From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 1 00:21:23 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 01 Feb 2007 01:21:23 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170155715.3368.34.camel@hughsie-laptop> (Richard Hughes's message of "Tue, 30 Jan 2007 11:15:15 +0000") References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> Message-ID: <87r6taohh8.fsf@kosh.bigo.ensc.de> hughsient at gmail.com (Richard Hughes) writes: > Suspend-to-disk should probably be "hibernate" and suspend-to-ram > should be "suspend". I do not think so. I can not imagine what 'hibernate' means or which components are affected by 'suspend'. 'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Feb 1 00:40:43 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 31 Jan 2007 18:40:43 -0600 Subject: F7 KDE spin References: <45A2BABB.2090902@math.unl.edu> <16de708d0701081825l33023bd4p818ad14919feae0b@mail.gmail.com> <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> <45C124AB.4020109@redhat.com> Message-ID: Warren Togami wrote: > The htmlview and launchmail in FC7 should fallback to *any* browser in a > list of fallbacks if the configured browser or mail client doesn't > exist. This should help this case... although htmlview could probably > use a lot more cleanup. xdg-open pretty much deprecates htmlview, imo. It'll open arbitrary file,URL using the current desktop's default app for that mimetype. -- Rex From chitlesh at fedoraproject.org Thu Feb 1 01:15:35 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 1 Feb 2007 02:15:35 +0100 Subject: F7 KDE spin In-Reply-To: <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> References: <45A2BABB.2090902@math.unl.edu> <16de708d0701081825l33023bd4p818ad14919feae0b@mail.gmail.com> <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> Message-ID: <13dbfe4f0701311715q4bec3b8eg5548dd752ce27a8@mail.gmail.com> On 1/31/07, Chitlesh GOORAH wrote: > I'll publish the full list of rpms after the updates to rawhide. here is the list a2ps-4.13b-60.fc7 acl-2.2.39-1.1 acpid-1.0.4-5 alsa-lib-1.0.14-0.2.rc2.fc7 alsa-utils-1.0.14-0.3.rc2.fc7 anacron-2.3-45.fc7 apmd-3.2.2-5 arts-1.5.6-1.fc7 aspell-0.60.5-2.fc7 aspell-en-6.0-2.1 at-3.1.10-6.fc7 atk-1.13.2-1.fc7 attr-2.4.32-1.1 audiofile-0.2.6-5 audit-libs-1.3.1-2.fc7 audit-libs-python-1.3.1-2.fc7 authconfig-5.3.13-1.fc7 authconfig-gtk-5.3.13-1.fc7 autofs-5.0.1-0.rc3.13 autorun-3.20-1.1 avahi-0.6.16-2.fc7 avahi-glib-0.6.16-2.fc7 avahi-qt3-0.6.16-2.fc7 basesystem-8.0-5.1.1 bash-3.2-4.fc7 bc-1.06-23 beecrypt-4.1.2-12 bind-libs-9.3.4-2.fc7 bind-utils-9.3.4-2.fc7 binutils-2.17.50.0.9-1 bitmap-fonts-0.3-5.1.1 bitstream-vera-fonts-1.10-7 bluez-gnome-0.6-1.fc7 bluez-libs-3.9-1.fc7 bluez-utils-3.9-1.fc7 busybox-1.2.2-4.fc7 bzip2-1.0.4-1.fc7 bzip2-libs-1.0.4-1.fc7 cairo-1.3.12-1.fc7 ccid-1.1.0-2 cdparanoia-libs-alpha9.8-27.2 chkconfig-1.3.30-1 chkfontpath-1.10.1-1.1 compat-db-4.3.29-2.fc7 comps-extras-11.1-1.1 coolkey-1.0.1-15.fc7 coreutils-6.7-3.fc7 cpio-2.6-23.fc7 cpp-4.1.1-54 cpuspeed-1.2.1-1.53.fc7 cracklib-2.8.9-7 cracklib-dicts-2.8.9-7 crash-4.0-3.3 crontabs-1.10-12.fc7 cryptsetup-luks-1.0.3-3.fc7 cups-1.2.7-7.fc7 cups-libs-1.2.7-7.fc7 curl-7.16.1-1.fc7 cyrus-sasl-2.1.22-5 cyrus-sasl-lib-2.1.22-5 cyrus-sasl-plain-2.1.22-5 db4-4.5.20-4.fc7 dbus-1.0.1-9.fc6 dbus-glib-0.71-4.fc7 dbus-python-0.80.1-1.fc7 dbus-x11-1.0.1-9.fc6 dejavu-lgc-fonts-2.13-1 desktop-backgrounds-basic-2.0-37 desktop-file-utils-0.12-1.fc7 desktop-printing-0.20-3.fc7 device-mapper-1.02.17-1.fc7 device-mapper-multipath-0.4.7-9.fc7 dhcdbd-2.2-1.fc7 dhclient-3.0.5-11.fc7 dhcpv6_client-0.10-35.fc7 diffutils-2.8.1-16.fc7 dmidecode-2.7-1.26.1.fc6 dmraid-1.0.0.rc14-1.fc7 docbook-dtds-1.0-30.1 dos2unix-3.1-27.1 dosfstools-2.11-6.1.fc7 dump-0.4b41-5.fc7 e2fsprogs-1.39-9 e2fsprogs-libs-1.39-9 echo-icon-theme-0.1-6.fc7 ed-0.4-1 eject-2.1.5-5 elfutils-libelf-0.125-3.fc7 enscript-1.6.4-6.fc7 esound-0.2.36-4.fc7 esound-libs-0.2.36-4.fc7 ethtool-5-1.fc7 expat-1.95.8-9 fbset-2.1-24.fc7 fedora-logos-6.0.90-1.fc7 fedora-release-6.90-2 fedora-release-notes-6-3 file-4.19-2.fc7 file-libs-4.19-2.fc7 filesystem-2.4.1-1 findutils-4.2.29-2 finger-0.17-32.2.1.1 firstboot-1.4.29-1.fc7 firstboot-tui-1.4.29-1.fc7 flac-1.1.2-27 fontconfig-2.4.2-2.fc7 foomatic-3.0.2-45.fc7 freetype-2.3.0-2.fc7 fribidi-0.10.7-5.1 ftp-0.17-35.fc7 gamin-0.1.8-3.fc7 gawk-3.1.5-14.fc7 GConf2-2.16.0-4.fc7 gdbm-1.8.0-26.2.1 gettext-0.16.1-3.fc7 ghostscript-8.15.3-7.fc7 ghostscript-fonts-5.50-14.fc7 glib2-2.12.9-1.fc7 glibc-2.5.90-15 glibc-common-2.5.90-15 glx-utils-6.5.2-4.fc7 gmp-4.1.4-11 gnome-keyring-0.7.3-1.fc7 gnome-mime-data-2.4.3-2.fc7 gnome-mount-0.5-3.fc7 gnome-python2-2.17.2-1.fc7 gnome-python2-bonobo-2.17.2-1.fc7 gnome-python2-canvas-2.17.2-1.fc7 gnome-python2-gconf-2.17.2-1.fc7 gnome-python2-gnomevfs-2.17.2-1.fc7 gnome-vfs2-2.17.90-1.fc7 gnupg-1.4.6-3 gnutls-1.4.1-2 gpg-pubkey-1ac70ce6-41bebeef gpg-pubkey-4f2a6fd2-3f9d9d3b gphoto2-2.3.1-3.fc7 gpm-1.20.1-80.fc7 grep-2.5.1-57.fc7 groff-1.18.1.4-2 grub-0.97-13 gtk2-2.10.9-2.fc7 gtk2-engines-2.9.2-1.fc7 gtk-qt-engine-0.70-4.20061211svn.fc7 gzip-1.3.9-2.fc7 hal-0.5.8.1-6.fc7 hal-cups-utils-0.6.5-1.fc7 hdparm-6.9-1 hesiod-3.1.0-8 hicolor-icon-theme-0.10-1 hpijs-1.6.12-1.fc7 hplip-1.6.12-1.fc7 htdig-3.2.0b6-9.fc7 htmlview-3.0.0-15.fc7 hwdata-0.195-1 ifd-egate-0.05-15 im-chooser-0.3.4-1.fc7 info-4.8-15 initscripts-8.48-1 iproute-2.6.19-1.fc7 ipsec-tools-0.6.6-1 iptables-1.3.7-1.1 iptables-ipv6-1.3.7-1.1 iptstate-1.4-1.1.2.2 iputils-20020927-41.fc6 irda-utils-0.9.18-1.fc7 irqbalance-0.55-2.fc7 jwhois-3.2.3-10 katapult-0.3.1.4-3.fc7 kbd-1.12-21 kdeaccessibility-3.5.5-0.1.fc6 kdeaddons-3.5.5-0.1.fc6 kdeartwork-3.5.5-0.1.fc6 kdebase-3.5.5-0.4.fc6 kdegraphics-3.5.5-0.1.fc6 kdelibs-3.5.5-1.fc7 kdemultimedia-3.5.5-0.1.fc6 kdenetwork-3.5.5-0.1.fc6 kdepim-3.5.5-1.fc7 kdeutils-3.5.5-3.fc7 kdmtheme-1.1.2-4.fc7 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 kernel-2.6.19-1.2914.fc7 kernel-2.6.19-1.2916.fc7 kernel-headers-2.6.19-1.2916.fc7 kexec-tools-1.101-58.fc7 kleansweep-0.2.9-3.fc7 kmenu-gnome-0.6.2-1.fc7 kpartx-0.4.7-9.fc7 krb5-auth-dialog-0.7-1 krb5-libs-1.6-1 krb5-workstation-1.6-1 ksh-20060214-1.1 kudzu-1.2.64-2 lcms-1.15-2 less-394-6.fc7 lftp-3.5.9-1.fc7 libacl-2.2.39-1.1 libart_lgpl-2.3.17-4 libattr-2.4.32-1.1 libbonobo-2.17.90-1.fc7 libbonoboui-2.17.90-1.fc7 libcap-1.10-25 libcroco-0.6.1-2.1 libdaemon-0.10-3.2 libdhcp-1.19-3.fc7 libdhcp4client-3.0.5-11.fc7 libdhcp6client-0.10-35.fc7 libdmx-1.0.2-3.1 libdrm-2.3.0-2.fc7 libevent-1.1a-3.2.1 libexif-0.6.13-2 libfontenc-1.0.4-2.fc7 libFS-1.0.0-3.1 libgcc-4.1.1-54 libgcrypt-1.2.3-2 libglade2-2.6.0-3.fc7 libgnome-2.17.90-1.fc7 libgnomecanvas-2.14.0-5.fc7 libgnomecups-0.2.2-8 libgnomeui-2.17.90-1.fc7 libgomp-4.1.1-54 libgpg-error-1.4-2 libgsf-1.14.3-2 libgssapi-0.10-1 libICE-1.0.3-1.fc7 libIDL-0.8.7-2.fc7 libidn-0.6.8-4 libieee1284-0.2.9-4 libjpeg-6b-37 libmng-1.0.9-5.1 libnl-1.0-0.10.pre5.4 libnotify-0.4.3-2.fc7 libogg-1.1.3-2.fc6 libpcap-0.9.5-1.fc7 libpng-1.2.10-7 libraw1394-1.2.1-1.fc6 librsvg2-2.16.1-1.fc7 libsane-hpaio-1.6.12-1.fc7 libselinux-1.34.0-3.fc7 libselinux-python-1.34.0-3.fc7 libsemanage-1.10.0-2.fc7 libsepol-1.16.0-1.fc7 libSM-1.0.2-1 libstdc++-4.1.1-54 libsysfs-2.1.0-1.fc7 libtermcap-2.0.8-46.1 libthai-0.1.7-5.fc7 libtheora-1.0alpha7-1 libtiff-3.8.2-7.fc7 libusb-0.1.12-6.fc7 libuser-0.55-2 libutempter-1.1.4-3.fc6 libvolume_id-104-1 libvorbis-1.1.2-1.2.1 libwnck-2.16.2-1.fc7 libX11-1.0.3-7.fc7 libXau-1.0.3-1.fc7 libXaw-1.0.2-8.1 libXcomposite-0.3.1-1 libXcursor-1.1.8-1 libXdamage-1.0.4-1 libXdmcp-1.0.2-2.fc7 libXext-1.0.1-2.1 libXfixes-4.0.3-1 libXfont-1.2.6-2.fc7 libXfontcache-1.0.4-1.fc7 libXft-2.1.12-1.fc7 libXi-1.0.2-1 libXinerama-1.0.1-2.1 libxkbfile-1.0.4-1.fc7 libxml2-2.6.27-2 libxml2-python-2.6.27-2 libXmu-1.0.3-1.fc7 libXpm-3.5.6-1 libXrandr-1.1.2-1.fc7 libXrender-0.9.2-1.fc7 libXres-1.0.2-1.fc7 libXScrnSaver-1.1.2-1.fc7 libxslt-1.1.20-1.fc6 libXt-1.0.4-1.fc7 libXTrap-1.0.0-3.1 libXtst-1.0.1-3.1 libXv-1.0.3-1.fc7 libXxf86dga-1.0.1-3.1 libXxf86misc-1.0.1-3.1 libXxf86vm-1.0.1-3.1 linuxwacom-0.7.4_1-2.1 lm_sensors-2.10.1-1.fc7 lockdev-1.0.1-10 logrotate-3.7.4-11.fc7 logwatch-7.3.2-5.fc7 lsof-4.78-3 lvm2-2.02.21-1.fc7 m4-1.4.8-1 mailcap-2.1.23-1.fc6 mailx-8.1.1-44.2.2 make-3.81-3.fc7 MAKEDEV-3.23-1.2 man-1.6e-2.fc7 man-pages-2.43-4.fc7 mcstrans-0.1.10-1.fc7 mdadm-2.6-1.fc7 mesa-libGL-6.5.2-4.fc7 mesa-libGLU-6.5.2-4.fc7 metacity-2.17.5-1.fc7 mgetty-1.1.33-10.fc7 microcode_ctl-1.13-1.37.fc7 mingetty-1.07-5.2.2 mkbootdisk-1.5.3-2.1 mkinitrd-6.0.6-3 mktemp-1.5-24.fc7 mlocate-0.15-2 module-init-tools-3.3-0.pre3.1.6.fc7 mtools-3.9.10-3.fc7 mtr-0.71-3.1 nano-1.3.12-1.1 nash-6.0.6-3 nc-1.84-10.fc6 ncurses-5.6-2.20070120.fc7 neon-0.25.5-5.1 net-snmp-libs-5.4-8.fc7 net-tools-1.60-77.fc7 NetworkManager-0.6.5-0.cvs20061025.fc7.1 NetworkManager-glib-0.6.5-0.cvs20061025.fc7.1 newt-0.52.4-3.fc7 nfs-utils-1.0.10-5.fc6 nfs-utils-lib-1.0.8-7.2 notification-daemon-0.3.6-1.fc7 notify-python-0.1.0-4.fc7 nscd-2.5.90-15 nspr-4.6.5-1 nss-3.11.4-5.fc7 nss_db-2.2-35.1 nss_ldap-253-4 nss-tools-3.11.4-5.fc7 ntp-4.2.4-4.fc7 ntsysv-1.3.30-1 numactl-0.9.8-2.fc7 openjade-1.3.2-27 openldap-2.3.30-1.1.fc7 opensp-1.5.2-3.1 openssh-4.5p1-2.fc7 openssh-askpass-4.5p1-2.fc7 openssh-clients-4.5p1-2.fc7 openssh-server-4.5p1-2.fc7 openssl-0.9.8b-12.fc7 ORBit2-2.14.5-2.fc7 pam-0.99.7.1-1.fc7 pam_ccreds-3-5 pam_krb5-2.2.11-1 pam_passwdqc-1.0.2-1.2.2 pam_pkcs11-0.5.3-22 pam_smb-1.1.7-7.2.1 pango-1.15.5-1.fc7 paps-0.6.6-17.fc7 parted-1.8.2-4.fc7 passwd-0.74-2 patch-2.5.4-29.2.2 pax-3.4-1.2.2 pciutils-2.2.3-4 pcmciautils-014-5 pcre-7.0-2 pcsc-lite-1.3.2-1 pcsc-lite-libs-1.3.2-1 perl-5.8.8-12.fc7 perl-String-CRC32-1.4-2.fc6 pilot-link-0.12.1-4.fc7 pinfo-0.6.9-2.fc7 pirut-1.2.10-1.fc7 pkgconfig-0.21-3.fc7 pm-utils-0.19.1-6.fc7 policycoreutils-1.34.1-3.fc7 popt-1.10.2-39.fc7 portmap-4.0-65.3 ppp-2.4.4-2 prelink-0.3.10-1 procmail-3.22-18 procps-3.2.7-8 psacct-6.3.2-43.fc7 psmisc-22.2-5 psutils-1.17-26.1 pycairo-1.2.6-2.fc7 pygobject2-2.12.3-2.fc7 pygtk2-2.10.3-7.fc7 pygtk2-libglade-2.10.3-7.fc7 pyorbit-2.14.1-2 PyQt-3.17-3 python-2.5-9.fc7 python-libs-2.5-9.fc7 python-numeric-24.2-3 python-urlgrabber-2.9.9-5.fc7 pyxf86config-0.3.32-1.fc7 PyXML-0.8.4-5 qt-3.3.7-2.fc7 quota-3.13-1.3.fc7 rdate-1.4-6 rdist-6.1.5-44 readahead-1.3-5 readline-5.2-2.fc7 redhat-artwork-5.0.8-4.fc7 redhat-lsb-3.1-12.2 redhat-menus-7.8.9-4.fc7 rhgb-0.16.4-4.fc7 rhpl-0.201-2 rhpxl-0.42-1.fc7 rmt-0.4b41-5.fc7 rng-utils-2.0-1.14.1.fc6 rootfiles-8.1-1.1.1 rpm-4.4.2-39.fc7 rpm-libs-4.4.2-39.fc7 rpm-python-4.4.2-39.fc7 rp-pppoe-3.5-32.1 rsh-0.17-39.fc7 rsync-2.6.9-1 samba-client-3.0.23c-2 samba-common-3.0.23c-2 sane-backends-1.0.18-5.fc7 sane-backends-libs-1.0.18-5.fc7 scrollkeeper-0.3.14-10.fc7 SDL-1.2.10-9 sed-4.1.5-7.fc7 selinux-policy-2.5.2-2.fc7 selinux-policy-targeted-2.5.2-2.fc7 sendmail-8.13.8-4 setarch-2.0-3.fc7 setserial-2.17-19.2.2 setup-2.6.2-1.fc7 setuptool-1.19.2-2 sgml-common-0.6.3-19 shadow-utils-4.0.18.1-9.fc7 shared-mime-info-0.19-2.fc7 sip-4.5.2-1 slang-2.0.7-1.fc7 smartmontools-5.36-5.fc7 sox-12.18.1-1 specspo-12-1 sqlite-3.3.6-2 startup-notification-0.8-4.1 stunnel-4.20-2 sudo-1.6.8p12-11.fc7 switchdesk-4.0.8-6 symlinks-1.2-26.fc7 synaptics-0.14.4-8.fc6 sysklogd-1.4.1-43.fc7 sysklogd-1.4.1-44.fc7 syslinux-3.31-2 sysreport-1.4.3-9 system-config-date-1.8.11-1.fc7 system-config-display-1.0.48-1.fc7 system-config-keyboard-1.2.11-1.fc7 system-config-language-1.1.16-1.fc7 system-config-lvm-1.0.18-1.2.FC6 system-config-network-1.3.96-1.fc6 system-config-network-tui-1.3.96-1.fc6 system-config-printer-0.7.49-1.fc7 system-config-printer-libs-0.7.49-1.fc7 system-config-rootpassword-1.1.10-1 system-config-securitylevel-1.7.0-1.fc7 system-config-securitylevel-tui-1.7.0-1.fc7 system-config-services-0.9.4-1.fc7 system-config-soundcard-2.0.6-2.fc7 system-config-users-1.2.51-1.fc7 SysVinit-2.86-14 talk-0.17-29.2.2 tar-1.15.1-25.fc7 tcpdump-3.9.5-2.fc7 tcp_wrappers-7.6-41 tcp_wrappers-libs-7.6-41 tcsh-6.14-13 telnet-0.17-37 termcap-5.5-1.20060701.1 time-1.7-28.fc7 tmpwatch-2.9.10-1 traceroute-2.0.3-1.1.fc7 tree-1.5.0-5.fc7 ttmkfdir-3.0.9-24.fc7 tzdata-2007a-1.fc7 udev-104-1 unix2dos-2.2-26.2.2 unzip-5.52-2.2.1 urw-fonts-2.3-6.1.1 usbutils-0.71-2.1 usermode-1.87-3 usermode-gtk-1.87-3 util-linux-2.13-0.49.fc7 vconfig-1.9-3.fc7 vim-minimal-7.0.188-3 vixie-cron-4.1-73.fc7 vnc-server-4.1.2-10.fc7 vte-0.15.2-1.fc7 wget-1.10.2-12.fc7 which-2.16-8 wireless-tools-28-1.fc6 words-3.0-10.fc7 wpa_supplicant-0.4.9-1.fc7 xkeyboard-config-0.8-7.fc6 xml-common-0.6.3-19 xorg-x11-apps-7.1-4.fc7 xorg-x11-drivers-7.1-3 xorg-x11-drv-acecad-1.1.0-2.1 xorg-x11-drv-aiptek-1.0.1-2 xorg-x11-drv-apm-1.1.1-2.1 xorg-x11-drv-ark-0.6.0-2.1 xorg-x11-drv-ast-0.81.0-3 xorg-x11-drv-ati-6.6.3-1.fc7 xorg-x11-drv-calcomp-1.1.0-1.1 xorg-x11-drv-chips-1.1.1-2.1 xorg-x11-drv-cirrus-1.1.0-2.fc6 xorg-x11-drv-citron-2.2.0-1.1 xorg-x11-drv-cyrix-1.1.0-4 xorg-x11-drv-digitaledge-1.1.0-1.1 xorg-x11-drv-dmc-1.1.0-2 xorg-x11-drv-dummy-0.2.0-2.1 xorg-x11-drv-dynapro-1.1.0-2 xorg-x11-drv-elo2300-1.1.0-1.1 xorg-x11-drv-elographics-1.1.0-1.1 xorg-x11-drv-evdev-1.1.2-2.1 xorg-x11-drv-fbdev-0.3.1-1.fc7 xorg-x11-drv-fpit-1.1.0-1.1 xorg-x11-drv-glint-1.1.1-4.1 xorg-x11-drv-hyperpen-1.1.0-2 xorg-x11-drv-i128-1.2.0-4 xorg-x11-drv-i740-1.1.0-2.1 xorg-x11-drv-i810-1.6.5-11.fc7 xorg-x11-drv-jamstudio-1.1.0-1.1 xorg-x11-drv-joystick-1.1.0-1.1 xorg-x11-drv-keyboard-1.1.0-2.1 xorg-x11-drv-magellan-1.1.0-1.1 xorg-x11-drv-magictouch-1.0.0.5-2.1 xorg-x11-drv-mga-1.4.6.1-1.fc7 xorg-x11-drv-microtouch-1.1.0-1.1 xorg-x11-drv-mouse-1.2.1-1.fc7 xorg-x11-drv-mutouch-1.1.0-2 xorg-x11-drv-neomagic-1.1.1-2.1 xorg-x11-drv-nsc-2.8.1-3.fc7 xorg-x11-drv-nv-1.2.2.1-1.fc7 xorg-x11-drv-palmax-1.1.0-1.1 xorg-x11-drv-penmount-1.1.0-2.1 xorg-x11-drv-rendition-4.1.3-1.fc7 xorg-x11-drv-s3-0.5.0-1.fc7 xorg-x11-drv-s3virge-1.9.1-2.1 xorg-x11-drv-savage-2.1.2-1.fc7 xorg-x11-drv-siliconmotion-1.4.1-2.1 xorg-x11-drv-sis-0.9.3-1.fc7 xorg-x11-drv-sisusb-0.8.1-4.1 xorg-x11-drv-spaceorb-1.1.0-1.1 xorg-x11-drv-summa-1.1.0-1.1 xorg-x11-drv-tdfx-1.3.0-2.fc7 xorg-x11-drv-trident-1.2.3-2.fc7 xorg-x11-drv-tseng-1.1.0-3.1 xorg-x11-drv-ur98-1.1.0-1.1 xorg-x11-drv-v4l-0.1.1-4 xorg-x11-drv-vesa-1.3.0-2.fc7 xorg-x11-drv-vga-4.1.0-2.1 xorg-x11-drv-via-0.2.1-7 xorg-x11-drv-vmmouse-12.4.0-2.1 xorg-x11-drv-vmware-10.14.1-1.fc7 xorg-x11-drv-void-1.1.0-3.1 xorg-x11-drv-voodoo-1.1.0-3.1 xorg-x11-filesystem-7.1-2.fc6 xorg-x11-fonts-100dpi-7.1-3.fc7 xorg-x11-fonts-75dpi-7.1-3.fc7 xorg-x11-fonts-base-7.1-3.fc7 xorg-x11-fonts-ISO8859-1-100dpi-7.1-3.fc7 xorg-x11-fonts-ISO8859-1-75dpi-7.1-3.fc7 xorg-x11-fonts-misc-7.1-3.fc7 xorg-x11-fonts-truetype-7.1-3.fc7 xorg-x11-fonts-Type1-7.1-3.fc7 xorg-x11-font-utils-7.1-2 xorg-x11-server-utils-7.1-5.fc7 xorg-x11-server-Xorg-1.2.0-3.fc7 xorg-x11-twm-1.0.1-3.1 xorg-x11-utils-7.1-3.fc7 xorg-x11-xauth-1.0.2-1.fc7 xorg-x11-xdm-1.1.3-1.fc7 xorg-x11-xfs-1.0.2-3.1 xorg-x11-xinit-1.0.2-15.fc7 xorg-x11-xkb-utils-1.0.2-3.fc7 xsri-2.1.0-10.fc6 xterm-223-2.fc7 yakuake-2.7.5-4.fc7 ypbind-1.19-7.fc7 yp-tools-2.9-0.1 yum-3.1.0-2.fc7 yum-metadata-parser-1.0.3-1.fc7 yum-updatesd-3.1.0-2.fc7 zip-2.31-1.2.2 zlib-1.2.3-4 I've installed kleansweep, kdmtheme, yakuake and katapult from FE :) -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Thu Feb 1 01:18:56 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 1 Feb 2007 02:18:56 +0100 Subject: F7 KDE spin In-Reply-To: <45C124AB.4020109@redhat.com> References: <45A2BABB.2090902@math.unl.edu> <16de708d0701081825l33023bd4p818ad14919feae0b@mail.gmail.com> <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> <45C124AB.4020109@redhat.com> Message-ID: <13dbfe4f0701311718h78ea9fceu91cec9feb4b748b9@mail.gmail.com> On 2/1/07, Warren Togami wrote: > The htmlview and launchmail in FC7 should fallback to *any* browser in a > list of fallbacks if the configured browser or mail client doesn't > exist. This should help this case... although htmlview could probably > use a lot more cleanup. Cool that could help :) The previous list I sent could be useful if someone wants to strip down useless apps from the kde spin. However, what will be status of the pup applet on the kicker, knowing the fact that in fc6 kde it isn't on the kicker and hence the service yum-updatesd is no more useful. Chitlesh -- http://clunixchit.blogspot.com From alan at redhat.com Thu Feb 1 01:30:19 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 31 Jan 2007 20:30:19 -0500 Subject: export restrictions in EULA In-Reply-To: <883cfe6d0701311218m64c6a17bif5f3ce0dbd9662fb@mail.gmail.com> References: <3118d8de0701310816k78a3a235w3880afd07a5ac264@mail.gmail.com> <3118d8de0701310826y51c9d403jc388c1c68201d9e1@mail.gmail.com> <883cfe6d0701311218m64c6a17bif5f3ce0dbd9662fb@mail.gmail.com> Message-ID: <20070201013019.GA12608@devserv.devel.redhat.com> On Wed, Jan 31, 2007 at 03:18:00PM -0500, Michel Salim wrote: > >curiosity how is that being enforced on the Fedora infrastructure end, > >and how is that restriction handling passed to mirrors? Is each > >mirror required to implement their own set of restrictions? Does a > >Fedora mirror server in Canada (or some other non-restricted country) > >sidestep that issue? If so, doesn't that basically make the EULA > >clause moot (from a once the dam is broken kinda perspective)? With my Red Hat firmly *off* I can perhaps comment on the situation a little. US companies and citizens are in the rather peculiar state of actually being forbidden from dealing with some countries or even visiting certain of them (as opposed to merely being forbidden to deal commercially with or sell "dual use" products to them). Cuba is one of these for rather political reasons. As a US company Red Hat is obliged to follow US law, ditto US citizens. In other jurisdictions the laws vary - restrictions like the US one are very rare but some countries do count crypto as stuff not to be shipped to their particular list of "rogue states". So if you run a mirror check the local law. In other states you may actually be committing an offence if you enforce the US regulations, as it falls under various kinds of "racial discrimination" laws. And Canada has its own collection of laws to do with Cuba designed to maximally screw up any attempt by the USA to enforce US law on Canadian companies. Not sure how that affects Canadian mirrors. Every piece of software has ugly corners people prefer not to touch or look into, export law often seems to be one of the legal equivalents because it used as a political tool. Alan From pemboa at gmail.com Thu Feb 1 01:37:11 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 31 Jan 2007 19:37:11 -0600 Subject: export restrictions in EULA In-Reply-To: <3118d8de0701310826y51c9d403jc388c1c68201d9e1@mail.gmail.com> References: <3118d8de0701310816k78a3a235w3880afd07a5ac264@mail.gmail.com> <3118d8de0701310826y51c9d403jc388c1c68201d9e1@mail.gmail.com> Message-ID: <16de708d0701311737k4196748sdfa681643c912382@mail.gmail.com> On 1/31/07, Jason Corley wrote: > I'm not sure what list this is really appropriate for, so apologies if > this is the wrong forum. I noticed that the Fedora EULA still include > notes about export restrictions, specifically: > > "... understands that certain of the software are subject to export controls > under the U.S. Commerce Departments Export Administration Regulations > (EAR) ..." > > Cuba, Iran, North Korea, etc. are all restricted areas. Out of > curiosity how is that being enforced on the Fedora infrastructure end, > and how is that restriction handling passed to mirrors? Is each > mirror required to implement their own set of restrictions? Does a > Fedora mirror server in Canada (or some other non-restricted country) > sidestep that issue? If so, doesn't that basically make the EULA > clause moot (from a once the dam is broken kinda perspective)? > > Jason > So wait. Are you trying to bind Fedora as an American distro? I thought Linux was without borders. If this is the case I am going to have to look at my ticket pass for Fedora again. I was of the opinion there was no need for politics here in Fedora. -- Fedora Core 6 and proud From pemboa at gmail.com Thu Feb 1 01:39:20 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 31 Jan 2007 19:39:20 -0600 Subject: Spyware, smolt, yum In-Reply-To: References: <20070131180152.9EB887399A@hormel.redhat.com> Message-ID: <16de708d0701311739k1a9fc439jfcb38f6ee6adc7a5@mail.gmail.com> On 1/31/07, chris at idlelion.net wrote: > I read that the number of machines using Fedora is being counted from > their use of getting updates with yum. > > FC6 sets this up by default, with no instruction or permission to me, nor > any notice or question to me. > > Is it spyware, by your definition? (Where you = anyone.) You read wrong. Yum isn't doing anything. -- Fedora Core 6 and proud From rc040203 at freenet.de Thu Feb 1 01:46:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 02:46:31 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> Message-ID: <1170294392.5838.587.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 11:10 -0700, Tom Tromey wrote: > >>>>> "Ralf" == Ralf Corsepius writes: > > Ralf> I don't have any reasons to trust this URL smolt sends it data too. > > In principle I think this site should be controlled by the fedora project. Why do you think are people disabling log-in prompts, forging/suppressing server id-strings, not using HINFO records in named etc. ? .. for not exposing details to the public to prevent them from exposing them from avoidable unnecessarily vulnerabilities. Not worth mentioning, jerks sneaking on connections, theft of the data base, connecting this data with data available from other sources and selling this data ... This consideration alone is sufficient reason for me to classify smolt as non-acceptable. > I didn't look to see whether it is or not. But in any case IMO it > ought to be approximately as trustworthy as the standard yum servers. > > The smolt data looked quite nice to me. Good stuff to know. Pardon, but you'd better never mention the word "security" in a Fedora context again ;) Ralf From rc040203 at freenet.de Thu Feb 1 01:56:50 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 02:56:50 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170266495.23602.18.camel@dawkins> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170266495.23602.18.camel@dawkins> Message-ID: <1170295010.5838.596.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 19:01 +0100, David Nielsen wrote: > On ons, 2007-01-31 at 18:54 +0100, Ralf Corsepius wrote: > > > There is not way to convince me about such spy-ware. If you want to > > collect statics with an opt-in, you can achieve the same by launching a > > counter website. > > What a brilliant way to have a debate "nothing you can say can change my > mind".. that is the rhetoric of conspiracy theorists and other breeds of > true believers. Would you have preferred me to say: "Hell needs to freeze in before I'll install this piece of crap?" And it's not related to conspiracy - It's about privacy. Less politely: My HW profile is none of your business. BTW, my person definition of SPYWARE: A piece of software which silently collects otherwise unavailable data and transmits it without any technical need to operate a local machine. Ralf From pemboa at gmail.com Thu Feb 1 02:01:46 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 31 Jan 2007 20:01:46 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170295010.5838.596.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170266495.23602.18.camel@dawkins> <1170295010.5838.596.camel@mccallum.corsepiu.local> Message-ID: <16de708d0701311801h41dd4494vd1310974056d377f@mail.gmail.com> On 1/31/07, Ralf Corsepius wrote: > On Wed, 2007-01-31 at 19:01 +0100, David Nielsen wrote: > > On ons, 2007-01-31 at 18:54 +0100, Ralf Corsepius wrote: > > > > > There is not way to convince me about such spy-ware. If you want to > > > collect statics with an opt-in, you can achieve the same by launching a > > > counter website. > > > > What a brilliant way to have a debate "nothing you can say can change my > > mind".. that is the rhetoric of conspiracy theorists and other breeds of > > true believers. > > Would you have preferred me to say: "Hell needs to freeze in before I'll > install this piece of crap?" > > And it's not related to conspiracy - It's about privacy. > Less politely: My HW profile is none of your business. > > BTW, my person definition of SPYWARE: > A piece of software which silently collects otherwise unavailable data > and transmits it without any technical need to operate a local machine. > > Ralf Go on and define 'silent' now. -- Fedora Core 6 and proud From ajackson at redhat.com Thu Feb 1 01:55:29 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 31 Jan 2007 20:55:29 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170295010.5838.596.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170266495.23602.18.camel@dawkins> <1170295010.5838.596.camel@mccallum.corsepiu.local> Message-ID: <1170294929.17252.107.camel@localhost.localdomain> On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote: > BTW, my person definition of SPYWARE: > A piece of software which silently collects otherwise unavailable data > and transmits it without any technical need to operate a local machine. So your web browser sends no useragent string? (troll, troll) - ajax From rc040203 at freenet.de Thu Feb 1 02:09:02 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 03:09:02 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170294929.17252.107.camel@localhost.localdomain> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170266495.23602.18.camel@dawkins> <1170295010.5838.596.camel@mccallum.corsepiu.local> <1170294929.17252.107.camel@localhost.localdomain> Message-ID: <1170295742.5838.598.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 20:55 -0500, Adam Jackson wrote: > On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote: > > > BTW, my person definition of SPYWARE: > > A piece of software which silently collects otherwise unavailable data > > and transmits it without any technical need to operate a local machine. > > So your web browser sends no useragent string? Guess why users fake them? Ralf From Curtis at GreenKey.net Thu Feb 1 01:35:25 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Wed, 31 Jan 2007 17:35:25 -0800 (PST) Subject: Why ship mx? In-Reply-To: <200701311516.52378.jkeating@redhat.com> References: <200701311516.52378.jkeating@redhat.com> Message-ID: <20070201013526.35DFC6F06E@alopias.GreenKey.net> 3:16pm Jesse Keating said: > Does anybody see any reason why we should continue to ship mx, in any form? > If not, we need to put it in the dead.package pile. > I've wrtitten a couple applications that make wicked use of mxDateTime to interact with external databases and systems that use goofy formats. Are there sufficient alternatives in Python 2.5? ../C From pemboa at gmail.com Thu Feb 1 02:15:21 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 31 Jan 2007 20:15:21 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170295742.5838.598.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170266495.23602.18.camel@dawkins> <1170295010.5838.596.camel@mccallum.corsepiu.local> <1170294929.17252.107.camel@localhost.localdomain> <1170295742.5838.598.camel@mccallum.corsepiu.local> Message-ID: <16de708d0701311815n60ceae24m30f71db785b80a30@mail.gmail.com> On 1/31/07, Ralf Corsepius wrote: > On Wed, 2007-01-31 at 20:55 -0500, Adam Jackson wrote: > > On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote: > > > > > BTW, my person definition of SPYWARE: > > > A piece of software which silently collects otherwise unavailable data > > > and transmits it without any technical need to operate a local machine. > > > > So your web browser sends no useragent string? > > Guess why users fake them? To get to IE only websites? -- Fedora Core 6 and proud From jkeating at redhat.com Thu Feb 1 02:20:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 21:20:02 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170294392.5838.587.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <1170294392.5838.587.camel@mccallum.corsepiu.local> Message-ID: <200701312120.05596.jkeating@redhat.com> On Wednesday 31 January 2007 20:46, Ralf Corsepius wrote: > Not worth mentioning, jerks sneaking on connections, theft of the data > base, connecting this data with data available from other sources and > selling this data ... Don't forget hacking the Gibson. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Curtis at GreenKey.net Thu Feb 1 02:20:27 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Wed, 31 Jan 2007 18:20:27 -0800 (PST) Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <604aa7910701311417l50264359me99c479972e270b8@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311130.37925.dennis@ausil.us> <1170275115.3790.2.camel@dhollis-lnx.sunera.com> <604aa7910701311417l50264359me99c479972e270b8@mail.gmail.com> Message-ID: <20070201022027.2AA5C6F070@alopias.GreenKey.net> 1:17pm Jeff Spaleta said: > -jef"lspci > 02:00.0 Brainwave Orbital Laser controller: Starbucks Coffee Co. > BOL203x (rev 09)" > spaleta > I suspect it's patent encumbered. :-p ../C From tromey at redhat.com Thu Feb 1 00:11:12 2007 From: tromey at redhat.com (Tom Tromey) Date: 31 Jan 2007 17:11:12 -0700 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170294392.5838.587.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> Message-ID: >>>>> "Ralf" == Ralf Corsepius writes: >> The smolt data looked quite nice to me. Good stuff to know. Ralf> Pardon, but you'd better never mention the word "security" in a Fedora Ralf> context again ;) Yeah. It's kind of hard to want to get involved again. I understand you're more worried about people somehow getting your hardware profile than I am. That's even understandable. What I don't understand is why clicking "No" is not enough. Tom From pemboa at gmail.com Thu Feb 1 02:00:27 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 31 Jan 2007 20:00:27 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170294392.5838.587.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> Message-ID: <16de708d0701311800j2b162591k6c2cf525b60c4050@mail.gmail.com> On 1/31/07, Ralf Corsepius wrote: > On Wed, 2007-01-31 at 11:10 -0700, Tom Tromey wrote: > > >>>>> "Ralf" == Ralf Corsepius writes: > > > > Ralf> I don't have any reasons to trust this URL smolt sends it data too. > > > > In principle I think this site should be controlled by the fedora project. > > Why do you think are people disabling log-in prompts, > forging/suppressing server id-strings, not using HINFO records in named > etc. ? No idea what you're talking about, and I consider myself somewhat paranoid. > .. for not exposing details to the public to prevent them from exposing > them from avoidable unnecessarily vulnerabilities. Well I guess the public could look at the large textbox with the data that could be sent, or open up ethereal to watch the unencrypted data....or they could just not click 'yes'. > Not worth mentioning, jerks sneaking on connections, theft of the data > base, connecting this data with data available from other sources and > selling this data ... We're still talking about data which contains solely of hardware information which is individually publicly available, but collectively somewhat unique to a computer right? > This consideration alone is sufficient reason for me to classify smolt > as non-acceptable. Okay. But your non-logical red-herring field arguments are getting somewhat annoying. > > I didn't look to see whether it is or not. But in any case IMO it > > ought to be approximately as trustworthy as the standard yum servers. > > > > The smolt data looked quite nice to me. Good stuff to know. > Pardon, but you'd better never mention the word "security" in a Fedora > context again ;) Now that's just uncalled for. > Ralf Arthur -- Fedora Core 6 and proud From caillon at redhat.com Thu Feb 1 02:25:15 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 31 Jan 2007 21:25:15 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170295742.5838.598.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170266495.23602.18.camel@dawkins> <1170295010.5838.596.camel@mccallum.corsepiu.local> <1170294929.17252.107.camel@localhost.localdomain> <1170295742.5838.598.camel@mccallum.corsepiu.local> Message-ID: <45C14F8B.2070801@redhat.com> Ralf Corsepius wrote: > On Wed, 2007-01-31 at 20:55 -0500, Adam Jackson wrote: > >> On Thu, 2007-02-01 at 02:56 +0100, Ralf Corsepius wrote: >> >> >>> BTW, my person definition of SPYWARE: >>> A piece of software which silently collects otherwise unavailable data >>> and transmits it without any technical need to operate a local machine. >>> >> So your web browser sends no useragent string? >> > > Guess why users fake them? > Silly me. I actually believed for a second that you were using evolution-2.8.2.1-3.fc6 to send your emails... From jkeating at redhat.com Thu Feb 1 02:25:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 21:25:43 -0500 Subject: Why ship mx? In-Reply-To: <20070201013526.35DFC6F06E@alopias.GreenKey.net> References: <200701311516.52378.jkeating@redhat.com> <20070201013526.35DFC6F06E@alopias.GreenKey.net> Message-ID: <200701312125.43735.jkeating@redhat.com> On Wednesday 31 January 2007 20:35, Curtis Doty wrote: > I've wrtitten a couple applications that make wicked use of mxDateTime to > interact with external databases and systems that use goofy formats. Are > there sufficient alternatives in Python 2.5? Hrm, perhaps I was speaking of the wrong app. I was thinking of mx the mail exchanger, not the python module. Disregard this message. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Feb 1 02:38:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 31 Jan 2007 21:38:25 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <45C14F8B.2070801@redhat.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <1170295742.5838.598.camel@mccallum.corsepiu.local> <45C14F8B.2070801@redhat.com> Message-ID: <200701312138.25728.jkeating@redhat.com> On Wednesday 31 January 2007 21:25, Christopher Aillon wrote: > Silly me. ?I actually believed for a second that you were using > evolution-2.8.2.1-3.fc6 to send your emails... From a machine with a local address of 192.168.1.100, external address hsi-kbw-082-212-056-027.hsi.kabelbw.de ([82.212.56.27]) blah blah blah... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at fedoraproject.org Thu Feb 1 02:44:58 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 31 Jan 2007 20:44:58 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170295010.5838.596.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170266495.23602.18.camel@dawkins> <1170295010.5838.596.camel@mccallum.corsepiu.local> Message-ID: <3237e4410701311844kb61ef13k36bde09d70fa0863@mail.gmail.com> On 1/31/07, Ralf Corsepius wrote: > BTW, my person definition of SPYWARE: > A piece of software which silently collects otherwise unavailable data > and transmits it without any technical need to operate a local machine. BTW, this is my personal definition of FUD. Don't participate Ralf. Seriously, its ok. If you don't want your hardware counted, don't. But sounding off and trying to prevent others from participating is bad form. -Mike From michael.wiktowy at gmail.com Thu Feb 1 02:48:26 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Wed, 31 Jan 2007 21:48:26 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> Message-ID: <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> On 1/31/07, Mike McGrath wrote: > On 1/31/07, Michael Wiktowy wrote: > > Does the profile give any indication whether the hardware is installed > > and working properly (or providing some limited functionality) or is > > it just cataloging its existence? > > The LHCP guys are doing this. Smolt has a much smaller scope. I think that the LHCP idea is fantastic! So if Smolt does not give any indication that hardware is working, it seems only useful when talking with tech support/bugzilla and you need a simple way to gather all the data on your machine to give to someone more knowledgeable to figure out. So what is derived from putting it into firstboot and collecting statistics that won't tell you anything other than the range of hardware that exists in the world? What the motivation is for collecting this data from everyone? I see Smolt as a useful tool for interactive troubleshooting but I can see much beneficial use for the data collected. Can you offer some examples? /Mike From mmcgrath at fedoraproject.org Thu Feb 1 02:56:12 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 31 Jan 2007 20:56:12 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> Message-ID: <3237e4410701311856r5aa176a8ue5c0b1a1d562b93b@mail.gmail.com> On 1/31/07, Michael Wiktowy wrote: > So if Smolt does not give any indication that hardware is working, it > seems only useful when talking with tech support/bugzilla and you need > a simple way to gather all the data on your machine to give to someone > more knowledgeable to figure out. > > So what is derived from putting it into firstboot and collecting > statistics that won't tell you anything other than the range of > hardware that exists in the world? What the motivation is for > collecting this data from everyone? I see Smolt as a useful tool for > interactive troubleshooting but I can see much beneficial use for the > data collected. Can you offer some examples? > > /Mike Tons. Hey Dell, did you know (insert number) people are using Fedora Linux on your systems? Mind helping us with driver support? Hey Nvidia, We've seen (insert number) people trying to use the nvidia cards. Unfortunately because your driver is not open source, many of them are unable to use all the features of your card. Hey dev's (insert popular hardware) we had no idea this many people were using this setup. Lets get one and test everything for them. Hey dev's almost no one is using (insert un-popular arch here) perhaps we should think about making it a secondary arch. Hey (insert popular university here) we've got a TON of users now, would you be interested in partnering with us to host some things? Perhaps we could propose some curriculum for your CS department? Depending on how the LHCP development goes we may add a "doesn't or does" work feature. But its not there right now. For Smolt I wanted to stay away from feature creep :-D Its initial inception was just for Metrics but as demands come about, we'll see. -Mike From katzj at redhat.com Thu Feb 1 02:55:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 31 Jan 2007 21:55:51 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> Message-ID: <1170298551.2892.5.camel@aglarond.local> On Wed, 2007-01-31 at 21:48 -0500, Michael Wiktowy wrote: > So what is derived from putting it into firstboot and collecting > statistics that won't tell you anything other than the range of > hardware that exists in the world? What the motivation is for > collecting this data from everyone? I see Smolt as a useful tool for > interactive troubleshooting but I can see much beneficial use for the > data collected. Can you offer some examples? For one thing, it gives us data on what hardware is the most commonly in use by Fedora users. This can help to focus testing, hardware purchases as well as some help when dealing with hardware vendors to improve drivers (or even write them in the first place) Jeremy From fenn at stanford.edu Thu Feb 1 03:11:18 2007 From: fenn at stanford.edu (Tim Fenn) Date: Wed, 31 Jan 2007 19:11:18 -0800 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <604aa7910701311417l50264359me99c479972e270b8@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311130.37925.dennis@ausil.us> <1170275115.3790.2.camel@dhollis-lnx.sunera.com> <604aa7910701311417l50264359me99c479972e270b8@mail.gmail.com> Message-ID: <20070201031117.GA15924@stanford.edu> On Wed, Jan 31, 2007 at 01:17:54PM -0900, Jeff Spaleta wrote: > On 1/31/07, David Hollis wrote: > >I also presume the stats web page would be expanded on to provide more > >than just Top 20 devices and such? The reason I ask is that as a device > >driver maintainer, it would certainly be interesting to be able to get > >some ideas on how many people have the device/are using the driver and > >platforms. > > We also totally need a section for the most snaztastic set of hardware > running fedora. I mean seriously, if someone is running fedora on the > equivalent audio/video setup as a 20 screen Movie Theature > Multiplex.. that would be interesting to highlight... if they choose > to let us know about it of course. > I know I'm not much of a regular contributor to the list, but I think this is a great idea: I've had more people ask me about fedora (and linux in general) thanks to my snazzy mythtv+fedora box at home than my "because its free!" argument, and I'm betting Jarod Wilson would agree. -Tim From michael.wiktowy at gmail.com Thu Feb 1 03:12:26 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Wed, 31 Jan 2007 22:12:26 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701311856r5aa176a8ue5c0b1a1d562b93b@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> <3237e4410701311856r5aa176a8ue5c0b1a1d562b93b@mail.gmail.com> Message-ID: <3e4ec4600701311912q433f5916s206a0489d34cb08e@mail.gmail.com> On 1/31/07, Mike McGrath wrote: > On 1/31/07, Michael Wiktowy wrote: > >Can you offer some examples? > Tons. > Depending on how the LHCP development goes we may add a "doesn't or > does" work feature. But its not there right now. For Smolt I wanted > to stay away from feature creep :-D Its initial inception was just > for Metrics but as demands come about, we'll see. OK ... I'm sold. I was under the impression that it was aggregating all the stats together on the server but it you (and hopefully all the users offering their personal data) are able to have complex queries like that (i.e. the association of which hardware is on which box), that is valuable from a marketing/strategic partnership perspective. Is it only in the FC6 yum repo at the moment? I tried installing it on my FC4 box and yum couldn't find it. /Mike From skvidal at linux.duke.edu Thu Feb 1 03:16:00 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 31 Jan 2007 22:16:00 -0500 Subject: export restrictions in EULA In-Reply-To: <16de708d0701311737k4196748sdfa681643c912382@mail.gmail.com> References: <3118d8de0701310816k78a3a235w3880afd07a5ac264@mail.gmail.com> <3118d8de0701310826y51c9d403jc388c1c68201d9e1@mail.gmail.com> <16de708d0701311737k4196748sdfa681643c912382@mail.gmail.com> Message-ID: <1170299760.32525.29.camel@cutter> On Wed, 2007-01-31 at 19:37 -0600, Arthur Pemberton wrote: > On 1/31/07, Jason Corley wrote: > > I'm not sure what list this is really appropriate for, so apologies if > > this is the wrong forum. I noticed that the Fedora EULA still include > > notes about export restrictions, specifically: > > > > "... understands that certain of the software are subject to export controls > > under the U.S. Commerce Departments Export Administration Regulations > > (EAR) ..." > > > > Cuba, Iran, North Korea, etc. are all restricted areas. Out of > > curiosity how is that being enforced on the Fedora infrastructure end, > > and how is that restriction handling passed to mirrors? Is each > > mirror required to implement their own set of restrictions? Does a > > Fedora mirror server in Canada (or some other non-restricted country) > > sidestep that issue? If so, doesn't that basically make the EULA > > clause moot (from a once the dam is broken kinda perspective)? > > > > Jason > > > > So wait. Are you trying to bind Fedora as an American distro? I > thought Linux was without borders. If this is the case I am going to > have to look at my ticket pass for Fedora again. I was of the opinion > there was no need for politics here in Fedora. Linux might be w/o borders but red hat is a US company and while this isn't about politics it is about law. So while "Linux" might not be stopped if someone violates the law red hat sure could be and therefore must comply with the laws of the country it occupies as its home. -sv From mmcgrath at fedoraproject.org Thu Feb 1 03:19:56 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 31 Jan 2007 21:19:56 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3e4ec4600701311912q433f5916s206a0489d34cb08e@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> <3237e4410701311856r5aa176a8ue5c0b1a1d562b93b@mail.gmail.com> <3e4ec4600701311912q433f5916s206a0489d34cb08e@mail.gmail.com> Message-ID: <3237e4410701311919k5c53c108l3319814304b791e3@mail.gmail.com> On 1/31/07, Michael Wiktowy wrote: > On 1/31/07, Mike McGrath wrote: > Is it only in the FC6 yum repo at the moment? I tried installing it on > my FC4 box and yum couldn't find it. > Watch for these in the next couple of days. I'm hoping to get FC3, 4 and 5 out. I'm not sure if I can get them into the yum repo (there's policies and FC3 and 4 are EOL'd) but you'll be able to download it and install it directly. -Mike From michael.wiktowy at gmail.com Thu Feb 1 03:32:08 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Wed, 31 Jan 2007 22:32:08 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701311919k5c53c108l3319814304b791e3@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> <3237e4410701311856r5aa176a8ue5c0b1a1d562b93b@mail.gmail.com> <3e4ec4600701311912q433f5916s206a0489d34cb08e@mail.gmail.com> <3237e4410701311919k5c53c108l3319814304b791e3@mail.gmail.com> Message-ID: <3e4ec4600701311932p7289a992ld9c37133d2cd4da4@mail.gmail.com> On 1/31/07, Mike McGrath wrote: > Watch for these in the next couple of days. I'm hoping to get FC3, 4 > and 5 out. I'm not sure if I can get them into the yum repo (there's > policies and FC3 and 4 are EOL'd) but you'll be able to download it > and install it directly. Count on your "Number of people still using FC4" numbers being skewed ;] I thought EOL meant no new official security updates, not a ban on developers putting their goods into Extras. Hmmm. I was planning on hopping back on the treadmill soon anyways ... after I do some research on the hardware compatibility and proper configuration of my Sil 3112 RAID controller ... hopefully you can tell me soon how many others out there have one of those :] /Mike From mmcgrath at fedoraproject.org Thu Feb 1 03:42:10 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 31 Jan 2007 21:42:10 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3e4ec4600701311932p7289a992ld9c37133d2cd4da4@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> <3237e4410701311856r5aa176a8ue5c0b1a1d562b93b@mail.gmail.com> <3e4ec4600701311912q433f5916s206a0489d34cb08e@mail.gmail.com> <3237e4410701311919k5c53c108l3319814304b791e3@mail.gmail.com> <3e4ec4600701311932p7289a992ld9c37133d2cd4da4@mail.gmail.com> Message-ID: <3237e4410701311942r4eac6e2cl7a08cf118d6dc173@mail.gmail.com> On 1/31/07, Michael Wiktowy wrote: > > Count on your "Number of people still using FC4" numbers being skewed ;] > > I thought EOL meant no new official security updates, not a ban on > developers putting their goods into Extras. Hmmm. I was planning on > hopping back on the treadmill soon anyways ... after I do some > research on the hardware compatibility and proper configuration of my > Sil 3112 RAID controller ... hopefully you can tell me soon how many > others out there have one of those :] I'm not sure what the official policy is actually or even if there is one. But I do know the builders have disabled fc3 and 4 builds. -Mike From Curtis at GreenKey.net Thu Feb 1 03:52:15 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Wed, 31 Jan 2007 19:52:15 -0800 (PST) Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701311204y78ddc877xb940a55e05cb99@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <87abzzov1f.fsf@kosh.bigo.ensc.de> <200701311445.54719.jkeating@redhat.com> <3237e4410701311204y78ddc877xb940a55e05cb99@mail.gmail.com> Message-ID: <20070201035215.913E16F070@alopias.GreenKey.net> 2:04pm Mike McGrath said: > On 1/31/07, Jesse Keating wrote: > > On Wednesday 31 January 2007 14:28, Enrico Scholz wrote: > > > mmh... what the heck is this tool doing? When I try to install it on my > > > servers I get > > > > Run this again with debug. Most likely smolt requires something which in > > turn > > has some heafty requires. > > > > redhat-lsb I might get rid of that. Does anyone here care about the > output from lsb_release? > Negative. On another note, I just fired up smolt on a Xen Dom0 and noticed that it reports varying values for systemMemory depending on how many DomUs are running. If it's trying to report hardware, then it should look beyond the hypervisor in this case. And of course, running smolt in a DomU is almost pointless. ../C From rc040203 at freenet.de Thu Feb 1 03:52:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 04:52:16 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <200701312138.25728.jkeating@redhat.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <1170295742.5838.598.camel@mccallum.corsepiu.local> <45C14F8B.2070801@redhat.com> <200701312138.25728.jkeating@redhat.com> Message-ID: <1170301937.5838.683.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 21:38 -0500, Jesse Keating wrote: > On Wednesday 31 January 2007 21:25, Christopher Aillon wrote: > > Silly me. I actually believed for a second that you were using > > evolution-2.8.2.1-3.fc6 to send your emails... Yes, it exposes me to be a likely victim of certain type of evolution (esp email) exploits. In other words, the fact evo transmits this info is a security relevant BUG in evolution. Nevertheless, evo is still is a client, not a server, so should exploits happen their impact is likely to be limited. On servers the situation is different, faking/suppressing id strings is pretty effective to at least to irritate potential attackers. > From a machine with a local address of 192.168.1.100, external address > hsi-kbw-082-212-056-027.hsi.kabelbw.de ([82.212.56.27]) blah blah blah... Yes, you apparently know to read mail headers. It doesn't tell you which NIC or GPU or CPU this machine has, if this is a physical machine at all (I could be masquerading) nor how many machines I have in my network, nor ... does it tell you the uptime, nor the bogomips nor does this allow you any conclusion on my income. Ralf From rc040203 at freenet.de Thu Feb 1 03:54:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 04:54:31 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <16de708d0701311800j2b162591k6c2cf525b60c4050@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <16de708d0701311800j2b162591k6c2cf525b60c4050@mail.gmail.com> Message-ID: <1170302071.5838.686.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 20:00 -0600, Arthur Pemberton wrote: > On 1/31/07, Ralf Corsepius wrote: > > On Wed, 2007-01-31 at 11:10 -0700, Tom Tromey wrote: > > > >>>>> "Ralf" == Ralf Corsepius writes: > > > > > > Ralf> I don't have any reasons to trust this URL smolt sends it data too. > > > > > > In principle I think this site should be controlled by the fedora project. > > > > Why do you think are people disabling log-in prompts, > > forging/suppressing server id-strings, not using HINFO records in named > > etc. ? > > No idea what you're talking about, and I consider myself somewhat paranoid. Many servers/service return an id-string identifying the version of a particular piece of SW - If this string is correct it, it provides clear information to which vulnerabilities it is likely to be vulnerable. Therefore many server admins use faked id-strings or don't provide this kind of information. > > Not worth mentioning, jerks sneaking on connections, theft of the data > > base, connecting this data with data available from other sources and > > selling this data ... > > We're still talking about data which contains solely of hardware > information which is individually publicly available, It is not publicly available!! You don't know which hardware I am running nor how many machines I have, nor what I am using them for. Otherwise smolt would not exist! All you know is me using Fedora 6/i686 on a certain IP address. Ralf From wtogami at redhat.com Thu Feb 1 03:56:10 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 31 Jan 2007 22:56:10 -0500 Subject: F7 KDE spin In-Reply-To: References: <45A2BABB.2090902@math.unl.edu> <16de708d0701081825l33023bd4p818ad14919feae0b@mail.gmail.com> <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> <45C124AB.4020109@redhat.com> Message-ID: <45C164DA.1010701@redhat.com> Rex Dieter wrote: > Warren Togami wrote: > > >> The htmlview and launchmail in FC7 should fallback to *any* browser in a >> list of fallbacks if the configured browser or mail client doesn't >> exist. This should help this case... although htmlview could probably >> use a lot more cleanup. > > xdg-open pretty much deprecates htmlview, imo. It'll open arbitrary > file,URL using the current desktop's default app for that mimetype. > > -- Rex > Which MIME system does it use? Is this an upstream freedesktop.org standard? Has both GNOME and KDE accepted xdg-open? Warren Togami wtogami at redhat.com From vonbrand at inf.utfsm.cl Thu Feb 1 04:05:26 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 01 Feb 2007 01:05:26 -0300 Subject: Version strings [Was: Re: Smolt: Fedora Hardware Profiler] In-Reply-To: <1170302071.5838.686.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <16de708d0701311800j2b162591k6c2cf525b60c4050@mail.gmail.com> <1170302071.5838.686.camel@mccallum.corsepiu.local> Message-ID: <200702010405.l1145QZx022936@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: [...] > Many servers/service return an id-string identifying the version of a > particular piece of SW - If this string is correct it, it provides clear > information to which vulnerabilities it is likely to be vulnerable. In my experience, the use of those for troubleshooting is much more important than any vulnerabilities exposed this way. Crackers (particularly automated attacks) usually just dive in, without any regard to any version strings. Besides, it is easy to guess (quite accurately, via something like nmap) what is at the other end. Hiding what you are running is an example of what is dismissed with the quip "Security through obscurity, isn't". It is uniformly regarded as almost completely useless. Fix the vulnerabilities, don't pretend they aren't there. > Therefore many server admins use faked id-strings or don't provide this > kind of information. That is detrimental to legitimate uses, and stops no cracker. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From tibbs at math.uh.edu Thu Feb 1 04:38:02 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 31 Jan 2007 22:38:02 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701311942r4eac6e2cl7a08cf118d6dc173@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> <3e4ec4600701311848i792258acn48f5fe24bf2b1288@mail.gmail.com> <3237e4410701311856r5aa176a8ue5c0b1a1d562b93b@mail.gmail.com> <3e4ec4600701311912q433f5916s206a0489d34cb08e@mail.gmail.com> <3237e4410701311919k5c53c108l3319814304b791e3@mail.gmail.com> <3e4ec4600701311932p7289a992ld9c37133d2cd4da4@mail.gmail.com> <3237e4410701311942r4eac6e2cl7a08cf118d6dc173@mail.gmail.com> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> I'm not sure what the official policy is actually or even if there MM> is one. But I do know the builders have disabled fc3 and 4 MM> builds. You can't branch new packages to FC3 and FC4 (nor anything older, obviously), but you can still commit things to existing old branches if you like. (There's still one package that I keep updated because I still need it on FC3 and it's easier to maintain everything together.) And of course since there's no buildsys for FC3 and FC4. - J< From rc040203 at freenet.de Thu Feb 1 05:00:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 06:00:58 +0100 Subject: Version strings [Was: Re: Smolt: Fedora Hardware Profiler] In-Reply-To: <200702010405.l1145QZx022936@laptop13.inf.utfsm.cl> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <16de708d0701311800j2b162591k6c2cf525b60c4050@mail.gmail.com> <1170302071.5838.686.camel@mccallum.corsepiu.local> <200702010405.l1145QZx022936@laptop13.inf.utfsm.cl> Message-ID: <1170306059.8628.37.camel@columbo.corsepiu.local> On Thu, 2007-02-01 at 01:05 -0300, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > [...] > > > Many servers/service return an id-string identifying the version of a > > particular piece of SW - If this string is correct it, it provides clear > > information to which vulnerabilities it is likely to be vulnerable. > > In my experience, the use of those for troubleshooting is much more > important than any vulnerabilities exposed this way. Crackers (particularly > automated attacks) usually just dive in, without any regard to any version > strings. Besides, it is easy to guess (quite accurately, via something like > nmap) what is at the other end. Hiding what you are running is an example > of what is dismissed with the quip "Security through obscurity, isn't". It will surprise you: I share this opinion. Nevertheless, it's still seems pretty common practice. > It > is uniformly regarded as almost completely useless. Fix the vulnerabilities, > don't pretend they aren't there. I've recently read an article, claiming that most server attacks these days would be quite simple ("Is this a win server? If yes, attack, if no stop the attack.) because the overall amount of "easy to intrude, wide-open, high-bandwith home-servers" would make deep crack attacks against "real servers" less attractive. This article also claimed that there is a market for people collecting, validating and selling such "potentially vulnerable" addresses esp. to spammers. This would indicate the issue is less "not to pretend to have a bug fixed", but to let a machine appear unattractive for being a candidate for a deeper attack. Now, it's up to the beholder to draw his conclusions. Is a machine identifying as "Fedora linux i386" or "WinServer XYZ" or not providing an id is more likely to be attacked? - I don't know. > > Therefore many server admins use faked id-strings or don't provide this > > kind of information. > > That is detrimental to legitimate uses, Legitimate uses should not need them at all. > and stops no cracker. True. Real crackers will probe and find out. Ralf From rc040203 at freenet.de Thu Feb 1 05:46:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 06:46:19 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> Message-ID: <1170308780.2588.31.camel@mccallum.corsepiu.local> On Wed, 2007-01-31 at 17:11 -0700, Tom Tromey wrote: > >>>>> "Ralf" == Ralf Corsepius writes: > > >> The smolt data looked quite nice to me. Good stuff to know. > > Ralf> Pardon, but you'd better never mention the word "security" in a Fedora > Ralf> context again ;) > > Yeah. It's kind of hard to want to get involved again. > > I understand you're more worried about people somehow getting your > hardware profile than I am. That's even understandable. What I don't > understand is why clicking "No" is not enough. It's probably a cultural difference. In Europe, esp. in Germany, "data collectionitis of certain enterprises" and "data privacy" are _VERY_ _HOT_ political topics. This manifests at various places, e.g. Germany having very restrictive laws on "data privacy" and the public/press/media's attitude being very hostile against anybody "collecting data". Also, probably unlike in many other parts of the world people around here are conscious about "data privacy" and often have a negative attitude against institutions collecting data. Fact is, what you seem to take for granted, isn't in Germany. The legal details are complicated, it would require to be a laywer to elaborate, but German's laws mandate "explicit opt-in" and mandate explicit regulations on many other details (e.g. timed deletion of data) in many situations. Though this isn't 100% legally mandated, this has lead to many people in Germany to consider "opt-in" as a matter of fairness and consider enterprises choosing "opt-out" to be playing foul and to be jerks. I had mentioned this aspect in a very early mail of this thread, but ... this had been pushed aside. IMO, you and Fedora are vastly underestimating the situation. You understand you are playing with a loaded gun here and are better off taking concerns about it seriously. Ralf From lists at wilsonet.com Thu Feb 1 06:01:48 2007 From: lists at wilsonet.com (Jarod Wilson) Date: Thu, 1 Feb 2007 01:01:48 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <20070201031117.GA15924@stanford.edu> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311130.37925.dennis@ausil.us> <1170275115.3790.2.camel@dhollis-lnx.sunera.com> <604aa7910701311417l50264359me99c479972e270b8@mail.gmail.com> <20070201031117.GA15924@stanford.edu> Message-ID: <757910C4-B42D-4242-B0FE-8385AFEC9D39@wilsonet.com> On Jan 31, 2007, at 22:11, Tim Fenn wrote: > On Wed, Jan 31, 2007 at 01:17:54PM -0900, Jeff Spaleta wrote: >> On 1/31/07, David Hollis wrote: >>> I also presume the stats web page would be expanded on to provide >>> more >>> than just Top 20 devices and such? The reason I ask is that as a >>> device >>> driver maintainer, it would certainly be interesting to be able >>> to get >>> some ideas on how many people have the device/are using the >>> driver and >>> platforms. >> >> We also totally need a section for the most snaztastic set of >> hardware >> running fedora. I mean seriously, if someone is running fedora on >> the >> equivalent audio/video setup as a 20 screen Movie Theature >> Multiplex.. that would be interesting to highlight... if they choose >> to let us know about it of course. >> > > I know I'm not much of a regular contributor to the list, but I think > this is a great idea: I've had more people ask me about fedora (and > linux in general) thanks to my snazzy mythtv+fedora box at home than > my "because its free!" argument, and I'm betting Jarod Wilson would > agree. Definitely. :) -- Jarod Wilson jarod at wilsonet.com From pemboa at gmail.com Thu Feb 1 06:04:51 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 1 Feb 2007 00:04:51 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170308780.2588.31.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <1170308780.2588.31.camel@mccallum.corsepiu.local> Message-ID: <16de708d0701312204p2f249872wdd83b9b3aa21a413@mail.gmail.com> On 1/31/07, Ralf Corsepius wrote: > On Wed, 2007-01-31 at 17:11 -0700, Tom Tromey wrote: > > >>>>> "Ralf" == Ralf Corsepius writes: > > > > >> The smolt data looked quite nice to me. Good stuff to know. > > > > Ralf> Pardon, but you'd better never mention the word "security" in a Fedora > > Ralf> context again ;) > > > > Yeah. It's kind of hard to want to get involved again. > > > > I understand you're more worried about people somehow getting your > > hardware profile than I am. That's even understandable. What I don't > > understand is why clicking "No" is not enough. > It's probably a cultural difference. > > In Europe, esp. in Germany, "data collectionitis of certain enterprises" > and "data privacy" are _VERY_ _HOT_ political topics. > > This manifests at various places, e.g. Germany having very restrictive > laws on "data privacy" and the public/press/media's attitude being very > hostile against anybody "collecting data". Also, probably unlike in many > other parts of the world people around here are conscious about "data > privacy" and often have a negative attitude against institutions > collecting data. Ok. > Fact is, what you seem to take for granted, isn't in Germany. The legal > details are complicated, it would require to be a laywer to elaborate, > but German's laws mandate "explicit opt-in" and mandate explicit > regulations on many other details (e.g. timed deletion of data) > in many situations. So what you're saying is that the hardware profiler should be opt in only? > Though this isn't 100% legally mandated, this has lead to many people in > Germany to consider "opt-in" as a matter of fairness and consider > enterprises choosing "opt-out" to be playing foul and to be jerks. > I had mentioned this aspect in a very early mail of this thread, but ... > this had been pushed aside. Ok > IMO, you and Fedora are vastly underestimating the situation. You > understand you are playing with a loaded gun here and are better off > taking concerns about it seriously. I dislike people who corrupt everything I like with legal mumbo jumbo -- Fedora Core 6 and proud From fedora at camperquake.de Thu Feb 1 07:24:10 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 1 Feb 2007 08:24:10 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701310820x3def333dh90c9e74c56863dc5@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <1170259702.5838.460.camel@mccallum.corsepiu.local> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <20070131171627.69256ab1@banea.int.addix.net> <3237e4410701310820x3def333dh90c9e74c56863dc5@mail.gmail.com> Message-ID: <20070201082410.309f0836@banea.int.addix.net> Hi. On Wed, 31 Jan 2007 10:20:49 -0600, Mike McGrath wrote: > Meh, if someone is clicking next, next, next. That's their problem. > Try out the firstboot method first... It defaults to no with a "are > you sure you mean no" dialog. I'm sure the verbage could be made more > clear... Seriously, try it first. Is there a way to run firstboot in a kind of "just look" mode on an already installed system? I'm willing to look at it, but I do not want it to actually change something about my system. From rc040203 at freenet.de Thu Feb 1 07:35:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 01 Feb 2007 08:35:23 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <16de708d0701312204p2f249872wdd83b9b3aa21a413@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <1170308780.2588.31.camel@mccallum.corsepiu.local> <16de708d0701312204p2f249872wdd83b9b3aa21a413@mail.gmail.com> Message-ID: <1170315323.2588.94.camel@mccallum.corsepiu.local> On Thu, 2007-02-01 at 00:04 -0600, Arthur Pemberton wrote: > On 1/31/07, Ralf Corsepius wrote: > > On Wed, 2007-01-31 at 17:11 -0700, Tom Tromey wrote: > > > >>>>> "Ralf" == Ralf Corsepius writes: > > > > > > >> The smolt data looked quite nice to me. Good stuff to know. > > > > > > Ralf> Pardon, but you'd better never mention the word "security" in a Fedora > > > Ralf> context again ;) > > > > > > Yeah. It's kind of hard to want to get involved again. > > > > > > I understand you're more worried about people somehow getting your > > > hardware profile than I am. That's even understandable. What I don't > > > understand is why clicking "No" is not enough. > > It's probably a cultural difference. > > > > In Europe, esp. in Germany, "data collectionitis of certain enterprises" > > and "data privacy" are _VERY_ _HOT_ political topics. > > Fact is, what you seem to take for granted, isn't in Germany. The legal > > details are complicated, it would require to be a laywer to elaborate, > > but German's laws mandate "explicit opt-in" and mandate explicit > > regulations on many other details (e.g. timed deletion of data) > > in many situations. > > So what you're saying is that the hardware profiler should be opt in only? Yes, this would be the minimum requirement to "not let Fedora to appear as jerks". The more explicit and detailed, the better. Ralf From fedora at camperquake.de Thu Feb 1 07:35:29 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 1 Feb 2007 08:35:29 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <16de708d0701312204p2f249872wdd83b9b3aa21a413@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <1170308780.2588.31.camel@mccallum.corsepiu.local> <16de708d0701312204p2f249872wdd83b9b3aa21a413@mail.gmail.com> Message-ID: <20070201083529.71ee336f@banea.int.addix.net> Hi. On Thu, 1 Feb 2007 00:04:51 -0600, Arthur Pemberton wrote: > So what you're saying is that the hardware profiler should be opt in > only? That is the long and short of it, I think (at least it is for me). Integrate it into firstboot, advertise it all you want, but please let it default to "no". Mike mentioned a user clicking "Next, Next, Next" somewhere else in this thread (and most of us know this behaviour, I think). Someone doing this ought to be treated with the principle of least surprise (and default and good security). Just clicking next will enable SeLinux, because it is good for the average user, and protects his machine. Just clicking next will enable the Firewall, because it is good for the user, and protects his machine. Just clicking next will require the user to enter a root password, and create an account (during firstboot, correct me if I'm wrong) to work as. In the same line I think that the default for sending this hardware information ought to be no. From jdieter at gmail.com Thu Feb 1 08:40:03 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 01 Feb 2007 10:40:03 +0200 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <20070201083529.71ee336f@banea.int.addix.net> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <1170308780.2588.31.camel@mccallum.corsepiu.local> <16de708d0701312204p2f249872wdd83b9b3aa21a413@mail.gmail.com> <20070201083529.71ee336f@banea.int.addix.net> Message-ID: <1170319203.4904.4.camel@jndwidescreen.lesbg.loc> On Thu, 2007-02-01 at 08:35 +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 1 Feb 2007 00:04:51 -0600, Arthur Pemberton wrote: > > > So what you're saying is that the hardware profiler should be opt in > > only? > > That is the long and short of it, I think (at least it is for me). > Integrate it into firstboot, advertise it all you want, but please > let it default to "no". > > Mike mentioned a user clicking "Next, Next, Next" somewhere else in > this thread (and most of us know this behaviour, I think). Someone > doing this ought to be treated with the principle of least surprise > (and default and good security). > > Just clicking next will enable SeLinux, because it is good for the > average user, and protects his machine. > Just clicking next will enable the Firewall, because it is good > for the user, and protects his machine. > Just clicking next will require the user to enter a root password, > and create an account (during firstboot, correct me if I'm wrong) to > work as. > > In the same line I think that the default for sending this hardware > information ought to be no. > It is. To quote Mike, 'It defaults to no with a "are you sure you mean no" dialog.' Which means it is opt-in, not opt-out. Which means this whole debate is pointless. -------------- 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 jerone at gmail.com Thu Feb 1 08:41:39 2007 From: jerone at gmail.com (Jerone Young) Date: Thu, 1 Feb 2007 02:41:39 -0600 Subject: [RFC] Grub 2 packages for FC7 Message-ID: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> I've got intial packages for FC7 and grub2. This allows grub2 to be installed side by side with grub1. This is especially nice as grub2 is still in development and some key features are still not there for full replacement of grub one. For this inital package I have support for standard i386 & x86-64 PCs. I'll be adding an grub2-efi and ppc file pacakages shortly (though because I'm a bit tardy getting these to the list I figured I would just throw these on the list. I have a prebuilt package for x86-64, the source rpm, & spec file. Everything can be found at: http://jgotech.net/jerone/ *Issues* While it installs fine to the boot sector.. for some reason (that I cannot see why) grub is not reading from /boot/grub2/grub.cfg .. and will bring to the grub prompt. While you can boot fine from the prompt, I'm unsure why it currently is not reading the configuration file and bring up a menu (I've seen it work in the past). So now all commands have "grub2" as a prefix. So instead of "grub-install". Also installs files to "/boot/grub2" when run "grub2-install". You can easily see the file list from the rpm by grabing the binary rpm and doing "rpm -qlp ". Information on writing the config file for grub2 (which is grub.cfg) can be found: http://grub.enbug.org/grub.cfg Grub Dev wiki: http://grub.enbug.org/ Grub: http://www.gnu.org/software/grub/ Signed-off-by: Jerone Young From naoki at valuecommerce.com Thu Feb 1 09:00:39 2007 From: naoki at valuecommerce.com (Naoki) Date: Thu, 01 Feb 2007 18:00:39 +0900 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170308780.2588.31.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <1170308780.2588.31.camel@mccallum.corsepiu.local> Message-ID: <1170320439.3289.367.camel@dragon.valuecommerce.ne.jp> > IMO, you and Fedora are vastly underestimating the situation. You > understand you are playing with a loaded gun here and are better off > taking concerns about it seriously. Umm, isn't "yum -y install smolt && smoltSendProfile" about as "opt-in" as you can get? From hughsient at gmail.com Thu Feb 1 09:27:47 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 01 Feb 2007 09:27:47 +0000 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <87r6taohh8.fsf@kosh.bigo.ensc.de> References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> Message-ID: <1170322067.3338.19.camel@hughsie-laptop> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote: > > 'suspend-to-disk' and 'suspend-to-ram' are much more descriptives > names > and more consistent with rest of system (/sys/power/state). And how many joe-average Linux users know what the contents of /sys/power/state is? Also, my girlfriend has no concept of what "ram" is, and why it should be faster than "disk". She does understand the speed difference between suspend and hibernate. I really don't think it's important to know what each of the Sx states is doing to individual bits of hardware, not for the end user anyway. Richard. From pertusus at free.fr Thu Feb 1 09:43:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 Feb 2007 10:43:01 +0100 Subject: F7 KDE spin In-Reply-To: <45C164DA.1010701@redhat.com> References: <45A2BABB.2090902@math.unl.edu> <16de708d0701081825l33023bd4p818ad14919feae0b@mail.gmail.com> <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> <45C124AB.4020109@redhat.com> <45C164DA.1010701@redhat.com> Message-ID: <20070201094301.GA2752@free.fr> On Wed, Jan 31, 2007 at 10:56:10PM -0500, Warren Togami wrote: > > Which MIME system does it use? > > Is this an upstream freedesktop.org standard? > > Has both GNOME and KDE accepted xdg-open? It is a simple script. It detects the desktop and runs the gnome, kde or xfce command apropriately to open a file. If gnome, kde or xfce aren't running, it tries mimeopen (a perl desktop agnostic script that follows the freedesktop standarrd) if installed, and then uses what is in BROWSER falling back to firefox (if I recall well). -- Pat From pertusus at free.fr Thu Feb 1 09:45:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 Feb 2007 10:45:05 +0100 Subject: [RFC] Grub 2 packages for FC7 In-Reply-To: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> References: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> Message-ID: <20070201094505.GB2752@free.fr> On Thu, Feb 01, 2007 at 02:41:39AM -0600, Jerone Young wrote: > I've got intial packages for FC7 and grub2. This allows grub2 to be > installed side by side with grub1. This is especially nice as grub2 is > still in development and some key features are still not there for > full replacement of grub one. Why don't you submit it for extras? I guess it can be installed in paralell with grub. -- Pat From naoki at valuecommerce.com Thu Feb 1 10:25:43 2007 From: naoki at valuecommerce.com (Naoki) Date: Thu, 01 Feb 2007 19:25:43 +0900 Subject: Compatability libs. Please sir, can I have some more? Message-ID: <1170325543.3289.397.camel@dragon.valuecommerce.ne.jp> I understand I'll get flamed for suggesting this but.. A "whatprovides python\(abi\)" tells me : python.x86_64 2.5-9.fc7 development & python.x86_64 2.4.4-1.fc6 updates Which is what I expect and is all cool. But here is an idea. Often to make the transition easier on people we (fedora) provides compatibility libraries. This is great. Just wondering though, with the dropping of Legacy ( which I will in no way debate because that's been done to death and explained enough already ), I was thinking by just throwing a few more compat-libs into the mix it might help out those who otherwise find an upgrade daunting.. There looks to be these compat-libs shipping now : compat-libstdc++-33 compat-libgcc-296 compat-libgda compat-libosip2 compat-libgpod compat-libf2c-34 Would it be at all feasible to add some more into extras? Perhaps : python 2.4 postgres mysql php others ? I am not suggesting to keep them maintained with security or other patches. But to simply offer them once as an unsupported method of allowing FC upgrades while maintaining some legacy apps to those who would like it. Yep I know people who want to run an 'old' software stack should use another distro but if that is the case why have any compat-libs at all? From bart.vanbrabant at zoeloelip.be Thu Feb 1 10:44:28 2007 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Thu, 01 Feb 2007 11:44:28 +0100 Subject: Compatability libs. Please sir, can I have some more? In-Reply-To: <1170325543.3289.397.camel@dragon.valuecommerce.ne.jp> References: <1170325543.3289.397.camel@dragon.valuecommerce.ne.jp> Message-ID: <45C1C48C.5080006@zoeloelip.be> > I am not suggesting to keep them maintained with security or other > patches. I hope you are kidding? I think it's better to *not* provide any compat libs that aren't maintained. Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From pertusus at free.fr Thu Feb 1 10:45:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 Feb 2007 11:45:43 +0100 Subject: Compatability libs. Please sir, can I have some more? In-Reply-To: <1170325543.3289.397.camel@dragon.valuecommerce.ne.jp> References: <1170325543.3289.397.camel@dragon.valuecommerce.ne.jp> Message-ID: <20070201104543.GC2752@free.fr> On Thu, Feb 01, 2007 at 07:25:43PM +0900, Naoki wrote: > Would it be at all feasible to add some more into extras? Perhaps : > > python 2.4 > postgres > mysql > php > others ? Submit them, if they pass review, they will be added. I can't see anything that would prevent them for entering fedora, as long as they don't conflict and don't interfere with non compat packages. -- Pat From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 1 11:05:43 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Feb 2007 12:05:43 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> Message-ID: <20070201120543.00c6a594@python3.es.egwn.lan> Mike McGrath wrote : > Current stats can be found at: > > http://smolt.fedoraproject.org/stats Three quick comments : - The current CPU vendor percentages seem wrong (12% Intel, 12% AMD, all others below 1%... far from 100% total!) - CPU cores seem to be counted as CPUs. Maybe HT CPUs are also counted as multiple CPUs. It would be best to try and separate those informations (real CPUs, HTs, cores). - Some "< 512" should probably be "=< 512". Anyway, it's pretty cool to see all those stats :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.52 0.83 1.06 From buildsys at redhat.com Thu Feb 1 11:18:16 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 1 Feb 2007 06:18:16 -0500 Subject: rawhide report: 20070201 changes Message-ID: <200702011118.l11BIG87025296@hs20-bc2-6.build.redhat.com> Removed package pump Removed package eclipse-bugzilla Updated Packages: cracklib-2.8.9-8 ---------------- * Wed Jan 31 2007 Nalin Dahyabhai - 2.8.9-8 - add word list from attachment #126053 (#185314) dhcp-12:3.0.5-12.fc7 -------------------- * Wed Jan 31 2007 David Cantrell - 12:3.0.5-12 - Rebuild * Tue Jan 30 2007 David Cantrell - 12:3.0.5-11 - Remove FORTIFY_SOURCE=0 leftovers from testing last week (whoops) * Tue Jan 30 2007 David Cantrell - 12:3.0.5-10 - Fix Xen networking problems with partial checksums (#221964) eclipse-1:3.2.1-34.fc7 ---------------------- * Tue Jan 30 2007 Ben Konrath 3.2.1-34 - Create symlinks to the SWT JNI libs in %{_libdir}/eclipse with sane versions. * Mon Jan 29 2007 Ben Konrath 3.2.1-33 - Check for features directory in sdk postun script. - Resolves: #224588. * Fri Jan 26 2007 Ben Konrath 3.2.1-32 - Fix bug in ecj [] patch. ed-0.4-2 -------- * Wed Jan 31 2007 Karsten Hopp 0.4-2 - use RPM_OPT_FLAGS, this fixes debuginfo f-spot-0.3.2-1.fc7 ------------------ * Tue Jan 23 2007 Matthias Clasen - 0.3.2-1 - Update to 0.3.2 * Fri Oct 20 2006 Christopher Aillon - 0.2.2-1 - Update to 0.2.2 flex-2.5.33-3.fc7 ----------------- * Wed Jan 31 2007 Petr Machata - 2.5.33-3 - Compile with -fPIC. fonts-chinese-3.03-4.fc7 ------------------------ * Thu Feb 01 2007 Caius Chance - 3.03-4.fc7 - Fixed bz#226716: LTC30501-Missing files in Traditional Chinese font support package (el5->devel). fonts-indic-2.1.2-2.fc7 ----------------------- * Thu Feb 01 2007 Parag Nemade - 2.1.2-2 - Updated SPEC file as part of core/extras merge gettext-0.16.1-4.fc7 -------------------- * Thu Feb 01 2007 Jens Petersen - 0.16.1-4 - protect install-info in devel %post and %preun too (Ville Skytt??, #223689) - forward port fix to reset of timestamp of examples ChangeLog for brp-java-repack-jars libintl.jar multilib conflict (#205207) gnome-doc-utils-0.9.2-1.fc7 --------------------------- * Wed Jan 31 2007 Matthias Clasen - 0.9.2-1 - Update to 0.9.2 kdebase-6:3.5.6-0.1.fc6 ----------------------- * Tue Jan 30 2007 Than Ngo - 6:3.5.6-0.1.fc6 - 3.5.6 * Thu Nov 30 2006 Than Ngo - 6:3.5.5-0.6.fc6 - apply upstream fix: * Tue Nov 07 2006 Than Ngo 6:3.5.5-0.5.fc6 - add hibernate/suspend in shutdown dialog kdegames-6:3.5.6-0.1.fc6 ------------------------ * Wed Jan 31 2007 Than Ngo 6:3.5.6-0.1.fc6 - 3.5.6 kdemultimedia-6:3.5.6-0.1.fc6 ----------------------------- * Wed Jan 31 2007 Than Ngo 6:3.5.6-0.1.fc6 - 3.5.6 kernel-2.6.19-1.2917.fc7 ------------------------ * Wed Jan 31 2007 Dave Jones - 2.6.20rc7 mod_perl-2.0.3-4 ---------------- * Wed Jan 31 2007 Joe Orton 2.0.3-4 - restore ModPerl::MM module-init-tools-3.3-0.pre6.1.9.fc7 ------------------------------------ * Thu Feb 01 2007 Jon Masters - 3.3-0.pre6.1.7 - Rebase to latest upstream release. nautilus-cd-burner-2.17.6-2.fc7 ------------------------------- * Wed Jan 31 2007 Alexander Larsson - 2.17.6-2 - Disable cdrdao on s390x (its not availible) newt-0.52.5-1.fc7 ----------------- * Wed Jan 31 2007 Miroslav Lichvar - 0.52.5-1 - provide option to change text of buttons (#126768) - don't add escape key to hot keys by default (#216157) - fix cursor position in checkboxtree, radio button and checkbox - don't force monochrome terminals to output colors - highlight active compact button on monochrome terminals - update translations from debian pykickstart-0.93-2.fc7 ---------------------- * Wed Jan 31 2007 Chris Lumens - 0.93-2 - Make some minor spec file changes to get closer to the extras guidelines. radvd-1.0-1.fc7 --------------- * Wed Jan 31 2007 Martin Bacovsky - 1.0-1.fc7 - rebase to upstream 1.0 - Resolves: #225542: radvd 1.0 released rhythmbox-0.9.7-11.fc7 ---------------------- * Wed Jan 31 2007 - Bastien Nocera - 0.9.7-11.fc7 - Require automake in the BuildRequires as well, as we need to generate plugins/mmkeys/Makefile.in * Wed Jan 31 2007 - Bastien Nocera - 0.9.7-10.fc7 - Require autoconf in the BuildRequires, as it's not in the minimum build environment * Wed Jan 31 2007 - Bastien Nocera - 0.9.7-9.fc7 - Exclude s390* from the builds, as there's no gnome-media there sysklogd-1.4.1-45.fc7 --------------------- * Wed Jan 31 2007 Nils Philippsen 1.4.1-45 - fix typo in %post scriptlet system-config-services-0.9.6-1.fc7 ---------------------------------- * Wed Jan 31 2007 Nils Philippsen - 0.9.6 - fix up service metadata reading a bit (#217591) * Wed Jan 31 2007 Nils Philippsen - 0.9.5 - use "install -m" to install a lot of files without executable bits (#222579) tcl-8.5a5-5.fc7 --------------- * Thu Jan 25 2007 Marcela Maslanova - 8.5a5-5 - rebuilt * Mon Dec 18 2006 Marcela Maslanova - 8.5a5-4 - change in spec for compatibility with tk, version 8.5a5 - Resolves: rhbz#160441 * Thu Jul 20 2006 David Cantrell - 8.4.13-3 - Fix cflags patch so it applies correctly - Changes $(CFLAGS) to ${CFLAGS} in cflags patch tk-8.5a5-1.fc7 -------------- * Thu Jan 25 2007 Marcela Maslanova - 8.5a5-1 - update: version 8.5a5 - Resolves: rhbz#160442 tomboy-0.5.5-1.fc7 ------------------ * Wed Jan 31 2007 Matthias Clasen - 0.5.5-1 - Update to 0.5.5 virt-manager-0.3.0-2.fc7 ------------------------ * Wed Jan 31 2007 Daniel P. Berrange - 0.3.0-2.fc7 - Added dep on desktop-file-utils for post/postun scripts * Mon Jan 22 2007 Daniel P. Berrange - 0.3.0-1.fc7 - Added support for managing inactive domains - Require virt-inst >= 0.100.0 and libvirt >= 0.1.11 for ianctive domain management capabilities - Add progress bars during VM creation stage - Improved reliability of VNC console - Updated translations again - Added destroy option to menu bar to forceably kill a guest - Visually differentiate allocated memory, from actual used memory on host - Validate file magic when restoring a guest from a savd file - Performance work on domain listing - Allow creation of non-sparse files - Fix backspace key in serial console * Tue Dec 19 2006 Daniel P. Berrange - 0.2.6-3.fc7 - Imported latest translations from Fedora i18n repository (bz 203783) - Use 127.0.0.1 address for connecting to VNC console instead of localhost to avoid some issue with messed up /etc/hosts. - Add selector for sparse or non-sparse file, defaulting to non-sparse. Add appropriate warnings and progress-bar text. (bz 218996) - Disable memory ballooning & CPU hotplug for HVM guests (bz 214432) - Updated memory-setting UI to include a hard upper limit for physical host RAM - Added documentation on the page warning that setting virtual host RAM too high can exhaust the memory of the machine - Handle errors when hostname resolution fails to avoid app exiting (bz 216975) xorg-x11-server-1.2.0-4.fc7 --------------------------- * Wed Jan 31 2007 Adam Jackson 1.2.0-4 - Fix typo in SDK header. (#222487) * Mon Jan 29 2007 Adam Jackson 1.2.0-3 - Fix MMX check on AMD CPUs. (#222332) - Fix Xephyr keysym init on LP64. (#224311) * Wed Jan 24 2007 Adam Jackson 1.2.0-2 - Delete ModulePath lines rather than attempt to munge them. (#186338) Broken deps for ppc ---------------------------------------------------------- expect - 5.43.0-5.1.ppc requires libtcl8.4.so expectk - 5.43.0-5.1.ppc requires libtk8.4.so expectk - 5.43.0-5.1.ppc requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.ppc requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtk8.4.so setools-gui - 3.0-2.fc7.ppc requires libtk8.4.so setools-gui - 3.0-2.fc7.ppc requires libtcl8.4.so tkinter - 2.5-9.fc7.ppc requires libtk8.4.so tkinter - 2.5-9.fc7.ppc requires libtcl8.4.so Broken deps for s390 ---------------------------------------------------------- expect - 5.43.0-5.1.s390 requires libtcl8.4.so expectk - 5.43.0-5.1.s390 requires libtk8.4.so expectk - 5.43.0-5.1.s390 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.s390 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtcl8.4.so setools-gui - 3.0-2.fc7.s390 requires libtk8.4.so setools-gui - 3.0-2.fc7.s390 requires libtcl8.4.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 tkinter - 2.5-9.fc7.s390 requires libtk8.4.so tkinter - 2.5-9.fc7.s390 requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- expect - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtk8.4.so()(64bit) setools-gui - 3.0-2.fc7.ppc64 requires libtcl8.4.so()(64bit) setools-gui - 3.0-2.fc7.ppc64 requires libtk8.4.so()(64bit) tkinter - 2.5-9.fc7.ppc64 requires libtcl8.4.so()(64bit) tkinter - 2.5-9.fc7.ppc64 requires libtk8.4.so()(64bit) Broken deps for i386 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expectk - 5.43.0-5.1.i386 requires libtk8.4.so expectk - 5.43.0-5.1.i386 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.i386 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so setools-gui - 3.0-2.fc7.i386 requires libtk8.4.so setools-gui - 3.0-2.fc7.i386 requires libtcl8.4.so tkinter - 2.5-9.fc7.i386 requires libtk8.4.so tkinter - 2.5-9.fc7.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expect - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) setools-gui - 3.0-2.fc7.x86_64 requires libtcl8.4.so()(64bit) setools-gui - 3.0-2.fc7.x86_64 requires libtk8.4.so()(64bit) tkinter - 2.5-9.fc7.x86_64 requires libtcl8.4.so()(64bit) tkinter - 2.5-9.fc7.x86_64 requires libtk8.4.so()(64bit) Broken deps for ia64 ---------------------------------------------------------- expect - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtk8.4.so()(64bit) setools-gui - 3.0-2.fc7.ia64 requires libtcl8.4.so()(64bit) setools-gui - 3.0-2.fc7.ia64 requires libtk8.4.so()(64bit) tkinter - 2.5-9.fc7.ia64 requires libtcl8.4.so()(64bit) tkinter - 2.5-9.fc7.ia64 requires libtk8.4.so()(64bit) Broken deps for s390x ---------------------------------------------------------- expect - 5.43.0-5.1.s390 requires libtcl8.4.so expect - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.s390x requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtk8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtk8.4.so()(64bit) setools-gui - 3.0-2.fc7.s390x requires libtcl8.4.so()(64bit) setools-gui - 3.0-2.fc7.s390x requires libtk8.4.so()(64bit) tkinter - 2.5-9.fc7.s390x requires libtcl8.4.so()(64bit) tkinter - 2.5-9.fc7.s390x requires libtk8.4.so()(64bit) From pknirsch at redhat.com Thu Feb 1 11:25:37 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 01 Feb 2007 12:25:37 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <45C0EA33.1090102@redhat.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <20070131165307.GD26542@nostromo.devel.redhat.com> <3237e4410701310857o1f808139m7965f99f93ff6f79@mail.gmail.com> <45C0EA33.1090102@redhat.com> Message-ID: <45C1CE31.9040008@redhat.com> Bret McMillan wrote: > Mike McGrath wrote: >> On 1/31/07, Bill Nottingham wrote: >>> Mike McGrath (mmcgrath at fedoraproject.org) said: >>> > *Note: this is not LHCP, which is going to be a much larger project. >>> > Smolt has a much smaller scope and will ultimately (hopefully) be >>> > replaced by LHCP when it is ready. >>> >>> So, the issue I see is that the data appears to be stored as HAL >>> descriptive strings - these could change over time. Storing >>> it as vendor/id pairs might be more flexible. >>> >>> (Or is this actually done that way, and the display on the website >>> is what's doing the conversion?) >>> >> >> They're presently being pulled from the hardware object created using >> the RHN client tools. I'll look to see what it would take to get >> vendor/id pairs. > > Ouch. The way RHN currently deals with hardware is pretty painful, at > least server-side; a bunch of us are interested in pursuing something > more HAL'ish, drop me a line if you're interested, and maybe we can see > if there are points of commonality. > > --Bret > As we'll probably be reusing a lot of that hardware probing code in LHCP as well i'd be really interested about what/how we can do that better, so it would be awesome if you could get me in the loop. Our current code in LHCP is very basic for now (just a prove of concept), so doing that the same way in smolt and LHCP should be really benefical. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From pknirsch at redhat.com Thu Feb 1 11:32:18 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 01 Feb 2007 12:32:18 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600701311401m4e72caa4gdc28fe912d9a1f85@mail.gmail.com> <3237e4410701311415l6629b09cn3ab3cfd971207443@mail.gmail.com> Message-ID: <45C1CFC2.5070708@redhat.com> Mike McGrath wrote: > On 1/31/07, Michael Wiktowy wrote: >> On 1/31/07, Mike McGrath wrote: >> Does the profile give any indication whether the hardware is installed >> and working properly (or providing some limited functionality) or is >> it just cataloging its existence? > > The LHCP guys are doing this. Smolt has a much smaller scope. > Exactly. I've already received some really valuable feedback to various components and we'll be integrating as many of them as possible. As we'll also be trying to work with the smolt guys as closely together as possible we hope to get to a point where the manual testing you can do with LHCP can be integrated with the data collected from smolt. But it'll take some more time until LHCP reaches that point. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From alan at redhat.com Thu Feb 1 12:28:20 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 1 Feb 2007 07:28:20 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170308780.2588.31.camel@mccallum.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <1170308780.2588.31.camel@mccallum.corsepiu.local> Message-ID: <20070201122820.GA9927@devserv.devel.redhat.com> On Thu, Feb 01, 2007 at 06:46:19AM +0100, Ralf Corsepius wrote: > Fact is, what you seem to take for granted, isn't in Germany. The legal > details are complicated, it would require to be a laywer to elaborate, > but German's laws mandate "explicit opt-in" and mandate explicit > regulations on many other details (e.g. timed deletion of data) > in many situations. The UK likewise, although they are hopeless at enforcing it, especially when government is (as usual) the offender. Any contract based approach the same would apply as contract normally can only be created by active acceptance (I cannot for example say "I'll sell you a car for $250,000 unless you say you don't want it" and expect that to be an enforcable contract) Thus from a simple practical "what is allowed" point of view, personal data collection must be opt-in > IMO, you and Fedora are vastly underestimating the situation. You > understand you are playing with a loaded gun here and are better off > taking concerns about it seriously. Agreed. Alan From jkeating at redhat.com Thu Feb 1 12:59:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 07:59:48 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <20070201082410.309f0836@banea.int.addix.net> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310820x3def333dh90c9e74c56863dc5@mail.gmail.com> <20070201082410.309f0836@banea.int.addix.net> Message-ID: <200702010759.49011.jkeating@redhat.com> On Thursday 01 February 2007 02:24, Ralf Ertzinger wrote: > Is there a way to run firstboot in a kind of "just look" mode on an > already installed system? I'm willing to look at it, but I do not want > it to actually change something about my system. firstboot --debug -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From benny+usenet at amorsen.dk Thu Feb 1 13:56:27 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 01 Feb 2007 14:56:27 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> Message-ID: >>>>> "RH" == Richard Hughes writes: RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote: >> 'suspend-to-disk' and 'suspend-to-ram' are much more descriptives >> names and more consistent with rest of system (/sys/power/state). RH> And how many joe-average Linux users know what the contents of RH> /sys/power/state is? Also, my girlfriend has no concept of what RH> "ram" is, and why it should be faster than "disk". RH> She does understand the speed difference between suspend and RH> hibernate. I don't think I'll ever be able to remember which of suspend and hibernate means suspend-to-disk. Perhaps its easier for native English speakers, or perhaps I need my brain fixed. /Benny From mmcgrath at fedoraproject.org Thu Feb 1 14:04:33 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 1 Feb 2007 08:04:33 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <20070201120543.00c6a594@python3.es.egwn.lan> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <20070201120543.00c6a594@python3.es.egwn.lan> Message-ID: <3237e4410702010604y6abbc588g8df09095368a33a3@mail.gmail.com> On 2/1/07, Matthias Saou wrote: > Mike McGrath wrote : > - The current CPU vendor percentages seem wrong > (12% Intel, 12% AMD, all others below 1%... far from 100% total!) > - CPU cores seem to be counted as CPUs. Maybe HT CPUs are also counted > as multiple CPUs. It would be best to try and separate those > informations (real CPUs, HTs, cores). > - Some "< 512" should probably be "=< 512". re cpu vendor. Yeah.. just ignore that for now, I've completely horked up the query it uses to get that stuff. I should probably comment it out. Re: HT. I might have to come up with something clever there. I'm also wondering if we should just leave it the way the host sees it. Someone mentioned that speed was getting reported as cpuspeed reports it, not maximum. -Mike From mclasen at redhat.com Thu Feb 1 14:38:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 01 Feb 2007 09:38:34 -0500 Subject: F7 KDE spin In-Reply-To: <45C164DA.1010701@redhat.com> References: <45A2BABB.2090902@math.unl.edu> <16de708d0701081825l33023bd4p818ad14919feae0b@mail.gmail.com> <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> <45C124AB.4020109@redhat.com> <45C164DA.1010701@redhat.com> Message-ID: <1170340715.9637.29.camel@golem.boston.devel.redhat.com> On Wed, 2007-01-31 at 22:56 -0500, Warren Togami wrote: > Rex Dieter wrote: > > Warren Togami wrote: > > > > > >> The htmlview and launchmail in FC7 should fallback to *any* browser in a > >> list of fallbacks if the configured browser or mail client doesn't > >> exist. This should help this case... although htmlview could probably > >> use a lot more cleanup. > > > > xdg-open pretty much deprecates htmlview, imo. It'll open arbitrary > > file,URL using the current desktop's default app for that mimetype. > > > > -- Rex > > > > Which MIME system does it use? > > Is this an upstream freedesktop.org standard? > > Has both GNOME and KDE accepted xdg-open? There is nothing to accept here, really. The xdg- wrapper scripts are meant for third-party software that wants to work on multiple desktops. They were never intended to be pushed back into the desktops themselves, At least that was not case when the Portland project was started. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 1 14:37:14 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Feb 2007 15:37:14 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410702010604y6abbc588g8df09095368a33a3@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <20070201120543.00c6a594@python3.es.egwn.lan> <3237e4410702010604y6abbc588g8df09095368a33a3@mail.gmail.com> Message-ID: <20070201153714.1ebd5f36@python3.es.egwn.lan> Mike McGrath wrote : > > - The current CPU vendor percentages seem wrong > > (12% Intel, 12% AMD, all others below 1%... far from 100% total!) > > - CPU cores seem to be counted as CPUs. Maybe HT CPUs are also counted > > as multiple CPUs. It would be best to try and separate those > > informations (real CPUs, HTs, cores). > > - Some "< 512" should probably be "=< 512". > > re cpu vendor. Yeah.. just ignore that for now, I've completely > horked up the query it uses to get that stuff. I should probably > comment it out. It would be interesting to get the real AMD vs. Intel numbers :-) > Re: HT. I might have to come up with something clever there. I'm > also wondering if we should just leave it the way the host sees it. > Someone mentioned that speed was getting reported as cpuspeed reports > it, not maximum. I can confirm this. A dual dual-core 5140 2.33GHz system gets reported : numCPUs: 4 CPUSpeed: 1999 As it is currently running at 2GHz indeed (ondemand governor). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.26 1.13 1.33 From vonbrand at inf.utfsm.cl Thu Feb 1 15:03:35 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 01 Feb 2007 12:03:35 -0300 Subject: Version strings [Was: Re: Smolt: Fedora Hardware Profiler] In-Reply-To: <1170306059.8628.37.camel@columbo.corsepiu.local> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3237e4410701310811w82a9523g3dd29f46683f7072@mail.gmail.com> <1170263751.5838.499.camel@mccallum.corsepiu.local> <200701311132.03921.dennis@ausil.us> <1170266048.5838.527.camel@mccallum.corsepiu.local> <1170294392.5838.587.camel@mccallum.corsepiu.local> <16de708d0701311800j2b162591k6c2cf525b60c4050@mail.gmail.com> <1170302071.5838.686.camel@mccallum.corsepiu.local> <200702010405.l1145QZx022936@laptop13.inf.utfsm.cl> <1170306059.8628.37.camel@columbo.corsepiu.local> Message-ID: <200702011503.l11F3Zxf005350@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Thu, 2007-02-01 at 01:05 -0300, Horst H. von Brand wrote: > > Ralf Corsepius wrote: > > > > [...] > > > > > Many servers/service return an id-string identifying the version of a > > > particular piece of SW - If this string is correct it, it provides clear > > > information to which vulnerabilities it is likely to be vulnerable. > > > > In my experience, the use of those for troubleshooting is much more > > important than any vulnerabilities exposed this way. Crackers (particularly > > automated attacks) usually just dive in, without any regard to any version > > strings. Besides, it is easy to guess (quite accurately, via something like > > nmap) what is at the other end. Hiding what you are running is an example > > of what is dismissed with the quip "Security through obscurity, isn't". > It will surprise you: I share this opinion. > Nevertheless, it's still seems pretty common practice. Yes, as the saying here goes, if dumb people could fly, you'd never see the sun. > > It > > is uniformly regarded as almost completely useless. Fix the vulnerabilities, > > don't pretend they aren't there. > I've recently read an article, claiming that most server attacks these > days would be quite simple ("Is this a win server? If yes, attack, if no > stop the attack.) because the overall amount of "easy to intrude, > wide-open, high-bandwith home-servers" would make deep crack attacks > against "real servers" less attractive. Why? Most attacks go after "easy targets" (obviously), mostly because they are after numbers of anonymous machines, not particular machines. And the most realiable way to find out if something is an crackable target or not is just to try the attack. Fell for one recently, on rawhide PAM got broken and random passwords worked against disabled accounts. Hole lasted less than a day, but "just try stupid passwords against common account names over SSH" got them into an otherwise well protected machine. Crackers have almost unlimited computing power at their disposal (other cracked machines by the score), so careful scouting before a planned attack isn't needed at all. That doesn't mean deep attacks aren't going on, but they are much less visible overall (because they are few in between, better planed (and thus less easy to detect), and many targets have a high embarrasment factor to booth). > This article also claimed that there is a market for people collecting, > validating and selling such "potentially vulnerable" addresses esp. to > spammers. Sure thing. > This would indicate the issue is less "not to pretend to have a bug > fixed", but to let a machine appear unattractive for being a candidate > for a deeper attack. > Now, it's up to the beholder to draw his conclusions. Is a machine > identifying as "Fedora linux i386" or "WinServer XYZ" or not providing > an id is more likely to be attacked? - I don't know. I'd guess it makes very little difference. > > > Therefore many server admins use faked id-strings or don't provide this > > > kind of information. > > That is detrimental to legitimate uses, > Legitimate uses should not need them at all. They do. Why doesn't that MTA blackhole mail from here? Oh, yet another badly configured Trend Micro anti-spam thingie. Grelisting stops all mail from some.site.org? An Exchange who hasn't got a clue about 400 error messages. Those are just two recent examples here. Yes, standards are terrific, but next to nobody implements them correctly, and knowing what you are talking to goes a long way to finding out why things break. > > and stops no cracker. > True. Real crackers will probe and find out. Or just dive in just in case. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From caillon at redhat.com Thu Feb 1 15:07:33 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 01 Feb 2007 10:07:33 -0500 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> Message-ID: <45C20235.4080305@redhat.com> Benny Amorsen wrote: >>>>>> "RH" == Richard Hughes writes: > > RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote: >>> 'suspend-to-disk' and 'suspend-to-ram' are much more descriptives >>> names and more consistent with rest of system (/sys/power/state). > > RH> And how many joe-average Linux users know what the contents of > RH> /sys/power/state is? Also, my girlfriend has no concept of what > RH> "ram" is, and why it should be faster than "disk". > > RH> She does understand the speed difference between suspend and > RH> hibernate. > > I don't think I'll ever be able to remember which of suspend and > hibernate means suspend-to-disk. Perhaps its easier for native English > speakers, or perhaps I need my brain fixed. Then use the English dictionary to learn that hibernate is what some animals, e.g. bears as a long sleep over the winter, thus is considered a longer sleep. Or, use a mnemonic device of some sort to help. For example, spell them out: Suspend <-- shorter (less letters) Hibernate <-- longer (more letters) Suspend takes the shorter time, and is RAM, and hibernate takes longer to do, thus suspend to disk. From dimi at lattica.com Thu Feb 1 15:22:22 2007 From: dimi at lattica.com (Dimi Paun) Date: Thu, 1 Feb 2007 10:22:22 -0500 (EST) Subject: rawhide report: 20070201 changes In-Reply-To: <200702011118.l11BIG87025296@hs20-bc2-6.build.redhat.com> References: <200702011118.l11BIG87025296@hs20-bc2-6.build.redhat.com> Message-ID: <2806.207.245.37.34.1170343342.squirrel@lattica.com> On Thu, February 1, 2007 06:18, buildsys at redhat.com wrote: > Removed package eclipse-bugzilla It would be so good if there was an explanation for these package removals... -- Dimi Paun Lattica, Inc. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 1 15:39:40 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Feb 2007 16:39:40 +0100 Subject: rawhide report: 20070201 changes In-Reply-To: <2806.207.245.37.34.1170343342.squirrel@lattica.com> References: <200702011118.l11BIG87025296@hs20-bc2-6.build.redhat.com> <2806.207.245.37.34.1170343342.squirrel@lattica.com> Message-ID: <20070201163940.18ab45e9@python3.es.egwn.lan> Dimi Paun wrote : > > On Thu, February 1, 2007 06:18, buildsys at redhat.com wrote: > > Removed package eclipse-bugzilla > > It would be so good if there was an explanation for these > package removals... It has been explained on fedora-maintainers : Begin forwarded message: Date: Wed, 31 Jan 2007 15:48:18 -0500 From: Andrew Overholt To: fedora-maintainers at redhat Cc: fedora-devel-java-list at redhat Subject: Dropping eclipse-bugzilla Hi, I'd like to drop eclipse-bugzilla from Fedora. It's no longer maintained and the Java 1.5 stuff we're getting will allow us to build and ship Mylar which has better BZ integration. Anyone have any problems with this? How should we go about this? It's currently in Core but I don't want it merged into the BNF. Thanks, Andrew -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.63 1.11 1.13 From jsacco at gnome.org Thu Feb 1 15:41:32 2007 From: jsacco at gnome.org (Joseph E. Sacco) Date: Thu, 01 Feb 2007 10:41:32 -0500 Subject: 2.6.20 series kernels do not boot on systems with SCSI drives Message-ID: <1170344492.2361.9.camel@rt.jesacco.com> The recent sequence of rawhide kernels do no boot on systems with SCSI drives: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220470 The problem appears to be with the 2.6.20.x series kernels. [I am using the numbering system from kernel.org]. Kernel-2.6.19.2, built from source pulled from kernel.org boots and runs without incident. -Joseph -- jsacco [at] gnome [dot] org From pknirsch at redhat.com Thu Feb 1 15:47:02 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 01 Feb 2007 16:47:02 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> Message-ID: <45C20B76.8030505@redhat.com> Benny Amorsen wrote: >>>>>> "RH" == Richard Hughes writes: > > RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote: >>> 'suspend-to-disk' and 'suspend-to-ram' are much more descriptives >>> names and more consistent with rest of system (/sys/power/state). > > RH> And how many joe-average Linux users know what the contents of > RH> /sys/power/state is? Also, my girlfriend has no concept of what > RH> "ram" is, and why it should be faster than "disk". > > RH> She does understand the speed difference between suspend and > RH> hibernate. > > I don't think I'll ever be able to remember which of suspend and > hibernate means suspend-to-disk. Perhaps its easier for native English > speakers, or perhaps I need my brain fixed. > > > /Benny > > Hm, i've talked also with a few other folks here and maybe a short description would help a lot. Or do something like: Hibernate (suspend to memory) and Suspend (suspend to harddisk) although the later really looks wierd as suspend is used twice there. I'll try a few things and see what looks best, probably dicing up the description. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From giallu at gmail.com Thu Feb 1 15:45:26 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 1 Feb 2007 16:45:26 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <20070201120543.00c6a594@python3.es.egwn.lan> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <20070201120543.00c6a594@python3.es.egwn.lan> Message-ID: And what weird machine was this => Fedora Core release 5 (Zod)... From notting at redhat.com Thu Feb 1 16:12:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Feb 2007 11:12:25 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701311204y78ddc877xb940a55e05cb99@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <87abzzov1f.fsf@kosh.bigo.ensc.de> <200701311445.54719.jkeating@redhat.com> <3237e4410701311204y78ddc877xb940a55e05cb99@mail.gmail.com> Message-ID: <20070201161225.GD12074@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at fedoraproject.org) said: > redhat-lsb I might get rid of that. Does anyone here care about the > output from lsb_release? Realistically, for something like this, I'd track the distro release, and let the distro release <-> LSB release association be elsewhere. Bill From michael.wiktowy at gmail.com Thu Feb 1 16:15:59 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Thu, 1 Feb 2007 11:15:59 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> Message-ID: <3e4ec4600702010815n56e68f7ay97fa9f61ad638215@mail.gmail.com> On 1/31/07, Mike McGrath wrote: > Current stats can be found at: > > http://smolt.fedoraproject.org/stats > > You can have your machine send its stats by installing smolt with yum > and typing "smoltSendProfile" Is there any mechanism in place to prevent bogus profiles being submitted? It would be stupid and malicious for people to do that but there is no shortage of stupid malicious people. Also there have been people who already edited their kernel dumps to hide that they were using binary-only modules when seeking help. So that would be another class of people who might do this. I can't really think of a way to prevent this sort of thing in an open system but at least there are way to harden against it and detect some tampering and be able to purge it from the database after. Things I can think of to harden: - flood protection: limit to one submission per time period per IP ... tar pitting might make massive corruption too tedious - whitelist of known hardware: might be hard to capture every single different string that could be generated by your hardware detection but at least some fields have a finite number of different things that it could be and might prevent a lot of "D3wd ... I 0wz0r yur 57475!!!" cpu architectures being submitted. - stats query subset of the whole: If you set up the stats query page to only include what the user wants to look for (rather than have global stats including everything submitted), then you have a human in the loop that can choose whether something looks fishy or not and whether they want to include it in their generated stats. Then the existence of vandalized stats won't matter since the users can easily exclude them from their stats. So the user can query "Out of the cpu architectures X, Y and Z, what percentage is X." as they don't care about the "l337" cpu type and don't want to include those in the total number. Just some thoughts. /Mike From notting at redhat.com Thu Feb 1 16:19:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Feb 2007 11:19:54 -0500 Subject: Compatability libs. Please sir, can I have some more? In-Reply-To: <1170325543.3289.397.camel@dragon.valuecommerce.ne.jp> References: <1170325543.3289.397.camel@dragon.valuecommerce.ne.jp> Message-ID: <20070201161954.GE12074@nostromo.devel.redhat.com> Naoki (naoki at valuecommerce.com) said: > python 2.4 Without an interpreter, is there *any* chance this would actually work at all? Bill From jkeating at redhat.com Thu Feb 1 16:57:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Feb 2007 11:57:45 -0500 Subject: Announcing Fedora 7 Test 1 (6.90) Message-ID: <200702011157.46104.jkeating@redhat.com> Just a quick blurb. Fedora 7 Test 1 has been released today. For this particular release, we only did a Desktop spin of the package collection. We are still fine tuning targetted spins of the collection as part of the merger of Core and Extras. We also produced a LiveCD that has the ability to install to your harddrive, should you wish. http://fedoraproject.org/wiki/Releases/7 has the gory details of our work on the 7th release of Fedora. Downloads ========= DVD, CD and network installation are available. Please read the Important Warnings below in this announcement for more details. http://torrent.fedoraproject.org/ The recommended method of download is via BitTorrent from this site. http://fedora.redhat.com/Download/mirrors.html HTTP, FTP, and RSYNC downloads are available from Fedora Project mirrors listed above. Note that not all mirrors may be synced at this time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jerone at gmail.com Thu Feb 1 17:16:40 2007 From: jerone at gmail.com (Jerone Young) Date: Thu, 1 Feb 2007 11:16:40 -0600 Subject: [RFC] Grub 2 packages for FC7 In-Reply-To: <20070201094505.GB2752@free.fr> References: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> <20070201094505.GB2752@free.fr> Message-ID: <9f50a7a00702010916u4e5afc99pe0d9fbdbfdc5fce4@mail.gmail.com> Sure, except What is the deal with extras? Is it not supposed to be fused with regular repository with FC7? Yes this allows grub2 to be installed in parrallel with grub1. On 2/1/07, Patrice Dumas wrote: > On Thu, Feb 01, 2007 at 02:41:39AM -0600, Jerone Young wrote: > > I've got intial packages for FC7 and grub2. This allows grub2 to be > > installed side by side with grub1. This is especially nice as grub2 is > > still in development and some key features are still not there for > > full replacement of grub one. > > Why don't you submit it for extras? I guess it can be installed in > paralell with grub. > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From drago01 at gmail.com Thu Feb 1 17:24:06 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 01 Feb 2007 18:24:06 +0100 Subject: Announcing Fedora 7 Test 1 (6.90) In-Reply-To: <200702011157.46104.jkeating@redhat.com> References: <200702011157.46104.jkeating@redhat.com> Message-ID: <45C22236.6070209@gmail.com> Jesse Keating wrote: > Just a quick blurb. > > Fedora 7 Test 1 has been released today. For this particular release, we only > did a Desktop spin of the package collection. We are still fine tuning > targetted spins of the collection as part of the merger of Core and Extras. > We also produced a LiveCD that has the ability to install to your harddrive, > should you wish. > > I would like to test this but where is the livecd? cannot find a torrent for it. From katzj at redhat.com Thu Feb 1 17:37:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 01 Feb 2007 12:37:18 -0500 Subject: [RFC] Grub 2 packages for FC7 In-Reply-To: <9f50a7a00702010916u4e5afc99pe0d9fbdbfdc5fce4@mail.gmail.com> References: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> <20070201094505.GB2752@free.fr> <9f50a7a00702010916u4e5afc99pe0d9fbdbfdc5fce4@mail.gmail.com> Message-ID: <1170351438.8736.10.camel@aglarond.local> On Thu, 2007-02-01 at 11:16 -0600, Jerone Young wrote: > On 2/1/07, Patrice Dumas wrote: > > On Thu, Feb 01, 2007 at 02:41:39AM -0600, Jerone Young wrote: > > > I've got intial packages for FC7 and grub2. This allows grub2 to be > > > installed side by side with grub1. This is especially nice as grub2 is > > > still in development and some key features are still not there for > > > full replacement of grub one. > > > > Why don't you submit it for extras? I guess it can be installed in > > paralell with grub. > > Sure, except What is the deal with extras? Is it not supposed to be > fused with regular repository with FC7? Yes this allows grub2 to be > installed in parrallel with grub1. The merge is (slowly) moving along. But the processes for adding new packages will remain almost entirely the same. So go ahead and submit the package and then it'll be easier for people to grab and test and help move forward. Jeremy From david at lovesunix.net Thu Feb 1 17:39:26 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 01 Feb 2007 18:39:26 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <45C20235.4080305@redhat.com> References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> Message-ID: <1170351566.25835.4.camel@dawkins> tor, 01 02 2007 kl. 10:07 -0500, skrev Christopher Aillon: > Benny Amorsen wrote: > >>>>>> "RH" == Richard Hughes writes: > > > > RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote: > >>> 'suspend-to-disk' and 'suspend-to-ram' are much more descriptives > >>> names and more consistent with rest of system (/sys/power/state). > > > > RH> And how many joe-average Linux users know what the contents of > > RH> /sys/power/state is? Also, my girlfriend has no concept of what > > RH> "ram" is, and why it should be faster than "disk". > > > > RH> She does understand the speed difference between suspend and > > RH> hibernate. > > > > I don't think I'll ever be able to remember which of suspend and > > hibernate means suspend-to-disk. Perhaps its easier for native English > > speakers, or perhaps I need my brain fixed. > > Then use the English dictionary to learn that hibernate is what some > animals, e.g. bears as a long sleep over the winter, thus is considered > a longer sleep. > > > Or, use a mnemonic device of some sort to help. For example, spell them > out: > > Suspend <-- shorter (less letters) > Hibernate <-- longer (more letters) > > Suspend takes the shorter time, and is RAM, and hibernate takes longer > to do, thus suspend to disk. A problem you are overlooking is that the whole suspend, hibernate, sleep thing doesn't translate well at all. I had the (dis)pleasure of translating gnome-power-manager and you end up trying to convey slight technical differences in languages which sometimes don't have direct equivalents.. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 nphilipp at redhat.com Thu Feb 1 17:50:45 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 01 Feb 2007 18:50:45 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <45C20B76.8030505@redhat.com> References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> <45C20B76.8030505@redhat.com> Message-ID: <1170352245.8559.16.camel@gibraltar.stuttgart.redhat.com> Hi Phil, On Thu, 2007-02-01 at 16:47 +0100, Phil Knirsch wrote: > Hm, i've talked also with a few other folks here and maybe a short > description would help a lot. Or do something like: > > Hibernate (suspend to memory) > > and > > Suspend (suspend to harddisk) It's exactly vice versa ;-). At least here on my Desktop(tm)(*), "Hibernate" suspends to disk and the "Suspend" entry of the power manager applet has a nice stylized memory module overlay (though I haven't tried it out lately as I should have). (*): Given some not quite recent discussions on this list, my not mentioning what desktop environment I'm using should give you an idea what I use. Sort of ;-P. > although the later really looks wierd as suspend is used twice there. > I'll try a few things and see what looks best, probably dicing up the > description. Maybe: Hibernate (to disk) and: Suspend (to memory) Ciao, Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 hughsient at gmail.com Thu Feb 1 18:02:49 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 01 Feb 2007 18:02:49 +0000 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170351566.25835.4.camel@dawkins> References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> <1170351566.25835.4.camel@dawkins> Message-ID: <1170352969.13451.5.camel@hughsie-laptop> On Thu, 2007-02-01 at 18:39 +0100, David Nielsen wrote: > > A problem you are overlooking is that the whole suspend, hibernate, > sleep thing doesn't translate well at all. I had the (dis)pleasure of > translating gnome-power-manager and you end up trying to convey slight > technical differences in languages which sometimes don't have direct > equivalents.. So you choose non-English words that convey the sleep state, for instance "nap" and "slumber" are two alternate words you could have used in English. I really don't think choosing non-native wording is a good excuse for expressing detailed device specification in the UI. The language teams just have to choose two words in a locale and stick to it. I can even add a translation section to the nomenclature page if you like. Richard. From nphilipp at redhat.com Thu Feb 1 18:03:30 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 01 Feb 2007 19:03:30 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <20070201161225.GD12074@nostromo.devel.redhat.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <87abzzov1f.fsf@kosh.bigo.ensc.de> <200701311445.54719.jkeating@redhat.com> <3237e4410701311204y78ddc877xb940a55e05cb99@mail.gmail.com> <20070201161225.GD12074@nostromo.devel.redhat.com> Message-ID: <1170353010.8559.18.camel@gibraltar.stuttgart.redhat.com> On Thu, 2007-02-01 at 11:12 -0500, Bill Nottingham wrote: > Mike McGrath (mmcgrath at fedoraproject.org) said: > > redhat-lsb I might get rid of that. Does anyone here care about the > > output from lsb_release? > > Realistically, for something like this, I'd track the distro release, > and let the distro release <-> LSB release association be elsewhere. You could always run lsb_release if it exists only (but it's pretty pointless I guess). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 redhat at olen.net Thu Feb 1 18:22:42 2007 From: redhat at olen.net (Ola Thoresen) Date: Thu, 01 Feb 2007 19:22:42 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> Message-ID: <45C22FF2.30606@olen.net> Mike McGrath wrote: > Hey guys, smolt is in a state now where it can be released and tested > by the general public. Currently smolt-firstboot has firstboot > integration with opt in/out. My question for the dev's is: > > Do we as a community want to include this by default in Fedora 7? I can also see this as an extremely useful tool for IT-departments and companies trying to keep track of their hardware. So a nice feature would be to get a local copy of the smolt-server running, and then have all servers and workstations report to that server - either instead of or in addition to the fedora server. That way it would be easy to keep track of which workstations have been upgraded with more RAM, what chipset the different servers have and so on. Ofcourse one could also add a "module" for the local reporting that adds info such as ip and mac-address for network cards, different configuration parameters and so on. Rgds. -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From skvidal at linux.duke.edu Thu Feb 1 18:26:07 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 01 Feb 2007 13:26:07 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <45C22FF2.30606@olen.net> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <45C22FF2.30606@olen.net> Message-ID: <1170354367.1547.50.camel@cutter> On Thu, 2007-02-01 at 19:22 +0100, Ola Thoresen wrote: > Mike McGrath wrote: > > Hey guys, smolt is in a state now where it can be released and tested > > by the general public. Currently smolt-firstboot has firstboot > > integration with opt in/out. My question for the dev's is: > > > > Do we as a community want to include this by default in Fedora 7? > > I can also see this as an extremely useful tool for IT-departments and > companies trying to keep track of their hardware. > So a nice feature would be to get a local copy of the smolt-server > running, and then have all servers and workstations report to that > server - either instead of or in addition to the fedora server. > > That way it would be easy to keep track of which workstations have been > upgraded with more RAM, what chipset the different servers have and so on. > > Ofcourse one could also add a "module" for the local reporting that adds > info such as ip and mac-address for network cards, different > configuration parameters and so on. > +1 - that sounds like a very good idea. -sv From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 1 18:33:19 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 01 Feb 2007 19:33:19 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170322067.3338.19.camel@hughsie-laptop> (Richard Hughes's message of "Thu, 01 Feb 2007 09:27:47 +0000") References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> Message-ID: <87r6t9locw.fsf@kosh.bigo.ensc.de> hughsient at gmail.com (Richard Hughes) writes: >> 'suspend-to-disk' and 'suspend-to-ram' are much more descriptives >> names and more consistent with rest of system (/sys/power/state). > > And how many joe-average Linux users know what the contents of > /sys/power/state is? Also, my girlfriend has no concept of what > "ram" is, and why it should be faster than "disk". Then, she should not be part of the LHCP userbase. Reports from people who do not know the difference between ram and disk are useless and would generate wrong entries in the hardware database only. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From david at lovesunix.net Thu Feb 1 18:44:33 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 01 Feb 2007 19:44:33 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170352969.13451.5.camel@hughsie-laptop> References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> <1170351566.25835.4.camel@dawkins> <1170352969.13451.5.camel@hughsie-laptop> Message-ID: <1170355473.25835.14.camel@dawkins> tor, 01 02 2007 kl. 18:02 +0000, skrev Richard Hughes: > On Thu, 2007-02-01 at 18:39 +0100, David Nielsen wrote: > > > > A problem you are overlooking is that the whole suspend, hibernate, > > sleep thing doesn't translate well at all. I had the (dis)pleasure of > > translating gnome-power-manager and you end up trying to convey slight > > technical differences in languages which sometimes don't have direct > > equivalents.. > > So you choose non-English words that convey the sleep state, for > instance "nap" and "slumber" are two alternate words you could have used > in English. I really don't think choosing non-native wording is a good > excuse for expressing detailed device specification in the UI. The > language teams just have to choose two words in a locale and stick to > it. > > I can even add a translation section to the nomenclature page if you > like. I wasn't picking on you Richard but I'm sure translators will take any help they can get though. I see no big functional difference between the two, might it not be possible just to have one suspend function based on what works best for the platform and having the other (be that STR or STD) be available say via a gconf key. I assume we could catch botched resumes and inform the user that say STR would no longer be the default as it appears unsupported currently. This way we'd have fewer options and the same level of functionality. I suppose LHCP long term will be helpful in tracking down broken drivers (Matthew Garrett claims to drink heavily due to driver suspend/resume bugs - let's save Matthew' poor liver). Do I need to put down the crack pipe? - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 javert42 at cs.byu.edu Thu Feb 1 18:44:52 2007 From: javert42 at cs.byu.edu (Topher Fischer) Date: Thu, 01 Feb 2007 11:44:52 -0700 Subject: Adding modules to Fedora's kernel package In-Reply-To: <20070131094842.412f7249@banea.int.addix.net> References: <45BE6B02.2030207@cs.byu.edu> <20070129214756.GH9363@redhat.com> <20070130083627.230ffc72@banea.int.addix.net> <20070130213754.GC16847@redhat.com> <20070131091139.5d149627@banea.int.addix.net> <20070131094842.412f7249@banea.int.addix.net> Message-ID: <45C23524.2060206@cs.byu.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Ertzinger wrote: > Hi. > > On Wed, 31 Jan 2007 09:11:39 +0100, Ralf Ertzinger wrote: > >> I'm fine with that, I just wanted to point out that just getting hdaps >> into the kernel will save your bacon in case you start throwing your >> laptop around. > > Of course it will _not_ save your bacon or any other breakfast products. > That's not true! It could save all the Spam I have on my hard drive. - -- Topher Fischer GnuPG Fingerprint: 3597 1B8D C7A5 C5AF 2E19 EFF5 2FC3 BE99 D123 6674 javert42 at cs.byu.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFwjUkL8O+mdEjZnQRAv9bAJ9DV9iKp7BWVPU2JdN4BzpzaG1fHACfWu5z i3Yj0kqgOiCSZ4jNsb2469o= =qZYm -----END PGP SIGNATURE----- From overholt at redhat.com Thu Feb 1 18:41:13 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 1 Feb 2007 13:41:13 -0500 Subject: rawhide report: 20070201 changes In-Reply-To: <2806.207.245.37.34.1170343342.squirrel@lattica.com> References: <200702011118.l11BIG87025296@hs20-bc2-6.build.redhat.com> <2806.207.245.37.34.1170343342.squirrel@lattica.com> Message-ID: <20070201184113.GE19841@redhat.com> * Dimi Paun [2007-02-01 10:23]: > > On Thu, February 1, 2007 06:18, buildsys at redhat.com wrote: > > Removed package eclipse-bugzilla > > It would be so good if there was an explanation for these > package removals... Sorry, I should have sent it here as well. Do you currently use eclipse-bugzilla, Dimi? If so, I'm interested in talking about using Mylar instead. Let me know if you're available some time on IRC. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hughsient at gmail.com Thu Feb 1 19:17:15 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 01 Feb 2007 19:17:15 +0000 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170355473.25835.14.camel@dawkins> References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> <1170351566.25835.4.camel@dawkins> <1170352969.13451.5.camel@hughsie-laptop> <1170355473.25835.14.camel@dawkins> Message-ID: <1170357435.22407.4.camel@hughsie-laptop> On Thu, 2007-02-01 at 19:44 +0100, David Nielsen wrote: > > > I wasn't picking on you Richard but I'm sure translators will take any > help they can get though. Sure, I'll blog about the suspend hibernate nomenclature for translators and see if we can get a pseudo-standard sorted for all locales. See http://live.gnome.org/GnomePowerManager/SleepNames for the list so far. > Do I need to put down the crack pipe? Whilst I understand the simplification for users argument, I think suspend (computer still "on", takes about 10 seconds) and hibernate (computer "off", takes about a minute and a half) are sufficiently different to give the user a choice if they have both working. g-p-m already just modifies it's preferences automatically if only one, or neither "should" work on the system. Richard. From brent at brentnorris.net Thu Feb 1 20:06:38 2007 From: brent at brentnorris.net (Brent) Date: Thu, 01 Feb 2007 14:06:38 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <3e4ec4600702010815n56e68f7ay97fa9f61ad638215@mail.gmail.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <3e4ec4600702010815n56e68f7ay97fa9f61ad638215@mail.gmail.com> Message-ID: <45C2484E.90502@brentnorris.net> Michael Wiktowy wrote: > On 1/31/07, Mike McGrath wrote: >> Current stats can be found at: >> >> http://smolt.fedoraproject.org/stats >> >> You can have your machine send its stats by installing smolt with yum >> and typing "smoltSendProfile" > > Is there any mechanism in place to prevent bogus profiles being > submitted? When this was said, I got the image of some company padding the submitted profiles, so they could then say, "Look the number of people using our hardware is > than the number of people using their hardware!" and then trying to leverage that to some effect. Crazy, but there are people that hire people to go and edit Wikipedia into their favor. Brent From jeff at ocjtech.us Thu Feb 1 20:47:04 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 01 Feb 2007 14:47:04 -0600 Subject: Announcing Fedora 7 Test 1 (6.90) In-Reply-To: <45C22236.6070209@gmail.com> References: <200702011157.46104.jkeating@redhat.com> <45C22236.6070209@gmail.com> Message-ID: <1170362824.3843.40.camel@lt21223.campus.dmacc.edu> On Thu, 2007-02-01 at 18:24 +0100, dragoran wrote: > > I would like to test this but where is the livecd? > cannot find a torrent for it. It's there now... Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Thu Feb 1 21:18:04 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 1 Feb 2007 16:18:04 -0500 Subject: Adding modules to Fedora's kernel package In-Reply-To: <1170202269.6077.6.camel@hughsie-laptop> References: <45BE6B02.2030207@cs.byu.edu> <20070129214756.GH9363@redhat.com> <20070130213630.GB16847@redhat.com> <20070130222656.GB15836@nostromo.devel.redhat.com> <20070130235241.GA11603@redhat.com> <1170202269.6077.6.camel@hughsie-laptop> Message-ID: <20070201211804.GA22019@redhat.com> On Wed, Jan 31, 2007 at 12:11:09AM +0000, Richard Hughes wrote: > On Tue, 2007-01-30 at 18:52 -0500, Dave Jones wrote: > > > > Sure. We could. Needs someone to write the bits for module-init-tools > > to parse them based on the dmi of the running system too though. > > HAL exports dmidata in properties on the computer object - or is that > too late in the boot to modprobe stuff? That could work too I guess. The window between bootup and hal starting is sufficiently small not to really be that big a deal. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Thu Feb 1 21:18:52 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 1 Feb 2007 16:18:52 -0500 Subject: Adding modules to Fedora's kernel package In-Reply-To: <20070131020053.GA18505@nostromo.devel.redhat.com> References: <45BE6B02.2030207@cs.byu.edu> <20070129214756.GH9363@redhat.com> <20070130213630.GB16847@redhat.com> <20070130222656.GB15836@nostromo.devel.redhat.com> <20070130235241.GA11603@redhat.com> <20070131020053.GA18505@nostromo.devel.redhat.com> Message-ID: <20070201211852.GB22019@redhat.com> On Tue, Jan 30, 2007 at 09:00:53PM -0500, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > > Can't we add modaliases for DMI data, and have the kernel export that? > > > > Sure. We could. Needs someone to write the bits for module-init-tools > > to parse them based on the dmi of the running system too though. > > Nonono.... these would be exported in /sys/bus/dmi/blahblah/modalias... that > way udev automatically handles it. Oh, that idea I like. A lot. Dave -- http://www.codemonkey.org.uk From giallu at gmail.com Thu Feb 1 21:50:03 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 1 Feb 2007 22:50:03 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170357435.22407.4.camel@hughsie-laptop> References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> <1170351566.25835.4.camel@dawkins> <1170352969.13451.5.camel@hughsie-laptop> <1170355473.25835.14.camel@dawkins> <1170357435.22407.4.camel@hughsie-laptop> Message-ID: On 2/1/07, Richard Hughes wrote: > On Thu, 2007-02-01 at 19:44 +0100, David Nielsen wrote: > > > > > > I wasn't picking on you Richard but I'm sure translators will take any > > help they can get though. > > Sure, I'll blog about the suspend hibernate nomenclature for translators > and see if we can get a pseudo-standard sorted for all locales. > > See http://live.gnome.org/GnomePowerManager/SleepNames for the list so > far. Nice page. I'd argue the italian for Resume is definetely not Resume: shoud probably be Riprendi (spanish like) or Riattiva (french like). /me just wonders why french is the only language with a complete sentence for the action, much like "put to sleep", "put to hibernation"... From hughsient at gmail.com Thu Feb 1 22:00:57 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 01 Feb 2007 22:00:57 +0000 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: References: <45BE11A9.7080702@redhat.com> <1170155715.3368.34.camel@hughsie-laptop> <87r6taohh8.fsf@kosh.bigo.ensc.de> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> <1170351566.25835.4.camel@dawkins> <1170352969.13451.5.camel@hughsie-laptop> <1170355473.25835.14.camel@dawkins> <1170357435.22407.4.camel@hughsie-laptop> Message-ID: <1170367257.11382.0.camel@hughsie-laptop> On Thu, 2007-02-01 at 22:50 +0100, Gianluca Sforna wrote: > > Nice page. > I'd argue the italian for Resume is definetely not Resume: shoud > probably be Riprendi (spanish like) or Riattiva (french like). Please could you choose one and edit the wiki accordingly. Many thanks. Richard. From bruno at wolff.to Thu Feb 1 22:11:21 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 1 Feb 2007 16:11:21 -0600 Subject: [RFC] Grub 2 packages for FC7 In-Reply-To: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> References: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> Message-ID: <20070201221121.GA27533@wolff.to> On Thu, Feb 01, 2007 at 02:41:39 -0600, Jerone Young wrote: > I've got intial packages for FC7 and grub2. This allows grub2 to be > installed side by side with grub1. This is especially nice as grub2 is > still in development and some key features are still not there for > full replacement of grub one. Did you try accessing software raid devices with it? When I last tried it I couldn't get it to recognize md devices. That would be my main reason for switching to it. From giallu at gmail.com Thu Feb 1 22:32:52 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 1 Feb 2007 23:32:52 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170367257.11382.0.camel@hughsie-laptop> References: <45BE11A9.7080702@redhat.com> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> <1170351566.25835.4.camel@dawkins> <1170352969.13451.5.camel@hughsie-laptop> <1170355473.25835.14.camel@dawkins> <1170357435.22407.4.camel@hughsie-laptop> <1170367257.11382.0.camel@hughsie-laptop> Message-ID: On 2/1/07, Richard Hughes wrote: > On Thu, 2007-02-01 at 22:50 +0100, Gianluca Sforna wrote: > > > > Nice page. > > I'd argue the italian for Resume is definetely not Resume: shoud > > probably be Riprendi (spanish like) or Riattiva (french like). > > Please could you choose one and edit the wiki accordingly. > Done From chabotc at xs4all.nl Fri Feb 2 07:25:56 2007 From: chabotc at xs4all.nl (Chris Chabot) Date: Fri, 2 Feb 2007 08:25:56 +0100 Subject: Failed instalation of Fedora 7t1 on a MacBook Pro Message-ID: <001501c7469b$61037440$4101a8c0@xps> Hi All, In an moment of inspiration i wanted to see how fc7 test1 would install on my MacBook Pro, to see if the sound, wireless etc would work better then with fc6... so i loaded up bootcamp, repartitoned to make space for a fc7 instalation and booted up the fc7 (i386) test1 dvd. However my efferts were twarted, by a instalation screen that doesn't recognise my keyboard, and a 60 second timeout that seems to take forever, and doesn't fire after 60 seconds :-) In fc6 instalations the installer/boot menu wouldn't be controlable by keyboard too, but atleast it would continue after N seconds Any advice on how to get around this? Thanks in advance for any advice! -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From atkac at redhat.com Fri Feb 2 10:44:55 2007 From: atkac at redhat.com (Adam Tkac) Date: Fri, 02 Feb 2007 11:44:55 +0100 Subject: BIND 9.4 has been released for testing Message-ID: <45C31627.2070006@redhat.com> Hi all, I have built source rpm of new BIND 9.4 series nameserver for testing purposes. This version is more faster than 9.3 series and have many new features. Users could download source rpm from http://people.redhat.com/atkac/bind-9.4.0rc2-1.fc7.src.rpm . Please report all bugs to https://bugzilla.redhat.com . Regards, Adam From buildsys at redhat.com Fri Feb 2 11:54:15 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 2 Feb 2007 06:54:15 -0500 Subject: rawhide report: 20070202 changes Message-ID: <200702021154.l12BsFK3006323@hs20-bc2-6.build.redhat.com> Updated Packages: bind-31:9.3.4-3.fc7 ------------------- * Thu Feb 01 2007 Adam Tkac 31:9.3.4-3.fc7 - fixed building without libbind - fixed post section (selinux commands is now in if-endif statement) - prever macro has been removed from version chkconfig-1.3.32-1 ------------------ * Fri Feb 02 2007 Bill Nottingham 1.3.32-1 - support overriding various defaults via /etc/chkconfig.d () * Thu Feb 01 2007 Bill Nottingham 1.3.31-1 - fix man page (#220558, ) - add some more verbiage in alternatives man page (#221089) - don't print usage message on a nonexstent service (#226804) * Fri Dec 01 2006 Bill Nottingham 1.3.30.1-1 - translation updates: as, ka, lv, ml, te (#216617) cscope-15.5-15.2..fc7 --------------------- * Thu Feb 01 2007 Neil Horman -15.5-15.2.dist - Fixing changelog to not have macro in release * Wed Aug 23 2006 Neil Horman -15.5-15.1 - fixed overflows per bz 203651 - start using {dist} tag to make release numbering easier * Mon Jul 17 2006 Jesse Keating - 15.5-14 - rebuild dcraw-8.53-1.fc7 ---------------- * Thu Feb 01 2007 Nils Philippsen - 8.53-1 - upstream finally has a tarball, use that and its version (#209016) - use dist tag dhcp-12:3.0.5-13.fc7 -------------------- * Wed Jan 31 2007 David Cantrell - 12:3.0.5-13 - Add support for dhcpd(8) to read dhcpd.conf from an LDAP server (#224352) - Remove invalid ja_JP.eucJP man pages from /usr/share/doc fonts-arabic-2.0-5.fc7 ---------------------- * Thu Feb 01 2007 Parag Nemade - 2.0-5 - Updated SPEC file as part of Core/Extras Review Bug rh#225760 gtkhtml3-3.13.5-2.fc7 --------------------- * Thu Feb 01 2007 Matthew Barnes - 3.13.5-2.fc7 - Add -j2 and $RPM_OPT_FLAGS to make command (RH bug #225872). htdig-3:3.2.0b6-10.fc7 ---------------------- * Thu Feb 01 2007 Adam Tkac 3:3.2.0b6-10.fc7 - removed sigfault patch because it isn't stable yet - changed common_dir in htdig.conf to /var/www/html/htdig (#220390) kdesdk-3.5.6-0.1.fc6 -------------------- * Thu Feb 01 2007 Than Ngo 3.5.6-0.1.fc6 - 3.5.6 policycoreutils-1.34.1-4.fc7 ---------------------------- * Thu Feb 01 2007 Dan Walsh 1.34.1-4 - Fix audit2allow on missing translations python-2.5-10.fc7 ----------------- * Thu Feb 01 2007 Jeremy Katz - 2.5.3-10 - rebuild for new tcl/tk * Tue Jan 16 2007 Miroslav Lichvar - 2.5.3-9 - link with ncurses * Sat Jan 06 2007 Jeremy Katz - 2.5.3-8 - fix extensions to use shared libpython (#219564) - all 64bit platforms need the regex fix (#122304) radvd-1.0-2.fc7 --------------- * Thu Feb 01 2007 Martin Bacovsky - 1.0-2.fc7 - linking with -pie flag turned on again selinux-policy-2.5.2-3.fc7 -------------------------- * Thu Jan 25 2007 Dan Walsh 2.5.2-3 - Remove some targeted diffs in file context file setools-3.0-3.fc7 ----------------- * Thu Feb 01 2007 Dan Walsh 3.0-3 - Rebuild with newer libtk system-config-users-1.2.52-1.fc7 -------------------------------- * Thu Feb 01 2007 Nils Philippsen - 1.2.52 - fix BR: find-utils -> findutils - fix syntax error in Makefile * Wed Jan 31 2007 Nils Philippsen - use "install -m" to install a lot of files without executable bits (#222580) * Tue Jan 30 2007 Nils Philippsen - fix warning about all-digit usernames tcl-8.5a5-6.fc7 --------------- * Thu Jan 25 2007 Marcela Maslanova - 8.5a5-6 - rebuilt for obsoletes rhbz#217735 * Thu Jan 25 2007 Marcela Maslanova - 8.5a5-5 - rebuilt * Mon Dec 18 2006 Marcela Maslanova - 8.5a5-4 - change in spec for compatibility with tk, version 8.5a5 - Resolves: rhbz#160441 tn5250-0.17.3-7 --------------- * Thu Feb 01 2007 Karsten Hopp 0.17.3-7 - move tn5250,m4 and lib5250.so to -devel subpackage (#203639) - move tn5250-config, too - use macros Broken deps for ppc ---------------------------------------------------------- expect - 5.43.0-5.1.ppc requires libtcl8.4.so expectk - 5.43.0-5.1.ppc requires libtk8.4.so expectk - 5.43.0-5.1.ppc requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.ppc requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtk8.4.so Broken deps for i386 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expectk - 5.43.0-5.1.i386 requires libtk8.4.so expectk - 5.43.0-5.1.i386 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.i386 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- expect - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc64 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtk8.4.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expect - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.x86_64 requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) Broken deps for ia64 ---------------------------------------------------------- expect - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ia64 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtk8.4.so()(64bit) Broken deps for s390 ---------------------------------------------------------- expect - 5.43.0-5.1.s390 requires libtcl8.4.so expectk - 5.43.0-5.1.s390 requires libtk8.4.so expectk - 5.43.0-5.1.s390 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.s390 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtcl8.4.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- expect - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) expect - 5.43.0-5.1.s390 requires libtcl8.4.so expectk - 5.43.0-5.1.s390x requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtk8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390x requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtk8.4.so()(64bit) From rdieter at math.unl.edu Fri Feb 2 12:14:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 02 Feb 2007 06:14:05 -0600 Subject: F7 KDE spin References: <45A2BABB.2090902@math.unl.edu> <16de708d0701081825l33023bd4p818ad14919feae0b@mail.gmail.com> <13dbfe4f0701311250p5495474bye31869bd7abb983e@mail.gmail.com> <45C124AB.4020109@redhat.com> <45C164DA.1010701@redhat.com> <1170340715.9637.29.camel@golem.boston.devel.redhat.com> Message-ID: Matthias Clasen wrote: > On Wed, 2007-01-31 at 22:56 -0500, Warren Togami wrote: >> Which MIME system does it use? That of the current desktop in use. >> Is this an upstream freedesktop.org standard? yes. >> Has both GNOME and KDE accepted xdg-open? Yes, more or less, modulo a few certain folks. (: > There is nothing to accept here, really. The xdg- wrapper scripts are > meant for third-party software that wants to work on multiple desktops. > > They were never intended to be pushed back into the desktops themselves, > At least that was not case when the Portland project was started. I have it on good authority xdg-utils will be included (or at least proposed for inclusion) in the next iteration of LSB, so, whatever the original intent, it's here, and it's here to stay (for awhile anyway, until something better comes along). -- Rex From opensource at till.name Fri Feb 2 15:19:40 2007 From: opensource at till.name (Till Maas) Date: Fri, 02 Feb 2007 16:19:40 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <1170352245.8559.16.camel@gibraltar.stuttgart.redhat.com> References: <45BE11A9.7080702@redhat.com> <45C20B76.8030505@redhat.com> <1170352245.8559.16.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200702021619.47618.opensource@till.name> On Thursday 01 February 2007 18:50, Nils Philippsen wrote: > Hibernate (to disk) > > and: > > Suspend (to memory) Another suggestion: hibernate (suspend to disk) sleep (suspend to ram) Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Fri Feb 2 16:28:21 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 02 Feb 2007 17:28:21 +0100 Subject: x86_64 live cd/dvd Message-ID: <45C366A5.5040400@gmail.com> Is one planed for F7 ? Test1 only has a i386 one. From jkeating at redhat.com Fri Feb 2 18:41:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Feb 2007 13:41:27 -0500 Subject: x86_64 live cd/dvd In-Reply-To: <45C366A5.5040400@gmail.com> References: <45C366A5.5040400@gmail.com> Message-ID: <200702021341.30027.jkeating@redhat.com> On Friday 02 February 2007 11:28, dragoran wrote: > Is one planed for F7 ? > Test1 only has a i386 one. yes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmus at tmus.dk Fri Feb 2 18:01:36 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 02 Feb 2007 19:01:36 +0100 Subject: x86_64 live cd/dvd In-Reply-To: <45C366A5.5040400@gmail.com> References: <45C366A5.5040400@gmail.com> Message-ID: dragoran wrote: > Is one planed for F7 ? > Test1 only has a i386 one. > On a similar note - I suspect, for now, that the "Desktop" version is what compares to Core today, and what should be tested even for server stuff. Or am I mistaken? /Thomas From jkeating at redhat.com Fri Feb 2 19:10:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Feb 2007 14:10:57 -0500 Subject: x86_64 live cd/dvd In-Reply-To: References: <45C366A5.5040400@gmail.com> Message-ID: <200702021410.57505.jkeating@redhat.com> On Friday 02 February 2007 13:01, Thomas M Steenholdt wrote: > On a similar note - I suspect, for now, that the "Desktop" version is > what compares to Core today, and what should be tested even for server > stuff. Or am I mistaken? No, the Desktop spin is smaller than what Core was. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bdwheele at indiana.edu Fri Feb 2 19:22:19 2007 From: bdwheele at indiana.edu (Brian Wheeler) Date: Fri, 02 Feb 2007 14:22:19 -0500 Subject: f7 test: failure in qemu In-Reply-To: <200702021410.57505.jkeating@redhat.com> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> Message-ID: <1170444139.13309.34.camel@wombat.dlib.indiana.edu> It looks like in Fedora 7 Test 1 there's a couple of things that don't work in QEMU. On the Live CD: === -------------------------------------- WARNING: Cannot find root file system! -------------------------------------- Create symlink /dev/root and then exit this shell to continue the boot sequence === There's also a udev deprecation warning in 00-cdlabel.rules On the DVD: the cdrom device isn't found, so I can't install from it. It should be pretty standard and it has always worked before. Is this due to the new ide layer? Brian From eswierk at arastra.com Fri Feb 2 19:29:54 2007 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 2 Feb 2007 11:29:54 -0800 Subject: f7 test: failure in qemu In-Reply-To: <1170444139.13309.34.camel@wombat.dlib.indiana.edu> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> Message-ID: On 2/2/07, Brian Wheeler wrote: > On the DVD: the cdrom device isn't found, so I can't install from it. > > It should be pretty standard and it has always worked before. Is this > due to the new ide layer? I just noticed that. The libata/ide thing seems to be the culprit. I am about to try the latest qemu CVS, as a lot of changes have occurred since 0.8.2. --Ed From bdwheele at indiana.edu Fri Feb 2 19:43:39 2007 From: bdwheele at indiana.edu (Brian Wheeler) Date: Fri, 02 Feb 2007 14:43:39 -0500 Subject: f7 test: failure in qemu In-Reply-To: References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> Message-ID: <1170445419.13309.41.camel@wombat.dlib.indiana.edu> On Fri, 2007-02-02 at 11:29 -0800, Ed Swierk wrote: > On 2/2/07, Brian Wheeler wrote: > > On the DVD: the cdrom device isn't found, so I can't install from it. > > > > It should be pretty standard and it has always worked before. Is this > > due to the new ide layer? > > I just noticed that. The libata/ide thing seems to be the culprit. I > am about to try the latest qemu CVS, as a lot of changes have occurred > since 0.8.2. > > --Ed > I just now started the latest CVS version and it seems to be working. I was running an earlier (but still post 0.8.2) CVS version. The DVD still dumps garbage on the screen when displaying the boot menu, though. Brian From alan at redhat.com Fri Feb 2 19:54:24 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Feb 2007 14:54:24 -0500 Subject: f7 test: failure in qemu In-Reply-To: References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> Message-ID: <20070202195424.GA25372@devserv.devel.redhat.com> On Fri, Feb 02, 2007 at 11:29:54AM -0800, Ed Swierk wrote: > I just noticed that. The libata/ide thing seems to be the culprit. I > am about to try the latest qemu CVS, as a lot of changes have occurred > since 0.8.2. Unless qemu has improved a lot recently you'll have real problems with ATAPI DMA From eswierk at arastra.com Fri Feb 2 20:21:48 2007 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 2 Feb 2007 12:21:48 -0800 Subject: f7 test: failure in qemu In-Reply-To: <20070202195424.GA25372@devserv.devel.redhat.com> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <20070202195424.GA25372@devserv.devel.redhat.com> Message-ID: On 2/2/07, Alan Cox wrote: > Unless qemu has improved a lot recently you'll have real problems with > ATAPI DMA Well, some of these log messages give reason to hope: http://cvs.savannah.nongnu.org/viewcvs/qemu/hw/ide.c?rev=1.53&root=qemu&view=log --Ed From hughsient at gmail.com Fri Feb 2 20:35:04 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 02 Feb 2007 20:35:04 +0000 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <200702021619.47618.opensource@till.name> References: <45BE11A9.7080702@redhat.com> <45C20B76.8030505@redhat.com> <1170352245.8559.16.camel@gibraltar.stuttgart.redhat.com> <200702021619.47618.opensource@till.name> Message-ID: <1170448504.28357.2.camel@hughsie-laptop> On Fri, 2007-02-02 at 16:19 +0100, Till Maas wrote: > > hibernate (suspend to disk) > sleep (suspend to ram) No, sleep is used and has been used for all the sleep states over the years, S1, S3 *and* S4. It's got no real meaning anymore. If talking about situations involving suspend and hibernate, sleep if okay as it means both, and in this case I think it's harmless. Richard. From bojan at rexursive.com Fri Feb 2 23:02:05 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 2 Feb 2007 23:02:05 +0000 (UTC) Subject: f7 test: failure in qemu References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> Message-ID: Brian Wheeler indiana.edu> writes: > On the Live CD: > === > -------------------------------------- > WARNING: Cannot find root file system! > -------------------------------------- > > Create symlink /dev/root and then exit this shell to continue the boot > sequence > === Got this without qemu, straight on bare hardware (HP Pavilion ZE4201). -- Bojan From buildsys at redhat.com Sat Feb 3 11:52:09 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 3 Feb 2007 06:52:09 -0500 Subject: rawhide report: 20070203 changes Message-ID: <200702031152.l13Bq9fL019564@hs20-bc2-6.build.redhat.com> Updated Packages: NetworkManager-1:0.6.5-0.2.cvs20061025.fc7 ------------------------------------------ * Fri Feb 02 2007 Christopher Aillon - 1:0.6.5-0.2.cvs20061025 - Move .so file to -devel package avahi-0.6.16-3.fc7 ------------------ * Fri Feb 02 2007 Christopher Aillon - 0.6.16-3 - Remove bogus mono-libdir patches bug-buddy-1:2.17.3-2.fc7 ------------------------ * Fri Feb 02 2007 Ray Strode - 1:2.17.3-2 - change %makeinstall over to using DESTDIR instead - remove --vendor gnome and --add-category X-Red-Hat-Extra from desktop-file-utils - remove crufy perl s/// that's not need anymore - get rid of line that remove icon cache since it's not erroneously created anymore busybox-1:1.2.2-5.fc7 --------------------- * Fri Feb 02 2007 Ivana Varekova - 1:1.2.2-5 - fix id_ps patch (thanks Chris MacGregor) byacc-1.9.20050813-1.fc7 ------------------------ * Fri Feb 02 2007 Petr Machata - 1.9.20050813-1 - Thomas Dickey's 20050813 version of byacc: - own build system (linux patch reverted) - use tmpfile (security patch reverted) - Tidy up the specfile per rpmlint comments desktop-file-utils-0.12-3.fc7 ----------------------------- * Tue Nov 28 2006 Ray Strode - 0.12-3 - drop some rm -f cruft - don't call update-desktop-database from %post or %postun * Tue Nov 28 2006 Ray Strode - 0.12-2 - make --vendor optional dhcdbd-2.4-1.fc7 ---------------- * Fri Feb 02 2007 David Cantrell - 2.4-1 - Enable dhcdbd service by default in runlevels 2, 3, 4, and 5 * Mon Nov 06 2006 David Cantrell - 2.3-1 - Require dhcp-3.0.4 or higher - Removed the tests subdirectory since they are old and not useful dhcp-12:3.0.5-14.fc7 -------------------- * Fri Feb 02 2007 David Cantrell - 12:3.0.5-14 - Only export the symbols we want in libdhcp4client (#198496) eclipse-1:3.2.1-35.fc7 ---------------------- * Thu Feb 01 2007 Ben Konrath 3.2.1-35 - Use original name for the SWT JNI symlinks. - Rework ppc64, s390{x} and sparc{64} hack to fix multilib problem. - Update ecj [] patch to upstream version from 3.3. flex-2.5.33-4.fc7 ----------------- * Fri Feb 02 2007 Petr Machata - 2.5.33-4 - Use %find_lang to package locale files. freetype-2.3.1-1.fc7 -------------------- * Fri Feb 02 2007 Behdad Esfahbod 2.3.1-1 - Update to 2.3.1. glibc-2.5.90-16 --------------- * Fri Feb 02 2007 Jakub Jelinek 2.5.90-16 - add strerror_l - fix application crashes when doing NSS lookups through nscd mmapped databases and nscd decides to start garbage collection during the lookups (#219145, #225315) - fix %0lld printing of 0LL on 32-bit architectures (BZ#3902) - ignore errors from install-info in glibc-devel scriptlets (#223691) gtk-doc-1.7-3.fc7 ----------------- * Fri Feb 02 2007 Matthias Clasen - 1.7-3 - Fix the omf file (#223684) gtk2-2.10.9-3.fc7 ----------------- * Fri Feb 02 2007 Matthias Clasen - 2.10.9-3 - Fix update-gtk-immodules and update-gdk-pixbuf-loaders being swapped (#227134) indent-2.2.9-16.fc7 ------------------- * Fri Feb 02 2007 Petr Machata - 2.2.9-16 - Tidy up the specfile per rpmlint comments - Use utf-8 and fix national characters in contributor's names libdrm-2.3.0-3.fc7 ------------------ * Fri Feb 02 2007 Adam Jackson 2.3.0-3 - Remove ExclusiveArch. netpbm-10.35-11.fc7 ------------------- * Fri Feb 02 2007 Jindrich Novy 10.35-11 - fix pbmtomacp buffer overflow (#226969) openoffice.org-1:2.2.0-5.1 -------------------------- * Thu Feb 01 2007 Caolan McNamara - 1:2.2.0-5.1 - next candidate - workspace.npower5 integrated - some valgrind fixes integrated - Resolves: rhbz#158538 page breaks in calc problem - pair of build fixes pkgconfig-1:0.21-4.fc7 ---------------------- * Fri Feb 02 2007 Matthias Clasen - 1:0.21-4 - Address some package review complaints readahead-1:1.3-6.fc6 --------------------- * Fri Feb 02 2007 Karel Zak - 1:1.3-6 - update file lists selinux-policy-2.5.2-4.fc7 -------------------------- * Thu Feb 01 2007 Dan Walsh 2.5.2-4 - Fix spamassisin so crond can update spam files - Fixes to allow kpasswd to work - Fixes for bluetooth sg3_utils-1.23-1.fc7 -------------------- * Fri Feb 02 2007 Phil Knirsch - 1.23-1 - Update to sg3_utils-1.23 - Updated summary tetex-3.0-36.fc7 ---------------- * Thu Feb 01 2007 Jindrich Novy 3.0-36 - fix a couple of string overflows in makeindex, CVE-2007-0650 (#225491) - fix file list processing Broken deps for ppc ---------------------------------------------------------- expect - 5.43.0-5.1.ppc requires libtcl8.4.so expectk - 5.43.0-5.1.ppc requires libtk8.4.so expectk - 5.43.0-5.1.ppc requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.ppc requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtk8.4.so Broken deps for i386 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expectk - 5.43.0-5.1.i386 requires libtk8.4.so expectk - 5.43.0-5.1.i386 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.i386 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- expect - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc64 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtk8.4.so()(64bit) Broken deps for s390 ---------------------------------------------------------- expect - 5.43.0-5.1.s390 requires libtcl8.4.so expectk - 5.43.0-5.1.s390 requires libtk8.4.so expectk - 5.43.0-5.1.s390 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.s390 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtcl8.4.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- expect - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ia64 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtk8.4.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expect - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.x86_64 requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) Broken deps for s390x ---------------------------------------------------------- expect - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) expect - 5.43.0-5.1.s390 requires libtcl8.4.so expectk - 5.43.0-5.1.s390x requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtk8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390x requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtk8.4.so()(64bit) From gparted at gmail.com Sat Feb 3 13:27:00 2007 From: gparted at gmail.com (LarryT) Date: Sat, 03 Feb 2007 14:27:00 +0100 Subject: rawhide report: 20070203 changes In-Reply-To: <200702031152.l13Bq9fL019564@hs20-bc2-6.build.redhat.com> References: <200702031152.l13Bq9fL019564@hs20-bc2-6.build.redhat.com> Message-ID: <45C48DA4.6050107@gmail.com> Hello, I am not able to make updates atm : got this output from yum, always and always : Trying other mirror. primary.xml.gz 100% |=========================| 811 kB 00:00 http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 810 kB 00:00 http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. How come ? thx Larry buildsys at redhat.com wrote: > > > > Updated Packages: > > NetworkManager-1:0.6.5-0.2.cvs20061025.fc7 > ------------------------------------------ > * Fri Feb 02 2007 Christopher Aillon - 1:0.6.5-0.2.cvs20061025 > - Move .so file to -devel package > > avahi-0.6.16-3.fc7 > ------------------ > * Fri Feb 02 2007 Christopher Aillon - 0.6.16-3 > - Remove bogus mono-libdir patches > > bug-buddy-1:2.17.3-2.fc7 > ------------------------ > * Fri Feb 02 2007 Ray Strode - 1:2.17.3-2 > - change %makeinstall over to using DESTDIR instead > - remove --vendor gnome and --add-category X-Red-Hat-Extra from > desktop-file-utils > - remove crufy perl s/// that's not need anymore > - get rid of line that remove icon cache since it's not > erroneously created anymore > > busybox-1:1.2.2-5.fc7 > --------------------- > * Fri Feb 02 2007 Ivana Varekova - 1:1.2.2-5 > - fix id_ps patch (thanks Chris MacGregor) > > byacc-1.9.20050813-1.fc7 > ------------------------ > * Fri Feb 02 2007 Petr Machata - 1.9.20050813-1 > - Thomas Dickey's 20050813 version of byacc: > - own build system (linux patch reverted) > - use tmpfile (security patch reverted) > - Tidy up the specfile per rpmlint comments > > desktop-file-utils-0.12-3.fc7 > ----------------------------- > * Tue Nov 28 2006 Ray Strode - 0.12-3 > - drop some rm -f cruft > - don't call update-desktop-database from %post or %postun > > * Tue Nov 28 2006 Ray Strode - 0.12-2 > - make --vendor optional > > dhcdbd-2.4-1.fc7 > ---------------- > * Fri Feb 02 2007 David Cantrell - 2.4-1 > - Enable dhcdbd service by default in runlevels 2, 3, 4, and 5 > > * Mon Nov 06 2006 David Cantrell - 2.3-1 > - Require dhcp-3.0.4 or higher > - Removed the tests subdirectory since they are old and not useful > > dhcp-12:3.0.5-14.fc7 > -------------------- > * Fri Feb 02 2007 David Cantrell - 12:3.0.5-14 > - Only export the symbols we want in libdhcp4client (#198496) > > eclipse-1:3.2.1-35.fc7 > ---------------------- > * Thu Feb 01 2007 Ben Konrath 3.2.1-35 > - Use original name for the SWT JNI symlinks. > - Rework ppc64, s390{x} and sparc{64} hack to fix multilib problem. > - Update ecj [] patch to upstream version from 3.3. > > flex-2.5.33-4.fc7 > ----------------- > * Fri Feb 02 2007 Petr Machata - 2.5.33-4 > - Use %find_lang to package locale files. > > freetype-2.3.1-1.fc7 > -------------------- > * Fri Feb 02 2007 Behdad Esfahbod 2.3.1-1 > - Update to 2.3.1. > > glibc-2.5.90-16 > --------------- > * Fri Feb 02 2007 Jakub Jelinek 2.5.90-16 > - add strerror_l > - fix application crashes when doing NSS lookups through nscd > mmapped databases and nscd decides to start garbage collection > during the lookups (#219145, #225315) > - fix %0lld printing of 0LL on 32-bit architectures (BZ#3902) > - ignore errors from install-info in glibc-devel scriptlets > (#223691) > > gtk-doc-1.7-3.fc7 > ----------------- > * Fri Feb 02 2007 Matthias Clasen - 1.7-3 > - Fix the omf file (#223684) > > gtk2-2.10.9-3.fc7 > ----------------- > * Fri Feb 02 2007 Matthias Clasen - 2.10.9-3 > - Fix update-gtk-immodules and update-gdk-pixbuf-loaders > being swapped (#227134) > > indent-2.2.9-16.fc7 > ------------------- > * Fri Feb 02 2007 Petr Machata - 2.2.9-16 > - Tidy up the specfile per rpmlint comments > - Use utf-8 and fix national characters in contributor's names > > libdrm-2.3.0-3.fc7 > ------------------ > * Fri Feb 02 2007 Adam Jackson 2.3.0-3 > - Remove ExclusiveArch. > > netpbm-10.35-11.fc7 > ------------------- > * Fri Feb 02 2007 Jindrich Novy 10.35-11 > - fix pbmtomacp buffer overflow (#226969) > > openoffice.org-1:2.2.0-5.1 > -------------------------- > * Thu Feb 01 2007 Caolan McNamara - 1:2.2.0-5.1 > - next candidate > - workspace.npower5 integrated > - some valgrind fixes integrated > - Resolves: rhbz#158538 page breaks in calc problem > - pair of build fixes > > pkgconfig-1:0.21-4.fc7 > ---------------------- > * Fri Feb 02 2007 Matthias Clasen - 1:0.21-4 > - Address some package review complaints > > readahead-1:1.3-6.fc6 > --------------------- > * Fri Feb 02 2007 Karel Zak - 1:1.3-6 > - update file lists > > selinux-policy-2.5.2-4.fc7 > -------------------------- > * Thu Feb 01 2007 Dan Walsh 2.5.2-4 > - Fix spamassisin so crond can update spam files > - Fixes to allow kpasswd to work > - Fixes for bluetooth > > sg3_utils-1.23-1.fc7 > -------------------- > * Fri Feb 02 2007 Phil Knirsch - 1.23-1 > - Update to sg3_utils-1.23 > - Updated summary > > tetex-3.0-36.fc7 > ---------------- > * Thu Feb 01 2007 Jindrich Novy 3.0-36 > - fix a couple of string overflows in makeindex, CVE-2007-0650 (#225491) > - fix file list processing > > Broken deps for ppc > ---------------------------------------------------------- > expect - 5.43.0-5.1.ppc requires libtcl8.4.so > expectk - 5.43.0-5.1.ppc requires libtk8.4.so > expectk - 5.43.0-5.1.ppc requires libtcl8.4.so > hfsutils - 3.2.6-7.2.2.ppc requires libtcl8.4.so > hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtk8.4.so > hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtcl8.4.so > isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so > kdebase - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.ppc requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.ppc requires libtcl8.4.so > pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so > pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so > ruby-libs - 1.8.5.2-1.fc7.ppc requires libtcl8.4.so > ruby-libs - 1.8.5.2-1.fc7.ppc requires libtk8.4.so > > > > Broken deps for i386 > ---------------------------------------------------------- > expect - 5.43.0-5.1.i386 requires libtcl8.4.so > expectk - 5.43.0-5.1.i386 requires libtk8.4.so > expectk - 5.43.0-5.1.i386 requires libtcl8.4.so > hfsutils - 3.2.6-7.2.2.i386 requires libtcl8.4.so > hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtk8.4.so > hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtcl8.4.so > isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so > kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.i386 requires libtcl8.4.so > pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so > pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so > > > > Broken deps for ppc64 > ---------------------------------------------------------- > expect - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.ppc64 requires libtk8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtk8.4.so()(64bit) > isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.ppc64 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.ppc64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtk8.4.so()(64bit) > > > > Broken deps for s390 > ---------------------------------------------------------- > expect - 5.43.0-5.1.s390 requires libtcl8.4.so > expectk - 5.43.0-5.1.s390 requires libtk8.4.so > expectk - 5.43.0-5.1.s390 requires libtcl8.4.so > hfsutils - 3.2.6-7.2.2.s390 requires libtcl8.4.so > hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtk8.4.so > hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtcl8.4.so > kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.s390 requires libtcl8.4.so > pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so > pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtk8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtcl8.4.so > systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 > systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 > > > > Broken deps for ia64 > ---------------------------------------------------------- > expect - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.ia64 requires libtk8.4.so()(64bit) > expectk - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtk8.4.so()(64bit) > isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.ia64 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.ia64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtk8.4.so()(64bit) > > > > Broken deps for x86_64 > ---------------------------------------------------------- > expect - 5.43.0-5.1.i386 requires libtcl8.4.so > expect - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.x86_64 requires libtk8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtk8.4.so()(64bit) > isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdebase - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.x86_64 requires kdelibs-devel >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.x86_64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) > > > > Broken deps for s390x > ---------------------------------------------------------- > expect - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) > expect - 5.43.0-5.1.s390 requires libtcl8.4.so > expectk - 5.43.0-5.1.s390x requires libtk8.4.so()(64bit) > expectk - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtk8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 > kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.s390x requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.s390x requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtk8.4.so()(64bit) > > > > From Matt_Domsch at dell.com Sat Feb 3 14:10:10 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 3 Feb 2007 08:10:10 -0600 Subject: Core x86_64 rawhide rebuild in mock status 2007-02-03 Message-ID: <20070203081010.A1175@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for x86_64 Sat Feb 3 07:30:18 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1157 Number failed to build: 82 Number expected to fail due to ExclusiveArch or ExcludeArch: 22 Leaving: 60 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 60 ---------------------------------- alacarte-0.11.1.1-2.fc7 amanda-2.5.0p2-4 anthy-7900-2.fc6 automake16-1.6.3-8 automake17-1.7.9-7 boost-1.33.1-10.fc7 castor-0.9.5-1jpp.7 compat-gcc-296-2.96-138 compat-gcc-32-3.2.3-61 compat-gcc-34-3.4.6-4 cscope-15.5-15.2..fc7 g-wrap-1.9.6-7.1 gdb-6.6-2.fc7 gmime-2.2.3-3.fc6 gnome-sharp-2.16.0-1.fc6 gnucash-2.0.4-1.fc6 grub-0.97-13 icon-naming-utils-0.8.1-1.fc6 jgroups-2.2.9.2-3jpp.2 junit-3.8.2-3jpp.1 kasumi-2.0.1-1.1.fc6 kdeadmin-3.5.5-0.1.fc6 kdeartwork-3.5.5-0.1.fc6 kdegames-3.5.6-0.1.fc6 kdegraphics-3.5.5-0.1.fc6 kdemultimedia-3.5.6-0.1.fc6 kdenetwork-3.5.5-0.1.fc6 kdesdk-3.5.6-0.1.fc6 kdevelop-3.3.5-0.1.fc6 kdewebdev-3.5.5-0.1.fc6 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libdhcp-1.19-3.fc7 libgssapi-0.10-1 linux-atm-2.5.0-1.20050118cvs memtest86+-1.65-4.1 mikmod-3.1.6-39.fc7 mysql-5.0.27-1.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-7.2 openldap-2.3.30-1.1.fc7 perl-5.8.8-12.fc7 perl-PDL-2.4.3-1.fc7 php-pear-1.4.11-2 ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 rhdb-utils-8.1.1-1.2.2 scim-anthy-1.2.2-1.fc7 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 syslinux-3.31-2 systemtap-0.5.10-1.fc7 tetex-3.0-35.fc7 tomcat5-5.5.17-6jpp.2 valgrind-3.2.1-7 velocity-1.4-6jpp.1 w3m-0.5.1-15.fc6 xen-3.0.4-4.fc7 xferstats-2.16-14.1 With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Sat Feb 3 14:10:18 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 3 Feb 2007 08:10:18 -0600 Subject: Core i386 rawhide rebuild in mock status 2007-02-03 Message-ID: <20070203081018.A1201@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for i386 Sat Feb 3 07:33:03 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1158 Number failed to build: 59 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 50 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 50 ---------------------------------- amanda-2.5.0p2-4 anthy-7900-2.fc6 automake16-1.6.3-8 automake17-1.7.9-7 castor-0.9.5-1jpp.7 cscope-15.5-15.2..fc7 g-wrap-1.9.6-7.1 gdb-6.6-2.fc7 gmime-2.2.3-3.fc6 gnome-sharp-2.16.0-1.fc6 gnucash-2.0.4-1.fc6 grub-0.97-13 icon-naming-utils-0.8.1-1.fc6 jgroups-2.2.9.2-3jpp.2 junit-3.8.2-3jpp.1 kasumi-2.0.1-1.1.fc6 kdeadmin-3.5.5-0.1.fc6 kdeartwork-3.5.5-0.1.fc6 kdegames-3.5.6-0.1.fc6 kdegraphics-3.5.5-0.1.fc6 kdemultimedia-3.5.6-0.1.fc6 kdenetwork-3.5.5-0.1.fc6 kdesdk-3.5.6-0.1.fc6 kdevelop-3.3.5-0.1.fc6 kdewebdev-3.5.5-0.1.fc6 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libdhcp-1.19-3.fc7 libgssapi-0.10-1 linux-atm-2.5.0-1.20050118cvs mikmod-3.1.6-39.fc7 mysql-5.0.27-1.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-7.2 openldap-2.3.30-1.1.fc7 perl-5.8.8-12.fc7 php-pear-1.4.11-2 ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 rhdb-utils-8.1.1-1.2.2 scim-anthy-1.2.2-1.fc7 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 systemtap-0.5.10-1.fc7 tetex-3.0-35.fc7 tomcat5-5.5.17-6jpp.2 velocity-1.4-6jpp.1 w3m-0.5.1-15.fc6 xferstats-2.16-14.1 With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Sat Feb 3 14:10:30 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 3 Feb 2007 08:10:30 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-03 Message-ID: <20070203081030.A1216@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Sat Feb 3 07:41:25 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2568 Number failed to build: 82 Number expected to fail due to ExclusiveArch or ExcludeArch: 19 Leaving: 63 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 63 ---------------------------------- PyKDE-3.16.0-5.fc7 rdieter at math.unl.edu R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de amarok-1.4.4-5.fc7 gauret at free.fr atitvout-0.4-6 andreas.bierfert at lowlatency.de banshee-0.10.12-4.fc6 caillon at redhat.com comix-3.6.2-2.fc7 mtasaka at ioa.s.u-tokyo.ac.jp compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com daap-sharp-0.3.3-4.fc6 bdpepple at ameritech.net darcs-1.0.8-4.fc7 petersen at redhat.com djvulibre-3.5.17-2.fc6 matthias at rpmforge.net em8300-kmod-0.16.0-5.2.6.18_1.2869.fc6 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gforth-0.6.2-7.fc6 gemi at bluewin.ch gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnucap-0.34-3.fc6 j.w.r.degoede at hhs.nl gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gpgme-1.1.2-6.fc6.1 rdieter at math.unl.edu gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kdemultimedia-extras-3.5.5-0.3.fc7 rdieter at math.unl.edu kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kpolynome-0.1.2-7.fc6 cgoorah at yahoo.com.au kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libreadline-java-0.8.0-13.fc6 ifoox at redhat.com mlton-20061107-2.fc7 adam at spicenitz.org monodevelop-0.12-7.fc7 paul at all-the-johnsons.co.uk nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.1.6-1.fc6 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org powerman-1.0.24-3.fc6 jwilson at redhat.com prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.7-2.fc6 jamatos at fc.up.pt python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com python-reportlab-2.0-2.fc7 bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com rawstudio-0.4.1-2.fc6 giallu at gmail.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de tellico-1.2.6-1.fc7 jamatos at fc.up.pt toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Sat Feb 3 14:11:00 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 3 Feb 2007 08:11:00 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-02-03 Message-ID: <20070203081100.A1236@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Sat Feb 3 07:46:52 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2568 Number failed to build: 58 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 56 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 56 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de amarok-1.4.4-5.fc7 gauret at free.fr banshee-0.10.12-4.fc6 caillon at redhat.com comix-3.6.2-2.fc7 mtasaka at ioa.s.u-tokyo.ac.jp compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com darcs-1.0.8-4.fc7 petersen at redhat.com djvulibre-3.5.17-2.fc6 matthias at rpmforge.net em8300-kmod-0.16.0-5.2.6.18_1.2869.fc6 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gforth-0.6.2-7.fc6 gemi at bluewin.ch gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnucap-0.34-3.fc6 j.w.r.degoede at hhs.nl gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gpgme-1.1.2-6.fc6.1 rdieter at math.unl.edu gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kdemultimedia-extras-3.5.5-0.3.fc7 rdieter at math.unl.edu kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kpolynome-0.1.2-7.fc6 cgoorah at yahoo.com.au kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libreadline-java-0.8.0-13.fc6 ifoox at redhat.com lighttpd-1.4.13-5.fc7 matthias at rpmforge.net nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.1.6-1.fc6 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org powerman-1.0.24-3.fc6 jwilson at redhat.com python-amara-1.1.7-2.fc6 jamatos at fc.up.pt python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com rawstudio-0.4.1-2.fc6 giallu at gmail.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.19_1.2917.fc7 giallu at gmail.com tellico-1.2.6-1.fc7 jamatos at fc.up.pt toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 gauret at free.fr Sat Feb 3 14:18:48 2007 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 03 Feb 2007 15:18:48 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project References: <45BE11A9.7080702@redhat.com> <45BF7ED2.7070002@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > Nice. But well: It sound like yet-another-hardware-compatibility-list to > me. Thus I'm wondering: Don't we have enough of those already? Agreed. > Or wait, let's do it even better: Try to work together with all of those > those and solve the problem once and for all *properly* and in a general > way? Read that as: cooperate with at least Novell/Opensuse, Debian and > Ubuntu and maybe get OSDL ^w TLF on board (from the start of). That would be awesome. So many people are waiting for such a list. How about something linked with Smolt ? You report your hardware with Smolt, it takes you to a webpage where you have a table with all your hardware, and 3 checkboxes for each component : Works, Works partially, Does not work. If that sounds good, Smolt could then be ported to other distros, and the results of each could be aggregated on a single authoritative website. I for one would love to see something like that. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr There are only 10 types of people in the world : those who understand binary and those who don't. From sander at hoentjen.eu Sat Feb 3 15:41:07 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Sat, 03 Feb 2007 16:41:07 +0100 Subject: dhcp client acting strangely Message-ID: <1170517268.8636.5.camel@peecee.hoentjen.eu> Hi, I am not sure if this is a user error or not, but here it goes: I just switched ISP's, and got a new modem/router. I plugged it in, and it has a dhcp server that i wanted to use. It doesn't work for some reason however. I then plugged in my old router, and internet worked again. I tried the new one again, that didn't work again. Going back to the old one now also failed. Setting the ip to a static address fixes things. Wireshark shows me that the routers indeed send a DHCPOFFER, but my client doesn't seem to react to that. Is this a bug somewhere or am I doing something stupid? Sander From dcantrell at redhat.com Sat Feb 3 16:08:56 2007 From: dcantrell at redhat.com (David Cantrell) Date: Sat, 03 Feb 2007 11:08:56 -0500 Subject: dhcp client acting strangely In-Reply-To: <1170517268.8636.5.camel@peecee.hoentjen.eu> References: <1170517268.8636.5.camel@peecee.hoentjen.eu> Message-ID: <1170518936.6828.5.camel@mortise.boston.redhat.com> On Sat, 2007-02-03 at 16:41 +0100, Sander Hoentjen wrote: > I am not sure if this is a user error or not, but here it goes: > I just switched ISP's, and got a new modem/router. I plugged it in, and > it has a dhcp server that i wanted to use. It doesn't work for some > reason however. I then plugged in my old router, and internet worked > again. I tried the new one again, that didn't work again. Going back to > the old one now also failed. Setting the ip to a static address fixes > things. > Wireshark shows me that the routers indeed send a DHCPOFFER, but my > client doesn't seem to react to that. > Is this a bug somewhere or am I doing something stupid? I don't think so. This happened to me at FUDcon yesterday while working on the dhcp packages. dhclient just completely stopped working. What finally made it work again? setenforce 0 But I'm not sure why this has never happened before. Trying to get to the bottom of this. -- David Cantrell Red Hat / Westford, MA -------------- 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 michel.salim at gmail.com Sat Feb 3 16:10:36 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 3 Feb 2007 11:10:36 -0500 Subject: Failed instalation of Fedora 7t1 on a MacBook Pro In-Reply-To: <001501c7469b$61037440$4101a8c0@xps> References: <001501c7469b$61037440$4101a8c0@xps> Message-ID: <883cfe6d0702030810r1dc9c247s3d79316a101f9387@mail.gmail.com> 2007/2/2, Chris Chabot : > > > > However my efferts were twarted, by a instalation screen that doesn't > recognise my keyboard, and a 60 second timeout that seems to take forever, > and doesn't fire after 60 seconds :-) > The timer does not count down on my machine either, so that at least is not MBP-specific. > > Any advice on how to get around this? > If you plug in a USB keyboard, does the MBP's firmware allow you to use it during boot? (Probably not) -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From michel.salim at gmail.com Sat Feb 3 16:13:16 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 3 Feb 2007 11:13:16 -0500 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <20070128000656.GW3639@zoidtechnologies.com> References: <45BBE897.9030802@andrei.myip.org> <20070128000656.GW3639@zoidtechnologies.com> Message-ID: <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> 2007/1/27, jam at zoidtechnologies.com : > On Sat, Jan 27, 2007 at 04:04:39PM -0800, Florin Andrei wrote: > > So, what it the rationale for /etc/init.d not being in the default > > $PATH, for root at least? > > > > I've never had to execute anything directly in /etc/init.d/ -- there is the > "service" command that runs those files for me, at least in fedora. you can > always modify $PATH by dropping a file into /etc/profile.d/ if you *really* > want this sort of thing to be possible. I would not want to see it in fedora > though. > It'll be nice if command-completion in bash and zsh can provide the list of available services .. otherwise, using zsh, there are ease-of-use arguments for having init.d in $PATH -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From sander at hoentjen.eu Sat Feb 3 16:21:38 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Sat, 03 Feb 2007 17:21:38 +0100 Subject: dhcp client acting strangely In-Reply-To: <1170518936.6828.5.camel@mortise.boston.redhat.com> References: <1170517268.8636.5.camel@peecee.hoentjen.eu> <1170518936.6828.5.camel@mortise.boston.redhat.com> Message-ID: <1170519698.7106.1.camel@peecee.hoentjen.eu> On Sat, 2007-02-03 at 11:08 -0500, David Cantrell wrote: > On Sat, 2007-02-03 at 16:41 +0100, Sander Hoentjen wrote: > > I am not sure if this is a user error or not, but here it goes: > > I just switched ISP's, and got a new modem/router. I plugged it in, and > > it has a dhcp server that i wanted to use. It doesn't work for some > > reason however. I then plugged in my old router, and internet worked > > again. I tried the new one again, that didn't work again. Going back to > > the old one now also failed. Setting the ip to a static address fixes > > things. > > Wireshark shows me that the routers indeed send a DHCPOFFER, but my > > client doesn't seem to react to that. > > Is this a bug somewhere or am I doing something stupid? > > I don't think so. This happened to me at FUDcon yesterday while working > on the dhcp packages. dhclient just completely stopped working. What > finally made it work again? > > setenforce 0 > > But I'm not sure why this has never happened before. Trying to get to > the bottom of this. > Humm.. # getenforce Permissive So I am already running with selinux disabled So it must be something different Sander From tmus at tmus.dk Sat Feb 3 15:47:02 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 03 Feb 2007 16:47:02 +0100 Subject: Default MTA for Fedora 7 Message-ID: I noticed that Exim is being installed as the default MTA, at least on the Desktop installation of Fedora 7 test1. Is this change intentional? I can't seem to find it mentioned anywhere?!? Thanks in advance /Thomas From notting at redhat.com Sat Feb 3 17:04:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 12:04:31 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: References: Message-ID: <20070203170431.GA5658@nostromo.devel.redhat.com> Thomas M Steenholdt (tmus at tmus.dk) said: > I noticed that Exim is being installed as the default MTA, at least on > the Desktop installation of Fedora 7 test1. Is this change intentional? Not exactly. It's how the dependencies got fulfilled. Bill From fedora at camperquake.de Sat Feb 3 17:57:29 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 3 Feb 2007 18:57:29 +0100 Subject: dhcp client acting strangely In-Reply-To: <1170519698.7106.1.camel@peecee.hoentjen.eu> References: <1170517268.8636.5.camel@peecee.hoentjen.eu> <1170518936.6828.5.camel@mortise.boston.redhat.com> <1170519698.7106.1.camel@peecee.hoentjen.eu> Message-ID: <20070203185729.4526e6ae@lain.camperquake.de> Hi. On Sat, 03 Feb 2007 17:21:38 +0100, Sander Hoentjen wrote > Humm.. > # getenforce > Permissive > So I am already running with selinux disabled Same here. selinux on permissive, dhclient just ignores the DHCP offers. No AVC messages in the log files, either. From dcantrell at redhat.com Sat Feb 3 18:07:42 2007 From: dcantrell at redhat.com (David Cantrell) Date: Sat, 03 Feb 2007 13:07:42 -0500 Subject: dhcp client acting strangely In-Reply-To: <20070203185729.4526e6ae@lain.camperquake.de> References: <1170517268.8636.5.camel@peecee.hoentjen.eu> <1170518936.6828.5.camel@mortise.boston.redhat.com> <1170519698.7106.1.camel@peecee.hoentjen.eu> <20070203185729.4526e6ae@lain.camperquake.de> Message-ID: <1170526062.6828.15.camel@mortise.boston.redhat.com> On Sat, 2007-02-03 at 18:57 +0100, Ralf Ertzinger wrote: > Hi. > > On Sat, 03 Feb 2007 17:21:38 +0100, Sander Hoentjen wrote > > > Humm.. > > # getenforce > > Permissive > > So I am already running with selinux disabled > > Same here. selinux on permissive, dhclient just ignores the DHCP > offers. No AVC messages in the log files, either. Also interesting. OK, so Permissive mode on FC-6 lets the new dhclient work, but on rawhide, no deal. Can someone file a bug so I can track this? Thanks, -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Sat Feb 3 19:00:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 03 Feb 2007 19:00:46 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203170431.GA5658@nostromo.devel.redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> Message-ID: <1170529246.29759.571.camel@pmac.infradead.org> On Sat, 2007-02-03 at 12:04 -0500, Bill Nottingham wrote: > Thomas M Steenholdt (tmus at tmus.dk) said: > > I noticed that Exim is being installed as the default MTA, at least on > > the Desktop installation of Fedora 7 test1. Is this change intentional? > > Not exactly. It's how the dependencies got fulfilled. It's probably a good thing though -- it _is_ a better choice because it's much easier to deal with and much more versatile than the other options; _especially_ than sendmail :) It's ironic though that the installer manages dependencies like that but not some, erm..., more basic ones... [root at net2-100 ~]# passwd dwmw2 passwd: error while loading shared libraries: libuser.so.1: cannot open shared object file: No such file or directory -- dwmw2 From jkeating at redhat.com Sat Feb 3 19:37:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 14:37:14 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170529246.29759.571.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> Message-ID: <200702031437.17431.jkeating@redhat.com> On Saturday 03 February 2007 14:00, David Woodhouse wrote: > It's ironic though that the installer manages dependencies like that but > not some, erm..., more basic ones... > > [root at net2-100 ~]# passwd dwmw2 > passwd: error while loading shared libraries: libuser.so.1: cannot open > shared object file: No such file or directory Sounds like one of the packages has a bad/missing Requires then, or the soname was bumped but passwd wasn't rebuilt, or something like that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernd.bartmann at gmail.com Sat Feb 3 19:46:21 2007 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Sat, 3 Feb 2007 20:46:21 +0100 Subject: FC7T1 and Bugzilla product / version Message-ID: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> Hi, against which product and version bugs for FC7T1 should be filed? In bugzilla.redhat.com one can find product "Fedora Core" and versions up to "fc6", but no "fc7test1". Also, as there is no more "Fedora Core" but only "Fedora" will the product then be "Fedora" and the version "f7test1"? Anyway neither do exist yet. Best regards, Bernd. From jkeating at redhat.com Sat Feb 3 19:53:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 14:53:21 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> Message-ID: <200702031453.21547.jkeating@redhat.com> On Saturday 03 February 2007 14:46, Bernd Bartmann wrote: > against which product and version bugs for FC7T1 should be filed? In > bugzilla.redhat.com one can find product "Fedora Core" and versions up > to "fc6", but no "fc7test1". Also, as there is no more "Fedora Core" > but only "Fedora" will the product then be "Fedora" and the version > "f7test1"? Anyway neither do exist yet. This is an excellent question for Will to answer. I think he gets the pleasure of defining how we setup the bugzilla for our new Fedora. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jfrieben at gmx.de Sat Feb 3 20:12:20 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sat, 03 Feb 2007 21:12:20 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: References: Message-ID: <20070203201220.106390@gmx.net> > I noticed that Exim is being installed as the default MTA, at least on > the Desktop installation of Fedora 7 test1. Is this change intentional? > I can't seem to find it mentioned anywhere?!? > > Thanks in advance > > /Thomas I had posted a related bug report back in December 2006 because of "yum" pulling in "exim" from "FE" in order to resolve a dependency on "/usr/sbin/sendmail" when installing "mutt" at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219920 . The bug got closed by J. Katz after classification as "NOTABUG". The argument was that the "sendmail" command is provided by several packages in "FC/FE" without particular ranking and "exim" simply seems to win by alphabetical order compared to "postfix" or "sendmail" .. :-/ -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From notting at redhat.com Sat Feb 3 20:12:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 15:12:39 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203201220.106390@gmx.net> References: <20070203201220.106390@gmx.net> Message-ID: <20070203201239.GA7111@nostromo.devel.redhat.com> Joachim Frieben (jfrieben at gmx.de) said: > The bug got closed by J. Katz after classification as "NOTABUG". The argument > was that the "sendmail" command is provided by several packages in "FC/FE" > without particular ranking and "exim" simply seems to win by alphabetical > order compared to "postfix" or "sendmail" .. :-/ Shortest name, not alphabetical. Bill From david at lovesunix.net Sat Feb 3 20:34:01 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 03 Feb 2007 21:34:01 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: References: Message-ID: <1170534841.3775.0.camel@dawkins> l?r, 03 02 2007 kl. 16:47 +0100, skrev Thomas M Steenholdt: > I noticed that Exim is being installed as the default MTA, at least on > the Desktop installation of Fedora 7 test1. Is this change intentional? > I can't seem to find it mentioned anywhere?!? What in a desktop install could possibly require an MTA.. it seems a bit daft to me. - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 gmx.de Sat Feb 3 20:37:11 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sat, 03 Feb 2007 21:37:11 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <1170534841.3775.0.camel@dawkins> References: <1170534841.3775.0.camel@dawkins> Message-ID: <20070203203711.153900@gmx.net> > What in a desktop install could possibly require an MTA.. it seems a bit > daft to me. > > - David Well, as mentioned earlier, "mutt" does, and this is certainly not a server application .. -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail?ac=OM.GX.GX003K11711T4781a From jkeating at redhat.com Sat Feb 3 20:38:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 15:38:35 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203201220.106390@gmx.net> References: <20070203201220.106390@gmx.net> Message-ID: <200702031538.35270.jkeating@redhat.com> On Saturday 03 February 2007 15:12, Joachim Frieben wrote: > The bug got closed by J. Katz after classification as "NOTABUG". The > argument was that the "sendmail" command is provided by several packages in > "FC/FE" without particular ranking and "exim" simply seems to win by > alphabetical order compared to "postfix" or "sendmail" .. :-/ Do you have any other suggestions on how to programattically decide what choice out of many options you'd use to satisfy a dep? fooz barz billy go All of these virtually provide /usr/bin/whizbang and use alternatives to handle this. bingo requires /usr/bin/whizbang, and doesn't care which one. What way to you decide which to grab? Currently yum does a sort of all that provide /usr/bin/whizbang and picks the one at the top. Shorter names sort before longer ones, so in this case, 'go' wins. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Feb 3 20:39:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 15:39:12 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203201239.GA7111@nostromo.devel.redhat.com> References: <20070203201220.106390@gmx.net> <20070203201239.GA7111@nostromo.devel.redhat.com> Message-ID: <200702031539.13032.jkeating@redhat.com> On Saturday 03 February 2007 15:12, Bill Nottingham wrote: > Shortest name, not alphabetical. Well, if there were another mailer with the same length of exim, then alphabetical would win. It's just a sort. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Sat Feb 3 20:40:50 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 3 Feb 2007 14:40:50 -0600 Subject: Default MTA for Fedora 7 In-Reply-To: <1170534841.3775.0.camel@dawkins> References: <1170534841.3775.0.camel@dawkins> Message-ID: <20070203204050.GB634026@hiwaay.net> Once upon a time, David Nielsen said: > What in a desktop install could possibly require an MTA.. it seems a bit > daft to me. Like it or not, /usr/sbin/sendmail (and still /usr/lib/sendmail) are the "standard" ways to send an email on a Unix-like system. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Sat Feb 3 20:48:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 15:48:39 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031538.35270.jkeating@redhat.com> References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> Message-ID: <20070203204839.GA7379@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > All of these virtually provide /usr/bin/whizbang and use alternatives to > handle this. Parse the alternatives %post calls and use the priorities. (No, I'm not serious.) Bill From jfrieben at gmx.de Sat Feb 3 20:52:07 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sat, 03 Feb 2007 21:52:07 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031538.35270.jkeating@redhat.com> References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> Message-ID: <20070203205207.153880@gmx.net> > Do you have any other suggestions on how to programattically decide what > choice out of many options you'd use to satisfy a dep? > > fooz > barz > billy > go > > All of these virtually provide /usr/bin/whizbang and use alternatives to > handle this. > > bingo requires /usr/bin/whizbang, and doesn't care which one. What way to > you > decide which to grab? Currently yum does a sort of all that > provide /usr/bin/whizbang and picks the one at the top. Shorter names > sort > before longer ones, so in this case, 'go' wins. > > -- > Jesse Keating > Release Engineer: Fedora One possibility would be to prompt the user, once alternative package choices appear and to let him pick one of them. Btw, at the time I had posted my bug report, "Extras" and "Core" were disjoint entities, and I was surprised/annoyed that a package from "Extras" got installed when there were equivalent packages available in "Core". So , in this case, I would have expected "Core" to have priority over "Extras" which appears rather reasonable to me. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From smooge at gmail.com Sat Feb 3 20:53:44 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 3 Feb 2007 13:53:44 -0700 Subject: Default MTA for Fedora 7 In-Reply-To: <1170529246.29759.571.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> Message-ID: <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> On 2/3/07, David Woodhouse wrote: > On Sat, 2007-02-03 at 12:04 -0500, Bill Nottingham wrote: > > Thomas M Steenholdt (tmus at tmus.dk) said: > > > I noticed that Exim is being installed as the default MTA, at least on > > > the Desktop installation of Fedora 7 test1. Is this change intentional? > > > > Not exactly. It's how the dependencies got fulfilled. > > It's probably a good thing though -- it _is_ a better choice because > it's much easier to deal with and much more versatile than the other > options; _especially_ than sendmail :) > No its better because you like it more. I think you have been pushing for this since at least 1999 (2000 for sure). Me I would like postfix :) -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Sat Feb 3 20:57:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 15:57:45 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203205207.153880@gmx.net> References: <200702031538.35270.jkeating@redhat.com> <20070203205207.153880@gmx.net> Message-ID: <200702031557.45767.jkeating@redhat.com> On Saturday 03 February 2007 15:52, Joachim Frieben wrote: > One possibility would be to prompt the user, once alternative package > choices appear and to let him pick one of them. Yum/rpm transactions need to happen noninteractively. Think Kickstart. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Sat Feb 3 20:59:15 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 03 Feb 2007 14:59:15 -0600 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> References: <45BBE897.9030802@andrei.myip.org> <20070128000656.GW3639@zoidtechnologies.com> <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> Message-ID: <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> On Sat, 2007-02-03 at 11:13 -0500, Michel Salim wrote: > > It'll be nice if command-completion in bash and zsh can provide the > list of available services .. otherwise, using zsh, there are > ease-of-use arguments for having init.d in $PATH If you install bash-completion and then type "service TAB" it will show you a list of all of the services. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat Feb 3 21:00:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 16:00:39 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170534841.3775.0.camel@dawkins> References: <1170534841.3775.0.camel@dawkins> Message-ID: <200702031600.39508.jkeating@redhat.com> On Saturday 03 February 2007 15:34, David Nielsen wrote: > What in a desktop install could possibly require an MTA.. it seems a bit > daft to me. mdadm. Some desktops do have software raid. fetchmail. Some desktops do read email. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mitr at volny.cz Sat Feb 3 21:04:21 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 03 Feb 2007 22:04:21 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031600.39508.jkeating@redhat.com> References: <1170534841.3775.0.camel@dawkins> <200702031600.39508.jkeating@redhat.com> Message-ID: <45C4F8D5.9010900@volny.cz> Jesse Keating napsal(a): > On Saturday 03 February 2007 15:34, David Nielsen wrote: >> What in a desktop install could possibly require an MTA.. it seems a bit >> daft to me. > fetchmail. Some desktops do read email. Desktops use a GUI mail client, though. Another example: cron requires /usr/sbin/sendmail, and even a desktop machine needs cron. Mirek From bernd.bartmann at gmail.com Sat Feb 3 21:08:54 2007 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Sat, 3 Feb 2007 22:08:54 +0100 Subject: Cryptic filenames in / of FC7T1 Message-ID: <6c18a4f0702031308l2b8bd353kd755ad8cfcc46ada@mail.gmail.com> Hi, I've found some cryptic named files in under / in FC7T1: a-7QeJ HXv5pB xI6TYx Zgu_vF All files are 4 bytes long and contain "blat". Where do they come from? Best regards, Bernd. From laroche at redhat.com Sat Feb 3 21:09:48 2007 From: laroche at redhat.com (Florian La Roche) Date: Sat, 3 Feb 2007 22:09:48 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031538.35270.jkeating@redhat.com> References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> Message-ID: <20070203210948.GA21580@dudweiler.stuttgart.redhat.com> On Sat, Feb 03, 2007 at 03:38:35PM -0500, Jesse Keating wrote: > On Saturday 03 February 2007 15:12, Joachim Frieben wrote: > > The bug got closed by J. Katz after classification as "NOTABUG". The > > argument was that the "sendmail" command is provided by several packages in > > "FC/FE" without particular ranking and "exim" simply seems to win by > > alphabetical order compared to "postfix" or "sendmail" .. :-/ > > Do you have any other suggestions on how to programattically decide what > choice out of many options you'd use to satisfy a dep? > > fooz > barz > billy > go > > All of these virtually provide /usr/bin/whizbang and use alternatives to > handle this. > > bingo requires /usr/bin/whizbang, and doesn't care which one. What way to you > decide which to grab? Currently yum does a sort of all that > provide /usr/bin/whizbang and picks the one at the top. Shorter names sort > before longer ones, so in this case, 'go' wins. The "shorter wins" makes sure we have a defined way. But for yum one even better way of doing this might be to also check the comps file. If one of the choices is mentioned there, then only use that one instead of the above ranking. This of course also means you'd have to mention sendmail in the comps/selection file. regards, Florian La Roche From jfrieben at gmx.de Sat Feb 3 21:11:22 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sat, 03 Feb 2007 22:11:22 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031557.45767.jkeating@redhat.com> References: <200702031538.35270.jkeating@redhat.com> <20070203205207.153880@gmx.net> <200702031557.45767.jkeating@redhat.com> Message-ID: <20070203211122.311630@gmx.net> > Yum/rpm transactions need to happen noninteractively. Think Kickstart. > > -- > Jesse Keating > Release Engineer: Fedora Think "expect"? -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail?ac=OM.GX.GX003K11711T4781a From jkeating at redhat.com Sat Feb 3 21:15:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 16:15:03 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203211122.311630@gmx.net> References: <200702031557.45767.jkeating@redhat.com> <20070203211122.311630@gmx.net> Message-ID: <200702031615.03605.jkeating@redhat.com> On Saturday 03 February 2007 16:11, Joachim Frieben wrote: > Think "expect"? You don't know how many people in the room just uttered disgusted sounds when I read this response out loud. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Feb 3 21:17:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 16:17:13 -0500 Subject: Cryptic filenames in / of FC7T1 In-Reply-To: <6c18a4f0702031308l2b8bd353kd755ad8cfcc46ada@mail.gmail.com> References: <6c18a4f0702031308l2b8bd353kd755ad8cfcc46ada@mail.gmail.com> Message-ID: <200702031617.14015.jkeating@redhat.com> On Saturday 03 February 2007 16:08, Bernd Bartmann wrote: > I've found some cryptic named files in under / in FC7T1: > > a-7QeJ > HXv5pB > xI6TYx > Zgu_vF > > All files are 4 bytes long and contain "blat". Where do they come from? So... this doesn't sound so good. Are they in / or in a subdirectory. Who owns the files? What are the timestamps on the files? When was the last time you walked away while logged in? Are you still connected to the network? Have you seen a jump in your traffic? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Sat Feb 3 21:26:47 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 03 Feb 2007 21:26:47 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031437.17431.jkeating@redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <200702031437.17431.jkeating@redhat.com> Message-ID: <1170538007.29759.577.camel@pmac.infradead.org> On Sat, 2007-02-03 at 14:37 -0500, Jesse Keating wrote: > Sounds like one of the packages has a bad/missing Requires then, or > the soname was bumped but passwd wasn't rebuilt, or something like > that. No, almost all 64-bit libraries seem to be missing, although the dependencies are correct -- rpm gets it right (see below) but the installer didn't. Bug 226956. [root at net2-100 ~]# rpm -e passwd.ppc64 [root at net2-100 ~]# rpm -Uhv /fish/redhat/rawhide-ppc/Fedora/RPMS/passwd-0.74-2.ppc64.rpm error: Failed dependencies: libaudit.so.0()(64bit) is needed by passwd-0.74-2.ppc64 libglib-2.0.so.0()(64bit) is needed by passwd-0.74-2.ppc64 libgmodule-2.0.so.0()(64bit) is needed by passwd-0.74-2.ppc64 libgobject-2.0.so.0()(64bit) is needed by passwd-0.74-2.ppc64 libpam.so.0()(64bit) is needed by passwd-0.74-2.ppc64 libpam.so.0(LIBPAM_1.0)(64bit) is needed by passwd-0.74-2.ppc64 libpam_misc.so.0()(64bit) is needed by passwd-0.74-2.ppc64 libpam_misc.so.0(LIBPAM_MISC_1.0)(64bit) is needed by passwd-0.74-2.ppc64 libpopt.so.0()(64bit) is needed by passwd-0.74-2.ppc64 libselinux.so.1()(64bit) is needed by passwd-0.74-2.ppc64 libuser.so.1()(64bit) is needed by passwd-0.74-2.ppc64 -- dwmw2 From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 3 21:28:13 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 03 Feb 2007 22:28:13 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031538.35270.jkeating@redhat.com> (Jesse Keating's message of "Sat, 3 Feb 2007 15:38:35 -0500") References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> Message-ID: <87odobx76a.fsf@kosh.bigo.ensc.de> jkeating at redhat.com (Jesse Keating) writes: > Do you have any other suggestions on how to programattically decide > what choice out of many options you'd use to satisfy a dep? Abort transaction when it is ambiguous (kickstart) or ask the user which alternative he wants (interactive anaconda). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jfrieben at gmx.de Sat Feb 3 21:28:54 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sat, 03 Feb 2007 22:28:54 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031615.03605.jkeating@redhat.com> References: <200702031557.45767.jkeating@redhat.com> <20070203211122.311630@gmx.net> <200702031615.03605.jkeating@redhat.com> Message-ID: <20070203212854.295110@gmx.net> > You don't know how many people in the room just uttered disgusted sounds > when > I read this response out loud. > > -- > Jesse Keating > Release Engineer: Fedora No need to get sarcastic. I mentioned "expect" only as an example, and it's not even required: already now, the -interactive- user input during an "anaconda" install procedure is processed in order to produce a valid kickstart file for later use. I do not see any fundamental difference in this respect. If packages can be selected by the user at will at install time, why not prompt him in case of anbiguities when the dependencies get processed? Once the final package selection has been established, it can be retained for the kickstart file, and for later automated installs, this question does not even need to be asked again, ... right? -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 3 21:30:04 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 03 Feb 2007 22:30:04 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203203711.153900@gmx.net> (Joachim Frieben's message of "Sat, 03 Feb 2007 21:37:11 +0100") References: <1170534841.3775.0.camel@dawkins> <20070203203711.153900@gmx.net> Message-ID: <87k5yzx737.fsf@kosh.bigo.ensc.de> jfrieben at gmx.de ("Joachim Frieben") writes: >> What in a desktop install could possibly require an MTA.. it seems a >> bit daft to me. > > Well, as mentioned earlier, "mutt" does, and this is certainly not a > server application .. That's a packaging bug. 'mutt' requires a program with a sendmail compatible CLI, but not an MTA. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From bernd.bartmann at gmail.com Sat Feb 3 21:30:39 2007 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Sat, 3 Feb 2007 22:30:39 +0100 Subject: Cryptic filenames in / of FC7T1 In-Reply-To: <200702031617.14015.jkeating@redhat.com> References: <6c18a4f0702031308l2b8bd353kd755ad8cfcc46ada@mail.gmail.com> <200702031617.14015.jkeating@redhat.com> Message-ID: <6c18a4f0702031330l4fcf1d42gd3ad5979993a930@mail.gmail.com> On 2/3/07, Jesse Keating wrote: > On Saturday 03 February 2007 16:08, Bernd Bartmann wrote: > > I've found some cryptic named files in under / in FC7T1: > > > > a-7QeJ > > HXv5pB > > xI6TYx > > Zgu_vF > > > > All files are 4 bytes long and contain "blat". Where do they come from? > > So... this doesn't sound so good. > > Are they in / or in a subdirectory. They are directly under /. > Who owns the files? > > What are the timestamps on the files? -rw------- 1 root root 4 3. Feb 20:49 a-7QeJ -rw------- 1 root root 4 3. Feb 22:22 h6fs6y -rw------- 1 root root 4 3. Feb 22:22 HOB-pX -rw------- 1 root root 4 3. Feb 21:01 HXv5pB -rw------- 1 root root 4 3. Feb 21:01 xI6TYx -rw------- 1 root root 4 3. Feb 20:49 Zgu_vF > When was the last time you walked away while logged in? > Are you still connected to the network? > Have you seen a jump in your traffic? Your question seems to suggest some kind of malware!? This is certainly not the case. I more suspect some of the init scripts redirecting output where it shouldn't. The system is a freshly installed FC7T1 + some reboots. No one besides myself has access to the system. Best regards, Bernd. From jkeating at redhat.com Sat Feb 3 21:32:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 16:32:04 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <45C4F8D5.9010900@volny.cz> References: <200702031600.39508.jkeating@redhat.com> <45C4F8D5.9010900@volny.cz> Message-ID: <200702031632.04362.jkeating@redhat.com> On Saturday 03 February 2007 16:04, Miloslav Trmac wrote: > > fetchmail. ?Some desktops do read email. > > Desktops use a GUI mail client, though. fetchmail is a method to fetch mail from remote places and deliver it locally, which can then be viewed with a gui client or a nongui client. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Sat Feb 3 21:37:05 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 03 Feb 2007 21:37:05 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> Message-ID: <1170538625.29759.583.camel@pmac.infradead.org> On Sat, 2007-02-03 at 13:53 -0700, Stephen John Smoogen wrote: > No its better because you like it more. I think you have been pushing > for this since at least 1999 (2000 for sure). > > Me I would like postfix :) Were you one of the postfix people who disappeared into the background around the time of FC4 when I was looking for someone to show me if/how postfix could achieve the stuff I currently do with Exim? You weren't the one who eventually _admitted_ to giving up, and said "I think I'll switch to Exim"; that was someone else, right? The others just went quiet. -- dwmw2 From wwoods at redhat.com Sat Feb 3 21:42:57 2007 From: wwoods at redhat.com (Will Woods) Date: Sat, 03 Feb 2007 16:42:57 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <200702031453.21547.jkeating@redhat.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> Message-ID: <1170538978.6858.21.camel@localhost.localdomain> On Sat, 2007-02-03 at 14:53 -0500, Jesse Keating wrote: > On Saturday 03 February 2007 14:46, Bernd Bartmann wrote: > > against which product and version bugs for FC7T1 should be filed? In > > bugzilla.redhat.com one can find product "Fedora Core" and versions up > > to "fc6", but no "fc7test1". Also, as there is no more "Fedora Core" > > but only "Fedora" will the product then be "Fedora" and the version > > "f7test1"? Anyway neither do exist yet. > > This is an excellent question for Will to answer. I think he gets the > pleasure of defining how we setup the bugzilla for our new Fedora. Hah! Yes, I suppose that most exellent joy is mine. So, we're keeping 'fc7' for the %dist tag (the .fc7 bit in package names) because it would cause problems with RPM name sorting if we changed that. But I don't think there's any tools that really require the bugzilla version for Fedora [Core|Extras|whatever] to start with 'fc'. Can anyone see any other downside to using 'f7testX' instead of 'fc7testX'? -w From jkeating at redhat.com Sat Feb 3 21:46:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 16:46:08 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203212854.295110@gmx.net> References: <200702031615.03605.jkeating@redhat.com> <20070203212854.295110@gmx.net> Message-ID: <200702031646.12311.jkeating@redhat.com> On Saturday 03 February 2007 16:28, Joachim Frieben wrote: > No need to get sarcastic. I mentioned "expect" only as an example, and it's > not even required: already now, the -interactive- user input during an > "anaconda" install procedure is processed in order to produce a valid > kickstart file for later use. I do not see any fundamental difference in > this respect. If packages can be selected by the user at will at install > time, why not prompt him in case of anbiguities when the dependencies get > processed? Once the final package selection has been established, it can be > retained for the kickstart file, and for later automated installs, this > question does not even need to be asked again, ... right? Because the only time this question comes up is _not_ the installer. And you don't use the installer to generate a kickstart file, many of us are perfectly happy creating those by hand, or porting them forward from previous releases. Look, rpm/yum transactions need to be able to be non-interactive. Period. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Feb 3 21:48:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 16:48:15 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <1170538978.6858.21.camel@localhost.localdomain> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> Message-ID: <200702031648.15855.jkeating@redhat.com> On Saturday 03 February 2007 16:42, Will Woods wrote: > Hah! Yes, I suppose that most exellent joy is mine. > > So, we're keeping 'fc7' for the %dist tag (the .fc7 bit in package > names) because it would cause problems with RPM name sorting if we > changed that. But I don't think there's any tools that really require > the bugzilla version for Fedora [Core|Extras|whatever] to start with > 'fc'. > > Can anyone see any other downside to using 'f7testX' instead of > 'fc7testX'? I don't. More interestingly, is there value in having a test1 version instead of just defaulting to devel during the development process? We wind up with a ton of bugs in both anyway, why double our search efforts? What compelling reasons do we have for pooping out new versions to file bugs against for each test release, when we most likely want each bug reporter to update to latest rawhide and try it again? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Curtis at GreenKey.net Sat Feb 3 21:48:43 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Sat, 3 Feb 2007 13:48:43 -0800 (PST) Subject: Cryptic filenames in / of FC7T1 In-Reply-To: <6c18a4f0702031308l2b8bd353kd755ad8cfcc46ada@mail.gmail.com> References: <6c18a4f0702031308l2b8bd353kd755ad8cfcc46ada@mail.gmail.com> Message-ID: <20070203214843.A00946F072@alopias.GreenKey.net> 10:08pm Bernd Bartmann said: > > I've found some cryptic named files in under / in FC7T1: > > a-7QeJ > HXv5pB > xI6TYx > Zgu_vF > > All files are 4 bytes long and contain "blat". Where do they come from? > Python does that in tempfile while looking for a tempdir. Something must be b0rk when it tries to unlink the blatness. ../C From pertusus at free.fr Sat Feb 3 21:50:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 3 Feb 2007 22:50:17 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <87k5yzx737.fsf@kosh.bigo.ensc.de> References: <1170534841.3775.0.camel@dawkins> <20070203203711.153900@gmx.net> <87k5yzx737.fsf@kosh.bigo.ensc.de> Message-ID: <20070203215017.GA22742@free.fr> On Sat, Feb 03, 2007 at 10:30:04PM +0100, Enrico Scholz wrote: > > That's a packaging bug. 'mutt' requires a program with a sendmail > compatible CLI, but not an MTA. Indeed, but a MTA also provides that. Among the candidates esmtp and ssmtp may be better suited for mutt, but both come unconfigured for local delivery. For the record here are the packages that provide a sendmail compatible CLI: sendmail-0:8.13.8-4.i386 postfix-2:2.3.6-1.i386 esmtp-0:0.5.1-13.fc6.i386 exim-0:4.63-6.fc7.i386 ssmtp-0:2.61-11.1.fc7.i386 -- Pat From naheemzaffar at gmail.com Sat Feb 3 21:59:16 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 3 Feb 2007 21:59:16 +0000 Subject: f7 test: failure in qemu In-Reply-To: References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> Message-ID: <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> I can confirm the same error on base hardware. Acer Aspire T180. From notting at redhat.com Sat Feb 3 22:02:48 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 17:02:48 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <200702031648.15855.jkeating@redhat.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> <200702031648.15855.jkeating@redhat.com> Message-ID: <20070203220248.GA8211@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > I don't. More interestingly, is there value in having a test1 version instead > of just defaulting to devel during the development process? We wind up with > a ton of bugs in both anyway, why double our search efforts? What compelling > reasons do we have for pooping out new versions to file bugs against for each > test release, when we most likely want each bug reporter to update to latest > rawhide and try it again? Requires manually shuffling the bugs to the final release later. Other than that, no real issues. Bill From jkeating at redhat.com Sat Feb 3 22:11:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 3 Feb 2007 17:11:12 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <20070203220248.GA8211@nostromo.devel.redhat.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> Message-ID: <200702031711.12227.jkeating@redhat.com> On Saturday 03 February 2007 17:02, Bill Nottingham wrote: > Requires manually shuffling the bugs to the final release later. > Other than that, no real issues. How is this any different than what we do today? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Sat Feb 3 22:09:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 17:09:39 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <200702031711.12227.jkeating@redhat.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> <200702031711.12227.jkeating@redhat.com> Message-ID: <20070203220939.GA8271@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > Requires manually shuffling the bugs to the final release later. > > Other than that, no real issues. > > How is this any different than what we do today? The fact that we never actually move the bugs over? Bill From wwoods at redhat.com Sat Feb 3 22:20:01 2007 From: wwoods at redhat.com (Will Woods) Date: Sat, 03 Feb 2007 17:20:01 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <20070203220248.GA8211@nostromo.devel.redhat.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> Message-ID: <1170541201.6858.28.camel@localhost.localdomain> On Sat, 2007-02-03 at 17:02 -0500, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > I don't. More interestingly, is there value in having a test1 version instead > > of just defaulting to devel during the development process? We wind up with > > a ton of bugs in both anyway, why double our search efforts? What compelling > > reasons do we have for pooping out new versions to file bugs against for each > > test release, when we most likely want each bug reporter to update to latest > > rawhide and try it again? > > Requires manually shuffling the bugs to the final release later. > Other than that, no real issues. Yeah, it makes sense to me. I guess the weird part will be figuring out which of the 'devel' bugs are actually against F7 and which are from older releases. -w From fedora at camperquake.de Sat Feb 3 22:20:00 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 3 Feb 2007 23:20:00 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <87odobx76a.fsf@kosh.bigo.ensc.de> References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> <87odobx76a.fsf@kosh.bigo.ensc.de> Message-ID: <20070203232000.4214d1cc@lain.camperquake.de> Hi. On Sat, 03 Feb 2007 22:28:13 +0100, Enrico Scholz wrote > Abort transaction when it is ambiguous (kickstart) Err, no. If a dependency can be satisfied in various ways then anaconda is free to choose any one of the possibilities at it's discretion in my book. If I want a certain package then I as the admin can put it into the kickstart file. From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 3 22:43:29 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 03 Feb 2007 23:43:29 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203232000.4214d1cc@lain.camperquake.de> (Ralf Ertzinger's message of "Sat, 3 Feb 2007 23:20:00 +0100") References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> <87odobx76a.fsf@kosh.bigo.ensc.de> <20070203232000.4214d1cc@lain.camperquake.de> Message-ID: <87wt2y50by.fsf@kosh.bigo.ensc.de> fedora at camperquake.de (Ralf Ertzinger) writes: >> Abort transaction when it is ambiguous (kickstart) > > Err, no. If a dependency can be satisfied in various ways then anaconda > is free to choose any one of the possibilities at it's discretion in my > book. Such a behavior is just a maintainance nightmare. 'kickstart' is used to build systems in a reproducible way. Having a clear semantic ("transactions must be always unambigous") would help to avoid bad surprises. (This works for years with 'apt'.) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From michel.salim at gmail.com Sat Feb 3 22:52:50 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 3 Feb 2007 17:52:50 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <1170541201.6858.28.camel@localhost.localdomain> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> <1170541201.6858.28.camel@localhost.localdomain> Message-ID: <883cfe6d0702031452m7ebbe0d6o8a80399bd4c2d180@mail.gmail.com> 2007/2/3, Will Woods : > On Sat, 2007-02-03 at 17:02 -0500, Bill Nottingham wrote: > > Jesse Keating (jkeating at redhat.com) said: > > > I don't. More interestingly, is there value in having a test1 version instead > > > of just defaulting to devel during the development process? We wind up with > > > a ton of bugs in both anyway, why double our search efforts? What compelling > > > reasons do we have for pooping out new versions to file bugs against for each > > > test release, when we most likely want each bug reporter to update to latest > > > rawhide and try it again? > > > > Requires manually shuffling the bugs to the final release later. > > Other than that, no real issues. > > Yeah, it makes sense to me. I guess the weird part will be figuring out > which of the 'devel' bugs are actually against F7 and which are from > older releases. > How about filing bugs against 'devel' but adding a 'f7test1' keyword to it? -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From fedora at camperquake.de Sat Feb 3 22:53:31 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 3 Feb 2007 23:53:31 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <87wt2y50by.fsf@kosh.bigo.ensc.de> References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> <87odobx76a.fsf@kosh.bigo.ensc.de> <20070203232000.4214d1cc@lain.camperquake.de> <87wt2y50by.fsf@kosh.bigo.ensc.de> Message-ID: <20070203235331.27bb6621@lain.camperquake.de> Hi. On Sat, 03 Feb 2007 23:43:29 +0100, Enrico Scholz wrote > Such a behavior is just a maintainance nightmare. 'kickstart' is used > to build systems in a reproducible way. Having a clear semantic > ("transactions must be always unambigous") would help to avoid bad > surprises. If you reproducably want sendmail then tell kickstart so instead of relying on side effects. From tmus at tmus.dk Sat Feb 3 21:59:17 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 03 Feb 2007 22:59:17 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203170431.GA5658@nostromo.devel.redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Thomas M Steenholdt (tmus at tmus.dk) said: >> I noticed that Exim is being installed as the default MTA, at least on >> the Desktop installation of Fedora 7 test1. Is this change intentional? > > Not exactly. It's how the dependencies got fulfilled. > > Bill > I just checked the contents of the DVD image, and the only MTA I can find there is Exim. I guess that's the real reason. So I guess the real question is: "If we change the Default MTA in Fedora - Which should it be?" I'm sure a lot of people will say Exim is great (i can't say, since i've never worked with it). Others will yell for Postfix, towards which i'm probably slightly biased, since that's what I currently use in most places. I'm sure yet others will have other MTA's listed as their favorite one. /Thomas From enrico.scholz at informatik.tu-chemnitz.de Sat Feb 3 23:06:03 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 04 Feb 2007 00:06:03 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203235331.27bb6621@lain.camperquake.de> (Ralf Ertzinger's message of "Sat, 3 Feb 2007 23:53:31 +0100") References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> <87odobx76a.fsf@kosh.bigo.ensc.de> <20070203232000.4214d1cc@lain.camperquake.de> <87wt2y50by.fsf@kosh.bigo.ensc.de> <20070203235331.27bb6621@lain.camperquake.de> Message-ID: <87ejp6lu3o.fsf@kosh.bigo.ensc.de> fedora at camperquake.de (Ralf Ertzinger) writes: >> Such a behavior is just a maintainance nightmare. 'kickstart' is >> used to build systems in a reproducible way. Having a clear semantic >> ("transactions must be always unambigous") would help to avoid bad >> surprises. > > If you reproducably want sendmail then tell kickstart so instead of > relying on side effects. Exactly. That's why, kickstart should abort on ambigous transactions. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From tmus at tmus.dk Sat Feb 3 23:16:40 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 04 Feb 2007 00:16:40 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031646.12311.jkeating@redhat.com> References: <200702031615.03605.jkeating@redhat.com> <20070203212854.295110@gmx.net> <200702031646.12311.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > > Look, rpm/yum transactions need to be able to be non-interactive. Period. > I agree - This is one of the places where the guys at Debian and Ubuntu has got it all wrong IMHO. /Thomas From dominik at greysector.net Sat Feb 3 22:54:33 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 3 Feb 2007 23:54:33 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> Message-ID: <20070203225433.GA7964@ryvius.pekin.waw.pl> On Saturday, 03 February 2007 at 21:53, Stephen John Smoogen wrote: > On 2/3/07, David Woodhouse wrote: > >On Sat, 2007-02-03 at 12:04 -0500, Bill Nottingham wrote: > >> Thomas M Steenholdt (tmus at tmus.dk) said: > >> > I noticed that Exim is being installed as the default MTA, at least on > >> > the Desktop installation of Fedora 7 test1. Is this change intentional? > >> > >> Not exactly. It's how the dependencies got fulfilled. > > > >It's probably a good thing though -- it _is_ a better choice because > >it's much easier to deal with and much more versatile than the other > >options; _especially_ than sendmail :) > > > > No its better because you like it more. I think you have been pushing > for this since at least 1999 (2000 for sure). > > Me I would like postfix :) +1 :) Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From fedora at camperquake.de Sat Feb 3 23:39:24 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 4 Feb 2007 00:39:24 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> Message-ID: <20070204003924.0a1febd2@lain.camperquake.de> Hi. On Sat, 3 Feb 2007 13:53:44 -0700, Stephen John Smoogen wrote > Me I would like postfix :) Simply get upstream to rename it to pfx. From lsof at nodata.co.uk Sat Feb 3 23:41:54 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 04 Feb 2007 00:41:54 +0100 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <883cfe6d0702031452m7ebbe0d6o8a80399bd4c2d180@mail.gmail.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> <1170541201.6858.28.camel@localhost.localdomain> <883cfe6d0702031452m7ebbe0d6o8a80399bd4c2d180@mail.gmail.com> Message-ID: <1170546114.9699.0.camel@sb-home.lan> Am Samstag, den 03.02.2007, 17:52 -0500 schrieb Michel Salim: > 2007/2/3, Will Woods : > > On Sat, 2007-02-03 at 17:02 -0500, Bill Nottingham wrote: > > > Jesse Keating (jkeating at redhat.com) said: > > > > I don't. More interestingly, is there value in having a test1 version instead > > > > of just defaulting to devel during the development process? We wind up with > > > > a ton of bugs in both anyway, why double our search efforts? What compelling > > > > reasons do we have for pooping out new versions to file bugs against for each > > > > test release, when we most likely want each bug reporter to update to latest > > > > rawhide and try it again? > > > > > > Requires manually shuffling the bugs to the final release later. > > > Other than that, no real issues. > > > > Yeah, it makes sense to me. I guess the weird part will be figuring out > > which of the 'devel' bugs are actually against F7 and which are from > > older releases. > > > How about filing bugs against 'devel' but adding a 'f7test1' keyword to it? > Why not add a "current stable" version, with a distro keyword for it? From selinux at gmail.com Sun Feb 4 00:28:10 2007 From: selinux at gmail.com (Tom London) Date: Sat, 3 Feb 2007 16:28:10 -0800 Subject: Cryptic filenames in / of FC7T1 In-Reply-To: <20070203214843.A00946F072@alopias.GreenKey.net> References: <6c18a4f0702031308l2b8bd353kd755ad8cfcc46ada@mail.gmail.com> <20070203214843.A00946F072@alopias.GreenKey.net> Message-ID: <4c4ba1530702031628y7d00ac84yacc0590968c7a39@mail.gmail.com> On 2/3/07, Curtis Doty wrote: > 10:08pm Bernd Bartmann said: > > > > I've found some cryptic named files in under / in FC7T1: > > > > a-7QeJ > > HXv5pB > > xI6TYx > > Zgu_vF > > > > All files are 4 bytes long and contain "blat". Where do they come from? > > > > Python does that in tempfile while looking for a tempdir. Something must > be b0rk when it tries to unlink the blatness. > > ../C > I believe these are coming from setroubleshootd. BZ'd here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222498 tom -- Tom London From laroche at redhat.com Sun Feb 4 00:45:54 2007 From: laroche at redhat.com (Florian La Roche) Date: Sun, 4 Feb 2007 01:45:54 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070203232000.4214d1cc@lain.camperquake.de> References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> <87odobx76a.fsf@kosh.bigo.ensc.de> <20070203232000.4214d1cc@lain.camperquake.de> Message-ID: <20070204004554.GA26441@dudweiler.stuttgart.redhat.com> On Sat, Feb 03, 2007 at 11:20:00PM +0100, Ralf Ertzinger wrote: > Hi. > > On Sat, 03 Feb 2007 22:28:13 +0100, Enrico Scholz wrote > > > Abort transaction when it is ambiguous (kickstart) > > Err, no. If a dependency can be satisfied in various ways then anaconda > is free to choose any one of the possibilities at it's discretion in > my book. > > If I want a certain package then I as the admin can put it into the > kickstart file. If you have several possibilities, you could also check if e.g. the comps file would favour one of them. Until now the MTA packages have been one of the very few where several possibilities have been available. sendmail has been the only choice which is also mentioned in the comps file at all. regards, Florian La Roche From eric at interplas.com Sun Feb 4 00:20:12 2007 From: eric at interplas.com (Eric Wood) Date: Sat, 03 Feb 2007 19:20:12 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070204003924.0a1febd2@lain.camperquake.de> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> <20070204003924.0a1febd2@lain.camperquake.de> Message-ID: <45C526BC.2070909@interplas.com> Ralf Ertzinger wrote: > Simply get upstream to rename it to pfx. > > The bigger issues is to why so many package have "sendmail", "postfix", or "exim" hardcoded in their binaries. A simple 'strings' command can tell us what package have these potential system calls embedded in their binaries: Of course I have a sendmail centric installation, and someone out there probably has a distro wide CVS search for dependencies. Besides, this simple search may be yeild a few false positives. Regardless, upstream packages should get more generic on their MTA of choice. But this proves to me the importance of sendmail of the other MTAs. strings for 'sendmail': anacron-2.3-44.fc6 at-3.1.8-84.fc6 authconfig-gtk-5.3.12-1.fc6 bash-3.1-16.1 crash-4.0-3.3 fetchmail-6.3.6-2.fc6 gnome-system-monitor-2.16.0-1.fc6 isdn4k-utils-3.2-50 logwatch-7.3-7.fc6 mailx-8.1.1-44.2.2 mdadm-2.5.4-2.fc6 mgetty-1.1.33-9.fc6 mutt-1.4.2.2-5.fc6 perl-5.8.8-10 perl-MIME-tools-5.420-2.fc6 php-cli-5.1.6-3.3.fc6 procmail-3.22-17.1 quota-3.13-1.2.3.1 rdist-6.1.5-44 redhat-lsb-3.1-11 rhgb-0.16.4-3.fc6 samba-3.0.23c-2 slrn-0.9.8.1pl1-1.2.2 sysreport-1.4.3-9 vixie-cron-4.1-64.fc6 strings for 'postfix' authconfig-gtk-5.3.12-1.fc6 gcalctool-5.8.25-1.fc6 glibc-common-2.5-10.fc6 samba-3.0.23c-2 sysreport-1.4.3-9 strings for 'exim' gnome-system-monitor-2.16.0-1.fc6 sysreport-1.4.3-9 My 2 cents. -eric wood From michel.salim at gmail.com Sun Feb 4 03:56:11 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 3 Feb 2007 22:56:11 -0500 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <1170546114.9699.0.camel@sb-home.lan> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> <1170541201.6858.28.camel@localhost.localdomain> <883cfe6d0702031452m7ebbe0d6o8a80399bd4c2d180@mail.gmail.com> <1170546114.9699.0.camel@sb-home.lan> Message-ID: <883cfe6d0702031956x361abb33ra8b651df4278e338@mail.gmail.com> 2007/2/3, nodata : > > How about filing bugs against 'devel' but adding a 'f7test1' keyword to it? > > > > Why not add a "current stable" version, with a distro keyword for it? > I'm not sure that's a good idea. That'd mean someone searching must take into account release dates. And how about 'current test release' then? -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From cmadams at hiwaay.net Sun Feb 4 04:54:14 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 3 Feb 2007 22:54:14 -0600 Subject: Default MTA for Fedora 7 In-Reply-To: <45C526BC.2070909@interplas.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> <20070204003924.0a1febd2@lain.camperquake.de> <45C526BC.2070909@interplas.com> Message-ID: <20070204045414.GD634026@hiwaay.net> Once upon a time, Eric Wood said: > The bigger issues is to why so many package have "sendmail", "postfix", > or "exim" hardcoded in their binaries. A simple 'strings' command can > tell us what package have these potential system calls embedded in their > binaries: I expect that most everything you found matching sendmail is calling /usr/sbin/sendmail (or archaic /usr/lib/sendmail). This is the Unix "standard" for a local message submission program, good or bad. That's why on Fedora /usr/sbin/sendmail is handled with alternatives; pretty much every replacement mailer supplies a basic /usr/sbin/sendmail that can accept messages the same way. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Sun Feb 4 04:52:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 23:52:23 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <45C526BC.2070909@interplas.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> <20070204003924.0a1febd2@lain.camperquake.de> <45C526BC.2070909@interplas.com> Message-ID: <20070204045223.GB11220@nostromo.devel.redhat.com> Eric Wood (eric at interplas.com) said: > Of course I have a sendmail centric installation, and someone out there > probably has a distro wide CVS search for dependencies. Besides, this > simple search may be yeild a few false positives. Regardless, upstream > packages should get more generic on their MTA of choice. But this > proves to me the importance of sendmail of the other MTAs. /usr/sbin/sendmail is a *standard* unix interface. It's in the LSB, and it's actually something that can be compiled in. (See /usr/include/paths.h) > strings for 'postfix' ... > gcalctool-5.8.25-1.fc6 Somehow, I doubt this has anything to do with mail. :) Bill From jfrieben at gmx.de Sun Feb 4 09:33:33 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 04 Feb 2007 10:33:33 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> Message-ID: <20070204093333.68890@gmx.net> > I just checked the contents of the DVD image, and the only MTA I can > find there is Exim. I guess that's the real reason. > > /Thomas No, this is not the real reason. "exim" is even preferred when both "Core" and "Extras" repositories are enabled while a program requiring "/usr/sin/sendmail" is scheduled for install. For instance, this can happen after a minimum install. In ordinary cases [e.g. desktop install], "sendmail" gets picked up during system install since it is listed in "comps.xml". -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail?ac=OM.GX.GX003K11713T4783a From dwmw2 at infradead.org Sun Feb 4 11:08:16 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 04 Feb 2007 11:08:16 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> Message-ID: <1170587296.29759.634.camel@pmac.infradead.org> On Sat, 2007-02-03 at 22:59 +0100, Thomas M Steenholdt wrote: > "If we change the Default MTA in Fedora - Which should it be?" > > I'm sure a lot of people will say Exim is great (i can't say, since i've > never worked with it). Others will yell for Postfix, towards which i'm > probably slightly biased, since that's what I currently use in most > places. I'm sure yet others will have other MTA's listed as their > favorite one. Exim certainly does the job for me. None of the others do, as far as I can tell. I'd be happy to be corrected on that count though, so I'll elucidate... I'd like to be able to do greylisting -- but not indiscriminately; I want to greylist only mail which actually looks suspicious in some way, rather than delaying perfectly genuine mail. Mail gets greylisted only if it has some SpamAssassin points, or it's HTML, or it comes from a machine with no reverse DNS or which is listed in a RBL, etc. That's a few lines of Exim ACL code, demonstrated (the quick hack version) at http://david.woodhou.se/eximconf/include/acl-greylist or perhaps more sanely with jgarzik's better SQLite-based version which is available in the same directory although I haven't yet switched over to it. Is it possible to do that kind of thing in other MTAs? Without writing or installing external software (or, perhaps, calling out to Exim? :) I also need to be able to run virtual domains on the cluster of mail machines I operate, but I don't really want to set up yet another distributed database; I _already_ have DNS running, after all. I keep aliases for virtual domains in TXT records, and I use Dynamic DNS so that owners of a given virtual domain can update their forwarding records with a trivial script round nsupdate. Currently, that's handled just a few lines of Exim router configuration in the same directory as the above (routers-dns-virtual). Can I do this in any of the other MTAs on offer? There's one or two more along those lines, like the trick described at http://www.infradead.org/rpr.html to avoid getting bounces to mail I didn't send. Last time I asked for help implementing these things in postfix, all the people who originally expressed an interest just went quiet after I explained what Exim is currently doing. The only coherent response I got was from the person who said "Oh. I think I'll switch to Exim". Obviously, not everyone wants to do quite as much with the MTA as I do. It's also important that it's secure, it's well-documented, and that the configuration file is actually understandable by a human rather than resembling line noise. Exim fulfils those criteria very well, and is a good choice for the whole range of people from newbies to nutters like myself. Even Postfix would also be a better choice than sendmail -- that isn't exactly a hard accolade to achieve. But it's much less versatile than Exim and much less flexible in handling and filtering of incoming mail. It might serve the newbies OK and those who really don't ask much of it, but it's less useful for anyone who actually wants to get _serious_ about running a spam-resistant mail server these days. If we ship a fully-fledged MTA as default, then Exim seems to make most sense. On the other hand, there is a strong argument to be made for shipping something a /usr/lib/sendmail which isn't capable of local delivery, doesn't listen on a TCP socket, and which does _nothing_ but deliver all mail to an external smarthost. You'd have a module in firstboot which asks for both the login details for that smarthost and the address to which (and from which) all root's mail should be sent. Actually, Exim could capably fulfil that duty too, and when running without local delivery can be be shipped in a mode where it doesn't even have to be setuid root. If that's all we want from a default 'MTA' then perhaps it's still overkill for the task though. But again, there's an advantage to having a single tool which can provide the _full_ range of functionality from low end to high end without the user ever having to throw one tool away and start learning a new one from scratch because they want to do something which the one they're currently using can't handle. -- dwmw2 From tmus at tmus.dk Sun Feb 4 10:37:34 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 04 Feb 2007 11:37:34 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070204093333.68890@gmx.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <20070204093333.68890@gmx.net> Message-ID: Joachim Frieben wrote: >> I just checked the contents of the DVD image, and the only MTA I can >> find there is Exim. I guess that's the real reason. >> >> /Thomas > > No, this is not the real reason. "exim" is even preferred when both "Core" and "Extras" repositories are enabled while a program requiring "/usr/sin/sendmail" is scheduled for install. For instance, this can happen after a minimum install. In ordinary cases [e.g. desktop install], "sendmail" gets picked up during system install since it is listed in "comps.xml". Still - Only Exim is available on the DVD. If something else is our *default* MTA, it would probably be a good idea to include that one on the DVD instead, wouldn't you agree. We can argue about what yum picks up as preferred for whatever reason, but when only one included package (Exim) provides /usr/sbin/sendmail, that whole discussion is pointless. If sendmail og postfix was on the DVD as well, that would be another case, but they're not. /Thomas From dwmw2 at infradead.org Sun Feb 4 11:14:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 04 Feb 2007 11:14:03 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <20070204093333.68890@gmx.net> Message-ID: <1170587644.29759.640.camel@pmac.infradead.org> On Sun, 2007-02-04 at 11:37 +0100, Thomas M Steenholdt wrote: > Still - Only Exim is available on the DVD. That's _because_ it was automatically chosen to satisfy the /usr/sbin/sendmail dependency. Pungi did that, at about the same time it decided _not_ to include the 64-bit libuser package to satisfy the libuser.so.1()(64bit) dependency in /usr/bin/passwd :) -- dwmw2 From buildsys at redhat.com Sun Feb 4 11:31:16 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 4 Feb 2007 06:31:16 -0500 Subject: rawhide report: 20070204 changes Message-ID: <200702041131.l14BVGE7012532@hs20-bc2-6.build.redhat.com> Updated Packages: GConf2-2.16.0-5.fc7 ------------------- * Sat Feb 03 2007 Matthias Clasen - 2.16.0-5 - Minor cleanups from package review audiofile-1:0.2.6-6.fc7 ----------------------- * Sat Feb 03 2007 Matthias Clasen - 1:0.2.6-6 - Corrections from package review devhelp-0.13-1.fc7 ------------------ * Sat Feb 03 2007 Matthew Barnes - 0.13-1.fc7 - Update to 0.13 - Clean up the spec file. - Remove devhelp-0.12-transparent.patch (fixed upstream). glib2-2.12.9-2.fc7 ------------------ * Sat Feb 03 2007 Matthias Clasen - 2.12.9-2 - Incorporate package review feedback: * drop an obsolete Provides: * add a -static subpackage * explain %check ppc exception * align summaries gpart-0.1h-5.fc7 ---------------- * Sat Feb 03 2007 David Cantrell - 0.1h-5 - Fix spec file problems with merge review (#225853) hal-0.5.8.1-8.fc7 ----------------- * Sat Feb 03 2007 Matthias Clasen - 0.5.8.1-8 - Incorporate more feedback from package review * Sat Feb 03 2007 Matthias Clasen - 0.5.8.1-7 - Use %find_lang (#161548) - Correct BuildRoot kernel-2.6.19-1.2919.fc7 ------------------------ * Sat Feb 03 2007 Dave Jones - 2.6.20-rc7-git1 memtest86+-1.65-6.fc7 --------------------- * Sat Feb 03 2007 Warren Togami - 1.65-6 - some spec cleanups (#226135) - remove old Obsoletes * Tue Jun 27 2006 Florian La Roche - 1.65-4 - make sure coreutils is installed for the preun script * Thu Jun 08 2006 Jesse Keating - 1.65-3 - rebuilt for new buildsystem sound-juicer-2.16.2-3.fc7 ------------------------- * Sat Feb 03 2007 Matthias Clasen - 2.16.2-3 - Minor fixes from package review: * Remove unnecessary Requires * Add URL * Correct Source, BuildRoot * Fix directory ownership xfsprogs-2.8.18-1.fc7 --------------------- Broken deps for ppc ---------------------------------------------------------- expect - 5.43.0-5.1.ppc requires libtcl8.4.so expectk - 5.43.0-5.1.ppc requires libtk8.4.so expectk - 5.43.0-5.1.ppc requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.ppc requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtk8.4.so Broken deps for i386 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expectk - 5.43.0-5.1.i386 requires libtk8.4.so expectk - 5.43.0-5.1.i386 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.i386 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtcl8.4.so isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- expect - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ppc64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc64 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtk8.4.so()(64bit) Broken deps for ia64 ---------------------------------------------------------- expect - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ia64 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtk8.4.so()(64bit) Broken deps for s390 ---------------------------------------------------------- expect - 5.43.0-5.1.s390 requires libtcl8.4.so expectk - 5.43.0-5.1.s390 requires libtk8.4.so expectk - 5.43.0-5.1.s390 requires libtcl8.4.so hfsutils - 3.2.6-7.2.2.s390 requires libtcl8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtk8.4.so hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtcl8.4.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- expect - 5.43.0-5.1.i386 requires libtcl8.4.so expect - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-5.1.x86_64 requires libtk8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.x86_64 requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) Broken deps for s390x ---------------------------------------------------------- expect - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) expect - 5.43.0-5.1.s390 requires libtcl8.4.so expectk - 5.43.0-5.1.s390x requires libtk8.4.so()(64bit) expectk - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtk8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390x requires kdelibs-devel >= 6:3.5.6 postgresql-pltcl - 8.2.1-2.fc7.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtk8.4.so()(64bit) From drago01 at gmail.com Sun Feb 4 11:38:55 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 04 Feb 2007 12:38:55 +0100 Subject: f7 test: failure on nvidia chipset In-Reply-To: <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> Message-ID: <45C5C5CF.8080508@gmail.com> for me the livecd does not boot on a nforce4 based system, because it could not find the root fs. this is because pata_amd does not get loaded, but I think this is a known issue. on my laptop ahci/ata_piix it boots fine. From drago01 at gmail.com Sun Feb 4 11:43:00 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 04 Feb 2007 12:43:00 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: References: <45BE11A9.7080702@redhat.com> <1170322067.3338.19.camel@hughsie-laptop> <45C20235.4080305@redhat.com> <1170351566.25835.4.camel@dawkins> <1170352969.13451.5.camel@hughsie-laptop> <1170355473.25835.14.camel@dawkins> <1170357435.22407.4.camel@hughsie-laptop> <1170367257.11382.0.camel@hughsie-laptop> Message-ID: <45C5C6C4.7020603@gmail.com> Gianluca Sforna wrote: > On 2/1/07, Richard Hughes wrote: >> On Thu, 2007-02-01 at 22:50 +0100, Gianluca Sforna wrote: >> > >> > Nice page. >> > I'd argue the italian for Resume is definetely not Resume: shoud >> > probably be Riprendi (spanish like) or Riattiva (french like). >> >> Please could you choose one and edit the wiki accordingly. >> > > Done > "Bereitschaft" for the german translations means "readiness" not anything sleep related. From tmus at tmus.dk Sun Feb 4 12:43:13 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 04 Feb 2007 13:43:13 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <1170587644.29759.640.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <20070204093333.68890@gmx.net> <1170587644.29759.640.camel@pmac.infradead.org> Message-ID: David Woodhouse wrote: > On Sun, 2007-02-04 at 11:37 +0100, Thomas M Steenholdt wrote: >> Still - Only Exim is available on the DVD. > > That's _because_ it was automatically chosen to satisfy > the /usr/sbin/sendmail dependency. Pungi did that, at about the same > time it decided _not_ to include the 64-bit libuser package to satisfy > the libuser.so.1()(64bit) dependency in /usr/bin/passwd :) > Heh :o). Okay then! /Thomas From jonathan.underwood at gmail.com Sun Feb 4 13:15:06 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 4 Feb 2007 13:15:06 +0000 Subject: Move from TeTeX to TeXLive In-Reply-To: <1163166491.2609.45.camel@redhat.usu> References: <1163146575.2609.7.camel@redhat.usu> <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> <1163166491.2609.45.camel@redhat.usu> Message-ID: <645d17210702040515x73fb61e4g5d673879c822befc@mail.gmail.com> On 10/11/06, Jindrich Novy wrote: > > Note that Michael Peters has already done a lot of work packaging up > > texlive as RPMs here: > > > > http://www.tetexrpm.org/texjive.html > > Yes, I made TeXLive upstream aware of Michael's work, so adopting his > work is also an option. > This announcement of work on TeXLive rpms might well be of interest: http://www.ntg.nl/pipermail/ntg-context/2007/023275.html > Jindrich > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dominik at greysector.net Sun Feb 4 13:29:29 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 4 Feb 2007 14:29:29 +0100 Subject: Move from TeTeX to TeXLive In-Reply-To: <1163166491.2609.45.camel@redhat.usu> References: <1163146575.2609.7.camel@redhat.usu> <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> <1163166491.2609.45.camel@redhat.usu> Message-ID: <20070204132929.GB25763@ryvius.pekin.waw.pl> On Friday, 10 November 2006 at 14:48, Jindrich Novy wrote: > On Fri, 2006-11-10 at 13:15 +0000, Jonathan Underwood wrote: > > On 10/11/06, Jindrich Novy wrote: > > > On Thu, 2006-11-09 at 21:02 +0000, Leo wrote: > > > > Now it is the beginning of FC7, I would suggest Fedora core 7 move to > > > > texlive. Here is how debian packages texlive: > > > > > > The conversion to TeX Live is definitely decided. I'm currently > > > discussing the future shape of it with TeX Live upstream which variant > > > will be most suitable for FC7. > > > > > > > http://ftp.debian.org/debian/pool/main/t/texlive-{bin, base,extra} > > > > > > Thanks for the link, I'll have a look. > > > > Note that Michael Peters has already done a lot of work packaging up > > texlive as RPMs here: > > > > http://www.tetexrpm.org/texjive.html > > Yes, I made TeXLive upstream aware of Michael's work, so adopting his > work is also an option. How about asking him to become a mainainer for Fedora first and then, if he doesn't want to, adopting his work. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jspaleta at gmail.com Sun Feb 4 18:14:08 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 4 Feb 2007 09:14:08 -0900 Subject: Would it make sense to make aspell dictionaries noarch packages? Message-ID: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> Okay so I'm doing the merge review for aspell and all its lovely little dictionary packages.... and I got to wondering, because i like complicating everyone's already overworked lives.... Is there a good reason why the dictionaries are arched packages? It seems they are arched simply because the payload is dropping into _libdir which is necessarily arch specific. My question is of course, can we change how aspell and its dictionary packages are built so that the dictionaries get pooped into _datadir instead of _libdir? Or am I completely blind and the dictionaries really are arch specific and need to be in _libdir? For example look at the payload of aspell-en... anything arch specific in that? For reference: https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c6 -jef"im sort of hungry"spaleta From gparted at gmail.com Sun Feb 4 18:25:35 2007 From: gparted at gmail.com (LarryT) Date: Sun, 04 Feb 2007 19:25:35 +0100 Subject: rawhide report: 20070204 changes In-Reply-To: <200702041131.l14BVGE7012532@hs20-bc2-6.build.redhat.com> References: <200702041131.l14BVGE7012532@hs20-bc2-6.build.redhat.com> Message-ID: <45C6251F.1030103@gmail.com> X86 / rawhide. (F7-test1) Have installed the last updates, and reboot : - Just after login, have a alert screen : http://www.fr.laurent.freesurf.fr/fc7-1_005.jpg , but X started. - Launched OOo which opens well. (still no REPLACE tab in Option/autocorrect). Larry buildsys at redhat.com wrote: > > > > Updated Packages: > > GConf2-2.16.0-5.fc7 > ------------------- > * Sat Feb 03 2007 Matthias Clasen - 2.16.0-5 > - Minor cleanups from package review > > audiofile-1:0.2.6-6.fc7 > ----------------------- > * Sat Feb 03 2007 Matthias Clasen - 1:0.2.6-6 > - Corrections from package review > > devhelp-0.13-1.fc7 > ------------------ > * Sat Feb 03 2007 Matthew Barnes - 0.13-1.fc7 > - Update to 0.13 > - Clean up the spec file. > - Remove devhelp-0.12-transparent.patch (fixed upstream). > > glib2-2.12.9-2.fc7 > ------------------ > * Sat Feb 03 2007 Matthias Clasen - 2.12.9-2 > - Incorporate package review feedback: > * drop an obsolete Provides: > * add a -static subpackage > * explain %check ppc exception > * align summaries > > gpart-0.1h-5.fc7 > ---------------- > * Sat Feb 03 2007 David Cantrell - 0.1h-5 > - Fix spec file problems with merge review (#225853) > > hal-0.5.8.1-8.fc7 > ----------------- > * Sat Feb 03 2007 Matthias Clasen - 0.5.8.1-8 > - Incorporate more feedback from package review > > * Sat Feb 03 2007 Matthias Clasen - 0.5.8.1-7 > - Use %find_lang (#161548) > - Correct BuildRoot > > kernel-2.6.19-1.2919.fc7 > ------------------------ > * Sat Feb 03 2007 Dave Jones > - 2.6.20-rc7-git1 > > memtest86+-1.65-6.fc7 > --------------------- > * Sat Feb 03 2007 Warren Togami - 1.65-6 > - some spec cleanups (#226135) > - remove old Obsoletes > > * Tue Jun 27 2006 Florian La Roche - 1.65-4 > - make sure coreutils is installed for the preun script > > * Thu Jun 08 2006 Jesse Keating - 1.65-3 > - rebuilt for new buildsystem > > sound-juicer-2.16.2-3.fc7 > ------------------------- > * Sat Feb 03 2007 Matthias Clasen - 2.16.2-3 > - Minor fixes from package review: > * Remove unnecessary Requires > * Add URL > * Correct Source, BuildRoot > * Fix directory ownership > > xfsprogs-2.8.18-1.fc7 > --------------------- > > Broken deps for ppc > ---------------------------------------------------------- > expect - 5.43.0-5.1.ppc requires libtcl8.4.so > expectk - 5.43.0-5.1.ppc requires libtk8.4.so > expectk - 5.43.0-5.1.ppc requires libtcl8.4.so > hfsutils - 3.2.6-7.2.2.ppc requires libtcl8.4.so > hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtk8.4.so > hfsutils-x11 - 3.2.6-7.2.2.ppc requires libtcl8.4.so > isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so > kdebase - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.ppc requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.ppc requires libtcl8.4.so > pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so > pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so > ruby-libs - 1.8.5.2-1.fc7.ppc requires libtcl8.4.so > ruby-libs - 1.8.5.2-1.fc7.ppc requires libtk8.4.so > > > > Broken deps for i386 > ---------------------------------------------------------- > expect - 5.43.0-5.1.i386 requires libtcl8.4.so > expectk - 5.43.0-5.1.i386 requires libtk8.4.so > expectk - 5.43.0-5.1.i386 requires libtcl8.4.so > hfsutils - 3.2.6-7.2.2.i386 requires libtcl8.4.so > hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtk8.4.so > hfsutils-x11 - 3.2.6-7.2.2.i386 requires libtcl8.4.so > isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so > kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.i386 requires libtcl8.4.so > pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so > pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so > > > > Broken deps for ppc64 > ---------------------------------------------------------- > expect - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.ppc64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.ppc64 requires libtk8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ppc64 requires libtk8.4.so()(64bit) > isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.ppc64 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.ppc64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtk8.4.so()(64bit) > > > > Broken deps for ia64 > ---------------------------------------------------------- > expect - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.ia64 requires libtk8.4.so()(64bit) > expectk - 5.43.0-5.1.ia64 requires libtcl8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.ia64 requires libtk8.4.so()(64bit) > isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.ia64 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.ia64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtk8.4.so()(64bit) > > > > Broken deps for s390 > ---------------------------------------------------------- > expect - 5.43.0-5.1.s390 requires libtcl8.4.so > expectk - 5.43.0-5.1.s390 requires libtk8.4.so > expectk - 5.43.0-5.1.s390 requires libtcl8.4.so > hfsutils - 3.2.6-7.2.2.s390 requires libtcl8.4.so > hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtk8.4.so > hfsutils-x11 - 3.2.6-7.2.2.s390 requires libtcl8.4.so > kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.s390 requires libtcl8.4.so > pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so > pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtk8.4.so > ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtcl8.4.so > systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 > systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 > > > > Broken deps for x86_64 > ---------------------------------------------------------- > expect - 5.43.0-5.1.i386 requires libtcl8.4.so > expect - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.x86_64 requires libtcl8.4.so()(64bit) > expectk - 5.43.0-5.1.x86_64 requires libtk8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.x86_64 requires libtk8.4.so()(64bit) > isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdebase - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.x86_64 requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.x86_64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) > > > > Broken deps for s390x > ---------------------------------------------------------- > expect - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) > expect - 5.43.0-5.1.s390 requires libtcl8.4.so > expectk - 5.43.0-5.1.s390x requires libtk8.4.so()(64bit) > expectk - 5.43.0-5.1.s390x requires libtcl8.4.so()(64bit) > hfsutils - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtcl8.4.so()(64bit) > hfsutils-x11 - 3.2.6-7.2.2.s390x requires libtk8.4.so()(64bit) > kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdebase - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 > kdegames - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 > kdesdk-devel - 3.5.6-0.1.fc6.s390x requires kdelibs-devel >= 6:3.5.6 > postgresql-pltcl - 8.2.1-2.fc7.s390x requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) > pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtcl8.4.so()(64bit) > ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtk8.4.so()(64bit) > > > > From dcantrell at redhat.com Sun Feb 4 19:39:47 2007 From: dcantrell at redhat.com (David Cantrell) Date: Sun, 04 Feb 2007 14:39:47 -0500 Subject: broken dhclient in rawhide fixed Message-ID: <1170617987.7629.4.camel@mortise.boston.redhat.com> dhclient-3.0.5-16.fc7 works fine on rawhide now. There was a problem with the Xen partial UDP checksum patch and since I know zero about Xen, I've disabled the patch for now. -- David Cantrell Red Hat / Westford, MA -------------- 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 sander at hoentjen.eu Sun Feb 4 20:01:20 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Sun, 04 Feb 2007 21:01:20 +0100 Subject: dhcp client acting strangely In-Reply-To: <1170526062.6828.15.camel@mortise.boston.redhat.com> References: <1170517268.8636.5.camel@peecee.hoentjen.eu> <1170518936.6828.5.camel@mortise.boston.redhat.com> <1170519698.7106.1.camel@peecee.hoentjen.eu> <20070203185729.4526e6ae@lain.camperquake.de> <1170526062.6828.15.camel@mortise.boston.redhat.com> Message-ID: <1170619280.7095.4.camel@peecee.hoentjen.eu> On Sat, 2007-02-03 at 13:07 -0500, David Cantrell wrote: > > Also interesting. OK, so Permissive mode on FC-6 lets the new dhclient > work, but on rawhide, no deal. > > Can someone file a bug so I can track this? > Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227286 Sander From mclasen at redhat.com Sun Feb 4 20:36:08 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 04 Feb 2007 15:36:08 -0500 Subject: broken dhclient in rawhide fixed In-Reply-To: <1170617987.7629.4.camel@mortise.boston.redhat.com> References: <1170617987.7629.4.camel@mortise.boston.redhat.com> Message-ID: <1170621368.3501.0.camel@localhost.localdomain> On Sun, 2007-02-04 at 14:39 -0500, David Cantrell wrote: > dhclient-3.0.5-16.fc7 works fine on rawhide now. There was a problem > with the Xen partial UDP checksum patch and since I know zero about Xen, > I've disabled the patch for now. Thanks, works for me. From dcantrell at redhat.com Sun Feb 4 22:26:36 2007 From: dcantrell at redhat.com (David Cantrell) Date: Sun, 04 Feb 2007 17:26:36 -0500 Subject: Announcing repoman - PyGTK yum repo manager Message-ID: <1170627996.7629.7.camel@mortise.boston.redhat.com> Announcing repoman ------------------ Repoman is a PyGTK frontend for configuring common and basic settings for yum. Specifically, it lets users enable and disable individual repos easily. Users can add and remove repositories as well. Repoman is not meant to expose all of yum's configuration settings in GUI form, but rather the common settings most users will care about. One of the interesting features is the Tracking page. Users can easily switch between stable (with or without updates) or development branches and repoman will enable and disable the correct repositories for the user. Repoman also offers a set of Python classes for reading and writing out /etc/yum.repos.d files. The core element is the RepoStanza, which are contained in RepoFiles, and all of those make up a Repos collection. This program is evolving a lot, so help testing and/or coding is appreciated. Repoman is short for repository manager. DOWNLOAD Web page: http://www.boston.burdell.org/repoman/ Source archives are available in tar.gz format. We have RPMs available for Fedora Core 6. We would have rawhide RPMs available, but we ran in to a problem building on rawhide. QUESTIONS/BUGS Please email me or Chris Lumens (email addresses on web page) if you bug reports. -- David Cantrell Red Hat / Westford, MA -------------- 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 lsof at nodata.co.uk Sun Feb 4 22:52:13 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 04 Feb 2007 23:52:13 +0100 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <883cfe6d0702031956x361abb33ra8b651df4278e338@mail.gmail.com> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> <1170541201.6858.28.camel@localhost.localdomain> <883cfe6d0702031452m7ebbe0d6o8a80399bd4c2d180@mail.gmail.com> <1170546114.9699.0.camel@sb-home.lan> <883cfe6d0702031956x361abb33ra8b651df4278e338@mail.gmail.com> Message-ID: <1170629533.3236.0.camel@sb-home.lan> Am Samstag, den 03.02.2007, 22:56 -0500 schrieb Michel Salim: > 2007/2/3, nodata : > > > > How about filing bugs against 'devel' but adding a 'f7test1' keyword to it? > > > > > > > Why not add a "current stable" version, with a distro keyword for it? > > > I'm not sure that's a good idea. That'd mean someone searching must > take into account release dates. And how about 'current test release' > then? Yep :) From giallu at gmail.com Sun Feb 4 22:55:07 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 4 Feb 2007 23:55:07 +0100 Subject: Extras i386 rawhide rebuild in mock status 2007-02-03 In-Reply-To: <20070203081100.A1236@humbolt.us.dell.com> References: <20070203081100.A1236@humbolt.us.dell.com> Message-ID: On 2/3/07, Matt Domsch wrote: > rawstudio-0.4.1-2.fc6 giallu at gmail.com Do I have to add an "aclocal" call as suggested by the log: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/rawstudio-0.4.1-2.fc6.src.rpm/result/build.log or is there anything else needed? btw, thanks Matt for running this effort From vonbrand at inf.utfsm.cl Mon Feb 5 01:21:40 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 04 Feb 2007 22:21:40 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: <1170587296.29759.634.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> Message-ID: <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> David Woodhouse wrote: > On Sat, 2007-02-03 at 22:59 +0100, Thomas M Steenholdt wrote: > > "If we change the Default MTA in Fedora - Which should it be?" > > > > I'm sure a lot of people will say Exim is great (i can't say, since i've > > never worked with it). Others will yell for Postfix, towards which i'm > > probably slightly biased, since that's what I currently use in most > > places. I'm sure yet others will have other MTA's listed as their > > favorite one. > > Exim certainly does the job for me. None of the others do, as far as I > can tell. I'd be happy to be corrected on that count though, so I'll > elucidate... > > I'd like to be able to do greylisting -- but not indiscriminately; I > want to greylist only mail which actually looks suspicious in some way, > rather than delaying perfectly genuine mail. Mail gets greylisted only > if it has some SpamAssassin points, or it's HTML, or it comes from a > machine with no reverse DNS or which is listed in a RBL, etc. The /point/ in greylisting is not to expend any effort on mail that comes from suspect origins. Stopping mail from an RBLed origin or no reverse DNS (or non-matching reverse DNS) are other, independent anti-spam measures. Sure, they can be integrated into greylisting (milter-greylist for sendmail integrates RBLs), but they are still independent. So is spamassassin's score, etc. > That's a > few lines of Exim ACL code, demonstrated (the quick hack version) at > http://david.woodhou.se/eximconf/include/acl-greylist or perhaps more > sanely with jgarzik's better SQLite-based version which is available in > the same directory although I haven't yet switched over to it. > Is it possible to do that kind of thing in other MTAs? Without writing > or installing external software (or, perhaps, calling out to Exim? :) Why is "installing external software" (specially if it is written to standardized interfaces defined exactly for such uses) off-limits? > I also need to be able to run virtual domains on the cluster of mail > machines I operate, but I don't really want to set up yet another > distributed database; I _already_ have DNS running, after all. I keep > aliases for virtual domains in TXT records, Lousy missuse of DNS, if you ask me. > and I use Dynamic DNS so > that owners of a given virtual domain can update their forwarding > records with a trivial script round nsupdate. Currently, that's handled > just a few lines of Exim router configuration in the same directory as > the above (routers-dns-virtual). Can I do this in any of the other MTAs > on offer? Why does an MTA have to bend over to such abuse of DNS? [...] > Even Postfix would also be a better choice than sendmail -- that isn't > exactly a hard accolade to achieve. But it's much less versatile than > Exim and much less flexible in handling and filtering of incoming mail. > It might serve the newbies OK and those who really don't ask much of it, > but it's less useful for anyone who actually wants to get _serious_ > about running a spam-resistant mail server these days. Better go tell that the guys at sendmail.org. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From mattdm at mattdm.org Mon Feb 5 02:01:15 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 4 Feb 2007 21:01:15 -0500 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <45BD4317.1000606@andrei.myip.org> References: <45BBE897.9030802@andrei.myip.org> <45BD1A44.7020003@redhat.com> <45BD4317.1000606@andrei.myip.org> Message-ID: <20070205020115.GA15152@jadzia.bu.edu> On Sun, Jan 28, 2007 at 04:43:03PM -0800, Florin Andrei wrote: > >Ambiguity is bad. > Correct. > OTOH, if all files in /etc/init.d would be named init- or > something like that, then the ambiguity would disappear and the > /etc/init.d could be added to the default $PATH. No one seems to have mentioned this, so I will. It's important to use /sbin/service rather than running /etc/init.d scripts directly for other reasons than its convenience. Namely, it properly sanitizes your environment so a program started that way behaves just as if really started by init at system boot time. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mike at miketc.com Mon Feb 5 02:52:02 2007 From: mike at miketc.com (Mike Chambers) Date: Sun, 04 Feb 2007 20:52:02 -0600 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1170627996.7629.7.camel@mortise.boston.redhat.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> Message-ID: <1170643923.2310.0.camel@scrappy.miketc.com> On Sun, 2007-02-04 at 17:26 -0500, David Cantrell wrote: > Repoman is short for repository manager. > > DOWNLOAD > > Web page: http://www.boston.burdell.org/repoman/ > > Source archives are available in tar.gz format. We have RPMs > available for Fedora Core 6. We would have rawhide RPMs available, > but we ran in to a problem building on rawhide. > So it's not ready for FC7/rawhide currently? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From clumens at redhat.com Mon Feb 5 03:42:22 2007 From: clumens at redhat.com (Chris Lumens) Date: Sun, 4 Feb 2007 22:42:22 -0500 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1170643923.2310.0.camel@scrappy.miketc.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <1170643923.2310.0.camel@scrappy.miketc.com> Message-ID: <20070205034222.GB5396@exeter.boston.redhat.com> > > Source archives are available in tar.gz format. We have RPMs > > available for Fedora Core 6. We would have rawhide RPMs available, > > but we ran in to a problem building on rawhide. > > > > So it's not ready for FC7/rawhide currently? I developed and built on my laptop earlier today, and it's fairly close to F7/rawhide. There were just some problems with the build system David was using earlier. Try it out and see what happens. It's just all python so there really shouldn't be any problems. - Chris From dcantrell at redhat.com Mon Feb 5 05:03:28 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 05 Feb 2007 00:03:28 -0500 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <20070205034222.GB5396@exeter.boston.redhat.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <1170643923.2310.0.camel@scrappy.miketc.com> <20070205034222.GB5396@exeter.boston.redhat.com> Message-ID: <1170651808.7629.12.camel@mortise.boston.redhat.com> On Sun, 2007-02-04 at 22:42 -0500, Chris Lumens wrote: > > > Source archives are available in tar.gz format. We have RPMs > > > available for Fedora Core 6. We would have rawhide RPMs available, > > > but we ran in to a problem building on rawhide. > > > > > > > So it's not ready for FC7/rawhide currently? > > I developed and built on my laptop earlier today, and it's fairly close > to F7/rawhide. There were just some problems with the build system > David was using earlier. Try it out and see what happens. It's just > all python so there really shouldn't be any problems. Yeah, I tried to build rawhide packages using brew, but got this error: python setup.py install --root=/var/tmp/repoman-0.4-1.fc7-root-brewbuilder running install error: invalid Python installation: unable to open /usr/lib/python2.5/config/Makefile (No such file or directory) It does work on rawhide though. -- David Cantrell Red Hat / Westford, MA -------------- 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 peter at thecodergeek.com Mon Feb 5 06:56:11 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 04 Feb 2007 22:56:11 -0800 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1170651808.7629.12.camel@mortise.boston.redhat.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <1170643923.2310.0.camel@scrappy.miketc.com> <20070205034222.GB5396@exeter.boston.redhat.com> <1170651808.7629.12.camel@mortise.boston.redhat.com> Message-ID: <1170658571.11071.14.camel@localhost> On Mon, 2007-02-05 at 00:03 -0500, David Cantrell wrote: > python setup.py install > --root=/var/tmp/repoman-0.4-1.fc7-root-brewbuilder > running install > error: invalid Python installation: unable to open /usr/lib/python2.5/config/Makefile (No such file or directory) > > It does work on rawhide though. Hmm. According to repoquery, that file is part of the python-devel package in development/FC7, so you should add python-devel as a BuildRequires to your spec to fix this. Actually, I see a couple of other things that may need fixing in the spec file if you would be so kind for the next EVR bump. :] * Source0 should be a fully-qualified URI using macros if appropriate (i.e., http://example.com/sources/%{name}-%{version}.tar.gz) * You don't need to set %debug_package to %nil, since having the package build as noarch makes rpmbuild automagically not do any of the normal debuginfo stripping. * Instead of hardcoding "%{_libdir}/python?.?/site-packages/" into your %files section, you should instead define the % python_sitelib macro and use that in your %files. (See the Packaging/Python page on the wiki for more information.) Does this BuildRequires fix it? -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 tla at rasmil.dk Mon Feb 5 08:40:32 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Mon, 05 Feb 2007 09:40:32 +0100 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1170627996.7629.7.camel@mortise.boston.redhat.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> Message-ID: <45C6ED80.8010706@rasmil.dk> David Cantrell wrote: > Announcing repoman > ------------------ > > Repoman is a PyGTK frontend for configuring common and basic settings > for yum. Specifically, it lets users enable and disable individual > repos easily. Users can add and remove repositories as well. > > Repoman is not meant to expose all of yum's configuration settings in > GUI form, but rather the common settings most users will care about. > > One of the interesting features is the Tracking page. Users can easily > switch between stable (with or without updates) or development branches > and repoman will enable and disable the correct repositories for the > user. > > Repoman also offers a set of Python classes for reading and writing out > /etc/yum.repos.d files. The core element is the RepoStanza, which are > contained in RepoFiles, and all of those make up a Repos collection. > > This program is evolving a lot, so help testing and/or coding is > appreciated. > > Repoman is short for repository manager. > > DOWNLOAD > > Web page: http://www.boston.burdell.org/repoman/ > > Source archives are available in tar.gz format. We have RPMs > available for Fedora Core 6. We would have rawhide RPMs available, > but we ran in to a problem building on rawhide. > > QUESTIONS/BUGS > > Please email me or Chris Lumens (email addresses on web page) if you > bug reports. > > Hi David Look very nice, i have started another project called 'system-config-repo' doing the same thing, manage yum repo. It is also written in Python, you can check the code here. http://yumex.svn.sourceforge.net/viewvc/yumex/trunk/system-config-repo/ Maybe we should join forces and merge our projects, there is no need to make 2 gui tools for managing yum repos. Checkout my code, tell me what you think. Tim From drago01 at gmail.com Mon Feb 5 08:52:20 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 05 Feb 2007 09:52:20 +0100 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> Message-ID: <45C6F044.5010002@gmail.com> Jeff Spaleta wrote: > For reference: > https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c6 > bug nr.? (your link is broken) > -jef"im sort of hungry"spaleta > From redhat at olen.net Mon Feb 5 09:32:33 2007 From: redhat at olen.net (Ola Thoresen) Date: Mon, 05 Feb 2007 10:32:33 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> Message-ID: <45C6F9B1.3010504@olen.net> Horst H. von Brand wrote: > David Woodhouse wrote: >> >> I'd like to be able to do greylisting -- but not indiscriminately; I >> want to greylist only mail which actually looks suspicious in some way, >> rather than delaying perfectly genuine mail. Mail gets greylisted only >> if it has some SpamAssassin points, or it's HTML, or it comes from a >> machine with no reverse DNS or which is listed in a RBL, etc. > > The /point/ in greylisting is not to expend any effort on mail that comes > from suspect origins. Stopping mail from an RBLed origin or no reverse DNS > (or non-matching reverse DNS) are other, independent anti-spam > measures. Sure, they can be integrated into greylisting (milter-greylist > for sendmail integrates RBLs), but they are still independent. So is > spamassassin's score, etc. > I somehow agree with David here, and have tried to configure Spamassassin and sendmail-milter accordingly, with no success. I'd like SA to block everything with a score higher than N (550 Blocked By Spamassassin) - This is easy. I do not want mail that SA has classified as almost certainly not spam to be greylisted. But then I'd like to greylist everything that is not blocked, but that is still suspicius (I.E. a score lower than N, but higher than M). But I geuss this is best solved by talking to the developers of one of the greylist-milters, to make them add a feature to whitelist email based on a custom header. (For instance "X-Spam-Level: ***") Rgds. -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From mingo at elte.hu Mon Feb 5 09:34:43 2007 From: mingo at elte.hu (Ingo Molnar) Date: Mon, 5 Feb 2007 10:34:43 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms Message-ID: <20070205093443.GA30675@elte.hu> in case you are interested in really bleeding-edge kernel rpms for fc7/fc6/fc5, i've created the -rt kernel yum repository, which provides the -rt kernel in rpmized form for i686 and x86_64, updated daily/bi-daily. The package is named 'kernel-rt' so it does not conflict with the Fedora kernel package - you can always revert to the Fedora kernel. The -rt kernel has the following main features: it closely tracks Linus' -git tree, has KVM, high-res timers, dynticks, fully preemptible kernel, preempt-rcu, plus all the usual upstream stuff that the Fedora kernel has enabled. (The yum repository pointers at the end of the announcement.) Ingo ----- Forwarded message from Ingo Molnar ----- Date: Mon, 5 Feb 2007 07:56:36 +0100 From: Ingo Molnar To: linux-kernel at vger.kernel.org Subject: v2.6.20-rt1, yum/rpm Cc: linux-rt-users at vger.kernel.org i have released the v2.6.20-rt1 kernel, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ more info about the -rt patchset can be found in the RT wiki: http://rt.wiki.kernel.org This is a fixes-only release. Since the -rt tree has been closely tracking Linus' upstream kernel since -rc1, no new issues are expected - please re-report if anything is still unfixed. There are lots of changes relative to 2.6.19-rt6 (the last stable release), but these are mostly fixes and other gradual improvements. KVM is now enabled in the yum kernel on both i686 and x86_64 (and has been enabled since around -rc1-rt1), the -rt tree tracks kvm-trunk (which is a bit fresher than upstream KVM) and has a few additional paravirt speedups implemented and enabled. to build a 2.6.20-rt1 tree, the following patches should be applied: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.tar.bz2 http://redhat.com/~mingo/realtime-preempt/patch-2.6.20-rt1 the -rt YUM repository for Fedora Core 6 and 5, for architectures i686 and x86_64 can be activated via: cd /etc/yum.repos.d wget http://people.redhat.com/~mingo/realtime-preempt/rt.repo yum install kernel-rt.x86_64 # on x86_64 yum install kernel-rt # on i686 yum update kernel-rt # refresh - or enable yum-updatesd as usual, bugreports, fixes and suggestions are welcome, Ingo ----- End forwarded message ----- ----- End forwarded message ----- From dwmw2 at infradead.org Mon Feb 5 11:25:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 05 Feb 2007 11:25:02 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> Message-ID: <1170674703.29759.758.camel@pmac.infradead.org> On Sun, 2007-02-04 at 22:21 -0300, Horst H. von Brand wrote: > > Exim certainly does the job for me. None of the others do, as far as I > > can tell. I'd be happy to be corrected on that count though, so I'll > > elucidate... I note you make no pretence at claiming Postfix can do these things; only arguments that I shouldn't _want_ to. This despite the fact that they're only _examples_ of the kind of thing people do with mail servers, and the fact that these are the reasons people come to me and _ask_ for an account on my systems. But despite the fact that it's a complete digression and you seem to have already conceded the point I was making, it's a subject which interests me so I'll play along... > > I'd like to be able to do greylisting -- but not indiscriminately; I > > want to greylist only mail which actually looks suspicious in some way, > > rather than delaying perfectly genuine mail. Mail gets greylisted only > > if it has some SpamAssassin points, or it's HTML, or it comes from a > > machine with no reverse DNS or which is listed in a RBL, etc. > > The /point/ in greylisting is not to expend any effort on mail that comes > from suspect origins. Resources are cheap, right up to the point the mail is accepted and delivered to my mailbox. At _that_ point I start to resent it. The point in greylisting is very simple: it's to check that the mail is coming from a 'proper' mail server which actually does retry mail when you give a temporary rejection. Some people na?vely delay all incoming mail (and some outgoing mail too, if they reject at RCPT TO and the recipient uses callouts) by greylisting indiscriminately. I prefer mail to be fast in the common case, so I like to delay _only_ mail which actually looks suspicious in some way, and I prefer _never_ to greylist mail from a host (IP address) which was already observed to retry in the past. > Stopping mail from an RBLed origin or no reverse DNS > (or non-matching reverse DNS) are other, independent anti-spam > measures. Sure, they can be integrated into greylisting (milter-greylist > for sendmail integrates RBLs), but they are still independent. So is > spamassassin's score, etc. You may have been trained to treat them independently because that's all you're used to being able to do, but personally I don't want to be limited in that fashion. I _want_ to be able to combine SA score with other reasons for considering a mail 'suspicious', and use that as a trigger for stuff like greylisting. For someone else, I used a similar set of criteria to trigger Exim's 'fakereject' feature which allows one to give a 550 rejection but still actually accept the message. It was configured to 'freeze' the mail on the queue, and give a URL with the rejection message as well as an explanation. When the recipient of the bounce went to that URL they would get a far more coherent explanation of the offences which caused the mail to be 'rejected', and could complete a captcha to verify that the mail _is_ genuine and have it unfrozen for delivery. That's not something I would normally have done; I prefer just to bounce and let people fix their sending mail servers if they're broken enough to get rejected. But the client in this case was adamant that this was what they wanted, and it allows them to peruse the frozen spam on the queue for false positives. It's better than accepting it and putting it into a spam folder, because that way the recipient wouldn't get a bounce, so they might think their mail is actually going to be read. > > Is it possible to do that kind of thing in other MTAs? Without writing > > or installing external software (or, perhaps, calling out to Exim? :) > > Why is "installing external software" (specially if it is written to > standardized interfaces defined exactly for such uses) off-limits? I suppose it isn't off-limits if it's versatile enough to be tweaked to users' requirements and if it's shipped in Fedora. Standardised interfaces are fine, again as long as they're versatile enough. For a long time, Exim had SpamAssassin support (sa-exim) which used a similar interface -- running on the mail just after DATA and giving a decision about whether to accept it or not. That wasn't good enough for folks who were used to better things, and it was very quickly replaced with full content scanning support within the ACL language. We finally dropped sa-exim from the Fedora packages in FE6, after keeping it around for a long time for compatibility. http://fedora.redhat.com/docs/release-notes/fc6/en_US/sn-Extras.html#id2916368 > > I also need to be able to run virtual domains on the cluster of mail > > machines I operate, but I don't really want to set up yet another > > distributed database; I _already_ have DNS running, after all. I keep > > aliases for virtual domains in TXT records, > > Lousy missuse of DNS, if you ask me. DNS is a distributed database which automatically synchronises between all the machines in the cluster. It also allows me to give 'keys' to certain users in order that they can modify certain subdomains as they desire. It was already running; I didn't have to set up a new database. Yes, it's 'abuse of DNS'. It's also _extremely_ convenient. If I want bondage and discipline I'll go back to programming in Modula-3. > > and I use Dynamic DNS so > > that owners of a given virtual domain can update their forwarding > > records with a trivial script round nsupdate. Currently, that's handled > > just a few lines of Exim router configuration in the same directory as > > the above (routers-dns-virtual). Can I do this in any of the other MTAs > > on offer? > > Why does an MTA have to bend over to such abuse of DNS? An MTA should be flexible enough that the admin can do what he/she need to do with with it. Because of the way SMTP works, especially the need to avoid sending bounces _after_ accepting mail, stuff _does_ need to be pushed down into the MTA to be done at SMTP time. And in the current environment, you have to get more and more involved to stay ahead of the game. I've just highlighted a few of the things I do with it; that's all. It wasn't an exhaustive list; just a glimpse of how Exim makes the mail system work much better for _me_ (and my users) than any other MTA could manage. OK, so returning to the original topic... now I've got two kinds of responses. First the "oh, I think I'll switch to Exim" and now the somewhat more disingenuous "you shouldn't want to do that anyway" :) -- dwmw2 From buildsys at redhat.com Mon Feb 5 11:26:19 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 5 Feb 2007 06:26:19 -0500 Subject: rawhide report: 20070205 changes Message-ID: <200702051126.l15BQJMU015863@hs20-bc2-6.build.redhat.com> Updated Packages: audit-1.4-1.fc7 --------------- * Sun Feb 04 2007 Steve Grubb 1.4-1 - New report about authentication attempts - Updates for python 2.5 - update autrace to have resource usage mode - update auditctl to support immutable config - added audit_log_user_command function to libaudit api - interpret capabilities - added audit event parsing library - updates for 2.6.20 kernel cpuspeed-1:1.2.1-1.55.fc7 ------------------------- * Sun Feb 04 2007 Jarod Wilson - Fix up compile flags and misc other fixes for core/extras merge review (#225658) devhelp-0.13-2.fc7 ------------------ * Sun Feb 04 2007 Matthew Barnes - 0.13-2.fc7 - Incorporate suggestions from package review. dhcp-12:3.0.5-16.fc7 -------------------- * Sun Feb 04 2007 David Cantrell - 12:3.0.5-16 - Disable xen-checksums patch for now as it breaks dhclient (#227266) - Updated fix-warnings patch * Sun Feb 04 2007 David Woodhouse - 12:3.0.5-15 - Fix broken file reading due to LDAP patch expect-5.43.0-6 --------------- * Sat Feb 03 2007 Miloslav Trmac - 5.43.0-6 - Update to build with Tcl 8.5 - Drop static libraries - Ship more documentation - Use %check for (make test), remove the conditional fedora-logos-6.0.90-2.fc7 ------------------------- * Sun Feb 04 2007 Matthias Clasen - 6.0.90-2 - Don't symlink the Fedora logo to gnome-logo-icon-transparent finger-0.17-34.fc7 ------------------ * Sun Feb 04 2007 Radek Vok??l - 0.17-34 - finger server permissions (#225754) * Sun Feb 04 2007 Radek Vok??l - 0.17-33 - spec files cleanups according to MergeReview (#225754) - dist tag added glib2-2.12.9-3.fc7 ------------------ * Sun Feb 04 2007 Matthias Clasen - 2.12.9-3 - More package review feedback: * install /etc/profile.d snipplets as 644 * explain Conflict with libgnomeui * remove stale Conflict with glib-devel gtksourceview-1.8.3-2.fc7 ------------------------- * Sun Feb 04 2007 Matthias Clasen - 1.8.3-2 - Incorporate package review feedback hfsutils-3.2.6-8 ---------------- * Fri Jan 26 2007 Jesse Keating - 3.2.6-8 - rebuild for new tcl kernel-2.6.20-1.2922.fc7 ------------------------ * Sun Feb 04 2007 Dave Jones - 2.6.20 - Move xen sources out of kernel-xen-devel. (Don Zickus) libexif-0.6.13-3.fc7 -------------------- * Sun Feb 04 2007 Matthias Clasen - 0.6.13-3 - Package review cleanups - Avoid multilib conflicts by using pregenerated docs lv-4.51-10.fc7 -------------- * Mon Feb 05 2007 Akira TAGOH - 4.51-10 - updated License tag. - clean up spec file for mass package review. (#226112) perl-Devel-Symdump-1:2.07-1.fc7 ------------------------------- * Sat Feb 03 2007 Jose Pedro Oliveira - 1:2.07-1 - Update to 2.07. - Minor corrections/cleanings. perl-HTML-Tagset-3.10-3.fc7 --------------------------- * Sat Feb 03 2007 Jose Pedro Oliveira - 3.10-3 - Minor corrections. * Wed Jul 12 2006 Jesse Keating - 3.10-2.1.1 - rebuild * Fri Feb 03 2006 Jason Vas Dias - 3.10-2.1 - rebuild for new perl-5.8.8 perl-Net-IP-1.25-3.fc7 ---------------------- * Sun Feb 04 2007 Robin Norwood - 1.25-3 - Resolves: bz#226271 - Incorporate some fixes to the spec file from Ville: postgresql-8.2.2-1.fc7 ---------------------- * Sun Feb 04 2007 Tom Lane 8.2.2-1 - Update to PostgreSQL 8.2.2 to fix CVE-2007-0555, CVE-2007-0556 Related: #225496 procps-3.2.7-10 --------------- * Mon Feb 05 2007 Karel Zak 3.2.7-10 - fix #212637 - sysctl using deprecated syscall - fix #140975 - top corrupts screen when sorting on first column * Tue Jan 30 2007 Karel Zak 3.2.7-9 - fix procps_version in FAQ patch (thanks to Ian Kent) selinux-policy-2.5.2-5.fc7 -------------------------- * Sun Feb 04 2007 Dan Walsh 2.5.2-5 - Fix ssh_agent to be marked as an executable - Allow Hal to rw sound device tcl-8.5a5-7.fc7 --------------- * Sun Feb 04 2007 Jakub Jelinek - 8.5a5-7 - fix broken stack checking code (#226785) * Thu Jan 25 2007 Marcela Maslanova - 8.5a5-6 - rebuilt for obsoletes rhbz#217735 * Thu Jan 25 2007 Marcela Maslanova - 8.5a5-5 - rebuilt xorg-x11-server-1.2.0-5.fc7 --------------------------- * Sun Feb 04 2007 Adam Jackson 1.2.0-5 - Massive spec formatting and style cleanup. - Build Xdmx on all arches. - Enable GL support even on non-DRI machines. - Re-add DRI to ppc64. - Update BuildRequires to current versions. - Remove some bogus Requires. Broken deps for i386 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.i386 requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc64 requires kdelibs-devel >= 6:3.5.6 pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ppc64 requires libtk8.4.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.x86_64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.i386 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.x86_64 requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.i386 requires kdelibs-devel >= 6:3.5.6 pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so kdebase - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ppc requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ppc requires kdelibs-devel >= 6:3.5.6 pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtcl8.4.so ruby-libs - 1.8.5.2-1.fc7.ppc requires libtk8.4.so Broken deps for s390 ---------------------------------------------------------- kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtk8.4.so ruby-tcltk - 1.8.5.2-1.fc7.s390 requires libtcl8.4.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) kdebase - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.ia64 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.ia64 requires kdelibs-devel >= 6:3.5.6 pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.ia64 requires libtk8.4.so()(64bit) Broken deps for s390x ---------------------------------------------------------- kdebase - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdebase - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390x requires kdelibs >= 6:3.5.6 kdegames - 6:3.5.6-0.1.fc6.s390 requires kdelibs >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390 requires kdelibs-devel >= 6:3.5.6 kdesdk-devel - 3.5.6-0.1.fc6.s390x requires kdelibs-devel >= 6:3.5.6 pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtcl8.4.so()(64bit) ruby-tcltk - 1.8.5.2-1.fc7.s390x requires libtk8.4.so()(64bit) From benny+usenet at amorsen.dk Mon Feb 5 12:11:51 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 05 Feb 2007 13:11:51 +0100 Subject: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> Message-ID: >>>>> "DW" == David Woodhouse writes: DW> Obviously, not everyone wants to do quite as much with the MTA as DW> I do. It's also important that it's secure, it's well-documented, DW> and that the configuration file is actually understandable by a DW> human rather than resembling line noise. Exim fulfils those DW> criteria very well, and is a good choice for the whole range of DW> people from newbies to nutters like myself. The configuration file advantage is only because the others are so horrid. Exim's habit of putting conditions at the end instead of at the beginning still confuses me. Postfix is worse though, and noone needs to be told about sendmail. All three have simple configuration if your needs are very simple. /Benny From tmus at tmus.dk Mon Feb 5 12:17:29 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Feb 2007 13:17:29 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070205093443.GA30675@elte.hu> References: <20070205093443.GA30675@elte.hu> Message-ID: Ingo Molnar wrote: > in case you are interested in really bleeding-edge kernel rpms for > fc7/fc6/fc5, i've created the -rt kernel yum repository, which provides > the -rt kernel in rpmized form for i686 and x86_64, updated > daily/bi-daily. The package is named 'kernel-rt' so it does not conflict > with the Fedora kernel package - you can always revert to the Fedora > kernel. It seems my system hangs at some point during IDE initialization... This is the last I see, before the system hangs (does not respond to caps-lock, num-lock etc) --- ICH7: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1880-0x1887, BIOS settings: hda:DMA, hdb:pio --- I'd expect it to continue with: --- Probing IDE interface ide0... hda: HL-DT-ST DVDRAM GSA-4083N, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... ide-floppy driver 0.99.newide --- or something not to too far from it. This is on a ThinkPad T60p (x86_64, dual-core), running x86_64 kernel. I haven't tried a lot of things to get it going yet, but I will! /Thomas From jnovy at redhat.com Mon Feb 5 12:24:11 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 05 Feb 2007 13:24:11 +0100 Subject: Move from TeTeX to TeXLive In-Reply-To: <20070204132929.GB25763@ryvius.pekin.waw.pl> References: <1163146575.2609.7.camel@redhat.usu> <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> <1163166491.2609.45.camel@redhat.usu> <20070204132929.GB25763@ryvius.pekin.waw.pl> Message-ID: <1170678252.2450.24.camel@redhat.usu> On Sun, 2007-02-04 at 14:29 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 10 November 2006 at 14:48, Jindrich Novy wrote: > > On Fri, 2006-11-10 at 13:15 +0000, Jonathan Underwood wrote: > > > http://www.tetexrpm.org/texjive.html > > > > Yes, I made TeXLive upstream aware of Michael's work, so adopting his > > work is also an option. > > How about asking him to become a mainainer for Fedora first and then, if he > doesn't want to, adopting his work. I asked Michael about adoption of texjive already about month ago and got this reply: Due to increased work, a book I'm writing, and a new hobby (snake breeding) - I've pretty much decided to just be a user for awhile (of both Fedora and LaTeX) so that tex packaging I was looking into - I'm not updating what's there anymore, it's dead. So I asked about the texjive project adoption: > Would you mind if I eventually base the new texlive packaging on your > texjive project? Go ahead. I've no problems with it at all if it is of value. So I decided to base the texlive packaging on the Michael's work and the packages should enter the review process shortly. Jindrich From jnovy at redhat.com Mon Feb 5 12:25:40 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 05 Feb 2007 13:25:40 +0100 Subject: Move from TeTeX to TeXLive In-Reply-To: <645d17210702040515x73fb61e4g5d673879c822befc@mail.gmail.com> References: <1163146575.2609.7.camel@redhat.usu> <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> <1163166491.2609.45.camel@redhat.usu> <645d17210702040515x73fb61e4g5d673879c822befc@mail.gmail.com> Message-ID: <1170678340.2450.27.camel@redhat.usu> On Sun, 2007-02-04 at 13:15 +0000, Jonathan Underwood wrote: > On 10/11/06, Jindrich Novy wrote: > > > Note that Michael Peters has already done a lot of work packaging up > > > texlive as RPMs here: > > > > > > http://www.tetexrpm.org/texjive.html > > > > Yes, I made TeXLive upstream aware of Michael's work, so adopting his > > work is also an option. > > > > This announcement of work on TeXLive rpms might well be of interest: > http://www.ntg.nl/pipermail/ntg-context/2007/023275.html > Thanks for the link. Found a rpm bug btw. while trying to rebuild it. (rhbz#227333). Jindrich From sdl.web at gmail.com Mon Feb 5 12:28:08 2007 From: sdl.web at gmail.com (Leo) Date: Mon, 05 Feb 2007 12:28:08 +0000 Subject: Move from TeTeX to TeXLive References: <1163146575.2609.7.camel@redhat.usu> <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> <1163166491.2609.45.camel@redhat.usu> <20070204132929.GB25763@ryvius.pekin.waw.pl> <1170678252.2450.24.camel@redhat.usu> Message-ID: On 2007-02-05, Jindrich Novy said: > On Sun, 2007-02-04 at 14:29 +0100, Dominik 'Rathann' Mierzejewski wrote: >> On Friday, 10 November 2006 at 14:48, Jindrich Novy wrote: >> > On Fri, 2006-11-10 at 13:15 +0000, Jonathan Underwood wrote: >> > > http://www.tetexrpm.org/texjive.html >> > >> > Yes, I made TeXLive upstream aware of Michael's work, so adopting his >> > work is also an option. >> >> How about asking him to become a mainainer for Fedora first and then, if he >> doesn't want to, adopting his work. > > I asked Michael about adoption of texjive already about month ago and > got this reply: > > > Due to increased work, a book I'm writing, and a new hobby (snake > breeding) - I've pretty much decided to just be a user for awhile (of > both Fedora and LaTeX) so that tex packaging I was looking into - I'm > not updating what's there anymore, it's dead. > > > So I asked about the texjive project adoption: > > >> Would you mind if I eventually base the new texlive packaging on your >> texjive project? > > Go ahead. I've no problems with it at all if it is of value. > > > So I decided to base the texlive packaging on the Michael's work and the > packages should enter the review process shortly. > > Jindrich Thank you for the effort. -- Leo (GPG Key: 9283AA3F) From tmus at tmus.dk Mon Feb 5 12:49:02 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Feb 2007 13:49:02 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: References: <20070205093443.GA30675@elte.hu> Message-ID: Thomas M Steenholdt wrote: > Ingo Molnar wrote: >> in case you are interested in really bleeding-edge kernel rpms for >> fc7/fc6/fc5, i've created the -rt kernel yum repository, which >> provides the -rt kernel in rpmized form for i686 and x86_64, updated >> daily/bi-daily. The package is named 'kernel-rt' so it does not >> conflict with the Fedora kernel package - you can always revert to the >> Fedora kernel. > > It seems my system hangs at some point during IDE initialization... > > This is the last I see, before the system hangs (does not respond to > caps-lock, num-lock etc) > --- > ICH7: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x1880-0x1887, BIOS settings: hda:DMA, hdb:pio > --- Ading "nolapic" kernel commandline option, makes boot work a lot better. Now, when hitting Gnome (in FC6) things are dog slow... mouse movement (USB) is jerky etc... *Should* this work or are there system libs or stuff that need updating/rebuilding to work correctly with a dyntick kernel?!? /Thomas From rdieter at math.unl.edu Mon Feb 5 13:43:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Feb 2007 07:43:44 -0600 Subject: Would it make sense to make aspell dictionaries noarch packages? References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > Okay so I'm doing the merge review for aspell and all its lovely > little dictionary packages.... and I got to wondering, because i like > complicating everyone's already overworked lives.... > > Is there a good reason why the dictionaries are arched packages? Yes, unfortunately. If memory serves, aspell dicts actually *used* to be packaged as noarch many moons ago, but it turned out that they were arch-specific afterall. -- Rex From roozbeh at farsiweb.info Mon Feb 5 14:12:53 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 05 Feb 2007 17:42:53 +0330 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> Message-ID: <1170684773.3345.4.camel@shalil.farsiweb.info> On Sun, 2007-02-04 at 09:14 -0900, Jeff Spaleta wrote: > Is there a good reason why the dictionaries are arched packages? The reason is, IIRC, that the binary databases aspell created were not portable between different arches. Don't remember if it was the big-/little-endian problem or what. roozbeh From dwmw2 at infradead.org Mon Feb 5 14:15:13 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 05 Feb 2007 14:15:13 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <45C6F9B1.3010504@olen.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <45C6F9B1.3010504@olen.net> Message-ID: <1170684913.29759.815.camel@pmac.infradead.org> On Mon, 2007-02-05 at 10:32 +0100, Ola Thoresen wrote: > I do not want mail that SA has classified as almost certainly not spam > to be greylisted. > But then I'd like to greylist everything that is not blocked, but that > is still suspicius (I.E. a score lower than N, but higher than M). > > But I geuss this is best solved by talking to the developers of one of > the greylist-milters, to make them add a feature to whitelist email > based on a custom header. (For instance "X-Spam-Level: ***") The simple greylisting implementation I referred to earlier already does that, in just a few lines of Exim ACL code which can be tweaked to implement whatever policy you actually want. Rather than a header in the mail itself, it's triggered by an ACL variable which can be set during ACL processing for various reasons, including a certain threshold of SA points, as well as the 'offences' of being HTML, having no Message-Id: header, having MIME errors, etc. I've been wondering if it's worth including something like that in the Fedora package, as an example rather than being enabled by default. Although it's useful to give examples of how to do such things, it's also important not to make the _default_ configuration too baroque. Debian gets this very wrong, which is why I've been slightly reluctant to include more than the basics in the Fedora package. But these days I suspect that greylisting _is_ counted amongst the basic requirements of a public-facing mail server so I think I'll have to include it. Would you (or anyone else, for that matter) be interested in being a guinea pig to help me assess how easy it is for newbies to Exim to use such a thing if I add it? -- dwmw2 From nphilipp at redhat.com Mon Feb 5 14:54:22 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Feb 2007 15:54:22 +0100 Subject: greylisting and dynamic host IPs, was: Default MTA for Fedora 7 In-Reply-To: <1170674703.29759.758.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> Message-ID: <1170687262.7121.16.camel@gibraltar.stuttgart.redhat.com> On Mon, 2007-02-05 at 11:25 +0000, David Woodhouse wrote: > The point in greylisting is very simple: it's to check that the mail is > coming from a 'proper' mail server which actually does retry mail when > you give a temporary rejection. Some people na?vely delay all incoming > mail (and some outgoing mail too, if they reject at RCPT TO and the > recipient uses callouts) by greylisting indiscriminately. I prefer mail > to be fast in the common case, so I like to delay _only_ mail which > actually looks suspicious in some way, and I prefer _never_ to greylist > mail from a host (IP address) which was already observed to retry in the > past. Note that you should probably only pass at greylisting if an IP is not from one of the "known" ranges of dynamic IPs. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 dominik at greysector.net Mon Feb 5 15:03:43 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 5 Feb 2007 16:03:43 +0100 Subject: Move from TeTeX to TeXLive In-Reply-To: References: <1163146575.2609.7.camel@redhat.usu> <645d17210611100515v71debb1em6693da363779b0e@mail.gmail.com> <1163166491.2609.45.camel@redhat.usu> <20070204132929.GB25763@ryvius.pekin.waw.pl> <1170678252.2450.24.camel@redhat.usu> Message-ID: <20070205150343.GB15152@ryvius.pekin.waw.pl> On Monday, 05 February 2007 at 13:28, Leo wrote: > On 2007-02-05, Jindrich Novy said: [...] > > So I decided to base the texlive packaging on the Michael's work and the > > packages should enter the review process shortly. > > > > Jindrich > > Thank you for the effort. Yes! And thanks for the feedback, too. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dwmw2 at infradead.org Mon Feb 5 16:10:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 05 Feb 2007 16:10:18 +0000 Subject: greylisting and dynamic host IPs, was: Default MTA for Fedora 7 In-Reply-To: <1170687262.7121.16.camel@gibraltar.stuttgart.redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170687262.7121.16.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1170691818.29759.842.camel@pmac.infradead.org> On Mon, 2007-02-05 at 15:54 +0100, Nils Philippsen wrote: > Note that you should probably only pass at greylisting if an IP is not > from one of the "known" ranges of dynamic IPs. Well, as with everything else it's a trade-off. If you receive mail from the same IP address again, you don't know whether it's actually the same host or not. Do you delay it just in case, or do you accept it? That's a local policy decision. These days, people tend to hold on to "dynamic" IP addresses for quite a long time, so I think it's probably worth avoiding greylisting for known resenders even in dynamic ranges. I make no special case for dynamic IP addresses. Actually, one thing which came up on conversation elsewhere quite recently was the idea that we should use a {HELO, IP} tuple to keep track of 'known resenders' instead of _just_ the IP address. That tends to mean that a new host taking over a dynamic IP address will tend not to get the benefit of the historical "known resender" status of that IP. It actually came up in the context of NAT -- it means that you can record _one_ host behind NAT as a 'known resender' but not necessarily grant the same status to the host of compromised Windows machines which may reside behind the same NAT box. You could also expire known resender status for dynamic ranges (or indeed _all_ ranges), if they don't send you mail for a period of time. There's a whole bunch of things you might want to do, and they're all fairly simple variations on the basic implementation. That's one of the reasons why an open-coded implementation in a capable MTA is preferable, in my opinion, to a more opaque 'plugin' to something less flexible. -- dwmw2 From j.w.r.degoede at hhs.nl Mon Feb 5 16:19:20 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 Feb 2007 17:19:20 +0100 Subject: New new package process SUCKS! (read please) Message-ID: <45C75908.8040003@hhs.nl> Hi all, I just went through my first new package under the new process (aka package no 100, so I'm experienced in this). The mail below may seem flamebate but it is mean't very seriously, so please take it seriously. And the new process SUCKS! First of all as discussed earlier the new review with flags is both unclear / not very well documented and much more work then it used to be, without any clear arguments why we needed a new process in the first place -> SUCKS Then I wanted todo an import an it failed as I first needed to be in owners.list and that requires manual intervention by an CVS admin, so now I have the feeling that I need a CVS admin for any fart I want todo -> SUCKS The new ACL design is broken, the ACL's shouldn't work by owners.list, but instead by putting the owner in the acl in the initial import and then owners.list would "just" be used for bugzilla and not for CVS access / ACL, which in turn means that then anyone could be given rights to owners.list as things were -> problem solved. I know things are probably not that easy. But the current solution is not a solution its a cure worse then the disease! IOW it SUCKS! Regards, Hans From michel.salim at gmail.com Mon Feb 5 16:19:23 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 5 Feb 2007 11:19:23 -0500 Subject: expat status Message-ID: <883cfe6d0702050819w560d8568l212dd72cef8805ca@mail.gmail.com> The expat update request was first submitted by Joe Orton back in June: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195888 for some reason, it's also assigned to himself, and the status is still NEW. Has this bug perhaps slipped out of the radar screen? Thanks, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From katzj at redhat.com Mon Feb 5 16:36:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Feb 2007 11:36:42 -0500 Subject: x86_64 live cd/dvd In-Reply-To: <45C366A5.5040400@gmail.com> References: <45C366A5.5040400@gmail.com> Message-ID: <1170693402.5207.1.camel@aglarond.local> On Fri, 2007-02-02 at 17:28 +0100, dragoran wrote: > Is one planed for F7 ? > Test1 only has a i386 one. Yes; it'll likely be a DVD image (but not 4 gigs!) just because of the fact that you want to have all of the bits for people to run x86 apps just like on an x86_64 install Jeremy From katzj at redhat.com Mon Feb 5 16:37:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Feb 2007 11:37:42 -0500 Subject: f7 test: failure in qemu In-Reply-To: <20070202195424.GA25372@devserv.devel.redhat.com> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <20070202195424.GA25372@devserv.devel.redhat.com> Message-ID: <1170693462.5207.3.camel@aglarond.local> On Fri, 2007-02-02 at 14:54 -0500, Alan Cox wrote: > On Fri, Feb 02, 2007 at 11:29:54AM -0800, Ed Swierk wrote: > > I just noticed that. The libata/ide thing seems to be the culprit. I > > am about to try the latest qemu CVS, as a lot of changes have occurred > > since 0.8.2. > > Unless qemu has improved a lot recently you'll have real problems with > ATAPI DMA qemu CVS is actually far better off here... there may still be something lurking, but it does seem to work Jeremy From katzj at redhat.com Mon Feb 5 16:38:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Feb 2007 11:38:53 -0500 Subject: f7 test: failure on nvidia chipset In-Reply-To: <45C5C5CF.8080508@gmail.com> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> <45C5C5CF.8080508@gmail.com> Message-ID: <1170693533.5207.5.camel@aglarond.local> On Sun, 2007-02-04 at 12:38 +0100, dragoran wrote: > for me the livecd does not boot on a nforce4 based system, because it > could not find the root fs. this is because pata_amd does not get > loaded, but I think this is a known issue. > on my laptop ahci/ata_piix it boots fine. It would be somewhat helpful if people who are having problems booting the live CD can file bugs including the output of lspci so that we can try to run all of the problem cases down Jeremy From katzj at redhat.com Mon Feb 5 16:40:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Feb 2007 11:40:09 -0500 Subject: f7 test: failure in qemu In-Reply-To: <1170445419.13309.41.camel@wombat.dlib.indiana.edu> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <1170445419.13309.41.camel@wombat.dlib.indiana.edu> Message-ID: <1170693609.5207.7.camel@aglarond.local> On Fri, 2007-02-02 at 14:43 -0500, Brian Wheeler wrote: > The DVD still dumps garbage on the screen when displaying the boot menu, > though. Yes. Using -std-vga for qemu makes things work. I haven't gotten to the bottom of if this is a qemu bug or a syslinux bug yet Jeremy From mschwendt.tmp0701.nospam at arcor.de Mon Feb 5 16:50:10 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 5 Feb 2007 17:50:10 +0100 Subject: New new package process SUCKS! (read please) In-Reply-To: <45C75908.8040003@hhs.nl> References: <45C75908.8040003@hhs.nl> Message-ID: <20070205175010.45608b6e.mschwendt.tmp0701.nospam@arcor.de> On Mon, 05 Feb 2007 17:19:20 +0100, Hans de Goede wrote: > Hi all, > > I just went through my first new package under the new process (aka > package no 100, so I'm experienced in this). The mail below may seem > flamebate but it is mean't very seriously, so please take it seriously. What?! Do you say there is a new process also for Extras package submissions and not just for the Merge reviews? How many lists do contributors have to follow these days? I've seen a huge "RFC" thread on maintainers-list, but no official announcement of a change in policies or processes. > And the new process SUCKS! The mails that come in via fedora-package-review list confuse my a lot, but so far I haven't found the time to look into any new package review process, so my comment ends here. From dcantrell at redhat.com Mon Feb 5 17:10:16 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 05 Feb 2007 12:10:16 -0500 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1170658571.11071.14.camel@localhost> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <1170643923.2310.0.camel@scrappy.miketc.com> <20070205034222.GB5396@exeter.boston.redhat.com> <1170651808.7629.12.camel@mortise.boston.redhat.com> <1170658571.11071.14.camel@localhost> Message-ID: <1170695416.7629.17.camel@mortise.boston.redhat.com> On Sun, 2007-02-04 at 22:56 -0800, Peter Gordon wrote: > On Mon, 2007-02-05 at 00:03 -0500, David Cantrell wrote: > > python setup.py install > > --root=/var/tmp/repoman-0.4-1.fc7-root-brewbuilder > > running install > > error: invalid Python installation: unable to open /usr/lib/python2.5/config/Makefile (No such file or directory) > > > > It does work on rawhide though. > > Hmm. According to repoquery, that file is part of the python-devel > package in development/FC7, so you should add python-devel as a > BuildRequires to your spec to fix this. > > Actually, I see a couple of other things that may need fixing in the > spec file if you would be so kind for the next EVR bump. :] > > * Source0 should be a fully-qualified URI using macros if > appropriate (i.e., > http://example.com/sources/%{name}-%{version}.tar.gz) > * You don't need to set %debug_package to %nil, since having the > package build as noarch makes rpmbuild automagically not do any > of the normal debuginfo stripping. > * Instead of hardcoding "%{_libdir}/python?.?/site-packages/" into > your %files section, you should instead define the % > python_sitelib macro and use that in your %files. (See the > Packaging/Python page on the wiki for more information.) > > Does this BuildRequires fix it? Yes, and all the above things have been fixed in repoman-0.5. Packages for FC-6 and rawhide are available: http://www.boston.burdell.org/repoman/ Thanks, -- David Cantrell Red Hat / Westford, MA -------------- 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 lsof at nodata.co.uk Mon Feb 5 17:39:10 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 05 Feb 2007 18:39:10 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <1170674703.29759.758.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> Message-ID: <1170697150.3254.4.camel@sb-home.lan> Am Montag, den 05.02.2007, 11:25 +0000 schrieb David Woodhouse: > On Sun, 2007-02-04 at 22:21 -0300, Horst H. von Brand wrote: > > > Exim certainly does the job for me. None of the others do, as far as I > > > can tell. I'd be happy to be corrected on that count though, so I'll > > > elucidate... > > I note you make no pretence at claiming Postfix can do these things; > only arguments that I shouldn't _want_ to. This despite the fact that > they're only _examples_ of the kind of thing people do with mail > servers, and the fact that these are the reasons people come to me and > _ask_ for an account on my systems. > > But despite the fact that it's a complete digression and you seem to > have already conceded the point I was making, it's a subject which > interests me so I'll play along... > > > > I'd like to be able to do greylisting -- but not indiscriminately; I > > > want to greylist only mail which actually looks suspicious in some way, > > > rather than delaying perfectly genuine mail. Mail gets greylisted only > > > if it has some SpamAssassin points, or it's HTML, or it comes from a > > > machine with no reverse DNS or which is listed in a RBL, etc. > > > > The /point/ in greylisting is not to expend any effort on mail that comes > > from suspect origins. > > Resources are cheap, right up to the point the mail is accepted and > delivered to my mailbox. At _that_ point I start to resent it. > > The point in greylisting is very simple: it's to check that the mail is > coming from a 'proper' mail server which actually does retry mail when > you give a temporary rejection. Some people na?vely delay all incoming > mail (and some outgoing mail too, if they reject at RCPT TO and the > recipient uses callouts) by greylisting indiscriminately. I prefer mail > to be fast in the common case, so I like to delay _only_ mail which > actually looks suspicious in some way, and I prefer _never_ to greylist > mail from a host (IP address) which was already observed to retry in the > past. > > > Stopping mail from an RBLed origin or no reverse DNS > > (or non-matching reverse DNS) are other, independent anti-spam > > measures. Sure, they can be integrated into greylisting (milter-greylist > > for sendmail integrates RBLs), but they are still independent. So is > > spamassassin's score, etc. > > You may have been trained to treat them independently because that's all > you're used to being able to do, but personally I don't want to be > limited in that fashion. I _want_ to be able to combine SA score with > other reasons for considering a mail 'suspicious', and use that as a > trigger for stuff like greylisting. > > For someone else, I used a similar set of criteria to trigger Exim's > 'fakereject' feature which allows one to give a 550 rejection but still > actually accept the message. It was configured to 'freeze' the mail on > the queue, and give a URL with the rejection message as well as an > explanation. When the recipient of the bounce went to that URL they > would get a far more coherent explanation of the offences which caused > the mail to be 'rejected', and could complete a captcha to verify that > the mail _is_ genuine and have it unfrozen for delivery. > > That's not something I would normally have done; I prefer just to bounce > and let people fix their sending mail servers if they're broken enough > to get rejected. But the client in this case was adamant that this was > what they wanted, and it allows them to peruse the frozen spam on the > queue for false positives. It's better than accepting it and putting it > into a spam folder, because that way the recipient wouldn't get a > bounce, so they might think their mail is actually going to be read. > > > > Is it possible to do that kind of thing in other MTAs? Without writing > > > or installing external software (or, perhaps, calling out to Exim? :) > > > > Why is "installing external software" (specially if it is written to > > standardized interfaces defined exactly for such uses) off-limits? > > I suppose it isn't off-limits if it's versatile enough to be tweaked to > users' requirements and if it's shipped in Fedora. > > Standardised interfaces are fine, again as long as they're versatile > enough. For a long time, Exim had SpamAssassin support (sa-exim) which > used a similar interface -- running on the mail just after DATA and > giving a decision about whether to accept it or not. That wasn't good > enough for folks who were used to better things, and it was very quickly > replaced with full content scanning support within the ACL language. We > finally dropped sa-exim from the Fedora packages in FE6, after keeping > it around for a long time for compatibility. > > http://fedora.redhat.com/docs/release-notes/fc6/en_US/sn-Extras.html#id2916368 > > > > I also need to be able to run virtual domains on the cluster of mail > > > machines I operate, but I don't really want to set up yet another > > > distributed database; I _already_ have DNS running, after all. I keep > > > aliases for virtual domains in TXT records, > > > > Lousy missuse of DNS, if you ask me. > > DNS is a distributed database which automatically synchronises between > all the machines in the cluster. It also allows me to give 'keys' to > certain users in order that they can modify certain subdomains as they > desire. It was already running; I didn't have to set up a new database. > > Yes, it's 'abuse of DNS'. It's also _extremely_ convenient. If I want > bondage and discipline I'll go back to programming in Modula-3. > > > > and I use Dynamic DNS so > > > that owners of a given virtual domain can update their forwarding > > > records with a trivial script round nsupdate. Currently, that's handled > > > just a few lines of Exim router configuration in the same directory as > > > the above (routers-dns-virtual). Can I do this in any of the other MTAs > > > on offer? > > > > Why does an MTA have to bend over to such abuse of DNS? > > An MTA should be flexible enough that the admin can do what he/she need > to do with with it. Because of the way SMTP works, especially the need > to avoid sending bounces _after_ accepting mail, stuff _does_ need to be > pushed down into the MTA to be done at SMTP time. And in the current > environment, you have to get more and more involved to stay ahead of the > game. I've just highlighted a few of the things I do with it; that's > all. It wasn't an exhaustive list; just a glimpse of how Exim makes the > mail system work much better for _me_ (and my users) than any other MTA > could manage. > > OK, so returning to the original topic... now I've got two kinds of > responses. First the "oh, I think I'll switch to Exim" and now the > somewhat more disingenuous "you shouldn't want to do that anyway" :) > > -- > dwmw2 > Are we really changing the default MTA just because of a cock-up in resolving dependencies? From michel.salim at gmail.com Mon Feb 5 17:45:50 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 5 Feb 2007 12:45:50 -0500 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> References: <45BBE897.9030802@andrei.myip.org> <20070128000656.GW3639@zoidtechnologies.com> <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> Message-ID: <883cfe6d0702050945o2f25f04fra40123bfdf17ac7e@mail.gmail.com> 2007/2/3, Jeffrey C. Ollie : > On Sat, 2007-02-03 at 11:13 -0500, Michel Salim wrote: > > > > It'll be nice if command-completion in bash and zsh can provide the > > list of available services .. otherwise, using zsh, there are > > ease-of-use arguments for having init.d in $PATH > > If you install bash-completion and then type "service TAB" it will show > you a list of all of the services. > Ah! Would be nice to have it selected by default, now that Core and Extras are merging. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From michel.salim at gmail.com Mon Feb 5 17:47:20 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 5 Feb 2007 12:47:20 -0500 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> References: <45BBE897.9030802@andrei.myip.org> <20070128000656.GW3639@zoidtechnologies.com> <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> Message-ID: <883cfe6d0702050947h10cfbe57ia2d06b59d3c8aca2@mail.gmail.com> 2007/2/3, Jeffrey C. Ollie : > On Sat, 2007-02-03 at 11:13 -0500, Michel Salim wrote: > > > > It'll be nice if command-completion in bash and zsh can provide the > > list of available services .. otherwise, using zsh, there are > > ease-of-use arguments for having init.d in $PATH > > If you install bash-completion and then type "service TAB" it will show > you a list of all of the services. > One reason I did not realized bash-completion already does this is that you have to be root (to have /sbin in your path) for the tab-completion to work. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From fedora at camperquake.de Mon Feb 5 17:52:22 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 5 Feb 2007 18:52:22 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <1170697150.3254.4.camel@sb-home.lan> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> Message-ID: <20070205185222.2478a357@banea.int.addix.net> Hi. On Mon, 05 Feb 2007 18:39:10 +0100, nodata wrote: > Are we really changing the default MTA just because of a cock-up in > resolving dependencies? No. We change it because sendmail sucks and needs to die. From jkeating at redhat.com Mon Feb 5 18:58:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Feb 2007 13:58:46 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070205185222.2478a357@banea.int.addix.net> References: <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> Message-ID: <200702051358.46945.jkeating@redhat.com> On Monday 05 February 2007 12:52, Ralf Ertzinger wrote: > > Are we really changing the default MTA just because of a cock-up in > > resolving dependencies? > > No. > We change it because sendmail sucks and needs to die. No, we haven't _changed_ anything. We let yum decide what dep to satisfy smtpdaemon dependencies of mdadm and fetchmail, which happened to be in the Desktop spin that we did for Test 1. We have not made any statement or decision about what might be the "default" MTA should a user actually ask for an MTA. In fact, in the Desktop installer, there is NO CHOICE for an MTA on purpose. Discussions like what are happening here is exactly why I don't want to choose a default one. I'd much rather the Mail Server grouped marked every MTA as 'optional' and the end user has to make a choice. If no choice is made, than the dependency resolver will make a choice, and right now, exim wins because it wins in a sort of all that provide smtpdaemon (shortest name). If somebody packages up the 'aa' package that provides smtpdaemon and plays with alternatives right, 'aa' would win, again because of the sort. I'm tired of this argument, let no mailer be default, other than what wins progamatically by dep resolution. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nigel.metheringham at dev.intechnology.co.uk Mon Feb 5 19:42:04 2007 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 5 Feb 2007 19:42:04 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <200702051358.46945.jkeating@redhat.com> References: <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051358.46945.jkeating@redhat.com> Message-ID: On 5 Feb 2007, at 18:58, Jesse Keating wrote: > If somebody packages up the 'aa' package that provides smtpdaemon and > plays with alternatives right, 'aa' would win, again because of the > sort. I came -><- this close to adding a wishlist item to the Exim bugzilla to change its name to 'a' (or do numerics sort earlier?) Fun fun fun... Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From vonbrand at inf.utfsm.cl Mon Feb 5 19:43:59 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 05 Feb 2007 16:43:59 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: <20070205185222.2478a357@banea.int.addix.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> Message-ID: <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> Ralf Ertzinger wrote: > On Mon, 05 Feb 2007 18:39:10 +0100, nodata wrote: > > Are we really changing the default MTA just because of a cock-up in > > resolving dependencies? > No. > We change it because sendmail sucks and needs to die. Says who? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From fedora at camperquake.de Mon Feb 5 20:18:52 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 5 Feb 2007 21:18:52 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> Message-ID: <20070205211852.73857c53@lain.camperquake.de> Hi. On Mon, 05 Feb 2007 16:43:59 -0300, Horst H. von Brand wrote > > No. > > We change it because sendmail sucks and needs to die. > > Says who? In all the discussions I have witnessed and participated in on this particular subject (on this list and elsewhere) there has never been a significant group wanting to keep sendmail. Heated discussions will be led about what to replace it with, but the usual consensus is that it has to go. From caillon at redhat.com Mon Feb 5 20:19:21 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 Feb 2007 15:19:21 -0500 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> Message-ID: <45C79149.80907@redhat.com> Jeff Spaleta wrote: > Okay so I'm doing the merge review for aspell and all its lovely > little dictionary packages.... and I got to wondering, because i like > complicating everyone's already overworked lives.... I think the plan is to get rid of aspell for FC7, though not sure how feasible that is... From paul at city-fan.org Mon Feb 5 20:38:17 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Feb 2007 20:38:17 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070205211852.73857c53@lain.camperquake.de> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> Message-ID: <1170707897.9391.1.camel@metropolis.intra.city-fan.org> On Mon, 2007-02-05 at 21:18 +0100, Ralf Ertzinger wrote: > Hi. > > On Mon, 05 Feb 2007 16:43:59 -0300, Horst H. von Brand wrote > > > > No. > > > We change it because sendmail sucks and needs to die. > > > > Says who? > > In all the discussions I have witnessed and participated in on this > particular subject (on this list and elsewhere) there has never > been a significant group wanting to keep sendmail. > > Heated discussions will be led about what to replace it with, but > the usual consensus is that it has to go. Perhaps that's because all of us that are quite happy with sendmail know that it's only a "yum install sendmail-cf" away and don't really care if it's the default or not? Paul. From notting at redhat.com Mon Feb 5 20:48:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Feb 2007 15:48:46 -0500 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <883cfe6d0702050945o2f25f04fra40123bfdf17ac7e@mail.gmail.com> References: <45BBE897.9030802@andrei.myip.org> <20070128000656.GW3639@zoidtechnologies.com> <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> <883cfe6d0702050945o2f25f04fra40123bfdf17ac7e@mail.gmail.com> Message-ID: <20070205204846.GG4858@nostromo.devel.redhat.com> Michel Salim (michel.salim at gmail.com) said: > Ah! Would be nice to have it selected by default, now that Core and > Extras are merging. Generally, either people swear by, or swear at, bash-completion. Not much middle ground. Bill From notting at redhat.com Mon Feb 5 21:02:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Feb 2007 16:02:34 -0500 Subject: New new package process SUCKS! (read please) In-Reply-To: <45C75908.8040003@hhs.nl> References: <45C75908.8040003@hhs.nl> Message-ID: <20070205210234.GH4858@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Then I wanted todo an import an it failed as I first needed to be in > owners.list and that requires manual intervention by an CVS admin, so > now I have the feeling that I need a CVS admin for any fart I want todo > -> SUCKS Mmm, hyperbole. Right now, the initial set up of a package needs done by the admin; currently this is adding an entry to the owners.list/ making the directory in CVS. In future it might be 'adding the entry to the package database and setting it up in the build system'. The step will still be needed, even though parts of it may change. Heck, I'd love to get it where the CVS branching stuff isn't a separate step. But that takes time and infrastructure, and there seems to be a dearth of people who want to touch the CVS stuff. > The new ACL design is broken, the ACL's shouldn't work by owners.list, > but instead by putting the owner in the acl in the initial import and > then owners.list would "just" be used for bugzilla and not for CVS > access / ACL, which in turn means that then anyone could be given rights > to owners.list as things were -> problem solved. I know things are > probably not that easy. But the current solution is not a solution its a > cure worse then the disease! IOW it SUCKS! owner in acl == anyone in acl can remove all the other owners. Bill From tmus at tmus.dk Mon Feb 5 20:39:42 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Feb 2007 21:39:42 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702051358.46945.jkeating@redhat.com> References: <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051358.46945.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Monday 05 February 2007 12:52, Ralf Ertzinger wrote: >>> Are we really changing the default MTA just because of a cock-up in >>> resolving dependencies? >> No. >> We change it because sendmail sucks and needs to die. > > No, we haven't _changed_ anything. We let yum decide what dep to satisfy > smtpdaemon dependencies of mdadm and fetchmail, which happened to be in the > Desktop spin that we did for Test 1. We have not made any statement or > decision about what might be the "default" MTA should a user actually ask for > an MTA. In fact, in the Desktop installer, there is NO CHOICE for an MTA on > purpose. > > Discussions like what are happening here is exactly why I don't want to choose > a default one. I'd much rather the Mail Server grouped marked every MTA > as 'optional' and the end user has to make a choice. If no choice is made, > than the dependency resolver will make a choice, and right now, exim wins > because it wins in a sort of all that provide smtpdaemon (shortest name). If > somebody packages up the 'aa' package that provides smtpdaemon and plays with > alternatives right, 'aa' would win, again because of the sort. > > I'm tired of this argument, let no mailer be default, other than what wins > progamatically by dep resolution. > > I'm not going to debate which mailer is best, but I have to say this... Knowing that exim will win a dependency race for for /usr/sbin/sendmail, including the package on the media and installing it by default (even if it's to satisfy a dep.), comes very very close to being a conscious decision. /Thomas From Curtis at GreenKey.net Mon Feb 5 22:12:00 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Mon, 5 Feb 2007 14:12:00 -0800 (PST) Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070205093443.GA30675@elte.hu> References: <20070205093443.GA30675@elte.hu> Message-ID: <20070205221200.9E59E6F071@alopias.GreenKey.net> 10:34am Ingo Molnar said: > > in case you are interested in really bleeding-edge kernel rpms for > fc7/fc6/fc5, i've created the -rt kernel yum repository, which provides > the -rt kernel in rpmized form for i686 and x86_64, updated > daily/bi-daily. The package is named 'kernel-rt' so it does not conflict > with the Fedora kernel package - you can always revert to the Fedora > kernel. > > The -rt kernel has the following main features: it closely tracks Linus' > -git tree, has KVM, high-res timers, dynticks, fully preemptible kernel, > preempt-rcu, plus all the usual upstream stuff that the Fedora kernel > has enabled. (The yum repository pointers at the end of the > announcement.) > What fun, :-) thank you for your efforts. I happen to have a G4 Proliant on my bench this morning so I fired up kernel-rt-2.6.20-1.rt2 and compared it to kernel-2.6.18-1.2869. The first thing I notice in userland is the load average and cpu util under procps stuff is unusually high. Is this just an artifact of RT kernel's better perspective/granularity? Normally quiet daemons, such as udevd and irqbalance, are suddenly registering significant clicks. About 3x to 4x what they were before. Also, running some very simple tools such as tload drive the load average above 1 on the rt kernel. Excessive observer bias? ../C From wart at kobold.org Mon Feb 5 22:42:39 2007 From: wart at kobold.org (Michael Thomas) Date: Mon, 05 Feb 2007 14:42:39 -0800 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <20070205204846.GG4858@nostromo.devel.redhat.com> References: <45BBE897.9030802@andrei.myip.org> <20070128000656.GW3639@zoidtechnologies.com> <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> <883cfe6d0702050945o2f25f04fra40123bfdf17ac7e@mail.gmail.com> <20070205204846.GG4858@nostromo.devel.redhat.com> Message-ID: <45C7B2DF.40506@kobold.org> Bill Nottingham wrote: > Michel Salim (michel.salim at gmail.com) said: >> Ah! Would be nice to have it selected by default, now that Core and >> Extras are merging. > > Generally, either people swear by, or swear at, bash-completion. Not > much middle ground. I'd be one of those swearing at it. If there is going to be any discussion of selecting it by default, I'd kindly ask that all of the network-based completion rules (*cough* yum *cough*) be disabled by default. --Wart From seandarcy2 at gmail.com Mon Feb 5 22:42:33 2007 From: seandarcy2 at gmail.com (sean) Date: Mon, 05 Feb 2007 17:42:33 -0500 Subject: rawhide report: 20070205 changes In-Reply-To: <200702051126.l15BQJMU015863@hs20-bc2-6.build.redhat.com> References: <200702051126.l15BQJMU015863@hs20-bc2-6.build.redhat.com> Message-ID: > > kernel-2.6.20-1.2922.fc7 > ------------------------ > * Sun Feb 04 2007 Dave Jones > - 2.6.20 > - Move xen sources out of kernel-xen-devel. (Don Zickus) > Installing: kernel ####################### [39/89] /sbin/mkinitrd: line 154: 9745 Segmentation fault $ldso --verify $bin > /dev/null 2>&1 /sbin/mkinitrd: line 154: 9746 Segmentation fault $ldso --verify $bin > /dev/null 2>&1 /sbin/mkinitrd: line 154: 9761 Segmentation fault $ldso --verify $bin > /dev/null 2>&1 /sbin/mkinitrd: line 154: 9762 Segmentation fault $ldso --verify $bin > /dev/null 2>&1 ............... rpm -q mkinitrd mkinitrd-6.0.6-3.x86_64 I've seen this before. Anybody else see it? sean From vonbrand at inf.utfsm.cl Mon Feb 5 23:58:07 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 05 Feb 2007 20:58:07 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: References: <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051358.46945.jkeating@redhat.com> Message-ID: <200702052358.l15Nw7ef010976@laptop13.inf.utfsm.cl> Nigel Metheringham wrote: > On 5 Feb 2007, at 18:58, Jesse Keating wrote: > > If somebody packages up the 'aa' package that provides smtpdaemon and > > plays with alternatives right, 'aa' would win, again because of the > > sort. > I came -><- this close to adding a wishlist item to the Exim bugzilla to > change its name to 'a' (or do numerics sort earlier?) > > Fun fun fun... Yep. My suggestion would be "sendmail" --> " " ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jkeating at redhat.com Tue Feb 6 00:27:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Feb 2007 19:27:49 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: References: <200702051358.46945.jkeating@redhat.com> Message-ID: <200702051927.52474.jkeating@redhat.com> On Monday 05 February 2007 15:39, Thomas M Steenholdt wrote: > I'm not going to debate which mailer is best, but I have to say this... > Knowing that exim will win a dependency race for for /usr/sbin/sendmail, > including the package on the media and installing it by default (even if > it's to satisfy a dep.), comes very very close to being a conscious > decision. If you don't have network enabled at install time (and the remote repo enabled), then only the packages on media will be looked at for solving smtpdaemon. If its sendmail, and sendmail alone, it will win. If it's postfix, it will win. Its all in what you put on the media. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michel.salim at gmail.com Tue Feb 6 01:51:16 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 5 Feb 2007 20:51:16 -0500 Subject: Firewire on Fedora 7: summary of troubles Message-ID: <883cfe6d0702051751q47764c88oba3f434ee50cce@mail.gmail.com> There are some regression in the present development tree when it comes to Firewire mass storage (sbp2) support: - kernel revision 1.2919.fc7: -- sbp2 loaded at boot time, but no drive detected -- after unloading and reloading sbp2, the drive is detected, but gnome-volume-manager still does not see it after logging in - kernel revision 1.2922.fc7: -- loading sbp2 causes kernel panic Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From david at fubar.dk Tue Feb 6 03:02:00 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 05 Feb 2007 22:02:00 -0500 Subject: Firewire on Fedora 7: summary of troubles In-Reply-To: <883cfe6d0702051751q47764c88oba3f434ee50cce@mail.gmail.com> References: <883cfe6d0702051751q47764c88oba3f434ee50cce@mail.gmail.com> Message-ID: <1170730920.2907.137.camel@zelda.fubar.dk> On Mon, 2007-02-05 at 20:51 -0500, Michel Salim wrote: > -- after unloading and reloading sbp2, the drive is detected, but > gnome-volume-manager still does not see it after logging in hal probably needs to be taught about the new Firewire stack; not hard, I'll look at this tomorrow when I seize my Firewire drives from krh :-) David From rc040203 at freenet.de Tue Feb 6 03:02:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Feb 2007 04:02:33 +0100 Subject: New new package process SUCKS! (read please) In-Reply-To: <20070205210234.GH4858@nostromo.devel.redhat.com> References: <45C75908.8040003@hhs.nl> <20070205210234.GH4858@nostromo.devel.redhat.com> Message-ID: <1170730953.1254.172.camel@mccallum.corsepiu.local> On Mon, 2007-02-05 at 16:02 -0500, Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > The new ACL design is broken, the ACL's shouldn't work by owners.list, > > but instead by putting the owner in the acl in the initial import and > > then owners.list would "just" be used for bugzilla and not for CVS > > access / ACL, which in turn means that then anyone could be given rights > > to owners.list as things were -> problem solved. I know things are > > probably not that easy. But the current solution is not a solution its a > > cure worse then the disease! IOW it SUCKS! > > owner in acl == anyone in acl can remove all the other owners. And where is the problem? Spell: Trust Spell: VCS Ralf From cmadams at hiwaay.net Tue Feb 6 03:04:58 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 5 Feb 2007 21:04:58 -0600 Subject: Default MTA for Fedora 7 In-Reply-To: <20070205211852.73857c53@lain.camperquake.de> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> Message-ID: <20070206030458.GS1488683@hiwaay.net> Once upon a time, Ralf Ertzinger said: > In all the discussions I have witnessed and participated in on this > particular subject (on this list and elsewhere) there has never > been a significant group wanting to keep sendmail. That's because people get flamed to a crisp when they even suggest sendmail. I still use it on almost all of my servers. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wart at kobold.org Tue Feb 6 05:56:06 2007 From: wart at kobold.org (Wart) Date: Mon, 05 Feb 2007 21:56:06 -0800 Subject: FC7t1 + kickstart Message-ID: <45C81876.2080606@kobold.org> I didn't see any anaconda bugs filed against fc7t1 in BZ for this, so I thought I'd check here first to make sure I'm not doing something stupid: I have a kickstart file for FC7t1 that was generated from an earlier FC7t1 install, but with an additional small %post section at the end: %post echo foo > /root/foo.txt However, it doesn't appear that the %post section ever gets run. The 'foo.txt' file never gets created. Is anaconda the right component to file a bug against? --Wart From Curtis at GreenKey.net Tue Feb 6 06:23:50 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Mon, 5 Feb 2007 22:23:50 -0800 (PST) Subject: FC7t1 + kickstart In-Reply-To: <45C81876.2080606@kobold.org> References: <45C81876.2080606@kobold.org> Message-ID: <20070206062351.259AF6F072@alopias.GreenKey.net> 9:56pm Wart said: > > I have a kickstart file for FC7t1 that was generated from an earlier FC7t1 > install, but with an additional small %post section at the end: > > %post > echo foo > /root/foo.txt > > However, it doesn't appear that the %post section ever gets run. The > 'foo.txt' file never gets created. Is anaconda the right component to file a > bug against? > I saw this last month in rawhide. My internal notes say, "TODO: %post broken in 2007-01-21 rawhide due to apparent shuffling of setStepList/installSteps". Is it *still* ignoring %post in fc7t1? Ugh. ../C From jfontain at free.fr Tue Feb 6 07:57:57 2007 From: jfontain at free.fr (jfontain at free.fr) Date: Tue, 06 Feb 2007 08:57:57 +0100 Subject: tcl 8.5 alpha in fedora 7? Message-ID: <1170748677.45c8350535560@imp.free.fr> Since tcl-8.5a5 is now in the development tree, is it to be included in fedora 7? Best regards, -- Jean-Luc From lsof at nodata.co.uk Tue Feb 6 07:42:12 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 06 Feb 2007 08:42:12 +0100 Subject: Bug 212424: FIxed for F7? Message-ID: <1170747732.3243.7.camel@sb-home.lan> Hello, Half the time I start Evolution it crashes. After three months of this I am losing my patience.. :/ Does anyone from Red Hat know if https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212424 will be fixed for F7? Thanks a lot. From caolanm at redhat.com Tue Feb 6 08:47:07 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 06 Feb 2007 08:47:07 +0000 Subject: Bug 212424: FIxed for F7? In-Reply-To: <1170747732.3243.7.camel@sb-home.lan> References: <1170747732.3243.7.camel@sb-home.lan> Message-ID: <1170751708.19212.15.camel@soulcrusher.caolan.org> On Tue, 2007-02-06 at 08:42 +0100, nodata wrote: > Hello, > > Half the time I start Evolution it crashes. > > After three months of this I am losing my patience.. :/ > > Does anyone from Red Hat know if > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212424 > will be fixed for F7? Are you sure your problem is #212424 ? That was a very difficult to reproduce crash in OOo around pure virtual methods, which I still reckon is some threading problem in glibc, and only appeared < 3 months ago. Do you have accessibility enabled, perhaps your evo problem is http://bugzilla.gnome.org/show_bug.cgi?id=330728 a well known and long running a11y explosion in evo ? The band-aid I shoved in there looks like it might get included as a short-term solution. C. From benny+usenet at amorsen.dk Tue Feb 6 09:07:44 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 06 Feb 2007 10:07:44 +0100 Subject: greylisting and dynamic host IPs, was: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170687262.7121.16.camel@gibraltar.stuttgart.redhat.com> Message-ID: >>>>> "NP" == Nils Philippsen writes: NP> Note that you should probably only pass at greylisting if an IP is NP> not from one of the "known" ranges of dynamic IPs. The IP I send this from is static. It is also supposedly a "known" dynamic IP. I would agree with you if the dynamic IP lists were actually dynamic IP lists. /Benny From buildsys at redhat.com Tue Feb 6 11:03:38 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 6 Feb 2007 06:03:38 -0500 Subject: rawhide report: 20070206 changes Message-ID: <200702061103.l16B3c8v026093@hs20-bc2-6.build.redhat.com> Updated Packages: GConf2-2.16.0-6.fc7 ------------------- * Mon Feb 05 2007 Matthias Clasen - 2.16.0-6 - Split off a -gtk subpackage to reduce dependencies adjtimex-1.21-2.fc7 ------------------- * Mon Feb 05 2007 Miroslav Lichvar 1.21-2 - spec cleanup (#225239) autofs-1:5.0.1-0.rc3.15 ----------------------- * Tue Feb 06 2007 Ian Kent - 5.0.1-0.rc3.15 - fix race when setting task done (bz 227268). beagle-0.2.15.1-1.fc7 --------------------- * Mon Feb 05 2007 Alexander Larsson - 0.2.15-1 - Update to 0.2.15 bind-31:9.3.4-4.fc7 ------------------- * Mon Feb 05 2007 Adam Tkac 31:9.3.4-4.fc7 - fixed conflict between bind-sdb and ldap - removed duplicated bind directory in bind-libs bug-buddy-1:2.17.3-3.fc7 ------------------------ * Fri Feb 02 2007 Ray Strode - 1:2.17.3-3 - add --vendor gnome back (bug 225629#c5) bzip2-1.0.4-3.fc7 ----------------- * Mon Feb 05 2007 Ivana Varekova 1.0.4-3 - Resolves: 226979 Buffer overflow in bzip2's bzip2recover comps-extras-11.2-2 ------------------- * Mon Feb 05 2007 Jeremy Katz - 11.2-2 - tweaks from package review * Tue Aug 01 2006 Bill Nottingham - 11.2-1 - tweak summary * Thu Mar 02 2006 Bill Nottingham - 11.1-1 - new education icon from Diana Fong - update XFCE icon createrepo-0.4.6-2.fc7 ---------------------- * Mon Feb 05 2007 Paul Nasrat - 0.4.6-2 - Packaging guidelines (#225661) * Thu Nov 09 2006 Paul Nasrat - 0.4.6-1 - Upgrade to latest release - Fix requires (#214388) cryptsetup-luks-1.0.3-4.fc7 --------------------------- * Mon Feb 05 2007 Alasdair Kergon - 1.0.3-4 - Add build dependency on new device-mapper-devel package. - Add preun and post ldconfig requirements. - Update BuildRoot. cscope-15.5-15.3.fc7 -------------------- * Mon Feb 05 2007 Neil Horman -15.5-15.3.dist - Fixing dist label in release tag. dcraw-8.53-2.fc7 ---------------- * Mon Feb 05 2007 Nils Philippsen - 8.53-2 - fix summary, use %find_lang (#225678) devhelp-0.13-3.fc7 ------------------ * Mon Feb 05 2007 Matthias Clasen - 0.13-3 - Fix scriptlet errors device-mapper-1.02.17-5.fc7 --------------------------- * Mon Feb 05 2007 Alasdair Kergon - 1.02.17-5 - Move libdevmapper.so to -devel package. * Mon Feb 05 2007 Alasdair Kergon - 1.02.17-4 - Fix -devel Requires. * Mon Feb 05 2007 Alasdair Kergon - 1.02.17-3 - Move some files into a separate -devel package. device-mapper-multipath-0.4.7-11.fc7 ------------------------------------ * Mon Feb 05 2007 Alasdair Kergon - 0.4.7-11.fc7 - Add build dependency on new device-mapper-devel package. - Add dependency on device-mapper. * Wed Jan 31 2007 Benjamin Marzinksi - 0.4.7-10.fc7 - Update BuildRoot and PreReq lines. dmraid-1.0.0.rc14-2.fc7 ----------------------- * Mon Feb 05 2007 Alasdair Kergon - 1.0.0.rc14-2 - Add build dependency on new device-mapper-devel package. - Add dependency on device-mapper. - Add post and postun ldconfig. - Update BuildRoot and Summary. e2fsprogs-1.39-10 ----------------- * Mon Feb 05 2007 Alasdair Kergon - 1.39-10 - Add build dependency on new device-mapper-devel package. echo-icon-theme-0.1-7.fc7 ------------------------- * Mon Feb 05 2007 Matthias Clasen - 0.1-7 - Neuter macros in %changelog ed-0.4-3 -------- * Mon Feb 05 2007 Karsten Hopp 0.4-3 - clean up spec file for merge review (#225717) elfutils-0.126-1.fc7 -------------------- * Mon Feb 05 2007 Roland McGrath - 0.126-1 - Update to 0.126 - New program eu-ar. - libdw: fix missing dwarf_getelf (#227206) - libdwfl: dwfl_module_addrname for st_size=0 symbols (#227167, #227231) - Resolves: RHBZ #227206, RHBZ #227167, RHBZ #227231 * Wed Jan 10 2007 Roland McGrath - 0.125-3 - Fix overeager warn_unused_result build failures. * Wed Jan 10 2007 Roland McGrath - 0.125-1 - Update to 0.125 - elflint: Compare DT_GNU_HASH tests. - move archives into -static RPMs - libelf, elflint: better support for core file handling - Really fix libdwfl sorting of modules with 64-bit addresses (#220817). - Resolves: RHBZ #220817, RHBZ #213792 esound-1:0.2.36-5.fc7 --------------------- * Mon Feb 05 2007 Matthias Clasen - 1:0.2.36-5 - Also split off a -tools package, and sort the man pages to the right packages fedora-release-6.90-3 --------------------- * Mon Feb 05 2007 Jesse Keating - 6.90-3 - Drop the legacy repo file. * Fri Jan 26 2007 Jesse Keating - 6.90-2 - Core? What Core? * Wed Jan 24 2007 Jeremy Katz - 6.90-1 - Bump to 6.90. Keep working with older release notes file-roller-2.17.90-2.fc7 ------------------------- * Mon Feb 05 2007 Christopher Aillon - 2.17.90-2 - Packaging issues: Remove unneeded desktop-file-utils requires Build with --disable-static fribidi-0.10.7-6.fc7 -------------------- * Mon Feb 05 2007 Caolan McNamara 0.10.7-6 - Resolves: rhbz#225771 spec cleanups ftp-0.17-36.fc7 --------------- * Mon Feb 05 2007 Marcela Maslanova - 0.17-36 - spec fix - rhbz#225774 gcc-4.1.1-55 ------------ * Fri Feb 02 2007 Jakub Jelinek 4.1.1-55 - update from gcc-4_1-branch (-r121069:121479) - PRs c++/28988, fortran/30278, libstdc++/30586, middle-end/29683, objc/27438 - add -march=core2 and -mtune=core2 support (Vlad Makarov) - fix sprintf builtin (PR middle-end/30473) - fix ICE on invalid __thread register on fields (PR c++/30536) - ignore install-info errors in scriptlets (#223687) - rename MNI and mni to SSSE3 and ssse3, keep -m{,no-}mni option and __MNI__ macro for compatibility gdb-6.6-3.fc7 ------------- * Mon Feb 05 2007 Jan Kratochvil - 6.6-3 - Fix a race during attaching to dying threads; backport (BZ 209445). - Testcase of unwinding has now marked its unsolvable cases (for BZ 140532). gnome-audio-2.0.0-4 ------------------- * Mon Feb 05 2007 Alexander Larsson - 2.0.0-4 - Minor specfile cleanups (#225812) gnome-python2-2.17.2-2.fc7 -------------------------- * Mon Feb 05 2007 Matthew Barnes - 2.17.2-2 - Rename spec file to gnome-python2.spec (RH bug #225834). * Mon Jan 08 2007 Matthew Barnes - 2.17.2-1 - Update to 2.17.2 * Sun Jan 07 2007 Matthew Barnes - 2.17.1-1 - Update to 2.17.1 gnome-python2-desktop-2.17.3-3.fc7 ---------------------------------- * Mon Feb 05 2007 Matthew Barnes - 2.17.3-3.fc7 - Add patch for GNOME bug #401760 (plparser fails to build). * Mon Feb 05 2007 Matthew Barnes - 2.17.3-2.fc7 - Rename spec file to gnome-python2-desktop.spec (RH bug #225832). gnome-python2-extras-2.14.2-9.fc7 --------------------------------- * Mon Feb 05 2007 Matthew Barnes - 2.14.2-9.fc7 - Rename spec file to gnome-python2-extras.spec (RH bug #225833). gnome-session-2.17.90.1-2.fc7 ----------------------------- * Mon Feb 05 2007 Matthias Clasen - 2.17.90.1-2 - Require GConf2-gtk for gconf-sanity-check gtksourceview-1.8.3-3.fc7 ------------------------- * Mon Feb 05 2007 Matthias Clasen - 1.8.3-3 - Correct the license tag to say GPL - Rework -devel description hdparm-6.9-2 ------------ * Mon Feb 05 2007 Karsten Hopp 6.9-2 - clean up spec file for merge review (#225882) icu-3.6-16 ---------- * Mon Feb 05 2007 Caolan McNamara - 3.6-16 - Resolves: rhbz#226949 layout telegu like pango kdelibs-6:3.5.6-1.fc7 --------------------- * Mon Feb 05 2007 Than Ngo - 6:3.5.5-1.fc7 - 3.5.6 - apply patch to fix #225420, CVE-2007-0537 Konqueror improper HTML comment rendering, thanks to Dirk M??ller, KDE security team lcms-1.16-2 ----------- * Mon Feb 05 2007 Alexander Larsson - 1.16-2 - Run swig during build to fix warnings in generated code - Fix build on 64bit * Mon Feb 05 2007 Alexander Larsson - 1.16-1 - Update to 1.16 - Specfile cleanups (#225981) - Remove static libs libgcrypt-1.2.4-1 ----------------- * Tue Feb 06 2007 Nalin Dahyabhai - 1.2.4-1 - update to 1.2.4 logwatch-7.3.2-6.fc7 -------------------- * Mon Feb 05 2007 Ivana Varekova 7.3.2-6 - Resolves: 226999 fix audit script lvm2-2.02.21-4.fc7 ------------------ * Mon Feb 05 2007 Alasdair Kergon - 2.02.21-4 - Remove file wildcards and unintentional lvmconf installation. * Mon Feb 05 2007 Alasdair Kergon - 2.02.21-3 - Add build dependency on new device-mapper-devel package. * Wed Jan 31 2007 Alasdair Kergon - 2.02.21-2 - Remove superfluous execute perm from .cache data file. man-pages-ja-20070115-1 ----------------------- * Mon Feb 05 2007 Akira TAGOH - 20070115-1 - updates to 20070115. * Mon Dec 18 2006 Akira TAGOH - 20061215-1 - updates o 20061215. man-pages-ko-1:1.48-15.2.fc7 ---------------------------- * Mon Feb 05 2007 Parag Nemade - 1:1.48-15.2 - Rebuild of package as pert of Core/Extras Merge mcstrans-0.2.1-1.fc7 -------------------- * Mon Feb 05 2007 Dan Walsh 0.2.1-1 - Rewrite to handle MLS properly * Mon Jan 29 2007 Dan Walsh 0.1.10-2 - Cleanup memory when complete mkinitrd-6.0.6-5 ---------------- * Mon Feb 05 2007 Alasdair Kergon - 6.0.6-5 - Add build dependency on new device-mapper-devel package. * Fri Feb 02 2007 David Cantrell - 6.0.6-4 - Rebuild for new libdhcp mtools-3.9.10-4.fc7 ------------------- * Mon Feb 05 2007 Adam Tkac 3.9.10-4.fc7 - fixed some unstandard statements in spec file (#226162) * Mon Jan 22 2007 Adam Tkac 3.9.10-3.fc7 - Resolves: #223712 - applied Ville Skytta's (ville.skytta "antispam" iki.fi) patch (install-info scriptlet failures) * Wed Aug 09 2006 Jitka Kudrnacova - 3.9.10-2 - rebuilt to prevent corruption on the 13th character (#195528) nano-2.0.3-1.fc7 ---------------- * Mon Feb 05 2007 Florian La Roche - 2.0.3-1 - update to 2.0.3 - update spec file syntax, fix scripts rh#220527 openoffice.org-1:2.2.0-5.2 -------------------------- * Mon Feb 05 2007 Caolan McNamara - 1:2.2.0-5.2 - Resolves: rhbz#227245 add openoffice.org-2.2.0.oooXXXXX.atkthreads.atexit.patch - Resolves: rhbz#226737 add openoffice.org-2.2.0.ooo74188.sw.cursorinsideglyph.patch pam_ccreds-4-1 -------------- * Mon Feb 05 2007 Tomas Mraz - 4-1 - new upstream version perl-Convert-ASN1-0.21-1.fc7 ---------------------------- * Sat Feb 03 2007 Jose Pedro Oliveira - 0.21-1 - Update to 0.21. - Corrected several changelog entries. - Removed an explicit perl(Convert::ASN1) provides. * Wed Jul 12 2006 Jesse Keating - 0.20-1.1 - rebuild * Thu Mar 09 2006 Jason Vas Dias - 0.20-1 - upgrade to upstream version 0.20 perl-HTML-Parser-3.56-1.fc7 --------------------------- * Sat Feb 03 2007 Jose Pedro Oliveira - 3.56-1 - Update to 3.56. - Brought specfile closer to the Fedora's Perl template. - Converted specfile to UTF-8 (changelog entries). - Added examples and doc files. perl-HTML-Tagset-3.10-5.fc7 --------------------------- * Mon Feb 05 2007 Robin Norwood - 3.10-5 - perl(Test::Pod) doesn't exist in our buildroots because it isn't in core. Removing for now. * Sun Feb 04 2007 Robin Norwood - 3.10-4 - Also add BuildRequires suggested by Jose. php-pear-1:1.4.11-3 ------------------- * Mon Feb 05 2007 Joe Orton 1:1.4.11-3 - use BuildArch not BuildArchitectures (#226925) - fix to use preferred BuildRoot (#226925) - strip more buildroot-relative paths from *.reg - force correct gpg path in default pear.conf pycairo-1.2.6-3.fc7 ------------------- * Mon Feb 05 2007 Matthew Barnes - 1.2.6-3.fc7 - Incorporate suggestions from package review (RH bug #226329). pygtk2-2.10.4-1.fc7 ------------------- * Mon Feb 05 2007 Matthew Barnes - 2.10.4-1.fc7 - Update to 2.10.4 * Mon Feb 05 2007 Matthew Barnes - 2.10.3-8.fc7 - Rename spec file to pygtk2.spec (RH bug #226333). python-pyblock-0.27-2 --------------------- * Mon Feb 05 2007 Alasdair Kergon - 0.27-2 - Add build dependency on new device-mapper-devel package. ruby-1.8.5.12-1.fc7 ------------------- * Mon Feb 05 2007 Akira TAGOH - 1.8.5.12-1 - New upstream release. scim-hangul-0.2.2-8.fc7 ----------------------- * Tue Feb 06 2007 Akira TAGOH - 0.2.2-8 - cleanups for mass package review. (#226393) wget-1.10.2-14.fc7 ------------------ * Mon Feb 05 2007 Karsten Hopp 1.10.2-14 - shut up rpmlint, even though xx isn't a macro * Mon Feb 05 2007 Karsten Hopp 1.10.2-13 - merge review changes (#226538) - use version/release/... in buildroot tag - remove BR perl - use SMP flags - use make install instead of %makeinstall - include copy of license - use Requires(post)/Requires(preun) - use optflags - remove trailing dot from summary - change tabs to spaces wireshark-0.99.5-1.fc7 ---------------------- * Mon Feb 05 2007 Radek Vok??l 0.99.5-1 - multiple security issues fixed (#227140) - CVE-2007-0459 - The TCP dissector could hang or crash while reassembling HTTP packets - CVE-2007-0459 - The HTTP dissector could crash. - CVE-2007-0457 - On some systems, the IEEE 802.11 dissector could crash. - CVE-2007-0456 - On some systems, the LLT dissector could crash. xorg-sgml-doctools-1.1.1-1.fc7 ------------------------------ xorg-x11-docs-1.3-1.fc7 ----------------------- * Mon Feb 05 2007 Adam Jackson 1.3-1 - Update to 1.3 xorg-x11-drv-nv-1.2.2.1-2.fc7 ----------------------------- * Mon Feb 05 2007 Adam Jackson 1.2.2.1-2 - nv.xinf: Update PCI IDs. (#227346) Broken deps for s390 ---------------------------------------------------------- pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) Broken deps for ia64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) Broken deps for i386 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so Broken deps for ppc ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so Broken deps for s390x ---------------------------------------------------------- pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) From mingo at elte.hu Tue Feb 6 11:36:51 2007 From: mingo at elte.hu (Ingo Molnar) Date: Tue, 6 Feb 2007 12:36:51 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: References: <20070205093443.GA30675@elte.hu> Message-ID: <20070206113651.GA5369@elte.hu> * Thomas M Steenholdt wrote: > >This is the last I see, before the system hangs (does not respond to > >caps-lock, num-lock etc) > >--- > >ICH7: not 100% native mode: will probe irqs later > > ide0: BM-DMA at 0x1880-0x1887, BIOS settings: hda:DMA, hdb:pio > >--- > > Ading "nolapic" kernel commandline option, makes boot work a lot > better. > > Now, when hitting Gnome (in FC6) things are dog slow... mouse movement > (USB) is jerky etc... i suspect this might be the sign of some interrupt problems. > *Should* this work or are there system libs or stuff that need > updating/rebuilding to work correctly with a dyntick kernel?!? yeah, it should be a drop-in replacement, so what you see is a bug either in the -rt kernel or in the upstream kernel. I'm wondering, does rawhide kernel rpm work? It's currently at 2.6.20-1.2922.fc7 which ought to be roughly the same vanilla base as -rt has. So if that kernel works for you then this is a regression in the -rt kernel. Ingo From mingo at elte.hu Tue Feb 6 11:41:15 2007 From: mingo at elte.hu (Ingo Molnar) Date: Tue, 6 Feb 2007 12:41:15 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070205221200.9E59E6F071@alopias.GreenKey.net> References: <20070205093443.GA30675@elte.hu> <20070205221200.9E59E6F071@alopias.GreenKey.net> Message-ID: <20070206114115.GB5369@elte.hu> * Curtis Doty wrote: > What fun, :-) thank you for your efforts. > > I happen to have a G4 Proliant on my bench this morning so I fired up > kernel-rt-2.6.20-1.rt2 and compared it to kernel-2.6.18-1.2869. > > The first thing I notice in userland is the load average and cpu util > under procps stuff is unusually high. Is this just an artifact of RT > kernel's better perspective/granularity? thanks for reporting this, this is indeed a bug in -rt2. What happens is that the RCU priority booster kernel thread is in uninterruptible sleep: $ ps aux | grep -i prio root 31 0.0 0.0 0 0 ? D Feb05 0:00 [RCU Prio Booste] that artificially increases the system load average by +1.0. I've fixed this in my tree and it will be in -rt3 today - it's harmless otherwise. Ingo From sertac.liste at gmail.com Tue Feb 6 12:08:04 2007 From: sertac.liste at gmail.com (=?utf-8?B?U2VydGHDpyDDli4gWcSxbGTEsXo=?=) Date: Tue, 6 Feb 2007 14:08:04 +0200 Subject: /etc/init.d in the default $PATH ? In-Reply-To: <883cfe6d0702050947h10cfbe57ia2d06b59d3c8aca2@mail.gmail.com> References: <45BBE897.9030802@andrei.myip.org> <20070128000656.GW3639@zoidtechnologies.com> <883cfe6d0702030813h7c155d6dx266d5484889b47e2@mail.gmail.com> <1170536355.4339.38.camel@lt21223.campus.dmacc.edu> <883cfe6d0702050947h10cfbe57ia2d06b59d3c8aca2@mail.gmail.com> Message-ID: <20070206120804.GA7088@kerouac> * [05.?ub.07 12:47 -0500] Michel Salim: > 2007/2/3, Jeffrey C. Ollie : > >If you install bash-completion and then type "service TAB" it will show > >you a list of all of the services. > > > One reason I did not realized bash-completion already does this is > that you have to be root (to have /sbin in your path) for the > tab-completion to work. Actually you don?t need to have /sbin in $PATH. Completion works fine if you just type ?service ? or modify the completion function as attached. -- ~serta? -------------- next part -------------- --- /etc/bash_completion.orig 2007-02-06 11:51:08.000000000 +0200 +++ /etc/bash_completion 2007-02-06 13:49:18.000000000 +0200 @@ -546,7 +546,7 @@ # don't complete for things like killall, ssh and mysql if it's # the standalone command, rather than the init script - [[ ${COMP_WORDS[0]} != @(*init.d/!(functions|~)|service) ]] && return 0 + [[ ${COMP_WORDS[0]} != @(*init.d/!(functions|~)|/sbin/service|service) ]] && return 0 # don't complete past 2nd token [ $COMP_CWORD -gt 2 ] && return 0 @@ -554,7 +554,7 @@ [ -d /etc/rc.d/init.d ] && sysvdir=/etc/rc.d/init.d \ || sysvdir=/etc/init.d - if [[ $COMP_CWORD -eq 1 ]] && [[ $prev == "service" ]]; then + if [[ $COMP_CWORD -eq 1 ]] && [[ $prev == "service" || $prev == "/sbin/service" ]]; then _services else COMPREPLY=( $( compgen -W '`sed -ne "y/|/ /; \ From mingo at elte.hu Tue Feb 6 12:41:00 2007 From: mingo at elte.hu (Ingo Molnar) Date: Tue, 6 Feb 2007 13:41:00 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070206114115.GB5369@elte.hu> References: <20070205093443.GA30675@elte.hu> <20070205221200.9E59E6F071@alopias.GreenKey.net> <20070206114115.GB5369@elte.hu> Message-ID: <20070206124100.GA4964@elte.hu> * Ingo Molnar wrote: > $ ps aux | grep -i prio > root 31 0.0 0.0 0 0 ? D Feb05 0:00 [RCU Prio Booste] > > that artificially increases the system load average by +1.0. I've > fixed this in my tree and it will be in -rt3 today - it's harmless > otherwise. fyi, i've just released the -rt3 rpms - can you still see any weirdness? Ingo From mattdm at mattdm.org Tue Feb 6 14:15:37 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Feb 2007 09:15:37 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206030458.GS1488683@hiwaay.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> Message-ID: <20070206141537.GA4293@jadzia.bu.edu> On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: > That's because people get flamed to a crisp when they even suggest > sendmail. I still use it on almost all of my servers. sendmail can do things no other MTA can. Period. 99.44% of people do not need those things, but the remainder _really_ needs them. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From david at lovesunix.net Tue Feb 6 14:42:48 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 06 Feb 2007 15:42:48 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206141537.GA4293@jadzia.bu.edu> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> Message-ID: <1170772969.2992.24.camel@dawkins> tir, 06 02 2007 kl. 09:15 -0500, skrev Matthew Miller: > On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: > > That's because people get flamed to a crisp when they even suggest > > sendmail. I still use it on almost all of my servers. > > sendmail can do things no other MTA can. Period. > > 99.44% of people do not need those things, but the remainder _really_ needs > them. Should we let the needs of less than 1% of users dictate such decisions, especially when: a) Sendmail is not exactly known for being easy to setup b) That less than 1% of people would be more that capable of removing say exim and install sendmail. - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 laroche at redhat.com Tue Feb 6 14:54:17 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 6 Feb 2007 15:54:17 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <1170684913.29759.815.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <45C6F9B1.3010504@olen.net> <1170684913.29759.815.camel@pmac.infradead.org> Message-ID: <20070206145417.GA17304@dudweiler.stuttgart.redhat.com> > Although it's useful to give examples of how to do such things, it's > also important not to make the _default_ configuration too baroque. > Debian gets this very wrong, which is why I've been slightly reluctant > to include more than the basics in the Fedora package. But these days I > suspect that greylisting _is_ counted amongst the basic requirements of > a public-facing mail server so I think I'll have to include it. Including this, but having it commented out sounds very good. > Would you (or anyone else, for that matter) be interested in being a > guinea pig to help me assess how easy it is for newbies to Exim to use > such a thing if I add it? I am ;-) I still run sendmail, but exim has been on my wishlist for a very long time now. regards, Florian La Roche From hughsient at gmail.com Tue Feb 6 15:02:21 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 06 Feb 2007 15:02:21 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <1170772969.2992.24.camel@dawkins> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <1170772969.2992.24.camel@dawkins> Message-ID: <1170774141.10584.2.camel@hughsie-laptop> On Tue, 2007-02-06 at 15:42 +0100, David Nielsen wrote: > Should we let the needs of less than 1% of users dictate such > decisions, > especially when: > > a) Sendmail is not exactly known for being easy to setup > b) That less than 1% of people would be more that capable of removing > say exim and install sendmail. I really don't see what all the fuss is about, the sort of user that can configure sendmail *really* should know how to do "yum install sendmail" Surely the default should be not to include an MTA, I'm guessing a large majority of people never one it anyway (myself included). Richard. From alan at redhat.com Tue Feb 6 15:05:00 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Feb 2007 10:05:00 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206141537.GA4293@jadzia.bu.edu> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> Message-ID: <20070206150500.GA20911@devserv.devel.redhat.com> On Tue, Feb 06, 2007 at 09:15:37AM -0500, Matthew Miller wrote: > sendmail can do things no other MTA can. Period. This is false. Sorry. There is nothing sendmail can do that exim cannot as both are (within the limits of memory) turing complete. From nphilipp at redhat.com Tue Feb 6 15:13:08 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 06 Feb 2007 16:13:08 +0100 Subject: greylisting and dynamic host IPs, was: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170687262.7121.16.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1170774789.15049.4.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-02-06 at 10:07 +0100, Benny Amorsen wrote: > >>>>> "NP" == Nils Philippsen writes: > > NP> Note that you should probably only pass at greylisting if an IP is > NP> not from one of the "known" ranges of dynamic IPs. > > The IP I send this from is static. It is also supposedly a "known" > dynamic IP. I would agree with you if the dynamic IP lists were > actually dynamic IP lists. Weeeell, the dynamic IP I have at home is dynamic, in fact they cut the connection every 24 hours to ensure I get a new IP. No problem because I push all my mails to a machine with a static IP so I don't have to send directly ;-). Anyway, the scheme dwmw2 mentioned (white list IP plus HELO host) should alleviate most false whitelisting due to dynamic IPs. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 clumens at redhat.com Tue Feb 6 15:23:05 2007 From: clumens at redhat.com (Chris Lumens) Date: Tue, 6 Feb 2007 10:23:05 -0500 Subject: FC7t1 + kickstart In-Reply-To: <20070206062351.259AF6F072@alopias.GreenKey.net> References: <45C81876.2080606@kobold.org> <20070206062351.259AF6F072@alopias.GreenKey.net> Message-ID: <20070206152304.GD5396@exeter.boston.redhat.com> > > However, it doesn't appear that the %post section ever gets run. The > > 'foo.txt' file never gets created. Is anaconda the right component to file a > > bug against? > > > > I saw this last month in rawhide. My internal notes say, "TODO: %post > broken in 2007-01-21 rawhide due to apparent shuffling of > setStepList/installSteps". > > Is it *still* ignoring %post in fc7t1? Ugh. In the future, please file bugs when you notice them. We all have a ton of things to do and don't get around to testing and fixing every single thing, so a bug report is a good way to draw our attention to what's wrong. Thanks. - Chris From jkeating at redhat.com Tue Feb 6 15:30:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 10:30:40 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170774141.10584.2.camel@hughsie-laptop> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> Message-ID: <200702061030.43263.jkeating@redhat.com> On Tuesday 06 February 2007 10:02, Richard Hughes wrote: > Surely the default should be not to include an MTA, I'm guessing a large > majority of people never one it anyway (myself included). That would require creating something to take the place of the smtpdaemon requirement of things like mdadm, fetchmail, logwatch, etc... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Feb 6 15:34:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 10:34:20 -0500 Subject: greylisting and dynamic host IPs, was: Default MTA for Fedora 7 In-Reply-To: References: <1170687262.7121.16.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200702061034.20156.jkeating@redhat.com> On Tuesday 06 February 2007 04:07, Benny Amorsen wrote: > The IP I send this from is static. It is also supposedly a "known" > dynamic IP. I would agree with you if the dynamic IP lists were > actually dynamic IP lists. Is it really static, or is it statically assigned through DHCP, making it a crossbreed static/dynamic? If it is within the rest of the dynamic range your ISP uses, then its really hard to tell. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hughsient at gmail.com Tue Feb 6 15:37:24 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 06 Feb 2007 15:37:24 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <200702061030.43263.jkeating@redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061030.43263.jkeating@redhat.com> Message-ID: <1170776244.10584.5.camel@hughsie-laptop> On Tue, 2007-02-06 at 10:30 -0500, Jesse Keating wrote: > That would require creating something to take the place of the > smtpdaemon > requirement of things like mdadm, fetchmail, logwatch, etc... How many "Desktop" users configure logwatch, fetchmail or mdadm? On the server spin sure, but on a Desktop? Richard. From jkeating at redhat.com Tue Feb 6 15:48:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 10:48:54 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170776244.10584.5.camel@hughsie-laptop> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702061030.43263.jkeating@redhat.com> <1170776244.10584.5.camel@hughsie-laptop> Message-ID: <200702061048.54302.jkeating@redhat.com> On Tuesday 06 February 2007 10:37, Richard Hughes wrote: > How many "Desktop" users configure logwatch, fetchmail or mdadm? On the > server spin sure, but on a Desktop? *shrug* I can certainly see mdadm used on a desktop that uses local raid to store important data, like ogg files. Fetchmail is still unfortunately used a lot :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmraz at redhat.com Tue Feb 6 16:06:05 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 06 Feb 2007 17:06:05 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702061048.54302.jkeating@redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702061030.43263.jkeating@redhat.com> <1170776244.10584.5.camel@hughsie-laptop> <200702061048.54302.jkeating@redhat.com> Message-ID: <1170777965.3238.12.camel@perun.kabelta.loc> On Tue, 2007-02-06 at 10:48 -0500, Jesse Keating wrote: > On Tuesday 06 February 2007 10:37, Richard Hughes wrote: > > How many "Desktop" users configure logwatch, fetchmail or mdadm? On the > > server spin sure, but on a Desktop? > > *shrug* I can certainly see mdadm used on a desktop that uses local raid to > store important data, like ogg files. Fetchmail is still unfortunately used > a lot :/ Plus smartd for watching your harddrives and crond and ..... -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From g at socallinuxexpo.org Tue Feb 6 16:16:24 2007 From: g at socallinuxexpo.org (Gareth J. Greenaway) Date: Tue, 6 Feb 2007 08:16:24 -0800 Subject: SCALE finalizes Expo Details Message-ID: <200702060816.24404.g@socallinuxexpo.org> The Southern California Linux Expo is this weekend in Los Angeles. Here are some last minute details: The Expo has added one additional speaker. Doug Hass, Director of Business Development for ImageStream, will speak on ?Advanced Quality of Service and Firewalls using Linux? His presentation covers the key concepts of quality of service and access list filtering using Open Source tools. The presentation includes an explanation of filtering using Linux's iptables tool and standard queuing methods as defined in the Differentiated Services RFC as well as applications of these methods through generic case studies. The Expo has added another BOF, ?Schools And Open Source Software?. There are a few BOF (Birds Of a Feather) session slots still available at SCALE on Sunday. If your group needs a meeting room for a BOF, contact gareth at socallinuxexpo.com to reserve one. The current BOFs can be viewed at http://socallinuxexpo.com/scale5x/events/bof.php If you live nearby, and have surplus electronic equipment you'd like to discard, you can bring it to SCALE and dispose of it legally. Access to the drop off point is a bit circuitous; we've created a map showing the approach and departure from the drop off area. If you are bringing equipment to dispose of, make sure you consult the map prior to leaving for the Westin. The map can be found at http://socallinuxexpo.com/scale5x/events/ewaste.php If you don't register ahead of time and have a question about the Expo during the Expo weekend, the SCALE phone number will be manned by Registration personnel during show hours. You can call 877-831-2569 and be routed through the SCALE Asterisk PBX directly to someone at Registration. The Vendor showcases currently booked are IBM with ?Business Innovation Through Linux?, and Verio with ?Linux Virtualization in Action?. The SCALE sponsors have generously donated oodles of prizes for the SCALE raffles. The biggies are: - Silicon Mechanics Rackform iServ R207 - This is a 1U rackmount server with a Dual-Core Intel Xeon CPU - 6-GB Seagate USB 2.0 pocket hard drive (Donated by Silicon Mechanics and Seagate) - Winner's choice of Intel Core 2 Duo or Dual-Core Intel Xeon 5130 Series processor (from Silicon Mechanics and Intel) - Four VIP Tickets to the Ticketmaster Suite at the Clippers VS Bobcats game February 26th at the Staples Center in Los Angeles Winners must be present to receive raffle prizes. SCALE has received a ton of books to disburse during the Expo. Each speaker at SCALE will receive several books to hand out at their session. (E.g., for the best question during a Q&A session). SCALE will be February 9-11, at The Westin LAX Hotel. Expo information and registration is available at http://socallinuxexpo.com/ Come join us for the best Open Source show on the West Coast! -- Gareth J. Greenaway | g at socallinuxexpo.org Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org From fedora at camperquake.de Tue Feb 6 17:02:38 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 6 Feb 2007 18:02:38 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702061048.54302.jkeating@redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702061030.43263.jkeating@redhat.com> <1170776244.10584.5.camel@hughsie-laptop> <200702061048.54302.jkeating@redhat.com> Message-ID: <20070206180238.11d7a3ef@banea.int.addix.net> Hi. On Tue, 6 Feb 2007 10:48:54 -0500, Jesse Keating wrote: > *shrug* I can certainly see mdadm used on a desktop that uses local > raid to store important data, like ogg files. Fetchmail is still > unfortunately used a lot :/ Well, there certainly needs to be a way to tell users that one of their hard disks is about to die. Maybe (stupid idea, I know) something that talks to the notification daemon when smart or mdadm send a mail. From dwmw2 at infradead.org Tue Feb 6 17:05:42 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 17:05:42 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206150500.GA20911@devserv.devel.redhat.com> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> Message-ID: <1170781542.7155.32.camel@hades.cambridge.redhat.com> On Tue, 2007-02-06 at 10:05 -0500, Alan Cox wrote: > On Tue, Feb 06, 2007 at 09:15:37AM -0500, Matthew Miller wrote: > > sendmail can do things no other MTA can. Period. > > This is false. Sorry. There is nothing sendmail can do that exim > cannot as both are (within the limits of memory) turing complete. Well, Exim's ACLs aren't _quite_ Turing-complete because it limits recursion to about 20 calls iirc. But that doesn't stop silly people like Tony from doing this: http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20050328/msg00086.html I have actually used recursion in ACLs for real: http://david.woodhou.se/eximconf/include/acl-helo-csv I think the rewrite rules are Turing-complete. Matthew, do you have any _examples_ of things which you believe can't be done in Exim? -- dwmw2 From alan at redhat.com Tue Feb 6 17:09:57 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Feb 2007 12:09:57 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170781542.7155.32.camel@hades.cambridge.redhat.com> References: <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <1170781542.7155.32.camel@hades.cambridge.redhat.com> Message-ID: <20070206170957.GA30288@devserv.devel.redhat.com> On Tue, Feb 06, 2007 at 05:05:42PM +0000, David Woodhouse wrote: > On Tue, 2007-02-06 at 10:05 -0500, Alan Cox wrote: > > On Tue, Feb 06, 2007 at 09:15:37AM -0500, Matthew Miller wrote: > > > sendmail can do things no other MTA can. Period. > > > > This is false. Sorry. There is nothing sendmail can do that exim > > cannot as both are (within the limits of memory) turing complete. > > Well, Exim's ACLs aren't _quite_ Turing-complete because it limits > recursion to about 20 calls iirc. But that doesn't stop silly people So use the iterative version of the algorithm I do like the fact the silly hacks like hanoi are readable in exim 8) From benny+usenet at amorsen.dk Tue Feb 6 17:21:57 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 06 Feb 2007 18:21:57 +0100 Subject: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> Message-ID: >>>>> "MM" == Matthew Miller writes: MM> On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: >> That's because people get flamed to a crisp when they even suggest >> sendmail. I still use it on almost all of my servers. MM> sendmail can do things no other MTA can. Period. MM> 99.44% of people do not need those things, but the remainder MM> _really_ needs them. Is there really anything useful left which exim can't do? UUCP bang paths are the only limitation I can think of off the cuff, and hopefully noone uses those. Exim can do UUCP with domain addressing though, if anyone still uses UUCP. /Benny From mattdm at mattdm.org Tue Feb 6 17:20:29 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Feb 2007 12:20:29 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170772969.2992.24.camel@dawkins> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <1170772969.2992.24.camel@dawkins> Message-ID: <20070206172029.GA19254@jadzia.bu.edu> On Tue, Feb 06, 2007 at 03:42:48PM +0100, David Nielsen wrote: > > 99.44% of people do not need those things, but the remainder _really_ > > needs them. > Should we let the needs of less than 1% of users dictate such decisions, > especially when: Dictate? No. Sendmail definitely shouldn't be the default. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Feb 6 17:21:50 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Feb 2007 12:21:50 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <200702061030.43263.jkeating@redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061030.43263.jkeating@redhat.com> Message-ID: <20070206172150.GB19254@jadzia.bu.edu> On Tue, Feb 06, 2007 at 10:30:40AM -0500, Jesse Keating wrote: > > Surely the default should be not to include an MTA, I'm guessing a large > > majority of people never one it anyway (myself included). > That would require creating something to take the place of the smtpdaemon > requirement of things like mdadm, fetchmail, logwatch, etc... Yes, what's Really Needed (tm) is a very lightweight smtpdaemon designed to fill this need and nothing more. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Feb 6 17:23:38 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Feb 2007 12:23:38 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206150500.GA20911@devserv.devel.redhat.com> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> Message-ID: <20070206172338.GC19254@jadzia.bu.edu> On Tue, Feb 06, 2007 at 10:05:00AM -0500, Alan Cox wrote: > > sendmail can do things no other MTA can. Period. > This is false. Sorry. There is nothing sendmail can do that exim cannot as > both are (within the limits of memory) turing complete. Well, sure, and we have the source and all. So add "without significant coding". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dblistsub-fedora at yahoo.it Tue Feb 6 17:26:54 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Tue, 6 Feb 2007 18:26:54 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <1170774141.10584.2.camel@hughsie-laptop> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> Message-ID: <200702061826.54434.dblistsub-fedora@yahoo.it> On Tuesday 06 February 2007 4:02:21 pm Richard Hughes wrote: > Surely the default should be not to include an MTA, I'm guessing a large > majority of people never one it anyway (myself included). If my memory serves me correctly, an MTA is a requirement spelled out in RFC 1123. Having a Unix host without an MTA would surely be surprising, desktop use or not. Davide Bolcioni -- There is no place like /home. From dwmw2 at infradead.org Tue Feb 6 17:37:27 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 17:37:27 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206172338.GC19254@jadzia.bu.edu> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206172338.GC19254@jadzia.bu.edu> Message-ID: <1170783447.7155.41.camel@hades.cambridge.redhat.com> On Tue, 2007-02-06 at 12:23 -0500, Matthew Miller wrote: > On Tue, Feb 06, 2007 at 10:05:00AM -0500, Alan Cox wrote: > > > sendmail can do things no other MTA can. Period. > > This is false. Sorry. There is nothing sendmail can do that exim cannot as > > both are (within the limits of memory) turing complete. > > Well, sure, and we have the source and all. So add "without > significant coding". Don't be disingenuous. Obviously even _postfix_ can manage a bunch of stuff if you're willing to hack on the source code to implement it. Alan was talking about the binaries we ship; just using normal configuration. Do you have examples, or were you just making it up for effect? -- dwmw2 From lsof at nodata.co.uk Tue Feb 6 17:48:03 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 06 Feb 2007 18:48:03 +0100 Subject: Bug 212424: FIxed for F7? In-Reply-To: <1170751708.19212.15.camel@soulcrusher.caolan.org> References: <1170747732.3243.7.camel@sb-home.lan> <1170751708.19212.15.camel@soulcrusher.caolan.org> Message-ID: <1170784083.3168.6.camel@sb-home.lan> Am Dienstag, den 06.02.2007, 08:47 +0000 schrieb Caolan McNamara: > On Tue, 2007-02-06 at 08:42 +0100, nodata wrote: > > Hello, > > > > Half the time I start Evolution it crashes. > > > > After three months of this I am losing my patience.. :/ > > > > Does anyone from Red Hat know if > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212424 > > will be fixed for F7? > > Are you sure your problem is #212424 ? That was a very difficult to > reproduce crash in OOo around pure virtual methods, which I still reckon > is some threading problem in glibc, and only appeared < 3 months ago. > > Do you have accessibility enabled, perhaps your evo problem is > http://bugzilla.gnome.org/show_bug.cgi?id=330728 a well known and long > running a11y explosion in evo ? The band-aid I shoved in there looks > like it might get included as a short-term solution. > > C. > I'm not sure because nobody is commenting on the bug. I reported the evo crash here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215634 From dwmw2 at infradead.org Tue Feb 6 17:55:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 17:55:02 +0000 Subject: qemu 0.9.0 in -devel Message-ID: <1170784502.7155.52.camel@hades.cambridge.redhat.com> I've built qemu 0.9.0 into FE-devel. Please poke at it and scream if you don't want me to put it into FE6. I've already closed UPSTREAM the RFE for kqemu, so don't bother hassling me about it. I would rather roger myself with a chainsaw than muck around with the abomination that is external kernel modules. -- dwmw2 From dwmw2 at infradead.org Tue Feb 6 17:57:27 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 17:57:27 +0000 Subject: Bug 212424: FIxed for F7? In-Reply-To: <1170784083.3168.6.camel@sb-home.lan> References: <1170747732.3243.7.camel@sb-home.lan> <1170751708.19212.15.camel@soulcrusher.caolan.org> <1170784083.3168.6.camel@sb-home.lan> Message-ID: <1170784647.7155.53.camel@hades.cambridge.redhat.com> On Tue, 2007-02-06 at 18:48 +0100, nodata wrote: > > Do you have accessibility enabled, perhaps your evo problem is > > http://bugzilla.gnome.org/show_bug.cgi?id=330728 a well known and long > > running a11y explosion in evo ? The band-aid I shoved in there looks > > like it might get included as a short-term solution. > > > I'm not sure because nobody is commenting on the bug. Of course they're not. Evolution is, to all extents and purposes, unmaintained. -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 6 17:59:57 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 6 Feb 2007 18:59:57 +0100 Subject: qemu 0.9.0 in -devel In-Reply-To: <1170784502.7155.52.camel@hades.cambridge.redhat.com> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> Message-ID: <20070206185957.71efebe6@python3.es.egwn.lan> David Woodhouse wrote : > I've built qemu 0.9.0 into FE-devel. Please poke at it and scream if you > don't want me to put it into FE6. > > I've already closed UPSTREAM the RFE for kqemu, so don't bother hassling > me about it. I would rather roger myself with a chainsaw than muck > around with the abomination that is external kernel modules. Oh, kqemu has been GPL'ed! Neat :-) I'll try to make some dkms enabled packages of it. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.42 0.52 0.57 From david at lovesunix.net Tue Feb 6 18:05:46 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 06 Feb 2007 19:05:46 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702061826.54434.dblistsub-fedora@yahoo.it> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061826.54434.dblistsub-fedora@yahoo.it> Message-ID: <1170785146.9702.4.camel@dawkins> tir, 06 02 2007 kl. 18:26 +0100, skrev Davide Bolcioni: > On Tuesday 06 February 2007 4:02:21 pm Richard Hughes wrote: > > > Surely the default should be not to include an MTA, I'm guessing a large > > majority of people never one it anyway (myself included). > > If my memory serves me correctly, an MTA is a requirement spelled out in RFC > 1123. Having a Unix host without an MTA would surely be surprising, desktop > use or not. RFC 1123: Requirements for Internet Hosts -- Application and Support Would a desktop technically fall into that catagory. Not to mention the same RFC talks of telnet - want telnet by default? old, crufty, insecure - pick any 3. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 jerone at gmail.com Tue Feb 6 18:06:30 2007 From: jerone at gmail.com (Jerone Young) Date: Tue, 6 Feb 2007 12:06:30 -0600 Subject: [RFC] Grub 2 packages for FC7 In-Reply-To: <20070201221121.GA27533@wolff.to> References: <9f50a7a00702010041k3fa7bf29nad1b5a0c211b266c@mail.gmail.com> <20070201221121.GA27533@wolff.to> Message-ID: <9f50a7a00702061006y74910b04x13a15e75cff2569@mail.gmail.com> I have not tried it on raid devices just yet (been distracted for a bit by other misc stuff). But once I get everything submitted to extras I'll have to get a setup to try it out. On 2/1/07, Bruno Wolff III wrote: > On Thu, Feb 01, 2007 at 02:41:39 -0600, > Jerone Young wrote: > > I've got intial packages for FC7 and grub2. This allows grub2 to be > > installed side by side with grub1. This is especially nice as grub2 is > > still in development and some key features are still not there for > > full replacement of grub one. > > Did you try accessing software raid devices with it? When I last tried it > I couldn't get it to recognize md devices. That would be my main reason for > switching to it. > From cmadams at hiwaay.net Tue Feb 6 18:10:45 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 6 Feb 2007 12:10:45 -0600 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206150500.GA20911@devserv.devel.redhat.com> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> Message-ID: <20070206181045.GE1303364@hiwaay.net> Once upon a time, Alan Cox said: > On Tue, Feb 06, 2007 at 09:15:37AM -0500, Matthew Miller wrote: > > sendmail can do things no other MTA can. Period. > > This is false. Sorry. There is nothing sendmail can do that exim cannot as both > are (within the limits of memory) turing complete. milter? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From wart at kobold.org Tue Feb 6 18:16:55 2007 From: wart at kobold.org (Michael Thomas) Date: Tue, 06 Feb 2007 10:16:55 -0800 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1170748677.45c8350535560@imp.free.fr> References: <1170748677.45c8350535560@imp.free.fr> Message-ID: <45C8C617.7000607@kobold.org> jfontain at free.fr wrote: > Since tcl-8.5a5 is now in the development tree, is it to be included in fedora > 7? It appears so, yes. --Wart From dwmw2 at infradead.org Tue Feb 6 18:22:37 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 18:22:37 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206181045.GE1303364@hiwaay.net> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> Message-ID: <1170786157.7155.73.camel@hades.cambridge.redhat.com> On Tue, 2007-02-06 at 12:10 -0600, Chris Adams wrote: > > This is false. Sorry. There is nothing sendmail can do that exim cannot as both > > are (within the limits of memory) turing complete. > > milter? Which one? Arguably we cannot ship Exim in a package named "sendmail" in Fedora -- I'm sure that'd never pass review either -- so perhaps that's another thing that sendmail can do but which Exim can't? If there's _really_ something which we can't do directly in an almost Turing-complete configuration language, then we _can_ call out to dynamically loaded libraries. But in general we don't need to. -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 6 18:25:20 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 6 Feb 2007 19:25:20 +0100 Subject: qemu 0.9.0 in -devel In-Reply-To: <20070206185957.71efebe6@python3.es.egwn.lan> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> <20070206185957.71efebe6@python3.es.egwn.lan> Message-ID: <20070206192520.44e9ef68@python3.es.egwn.lan> Matthias Saou wrote : > > I've already closed UPSTREAM the RFE for kqemu, so don't bother hassling > > me about it. I would rather roger myself with a chainsaw than muck > > around with the abomination that is external kernel modules. > > Oh, kqemu has been GPL'ed! Neat :-) > > I'll try to make some dkms enabled packages of it. http://freshrpms.net/rpm/dkms-kqemu Quickly tested, seems to work fine (x86_64). The only minor detail is one that has already been discussed today on another list : The package itself is "noarch", but it doesn't make sense on anything else than i386 and x86_64... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.06 0.67 0.53 From jspaleta at gmail.com Tue Feb 6 18:27:34 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Feb 2007 09:27:34 -0900 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <45C79149.80907@redhat.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C79149.80907@redhat.com> Message-ID: <604aa7910702061027j1f629d6q9da48c83aea7d8ef@mail.gmail.com> On 2/5/07, Christopher Aillon wrote: > Jeff Spaleta wrote: > > Okay so I'm doing the merge review for aspell and all its lovely > > little dictionary packages.... and I got to wondering, because i like > > complicating everyone's already overworked lives.... > > I think the plan is to get rid of aspell for FC7, though not sure how > feasible that is... Okay well... do we have a a more full list of 'plans' like this? Because aspell is in the merge review list. As much as I love to waste my own time on unimportant work, I'd daresay that other people might be underjoyed to be busting their arses reviewing packages which have been 'planned' to be shown the door. -jef"let's see if I can find another set of packages in the merge list that are fated for the dust bin. Or perhaps its just my superpower.. perhaps the mere fact that I am attempting to review packages causes ripples back through time which change history making that software obsolete. Let's see what happens when I try to review evo."spaleta From cmadams at hiwaay.net Tue Feb 6 18:28:51 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 6 Feb 2007 12:28:51 -0600 Subject: Default MTA for Fedora 7 In-Reply-To: <1170786157.7155.73.camel@hades.cambridge.redhat.com> References: <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> <1170786157.7155.73.camel@hades.cambridge.redhat.com> Message-ID: <20070206182851.GF1303364@hiwaay.net> Once upon a time, David Woodhouse said: > On Tue, 2007-02-06 at 12:10 -0600, Chris Adams wrote: > > > This is false. Sorry. There is nothing sendmail can do that exim cannot as both > > > are (within the limits of memory) turing complete. > > > > milter? > > Which one? sendmail has milter - exim does not (at least as shipped by Fedora AFAICT). No amount of configuration language is going to change that (unless exim's config language allows you to open TCP sockets and talk the milter protocol). Also, exim does not provide the libmilter client library. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Tue Feb 6 18:34:12 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 13:34:12 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206141537.GA4293@jadzia.bu.edu> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> Message-ID: <20070206183412.GC29861@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > sendmail can do things no other MTA can. Period. > > 99.44% of people do not need those things, but the remainder _really_ needs > them. 0.56% of people need Towers of Hanoi? (don't mind me, just passing through...) Bill From notting at redhat.com Tue Feb 6 18:35:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 13:35:20 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206172150.GB19254@jadzia.bu.edu> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061030.43263.jkeating@redhat.com> <20070206172150.GB19254@jadzia.bu.edu> Message-ID: <20070206183519.GD29861@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > Yes, what's Really Needed (tm) is a very lightweight smtpdaemon designed to > fill this need and nothing more. ssmtp? Bill From pbrobinson at gmail.com Tue Feb 6 18:51:49 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 6 Feb 2007 18:51:49 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> Message-ID: <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> > >>>>> "MM" == Matthew Miller writes: > > MM> On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: > >> That's because people get flamed to a crisp when they even suggest > >> sendmail. I still use it on almost all of my servers. > > MM> sendmail can do things no other MTA can. Period. > > MM> 99.44% of people do not need those things, but the remainder > MM> _really_ needs them. > > Is there really anything useful left which exim can't do? UUCP bang > paths are the only limitation I can think of off the cuff, and > hopefully noone uses those. Exim can do UUCP with domain addressing > though, if anyone still uses UUCP. Yes, I have a few sites that require it.... but then I also know how to 'yum install sendmail' too, as I'm sure just about everyone who uses UUCP does, or else compiles sendmail themsleves. Peter From bernd.bartmann at gmail.com Tue Feb 6 18:52:24 2007 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Tue, 6 Feb 2007 19:52:24 +0100 Subject: FC7T1 and Bugzilla product / version In-Reply-To: <1170629533.3236.0.camel@sb-home.lan> References: <6c18a4f0702031146y33ee1d49pe5f13b9d63bb104c@mail.gmail.com> <200702031453.21547.jkeating@redhat.com> <1170538978.6858.21.camel@localhost.localdomain> <200702031648.15855.jkeating@redhat.com> <20070203220248.GA8211@nostromo.devel.redhat.com> <1170541201.6858.28.camel@localhost.localdomain> <883cfe6d0702031452m7ebbe0d6o8a80399bd4c2d180@mail.gmail.com> <1170546114.9699.0.camel@sb-home.lan> <883cfe6d0702031956x361abb33ra8b651df4278e338@mail.gmail.com> <1170629533.3236.0.camel@sb-home.lan> Message-ID: <6c18a4f0702061052s2e4eb7fct53eb3a14ee1d3ab@mail.gmail.com> So what is the conclusion of this discussion so far: use Bugzilla Product "Fedora Core" and version "devel" or "fc7test1" (which is suddenly available in Bugzilla without further notice)? I think it would be good if we can get some kind of "official" statement here. Will? Also, a notice about the correct product / version should appear in the announcements of upcoming test releases. Best regards, Bernd. From cmadams at hiwaay.net Tue Feb 6 18:53:21 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 6 Feb 2007 12:53:21 -0600 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206183412.GC29861@nostromo.devel.redhat.com> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206183412.GC29861@nostromo.devel.redhat.com> Message-ID: <20070206185321.GG1303364@hiwaay.net> Once upon a time, Bill Nottingham said: > Matthew Miller (mattdm at mattdm.org) said: > > sendmail can do things no other MTA can. Period. > > > > 99.44% of people do not need those things, but the remainder _really_ needs > > them. > > 0.56% of people need Towers of Hanoi? (don't mind me, just passing > through...) Alan is the one who brought that up, and IIRC in relation to exim, not sendmail. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From caillon at redhat.com Tue Feb 6 19:26:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 06 Feb 2007 14:26:05 -0500 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <604aa7910702061027j1f629d6q9da48c83aea7d8ef@mail.gmail.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C79149.80907@redhat.com> <604aa7910702061027j1f629d6q9da48c83aea7d8ef@mail.gmail.com> Message-ID: <45C8D64D.7020901@redhat.com> Jeff Spaleta wrote: > On 2/5/07, Christopher Aillon wrote: >> Jeff Spaleta wrote: >> > Okay so I'm doing the merge review for aspell and all its lovely >> > little dictionary packages.... and I got to wondering, because i like >> > complicating everyone's already overworked lives.... >> >> I think the plan is to get rid of aspell for FC7, though not sure how >> feasible that is... > > Okay well... do we have a a more full list of 'plans' like this? > Because aspell is in the merge review list. As much as I love to waste > my own time on unimportant work, I'd daresay that other people might > be underjoyed to be busting their arses reviewing packages which have > been 'planned' to be shown the door. Personally, I believe it's way too early to do these reviews in the first place. They find mostly inconsequential, 20-second spec issues, that are perfect for fixing after test2 when the package lists are finalized and these types of fixes are the on the short list of fixes we should be taking. But I suppose that getting people to do the amount of reviews in that short of a time frame is not a good idea, so good thing for everyone doing the work that it's not up to me. From green at redhat.com Tue Feb 6 19:32:30 2007 From: green at redhat.com (Anthony Green) Date: Tue, 06 Feb 2007 11:32:30 -0800 Subject: Creating a jackuser group Message-ID: <1170790351.3564.12.camel@localhost.localdomain> fedora-music-list hosted a thread[1] recently on making it easier to run the jack-audio-connection-kit server. It's a bit of a mess right now because users have to manually edit /etc/security/limits.conf before anything will run. In order to clean things up, it was proposed that Fedora come pre-installed with a jackuser entry in /etc/group, as well as including the following in /etc/security/limits.conf... @jackuser - rtprio 20 @jackuser - memlock 131072 Then users simply need to be added to the jackuser group in order to run jackd and associated applications. I believe this models what other distros are doing to support jack users. We could even have a consolehelper enabled wrapper to ask users if they want to be added to this group if they aren't already when the run qjackctl. Most of the discussion is captured in mail threads referenced by this bugzilla entry.... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221785 So, if this sounds like a sane thing to do for Fedora 7, do I simply file bugzilla issues against the setup and pam packages (which own /etc/group and /etc/security/limits.conf respectively). Any comments? Thanks, AG [1] http://www.mail-archive.com/fedora-music-list at redhat.com/index.html#00121 From jspaleta at gmail.com Tue Feb 6 19:55:46 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Feb 2007 10:55:46 -0900 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <45C8D64D.7020901@redhat.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C79149.80907@redhat.com> <604aa7910702061027j1f629d6q9da48c83aea7d8ef@mail.gmail.com> <45C8D64D.7020901@redhat.com> Message-ID: <604aa7910702061155m3421bb28m18c2a60e3c15a0c@mail.gmail.com> On 2/6/07, Christopher Aillon wrote: > Personally, I believe it's way too early to do these reviews in the > first place. Or... its way too late... depending on your pov. > But I suppose that getting people to do the amount of > reviews in that short of a time frame is not a good idea, Even with the time we have now... its not clear to me its going to get done... if it comes down to relying on people like me, who are stupifyingly slow at doing reviews. -jef"More than slightly concerned over what's going to happen when a large group of hatters get reviewing rights at about the same time to speed up the core merge review process, and as a group gripe about particular review process guidance.. or worse, ignore items without griping to save time because their managers are leaning on them to get core items reviewed by a deadline. We still have a long way to go sorting out corporate versus community culture clash side-effects."spaleta From pekkas at netcore.fi Tue Feb 6 20:04:52 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 6 Feb 2007 22:04:52 +0200 (EET) Subject: WLAN: link must be UP before ESSID is set Message-ID: Hi, On new USB stick WLAN interface (driver zd1211rw) it seems that the 'ip link set $DEVICE up' needs to be done before ESSID is set for the card to come up at all. (On the other hand, for example, the old orinoco_cs doesn't require this.) Even though DHCP client (run after ESSID is set) brings up the link, the WLAN card is not associated to the AP (the state as shown below), and IP doesn't work yet. zd1211rw people had the opinion that this is a problem with ifup: "This is a distro bug - it should bring the interface up before using it. Many drivers require the interface to be up before scanning is possible, since for a lot of hardware, scanning is just transmission and reception of frames so requires the entire MAC layer to be activated just the same as if you were transmitting/receiving data." Should this be fixed by setting the link up before setting ESSID in ifup-wireless (or even before setting some other iwconfig options)? Is there any drawback in doing so? (At least it seems to me that you may not be able to specify a new MACADDR if this was done.) Is there already a bug report on this (based on very quick search I couldn't find one)? eth1 IEEE 802.11b/g ESSID:"S" Nickname:"zd1211" Mode:Managed Frequency:2.412 GHz Access Point: Invalid Bit Rate=1 Mb/s Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jspaleta at gmail.com Tue Feb 6 20:06:23 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Feb 2007 11:06:23 -0900 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <45C6F044.5010002@gmail.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C6F044.5010002@gmail.com> Message-ID: <604aa7910702061206t15953b39kf283fb9e85863f6c@mail.gmail.com> On 2/4/07, dragoran wrote: > Jeff Spaleta wrote: > > For reference: > > https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c6 > > > bug nr.? (your link is broken) silly bugzilla bugticket: 225286 though this pretty much affects all the aspell dictionaries as well. Are the dictionaries /usr/share/ data or are the /usr/lib/ data? Are they arch specific or are they not? How do I as a mere mortal, without access to a ppc machine... test whether the dictionary payloads are plagued with big-endian/little-endian issues or other potential arch-specific issues? And does it matter... if aspell is going to hit the dustbin of history? -jef"trying very very hard to ignore wtf is going on with the latex stack as long as possible, but fears he's going to have to go readup and possibly burn cycles on that issue for his own reasons if things haven't resolved into an obvious direction forward by now"spaleta From wtogami at redhat.com Tue Feb 6 20:12:31 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 15:12:31 -0500 Subject: Creating a jackuser group In-Reply-To: <1170790351.3564.12.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> Message-ID: <45C8E12F.9060202@redhat.com> Anthony Green wrote: > fedora-music-list hosted a thread[1] recently on making it easier to run > the jack-audio-connection-kit server. It's a bit of a mess right now > because users have to manually edit /etc/security/limits.conf before > anything will run. > > In order to clean things up, it was proposed that Fedora come > pre-installed with a jackuser entry in /etc/group, as well as including > the following in /etc/security/limits.conf... > > @jackuser - rtprio 20 > @jackuser - memlock 131072 > > Then users simply need to be added to the jackuser group in order to run > jackd and associated applications. I believe this models what other > distros are doing to support jack users. We could even have a > consolehelper enabled wrapper to ask users if they want to be added to > this group if they aren't already when the run qjackctl. > > Most of the discussion is captured in mail threads referenced by this > bugzilla entry.... > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221785 > > So, if this sounds like a sane thing to do for Fedora 7, do I simply > file bugzilla issues against the setup and pam packages (which > own /etc/group and /etc/security/limits.conf respectively). > Where do we draw the line between add-on software that should have a default user or group, and packages that have to create their own? Doesn't Apache in Core create its own? Warren Togami wtogami at redhat.com From dcbw at redhat.com Tue Feb 6 20:16:55 2007 From: dcbw at redhat.com (Dan Williams) Date: Tue, 06 Feb 2007 15:16:55 -0500 Subject: WLAN: link must be UP before ESSID is set In-Reply-To: References: Message-ID: <1170793015.5897.3.camel@localhost.localdomain> On Tue, 2007-02-06 at 22:04 +0200, Pekka Savola wrote: > Hi, > > On new USB stick WLAN interface (driver zd1211rw) it seems that the > 'ip link set $DEVICE up' needs to be done before ESSID is set for the > card to come up at all. (On the other hand, for example, the old > orinoco_cs doesn't require this.) > > Even though DHCP client (run after ESSID is set) brings up the link, > the WLAN card is not associated to the AP (the state as shown below), > and IP doesn't work yet. > > zd1211rw people had the opinion that this is a problem with ifup: > > "This is a distro bug - it should bring the interface up before using > it. Many drivers require the interface to be up before scanning is > possible, since for a lot of hardware, scanning is just transmission > and reception of frames so requires the entire MAC layer to be > activated just the same as if you were transmitting/receiving data." > > Should this be fixed by setting the link up before setting ESSID in > ifup-wireless (or even before setting some other iwconfig options)? Likely, yes. The device should be brought up before setting stuff on it. Some devices don't load firmware until you bring the device up. Ideally though, drivers should be caching the settings that userspace pushes down, and on ifup blasting those settings to firmware. But many softmac drivers don't yet do this. dan > Is there any drawback in doing so? (At least it seems to me that you > may not be able to specify a new MACADDR if this was done.) > > Is there already a bug report on this (based on very quick search I > couldn't find one)? > > eth1 IEEE 802.11b/g ESSID:"S" Nickname:"zd1211" > Mode:Managed Frequency:2.412 GHz Access Point: Invalid > Bit Rate=1 Mb/s > Encryption key:off > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From jwilson at redhat.com Tue Feb 6 20:16:03 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 6 Feb 2007 15:16:03 -0500 Subject: Creating a jackuser group In-Reply-To: <45C8E12F.9060202@redhat.com> References: <1170790351.3564.12.camel@localhost.localdomain> <45C8E12F.9060202@redhat.com> Message-ID: <200702061516.08682.jwilson@redhat.com> On Tuesday 06 February 2007 15:12, Warren Togami wrote: > Anthony Green wrote: > > fedora-music-list hosted a thread[1] recently on making it easier to run > > the jack-audio-connection-kit server. It's a bit of a mess right now > > because users have to manually edit /etc/security/limits.conf before > > anything will run. > > > > In order to clean things up, it was proposed that Fedora come > > pre-installed with a jackuser entry in /etc/group, as well as including > > the following in /etc/security/limits.conf... > > > > @jackuser - rtprio 20 > > @jackuser - memlock 131072 > > > > Then users simply need to be added to the jackuser group in order to run > > jackd and associated applications. I believe this models what other > > distros are doing to support jack users. We could even have a > > consolehelper enabled wrapper to ask users if they want to be added to > > this group if they aren't already when the run qjackctl. > > > > Most of the discussion is captured in mail threads referenced by this > > bugzilla entry.... > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221785 > > > > So, if this sounds like a sane thing to do for Fedora 7, do I simply > > file bugzilla issues against the setup and pam packages (which > > own /etc/group and /etc/security/limits.conf respectively). > > Where do we draw the line between add-on software that should have a > default user or group, and packages that have to create their own? > > Doesn't Apache in Core create its own? Quite a few packages create their own. I think the big problem here is the need to twiddle limits.conf. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Tue Feb 6 20:18:24 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 06 Feb 2007 21:18:24 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206182851.GF1303364@hiwaay.net> References: <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> <1170786157.7155.73.camel@hades.cambridge.redhat.com> <20070206182851.GF1303364@hiwaay.net> Message-ID: <45C8E290.9080008@camperquake.de> Hi. Chris Adams schrieb: > sendmail has milter - exim does not (at least as shipped by Fedora > AFAICT). No amount of configuration language is going to change that > (unless exim's config language allows you to open TCP sockets and talk > the milter protocol). Also, exim does not provide the libmilter client > library. I was under the impression that milter allowed sendmail to do things (like spam and virus scanning on the fly) that exim can do without external help. If that is so then exim does not have milter because it does not need it. I may be wrong though. From mclasen at redhat.com Tue Feb 6 20:29:32 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 06 Feb 2007 15:29:32 -0500 Subject: Creating a jackuser group In-Reply-To: <45C8E12F.9060202@redhat.com> References: <1170790351.3564.12.camel@localhost.localdomain> <45C8E12F.9060202@redhat.com> Message-ID: <1170793772.27486.1.camel@dhcp83-33.boston.redhat.com> On Tue, 2007-02-06 at 15:12 -0500, Warren Togami wrote: > Anthony Green wrote: > > fedora-music-list hosted a thread[1] recently on making it easier to run > > the jack-audio-connection-kit server. It's a bit of a mess right now > > because users have to manually edit /etc/security/limits.conf before > > anything will run. > > > > In order to clean things up, it was proposed that Fedora come > > pre-installed with a jackuser entry in /etc/group, as well as including > > the following in /etc/security/limits.conf... > > > > @jackuser - rtprio 20 > > @jackuser - memlock 131072 > > > > Then users simply need to be added to the jackuser group in order to run > > jackd and associated applications. I believe this models what other > > distros are doing to support jack users. We could even have a > > consolehelper enabled wrapper to ask users if they want to be added to > > this group if they aren't already when the run qjackctl. > > > > Most of the discussion is captured in mail threads referenced by this > > bugzilla entry.... > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221785 > > > > So, if this sounds like a sane thing to do for Fedora 7, do I simply > > file bugzilla issues against the setup and pam packages (which > > own /etc/group and /etc/security/limits.conf respectively). > > > > Where do we draw the line between add-on software that should have a > default user or group, and packages that have to create their own? > The pulseaudio package also creates a special group pulse-rt and allows only users in that group to run with realtime scheduling. I'm not very happy about that setup, since we want to make pulseaudio the default sound daemon. Can we at least avoid having each audio application create its own private group for realtime privileges ? From vonbrand at inf.utfsm.cl Tue Feb 6 21:08:49 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 06 Feb 2007 18:08:49 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206030458.GS1488683@hiwaay.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> Message-ID: <200702062108.l16L8nos005303@laptop13.inf.utfsm.cl> Chris Adams wrote: > Once upon a time, Ralf Ertzinger said: > > In all the discussions I have witnessed and participated in on this > > particular subject (on this list and elsewhere) there has never > > been a significant group wanting to keep sendmail. > That's because people get flamed to a crisp when they even suggest > sendmail. I still use it on almost all of my servers. So do I. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From benny+usenet at amorsen.dk Tue Feb 6 21:13:04 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 06 Feb 2007 22:13:04 +0100 Subject: greylisting and dynamic host IPs, was: Default MTA for Fedora 7 References: <1170687262.7121.16.camel@gibraltar.stuttgart.redhat.com> <200702061034.20156.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> On Tuesday 06 February 2007 04:07, Benny Amorsen wrote: >> The IP I send this from is static. It is also supposedly a "known" >> dynamic IP. I would agree with you if the dynamic IP lists were >> actually dynamic IP lists. JK> Is it really static, or is it statically assigned through DHCP, JK> making it a crossbreed static/dynamic? If it is within the rest of JK> the dynamic range your ISP uses, then its really hard to tell. It is really really static. No DHCP anywhere. I just don't get to set reverse DNS for it. And yes, it's hard to tell for the lists. The point is that they don't even try. They just split the Internet into corporations and the rest, only allowing corporations to run servers. I could play along and move my server to the company connection of course, but is that really where we want the Internet to go? /Benny From vonbrand at inf.utfsm.cl Tue Feb 6 21:16:51 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 06 Feb 2007 18:16:51 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: <1170776244.10584.5.camel@hughsie-laptop> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061030.43263.jkeating@redhat.com> <1170776244.10584.5.camel@hughsie-laptop> Message-ID: <200702062116.l16LGpL5005408@laptop13.inf.utfsm.cl> Richard Hughes wrote: > On Tue, 2007-02-06 at 10:30 -0500, Jesse Keating wrote: > > That would require creating something to take the place of the > > smtpdaemon > > requirement of things like mdadm, fetchmail, logwatch, etc... > How many "Desktop" users configure logwatch, More useful for the "desktop user" than "servers" (better see a summary of what looks fishy than having to wade through the full logs) > fetchmail This is a /desktop/ program, for mail handling by final users (specially ones with intermittent conectivity). It would be quite out of place on a server, IMHO. > or mdadm? RAID isn't too common right now, but all the (higher-end) desktop machines I've bought lately have RAID controllers built in. > On the > server spin sure, but on a Desktop? Define "desktop system". Many here will describe a development machine, with several services set up for testing and development. Even my notebook would qualify as "server"... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From eswierk at arastra.com Tue Feb 6 21:18:31 2007 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 6 Feb 2007 13:18:31 -0800 Subject: qemu 0.9.0 in -devel In-Reply-To: <1170784502.7155.52.camel@hades.cambridge.redhat.com> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> Message-ID: On 2/6/07, David Woodhouse wrote: > I've built qemu 0.9.0 into FE-devel. Please poke at it and scream if you > don't want me to put it into FE6. The new version causes SYSLINUX to hang when attempting to boot an FC6 diskboot.img. Apparently the problem is in the bios, as replacing bios.bin with the one from qemu 0.8.2 avoids the hang (although this will probably affect guest ACPI functionality). I've reported the problem to the qemu-devel list but there hasn't been any response yet. --Ed From mattdm at mattdm.org Tue Feb 6 21:18:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Feb 2007 16:18:34 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206183519.GD29861@nostromo.devel.redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061030.43263.jkeating@redhat.com> <20070206172150.GB19254@jadzia.bu.edu> <20070206183519.GD29861@nostromo.devel.redhat.com> Message-ID: <20070206211834.GA9176@jadzia.bu.edu> On Tue, Feb 06, 2007 at 01:35:20PM -0500, Bill Nottingham wrote: > Matthew Miller (mattdm at mattdm.org) said: > > Yes, what's Really Needed (tm) is a very lightweight smtpdaemon designed to > > fill this need and nothing more. > ssmtp? Maybe. It'd be nice for it to do something with root (i.e. admin) mail without relying on another host. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Feb 6 21:21:33 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Feb 2007 16:21:33 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170786157.7155.73.camel@hades.cambridge.redhat.com> References: <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> <1170786157.7155.73.camel@hades.cambridge.redhat.com> Message-ID: <20070206212133.GB9176@jadzia.bu.edu> On Tue, Feb 06, 2007 at 06:22:37PM +0000, David Woodhouse wrote: > > > This is false. Sorry. There is nothing sendmail can do that exim cannot as both > > > are (within the limits of memory) turing complete. > > milter? > Which one? Any arbitrary existing one. That's the point. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From green at redhat.com Tue Feb 6 21:33:48 2007 From: green at redhat.com (Anthony Green) Date: Tue, 06 Feb 2007 13:33:48 -0800 Subject: Creating a jackuser group In-Reply-To: <1170793772.27486.1.camel@dhcp83-33.boston.redhat.com> References: <1170790351.3564.12.camel@localhost.localdomain> <45C8E12F.9060202@redhat.com> <1170793772.27486.1.camel@dhcp83-33.boston.redhat.com> Message-ID: <1170797628.3564.35.camel@localhost.localdomain> On Tue, 2007-02-06 at 15:29 -0500, Matthias Clasen wrote: > The pulseaudio package also creates a special group pulse-rt and allows > only users in that group to run with realtime scheduling. I'm not very > happy about that setup, since we want to make pulseaudio the default > sound daemon. Can we at least avoid having each audio application create > its own private group for realtime privileges ? Sure, we're only talking about the sound servers (jack and pulseaudio), not the audio apps that use them. AG From vonbrand at inf.utfsm.cl Tue Feb 6 21:33:46 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 06 Feb 2007 18:33:46 -0300 Subject: rawhide report: 20070206 changes In-Reply-To: <200702061103.l16B3c8v026093@hs20-bc2-6.build.redhat.com> References: <200702061103.l16B3c8v026093@hs20-bc2-6.build.redhat.com> Message-ID: <200702062133.l16LXk12006123@laptop13.inf.utfsm.cl> buildsys at redhat.com wrote: [...] > devhelp-0.13-3.fc7 > ------------------ > * Mon Feb 05 2007 Matthias Clasen - 0.13-3 > - Fix scriptlet errors Yes, but how do you get rid of the darned devhelp-0.13-2.fc7? Updating errors out, and rpm shows -2 and -3 installed... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From green at redhat.com Tue Feb 6 21:38:59 2007 From: green at redhat.com (Anthony Green) Date: Tue, 06 Feb 2007 13:38:59 -0800 Subject: Creating a jackuser group In-Reply-To: <45C8E12F.9060202@redhat.com> References: <1170790351.3564.12.camel@localhost.localdomain> <45C8E12F.9060202@redhat.com> Message-ID: <1170797939.3564.42.camel@localhost.localdomain> On Tue, 2007-02-06 at 15:12 -0500, Warren Togami wrote: > Where do we draw the line between add-on software that should have a > default user or group, and packages that have to create their own? If it were just creating the group, then it most likely makes sense to manage that in the add-on package. However, in this case it's more than just creating the group. We need special bits in /etc/security/limits.conf as well. AFAIK there are no special tools or standard practices for manipulating this file at %post* time, which is why we have the suggestion of pre-configuring this in the base install. AG From jwilson at redhat.com Tue Feb 6 21:44:15 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 6 Feb 2007 16:44:15 -0500 Subject: rawhide report: 20070206 changes In-Reply-To: <200702062133.l16LXk12006123@laptop13.inf.utfsm.cl> References: <200702061103.l16B3c8v026093@hs20-bc2-6.build.redhat.com> <200702062133.l16LXk12006123@laptop13.inf.utfsm.cl> Message-ID: <200702061644.18807.jwilson@redhat.com> On Tuesday 06 February 2007 16:33, Horst H. von Brand wrote: > buildsys at redhat.com wrote: > > [...] > > > devhelp-0.13-3.fc7 > > ------------------ > > * Mon Feb 05 2007 Matthias Clasen - 0.13-3 > > - Fix scriptlet errors > > Yes, but how do you get rid of the darned devhelp-0.13-2.fc7? Updating > errors out, and rpm shows -2 and -3 installed... rpm -e --noscripts on the ones you don't want, run appropriate fixed scripts by hand? -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bruno at wolff.to Tue Feb 6 21:41:49 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 6 Feb 2007 15:41:49 -0600 Subject: Default MTA for Fedora 7 In-Reply-To: <200702062116.l16LGpL5005408@laptop13.inf.utfsm.cl> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061030.43263.jkeating@redhat.com> <1170776244.10584.5.camel@hughsie-laptop> <200702062116.l16LGpL5005408@laptop13.inf.utfsm.cl> Message-ID: <20070206214149.GA26674@wolff.to> On Tue, Feb 06, 2007 at 18:16:51 -0300, "Horst H. von Brand" wrote: > > RAID isn't too common right now, but all the (higher-end) desktop machines > I've bought lately have RAID controllers built in. Those are going to be crap anyway. You really want to use software raid rather than those. And all you need for software raid is 2 hard drives. So this isn't something that a desktop user would have to go two far out of their way for. From tmus at tmus.dk Tue Feb 6 21:00:36 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 06 Feb 2007 22:00:36 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070206113651.GA5369@elte.hu> References: <20070205093443.GA30675@elte.hu> <20070206113651.GA5369@elte.hu> Message-ID: Ingo Molnar wrote: > * Thomas M Steenholdt wrote: > >>> This is the last I see, before the system hangs (does not respond to >>> caps-lock, num-lock etc) >>> --- >>> ICH7: not 100% native mode: will probe irqs later >>> ide0: BM-DMA at 0x1880-0x1887, BIOS settings: hda:DMA, hdb:pio >>> --- >> Ading "nolapic" kernel commandline option, makes boot work a lot >> better. >> >> Now, when hitting Gnome (in FC6) things are dog slow... mouse movement >> (USB) is jerky etc... > > i suspect this might be the sign of some interrupt problems. On rt3, only USB is slow... Using the trackpoint works nicely. I noticed that hotplugging my USB mouse was not successful. I had to reboot with the mouse attached, to make it work. > >> *Should* this work or are there system libs or stuff that need >> updating/rebuilding to work correctly with a dyntick kernel?!? > > yeah, it should be a drop-in replacement, so what you see is a bug > either in the -rt kernel or in the upstream kernel. I'm wondering, does > rawhide kernel rpm work? It's currently at 2.6.20-1.2922.fc7 which ought > to be roughly the same vanilla base as -rt has. So if that kernel works > for you then this is a regression in the -rt kernel. I'll try to test the rawhide kernel soon-ish to let you know about this. I'm also missing the ipw3945 module - I can't recall if the fedora kernel pkgs usually provides that module or not, but my dkms based version of it fails to build because of the interrupt structure changes, and that kinda limits my use of the -rt kernel to reboot-test-reboot-again. On the positive side, this T60p thinkpad usually makes a high-pitched squeaky noise when idle while running on batteries. That annoyance is gone with the -rt kernels - Hooray :) /Thomas From jfontain at free.fr Tue Feb 6 22:07:53 2007 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 06 Feb 2007 23:07:53 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45C8C617.7000607@kobold.org> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> Message-ID: <45C8FC39.1030100@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Thomas wrote: > jfontain at free.fr wrote: >> Since tcl-8.5a5 is now in the development tree, is it to be >> included in fedora >> 7? > > It appears so, yes. Well, then there's gonna be a big problem with blt (now in extras, a graphical library) which is far from ready to compile against tcl-8.5, which in turn moodss (also in extras, a monitoring application), depends on. I wonder what justifies releasing such alpha software ? - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFyPw5kG/MMvcT1qQRAuLMAKCr0vXQTyJW4Eb+b2E/D3XvYtSLvQCfcYwV 71rSH1FaCXfZs6zOOF9LHSM= =yo+Q -----END PGP SIGNATURE----- From tmus at tmus.dk Tue Feb 6 20:48:58 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 06 Feb 2007 21:48:58 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702051927.52474.jkeating@redhat.com> References: <200702051358.46945.jkeating@redhat.com> <200702051927.52474.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Monday 05 February 2007 15:39, Thomas M Steenholdt wrote: >> I'm not going to debate which mailer is best, but I have to say this... >> Knowing that exim will win a dependency race for for /usr/sbin/sendmail, >> including the package on the media and installing it by default (even if >> it's to satisfy a dep.), comes very very close to being a conscious >> decision. > > If you don't have network enabled at install time (and the remote repo > enabled), then only the packages on media will be looked at for solving > smtpdaemon. If its sendmail, and sendmail alone, it will win. If it's > postfix, it will win. Its all in what you put on the media. > > Precisely. So let's make sure that whatever is put on the media, is something that we can somehow justify as our default packages for whatever. I don't care about which mailer is chosen as default, but I'm not too fond of the: "package XXX is the default choice for function YYY, because it won the *sort* contest". If we are going to include an MTA on the media at all - and install should of course be possible without network connectivity - we should be in charge of which mailer goes there. It should not be left to chance. /Thomas From jkeating at redhat.com Tue Feb 6 22:20:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 17:20:39 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: References: <200702051927.52474.jkeating@redhat.com> Message-ID: <200702061720.39266.jkeating@redhat.com> On Tuesday 06 February 2007 15:48, Thomas M Steenholdt wrote: > Precisely. So let's make sure that whatever is put on the media, is > something that we can somehow justify as our default packages for > whatever. I don't care about which mailer is chosen as default, but I'm > not too fond of the: "package XXX is the default choice for function > YYY, because it won the *sort* contest". If we are going to include an > MTA on the media at all - and install should of course be possible > without network connectivity - we should be in charge of which mailer > goes there. It should not be left to chance. I really really don't want to make that decision, because no matter _what_ decision I make, people with pitchforks are going to come after me. So I'm perfectly happy to make _no_ decision and let the tool sort it out. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Tue Feb 6 22:34:58 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Feb 2007 16:34:58 -0600 Subject: Creating a jackuser group In-Reply-To: <1170790351.3564.12.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> Message-ID: >>>>> "AG" == Anthony Green writes: AG> Then users simply need to be added to the jackuser group in order AG> to run jackd and associated applications. Why not name the group after the permission it grants instead of the application? Then any software that needs these realtime bits can hook into the same infrastructure. - J< From notting at redhat.com Tue Feb 6 22:33:17 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 17:33:17 -0500 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <45C8D64D.7020901@redhat.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C79149.80907@redhat.com> <604aa7910702061027j1f629d6q9da48c83aea7d8ef@mail.gmail.com> <45C8D64D.7020901@redhat.com> Message-ID: <20070206223317.GC331@nostromo.devel.redhat.com> Christopher Aillon (caillon at redhat.com) said: > >Okay well... do we have a a more full list of 'plans' like this? See the feature list on the wiki? Bill From lsof at nodata.co.uk Tue Feb 6 22:35:37 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 06 Feb 2007 23:35:37 +0100 Subject: Bug 212424: FIxed for F7? In-Reply-To: <1170784647.7155.53.camel@hades.cambridge.redhat.com> References: <1170747732.3243.7.camel@sb-home.lan> <1170751708.19212.15.camel@soulcrusher.caolan.org> <1170784083.3168.6.camel@sb-home.lan> <1170784647.7155.53.camel@hades.cambridge.redhat.com> Message-ID: <1170801337.3166.0.camel@sb-home.lan> Am Dienstag, den 06.02.2007, 17:57 +0000 schrieb David Woodhouse: > On Tue, 2007-02-06 at 18:48 +0100, nodata wrote: > > > Do you have accessibility enabled, perhaps your evo problem is > > > http://bugzilla.gnome.org/show_bug.cgi?id=330728 a well known and long > > > running a11y explosion in evo ? The band-aid I shoved in there looks > > > like it might get included as a short-term solution. > > > > > I'm not sure because nobody is commenting on the bug. > > Of course they're not. Evolution is, to all extents and purposes, > unmaintained. > > -- > dwmw2 > So is it worth me filing a request for it to be removed? What do you recommend? From notting at redhat.com Tue Feb 6 22:33:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 17:33:34 -0500 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <604aa7910702061206t15953b39kf283fb9e85863f6c@mail.gmail.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C6F044.5010002@gmail.com> <604aa7910702061206t15953b39kf283fb9e85863f6c@mail.gmail.com> Message-ID: <20070206223334.GD331@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > Are the dictionaries /usr/share/ data or are the /usr/lib/ data? > Are they arch specific or are they not? > How do I as a mere mortal, without access to a ppc machine... test > whether the dictionary payloads are plagued with > big-endian/little-endian issues or other potential arch-specific > issues? rpm2cpio. diff. Bill From dwmw2 at infradead.org Tue Feb 6 22:47:53 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 22:47:53 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206212133.GB9176@jadzia.bu.edu> References: <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> <1170786157.7155.73.camel@hades.cambridge.redhat.com> <20070206212133.GB9176@jadzia.bu.edu> Message-ID: <1170802073.29759.1008.camel@pmac.infradead.org> On Tue, 2007-02-06 at 16:21 -0500, Matthew Miller wrote: > On Tue, Feb 06, 2007 at 06:22:37PM +0000, David Woodhouse wrote: > > > > This is false. Sorry. There is nothing sendmail can do that exim cannot as both > > > > are (within the limits of memory) turing complete. > > > milter? > > Which one? > > Any arbitrary existing one. That's the point. Yet you don't seem to be able to _specify_ one which we might actually want to run; one which provides functionality that Exim can't already manage for itself. Thus the point seems rather contrived. You might as well claim "Exim cannot obey sendmail master.cf", as if _that_ means something real. It wasn't what I was asking. Sendmail and Postfix can't run Exim's dynamically loadable local_scan or expansion functions either. I wasn't disingenuous enough to list those as examples of what Postfix cannot do -- I gave real-world examples of actualy things I do with Exim which I'm led to believe postfix isn't capable of. Are you able to do the same, to back up your claim that sendmail can do real things that Exim cannot? I think we've conceded UUCP already, without much regret. Got anything we might care about? -- dwmw2 From kevin.verma at gmail.com Tue Feb 6 22:51:47 2007 From: kevin.verma at gmail.com (Anuj Verma (Kevin)) Date: Tue, 6 Feb 2007 22:51:47 +0000 (UTC) Subject: [slightly-off-fedora-topic] who all has got N800 or 770 here ? Message-ID: Hello, Seems planet.fedoraproject.org is suddenly coming up with posts about N800, so I could not resist myself to ask here, that how many of us here have got these devices. I have got one myself, who else ? lack of applications is what we all face, especially N800 ? (I wish if RPM works there) Cheers, Kevin From jspaleta at gmail.com Tue Feb 6 23:07:52 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Feb 2007 14:07:52 -0900 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <20070206223317.GC331@nostromo.devel.redhat.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C79149.80907@redhat.com> <604aa7910702061027j1f629d6q9da48c83aea7d8ef@mail.gmail.com> <45C8D64D.7020901@redhat.com> <20070206223317.GC331@nostromo.devel.redhat.com> Message-ID: <604aa7910702061507k20da5a90h668bb1b0fc9eec1d@mail.gmail.com> On 2/6/07, Bill Nottingham wrote: > Christopher Aillon (caillon at redhat.com) said: > > >Okay well... do we have a a more full list of 'plans' like this? > > See the feature list on the wiki? Do you mean this page: http://fedoraproject.org/static-tmp/7 as linked from: http://fedoraproject.org/wiki/Core/Schedule ? -jef"Can I have the wiki automatically play an ogg of the soft soothing sounds of crickets at twilight when i load that page in lieu of content in the a planned features section?"spaleta From dwmw2 at infradead.org Tue Feb 6 23:18:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Feb 2007 23:18:33 +0000 Subject: [slightly-off-fedora-topic] who all has got N800 or 770 here ? In-Reply-To: References: Message-ID: <1170803913.29759.1042.camel@pmac.infradead.org> On Tue, 2007-02-06 at 22:51 +0000, Anuj Verma (Kevin) wrote: > (I wish if RPM works there) You really don't want RPM on it. Trust me. -- dwmw2 From michael.wiktowy at gmail.com Tue Feb 6 23:04:20 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 6 Feb 2007 18:04:20 -0500 Subject: [slightly-off-fedora-topic] who all has got N800 or 770 here ? In-Reply-To: References: Message-ID: <3e4ec4600702061504k45f161ep9dcd9dc51f811147@mail.gmail.com> On 2/6/07, Anuj Verma (Kevin) wrote: > Hello, > > Seems planet.fedoraproject.org is suddenly coming up with posts about > N800, so I could not resist myself to ask here, that how many of us here > have got these devices. > > I have got one myself, who else ? lack of applications is what we all > face, especially N800 ? I have one of each (although I am currently deciding the fate of my 770). I have found that most 770 apps work fine on the N800. Enable the old mistal repos and install the apps you need. Most will work. Then disable those repos to avoid pulling in too much cruft. Either that or be patient and wait for the repackaging ... it seems to be coming along nicely. > (I wish if RPM works there) I don't. While I am more familiar with yum/rpm, the last thing that the Maemo community needs is more package/repo splintering. /Mike From tmus at tmus.dk Tue Feb 6 23:19:49 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 07 Feb 2007 00:19:49 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702061720.39266.jkeating@redhat.com> References: <200702051927.52474.jkeating@redhat.com> <200702061720.39266.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Tuesday 06 February 2007 15:48, Thomas M Steenholdt wrote: >> Precisely. So let's make sure that whatever is put on the media, is >> something that we can somehow justify as our default packages for >> whatever. I don't care about which mailer is chosen as default, but I'm >> not too fond of the: "package XXX is the default choice for function >> YYY, because it won the *sort* contest". If we are going to include an >> MTA on the media at all - and install should of course be possible >> without network connectivity - we should be in charge of which mailer >> goes there. It should not be left to chance. > > I really really don't want to make that decision, because no matter _what_ > decision I make, people with pitchforks are going to come after me. So I'm > perfectly happy to make _no_ decision and let the tool sort it out. > > I think that's too easy and I'm slightly concerned with how many changes of *default* MTA's we'll see over time this way. Lets pick one so that even though we may not be perfectly happy with the choice, we'll know what we can expect to see there. I'm a postfix guy, but a lot of the exim dudes here have made me curious, so i'll be experimenting with exim soon. I've run sendmail some years back, but not lately. Either way, I vote that we choose this component, rather than leaving it to the sort routine. The obvious and easy choice is: sendmail (this is what we've had for as long as I can remember) As I see it, the battle of the "newcomers" is between Exim and Postfix. I won't choose between these, either one is fine by me. (count of hands?) Perhaps the best choice: a super-slim (local-only?) sendmail compatible thingy which shall remain nameless for now (since I don't know any). This would be perfect for machines that is not going to be hosting e-mail services, but where sending email is required. This makes most sense to me. Is there a candidate for this perhaps?!? /Thomas From pertusus at free.fr Tue Feb 6 23:33:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 7 Feb 2007 00:33:30 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: References: <200702051927.52474.jkeating@redhat.com> <200702061720.39266.jkeating@redhat.com> Message-ID: <20070206233330.GA3121@free.fr> > sense to me. Is there a candidate for this perhaps?!? esmtp and ssmtp. (and msmtp but the review if dead if I recall well). -- Pat From vonbrand at inf.utfsm.cl Tue Feb 6 23:51:14 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 06 Feb 2007 20:51:14 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: <200702061720.39266.jkeating@redhat.com> References: <200702051927.52474.jkeating@redhat.com> <200702061720.39266.jkeating@redhat.com> Message-ID: <200702062351.l16NpEVe022547@laptop13.inf.utfsm.cl> Jesse Keating wrote: > On Tuesday 06 February 2007 15:48, Thomas M Steenholdt wrote: > > Precisely. So let's make sure that whatever is put on the media, is > > something that we can somehow justify as our default packages for > > whatever. I don't care about which mailer is chosen as default, but I'm > > not too fond of the: "package XXX is the default choice for function > > YYY, because it won the *sort* contest". If we are going to include an > > MTA on the media at all - and install should of course be possible > > without network connectivity - we should be in charge of which mailer > > goes there. It should not be left to chance. > I really really don't want to make that decision, because no matter _what_ > decision I make, people with pitchforks are going to come after me. So I'm > perfectly happy to make _no_ decision and let the tool sort it out. That by itself /is/ a decision... Yes, I know about the pitchforks and all, and can't say I envy your position. But MTA is just one of the areas where there are several alternatives (vi vs emacs vs Xemacs, bash vs ash vs dash vs zsh vs ...) plus the many "Do we include ...?" Better set up an uniform way to decide such questions, just leaving them to "random" doesn't cut it. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From bojan at rexursive.com Tue Feb 6 23:58:25 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 6 Feb 2007 23:58:25 +0000 (UTC) Subject: f7 test: failure on nvidia chipset References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> <45C5C5CF.8080508@gmail.com> <1170693533.5207.5.camel@aglarond.local> Message-ID: Jeremy Katz redhat.com> writes: > It would be somewhat helpful if people who are having problems booting > the live CD can file bugs including the output of lspci so that we can > try to run all of the problem cases down Maybe: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218444 -- Bojan From dwmw2 at infradead.org Wed Feb 7 00:10:07 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 00:10:07 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206185321.GG1303364@hiwaay.net> References: <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206183412.GC29861@nostromo.devel.redhat.com> <20070206185321.GG1303364@hiwaay.net> Message-ID: <1170807007.29759.1070.camel@pmac.infradead.org> On Tue, 2007-02-06 at 12:53 -0600, Chris Adams wrote: > > > 0.56% of people need Towers of Hanoi? (don't mind me, just passing > > through...) :) > Alan is the one who brought that up, and IIRC in relation to exim, not > sendmail. Well, there were folks claiming that sendmail is capable of things that Exim can't do, although they don't seem able to give any real examples of what kind of tasks they're thinking of. Having exhausted the real-world possibilities of things you might actually want to do with an MTA, we thought maybe they were thinking of Hanoi? -- dwmw2 From green at redhat.com Wed Feb 7 00:13:09 2007 From: green at redhat.com (Anthony Green) Date: Tue, 06 Feb 2007 16:13:09 -0800 Subject: Creating a jackuser group In-Reply-To: References: <1170790351.3564.12.camel@localhost.localdomain> Message-ID: <1170807189.3564.75.camel@localhost.localdomain> On Tue, 2007-02-06 at 16:34 -0600, Jason L Tibbitts III wrote: > Why not name the group after the permission it grants instead of the > application? Then any software that needs these realtime bits can > hook into the same infrastructure. Perhaps. What other software needs to tweak limits.conf with exactly the same parameterized permissions? AG From emmanuel.seyman at club-internet.fr Wed Feb 7 00:18:18 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 7 Feb 2007 01:18:18 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <45C4F8D5.9010900@volny.cz> References: <1170534841.3775.0.camel@dawkins> <200702031600.39508.jkeating@redhat.com> <45C4F8D5.9010900@volny.cz> Message-ID: <20070207001818.GA12502@orient.maison.lan> On Sat, Feb 03, 2007 at 10:04:21PM +0100, Miloslav Trmac wrote: > > Desktops use a GUI mail client, though. Desktop machines don't use anything. Users on those machines will use non-gui or gui tools, depending on which one they find best (and best being a subjective state, it cannot be defined). Emmanuel From emmanuel.seyman at club-internet.fr Wed Feb 7 00:23:48 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 7 Feb 2007 01:23:48 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <87ejp6lu3o.fsf@kosh.bigo.ensc.de> References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> <87odobx76a.fsf@kosh.bigo.ensc.de> <20070203232000.4214d1cc@lain.camperquake.de> <87wt2y50by.fsf@kosh.bigo.ensc.de> <20070203235331.27bb6621@lain.camperquake.de> <87ejp6lu3o.fsf@kosh.bigo.ensc.de> Message-ID: <20070207002348.GB12502@orient.maison.lan> On Sun, Feb 04, 2007 at 12:06:03AM +0100, Enrico Scholz wrote: > > > > If you reproducably want sendmail then tell kickstart so instead of > > relying on side effects. > > Exactly. That's why, kickstart should abort on ambigous transactions. Now, all we need is a way to make kickstart figure out if you reproducibly want sendmail or not. Emmanuel From mattdm at mattdm.org Wed Feb 7 00:48:01 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Feb 2007 19:48:01 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170802073.29759.1008.camel@pmac.infradead.org> References: <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> <1170786157.7155.73.camel@hades.cambridge.redhat.com> <20070206212133.GB9176@jadzia.bu.edu> <1170802073.29759.1008.camel@pmac.infradead.org> Message-ID: <20070207004801.GA23948@jadzia.bu.edu> On Tue, Feb 06, 2007 at 10:47:53PM +0000, David Woodhouse wrote: > Are you able to do the same, to back up your claim that sendmail can do > real things that Exim cannot? I think we've conceded UUCP already, > without much regret. Got anything we might care about? Not for the desktop MTA, certainly. Nor for the default MTA either (although as noted, I think exim is overkill there too). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ianburrell at gmail.com Wed Feb 7 01:12:42 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 6 Feb 2007 17:12:42 -0800 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206172150.GB19254@jadzia.bu.edu> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170772969.2992.24.camel@dawkins> <1170774141.10584.2.camel@hughsie-laptop> <200702061030.43263.jkeating@redhat.com> <20070206172150.GB19254@jadzia.bu.edu> Message-ID: On 2/6/07, Matthew Miller wrote: > On Tue, Feb 06, 2007 at 10:30:40AM -0500, Jesse Keating wrote: > > > Surely the default should be not to include an MTA, I'm guessing a large > > > majority of people never one it anyway (myself included). > > That would require creating something to take the place of the smtpdaemon > > requirement of things like mdadm, fetchmail, logwatch, etc... > > Yes, what's Really Needed (tm) is a very lightweight smtpdaemon designed to > fill this need and nothing more. > What is needed for most desktops and servers is an MTA that is not an SMTP daemon. They need /usr/sbin/sendmail that can send mail through SMTP to the local mail server (smart host). It also needs to be able to deliver mail locally. I suppose it would be okay if it could send email to arbitrary hosts on the Internet. It probably needs to be a daemon to retry failed messages. Very few machines need to be able to receive email and listen to SMTP. Anyone who needs to receive email will know enough to install and configure their mail server of choice. - Ian From dwmw2 at infradead.org Wed Feb 7 01:28:15 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 01:28:15 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070207004801.GA23948@jadzia.bu.edu> References: <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> <1170786157.7155.73.camel@hades.cambridge.redhat.com> <20070206212133.GB9176@jadzia.bu.edu> <1170802073.29759.1008.camel@pmac.infradead.org> <20070207004801.GA23948@jadzia.bu.edu> Message-ID: <1170811695.29759.1090.camel@pmac.infradead.org> On Tue, 2007-02-06 at 19:48 -0500, Matthew Miller wrote: > Not for the desktop MTA, certainly. Not for _any_ MTA as far as I can tell. Although I conceded UUCP I suspect we could even do that if we cared. > Nor for the default MTA either (although > as noted, I think exim is overkill there too). There's a lot to be said for a dead simple program as /usr/lib/sendmail which doesn't listen on port 25 and which isn't capable of much more than sending to an external smarthost after a bit of address rewriting. I don't think we even want local delivery. It's obviously something that a no-setuid installation of Exim could do with a very simple configuration file, but you're probably right that it's overkill. Although it does have the advantage that you then have a single tool which covers users from the very low end to the very high end without needing to change tools when they outgrow it. -- dwmw2 From Curtis at GreenKey.net Wed Feb 7 01:36:36 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Tue, 6 Feb 2007 17:36:36 -0800 (PST) Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070206124100.GA4964@elte.hu> References: <20070205093443.GA30675@elte.hu> <20070205221200.9E59E6F071@alopias.GreenKey.net> <20070206114115.GB5369@elte.hu> <20070206124100.GA4964@elte.hu> Message-ID: <20070207013636.5DF136F072@alopias.GreenKey.net> 1:41pm Ingo Molnar said: > > * Ingo Molnar wrote: > > > $ ps aux | grep -i prio > > root 31 0.0 0.0 0 0 ? D Feb05 0:00 [RCU Prio Booste] > > > > that artificially increases the system load average by +1.0. I've > > fixed this in my tree and it will be in -rt3 today - it's harmless > > otherwise. > > fyi, i've just released the -rt3 rpms - can you still see any weirdness? > It was -rt4 that came down the pike when I checked. And the /proc/loadavg still seems decidedly "twitchy" for lack of a better term. It never fully settles down. And a few shells running top and tload will eventually drive it up to around 1 again. But it never stabilizes. This does not happen with the old tickey kernels. And it does not happen in any deterministic way I've seen before. I notice all the irq threads are now -51 priority. And there are quite a few of them. Plus the group of RT threads for each CPU. Your RCU Prio Booster is only pri -50 and appears to be sleeping hapily. Are there better profiling tools I could be running? ../C From Curtis at GreenKey.net Wed Feb 7 01:46:39 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Tue, 6 Feb 2007 17:46:39 -0800 (PST) Subject: FC7t1 + kickstart In-Reply-To: <20070206152304.GD5396@exeter.boston.redhat.com> References: <45C81876.2080606@kobold.org> <20070206062351.259AF6F072@alopias.GreenKey.net> <20070206152304.GD5396@exeter.boston.redhat.com> Message-ID: <20070207014639.B25BA6F072@alopias.GreenKey.net> 10:23am Chris Lumens said: > > > However, it doesn't appear that the %post section ever gets run. The > > > 'foo.txt' file never gets created. Is anaconda the right component to file a > > > bug against? > > > > > > > I saw this last month in rawhide. My internal notes say, "TODO: %post > > broken in 2007-01-21 rawhide due to apparent shuffling of > > setStepList/installSteps". > > > > Is it *still* ignoring %post in fc7t1? Ugh. > > In the future, please file bugs when you notice them. We all have a ton > of things to do and don't get around to testing and fixing every single > thing, so a bug report is a good way to draw our attention to what's > wrong. Thanks. > Yes, I was testing some hacks in my anaconda tree and wasn't sure it was my own fault. Then I forgot. :-/ I see Wart's already opened http://bugzilla.redhat.com/227470 and your fix is upstream. Thank you. ../C From notting at redhat.com Wed Feb 7 01:56:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 20:56:55 -0500 Subject: Would it make sense to make aspell dictionaries noarch packages? In-Reply-To: <604aa7910702061507k20da5a90h668bb1b0fc9eec1d@mail.gmail.com> References: <604aa7910702041014o688d0490y8ba2b5ee17ff9d70@mail.gmail.com> <45C79149.80907@redhat.com> <604aa7910702061027j1f629d6q9da48c83aea7d8ef@mail.gmail.com> <45C8D64D.7020901@redhat.com> <20070206223317.GC331@nostromo.devel.redhat.com> <604aa7910702061507k20da5a90h668bb1b0fc9eec1d@mail.gmail.com> Message-ID: <20070207015655.GB3162@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > Do you mean this page: > http://fedoraproject.org/static-tmp/7 Yeah, I broke the wiki, so it got redirected to a static page. http://fedoraproject.org/wiki/CategoryFedora7Features Bill From notting at redhat.com Wed Feb 7 01:59:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 20:59:51 -0500 Subject: Creating a jackuser group In-Reply-To: <1170790351.3564.12.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> Message-ID: <20070207015951.GC3162@nostromo.devel.redhat.com> Anthony Green (green at redhat.com) said: > fedora-music-list hosted a thread[1] recently on making it easier to run > the jack-audio-connection-kit server. It's a bit of a mess right now > because users have to manually edit /etc/security/limits.conf before > anything will run. > > In order to clean things up, it was proposed that Fedora come > pre-installed with a jackuser entry in /etc/group, as well as including > the following in /etc/security/limits.conf... > > @jackuser - rtprio 20 > @jackuser - memlock 131072 > > Then users simply need to be added to the jackuser group in order to run > jackd and associated applications. I believe this models what other > distros are doing to support jack users. Well, it means any user you add can't be removed from the group, but... *shrug*. Still seems to be a hack. > So, if this sounds like a sane thing to do for Fedora 7, do I simply > file bugzilla issues against the setup and pam packages (which > own /etc/group and /etc/security/limits.conf respectively). You can *not* add users in setup; you break the transaction due to dependency loops. The group would need to be added attached to some other package. Bill From jkeating at redhat.com Wed Feb 7 03:18:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Feb 2007 22:18:21 -0500 Subject: Using qemu to test images Message-ID: <200702062218.22096.jkeating@redhat.com> I've been using qemu to test my install trees, both without KVM and with KVM, both i386 and x86_64. I want to start doing this for ppc as well, however I'm running into an issue and I really don't know where to go from here (: Basically I create a file system image and then run: sudo qemu-system-ppc -vnc 1 -m 512 -hda /home/jkeating/pungi.img -cdrom /srv/pungi/development/6.90/Desktop/ppc/os/images/boot.iso This is just like what I call on x86, module the -system-ppc. However when I connect to VNC I see http://people.redhat.com/jkeating/qemu-ppc.png I know some of you are experienced with qemu on ppc, care to give me a hand? This same message comes up when booting the Test1 isos, which I kno wboot on my macs, so I don't think it is something wrong with the image creation. The online documentation for ppc is a bit sparse :/ -- Jesse Keating Release Engineer: Fedora -------------- 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 Feb 7 03:55:32 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 6 Feb 2007 20:55:32 -0700 Subject: Default MTA for Fedora 7 In-Reply-To: <1170807007.29759.1070.camel@pmac.infradead.org> References: <1170587296.29759.634.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206183412.GC29861@nostromo.devel.redhat.com> <20070206185321.GG1303364@hiwaay.net> <1170807007.29759.1070.camel@pmac.infradead.org> Message-ID: <80d7e4090702061955k5b100b75r68e9ce5c136ee5ae@mail.gmail.com> On 2/6/07, David Woodhouse wrote: > On Tue, 2007-02-06 at 12:53 -0600, Chris Adams wrote: > > > > > 0.56% of people need Towers of Hanoi? (don't mind me, just passing > > > through...) > > :) > > > Alan is the one who brought that up, and IIRC in relation to exim, not > > sendmail. > > Well, there were folks claiming that sendmail is capable of things that > Exim can't do, although they don't seem able to give any real examples > of what kind of tasks they're thinking of. Having exhausted the > real-world possibilities of things you might actually want to do with an > MTA, we thought maybe they were thinking of Hanoi? > I can give one legitimate reason for not including exim. Including exim would make David Woodhouse happy after 7 years of asking it in Red Hat/Fedora Linux. If exim becomes the default SMTP in FC7.. I expect David would retire shortly after as his life ambition would have been completed.. instead it should be listed as something to be brought up at FC8. To be honest, all I ask for is that if it is not sendmail, that a) First boot has an advanced option to select which MTA you want to use versus having to select it via a kickstart b) That there is good and clear documentation on how to use that MTA on a system. I have come to like postfix, but it took me 3 days of extensive reading to get it to act similarly as sendmail did for a standalone system some localized email and some central email. I expect that exim would be the same as I am not used to it.. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From david at lovesunix.net Wed Feb 7 05:17:56 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 07 Feb 2007 06:17:56 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45C8FC39.1030100@free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> Message-ID: <1170825476.3002.11.camel@dawkins> tir, 06 02 2007 kl. 23:07 +0100, skrev Jean-Luc Fontaine: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Thomas wrote: > > jfontain at free.fr wrote: > >> Since tcl-8.5a5 is now in the development tree, is it to be > >> included in fedora > >> 7? > > > > It appears so, yes. > Well, then there's gonna be a big problem with blt (now in extras, a > graphical library) which is far from ready to compile against tcl-8.5, > which in turn moodss (also in extras, a monitoring application), > depends on. > I wonder what justifies releasing such alpha software ? Welcome to development, that specific library has plenty of time to get updated before F7 final. - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 kevin.kofler at chello.at Wed Feb 7 05:28:02 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 7 Feb 2007 05:28:02 +0000 (UTC) Subject: tcl 8.5 alpha in fedora 7? References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> Message-ID: Jean-Luc Fontaine free.fr> writes: > Well, then there's gonna be a big problem with blt (now in extras, a > graphical library) which is far from ready to compile against tcl-8.5, So fix it. :-) Fedora moves fast, so maintainers sometimes have to patch upstream packages for new libraries they're not ready for. Also note that the Tcl 8.5 alphas have been out for more than a year. > I wonder what justifies releasing such alpha software ? Anti-aliasing support! Yes, Tcl finally supports Xft instead of using the obsolete, non-anti-aliased core fonts system. (It took them way too long.) Frankly, Tcl/Tk is one of the slowest-moving libraries in the world, this transition is one that will happen once in a few YEARS, and I don't think there will be a lot to change (though I might be wrong). You can be glad your packages don't depend on something like libtunepimp which changes its API radically every few months. Kevin Kofler From Lam at Lam.pl Wed Feb 7 06:42:18 2007 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 07 Feb 2007 07:42:18 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <1170802073.29759.1008.camel@pmac.infradead.org> References: <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <20070206150500.GA20911@devserv.devel.redhat.com> <20070206181045.GE1303364@hiwaay.net> <1170786157.7155.73.camel@hades.cambridge.redhat.com> <20070206212133.GB9176@jadzia.bu.edu> <1170802073.29759.1008.camel@pmac.infradead.org> Message-ID: <1170830538.3837.15.camel@pensja.lam.pl> Dnia 06-02-2007, wto o godzinie 22:47 +0000, David Woodhouse napisa?(a): > Yet you don't seem to be able to _specify_ one which we might actually > want to run; one which provides functionality that Exim can't already > manage for itself. A proprietary milter speaking proprietary protocol with some proprietary daemon (I know I've seen some anti-virus solutions using milter, probably there are some anti-spam commercial systems as well). > Are you able to do the same, to back up your claim that sendmail can do > real things that Exim cannot? I think we've conceded UUCP already, > without much regret. Got anything we might care about? We, the Sendmail users, are so happy with our MTA that we've never tried to really use Exim. I myself experimented with Exim few years ago, but I couldn't make it accept mail for wildcard domain (user@*.somewhere.com). Probably an easy thing if you know its language, but it was so much easier to just use Sendmail. I can't really tell if Exim can't do this (actually, I guess it can), so there's no real point in arguing with you that it can't. The problem here is that in order to really compare two advanced programs, you have to become an expert in both, which doesn't make sense (unless comparing the two programs is your job or religion :)). By the way, does anyone know, which MTA will be the default for RHEL 5? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From bojan at rexursive.com Wed Feb 7 06:46:41 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 7 Feb 2007 06:46:41 +0000 (UTC) Subject: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > If we ship a fully-fledged MTA as default, then Exim seems to make most > sense. [..snip..] > But again, there's an > advantage to having a single tool which can provide the _full_ range of > functionality from low end to high end without the user ever having to > throw one tool away and start learning a new one from scratch because > they want to do something which the one they're currently using can't > handle. Never used Exim, so I'm not really sure how much truth is in the author's statement: "The bottom line is that Exim does not perform particularly well in environments where the queue regularly gets very large. It was never designed for this; deliveries from the queue were always intended to be 'exceptions' rather than the norm." Wouldn't that be a bit of a concern, at least on the server? Maybe we should have one default for the Server and some other for the Desktop spin? One other question - do Fedora packages ship with Exim set SUID root? Is that something to worry about? PS. As I said, never used Exim - just asking out of curiosity. -- Bojan From jcm at redhat.com Wed Feb 7 06:53:20 2007 From: jcm at redhat.com (Jon Masters) Date: Wed, 07 Feb 2007 01:53:20 -0500 Subject: Using qemu to test images In-Reply-To: <200702062218.22096.jkeating@redhat.com> References: <200702062218.22096.jkeating@redhat.com> Message-ID: <45C97760.1000105@redhat.com> Jesse Keating wrote: > This is just like what I call on x86, module the -system-ppc. However when I > connect to VNC I see http://people.redhat.com/jkeating/qemu-ppc.png Looks like a bad OF device tree (it can't find the devices it's looking for via get-property). Someone like dwmw2 who actually tests Fedora on qemu-ppc might know more about which package/file you want to tweak. Jon. From pmatilai at laiskiainen.org Wed Feb 7 07:10:41 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 7 Feb 2007 09:10:41 +0200 (EET) Subject: Default MTA for Fedora 7 In-Reply-To: <200702062351.l16NpEVe022547@laptop13.inf.utfsm.cl> References: <200702051927.52474.jkeating@redhat.com> <200702061720.39266.jkeating@redhat.com> <200702062351.l16NpEVe022547@laptop13.inf.utfsm.cl> Message-ID: On Tue, 6 Feb 2007, Horst H. von Brand wrote: > Jesse Keating wrote: >> On Tuesday 06 February 2007 15:48, Thomas M Steenholdt wrote: >>> Precisely. So let's make sure that whatever is put on the media, is >>> something that we can somehow justify as our default packages for >>> whatever. I don't care about which mailer is chosen as default, but I'm >>> not too fond of the: "package XXX is the default choice for function >>> YYY, because it won the *sort* contest". If we are going to include an >>> MTA on the media at all - and install should of course be possible >>> without network connectivity - we should be in charge of which mailer >>> goes there. It should not be left to chance. > >> I really really don't want to make that decision, because no matter _what_ >> decision I make, people with pitchforks are going to come after me. So I'm >> perfectly happy to make _no_ decision and let the tool sort it out. I can only imagine the reactions if/when somebody submits some niche MTA into the repository mid-release that happens to get selected over exim. > That by itself /is/ a decision... If the selection was truly random, it would be a slightly different thing ("see, we're carrying out a field-test to see which MTA is the best by installing random MTA" :) but as it stands... yum-randomizer plugin, anyone ;) - Panu - From enrico.scholz at informatik.tu-chemnitz.de Wed Feb 7 07:58:43 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Feb 2007 08:58:43 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <20070207002348.GB12502@orient.maison.lan> (Emmanuel Seyman's message of "Wed, 7 Feb 2007 01:23:48 +0100") References: <20070203201220.106390@gmx.net> <200702031538.35270.jkeating@redhat.com> <87odobx76a.fsf@kosh.bigo.ensc.de> <20070203232000.4214d1cc@lain.camperquake.de> <87wt2y50by.fsf@kosh.bigo.ensc.de> <20070203235331.27bb6621@lain.camperquake.de> <87ejp6lu3o.fsf@kosh.bigo.ensc.de> <20070207002348.GB12502@orient.maison.lan> Message-ID: <87ejp22ybw.fsf@kosh.bigo.ensc.de> emmanuel.seyman at club-internet.fr (Emmanuel Seyman) writes: >> > If you reproducably want sendmail then tell kickstart so instead of >> > relying on side effects. >> >> Exactly. That's why, kickstart should abort on ambigous transactions. > > Now, all we need is a way to make kickstart figure out if you > reproducibly want sendmail or not. Easy; %package has already a '--resolvedeps' option. Just add '--fuzzydeps' or '--exactdeps' options which switch between both operation modes (default should be '--exactdeps'). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From dwmw2 at infradead.org Wed Feb 7 08:45:39 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 08:45:39 +0000 Subject: Using qemu to test images In-Reply-To: <45C97760.1000105@redhat.com> References: <200702062218.22096.jkeating@redhat.com> <45C97760.1000105@redhat.com> Message-ID: <1170837939.29759.1098.camel@pmac.infradead.org> On Wed, 2007-02-07 at 01:53 -0500, Jon Masters wrote: > Jesse Keating wrote: > > > This is just like what I call on x86, module the -system-ppc. However when I > > connect to VNC I see http://people.redhat.com/jkeating/qemu-ppc.png > > Looks like a bad OF device tree (it can't find the devices it's looking > for via get-property). Someone like dwmw2 who actually tests Fedora on > qemu-ppc might know more about which package/file you want to tweak. I've never actually looked at qemu's whole-system emulation. Well, not since a long time before I started 'owning' it in Extras at least. I'll take a look. But it looks like the BIOS isn't capable of executing arbitrary Forth scripts like the one we use to tell the difference between 32-bit and 64-bit machines. The easiest fix for that is just to tell it to boot cd :,\ppc\mac\yaboot directly instead of screwing around with the Forth script which is marked as the Mac-bootable thing. You should then find that yaboot finds the config file in /etc/yaboot.conf which lets you choose _either_ 32-bit or 64-bit kernel. Failing that, just run /images/netboot/ppc32.img which is the full kernel+initrd bundle. It's designed for netbooting but works perfectly well like that too (it's what we have to do on Pegasos where the firmware sucks too). I'll see if I can find a better answer. Probably not this week though, and certainly not next week as I'll be away from Friday afternoon. P'raps ask on the qemu-devel list? -- dwmw2 From jfontain at free.fr Wed Feb 7 08:47:41 2007 From: jfontain at free.fr (jfontain at free.fr) Date: Wed, 07 Feb 2007 09:47:41 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> Message-ID: <1170838061.45c9922d58224@imp.free.fr> Quoting Kevin Kofler : > Jean-Luc Fontaine free.fr> writes: > > Well, then there's gonna be a big problem with blt (now in extras, a > > graphical library) which is far from ready to compile against tcl-8.5, > > So fix it. :-) Unfortunately, I do not have the resources to fix and maintain such a complicated C library (many widgets) and the author has stated several times that he will wait for a list a stable tcl beta. Furthermore, my software (moodss, moomps) requires extreme stability in order to monitor reliably system resources (deamon). Unless somebody wants to tackle maintaining blt, I may have to pull my packages from F7 then... -- Jean-Luc From fedora at camperquake.de Wed Feb 7 08:54:20 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 7 Feb 2007 09:54:20 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> Message-ID: <20070207095420.3987bf76@banea.int.addix.net> Hi. On Wed, 7 Feb 2007 06:46:41 +0000 (UTC), Bojan Smojver wrote: > "The bottom line is that Exim does not perform particularly well in > environments where the queue regularly gets very large. It was never > designed for this; deliveries from the queue were always intended to > be 'exceptions' rather than the norm." Depends on what you call 'large'. 10000 mails in the queue are not really a problem. From kevin.kofler at chello.at Wed Feb 7 09:04:29 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 7 Feb 2007 09:04:29 +0000 (UTC) Subject: tcl 8.5 alpha in fedora 7? References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> Message-ID: Jean-Luc Fontaine free.fr> writes: > Well, then there's gonna be a big problem with blt (now in extras, a > graphical library) which is far from ready to compile against tcl-8.5, The strange thing is that it doesn't show up in the "broken dependencies" list, so RPM thinks the version built against 8.4 is still going to run (there's no dependency on the versioned soname). I don't know whether that's true. itcl, itk and iwidgets are in a similar situation, they don't seem to depend on libtcl8.4.so either for some reason, so I have no idea if they actually need a rebuilt or not. Kevin Kofler From gemi at bluewin.ch Wed Feb 7 10:09:40 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 07 Feb 2007 11:09:40 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1170838061.45c9922d58224@imp.free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <1170838061.45c9922d58224@imp.free.fr> Message-ID: <1170842980.3892.1.camel@scriabin.tannenrauch.ch> On Wed, 2007-02-07 at 09:47 +0100, jfontain at free.fr wrote: > Quoting Kevin Kofler : > > > Jean-Luc Fontaine free.fr> writes: > > > Well, then there's gonna be a big problem with blt (now in extras, a > > > graphical library) which is far from ready to compile against tcl-8.5, > > > > So fix it. :-) > > Unfortunately, I do not have the resources to fix and maintain such a > complicated C library (many widgets) and the author has stated several times > that he will wait for a list a stable tcl beta. > Furthermore, my software (moodss, moomps) requires extreme stability in order to > monitor reliably system resources (deamon). > Unless somebody wants to tackle maintaining blt, I may have to pull my packages > from F7 then... One could also create a package compat-tcl-84. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From drago01 at gmail.com Wed Feb 7 10:21:16 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 07 Feb 2007 11:21:16 +0100 Subject: qemu 0.9.0 in -devel In-Reply-To: References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> Message-ID: <45C9A81C.8050206@gmail.com> Ed Swierk wrote: > The new version causes SYSLINUX to hang when attempting to boot an FC6 > diskboot.img. > add -std-vga to the qemu command line and it works. From drago01 at gmail.com Wed Feb 7 10:19:29 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 07 Feb 2007 11:19:29 +0100 Subject: f7 test: time zone problem In-Reply-To: <1170693533.5207.5.camel@aglarond.local> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> <45C5C5CF.8080508@gmail.com> <1170693533.5207.5.camel@aglarond.local> Message-ID: <45C9A7B1.4070304@gmail.com> Jeremy Katz wrote: > It would be somewhat helpful if people who are having problems booting > the live CD can file bugs including the output of lspci so that we can > try to run all of the problem cases down > > there is an other bug but I have no idea where to fill it (against what?)... the livecd uses a different timezone than my laptop. after rebooting it saves this time to the hwclock which causes a incorrect time when I boot back to fc6 and I have to set it back by hand. the livecd should: 1)not alter the hwclock or 2) ask the user for his timezone during booting (striped down firstboot) I would prefer 2 because more options can be added here too if needed. > Jeremy > > From jfontain at free.fr Wed Feb 7 10:37:53 2007 From: jfontain at free.fr (jfontain at free.fr) Date: Wed, 07 Feb 2007 11:37:53 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> Message-ID: <1170844673.45c9ac01ae15a@imp.free.fr> Quoting Kevin Kofler : > Jean-Luc Fontaine free.fr> writes: > > Well, then there's gonna be a big problem with blt (now in extras, a > > graphical library) which is far from ready to compile against tcl-8.5, > > So fix it. :-) Fedora moves fast, so maintainers sometimes have to patch > upstream packages for new libraries they're not ready for. Also note that the > Tcl 8.5 alphas have been out for more than a year. > > > I wonder what justifies releasing such alpha software ? > > Anti-aliasing support! Yes, Tcl finally supports Xft instead of using the > obsolete, non-anti-aliased core fonts system. (It took them way too long.) > > Frankly, Tcl/Tk is one of the slowest-moving libraries in the world, this > transition is one that will happen once in a few YEARS, and I don't think > there > will be a lot to change (though I might be wrong). You can be glad your > packages don't depend on something like libtunepimp which changes its API > radically every few months. Furthermore, from the Tcl developers at http://www.tcl.tk/software/tcltk/8.5.html: Latest Release: Tcl/Tk 8.5a5 (Oct 20, 2006) ... This version is still in development; most users should be using the latest stable version of Tcl/Tk. -- JL From rhl-devel-list at lnx.ro Wed Feb 7 10:38:49 2007 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Wed, 07 Feb 2007 12:38:49 +0200 Subject: Default MTA for Fedora 7 In-Reply-To: <20070207095420.3987bf76@banea.int.addix.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <20070207095420.3987bf76@banea.int.addix.net> Message-ID: <1170844729.15233.12.camel@DustPuppy.LNX.RO> On Wed, 2007-02-07 at 09:54 +0100, Ralf Ertzinger wrote: > Hi. > > On Wed, 7 Feb 2007 06:46:41 +0000 (UTC), Bojan Smojver wrote: > > > "The bottom line is that Exim does not perform particularly well in > > environments where the queue regularly gets very large. It was never > > designed for this; deliveries from the queue were always intended to > > be 'exceptions' rather than the norm." > > Depends on what you call 'large'. 10000 mails in the queue are not really > a problem. 10000 mails in a queue does not qualify as an "large" queue in my experience. try 100000 :) And we are not even talking about multiple queues. -- Cioby From mcepl at redhat.com Wed Feb 7 11:16:00 2007 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 7 Feb 2007 11:16:00 +0000 (UTC) Subject: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> <20070204003924.0a1febd2@lain.camperquake.de> <45C526BC.2070909@interplas.com> <20070204045223.GB11220@nostromo.devel.redhat.com> Message-ID: Bill Nottingham scripst: > /usr/sbin/sendmail is a *standard* unix interface. a) ed is a *standard* unix text editor ;-) (sorry, cannot resist) b) and all reasonable MTAs support /usr/sbin/sendmail -- what does it have to do with choice of particular package for Fedora? Matej -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC I know of no country in which there is so little independence of mind and real freedom of discussion as in America. -- Alexis de Tocqueville From buildsys at redhat.com Wed Feb 7 11:23:15 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 7 Feb 2007 06:23:15 -0500 Subject: rawhide report: 20070207 changes Message-ID: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> Updated Packages: ConsoleKit-0.1.0-5.fc7 ---------------------- * Tue Feb 06 2007 David Zeuthen - 0.1.0-5.fc7 - Start ConsoleKit a bit earlier so it starts before HAL (98 -> 90) - Minimize stack usage so VIRT size is more reasonable (mclasen) - Make session inactive when switching to non-session (davidz) anacron-2.3-47.fc7 ------------------ * Tue Feb 06 2007 Marcela Maslanova 2.3-47 - thanks for review from Jef Spaleta - rhbz#225247, rhbz#211309 anthy-8604-1.fc7 ---------------- * Tue Feb 06 2007 Akira TAGOH - 8604-1 - New upstream release. - no longer needed to regenerate autotools files. (#224146) - use original gcanna dict. - build with --disable-static. bash-3.2-7.fc7 -------------- * Tue Feb 06 2007 Tim Waugh 3.2-7 - Reinstated this change: - Post requires ncurses (bug #224567). - Reverted this change: - Added triggers for install-info (bug #225609). * Tue Feb 06 2007 Tim Waugh 3.2-6 - Reverted this change: - Post requires ncurses (bug #224567). * Mon Feb 05 2007 Tim Waugh 3.2-5 - Added triggers for install-info (bug #225609). - Use full path to utilities in scriptlets (bug #225609). - Fix missing sh-bangs in example scripts (bug #225609). - Post requires ncurses (bug #224567). - Removed Prefix tag (bug #225609). - Fixed BuildRoot tag (bug #225609). - Removed trailing full-stop from summary (bug #225609). - Spec file is now UTF-8 (bug #225609). - Removed obsolete Obsoletes (bug #225609). - Moved 'make check' to new 'check' section (bug #225609). - Removed uses of RPM_SOURCE_DIR (bug #225609). - Fixed macros in changelog (bug #225609). - Changed tabs to spaces (bug #225609). bzip2-1.0.4-4.fc7 ----------------- * Tue Feb 06 2007 Ivana Varekova 1.0.4-4 - fix bzip2recover patch ccid-1.2.1-1.fc7 ---------------- * Tue Feb 06 2007 Bob Relyea - 1.2.1-1 - Pick up ccid 1.2.1 - use pcscd 'hotplug' feature instead of restarting the daemon - add enable_udev compiz-0.3.6-2.fc7 ------------------ * Tue Feb 06 2007 Kristian H??gsberg 0.3.6 - Require gnome-session > 2.16 so it starts gtk-window-decorator. - Update to desktop-effects 0.7.1 that doesn't refuse to work with Xinerama. * Tue Jan 16 2007 Kristian H??gsberg - 0.3.6-1 - Update to 0.3.6, update patches. - Drop autotool build requires. - Drop glfinish.patch, cow.patch, resize-offset.patch and icon-menu-patch. - Add libdecoration.so - Update to desktop-effects-0.7.0, which spawns the right decorator and plays nicely with unknown plugins. * Sat Nov 25 2006 Matthias Clasen - 0.3.4-2 - Update the fedora logo patch (#217224) control-center-1:2.17.90-5.fc7 ------------------------------ * Tue Feb 06 2007 Matthias Clasen - 2.17.90-5 - Fix some problems with the color theme support * Mon Feb 05 2007 Ray Strode - 2.17.90-4 - remove crufty sed replace line - use find -name '*.la' instead of removing each one individually dhcpv6-0.10-37.fc7 ------------------ * Tue Feb 06 2007 David Cantrell - 0.10-37 - Add missing ';;' on line 72 of dhcp6r init script * Tue Feb 06 2007 David Cantrell - 0.10-36 - Make dhcp6s and dhcp6r init scripts LSB compliant dos2unix-3.1-28.fc7 ------------------- * Tue Feb 06 2007 Tim Waugh 3.1-28 - Fixed build root (bug #225706). - Build with SMP flags (bug #225706). - Use dist in release tag (bug #225706). - Fixed macros in changelog (bug #225706). - Preserve timestamps when using install (bug #225706). echo-icon-theme-0.2-1.20070206wiki.fc7 -------------------------------------- * Tue Feb 06 2007 Matthias Clasen - 0.2-1.20070206wiki - New snapshot eclipse-1:3.2.1-36.fc7 ---------------------- * Tue Feb 06 2007 Ben Konrath 3.2.1-36 - Rework ppc64, s390{x} and sparc{64} hack again to try to fix multilib problem. fast-user-switch-applet-2.17.3-2.fc7 ------------------------------------ ftp-0.17-37.fc7 --------------- * Tue Feb 06 2007 Marcela Maslanova - 0.17-37 - add gpl - spec fix - rhbz#225774 * Tue Jan 30 2007 Marcela Maslanova - 0.17-35 - nodebug package * Wed Sep 13 2006 Marcela Maslanova - 0.17-33 - rebuilt gdm-1:2.17.6-2.fc7 ------------------ * Tue Feb 06 2007 Matthias Clasen - 1:2.17.6-2 - Apply a patch to improve fast user switching experience ghostscript-fonts-5.50-15.fc7 ----------------------------- * Tue Feb 06 2007 Tim Waugh 5.50-15 - Fixed URL (bug #225794). - Fixed build root tag (bug #225794). - This package does not require ghostscript (bug #225794). gmime-2.2.3-5.fc7 ----------------- * Tue Feb 06 2007 Alexander Larsson - 2.2.3-5 - Fix build with new automake (#224157) * Thu Oct 12 2006 Alexander Larsson - 2.2.3-4 - Bump glib requirement to 2.6 (#209565) gnome-screensaver-2.17.6-3.fc7 ------------------------------ * Tue Feb 06 2007 Matthias Clasen - 2.17.6-3 - Apply a patch to improve the fast user switching experience * Tue Feb 06 2007 David Zeuthen - 2.17.6-2.fc7 - Enable the "Switch User" button by default gnome-session-2.17.90.1-3.fc7 ----------------------------- * Tue Feb 06 2007 Kristian H??gsberg - 2.17.90.1-3 - Update gnome-session-2.17.5-window-manager.patch to start gtk-window-decorator instead of gnome-window-decorator for compiz. gzip-1.3.10-1.fc7 ----------------- * Tue Feb 06 2007 Ivana Varekova - 1.3.10-1 - Resolves: 225878 update to 1.3.10 change BuildRoot * Mon Jan 22 2007 Ivana Varekova - 1.3.9-2 - Resolves: 223702 fix non-failsafe install-info problem * Mon Jan 15 2007 Ivana Varekova - 1.3.9-1 - rebuild to 1.3.9 - spec cleanup hal-0.5.9-0.git20070206.1.fc7 ----------------------------- * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.1.fc7 - Make sure /var/cache/hald exists and has right mode / permissions (notting) * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.fc7 - Update to git snapshot - Drop upstreamed patches - Include hal-info snapshot in this SRPM for now (will be moved to it's own SRPM eventually) - Require ConsoleKit as this release denies some service to callers not originating from an active desktop session (f-u-s requirement) ifd-egate-0.05-16 ----------------- * Tue Feb 06 2007 Bob Relyea 0.05-16 - support new pcsc-lite udev functions kde-i18n-1:3.5.6-1.fc7 ---------------------- * Tue Feb 06 2007 Than Ngo 1:3.5.6-1.fc7 - 3.5.6 * Tue Aug 08 2006 Than Ngo 1:3.5.4-1 - 3.5.4 * Fri Jun 09 2006 Than Ngo 1:3.5.3-3 - fix dangling symlinks kdebase-6:3.5.6-1.fc7 --------------------- * Sun Jan 28 2007 Than Ngo 6:3.5.6-1.fc7 - 3.5.6 * Thu Nov 30 2006 Than Ngo - 6:3.5.5-0.6.fc6 - apply upstream fix: * Tue Nov 07 2006 Than Ngo 6:3.5.5-0.5.fc6 - add hibernate/suspend in shutdown dialog kdepim-6:3.5.6-1.fc7 -------------------- * Tue Feb 06 2007 Than Ngo - 6:3.5.6-1.fc7 - 3.5.6 lm_sensors-2.10.2-1.fc7 ----------------------- * Tue Feb 06 2007 Florian La Roche - 2.10.2-1 - Update to lm_sensors-2.10.2 nautilus-2.17.90-3.fc7 ---------------------- * Tue Feb 06 2007 Alexander Larsson - 2.17.90-3 - update tracker dynamic search patch to new .so name * Tue Jan 23 2007 Alexander Larsson - 2.17.90-2 - Fix gnome bug #362302 in selinux patch * Mon Jan 22 2007 Matthias Clasen - 2.17.90-1 - Update to 2.17.90 ncurses-5.6-3.20070203.fc7 -------------------------- * Tue Feb 06 2007 Miroslav Lichvar 5.6-3.20070203 - update to patch 20070203 - spec cleanup (#226188) openhpi-2.8.0-1.fc7 ------------------- * Tue Feb 06 2007 Phil Knirsch - 2.8.0-1.fc7 - Update to openhpi-2.8.0 openmpi-1.1-8.fc7 ----------------- * Tue Feb 06 2007 Florian La Roche - 1.1-8 - also add requires for sub-packages for "alternatives" openobex-1.3-4 -------------- * Wed Feb 07 2007 Harald Hoyer - 1.3-4 - readded obex_push openoffice.org-1:2.2.0-6.1 -------------------------- * Tue Feb 06 2007 Caolan McNamara - 1:2.2.0-6.1 - next candidate - drop integrated openoffice.org-2.2.0.ooo73295.basctl.extraqual.patch - extra gl and pa-IN help translations pam-0.99.7.1-2.fc7 ------------------ * Tue Feb 06 2007 Tomas Mraz 0.99.7.1-2 - more X displays as consoles (#227462) * Wed Jan 24 2007 Tomas Mraz 0.99.7.1-1 - upgrade to new upstream version resolving CVE-2007-0003 - pam_namespace: unmount poly dir for override users * Mon Jan 22 2007 Tomas Mraz 0.99.7.0-2 - add back min salt length requirement which was erroneously removed upstream (CVE-2007-0003) pcsc-lite-1.3.3-1.fc7 --------------------- * Tue Feb 06 2007 Bob Relyea - 1.3.3-1 - Pick up 1.3.3 rhpxl-0.43-1.fc7 ---------------- * Tue Feb 06 2007 Chris Lumens - 0.43-1 - Add support for writing out ibmasm config information (#198797). - Various fixes that allow the resolution in a kickstart file to be propagated to the installed system. screen-4.0.3-3.fc7 ------------------ * Tue Feb 06 2007 Marcela Maslanova - 4.0.3-3 - rebuilt (change in spec file) sendmail-8.14.0-1 ----------------- * Tue Feb 06 2007 Thomas Woerner 8.14.0-1 - new version 8.14.0 - adapted patches: makemapman, dynamic shared-mime-info-0.20-1.fc7 --------------------------- * Tue Feb 06 2007 - Bastien Nocera - 0.20-1 - Update to 0.20, and remove outdated patches symlinks-1.2-27.fc7 ------------------- * Tue Feb 06 2007 Tim Waugh 1.2-27 - Fixed summary (bug #226445). - Added token URL tag (bug #226445). tar-2:1.15.1-26.fc7 ------------------- * Tue Feb 06 2007 Peter Vrabec 2:1.15.1-26 - fix spec file to meet Fedora standards (#226478) tree-1.5.0-6.fc7 ---------------- * Tue Feb 06 2007 Tim Waugh 1.5.0-6 - Preserve timestamps on install (bug #226503). - Added SMP flags (bug #226503). - Removed Prefix: tag (bug #226503). - Removed bogus mkdir call (bug #226503). - Ship the LICENSE file (bug #226503). - Fixed summary (bug #226503). udev-104-2 ---------- * Tue Feb 06 2007 Harald Hoyer - 104-2 - moved uinput to input subdirectory (rhbz#213854) - added USB floppy symlinks (rhbz#185171) - fixed ZIP drive handling (rhbz#223016) - Resolves: rhbz#213854,rhbz#185171,rhbz#223016 unix2dos-2.2-27.fc7 ------------------- * Tue Feb 06 2007 Tim Waugh 2.2-27 - Preserve timestamps on install (bug #226516). - Fixed summary (bug #226514). - Fixed build root (bug #226514). - Don't explicitly require perl for build (bug #226514). - Added dist to release tag (bug #226514). - Don't build with '-Wall' since RPM_OPT_FLAGS already includes it (bug #226514). - Fixed macros in changelog (bug #226514). unzip-5.52-4.fc7 ---------------- * Wed Feb 07 2007 Ivana Varekova - 5.52-4 - incorporate the next peckage review comment * Tue Feb 06 2007 Ivana Varekova - 5.52-3 - Resolves: 226516 Incorporate the package review vim-2:7.0.191-2.fc7 ------------------- * Tue Feb 06 2007 Karsten Hopp 7.0.191-2 - uses ncurses instead of ncursesw * Tue Feb 06 2007 Karsten Hopp 7.0.191-1 - patchlevel 191 - clean up spec file for rpmlint - drop cvim stuff zip-2.31-3.fc7 -------------- * Wed Feb 07 2007 Ivana Varekova - 2.31-3 - incorporate the next peckage review comment * Tue Feb 06 2007 Ivana Varekova - 2.31-2 - incorporate the package review Broken deps for s390 ---------------------------------------------------------- openhpi - 2.8.0-1.fc7.s390 requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) openhpi - 2.8.0-1.fc7.x86_64 requires libopenhpi.so.2()(64bit) openhpi - 2.8.0-1.fc7.i386 requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) Broken deps for i386 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so openhpi - 2.8.0-1.fc7.i386 requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) openhpi - 2.8.0-1.fc7.ppc64 requires libopenhpi.so.2()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so openhpi - 2.8.0-1.fc7.ppc requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so Broken deps for ia64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) Broken deps for s390x ---------------------------------------------------------- openhpi - 2.8.0-1.fc7.s390 requires libopenhpi.so.2 openhpi - 2.8.0-1.fc7.s390x requires libopenhpi.so.2()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) From sb at monkey-mind.net Wed Feb 7 11:47:02 2007 From: sb at monkey-mind.net (Steven Bakker) Date: Wed, 07 Feb 2007 12:47:02 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: References: <200702051927.52474.jkeating@redhat.com> <200702061720.39266.jkeating@redhat.com> <200702062351.l16NpEVe022547@laptop13.inf.utfsm.cl> Message-ID: <1170848822.4124.63.camel@cluestix.noc.ams-ix.net> On Wed, 2007-02-07 at 09:10 +0200, Panu Matilainen wrote: > I can only imagine the reactions if/when somebody submits some niche MTA > into the repository mid-release that happens to get selected over exim. Great! I just thought of "a00-compressing-mailer"; it installs /usr/sbin/sendmail as a symlink to /bin/true. ;-) -- Steven From dcbw at redhat.com Wed Feb 7 11:56:24 2007 From: dcbw at redhat.com (Dan Williams) Date: Wed, 07 Feb 2007 06:56:24 -0500 Subject: Creating a jackuser group In-Reply-To: <20070207015951.GC3162@nostromo.devel.redhat.com> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> Message-ID: <1170849384.2877.5.camel@localhost.localdomain> On Tue, 2007-02-06 at 20:59 -0500, Bill Nottingham wrote: > Anthony Green (green at redhat.com) said: > > fedora-music-list hosted a thread[1] recently on making it easier to run > > the jack-audio-connection-kit server. It's a bit of a mess right now > > because users have to manually edit /etc/security/limits.conf before > > anything will run. > > > > In order to clean things up, it was proposed that Fedora come > > pre-installed with a jackuser entry in /etc/group, as well as including > > the following in /etc/security/limits.conf... > > > > @jackuser - rtprio 20 > > @jackuser - memlock 131072 > > > > Then users simply need to be added to the jackuser group in order to run > > jackd and associated applications. I believe this models what other > > distros are doing to support jack users. > > Well, it means any user you add can't be removed from the group, but... > *shrug*. Still seems to be a hack. > > > So, if this sounds like a sane thing to do for Fedora 7, do I simply > > file bugzilla issues against the setup and pam packages (which > > own /etc/group and /etc/security/limits.conf respectively). > > You can *not* add users in setup; you break the transaction due to > dependency loops. The group would need to be added attached to some > other package. Hmm; I wonder if there are better ways to do this. Debian/Ubuntu use groups for networking stuff, and, for example, you can't talk to NetworkManager unless you're in the 'netdev' group. Which is odd. So lets think about the user experience here. If somebody installs an app that uses Jack or requires realtime audio capabilities, what's the failure mode if they're not in the 'rtaudio' group? How would they know what to do to be able to do realtime audio? How do they get told that they need to got to system-config-users, enter the root password, and add themselves? Just fixing up the lower layers and base permission scheme doesn't fix the problem; we've got to think how it works vertically all down the entire stack. About the last thing we want is a nice "Could not initialize realtime audio" dialog in some app, which is par for the course, but says _nothing_ about what failed, and how to fix it. Dan From drago01 at gmail.com Wed Feb 7 12:04:46 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 07 Feb 2007 13:04:46 +0100 Subject: [RFE] install from software raid in f7 Message-ID: <45C9C05E.8000103@gmail.com> Hello, Anaconda is able to install from harddisk. But this does not work if the images are on a mdraid device. (cannot select it). Anaconda is able to mount md raid devices (see rescue mode). So is it possible to add this feature to f7? (point to md raid device and install/update from there). This will not only make it possible to do harddisk installs fro people which does not have a non raid partiton on there disks (exept /boot which is to small), but this (raid0,raid5) would also be the fastest install source (comparing with non raid hdd or optical media). From jonathan.underwood at gmail.com Wed Feb 7 12:20:07 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 7 Feb 2007 12:20:07 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206233330.GA3121@free.fr> References: <200702051927.52474.jkeating@redhat.com> <200702061720.39266.jkeating@redhat.com> <20070206233330.GA3121@free.fr> Message-ID: <645d17210702070420h5a56f508va8176f5d5e9b545a@mail.gmail.com> On 06/02/07, Patrice Dumas wrote: > > sense to me. Is there a candidate for this perhaps?!? > > esmtp and ssmtp. > > (and msmtp but the review if dead if I recall well). Also nbsmtp. From dwmw2 at infradead.org Wed Feb 7 12:36:51 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 12:36:51 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <20070207095420.3987bf76@banea.int.addix.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <20070207095420.3987bf76@banea.int.addix.net> Message-ID: <1170851811.29759.1134.camel@pmac.infradead.org> On Wed, 2007-02-07 at 09:54 +0100, Ralf Ertzinger wrote: > Hi. > > On Wed, 7 Feb 2007 06:46:41 +0000 (UTC), Bojan Smojver wrote: > > > "The bottom line is that Exim does not perform particularly well in > > environments where the queue regularly gets very large. It was never > > designed for this; deliveries from the queue were always intended to > > be 'exceptions' rather than the norm." > > Depends on what you call 'large'. 10000 mails in the queue are not really > a problem. I think that comment predates the split spool directory stuff as well. -- dwmw2 From dwmw2 at infradead.org Wed Feb 7 13:11:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 13:11:38 +0000 Subject: Greylisting support for Exim in -devel. In-Reply-To: <20070206145417.GA17304@dudweiler.stuttgart.redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <45C6F9B1.3010504@olen.net> <1170684913.29759.815.camel@pmac.infradead.org> <20070206145417.GA17304@dudweiler.stuttgart.redhat.com> Message-ID: <1170853898.29759.1151.camel@pmac.infradead.org> On Tue, 2007-02-06 at 15:54 +0100, Florian La Roche wrote: > > Although it's useful to give examples of how to do such things, it's > > also important not to make the _default_ configuration too baroque. > > Debian gets this very wrong, which is why I've been slightly reluctant > > to include more than the basics in the Fedora package. But these days I > > suspect that greylisting _is_ counted amongst the basic requirements of > > a public-facing mail server so I think I'll have to include it. > > Including this, but having it commented out sounds very good. > > > Would you (or anyone else, for that matter) be interested in being a > > guinea pig to help me assess how easy it is for newbies to Exim to use > > such a thing if I add it? > > I am ;-) I still run sendmail, but exim has been on my wishlist for > a very long time now. Ok, I've thrown together a fairly simple example of how to implement greylisting in Exim. It's in exim-4.66-2.fc7, building in -devel now. There's an 'exim-greylist' subpackage which contains a snippet of ACL subroutine to do greylisting, along with a %post script to create the sqlite tables, a cron job to expire old entries, etc. To use it, just install the exim-greylist package, then edit /etc/exim/exim.conf and uncomment the bits which refer to it. By default, it only greylists mail which lacks a Message-Id: header. There are examples in the config file which you can just uncomment and tweak to trigger greylisting for other offences, including SA points, RBLs, or you can just make it unconditional. As discussed, it remembers the { IP, HELO } of any host which is observed to resend mail, and it won't bother greylisting mail from that host again. Please play with it and let me know if there are ways I could improve it. Packages (src and ppc; I don't have i386 rawhide to hand) at http://david.woodhou.se/exim-greylist/ -- dwmw2 From jkeating at redhat.com Wed Feb 7 13:46:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 08:46:00 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170830538.3837.15.camel@pensja.lam.pl> References: <1170674703.29759.758.camel@pmac.infradead.org> <1170802073.29759.1008.camel@pmac.infradead.org> <1170830538.3837.15.camel@pensja.lam.pl> Message-ID: <200702070846.03555.jkeating@redhat.com> On Wednesday 07 February 2007 01:42, Leszek Matok wrote: > By the way, does anyone know, which MTA will be the default for RHEL 5? I think it will be sendmail. Path of least surprise. Much harder to make any sort of change like that in RHEL :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From green at redhat.com Wed Feb 7 14:01:18 2007 From: green at redhat.com (Anthony Green) Date: Wed, 07 Feb 2007 06:01:18 -0800 Subject: Creating a jackuser group In-Reply-To: <1170849384.2877.5.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> Message-ID: <1170856878.3564.92.camel@localhost.localdomain> On Wed, 2007-02-07 at 06:56 -0500, Dan Williams wrote: > So lets think about the user experience here. If somebody installs an > app that uses Jack or requires realtime audio capabilities, what's the > failure mode if they're not in the 'rtaudio' group? How would they know > what to do to be able to do realtime audio? How do they get told that > they need to got to system-config-users, enter the root password, and > add themselves? The plan that was discussed on fedora-music-list was to wrap qjackctl in a script that checked to see if the user was part of the jackuser group and, if not, popped up a dialog box asking if they wanted to join (requiring root password via consolehelper script). See the thread here: http://www.mail-archive.com/fedora-music-list at redhat.com/msg00121.html AG From nphilipp at redhat.com Wed Feb 7 14:23:08 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 07 Feb 2007 15:23:08 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> Message-ID: <1170858188.21302.8.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-02-06 at 18:51 +0000, Peter Robinson wrote: > > >>>>> "MM" == Matthew Miller writes: > > > > MM> On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: > > >> That's because people get flamed to a crisp when they even suggest > > >> sendmail. I still use it on almost all of my servers. > > > > MM> sendmail can do things no other MTA can. Period. > > > > MM> 99.44% of people do not need those things, but the remainder > > MM> _really_ needs them. > > > > Is there really anything useful left which exim can't do? UUCP bang > > paths are the only limitation I can think of off the cuff, and > > hopefully noone uses those. Exim can do UUCP with domain addressing > > though, if anyone still uses UUCP. > > Yes, I have a few sites that require it.... but then I also know how > to 'yum install sendmail' too, as I'm sure just about everyone who > uses UUCP does, or else compiles sendmail themsleves. This would put me in the "just not about everyone" group as I use postfix and UUCP. It was really easy to setup, but I might have to try out something different for more effective anti-spam stuff. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 gajownik at gmail.com Wed Feb 7 14:34:02 2007 From: gajownik at gmail.com (Dawid Gajownik) Date: Wed, 7 Feb 2007 15:34:02 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070205093443.GA30675@elte.hu> References: <20070205093443.GA30675@elte.hu> Message-ID: <9aa7c6490702070634h61a917fcy93f759b86b2afe86@mail.gmail.com> On 2/5/07, Ingo Molnar wrote: > as usual, bugreports, fixes and suggestions are welcome, With kernel 2.6.20-1.rt5.0116 I got today this backtrace: Feb 7 14:30:05 zuzia kernel: pcmcia: registering new device pcmcia1.0 Feb 7 14:30:05 zuzia kernel: bt3c_interrupt: Call of irq 3 for unknown device Feb 7 14:30:06 zuzia hcid[2243]: HCI dev 0 registered Feb 7 14:30:06 zuzia hcid[2243]: Register path:/org/bluez/hci0 fallback:0 Feb 7 14:30:06 zuzia hcid[2243]: HCI dev 0 up Feb 7 14:30:06 zuzia hcid[2243]: Device hci0 has been added Feb 7 14:30:06 zuzia hcid[2243]: Starting security manager 0 Feb 7 14:30:07 zuzia hcid[2243]: Device hci0 has been activated Feb 7 15:00:13 zuzia kernel: BUG: time warp detected! Feb 7 15:00:13 zuzia kernel: prev > now, 103fb8125205ab86 > 103fb8116b2b6402: Feb 7 15:00:13 zuzia kernel: = 3873064836 delta, on CPU#0 Feb 7 15:00:13 zuzia kernel: [] dump_trace+0x63/0x1e8 Feb 7 15:00:13 zuzia kernel: [] show_trace_log_lvl+0x1c/0x39 Feb 7 15:00:13 zuzia kernel: [] show_trace+0x12/0x14 Feb 7 15:00:13 zuzia kernel: [] dump_stack+0x14/0x16 Feb 7 15:00:13 zuzia kernel: [] do_gettimeofday+0x155/0x188 Feb 7 15:00:13 zuzia kernel: [] evdev_event+0x96/0x131 Feb 7 15:00:13 zuzia kernel: [] input_event+0x3dd/0x486 Feb 7 15:00:13 zuzia kernel: [] atkbd_interrupt+0x21f/0x4df Feb 7 15:00:13 zuzia kernel: [] serio_interrupt+0x2f/0x61 Feb 7 15:00:13 zuzia kernel: [] i8042_interrupt+0x1ff/0x213 Feb 7 15:00:13 zuzia kernel: [] handle_IRQ_event+0x4e/0xdc Feb 7 15:00:13 zuzia kernel: [] thread_simple_irq+0x39/0x6b Feb 7 15:00:13 zuzia kernel: [] do_irqd+0xe4/0x29a Feb 7 15:00:13 zuzia kernel: [] kthread+0xb2/0xd7 Feb 7 15:00:13 zuzia kernel: [] kernel_thread_helper+0x7/0x10 Feb 7 15:00:13 zuzia kernel: ======================= Feb 7 15:00:13 zuzia kernel: --------------------------- Feb 7 15:00:13 zuzia kernel: | preempt count: 00000000 ] Feb 7 15:00:13 zuzia kernel: | 0-level deep critical section nesting: Feb 7 15:00:13 zuzia kernel: ---------------------------------------- Feb 7 15:00:13 zuzia kernel: Applications started hanging and in the end I wasn't able to cleanly reboot my machine. Hope that helps, Dawid From jwilson at redhat.com Wed Feb 7 14:36:40 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 7 Feb 2007 09:36:40 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170858188.21302.8.camel@gibraltar.stuttgart.redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> <1170858188.21302.8.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200702070936.44060.jwilson@redhat.com> On Wednesday 07 February 2007 09:23, Nils Philippsen wrote: > On Tue, 2007-02-06 at 18:51 +0000, Peter Robinson wrote: > > > >>>>> "MM" == Matthew Miller writes: > > > > > > MM> On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: > > > >> That's because people get flamed to a crisp when they even suggest > > > >> sendmail. I still use it on almost all of my servers. > > > > > > MM> sendmail can do things no other MTA can. Period. > > > > > > MM> 99.44% of people do not need those things, but the remainder > > > MM> _really_ needs them. > > > > > > Is there really anything useful left which exim can't do? UUCP bang > > > paths are the only limitation I can think of off the cuff, and > > > hopefully noone uses those. Exim can do UUCP with domain addressing > > > though, if anyone still uses UUCP. > > > > Yes, I have a few sites that require it.... but then I also know how > > to 'yum install sendmail' too, as I'm sure just about everyone who > > uses UUCP does, or else compiles sendmail themsleves. > > This would put me in the "just not about everyone" group as I use > postfix and UUCP. It was really easy to setup, but I might have to try > out something different for more effective anti-spam stuff. I'm a postfix user too. No uucp though. Dual-mta postfix setup with maia mailguard (a fork of amavisd-new, if you will) in between nuking spam. (With some counter-measures at the first postfix instance level too). Works extremely well for me. As for the performance issue someone else quoted regarding exim... At one point in time, I worked at a place that had lots of mail servers moving tens of millions of emails per day. There was no way in hell exim could handle the load (we tried). Both sendmail and qmail (ew) had their issues as well. Postfix was rock-solid, and had no problems holding up under the stress. Granted, this is a few years ago now, so postfix could have regressed (unlikely) and the others (save qmail) could have improved... Postfix: the choice of spammers^Wlegitimate high-volume email businesses?... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From baris at teamforce.name.tr Wed Feb 7 14:38:48 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Wed, 07 Feb 2007 16:38:48 +0200 Subject: WLAN: link must be UP before ESSID is set In-Reply-To: References: Message-ID: <1170859128.3191.4.camel@localhost.localdomain> I'm using zd1211rw device and bringing interface up before setting ESSID and KEY for wireless device did not cause any problem for me using different hardware as well. That was not an issue with vendor driver, but it's necessary to bring interface up for rewrite of the driver. Thus, I was not sure if this related with driver or the network-scripts. But considering zd1211rw is included with kernel, it's evident that without necessary changes on ifup-wireless it's not possible to automatically bring interface into running state. If someone states a bug id, i can submit my change(s). On Tue, 2007-02-06 at 22:04 +0200, Pekka Savola wrote: > Hi, > > On new USB stick WLAN interface (driver zd1211rw) it seems that the > 'ip link set $DEVICE up' needs to be done before ESSID is set for the > card to come up at all. (On the other hand, for example, the old > orinoco_cs doesn't require this.) > > Even though DHCP client (run after ESSID is set) brings up the link, > the WLAN card is not associated to the AP (the state as shown below), > and IP doesn't work yet. > > zd1211rw people had the opinion that this is a problem with ifup: > > "This is a distro bug - it should bring the interface up before using > it. Many drivers require the interface to be up before scanning is > possible, since for a lot of hardware, scanning is just transmission > and reception of frames so requires the entire MAC layer to be > activated just the same as if you were transmitting/receiving data." > > Should this be fixed by setting the link up before setting ESSID in > ifup-wireless (or even before setting some other iwconfig options)? > > Is there any drawback in doing so? (At least it seems to me that you > may not be able to specify a new MACADDR if this was done.) > > Is there already a bug report on this (based on very quick search I > couldn't find one)? > > eth1 IEEE 802.11b/g ESSID:"S" Nickname:"zd1211" > Mode:Managed Frequency:2.412 GHz Access Point: Invalid > Bit Rate=1 Mb/s > Encryption key:off > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From dwmw2 at infradead.org Wed Feb 7 15:21:14 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 15:21:14 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <200702070936.44060.jwilson@redhat.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> <1170858188.21302.8.camel@gibraltar.stuttgart.redhat.com> <200702070936.44060.jwilson@redhat.com> Message-ID: <1170861674.29759.1165.camel@pmac.infradead.org> On Wed, 2007-02-07 at 09:36 -0500, Jarod Wilson wrote: > As for the performance issue someone else quoted regarding exim... At one > point in time, I worked at a place that had lots of mail servers moving tens > of millions of emails per day. There was no way in hell exim could handle the > load (we tried). Both sendmail and qmail (ew) had their issues as well. > Postfix was rock-solid, and had no problems holding up under the stress. > Granted, this is a few years ago now, so postfix could have regressed > (unlikely) and the others (save qmail) could have improved... I've heard anecdotes the other way round too, and there are some very large deployments of Exim. I suspect that it depends a lot on how well-tuned it is. With large queues, you definitely need the 'split_spool_directory' option turned on to avoid putting too many files in a single directory -- it's going to suck quite hard otherwise; especially on older kernels. You may also want multiple queue-runner processes in parallel, if you have a large number of mails stuck on the queue that aren't immediately deliverable. -- dwmw2 From jwilson at redhat.com Wed Feb 7 15:29:00 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 7 Feb 2007 10:29:00 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: <1170861674.29759.1165.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702070936.44060.jwilson@redhat.com> <1170861674.29759.1165.camel@pmac.infradead.org> Message-ID: <200702071029.04326.jwilson@redhat.com> On Wednesday 07 February 2007 10:21, David Woodhouse wrote: > On Wed, 2007-02-07 at 09:36 -0500, Jarod Wilson wrote: > > As for the performance issue someone else quoted regarding exim... At one > > point in time, I worked at a place that had lots of mail servers moving > > tens of millions of emails per day. There was no way in hell exim could > > handle the load (we tried). Both sendmail and qmail (ew) had their issues > > as well. Postfix was rock-solid, and had no problems holding up under the > > stress. Granted, this is a few years ago now, so postfix could have > > regressed (unlikely) and the others (save qmail) could have improved... > > I've heard anecdotes the other way round too, and there are some very > large deployments of Exim. I suspect that it depends a lot on how > well-tuned it is. With large queues, you definitely need the > 'split_spool_directory' option turned on to avoid putting too many files > in a single directory -- it's going to suck quite hard otherwise; > especially on older kernels. You may also want multiple queue-runner > processes in parallel, if you have a large number of mails stuck on the > queue that aren't immediately deliverable. Cool, I figured the situation was probably better nowadays. My anecdote is from at least three or four years ago on Red Hat Linux 7.x systems. Note to self: give exim a try one of these days... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Feb 7 15:50:21 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Feb 2007 10:50:21 -0500 Subject: f7 test: time zone problem In-Reply-To: <45C9A7B1.4070304@gmail.com> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> <45C5C5CF.8080508@gmail.com> <1170693533.5207.5.camel@aglarond.local> <45C9A7B1.4070304@gmail.com> Message-ID: <1170863421.16292.2.camel@aglarond.local> On Wed, 2007-02-07 at 11:19 +0100, dragoran wrote: > Jeremy Katz wrote: > > It would be somewhat helpful if people who are having problems booting > > the live CD can file bugs including the output of lspci so that we can > > try to run all of the problem cases down > > > there is an other bug but I have no idea where to fill it (against what?)... > the livecd uses a different timezone than my laptop. after rebooting it > saves this time to the hwclock which causes a incorrect time when I boot > back to fc6 and I have to set it back by hand. Just file it against distribution for now and have it block Fedora7LiveCD Jeremy From a.badger at gmail.com Wed Feb 7 16:00:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 Feb 2007 08:00:04 -0800 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1170842980.3892.1.camel@scriabin.tannenrauch.ch> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <1170838061.45c9922d58224@imp.free.fr> <1170842980.3892.1.camel@scriabin.tannenrauch.ch> Message-ID: <1170864004.4306.30.camel@localhost.localdomain> On Wed, 2007-02-07 at 11:09 +0100, G?rard Milmeister wrote: > On Wed, 2007-02-07 at 09:47 +0100, jfontain at free.fr wrote: > > Quoting Kevin Kofler : > > > > > Jean-Luc Fontaine free.fr> writes: > > > > Well, then there's gonna be a big problem with blt (now in extras, a > > > > graphical library) which is far from ready to compile against tcl-8.5, > > > > > > So fix it. :-) > > > > Unfortunately, I do not have the resources to fix and maintain such a > > complicated C library (many widgets) and the author has stated several times > > that he will wait for a list a stable tcl beta. > > Furthermore, my software (moodss, moomps) requires extreme stability in order to > > monitor reliably system resources (deamon). > > Unless somebody wants to tackle maintaining blt, I may have to pull my packages > > from F7 then... > One could also create a package compat-tcl-84. +1. Jesse, are there guidelines in Core for creating compat packages? Any input on who should be responsible for creating and maintaining compat packages when they're needed? -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 eswierk at arastra.com Wed Feb 7 16:45:54 2007 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 7 Feb 2007 08:45:54 -0800 Subject: qemu 0.9.0 in -devel In-Reply-To: <45C9A81C.8050206@gmail.com> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> <45C9A81C.8050206@gmail.com> Message-ID: On 2/7/07, dragoran wrote: > add -std-vga to the qemu command line and it works. Weird--that doesn't make any difference when I try it. SYSLINUX still hangs during "Loading initrd.img" after printing 90 or so dots. Which image are you booting? --Ed From alikins at redhat.com Wed Feb 7 17:06:35 2007 From: alikins at redhat.com (Adrian Likins) Date: Wed, 07 Feb 2007 12:06:35 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170354367.1547.50.camel@cutter> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <45C22FF2.30606@olen.net> <1170354367.1547.50.camel@cutter> Message-ID: <45CA071B.5050909@redhat.com> seth vidal wrote: > On Thu, 2007-02-01 at 19:22 +0100, Ola Thoresen wrote: > >> Mike McGrath wrote: >> >>> Hey guys, smolt is in a state now where it can be released and tested >>> by the general public. Currently smolt-firstboot has firstboot >>> integration with opt in/out. My question for the dev's is: >>> >>> Do we as a community want to include this by default in Fedora 7? >>> >> I can also see this as an extremely useful tool for IT-departments and >> companies trying to keep track of their hardware. >> So a nice feature would be to get a local copy of the smolt-server >> running, and then have all servers and workstations report to that >> server - either instead of or in addition to the fedora server. >> >> That way it would be easy to keep track of which workstations have been >> upgraded with more RAM, what chipset the different servers have and so on. >> >> Ofcourse one could also add a "module" for the local reporting that adds >> info such as ip and mac-address for network cards, different >> configuration parameters and so on. >> >> > > > +1 - that sounds like a very good idea. > In the local use case, it might be nice to add something like tracking package installs as well (hmm, that sounds familiar for some reason...). Ditto the kickstart, install log, etc. It could also be useful to send up the type of info found in sysreport. I think someone even started writing a module python based one at one point. Adrian From cweyl at alumni.drew.edu Wed Feb 7 17:16:15 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 7 Feb 2007 09:16:15 -0800 Subject: New new package process SUCKS! (read please) In-Reply-To: <20070205175010.45608b6e.mschwendt.tmp0701.nospam@arcor.de> References: <45C75908.8040003@hhs.nl> <20070205175010.45608b6e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <7dd7ab490702070916t2424a84ak1cfc6101e0f75695@mail.gmail.com> On 2/5/07, Michael Schwendt wrote: > On Mon, 05 Feb 2007 17:19:20 +0100, Hans de Goede wrote: > > I just went through my first new package under the new process (aka > > package no 100, so I'm experienced in this). The mail below may seem > > flamebate but it is mean't very seriously, so please take it seriously. > > What?! > > Do you say there is a new process also for Extras package submissions and > not just for the Merge reviews? Just to push this point (since I haven't seen anything one way or the other), is this new process applicable to all new package submissions/reviews going forward, or just the Core-merge reviews? -Chris -- Chris Weyl Ex astris, scientia From skvidal at linux.duke.edu Wed Feb 7 17:19:01 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 07 Feb 2007 12:19:01 -0500 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <45CA071B.5050909@redhat.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <45C22FF2.30606@olen.net> <1170354367.1547.50.camel@cutter> <45CA071B.5050909@redhat.com> Message-ID: <1170868741.1451.94.camel@cutter> On Wed, 2007-02-07 at 12:06 -0500, Adrian Likins wrote: > In the local use case, it might be nice to add something like tracking > package installs as well (hmm, that sounds familiar for some reason...). > Ditto the kickstart, install log, etc. > > It could also be useful to send up the type of info found in sysreport. > I think someone even started writing a module python based one at one > point. I ran this by a few folks at my office. They suggested: - packages installed - services chkconfig'd on - daemons running which all seemed like good ideas in the local use case. -sv From david at lovesunix.net Wed Feb 7 17:21:47 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 07 Feb 2007 18:21:47 +0100 Subject: rawhide report: 20070207 changes In-Reply-To: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> Message-ID: <1170868907.2967.2.camel@dawkins> ons, 07 02 2007 kl. 06:23 -0500, skrev buildsys at redhat.com: > hal-0.5.9-0.git20070206.1.fc7 > ----------------------------- > * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.1.fc7 > - Make sure /var/cache/hald exists and has right mode / permissions (notting) > > * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.fc7 > - Update to git snapshot > - Drop upstreamed patches > - Include hal-info snapshot in this SRPM for now (will be moved to it's > own SRPM eventually) > - Require ConsoleKit as this release denies some service to callers > not originating from an active desktop session (f-u-s requirement) After todays update HAL no longer starts. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 mmcgrath at fedoraproject.org Wed Feb 7 17:21:48 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 7 Feb 2007 11:21:48 -0600 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <1170868741.1451.94.camel@cutter> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <45C22FF2.30606@olen.net> <1170354367.1547.50.camel@cutter> <45CA071B.5050909@redhat.com> <1170868741.1451.94.camel@cutter> Message-ID: <3237e4410702070921k72bf1f97g129adc56e73c6d82@mail.gmail.com> On 2/7/07, seth vidal wrote: > On Wed, 2007-02-07 at 12:06 -0500, Adrian Likins wrote: > > > In the local use case, it might be nice to add something like tracking > > package installs as well (hmm, that sounds familiar for some reason...). > > Ditto the kickstart, install log, etc. > > > > It could also be useful to send up the type of info found in sysreport. > > I think someone even started writing a module python based one at one > > point. > > I ran this by a few folks at my office. They suggested: > > - packages installed > - services chkconfig'd on > - daemons running > > which all seemed like good ideas in the local use case. > Cool, so I've got a few more things to harden in the public view. After that we can extend smolt and smoon (the local smolt) to do those things probably without many problems. I'm having a heck of a time getting the python dbus bindings to do what I want. -Mike From david at fubar.dk Wed Feb 7 18:04:05 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Feb 2007 13:04:05 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170868907.2967.2.camel@dawkins> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170868907.2967.2.camel@dawkins> Message-ID: <1170871445.2858.0.camel@zelda.fubar.dk> On Wed, 2007-02-07 at 18:21 +0100, David Nielsen wrote: > ons, 07 02 2007 kl. 06:23 -0500, skrev buildsys at redhat.com: > > > > hal-0.5.9-0.git20070206.1.fc7 > > ----------------------------- > > * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.1.fc7 > > - Make sure /var/cache/hald exists and has right mode / permissions (notting) > > > > * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.fc7 > > - Update to git snapshot > > - Drop upstreamed patches > > - Include hal-info snapshot in this SRPM for now (will be moved to it's > > own SRPM eventually) > > - Require ConsoleKit as this release denies some service to callers > > not originating from an active desktop session (f-u-s requirement) > > After todays update HAL no longer starts. Did you file a bug? It works great for me and I've also had some other people test the RPM. David From zaitcev at redhat.com Wed Feb 7 18:03:44 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 7 Feb 2007 10:03:44 -0800 Subject: Kernel git repo hosting Message-ID: <20070207100344.8efbb97c.zaitcev@redhat.com> Hi, Dave, everyone: I am looking at publishing a git repository for a Fedora kernel fork, and I am running against the standard quota at people.redhat.com. Specifically, while space is there (barely), an non-packed repo has too many files. Also, it's a serious pain to upload the whole repo every time. It takes hours across my modem. So, I'd like to be able to use rsync. Do I have any options within the project? I'm not on welfare, I can pay my own hosting... Just thought to ask because I feel more comfortable within our own tent. Cheers, -- Pete From Fedora at FamilleCollet.com Wed Feb 7 18:09:41 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 07 Feb 2007 19:09:41 +0100 Subject: Smolt: Fedora Hardware Profiler In-Reply-To: <45CA071B.5050909@redhat.com> References: <3237e4410701310726y77ac4fcelbb84f2c029545a60@mail.gmail.com> <45C22FF2.30606@olen.net> <1170354367.1547.50.camel@cutter> <45CA071B.5050909@redhat.com> Message-ID: <45CA15E5.60402@FamilleCollet.com> >>>> >>> I can also see this as an extremely useful tool for IT-departments >>> and companies trying to keep track of their hardware. >>> So a nice feature would be to get a local copy of the smolt-server >>> running, and then have all servers and workstations report to that >>> server - either instead of or in addition to the fedora server. >>> >>> That way it would be easy to keep track of which workstations have >>> been upgraded with more RAM, what chipset the different servers have >>> and so on. >>> >>> Ofcourse one could also add a "module" for the local reporting that >>> adds info such as ip and mac-address for network cards, different >>> configuration parameters and so on. >>> You should have a look ? OCS NG : http://ocsinventory.sourceforge.net/ Client already in the Extras. I'm working on RPM for the servers... Remi. From david at fubar.dk Wed Feb 7 18:11:00 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Feb 2007 13:11:00 -0500 Subject: Creating a jackuser group In-Reply-To: <1170856878.3564.92.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <1170856878.3564.92.camel@localhost.localdomain> Message-ID: <1170871860.2858.4.camel@zelda.fubar.dk> On Wed, 2007-02-07 at 06:01 -0800, Anthony Green wrote: > The plan that was discussed on fedora-music-list was to wrap qjackctl in > a script that checked to see if the user was part of the jackuser group > and, if not, popped up a dialog box asking if they wanted to join > (requiring root password via consolehelper script). How on earth can this be considered a good user experience? Please don't bother the user with such questions; fix the base system instead and please do this without having secret UNIX groups that one has to be part of. It's just _broken_ using group membership for such things. Thanks. David From david at fubar.dk Wed Feb 7 18:15:34 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Feb 2007 13:15:34 -0500 Subject: Creating a jackuser group In-Reply-To: <1170849384.2877.5.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> Message-ID: <1170872134.2858.7.camel@zelda.fubar.dk> On Wed, 2007-02-07 at 06:56 -0500, Dan Williams wrote: > Hmm; I wonder if there are better ways to do this. Debian/Ubuntu use > groups for networking stuff, and, for example, you can't talk to > NetworkManager unless you're in the 'netdev' group. Which is odd. > > So lets think about the user experience here. If somebody installs an > app that uses Jack or requires realtime audio capabilities, what's the > failure mode if they're not in the 'rtaudio' group? How would they know > what to do to be able to do realtime audio? How do they get told that > they need to got to system-config-users, enter the root password, and > add themselves? > > Just fixing up the lower layers and base permission scheme doesn't fix > the problem; we've got to think how it works vertically all down the > entire stack. About the last thing we want is a nice "Could not > initialize realtime audio" dialog in some app, which is par for the > course, but says _nothing_ about what failed, and how to fix it. Probably the right thing is to allow the process to run as realtime if, and only if, the user is logged into the local console. So I'd rather people try to figure out how to do that instead of papering over it with group membership and harassing the user with pointless questions. Thanks. David From jkeating at redhat.com Wed Feb 7 18:23:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 13:23:49 -0500 Subject: Kernel git repo hosting In-Reply-To: <20070207100344.8efbb97c.zaitcev@redhat.com> References: <20070207100344.8efbb97c.zaitcev@redhat.com> Message-ID: <200702071323.49975.jkeating@redhat.com> On Wednesday 07 February 2007 13:03, Pete Zaitcev wrote: > I am looking at publishing a git repository for a Fedora kernel fork, and > I am running against the standard quota at people.redhat.com. Specifically, > while space is there (barely), an non-packed repo has too many files. Also, > it's a serious pain to upload the whole repo every time. It takes hours > across my modem. So, I'd like to be able to use rsync. > > Do I have any options within the project? I'm not on welfare, I can pay > my own hosting... Just thought to ask because I feel more comfortable > within our own tent. http://hosted.fedoraproject.org has git space should you need it. Uses the Fedora Account System for authentication for write, otherwise you can pull anonymously (once we get gitweb setup correctly). You can have a git repo without having a Trac instance, should you not want/need it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at lovesunix.net Wed Feb 7 18:26:28 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 07 Feb 2007 19:26:28 +0100 Subject: rawhide report: 20070207 changes In-Reply-To: <1170871445.2858.0.camel@zelda.fubar.dk> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170868907.2967.2.camel@dawkins> <1170871445.2858.0.camel@zelda.fubar.dk> Message-ID: <1170872788.2967.7.camel@dawkins> ons, 07 02 2007 kl. 13:04 -0500, skrev David Zeuthen: > On Wed, 2007-02-07 at 18:21 +0100, David Nielsen wrote: > > ons, 07 02 2007 kl. 06:23 -0500, skrev buildsys at redhat.com: > > > > > > > hal-0.5.9-0.git20070206.1.fc7 > > > ----------------------------- > > > * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.1.fc7 > > > - Make sure /var/cache/hald exists and has right mode / permissions (notting) > > > > > > * Tue Feb 06 2007 David Zeuthen - 0.5.9-0.git20070206.fc7 > > > - Update to git snapshot > > > - Drop upstreamed patches > > > - Include hal-info snapshot in this SRPM for now (will be moved to it's > > > own SRPM eventually) > > > - Require ConsoleKit as this release denies some service to callers > > > not originating from an active desktop session (f-u-s requirement) > > > > After todays update HAL no longer starts. > > Did you file a bug? It works great for me and I've also had some other > people test the RPM. Upon investigation this appears to be a SELinux policy issue actually, I see the following in dmesg after attempting to start HAL: audit(1170872559.797:8): avc: denied { write } for pid=4679 comm="hald-generate-f" name="hald" dev=dm-3 ino=4653249 scontext=user_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir However the policy relabeling is a tad problematic as seen in #227702 - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Wed Feb 7 18:30:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 18:30:18 +0000 Subject: Kernel git repo hosting In-Reply-To: <20070207100344.8efbb97c.zaitcev@redhat.com> References: <20070207100344.8efbb97c.zaitcev@redhat.com> Message-ID: <1170873018.29759.1187.camel@pmac.infradead.org> On Wed, 2007-02-07 at 10:03 -0800, Pete Zaitcev wrote: > I am looking at publishing a git repository for a Fedora kernel fork, and > I am running against the standard quota at people.redhat.com. Specifically, > while space is there (barely), an non-packed repo has too many files. Also, > it's a serious pain to upload the whole repo every time. It takes hours > across my modem. So, I'd like to be able to use rsync. Er, why would you either upload the whole repo each time _or_ use rsync? What's wrong with 'git-push' over ssh? > Do I have any options within the project? I'm not on welfare, I can pay > my own hosting... Just thought to ask because I feel more comfortable > within our own tent. Obviously you're welcome to an account on git.infradead.org, but it sounds like that's not what you're after. -- dwmw2 From hughsient at gmail.com Wed Feb 7 18:48:09 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 07 Feb 2007 18:48:09 +0000 Subject: rawhide report: 20070207 changes In-Reply-To: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> Message-ID: <1170874089.30879.6.camel@hughsie-laptop> On Wed, 2007-02-07 at 06:23 -0500, buildsys at redhat.com wrote: > hal-0.5.9-0.git20070206.1.fc7 > ----------------------------- > - Include hal-info snapshot in this SRPM for now (will be moved to > it's own SRPM eventually) This *has* to be done before F7 - want me to file a bug? Richard. From florin at andrei.myip.org Wed Feb 7 18:50:57 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 07 Feb 2007 10:50:57 -0800 Subject: Creating a jackuser group In-Reply-To: <1170872134.2858.7.camel@zelda.fubar.dk> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <1170872134.2858.7.camel@zelda.fubar.dk> Message-ID: <45CA1F91.1000903@andrei.myip.org> David Zeuthen wrote: > > Probably the right thing is to allow the process to run as realtime if, > and only if, the user is logged into the local console. So I'd rather > people try to figure out how to do that instead of papering over it with > group membership and harassing the user with pointless questions. > Thanks. I see your point. But if I may - using realtime groups for JACK is pretty much standard practice in the Linux audio community for Fedora and similar distributions. Spend some time on the LAU (Linux Audio Users) mailing list, actually go ahead and install and test jackd, qjackctl, a couple synths and a sequencer and you'll see what I mean. I'm not saying it's the best solution. I'm just saying this has been used for a long time and there were no riots in the LAU community over the real or perceived issues of this method. Also, allowing any local user realtime privileges may open up other problems. Debian has a special user group (the "audio" group) for such things. The examples may probably continue. I think the problem that LAU is facing is that the things that they do are not widely known and understood. _That_ is the biggest hurdle in integrating advanced audio features in mainstream distributions. -- Florin Andrei http://florin.myip.org/ From jkeating at redhat.com Wed Feb 7 18:52:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 13:52:27 -0500 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1170864004.4306.30.camel@localhost.localdomain> References: <1170748677.45c8350535560@imp.free.fr> <1170842980.3892.1.camel@scriabin.tannenrauch.ch> <1170864004.4306.30.camel@localhost.localdomain> Message-ID: <200702071352.27469.jkeating@redhat.com> On Wednesday 07 February 2007 11:00, Toshio Kuratomi wrote: > +1. ?Jesse, are there guidelines in Core for creating compat packages? > Any input on who should be responsible for creating and maintaining > compat packages when they're needed? Hrm, I thought we did, but I'm not seeing anything in a wiki search :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From florin at andrei.myip.org Wed Feb 7 19:13:49 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 07 Feb 2007 11:13:49 -0800 Subject: Creating a jackuser group In-Reply-To: <1170849384.2877.5.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> Message-ID: <45CA24ED.4070702@andrei.myip.org> Dan Williams wrote: > > Hmm; I wonder if there are better ways to do this. Debian/Ubuntu use > groups for networking stuff, and, for example, you can't talk to > NetworkManager unless you're in the 'netdev' group. Which is odd. We also have to take into consideration what the upstream recommends. http://jackit.sourceforge.net/docs/faq.php#a52 Realtime groups seems to be the recommendation from upstream. > So lets think about the user experience here. If somebody installs an > app that uses Jack or requires realtime audio capabilities, what's the > failure mode if they're not in the 'rtaudio' group? How would they know > what to do to be able to do realtime audio? How do they get told that > they need to got to system-config-users, enter the root password, and > add themselves? Best-case scenario, the apps will silently drop RT capabilities. Everything will just work fine, except when there's a CPU load spike, when jackd may or may not drop a few chunks of audio stream. That may get noticed by the user as clicks and pops, or not, depending on many factors. Most of the time on an otherwise idle system, there will be no difference. Worst-case scenario... I guess someone with more experience should chime in here. I don't think there's any difference from the best-case I just described. At least, I can't remember any situation when anything happened that was worse than the best-case described above (silent dropping of RT capabilities). If I'm not mistaken, it's just jackd that actually has to acquire RT. The other JACK-enabled apps just hook up into that. But feel free to correct me if I'm wrong. Finally, please keep in mind that RT capabilities are more of an advanced user thing. Well, that's debatable, of course, but people who absolutely need RT and cannot live without it are probably those who load up a bunch of synths on a laptop, hook up a MIDI keyboard and perform on stage. Also, enthusiasts like me will arguably need RT as a basic requirement that cannot be replaced by something else. All these people will be glad to click on a pop-up, enter a root password and do such things to enable RT. This will be perceived as an improvement over the current situation, which requires reading docs, making manual changes to obscure system files (with the potential to break the whole system) and stuff like that. The most casual users (those who may test ZynAddSubFX a couple times then forget it) do not need RT, and can simply dismiss a pop-up with few ill effects (the performance will remain at the default non-RT level). But if the user interaction is simple enough ("enter root password to enable RT for best audio performance") then why not give them that capability? -- Florin Andrei http://florin.myip.org/ From notting at redhat.com Wed Feb 7 19:15:19 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Feb 2007 14:15:19 -0500 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> <20070204003924.0a1febd2@lain.camperquake.de> <45C526BC.2070909@interplas.com> <20070204045223.GB11220@nostromo.devel.redhat.com> Message-ID: <20070207191519.GB24204@nostromo.devel.redhat.com> Matej Cepl (mcepl at redhat.com) said: > b) and all reasonable MTAs support /usr/sbin/sendmail -- what does it have > to do with choice of particular package for Fedora? Nothing, just commenting that a package that matches /usr/sbin/sendmail in 'strings' output probably is not sendmail specific (which is what was being implied in the original mail.) Bill From mclasen at redhat.com Wed Feb 7 19:25:38 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 Feb 2007 14:25:38 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170874089.30879.6.camel@hughsie-laptop> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> Message-ID: <1170876338.3444.0.camel@localhost.localdomain> On Wed, 2007-02-07 at 18:48 +0000, Richard Hughes wrote: > On Wed, 2007-02-07 at 06:23 -0500, buildsys at redhat.com wrote: > > hal-0.5.9-0.git20070206.1.fc7 > > ----------------------------- > > - Include hal-info snapshot in this SRPM for now (will be moved to > > it's own SRPM eventually) > > This *has* to be done before F7 - want me to file a bug? > Please put it on FC7Blocker then. From mclasen at redhat.com Wed Feb 7 19:36:05 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 Feb 2007 14:36:05 -0500 Subject: Creating a jackuser group In-Reply-To: <45CA24ED.4070702@andrei.myip.org> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> Message-ID: <1170876965.3444.7.camel@localhost.localdomain> On Wed, 2007-02-07 at 11:13 -0800, Florin Andrei wrote: > > Finally, please keep in mind that RT capabilities are more of an > advanced user thing. Well, that's debatable, of course, but people who > absolutely need RT and cannot live without it are probably those who > load up a bunch of synths on a laptop, hook up a MIDI keyboard and > perform on stage. > Also, enthusiasts like me will arguably need RT as a basic requirement > that cannot be replaced by something else. > > All these people will be glad to click on a pop-up, enter a root > password and do such things to enable RT. This will be perceived as an > improvement over the current situation, which requires reading docs, > making manual changes to obscure system files (with the potential to > break the whole system) and stuff like that. No, regular users will not be glad if they are forced to answer a question they have absolutely no idea about. How is a normal user going to be able to answer the question "Do you want to be added to the 'realtime' UNIX group" ? If realtime is a requirement for acceptable audio experience, then everybody needs to get it without extra questions asked. If it is not, then why bother ? From chitlesh at fedoraproject.org Wed Feb 7 19:32:23 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 7 Feb 2007 20:32:23 +0100 Subject: rawhide report: 20070207 changes In-Reply-To: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> Message-ID: <13dbfe4f0702071132l2eb6831bwf44abe0fde7d3a54@mail.gmail.com> On 2/7/07, buildsys at redhat.com wrote: > compiz-0.3.6-2.fc7 > ------------------ > * Tue Feb 06 2007 Kristian H?gsberg 0.3.6 > - Require gnome-session > 2.16 so it starts gtk-window-decorator. > - Update to desktop-effects 0.7.1 that doesn't refuse to work with Xinerama. > > * Tue Jan 16 2007 Kristian H?gsberg - 0.3.6-1 > - Update to 0.3.6, update patches. > - Drop autotool build requires. > - Drop glfinish.patch, cow.patch, resize-offset.patch and icon-menu-patch. > - Add libdecoration.so > - Update to desktop-effects-0.7.0, which spawns the right decorator > and plays nicely with unknown plugins. > > * Sat Nov 25 2006 Matthias Clasen - 0.3.4-2 > - Update the fedora logo patch (#217224) Hello, can anyone update the status of these RFE for compiz ?? How that new releases have been pushed how far is it compatible with kde ? and what are the actual problems still encountered by any fedora kde user ? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212987 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212239 Chitlesh -- http://clunixchit.blogspot.com From notting at redhat.com Wed Feb 7 19:31:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Feb 2007 14:31:18 -0500 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1170844673.45c9ac01ae15a@imp.free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <1170844673.45c9ac01ae15a@imp.free.fr> Message-ID: <20070207193118.GD24204@nostromo.devel.redhat.com> jfontain at free.fr (jfontain at free.fr) said: > Furthermore, from the Tcl developers at > http://www.tcl.tk/software/tcltk/8.5.html: > > Latest Release: Tcl/Tk 8.5a5 (Oct 20, 2006) > ... > This version is still in development; most users should be using the latest > stable version of Tcl/Tk. Jumping in late... when is 8.5 final intended to be released? Bill From wart at kobold.org Wed Feb 7 19:43:09 2007 From: wart at kobold.org (Michael Thomas) Date: Wed, 07 Feb 2007 11:43:09 -0800 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <20070207193118.GD24204@nostromo.devel.redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <1170844673.45c9ac01ae15a@imp.free.fr> <20070207193118.GD24204@nostromo.devel.redhat.com> Message-ID: <45CA2BCD.3080201@kobold.org> Bill Nottingham wrote: > jfontain at free.fr (jfontain at free.fr) said: >> Furthermore, from the Tcl developers at >> http://www.tcl.tk/software/tcltk/8.5.html: >> >> Latest Release: Tcl/Tk 8.5a5 (Oct 20, 2006) >> ... >> This version is still in development; most users should be using the latest >> stable version of Tcl/Tk. > > Jumping in late... when is 8.5 final intended to be released? This was asked on comp.lang.tcl yesterday, and the response was a pointer to the tcl wiki, which hasn't been updated since Nov. 20: http://wiki.tcl.tk/12753 It seems that the beta release was roughly due in December, but has not appeared yet. No timeframe is given for the 8.5 final release. --Wart From notting at redhat.com Wed Feb 7 19:48:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Feb 2007 14:48:41 -0500 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CA2BCD.3080201@kobold.org> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <1170844673.45c9ac01ae15a@imp.free.fr> <20070207193118.GD24204@nostromo.devel.redhat.com> <45CA2BCD.3080201@kobold.org> Message-ID: <20070207194841.GA25631@nostromo.devel.redhat.com> Michael Thomas (wart at kobold.org) said: > >Jumping in late... when is 8.5 final intended to be released? > > This was asked on comp.lang.tcl yesterday, and the response was a > pointer to the tcl wiki, which hasn't been updated since Nov. 20: > > http://wiki.tcl.tk/12753 > > It seems that the beta release was roughly due in December, but has not > appeared yet. No timeframe is given for the 8.5 final release. That implies to me that we probably *don't* want 8.5 in F7. Bill From david at fubar.dk Wed Feb 7 19:52:01 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Feb 2007 14:52:01 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170872788.2967.7.camel@dawkins> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170868907.2967.2.camel@dawkins> <1170871445.2858.0.camel@zelda.fubar.dk> <1170872788.2967.7.camel@dawkins> Message-ID: <1170877921.3315.6.camel@zelda.fubar.dk> On Wed, 2007-02-07 at 19:26 +0100, David Nielsen wrote: > Upon investigation this appears to be a SELinux policy issue actually, > I see the following in dmesg after attempting to start HAL: > > audit(1170872559.797:8): avc: denied { write } for pid=4679 > comm="hald-generate-f" name="hald" dev=dm-3 ino=4653249 > scontext=user_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_t:s0 > tclass=dir > > However the policy relabeling is a tad problematic as seen in #227702 I'm slightly annoyed that everytime I do the smallest change in HAL then SELinux breaks something insofar that it prevents HAL from doing what it needs to do. In a way it's good, it's what SELinux is _supposed_ to do but it's just bloody annoying nonetheless. Maybe the policy is too strict, maybe HAL is moving too fast. I don't know. So I really really wish I could ship the SELinux policy for HAL _along_ with the HAL tarball then I could fix this up before releases etc. etc. Having it decoupled as it is now is just a really bad idea I think. Also, it might educate other vendors that SELinux is a pretty good idea given that it prevents so many things from happening. Dan, is that going to possible to do anytime soon? David From florin at andrei.myip.org Wed Feb 7 19:56:07 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 07 Feb 2007 11:56:07 -0800 Subject: Creating a jackuser group In-Reply-To: <1170876965.3444.7.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> <1170876965.3444.7.camel@localhost.localdomain> Message-ID: <45CA2ED7.30708@andrei.myip.org> Matthias Clasen wrote: > > No, regular users will not be glad if they are forced to answer a > question they have absolutely no idea about. How is a normal user going > to be able to answer the question "Do you want to be added to the > 'realtime' UNIX group" ? Why use such an obscure phrase? Think from the user's perspective, not from the OS's. "Enter root password to improve audio performance for your account" Better, huh? ;-) > If realtime is a requirement for acceptable audio experience, then > everybody needs to get it without extra questions asked. If it is not, > then why bother ? It's not either black or white. Just to play MP3s, RT is not needed, indeed. But to run a software synth and jackd in any other way than just plain casual, it pretty much is a requirement. There might be some security implications to allowing each and every user account RT capabilities by default. But I'll leave that explanation to people who are more knowledgeable in this field. -- Florin Andrei http://florin.myip.org/ From jima at beer.tclug.org Wed Feb 7 19:58:30 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 7 Feb 2007 13:58:30 -0600 (CST) Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <20070207194841.GA25631@nostromo.devel.redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <1170844673.45c9ac01ae15a@imp.free.fr> <20070207193118.GD24204@nostromo.devel.redhat.com> <45CA2BCD.3080201@kobold.org> <20070207194841.GA25631@nostromo.devel.redhat.com> Message-ID: On Wed, 7 Feb 2007, Bill Nottingham wrote: > Michael Thomas (wart at kobold.org) said: >> It seems that the beta release was roughly due in December, but has not >> appeared yet. No timeframe is given for the 8.5 final release. > > That implies to me that we probably *don't* want 8.5 in F7. And when it comes out, it'll need an Epoch. Whose idea was it to use 8.5a5 for the Version? I thought that went against the guidelines (in favor of, say, V-R 8.5-0.1.a%{?dist}). Huh, whatdya know: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease Jima From jkeating at redhat.com Wed Feb 7 20:00:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 15:00:05 -0500 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: References: <1170748677.45c8350535560@imp.free.fr> <20070207194841.GA25631@nostromo.devel.redhat.com> Message-ID: <200702071500.05940.jkeating@redhat.com> On Wednesday 07 February 2007 14:58, Jima wrote: > ? And when it comes out, it'll need an Epoch. ?Whose idea was it to use > 8.5a5 for the Version? ?I thought that went against the guidelines (in > favor of, say, V-R 8.5-0.1.a%{?dist}). > ? Huh, whatdya know: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease Yeah, a fun case of somebody not following the guidelines :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Wed Feb 7 20:13:44 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Feb 2007 15:13:44 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170874089.30879.6.camel@hughsie-laptop> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> Message-ID: <1170879224.3315.11.camel@zelda.fubar.dk> On Wed, 2007-02-07 at 18:48 +0000, Richard Hughes wrote: > On Wed, 2007-02-07 at 06:23 -0500, buildsys at redhat.com wrote: > > hal-0.5.9-0.git20070206.1.fc7 > > ----------------------------- > > - Include hal-info snapshot in this SRPM for now (will be moved to > > it's own SRPM eventually) > > This *has* to be done before F7 - want me to file a bug? Even better; if you can package it up for Extras then the two of us can co-maintain it and I'll make the next hal build pull it in. How about that? Of course, this is only true if hal (which used to be in Core) can now pull in packages from Extras.... or whatever we call it now. Can anyone confirm this? David From davej at redhat.com Wed Feb 7 20:18:21 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 7 Feb 2007 15:18:21 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170877921.3315.6.camel@zelda.fubar.dk> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170868907.2967.2.camel@dawkins> <1170871445.2858.0.camel@zelda.fubar.dk> <1170872788.2967.7.camel@dawkins> <1170877921.3315.6.camel@zelda.fubar.dk> Message-ID: <20070207201821.GA2597@redhat.com> On Wed, Feb 07, 2007 at 02:52:01PM -0500, David Zeuthen wrote: > On Wed, 2007-02-07 at 19:26 +0100, David Nielsen wrote: > > Upon investigation this appears to be a SELinux policy issue actually, > > I see the following in dmesg after attempting to start HAL: > > > > audit(1170872559.797:8): avc: denied { write } for pid=4679 > > comm="hald-generate-f" name="hald" dev=dm-3 ino=4653249 > > scontext=user_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_t:s0 > > tclass=dir > > > > However the policy relabeling is a tad problematic as seen in #227702 > > I'm slightly annoyed that everytime I do the smallest change in HAL then > SELinux breaks something insofar that it prevents HAL from doing what it > needs to do. In a way it's good, it's what SELinux is _supposed_ to do > but it's just bloody annoying nonetheless. Maybe the policy is too > strict, maybe HAL is moving too fast. I don't know. I'm puzzled why you're not seeing these when you test the code before pushing it. Are you running with selinux disabled ? Or is it failing only in certain hardware configurations that you don't have? Dave -- http://www.codemonkey.org.uk From jkeating at redhat.com Wed Feb 7 20:24:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 15:24:07 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170879224.3315.11.camel@zelda.fubar.dk> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> Message-ID: <200702071524.08122.jkeating@redhat.com> On Wednesday 07 February 2007 15:13, David Zeuthen wrote: > Of course, this is only true if hal (which used to be in Core) can now > pull in packages from Extras.... or whatever we call it now. Can anyone > confirm this? Not yet, only once the SCMs and buildsystems merge. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dyek at real.com Wed Feb 7 20:27:37 2007 From: dyek at real.com (Daniel Yek) Date: Wed, 07 Feb 2007 12:27:37 -0800 Subject: Is there a NFS alternative? Message-ID: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> Hi, It was a while ago when I read that NFS was difficult to secure with (the use of) ssh and iptables (or something like that). I really needed an alternative that works and can be made secure. Is GFS a suitable replacement for NFS? If not, what is the closest thing to NFS? Thanks. -- Daniel Yek From david at fubar.dk Wed Feb 7 20:30:09 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Feb 2007 15:30:09 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <200702071524.08122.jkeating@redhat.com> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> <200702071524.08122.jkeating@redhat.com> Message-ID: <1170880209.3315.22.camel@zelda.fubar.dk> On Wed, 2007-02-07 at 15:24 -0500, Jesse Keating wrote: > On Wednesday 07 February 2007 15:13, David Zeuthen wrote: > > Of course, this is only true if hal (which used to be in Core) can now > > pull in packages from Extras.... or whatever we call it now. Can anyone > > confirm this? > > Not yet, only once the SCMs and buildsystems merge. OK, when is this supposed to happen? (For the record, I also want gnome-mount to pull in ntfs-3g and make hal pull in libsmbios once Matt, his colleagues or others have packaged it up [1] for Fedora (hint hint nudge nudge) - the latter means that Dell laptops can have their backlight controlled via g-p-m etc.) David From pemboa at gmail.com Wed Feb 7 20:44:07 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 7 Feb 2007 14:44:07 -0600 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> Message-ID: <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> On 2/7/07, Daniel Yek wrote: > Hi, > > It was a while ago when I read that NFS was difficult to secure with (the > use of) ssh and iptables (or something like that). > > I really needed an alternative that works and can be made secure. Is GFS a > suitable replacement for NFS? If not, what is the closest thing to NFS? > > Thanks. Subdue NFS to use only one port, firewall all other ports off....possible filter the NFS port too? -- Fedora Core 6 and proud From dyek at real.com Wed Feb 7 20:50:44 2007 From: dyek at real.com (Daniel Yek) Date: Wed, 07 Feb 2007 12:50:44 -0800 Subject: Is there a NFS alternative? In-Reply-To: <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.co m> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> Message-ID: <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> At 12:44 PM 2/7/2007, Arthur Pemberton wrote: >On 2/7/07, Daniel Yek wrote: >>Hi, >> >>It was a while ago when I read that NFS was difficult to secure with (the >>use of) ssh and iptables (or something like that). >> >>I really needed an alternative that works and can be made secure. Is GFS a >>suitable replacement for NFS? If not, what is the closest thing to NFS? >> >>Thanks. > >Subdue NFS to use only one port, firewall all other ports >off....possible filter the NFS port too? Thanks for replying. That is what I read and I was looking for an alternative to that. Is there other solution? Or this is the best available solution already? -- Daniel Yek From pemboa at gmail.com Wed Feb 7 20:52:01 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 7 Feb 2007 14:52:01 -0600 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> Message-ID: <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> On 2/7/07, Daniel Yek wrote: > At 12:44 PM 2/7/2007, Arthur Pemberton wrote: > >On 2/7/07, Daniel Yek wrote: > >>Hi, > >> > >>It was a while ago when I read that NFS was difficult to secure with (the > >>use of) ssh and iptables (or something like that). > >> > >>I really needed an alternative that works and can be made secure. Is GFS a > >>suitable replacement for NFS? If not, what is the closest thing to NFS? > >> > >>Thanks. > > > >Subdue NFS to use only one port, firewall all other ports > >off....possible filter the NFS port too? > > Thanks for replying. > > That is what I read and I was looking for an alternative to that. Is there > other solution? Or this is the best available solution already? Well, if you can suggest how the solution could be made better, I or others can maybe suggest how to implement it. The only other thing i can thing of is have port mapper interface with iptables in a plug and play type firewall way (or however Windows refers to it) -- Fedora Core 6 and proud From hughsient at gmail.com Wed Feb 7 20:51:52 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 07 Feb 2007 20:51:52 +0000 Subject: rawhide report: 20070207 changes In-Reply-To: <20070207201821.GA2597@redhat.com> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170868907.2967.2.camel@dawkins> <1170871445.2858.0.camel@zelda.fubar.dk> <1170872788.2967.7.camel@dawkins> <1170877921.3315.6.camel@zelda.fubar.dk> <20070207201821.GA2597@redhat.com> Message-ID: <1170881512.11255.2.camel@hughsie-laptop> On Wed, 2007-02-07 at 15:18 -0500, Dave Jones wrote: > > I'm puzzled why you're not seeing these when you test the code before > pushing it. Are you running with selinux disabled ? > Or is it failing only in certain hardware configurations that you > don't have? I didn't catch it as selinux is disabled on my box... Richard. From tibbs at math.uh.edu Wed Feb 7 21:02:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Feb 2007 15:02:06 -0600 Subject: Creating a jackuser group In-Reply-To: <1170807189.3564.75.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <1170807189.3564.75.camel@localhost.localdomain> Message-ID: >>>>> "AG" == Anthony Green writes: AG> Perhaps. What other software needs to tweak limits.conf with AG> exactly the same parameterized permissions? Pulseaudio? CD writing has in the past wanted the priority boost, but probably not the mlock limit adjustement (although perhaps it wouldn't hurt). - J< From mattdm at mattdm.org Wed Feb 7 21:08:59 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 7 Feb 2007 16:08:59 -0500 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> Message-ID: <20070207210859.GA8671@jadzia.bu.edu> On Wed, Feb 07, 2007 at 12:27:37PM -0800, Daniel Yek wrote: > I really needed an alternative that works and can be made secure. Is GFS a > suitable replacement for NFS? If not, what is the closest thing to NFS? The only thing GFS shares with NFS is the letters "F" and "S". It is otherwise an entirely different thing. The closest thing to what you want is NFSv4 with Kerberos. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From hughsient at gmail.com Wed Feb 7 20:49:47 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 07 Feb 2007 20:49:47 +0000 Subject: rawhide report: 20070207 changes In-Reply-To: <1170879224.3315.11.camel@zelda.fubar.dk> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> Message-ID: <1170881387.11255.1.camel@hughsie-laptop> On Wed, 2007-02-07 at 15:13 -0500, David Zeuthen wrote: > Even better; if you can package it up for Extras then the two of us > can > co-maintain it and I'll make the next hal build pull it in. How about > that? That's no problem. Until we have core and extras merged, there is a SRPM package here: http://people.freedesktop.org/~hughsient/fedora/6/SRPMS/ Richard. From bruno at wolff.to Wed Feb 7 21:19:49 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 7 Feb 2007 15:19:49 -0600 Subject: [RFE] install from software raid in f7 In-Reply-To: <45C9C05E.8000103@gmail.com> References: <45C9C05E.8000103@gmail.com> Message-ID: <20070207211949.GA7208@wolff.to> On Wed, Feb 07, 2007 at 13:04:46 +0100, dragoran wrote: > Hello, > Anaconda is able to install from harddisk. But this does not work if the > images are on a mdraid device. (cannot select it). > Anaconda is able to mount md raid devices (see rescue mode). So is it > possible to add this feature to f7? (point to md raid device and > install/update from there). > This will not only make it possible to do harddisk installs fro people > which does not have a non raid partiton on there disks (exept /boot > which is to small), but this (raid0,raid5) would also be the fastest > install source (comparing with non raid hdd or optical media). I have a bugzilla entry (227474) related to this. From jkeating at redhat.com Wed Feb 7 21:42:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Feb 2007 16:42:46 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170880209.3315.22.camel@zelda.fubar.dk> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <200702071524.08122.jkeating@redhat.com> <1170880209.3315.22.camel@zelda.fubar.dk> Message-ID: <200702071642.46731.jkeating@redhat.com> On Wednesday 07 February 2007 15:30, David Zeuthen wrote: > OK, when is this supposed to happen? > > (For the record, I also want gnome-mount to pull in ntfs-3g and make hal > pull in libsmbios once Matt, his colleagues or others have packaged it > up [1] for Fedora (hint hint nudge nudge) - the latter means that Dell > laptops can have their backlight controlled via g-p-m etc.) ASAP, blocked by legal right now on a license for the buildsystem. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sander at hoentjen.eu Wed Feb 7 21:46:12 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Wed, 07 Feb 2007 22:46:12 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <200702071500.05940.jkeating@redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <20070207194841.GA25631@nostromo.devel.redhat.com> <200702071500.05940.jkeating@redhat.com> Message-ID: <1170884772.12523.3.camel@peecee.hoentjen.eu> On Wed, 2007-02-07 at 15:00 -0500, Jesse Keating wrote: > On Wednesday 07 February 2007 14:58, Jima wrote: > > And when it comes out, it'll need an Epoch. Whose idea was it to use > > 8.5a5 for the Version? I thought that went against the guidelines (in > > favor of, say, V-R 8.5-0.1.a%{?dist}). > > Huh, whatdya know: > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease > > Yeah, a fun case of somebody not following the guidelines :/ > Can it not be fixed now? After all it is rawhide, people using it should now how to fix stuff.. But it would have been better if it had been avoided of course. :) From galibert at pobox.com Wed Feb 7 21:52:52 2007 From: galibert at pobox.com (Olivier Galibert) Date: Wed, 7 Feb 2007 22:52:52 +0100 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> Message-ID: <20070207215252.GA20425@dspnet.fr.eu.org> On Wed, Feb 07, 2007 at 12:27:37PM -0800, Daniel Yek wrote: > Hi, > > It was a while ago when I read that NFS was difficult to secure with (the > use of) ssh and iptables (or something like that). > > I really needed an alternative that works and can be made secure. Is GFS a > suitable replacement for NFS? If not, what is the closest thing to NFS? What is your threat model? What do you want to be secured against? OG. From david at fubar.dk Wed Feb 7 21:53:38 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Feb 2007 16:53:38 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <20070207201821.GA2597@redhat.com> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170868907.2967.2.camel@dawkins> <1170871445.2858.0.camel@zelda.fubar.dk> <1170872788.2967.7.camel@dawkins> <1170877921.3315.6.camel@zelda.fubar.dk> <20070207201821.GA2597@redhat.com> Message-ID: <1170885218.3315.26.camel@zelda.fubar.dk> On Wed, 2007-02-07 at 15:18 -0500, Dave Jones wrote: > I'm puzzled why you're not seeing these when you test the code before > pushing it. Are you running with selinux disabled ? > Or is it failing only in certain hardware configurations that you don't have? Bah, mea culpa. I need to admit I wasn't running SELinux in Enforcing mode on the laptop I was testing it on. I see the issues in the AVC log as it's running Permissive mode. Still, some of my complaints still stand: As a developer, SELinux right now is a thing that gets more in my way than I like it to. It's probably specific to HAL as it runs with lots of privileges to do stuff. David From lsof at nodata.co.uk Wed Feb 7 21:53:52 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 07 Feb 2007 22:53:52 +0100 Subject: Is there a NFS alternative? In-Reply-To: <20070207210859.GA8671@jadzia.bu.edu> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <20070207210859.GA8671@jadzia.bu.edu> Message-ID: <1170885232.3189.8.camel@sb-home.lan> Am Mittwoch, den 07.02.2007, 16:08 -0500 schrieb Matthew Miller: > On Wed, Feb 07, 2007 at 12:27:37PM -0800, Daniel Yek wrote: > > I really needed an alternative that works and can be made secure. Is GFS a > > suitable replacement for NFS? If not, what is the closest thing to NFS? > > > The only thing GFS shares with NFS is the letters "F" and "S". It is > otherwise an entirely different thing. > > The closest thing to what you want is NFSv4 with Kerberos. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > and perhaps -o tcp with udp firewalled? From lamont at gurulabs.com Wed Feb 7 22:04:46 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 7 Feb 2007 15:04:46 -0700 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> Message-ID: <200702071504.47527.lamont@gurulabs.com> On Wednesday 07 February 2007 01:27pm, Daniel Yek wrote: > Hi, > > It was a while ago when I read that NFS was difficult to secure with (the > use of) ssh and iptables (or something like that). > > I really needed an alternative that works and can be made secure. Is GFS a > suitable replacement for NFS? If not, what is the closest thing to NFS? Kerberized NFS, preferably NFS4. AndrewFS or CodaFS. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ihok at hotmail.com Wed Feb 7 22:04:16 2007 From: ihok at hotmail.com (Jack Tanner) Date: Wed, 07 Feb 2007 17:04:16 -0500 Subject: Creating a jackuser group In-Reply-To: <1170872134.2858.7.camel@zelda.fubar.dk> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <1170872134.2858.7.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > Probably the right thing is to allow the process to run as realtime if, > and only if, the user is logged into the local console. So I'd rather Er, please don't. That's not the right abstraction. That would make it painful to play with audio on a headless system (e.g., one that's plugged into good speakers on the house stereo)... As it is, in order to use a headless system *just for playing sound remotely* I have to create an 'audio' group, add myself to it, and give the group local rights. I still haven't figured out a clean way of playing video remotely. From vonbrand at inf.utfsm.cl Wed Feb 7 22:20:38 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 07 Feb 2007 19:20:38 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: <200702070846.03555.jkeating@redhat.com> References: <1170674703.29759.758.camel@pmac.infradead.org> <1170802073.29759.1008.camel@pmac.infradead.org> <1170830538.3837.15.camel@pensja.lam.pl> <200702070846.03555.jkeating@redhat.com> Message-ID: <200702072220.l17MKcDt005480@laptop13.inf.utfsm.cl> Jesse Keating wrote: > On Wednesday 07 February 2007 01:42, Leszek Matok wrote: > > By the way, does anyone know, which MTA will be the default for RHEL 5? > I think it will be sendmail. Path of least surprise. Much harder to > make any sort of change like that in RHEL :/ That alone would be a reason of some weight to keep the same for Fedora... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Wed Feb 7 22:23:32 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 07 Feb 2007 19:23:32 -0300 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> Message-ID: <200702072223.l17MNWDU005540@laptop13.inf.utfsm.cl> Bojan Smojver wrote: > David Woodhouse infradead.org> writes: > > If we ship a fully-fledged MTA as default, then Exim seems to make most > > sense. > > [..snip..] > > > But again, there's an > > advantage to having a single tool which can provide the _full_ range of > > functionality from low end to high end without the user ever having to > > throw one tool away and start learning a new one from scratch because > > they want to do something which the one they're currently using can't > > handle. > > Never used Exim, so I'm not really sure how much truth is in the author's > statement: > > "The bottom line is that Exim does not perform particularly well in > environments where the queue regularly gets very large. It was never > designed for this; deliveries from the queue were always intended to be > 'exceptions' rather than the norm." I have a machine here (FallbackMX for our mailing list handler, will probably do the same duty for our regular mailservers soon) where the queue is normally around 2000 messages, with highs in the low 4000s. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From zaitcev at redhat.com Wed Feb 7 22:28:26 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 7 Feb 2007 14:28:26 -0800 Subject: Kernel git repo hosting In-Reply-To: <1170873018.29759.1187.camel@pmac.infradead.org> References: <20070207100344.8efbb97c.zaitcev@redhat.com> <1170873018.29759.1187.camel@pmac.infradead.org> Message-ID: <20070207142826.c1586133.zaitcev@redhat.com> On Wed, 07 Feb 2007 18:30:18 +0000, David Woodhouse wrote: > On Wed, 2007-02-07 at 10:03 -0800, Pete Zaitcev wrote: > > it's a serious pain to upload the whole repo every time. It takes hours > > across my modem. So, I'd like to be able to use rsync. > > Er, why would you either upload the whole repo each time _or_ use rsync? > What's wrong with 'git-push' over ssh? Oh duh, sorry. I just found that charlotte allows access from VPN. I thought it wasn't the case. So yes, I can ssh there, but still, it does not help with running over the file quota, and she does not have git installed. Thanks for the offer, BTW. -- Pete From dwmw2 at infradead.org Wed Feb 7 22:41:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 22:41:19 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <200702072223.l17MNWDU005540@laptop13.inf.utfsm.cl> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702072223.l17MNWDU005540@laptop13.inf.utfsm.cl> Message-ID: <1170888079.29759.1194.camel@pmac.infradead.org> On Wed, 2007-02-07 at 19:23 -0300, Horst H. von Brand wrote: > I have a machine here (FallbackMX for our mailing list handler, will > probably do the same duty for our regular mailservers soon) where the queue > is normally around 2000 messages, with highs in the low 4000s. I see no reason why Exim shouldn't cope perfectly well with that. -- dwmw2 From dwmw2 at infradead.org Wed Feb 7 22:49:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 07 Feb 2007 22:49:02 +0000 Subject: Kernel git repo hosting In-Reply-To: <20070207142826.c1586133.zaitcev@redhat.com> References: <20070207100344.8efbb97c.zaitcev@redhat.com> <1170873018.29759.1187.camel@pmac.infradead.org> <20070207142826.c1586133.zaitcev@redhat.com> Message-ID: <1170888542.29759.1199.camel@pmac.infradead.org> On Wed, 2007-02-07 at 14:28 -0800, Pete Zaitcev wrote: > Oh duh, sorry. I just found that charlotte allows access from VPN. I thought > it wasn't the case. So yes, I can ssh there, Not entirely sure what the above means. If you weren't previously able to SSH into it, how _did_ you ever put stuff on it? > but still, it does not help with running over the file quota, and she > does not have git installed. Yeah. And it won't be able to export it to the world in any sensible fashion either. Seriously, just put it elsewhere. You do nobody any favours by making them try to get it from a server which doesn't have git:// running. -- dwmw2 From davej at redhat.com Wed Feb 7 23:06:02 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 7 Feb 2007 18:06:02 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170885218.3315.26.camel@zelda.fubar.dk> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170868907.2967.2.camel@dawkins> <1170871445.2858.0.camel@zelda.fubar.dk> <1170872788.2967.7.camel@dawkins> <1170877921.3315.6.camel@zelda.fubar.dk> <20070207201821.GA2597@redhat.com> <1170885218.3315.26.camel@zelda.fubar.dk> Message-ID: <20070207230602.GA25754@redhat.com> On Wed, Feb 07, 2007 at 04:53:38PM -0500, David Zeuthen wrote: > On Wed, 2007-02-07 at 15:18 -0500, Dave Jones wrote: > > I'm puzzled why you're not seeing these when you test the code before > > pushing it. Are you running with selinux disabled ? > > Or is it failing only in certain hardware configurations that you don't have? > > Bah, mea culpa. I need to admit I wasn't running SELinux in Enforcing > mode on the laptop I was testing it on. I see the issues in the AVC log > as it's running Permissive mode. Still, some of my complaints still > stand: As a developer, SELinux right now is a thing that gets more in my > way than I like it to. It's probably specific to HAL as it runs with > lots of privileges to do stuff. Maybe so, but as developers, we should never turn it off. How can we expect our users to use selinux if we disable it ourselves ? I don't recall ever waiting more than 24hrs for Dan to look into an issue I've had with SELinux policy, so there really shouldn't be an excuse. We really need some infrastructure in the updates system that applies an update, runs it, and disallows the update being pushed live if AVC's get generated. Dave -- http://www.codemonkey.org.uk From green at redhat.com Wed Feb 7 23:10:42 2007 From: green at redhat.com (Anthony Green) Date: Wed, 07 Feb 2007 15:10:42 -0800 Subject: Creating a jackuser group In-Reply-To: <1170871860.2858.4.camel@zelda.fubar.dk> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <1170856878.3564.92.camel@localhost.localdomain> <1170871860.2858.4.camel@zelda.fubar.dk> Message-ID: <1170889843.3759.14.camel@localhost.localdomain> On Wed, 2007-02-07 at 13:11 -0500, David Zeuthen wrote: > How on earth can this be considered a good user experience? It's a major incremental improvement over the current state of affairs, which is: nothing works unless you manage to find, read, and follow the instructions in /usr/share/doc/jack-audio-connection-kit-0.102.20/README.Fedora > Please don't > bother the user with such questions; fix the base system instead and > please do this without having secret UNIX groups that one has to be part > of. It's just _broken_ using group membership for such things. Thanks. I can't think of a better solution and I don't think that automatically granting permission to console users is a workable suggestion. AG From green at redhat.com Wed Feb 7 23:12:23 2007 From: green at redhat.com (Anthony Green) Date: Wed, 07 Feb 2007 15:12:23 -0800 Subject: Creating a jackuser group In-Reply-To: <45CA24ED.4070702@andrei.myip.org> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> Message-ID: <1170889943.3759.16.camel@localhost.localdomain> On Wed, 2007-02-07 at 11:13 -0800, Florin Andrei wrote: > Best-case scenario, the apps will silently drop RT capabilities. We don't even approach this with Fedora. jackd will refuse to start from qjackctl if you don't have the permissions set up properly. AG From pemboa at gmail.com Wed Feb 7 23:53:40 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 7 Feb 2007 17:53:40 -0600 Subject: Is there a NFS alternative? In-Reply-To: <200702071504.47527.lamont@gurulabs.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <200702071504.47527.lamont@gurulabs.com> Message-ID: <16de708d0702071553p341bbf38nccfd6f36b425c188@mail.gmail.com> On 2/7/07, Lamont Peterson wrote: > On Wednesday 07 February 2007 01:27pm, Daniel Yek wrote: > > Hi, > > > > It was a while ago when I read that NFS was difficult to secure with (the > > use of) ssh and iptables (or something like that). > > > > I really needed an alternative that works and can be made secure. Is GFS a > > suitable replacement for NFS? If not, what is the closest thing to NFS? > > Kerberized NFS, preferably NFS4. > > AndrewFS or CodaFS. > -- > Lamont Peterson > Senior Instructor > Guru Labs, L.C. [ http://www.GuruLabs.com/ ] > It sounds like there are those of you who actually get NFS4 to work. I have tried twice on FC6, and have yet to succeed myself, just gave up and used NFS3. I opened a thread on the general mailing list about it but got no real help. -- Fedora Core 6 and proud From bojan at rexursive.com Wed Feb 7 23:55:09 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 7 Feb 2007 23:55:09 +0000 (UTC) Subject: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702072223.l17MNWDU005540@laptop13.inf.utfsm.cl> <1170888079.29759.1194.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > I see no reason why Exim shouldn't cope perfectly well with that. Any comment regarding the SUID stuff? -- Bojan From dyek at real.com Thu Feb 8 00:02:21 2007 From: dyek at real.com (Daniel Yek) Date: Wed, 07 Feb 2007 16:02:21 -0800 Subject: Is there a NFS alternative? In-Reply-To: <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.co m> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> Message-ID: <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> At 12:52 PM 2/7/2007, Arthur Pemberton wrote: >> >>It was a while ago when I read that NFS was difficult to secure with (the >> >>use of) ssh and iptables (or something like that). >> >> >> >>I really needed an alternative that works and can be made secure. >> >> If not, what is the closest thing to NFS? >> >> >Subdue NFS to use only one port, firewall all other ports >> >off....possible filter the NFS port too? >> >>That is what I read and I was looking for an alternative to that. Is there >>other solution? Or this is the best available solution already? > >Well, if you can suggest how the solution could be made better, I or >others can maybe suggest how to implement it. >The only other thing i can think of is have port mapper interface with >iptables in a plug and play type firewall way (or however Windows >refers to it) At 01:52 PM 2/7/2007, Olivier Galibert wrote: >What is your threat model? What do you want to be secured against? > > OG. At 02:04 PM 2/7/2007, Lamont Peterson wrote: >Kerberized NFS, preferably NFS4. > >AndrewFS or CodaFS. Thanks everybody for replying! I am hoping for a secure solution to mount directories "shared out" from my other computer located remotely over the Internet. So that I can edit source files and execute programs "locally" and compile remotely (a much faster machine). Whether I go with subdued NFS or NFS4, I will have to secure the communication channels with ssh tunnels and doing it the ad-hoc way (scripted) is a lot of hassles for daily use with connection that can get cut once in a while (daily, for example.) Without a secure solution, I would just use scp (and possibly develop other solutions to sync files.) With Fedora Core's iptables policies and selinux, I feel secure leaving computers exposed to the Internet, knowing that I won't ending up suspecting a breach and spending a lot of time dealing with it. It would be regrettable to use a network service (likes NFS without ssh tunnels) that makes me feel uncertain and insecure. The peace of mind is invaluable. I have at most read about AFS (and used it as an end user in an administered environment) and CodaFS, but don't know if encryption of network communication is built in or integrated. I suspect not. (Haven't done the research yet...) Is NFS(4) still the best (and easiest-to-use?) solution? Thanks. -- Daniel Yek From dwmw2 at infradead.org Thu Feb 8 00:02:55 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Feb 2007 00:02:55 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702072223.l17MNWDU005540@laptop13.inf.utfsm.cl> <1170888079.29759.1194.camel@pmac.infradead.org> Message-ID: <1170892975.29759.1224.camel@pmac.infradead.org> On Wed, 2007-02-07 at 23:55 +0000, Bojan Smojver wrote: > Any comment regarding the SUID stuff? Oh, sorry -- I missed that. Yes, of course we ship with it suid root. It normally drops privileges almost immediately, but for local deliveries it needs to keep them. If you were running it in a mode where it doesn't do any local delivery but just ships everything off to a smarthost, you wouldn't need it setuid. -- dwmw2 From dwmw2 at infradead.org Thu Feb 8 00:11:58 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Feb 2007 00:11:58 +0000 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> Message-ID: <1170893518.29759.1230.camel@pmac.infradead.org> On Wed, 2007-02-07 at 16:02 -0800, Daniel Yek wrote: > I am hoping for a secure solution to mount directories "shared out" from my > other computer located remotely over the Internet. So that I can edit > source files and execute programs "locally" and compile remotely (a much > faster machine). Editing of source files works quite nicely over ssh given a capable editor. $ emacs /dwmw2 at pentafluge.infradead.org:/home/dwmw2/public_html/foo.html & And obviously SSH is clever enough that that kind of trick even works for hosts within private networks, because you can play tricks with ProxyCommand to make 'ssh somehost.company.internal' entirely transparent. Mostly I just use the above trick with emacs, and rsync -- which again works over SSH so it's easy to get to/from company-internal machines. -- dwmw2 From k.georgiou at imperial.ac.uk Thu Feb 8 00:15:08 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Thu, 8 Feb 2007 00:15:08 +0000 Subject: Is there a NFS alternative? In-Reply-To: <16de708d0702071553p341bbf38nccfd6f36b425c188@mail.gmail.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <200702071504.47527.lamont@gurulabs.com> <16de708d0702071553p341bbf38nccfd6f36b425c188@mail.gmail.com> Message-ID: <20070208001508.GA5810@imperial.ac.uk> On Wed, Feb 07, 2007 at 05:53:40PM -0600, Arthur Pemberton wrote: > On 2/7/07, Lamont Peterson wrote: > >On Wednesday 07 February 2007 01:27pm, Daniel Yek wrote: > >> Hi, > >> > >> It was a while ago when I read that NFS was difficult to secure with (the > >> use of) ssh and iptables (or something like that). > >> > >> I really needed an alternative that works and can be made secure. Is GFS > >a > >> suitable replacement for NFS? If not, what is the closest thing to NFS? > > > >Kerberized NFS, preferably NFS4. > > > It sounds like there are those of you who actually get NFS4 to work. I > have tried twice on FC6, and have yet to succeed myself, just gave up > and used NFS3. I opened a thread on the general mailing list about it > but got no real help. I am running NFS4 with kerberos since FC5 (maybe even earlier) with only minor problems here and there. There is a problem with krb5 since 2.6.18 that prevents multiple mounts (bugzilla #218330) in FC5/6 so you might have some problems. From bojan at rexursive.com Thu Feb 8 01:55:39 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 8 Feb 2007 01:55:39 +0000 (UTC) Subject: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702072223.l17MNWDU005540@laptop13.inf.utfsm.cl> <1170888079.29759.1194.camel@pmac.infradead.org> <1170892975.29759.1224.camel@pmac.infradead.org> Message-ID: David Woodhouse infradead.org> writes: > Oh, sorry -- I missed that. Yes, of course we ship with it suid root. It > normally drops privileges almost immediately, but for local deliveries > it needs to keep them. OK, thanks for that explanation. I see there is a lot of MTA discussion out there on the net, especially about security architectures of various different MTAs, but it all appears to boil down to "local delivery == root at some point". Whether non-monolithic architecture of Postfix is better overall in terms of security appears to be a very contentious issue, but it doesn't seem to impact local delivery (i.e. this is still root at many points). -- Bojan From kevin.kofler at chello.at Thu Feb 8 05:13:37 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 8 Feb 2007 05:13:37 +0000 (UTC) Subject: Is there a NFS alternative? References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> Message-ID: Daniel Yek real.com> writes: > It was a while ago when I read that NFS was difficult to secure with (the > use of) ssh and iptables (or something like that). > > I really needed an alternative that works and can be made secure. Is GFS a > suitable replacement for NFS? If not, what is the closest thing to NFS? Is fuse-sshfs a viable alternative? Others have also mentioned fully-userspace solutions, i.e. giving your apps URLs instead of file names. Emacs has been given as an example, but it's not the only editor to support this. Most KDE and GNOME apps support sftp:// URLs (sftp ioslave in KDE, sftp gnome-vfs plugin in GNOME). Kate can work just fine with sftp:// URLs, for example. Kevin Kofler From tmus at tmus.dk Thu Feb 8 06:04:42 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Feb 2007 07:04:42 +0100 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.co m> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> Message-ID: Daniel Yek wrote: > I am hoping for a secure solution to mount directories "shared out" from > my other computer located remotely over the Internet. So that I can edit > source files and execute programs "locally" and compile remotely (a much > faster machine). I'm probably misunderstanding this, but here we go anyway. :-) Sharing a directory will not let you build remotely. It will allow you to build in a place where another host can get the results. You need to have some sort of shell on the system that will be building. If you actually get to the fast computer over the internet (ssh or something) and build something off an NFS mount from your local machine, then there's a good chance that the latency in reading and writing files on the NFS share will far outweigh the faster processor on the remote machine, in which case you'll be better off building from your local machine, even if it is slower. (disclaimer: i don't know what kind of connection you have to the internet). I'd say edit the files locally, then rsync files over and built remotely (all this could easily be put in you Makefile btw) and sync results back. Again - sorry if i'm not getting the picture. ;-) /Thomas From tmus at tmus.dk Thu Feb 8 06:13:55 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Feb 2007 07:13:55 +0100 Subject: announce: v2.6.20-rt1 yum repository and kernel rpms In-Reply-To: <20070206113651.GA5369@elte.hu> References: <20070205093443.GA30675@elte.hu> <20070206113651.GA5369@elte.hu> Message-ID: Ingo Molnar wrote: > yeah, it should be a drop-in replacement, so what you see is a bug > either in the -rt kernel or in the upstream kernel. I'm wondering, does > rawhide kernel rpm work? It's currently at 2.6.20-1.2922.fc7 which ought > to be roughly the same vanilla base as -rt has. So if that kernel works > for you then this is a regression in the -rt kernel. > > Ingo > The .fc7 kernel works fine for me! Should a bug for this be filed somewhere, so that it can be tracked? /Thomas From dyek at real.com Thu Feb 8 06:55:05 2007 From: dyek at real.com (Daniel Yek) Date: Wed, 07 Feb 2007 22:55:05 -0800 Subject: Is there a NFS alternative? In-Reply-To: References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> Message-ID: <6.2.1.2.2.20070207220542.26a04300@mailone.real.com> At 09:13 PM 2/7/2007, Kevin Kofler wrote: > > It was a while ago when I read that NFS was difficult to secure with (the > > use of) ssh and iptables (or something like that). > > > > I really needed an alternative that works and can be made secure. Is GFS a > > suitable replacement for NFS? If not, what is the closest thing to NFS? > >Is fuse-sshfs a viable alternative? This is exciting. I briefly scan through several web sites, didn't find any information about the perceived delay and fine-grained control of when it syncs (ssh / scp out), etc. If the perceived delay on save is minimum -- as fast as saving to the local disk, this would be a perfect solution that I am looking for. I just need it to cache locally (which fuse-sshfs does) and flush/sync when I want it to, or asynchronously in the background so that it doesn't bother me with synchronous "delayed return". I can imagine it being very useful, but I'll have to give myself time to use it for a while. Thanks a bunch. http://marc.abramowitz.info/archives/2006/02/21/fusesshfs/ Install: yum install fuse-sshfs Or: apt-get install sshfs adduser yourlocalusername fuse (log out and back in so that it recognizes me as a member of the group "fuse") How to mount a filesystem: > sshfs hostname: mountpoint To unmount the filesystem: > fusermount -u mountpoint -- Daniel Yek >Others have also mentioned fully-userspace solutions, i.e. giving your apps >URLs instead of file names. Emacs has been given as an example, but it's not >the only editor to support this. Most KDE and GNOME apps support sftp:// URLs >(sftp ioslave in KDE, sftp gnome-vfs plugin in GNOME). Kate can work just >fine >with sftp:// URLs, for example. > > Kevin Kofler From dyek at real.com Thu Feb 8 07:04:57 2007 From: dyek at real.com (Daniel Yek) Date: Wed, 07 Feb 2007 23:04:57 -0800 Subject: Is there a NFS alternative? In-Reply-To: References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.co m> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> Message-ID: <6.2.1.2.2.20070207225936.26d11b50@mailone.real.com> At 10:04 PM 2/7/2007, Thomas M Steenholdt wrote: >I'm probably misunderstanding this, but here we go anyway. :-) > >Sharing a directory will not let you build remotely. It will allow you to >build in a place where another host can get the results. You need to have >some sort of shell on the system that will be building. > >If you actually get to the fast computer over the internet (ssh or >something) and build something off an NFS mount from your local machine, >then there's a good chance that the latency in reading and writing files >on the NFS share will far outweigh the faster processor on the remote >machine, in which case you'll be better off building from your local >machine, even if it is slower. (disclaimer: i don't know what kind of >connection you have to the internet). > >I'd say edit the files locally, then rsync files over and built remotely >(all this could easily be put in you Makefile btw) and sync results back. > >Again - sorry if i'm not getting the picture. ;-) > >/Thomas I have remote access to that "my other machine", so I have ssh access to kick off build scripts. One other advantage of mounting the directory remotely is that the source files are then saved in that computer and the overhead of syncing the work two times a day is zero. Thanks. -- Daniel Yek From seg at haxxed.com Thu Feb 8 07:48:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 08 Feb 2007 01:48:16 -0600 Subject: Creating a jackuser group In-Reply-To: <1170876965.3444.7.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> <1170876965.3444.7.camel@localhost.localdomain> Message-ID: <1170920896.13307.38.camel@localhost.localdomain> On Wed, 2007-02-07 at 14:36 -0500, Matthias Clasen wrote: > If realtime is a requirement for acceptable audio experience, then > everybody needs to get it without extra questions asked. If it is not, > then why bother ? The point being missed here is there are security implications. A malicious user with RT privs can easily lock the machine up hard, at will. Because RT is basically cooperative multitasking, the RT process runs uninterrupted until it gives up its slice, and if it doesn't... total system lockup. So handing out RT privs has to be done very carefully. -------------- 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 arjan at fenrus.demon.nl Thu Feb 8 07:49:59 2007 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 08 Feb 2007 08:49:59 +0100 Subject: rawhide report: 20070207 changes In-Reply-To: <1170880209.3315.22.camel@zelda.fubar.dk> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> <200702071524.08122.jkeating@redhat.com> <1170880209.3315.22.camel@zelda.fubar.dk> Message-ID: <1170920999.8675.29.camel@laptopd505.fenrus.org> > make hal > pull in libsmbios once Matt, his colleagues or others have packaged it > up [1] for Fedora (hint hint nudge nudge) - the latter means that Dell > laptops can have their backlight controlled via g-p-m etc.) .... which is ENTIRELY the wrong way I suspect. The kernel provides a unified backlight API now, adding more private hacks rather than moving them to the unified API sounds like a step backwards to me .. From hughsient at gmail.com Thu Feb 8 08:44:23 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 08 Feb 2007 08:44:23 +0000 Subject: rawhide report: 20070207 changes In-Reply-To: <1170920999.8675.29.camel@laptopd505.fenrus.org> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> <200702071524.08122.jkeating@redhat.com> <1170880209.3315.22.camel@zelda.fubar.dk> <1170920999.8675.29.camel@laptopd505.fenrus.org> Message-ID: <1170924263.4059.1.camel@hughsie-laptop> On Thu, 2007-02-08 at 08:49 +0100, Arjan van de Ven wrote: > > .... which is ENTIRELY the wrong way I suspect. > The kernel provides a unified backlight API now, adding more private > hacks rather than moving them to the unified API sounds like a step > backwards to me .. I don't think smbios can be moved into the backlight kernel class as the libsmbios library is written in C++ (IIRC) and is pretty huge. Richard. From dwmw2 at infradead.org Thu Feb 8 09:22:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Feb 2007 09:22:46 +0000 Subject: rawhide report: 20070207 changes In-Reply-To: <1170924263.4059.1.camel@hughsie-laptop> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> <200702071524.08122.jkeating@redhat.com> <1170880209.3315.22.camel@zelda.fubar.dk> <1170920999.8675.29.camel@laptopd505.fenrus.org> <1170924263.4059.1.camel@hughsie-laptop> Message-ID: <1170926566.29759.1260.camel@pmac.infradead.org> On Thu, 2007-02-08 at 08:44 +0000, Richard Hughes wrote: > I don't think smbios can be moved into the backlight kernel class as > the libsmbios library is written in C++ (IIRC) and is pretty huge. Then the kindest thing to do is take it out back and shoot it humanely, then do it again with taste. -- dwmw2 From jonesc at hep.phy.cam.ac.uk Thu Feb 8 09:31:51 2007 From: jonesc at hep.phy.cam.ac.uk (Chris Jones) Date: Thu, 08 Feb 2007 09:31:51 +0000 Subject: Is there a NFS alternative? In-Reply-To: References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.co m> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> Message-ID: <45CAEE07.7040406@hep.phy.cam.ac.uk> > > If you actually get to the fast computer over the internet (ssh or > something) and build something off an NFS mount from your local machine, > then there's a good chance that the latency in reading and writing files > on the NFS share will far outweigh the faster processor on the remote > machine, in which case you'll be better off building from your local > machine, even if it is slower. (disclaimer: i don't know what kind of > connection you have to the internet). AFS is quite good in this regard, in that it transparently maintains a file cache on the local machine. If files don't change, they aren't re-read from the main server. Changes are sync'ed back transparently as well. I have used this very effectively in a work environment. Chris From benny+usenet at amorsen.dk Thu Feb 8 10:32:46 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 08 Feb 2007 11:32:46 +0100 Subject: Default MTA for Fedora 7 References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> <1170858188.21302.8.camel@gibraltar.stuttgart.redhat.com> Message-ID: >>>>> "NP" == Nils Philippsen writes: NP> This would put me in the "just not about everyone" group as I use NP> postfix and UUCP. It was really easy to setup, but I might have to NP> try out something different for more effective anti-spam stuff. Notice that Exim CAN do UUCP, just not UUCP bang paths. That is, the old foo!bar!baz stuff. /Benny From dwmw2 at infradead.org Thu Feb 8 10:37:35 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Feb 2007 10:37:35 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> <1170858188.21302.8.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1170931055.29759.1276.camel@pmac.infradead.org> On Thu, 2007-02-08 at 11:32 +0100, Benny Amorsen wrote: > Notice that Exim CAN do UUCP, just not UUCP bang paths. That is, the > old foo!bar!baz stuff. Actually, we can almost certainly handle that with a cunning bit of rewriting. You rewrite 'foo!bar!baz' to 'bar!baz at foo' on the input, then process it as UUCP to host foo and make sure it's presented correctly on the way out. -- dwmw2 From tmus at tmus.dk Thu Feb 8 10:56:11 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Feb 2007 11:56:11 +0100 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207225936.26d11b50@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.co m> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> <6.2.1.2.2.20070207225936.26d11b50@mailone.real.com> Message-ID: Daniel Yek wrote: > One other advantage of mounting the directory remotely is that the > source files are then saved in that computer and the overhead of syncing > the work two times a day is zero. > But all reads and writes will take place over the internet, which is a major overhead in itself. /Thomas From buildsys at redhat.com Thu Feb 8 11:10:57 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 8 Feb 2007 06:10:57 -0500 Subject: rawhide report: 20070208 changes Message-ID: <200702081110.l18BAvqB021127@hs20-bc2-6.build.redhat.com> Updated Packages: acpid-1.0.4-6.fc7 ----------------- * Wed Feb 07 2007 Phil Knirsch - 1.0.4-6.fc7 - Tons of specfile changes due to review (#225237) aspell-sr-50:0.02-2.fc7 ----------------------- * Wed Feb 07 2007 Ivana Varekova -50:0.02-2 - incorporate the first part of package review - spec file cleanup bash-3.2-8.fc7 -------------- * Wed Feb 07 2007 Tim Waugh 3.2-8 - Avoid %makeinstall (bug #225609). bind-31:9.3.4-5.fc7 ------------------- * Wed Feb 07 2007 Adam Tkac 31:9.3.4-5.fc7 - bind-chroot-admin now uses correct chroot path (#227600) checkpolicy-2.0.0-1.fc7 ----------------------- * Tue Nov 14 2006 Dan Walsh - 2.0.0-1 - Latest update from NSA * Merged patch to use new libsepol error codes by Karl MacMillan. * Updated version for stable branch. comps-extras-11.2-3 ------------------- * Wed Feb 07 2007 Jeremy Katz - 11.2-3 - and a few more control-center-1:2.17.90-6.fc7 ------------------------------ * Wed Feb 07 2007 Matthias Clasen - 2.17.90-6 - Make gstreamer pulse plugin show up in the sound capplet cpio-2.6-24.fc7 --------------- * Mon Jan 22 2007 Peter Vrabec 2.6-24 - fix spec file to meet Fedora standards (#225656) eclipse-1:3.2.1-37.fc7 ---------------------- * Wed Feb 07 2007 Ben Konrath 3.2.1-37 - Move rcp feature to %{_libdir} to avoid multilib conflict on ppc{,64}. expect-5.43.0-7 --------------- * Thu Feb 08 2007 Miloslav Trmac - 5.43.0-7 - s/%{buildroot}/"$RPM_BUILD_ROOT"/g - s,/usr/share/man,%{_mandir},g - Use the Fedora-specified Buildroot: - Remove BuildRequires: libX11-devel - Don't install pkgIndex.tcl as an executable file - Drop the incorrect expect-5.32.2-fixcat.patch - Remove comments from *.h.in because they confuse config.status; this makes the workaround expect-5.43.0-cfg-setpgrp.patch unnecesary. frysk-0.0.1.2007.02.07.rh1-1.fc7 -------------------------------- * Tue Feb 06 2007 Stepan Kasal - 0.0.1.2007.02.07.rh1-1 - New upstream version. - Add Gnome help files, test_looper.xml, and test_main_looper to the file lists. - Temporarily: switch off /usr/share/frysk/test, current tarball does not install it; switch off ppc64 build, frysk-imports/include/frysk-asm.h ain't ready. * Tue Feb 06 2007 Stepan Kasal - 0.0.1.2006.12.22.rh1-8 - Do not delete the .desktop file, nove it to docdir. - Related: #211200 * Tue Jan 30 2007 Stepan Kasal - 0.0.1.2006.12.22.rh1-7 - Move the requirement for libgconf-java to subpackage frysk-gnome. - Resolves: #225401. ftp-0.17-38.fc7 --------------- * Wed Feb 07 2007 Marcela Maslanova - 0.17-38 - add gpl - spec fix - rhbz#225774 * Tue Jan 30 2007 Marcela Maslanova - 0.17-35 - nodebug package * Wed Sep 13 2006 Marcela Maslanova - 0.17-33 - rebuilt ghostscript-fonts-5.50-16.fc7 ----------------------------- * Wed Feb 07 2007 Tim Waugh 5.50-16 - Fixed URL again (bug #225794). - Fixed requires tags (bug #225794). - Preserve timestamps on installed files (bug #225794). - Added empty %build section (bug #225794). - Use FHS macros for file manifest (bug #225794). - Fixed summary (bug #225794). - Fixed description (bug #225794). - Fixed license (bug #225794). gnome-media-2.17.90-2.fc7 ------------------------- * Wed Feb 07 2007 Matthias Clasen - 2.17.90-2 - Add X-GNOME-PersonalSettings to gnome-volume-control.desktop gnome-panel-2.17.91-1.svn20070207.fc7 ------------------------------------- gnome-volume-manager-2.17.0-3.fc7 --------------------------------- * Wed Feb 07 2007 Matthias Clasen - 2.17.0-3 - Use desktop-file-install - Add HardwareSettings category to gnome-volume-properties.desktop (fixed in upstream svn) * Tue Nov 14 2006 David Zeuthen - 2.17.0-2.fc7 - Refuse to automount when screensaver is running (#215057) * Tue Nov 07 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 gnutls-1.4.5-1 -------------- * Wed Feb 07 2007 Tomas Mraz 1.4.5-1 - new upstream version - drop libtermcap-devel from buildrequires joe-3.5-2.fc7 ------------- * Wed Feb 07 2007 Ivana Varekova 3.5-2 - fix 227487 - joe wakes up spuriously once per ... patch by Arjan van de Ven - spec file cleanup kdeaccessibility-1:3.5.6-1.fc7 ------------------------------ * Wed Feb 07 2007 Than Ngo 1:3.5.6-1.fc7 - 3.5.6 * Thu Aug 10 2006 Than Ngo 1:3.5.4-1 - rebuild * Mon Jul 24 2006 Than Ngo 1:3.5.4-0.pre1 - prerelease of 3.5.4 (from the first-cut tag) kdeaddons-3.5.6-1.fc7 --------------------- * Wed Feb 07 2007 Than Ngo 3.5.6-1.fc7 - 3.5.6 * Thu Aug 10 2006 Than Ngo 3.5.4-1 - rebuild * Mon Jul 24 2006 Than Ngo 3.5.4-0.pre1 - prerelease of 3.5.4 (from the first-cut tag) kdeadmin-7:3.5.6-1.fc7 ---------------------- * Wed Feb 07 2007 Than Ngo 7:3.5.6-1.fc7 - 3.5.6 * Fri Aug 18 2006 Than Ngo 7:3.5.4-2 - add FC6 support in knetworkconf * Thu Aug 10 2006 Than Ngo 7:3.5.4-1 - rebuild kdeartwork-3.5.6-1.fc7 ---------------------- * Wed Feb 07 2007 han Ngo 3.5.6-1.fc7 - 3.5.6 * Thu Aug 10 2006 Than Ngo 3.5.4-1 - rebuild * Mon Jul 24 2006 Than Ngo 3.5.4-0.pre1 - prerelease of 3.5.4 (from the first-cut tag) kdebindings-3.5.6-1.fc7 ----------------------- * Thu Feb 08 2007 Than Ngo - 3.5.6-1.fc7 - 3.5.6 kdeedu-3.5.6-1.fc7 ------------------ * Wed Feb 07 2007 Than Ngo 3.5.6-1.fc7 - 3.5.6 kdegames-6:3.5.6-1.fc7 ---------------------- * Wed Feb 07 2007 Than Ngo 6:3.5.6-1.fc7 - 3.5.6 * Thu Aug 10 2006 Than Ngo 6:3.5.4-1 - rebuild * Mon Jul 24 2006 Than Ngo 6:3.5.4-0.pre1 - prerelease of 3.5.4 (from the first-cut tag) kdegraphics-7:3.5.6-1.fc7 ------------------------- * Wed Feb 07 2007 Than Ngo 7:3.5.6-1.fc7 - 3.5.6 kdemultimedia-6:3.5.6-1.fc7 --------------------------- * Wed Feb 07 2007 Than Ngo 6:3.5.4-1.fc7 - 3.5.6 * Wed Sep 06 2006 Than Ngo 6:3.5.4-2 - fix file conflict #202944 * Thu Aug 10 2006 Than Ngo 6:3.5.4-1 - rebuild kdenetwork-7:3.5.6-1.fc7 ------------------------ * Thu Feb 08 2007 Than Ngo 7:3.5.6-1.fc7 - 3.5.6 * Tue Sep 19 2006 Than Ngo 7:3.5.4-5 - apply upstream patches fix #133995, emoticon parsing if there are sub-emoticons * Wed Sep 06 2006 Than Ngo 7:3.5.4-4 - fix dependency problem kdesdk-3.5.6-1.fc7 ------------------ * Thu Feb 08 2007 Than Ngo 3.5.6-1.fc7 - 3.5.6 * Tue Sep 05 2006 Than Ngo 3.5.4-2 - fix #205217, multilib issue - apply upstream patches fix #131717, kompare won't parse diffs from git * Thu Aug 10 2006 Than Ngo 3.5.4-1 - rebuild kdeutils-6:3.5.6-1.fc7 ---------------------- * Thu Feb 08 2007 Than Ngo 6:3.5.6-1.fc7 - 3.5.6 kdevelop-9:3.3.6-1.fc7 ---------------------- * Thu Feb 08 2007 Than Ngo 9:3.3.6-1.fc7 - 3.3.6 * Thu Aug 10 2006 Than Ngo 9:3.3.4-1 - rebuild * Mon Jul 24 2006 Than Ngo 9:3.3.4-0.pre1 - prerelease of 3.3.4 (from the first-cut tag) less-394-7.fc7 -------------- * Wed Feb 07 2007 Ivana Varekova - 394-7 - incorporate the package review * Wed Nov 22 2006 Ivana Varekova - 394-6 - fix permissions of debuginfo source code * Wed Oct 25 2006 Ivana Varekova - 394-5 - fix command ">" (#120916) libgdiplus-1.2.3-1.fc7 ---------------------- * Thu Feb 08 2007 Alexander Larsson - 1.2.3-1 - Update to 1.2.3 libselinux-2.0.0-1.fc7 ---------------------- * Wed Feb 07 2007 Dan Walsh - 2.0.0-1 * Merged patch from Todd Miller to remove sscanf in matchpathcon.c because of the use of the non-standard format %as. (original patch changed for style). * Merged patch from Todd Miller to fix memory leak in matchpathcon.c. libsemanage-1.10.1-1.fc7 ------------------------ * Wed Feb 07 2007 Dan Walsh - 1.10.1-1 - Upgrade to latest from NSA * Merged python binding fix from Dan Walsh. * Updated version for stable branch. libsepol-2.0.1-1.fc7 -------------------- * Wed Feb 07 2007 Dan Walsh 2.0.1-1 - Upgrade to latest from NSA * Merged libsepol segfault fix from Stephen Smalley for when sensitivities are required but not present in the base. * Merged patch to add errcodes.h to libsepol by Karl MacMillan. mc-1:4.6.1a-41.20070122cvs.fc7 ------------------------------ * Tue Feb 06 2007 Jindrich Novy 4.6.1a-41 - merge review spec fixes (#226133) mt-st-0.9b-3.fc7 ---------------- * Wed Feb 07 2007 Jindrich Novy - 0.9b-3 - spec fixes - use mtio.h from kernel-headers instead of the mt-st one mtx-1.3.10-1.fc7 ---------------- * Tue Feb 06 2007 Jindrich Novy 1.3.10-1 - update to mtx-1.3.10 - update URL, Source0 - don't strip debuginfo mutt-5:1.5.13-1.20070126cvs.fc7 ------------------------------- * Wed Feb 07 2007 Miroslav Lichvar 5:1.5.13-1.20070126cvs - update to 1.5.13, and latest CVS (#168183, #220816) - spec cleanup nautilus-2.17.90-4.fc7 ---------------------- * Wed Feb 07 2007 Matthias Clasen - 2.17.90-4 - Add DesktopSettings category to nautilus-file-management-properties.desktop * Tue Feb 06 2007 Alexander Larsson - 2.17.90-3 - update tracker dynamic search patch to new .so name * Tue Jan 23 2007 Alexander Larsson - 2.17.90-2 - Fix gnome bug #362302 in selinux patch ncpfs-2.2.6-7 ------------- * Thu Feb 08 2007 Miloslav Trmac - 2.2.6-7 - Add URL: - Fix BuildRoot: - Split development files to ncpfs-devel - Only modify the ldconfig invocation in the Makefile instead of commenting it out and running ldconfig in %install - Don't exclude ipx header files, the other header files refer to them openhpi-2.8.0-2.fc7 ------------------- * Wed Feb 07 2007 Phil Knirsch - 2.8.0-2.fc7 - Bump and rebuild. postgresql-8.2.3-1.fc7 ---------------------- * Wed Feb 07 2007 Tom Lane 8.2.3-1 - Update to PostgreSQL 8.2.3 due to regression induced by security fix Resolves: #227522 pykickstart-0.94-1.fc7 ---------------------- * Wed Feb 07 2007 Chris Lumens - 0.94-1 - Add a newline to the end of the key command output. - Use network bootproto constants (#197694). - Fix tracebacks in subclass __str__ methods (#226734). setroubleshoot-1.8.17-1.fc7 --------------------------- * Wed Feb 07 2007 Dan Walsh - 1.8.17-1 - Remove tempfile handling in util.py. Causes lots of avc's and is not used * Fri Feb 02 2007 John Dennis - 1.8.16-1 [John Dennis ] - Resolves: Bug# 224343 sealert's "Aditional Info:" text should be in white box - Resolves: Bug# 224336 sealert should have GtkRadioButtons in menu View - Related: bug #224351 Rewrite parts of logging support to better support changing output categories, output destinations. Now -v -V verbose works in sealert. - Resolves bug# 225161, granted AVC's incorrectly identified as a denial - add alert count to status bar - add "Help" command to Help menu, opens web browser on wiki User FAQ [Dan Walsh ] - Make setroubleshoot.logrotate correctly setserial-2.17-20.fc7 --------------------- * Wed Feb 07 2007 Tim Waugh 2.17-20 - Fixed mandir in fhs patch (bug #226411). - Don't run strip (bug #226411). - Fixed readme patch to talk about Fedora not Red Hat Linux (bug #226411). - Fixed build root tag (bug #226411). - Use SMP make flags (bug #226411). - Avoid %makeinstall (bug #226411). - Fixed summary (bug #226411). spamassassin-3.1.7-8.fc7 ------------------------ * Wed Feb 07 2007 Warren Togami 3.1.7-8 - only restart spamd if necessary after sa-update (#227756) * Wed Feb 07 2007 Warren Togami 3.1.7-7 - requires gnupg (#227738) symlinks-1.2-28.fc7 ------------------- * Wed Feb 07 2007 Tim Waugh 1.2-28 - Fixed build root (bug #226445). sysklogd-1.4.1-46.fc7 --------------------- * Wed Feb 07 2007 Peter Vrabec 1.4.1-46 - do not stop running syslog-ng during sysklogd uninstall (#182605) system-config-kickstart-2.7.2-1.fc7 ----------------------------------- * Wed Feb 07 2007 Chris Lumens 2.7.2-1 - Add package-level selection and removal (#222592). - Add UI for the key command (#226718). - Fix iter handling on the partition screen for auto partitions (#225087). system-config-printer-0.7.50-1.fc7 ---------------------------------- * Wed Feb 07 2007 Tim Waugh 0.7.50-1 - 0.7.50: - Fixed hex digits list (bug #223770). - Added bs translation. - Don't put the ellipsis in the real device URI (bug #227643). - Don't check for existing drivers for complex command lines (bug #225104). - Allow floating point job options (bug #224651). - Prevent shared/published confusion (bug #225081). - Fixed PPD page size setting. - Avoid os.remove exception (bug #226703). - Handle unknown job options (bug #225538). tree-1.5.0-7.fc7 ---------------- * Wed Feb 07 2007 Tim Waugh 1.5.0-7 - Current version no longer ships binary, so don't try removing it (bug #226503). unix2dos-2.2-28.fc7 ------------------- * Wed Feb 07 2007 Tim Waugh 2.2-28 - Fixed license tag (bug #226514). vixie-cron-4:4.1-74.fc7 ----------------------- * Wed Feb 07 2007 Marcela Maslanova - 4:4.1-74 - rhbz#223894 xterm-223-3.fc7 --------------- * Wed Feb 07 2007 Miroslav Lichvar 223-3 - spec cleanup (#226660) Broken deps for s390 ---------------------------------------------------------- openhpi - 2.8.0-2.fc7.s390 requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.s390 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.s390 requires libtcl8.4.so redhat-lsb - 3.1-12.2.s390 requires /bin/cpio systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc64 requires libtcl8.4.so()(64bit) openhpi - 2.8.0-2.fc7.ppc64 requires libopenhpi.so.2()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) redhat-lsb - 3.1-12.2.ppc64 requires /bin/cpio Broken deps for ia64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ia64 requires libtk8.4.so()(64bit) redhat-lsb - 3.1-12.2.ia64 requires /bin/cpio Broken deps for x86_64 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.x86_64 requires libtcl8.4.so()(64bit) openhpi - 2.8.0-2.fc7.x86_64 requires libopenhpi.so.2()(64bit) openhpi - 2.8.0-2.fc7.i386 requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) redhat-lsb - 3.1-12.2.x86_64 requires /bin/cpio Broken deps for s390x ---------------------------------------------------------- openhpi - 2.8.0-2.fc7.s390 requires libopenhpi.so.2 openhpi - 2.8.0-2.fc7.s390x requires libopenhpi.so.2()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.s390x requires libtk8.4.so()(64bit) redhat-lsb - 3.1-12.2.s390x requires /bin/cpio Broken deps for i386 ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.i386 requires libtcl8.4.so openhpi - 2.8.0-2.fc7.i386 requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so redhat-lsb - 3.1-12.2.i386 requires /bin/cpio Broken deps for ppc ---------------------------------------------------------- isdn4k-utils-vboxgetty - 3.2-53.fc7.ppc requires libtcl8.4.so openhpi - 2.8.0-2.fc7.ppc requires libopenhpi.so.2 pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so redhat-lsb - 3.1-12.2.ppc requires /bin/cpio From k.georgiou at imperial.ac.uk Thu Feb 8 11:22:23 2007 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Thu, 8 Feb 2007 11:22:23 +0000 Subject: Is there a NFS alternative? In-Reply-To: References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> <6.2.1.2.2.20070207225936.26d11b50@mailone.real.com> Message-ID: <20070208112223.GA11506@imperial.ac.uk> On Thu, Feb 08, 2007 at 11:56:11AM +0100, Thomas M Steenholdt wrote: > Daniel Yek wrote: > >One other advantage of mounting the directory remotely is that the > >source files are then saved in that computer and the overhead of syncing > >the work two times a day is zero. > > > But all reads and writes will take place over the internet, which is a > major overhead in itself. The cachefilesd daemon might help there, I never tried it though so it might not even work with nfs+krb5. Kostas Georgiou From drago01 at gmail.com Thu Feb 8 12:20:53 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 08 Feb 2007 13:20:53 +0100 Subject: qemu 0.9.0 in -devel In-Reply-To: References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> <45C9A81C.8050206@gmail.com> Message-ID: <45CB15A5.1090807@gmail.com> Ed Swierk wrote: > On 2/7/07, dragoran wrote: >> add -std-vga to the qemu command line and it works. > > Weird--that doesn't make any difference when I try it. SYSLINUX still > hangs during "Loading initrd.img" after printing 90 or so dots. > > Which image are you booting? I tested with the x86_64 rescue image with this commad: qemu-system-x86_64 -cdrom imagename.iso -hd hd.img -m 960 -localtime -bootd -kernel-kqemu -std-vga (replace qemu-system-x86_64 with qemu on i386) > --Ed > From mcepl at redhat.com Thu Feb 8 13:58:54 2007 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 8 Feb 2007 13:58:54 +0000 (UTC) Subject: Default MTA for Fedora 7 References: <1170674703.29759.758.camel@pmac.infradead.org> <1170802073.29759.1008.camel@pmac.infradead.org> <1170830538.3837.15.camel@pensja.lam.pl> <200702070846.03555.jkeating@redhat.com> Message-ID: Jesse Keating scripst: > I think it will be sendmail. Path of least surprise. Much harder to make any > sort of change like that in RHEL :/ I would say that substantial part of all sendmails on Linux are running RHEL anyways (or other way around, that substantial part of RHELs are used for running sendmail). However, this thread began (long time ago :-)) thinking about Fedora *Desktop* spin. I would say that really desktop users should be getting something more palatable than sendmail. The problem of the situation and the reason why this whole discussion seems to me to be pointless is that there is really not good *well-tested and mature* MTA, which would just deliver to smarthost *and* locally, so we have to choose between different not-perfect huge MTAs scaled down to the personal size. The MTA which I would love was masqmail (http://dag.wieers.com/rpm/packages/masqmail/), but that was abandoned even by its author (and probably the only developer). Oh well. Matej -- http://www.ceplovi.cz/matej/blog/, Jabber: ceplmajabber.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC The function of the expert is not to be more right than other people, but to be wrong for more sophisticated reasons. -- Dr. David Butler, British psephologist From nphilipp at redhat.com Thu Feb 8 14:35:21 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 08 Feb 2007 15:35:21 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> <1170697150.3254.4.camel@sb-home.lan> <20070205185222.2478a357@banea.int.addix.net> <200702051943.l15Jhxiu007711@laptop13.inf.utfsm.cl> <20070205211852.73857c53@lain.camperquake.de> <20070206030458.GS1488683@hiwaay.net> <20070206141537.GA4293@jadzia.bu.edu> <5256d0b0702061051t3f642bd5g3a6a061a8c5c9795@mail.gmail.com> <1170858188.21302.8.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1170945321.3452.6.camel@gibraltar.stuttgart.redhat.com> On Thu, 2007-02-08 at 11:32 +0100, Benny Amorsen wrote: > >>>>> "NP" == Nils Philippsen writes: > > NP> This would put me in the "just not about everyone" group as I use > NP> postfix and UUCP. It was really easy to setup, but I might have to > NP> try out something different for more effective anti-spam stuff. > > Notice that Exim CAN do UUCP, just not UUCP bang paths. That is, the > old foo!bar!baz stuff. And I'm not masochistic enough to actually want bang paths ;-), I just think that UUCP is a good way to hook up a machine with mail that's not always on and gets dynamic IP addresses. I just wanted to counter the notion a bit that everyone who uses UUCP uses sendmail. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 dennis at ausil.us Thu Feb 8 14:53:41 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 8 Feb 2007 08:53:41 -0600 Subject: qemu 0.9.0 in -devel In-Reply-To: <1170784502.7155.52.camel@hades.cambridge.redhat.com> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> Message-ID: <200702080853.41632.dennis@ausil.us> On Tuesday 06 February 2007 11:55, David Woodhouse wrote: > I've built qemu 0.9.0 into FE-devel. Please poke at it and scream if you > don't want me to put it into FE6. > > I've already closed UPSTREAM the RFE for kqemu, so don't bother hassling > me about it. I would rather roger myself with a chainsaw than muck > around with the abomination that is external kernel modules. I built the devel srpm on FC-6 and it resolved a couple of sparc32 issues i had. So i say push it -- Dennis Gilmore, RHCE From kevin.verma at gmail.com Thu Feb 8 15:21:43 2007 From: kevin.verma at gmail.com (Anuj Verma (Kevin)) Date: Thu, 8 Feb 2007 15:21:43 +0000 (UTC) Subject: FYI: Hildon desktop scalability - its on your desktop Message-ID: What is Hildon ? http://maemo.org/community/hildon_ui.html Whats with it for Desktop now ? http://www.karoliinasalminen.com/blog/?p=174 http://www.katix.org/gallery2/main.php?g2_view=core:ShowItem&g2_itemId=4906&g2_imageViewsIndex=2 Kevin From jwboyer at jdub.homelinux.org Thu Feb 8 15:45:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 8 Feb 2007 09:45:12 -0600 Subject: FYI: Hildon desktop scalability - its on your desktop In-Reply-To: References: Message-ID: <20070208154511.GB13072@yoda.jdub.homelinux.org> On Thu, Feb 08, 2007 at 03:21:43PM +0000, Anuj Verma (Kevin) wrote: > What is Hildon ? > http://maemo.org/community/hildon_ui.html Um, it's the window manager on the Nokia n770 and n800 devices. > Whats with it for Desktop now ? I have no idea. It really has nothing to do with Fedora. josh From dwmw2 at infradead.org Thu Feb 8 15:54:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Feb 2007 15:54:18 +0000 Subject: qemu 0.9.0 in -devel In-Reply-To: <200702080853.41632.dennis@ausil.us> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> <200702080853.41632.dennis@ausil.us> Message-ID: <1170950058.29759.1347.camel@pmac.infradead.org> On Thu, 2007-02-08 at 08:53 -0600, Dennis Gilmore wrote: > I built the devel srpm on FC-6 and it resolved a couple of sparc32 issues i > had. So i say push it There's apparently a BIOS issue on i386? There's also one on PPC; I'm working on getting it to boot Fedora in qemu-system-ppc. I'd like to get those sorted first. -- dwmw2 From dennis at ausil.us Thu Feb 8 16:04:55 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 8 Feb 2007 10:04:55 -0600 Subject: qemu 0.9.0 in -devel In-Reply-To: <1170950058.29759.1347.camel@pmac.infradead.org> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> <200702080853.41632.dennis@ausil.us> <1170950058.29759.1347.camel@pmac.infradead.org> Message-ID: <200702081004.55357.dennis@ausil.us> On Thursday 08 February 2007 09:54, David Woodhouse wrote: > On Thu, 2007-02-08 at 08:53 -0600, Dennis Gilmore wrote: > > I built the devel srpm on FC-6 and it resolved a couple of sparc32 issues > > i had. So i say push it > > There's apparently a BIOS issue on i386? There's also one on PPC; I'm > working on getting it to boot Fedora in qemu-system-ppc. I'd like to get > those sorted first. ok i only tested qemu-system-sparc which worked much better than 0.8.2 -- Dennis Gilmore, RHCE From kevin.verma at gmail.com Thu Feb 8 16:23:48 2007 From: kevin.verma at gmail.com (Anuj Verma (Kevin)) Date: Thu, 8 Feb 2007 16:23:48 +0000 (UTC) Subject: FYI: Hildon desktop scalability - its on your desktop References: <20070208154511.GB13072@yoda.jdub.homelinux.org> Message-ID: On Thu, 08 Feb 2007 09:45:12 -0600, Josh Boyer wrote: > Um, it's the window manager on the Nokia n770 and n800 devices. > >> Whats with it for Desktop now ? > > I have no idea. It really has nothing to do with Fedora. > > josh Perhaps this can be a choice of window manager for some Fedora users in future. Maybe for users of Pepperpad & Orgami devices. From jwboyer at jdub.homelinux.org Thu Feb 8 17:56:50 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 8 Feb 2007 11:56:50 -0600 Subject: FYI: Hildon desktop scalability - its on your desktop In-Reply-To: References: <20070208154511.GB13072@yoda.jdub.homelinux.org> Message-ID: <20070208175650.GC13072@yoda.jdub.homelinux.org> On Thu, Feb 08, 2007 at 04:23:48PM +0000, Anuj Verma (Kevin) wrote: > On Thu, 08 Feb 2007 09:45:12 -0600, Josh Boyer wrote: > > > Um, it's the window manager on the Nokia n770 and n800 devices. > > > >> Whats with it for Desktop now ? > > > > I have no idea. It really has nothing to do with Fedora. > > > > josh > > Perhaps this can be a choice of window manager for some Fedora users in > future. Maybe for users of Pepperpad & Orgami devices. I suppose it could be if it works well and someone packaged it for Fedora. New contributions are always welcome as long as they meet the packaging criteria and are free software :). josh From gilboad at gmail.com Thu Feb 8 18:31:50 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 08 Feb 2007 20:31:50 +0200 Subject: Is there a NFS alternative? In-Reply-To: <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> Message-ID: <1170959510.6314.37.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-07 at 14:52 -0600, Arthur Pemberton wrote: > On 2/7/07, Daniel Yek wrote: > > At 12:44 PM 2/7/2007, Arthur Pemberton wrote: > > >On 2/7/07, Daniel Yek wrote: > > >>Hi, > > >> > > >>It was a while ago when I read that NFS was difficult to secure with (the > > >>use of) ssh and iptables (or something like that). > > >> > > >>I really needed an alternative that works and can be made secure. Is GFS a > > >>suitable replacement for NFS? If not, what is the closest thing to NFS? > > >> > > >>Thanks. > > > > > >Subdue NFS to use only one port, firewall all other ports > > >off....possible filter the NFS port too? > > > > Thanks for replying. > > > > That is what I read and I was looking for an alternative to that. Is there > > other solution? Or this is the best available solution already? > > Well, if you can suggest how the solution could be made better, I or > others can maybe suggest how to implement it. > > The only other thing i can thing of is have port mapper interface with > iptables in a plug and play type firewall way (or however Windows > refers to it) > No need to. Just configure the ports in /etc/sysconfig/nfs and open a hole for them. E.g: # # /etc/sysconfig/nfs # # mountd 2050/tcp # mountd 2050/udp MOUNTD_PORT=2050 # rquotad 2051/tcp # rquotad 2051/udp RQUOTAD_PORT=2051 # nlockmgr 2052/tcp # nlockmgr 2052/udp LOCKD_TCPPORT=2052 LOCKD_UDPPORT=2052 # status 2053/tcp # status 2053/udp STATD_PORT=2053 STATD_OUTGOING_PORT=2054 - Gilboa From gilboad at gmail.com Thu Feb 8 18:35:12 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 08 Feb 2007 20:35:12 +0200 Subject: Is there a NFS alternative? In-Reply-To: <1170959510.6314.37.camel@gilboa-work-dev.localdomain> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <1170959510.6314.37.camel@gilboa-work-dev.localdomain> Message-ID: <1170959712.6314.41.camel@gilboa-work-dev.localdomain> On Thu, 2007-02-08 at 20:31 +0200, Gilboa Davara wrote: > On Wed, 2007-02-07 at 14:52 -0600, Arthur Pemberton wrote: > > On 2/7/07, Daniel Yek wrote: > > > At 12:44 PM 2/7/2007, Arthur Pemberton wrote: > > > >On 2/7/07, Daniel Yek wrote: > > > >>Hi, > > > >> > > > >>It was a while ago when I read that NFS was difficult to secure with (the > > > >>use of) ssh and iptables (or something like that). > > > >> > > > >>I really needed an alternative that works and can be made secure. Is GFS a > > > >>suitable replacement for NFS? If not, what is the closest thing to NFS? > > > >> > > > >>Thanks. > > > > > > > >Subdue NFS to use only one port, firewall all other ports > > > >off....possible filter the NFS port too? > > > > > > Thanks for replying. > > > > > > That is what I read and I was looking for an alternative to that. Is there > > > other solution? Or this is the best available solution already? > > > > Well, if you can suggest how the solution could be made better, I or > > others can maybe suggest how to implement it. > > > > The only other thing i can thing of is have port mapper interface with > > iptables in a plug and play type firewall way (or however Windows > > refers to it) > > > > No need to. > Just configure the ports in /etc/sysconfig/nfs and open a hole for them. > E.g: > # > # /etc/sysconfig/nfs > # > # mountd 2050/tcp > # mountd 2050/udp > MOUNTD_PORT=2050 > > # rquotad 2051/tcp > # rquotad 2051/udp > RQUOTAD_PORT=2051 > > # nlockmgr 2052/tcp > # nlockmgr 2052/udp > LOCKD_TCPPORT=2052 > LOCKD_UDPPORT=2052 > > # status 2053/tcp > # status 2053/udp > STATD_PORT=2053 > STATD_OUTGOING_PORT=2054 > > - Gilboa Forgot to add. You can then use SSH port redirection (ssh -L) to access these ports over a secure connection. - Gilboa From jfontain at free.fr Thu Feb 8 20:08:35 2007 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 08 Feb 2007 21:08:35 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> Message-ID: <45CB8343.3090306@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Kofler wrote: > Jean-Luc Fontaine free.fr> writes: >> Well, then there's gonna be a big problem with blt (now in extras, a >> graphical library) which is far from ready to compile against tcl-8.5, > > The strange thing is that it doesn't show up in the "broken dependencies" list, > so RPM thinks the version built against 8.4 is still going to run (there's no > dependency on the versioned soname). I don't know whether that's true. I checked again and blt is indeed very much incompatible with tcl-8.5, so I will correct blt.spec accordingly. > > itcl, itk and iwidgets are in a similar situation, they don't seem to depend on > libtcl8.4.so either for some reason, so I have no idea if they actually need a > rebuilt or not. Neither do I, and I suspect that the quite many packages that depend on tcl have not been well tested against tcl-8.5. So I hope reason will prevail and F7 will include the recent tcl 8.4.14 instead. - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFy4NCkG/MMvcT1qQRAkQQAJ9DKd863oF2Y/4KaN46qEV7qeuGnQCfdn57 mXF4Kqr3A7OvuwfJPGkmuP4= =Ipq0 -----END PGP SIGNATURE----- From mmcgrath at fedoraproject.org Thu Feb 8 20:27:58 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 8 Feb 2007 14:27:58 -0600 Subject: Wiki upgrade Message-ID: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> There's been a strong push to get the wiki upgraded sooner than later. Unfortunately we're running into stability issues (among other things) in its current state and platform. Sometime in the next couple of weeks we'll probably request a 12-24 hour wiki change lock so we can do the upgrade. We're going to try to make this as painless as possible but please be patient. Is there any time that is better / worse than any other time for anyone out there? Does anyone care as long as enough advanced notice is given? -Mike From tibbs at math.uh.edu Thu Feb 8 20:32:17 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Feb 2007 14:32:17 -0600 Subject: Wiki upgrade In-Reply-To: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> References: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> Is there any time that is better / worse than any other time for MM> anyone out there? Does anyone care as long as enough advanced MM> notice is given? Any chance we could get the package import switched over from editing CVSSyncNeeded to flags before the wiki is taken offline? - J< From chitlesh at fedoraproject.org Thu Feb 8 21:07:07 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 8 Feb 2007 22:07:07 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1170842980.3892.1.camel@scriabin.tannenrauch.ch> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <1170838061.45c9922d58224@imp.free.fr> <1170842980.3892.1.camel@scriabin.tannenrauch.ch> Message-ID: <13dbfe4f0702081307q13096230v3e742e1401ee6713@mail.gmail.com> On 2/7/07, G?rard Milmeister wrote: > One could also create a package compat-tcl-84. I have about 4/5 packages which compile under tcl/tk. It would be nice that for such type of package on with many apps depends on: - fedora maintainer should provide rpms of the "sudden change" of version before submitting to rawhide - during a time delay, the respective packagers test their packages against that major update - and then submit it to rawhide if consider worth Last time, guile updated to 1.8, all my geda packages that fedora shipped were broken, till now upstream doesn't have a fix yet. Mamuro and G?rard helped to package a compat-guile package to temporary fix the fedora broken packages. I just don't want to see all my dependent packages broken again (broken packages == fedora removed from all nodes of my university lab + all my effort for opensource were useless) . During the review, the blt module was broken, and now it's working fine. But duno what it could be next time. Chitlesh -- http://clunixchit.blogspot.com From wart at kobold.org Thu Feb 8 21:17:03 2007 From: wart at kobold.org (Michael Thomas) Date: Thu, 08 Feb 2007 13:17:03 -0800 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> Message-ID: <45CB934F.8020600@kobold.org> Kevin Kofler wrote: > Jean-Luc Fontaine free.fr> writes: >> Well, then there's gonna be a big problem with blt (now in extras, a >> graphical library) which is far from ready to compile against tcl-8.5, > > The strange thing is that it doesn't show up in the "broken dependencies" list, > so RPM thinks the version built against 8.4 is still going to run (there's no > dependency on the versioned soname). I don't know whether that's true. It's likely compiled against the Tcl stubs library, which is supposed to allow upgrades to the core Tcl without the need to rebuild the extension itself. The staticly linked stubs library can switch from the dynamic libtlc8.4.so to libtcl8.5.so without needing to recompile the extension. http://wiki.tcl.tk/285 > itcl, itk and iwidgets are in a similar situation, they don't seem to depend on > libtcl8.4.so either for some reason, so I have no idea if they actually need a > rebuilt or not. In this case, the stubs mechanism failed because itcl tries to require tcl 8.4 or tcl8.5, and fails because it doesn't recognize 8.5a5 as a valid 8.5 version. This is easy to fix with a rebuild if itcl/itk. I don't think it's unreasonable to expect a rebuild of the extensions when moving from 8.4 to 8.5aX to 8.5. Rebuilding itcl/itk with tcl8.5a5 fixes the problem for itcl, and itcl passes its own test suite with tcl8.5a5. I'm submitting rebuilds for both itcl and itk now (iwidgets is noarch, no rebuild is necessary). --Wart From sander at hoentjen.eu Thu Feb 8 21:31:22 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Thu, 08 Feb 2007 22:31:22 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CB8343.3090306@free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB8343.3090306@free.fr> Message-ID: <1170970282.11060.13.camel@peecee.hoentjen.eu> On Thu, 2007-02-08 at 21:08 +0100, Jean-Luc Fontaine wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kevin Kofler wrote: > > Jean-Luc Fontaine free.fr> writes: > >> Well, then there's gonna be a big problem with blt (now in extras, a > >> graphical library) which is far from ready to compile against tcl-8.5, > > > > The strange thing is that it doesn't show up in the "broken > dependencies" list, > > so RPM thinks the version built against 8.4 is still going to run > (there's no > > dependency on the versioned soname). I don't know whether that's true. > I checked again and blt is indeed very much incompatible with tcl-8.5, > so I will correct blt.spec accordingly. > > > > itcl, itk and iwidgets are in a similar situation, they don't seem to > depend on > > libtcl8.4.so either for some reason, so I have no idea if they actually > need a > > rebuilt or not. > Neither do I, and I suspect that the quite many packages that depend > on tcl have not been well tested against tcl-8.5. So I hope reason > will prevail and F7 will include the recent tcl 8.4.14 instead. > I am a bit in unsure here. On the one hand I really want tcl/tk 8.5 because a lot of amsn users are requesting AA fonts (or are complaining about the lack thereof). We also tested amsn against 8.5 and fixed incompatibility issues. Some of those were not fixed in amsn but in tcl/tk. In that respect I think it is important for projects to step to tcl/tk 8.5 so they can report any problems they have to the tcl/tk team. (yes i know that this is not the task of fedora, but i wanted to point it out anyway) On the other hand we don't know when this will even get out of alpha. I would still vote in favor of 8.5 though, 8.5 has reached more or less the bug fixing stage(*) and what better way to flush out bugs by having lots of users. Then again maybe the true reason is i want it because i like new shiny things. Sander (*) according to a dev on IRC: "feature freeze was december and now it's bug fixing time prior to beta" From mmcgrath at fedoraproject.org Thu Feb 8 21:44:03 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 8 Feb 2007 15:44:03 -0600 Subject: Wiki upgrade In-Reply-To: References: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> Message-ID: <3237e4410702081344q1a5fc46bnf63f7869b3891244@mail.gmail.com> On 08 Feb 2007 14:32:17 -0600, Jason L Tibbitts III wrote: > >>>>> "MM" == Mike McGrath writes: > > MM> Is there any time that is better / worse than any other time for > MM> anyone out there? Does anyone care as long as enough advanced > MM> notice is given? > > Any chance we could get the package import switched over from editing > CVSSyncNeeded to flags before the wiki is taken offline? > Sorry, i crossposted the hell out of this. The wiki won't be taken offline just made un-editible for most of that time. I haven't been working with the CVSSync changes so I can't speak with any authority on what will happen when with it. -Mike From jfontain at free.fr Thu Feb 8 21:55:20 2007 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 08 Feb 2007 22:55:20 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CB934F.8020600@kobold.org> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> Message-ID: <45CB9C48.6000406@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Thomas wrote: > Kevin Kofler wrote: >> Jean-Luc Fontaine free.fr> writes: >>> Well, then there's gonna be a big problem with blt (now in extras, a >>> graphical library) which is far from ready to compile against >>> tcl-8.5, >> >> The strange thing is that it doesn't show up in the "broken >> dependencies" list, so RPM thinks the version built against 8.4 is >> still going to run (there's no dependency on the versioned soname). >> I don't know whether that's true. > > It's likely compiled against the Tcl stubs library, blt certainly is not: would you be willing to try to make it work? (like I mentioned before, I cannot do it). But be advised that the blt CVS does not even compile... - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFy5xHkG/MMvcT1qQRAtaLAJoCobM8j5gY8qBnWrg7AWbpRpmlwgCgsFIg Ph1ZqVA2QYdIj/2446YAaB4= =67ah -----END PGP SIGNATURE----- From wart at kobold.org Thu Feb 8 22:06:09 2007 From: wart at kobold.org (Michael Thomas) Date: Thu, 08 Feb 2007 14:06:09 -0800 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CB9C48.6000406@free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> <45CB9C48.6000406@free.fr> Message-ID: <45CB9ED1.6000307@kobold.org> Jean-Luc Fontaine wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Thomas wrote: >> Kevin Kofler wrote: >>> Jean-Luc Fontaine free.fr> writes: >>>> Well, then there's gonna be a big problem with blt (now in extras, a >>>> graphical library) which is far from ready to compile against >>>> tcl-8.5, >>> The strange thing is that it doesn't show up in the "broken >>> dependencies" list, so RPM thinks the version built against 8.4 is >>> still going to run (there's no dependency on the versioned soname). >>> I don't know whether that's true. >> It's likely compiled against the Tcl stubs library, > blt certainly is not: would you be willing to try to make it work? > (like I mentioned before, I cannot do it). > But be advised that the blt CVS does not even compile... Yes, I'm willing to work on it. I maintain almost 20 other Tcl extensions, so I wouldn't be surprised to run into the same problems in multiple places. --Wart From mattdm at mattdm.org Thu Feb 8 22:09:14 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Feb 2007 17:09:14 -0500 Subject: Is there a NFS alternative? In-Reply-To: <1170885232.3189.8.camel@sb-home.lan> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <20070207210859.GA8671@jadzia.bu.edu> <1170885232.3189.8.camel@sb-home.lan> Message-ID: <20070208220914.GA22507@jadzia.bu.edu> On Wed, Feb 07, 2007 at 10:53:52PM +0100, nodata wrote: > > The only thing GFS shares with NFS is the letters "F" and "S". It is > > otherwise an entirely different thing. > > The closest thing to what you want is NFSv4 with Kerberos. > and perhaps -o tcp with udp firewalled? NFSv4 is TCP-only. (Although apparently the Linux implementation might support UDP as a non-standard option.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Feb 8 22:09:43 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Feb 2007 17:09:43 -0500 Subject: Is there a NFS alternative? In-Reply-To: <200702071504.47527.lamont@gurulabs.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <200702071504.47527.lamont@gurulabs.com> Message-ID: <20070208220943.GB22507@jadzia.bu.edu> On Wed, Feb 07, 2007 at 03:04:46PM -0700, Lamont Peterson wrote: > AndrewFS or CodaFS. ^^^^^^^ No. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From seg at haxxed.com Thu Feb 8 22:34:44 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 08 Feb 2007 16:34:44 -0600 Subject: Is there a NFS alternative? In-Reply-To: <20070208220914.GA22507@jadzia.bu.edu> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <20070207210859.GA8671@jadzia.bu.edu> <1170885232.3189.8.camel@sb-home.lan> <20070208220914.GA22507@jadzia.bu.edu> Message-ID: <1170974084.13307.62.camel@localhost.localdomain> On Thu, 2007-02-08 at 17:09 -0500, Matthew Miller wrote: > NFSv4 is TCP-only. (Although apparently the Linux implementation might > support UDP as a non-standard option.) NFSv4 can go through firewalls quite nicely, in fact system-config-securitylevel has a checkbox for it. I've never ever had any luck getting NFSv3 to pipe through NAT or a SSH tunnel etc. I recently started switching all my systems over to NFSv4, so I can enable their firewalls. (With IPv6, you can no longer count on the safety of NAT...) I'm having strange problems with one of my boxes, the system locks up hard any time I actually try and use the mount for very long. Its my "HTPC" and playing video off it on another machine will do it every time. And then there's the PPC box that refuses to mount NFSv4 at all... -------------- 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 david at fubar.dk Thu Feb 8 23:37:10 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 08 Feb 2007 18:37:10 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170920999.8675.29.camel@laptopd505.fenrus.org> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> <200702071524.08122.jkeating@redhat.com> <1170880209.3315.22.camel@zelda.fubar.dk> <1170920999.8675.29.camel@laptopd505.fenrus.org> Message-ID: <1170977830.5753.3.camel@zelda.fubar.dk> On Thu, 2007-02-08 at 08:49 +0100, Arjan van de Ven wrote: > > make hal > > pull in libsmbios once Matt, his colleagues or others have packaged it > > up [1] for Fedora (hint hint nudge nudge) - the latter means that Dell > > laptops can have their backlight controlled via g-p-m etc.) > > .... which is ENTIRELY the wrong way I suspect. > The kernel provides a unified backlight API now, adding more private > hacks rather than moving them to the unified API sounds like a step > backwards to me .. Yea, I agree it would be a helluva lot nicer if this could be done in the kernel instead of doing it from user space. But as Richard says, and from what I gather from several kernel developers, the way backlight works on a Dell laptop is not something that people want in the kernel. Today it's done via libsmbios and the dcdbas kernel module (which is upstream already). At least with HAL applications on top, like g-p-m, don't have to care; and should someone submit a kernel module to the kernel that does this, we'll just use that instead. I hope that clarifies. David From lamont at gurulabs.com Fri Feb 9 01:19:18 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 8 Feb 2007 18:19:18 -0700 Subject: Is there a NFS alternative? In-Reply-To: <20070208220943.GB22507@jadzia.bu.edu> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <200702071504.47527.lamont@gurulabs.com> <20070208220943.GB22507@jadzia.bu.edu> Message-ID: <200702081819.29051.lamont@gurulabs.com> On Thursday 08 February 2007 03:09pm, Matthew Miller wrote: > On Wed, Feb 07, 2007 at 03:04:46PM -0700, Lamont Peterson wrote: > > AndrewFS or CodaFS. > > ^^^^^^^ > > No. :) Agreed. He asked *is* there an alternative, so I listed an alternative. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajneil at gmail.com Fri Feb 9 03:05:37 2007 From: ajneil at gmail.com (Alastair Neil) Date: Thu, 8 Feb 2007 22:05:37 -0500 Subject: Is there a NFS alternative? In-Reply-To: <200702081819.29051.lamont@gurulabs.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <200702071504.47527.lamont@gurulabs.com> <20070208220943.GB22507@jadzia.bu.edu> <200702081819.29051.lamont@gurulabs.com> Message-ID: <85ac2ef40702081905l5c78a1bdjb3c92c6dcabd1c21@mail.gmail.com> On 2/8/07, Lamont Peterson wrote: > > On Thursday 08 February 2007 03:09pm, Matthew Miller wrote: > > On Wed, Feb 07, 2007 at 03:04:46PM -0700, Lamont Peterson wrote: > > > AndrewFS or CodaFS. > > > > ^^^^^^^ > > > > No. > > :) Agreed. > > He asked *is* there an alternative, so I listed an alternative. > -- > Here is my iptables and nfs configuration. We flirted with nfsv4 however the supported feature matrix is pretty sparse. For secure filesharing we are migrating to OpenAFS. [ajn at depweb ~]$ cat /etc/sysconfig/nfs > RPCNFSDCOUNT=35 > STATD_PORT=10002 > STATD_OUTGOING_PORT=10003 > MOUNTD_PORT=10004 > RQUOTAD_PORT=10005 > [ajn at depweb ~]$ sudo cat /etc/sysconfig/iptables > # Firewall configuration written by system-config-securitylevel > # Manual customization of this file is not recommended. > *filter > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > :RH-Firewall-1-INPUT - [0:0] > :NFS-INPUT - [0:0] > -A INPUT -j NFS-INPUT > -A FORWARD -j NFS-INPUT > -A INPUT -j RH-Firewall-1-INPUT > -A FORWARD -j RH-Firewall-1-INPUT > -A RH-Firewall-1-INPUT -i lo -j ACCEPT > -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT > -A RH-Firewall-1-INPUT -p 50 -j ACCEPT > -A RH-Firewall-1-INPUT -p 51 -j ACCEPT > -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT > -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j > ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j > ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j > ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j > ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j > ACCEPT > -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited > # Firewall rules for NFS with the following restrictions set in the nfs > sysconfig: > # RPCNFSDCOUNT=25 > # STATD_PORT=10002 > # STATD_OUTGOING_PORT=10003 > # MOUNTD_PORT=10004 > # RQUOTAD_PORT=10005 > # > -A NFS-INPUT -p tcp -m tcp --dport 111 -j ACCEPT > -A NFS-INPUT -p udp -m udp --dport 111 -j ACCEPT > -A NFS-INPUT -p tcp -m tcp --dport 2049 -j ACCEPT > -A NFS-INPUT -p udp -m udp --dport 2049 -j ACCEPT > -A NFS-INPUT -p tcp -m tcp --dport 10002:10005 -j ACCEPT > -A NFS-INPUT -p udp -m udp --dport 10002:10005 -j ACCEPT > # > COMMIT > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.salim at gmail.com Fri Feb 9 03:40:37 2007 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 8 Feb 2007 22:40:37 -0500 Subject: Firewire on Fedora 7: summary of troubles In-Reply-To: <1170730920.2907.137.camel@zelda.fubar.dk> References: <883cfe6d0702051751q47764c88oba3f434ee50cce@mail.gmail.com> <1170730920.2907.137.camel@zelda.fubar.dk> Message-ID: <883cfe6d0702081940y8d55d26wdd669d5ac6f981cb@mail.gmail.com> 2007/2/5, David Zeuthen : > On Mon, 2007-02-05 at 20:51 -0500, Michel Salim wrote: > > -- after unloading and reloading sbp2, the drive is detected, but > > gnome-volume-manager still does not see it after logging in > > hal probably needs to be taught about the new Firewire stack; not hard, > I'll look at this tomorrow when I seize my Firewire drives from krh :-) > The new hal and/or dbus seems to make my Firewire problem worse; now with both 1.2919 and 1.2922 kernels (x86_64) I'd get a kernel panic. If I plug the Firewire device in after the system boots up, after the kernel panic messages are dumped on the current terminal I could switch to other terminals but after entering my username and password I would not get a prompt. I have some dmesg output from the time before the problem becomes terminal -- this is more a kernel bug than a hal bug, yes? -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From michel.salim at gmail.com Fri Feb 9 03:47:35 2007 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 8 Feb 2007 22:47:35 -0500 Subject: Firewire on Fedora 7: summary of troubles In-Reply-To: <883cfe6d0702081940y8d55d26wdd669d5ac6f981cb@mail.gmail.com> References: <883cfe6d0702051751q47764c88oba3f434ee50cce@mail.gmail.com> <1170730920.2907.137.camel@zelda.fubar.dk> <883cfe6d0702081940y8d55d26wdd669d5ac6f981cb@mail.gmail.com> Message-ID: <883cfe6d0702081947m197fce2fm278cb09c152d52b9@mail.gmail.com> 2007/2/8, Michel Salim : > The new hal and/or dbus seems to make my Firewire problem worse; now > with both 1.2919 and 1.2922 kernels (x86_64) I'd get a kernel panic. > If I plug the Firewire device in after the system boots up, after the > kernel panic messages are dumped on the current terminal I could > switch to other terminals but after entering my username and password > I would not get a prompt. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222550 -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From bojan at rexursive.com Fri Feb 9 04:28:09 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 09 Feb 2007 15:28:09 +1100 Subject: ViewVC Message-ID: <20070209152809.1s4bir200k04cgsg@www.rexursive.com> I'm not sure if I'm being blind or something, but I can't seem to be able to find ViewVC (http://www.viewvc.org/) in Core/Extras (6 and devel). Does anyone know if this software was ever officially part of Fedora? -- Bojan From trenner at terrasoftsolutions.com Fri Feb 9 05:03:07 2007 From: trenner at terrasoftsolutions.com (Timothy Renner) Date: Thu, 08 Feb 2007 22:03:07 -0700 Subject: Is there a NFS alternative? In-Reply-To: <85ac2ef40702081905l5c78a1bdjb3c92c6dcabd1c21@mail.gmail.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <200702071504.47527.lamont@gurulabs.com> <20070208220943.GB22507@jadzia.bu.edu> <200702081819.29051.lamont@gurulabs.com> <85ac2ef40702081905l5c78a1bdjb3c92c6dcabd1c21@mail.gmail.com> Message-ID: <45CC008B.2050704@terrasoftsolutions.com> There is another alternative I use that doesn't require switching filesystems. OpenVPN (http://openvpn.net/). I can hook in from anywhere (It needs a single port open in your firewall and supports either UDP or TCP. This way you can keep from opening up ports to the outside and and allow access only through the VPN interface. NFS runs quite well for me over it as packets are just routed and it took me about 10 minutes to set up a server, generate keys and set up a client, never having done this before. -Tim > > He asked *is* there an alternative, so I listed an alternative. > -- > From lmacken at redhat.com Fri Feb 9 06:22:50 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 09 Feb 2007 01:22:50 -0500 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1170627996.7629.7.camel@mortise.boston.redhat.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> Message-ID: <45CC133A.8050902@redhat.com> David Cantrell wrote: > Announcing repoman > ------------------ > > Repoman is a PyGTK frontend for configuring common and basic settings > for yum. Specifically, it lets users enable and disable individual > repos easily. Users can add and remove repositories as well. > > Repoman is not meant to expose all of yum's configuration settings in > GUI form, but rather the common settings most users will care about. > > One of the interesting features is the Tracking page. Users can easily > switch between stable (with or without updates) or development branches > and repoman will enable and disable the correct repositories for the > user. > > Repoman also offers a set of Python classes for reading and writing out > /etc/yum.repos.d files. The core element is the RepoStanza, which are > contained in RepoFiles, and all of those make up a Repos collection. > > This program is evolving a lot, so help testing and/or coding is > appreciated. Nice work! Just nitpicking a bit; there is duplicate functionality with regard to enabling a repository. I'd say just leave the checkbox on the Repositories list and toss the one in the Edit window (which doesn't seem to be working anyway). Also, attached is a trivial patch to make repoman not explode when ctrl+c'd from the command line. luke -------------- next part -------------- A non-text attachment was scrubbed... Name: repoman-0.5-kb.patch Type: text/x-patch Size: 292 bytes Desc: not available URL: From naoki at valuecommerce.com Fri Feb 9 07:41:47 2007 From: naoki at valuecommerce.com (Naoki) Date: Fri, 09 Feb 2007 16:41:47 +0900 Subject: My fc7t1 problems. Message-ID: <1171006907.3634.50.camel@dragon.valuecommerce.ne.jp> Anybody else? 2.6.19 kernel kills my 64-bit SMP boxes (up stream issue actually) : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227961 "2.6.19-1.2898.2.3.fc7xen #1 SMP" breaks networking - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227972 For some reason devices can DHCP on boot, routes are correctly set etc, but no network traffic is passing. tcpdump on eth0 shows zero packets, even when pinging local IP. This is with the "bnx2" driver. "yum upgrade" from clean FC6 kills sudoers file (creates an "rpmnew" and an "rpmsave" but removes /etc/sudoers" - Anybody else, bug ? From jfontain at free.fr Fri Feb 9 07:44:17 2007 From: jfontain at free.fr (jfontain at free.fr) Date: Fri, 09 Feb 2007 08:44:17 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CB9ED1.6000307@kobold.org> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> <45CB9C48.6000406@free.fr> <45CB9ED1.6000307@kobold.org> Message-ID: <1171007057.45cc26511a668@imp.free.fr> Quoting Michael Thomas : > Jean-Luc Fontaine wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Michael Thomas wrote: > >> Kevin Kofler wrote: > >>> Jean-Luc Fontaine free.fr> writes: > >>>> Well, then there's gonna be a big problem with blt (now in extras, a > >>>> graphical library) which is far from ready to compile against > >>>> tcl-8.5, > >>> The strange thing is that it doesn't show up in the "broken > >>> dependencies" list, so RPM thinks the version built against 8.4 is > >>> still going to run (there's no dependency on the versioned soname). > >>> I don't know whether that's true. > >> It's likely compiled against the Tcl stubs library, > > blt certainly is not: would you be willing to try to make it work? > > (like I mentioned before, I cannot do it). > > But be advised that the blt CVS does not even compile... > > Yes, I'm willing to work on it. I maintain almost 20 other Tcl > extensions, so I wouldn't be surprised to run into the same problems in > multiple places. Great! Of course I will be helping testing it. From fedora at leemhuis.info Fri Feb 9 07:59:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Feb 2007 08:59:56 +0100 Subject: Announcing LHCP - Linux Hardware Compatibility Project In-Reply-To: <45BF7ED2.7070002@leemhuis.info> References: <45BE11A9.7080702@redhat.com> <45BF7ED2.7070002@leemhuis.info> Message-ID: <45CC29FC.2040701@leemhuis.info> On 30.01.2007 18:22, Thorsten Leemhuis wrote: > Phil Knirsch schrieb: >> We've recently started working on a project called Linux Hardware >> Compatibility >> Project or in short LHCP. > Nice. But well: It sound like yet-another-hardware-compatibility-list to > me. Thus I'm wondering: Don't we have enough of those already? You link > to several yourself on > https://hosted.fedoraproject.org/projects/LHCP/wiki/Links > So why yet another approach? Why not co-operate with one of those? Or > wait, let's do it even better: Try to work together with all of those > those and solve the problem once and for all *properly* and in a general > way? Read that as: cooperate with at least Novell/Opensuse, Debian and > Ubuntu and maybe get OSDL ^w TLF on board (from the start of). [...] Seems I didn't get much replies on this besides the post from Aurelien. :-( Anyway, there is yet a new effort out there that tries to solve the "is my hardware compatible to my operating system/linux" problem. And it not even tries to be cross-distribution, it tries it to solve it this problem for all major Operating Systems: http://www.compatdb.org/ [...] The CompatDB.org project is an attempt to create a free (as in the freedom) standard for user submitted compatibility lists as well free compatibility lists for Windows, Linux, and Mac OS. [...] The following operating systems are currently supported by CompatDB.org: [...] Linux: [...] Fedora Core [...] [...] CU thl From jfontain at free.fr Fri Feb 9 08:38:20 2007 From: jfontain at free.fr (jfontain at free.fr) Date: Fri, 09 Feb 2007 09:38:20 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CB9ED1.6000307@kobold.org> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> <45CB9C48.6000406@free.fr> <45CB9ED1.6000307@kobold.org> Message-ID: <1171010300.45cc32fc9eef1@imp.free.fr> Quoting Michael Thomas : > Yes, I'm willing to work on it. I maintain almost 20 other Tcl > extensions, so I wouldn't be surprised to run into the same problems in > multiple places. And thank you very much indeed for your work. Please let us know how your packages go against tcl 8.5 alpha so we can decide whether to stick with 8.4.14 or not. -- JL From mmaslano at redhat.com Fri Feb 9 12:17:31 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Fri, 09 Feb 2007 13:17:31 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1171010300.45cc32fc9eef1@imp.free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> <45CB9C48.6000406@free.fr> <45CB9ED1.6000307@kobold.org> <1171010300.45cc32fc9eef1@imp.free.fr> Message-ID: <45CC665B.5050104@redhat.com> I decided to go back to tcl8.4 and wait for final release. Too many packages are broken and their upstream didn't start work on them. Marcela Maslanova From drago01 at gmail.com Fri Feb 9 12:17:41 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 09 Feb 2007 13:17:41 +0100 Subject: rawhide report: 20070207 changes In-Reply-To: <13dbfe4f0702071132l2eb6831bwf44abe0fde7d3a54@mail.gmail.com> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <13dbfe4f0702071132l2eb6831bwf44abe0fde7d3a54@mail.gmail.com> Message-ID: <45CC6665.4070007@gmail.com> Chitlesh GOORAH wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212239 > compiz has a kde-window-decorator now but it is disabled in the builds because it depends on dbus-qt which is in extras. with the extras/core merge this should be solved in f7. (when the merge is complete and compiz is rebuild with kwd enabled) > Chitlesh From drago01 at gmail.com Fri Feb 9 12:21:56 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 09 Feb 2007 13:21:56 +0100 Subject: Is there a NFS alternative? In-Reply-To: <1170893518.29759.1230.camel@pmac.infradead.org> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071244j2e3fcf8fke2e086fbd90588eb@mail.gmail.com> <6.2.1.2.2.20070207124801.22e0ad00@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> <1170893518.29759.1230.camel@pmac.infradead.org> Message-ID: <45CC6764.5090106@gmail.com> David Woodhouse wrote: > On Wed, 2007-02-07 at 16:02 -0800, Daniel Yek wrote: > >> I am hoping for a secure solution to mount directories "shared out" from my >> other computer located remotely over the Internet. So that I can edit >> source files and execute programs "locally" and compile remotely (a much >> faster machine). >> > > Editing of source files works quite nicely over ssh given a capable > editor. > > $ emacs /dwmw2 at pentafluge.infradead.org:/home/dwmw2/public_html/foo.html & > > And obviously SSH is clever enough that that kind of trick even works > for hosts within private networks, because you can play tricks with > ProxyCommand to make 'ssh somehost.company.internal' entirely > transparent. > > Mostly I just use the above trick with emacs, and rsync -- which again > works over SSH so it's easy to get to/from company-internal machines. > > > you could also use fuse-sshfs From sundaram at fedoraproject.org Fri Feb 9 12:16:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 09 Feb 2007 17:46:16 +0530 Subject: ViewVC In-Reply-To: <20070209152809.1s4bir200k04cgsg@www.rexursive.com> References: <20070209152809.1s4bir200k04cgsg@www.rexursive.com> Message-ID: <45CC6610.9070201@fedoraproject.org> Bojan Smojver wrote: > I'm not sure if I'm being blind or something, but I can't seem to be > able to find ViewVC (http://www.viewvc.org/) in Core/Extras (6 and > devel). Does anyone know if this software was ever officially part of > Fedora? afaik, No Rahul From jkeating at redhat.com Fri Feb 9 13:04:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Feb 2007 08:04:23 -0500 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CC665B.5050104@redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <1171010300.45cc32fc9eef1@imp.free.fr> <45CC665B.5050104@redhat.com> Message-ID: <200702090804.23196.jkeating@redhat.com> On Friday 09 February 2007 07:17, Marcela Maslanova wrote: > I decided to go back to tcl8.4 and wait for final release. ?Too many > packages are broken > and their upstream didn't start work on them. Did you introduce an epoch or is there now a broken upgrade path? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sander at hoentjen.eu Fri Feb 9 13:34:31 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Fri, 09 Feb 2007 14:34:31 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <200702090804.23196.jkeating@redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <1171010300.45cc32fc9eef1@imp.free.fr> <45CC665B.5050104@redhat.com> <200702090804.23196.jkeating@redhat.com> Message-ID: <1171028071.11060.25.camel@peecee.hoentjen.eu> On Fri, 2007-02-09 at 08:04 -0500, Jesse Keating wrote: > On Friday 09 February 2007 07:17, Marcela Maslanova wrote: > > I decided to go back to tcl8.4 and wait for final release. Too many > > packages are broken > > and their upstream didn't start work on them. > > Did you introduce an epoch or is there now a broken upgrade path? according to http://cvs.fedora.redhat.com/viewcvs/devel/tcl/tcl.spec?r1=1.42&r2=1.43 he used an epoch From cra at WPI.EDU Fri Feb 9 13:34:58 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 9 Feb 2007 08:34:58 -0500 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <200702090804.23196.jkeating@redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <1171010300.45cc32fc9eef1@imp.free.fr> <45CC665B.5050104@redhat.com> <200702090804.23196.jkeating@redhat.com> Message-ID: <20070209133458.GN3334@angus.ind.WPI.EDU> On Fri, Feb 09, 2007 at 08:04:23AM -0500, Jesse Keating wrote: > On Friday 09 February 2007 07:17, Marcela Maslanova wrote: > > I decided to go back to tcl8.4 and wait for final release. ?Too many > > packages are broken > > and their upstream didn't start work on them. > > Did you introduce an epoch or is there now a broken upgrade path? I always thought introducing epochs in rawhide was bad--that this sort of breakage was to be expected from time to time, and that users of rawhide were expected to manually downgrade packages in these instances. From mmaslano at redhat.com Fri Feb 9 13:39:05 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Fri, 09 Feb 2007 14:39:05 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <200702090804.23196.jkeating@redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <1171010300.45cc32fc9eef1@imp.free.fr> <45CC665B.5050104@redhat.com> <200702090804.23196.jkeating@redhat.com> Message-ID: <45CC7979.6030703@redhat.com> I used an epoch. Upgrade looks ok. > Did you introduce an epoch or is there now a broken upgrade path? > > From paul at city-fan.org Fri Feb 9 13:43:06 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 09 Feb 2007 13:43:06 +0000 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <20070209133458.GN3334@angus.ind.WPI.EDU> References: <1170748677.45c8350535560@imp.free.fr> <1171010300.45cc32fc9eef1@imp.free.fr> <45CC665B.5050104@redhat.com> <200702090804.23196.jkeating@redhat.com> <20070209133458.GN3334@angus.ind.WPI.EDU> Message-ID: <45CC7A6A.2060102@city-fan.org> Chuck Anderson wrote: > On Fri, Feb 09, 2007 at 08:04:23AM -0500, Jesse Keating wrote: >> On Friday 09 February 2007 07:17, Marcela Maslanova wrote: >>> I decided to go back to tcl8.4 and wait for final release. Too many >>> packages are broken >>> and their upstream didn't start work on them. >> Did you introduce an epoch or is there now a broken upgrade path? > > I always thought introducing epochs in rawhide was bad--that this sort > of breakage was to be expected from time to time, and that users of > rawhide were expected to manually downgrade packages in these > instances. I'm in a similar position with bittorrent in Rawhide. The GUI for 5.x doesn't work with wxPython 2.8 and I may have to revert to 4.4, which has a pygtk2-based GUI. Should I use an epoch or not? Paul. From jkeating at redhat.com Fri Feb 9 14:32:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Feb 2007 09:32:44 -0500 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <20070209133458.GN3334@angus.ind.WPI.EDU> References: <1170748677.45c8350535560@imp.free.fr> <200702090804.23196.jkeating@redhat.com> <20070209133458.GN3334@angus.ind.WPI.EDU> Message-ID: <200702090932.44205.jkeating@redhat.com> On Friday 09 February 2007 08:34, Chuck Anderson wrote: > I always thought introducing epochs in rawhide was bad--that this sort > of breakage was to be expected from time to time, and that users of > rawhide were expected to manually downgrade packages in these > instances. There has been some discussion on this lately, and many feel that introducing some epochs is better than having broken upgrade paths. As to which point we make the cut off and say no more broken upgrades has yet to be decided. Choices are Test1, Test2, or Test3. I'm somewhat in favor of Test3. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pvrabec at redhat.com Fri Feb 9 15:17:13 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Fri, 9 Feb 2007 16:17:13 +0100 Subject: default syslogd Message-ID: <20070209161713.19ca2838@wrabco.brq.redhat.com> Hi, don't we want to change default syslogd in F7? syslog-ng might be ok, if there aren't problems with patents in US. http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html From sundaram at fedoraproject.org Fri Feb 9 15:21:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 09 Feb 2007 20:51:26 +0530 Subject: default syslogd In-Reply-To: <20070209161713.19ca2838@wrabco.brq.redhat.com> References: <20070209161713.19ca2838@wrabco.brq.redhat.com> Message-ID: <45CC9176.7040907@fedoraproject.org> Peter Vrabec wrote: > Hi, > > don't we want to change default syslogd in F7? > syslog-ng might be ok, if there aren't problems with patents in US. > http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html > Well if you are suspecting patent issues, you would need to get Red Hat legal involved. Nobody in this list can help there. Rahul From jkeating at redhat.com Fri Feb 9 15:33:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 9 Feb 2007 10:33:58 -0500 Subject: default syslogd In-Reply-To: <20070209161713.19ca2838@wrabco.brq.redhat.com> References: <20070209161713.19ca2838@wrabco.brq.redhat.com> Message-ID: <200702091033.59011.jkeating@redhat.com> On Friday 09 February 2007 10:17, Peter Vrabec wrote: > don't we want to change default syslogd in F7? Are you signing up to be responsible to drive this change, have it testable by Test1 (oops, too late), feature frozen by Test2? There is a lot involved with changing syslog, and these types of things don't just magically happen, they need a driver. Care to drive? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eswierk at arastra.com Fri Feb 9 16:24:43 2007 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 9 Feb 2007 08:24:43 -0800 Subject: qemu 0.9.0 in -devel In-Reply-To: <1170950058.29759.1347.camel@pmac.infradead.org> References: <1170784502.7155.52.camel@hades.cambridge.redhat.com> <200702080853.41632.dennis@ausil.us> <1170950058.29759.1347.camel@pmac.infradead.org> Message-ID: On 2/8/07, David Woodhouse wrote: > There's apparently a BIOS issue on i386? There's also one on PPC; I'm > working on getting it to boot Fedora in qemu-system-ppc. I'd like to get > those sorted first. The i386 BIOS issue (SYSLINUX hanging) has been fixed in qemu CVS: http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg00128.html --Ed From lsof at nodata.co.uk Fri Feb 9 19:25:44 2007 From: lsof at nodata.co.uk (nodata) Date: Fri, 09 Feb 2007 20:25:44 +0100 Subject: default syslogd In-Reply-To: <20070209161713.19ca2838@wrabco.brq.redhat.com> References: <20070209161713.19ca2838@wrabco.brq.redhat.com> Message-ID: <1171049144.3288.0.camel@sb-home.lan> Am Freitag, den 09.02.2007, 16:17 +0100 schrieb Peter Vrabec: > Hi, > > don't we want to change default syslogd in F7? > syslog-ng might be ok, if there aren't problems with patents in US. > http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html > Bit late isn't it? Didn't the younger Fedora Test releases have pretty much a feature freeze for Test 1? From sundaram at fedoraproject.org Fri Feb 9 19:43:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 10 Feb 2007 01:13:04 +0530 Subject: default syslogd In-Reply-To: <1171049144.3288.0.camel@sb-home.lan> References: <20070209161713.19ca2838@wrabco.brq.redhat.com> <1171049144.3288.0.camel@sb-home.lan> Message-ID: <45CCCEC8.5000101@fedoraproject.org> nodata wrote: > Am Freitag, den 09.02.2007, 16:17 +0100 schrieb Peter Vrabec: >> Hi, >> >> don't we want to change default syslogd in F7? >> syslog-ng might be ok, if there aren't problems with patents in US. >> http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html >> > > Bit late isn't it? > > Didn't the younger Fedora Test releases have pretty much a feature > freeze for Test 1? > No. Feature freeze has never been before test 2. There is a intermediate just a few days before each of the test releases to get some testing done however. Rahul From jyoung5 at us.ibm.com Fri Feb 9 20:38:21 2007 From: jyoung5 at us.ibm.com (Jerone Young) Date: Fri, 09 Feb 2007 14:38:21 -0600 Subject: Question on Feature Freeze ..and possibly of adding PPC Xen? Message-ID: <1171053501.3182.23.camel@thinkpad> I'm wondering how hard is the feature freeze on Febuary 20th? We would like to try and enable PPC Fedora with Xen. Though doing so will run past the freeze date of Febuary 20th as we would need to up port to the fedora kernel version. What would be the complete cut off date if it would be possible ? Also would any featured packages outside of the kernel that does not make the feature freeze date be OK for extras. Will there be an extras repository around FC7 time frame or is it that all packages will have be in the main repository and make the freeze date? From poelstra at redhat.com Sat Feb 10 00:34:29 2007 From: poelstra at redhat.com (John Poelstra) Date: Fri, 09 Feb 2007 16:34:29 -0800 Subject: Release process Message-ID: <45CD1315.6000405@redhat.com> This page refers to a release process "proposed" at the Fedora Summit a few months ago: http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess 1) Curious if this been "approved" or "finalized" somewhere else or if this is what we decided to do and can adopted as the current process? 2) The section on "rawhide" refers to a "rawhide repo"... will there be an actual repo named "rawhide" or is this assumed to be the current "development" repo? Thanks, John From opensource at till.name Sat Feb 10 00:49:19 2007 From: opensource at till.name (Till Maas) Date: Sat, 10 Feb 2007 01:49:19 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702031600.39508.jkeating@redhat.com> References: <1170534841.3775.0.camel@dawkins> <200702031600.39508.jkeating@redhat.com> Message-ID: <200702100149.21220.opensource@till.name> On Saturday 03 February 2007 22:00, Jesse Keating wrote: > fetchmail. Some desktops do read email. fetchmail can deliver mails with procmail or maildrop to local users. Regards, Till From jwilliam at xmission.com Sat Feb 10 01:04:32 2007 From: jwilliam at xmission.com (Jerry Williams) Date: Fri, 9 Feb 2007 18:04:32 -0700 Subject: Wakeup alarm? Message-ID: <000301c74caf$6cb0eab0$020aa8c0@a18> Can I get a beep on the screen that says click next to do the installation? Since at this point you have to wait for the dependency check to finish before you can click next for the install to run. That way I can get a 3 min. nap. :) There are some other versions of Linux that ask you for everything and then they do the install and you don't have to sit and wait for any long steps. From hughsient at gmail.com Sat Feb 10 01:09:24 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 10 Feb 2007 01:09:24 +0000 Subject: Wakeup alarm? In-Reply-To: <000301c74caf$6cb0eab0$020aa8c0@a18> References: <000301c74caf$6cb0eab0$020aa8c0@a18> Message-ID: <1171069764.19887.0.camel@hughsie-laptop> On Fri, 2007-02-09 at 18:04 -0700, Jerry Williams wrote: > Can I get a beep on the screen that says click next to do the > installation? > Since at this point you have to wait for the dependency check to > finish Why do we even need to confirm the next step? I've had boxes sitting idle for hours at this step... Richard. From cmadams at hiwaay.net Sat Feb 10 04:37:42 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 9 Feb 2007 22:37:42 -0600 Subject: Wakeup alarm? In-Reply-To: <1171069764.19887.0.camel@hughsie-laptop> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <1171069764.19887.0.camel@hughsie-laptop> Message-ID: <20070210043742.GA1510752@hiwaay.net> Once upon a time, Richard Hughes said: > Why do we even need to confirm the next step? I've had boxes sitting > idle for hours at this step... I haven't looked at the anaconda source, but the process is package selection -> dependency checking -> ask ok to install. What if dependency checking fails for some reason? It may not be done asking questions at that stage. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwilliam at xmission.com Sat Feb 10 05:19:06 2007 From: jwilliam at xmission.com (Jerry Williams) Date: Fri, 9 Feb 2007 22:19:06 -0700 Subject: Wakeup alarm? In-Reply-To: <20070210043742.GA1510752@hiwaay.net> References: <000301c74caf$6cb0eab0$020aa8c0@a18><1171069764.19887.0.camel@hughsie-laptop> <20070210043742.GA1510752@hiwaay.net> Message-ID: <000001c74cd2$fc94c5c0$020aa8c0@a18> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Chris Adams > Sent: Friday, February 09, 2007 9:38 PM > To: Development discussions related to Fedora Core > Subject: Re: Wakeup alarm? > > Once upon a time, Richard Hughes said: > > Why do we even need to confirm the next step? I've had boxes sitting > > idle for hours at this step... > > I haven't looked at the anaconda source, but the process is package > selection -> dependency checking -> ask ok to install. What if > dependency checking fails for some reason? It may not be done asking > questions at that stage. So if it fails another screen pops up and shows the problem and it sits for hours. How about a check box you can check to continue if no dependency problems. So package selection, check box -> dependency checking, no problems -> install Jerry Williams > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. From pertusus at free.fr Sat Feb 10 09:24:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Feb 2007 10:24:56 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <200702100149.21220.opensource@till.name> References: <1170534841.3775.0.camel@dawkins> <200702031600.39508.jkeating@redhat.com> <200702100149.21220.opensource@till.name> Message-ID: <20070210092456.GA2797@free.fr> On Sat, Feb 10, 2007 at 01:49:19AM +0100, Till Maas wrote: > On Saturday 03 February 2007 22:00, Jesse Keating wrote: > > > fetchmail. Some desktops do read email. > > fetchmail can deliver mails with procmail or maildrop to local users. Indeed, but see bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66396 It seems to rely on a real MTA for bounce mail. -- Pat From jkeating at redhat.com Sat Feb 10 14:10:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Feb 2007 09:10:26 -0500 Subject: Wakeup alarm? In-Reply-To: <20070210043742.GA1510752@hiwaay.net> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <1171069764.19887.0.camel@hughsie-laptop> <20070210043742.GA1510752@hiwaay.net> Message-ID: <200702100910.30331.jkeating@redhat.com> On Friday 09 February 2007 23:37, Chris Adams wrote: > I haven't looked at the anaconda source, but the process is package > selection -> dependency checking -> ask ok to install. ?What if > dependency checking fails for some reason? ?It may not be done asking > questions at that stage. Also we don't know how many CDs you'll need before doing depchecking. We have to prompt you with how many you'll need so that you don't start the install and get asked for a CD you didn't download/burn. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Sat Feb 10 14:14:14 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 10 Feb 2007 15:14:14 +0100 Subject: Wakeup alarm? In-Reply-To: <000301c74caf$6cb0eab0$020aa8c0@a18> References: <000301c74caf$6cb0eab0$020aa8c0@a18> Message-ID: <45CDD336.4090502@gmail.com> a better solution is to speed up the depsolving process somehow. maybe doing it with a plugin which is written in C like the metadata parser would help? From sundaram at fedoraproject.org Sat Feb 10 15:04:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 10 Feb 2007 20:34:51 +0530 Subject: Wakeup alarm? In-Reply-To: <45CDD336.4090502@gmail.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <45CDD336.4090502@gmail.com> Message-ID: <45CDDF13.4010102@fedoraproject.org> dragoran wrote: > a better solution is to speed up the depsolving process somehow. > maybe doing it with a plugin which is written in C like the metadata > parser would help? > The dependency resolving is done via RPM for the most part. The yum hackfest in FUDCon Boston 2007 recently was focused on generating and using the sqllite backend directly and fall back to parsing the metadata from XML only when the database content is outdated. That I heard has resulted in substantial performance boost. That along with a patch to use queries more effectively should make things better soon enough. https://lists.dulug.duke.edu/pipermail/yum-devel/2006-December/002970.html https://lists.dulug.duke.edu/pipermail/yum-devel/2007-January/003071.html Rahul From drago01 at gmail.com Sat Feb 10 15:53:02 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 10 Feb 2007 16:53:02 +0100 Subject: Wakeup alarm? In-Reply-To: <45CDDF13.4010102@fedoraproject.org> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <45CDD336.4090502@gmail.com> <45CDDF13.4010102@fedoraproject.org> Message-ID: <45CDEA5E.1040509@gmail.com> Rahul Sundaram wrote: > > The dependency resolving is done via RPM for the most part. The yum > hackfest in FUDCon Boston 2007 recently was focused on generating and > using the sqllite backend directly and fall back to parsing the > metadata from XML only when the database content is outdated. That I > heard has resulted in substantial performance boost. That along with a > patch to use queries more effectively should make things better soon > enough. > > https://lists.dulug.duke.edu/pipermail/yum-devel/2006-December/002970.html > > https://lists.dulug.duke.edu/pipermail/yum-devel/2007-January/003071.html > ok thx for that info and the links will look at them. > Rahul > From n0dalus+redhat at gmail.com Sat Feb 10 16:34:31 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sun, 11 Feb 2007 03:04:31 +1030 Subject: Wakeup alarm? In-Reply-To: <45CDD336.4090502@gmail.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <45CDD336.4090502@gmail.com> Message-ID: <6280325c0702100834i46760a25i63559a734073c6e5@mail.gmail.com> On 2/11/07, dragoran wrote: > a better solution is to speed up the depsolving process somehow. > maybe doing it with a plugin which is written in C like the metadata > parser would help? One thing that would really help, regardless of programming language (though C would be much faster), is to provide a "summary" of dependency relationships between packages on the discs. It would be in a small, separate file. A simple binary format would make it very small for fitting into memory uncompressed (though it's not necessary). To save space, packages should be referred to by an indexing system (integer numbers) and not by name -- this could improve efficiency in other parts of the installer too, so a centralized lookup table should be there if it's not already. - The first thing it would have is a pre-computed installation order for the (very) minimal installation. For this subset of packages the installer should be doing no dep-checking, and it should be the first things installed (and on the first disc). - Packages which only rely on the minimal set are then listed in the file. The installer can now install any of these at any time without dep-solving. - The rest of the dependencies are then listed, in an installable order, for every package. For example: The bare minimum install has the packages: A, B and C. There are also packages: D, E, F, G, H, I, J, K and L. Dependencies are as follows: A < B (this means B depends on A) A < C B < D C < D A < E A < F C < F A < G D < G F < H G < H K < H J < I E < J I < K The above dependencies can now be "summarized" (note that all these should be sets of indexes, not package names as shown here): A,B,C (installed first and in this order -- no dep checking needed) D,E,F (can be installed at any time without dep checking) D < G D,E,F,G,J,I,K < H (note order is already worked out) E,J < I E < J E,J,I < K The installer would go through and use a process something like this (some of this could likely be futher optimized, but keeping it simple for now). Pseudocode: #define n (KNOWN_PACKAGES-MIN_INSTALL_PACKAGES) int wanted_packages[]; bool installing[n] = { false, false, ... }; int install_order[n]; int i = 0; for(wanted_package in wanted_packages) { /* Gets install list from summary file This should offset indexes so package 0 the first package not in min install */ int install_list[] = get_install_list(wanted_package); for(package in install_list) { if(!installing[package]) { install_order[i++] = package + MIN_INSTALL_PACKAGES; installing[package] = true; } } } min_install(); install_packages(install_order); I don't know how different this is from what the installer already does, but I'd be interested to see how much it could be improved. n0dalus. From kwade at redhat.com Sat Feb 10 18:33:23 2007 From: kwade at redhat.com (Karsten Wade) Date: Sat, 10 Feb 2007 10:33:23 -0800 Subject: bz relnotes flag Message-ID: <1171132403.3265.89.camel@erato.phig.org> Today a new flag was added to bugzilla for Fedora components. By flipping the 'fedora_requires_release_notes' flag, the release notes team is alerted that the something in this bug report is worth tracking in the release notes.[1] The release notes process has now been updated to reflect the "Six Ways to Submit a Release Note": http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process Six Ways to Submit a Release Note These are in order of preference, starting with the best option: 1. Edit the content directly within the appropriate beat at http://fedoraproject.org/wiki/Docs/Beats. 2. Email relnotes at fedoraproject.org. 3. Add relnotes at fedoraproject.org as a Cc: in an existing bug report. 4. Change the fedora_requires_release_note flag on an existing Bugzilla entry to '+' (NEW) 5. Enter a new release note request, comment, etc. into this pre-filled bugzilla request (http://tinyurl.com/nej3u). 6. Include the *docs* keyword in your CVS commit log. [1] Kudos to Uli Drepper for finding and using this flag within three hours of it being added; thanks to Dave Lawrence for coming out of retirement to add the flag. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 Lam at Lam.pl Sat Feb 10 19:35:26 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 10 Feb 2007 20:35:26 +0100 Subject: Wakeup alarm? In-Reply-To: <200702100910.30331.jkeating@redhat.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <1171069764.19887.0.camel@hughsie-laptop> <20070210043742.GA1510752@hiwaay.net> <200702100910.30331.jkeating@redhat.com> Message-ID: <1171136126.9742.6.camel@pensja.lam.pl> Dnia 10-02-2007, sob o godzinie 09:10 -0500, Jesse Keating napisa?(a): > We have > to prompt you with how many you'll need so that you don't start the install > and get asked for a CD you didn't download/burn. No you don't. I haven't seen a multi-disk installation for a long time now. These days people either download single DVD or a "server CD". The prompt is useless when it requires just one disk (or an NFS/FTP directory). Also, is there a way in F7 Anaconda to click "no, I don't have the fourth CD, deselect the packages and their dependencies"? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From dcantrell at redhat.com Sat Feb 10 20:19:04 2007 From: dcantrell at redhat.com (David Cantrell) Date: Sat, 10 Feb 2007 15:19:04 -0500 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <45CC133A.8050902@redhat.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <45CC133A.8050902@redhat.com> Message-ID: <1171138744.3250.13.camel@mortise.boston.redhat.com> On Fri, 2007-02-09 at 01:22 -0500, Luke Macken wrote: > David Cantrell wrote: > > Announcing repoman > > ------------------ > > > > Repoman is a PyGTK frontend for configuring common and basic settings > > for yum. Specifically, it lets users enable and disable individual > > repos easily. Users can add and remove repositories as well. > > > > Repoman is not meant to expose all of yum's configuration settings in > > GUI form, but rather the common settings most users will care about. > > > > One of the interesting features is the Tracking page. Users can easily > > switch between stable (with or without updates) or development branches > > and repoman will enable and disable the correct repositories for the > > user. > > > > Repoman also offers a set of Python classes for reading and writing out > > /etc/yum.repos.d files. The core element is the RepoStanza, which are > > contained in RepoFiles, and all of those make up a Repos collection. > > > > This program is evolving a lot, so help testing and/or coding is > > appreciated. > > Nice work! > > Just nitpicking a bit; there is duplicate functionality with regard to > enabling a repository. I'd say just leave the checkbox on the > Repositories list and toss the one in the Edit window (which doesn't > seem to be working anyway). Chris and I were sort of torn on this issue. We decided to put the checkbox in the window anyway because it was also going to be used for the Add a New Repo window too. But that got changed later on. We'll play around with the UI a bit and fix that up. > Also, attached is a trivial patch to make repoman not explode when > ctrl+c'd from the command line. Thanks! Applied in repoman-0.6, which is available at: http://www.boston.burdell.org/repoman/ -- David Cantrell Red Hat / Westford, MA -------------- 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 mike at miketc.com Sat Feb 10 21:00:32 2007 From: mike at miketc.com (Mike Chambers) Date: Sat, 10 Feb 2007 15:00:32 -0600 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1171138744.3250.13.camel@mortise.boston.redhat.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <45CC133A.8050902@redhat.com> <1171138744.3250.13.camel@mortise.boston.redhat.com> Message-ID: <1171141232.3234.0.camel@scrappy.miketc.com> On Sat, 2007-02-10 at 15:19 -0500, David Cantrell wrote: > Applied in repoman-0.6, which is available at: > > http://www.boston.burdell.org/repoman/ I get this error (as well as last version) when trying to run repoman.. Component: Repository Manager Summary: TBdc86dff1 interface.py:70:__init__:AttributeError: 'NoneType' object has no attribute 'isEnabled' Traceback (most recent call last): File "/usr/sbin/repoman", line 31, in ui = RepoMan() File "/usr/lib/python2.5/site-packages/repoman/interface.py", line 522, in __init__ self.trackingPage = TrackingPage(self) File "/usr/lib/python2.5/site-packages/repoman/interface.py", line 70, in __init__ if self.repos.getStanzaByName("updates-testing").isEnabled(): AttributeError: 'NoneType' object has no attribute 'isEnabled' Local variables in innermost frame: interface: self: -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From jkeating at redhat.com Sat Feb 10 21:00:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Feb 2007 16:00:58 -0500 Subject: Wakeup alarm? In-Reply-To: <1171136126.9742.6.camel@pensja.lam.pl> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702100910.30331.jkeating@redhat.com> <1171136126.9742.6.camel@pensja.lam.pl> Message-ID: <200702101601.01438.jkeating@redhat.com> On Saturday 10 February 2007 14:35, Leszek Matok wrote: > No you don't. I haven't seen a multi-disk installation for a long time > now. These days people either download single DVD or a "server CD". The > prompt is useless when it requires just one disk (or an NFS/FTP > directory). Not everybody has DVD readers, and we may not have a single CD install set. > Also, is there a way in F7 Anaconda to click "no, I don't have the > fourth CD, deselect the packages and their dependencies"? You can hit cancel, go back and adjust your package selection. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mladen.kuntner at triera.net Sat Feb 10 22:03:12 2007 From: mladen.kuntner at triera.net (Mladen Kuntner) Date: Sat, 10 Feb 2007 23:03:12 +0100 Subject: F7 test1 x64 DVD install report Message-ID: <1171144992.2866.9.camel@cpe1-23-149.cable.triera.net> Hi. Sending a F7 test1 x64 DVD install report. Early in install there was an error like unable to find install media and window with drivers selection list. After few tries the right one was AMD PATA so i was able to continue installation. This is on Gigabyte nforce motherboard. lspci shows: 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2) Install and post install went ok. On first boot monitor (Hansol 900P) was not found so i had max resolution of 800x600. After ?yum install system-config-display ? i set monitor manually and can set resolution to 1600x1200. On turning printer (Samsung ML 1610 usb) there was a window to select printer but on ok nothing happened. After ?yum install system-config-printer? it was posible to install printer manually and is working ok. Usb memory stick works ok. lsusb shows Bus 002 Device 002: ID 0457:0151 Silicon Integrated Systems Corp. Super Flash 1GB Flash Drive No luck with Canon S1 IS digital camera. lsusb shows Bus 001 Device 002: ID 04a9:309c Canon, Inc. PowerShot S1 IS . On turning camera on there is gthumb's window to import photos but clicking on ok does nothing. I found that there is no disk device associated with camera created in /dev directory. (udev bug?) For memory stick: brw-r----- 1 root disk 8, 17 2007-02-10 22:01 sdb1 crw------- 1 root root 21, 2 2007-02-10 22:01 sg2 brw-r----- 1 root disk 8, 16 2007-02-10 22:01 sdb crw------- 1 root root 253, 7 2007-02-10 22:01 usbdev2.2_ep83 crw------- 1 root root 253, 6 2007-02-10 22:01 usbdev2.2_ep82 crw------- 1 root root 253, 5 2007-02-10 22:01 usbdev2.2_ep01 crw------- 1 root root 253, 4 2007-02-10 22:01 usbdev2.2_ep00 for camera: crw------- 1 root root 253, 11 2007-02-10 22:04 usbdev1.2_ep83 crw------- 1 root root 253, 10 2007-02-10 22:04 usbdev1.2_ep82 crw------- 1 root root 253, 9 2007-02-10 22:04 usbdev1.2_ep01 crw------- 1 root root 253, 8 2007-02-10 22:04 usbdev1.2_ep00 TV card AverMedia 007 FM works ok (no radio) lspci shows 01:08.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev d0) As usual after modprobe saa7134-alsa sox -q -c 2 -s -l -r 32000 -t ossdsp /dev/dsp1 -l -r 32000 -t ossdsp /dev/dsp & to get sound (is there a better way?) tvtime works ok. I was unable to get sound with gnomeradio (was ok in FC6). Video camera JVC GR DVL 157E firewire (not working) lsmod shows fw_ohci 23432 0 fw_core 45512 1 fw_ohci and there is, when i turn camera on crw------- 1 root root 252, 0 2007-02-10 22:35 fw1 in /dev but dvgrab is not working: raw1394 - failed to get handle: No such file or directory. I understand that it is new firewire stack in 2.6.20 kernels and it looks ok but what about user programs? This all on rawhide updated 10.2.2007 kernel 2.6.20-1.2922.fc7 #1 SMP mladen kuntner From dimi at lattica.com Sat Feb 10 23:05:44 2007 From: dimi at lattica.com (Dimi Paun) Date: Sat, 10 Feb 2007 18:05:44 -0500 (EST) Subject: Wakeup alarm? In-Reply-To: <200702101601.01438.jkeating@redhat.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702100910.30331.jkeating@redhat.com> <1171136126.9742.6.camel@pensja.lam.pl> <200702101601.01438.jkeating@redhat.com> Message-ID: <40208.74.96.19.63.1171148744.squirrel@lattica.com> On Sat, February 10, 2007 16:00, Jesse Keating wrote: > You can hit cancel, go back and adjust your package selection. And how to you know what to deselect? -- Dimi Paun Lattica, Inc. From mschwendt.tmp0701.nospam at arcor.de Sat Feb 10 23:06:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 11 Feb 2007 00:06:44 +0100 Subject: Understanding multi-lib conflicts in packages Message-ID: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> I have a *long* list of i386+x86_64 multi-lib package conflicts in Extras 7 here. If two packages (one i386, the other x86_64) of the same name are installed, which files can cause conflicts because no magic inside RPM takes care of overriding files like executables? Can %doc files cause a conflict? I assume include files can cause a conflict. I assume arch-independent data files can cause a conflict. I assume executables in bindir/sbindir'n'friends don't cause a conflict, because RPM lets the best arch win (or something like that, right?) A few examples. Are these false positives? ClanLib-devel - 0.8.0-3.fc6.i386 Conflicts: 2 File conflict in: /usr/share/doc/ClanLib-devel-0.8.0/html/Reference/html/global_index.html /usr/share/doc/ClanLib-devel-0.8.0/html/Reference/html/cross_index.html Packages with the same files: ClanLib-devel - 0.8.0-3.fc6.x86_64 ode-devel - 0.7-2.fc6.i386 Conflicts: 1 File conflict in: /usr/include/ode/config.h Packages with the same files: ode-devel - 0.7-2.fc6.x86_64 qt4-devel - 4.2.2-2.fc7.i386 Conflicts: 4 File conflict in: /usr/include/QtCore/qconfig.h /usr/include/Qt/qconfig.h /usr/share/qt4/mkspecs/common/g++.conf /usr/share/qt4/mkspecs/qconfig.pri Packages with the same files: qt4-devel - 4.2.2-2.fc7.x86_64 rekall - 2.4.5-5.fc7.3.i386 Conflicts: 9 File conflict in: /usr/bin/rekallqt /usr/bin/rkdcop /usr/share/apps/rekallqt/test/forms/forms Packages with the same files: rekall - 2.4.5-5.fc7.3.x86_64 From mclasen at redhat.com Sat Feb 10 23:27:59 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 10 Feb 2007 18:27:59 -0500 Subject: Understanding multi-lib conflicts in packages In-Reply-To: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45CE54FF.4070904@redhat.com> Michael Schwendt wrote: > I have a *long* list of i386+x86_64 multi-lib package conflicts in > Extras 7 here. > > If two packages (one i386, the other x86_64) of the same name > are installed, which files can cause conflicts because no magic > inside RPM takes care of overriding files like executables? > > Can %doc files cause a conflict? > Yes, this is a common form of multilib conflict, which often arises when documentation is generated at build time and the doc generator (e.g. gtk-doc or doxygen) embeds timestamps or some other random data in the generated docs. The easiest fix here is often to use pregenerated docs as separate source instead of generating the docs at build time. > I assume include files can cause a conflict. > Yes, quite a few libraries install config.h-alike headers which naturally cause conflicts. > I assume arch-independent data files can cause a conflict. > Only if they are generated at build time and include timestamps or other variable data. Identical files will not cause conflicts if they installed by arch-variants of the same package, AFAIK. > I assume executables in bindir/sbindir'n'friends don't cause > a conflict, because RPM lets the best arch win (or something like > that, right?) > Yes. But unfortunately, rpm has some mis-optimization in this area: if it sees that a binary will later be overwritten by an arch-variant of the same package, it does not bother to install the "wrong arch" binary in the first place. Unfortunately, that wreaks havoc with other packages that Requires(post) the package in order to use that very binary. We have seen cases like this with e.g. fc-cache and gtk-update-icon-cache in RHEL. Matthias From nicolas.mailhot at laposte.net Sat Feb 10 23:37:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Feb 2007 07:37:41 +0800 Subject: Default MTA for Fedora 7 In-Reply-To: <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> Message-ID: <45CE5745.1010901@laposte.net> Stephen John Smoogen a ?crit : > On 2/3/07, David Woodhouse wrote: >> Not exactly. It's how the dependencies got fulfilled. >> >> It's probably a good thing though -- it _is_ a better choice because >> it's much easier to deal with and much more versatile than the other >> options; _especially_ than sendmail :) >> > > No its better because you like it more. I think you have been pushing > for this since at least 1999 (2000 for sure). > > Me I would like postfix :) It *is* way better than sendmail but it *do* like postfix better too. Someone has shamelessly used the fact exim was the MTA with the shortest name to sneak this big change in. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sat Feb 10 23:52:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Feb 2007 07:52:18 +0800 Subject: Default MTA for Fedora 7 In-Reply-To: <20070206180238.11d7a3ef@banea.int.addix.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702061030.43263.jkeating@redhat.com> <1170776244.10584.5.camel@hughsie-laptop> <200702061048.54302.jkeating@redhat.com> <20070206180238.11d7a3ef@banea.int.addix.net> Message-ID: <45CE5AB2.9080204@laposte.net> Ralf Ertzinger a ?crit : > Well, there certainly needs to be a way to tell users that one of their > hard disks is about to die. These things need to be moved to dbus with an optionnal dbus-to-sendmail remoter sink -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sat Feb 10 23:58:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Feb 2007 07:58:25 +0800 Subject: Default MTA for Fedora 7 In-Reply-To: <1170674703.29759.758.camel@pmac.infradead.org> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170587296.29759.634.camel@pmac.infradead.org> <200702050121.l151LeCH020289@laptop13.inf.utfsm.cl> <1170674703.29759.758.camel@pmac.infradead.org> Message-ID: <45CE5C21.9090301@laposte.net> David Woodhouse a ?crit : > I note you make no pretence at claiming Postfix can do these things; > only arguments that I shouldn't _want_ to And postfix has a nice modular secure design exim lacks. Now you tell us how to get it with exim. It's easy to pick up the strong point of one implemetation and declare it's obviously better then the others because of it (disregarding all other points) Note you can do greylisting with postfix, I happen not to use it, but any 5s postfix greylist googling will return lots of hits. -- Nicolas Mailhot From hughsient at gmail.com Sat Feb 10 23:58:40 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 10 Feb 2007 23:58:40 +0000 Subject: Default MTA for Fedora 7 In-Reply-To: <45CE5AB2.9080204@laposte.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <200702061030.43263.jkeating@redhat.com> <1170776244.10584.5.camel@hughsie-laptop> <200702061048.54302.jkeating@redhat.com> <20070206180238.11d7a3ef@banea.int.addix.net> <45CE5AB2.9080204@laposte.net> Message-ID: <1171151920.22738.0.camel@hughsie-laptop> On Sun, 2007-02-11 at 07:52 +0800, Nicolas Mailhot wrote: > These things need to be moved to dbus with an optionnal > dbus-to-sendmail > remoter sink Agree, then we can pop up a nice libnotify warning box for the desktop user just like we do when the battery is going to explode. Richard. From mschwendt.tmp0701.nospam at arcor.de Sun Feb 11 01:07:34 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 11 Feb 2007 02:07:34 +0100 Subject: Understanding multi-lib conflicts in packages In-Reply-To: <45CE54FF.4070904@redhat.com> References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> <45CE54FF.4070904@redhat.com> Message-ID: <20070211020734.20dd510e.mschwendt.tmp0701.nospam@arcor.de> On Sat, 10 Feb 2007 18:27:59 -0500, Matthias Clasen wrote: > > Can %doc files cause a conflict? > > > Yes, this is a common form of multilib conflict, which often arises when > documentation is generated at build time and the doc generator (e.g. gtk-doc > or doxygen) embeds timestamps or some other random data in the generated > docs. > > The easiest fix here is often to use pregenerated docs as separate source > instead of generating the docs at build time. That is a very inconvenient solution, however. > > I assume include files can cause a conflict. > > > Yes, quite a few libraries install config.h-alike headers which naturally > cause conflicts. My mail was phrased poorly. ;) I didn't mean to ask whether include files can differ between one arch and another. Surely they can. E.g. when they contain targetarch-dependent definitions, they can be difficult to fix for multi-lib. I want to ignore conflicting -devel packages as much as possible, since the -devel packages are optional. Having i386 and x86_64 headers installed in parallel is not a hard requirement. Library packages, on the contrary, can be pulled in as dependencies of a multi-compat application or another library. An i386 library (or "main" packages in general) should not conflict with its x86_64 counter-part because of %doc files, data files, or config files, for example. > > I assume arch-independent data files can cause a conflict. > > > Only if they are generated at build time and include timestamps or other > variable data. So, when RPM does not play any multi-lib tricks with files below %_datadir, there are several packages in Extras Devel which conflict because they contain arch-independent files which have different checksums on i386 compared with x86_64. From michel.salim at gmail.com Sun Feb 11 02:25:34 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 10 Feb 2007 21:25:34 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? Message-ID: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> SWT applications (Eclipse, Azureus) runs fine against Sun JDK 6 on Fedora Core 6; on Fedora 7, however, all of them produces a SIGSEGV with the last native frame being libgobject-2.0.so.0. The last frame on the Java stack is org.eclipse.swt.internal.gtk.OS._gtk_init_check I'd submit this to Sun, but it's probably better if one of Fedora's Java developer were to do this instead, since they'd have a better idea what might be causing this? Thanks, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From michel.salim at gmail.com Sun Feb 11 02:33:53 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 10 Feb 2007 21:33:53 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> Message-ID: <883cfe6d0702101833h612ebed0x5d82a4269793db30@mail.gmail.com> Correction: this only applies to running against the 64-bit JVM. Running 32-bit SWT apps on top of the 32-bit JVM works fine. 2007/2/10, Michel Salim : > SWT applications (Eclipse, Azureus) runs fine against Sun JDK 6 on > Fedora Core 6; on Fedora 7, however, all of them produces a SIGSEGV > with the last native frame being libgobject-2.0.so.0. The last frame > on the Java stack is org.eclipse.swt.internal.gtk.OS._gtk_init_check > > I'd submit this to Sun, but it's probably better if one of Fedora's > Java developer were to do this instead, since they'd have a better > idea what might be causing this? > > Thanks, > > -- > Michel Salim > http://hircus.wordpress.com/ > > My theology, briefly, is that the universe was dictated but not signed. > -- Christopher Morley > -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From rdieter at math.unl.edu Sun Feb 11 04:29:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 10 Feb 2007 22:29:10 -0600 Subject: Understanding multi-lib conflicts in packages In-Reply-To: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > I have a *long* list of i386+x86_64 multi-lib package conflicts in > Extras 7 here. Thanks, good work. > qt4-devel - 4.2.2-2.fc7.i386 > Conflicts: 4 > File conflict in: > /usr/include/QtCore/qconfig.h > /usr/include/Qt/qconfig.h > /usr/share/qt4/mkspecs/common/g++.conf > /usr/share/qt4/mkspecs/qconfig.pri > Packages with the same files: > qt4-devel - 4.2.2-2.fc7.x86_64 FYI, issue being tracked at http://bugzilla.redhat.com/223663 -- Rex From jwilliam at xmission.com Sun Feb 11 06:24:26 2007 From: jwilliam at xmission.com (Jerry Williams) Date: Sat, 10 Feb 2007 23:24:26 -0700 Subject: Wakeup alarm? In-Reply-To: <000301c74caf$6cb0eab0$020aa8c0@a18> References: <000301c74caf$6cb0eab0$020aa8c0@a18> Message-ID: <000001c74da5$47829030$020aa8c0@a18> > Can I get a beep on the screen that says click next to do the > installation? It beeps at you to reboot, so the code is already there. Can I just get a beep to tell me that I need to click next? Then you can figure out a better fix later. From jspaleta at gmail.com Sun Feb 11 06:35:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 Feb 2007 21:35:31 -0900 Subject: For your dining pleasure.. i give you experimental packages of usbsink Message-ID: <604aa7910702102235q4fd3331eude71c3e40e850897@mail.gmail.com> Good Alaskan Evening! I have produced a set of packages and a package review request for usbsink. I thought I'd let everyone on the list know about it.. because I think this is actually pretty super keen, and I think a lot of people might want to try it out and see how well it works. If a lot of people find it useful, perhaps it will be useful enough to think about as an f7 or later desktop 'feature' for a default desktop install. I make no such claim yet...but I see this application's..potential.. since its one of the rare applications I ask my wife about which illicts a response like 'oooooh that would be handy.' -jef"Because my wife has a far better feel for the pulse of mainstream desktop users than I..she keeps her desktop effects turned on..and I cringe at the sight of the wasted gpu cycles"spaleta References: http://usbsink.sourceforge.net/ USBSink is a GNOME program for automatic file synchronization over USB. It is designed for users of removable drives, such as flash drives or external hard disks. In USBSink you define a task associated to a particular USB drive, and then have a complete automation of data trasfers. With file monitoring and hardware detection features, USBSink is able to respond and act according to relevant events on the desktop. Experimental Package Location: http://jspaleta.thecodergeek.com/Fedora%20SRPMS/usbsink/ binaries for fe6 and fe-development are available Review Request Ticket: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228188 From opensource at till.name Sun Feb 11 13:52:54 2007 From: opensource at till.name (Till Maas) Date: Sun, 11 Feb 2007 14:52:54 +0100 Subject: Is there a NFS alternative? In-Reply-To: <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> Message-ID: <200702111453.13491.opensource@till.name> On Thursday 08 February 2007 01:02, Daniel Yek wrote: > I am hoping for a secure solution to mount directories "shared out" from my > other computer located remotely over the Internet. So that I can edit > source files and execute programs "locally" and compile remotely (a much > faster machine). > Is NFS(4) still the best (and easiest-to-use?) solution? As someone else suggested, try fuse-sshfs, with sshfs remotehosts: /mnt/remotehome you can mount your remote home directory to /mnt/remotehome and with fusermount -u /mnt/remotehome you can umount it. Nothing more than a unprivileged ssh account on the remote machine and fuse-sshfs on the local machine and a user in the fuse group is required. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Feb 11 15:14:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 11 Feb 2007 10:14:30 -0500 Subject: Wakeup alarm? In-Reply-To: <40208.74.96.19.63.1171148744.squirrel@lattica.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702101601.01438.jkeating@redhat.com> <40208.74.96.19.63.1171148744.squirrel@lattica.com> Message-ID: <200702111014.38454.jkeating@redhat.com> On Saturday 10 February 2007 18:05, Dimi Paun wrote: > And how to you know what to deselect? You don't really, we don't indicate what packages are on which media. Maybe we should, but doesn't help when the package is on say media 1, but the deps of it which aren't visibly listed are on media 4. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Lam at Lam.pl Sun Feb 11 15:30:59 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 11 Feb 2007 16:30:59 +0100 Subject: Wakeup alarm? In-Reply-To: <200702111014.38454.jkeating@redhat.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702101601.01438.jkeating@redhat.com> <40208.74.96.19.63.1171148744.squirrel@lattica.com> <200702111014.38454.jkeating@redhat.com> Message-ID: <1171207859.3864.11.camel@pensja.lam.pl> Dnia 11-02-2007, nie o godzinie 10:14 -0500, Jesse Keating napisa?(a): > You don't really, we don't indicate what packages are on which media. Maybe > we should, but doesn't help when the package is on say media 1, but the deps > of it which aren't visibly listed are on media 4. That's why I said "deselect the packages and their dependencies". That's also why I said that the "confirm CD list" step is useless - it's faster to download the complete set (or run minimal install) than to guess or somehow experimentally get to the packages you need to deselect. Another method I've seen in an installer of some other distro is a list of media that I have. That would be one more step before package selection, which could also take an updates CD, some "extras" CD, drivers CD or any other yum repo. Then we could install anything from anywhere, provided we have the media available. I understand adding any yum repo upon installation is not trivial (it can be inconsistent by itself, it can be conflicting with our packages and so on), but if we start from the media selection, it's a step forward. Also, that way, there's no need to ask the user to stay at the keyboard only to press "Next" after a very long depsolving, which this thread is all about. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From overholt at redhat.com Sun Feb 11 15:29:31 2007 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 11 Feb 2007 10:29:31 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <883cfe6d0702101833h612ebed0x5d82a4269793db30@mail.gmail.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <883cfe6d0702101833h612ebed0x5d82a4269793db30@mail.gmail.com> Message-ID: <20070211152930.GA29324@redhat.com> * Michel Salim [2007-02-10 21:34]: > Correction: this only applies to running against the 64-bit JVM. > Running 32-bit SWT apps on top of the 32-bit JVM works fine. Running the 64-bit SWT package against the 64-bit JVM or the 32-bit SWT package against the 64-bit JVM? Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michel.salim at gmail.com Sun Feb 11 16:34:28 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 11 Feb 2007 11:34:28 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <20070211152930.GA29324@redhat.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <883cfe6d0702101833h612ebed0x5d82a4269793db30@mail.gmail.com> <20070211152930.GA29324@redhat.com> Message-ID: <883cfe6d0702110834i74be88d0y3bf8063e68bdbe44@mail.gmail.com> 2007/2/11, Andrew Overholt : > * Michel Salim [2007-02-10 21:34]: > > Correction: this only applies to running against the 64-bit JVM. > > Running 32-bit SWT apps on top of the 32-bit JVM works fine. > > Running the 64-bit SWT package against the 64-bit JVM or the 32-bit SWT > package against the 64-bit JVM? > 64-bit SWT package against 64-bit JVM (tried with the latest Eclipse and Azureus) Thanks, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From dimi at lattica.com Sun Feb 11 16:34:27 2007 From: dimi at lattica.com (Dimi Paun) Date: Sun, 11 Feb 2007 11:34:27 -0500 (EST) Subject: Wakeup alarm? In-Reply-To: <200702111014.38454.jkeating@redhat.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702101601.01438.jkeating@redhat.com> <40208.74.96.19.63.1171148744.squirrel@lattica.com> <200702111014.38454.jkeating@redhat.com> Message-ID: <41369.74.96.19.63.1171211667.squirrel@lattica.com> On Sun, February 11, 2007 10:14, Jesse Keating wrote: > On Saturday 10 February 2007 18:05, Dimi Paun wrote: >> And how to you know what to deselect? > > You don't really, we don't indicate what packages are on which media. Maybe > we should, but doesn't help when the package is on say media 1, but the deps > of it which aren't visibly listed are on media 4. Right. Which is why I think it's not fair to answer that the solution is to "go back and deselect the packages". It's just not something that people can do. -- Dimi Paun Lattica, Inc. From cmadams at hiwaay.net Sun Feb 11 18:33:29 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 11 Feb 2007 12:33:29 -0600 Subject: Wakeup alarm? In-Reply-To: <41369.74.96.19.63.1171211667.squirrel@lattica.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702101601.01438.jkeating@redhat.com> <40208.74.96.19.63.1171148744.squirrel@lattica.com> <200702111014.38454.jkeating@redhat.com> <41369.74.96.19.63.1171211667.squirrel@lattica.com> Message-ID: <20070211183329.GC1145885@hiwaay.net> Once upon a time, Dimi Paun said: > On Sun, February 11, 2007 10:14, Jesse Keating wrote: > > On Saturday 10 February 2007 18:05, Dimi Paun wrote: > >> And how to you know what to deselect? > > > > You don't really, we don't indicate what packages are on which media. Maybe > > we should, but doesn't help when the package is on say media 1, but the deps > > of it which aren't visibly listed are on media 4. > > Right. Which is why I think it's not fair to answer that the > solution is to "go back and deselect the packages". It's just not > something that people can do. If anaconda doesn't check which CDs will be required, users will get stuck half way through installation without a required CD. Right now, the only real solution at the CD check is to quit (before starting the actual install), but that is MUCH better than getting half way through install and aborting (probably leaving a mess). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From lsof at nodata.co.uk Sun Feb 11 22:56:00 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 11 Feb 2007 23:56:00 +0100 Subject: Default MTA for Fedora 7 In-Reply-To: <45CE5745.1010901@laposte.net> References: <20070203170431.GA5658@nostromo.devel.redhat.com> <1170529246.29759.571.camel@pmac.infradead.org> <80d7e4090702031253x5260bb6bo9fe0b7e857f9f7ee@mail.gmail.com> <45CE5745.1010901@laposte.net> Message-ID: <1171234560.3193.11.camel@localhost.localdomain> Am Sonntag, den 11.02.2007, 07:37 +0800 schrieb Nicolas Mailhot: > Stephen John Smoogen a ?crit : > > On 2/3/07, David Woodhouse wrote: > >> Not exactly. It's how the dependencies got fulfilled. > >> > >> It's probably a good thing though -- it _is_ a better choice because > >> it's much easier to deal with and much more versatile than the other > >> options; _especially_ than sendmail :) > >> > > > > No its better because you like it more. I think you have been pushing > > for this since at least 1999 (2000 for sure). > > > > Me I would like postfix :) Me too. Very clean. Sendmail X has a very similar design to Postfix. Not looked at it for a while though. > > It *is* way better than sendmail but it *do* like postfix better too. > Someone has shamelessly used the fact exim was the MTA with the shortest > name to sneak this big change in. Yes. Imagine if RHEL was to switch the default MTA to Exim "because it has the shortest name". Customers would laugh. Fedora doesn't deserve the switch either. (Is this seriously being considered?) > > > -- > Nicolas Mailhot > From wart at kobold.org Sun Feb 11 23:43:06 2007 From: wart at kobold.org (Wart) Date: Sun, 11 Feb 2007 15:43:06 -0800 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1171007057.45cc26511a668@imp.free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> <45CB9C48.6000406@free.fr> <45CB9ED1.6000307@kobold.org> <1171007057.45cc26511a668@imp.free.fr> Message-ID: <45CFAA0A.3060409@kobold.org> jfontain at free.fr wrote: > Quoting Michael Thomas : > >> Jean-Luc Fontaine wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Michael Thomas wrote: >>>> Kevin Kofler wrote: >>>>> Jean-Luc Fontaine free.fr> writes: >>>>>> Well, then there's gonna be a big problem with blt (now in extras, a >>>>>> graphical library) which is far from ready to compile against >>>>>> tcl-8.5, >>>>> The strange thing is that it doesn't show up in the "broken >>>>> dependencies" list, so RPM thinks the version built against 8.4 is >>>>> still going to run (there's no dependency on the versioned soname). >>>>> I don't know whether that's true. >>>> It's likely compiled against the Tcl stubs library, >>> blt certainly is not: would you be willing to try to make it work? >>> (like I mentioned before, I cannot do it). >>> But be advised that the blt CVS does not even compile... >> Yes, I'm willing to work on it. I maintain almost 20 other Tcl >> extensions, so I wouldn't be surprised to run into the same problems in >> multiple places. > > Great! Of course I will be helping testing it. I was able to get BLT to build and load against tcl 8.5a5 using this patch, but haven't done any other testing. Can you try it out and see if there are any runtime problems? http://www.kobold.org/~wart/fedora/blt-2.4z-tcl85.patch binary and src rpms for testing: http://www.kobold.org/~wart/fedora/blt-2.4-15.z.fc7.1.i386.rpm http://www.kobold.org/~wart/fedora/blt-2.4-15.z.fc7.1.src.rpm --Wart From jwilliam at xmission.com Mon Feb 12 00:10:24 2007 From: jwilliam at xmission.com (Jerry Williams) Date: Sun, 11 Feb 2007 17:10:24 -0700 Subject: Wakeup alarm? In-Reply-To: <20070211183329.GC1145885@hiwaay.net> References: <000301c74caf$6cb0eab0$020aa8c0@a18><200702101601.01438.jkeating@redhat.com><40208.74.96.19.63.1171148744.squirrel@lattica.com><200702111014.38454.jkeating@redhat.com><41369.74.96.19.63.1171211667.squirrel@lattica.com> <20070211183329.GC1145885@hiwaay.net> Message-ID: <002801c74e3a$320bc3d0$020aa8c0@a18> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Chris Adams > Sent: Sunday, February 11, 2007 11:33 AM > To: Development discussions related to Fedora Core > Subject: Re: Wakeup alarm? > > Once upon a time, Dimi Paun said: > > On Sun, February 11, 2007 10:14, Jesse Keating wrote: > > > On Saturday 10 February 2007 18:05, Dimi Paun wrote: > > >> And how to you know what to deselect? > > > > > > You don't really, we don't indicate what packages are on which media. > Maybe > > > we should, but doesn't help when the package is on say media 1, but > the deps > > > of it which aren't visibly listed are on media 4. > > > > Right. Which is why I think it's not fair to answer that the > > solution is to "go back and deselect the packages". It's just not > > something that people can do. > > If anaconda doesn't check which CDs will be required, users will get > stuck half way through installation without a required CD. Right now, > the only real solution at the CD check is to quit (before starting the > actual install), but that is MUCH better than getting half way through > install and aborting (probably leaving a mess). This is something that I have run into. It seems like the install is an all or nothing install. It seems like all of the tools like pirut and system-install-packages both need XWindows. If my install fails and I am left with just command line how do I finish getting things installed? It seems like the last thing that happens is the grub install. Seems to me that it would be better to get the base installed and working. Then if something doesn't work you still have a system that does. Is there a command line or tools that allow for something like: system-install-packages "GNOME Desktop Environment" that doesn't require a GUI? Also when I install on a machine with Windows Grub lets me add that to my list of things I can boot from. But if I already have grub installed it doesn't seem to allow me to add it's configuration to the new one. I have been trying to be able to boot Fedora Core 5, Fedora Core 6 and Fedora 7 all on the same machine. It works, just that it requires a manual process. Can't grub or the installer see that grub is there and copy the current configuration to the new one or ask me if I want to? I must have a flaky DVD drive, media passes the test, but some times install will fail at different places. FC5 chokes, FC6 will at least let you retry. So things are getting better. Thanks to everyone for their help! Jerry Williams From pemboa at gmail.com Mon Feb 12 01:40:20 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 12 Feb 2007 19:40:20 +1800 Subject: Wakeup alarm? In-Reply-To: <200702100910.30331.jkeating@redhat.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <1171069764.19887.0.camel@hughsie-laptop> <20070210043742.GA1510752@hiwaay.net> <200702100910.30331.jkeating@redhat.com> Message-ID: <16de708d0702111740o7c1ca7em84626c95a3ec5bc1@mail.gmail.com> On 2/11/07, Jesse Keating wrote: > On Friday 09 February 2007 23:37, Chris Adams wrote: > > I haven't looked at the anaconda source, but the process is package > > selection -> dependency checking -> ask ok to install. What if > > dependency checking fails for some reason? It may not be done asking > > questions at that stage. > > Also we don't know how many CDs you'll need before doing depchecking. We have > to prompt you with how many you'll need so that you don't start the install > and get asked for a CD you didn't download/burn. So at by that stage of the installtion Anaconda doesn't know if it is doing a DVD install or network install or multi disk install? > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Fedora Core 6 and proud From dyek at real.com Mon Feb 12 03:24:16 2007 From: dyek at real.com (Daniel Yek) Date: Sun, 11 Feb 2007 19:24:16 -0800 Subject: fuse-sshfs; was Re: Is there a NFS alternative? In-Reply-To: <200702111453.13491.opensource@till.name> References: <6.2.1.2.2.20070207122008.227ad960@mailone.real.com> <16de708d0702071252j5a19d3fdp3395d12e4b288bdb@mail.gmail.com> <6.2.1.2.2.20070207152600.24543eb0@mailone.real.com> <200702111453.13491.opensource@till.name> Message-ID: <6.2.1.2.2.20070211190902.32b6aeb0@mailone.real.com> At 05:52 AM 2/11/2007, Till Maas wrote: >On Thursday 08 February 2007 01:02, Daniel Yek wrote: > > > I am hoping for a secure solution to mount directories "shared out" from my > > other computer located remotely over the Internet. So that I can edit > > source files and execute programs "locally" and compile remotely (a much > > faster machine). > > > Is NFS(4) still the best (and easiest-to-use?) solution? > >As someone else suggested, try fuse-sshfs, with > >sshfs remotehosts: /mnt/remotehome > >you can mount your remote home directory to /mnt/remotehome and with > >fusermount -u /mnt/remotehome > >you can umount it. Nothing more than a unprivileged ssh account on the remote >machine and fuse-sshfs on the local machine and a user in the fuse group is >required. > >Regards, >Till I have been using fuse-sshfs for a few days now. It is something good to know and I'm still using it, but it fell short in 2 aspects so far: 1. While saving over the Internet each time I habitually save a text file isn't too bad, executing a program in the fuse-sshfs mounted directory is unbearable. It took my program a warping 4 minutes to "download" and execute. Worst, everytime the program reload a DSO file, the DSO file is "downloaded" over the Internet again (and again.) Caching is very much inadequate. I can use rsync over a small directory hierarchy to workaround this problem though (still not exactly convenient enough to be transparent). 2. Whenever I lose my ssh connection due to some timeout problem, it was such a hassle to quit all text editors (so that no process has a handle to a fuse-sshfs mounted subdirectory, I think,) and remount the directory. Remounting shouldn't require unmounting or quiting text editors. Thanks for all feedback. They are very useful. -- Daniel Yek From jspaleta at gmail.com Mon Feb 12 04:18:59 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 11 Feb 2007 19:18:59 -0900 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <200702090932.44205.jkeating@redhat.com> References: <1170748677.45c8350535560@imp.free.fr> <200702090804.23196.jkeating@redhat.com> <20070209133458.GN3334@angus.ind.WPI.EDU> <200702090932.44205.jkeating@redhat.com> Message-ID: <604aa7910702112018h636b0b91k2957dd28d3dd47f1@mail.gmail.com> On 2/9/07, Jesse Keating wrote: > There has been some discussion on this lately, and many feel that introducing > some epochs is better than having broken upgrade paths. As to which point we > make the cut off and say no more broken upgrades has yet to be decided. > Choices are Test1, Test2, or Test3. I'm somewhat in favor of Test3. I would agree with your personal opinion about Test3 for the point of enforcement for upgrade path stablization. Anything ealier than that is an unrealistic policy made of rainbows and puppydog tails considering the actual process of how rawhide is turned into a final release. There must be adequate time where upgrade path breakage, while frowned on, is allowed as a necessary evil, during which time we take stock of where each upstream codebase is at, and allow time for package rollbacks without the undue burden of upgrade path calculations. This sort of crap sure as hell better happen during the test2 process... so that by test3 we can start nailing down the specific issue of upgrade paths coherently. -jef"and by we.. i mean the people who care about upgrade paths...i don't have to care.. because I have a time machine and I'm always running a future version of fedora that doesn't actual exist yet"spaleta From wart at kobold.org Mon Feb 12 04:24:21 2007 From: wart at kobold.org (Wart) Date: Sun, 11 Feb 2007 20:24:21 -0800 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <1171010300.45cc32fc9eef1@imp.free.fr> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> <45CB9C48.6000406@free.fr> <45CB9ED1.6000307@kobold.org> <1171010300.45cc32fc9eef1@imp.free.fr> Message-ID: <45CFEBF5.4060808@kobold.org> jfontain at free.fr wrote: > Quoting Michael Thomas : > > >> Yes, I'm willing to work on it. I maintain almost 20 other Tcl >> extensions, so I wouldn't be surprised to run into the same problems in >> multiple places. > > And thank you very much indeed for your work. Please let us know how your > packages go against tcl 8.5 alpha so we can decide whether to stick with 8.4.14 > or not. I've noticed a couple of things, none of which seem very major: - Packages built against the Tcl stub library don't load properly with Tcl 8.5a5. They need to be rebuilt (BLT, itcl/itk) - If the package version declared in pkgIndex.tcl does not match the version from the 'package provide' statement in the .tcl file providing the package, then 'package require foo' will fail. Under Tcl 8.4, this situation would silently succeed. Of course, if the version in pkgIndex.tcl doesn't match the version in the actual .tcl file, then it's a bug that should be fixed anyway (tclsoap, tclxml) - tk8.5a5 purportedly includes the tile extension, so that won't have to be maintained as a separate extension anymore. ditto for tcldict being included in tcl 8.5a5. - tbcload, and likely the tclpro compiler, haven't been updated with the bytecode changes in Tcl 8.5. It's unclear if this will ever happen, unfortunately, due to lack of effort. This doesn't seem to affect the tclpro debugger and syntax checker, so it may not be much of a loss. There may be other runtime issues that we haven't discovered yet, but I think we ought to proceed with tcl 8.5a5 for now to help uncover and fix them so that we can have this long awaited Tcl update for F7. --Wart From pmatilai at laiskiainen.org Mon Feb 12 07:04:55 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 12 Feb 2007 09:04:55 +0200 (EET) Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1171141232.3234.0.camel@scrappy.miketc.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <45CC133A.8050902@redhat.com> <1171138744.3250.13.camel@mortise.boston.redhat.com> <1171141232.3234.0.camel@scrappy.miketc.com> Message-ID: On Sat, 10 Feb 2007, Mike Chambers wrote: > On Sat, 2007-02-10 at 15:19 -0500, David Cantrell wrote: > >> Applied in repoman-0.6, which is available at: >> >> http://www.boston.burdell.org/repoman/ > > I get this error (as well as last version) when trying to run repoman.. > > Component: Repository Manager > Summary: TBdc86dff1 interface.py:70:__init__:AttributeError: 'NoneType' > object has no attribute 'isEnabled' > > Traceback (most recent call last): > File "/usr/sbin/repoman", line 31, in > ui = RepoMan() > File "/usr/lib/python2.5/site-packages/repoman/interface.py", line > 522, in __init__ > self.trackingPage = TrackingPage(self) > File "/usr/lib/python2.5/site-packages/repoman/interface.py", line 70, > in __init__ > if self.repos.getStanzaByName("updates-testing").isEnabled(): > AttributeError: 'NoneType' object has no attribute 'isEnabled' > > Local variables in innermost frame: > interface: > self: I saw this too - repoman (at the moment) only works if you have the default Fedora repository setup on your system. If the idea is to have a Fedora-specific tool I think it should be called fedora-repoman or something like that to indicate it's really distro-specific. - Panu - From pekkas at netcore.fi Mon Feb 12 07:35:18 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 12 Feb 2007 09:35:18 +0200 (EET) Subject: WLAN: link must be UP before ESSID is set In-Reply-To: <1170859128.3191.4.camel@localhost.localdomain> References: <1170859128.3191.4.camel@localhost.localdomain> Message-ID: Filed as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228253 On Wed, 7 Feb 2007, Baris Cicek wrote: > I'm using zd1211rw device and bringing interface up before setting ESSID > and KEY for wireless device did not cause any problem for me using > different hardware as well. > > That was not an issue with vendor driver, but it's necessary to bring > interface up for rewrite of the driver. Thus, I was not sure if this > related with driver or the network-scripts. > > But considering zd1211rw is included with kernel, it's evident that > without necessary changes on ifup-wireless it's not possible to > automatically bring interface into running state. > > If someone states a bug id, i can submit my change(s). > > On Tue, 2007-02-06 at 22:04 +0200, Pekka Savola wrote: >> Hi, >> >> On new USB stick WLAN interface (driver zd1211rw) it seems that the >> 'ip link set $DEVICE up' needs to be done before ESSID is set for the >> card to come up at all. (On the other hand, for example, the old >> orinoco_cs doesn't require this.) >> >> Even though DHCP client (run after ESSID is set) brings up the link, >> the WLAN card is not associated to the AP (the state as shown below), >> and IP doesn't work yet. >> >> zd1211rw people had the opinion that this is a problem with ifup: >> >> "This is a distro bug - it should bring the interface up before using >> it. Many drivers require the interface to be up before scanning is >> possible, since for a lot of hardware, scanning is just transmission >> and reception of frames so requires the entire MAC layer to be >> activated just the same as if you were transmitting/receiving data." >> >> Should this be fixed by setting the link up before setting ESSID in >> ifup-wireless (or even before setting some other iwconfig options)? >> >> Is there any drawback in doing so? (At least it seems to me that you >> may not be able to specify a new MACADDR if this was done.) >> >> Is there already a bug report on this (based on very quick search I >> couldn't find one)? >> >> eth1 IEEE 802.11b/g ESSID:"S" Nickname:"zd1211" >> Mode:Managed Frequency:2.412 GHz Access Point: Invalid >> Bit Rate=1 Mb/s >> Encryption key:off >> Link Quality:0 Signal level:0 Noise level:0 >> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 >> Tx excessive retries:0 Invalid misc:0 Missed beacon:0 >> >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From giallu at gmail.com Mon Feb 12 09:00:19 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 12 Feb 2007 10:00:19 +0100 Subject: libXft.so.1 Message-ID: Hi all, I have here a legacy application linked to libXft.so.1 but, unless I'm blind or something, it is nowhere to be found in FC6. Is there any compat- package available/planned? Cheers Gianluca From to.tonton at gmail.com Mon Feb 12 09:09:32 2007 From: to.tonton at gmail.com (Tonton) Date: Mon, 12 Feb 2007 10:09:32 +0100 Subject: does i810 bug on 3d ? Message-ID: <41649c240702120109u4b33b5b4id386eddfdfaa74e0@mail.gmail.com> hello i use asus vintage2-ph1 chip i945 gmch with fedora core 6 up to date there is an on board intel video card but i have trouble for 3d ! only one head and no resolution trouble problem for Doom3 google earth chess3d and rendering alert in blender iuse 32bit version on celeronD, on x86_64 can not switch off hang when killing Xserver in glxinfo this alert libGL warning: 3D driver claims to not support visual 0x5b and in Xorg.0log these warnings I810(0): Bad V_BIOS checksum I810(0): Unable to estimate virtual size (II) I810(0): initializing int10 (WW) I810(0): Bad V_BIOS checksum WW) I810(0): Extended BIOS function 0x5f05 not supported. (WW) I810(0): Extended BIOS function 0x5f05 not supported. (II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method. (II) I810(0): Setting refresh with VBE 3 method. (WW) I810(0): Extended BIOS function 0x5f28 not supported. (WW) AIGLX: 3D driver claims to not support visual 0x23 (WW) AIGLX: 3D driver claims to not support visual 0x24 (WW) AIGLX: 3D driver claims to not support visual 0x25 (WW) AIGLX: 3D driver claims to not support visual 0x26 (WW) AIGLX: 3D driver claims to not support visual 0x27 (WW) AIGLX: 3D driver claims to not support visual 0x28 (WW) AIGLX: 3D driver claims to not support visual 0x29 (WW) AIGLX: 3D driver claims to not support visual 0x2a (WW) AIGLX: 3D driver claims to not support visual 0x2b (WW) AIGLX: 3D driver claims to not support visual 0x2c (WW) AIGLX: 3D driver claims to not support visual 0x2d (WW) AIGLX: 3D driver claims to not support visual 0x2e (WW) AIGLX: 3D driver claims to not support visual 0x2f (WW) AIGLX: 3D driver claims to not support visual 0x30 (WW) AIGLX: 3D driver claims to not support visual 0x31 (WW) AIGLX: 3D driver claims to not support visual 0x32 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Mon Feb 12 10:04:59 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 05:04:59 -0500 Subject: Creating a jackuser group In-Reply-To: References: <1170790351.3564.12.camel@localhost.localdomain> <1170807189.3564.75.camel@localhost.localdomain> Message-ID: <20070212100459.GB871@devserv.devel.redhat.com> On Wed, Feb 07, 2007 at 03:02:06PM -0600, Jason L Tibbitts III wrote: > Pulseaudio? CD writing has in the past wanted the priority boost, but > probably not the mlock limit adjustement (although perhaps it wouldn't > hurt). CD writing has needed neither (on Linux at least) in the real world for most of the past ten years. I/O subsystems and machines have improved far beyond trying to sustain streaming I/O off disk to CD being "hard". cdrecord does try and make the problem worse by turning off burnproof but thats a problem with cdrecord that is only fixable now people are actively forking it From alan at redhat.com Mon Feb 12 10:10:22 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 05:10:22 -0500 Subject: Creating a jackuser group In-Reply-To: <1170889943.3759.16.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> <1170889943.3759.16.camel@localhost.localdomain> Message-ID: <20070212101022.GC871@devserv.devel.redhat.com> On Wed, Feb 07, 2007 at 03:12:23PM -0800, Anthony Green wrote: > We don't even approach this with Fedora. jackd will refuse to start > from qjackctl if you don't have the permissions set up properly. Then perhaps we shouldn't be using jack until they fix that ? From alan at redhat.com Mon Feb 12 10:17:00 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Feb 2007 05:17:00 -0500 Subject: rawhide report: 20070207 changes In-Reply-To: <1170924263.4059.1.camel@hughsie-laptop> References: <200702071123.l17BNFFt007909@hs20-bc2-6.build.redhat.com> <1170874089.30879.6.camel@hughsie-laptop> <1170879224.3315.11.camel@zelda.fubar.dk> <200702071524.08122.jkeating@redhat.com> <1170880209.3315.22.camel@zelda.fubar.dk> <1170920999.8675.29.camel@laptopd505.fenrus.org> <1170924263.4059.1.camel@hughsie-laptop> Message-ID: <20070212101700.GD871@devserv.devel.redhat.com> On Thu, Feb 08, 2007 at 08:44:23AM +0000, Richard Hughes wrote: > > The kernel provides a unified backlight API now, adding more private > > hacks rather than moving them to the unified API sounds like a step > > backwards to me .. > > I don't think smbios can be moved into the backlight kernel class as the > libsmbios library is written in C++ (IIRC) and is pretty huge. So the library needs replacing with something that is maintainable and works, in which case the argument applies even more strongly. From paul at city-fan.org Mon Feb 12 10:21:18 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 12 Feb 2007 10:21:18 +0000 Subject: Wakeup alarm? In-Reply-To: <002801c74e3a$320bc3d0$020aa8c0@a18> References: <000301c74caf$6cb0eab0$020aa8c0@a18><200702101601.01438.jkeating@redhat.com><40208.74.96.19.63.1171148744.squirrel@lattica.com><200702111014.38454.jkeating@redhat.com><41369.74.96.19.63.1171211667.squirrel@lattica.com> <20070211183329.GC1145885@hiwaay.net> <002801c74e3a$320bc3d0$020aa8c0@a18> Message-ID: <45D03F9E.5060403@city-fan.org> Jerry Williams wrote: > This is something that I have run into. It seems like the install is an all > or nothing install. It seems like all of the tools like pirut and > system-install-packages both need XWindows. If my install fails and I am > left with just command line how do I finish getting things installed? It > seems like the last thing that happens is the grub install. Seems to me > that it would be better to get the base installed and working. Then if > something doesn't work you still have a system that does. +1 > Is there a > command line or tools that allow for something like: > system-install-packages "GNOME Desktop Environment" > that doesn't require a GUI? # yum groupinstall "GNOME Desktop Environment" Paul. From jfontain at free.fr Mon Feb 12 10:55:19 2007 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Mon, 12 Feb 2007 11:55:19 +0100 Subject: tcl 8.5 alpha in fedora 7? In-Reply-To: <45CFAA0A.3060409@kobold.org> References: <1170748677.45c8350535560@imp.free.fr> <45C8C617.7000607@kobold.org> <45C8FC39.1030100@free.fr> <45CB934F.8020600@kobold.org> <45CB9C48.6000406@free.fr> <45CB9ED1.6000307@kobold.org> <1171007057.45cc26511a668@imp.free.fr> <45CFAA0A.3060409@kobold.org> Message-ID: <45D04797.4000605@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wart wrote: > > I was able to get BLT to build and load against tcl 8.5a5 using this > patch, but haven't done any other testing. Can you try it out and > see if there are any runtime problems? > > http://www.kobold.org/~wart/fedora/blt-2.4z-tcl85.patch > > binary and src rpms for testing: > > http://www.kobold.org/~wart/fedora/blt-2.4-15.z.fc7.1.i386.rpm > http://www.kobold.org/~wart/fedora/blt-2.4-15.z.fc7.1.src.rpm Thanks! Immediate problems: - - I don't seem to have anti-aliasing and $ tclsh % package require Tk 8.5a5 % load /usr/lib/blt2.4/libBLT24.so version conflict for package "Tk": have 8.5a5, need 8.5 - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF0EeXkG/MMvcT1qQRAmP8AJ9vlt1C/txPlxgqsIM3Szyv38jVPwCfUHLd RruGKKujV8hymv+R4itdcn0= =j+GY -----END PGP SIGNATURE----- From mspevack at redhat.com Mon Feb 12 12:02:55 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 07:02:55 -0500 (EST) Subject: simplistic questions about core/extras merge Message-ID: Hi guys, Hopefully a lot of what I bring up in this email is redundant, and you can just point me to the right places. My goal today is to get an email written up for our *internal* developers, but that is also able to be shown to external developers, that explains exactly what they need to do for Fedora 7. I know that Bill has taken a stab at this before, and it led to a really long thread on one of our internal lists. I think we need to follow up with that, so I'm hoping that I can use this list as a place to get the email drafted up, and then from there I can send it to some engineering managers within Red Hat, and also to the developers who they manage. The audience is 3 types of people: 1) Internal RH developers who already contribute actively to Fedora. 2) Internal RH developers who like the Fedora 7 idea, but haven't yet had time to get Fedora accounts and start thinking about what Fedora 7 means for them. In reality, that won't change much until after RHEL5 goes out. 3) Internal RH developers who don't pay much attention to Fedora at all, aside from what they are "forced" to do. ======== So let's look at the process for a single package, making its way from "Core" to "New World": 1) Package is reviewed under the current Fedora guidelines. As these reviews happen, the guidelines that we have are always up for intelligent discussion. 2) Once a package passes review, a couple of things have to happen a) Current maintainer (someone who is @redhat.com) needs to agree to a freeze. b) Current maintaner needs to get a Fedora account. c) Package's "upstream" is moved from internal CVS and build system to external CVS and build system (basically Extras) d) Current maintainer decides if anyone else should have "maintainer" ACLs at this time e) Development resumes Is that basically the right model? Am I forgetting any major concerns that have previously been voiced? What steps am I missing? I have a few other questions too: 1) What is the process for new folks being given "maintainer" access to a package that is in the New World? I think it's simply a matter of the current maintainer saying so, and the proper access being given in CVS? But *who* is the person/persons who actually makes that happen? 2) What are we going to call the new repo, from the /etc/yum.repos.d/ perspective? In fact, my larger question is "what will f7's fedora-release package look like? 3) How are we going to deal with the worst case scenario, which is packages that fail review, or for which the current @redhat.com maintainer doesn't do anything to help prepare for the merge? ===== My understanding is that for F7Test1, Jesse basically just manually pulled together the packages that went into the Desktop spin from wherever they currently happened to live -- Core or Extras. And that's a fine hack for the time being, but hopefully we will see less and less of that as F7-GOLD gets closer. Ok, comment, flame me, tell me how I'm out of touch and all of this is already spelled out somewhere that I just haven't seen. :-) --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From j.w.r.degoede at hhs.nl Mon Feb 12 12:16:54 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 12 Feb 2007 13:16:54 +0100 Subject: simplistic questions about core/extras merge In-Reply-To: References: Message-ID: <45D05AB6.5070509@hhs.nl> Max Spevack wrote: > > Ok, comment, flame me, tell me how I'm out of touch and all of this is > already spelled out somewhere that I just haven't seen. :-) > I'm a non @redhat.com-er, but I like what I see! no further comments, except for one: > 2) Once a package passes review, a couple of things have to happen > a) Current maintainer (someone who is @redhat.com) needs to agree to > a freeze. > b) Current maintaner needs to get a Fedora account. > c) Package's "upstream" is moved from internal CVS and build system > to external CVS and build system (basically Extras) > d) Current maintainer decides if anyone else should have > "maintainer" ACLs at this time I would like to see the current maintainer encouraged to seek out interested community members here. Many core packages have many bugs open against them, in some cases that is because there are many bugs for a package which are hard to fix, take the kernel for example. In other cases however most of the many open bug are purely a matter of not enough time getting invested into the package (for whatever reasons, I'm not trying to judge anyone here). I believe that in the not enough time invested cases the package and thus Fedora could benefit enormously from the help of one or 2 interested community members. Let me put my money where my mouth is, if any core package maintainer would like a hand and is serious about this. Then drop me a mail with a couple of BZ id's you would like a hand with, or a package name for which you want me to go through bugzilla and fix any bugs against that package in general. Note you should be willing to treat me as a fellow developer and not as some kinda newbie (which I'm not). > e) Development resumes > Regards, Hans From buc at odusz.so-cdu.ru Mon Feb 12 12:22:21 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 12 Feb 2007 15:22:21 +0300 Subject: simplistic questions about core/extras merge In-Reply-To: <45D05AB6.5070509@hhs.nl> References: <45D05AB6.5070509@hhs.nl> Message-ID: <45D05BFD.50108@odu.neva.ru> Hans de Goede wrote: > most of the many open bug are purely a matter of not enough time > getting invested into the package +1 (actually, +100 ... :( ) Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From fedora at leemhuis.info Mon Feb 12 12:48:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 12 Feb 2007 13:48:03 +0100 Subject: What are we going to call the new repo? (Was: Re: simplistic questions about core/extras merge) In-Reply-To: References: Message-ID: <45D06203.5090801@leemhuis.info> On 12.02.2007 13:02, Max Spevack wrote: > [...] > 2) What are we going to call the new repo, from the /etc/yum.repos.d/ > perspective? In fact, my larger question is "what will f7's > fedora-release package look like? Not a big deal, but I'd really would like to have a proper name we all agree on to use. I ran into situations now and then already where just using the term "Fedora" didn't make it clear that I was taking about the merged Core and Extras repository. So how about one of those: * Fedora Package Collection * Fedora Collection * Fedora Packages * Fedora Collective * Fedora Package Collective * Fedora Package Repository * Fedora Repository * /me *currently* votes for "Fedora Package Repository" (short: "fedora-repo"), as that's what it is. Cu thl From rstrode at redhat.com Mon Feb 12 12:55:26 2007 From: rstrode at redhat.com (Ray Strode) Date: Mon, 12 Feb 2007 07:55:26 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: References: Message-ID: <45D063BE.4020104@redhat.com> Hi, > 3) How are we going to deal with the worst case scenario, which is > packages that fail review, or for which the current @redhat.com > maintainer doesn't do anything to help prepare for the merge? I think that's a very important question to ask (there isn't much time left and there are a lot of packages to go!). What are we going to do with packages that don't get done? I don't know answer. Note that when we merge, the number of people available that can do spec cleanups and such will be much higher. It may make sense to let the overflow, overflow and clean things up post-merge. --Ray From rc040203 at freenet.de Mon Feb 12 13:04:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 Feb 2007 14:04:59 +0100 Subject: simplistic questions about core/extras merge In-Reply-To: <45D05BFD.50108@odu.neva.ru> References: <45D05AB6.5070509@hhs.nl> <45D05BFD.50108@odu.neva.ru> Message-ID: <1171285500.3622.8.camel@mccallum.corsepiu.local> On Mon, 2007-02-12 at 15:22 +0300, Dmitry Butskoy wrote: > Hans de Goede wrote: > > > most of the many open bug are purely a matter of not enough time > > getting invested into the package > > > +1 +1 Open up Core for community collaboration and co-maintenance! Ralf From rc040203 at freenet.de Mon Feb 12 13:07:09 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 Feb 2007 14:07:09 +0100 Subject: What are we going to call the new repo? (Was: Re: simplistic questions about core/extras merge) In-Reply-To: <45D06203.5090801@leemhuis.info> References: <45D06203.5090801@leemhuis.info> Message-ID: <1171285629.3622.12.camel@mccallum.corsepiu.local> On Mon, 2007-02-12 at 13:48 +0100, Thorsten Leemhuis wrote: > On 12.02.2007 13:02, Max Spevack wrote: > > [...] > > 2) What are we going to call the new repo, from the /etc/yum.repos.d/ > > perspective? In fact, my larger question is "what will f7's > > fedora-release package look like? > > Not a big deal, but I'd really would like to have a proper name we all > agree on to use. I ran into situations now and then already where just > using the term "Fedora" didn't make it clear that I was taking about the > merged Core and Extras repository. > > So how about one of those: > * Fedora Package Collection > * Fedora Collection > * Fedora Packages > * Fedora Collective Only if you rename FAB into Central Committee. ;) > * Fedora Package Collective > * Fedora Package Repository > * Fedora Repository > * > > /me *currently* votes for "Fedora Package Repository" (short: > "fedora-repo"), as that's what it is. Why not what at least I perceive as obvious: "Fedora"? Ralf From mspevack at redhat.com Mon Feb 12 13:13:53 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 08:13:53 -0500 (EST) Subject: What are we going to call the new repo? (Was: Re: simplistic questions about core/extras merge) In-Reply-To: <45D06203.5090801@leemhuis.info> References: <45D06203.5090801@leemhuis.info> Message-ID: On Mon, 12 Feb 2007, Thorsten Leemhuis wrote: > /me *currently* votes for "Fedora Package Repository" (short: > "fedora-repo"), as that's what it is. Fine with me. --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From mspevack at redhat.com Mon Feb 12 13:16:25 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 08:16:25 -0500 (EST) Subject: simplistic questions about core/extras merge In-Reply-To: <45D063BE.4020104@redhat.com> References: <45D063BE.4020104@redhat.com> Message-ID: On Mon, 12 Feb 2007, Ray Strode wrote: > I think that's a very important question to ask (there isn't much time > left and there are a lot of packages to go!). What are we going to do > with packages that don't get done? > > I don't know answer. Note that when we merge, the number of people > available that can do spec cleanups and such will be much higher. It > may make sense to let the overflow, overflow and clean things up > post-merge. I think that for Fedora 7, we're going to have to make our best effort, but acknowledge that there might be some packages that aren't 100% "finished" in time. We should do what we can to minimize that (and I applaud loudly for all the people who are working so hard on the package reviews), but we should also realize that in some cases we might have to be ok with it. There's a huge number of packages, and not a huge amount of time. And until RHEL5 is out, RH-developer time is precious (and that's to be expected). --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From j.w.r.degoede at hhs.nl Mon Feb 12 13:52:23 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Mon, 12 Feb 2007 14:52:23 +0100 Subject: simplistic questions about core/extras merge In-Reply-To: <1171285500.3622.8.camel@mccallum.corsepiu.local> References: <45D05AB6.5070509@hhs.nl> <45D05BFD.50108@odu.neva.ru> <1171285500.3622.8.camel@mccallum.corsepiu.local> Message-ID: On Mon, 12 Feb 2007 14:04:59 +0100 Ralf Corsepius wrote: > On Mon, 2007-02-12 at 15:22 +0300, Dmitry Butskoy wrote: > > Hans de Goede wrote: > > > > > most of the many open bug are purely a matter of not > enough time > > > getting invested into the package > > > > > > +1 > +1 > > Open up Core for community collaboration and > co-maintenance! > I'm glad people agree, now it would really help if people would stop asking @redhat.com people to open-up as if this is a unilateral thing, things need to come from two side both from the @redhat.com people and from us. Hence I would like to see other FE contributers to join my offer to help out @redhat.com with specific bz id's or specific packages which which the @redhat.com people feel comfortable opening up / could really use help with. Regards, Hans From mschwendt.tmp0701.nospam at arcor.de Mon Feb 12 13:58:05 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 12 Feb 2007 14:58:05 +0100 Subject: Why is redhat-artwork multi-lib? Message-ID: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> In the rawhide for x86_64 repository: redhat-artwork - 5.0.8-4.fc7.i386 redhat-artwork - 5.0.8-4.fc7.x86_64 $ rpm -q --provides redhat-artwork bluecurve.so config(redhat-artwork) = 5.0.8-1.fc6 kwin3_bluecurve.so.0 libbluecurve.so redhat-artwork = 5.0.8-1.fc6 $ rpm -ql redhat-artwork|wc -l 8045 $ rpm -ql redhat-artwork|grep share|wc -l 8024 Why is such a huge data (!) package, which contains over 8000 files in /usr/share, merged with the few arch-specific bluecurve libs, so that it becomes a multi-lib package? From linux_4ever at yahoo.com Mon Feb 12 14:01:05 2007 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 12 Feb 2007 06:01:05 -0800 (PST) Subject: rawhide named Message-ID: <763336.95020.qm@web51515.mail.yahoo.com> hi, Updated to current bind in rawhide and now have this: ]# ls -l | grep 2007-02-12 drwxrwx--- 2 named named 4096 2007-02-12 08:47 -- drwxrwx--- 2 named named 4096 2007-02-12 08:47 # drwxrwx--- 2 named named 4096 2007-02-12 08:47 a drwxr-xr-x 2 root root 4096 2007-02-12 08:47 bin drwxrwx--- 2 named named 4096 2007-02-12 08:47 chroot drwxr-x--- 5 root root 4096 2007-02-12 08:47 environment. drwxrwx--- 2 named named 4096 2007-02-12 08:47 in drwxrwx--- 2 named named 4096 2007-02-12 08:47 named drwxr-xr-x 3 root root 4096 2007-02-12 08:47 ROOTDIR=" drwxrwx--- 2 named named 4096 2007-02-12 08:47 run drwxrwx--- 2 named named 4096 2007-02-12 08:47 will Looks like a bad script. Installed Packages bind.x86_64 31:9.3.4-5.fc7 installed bind-chroot.x86_64 31:9.3.4-5.fc7 installed bind-libs.x86_64 31:9.3.4-5.fc7 installed bind-utils.x86_64 31:9.3.4-5.fc7 installed -Steve ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited From atkac at redhat.com Mon Feb 12 14:12:22 2007 From: atkac at redhat.com (Adam Tkac) Date: Mon, 12 Feb 2007 15:12:22 +0100 Subject: rawhide named In-Reply-To: <763336.95020.qm@web51515.mail.yahoo.com> References: <763336.95020.qm@web51515.mail.yahoo.com> Message-ID: <45D075C6.7040004@redhat.com> Steve G napsal(a): > hi, > > Updated to current bind in rawhide and now have this: > > ]# ls -l | grep 2007-02-12 > drwxrwx--- 2 named named 4096 2007-02-12 08:47 -- > drwxrwx--- 2 named named 4096 2007-02-12 08:47 # > drwxrwx--- 2 named named 4096 2007-02-12 08:47 a > drwxr-xr-x 2 root root 4096 2007-02-12 08:47 bin > drwxrwx--- 2 named named 4096 2007-02-12 08:47 chroot > drwxr-x--- 5 root root 4096 2007-02-12 08:47 environment. > drwxrwx--- 2 named named 4096 2007-02-12 08:47 in > drwxrwx--- 2 named named 4096 2007-02-12 08:47 named > drwxr-xr-x 3 root root 4096 2007-02-12 08:47 ROOTDIR=" > drwxrwx--- 2 named named 4096 2007-02-12 08:47 run > drwxrwx--- 2 named named 4096 2007-02-12 08:47 will > > Looks like a bad script. > > Installed Packages > bind.x86_64 31:9.3.4-5.fc7 installed > bind-chroot.x86_64 31:9.3.4-5.fc7 installed > bind-libs.x86_64 31:9.3.4-5.fc7 installed > bind-utils.x86_64 31:9.3.4-5.fc7 installed > > > -Steve > > > > > ____________________________________________________________________________________ > Yahoo! Music Unlimited > Access over 1 million songs. > http://music.yahoo.com/unlimited > > You're right. Script (bind-chroot-admin) is broken in bind-*-5.fc7 but this could be fixed in -6.fc7 series. Could you try to update to 9.3.4-6.fc7 and report results to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227995, please ? Regards, Adam From mschwendt.tmp0701.nospam at arcor.de Mon Feb 12 14:18:27 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 12 Feb 2007 15:18:27 +0100 Subject: simplistic questions about core/extras merge In-Reply-To: References: <45D05AB6.5070509@hhs.nl> <45D05BFD.50108@odu.neva.ru> <1171285500.3622.8.camel@mccallum.corsepiu.local> Message-ID: <20070212151827.0028acc5.mschwendt.tmp0701.nospam@arcor.de> On Mon, 12 Feb 2007 14:52:23 +0100, Goede, J.W.R. de wrote: > I'm glad people agree, now it would really help if people > would stop asking @redhat.com people to open-up as if this > is a unilateral thing, things need to come from two side > both from the @redhat.com people and from us. > > Hence I would like to see other FE contributers to join my > offer to help out @redhat.com with specific bz id's or > specific packages which which the @redhat.com people feel > comfortable opening up / could really use help with. There's a long thread about that on one of the community's internal lists. Eh? What? -- Yes, a lot of things about the Merge are unknown and planned in closed circles. Joking aside! The community doesn't have an internal list. But to me it is no surprise that external fedora lists are no success, when essential communication about Fedora seems to be internal to Red Hat. Moving packages from internal cvs at Red Hat to Fedora Extras cvs is not everything. Moving (and closing down) some lists ought to happen, too, as we are caught in a redundant web of lists, where it is cross-posted again and again because nobody knows whom to reach in what place. Package ownership in Core doesn't seem to be clear in all cases either, as some maintainers have already expressed that they wish to give a package to somebody else. It is only a matter of time before the community will learn what packages in the merged set of packages will be orphaned unless somebody from the community picks them up. From stickster at gmail.com Mon Feb 12 14:19:55 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 12 Feb 2007 09:19:55 -0500 Subject: What are we going to call the new repo? (Was: Re: simplistic questions about core/extras merge) In-Reply-To: <45D06203.5090801@leemhuis.info> References: <45D06203.5090801@leemhuis.info> Message-ID: <1171289995.14634.15.camel@localhost.localdomain> On Mon, 2007-02-12 at 13:48 +0100, Thorsten Leemhuis wrote: > On 12.02.2007 13:02, Max Spevack wrote: > > [...] > > 2) What are we going to call the new repo, from the /etc/yum.repos.d/ > > perspective? In fact, my larger question is "what will f7's > > fedora-release package look like? > > Not a big deal, but I'd really would like to have a proper name we all > agree on to use. I ran into situations now and then already where just > using the term "Fedora" didn't make it clear that I was taking about the > merged Core and Extras repository. > > So how about one of those: > * Fedora Package Collection > * Fedora Collection "Fedora Collection" allows us to sensibly continue using the current dist tag ".fcX". -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 linux_4ever at yahoo.com Mon Feb 12 14:26:33 2007 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 12 Feb 2007 06:26:33 -0800 (PST) Subject: rawhide named In-Reply-To: <45D075C6.7040004@redhat.com> Message-ID: <275818.5642.qm@web51501.mail.yahoo.com> >Script (bind-chroot-admin) is broken in bind-*-5.fc7 but this could be fixed in >-6.fc7 series. Could you try to update to 9.3.4-6.fc7 As soon as I see a new rawhide push I will. >and report results to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227995 hmm, I searched bz right after sending the email and found nothing. So, I opened bz 228276. -Steve ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html From mclasen at redhat.com Mon Feb 12 14:44:11 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 09:44:11 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: References: Message-ID: <45D07D3B.3010808@redhat.com> Max Spevack wrote: > > So let's look at the process for a single package, making its way from > "Core" to "New World": > > 1) Package is reviewed under the current Fedora guidelines. As these > reviews happen, the guidelines that we have are always up for > intelligent discussion. > > 2) Once a package passes review, a couple of things have to happen > a) Current maintainer (someone who is @redhat.com) needs to agree > to a freeze. I don't think it is possible to just stop development just because a package has been approved. There isn't even a new build system yet, so please let us just continue to do development in the old build system until the time that the infrastructure is actually ready to do the move. I don't think such a freeze between approval and move would buy us anything, really. Or do you want me to wait for reapproval after any change I do post-merge, too ? From rdieter at fedoraproject.org Mon Feb 12 14:33:06 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 08:33:06 -0600 Subject: simplistic questions about core/extras merge References: <45D063BE.4020104@redhat.com> Message-ID: Ray Strode wrote: >> 3) How are we going to deal with the worst case scenario, which is >> packages that fail review, or for which the current @redhat.com >> maintainer doesn't do anything to help prepare for the merge? > > I think that's a very important question to ask (there isn't much time > left and there are a lot of packages to go!). What are we going to do > with packages that don't get done? IMO, simple: either the @redhat.com maintainer does their job (possibly with inducement related to pointy sticks), or give the package to someone else who can/will. -- Rex From rdieter at math.unl.edu Mon Feb 12 14:52:31 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Feb 2007 08:52:31 -0600 Subject: F7 KDE spin r2 Message-ID: <45D07F2F.6010506@math.unl.edu> Just updated: http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE to include more details. Feedback, criticism is welcome. Further, we'll be holding an informal irc meetings on #fedora-devel Tuesdays @ 03:00 UTC (turns out to be Mon 9pm CST for me). If folks are interested, but that time doesn't work for you, please post times that work better for you at: http://fedoraproject.org/wiki/Extras/SIGs/KDE -- Rex From mclasen at redhat.com Mon Feb 12 15:03:11 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 10:03:11 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45D081AF.3040508@redhat.com> Michael Schwendt wrote: > In the rawhide for x86_64 repository: > > redhat-artwork - 5.0.8-4.fc7.i386 > redhat-artwork - 5.0.8-4.fc7.x86_64 > > $ rpm -q --provides redhat-artwork > bluecurve.so > config(redhat-artwork) = 5.0.8-1.fc6 > kwin3_bluecurve.so.0 > libbluecurve.so > redhat-artwork = 5.0.8-1.fc6 > > $ rpm -ql redhat-artwork|wc -l > 8045 > $ rpm -ql redhat-artwork|grep share|wc -l > 8024 > > Why is such a huge data (!) package, which contains over 8000 files in > /usr/share, merged with the few arch-specific bluecurve libs, so that it > becomes a multi-lib package? > > History. Thats just the way it was initially done, before multilib became an issue. From mspevack at redhat.com Mon Feb 12 15:02:15 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 12 Feb 2007 10:02:15 -0500 (EST) Subject: simplistic questions about core/extras merge In-Reply-To: <45D07D3B.3010808@redhat.com> References: <45D07D3B.3010808@redhat.com> Message-ID: On Mon, 12 Feb 2007, Matthias Clasen wrote: >> 2) Once a package passes review, a couple of things have to happen >> a) Current maintainer (someone who is @redhat.com) needs to agree to a >> freeze. > > I don't think it is possible to just stop development just because a > package has been approved. There isn't even a new build system yet, so > please let us just continue to do development in the old build system > until the time that the infrastructure is actually ready to do the move. > I don't think such a freeze between approval and move would buy us > anything, really. Or do you want me to wait for reapproval after any > change I do post-merge, too ? All I mean is that eventually, there will be a moment in time in which a package's CVS moves from internal to external. The maintainer basically has control over that timeframe, which doesn't have to be long. But at some point the maintainer of a package will say something like: "no more checkins to the internal CVS, we're moving" followed by "ok to checkin, we're now in the external CVS" is that wrong? -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From mclasen at redhat.com Mon Feb 12 15:12:26 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 10:12:26 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: References: <45D07D3B.3010808@redhat.com> Message-ID: <45D083DA.1000503@redhat.com> Max Spevack wrote: > > All I mean is that eventually, there will be a moment in time in which > a package's CVS moves from internal to external. The maintainer > basically has control over that timeframe, which doesn't have to be > long. But at some point the maintainer of a package will say > something like: > > "no more checkins to the internal CVS, we're moving" > followed by > "ok to checkin, we're now in the external CVS" > > is that wrong? No, thats fine. I misunderstood your original mail to mean "no commits between approval and move". From skvidal at linux.duke.edu Mon Feb 12 15:09:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Feb 2007 10:09:11 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <45D081AF.3040508@redhat.com> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> Message-ID: <1171292951.27965.69.camel@cutter> On Mon, 2007-02-12 at 10:03 -0500, Matthias Clasen wrote: > Michael Schwendt wrote: > > In the rawhide for x86_64 repository: > > > > redhat-artwork - 5.0.8-4.fc7.i386 > > redhat-artwork - 5.0.8-4.fc7.x86_64 > > > > $ rpm -q --provides redhat-artwork > > bluecurve.so > > config(redhat-artwork) = 5.0.8-1.fc6 > > kwin3_bluecurve.so.0 > > libbluecurve.so > > redhat-artwork = 5.0.8-1.fc6 > > > > $ rpm -ql redhat-artwork|wc -l > > 8045 > > $ rpm -ql redhat-artwork|grep share|wc -l > > 8024 > > > > Why is such a huge data (!) package, which contains over 8000 files in > > /usr/share, merged with the few arch-specific bluecurve libs, so that it > > becomes a multi-lib package? > > > > > History. > Thats just the way it was initially done, before multilib became an issue. okay, But now that multilib is an issue is it possible to un-do this so it can be a nice noarch pkg? -sv From ajackson at redhat.com Mon Feb 12 14:59:16 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 12 Feb 2007 09:59:16 -0500 Subject: libXft.so.1 In-Reply-To: References: Message-ID: <1171292356.7008.6.camel@localhost.localdomain> On Mon, 2007-02-12 at 10:00 +0100, Gianluca Sforna wrote: > Hi all, > I have here a legacy application linked to libXft.so.1 but, unless I'm > blind or something, it is nowhere to be found in FC6. > > Is there any compat- package available/planned? This used to be provided by the xorg-x11 package in FC4, and by XFree86 in FC1 and earlier. Upstream Xorg dropped it during modularisation, so there's currently no real upstream packaging for it besides the 6.9 monolithic Xorg release. I don't have any plans to add Xft1 to Fedora myself, but it'd be fine to include. If you do so you may want to engage Xorg upstream to get a modular package constructed too, since I can imagine other distros wanting this. Until then you could just rip the binaries out of the FC4 xorg-x11. - ajax From mclasen at redhat.com Mon Feb 12 15:14:31 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 10:14:31 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171292951.27965.69.camel@cutter> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> Message-ID: <45D08457.5040506@redhat.com> seth vidal wrote: > > okay, But now that multilib is an issue is it possible to un-do this so > it can be a nice noarch pkg? > Reorganizing the artwork packages has been on our TODO list for some time, we just haven't gotten around to it yet. From skvidal at linux.duke.edu Mon Feb 12 15:16:32 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Feb 2007 10:16:32 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <45D08457.5040506@redhat.com> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> Message-ID: <1171293392.27965.71.camel@cutter> On Mon, 2007-02-12 at 10:14 -0500, Matthias Clasen wrote: > seth vidal wrote: > > > > okay, But now that multilib is an issue is it possible to un-do this so > > it can be a nice noarch pkg? > > > > Reorganizing the artwork packages has been on our TODO list for some > time, we just haven't gotten > around to it yet. Is there anything specific and difficult about it? Could one of the community contributors who has an interest in it take a whack at it? -sv From mclasen at redhat.com Mon Feb 12 15:29:15 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 10:29:15 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171293392.27965.71.camel@cutter> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> Message-ID: <45D087CB.7090901@redhat.com> seth vidal wrote: > On Mon, 2007-02-12 at 10:14 -0500, Matthias Clasen wrote: > >> seth vidal wrote: >> >>> okay, But now that multilib is an issue is it possible to un-do this so >>> it can be a nice noarch pkg? >>> >>> >> Reorganizing the artwork packages has been on our TODO list for some >> time, we just haven't gotten >> around to it yet. >> > > Is there anything specific and difficult about it? Could one of the > community contributors who has an interest in it take a whack at it? > I don't think it is particularly difficult, but there are a number of constraints (like keeping all trademarked logos in a separate package). What we need before making any decisions here is a summary of the current situation (what "artwork" packages do we have, how do they interact, also wrt to derived distributions, etc) and a list of goals for a reorganization. I'm sure interested community members can take a whack at that. From fche at redhat.com Mon Feb 12 15:32:22 2007 From: fche at redhat.com (Frank Ch. Eigler) Date: 12 Feb 2007 10:32:22 -0500 Subject: Wakeup alarm? In-Reply-To: <200702100910.30331.jkeating@redhat.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <1171069764.19887.0.camel@hughsie-laptop> <20070210043742.GA1510752@hiwaay.net> <200702100910.30331.jkeating@redhat.com> Message-ID: Jesse Keating writes: > Also we don't know how many CDs you'll need before doing > depchecking. We have to prompt you with how many you'll need so > that you don't start the install and get asked for a CD you didn't > download/burn. Anaconda can tell when this is not applicable, for example if it runs off of a DVD installation. Then this post-depcheck prompt is nothing but a waste of time. Even if this prompting were applicable (for CD installs), is there data to support the intuition that the problem (not enough CDs downloaded) occurs frequently enough to justify the time waste imposed on those who do not make that mistake? - FChE From jkeating at redhat.com Mon Feb 12 15:37:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 10:37:04 -0500 Subject: Wakeup alarm? In-Reply-To: <16de708d0702111740o7c1ca7em84626c95a3ec5bc1@mail.gmail.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702100910.30331.jkeating@redhat.com> <16de708d0702111740o7c1ca7em84626c95a3ec5bc1@mail.gmail.com> Message-ID: <200702121037.05182.jkeating@redhat.com> On Sunday 11 February 2007 20:40, Arthur Pemberton wrote: > So at by that stage of the installtion Anaconda doesn't know if it is > doing a DVD install or network install or multi disk install? There isn't currently a way to tell a difference between a CD and a DVD. Due to a logic flaw in how we've been composing, the same metadata from multiple CD set was used on the DVD as well. I'll be fixing this in Pungi, so that we have _some_ clue (all packages reference media1), but that won't help in the multiple DVD scenario, where the repodata is split again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Feb 12 15:36:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 Feb 2007 10:36:56 -0500 Subject: Question on Feature Freeze ..and possibly of adding PPC Xen? In-Reply-To: <1171053501.3182.23.camel@thinkpad> References: <1171053501.3182.23.camel@thinkpad> Message-ID: <1171294616.17054.8.camel@aglarond.local> On Fri, 2007-02-09 at 14:38 -0600, Jerone Young wrote: > I'm wondering how hard is the feature freeze on Febuary 20th? For things which have an impact outside of themself, we're going to need to hold the line pretty well if we're going to actually hit the release schedule. > We would like to try and enable PPC Fedora with Xen. Though doing so > will run past the freeze date of Febuary 20th as we would need to up > port to the fedora kernel version. What would be the complete cut off > date if it would be possible ? Given the fact that it's a pretty major feature and needs to have some significant exposure, I think that it's going to need to be there for test2 if it's going to be in F7. > Also would any featured packages outside of the kernel that does not > make the feature freeze date be OK for extras. Will there be an extras > repository around FC7 time frame or is it that all packages will have be > in the main repository and make the freeze date? There's one repository of packages. New packages will be able to trickle into the released repository, but some of the mechanics of that aren't fully fleshed out yet. Jeremy From jkeating at redhat.com Mon Feb 12 15:44:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 10:44:07 -0500 Subject: Wakeup alarm? In-Reply-To: References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702100910.30331.jkeating@redhat.com> Message-ID: <200702121044.07334.jkeating@redhat.com> On Monday 12 February 2007 10:32, Frank Ch. Eigler wrote: > Anaconda can tell when this is not applicable, for example if it runs > off of a DVD installation. ?Then this post-depcheck prompt is nothing > but a waste of time. Due to a composing logic flaw in past releases, it was not possible to distinguish between CD media and DVD media. The same repodata was used. I'll be fixing that in pungi so that we can tell when we're on DVD vs CD, however since people want the monster spin of doom, we'll need to actually split across multiple DVDs so the problem is back. > Even if this prompting were applicable (for CD installs), is there > data to support the intuition that the problem (not enough CDs > downloaded) occurs frequently enough to justify the time waste imposed > on those who do not make that mistake? I go through this often enough. I burn one or 2 out of the 5, do some package selection, realize I have too much, go back and trim it down a bit. I'm just stating why the check is there. Whether or not it should go away, I don't have a strong argument for either, I'm just stating why it is there now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcantrell at redhat.com Mon Feb 12 15:44:41 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 12 Feb 2007 10:44:41 -0500 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <45CC133A.8050902@redhat.com> <1171138744.3250.13.camel@mortise.boston.redhat.com> <1171141232.3234.0.camel@scrappy.miketc.com> Message-ID: <1171295081.2997.10.camel@mortise.boston.redhat.com> On Mon, 2007-02-12 at 09:04 +0200, Panu Matilainen wrote: > On Sat, 10 Feb 2007, Mike Chambers wrote: > > > On Sat, 2007-02-10 at 15:19 -0500, David Cantrell wrote: > > > >> Applied in repoman-0.6, which is available at: > >> > >> http://www.boston.burdell.org/repoman/ > > > > I get this error (as well as last version) when trying to run repoman.. > > > > Component: Repository Manager > > Summary: TBdc86dff1 interface.py:70:__init__:AttributeError: 'NoneType' > > object has no attribute 'isEnabled' > > > > Traceback (most recent call last): > > File "/usr/sbin/repoman", line 31, in > > ui = RepoMan() > > File "/usr/lib/python2.5/site-packages/repoman/interface.py", line > > 522, in __init__ > > self.trackingPage = TrackingPage(self) > > File "/usr/lib/python2.5/site-packages/repoman/interface.py", line 70, > > in __init__ > > if self.repos.getStanzaByName("updates-testing").isEnabled(): > > AttributeError: 'NoneType' object has no attribute 'isEnabled' > > > > Local variables in innermost frame: > > interface: > > self: > > I saw this too - repoman (at the moment) only works if you have the > default Fedora repository setup on your system. If the idea is to have a > Fedora-specific tool I think it should be called fedora-repoman or > something like that to indicate it's really distro-specific. Fixed in repoman-0.7. The Tracking page was assuming a standard Fedora repo file layout. When you lack a Fedora standard repository, the Tracking page is disabled. Thanks, -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Feb 12 15:56:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 10:56:01 -0500 Subject: Wakeup alarm? In-Reply-To: <200702121044.07334.jkeating@redhat.com> References: <000301c74caf$6cb0eab0$020aa8c0@a18> <200702121044.07334.jkeating@redhat.com> Message-ID: <200702121056.01187.jkeating@redhat.com> On Monday 12 February 2007 10:44, Jesse Keating wrote: > Due to a composing logic flaw in past releases, it was not possible to > distinguish between CD media and DVD media. ?The same repodata was used. Wait, this wasn't a logic flaw, this is done on purpose by design. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Feb 12 15:56:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 Feb 2007 10:56:45 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: References: <45D07D3B.3010808@redhat.com> Message-ID: <1171295805.17054.16.camel@aglarond.local> On Mon, 2007-02-12 at 10:02 -0500, Max Spevack wrote: > On Mon, 12 Feb 2007, Matthias Clasen wrote: > >> 2) Once a package passes review, a couple of things have to happen > >> a) Current maintainer (someone who is @redhat.com) needs to agree to a > >> freeze. > > > > I don't think it is possible to just stop development just because a > > package has been approved. There isn't even a new build system yet, so > > please let us just continue to do development in the old build system > > until the time that the infrastructure is actually ready to do the move. > > I don't think such a freeze between approval and move would buy us > > anything, really. Or do you want me to wait for reapproval after any > > change I do post-merge, too ? > > All I mean is that eventually, there will be a moment in time in which a > package's CVS moves from internal to external. The maintainer basically > has control over that timeframe, which doesn't have to be long. But at > some point the maintainer of a package will say something like: > > "no more checkins to the internal CVS, we're moving" > followed by > "ok to checkin, we're now in the external CVS" > > is that wrong? I'm not sure how much it's actually going to be under the control of the maintainer. To be able to do the switch sanely (especially with the build system bits), it's going to largely have to be a big change everything at once. Also, the confusion of "anaconda is on cvs.fedora, rhpl is on the internal cvs server" is just too much for me... Jeremy From skvidal at linux.duke.edu Mon Feb 12 16:06:01 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Feb 2007 11:06:01 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <45D087CB.7090901@redhat.com> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> Message-ID: <1171296361.27965.82.camel@cutter> On Mon, 2007-02-12 at 10:29 -0500, Matthias Clasen wrote: > I don't think it is particularly difficult, but there are a number of > constraints (like > keeping all trademarked logos in a separate package). What we need > before making > any decisions here is a summary of the current situation (what "artwork" > packages > do we have, how do they interact, also wrt to derived distributions, > etc) and a list > of goals for a reorganization. I'm sure interested community members can > take a > whack at that. Jeremy, were you planning in changes in this area vis anaconda? -sv From katzj at redhat.com Mon Feb 12 16:06:11 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 Feb 2007 11:06:11 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171296361.27965.82.camel@cutter> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> Message-ID: <1171296371.17054.25.camel@aglarond.local> On Mon, 2007-02-12 at 11:06 -0500, seth vidal wrote: > On Mon, 2007-02-12 at 10:29 -0500, Matthias Clasen wrote: > > I don't think it is particularly difficult, but there are a number of > > constraints (like > > keeping all trademarked logos in a separate package). What we need > > before making > > any decisions here is a summary of the current situation (what "artwork" > > packages > > do we have, how do they interact, also wrt to derived distributions, > > etc) and a list > > of goals for a reorganization. I'm sure interested community members can > > take a > > whack at that. > were you planning in changes in this area vis anaconda? One thing that was discussed a little at FUDCon was moving some of the trademarked logo bits into a separate "branding" repository. That doesn't really have much to do with redhat-artwork, though. Historically speaking, redhat-artwork was created to contain all Bluecurve bits (and could as well have been called "bluecurve-artwork", it was just named prior to the name Bluecurve and with the thought of letting the theme change over time...) Jeremy From notting at redhat.com Mon Feb 12 16:08:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 11:08:38 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171296371.17054.25.camel@aglarond.local> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> <1171296371.17054.25.camel@aglarond.local> Message-ID: <20070212160838.GG11536@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > That doesn't really have much to do with redhat-artwork, though. > Historically speaking, redhat-artwork was created to contain all > Bluecurve bits (and could as well have been called "bluecurve-artwork", > it was just named prior to the name Bluecurve and with the thought of > letting the theme change over time...) *cough* system-artwork *cough* Bill From skvidal at linux.duke.edu Mon Feb 12 16:18:42 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Feb 2007 11:18:42 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171296371.17054.25.camel@aglarond.local> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> <1171296371.17054.25.camel@aglarond.local> Message-ID: <1171297122.27965.92.camel@cutter> On Mon, 2007-02-12 at 11:06 -0500, Jeremy Katz wrote: > On Mon, 2007-02-12 at 11:06 -0500, seth vidal wrote: > > On Mon, 2007-02-12 at 10:29 -0500, Matthias Clasen wrote: > > > I don't think it is particularly difficult, but there are a number of > > > constraints (like > > > keeping all trademarked logos in a separate package). What we need > > > before making > > > any decisions here is a summary of the current situation (what "artwork" > > > packages > > > do we have, how do they interact, also wrt to derived distributions, > > > etc) and a list > > > of goals for a reorganization. I'm sure interested community members can > > > take a > > > whack at that. > > were you planning in changes in this area vis anaconda? > > One thing that was discussed a little at FUDCon was moving some of the > trademarked logo bits into a separate "branding" repository. > > That doesn't really have much to do with redhat-artwork, though. > Historically speaking, redhat-artwork was created to contain all > Bluecurve bits (and could as well have been called "bluecurve-artwork", > it was just named prior to the name Bluecurve and with the thought of > letting the theme change over time...) Matthias, So it sounds like all that needs to happen is: 1. rename the pkg to system-artwork (add an obsoletes redhat-artwork) 2. get rid of the bluecurve libs into another pkg 3. profit! Does that sound right to you? -sv From notting at redhat.com Mon Feb 12 16:17:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 11:17:10 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171297122.27965.92.camel@cutter> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> <1171296371.17054.25.camel@aglarond.local> <1171297122.27965.92.camel@cutter> Message-ID: <20070212161710.GJ11536@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > So it sounds like all that needs to happen is: > > 1. rename the pkg to system-artwork (add an obsoletes redhat-artwork) > 2. get rid of the bluecurve libs into another pkg > 3. profit! > > Does that sound right to you? Actually, considering that we're not even using them by default, would we want to split the bluecurve theme out to the point where it's not even shipped by default? Bill From skvidal at linux.duke.edu Mon Feb 12 16:21:04 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Feb 2007 11:21:04 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <20070212161710.GJ11536@nostromo.devel.redhat.com> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> <1171296371.17054.25.camel@aglarond.local> <1171297122.27965.92.camel@cutter> <20070212161710.GJ11536@nostromo.devel.redhat.com> Message-ID: <1171297264.27965.94.camel@cutter> On Mon, 2007-02-12 at 11:17 -0500, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > So it sounds like all that needs to happen is: > > > > 1. rename the pkg to system-artwork (add an obsoletes redhat-artwork) > > 2. get rid of the bluecurve libs into another pkg > > 3. profit! > > > > Does that sound right to you? > > Actually, considering that we're not even using them by default, > would we want to split the bluecurve theme out to the point > where it's not even shipped by default? +1 -sv From mclasen at redhat.com Mon Feb 12 16:26:37 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 12 Feb 2007 11:26:37 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171297122.27965.92.camel@cutter> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> <1171296371.17054.25.camel@aglarond.local> <1171297122.27965.92.camel@cutter> Message-ID: <45D0953D.7000608@redhat.com> seth vidal wrote: > On Mon, 2007-02-12 at 11:06 -0500, Jeremy Katz wrote: > >> On Mon, 2007-02-12 at 11:06 -0500, seth vidal wrote: >> >>> On Mon, 2007-02-12 at 10:29 -0500, Matthias Clasen wrote: >>> >>>> I don't think it is particularly difficult, but there are a number of >>>> constraints (like >>>> keeping all trademarked logos in a separate package). What we need >>>> before making >>>> any decisions here is a summary of the current situation (what "artwork" >>>> packages >>>> do we have, how do they interact, also wrt to derived distributions, >>>> etc) and a list >>>> of goals for a reorganization. I'm sure interested community members can >>>> take a >>>> whack at that. >>>> >>> were you planning in changes in this area vis anaconda? >>> >> One thing that was discussed a little at FUDCon was moving some of the >> trademarked logo bits into a separate "branding" repository. >> >> That doesn't really have much to do with redhat-artwork, though. >> Historically speaking, redhat-artwork was created to contain all >> Bluecurve bits (and could as well have been called "bluecurve-artwork", >> it was just named prior to the name Bluecurve and with the thought of >> letting the theme change over time...) >> > > Matthias, > So it sounds like all that needs to happen is: > > 1. rename the pkg to system-artwork (add an obsoletes redhat-artwork) > 2. get rid of the bluecurve libs into another pkg > 3. profit! > > Does that sound right to you > Moving the libs to another package lets redhat-artwork become noarch, sure. It doesn't address most of the other issues with artwork being spread over several packages in a confusing way... From notting at redhat.com Mon Feb 12 16:24:13 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 11:24:13 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: References: Message-ID: <20070212162413.GK11536@nostromo.devel.redhat.com> Max Spevack (mspevack at redhat.com) said: > So let's look at the process for a single package, making its way from > "Core" to "New World": > > 1) Package is reviewed under the current Fedora guidelines. As these > reviews happen, the guidelines that we have are always up for intelligent > discussion. > > 2) Once a package passes review, a couple of things have to happen > a) Current maintainer (someone who is @redhat.com) needs to agree > to a freeze. > b) Current maintaner needs to get a Fedora account. > c) Package's "upstream" is moved from internal CVS and build > system to external CVS and build system (basically Extras) > d) Current maintainer decides if anyone else should have > "maintainer" ACLs at this time > e) Development resumes > > Is that basically the right model? Am I forgetting any major concerns > that have previously been voiced? What steps am I missing? Well, there has been plans of a two-stage merge. For anything that's reasonably on the edges of Fedora (i.e., isn't a dependency of the world), we could do moves before 'the big switch', which would be done in a one-off basis as stated above. However, for the vast majority of packages, there will be a simple drop-dead date where they are moved en-masse. The Fedora account requirements, etc. will all still be there, but it will be a period where we shut down all CVS for a few hours to do this. > I have a few other questions too: > > 1) What is the process for new folks being given "maintainer" access to a > package that is in the New World? I think it's simply a matter of the > current maintainer saying so, and the proper access being given in CVS? > But *who* is the person/persons who actually makes that happen? The maintainer (or a CVS administrator) does that by editing the ACL. > 2) What are we going to call the new repo, from the /etc/yum.repos.d/ > perspective? In fact, my larger question is "what will f7's > fedora-release package look like? One repo to rule... . Sorry about that. Right now we have core, extras, devel, extras-devel, updates, and updates-testing. This would be trimmed to simply release, development, updates, and updates-testing. > 3) How are we going to deal with the worst case scenario, which is > packages that fail review, or for which the current @redhat.com maintainer > doesn't do anything to help prepare for the merge? Pointy sticks, pitchforks, managers? Bill From skvidal at linux.duke.edu Mon Feb 12 16:27:32 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Feb 2007 11:27:32 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <45D0953D.7000608@redhat.com> References: <20070212145805.0b08f874.mschwendt.tmp0701.nospam@arcor.de> <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> <1171296371.17054.25.camel@aglarond.local> <1171297122.27965.92.camel@cutter> <45D0953D.7000608@redhat.com> Message-ID: <1171297652.27965.99.camel@cutter> On Mon, 2007-02-12 at 11:26 -0500, Matthias Clasen wrote: > seth vidal wrote: > > On Mon, 2007-02-12 at 11:06 -0500, Jeremy Katz wrote: > > > >> On Mon, 2007-02-12 at 11:06 -0500, seth vidal wrote: > >> > >>> On Mon, 2007-02-12 at 10:29 -0500, Matthias Clasen wrote: > >>> > >>>> I don't think it is particularly difficult, but there are a number of > >>>> constraints (like > >>>> keeping all trademarked logos in a separate package). What we need > >>>> before making > >>>> any decisions here is a summary of the current situation (what "artwork" > >>>> packages > >>>> do we have, how do they interact, also wrt to derived distributions, > >>>> etc) and a list > >>>> of goals for a reorganization. I'm sure interested community members can > >>>> take a > >>>> whack at that. > >>>> > >>> were you planning in changes in this area vis anaconda? > >>> > >> One thing that was discussed a little at FUDCon was moving some of the > >> trademarked logo bits into a separate "branding" repository. > >> > >> That doesn't really have much to do with redhat-artwork, though. > >> Historically speaking, redhat-artwork was created to contain all > >> Bluecurve bits (and could as well have been called "bluecurve-artwork", > >> it was just named prior to the name Bluecurve and with the thought of > >> letting the theme change over time...) > >> > > > > Matthias, > > So it sounds like all that needs to happen is: > > > > 1. rename the pkg to system-artwork (add an obsoletes redhat-artwork) > > 2. get rid of the bluecurve libs into another pkg > > 3. profit! > > > > Does that sound right to you > > > > Moving the libs to another package lets redhat-artwork become noarch, > sure. It doesn't address > most of the other issues with artwork being spread over several packages > in a confusing way... okay, that wasn't clear from the earlier emails. Why don't we take this one step at a time: Steps: 1. get rid of the bluecurve bits and fix up redhat-artwork to be noarch 2. start the package reorg for all of our artwork How does that sound? With regard to number 2 is there anyone outside of yourself who might have a good enough understanding of where all the art is to comment appropriately? thanks, -sv From jkeating at redhat.com Mon Feb 12 16:31:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 11:31:46 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: <20070212162413.GK11536@nostromo.devel.redhat.com> References: <20070212162413.GK11536@nostromo.devel.redhat.com> Message-ID: <200702121131.46606.jkeating@redhat.com> On Monday 12 February 2007 11:24, Bill Nottingham wrote: > Well, there has been plans of a two-stage merge. For anything that's > reasonably on the edges of Fedora (i.e., isn't a dependency of the world), > we could do moves before 'the big switch', which would be done in a one-off > basis as stated above. Well, not so much two-stage, but anything that wanted to move early and was a leaf node could. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 12 16:29:30 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 11:29:30 -0500 Subject: Why is redhat-artwork multi-lib? In-Reply-To: <1171297652.27965.99.camel@cutter> References: <45D081AF.3040508@redhat.com> <1171292951.27965.69.camel@cutter> <45D08457.5040506@redhat.com> <1171293392.27965.71.camel@cutter> <45D087CB.7090901@redhat.com> <1171296361.27965.82.camel@cutter> <1171296371.17054.25.camel@aglarond.local> <1171297122.27965.92.camel@cutter> <45D0953D.7000608@redhat.com> <1171297652.27965.99.camel@cutter> Message-ID: <20070212162930.GL11536@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > With regard to number 2 is there anyone outside of yourself who might > have a good enough understanding of where all the art is to comment > appropriately? redhat-artwork fedora-logos {gnome,echo,hicolor}-icon-theme kdeartwork-* desktop-backgrounds-* I'm probably missing something. If you're talking about fedora-logos, it includes support bits for anaconda, grub, syslinux, gdm, kdm, gnome-screensaver, GNOME & KDE splash screens, firstboot, the backgrounds capplet, and the GNOME & KDE menus. Bill From kevin at scrye.com Mon Feb 12 16:42:59 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 12 Feb 2007 09:42:59 -0700 Subject: simplistic questions about core/extras merge In-Reply-To: References: <45D05AB6.5070509@hhs.nl> <45D05BFD.50108@odu.neva.ru> <1171285500.3622.8.camel@mccallum.corsepiu.local> Message-ID: <20070212094259.13a7302f@ningauble.scrye.com> On Mon, 12 Feb 2007 14:52:23 +0100 j.w.r.degoede at hhs.nl ("Goede, J.W.R. de") wrote: > On Mon, 12 Feb 2007 14:04:59 +0100 > Ralf Corsepius wrote: > > On Mon, 2007-02-12 at 15:22 +0300, Dmitry Butskoy wrote: > > > Hans de Goede wrote: > > > > > > > most of the many open bug are purely a matter of not > > enough time > > > > getting invested into the package > > > > > > > > > +1 > > +1 > > > > Open up Core for community collaboration and > > co-maintenance! > > > > I'm glad people agree, now it would really help if people > would stop asking @redhat.com people to open-up as if this > is a unilateral thing, things need to come from two side > both from the @redhat.com people and from us. Agreed. > Hence I would like to see other FE contributers to join my > offer to help out @redhat.com with specific bz id's or > specific packages which which the @redhat.com people feel > comfortable opening up / could really use help with. I would be happy to do so as well... In particular with most of the core merge reviews I have done, since they are packages I use every day and understand pretty well. Feel free to contact me via email... Also, I see some core packages (xfsprogs comes to mind) where the maintainer asked for someone more interested in the package to step forward to maintain. I think thats great, as someone who uses/is more interested in a package will be able to give it more attention. > Regards, > > Hans kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon Feb 12 17:02:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 12 Feb 2007 11:02:37 -0600 Subject: simplistic questions about core/extras merge In-Reply-To: <200702121131.46606.jkeating@redhat.com> References: <20070212162413.GK11536@nostromo.devel.redhat.com> <200702121131.46606.jkeating@redhat.com> Message-ID: <1171299757.4003.11.camel@zod.rchland.ibm.com> On Mon, 2007-02-12 at 11:31 -0500, Jesse Keating wrote: > On Monday 12 February 2007 11:24, Bill Nottingham wrote: > > Well, there has been plans of a two-stage merge. For anything that's > > reasonably on the edges of Fedora (i.e., isn't a dependency of the world), > > we could do moves before 'the big switch', which would be done in a one-off > > basis as stated above. > > Well, not so much two-stage, but anything that wanted to move early and was a > leaf node could. Are we preserving the cvs history of this stuff? I _think_ the answer is yes, but I just wanted to clarify... josh From jwilson at redhat.com Mon Feb 12 17:03:37 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 12 Feb 2007 12:03:37 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: <20070212094259.13a7302f@ningauble.scrye.com> References: <20070212094259.13a7302f@ningauble.scrye.com> Message-ID: <200702121203.41144.jwilson@redhat.com> On Monday 12 February 2007 11:42, Kevin Fenzi wrote: > Also, I see some core packages (xfsprogs comes to mind) where the > maintainer asked for someone more interested in the package to step > forward to maintain. I think thats great, as someone who uses/is more > interested in a package will be able to give it more attention. Just an fyi, Eric Sandeen is planning on taking over xfsprogs. Eric came to Red Hat from SGI, and still actively works on the XFS code. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 12 17:04:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 12:04:01 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: <1171299757.4003.11.camel@zod.rchland.ibm.com> References: <20070212162413.GK11536@nostromo.devel.redhat.com> <200702121131.46606.jkeating@redhat.com> <1171299757.4003.11.camel@zod.rchland.ibm.com> Message-ID: <20070212170401.GA13117@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > Are we preserving the cvs history of this stuff? I _think_ the answer > is yes, but I just wanted to clarify... It is the plan. Bill From drago01 at gmail.com Mon Feb 12 17:21:59 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 12 Feb 2007 18:21:59 +0100 Subject: f7 test: time zone problem In-Reply-To: <1170863421.16292.2.camel@aglarond.local> References: <45C366A5.5040400@gmail.com> <200702021410.57505.jkeating@redhat.com> <1170444139.13309.34.camel@wombat.dlib.indiana.edu> <3adc77210702031359w41405ff1oac737558322a9381@mail.gmail.com> <45C5C5CF.8080508@gmail.com> <1170693533.5207.5.camel@aglarond.local> <45C9A7B1.4070304@gmail.com> <1170863421.16292.2.camel@aglarond.local> Message-ID: <45D0A237.20209@gmail.com> Jeremy Katz wrote: > On Wed, 2007-02-07 at 11:19 +0100, dragoran wrote: > >> Jeremy Katz wrote: >> >>> It would be somewhat helpful if people who are having problems booting >>> the live CD can file bugs including the output of lspci so that we can >>> try to run all of the problem cases down >>> >>> >> there is an other bug but I have no idea where to fill it (against what?)... >> the livecd uses a different timezone than my laptop. after rebooting it >> saves this time to the hwclock which causes a incorrect time when I boot >> back to fc6 and I have to set it back by hand. >> > > Just file it against distribution for now and have it block > Fedora7LiveCD > sorry I missed this mail filled bug #228323 but there is no "Fedora7LiveCD" only FC6LiveCDTracker so which bug should this block? > Jeremy > > From chitlesh at fedoraproject.org Mon Feb 12 18:19:49 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 12 Feb 2007 19:19:49 +0100 Subject: F7 KDE spin r2 In-Reply-To: <45D07F2F.6010506@math.unl.edu> References: <45D07F2F.6010506@math.unl.edu> Message-ID: <13dbfe4f0702121019q7d884133yfd98e8af7834c8d0@mail.gmail.com> On 2/12/07, Rex Dieter wrote: > Just updated: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE > to include more details. Feedback, criticism is welcome. > > Further, we'll be holding an informal irc meetings on #fedora-devel > Tuesdays @ 03:00 UTC (turns out to be Mon 9pm CST for me). If folks are > interested, but that time doesn't work for you, please post times that > work better for you at: > http://fedoraproject.org/wiki/Extras/SIGs/KDE Hello for some reason, I can't access the wiki: Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/MoinMoin/request.py", line 865, in run self.page.send_page(self, count_hit=1) File "/usr/lib/python2.3/site-packages/MoinMoin/Page.py", line 1104, in send_page request.user.addTrail(self.page_name) File "/usr/lib/python2.3/site-packages/MoinMoin/user.py", line 716, in addTrail if not (page.exists() and File "/usr/lib/python2.3/site-packages/MoinMoin/security.py", line 52, in return lambda pagename, Page=Page, request=request, attr=attr: Page(request, pagename).getACL(request).may(request, self.name, attr) File "/usr/lib/python2.3/site-packages/MoinMoin/wikiacl.py", line 200, in may is_group_member = request.dicts.has_member File "/usr/lib/python2.3/site-packages/MoinMoin/request.py", line 154, in __getattr__ self.dicts = self.initdicts() File "/usr/lib/python2.3/site-packages/MoinMoin/request.py", line 621, in initdicts dicts.scandicts() File "/usr/lib/python2.3/site-packages/MoinMoin/wikidicts.py", line 367, in scandicts self.groupdict[pagename] = oldgroupdict[pagename] KeyError: u'MarketingGroup' Well, I'll propose Tuesdays @ 20:00 UTC if you don't mind. Chitlesh -- http://clunixchit.blogspot.com From jjoe at flummiball.de Mon Feb 12 18:23:59 2007 From: jjoe at flummiball.de (Jonas G) Date: Mon, 12 Feb 2007 19:23:59 +0100 Subject: glade-- Message-ID: <45D0B0BF.8080209@flummiball.de> hi guys! Is there glade-- for FC6 in the reposity-tree? I want to create a gtkmm-project with glade but it says that i have to install glade-- first but i cannot find it with apt or yum?! thanks greetings from germany jonas From lamont at gurulabs.com Mon Feb 12 18:27:26 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Mon, 12 Feb 2007 11:27:26 -0700 Subject: F7 KDE spin r2 In-Reply-To: <13dbfe4f0702121019q7d884133yfd98e8af7834c8d0@mail.gmail.com> References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702121019q7d884133yfd98e8af7834c8d0@mail.gmail.com> Message-ID: <200702121127.33121.lamont@gurulabs.com> On Monday 12 February 2007 11:19am, Chitlesh GOORAH wrote: > On 2/12/07, Rex Dieter wrote: > > Just updated: > > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE > > to include more details. Feedback, criticism is welcome. > > > > Further, we'll be holding an informal irc meetings on #fedora-devel > > Tuesdays @ 03:00 UTC (turns out to be Mon 9pm CST for me). If folks are > > interested, but that time doesn't work for you, please post times that > > work better for you at: > > http://fedoraproject.org/wiki/Extras/SIGs/KDE > > Hello for some reason, I can't access the wiki: Same here: > Traceback (most recent call last): > File "/usr/lib/python2.3/site-packages/MoinMoin/request.py", line 865, in > run self.page.send_page(self, count_hit=1) > File "/usr/lib/python2.3/site-packages/MoinMoin/Page.py", line 1104, > in send_page > request.user.addTrail(self.page_name) > File "/usr/lib/python2.3/site-packages/MoinMoin/user.py", line 716, > in addTrail > if not (page.exists() and > File "/usr/lib/python2.3/site-packages/MoinMoin/security.py", line > 52, in > return lambda pagename, Page=Page, request=request, attr=attr: > Page(request, pagename).getACL(request).may(request, self.name, attr) > File "/usr/lib/python2.3/site-packages/MoinMoin/wikiacl.py", line 200, in > may is_group_member = request.dicts.has_member > File "/usr/lib/python2.3/site-packages/MoinMoin/request.py", line > 154, in __getattr__ > self.dicts = self.initdicts() > File "/usr/lib/python2.3/site-packages/MoinMoin/request.py", line > 621, in initdicts > dicts.scandicts() > File "/usr/lib/python2.3/site-packages/MoinMoin/wikidicts.py", line > 367, in scandicts > self.groupdict[pagename] = oldgroupdict[pagename] > KeyError: u'MarketingGroup' [snip] -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Mon Feb 12 18:33:22 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 12 Feb 2007 10:33:22 -0800 Subject: glade-- In-Reply-To: <45D0B0BF.8080209@flummiball.de> References: <45D0B0BF.8080209@flummiball.de> Message-ID: <45D0B2F2.3030806@poolshark.org> Jonas G wrote: > hi guys! > Is there glade-- for FC6 in the reposity-tree? I want to create a > gtkmm-project with glade but it says that i have to install glade-- > first but i cannot find it with apt or yum?! > > thanks > > greetings from germany > > jonas > I would recommend using the glade/libglademm combination instead. glademm is an old (unrelated) project that is not currently in Extras. From jjoe at flummiball.de Mon Feb 12 18:45:04 2007 From: jjoe at flummiball.de (Jonas G) Date: Mon, 12 Feb 2007 19:45:04 +0100 Subject: glade-- In-Reply-To: <45D0B2F2.3030806@poolshark.org> References: <45D0B0BF.8080209@flummiball.de> <45D0B2F2.3030806@poolshark.org> Message-ID: <45D0B5B0.6030608@flummiball.de> Denis Leroy wrote: > Jonas G wrote: >> hi guys! >> Is there glade-- for FC6 in the reposity-tree? I want to create a >> gtkmm-project with glade but it says that i have to install glade-- >> first but i cannot find it with apt or yum?! >> >> thanks >> >> greetings from germany >> >> jonas >> > > I would recommend using the glade/libglademm combination instead. > glademm is an old (unrelated) project that is not currently in Extras. > I have libglademm24(-devel) installed but theres only the command glade-2 available. When I click "Build" in galde-2 ther comes that error: Error running glade-- to generate the C++ source code. Check that you have glade-- installed and that it is in your PATH. Then try running 'glade-- ' in a terminal. Can anyone help me? greetings From jwboyer at jdub.homelinux.org Mon Feb 12 18:48:21 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 12 Feb 2007 12:48:21 -0600 Subject: simplistic questions about core/extras merge In-Reply-To: <20070212170401.GA13117@nostromo.devel.redhat.com> References: <20070212162413.GK11536@nostromo.devel.redhat.com> <200702121131.46606.jkeating@redhat.com> <1171299757.4003.11.camel@zod.rchland.ibm.com> <20070212170401.GA13117@nostromo.devel.redhat.com> Message-ID: <1171306101.4003.22.camel@zod.rchland.ibm.com> On Mon, 2007-02-12 at 12:04 -0500, Bill Nottingham wrote: > Josh Boyer (jwboyer at jdub.homelinux.org) said: > > Are we preserving the cvs history of this stuff? I _think_ the answer > > is yes, but I just wanted to clarify... > > It is the plan. Wait... but what about these "leaf" packages that want to move early? Have we had any of them actually move yet and preserve the history? josh From rdieter at fedoraproject.org Mon Feb 12 18:43:53 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 12:43:53 -0600 Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702121019q7d884133yfd98e8af7834c8d0@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > Hello for some reason, I can't access the wiki: Should be better now (or so I've heard). -- Rex From notting at redhat.com Mon Feb 12 19:25:02 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Feb 2007 14:25:02 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: <1171306101.4003.22.camel@zod.rchland.ibm.com> References: <20070212162413.GK11536@nostromo.devel.redhat.com> <200702121131.46606.jkeating@redhat.com> <1171299757.4003.11.camel@zod.rchland.ibm.com> <20070212170401.GA13117@nostromo.devel.redhat.com> <1171306101.4003.22.camel@zod.rchland.ibm.com> Message-ID: <20070212192502.GB15002@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > > It is the plan. > > Wait... but what about these "leaf" packages that want to move early? > Have we had any of them actually move yet and preserve the history? Not AFIAK. Most of the ones I've seen that have gotten through review (gzip, wget, etc) aren't leaf nodes. Bill From tibbs at math.uh.edu Mon Feb 12 19:49:11 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Feb 2007 13:49:11 -0600 Subject: simplistic questions about core/extras merge In-Reply-To: <20070212192502.GB15002@nostromo.devel.redhat.com> References: <20070212162413.GK11536@nostromo.devel.redhat.com> <200702121131.46606.jkeating@redhat.com> <1171299757.4003.11.camel@zod.rchland.ibm.com> <20070212170401.GA13117@nostromo.devel.redhat.com> <1171306101.4003.22.camel@zod.rchland.ibm.com> <20070212192502.GB15002@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> Not AFIAK. Most of the ones I've seen that have gotten through BN> review (gzip, wget, etc) aren't leaf nodes. But there were packages which previously went to Extras from Core; two examples I know of are exim and cyrus-imapd, and neither had their history preserved. - J< From jkeating at redhat.com Mon Feb 12 19:50:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 14:50:56 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: References: <20070212192502.GB15002@nostromo.devel.redhat.com> Message-ID: <200702121450.56280.jkeating@redhat.com> On Monday 12 February 2007 14:49, Jason L Tibbitts III wrote: > But there were packages which previously went to Extras from Core; two > examples I know of are exim and cyrus-imapd, and neither had their > history preserved. Correct. It wasn't much thought of then. Now we'd like to preserve history, and we'll have to come up with a good way to do that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Mon Feb 12 20:08:25 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 12 Feb 2007 12:08:25 -0800 Subject: glade-- In-Reply-To: <45D0B5B0.6030608@flummiball.de> References: <45D0B0BF.8080209@flummiball.de> <45D0B2F2.3030806@poolshark.org> <45D0B5B0.6030608@flummiball.de> Message-ID: <1171310905.4306.316.camel@localhost.localdomain> On Mon, 2007-02-12 at 19:45 +0100, Jonas G wrote: > Denis Leroy wrote: > > Jonas G wrote: > >> hi guys! > >> Is there glade-- for FC6 in the reposity-tree? I want to create a > >> gtkmm-project with glade but it says that i have to install glade-- > >> first but i cannot find it with apt or yum?! > >> > >> thanks > >> > >> greetings from germany > >> > >> jonas > >> > > > > I would recommend using the glade/libglademm combination instead. > > glademm is an old (unrelated) project that is not currently in Extras. > > > > I have libglademm24(-devel) installed but theres only the command > glade-2 available. When I click "Build" in galde-2 ther comes that error: > Error running glade-- to generate the C++ source code. > Check that you have glade-- installed and that it is in your PATH. > Then try running 'glade-- ' in a terminal. > > Can anyone help me? Denis is recommending that you don't use Build to generate a C++ source file. Instead, just save the project and then find the scratch.glade file. Put this in your project. Use the libglademm library to import the glade file and construct your GUI on the fly. -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 seg at haxxed.com Mon Feb 12 20:20:48 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 12 Feb 2007 14:20:48 -0600 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> Message-ID: <1171311648.25026.7.camel@localhost.localdomain> On Sat, 2007-02-10 at 21:25 -0500, Michel Salim wrote: > SWT applications (Eclipse, Azureus) runs fine against Sun JDK 6 on > Fedora Core 6; on Fedora 7, however, all of them produces a SIGSEGV > with the last native frame being libgobject-2.0.so.0. The last frame > on the Java stack is org.eclipse.swt.internal.gtk.OS._gtk_init_check Actually I'm seeing this on FC6 as well. However, only on x86_64. x86_64 Sun java, and x86_64 fedora packages. My i386 box works fine with the same (but 32bit) configuration. I tried using the same i386 Sun JVM and i386 Fedora packages (including Azureus) on the x86_64 box, but that didn't work either. Confusing. I might have missed something 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 chitlesh at fedoraproject.org Mon Feb 12 20:43:33 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 12 Feb 2007 21:43:33 +0100 Subject: F7 KDE spin r2 In-Reply-To: <45D07F2F.6010506@math.unl.edu> References: <45D07F2F.6010506@math.unl.edu> Message-ID: <13dbfe4f0702121243p73d7049ao9c7e2ce7435e829d@mail.gmail.com> On 2/12/07, Rex Dieter wrote: > Just updated: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE > to include more details. Feedback, criticism is welcome. > > Further, we'll be holding an informal irc meetings on #fedora-devel > Tuesdays @ 03:00 UTC (turns out to be Mon 9pm CST for me). If folks are > interested, but that time doesn't work for you, please post times that > work better for you at: > http://fedoraproject.org/wiki/Extras/SIGs/KDE Hello, is there already an agenda for the meeting ? perhaps we should lay down * who did what already and hence assign tasks afterwards * I've split ksirc from kdenetwork already for using konservation as default client. * kmenu entries policies ?? what should be done with respect to double kmenu entries and those entries who are on "Lost & found" ? obviously we should correct them. I can volunteer. * ........... Chitlesh -- http://clunixchit.blogspot.com From pemboa at gmail.com Mon Feb 12 21:10:12 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 12 Feb 2007 15:10:12 -0600 Subject: F7 KDE spin r2 In-Reply-To: <45D07F2F.6010506@math.unl.edu> References: <45D07F2F.6010506@math.unl.edu> Message-ID: <16de708d0702121310n67bd9a73scf86db362fb5fdaf@mail.gmail.com> On 2/12/07, Rex Dieter wrote: > Just updated: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE > to include more details. Feedback, criticism is welcome. > > Further, we'll be holding an informal irc meetings on #fedora-devel > Tuesdays @ 03:00 UTC (turns out to be Mon 9pm CST for me). If folks are > interested, but that time doesn't work for you, please post times that > work better for you at: > http://fedoraproject.org/wiki/Extras/SIGs/KDE > > -- Rex > I see ksirc is being placed as as a more optional package. Is there another IRC client being installed in the spin by default? Having an irc client (both text and GUI) could be very useful if one at least has network access on an F7 install gone bad. -- Fedora Core 6 and proud From chitlesh at fedoraproject.org Mon Feb 12 21:14:16 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 12 Feb 2007 22:14:16 +0100 Subject: F7 KDE spin r2 In-Reply-To: <16de708d0702121310n67bd9a73scf86db362fb5fdaf@mail.gmail.com> References: <45D07F2F.6010506@math.unl.edu> <16de708d0702121310n67bd9a73scf86db362fb5fdaf@mail.gmail.com> Message-ID: <13dbfe4f0702121314p116702xfaceb4d1af2c354e@mail.gmail.com> On 2/12/07, Arthur Pemberton wrote: > I see ksirc is being placed as as a more optional package. Is there > another IRC client being installed in the spin by default? Having an > irc client (both text and GUI) could be very useful if one at least > has network access on an F7 install gone bad. konversation :) Chitlesh -- http://clunixchit.blogspot.com From rdieter at fedoraproject.org Mon Feb 12 21:17:14 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 15:17:14 -0600 Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702121243p73d7049ao9c7e2ce7435e829d@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On 2/12/07, Rex Dieter wrote: >> Just updated: >> http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE >> to include more details. Feedback, criticism is welcome. >> >> Further, we'll be holding an informal irc meetings on #fedora-devel >> Tuesdays @ 03:00 UTC (turns out to be Mon 9pm CST for me). If folks are >> interested, but that time doesn't work for you, please post times that >> work better for you at: >> http://fedoraproject.org/wiki/Extras/SIGs/KDE > is there already an agenda for the meeting ? > perhaps we should lay down > * who did what already and hence assign tasks afterwards Informally, * lobby for more merge package reviews/reviewers * discuss items currently on wiki * assign tasks (most items are yet TODO) > * I've split ksirc from kdenetwork already for using konservation > as default client. That's a start. We should probably yank out ktalkd/wifi/kpf too. > what should be done with respect to double kmenu entries never seen that, explain? > and those entries who are on "Lost & found" ? which ones? -- Rex From rdieter at fedoraproject.org Mon Feb 12 21:17:41 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 15:17:41 -0600 Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <16de708d0702121310n67bd9a73scf86db362fb5fdaf@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > I see ksirc is being placed as as a more optional package. Is there > another IRC client being installed in the spin by default? konversation. -- Rex From pemboa at gmail.com Mon Feb 12 21:21:53 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 12 Feb 2007 15:21:53 -0600 Subject: F7 KDE spin r2 In-Reply-To: References: <45D07F2F.6010506@math.unl.edu> <16de708d0702121310n67bd9a73scf86db362fb5fdaf@mail.gmail.com> Message-ID: <16de708d0702121321y1c5c9a21n1cd2af81501573b6@mail.gmail.com> On 2/12/07, Rex Dieter wrote: > Arthur Pemberton wrote: > > > I see ksirc is being placed as as a more optional package. Is there > > another IRC client being installed in the spin by default? > > konversation. > Okay. My mistake. The fact that konversation was in parenthesis made it seem as if the two were the same. Are there any good textmode irc clients in Fedora land? Peace -- Fedora Core 6 and proud From buildsys at redhat.com Mon Feb 12 21:25:54 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 12 Feb 2007 16:25:54 -0500 Subject: rawhide report: 20070212 changes Message-ID: <200702122125.l1CLPsat032312@hs20-bc2-6.build.redhat.com> New package elilo ELILO linux boot loader for EFI-based systems New package iprutils Utilities for the IBM Power Linux RAID adapters New package librtas Libraries to provide access to RTAS calls and RTAS events. New package libunwind An unwinding library for ia64. New package ppc64-utils Linux/PPC64 specific utilities New package prctl Utility to perform process operations New package salinfo SAL info tool. New package yaboot Linux bootloader for Power Macintosh "New World" computers. Updated Packages: adaptx-0.9.13-4jpp.1.fc7 ------------------------ * Wed Jan 31 2007 Deepak Bhole 0.9.13-4jpp.1 - Fixed issues raised by rpmlint alacarte-0.11.2-1.svn20070212.fc7 --------------------------------- * Mon Feb 12 2007 Matthias Clasen - 0.11.2-1.svn20070212 - Bring back editing of the System menu autofs-1:5.0.1-0.rc3.18 ----------------------- * Sat Feb 10 2007 Ian Kent - 5.0.1-0.rc3.18 - update the "task done race" patch to fix a deadlock. - added URL tag. - removed obsoletes autofs-ldap. - replaced init directory paths with %{_initrddir} macro. * Fri Feb 09 2007 Ian Kent - 5.0.1-0.rc3.17 - make use of spaces and tabs in spec file consistent. - escape embedded macro text in %changelog. - eliminate redundant %version and %release. - remove redundant conditional check from %clean. - remove redundant exit from %preun. - correct %defattr spec. - remove empty %doc and redundant %dir misc lines. - combine program module spec lines into simpler one line form. bash-3.2-9.fc7 -------------- * Mon Feb 12 2007 Tim Waugh 3.2-9 - Rebuild to link with libtinfo instead of libncurses. createrepo-0.4.7-3.fc7 ---------------------- * Mon Feb 12 2007 Jesse Keating - 0.4.7-3 - Require yum-metadata-parser. enscript-1.6.4-7.fc7 -------------------- * Mon Feb 12 2007 Adam Tkac 1.6.4-7.fc7 - wrap_header patch had problems with around 70 characters long headers * Fri Jan 26 2007 Adam Tkac 1.6.4-6.fc7 - wrap_header patch has been improved * Tue Dec 19 2006 Adam Tkac 1.6.4-5.fc7 - fixed long-header patch filesystem-2.4.2-1.fc7 ---------------------- * Mon Feb 12 2007 Phil Knirsch - 2.4.2-1 - Added several missing unowned directories (#224052) - Tiny specfile cleanups gawk-3.1.5-15.fc7 ----------------- * Mon Feb 12 2007 Karel Zak 3.1.5-15 - fix #225777 - clean up spec file according to Fedora Merge Review suggestions (thanks to Dan Horak and Patrice Dumas) gcalctool-5.9.12-1.fc7 ---------------------- * Mon Feb 12 2007 Matthias Clasen - 5.9.12-1 - Update to 5.9.12 gcc-4.1.1-57 ------------ * Sun Feb 11 2007 Jakub Jelinek 4.1.1-57 - package up ammintrin.h on i386/x86_64 - fix AMDfam10 testcases (H.J. Lu) - fix f951 assert accessing memory after free (H.J. Lu, PR fortran/27351) * Sat Feb 10 2007 Jakub Jelinek 4.1.1-56 - update from gcc-4_1-branch (-r121479:121738) - PRs c++/29487, target/29487, target/30370 - merge gomp fixes from gcc-4_2-branch (-r121689:121690) PR c++/30703 - add AMDfam10 support (Harsha Jagasia, #222897) - set build_ada to 1 on alpha (#224247) - regenerate libjava.util.TimeZone data from tzdata2007a (#227888) gdm-1:2.17.6-4.fc7 ------------------ * Mon Feb 12 2007 Matthias Clasen - 1:2.17.6-4 - Reuse existing sessions without asking - Don't show failsafe sessions glibc-2.5.90-17 --------------- * Sun Feb 11 2007 Jakub Jelinek 2.5.90-17 - RFC2671 support in resolver (#205842) - fix strptime (BZ#3944) - fix regcomp with REG_NEWLINE (BZ#3957) - fix pthread_mutex_timedlock on x86_64 (#228103) gnome-keyring-0.7.91-1.fc7 -------------------------- * Mon Feb 12 2007 Matthias Clasen - 0.7.91-1 - Update to 0.7.91 gnome-media-2.17.91-1.fc7 ------------------------- * Mon Feb 12 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gnome-speech-0.4.9-1.fc7 ------------------------ * Sun Feb 11 2007 Matthias Clasen - 0.4.9-1 - Update to 0.4.9 gnome-themes-2.17.91-1.fc7 -------------------------- * Mon Feb 12 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 kexec-tools-1.101-60.fc7 ------------------------ * Mon Feb 12 2007 Neil Horman - 1.101-60.fc7 - Fixing up file permissions on kdump.conf (bz 228137) libpng-2:1.2.16-1.fc7 --------------------- * Mon Feb 12 2007 Tom Lane 2:1.2.16-1 - Update to libpng 1.2.16 Resolves: #211705, #216706, #227334 - Separate libpng.a into a -static subpackage - Other minor packaging fixes per Fedora merge review Resolves: #226038 libsoup-2.2.100-1.fc7 --------------------- * Mon Feb 12 2007 Matthew Barnes - 2.2.100-1 - Update to 2.2.100 logwatch-7.3.2-9.fc7 -------------------- * Mon Feb 12 2007 Ivana Varekova 7.3.2-9 - Resolves: 228258 logwatch warns about dhcdbd subscripton enabled - add xntpd, up2date and automount services mrtg-2.15.1-1 ------------- * Mon Feb 12 2007 Miloslav Trmac - 2.15.1-1 - Update to mrtg-2.15.1 ncurses-5.6-4.20070210.fc7 -------------------------- * Mon Feb 12 2007 Miroslav Lichvar 5.6-4.20070210 - update to patch 20070210 - generate separate terminfo library - move static libraries to -static subpackage - avoid unnecessary linking with libdl opensp-1.5.2-4.fc7 ------------------ * Mon Feb 12 2007 Tim Waugh 1.5.2-4 - Fixed build root. - Give IDs to nodes in the release notes source to prevent releasenotes.html having multilib conflicts (bug #228320). orca-2.17.91-1.fc7 ------------------ * Sun Feb 11 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 policycoreutils-2.0.1-1.fc7 --------------------------- * Wed Feb 07 2007 Dan Walsh 2.0.0-1 - Update to upstream * Merged new audit2allow from Karl MacMillan. This audit2allow depends on the new sepolgen python module. Note that you must run the sepolgen-ifgen tool to generate the data needed by audit2allow to generate refpolicy. * Fixed newrole non-pam build. - Fix Changelog and spelling error in man page selinux-policy-2.5.3-1.fc7 -------------------------- * Sun Feb 11 2007 Dan Walsh 2.5.3-7 - smartmontools-1:5.36-7.fc7 -------------------------- * Mon Feb 12 2007 Tomas Mraz - 1:5.36-7 - redirect service script output to null (#224566) * Sun Feb 11 2007 Florian La Roche - 1:5.36-6 - make sure the preun script does not fail sysstat-7.0.4-1.fc7 ------------------- * Mon Feb 12 2007 Ivana Varekova - 7.0.4-1 - update to 7.0.4 - spec file cleanup tcsh-6.14-14 ------------ * Mon Feb 12 2007 Miloslav Trmac - 6.14-14 - Link to libtinfo instead of libncurses thunderbird-1.5.0.9-8.fc7 ------------------------- * Mon Feb 12 2007 Martin Stransky 1.5.0.9-8 - added fix for #227406: garbage characters on some websites (when pango is disabled) vim-2:7.0.192-1.fc7 ------------------- * Mon Feb 12 2007 Karsten Hopp 7.0.192-1 - patchlevel 192 - test fix for highlighting problems with curly brackets in #define (#203577) wget-1.10.2-15.fc7 ------------------ * Mon Feb 12 2007 Karsten Hopp 1.10.2-15 - fix discarding of expired cookies - escape non-printable characters - drop to11 patch for now (#223754, #227853, #227498) zenity-2.17.91-1.fc7 -------------------- * Mon Feb 12 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 Broken deps for s390 ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.s390 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.s390 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.s390 requires libtk8.5.so setools-gui - 3.0-3.fc7.s390 requires libtk8.5.so setools-gui - 3.0-3.fc7.s390 requires libtcl8.5.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 tkinter - 2.5-10.fc7.s390 requires libtk8.5.so tkinter - 2.5-10.fc7.s390 requires libtcl8.5.so Broken deps for x86_64 ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.x86_64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.x86_64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.x86_64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.x86_64 requires libtcl8.5.so()(64bit) setools-gui - 3.0-3.fc7.x86_64 requires libtk8.5.so()(64bit) tkinter - 2.5-10.fc7.x86_64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.x86_64 requires libtk8.5.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.ppc64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ppc64 requires libtk8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ppc64 requires libtcl8.5.so()(64bit) setools-gui - 3.0-3.fc7.ppc64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.ppc64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ppc64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ppc64 requires libtk8.5.so()(64bit) Broken deps for ia64 ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.ia64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ia64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ia64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.ia64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.ia64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ia64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ia64 requires libtk8.5.so()(64bit) Broken deps for i386 ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.i386 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.i386 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.i386 requires libtk8.5.so setools-gui - 3.0-3.fc7.i386 requires libtk8.5.so setools-gui - 3.0-3.fc7.i386 requires libtcl8.5.so tkinter - 2.5-10.fc7.i386 requires libtk8.5.so tkinter - 2.5-10.fc7.i386 requires libtcl8.5.so Broken deps for s390x ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.s390x requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.s390x requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.s390x requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.s390x requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.s390x requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.s390x requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.s390x requires libtk8.5.so()(64bit) Broken deps for ppc ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.ppc requires libtcl8.5.so ruby-libs - 1.8.5.12-1.fc7.ppc requires libtcl8.5.so ruby-libs - 1.8.5.12-1.fc7.ppc requires libtk8.5.so setools-gui - 3.0-3.fc7.ppc requires libtk8.5.so setools-gui - 3.0-3.fc7.ppc requires libtcl8.5.so tkinter - 2.5-10.fc7.ppc requires libtk8.5.so tkinter - 2.5-10.fc7.ppc requires libtcl8.5.so From jkeating at redhat.com Mon Feb 12 21:26:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Feb 2007 16:26:57 -0500 Subject: F7 KDE spin r2 In-Reply-To: <16de708d0702121321y1c5c9a21n1cd2af81501573b6@mail.gmail.com> References: <45D07F2F.6010506@math.unl.edu> <16de708d0702121321y1c5c9a21n1cd2af81501573b6@mail.gmail.com> Message-ID: <200702121626.57728.jkeating@redhat.com> On Monday 12 February 2007 16:21, Arthur Pemberton wrote: > Are there any good textmode irc clients in Fedora land? irssi -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Mon Feb 12 21:29:17 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 12 Feb 2007 22:29:17 +0100 Subject: F7 KDE spin r2 In-Reply-To: References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702121243p73d7049ao9c7e2ce7435e829d@mail.gmail.com> Message-ID: <13dbfe4f0702121329x1e790f9eq4282e58ff594477@mail.gmail.com> On 2/12/07, Rex Dieter wrote: > > * I've split ksirc from kdenetwork already for using konservation > > as default client. > > That's a start. We should probably yank out ktalkd/wifi/kpf too. Ok, I can volunteer to work on the split for kdenetwork package. However, I don't see a reason behind pulling kwifimanager of the hook. > > what should be done with respect to double kmenu entries > > never seen that, explain? Well, qucs for example :) > > and those entries who are on "Lost & found" ? > > which ones? I have only one example: kicad. I'll be firing a RFE with a patch soon :) Chitlesh -- http://clunixchit.blogspot.com From rdieter at fedoraproject.org Mon Feb 12 21:32:48 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Mon, 12 Feb 2007 15:32:48 -0600 Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702121243p73d7049ao9c7e2ce7435e829d@mail.gmail.com> <13dbfe4f0702121329x1e790f9eq4282e58ff594477@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On 2/12/07, Rex Dieter wrote: >> > * I've split ksirc from kdenetwork already for using konservation >> > as default client. >> >> That's a start. We should probably yank out ktalkd/wifi/kpf too. > > Ok, I can volunteer to work on the split for kdenetwork package. > However, I don't see a reason behind pulling kwifimanager of the hook. It duplicates NetworkManager functionality. >> > what should be done with respect to double kmenu entries ... > Well, qucs for example :) > >> > and those entries who are on "Lost & found" ? ... > I have only one example: kicad. I'll be firing a RFE with a patch soon :) Both of these are likely explained that they're using bad/invalid .desktop Categories, unless I'm missing something. -- Rex From michel.salim at gmail.com Mon Feb 12 22:09:18 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 12 Feb 2007 17:09:18 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <1171311648.25026.7.camel@localhost.localdomain> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> Message-ID: <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> 2007/2/12, Callum Lerwick : > On Sat, 2007-02-10 at 21:25 -0500, Michel Salim wrote: > > SWT applications (Eclipse, Azureus) runs fine against Sun JDK 6 on > > Fedora Core 6; on Fedora 7, however, all of them produces a SIGSEGV > > with the last native frame being libgobject-2.0.so.0. The last frame > > on the Java stack is org.eclipse.swt.internal.gtk.OS._gtk_init_check > > Actually I'm seeing this on FC6 as well. However, only on x86_64. x86_64 > Sun java, and x86_64 fedora packages. My i386 box works fine with the > same (but 32bit) configuration. I tried using the same i386 Sun JVM and > i386 Fedora packages (including Azureus) on the x86_64 box, but that > didn't work either. Confusing. I might have missed something though... > Slightly different use case than mine; when running against Sun Java I normally use the binary tarballs from upstream, not the Fedora-supplied RPMs. I *did* try running Fedora Eclipse against Sun Java (by mistake; the path to the JVM got added in front of /usr/bin when I reorganized my login scripts) and it did produce the same error. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From michel.salim at gmail.com Mon Feb 12 22:34:19 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 12 Feb 2007 17:34:19 -0500 Subject: simplistic questions about core/extras merge In-Reply-To: <45D05AB6.5070509@hhs.nl> References: <45D05AB6.5070509@hhs.nl> Message-ID: <883cfe6d0702121434x48fd9cb7w442d88f9dad86d59@mail.gmail.com> 2007/2/12, Hans de Goede : > > Let me put my money where my mouth is, if any core package maintainer > would like a hand and is serious about this. Then drop me a mail with a > couple of BZ id's you would like a hand with, or a package name for > which you want me to go through bugzilla and fix any bugs against that > package in general. Note you should be willing to treat me as a fellow > developer and not as some kinda newbie (which I'm not). > How about a Wiki page? -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From mike at miketc.com Tue Feb 13 01:18:09 2007 From: mike at miketc.com (Mike Chambers) Date: Mon, 12 Feb 2007 19:18:09 -0600 Subject: Announcing repoman - PyGTK yum repo manager In-Reply-To: <1171141232.3234.0.camel@scrappy.miketc.com> References: <1170627996.7629.7.camel@mortise.boston.redhat.com> <45CC133A.8050902@redhat.com> <1171138744.3250.13.camel@mortise.boston.redhat.com> <1171141232.3234.0.camel@scrappy.miketc.com> Message-ID: <1171329490.13838.1.camel@scrappy.miketc.com> On Sat, 2007-02-10 at 15:00 -0600, Mike Chambers wrote: > On Sat, 2007-02-10 at 15:19 -0500, David Cantrell wrote: > > > Applied in repoman-0.6, which is available at: > > > > http://www.boston.burdell.org/repoman/ > > I get this error (as well as last version) when trying to run repoman.. > > Component: Repository Manager > Summary: TBdc86dff1 interface.py:70:__init__:AttributeError: 'NoneType' > object has no attribute 'isEnabled' > > Traceback (most recent call last): > File "/usr/sbin/repoman", line 31, in > ui = RepoMan() > File "/usr/lib/python2.5/site-packages/repoman/interface.py", line > 522, in __init__ > self.trackingPage = TrackingPage(self) > File "/usr/lib/python2.5/site-packages/repoman/interface.py", line 70, > in __init__ > if self.repos.getStanzaByName("updates-testing").isEnabled(): > AttributeError: 'NoneType' object has no attribute 'isEnabled' > > Local variables in innermost frame: > interface: > self: This has since been fixed and works now *yay*!. BUT... When going to the repo list and adding/removing/editing and such, get a permissions error below.. Failed writing new /etc/yum.repos.d/cityfan.repo repository file. Make sure you have the correct permissions to write repository files. That usually means having superuser permissions on the system. Yet I *was asked* for root password (console helper?) and was given. So why is it having a permissions error? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From seg at haxxed.com Mon Feb 12 20:37:12 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 12 Feb 2007 14:37:12 -0600 Subject: simplistic questions about core/extras merge In-Reply-To: References: Message-ID: <1171312632.25026.16.camel@localhost.localdomain> On Mon, 2007-02-12 at 07:02 -0500, Max Spevack wrote: > 3) Internal RH developers who don't pay much attention to Fedora at all, > aside from what they are "forced" to do. I can't speak for what trouble or drama this may cause within Red Hat, but from the community's point of view, we're much better off if this kind of people are encouraged to just let go of whatever packages they're not interested in maintaining to someone who has an honest interest in them. If they're not interested in Fedora, they shouldn't have to bother even getting a Fedora account. There's been some core package orphaning going on already. -------------- 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 rc040203 at freenet.de Tue Feb 13 06:16:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 07:16:19 +0100 Subject: simplistic questions about core/extras merge In-Reply-To: <1171312632.25026.16.camel@localhost.localdomain> References: <1171312632.25026.16.camel@localhost.localdomain> Message-ID: <1171347379.3622.119.camel@mccallum.corsepiu.local> On Mon, 2007-02-12 at 14:37 -0600, Callum Lerwick wrote: > On Mon, 2007-02-12 at 07:02 -0500, Max Spevack wrote: > > 3) Internal RH developers who don't pay much attention to Fedora at all, > > aside from what they are "forced" to do. > > I can't speak for what trouble or drama this may cause within Red Hat, Right, this is Red Hat management problem. They will have to decide on what to do and we, the community will have to watch for what will happen. > but from the community's point of view, we're much better off if this > kind of people are encouraged to just let go of whatever packages > they're not interested in maintaining to someone who has an honest > interest in them. I'd rather not see this happening, firstly, because this won't always be applicable (technical complexity) and in second place, because this it is a double-sided sword (outsourcing). I'd prefer RH'd devs to start opening their packages and collaborate with the community on their packages - IMO, both sides can only mutually benefit from this in longer terms. Ralf From buildsys at redhat.com Tue Feb 13 10:49:14 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 13 Feb 2007 05:49:14 -0500 Subject: rawhide report: 20070213 changes Message-ID: <200702131049.l1DAnEKc003215@hs20-bc2-6.build.redhat.com> Updated Packages: ORBit2-2.14.6-1.fc7 ------------------- * Mon Feb 12 2007 Matthias Clasen - 2.14.6-1 - Update to 2.14.6 alacarte-0.11.3-2.fc7 --------------------- * Tue Feb 13 2007 Matthias Clasen - 0.11.3-2 - Update to 0.11.3 anthy-8607-1.fc7 ---------------- * Tue Feb 13 2007 Akira TAGOH - 8607-1 - New upstream release. - correct doc installation. (#228311) at-spi-1.17.0-1.fc7 ------------------- * Tue Feb 13 2007 Matthias Clasen - 1.17.0-1 - Update to 1.17.0 atk-1.17.0-1.fc7 ---------------- * Tue Feb 13 2007 Matthias Clasen - 1.17.0-1 - Update to 1.17.0 cracklib-2.8.9-9 ---------------- * Mon Feb 12 2007 Nalin Dahyabhai - 2.8.9-9 - drop final "." from summaries (Jef Spaleta, #225659) - drop static library from -devel subpackage (Jef Spaleta, #225659) - note that the most recently-added wordlist came from bugzilla (#225659) - remove explicit dependency on gzip, as it's implicit (Jef Spaleta, #225659) - convert %triggerpostun to not use a shell as an interpreter (#225659) dtach-0.7-1.2.3 --------------- * Sat Feb 03 2007 Jef Spaleta - 0.7-1.2.3 - Specfile clean up for merge review eog-2.17.91-1.fc7 ----------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 evolution-2.9.91-1.fc7 ---------------------- * Mon Feb 12 2007 Matthew Barnes - 2.9.91-1.fc7 - Update to 2.9.91 - Require gtkhtml3 >= 3.13.6. - Add files for new imap-features plugin. - Add flag to disable deprecated Pango symbols. - Remove patch for GNOME bug #357216 (fixed upstream). - Remove patch for GNOME bug #359979 (fixed upstream). * Fri Jan 26 2007 Matthew Barnes - 2.9.5-4.fc7 - Compile with the -fno-strict-aliasing flag, which will hopefully improve reliability until the illegal type-punning is fixed (RH bug #224552). * Sun Jan 21 2007 Matthew Barnes - 2.9.5-3.fc7 - Revise evolution-2.7.1-no-gnome-common.patch so that we no longer have to run autoconf before building. - Revise evolution-2.5.4-fix-conduit-dir.patch so that we no longer have to run automake before building. evolution-data-server-1.9.91-1.fc7 ---------------------------------- * Mon Feb 12 2007 Matthew Barnes - 1.9.91-1.fc7 - Update to 1.9.91 - Add flag to disable deprecated Pango symbols. - Remove patch for GNOME bug #359979 (fixed upstream). * Sun Jan 21 2007 Matthew Barnes - 1.9.5-4.fc7 - Revise evolution-data-server-1.8.0-no-gnome-common.patch so that we no longer have to run autoconf before building. evolution-webcal-2.9.91-1.fc7 ----------------------------- * Mon Feb 12 2007 Matthew Barnes - 2.9.91-1.fc7 - Update to 2.9.91 file-roller-2.17.91-1.fc7 ------------------------- * Mon Feb 12 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 firstboot-1.4.30-1.fc7 ---------------------- * Mon Feb 12 2007 Chris Lumens 1.4.30-1 - Focus the next button by default (#227867). - Enable fullscreen mode again; scale sidebar graphics (#211198). - Bring spec file more in line with the packaging guidelines. gail-1.17.0-1.fc7 ----------------- * Tue Feb 13 2007 Matthias Clasen - 1.17.0-1 - Update to 1.17.0 gnome-icon-theme-2.17.91-1.fc7 ------------------------------ * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gnome-panel-2.17.91-5.fc7 ------------------------- * Tue Feb 13 2007 Matthias Clasen 2.17.91-5 - Update to 2.17.91 gnome-vfs2-2.17.91-1.fc7 ------------------------ * Mon Feb 12 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gtk2-engines-2.9.3-1.fc7 ------------------------ * Mon Feb 12 2007 Matthias Clasen - 2.9.3-1 - Update to 2.9.3 gtkhtml3-3.13.91-1.fc7 ---------------------- * Mon Feb 12 2007 Matthew Barnes - 3.13.91-1.fc7 - Update to 3.13.91 - Add flag to disable deprecated Pango symbols. - Remove patch for GNOME bug #394182 (fixed upstream). junit-3.8.2-3jpp.1.fc7 ---------------------- * Mon Feb 12 2007 Thomas Fitzsimmons - 3.8.2-3jpp.1.fc7 - Add dist tag * Mon Feb 12 2007 Thomas Fitzsimmons - 3.8.2-3jpp.1 - Committed on behalf of Tania Bento - Update per Fedora review process - Resolves rhbz#225954 kernel-2.6.20-1.2925.fc7 ------------------------ * Mon Feb 12 2007 Kristian H??gsberg - Update firewire patch with latest usptream changes. * Mon Feb 05 2007 Dave Jones - Fix attr2 corruption with btree data extents libgtop2-2.14.7-1.fc7 --------------------- * Mon Feb 12 2007 Matthias Clasen - 2.14.7-1 - Update to 2.14.7 libwnck-2.17.91-1.fc7 --------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 mcstrans-0.2.2-1.fc7 -------------------- * Mon Feb 12 2007 Dan Walsh 0.2.2-1 - Additional fix to handle ssh root/sysadm_r/s0:c1,c2 Resolves: #224637 nautilus-2.17.91-1.fc7 ---------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 pirut-1.2.11-1.fc7 ------------------ * Fri Feb 09 2007 James Bowes - 1.2.11-1 - Catch an error case (katzj, #221681) - Require gnome-session for /etc/xdg/autostart - Use the standard buildroot scim-1.4.5-8.fc7 ---------------- * Mon Feb 12 2007 Jens Petersen - 1.4.5-8 - separate gtk immodule out to a separate subpackage - update icons with improvements by Andy Fitzsimon - add functions to xinput script to test for presence of immodules * Fri Dec 15 2006 Jens Petersen - 1.4.5-7 - improve scim_panel-observe-workarea-xprop-204442.patch to autosnap within desktop workarea (#204442) - add scim_panel_gtk-settle-toolbar-after-drag.patch to autosnap toolbar after dragging - improve initial-locale-hotkey-186861.patch not to set next/previous factory and show menu hotkeys by default (#219247) - remove show factory menu hotkey and add super and hyper as valid modifiers in scim-system-default-config.patch - improve scim-1.4.5-panel-menu-fixes.patch to correctly name recently used factories for same language (#217324) * Fri Dec 01 2006 Jens Petersen - 1.4.5-6 - fix scim-restart quoting for pkill -f - rename scim-turn-off-snooper.patch to scim-gtkimm-default-snooper-off-213796.patch syslinux-3.36-1.fc7 ------------------- * Mon Feb 12 2007 Florian La Roche - 3.36-1 - update to 3.36 xorg-x11-proto-devel-7.2-1.fc7 ------------------------------ * Mon Feb 12 2007 Adam Jackson 7.2-1 - randrproto 1.2 - Superstition bump to 7.2 Broken deps for ia64 ---------------------------------------------------------- firstboot-tui - 1.4.30-1.fc7.noarch requires system-config-network-tui. postgresql-pltcl - 8.2.3-1.fc7.ia64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ia64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ia64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.ia64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.ia64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ia64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ia64 requires libtk8.5.so()(64bit) Broken deps for i386 ---------------------------------------------------------- firstboot-tui - 1.4.30-1.fc7.noarch requires system-config-network-tui. postgresql-pltcl - 8.2.3-1.fc7.i386 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.i386 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.i386 requires libtk8.5.so setools-gui - 3.0-3.fc7.i386 requires libtk8.5.so setools-gui - 3.0-3.fc7.i386 requires libtcl8.5.so tkinter - 2.5-10.fc7.i386 requires libtk8.5.so tkinter - 2.5-10.fc7.i386 requires libtcl8.5.so Broken deps for s390 ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.s390 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.s390 requires libtcl8.5.so ruby-tcltk - 1.8.5.12-1.fc7.s390 requires libtk8.5.so setools-gui - 3.0-3.fc7.s390 requires libtk8.5.so setools-gui - 3.0-3.fc7.s390 requires libtcl8.5.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 tkinter - 2.5-10.fc7.s390 requires libtk8.5.so tkinter - 2.5-10.fc7.s390 requires libtcl8.5.so Broken deps for ppc64 ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.ppc64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ppc64 requires libtk8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.ppc64 requires libtcl8.5.so()(64bit) setools-gui - 3.0-3.fc7.ppc64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.ppc64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ppc64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.ppc64 requires libtk8.5.so()(64bit) Broken deps for ppc ---------------------------------------------------------- firstboot-tui - 1.4.30-1.fc7.noarch requires system-config-network-tui. postgresql-pltcl - 8.2.3-1.fc7.ppc requires libtcl8.5.so ruby-libs - 1.8.5.12-1.fc7.ppc requires libtcl8.5.so ruby-libs - 1.8.5.12-1.fc7.ppc requires libtk8.5.so setools-gui - 3.0-3.fc7.ppc requires libtk8.5.so setools-gui - 3.0-3.fc7.ppc requires libtcl8.5.so tkinter - 2.5-10.fc7.ppc requires libtk8.5.so tkinter - 2.5-10.fc7.ppc requires libtcl8.5.so Broken deps for s390x ---------------------------------------------------------- postgresql-pltcl - 8.2.3-1.fc7.s390x requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.s390x requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.s390x requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.s390x requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.s390x requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.s390x requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.s390x requires libtk8.5.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- firstboot-tui - 1.4.30-1.fc7.noarch requires system-config-network-tui. postgresql-pltcl - 8.2.3-1.fc7.x86_64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.x86_64 requires libtcl8.5.so()(64bit) ruby-tcltk - 1.8.5.12-1.fc7.x86_64 requires libtk8.5.so()(64bit) setools-gui - 3.0-3.fc7.x86_64 requires libtcl8.5.so()(64bit) setools-gui - 3.0-3.fc7.x86_64 requires libtk8.5.so()(64bit) tkinter - 2.5-10.fc7.x86_64 requires libtcl8.5.so()(64bit) tkinter - 2.5-10.fc7.x86_64 requires libtk8.5.so()(64bit) From kloczek at zie.pg.gda.pl Tue Feb 13 10:51:29 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Tue, 13 Feb 2007 11:51:29 +0100 Subject: rawhide report: 20070206 changes In-Reply-To: <200702061103.l16B3c8v026093@hs20-bc2-6.build.redhat.com> References: <200702061103.l16B3c8v026093@hs20-bc2-6.build.redhat.com> Message-ID: <1171363889.31079.5.camel@kloczek01.pracownicy.zie> Dnia 06-02-2007, wto o godzinie 06:03 -0500, buildsys at redhat.com napisa?(a): [..] > GConf2-2.16.0-6.fc7 > ------------------- > * Mon Feb 05 2007 Matthias Clasen - 2.16.0-6 > - Split off a -gtk subpackage to reduce dependencies IMO this split is kind of nonsens. Even if this split have some sense it is not all/it is buggy. Why this split is buggy ? Because gnome-session requires and uses gconf-sanity-check-2 program (IIRC check for availability in build enviromet for gconf-sanity-check-2 is performed in autoconf suit of gnome-session and grep on gnome-session will show from where it is runed/used by gnome-session). So .. this split without add "Requires: GConf2-gtk" and "BuildRequires: GConf2-gtk" to gnome-session is plain bug. Why this split is kind of nonsens ? Because IIRC there is no program which uses GConf2 and not uses gtk+. So .. if there is no packages which uses GConf2 and not uses gtk+ .. better will be reverte this split and keep gconf-sanity-check-2 in GConf2 binary package. kloczek From mclasen at redhat.com Tue Feb 13 13:00:42 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 13 Feb 2007 08:00:42 -0500 Subject: rawhide report: 20070206 changes In-Reply-To: <1171363889.31079.5.camel@kloczek01.pracownicy.zie> References: <200702061103.l16B3c8v026093@hs20-bc2-6.build.redhat.com> <1171363889.31079.5.camel@kloczek01.pracownicy.zie> Message-ID: <1171371642.3256.1.camel@dhcp83-33.boston.redhat.com> On Tue, 2007-02-13 at 11:51 +0100, Tomasz K?oczko wrote: > Dnia 06-02-2007, wto o godzinie 06:03 -0500, buildsys at redhat.com > napisa?(a): > [..] > > GConf2-2.16.0-6.fc7 > > ------------------- > > * Mon Feb 05 2007 Matthias Clasen - 2.16.0-6 > > - Split off a -gtk subpackage to reduce dependencies > > IMO this split is kind of nonsens. Even if this split have some sense it > is not all/it is buggy. > > Why this split is buggy ? Because gnome-session requires and uses > gconf-sanity-check-2 program (IIRC check for availability in build > enviromet for gconf-sanity-check-2 is performed in autoconf suit of > gnome-session and grep on gnome-session will show from where it is > runed/used by gnome-session). > So .. this split without add "Requires: GConf2-gtk" and "BuildRequires: > GConf2-gtk" to gnome-session is plain bug. Why don't you check the gnome-session spec before sending uninformed mail ? I did add just those, at the same time as I did the split. > > Why this split is kind of nonsens ? Because IIRC there is no program > which uses GConf2 and not uses gtk+. > > So .. if there is no packages which uses GConf2 and not uses gtk+ .. > better will be reverte this split and keep gconf-sanity-check-2 in > GConf2 binary package. Do you think I did that just for fun ? I have split it off because I have been asked by people who want to use GConf with gtk+. From chitlesh at fedoraproject.org Tue Feb 13 17:53:33 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 13 Feb 2007 18:53:33 +0100 Subject: F7 KDE spin r2 In-Reply-To: <45D07F2F.6010506@math.unl.edu> References: <45D07F2F.6010506@math.unl.edu> Message-ID: <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> On 2/12/07, Rex Dieter wrote: > Further, we'll be holding an informal irc meetings on #fedora-devel > Tuesdays @ 03:00 UTC (turns out to be Mon 9pm CST for me). If folks are > interested, but that time doesn't work for you, please post times that > work better for you at: > http://fedoraproject.org/wiki/Extras/SIGs/KDE So when will be the first meeting be held ? Chitlesh -- http://clunixchit.blogspot.com From janina at rednote.net Tue Feb 13 17:55:24 2007 From: janina at rednote.net (Janina Sajka) Date: Tue, 13 Feb 2007 12:55:24 -0500 Subject: Firefox 3 In-Reply-To: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> Message-ID: <20070213175524.GA7375@rednote.net> I'm responding via the list , as it's the only email I have for you ... MATSUURA Takanori writes: > Hi all, > > I put firefox-trunk SRPM based on current fedora rawhide one at > http://homepage2.nifty.com/t-matsuu/install-memo/fc/ > This has been very helpful, and I have been bui9lding and publishing binaries based on these src.rpm files @SpeakupModified.Org. However, there's now a problem where the src.rpms are not retrievable via the URI provided. The pointers suggest a late January src.rpm, and another on February 10, both of which have been yielding 404 errors. Janina From kevin.kofler at chello.at Tue Feb 13 18:16:08 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 13 Feb 2007 18:16:08 +0000 (UTC) Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > So when will be the first meeting be held ? The first one was at 0300 UTC (04:00 (AM) CET), but there will be another one tonight at the time you suggested: 2000 UTC (21:00 CET). Kevin Kofler From chitlesh at fedoraproject.org Tue Feb 13 18:19:06 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 13 Feb 2007 19:19:06 +0100 Subject: F7 KDE spin r2 In-Reply-To: References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> Message-ID: <13dbfe4f0702131019k47203c61td4416e08fd2109f8@mail.gmail.com> On 2/13/07, Kevin Kofler wrote: > The first one was at 0300 UTC (04:00 (AM) CET), but there will be another one > tonight at the time you suggested: 2000 UTC (21:00 CET). > > Kevin Kofler Ah ok :) So someone who was present can post their irc log for the meeting ? thanks Chitlesh -- http://clunixchit.blogspot.com From lamont at gurulabs.com Tue Feb 13 18:28:32 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Tue, 13 Feb 2007 11:28:32 -0700 Subject: F7 KDE spin r2 In-Reply-To: References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> Message-ID: <200702131128.32843.lamont@gurulabs.com> On Tuesday 13 February 2007 11:16am, Kevin Kofler wrote: > Chitlesh GOORAH fedoraproject.org> writes: > > So when will be the first meeting be held ? > > The first one was at 0300 UTC (04:00 (AM) CET), but there will be another > one tonight at the time you suggested: 2000 UTC (21:00 CET). Will that also be on #fedora-devel (freenode), or is there another channel to use? -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michel.salim at gmail.com Tue Feb 13 18:28:05 2007 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 13 Feb 2007 13:28:05 -0500 Subject: /tmp filling up Message-ID: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> Has anyone else experienced their /tmp directory filling up with tmpXXXXXX.tmp files? It reliably occurs on two separate installs of F7 I've done after several hours of usage, entirely filling up the partition (how I wished I'd put /tmp on a separate partition). Incidentally, what's the rule determining when the space reclaimed by deleting a file on a full partition is actually made available? Restarting does the trick, and sometimes logging out works as well. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From kevin.kofler at chello.at Tue Feb 13 18:27:42 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 13 Feb 2007 18:27:42 +0000 (UTC) Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> <13dbfe4f0702131019k47203c61td4416e08fd2109f8@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > Ah ok :) > So someone who was present can post their irc log for the meeting ? > thanks Feb 13 03:56:34 --> rdieter (n=rdieter at sting.unl.edu) hat #fedora-devel betreten Feb 13 03:57:11 rdieter: Hej... Feb 13 03:57:37 <-- mull hat sich getrennt (Read error: 110 (Connection timed out)) Feb 13 03:57:53 liquidat: hi Feb 13 03:58:20 You can be quite lucky that I'm here - it is just because a review I wanted to write took so much longer (but was very exciting anyway). Feb 13 03:58:35 And I'm not sure how long I will stay here - it's 4 o'clock in the morning here... Feb 13 03:58:42 what review? Feb 13 03:58:44 But well, we'll see. Feb 13 03:58:50 I blogged about VirtualBox. Feb 13 03:58:53 It's 4 AM too, so what? ;-) Feb 13 03:58:56 +here Feb 13 03:59:14 Btw., *that* would be a cool addition for the KDE fedora spin (virtualbox' gui is qt). Feb 13 03:59:32 forgive my ignorance, what is it? Feb 13 03:59:37 Kevin_Kofler: Well, I guess it's the same time zone, even the same language (somewhat) ;) Feb 13 04:00:03 rdieter: A virtual machine. Just like Vmware, but the interface is stunning (perfect designed). It was released as GPL some days ago. Feb 13 04:00:16 like qemu too? Feb 13 04:00:17 http://liquidat.wordpress.com/2007/02/13/review-innoteks-virtualbox/ Feb 13 04:01:09 rdieter: Well, "like Qemu" if you mean the GPL part - the GUI is light years ahead, the speed is at the same level as Vmware, and you can even use it for servers because it works on command line as well. Feb 13 04:01:18 It is really stunning, believe me. Feb 13 04:01:29 looks impressive. Feb 13 04:01:37 Astonishing I meant. But, well stunning maybe also ;) Feb 13 04:01:48 afk ~2 min. Feb 13 04:02:37 Impressive is the right word... Feb 13 04:03:29 I copied a small performance test a news magazine here made, it gives a pretty good impression of the VirtualBox performance. Feb 13 04:06:30 Hm... so, who is here for the KDE talk? Feb 13 04:06:40 back. Feb 13 04:06:52 wb Feb 13 04:07:31 So - how do we start? Feb 13 04:08:07 ok, topic #1, encourage reviews of kde-related pkgs. Feb 13 04:08:42 I listed most of the (core) ones on the wiki: http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE Feb 13 04:09:06 this is vital, movement needs to happen asap. Feb 13 04:09:27 no modification, or comaintainership can happen until these first pass review. Feb 13 04:09:30 What do we need to do? Just making usual package reviews with these? Feb 13 04:09:44 usual review, pretty much. Feb 13 04:10:10 Ah, ok. Feb 13 04:10:34 procedure is slightly different with merge reviews: http://fedoraproject.org/wiki/WarrenTogami/ReviewWithFlags Feb 13 04:11:23 questions/comments? Feb 13 04:12:02 I could take a smaller one - the problem is that I have only my laptop as a machine to make mock build tests. Feb 13 04:12:25 kdenetwork takes more than 40 minutes here... Feb 13 04:12:32 with merge reviews, you can pretty much assume they already build. Feb 13 04:12:40 (: Feb 13 04:12:49 Well, not kdenetwork, that's the reason why I say. Feb 13 04:13:17 really? interesting, well *most* should build as-is anyway. (: Feb 13 04:13:26 at least the kde-3.5.6 pkgs should. Feb 13 04:13:37 --> craigt (n=craigt at ool-43512319.dyn.optonline.net) hat #fedora-devel betreten Feb 13 04:13:40 kde < 3.5.5 had issues with rawhide's autoconf/automake stack. Feb 13 04:13:46 http://bugzilla.redhat.com/195486 there it says it doesn't. Feb 13 04:14:29 ?? it worksforme. Feb 13 04:14:33 Anyway, can you add a flag on the webpage to each bug report if there is a reviewer already or not? Feb 13 04:14:42 I'll have to update that for kdenetwork-3.5.6 Feb 13 04:15:12 * rdieter shrugs. Feb 13 04:15:30 Like, kdenetwork has a reviwer, but kdebindings does not? Feb 13 04:15:56 kdenetwork hasn't a reviewer (it's assigned still to nobody) Feb 13 04:16:18 kdebindings likely doesn't either. Feb 13 04:18:12 Strange, at the bug report of kdenetwork Michael J Knox said "I will review this one": https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195486#c2 Feb 13 04:18:12 and in comment #9, said "I'll have to step out..." Feb 13 04:18:12 "and be unable to complete this review" Feb 13 04:19:18 anyway, there's a mix of merge reviews (from Core), and Review Requests of mine. Feb 13 04:19:24 Sorry, didn't see that :( Feb 13 04:19:49 the latter ones follow the "usual" Extras' procedure, the former the new ReviewWithFlags method. Feb 13 04:20:11 anything else? otherwise, I'll try to move on. Feb 13 04:20:17 No, please move on. Feb 13 04:21:04 topic #2: package splitting. Feb 13 04:21:50 Rationale here is to include in the main pkgs only those bits we want installed by default, Feb 13 04:21:57 the rest split into subpkgs or into an -extras pkg, or simply omitted altogether (rarely). Feb 13 04:22:42 The best bits, trying to avoid overlaps in functionality. Feb 13 04:23:01 Again, I refer to http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE Feb 13 04:23:30 Does the list of items to split-out make sense? Feb 13 04:23:45 Almost: kdenetwork lists kpdf?! Feb 13 04:23:54 (that list was mostly from a brainstorming session I had at FUDCon with Aaron Seigo of kde) Feb 13 04:24:09 kpdf != kpf Feb 13 04:24:23 Oh, my fault, sorry. Feb 13 04:24:27 n p Feb 13 04:25:28 stuff in () is what replaces the lost functionality (if that wasn't obvious). Feb 13 04:25:40 What's the rationale for splitting off ktalkd? Doesn't that mean that if someone old school enough tries to send you a "talk" message, it gets just lost or printed on some console you'll never notice? Feb 13 04:26:05 ktalkd != old talk protocol. It's something even older and different, afaik. Feb 13 04:26:35 (or am I rememberring it wrong?) Feb 13 04:26:46 http://docs.kde.org/stable/en/kdenetwork/ktalkd/introduction.html Feb 13 04:27:06 That at least claims it takes messages from "talk", as well as "ntalk" and "otalk". Feb 13 04:27:11 There are security concerns about running that app on multi-user-machines. Feb 13 04:27:20 That shouldn't be integrated! Feb 13 04:27:46 It being insecure would be a good reason not to install it by default, of course. Feb 13 04:28:01 yeah, that warning about use on multi-user machines, is troubling. Feb 13 04:28:26 Why would you use talk on a single-user machine? ;-) Feb 13 04:28:47 exactly. Feb 13 04:28:47 --> kmaraas (n=kmaraas at 115.84-48-67.nextgentel.com) hat #fedora-devel betreten Feb 13 04:29:04 Is someone packaging speedcrunch? Feb 13 04:29:10 heck, that's what irc, jabber, etc, is for these days. Feb 13 04:29:23 re: speedcrunch, not yet, afaik. Feb 13 04:29:47 I should have put that one in the "not yet packaged for Fedora" section. Feb 13 04:30:14 any other questions/comments regarding package splits? Feb 13 04:30:25 I will try to submit speedcrunch tomorrow... Feb 13 04:30:31 thanks. Feb 13 04:30:59 the splitting business may involve a wee-bit of work, but I think it will be worth it (hopefully, we'll have to time) Feb 13 04:31:20 recall: F7t2 freeze is 02/20 Feb 13 04:31:53 I agree... Feb 13 04:32:01 ok, last topic on my informal agenda: app defaults/setup. Feb 13 04:32:26 --> fedorared (n=john at fedora/fedorared) hat #fedora-devel betreten Feb 13 04:32:52 In short, setup things so that stuff works as sanely as possible out of the box. Feb 13 04:33:42 one optimization that may be controversial was to make pdf the default print output, and make kpdf the default print preview. Feb 13 04:34:04 (maybe just pdf for print preview, anyway) Feb 13 04:34:17 I tried that one on my local machine, and it worked. Feb 13 04:34:49 The question is how much work this is on the packages, but in other cases I would prefer kpdf - the old one was really old. Feb 13 04:35:20 this part, I don't see as being much work (less than pkg splitting, in any case) Feb 13 04:35:46 What are reasons against, than? Feb 13 04:36:35 I can't think of any reason, but I'm biased. Feb 13 04:37:02 any other ideas for possible app/setup customization to improve user experience? Feb 13 04:37:34 Well, it would be cool to have another style Feb 13 04:37:44 Have you seen jkatz's proposed list of spins yet? http://katzj.livejournal.com/400723.html Feb 13 04:38:15 Polyester together with Fedora colours would be nicer than just the plain KDE. Feb 13 04:38:18 There's no full KDE spin in that plan, just a live CD... Feb 13 04:38:22 yes, I saw his rough draft (though I forgot to comment on it) Feb 13 04:38:44 yeah, we plan on making a full/regular spin first, then livecd too (if we have time) Feb 13 04:39:32 liquidat: I'm strongly against anything buy plastik as the default, thought we can include other styles in the spin. Feb 13 04:40:10 rdieter: Ok, than plastik :) Feb 13 04:40:24 new/flashy styles are cute, but are also a source of irritating bugs. Feb 13 04:41:07 Just make sure the good old Bluecurve libs end up on the spin. Feb 13 04:41:11 I'd feel a lot better going with something tried-and-true, which still qualifies as quasi-cool. Feb 13 04:41:48 yeah, Bluecurve is/will-be in redhat-artwork (or whatever they end up naming it), no getting away from that, likely. Feb 13 04:42:32 Hm.. I have no other ideas... Feb 13 04:42:35 There's currently a proposal on the ML to split off the Bluecurve binaries from redhat-artwork to avoid multilibbing all that data. Feb 13 04:42:47 speaking of theming, I'm also strongly leaning toward using crystalsvg icon theme. Feb 13 04:43:00 Which one is the default? Feb 13 04:43:08 echo looks nice, but dev's seem only luke-warm to address kde-specific issues. Feb 13 04:43:42 Fc-6 defaults to Bluecurve icon theme, I believe. Feb 13 04:43:52 I propose to use crystalsvg. Feb 13 04:43:59 for F7 kde spin, anyway. Feb 13 04:44:35 unless a miracle occurs and echo gets fixed in the meantime. Feb 13 04:45:02 So lets take crystalsvg - isn't that even the default for KDE vanilla? Feb 13 04:45:08 yup. Feb 13 04:46:14 cool thing is, all/most of the customizations, and theming defaults will be contained in a separate .noarch pkg. Feb 13 04:46:44 Which will allow local/site admins to customize things easily by replacing/updating that one bit. Feb 13 04:47:04 Or even better, use kde's kiosktool to do it. Feb 13 04:47:11 Hm, sounds nice :) Feb 13 04:47:53 I initially named the "defaults" pkg, kde-config (but that's confusing, since kdelibs includes a binary named kde-config). Feb 13 04:48:00 <-- daMaestro hat sich getrennt ("Leaving") Feb 13 04:48:10 I think I'm leaning toward calling it kde-settings instead. Feb 13 04:49:06 kde-settings-default (so others can add kde-settings-corporatebranding or whatever) Feb 13 04:50:01 sure, that makes sense too. Feb 13 04:50:11 kde-default-settings would be more grammatical. Feb 13 04:51:15 even better. Feb 13 04:51:45 Whatever :) Feb 13 04:52:16 if anybody listening knows or is near than at redhat.com, poke him to wake up. Feb 13 04:53:44 that's pretty much all I had in mind, any other topics? Feb 13 04:54:15 * rdieter had been hoping than would have been here. Feb 13 04:55:17 A question: will we include non-security bug fixes when they appear? Feb 13 04:55:23 I have the ICQ problem in my mind. Feb 13 04:55:44 A big, it depends, but usually, yes. Feb 13 04:56:08 we don't want to push big pkg updates for every small bug fix either. Feb 13 04:56:43 there's a balance. (I'd argue the kopete icq warranted being fixed) Feb 13 04:57:19 Ah, ok. Feb 13 04:58:06 otherwise, review, review, review. Have I mentioned package reviews? (: Feb 13 04:59:30 ;) Feb 13 05:00:02 Well, I have almost no real experience there, but I will try to push up speedcrunch (ha, cmake one, never tried that in a spec file before). Feb 13 05:00:03 good night everybody, we'll reconvene tomorrow at 20:00 UTC Feb 13 05:00:40 --> sankarshan (n=sankarsh at 202.80.58.210) hat #fedora-devel betreten Feb 13 05:00:43 Would that be today for us in Europe? Feb 13 05:01:02 probably, Tue 20:00 UTC. Feb 13 05:01:31 (another time recently suggested on the KDE SIG wiki). Feb 13 05:01:43 I'm not sure if I will be there, but good night! Feb 13 05:01:49 Or good morning almost ;) Feb 13 05:01:50 thanks liquidat, Kevin_Kofler. Feb 13 05:01:59 <-- liquidat (n=liquidat at 4560-02bg04.stw-wh.uni-jena.de) hat #fedora-devel verlassen ("Konversation terminated!") Feb 13 05:02:30 <-- rdieter hat sich getrennt (Remote closed the connection) Feb 13 05:02:30 --- Getrennt (). From dennis at ausil.us Tue Feb 13 18:32:48 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 13 Feb 2007 12:32:48 -0600 Subject: F7 KDE spin r2 In-Reply-To: References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> Message-ID: <200702131232.54552.dennis@ausil.us> Once upon a time Tuesday 13 February 2007 12:16 pm, Kevin Kofler wrote: > Chitlesh GOORAH fedoraproject.org> writes: > > So when will be the first meeting be held ? > > The first one was at 0300 UTC (04:00 (AM) CET), but there will be another > one tonight at the time you suggested: 2000 UTC (21:00 CET). > > Kevin Kofler I cant do that time for meetings they have to be between of GMT 23:00 - 05:00 Dennis -------------- 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 fedoraproject.org Tue Feb 13 18:47:34 2007 From: rdieter at fedoraproject.org (Rex Dieter) Date: Tue, 13 Feb 2007 12:47:34 -0600 Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> <13dbfe4f0702131019k47203c61td4416e08fd2109f8@mail.gmail.com> Message-ID: Kevin Kofler wrote: > Chitlesh GOORAH fedoraproject.org> writes: >> Ah ok :) >> So someone who was present can post their irc log for the meeting ? >> thanks > > Feb 13 03:56:34 --> rdieter (n=rdieter at sting.unl.edu) hat #fedora-devel totally forgot about keeping an irc log. Kevin, could you post the log to the KDE SIG wiki page? -- Rex From kevin.kofler at chello.at Tue Feb 13 18:49:50 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 13 Feb 2007 18:49:50 +0000 (UTC) Subject: F7 KDE spin r2 References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> <13dbfe4f0702131019k47203c61td4416e08fd2109f8@mail.gmail.com> Message-ID: Rex Dieter fedoraproject.org> writes: > totally forgot about keeping an irc log. Kevin, could you post the log to > the KDE SIG wiki page? I don't have Wiki write access. Kevin Kofler From mschwendt.tmp0701.nospam at arcor.de Tue Feb 13 19:16:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 13 Feb 2007 20:16:15 +0100 Subject: Understanding multi-lib conflicts in packages In-Reply-To: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070213201615.4eff6dfe.mschwendt.tmp0701.nospam@arcor.de> Meanwhile, all automatically found multi-lib conflicts have been reported in bugzilla. Only six in Core, 4-5 dozen in Extras (-> FE7Target tracker). From chitlesh at fedoraproject.org Tue Feb 13 19:37:40 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 13 Feb 2007 20:37:40 +0100 Subject: F7 KDE spin r2 In-Reply-To: References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> <13dbfe4f0702131019k47203c61td4416e08fd2109f8@mail.gmail.com> Message-ID: <13dbfe4f0702131137x793a9e46qf4f1093b35e9374@mail.gmail.com> On 2/13/07, Kevin Kofler wrote: > I don't have Wiki write access. > send it to me i'll put it in the wiki Chitlesh -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Tue Feb 13 19:58:43 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 13 Feb 2007 20:58:43 +0100 Subject: F7 KDE spin r2 In-Reply-To: <13dbfe4f0702131137x793a9e46qf4f1093b35e9374@mail.gmail.com> References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> <13dbfe4f0702131019k47203c61td4416e08fd2109f8@mail.gmail.com> <13dbfe4f0702131137x793a9e46qf4f1093b35e9374@mail.gmail.com> Message-ID: <13dbfe4f0702131158g18ac3711x146c9bba9568980b@mail.gmail.com> Hello, I just came across: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195486 the kdenetwork spec file from this bug is different from the what fedora is shipping right now. kdenetwork is just an example here. I'm just asking whether for F7 we are dropping all fixes/features provided by fedora's actual kde instead of kde-redhat's kde ?? Chitlesh -- http://clunixchit.blogspot.com From selinux at gmail.com Tue Feb 13 20:01:35 2007 From: selinux at gmail.com (Tom London) Date: Tue, 13 Feb 2007 12:01:35 -0800 Subject: /tmp filling up In-Reply-To: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> Message-ID: <4c4ba1530702131201q21f6eb54pcd9d9fa0bda8d10@mail.gmail.com> On 2/13/07, Michel Salim wrote: > Has anyone else experienced their /tmp directory filling up with > tmpXXXXXX.tmp files? It reliably occurs on two separate installs of F7 > I've done after several hours of usage, entirely filling up the > partition (how I wished I'd put /tmp on a separate partition). > > Incidentally, what's the rule determining when the space reclaimed by > deleting a file on a full partition is actually made available? > Restarting does the trick, and sometimes logging out works as well. > > -- > Michel Salim Yeah, I've seen this. I've tried to track this down without success. The files seem to be copies of files: various modification times, various types, various sizes. Hasn't been taking up much space on my system though..... tom -- Tom London From mattdm at mattdm.org Tue Feb 13 21:30:31 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Feb 2007 16:30:31 -0500 Subject: /tmp filling up In-Reply-To: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> Message-ID: <20070213213031.GA334@jadzia.bu.edu> On Tue, Feb 13, 2007 at 01:28:05PM -0500, Michel Salim wrote: > Has anyone else experienced their /tmp directory filling up with > tmpXXXXXX.tmp files? It reliably occurs on two separate installs of F7 > I've done after several hours of usage, entirely filling up the > partition (how I wished I'd put /tmp on a separate partition). Many programs respect the environment variables TMP and/or TMPDIR; try setting that to a bigger directory (I use ~/tmp for my personal stuff, and then I also run tmpwatch on that directory from my user crontab). > Incidentally, what's the rule determining when the space reclaimed by > deleting a file on a full partition is actually made available? > Restarting does the trick, and sometimes logging out works as well. When the file is no longer actually open. So if the program that made the file is still using it, it won't be really removed even though it was unlinked. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From chitlesh at fedoraproject.org Tue Feb 13 22:06:03 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 13 Feb 2007 23:06:03 +0100 Subject: F7 KDE spin r2 In-Reply-To: <13dbfe4f0702131158g18ac3711x146c9bba9568980b@mail.gmail.com> References: <45D07F2F.6010506@math.unl.edu> <13dbfe4f0702130953g2ba43d0m26ec30d905c09369@mail.gmail.com> <13dbfe4f0702131019k47203c61td4416e08fd2109f8@mail.gmail.com> <13dbfe4f0702131137x793a9e46qf4f1093b35e9374@mail.gmail.com> <13dbfe4f0702131158g18ac3711x146c9bba9568980b@mail.gmail.com> Message-ID: <13dbfe4f0702131406h2803e99ej681c256f7fb2e472@mail.gmail.com> Second meeting of the day posted: http://fedoraproject.org/wiki/Extras/SIGs/KDE?action=AttachFile&do=get&target=meeting-2007-02-13_pm.txt Chitlesh -- http://clunixchit.blogspot.com From michel.salim at gmail.com Tue Feb 13 23:55:27 2007 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 13 Feb 2007 18:55:27 -0500 Subject: /tmp filling up In-Reply-To: <20070213213031.GA334@jadzia.bu.edu> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> <20070213213031.GA334@jadzia.bu.edu> Message-ID: <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> 2007/2/13, Matthew Miller : > On Tue, Feb 13, 2007 at 01:28:05PM -0500, Michel Salim wrote: > > Has anyone else experienced their /tmp directory filling up with > > tmpXXXXXX.tmp files? It reliably occurs on two separate installs of F7 > > I've done after several hours of usage, entirely filling up the > > partition (how I wished I'd put /tmp on a separate partition). > > Many programs respect the environment variables TMP and/or TMPDIR; try > setting that to a bigger directory (I use ~/tmp for my personal stuff, and > then I also run tmpwatch on that directory from my user crontab). > That won't help on a laptop -- / normally has about 10 GB free space, and it would entirely fill up once this bug triggers. I don't think it matters how much space you have free. > When the file is no longer actually open. So if the program that made the > file is still using it, it won't be really removed even though it was > unlinked. > Hmm. That narrows it down a bit - the culprit must be something that is run automatically when GNOME starts. I'll cook up something that will watch for a large file in /tmp and then find its owner. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From mattdm at mattdm.org Wed Feb 14 01:54:49 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Feb 2007 20:54:49 -0500 Subject: /tmp filling up In-Reply-To: <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> <20070213213031.GA334@jadzia.bu.edu> <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> Message-ID: <20070214015449.GA19000@jadzia.bu.edu> On Tue, Feb 13, 2007 at 06:55:27PM -0500, Michel Salim wrote: > >> Has anyone else experienced their /tmp directory filling up with > >> tmpXXXXXX.tmp files? It reliably occurs on two separate installs of F7 > >> I've done after several hours of usage, entirely filling up the > >> partition (how I wished I'd put /tmp on a separate partition). > >Many programs respect the environment variables TMP and/or TMPDIR; try > >setting that to a bigger directory (I use ~/tmp for my personal stuff, and > >then I also run tmpwatch on that directory from my user crontab). > That won't help on a laptop -- / normally has about 10 GB free space, > and it would entirely fill up once this bug triggers. I don't think it > matters how much space you have free. Okay, but you could put it to a smaller separate partition, fulfilling your wish above. > Hmm. That narrows it down a bit - the culprit must be something that > is run automatically when GNOME starts. I'll cook up something that > will watch for a large file in /tmp and then find its owner. lsof. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwilliam at xmission.com Wed Feb 14 02:57:46 2007 From: jwilliam at xmission.com (Jerry Williams) Date: Tue, 13 Feb 2007 19:57:46 -0700 Subject: images directory missing? Message-ID: <002101c74fe3$e79cec60$020aa8c0@a18> What happened to the images directory in: http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/ Jerry Williams From michel.salim at gmail.com Wed Feb 14 03:06:42 2007 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 13 Feb 2007 22:06:42 -0500 Subject: /tmp filling up In-Reply-To: <20070214015449.GA19000@jadzia.bu.edu> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> <20070213213031.GA334@jadzia.bu.edu> <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> <20070214015449.GA19000@jadzia.bu.edu> Message-ID: <883cfe6d0702131906n1583b917xb328b4214d577ca2@mail.gmail.com> 2007/2/13, Matthew Miller : > On Tue, Feb 13, 2007 at 06:55:27PM -0500, Michel Salim wrote: > > >> Has anyone else experienced their /tmp directory filling up with > > >> tmpXXXXXX.tmp files? It reliably occurs on two separate installs of F7 > > >> I've done after several hours of usage, entirely filling up the > > >> partition (how I wished I'd put /tmp on a separate partition). > > >Many programs respect the environment variables TMP and/or TMPDIR; try > > >setting that to a bigger directory (I use ~/tmp for my personal stuff, and > > >then I also run tmpwatch on that directory from my user crontab). > > That won't help on a laptop -- / normally has about 10 GB free space, > > and it would entirely fill up once this bug triggers. I don't think it > > matters how much space you have free. > > Okay, but you could put it to a smaller separate partition, fulfilling your > wish above. > > > Hmm. That narrows it down a bit - the culprit must be something that > > is run automatically when GNOME starts. I'll cook up something that > > will watch for a large file in /tmp and then find its owner. > > lsof. > well, lsof + inotify-tools. I want an early warning system, not find out when things start breaking. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From Curtis at GreenKey.net Wed Feb 14 03:15:37 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Tue, 13 Feb 2007 19:15:37 -0800 (PST) Subject: images directory missing? In-Reply-To: <002101c74fe3$e79cec60$020aa8c0@a18> References: <002101c74fe3$e79cec60$020aa8c0@a18> Message-ID: <20070214031537.A9FAF6F06C@alopias.GreenKey.net> 7:57pm Jerry Williams said: > What happened to the images directory in: > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/ > Yeah, it and the isolinux stuff didn't survive today's build. There are no obvious errors in the rawhide report. So we wait for tomorrow, or some sign from the buildsys admins. Maybe it hicup'd on the new syslinux from upstream, although I can't imagine why. ../C From Curtis at GreenKey.net Wed Feb 14 03:32:03 2007 From: Curtis at GreenKey.net (Curtis Doty) Date: Tue, 13 Feb 2007 19:32:03 -0800 (PST) Subject: Understanding multi-lib conflicts in packages In-Reply-To: <20070213201615.4eff6dfe.mschwendt.tmp0701.nospam@arcor.de> References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> <20070213201615.4eff6dfe.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070214033203.CDBE86F06C@alopias.GreenKey.net> 8:16pm Michael Schwendt said: > Meanwhile, all automatically found multi-lib conflicts have been reported > in bugzilla. Only six in Core, 4-5 dozen in Extras (-> FE7Target tracker). > URL or help please. For those of us who wish to contribute, but don't already have an advanced degree in the slow and morose beast known as Red Hat Bugzilla. :-/ ../C From jkeating at redhat.com Wed Feb 14 03:48:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Feb 2007 22:48:06 -0500 Subject: images directory missing? In-Reply-To: <20070214031537.A9FAF6F06C@alopias.GreenKey.net> References: <002101c74fe3$e79cec60$020aa8c0@a18> <20070214031537.A9FAF6F06C@alopias.GreenKey.net> Message-ID: <200702132248.06210.jkeating@redhat.com> On Tuesday 13 February 2007 22:15, Curtis Doty wrote: > Yeah, it and the isolinux stuff didn't survive today's build. There are no > obvious errors in the rawhide report. So we wait for tomorrow, or some > sign from the buildsys admins. Maybe it hicup'd on the new syslinux from > upstream, although I can't imagine why. Nope, just continued anaconda breakage. Things look better for tomorrow's rawhide. Isn't this fun? (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Wed Feb 14 04:27:14 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 13 Feb 2007 22:27:14 -0600 (CST) Subject: Understanding multi-lib conflicts in packages In-Reply-To: <20070214033203.CDBE86F06C@alopias.GreenKey.net> References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> <20070213201615.4eff6dfe.mschwendt.tmp0701.nospam@arcor.de> <20070214033203.CDBE86F06C@alopias.GreenKey.net> Message-ID: On Tue, 13 Feb 2007, Curtis Doty wrote: > 8:16pm Michael Schwendt said: >> Meanwhile, all automatically found multi-lib conflicts have been reported >> in bugzilla. Only six in Core, 4-5 dozen in Extras (-> FE7Target tracker). > > URL or help please. For those of us who wish to contribute, but don't > already have an advanced degree in the slow and morose beast known as Red > Hat Bugzilla. :-/ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE7Target Not sure which blocking bugs are the multilib conflicts, though. Jima From mattdm at mattdm.org Wed Feb 14 04:45:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Feb 2007 23:45:34 -0500 Subject: /tmp filling up In-Reply-To: <883cfe6d0702131906n1583b917xb328b4214d577ca2@mail.gmail.com> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> <20070213213031.GA334@jadzia.bu.edu> <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> <20070214015449.GA19000@jadzia.bu.edu> <883cfe6d0702131906n1583b917xb328b4214d577ca2@mail.gmail.com> Message-ID: <20070214044534.GA30123@jadzia.bu.edu> On Tue, Feb 13, 2007 at 10:06:42PM -0500, Michel Salim wrote: > >> Hmm. That narrows it down a bit - the culprit must be something that > >> is run automatically when GNOME starts. I'll cook up something that > >> will watch for a large file in /tmp and then find its owner. > >lsof. > well, lsof + inotify-tools. I want an early warning system, not find > out when things start breaking. Theoretically once you've found out what it is you can make it stop. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From j.w.r.degoede at hhs.nl Wed Feb 14 07:27:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 14 Feb 2007 08:27:36 +0100 Subject: simplistic questions about core/extras merge In-Reply-To: <883cfe6d0702121434x48fd9cb7w442d88f9dad86d59@mail.gmail.com> References: <45D05AB6.5070509@hhs.nl> <883cfe6d0702121434x48fd9cb7w442d88f9dad86d59@mail.gmail.com> Message-ID: <45D2B9E8.6010402@hhs.nl> Michel Salim wrote: > 2007/2/12, Hans de Goede : >> >> Let me put my money where my mouth is, if any core package maintainer >> would like a hand and is serious about this. Then drop me a mail with a >> couple of BZ id's you would like a hand with, or a package name for >> which you want me to go through bugzilla and fix any bugs against that >> package in general. Note you should be willing to treat me as a fellow >> developer and not as some kinda newbie (which I'm not). >> > How about a Wiki page? > A wiki page with what / for what? Next time please try to use more then one sentence to explain yourself, I'm many things but I'm not a mind reader. Regards, Hans From paul at city-fan.org Wed Feb 14 08:29:13 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 14 Feb 2007 08:29:13 +0000 Subject: Understanding multi-lib conflicts in packages In-Reply-To: References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> <20070213201615.4eff6dfe.mschwendt.tmp0701.nospam@arcor.de> <20070214033203.CDBE86F06C@alopias.GreenKey.net> Message-ID: <1171441754.7767.1.camel@metropolis.intra.city-fan.org> On Tue, 2007-02-13 at 22:27 -0600, Jima wrote: > On Tue, 13 Feb 2007, Curtis Doty wrote: > > 8:16pm Michael Schwendt said: > >> Meanwhile, all automatically found multi-lib conflicts have been reported > >> in bugzilla. Only six in Core, 4-5 dozen in Extras (-> FE7Target tracker). > > > > URL or help please. For those of us who wish to contribute, but don't > > already have an advanced degree in the slow and morose beast known as Red > > Hat Bugzilla. :-/ > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE7Target > > Not sure which blocking bugs are the multilib conflicts, though. Try the dependency tree view instead, which lists the summaries: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE7Target Paul. From kzak at redhat.com Wed Feb 14 09:41:58 2007 From: kzak at redhat.com (Karel Zak) Date: Wed, 14 Feb 2007 10:41:58 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> Message-ID: <20070214094158.GA3925@petra.dvoda.cz> On Sun, Nov 12, 2006 at 02:15:57PM -0900, Jeff Spaleta wrote: > On 11/12/06, Jeff Spaleta wrote: > >Okay its come to my attention that the readahead configs have a > >difficult time being kept in sync as package updates roll out. For fc6 > >right now for example readahead is out of sync with firefox libraries. > > > >Can we update readahead's implementation so we can get per package > >control of the default configs? Is a readahead.d/ structure > >appropriate here? > > Sorry... i didnt look hard enough... the readahead.d structure was > added for fc6.... the problem is package maintainers aren't using it > yet. I guess what I need to do is parse the existing config file... > identify individual packages that could drop files in readahead.d/ > and poke the appropriate maintainers in the eye about dropping a file > in there as part of package payloading. > > Anyone want to help me construct the list of packages that could make > sure of readahead.d/ on a per package basis based on the default > readahead configs we have right now? Update: I've wrote a small and simple readahead-auditd that is able to collect all filenames from boot process. It means everyone will be able to generate unique list for his Fedora. And also I can maintain default lists more effective now. I'm going to release an experimental readahead package with this solution to FC7 next week. Karel -- Karel Zak From mschwendt.tmp0701.nospam at arcor.de Wed Feb 14 10:48:11 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 14 Feb 2007 11:48:11 +0100 Subject: Understanding multi-lib conflicts in packages In-Reply-To: <1171441754.7767.1.camel@metropolis.intra.city-fan.org> References: <20070211000644.4115afc7.mschwendt.tmp0701.nospam@arcor.de> <20070213201615.4eff6dfe.mschwendt.tmp0701.nospam@arcor.de> <20070214033203.CDBE86F06C@alopias.GreenKey.net> <1171441754.7767.1.camel@metropolis.intra.city-fan.org> Message-ID: <20070214114811.90e7da0a.mschwendt.tmp0701.nospam@arcor.de> On Wed, 14 Feb 2007 08:29:13 +0000, Paul Howarth wrote: > On Tue, 2007-02-13 at 22:27 -0600, Jima wrote: > > On Tue, 13 Feb 2007, Curtis Doty wrote: > > > 8:16pm Michael Schwendt said: > > >> Meanwhile, all automatically found multi-lib conflicts have been reported > > >> in bugzilla. Only six in Core, 4-5 dozen in Extras (-> FE7Target tracker). > > > > > > URL or help please. For those of us who wish to contribute, but don't > > > already have an advanced degree in the slow and morose beast known as Red > > > Hat Bugzilla. :-/ > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE7Target > > > > Not sure which blocking bugs are the multilib conflicts, though. > > Try the dependency tree view instead, which lists the summaries: > > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE7Target > > Paul. Interesting are the cases where -devel packages (sometimes tiny ones for plug-in APIs) cause main 32-bit application packages to be pulled into the x86_64 repo, which then conflicts in data files (in a few cases due to packaging bugs). Splitting off a -libs package (for the corresponding files in the -devel package) should be possible in most cases, especially since we don't really want 32-bit applications in the 64-bit repo. As a last resort, there's still the multi-lib blacklist. ... and the additional Core tickets are these: 228311 (FIXED) 228315 228317 228318 228320 (FIXED) 228321 (MODIFIED via Merge review) From buildsys at redhat.com Wed Feb 14 11:03:11 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 14 Feb 2007 06:03:11 -0500 Subject: rawhide report: 20070214 changes Message-ID: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> Updated Packages: SysVinit-2.86-15 ---------------- * Tue Feb 13 2007 Bill Nottingham - 2.86-15 - spec cleanups; remove initunlvl part of %post, as that hasn't been supported for nearly 4 years anaconda-11.2.0.22-1 -------------------- * Tue Feb 13 2007 Chris Lumens - 11.2.0.22-1 - Load the ext3 module earlier to fix hd installs (#223749, #224534). - Don't traceback in postconfig if it's not a kickstart install. - Fix autopart string (dcantrell, #228192). - Remove references to genheader (dcantrell). - Rework text network UI to more closely follow graphical (dcantrell). autofs-1:5.0.1-0.rc3.20 ----------------------- * Wed Feb 14 2007 Ian Kent - 5.0.1-0.rc3.20 - correct return status from do_mkdir (bz 223480). chkconfig-1.3.33-1 ------------------ * Tue Feb 06 2007 Bill Nottingham 1.3.33-1 - various changes from review - support alternate %{_sbindir}, fix summaries, add version to requires, assorted other bits control-center-1:2.17.91-1.fc7 ------------------------------ * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 - Drop upstreamed patches - Update patches coreutils-6.7-4.fc7 ------------------- * Tue Feb 13 2007 Tim Waugh 6.7-4 - Ship COPYING file (bug #225655). - Use datadir and infodir macros in %pre scriptlet (bug #225655). - Use spaces not tabs (bug #225655). - Fixed build root. - Change prereq to requires (bug #225655). - Explicitly version some obsoletes tags (bug #225655). - Removed obsolete pl translation fix. cups-1:1.2.7-8.fc7 ------------------ * Tue Feb 13 2007 Tim Waugh 1:1.2.7-8 - Removed logrotate config file and maxlogsize patch (bug #227369). Now CUPS is in charge of rotating its own logs, and defaults to doing so once they get to 1Mb in size. dasher-4.3.4-1.fc7 ------------------ * Tue Feb 13 2007 Matthias Clasen - 4.3.4-1 - Update to 4.3.4 dbus-python-0.80.2-1.fc7 ------------------------ * Tue Feb 13 2007 John (J5) Palmieri - 0.80.2-1 - upgrade to 0.80.2 which fixes some memleaks emacs-22.0.93-6.fc7 ------------------- * Tue Feb 13 2007 Chip Coldwell - 22.0.93-6 - remove --without-xim configure flag to fix dead keys (Ville Skytt?? #224626) epiphany-2.17.91-1.fc7 ---------------------- * Tue Feb 13 2007 Matthias Clasen 2.17.91-1 - Update to 2.17.91 evince-0.7.2-1.fc7 ------------------ * Tue Feb 13 2007 Matthias Clasen - 0.7.2-1 - Update to 0.7.2 evolution-2.9.91-2.fc7 ---------------------- * Tue Feb 13 2007 Matthew Barnes - 2.9.91-2.fc7 - Require GConf2 in post. - Require scrollkeeper in post and postun. evolution-connector-2.9.91-2.fc7 -------------------------------- * Mon Feb 12 2007 Matthew Barnes - 2.9.91-2.fc7 - Fix some 64-bit compiler warnings. * Mon Feb 12 2007 Matthew Barnes - 2.9.91-1.fc7 - Update to 2.9.91 - Compile with -Werror. - Add BuildRequires db4-devel. - Add flags to disable deprecated Pango and GTK+ symbols. - Add patch for GNOME bug #405916 (fix all compiler warnings). - Remove patch for GNOME bug #360240 (superseded). * Sun Jan 21 2007 Matthew Barnes - 2.9.5-2.fc7 - Revise evolution-exchange-2.7.2-no_gnome_common.patch so that we no longer have to run autoconf before building. f-spot-0.3.3-1.fc7 ------------------ * Tue Feb 13 2007 Matthias Clasen - 0.3.3-1 - Update to 0.3.3 fast-user-switch-applet-2.17.3-3.fc7 ------------------------------------ * Tue Feb 13 2007 Matthias Clasen 2.17.3-3 - Set better defaults firstboot-1.4.30-2.fc7 ---------------------- * Tue Feb 13 2007 Chris Lumens 1.4.30-2 - Fix typo in dependencies. flac-1.1.3-2.fc7 ---------------- * Tue Feb 13 2007 - Bastien Nocera - 1.1.3-2 - A few fixes from the the Fedora merge review - Remove the static library * Tue Feb 13 2007 - Bastien Nocera - 1.1.3-1 - Update with work from Matthias Clasen up to upstream 1.1.3 (#229462) - Remove xmmx-flac Obsolete, as we don't ship the xmms plugin gnome-desktop-2.17.91-1.fc7 --------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gnome-games-1:2.17.91-1.fc7 --------------------------- * Tue Feb 13 2007 Matthias Clasen - 1:2.17.91-1 - Update to 2.17.91 gnome-menus-2.17.91-1.fc7 ------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gnome-netstatus-2.12.1-1.fc7 ---------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.12.1-1 - Update to 2.12.1 * Fri Feb 09 2007 Matthias Clasen - 2.12.0-7 - Package review cleanup gnome-panel-2.17.91-6.fc7 ------------------------- * Tue Feb 13 2007 Matthias Clasen 2.17.91-6 - Put the fast user switch applet in the default panel configuration gnome-power-manager-2.17.91-1.fc7 --------------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gnome-screensaver-2.17.7-1.fc7 ------------------------------ * Tue Feb 13 2007 Matthias Clasen - 2.17.7-1 - Update to 2.17.7 - Drop upstreamed patch gnome-session-2.17.91-1.fc7 --------------------------- * Tue Feb 13 2007 Matthisa Clasen - 2.17.91-1 - Update to 2.17.91 * Tue Feb 06 2007 Kristian H??gsberg - 2.17.90.1-3 - Update gnome-session-2.15.90-window-manager.patch to start gtk-window-decorator instead of gnome-window-decorator for compiz. [ Update: the patch is not applied and upstream gnome-session does the right thing. ] * Mon Feb 05 2007 Matthias Clasen - 2.17.90.1-2 - Require GConf2-gtk for gconf-sanity-check gnome-terminal-2.17.91-1.fc7 ---------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gstreamer-0.10.11-2.fc7 ----------------------- * Tue Feb 13 2007 - Bastien Nocera - 0.10.11-2 - Remove Requires on packages that BuildRequire us gstreamer-plugins-good-0.10.5-5.fc7 ----------------------------------- * Tue Feb 13 2007 - Bastien Nocera - 0.10.5-5 - Don't forget to run autoreconf when modifiying the configure.ac * Tue Feb 13 2007 - Bastien Nocera - 0.10.5-4 - Move cyclic dependency with -plugins-good and -plugins-base from gstreamer to here * Tue Feb 13 2007 - Bastien Nocera - 0.10.5-3 - Patch from Matthias Clasen for the libFLAC 1.1.3 update (#222946) gtksourceview-1.8.4-1.fc7 ------------------------- * Tue Feb 13 2007 Matthias Clasen - 1.8.4-1 - Update to 1.8.4 icu-3.6-18.fc7 -------------- * Tue Feb 13 2007 Caolan McNamara - 3.6-18 - Resolves: rhbz#228457 icu.icu5594.gujarati.patch libbonobo-2.17.91-1.fc7 ----------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 libbonoboui-2.17.91-1.fc7 ------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 libgnome-2.17.91-1.fc7 ---------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 * Mon Jan 22 2007 Matthias Clasen - 2.17.90-1 - Update to 2.17.90 * Wed Jan 10 2007 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 libgnomeprint22-2.17.91-1.fc7 ----------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 libgnomeprintui22-2.17.91-1.fc7 ------------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 libgnomeui-2.17.91-1.fc7 ------------------------ * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 man-pages-2.43-6.fc7 -------------------- * Tue Feb 13 2007 Ivana Varekova 2.43-6 - Resolves: 227260 fix iso-8859 (koi8-r) man pages * Mon Jan 29 2007 Ivana Varekova 2.43-4 - fix rt_sigprocmask.2 (#219074) - remove pciconfig_{read,write,iobase}.2 (#219827) - fix swapon.2 (#222493) * Fri Jan 12 2007 Ivana Varekova 2.43-3 - fix mmap2 man page - spec file cleanup mcstrans-0.2.3-1.fc7 -------------------- * Mon Feb 12 2007 Dan Walsh 0.2.3-1 - Additional fix to handle ssh root/sysadm_r/s0:c1,c2 Resolves: #224637 * Mon Feb 05 2007 Dan Walsh 0.2.1-1 - Rewrite to handle MLS properly Resolves: #225355 * Mon Jan 29 2007 Dan Walsh 0.1.10-2 - Cleanup memory when complete nautilus-cd-burner-2.17.7-1.fc7 ------------------------------- * Tue Feb 13 2007 Matthias Clasen - 2.17.7-3 - Update to 2.17.7 nc-1.84-11.fc7 -------------- * Tue Feb 13 2007 Radek Vok??l - 1.84-11 - few spec file changes openoffice.org-1:2.2.0-7.1 -------------------------- * Tue Feb 13 2007 Caolan McNamara - 1:2.2.0-7.1 - Resolves: rhbz#228254 crash on print to pdf after print to ps - Resolves: rhbz#227897 long/sal_Int32 mismatch - need openoffice.org-2.2.0.ooo74401.basctl.boost.patch to build pango-1.15.6-1.fc7 ------------------ * Tue Feb 13 2007 Matthias Clasen - 1.15.6-1 - Update to 1.15.6 perl-Crypt-SSLeay-0.53-1.fc7 ---------------------------- * Tue Feb 13 2007 Robin Norwood - 0.53-1 - New version: 0.53 perl-LDAP-1:0.34-1.fc7 ---------------------- * Tue Feb 13 2007 Robin Norwood - 1:0.34-1 - New version: 0.34 perl-XML-SAX-0.15-1 ------------------- * Tue Feb 13 2007 Robin Norwood - 0.15-1 - New version: 0.15 perl-XML-Twig-3.29-1.fc7 ------------------------ * Tue Feb 13 2007 Robin Norwood - 3.29-1 - New version: 3.29 python-2.5-11.fc7 ----------------- * Tue Feb 13 2007 Jeremy Katz - 2.5.3-11 - tcl/tk was reverted; rebuild again redhat-menus-7.8.10-1.fc7 ------------------------- * Tue Feb 13 2007 Matthias Clasen - 7.8.10-1 - Use Education ruby-1.8.5.12-2.fc7 ------------------- * Tue Feb 13 2007 Akira TAGOH - 1.8.5.12-2 - Rebuild scim-bridge-0.4.9-2.fc7 ----------------------- * Tue Feb 13 2007 Jens Petersen - 0.4.9-2 - remove xinput files since scim xinput file now checks for scim-bridge scim-qtimm-0.9.4-6.fc7 ---------------------- * Tue Feb 13 2007 Jens Petersen - 0.9.4-6 - remove xinput file since scim xinput file now checks for scim-qtimm setools-3.1-1.fc7 ----------------- * Tue Feb 13 2007 Dan Walsh 3.1-1 - Upgrade to upstream setroubleshoot-1.8.18-1.fc7 --------------------------- * Fri Feb 09 2007 Dan Walsh - 1.8.18-1 - Remove avc from Plugin.py spamassassin-3.1.8-1.fc7 ------------------------ * Tue Feb 13 2007 Warren Togami 3.1.8-1 - 3.1.8 CVE-2007-0451 * Tue Feb 13 2007 Warren Togami 3.1.7-9 - silence sa-update cron script system-config-printer-0.7.52-1.fc7 ---------------------------------- * Tue Feb 13 2007 Tim Waugh 0.7.52-1 - 0.7.52: - Sort models using cups.modelSort before scanning for a close match (bug #228505). - Fixed matching logic (bug #228505). tcl-1:8.4.13-9.fc7 ------------------ * Tue Feb 13 2007 Marcela Maslanova - 1:8.4.13-9 - review again * Fri Feb 09 2007 David Cantrell - 1:8.4.13-8 - rebuild * Thu Feb 08 2007 Marcela Maslanova - 1:8.4.13-7 - downgrade back to 8.4.13 - rhbz #226479 review tn5250-0.17.3-9.fc7 ------------------- * Tue Feb 13 2007 Karsten Hopp 0.17.3-9 - fix icon name - fix icon path * Tue Feb 13 2007 Karsten Hopp 0.17.3-8 - merge review changes (#226496): - move icons into hicolor subdir - require fedora-logos for the icons directory - require xterm for xt5250 - -devel subpackage requires automake, openssl-devel, ncurses-devel, pkgconfig - Requires(post): /usr/bin/tic - Requires(preun): coreutils - disable static libs tomboy-0.5.8-1.fc7 ------------------ * Tue Feb 13 2007 Matthias Clasen - 0.5.8-1 - Update to 0.5.8 valgrind-1:3.2.3-2 ------------------ * Tue Feb 13 2007 Jakub Jelinek 3.2.3-2 - fix valgrind.pc again * Tue Feb 13 2007 Jakub Jelinek 3.2.3-1 - update to 3.2.3 vte-0.15.3-1.fc7 ---------------- * Tue Feb 13 2007 Matthias Clasen 0.15.3-1 - Update to 0.15.3 xrestop-0.4-1.fc7 ----------------- * Tue Feb 13 2007 Adam Jackson 0.4-1 - Update to 0.4 yelp-2.16.2-3.fc7 ----------------- * Tue Feb 13 2007 Bill Nottingham 2.16.2-3 - own %{_datadir}/gnome/help (#205799) - rpmlint silencing: - add a URL: tag - add some docs yum-3.1.1-2.fc7 --------------- * Tue Feb 13 2007 James Bowes - 3.1.1-2 - Spec file updates from the merge review: use correct buildroot, mark logrotate file as noreplace, require correct versions of python and rpm, use name macro in source0. yum-metadata-parser-1.0.3-2.fc7 ------------------------------- * Tue Feb 13 2007 James Bowes - 1.0.3-2 - Spec file updates from the merge review: clean the buildroot. Broken deps for s390 ---------------------------------------------------------- kdemultimedia - 6:3.5.6-1.fc7.s390 requires libFLAC.so.7 postgresql-pltcl - 8.2.3-1.fc7.s390 requires libtcl8.5.so systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 vorbis-tools - 1:1.1.1-4.fc7.s390 requires libOggFLAC.so.3 vorbis-tools - 1:1.1.1-4.fc7.s390 requires libFLAC.so.7 Broken deps for ppc64 ---------------------------------------------------------- k3b - 0.12.17-1.ppc64 requires libFLAC++.so.5()(64bit) k3b - 0.12.17-1.ppc64 requires libFLAC.so.7()(64bit) kdemultimedia - 6:3.5.6-1.fc7.ppc64 requires libFLAC.so.7()(64bit) postgresql-pltcl - 8.2.3-1.fc7.ppc64 requires libtcl8.5.so()(64bit) vorbis-tools - 1:1.1.1-4.fc7.ppc64 requires libOggFLAC.so.3()(64bit) vorbis-tools - 1:1.1.1-4.fc7.ppc64 requires libFLAC.so.7()(64bit) Broken deps for ia64 ---------------------------------------------------------- k3b - 0.12.17-1.ia64 requires libFLAC.so.7()(64bit) k3b - 0.12.17-1.ia64 requires libFLAC++.so.5()(64bit) kdemultimedia - 6:3.5.6-1.fc7.ia64 requires libFLAC.so.7()(64bit) postgresql-pltcl - 8.2.3-1.fc7.ia64 requires libtcl8.5.so()(64bit) vorbis-tools - 1:1.1.1-4.fc7.ia64 requires libOggFLAC.so.3()(64bit) vorbis-tools - 1:1.1.1-4.fc7.ia64 requires libFLAC.so.7()(64bit) Broken deps for s390x ---------------------------------------------------------- kdemultimedia - 6:3.5.6-1.fc7.s390 requires libFLAC.so.7 kdemultimedia - 6:3.5.6-1.fc7.s390x requires libFLAC.so.7()(64bit) postgresql-pltcl - 8.2.3-1.fc7.s390x requires libtcl8.5.so()(64bit) vorbis-tools - 1:1.1.1-4.fc7.s390x requires libFLAC.so.7()(64bit) vorbis-tools - 1:1.1.1-4.fc7.s390x requires libOggFLAC.so.3()(64bit) Broken deps for x86_64 ---------------------------------------------------------- k3b - 0.12.17-1.x86_64 requires libFLAC++.so.5()(64bit) k3b - 0.12.17-1.x86_64 requires libFLAC.so.7()(64bit) kdemultimedia - 6:3.5.6-1.fc7.i386 requires libFLAC.so.7 kdemultimedia - 6:3.5.6-1.fc7.x86_64 requires libFLAC.so.7()(64bit) postgresql-pltcl - 8.2.3-1.fc7.x86_64 requires libtcl8.5.so()(64bit) vorbis-tools - 1:1.1.1-4.fc7.x86_64 requires libOggFLAC.so.3()(64bit) vorbis-tools - 1:1.1.1-4.fc7.x86_64 requires libFLAC.so.7()(64bit) Broken deps for i386 ---------------------------------------------------------- k3b - 0.12.17-1.i386 requires libFLAC.so.7 k3b - 0.12.17-1.i386 requires libFLAC++.so.5 kdemultimedia - 6:3.5.6-1.fc7.i386 requires libFLAC.so.7 postgresql-pltcl - 8.2.3-1.fc7.i386 requires libtcl8.5.so vorbis-tools - 1:1.1.1-4.fc7.i386 requires libFLAC.so.7 vorbis-tools - 1:1.1.1-4.fc7.i386 requires libOggFLAC.so.3 Broken deps for ppc ---------------------------------------------------------- k3b - 0.12.17-1.ppc requires libFLAC.so.7 k3b - 0.12.17-1.ppc requires libFLAC++.so.5 kdemultimedia - 6:3.5.6-1.fc7.ppc requires libFLAC.so.7 postgresql-pltcl - 8.2.3-1.fc7.ppc requires libtcl8.5.so vorbis-tools - 1:1.1.1-4.fc7.ppc requires libOggFLAC.so.3 vorbis-tools - 1:1.1.1-4.fc7.ppc requires libFLAC.so.7 From tonynelson at georgeanelson.com Wed Feb 14 14:09:22 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 14 Feb 2007 09:09:22 -0500 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20070214094158.GA3925@petra.dvoda.cz> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> <20070214094158.GA3925@petra.dvoda.cz> Message-ID: At 10:41 AM +0100 2/14/07, Karel Zak wrote: >On Sun, Nov 12, 2006 at 02:15:57PM -0900, Jeff Spaleta wrote: >> On 11/12/06, Jeff Spaleta wrote: >> >Okay its come to my attention that the readahead configs have a >> >difficult time being kept in sync as package updates roll out. For fc6 >> >right now for example readahead is out of sync with firefox libraries. >> > >> >Can we update readahead's implementation so we can get per package >> >control of the default configs? Is a readahead.d/ structure >> >appropriate here? >> >> Sorry... i didnt look hard enough... the readahead.d structure was >> added for fc6.... the problem is package maintainers aren't using it >> yet. I guess what I need to do is parse the existing config file... >> identify individual packages that could drop files in readahead.d/ >> and poke the appropriate maintainers in the eye about dropping a file >> in there as part of package payloading. >> >> Anyone want to help me construct the list of packages that could make >> sure of readahead.d/ on a per package basis based on the default >> readahead configs we have right now? > > Update: I've wrote a small and simple readahead-auditd that is able > to collect all filenames from boot process. It means everyone will be > able to generate unique list for his Fedora. And also I can maintain > default lists more effective now. I'm going to release an > experimental readahead package with this solution to FC7 next week. Would this work on FC6 as well? If the package can build cleanly on FC6 I'd try it out. Does the daemon keep running after booting finishes? Will it have anything more to do then? -- ____________________________________________________________________ TonyN.:' ' From jkeating at redhat.com Wed Feb 14 14:37:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Feb 2007 09:37:05 -0500 Subject: rawhide report: 20070214 changes In-Reply-To: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> References: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> Message-ID: <200702140937.05312.jkeating@redhat.com> On Wednesday 14 February 2007 06:03, buildsys at redhat.com wrote: > anaconda-11.2.0.22-1 > -------------------- > * Tue Feb 13 2007 Chris Lumens - 11.2.0.22-1 > - Load the ext3 module earlier to fix hd installs (#223749, #224534). > - Don't traceback in postconfig if it's not a kickstart install. > - Fix autopart string (dcantrell, #228192). > - Remove references to genheader (dcantrell). > - Rework text network UI to more closely follow graphical (dcantrell). This should actually work, I did a test compose with it yesterday. The first text part is black/white right now, but the Anaconda team is working on that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From darrellpf at gmail.com Wed Feb 14 14:54:44 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Wed, 14 Feb 2007 06:54:44 -0800 Subject: rawhide report: 20070214 changes In-Reply-To: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> References: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> Message-ID: > gnome-panel-2.17.91-6.fc7 > ------------------------- > * Tue Feb 13 2007 Matthias Clasen 2.17.91-6 > - Put the fast user switch applet in the default panel configuration > Updating : gnome-panel ##################### [ 53/115] error: %pre(control-center-2.17.91-1.fc7.i386) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping control-center-2.17.91-1.fc7 darrell From janina at rednote.net Wed Feb 14 16:16:11 2007 From: janina at rednote.net (Janina Sajka) Date: Wed, 14 Feb 2007 11:16:11 -0500 Subject: Firefox 3 In-Reply-To: <20070213175524.GA7375@rednote.net> References: <6f27515e0611140349x9ed5b3dob3c53654a300d137@mail.gmail.com> <20070213175524.GA7375@rednote.net> Message-ID: <20070214161611.GB7375@rednote.net> Janina Sajka writes: > I'm responding via the list , as it's the only email I have for you ... > > MATSUURA Takanori writes: > > Hi all, > > > > I put firefox-trunk SRPM based on current fedora rawhide one at > > http://homepage2.nifty.com/t-matsuu/install-memo/fc/ > > > This has been very helpful, and I have been bui9lding and publishing > binaries based on these src.rpm files @SpeakupModified.Org. > > However, there's now a problem where the src.rpms are not retrievable > via the URI provided. The pointers suggest a late January src.rpm, and > another on February 10, both of which have been yielding 404 errors. > Thanks for the fix. If anyone's interested in the binaries, they're at http://SpeakupModified.Org. ff3 is of paramount importance to a11y being the reason we are concerned to track closely on this. Janina > Janina > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka Phone: +1.202.595.7777 Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From michel.salim at gmail.com Wed Feb 14 16:49:06 2007 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 14 Feb 2007 11:49:06 -0500 Subject: /tmp filling up In-Reply-To: <20070214044534.GA30123@jadzia.bu.edu> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> <20070213213031.GA334@jadzia.bu.edu> <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> <20070214015449.GA19000@jadzia.bu.edu> <883cfe6d0702131906n1583b917xb328b4214d577ca2@mail.gmail.com> <20070214044534.GA30123@jadzia.bu.edu> Message-ID: <883cfe6d0702140849w32395fb9t3496ef2c4713ebff@mail.gmail.com> 2007/2/13, Matthew Miller : > On Tue, Feb 13, 2007 at 10:06:42PM -0500, Michel Salim wrote: > > >> Hmm. That narrows it down a bit - the culprit must be something that > > >> is run automatically when GNOME starts. I'll cook up something that > > >> will watch for a large file in /tmp and then find its owner. > > >lsof. > > well, lsof + inotify-tools. I want an early warning system, not find > > out when things start breaking. > > Theoretically once you've found out what it is you can make it stop. > It's beagle! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228718 Incidentally, does anyone know what command starts with 'beagled-h' ? rpm -ql'ing beagle does now show any. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From mmcgrath at redhat.com Wed Feb 14 16:59:03 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 14 Feb 2007 10:59:03 -0600 Subject: Smolt: firsboot revisited Message-ID: <45D33FD7.4010001@redhat.com> So smolt is still setup in firstboot and still is opt in. My question is do we want to install smolt as part of a default configuration with F7. My vote is yes. -Mike From jkeating at redhat.com Wed Feb 14 17:00:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Feb 2007 12:00:47 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <200702141200.47197.jkeating@redhat.com> On Wednesday 14 February 2007 11:59, Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. ?My question > is do we want to install smolt as part of a default configuration with > F7. ?My vote is yes. I vote yes too, but I want to see other votes before I just do it (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Wed Feb 14 17:08:31 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 14 Feb 2007 11:08:31 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <200702141108.31596.dennis@ausil.us> On Wednesday 14 February 2007 10:59, Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. I vote yes also -- Dennis Gilmore, RHCE From jwilson at redhat.com Wed Feb 14 17:10:09 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 14 Feb 2007 12:10:09 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <200702141200.47197.jkeating@redhat.com> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> Message-ID: <45D34271.1080800@redhat.com> Jesse Keating wrote: > On Wednesday 14 February 2007 11:59, Mike McGrath wrote: >> So smolt is still setup in firstboot and still is opt in. My question >> is do we want to install smolt as part of a default configuration with >> F7. My vote is yes. > > I vote yes too, but I want to see other votes before I just do it (: Another yes from me, but would be good to hear from people not under the Hat... -- Jarod Wilson jwilson at redhat.com From kzak at redhat.com Wed Feb 14 17:11:01 2007 From: kzak at redhat.com (Karel Zak) Date: Wed, 14 Feb 2007 18:11:01 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> <20070214094158.GA3925@petra.dvoda.cz> Message-ID: <20070214171101.GB3925@petra.dvoda.cz> On Wed, Feb 14, 2007 at 09:09:22AM -0500, Tony Nelson wrote: > At 10:41 AM +0100 2/14/07, Karel Zak wrote: > >On Sun, Nov 12, 2006 at 02:15:57PM -0900, Jeff Spaleta wrote: > >> On 11/12/06, Jeff Spaleta wrote: > >> >Okay its come to my attention that the readahead configs have a > >> >difficult time being kept in sync as package updates roll out. For fc6 > >> >right now for example readahead is out of sync with firefox libraries. > >> > > >> >Can we update readahead's implementation so we can get per package > >> >control of the default configs? Is a readahead.d/ structure > >> >appropriate here? > >> > >> Sorry... i didnt look hard enough... the readahead.d structure was > >> added for fc6.... the problem is package maintainers aren't using it > >> yet. I guess what I need to do is parse the existing config file... > >> identify individual packages that could drop files in readahead.d/ > >> and poke the appropriate maintainers in the eye about dropping a file > >> in there as part of package payloading. > >> > >> Anyone want to help me construct the list of packages that could make > >> sure of readahead.d/ on a per package basis based on the default > >> readahead configs we have right now? > > > > Update: I've wrote a small and simple readahead-auditd that is able > > to collect all filenames from boot process. It means everyone will be > > able to generate unique list for his Fedora. And also I can maintain > > default lists more effective now. I'm going to release an > > experimental readahead package with this solution to FC7 next week. > > Would this work on FC6 as well? If the package can build cleanly on FC6 > I'd try it out. No problem. I use FC6 too. > Does the daemon keep running after booting finishes? Will it have anything > more to do then? The default behaviour (depends on setting in a config file) will be automated finish few minutes after boot. It should be a good way how collect things that depend on user's habits (for example I start gnome-terminal, firefox and mutt after computer startup). I assume two steps: 1) collect filenames from boot process 2) post-processing -- things like sort by first block position All this things should be on demand. Later we can thing about more transparent and automated solution (or about completely different solution like fcache ;-). Karel -- Karel Zak From jdieter at gmail.com Wed Feb 14 17:14:21 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 14 Feb 2007 19:14:21 +0200 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <1171473261.6736.5.camel@jndwidescreen.lesbg.loc> On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. > > -Mike > My vote's yes, for what it's worth. Jonathan -------------- 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 jima at beer.tclug.org Wed Feb 14 17:27:56 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 14 Feb 2007 11:27:56 -0600 (CST) Subject: Smolt: firsboot revisited In-Reply-To: <45D34271.1080800@redhat.com> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> <45D34271.1080800@redhat.com> Message-ID: On Wed, 14 Feb 2007, Jarod Wilson wrote: > Jesse Keating wrote: >> On Wednesday 14 February 2007 11:59, Mike McGrath wrote: >>> So smolt is still setup in firstboot and still is opt in. My question >>> is do we want to install smolt as part of a default configuration with >>> F7. My vote is yes. >> >> I vote yes too, but I want to see other votes before I just do it (: > > Another yes from me, but would be good to hear from people not under the > Hat... I don't work for Red Hat, and I vote yes. (I am a smolt beta tester, though...) Jima From jwboyer at jdub.homelinux.org Wed Feb 14 17:08:26 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 14 Feb 2007 11:08:26 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <200702141200.47197.jkeating@redhat.com> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> Message-ID: <1171472906.4003.103.camel@zod.rchland.ibm.com> On Wed, 2007-02-14 at 12:00 -0500, Jesse Keating wrote: > On Wednesday 14 February 2007 11:59, Mike McGrath wrote: > > So smolt is still setup in firstboot and still is opt in. My question > > is do we want to install smolt as part of a default configuration with > > F7. My vote is yes. > > I vote yes too, but I want to see other votes before I just do it (: For which spins? Desktop, Server, and KDE? I would say sure. You'd have to ask the KDE spin guys though. And I don't think it should be functional on the LiveCD really... josh From bruno at wolff.to Wed Feb 14 17:39:20 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 14 Feb 2007 11:39:20 -0600 Subject: rawhide report: 20070214 changes In-Reply-To: <200702140937.05312.jkeating@redhat.com> References: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> <200702140937.05312.jkeating@redhat.com> Message-ID: <20070214173920.GA21630@wolff.to> On Wed, Feb 14, 2007 at 09:37:05 -0500, Jesse Keating wrote: > On Wednesday 14 February 2007 06:03, buildsys at redhat.com wrote: > > anaconda-11.2.0.22-1 > > -------------------- > > * Tue Feb 13 2007 Chris Lumens - 11.2.0.22-1 > > - Load the ext3 module earlier to fix hd installs (#223749, #224534). > > - Don't traceback in postconfig if it's not a kickstart install. > > - Fix autopart string (dcantrell, #228192). > > - Remove references to genheader (dcantrell). > > - Rework text network UI to more closely follow graphical (dcantrell). > > This should actually work, I did a test compose with it yesterday. The first > text part is black/white right now, but the Anaconda team is working on that. Is this going to the fix the all raid array elements are detected as being in md0 problem? I just tried to test it, but there was a pata regression so it doesn't see my disks at all. From fedora at leemhuis.info Wed Feb 14 17:43:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 14 Feb 2007 18:43:27 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <45D34A3F.8090906@leemhuis.info> Mike McGrath schrieb: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. +1 for "yes" CU thl From jwilliam at xmission.com Wed Feb 14 17:43:55 2007 From: jwilliam at xmission.com (Jerry Williams) Date: Wed, 14 Feb 2007 10:43:55 -0700 Subject: images back partition table unreadable Message-ID: <003f01c7505f$b30171c0$020aa8c0@a18> Rescue and normal install using pxeboot and NFS return messages about the partition table unreadable. Looks like anaconda is still broken. /bin/sh can't find shared library libtinfo.so.5 From skvidal at linux.duke.edu Wed Feb 14 17:49:12 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 14 Feb 2007 12:49:12 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <45D34A3F.8090906@leemhuis.info> References: <45D33FD7.4010001@redhat.com> <45D34A3F.8090906@leemhuis.info> Message-ID: <1171475352.27965.203.camel@cutter> On Wed, 2007-02-14 at 18:43 +0100, Thorsten Leemhuis wrote: > Mike McGrath schrieb: > > So smolt is still setup in firstboot and still is opt in. My question > > is do we want to install smolt as part of a default configuration with > > F7. My vote is yes. > > +1 for "yes" > me too -sv From david at lovesunix.net Wed Feb 14 18:01:33 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 14 Feb 2007 19:01:33 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <1171476093.13377.0.camel@dawkins> ons, 14 02 2007 kl. 10:59 -0600, skrev Mike McGrath: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. Smolt is doubleplus good, I vote yes. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 pemboa at gmail.com Wed Feb 14 18:04:32 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 14 Feb 2007 12:04:32 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <16de708d0702141004s52552fd0t779aaf2e9604349@mail.gmail.com> On 2/14/07, Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. > > -Mike > Not sure if following all the discussion on Smolt entitles me to vote - but I vote yes -- Fedora Core 6 and proud From rdieter at math.unl.edu Wed Feb 14 17:08:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 14 Feb 2007 11:08:55 -0600 Subject: Smolt: firsboot revisited References: <45D33FD7.4010001@redhat.com> Message-ID: Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. no harm, no brainer... yes -- Rex From tibbs at math.uh.edu Wed Feb 14 18:11:40 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Feb 2007 12:11:40 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> So smolt is still setup in firstboot and still is opt in. My MM> question is do we want to install smolt as part of a default MM> configuration with F7. My vote is yes. I vote yes as well, but then I'm a bit confused as how it would affect me as to date I've installed hundreds of machines and have only seen firstboot once. How does someone who uses kickstart for everything actually make use of smolt? - J< From clumens at redhat.com Wed Feb 14 18:12:05 2007 From: clumens at redhat.com (Chris Lumens) Date: Wed, 14 Feb 2007 13:12:05 -0500 Subject: rawhide report: 20070214 changes In-Reply-To: <20070214173920.GA21630@wolff.to> References: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> <200702140937.05312.jkeating@redhat.com> <20070214173920.GA21630@wolff.to> Message-ID: <20070214181205.GD4545@exeter.boston.redhat.com> > Is this going to the fix the all raid array elements are detected as being > in md0 problem? No. - Chris From peter at thecodergeek.com Wed Feb 14 17:52:29 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 14 Feb 2007 09:52:29 -0800 (PST) Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <57607.65.223.36.19.1171475549.squirrel@thecodergeek.com> Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. > Definitely another "yes" vote from me, as well. :] -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From stickster at gmail.com Wed Feb 14 18:15:46 2007 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 14 Feb 2007 13:15:46 -0500 Subject: /tmp filling up In-Reply-To: <883cfe6d0702140849w32395fb9t3496ef2c4713ebff@mail.gmail.com> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> <20070213213031.GA334@jadzia.bu.edu> <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> <20070214015449.GA19000@jadzia.bu.edu> <883cfe6d0702131906n1583b917xb328b4214d577ca2@mail.gmail.com> <20070214044534.GA30123@jadzia.bu.edu> <883cfe6d0702140849w32395fb9t3496ef2c4713ebff@mail.gmail.com> Message-ID: <1171476946.3935.67.camel@localhost.localdomain> On Wed, 2007-02-14 at 11:49 -0500, Michel Salim wrote: > 2007/2/13, Matthew Miller : > > On Tue, Feb 13, 2007 at 10:06:42PM -0500, Michel Salim wrote: > > > >> Hmm. That narrows it down a bit - the culprit must be something that > > > >> is run automatically when GNOME starts. I'll cook up something that > > > >> will watch for a large file in /tmp and then find its owner. > > > >lsof. > > > well, lsof + inotify-tools. I want an early warning system, not find > > > out when things start breaking. > > > > Theoretically once you've found out what it is you can make it stop. > > > It's beagle! > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228718 > > Incidentally, does anyone know what command starts with 'beagled-h' ? > rpm -ql'ing beagle does now show any. beagled-helper, isn't it? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 bruno at wolff.to Wed Feb 14 18:22:32 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 14 Feb 2007 12:22:32 -0600 Subject: rawhide report: 20070214 changes In-Reply-To: <20070214181205.GD4545@exeter.boston.redhat.com> References: <200702141103.l1EB3BCl007791@hs20-bc2-6.build.redhat.com> <200702140937.05312.jkeating@redhat.com> <20070214173920.GA21630@wolff.to> <20070214181205.GD4545@exeter.boston.redhat.com> Message-ID: <20070214182232.GA32397@wolff.to> On Wed, Feb 14, 2007 at 13:12:05 -0500, Chris Lumens wrote: > > Is this going to the fix the all raid array elements are detected as being > > in md0 problem? > > No. OK. I won't worry too much about about that until I see the next anaconda update. I reopened my kernel bug dealing with the hpt3x2 pata module. Until that is working (for a while I was getting the hpt37x module loaded which appeared to work, but based on the name wasn't the correct one for my controller) I am not going to be able to do much anyway. From stickster at gmail.com Wed Feb 14 18:16:21 2007 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 14 Feb 2007 13:16:21 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <45D34271.1080800@redhat.com> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> <45D34271.1080800@redhat.com> Message-ID: <1171476981.3935.69.camel@localhost.localdomain> On Wed, 2007-02-14 at 12:10 -0500, Jarod Wilson wrote: > Jesse Keating wrote: > > On Wednesday 14 February 2007 11:59, Mike McGrath wrote: > >> So smolt is still setup in firstboot and still is opt in. My question > >> is do we want to install smolt as part of a default configuration with > >> F7. My vote is yes. > > > > I vote yes too, but I want to see other votes before I just do it (: > > Another yes from me, but would be good to hear from people not under the > Hat... +1. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 dennis at ausil.us Wed Feb 14 18:24:44 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 14 Feb 2007 12:24:44 -0600 Subject: Smolt: firsboot revisited In-Reply-To: References: <45D33FD7.4010001@redhat.com> Message-ID: <200702141224.44910.dennis@ausil.us> On Wednesday 14 February 2007 12:11, Jason L Tibbitts III wrote: > >>>>> "MM" == Mike McGrath writes: > > MM> So smolt is still setup in firstboot and still is opt in. My > MM> question is do we want to install smolt as part of a default > MM> configuration with F7. My vote is yes. > > I vote yes as well, but then I'm a bit confused as how it would affect > me as to date I've installed hundreds of machines and have only seen > firstboot once. How does someone who uses kickstart for everything > actually make use of smolt? you would need to add the command to send the profile in your kickstart config after install and of course make sure smolt is in your package set -- Dennis Gilmore, RHCE From fedora at camperquake.de Wed Feb 14 17:53:22 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 14 Feb 2007 18:53:22 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <45D34C92.1030903@camperquake.de> Mike McGrath schrieb: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. Yes. From redhat at olen.net Wed Feb 14 17:48:59 2007 From: redhat at olen.net (Ola Thoresen) Date: Wed, 14 Feb 2007 18:48:59 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <45D34271.1080800@redhat.com> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> <45D34271.1080800@redhat.com> Message-ID: <45D34B8B.2020100@olen.net> Jarod Wilson wrote: > Jesse Keating wrote: >> On Wednesday 14 February 2007 11:59, Mike McGrath wrote: >>> So smolt is still setup in firstboot and still is opt in. My question >>> is do we want to install smolt as part of a default configuration with >>> F7. My vote is yes. >> >> I vote yes too, but I want to see other votes before I just do it (: > > Another yes from me, but would be good to hear from people not under the > Hat... > FWIW. A "Yes" from me as well, as long as it defaults to "Do not send anything". Rgds. -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From tonynelson at georgeanelson.com Wed Feb 14 18:43:51 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 14 Feb 2007 13:43:51 -0500 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20070214171101.GB3925@petra.dvoda.cz> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> <20070214094158.GA3925@petra.dvoda.cz> <20070214171101.GB3925@petra.dvoda.cz> Message-ID: At 6:11 PM +0100 2/14/07, Karel Zak wrote: >On Wed, Feb 14, 2007 at 09:09:22AM -0500, Tony Nelson wrote: >> At 10:41 AM +0100 2/14/07, Karel Zak wrote: ... >> > Update: I've wrote a small and simple readahead-auditd that is able >> > to collect all filenames from boot process. It means everyone will be >> > able to generate unique list for his Fedora. And also I can maintain >> > default lists more effective now. I'm going to release an >> > experimental readahead package with this solution to FC7 next week. >> >> Would this work on FC6 as well? If the package can build cleanly on FC6 >> I'd try it out. > > No problem. I use FC6 too. Good, thanks. >> Does the daemon keep running after booting finishes? Will it have anything >> more to do then? > > The default behaviour (depends on setting in a config file) will be > automated finish few minutes after boot. It should be a good way how > collect things that depend on user's habits (for example I start > gnome-terminal, firefox and mutt after computer startup). > > I assume two steps: > > 1) collect filenames from boot process > 2) post-processing -- things like sort by first block position > > All this things should be on demand. Later we can thing about more > transparent and automated solution (or about completely different > solution like fcache ;-). I think you're saying that the daemon will terminate after collecting data during boot, but the readahead.whenever files will only be regenerated when a separate command is run. Thus, after installing, say, a new Firefox, the readahead.d/default.later file will have stale entries in it until the user notices and runs that command. I expect it will become clear when I examine the source. -- ____________________________________________________________________ TonyN.:' ' From skvidal at linux.duke.edu Wed Feb 14 18:45:45 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 14 Feb 2007 13:45:45 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <45D34B8B.2020100@olen.net> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> <45D34271.1080800@redhat.com> <45D34B8B.2020100@olen.net> Message-ID: <1171478746.27965.209.camel@cutter> On Wed, 2007-02-14 at 18:48 +0100, Ola Thoresen wrote: > Jarod Wilson wrote: > > Jesse Keating wrote: > >> On Wednesday 14 February 2007 11:59, Mike McGrath wrote: > >>> So smolt is still setup in firstboot and still is opt in. My question > >>> is do we want to install smolt as part of a default configuration with > >>> F7. My vote is yes. > >> > >> I vote yes too, but I want to see other votes before I just do it (: > > > > Another yes from me, but would be good to hear from people not under the > > Hat... > > > > FWIW. > A "Yes" from me as well, as long as it defaults to "Do not send anything". 'opt in' means you must CHOOSE to send any data. The default mode is 'do not send any data' -sv From Lam at Lam.pl Wed Feb 14 18:50:58 2007 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 14 Feb 2007 19:50:58 +0100 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <1171476093.13377.0.camel@dawkins> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> Message-ID: <1171479058.4077.7.camel@pensja.lam.pl> Dnia 14-02-2007, ?ro o godzinie 19:01 +0100, David Nielsen napisa?(a): > Smolt is doubleplus good, I vote yes. I don't know nice 1984-ish word for "not so good", but: Can Smolt work from behind a proxy server, faking the User-Agent? Because, you know, I've tried to register some machines from a real production environment, with no luck. setenv http_proxy doesn't work, probably because our proxy rejects most of UA-s (or because Smolt doesn't honor http_proxy at all). Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From mmcgrath at redhat.com Wed Feb 14 19:29:40 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 14 Feb 2007 13:29:40 -0600 Subject: Smolt: firsboot revisited In-Reply-To: References: <45D33FD7.4010001@redhat.com> Message-ID: <45D36324.2070408@redhat.com> Jason L Tibbitts III wrote: > MM> So smolt is still setup in firstboot and still is opt in. My > MM> question is do we want to install smolt as part of a default > MM> configuration with F7. My vote is yes. > > I vote yes as well, but then I'm a bit confused as how it would affect > me as to date I've installed hundreds of machines and have only seen > firstboot once. How does someone who uses kickstart for everything > actually make use of smolt? This is my typical use case as well but I understand that many people (especially the more casual users) actually do use firstboot though. -Mike From mmcgrath at redhat.com Wed Feb 14 19:47:50 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 14 Feb 2007 13:47:50 -0600 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <1171479058.4077.7.camel@pensja.lam.pl> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> <1171479058.4077.7.camel@pensja.lam.pl> Message-ID: <45D36766.70408@redhat.com> Leszek Matok wrote: > Dnia 14-02-2007, ?ro o godzinie 19:01 +0100, David Nielsen napisa?(a): > >> Smolt is doubleplus good, I vote yes. >> > I don't know nice 1984-ish word for "not so good", but: > > Can Smolt work from behind a proxy server, faking the User-Agent? > Because, you know, I've tried to register some machines from a real > production environment, with no luck. setenv http_proxy doesn't work, > probably because our proxy rejects most of UA-s (or because Smolt > doesn't honor http_proxy at all). This is a must, I'll contact you as soon as its ready. -Mike From jeff at ocjtech.us Wed Feb 14 19:59:31 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 14 Feb 2007 13:59:31 -0600 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <45D36766.70408@redhat.com> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> <1171479058.4077.7.camel@pensja.lam.pl> <45D36766.70408@redhat.com> Message-ID: <1171483171.3851.5.camel@lt21223.campus.dmacc.edu> On Wed, 2007-02-14 at 13:47 -0600, Mike McGrath wrote: > Leszek Matok wrote: > > Dnia 14-02-2007, ?ro o godzinie 19:01 +0100, David Nielsen napisa?(a): > > > >> Smolt is doubleplus good, I vote yes. > >> > > I don't know nice 1984-ish word for "not so good", but: > > > > Can Smolt work from behind a proxy server, faking the User-Agent? > > Because, you know, I've tried to register some machines from a real > > production environment, with no luck. setenv http_proxy doesn't work, > > probably because our proxy rejects most of UA-s (or because Smolt > > doesn't honor http_proxy at all). > > This is a must, I'll contact you as soon as its ready. Setting http_proxy should work - I've tested that before. If your proxy blocks unusual User-Agent strings that may be more difficult to deal with - I'm not sure how easy it is to configure urlgrabber to use a different User-Agent string. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Wed Feb 14 20:03:38 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 14 Feb 2007 15:03:38 -0500 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <1171483171.3851.5.camel@lt21223.campus.dmacc.edu> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> <1171479058.4077.7.camel@pensja.lam.pl> <45D36766.70408@redhat.com> <1171483171.3851.5.camel@lt21223.campus.dmacc.edu> Message-ID: <1171483418.27965.234.camel@cutter> On Wed, 2007-02-14 at 13:59 -0600, Jeffrey C. Ollie wrote: > On Wed, 2007-02-14 at 13:47 -0600, Mike McGrath wrote: > > Leszek Matok wrote: > > > Dnia 14-02-2007, ?ro o godzinie 19:01 +0100, David Nielsen napisa?(a): > > > > > >> Smolt is doubleplus good, I vote yes. > > >> > > > I don't know nice 1984-ish word for "not so good", but: > > > > > > Can Smolt work from behind a proxy server, faking the User-Agent? > > > Because, you know, I've tried to register some machines from a real > > > production environment, with no luck. setenv http_proxy doesn't work, > > > probably because our proxy rejects most of UA-s (or because Smolt > > > doesn't honor http_proxy at all). > > > > This is a must, I'll contact you as soon as its ready. > > Setting http_proxy should work - I've tested that before. If your proxy > blocks unusual User-Agent strings that may be more difficult to deal > with - I'm not sure how easy it is to configure urlgrabber to use a > different User-Agent string. > for MOST proxies. Some Microsoft-based proxies like to make kittens suffer. -sv From jspaleta at gmail.com Wed Feb 14 20:23:06 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 14 Feb 2007 11:23:06 -0900 Subject: Can we make readahead more robust to package updates? In-Reply-To: <20070214094158.GA3925@petra.dvoda.cz> References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> <20070214094158.GA3925@petra.dvoda.cz> Message-ID: <604aa7910702141223y70493abbs46e96be8ff15ccc4@mail.gmail.com> On 2/14/07, Karel Zak wrote: > Update: I've wrote a small and simple readahead-auditd that is able > to collect all filenames from boot process. It means everyone will be > able to generate unique list for his Fedora. And also I can maintain > default lists more effective now. I'm going to release an > experimental readahead package with this solution to FC7 next week. Are you interested in collecting those 'unique' lists for some unscientific comparison of what the common boot time items are out in the wild? -jef From kzak at redhat.com Wed Feb 14 22:14:11 2007 From: kzak at redhat.com (Karel Zak) Date: Wed, 14 Feb 2007 23:14:11 +0100 Subject: Can we make readahead more robust to package updates? In-Reply-To: References: <604aa7910611121457i78961abbkc360777e15ce43b2@mail.gmail.com> <604aa7910611121515o1cdbd74bsa04114be2922cd0@mail.gmail.com> <20070214094158.GA3925@petra.dvoda.cz> <20070214171101.GB3925@petra.dvoda.cz> Message-ID: <20070214221411.GC3925@petra.dvoda.cz> On Wed, Feb 14, 2007 at 01:43:51PM -0500, Tony Nelson wrote: > I think you're saying that the daemon will terminate after collecting data > during boot, but the readahead.whenever files will only be regenerated when I'm not sure if we need to run the daemon for every boot. I don't know how expensive is our audit system... we will see. > a separate command is run. Thus, after installing, say, a new Firefox, the > readahead.d/default.later file will have stale entries in it until the user Prepare a new version of the readahead.d/default.later file is very simple (one qsort) and I think it will be possible to do it automatically. So, without a separate command. More attractive is to generate final version of the lists where filenames are sorted by first data block -- see "fast mode" in https://hosted.fedoraproject.org/projects/readahead/browser/README. Now in FC6 readahead supports the "full mode" only. The readahead in FC7 will support both modes, but regenerate lists for "fast mode" is more expensive -- it seems like a good job for cron or some manually started command. > notices and runs that command. I expect it will become clear when I > examine the source. Yeah, that's always more clear than my mails. Sorry ;-) Karel -- Karel Zak From a.badger at gmail.com Thu Feb 15 01:59:39 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Feb 2007 17:59:39 -0800 Subject: Smolt: firsboot revisited In-Reply-To: <1171472906.4003.103.camel@zod.rchland.ibm.com> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> <1171472906.4003.103.camel@zod.rchland.ibm.com> Message-ID: <1171504779.4472.72.camel@localhost.localdomain> On Wed, 2007-02-14 at 11:08 -0600, Josh Boyer wrote: > On Wed, 2007-02-14 at 12:00 -0500, Jesse Keating wrote: > > On Wednesday 14 February 2007 11:59, Mike McGrath wrote: > > > So smolt is still setup in firstboot and still is opt in. My question > > > is do we want to install smolt as part of a default configuration with > > > F7. My vote is yes. > > > > I vote yes too, but I want to see other votes before I just do it (: > > For which spins? Desktop, Server, and KDE? I would say sure. You'd > have to ask the KDE spin guys though. And I don't think it should be > functional on the LiveCD really... > +1 -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 rc040203 at freenet.de Thu Feb 15 04:48:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 05:48:36 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <1171514916.3622.345.camel@mccallum.corsepiu.local> On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. My vote is no. * It adds no user usable functionality * It adds further package bloat * is legally questionable. Ralf From skvidal at linux.duke.edu Thu Feb 15 05:34:36 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 00:34:36 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171514916.3622.345.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> Message-ID: <1171517676.27965.287.camel@cutter> On Thu, 2007-02-15 at 05:48 +0100, Ralf Corsepius wrote: > On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > > So smolt is still setup in firstboot and still is opt in. My question > > is do we want to install smolt as part of a default configuration with > > F7. My vote is yes. > > My vote is no. > > * is legally questionable. If you have a concern here, please file a bug on it and I will make sure it gets passed into the legal queue for evaluation. Please list the country where you think the law might be violated. Thanks, -sv From fedora at leemhuis.info Thu Feb 15 05:55:27 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 15 Feb 2007 06:55:27 +0100 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <45D36766.70408@redhat.com> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> <1171479058.4077.7.camel@pensja.lam.pl> <45D36766.70408@redhat.com> Message-ID: <45D3F5CF.40003@leemhuis.info> On 14.02.2007 20:47, Mike McGrath wrote: > Leszek Matok wrote: >> Dnia 14-02-2007, ?ro o godzinie 19:01 +0100, David Nielsen napisa?(a): >>> Smolt is doubleplus good, I vote yes. >> I don't know nice 1984-ish word for "not so good", but: >> Can Smolt work from behind a proxy server, faking the User-Agent? >> Because, you know, I've tried to register some machines from a real >> production environment, with no luck. setenv http_proxy doesn't work, >> probably because our proxy rejects most of UA-s (or because Smolt >> doesn't honor http_proxy at all). > This is a must, I'll contact you as soon as its ready. Side note: Not that it helps much in the firstboot case -- as a normal user who does a normal install you afaik are not able to configure the proxy before firstboot or while in it. (?) CU thl (?) that why you also can't use external repos in anaconda if your machine live in a network that forces the use of a proxy (yes, I have machines in such networks -- that sucks). Reminder for those that are interested: proxy support for anaconda RFE is #125917 From rc040203 at freenet.de Thu Feb 15 05:58:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 06:58:24 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <1171517676.27965.287.camel@cutter> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> Message-ID: <1171519104.3622.358.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 00:34 -0500, seth vidal wrote: > On Thu, 2007-02-15 at 05:48 +0100, Ralf Corsepius wrote: > > On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > > > So smolt is still setup in firstboot and still is opt in. My question > > > is do we want to install smolt as part of a default configuration with > > > F7. My vote is yes. > > > > My vote is no. > > > > > * is legally questionable. > > If you have a concern here, please file a bug on it and I will make sure > it gets passed into the legal queue for evaluation. Everything that needed to be said had been communicated to Mr. McGrath. It's up to him to decide on what to do with it. > Please list the > country where you think the law might be violated. Probably most parts of the world outside of the US, definitely in Europe, definitely in Germany, probably also in some part of Asia. Besides this, you should understand that data-privacy plays a much more important role than what you are used to in many countries and communities - As I already said: You are playing with a loaded gun, right in front of your face. Here in Germany, many folks consider any such transition from user to vendor as "hostile espionage". Press is full of articles flaming manufactures for this and related topics. It will definitely be reason for users not to choose Fedora in future (It might have escaped you, but Microsoft and other vendors having done the similar is the reason why many users choose to switch to Linux). Ralf From skvidal at linux.duke.edu Thu Feb 15 06:03:05 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 01:03:05 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171519104.3622.358.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> Message-ID: <1171519385.27965.290.camel@cutter> On Thu, 2007-02-15 at 06:58 +0100, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 00:34 -0500, seth vidal wrote: > > On Thu, 2007-02-15 at 05:48 +0100, Ralf Corsepius wrote: > > > On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > > > > So smolt is still setup in firstboot and still is opt in. My question > > > > is do we want to install smolt as part of a default configuration with > > > > F7. My vote is yes. > > > > > > My vote is no. > > > > > > > > * is legally questionable. > > > > If you have a concern here, please file a bug on it and I will make sure > > it gets passed into the legal queue for evaluation. > > Everything that needed to be said had been communicated to Mr. McGrath. > It's up to him to decide on what to do with it. > > > Please list the > > country where you think the law might be violated. > Probably most parts of the world outside of the US, definitely in > Europe, definitely in Germany, probably also in some part of Asia. > > Besides this, you should understand that data-privacy plays a much more > important role than what you are used to in many countries and > communities - As I already said: You are playing with a loaded gun, > right in front of your face. > > Here in Germany, many folks consider any such transition from user to > vendor as "hostile espionage". Press is full of articles flaming > manufactures for this and related topics. > > It will definitely be reason for users not to choose Fedora in future > (It might have escaped you, but Microsoft and other vendors having done > the similar is the reason why many users choose to switch to Linux). No need for such a screed. I wasn't arguing with you. I was simply volunteering to take the issues through the board to legal to get them addressed. I'll talk to Mike and make sure I have a firm handle on your concerns so I can make sure they are represented. Thanks, -sv From jspaleta at gmail.com Thu Feb 15 06:02:41 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 14 Feb 2007 21:02:41 -0900 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <604aa7910702142202x34bbbb9dyee53c9a95dfe1872@mail.gmail.com> On 2/14/07, Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. Now that its reporting correctly for my current systems.... yes -jef"did i happen to mention that my votes can be bought?"spaleta From fedora at leemhuis.info Thu Feb 15 06:21:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 15 Feb 2007 07:21:26 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <1171519104.3622.358.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> Message-ID: <45D3FBE6.4040706@leemhuis.info> On 15.02.2007 06:58, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 00:34 -0500, seth vidal wrote: >> On Thu, 2007-02-15 at 05:48 +0100, Ralf Corsepius wrote: >>> On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: >>>> So smolt is still setup in firstboot and still is opt in. My question >>>> is do we want to install smolt as part of a default configuration with >>>> F7. My vote is yes. >>> My vote is no. >>> * is legally questionable. >> If you have a concern here, please file a bug on it and I will make sure >> it gets passed into the legal queue for evaluation. > Everything that needed to be said had been communicated to Mr. McGrath. > It's up to him to decide on what to do with it. Could you give a quick summary please? That would be very helpful, as there were a lot of mails on this topic in the last month, and one can't know which of them and which arguments in them you exactly mean. Thanks in advance. >> Please list the >> country where you think the law might be violated. > Probably most parts of the world outside of the US, definitely in > Europe, definitely in Germany, probably also in some part of Asia. I'm not a lawyer, but I live in Germany, and I think this kind of anonymous opt-in mechanism should be fine, as long as it's clearly documented what kind of informations are send. Ralf, could you give me some insight why you think this should the law might be violated? @mmcgrath, is it clearly documented what informations are send? Wuld be ideal if one could open a window to see what informations are going to be send exactly. And will that part also translated -- it *could* be problematic if the text is not localized... > [...] CU thl From luya_tfz at thefinalzone.com Thu Feb 15 06:33:41 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Thu, 15 Feb 2007 01:33:41 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171517676.27965.287.camel@cutter> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> Message-ID: <1171521221.45d3fec5cded8@ssl.mecca.ca> Luya nods for enable smolt by default. -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From bernie at develer.com Thu Feb 15 06:37:06 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 15 Feb 2007 07:37:06 +0100 Subject: Switching to ncurses In-Reply-To: <456FF253.9010503@develer.com> References: <456FF253.9010503@develer.com> Message-ID: <45D3FF92.2020202@develer.com> Bernardo Innocenti wrote: > bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 > text data bss dec hex filename > 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 > 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 It's somewhat better now: bender:/# size /lib64/libncurses.so.5 /lib64/libtinfo.so.5 /lib64/libtermcap.so.2 text data bss dec hex filename 122768 2296 520 125584 1ea90 /lib64/libncurses.so.5 110682 14048 2064 126794 1ef4a /lib64/libtinfo.so.5 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 And now bash links against libtinfo only. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rc040203 at freenet.de Thu Feb 15 07:20:21 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 08:20:21 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <45D3FBE6.4040706@leemhuis.info> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> Message-ID: <1171524021.3622.419.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 07:21 +0100, Thorsten Leemhuis wrote: > On 15.02.2007 06:58, Ralf Corsepius wrote: > > On Thu, 2007-02-15 at 00:34 -0500, seth vidal wrote: > >> On Thu, 2007-02-15 at 05:48 +0100, Ralf Corsepius wrote: > >>> On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > >>>> So smolt is still setup in firstboot and still is opt in. My question > >>>> is do we want to install smolt as part of a default configuration with > >>>> F7. My vote is yes. > >>> My vote is no. > >>> * is legally questionable. > >> If you have a concern here, please file a bug on it and I will make sure > >> it gets passed into the legal queue for evaluation. > > Everything that needed to be said had been communicated to Mr. McGrath. > > It's up to him to decide on what to do with it. > > Could you give a quick summary please? Firstly, please note that I said "questionable", i.e. would have to carefully examined by a specialized lawyer. Secondly you should be aware that is actually is about two separate issue: "Legality and correctness" On the legal side, it is "Schutz der Privatsph?re" (Protection of private sphere") in general, a legally complicated matter with many booby-traps hidden inside. In Germany, even "collecting data without prior consent" in many cases is considered illegal. E.g. there had been a precedence in which someone having set up a webcam monitoring his house's front yard has been considered illegal for breach of privacy. It's the reason why most shops using camera supervision nowadays have signs explicitly notifying their customers. Things become further complicated when personalized data comes into play (BDSG - Bundesdatenschutzgesetz - "Federal Law on Data Privacy"). The crucial points here would be "when to consider data personalized" and "which data is allowed to be collected under which circumstances". Rule of thumb: Any personalized data must not be collected unless it is technically required for a transaction (Classic example: Any bill must be removed from cashier systems after the customer has paid, within a predefined timeframe). I.e. from a German point of view. Smolt's "machine id" in connection with the IP address needs to be legally reviewed if this qualifies as "personalized data". I for one regard it as such. > >> Please list the > >> country where you think the law might be violated. > > Probably most parts of the world outside of the US, definitely in > > Europe, definitely in Germany, probably also in some part of Asia. > > I'm not a lawyer, but I live in Germany, and I think this kind of > anonymous opt-in mechanism should be fine, as long as it's clearly > documented what kind of informations are send. IANAL, too, but, yes this matches with my knowledge. I repeatedly said, to be legally safe in Germany, any such transaction must be opt-in (I am aware this not to be 100% legally correct, but it's the "rule of thumb to be safe"). The other point is "is it correctlyness" to transmit such data: Here apparently German perception is different from that in other countries. Microsoft and other vendors had been flamed, Intel was flamed for their CPU-Ids (they didn't even transmit anything, simply the fact they implemented an option was enough), many other vendors followed, ... Check heise's newticker for press notices concerning this, they are easy to find .... This touches security as well as privacy. Ask yourself: If you were an administration/government/military organisation, an enterprise's financial/development department, a bank, simply a shop archiving your customer data or other entity dealing with "secret"/"private" information, would you want details about your systems to be exposed to the public? Consider secret services/competitors spying the net, consider man-in-the-middle attacks, consider intruders harvesting the database, ... I would not - I would take any measure to prevent and obsure such transmission. Ralf From skvidal at linux.duke.edu Thu Feb 15 07:33:31 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 02:33:31 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171524021.3622.419.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> Message-ID: <1171524811.27965.307.camel@cutter> On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > Firstly, please note that I said "questionable", i.e. would have to > carefully examined by a specialized lawyer. > > Secondly you should be aware that is actually is about two separate > issue: "Legality and correctness" > > On the legal side, it is "Schutz der Privatsph?re" (Protection of > private sphere") in general, a legally complicated matter with many > booby-traps hidden inside. > > > In Germany, even "collecting data without prior consent" in many cases > is considered illegal. E.g. there had been a precedence in which someone > having set up a webcam monitoring his house's front yard has been > considered illegal for breach of privacy. It's the reason why most shops > using camera supervision nowadays have signs explicitly notifying their > customers. There is prior consent. The information is not transmitted until the user consents and it defaults to NOT transmitting. > Things become further complicated when personalized data comes into play > (BDSG - Bundesdatenschutzgesetz - "Federal Law on Data Privacy"). > The crucial points here would be "when to consider data personalized" > and "which data is allowed to be collected under which circumstances". > > Rule of thumb: Any personalized data must not be collected unless it is > technically required for a transaction (Classic example: Any bill must > be removed from cashier systems after the customer has paid, within a > predefined timeframe). > > I.e. from a German point of view. Smolt's "machine id" in connection > with the IP address needs to be legally reviewed if this qualifies as > "personalized data". I for one regard it as such. > but there is no requirement that this data be transmitted. In fact, in the default case that smolt is configured for - it is not transmitted. and in order to use the system you need not transmit it. If I ask you for your name and you choose not to give it have I committed a crime by asking and giving you the option of giving me the information? Of course not. can you imagine what a law that made that illegal would look like? > IANAL, too, but, yes this matches with my knowledge. I repeatedly said, > to be legally safe in Germany, any such transaction must be opt-in (I am > aware this not to be 100% legally correct, but it's the "rule of thumb > to be safe"). and we are safe in that regard. smolt is opt-in. > The other point is "is it correctlyness" to transmit such data: > We're giving the user the choice to send this data or not. We default to NOT sending this information. How much more correct can you get? > Ask yourself: If you were an administration/government/military > organisation, an enterprise's financial/development department, a bank, > simply a shop archiving your customer data or other entity dealing with > "secret"/"private" information, would you want details about your > systems to be exposed to the public? > > Consider secret services/competitors spying the net, consider > man-in-the-middle attacks, consider intruders harvesting the > database, ... > > I would not - I would take any measure to prevent and obsure such > transmission. Thats fine. In that case you can simply instruct your users to not send such information and the users can simply just click 'next' on the menu. But there's no legal issue with the above, only a corporate or administrative policy issue. -sv From david at lovesunix.net Thu Feb 15 07:36:31 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 15 Feb 2007 08:36:31 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <1171472906.4003.103.camel@zod.rchland.ibm.com> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> <1171472906.4003.103.camel@zod.rchland.ibm.com> Message-ID: <1171524991.15716.12.camel@dawkins> ons, 14 02 2007 kl. 11:08 -0600, skrev Josh Boyer: > On Wed, 2007-02-14 at 12:00 -0500, Jesse Keating wrote: > > On Wednesday 14 February 2007 11:59, Mike McGrath wrote: > > > So smolt is still setup in firstboot and still is opt in. My question > > > is do we want to install smolt as part of a default configuration with > > > F7. My vote is yes. > > > > I vote yes too, but I want to see other votes before I just do it (: > > For which spins? Desktop, Server, and KDE? I would say sure. You'd > have to ask the KDE spin guys though. And I don't think it should be > functional on the LiveCD really... It might be useful to have it available. I often boot a LiveCD on friends machines to see if the hardware is generally supported. It would be helpful to have a nice little frontend to tell the stats page "This is the liveCD, all this hardware works" (ands maybe even flag something as problematic). I de realise this is more a LCHD (or whatever that larger database is called - honestly it needs a sexier name). - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- 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 rc040203 at freenet.de Thu Feb 15 08:15:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 09:15:38 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <1171524811.27965.307.camel@cutter> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> Message-ID: <1171527338.3622.457.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > Ask yourself: If you were an administration/government/military > > organisation, an enterprise's financial/development department, a bank, > > simply a shop archiving your customer data or other entity dealing with > > "secret"/"private" information, would you want details about your > > systems to be exposed to the public? > > > > Consider secret services/competitors spying the net, consider > > man-in-the-middle attacks, consider intruders harvesting the > > database, ... > > > > I would not - I would take any measure to prevent and obsure such > > transmission. > > Thats fine. In that case you can simply instruct your users to not send > such information and the users can simply just click 'next' on the menu. Many folks around here would advise their management to classify Fedora as not trustworthy and to ban it :-o. Is exactly the kind of argumentation why before-mentioned institutions chose to migrate away from Microsoft systems. Ralf From michel.salim at gmail.com Thu Feb 15 08:15:39 2007 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 15 Feb 2007 03:15:39 -0500 Subject: /tmp filling up In-Reply-To: <1171476946.3935.67.camel@localhost.localdomain> References: <883cfe6d0702131028s5d3670d3y943c123519fed89f@mail.gmail.com> <20070213213031.GA334@jadzia.bu.edu> <883cfe6d0702131555w677b1417nfca3f18eb39f1b29@mail.gmail.com> <20070214015449.GA19000@jadzia.bu.edu> <883cfe6d0702131906n1583b917xb328b4214d577ca2@mail.gmail.com> <20070214044534.GA30123@jadzia.bu.edu> <883cfe6d0702140849w32395fb9t3496ef2c4713ebff@mail.gmail.com> <1171476946.3935.67.camel@localhost.localdomain> Message-ID: <883cfe6d0702150015s42fe86ccq464ee1b1c5a98c69@mail.gmail.com> 2007/2/14, Paul W. Frields : > On Wed, 2007-02-14 at 11:49 -0500, Michel Salim wrote: > > 2007/2/13, Matthew Miller : > > > On Tue, Feb 13, 2007 at 10:06:42PM -0500, Michel Salim wrote: > > > > >> Hmm. That narrows it down a bit - the culprit must be something that > > > > >> is run automatically when GNOME starts. I'll cook up something that > > > > >> will watch for a large file in /tmp and then find its owner. > > > > >lsof. > > > > well, lsof + inotify-tools. I want an early warning system, not find > > > > out when things start breaking. > > > > > > Theoretically once you've found out what it is you can make it stop. > > > > > It's beagle! > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228718 > > > > Incidentally, does anyone know what command starts with 'beagled-h' ? > > rpm -ql'ing beagle does now show any. > > beagled-helper, isn't it? > Yes, but where is the binary located? The closest I've found is %{_libdir}/beagle/beagled-index-helper . Can a process change its reported name? -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From skvidal at linux.duke.edu Thu Feb 15 08:18:12 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 03:18:12 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171527338.3622.457.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> Message-ID: <1171527492.27965.309.camel@cutter> On Thu, 2007-02-15 at 09:15 +0100, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > Ask yourself: If you were an administration/government/military > > > organisation, an enterprise's financial/development department, a bank, > > > simply a shop archiving your customer data or other entity dealing with > > > "secret"/"private" information, would you want details about your > > > systems to be exposed to the public? > > > > > > Consider secret services/competitors spying the net, consider > > > man-in-the-middle attacks, consider intruders harvesting the > > > database, ... > > > > > > I would not - I would take any measure to prevent and obsure such > > > transmission. > > > > Thats fine. In that case you can simply instruct your users to not send > > such information and the users can simply just click 'next' on the menu. > Many folks around here would advise their management to classify Fedora > as not trustworthy and to ban it :-o. > > Is exactly the kind of argumentation why before-mentioned institutions > chose to migrate away from Microsoft systems. but that's not a legal issue. You said you had a legal concern with including smolt and this is not a legal issue at all. -sv From pemboa at gmail.com Thu Feb 15 08:19:49 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 16 Feb 2007 02:19:49 +1800 Subject: Smolt: firsboot revisited In-Reply-To: <1171527338.3622.457.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> Message-ID: <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> On 2/16/07, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > Ask yourself: If you were an administration/government/military > > > organisation, an enterprise's financial/development department, a bank, > > > simply a shop archiving your customer data or other entity dealing with > > > "secret"/"private" information, would you want details about your > > > systems to be exposed to the public? > > > > > > Consider secret services/competitors spying the net, consider > > > man-in-the-middle attacks, consider intruders harvesting the > > > database, ... > > > > > > I would not - I would take any measure to prevent and obsure such > > > transmission. > > > > Thats fine. In that case you can simply instruct your users to not send > > such information and the users can simply just click 'next' on the menu. > Many folks around here would advise their management to classify Fedora > as not trustworthy and to ban it :-o. > > Is exactly the kind of argumentation why before-mentioned institutions > chose to migrate away from Microsoft systems. > > Ralf I don't think you've ever said how the information is being sent without user permission or what the personal data is that is being sent. -- Fedora Core 6 and proud From rc040203 at freenet.de Thu Feb 15 08:32:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 09:32:35 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> Message-ID: <1171528355.3622.467.camel@mccallum.corsepiu.local> On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > On 2/16/07, Ralf Corsepius wrote: > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > I don't think you've ever said how the information is being sent > without user permission or what the personal data is that is being > sent. The smolt developers would be the ones to reply this. AFAIS (I banned smolt from my installations), it transmits a machine-id, several HW details (CPU brand, type, peripherials, bogomips) and OS details via http. i.e. they have the IP, they have a "machine-id", and they have information which is not publicly available elsewhere. Ralf From skvidal at linux.duke.edu Thu Feb 15 08:37:44 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 03:37:44 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171528355.3622.467.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> Message-ID: <1171528664.27965.318.camel@cutter> On Thu, 2007-02-15 at 09:32 +0100, Ralf Corsepius wrote: > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > On 2/16/07, Ralf Corsepius wrote: > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > I don't think you've ever said how the information is being sent > > without user permission or what the personal data is that is being > > sent. > The smolt developers would be the ones to reply this. The smolt developers and the smolt code HAS replied to this. there is no way for smolt to transmit information w/o the consent of the user. The user must explicitly agree to send the information. If the user chooses the default behavior then the information is not transmitted. so in any execution of smolt the user has 2 options: 1. select no, do not send this information 2. select yes, send this information option 1 is already selected for the user. If they make no change to the selection then they will NOT transmit information. -sv From rc040203 at freenet.de Thu Feb 15 08:43:47 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 09:43:47 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <1171528664.27965.318.camel@cutter> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <1171528664.27965.318.camel@cutter> Message-ID: <1171529027.3622.474.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 03:37 -0500, seth vidal wrote: > On Thu, 2007-02-15 at 09:32 +0100, Ralf Corsepius wrote: > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > On 2/16/07, Ralf Corsepius wrote: > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > I don't think you've ever said how the information is being sent > > > without user permission or what the personal data is that is being > > > sent. > > > The smolt developers would be the ones to reply this. > The smolt developers and the smolt code HAS replied to this. Yes, but this thread started with "Shall smolt be installed by default", so the question wasn't "opt-in/opt-out", it was "installed by default" I expressed my opinion and said: No, ... Arthur's was "how" - I said "http:" and "what" Ralf From skvidal at linux.duke.edu Thu Feb 15 08:50:10 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 03:50:10 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171529027.3622.474.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <1171528664.27965.318.camel@cutter> <1171529027.3622.474.camel@mccallum.corsepiu.local> Message-ID: <1171529410.27965.321.camel@cutter> On Thu, 2007-02-15 at 09:43 +0100, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 03:37 -0500, seth vidal wrote: > > On Thu, 2007-02-15 at 09:32 +0100, Ralf Corsepius wrote: > > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > > On 2/16/07, Ralf Corsepius wrote: > > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > > > I don't think you've ever said how the information is being sent > > > > without user permission or what the personal data is that is being > > > > sent. > > > > > The smolt developers would be the ones to reply this. > > The smolt developers and the smolt code HAS replied to this. > > Yes, but this thread started with "Shall smolt be installed by default", > so the question wasn't "opt-in/opt-out", it was "installed by default" just b/c something is installed by default means nothing about whether or not you have to run it and nothing further on whether or not you have to agree to do anything if it does run. -sv From pemboa at gmail.com Thu Feb 15 08:50:03 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 16 Feb 2007 02:50:03 +1800 Subject: Smolt: firsboot revisited In-Reply-To: <1171529027.3622.474.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <1171528664.27965.318.camel@cutter> <1171529027.3622.474.camel@mccallum.corsepiu.local> Message-ID: <16de708d0702150050r51eff319i6715a412a86150d1@mail.gmail.com> On 2/16/07, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 03:37 -0500, seth vidal wrote: > > On Thu, 2007-02-15 at 09:32 +0100, Ralf Corsepius wrote: > > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > > On 2/16/07, Ralf Corsepius wrote: > > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > > > I don't think you've ever said how the information is being sent > > > > without user permission or what the personal data is that is being > > > > sent. > > > > > The smolt developers would be the ones to reply this. > > The smolt developers and the smolt code HAS replied to this. > > Yes, but this thread started with "Shall smolt be installed by default", > so the question wasn't "opt-in/opt-out", it was "installed by default" > > I expressed my opinion and said: No, ... > > Arthur's was "how" - I said "http:" and "what" > > Ralf I think "installed by default" here means that the Smolt code will be on the install media and copied to the hard drive by default (if even that much) - installing sends no data - the user has to choose to run it. hence the "opt-in" . The discussion on opt-in/out ended long ago. -- Fedora Core 6 and proud From pemboa at gmail.com Thu Feb 15 08:46:03 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 16 Feb 2007 02:46:03 +1800 Subject: Smolt: firsboot revisited In-Reply-To: <1171528355.3622.467.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> Message-ID: <16de708d0702150046n2af8f9f9l188c01e4da28b5b7@mail.gmail.com> On 2/16/07, Ralf Corsepius wrote: > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > On 2/16/07, Ralf Corsepius wrote: > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > I don't think you've ever said how the information is being sent > > without user permission or what the personal data is that is being > > sent. > The smolt developers would be the ones to reply this. > > AFAIS (I banned smolt from my installations), it transmits > a machine-id, several HW details (CPU brand, type, peripherials, > bogomips) and OS details via http. > > i.e. they have the IP, they have a "machine-id", and they have > information which is not publicly available elsewhere. > > Ralf > Fair enough. However the machine-id cannot legally id your computer, nor is it supposed to be able to. As far as I understand, your machine-id will be specific to Fedora. But considiering you have to TELL IT to transmit thoise things, how can there be any legal problems? Or are you saying it is illegal to ask someone to fillout a survey form , where they can simply ignore, in your country? -- Fedora Core 6 and proud From baris at teamforce.name.tr Thu Feb 15 09:50:43 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Thu, 15 Feb 2007 11:50:43 +0200 Subject: Smolt: firsboot revisited In-Reply-To: <1171529027.3622.474.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <1171528664.27965.318.camel@cutter> <1171529027.3622.474.camel@mccallum.corsepiu.local> Message-ID: <1171533043.3214.36.camel@localhost.localdomain> Why is that so different from bug-buddy sending bug report, or MS Windows sending bug report using already installed (for MS case, even embedded) software? If it was a legal issue, it might have been brought forward years ago and should have been resolved already. For those mechanisms you can choose to send it or easily discard it. I'm not quite sure about MS bug reporting tool, but bug-buddy is helpful for GNOME developers. I hope smolt would serve similar benefits. And well my vote is 'yes' if it counts. On Thu, 2007-02-15 at 09:43 +0100, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 03:37 -0500, seth vidal wrote: > > On Thu, 2007-02-15 at 09:32 +0100, Ralf Corsepius wrote: > > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > > On 2/16/07, Ralf Corsepius wrote: > > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > > > I don't think you've ever said how the information is being sent > > > > without user permission or what the personal data is that is being > > > > sent. > > > > > The smolt developers would be the ones to reply this. > > The smolt developers and the smolt code HAS replied to this. > > Yes, but this thread started with "Shall smolt be installed by default", > so the question wasn't "opt-in/opt-out", it was "installed by default" > > I expressed my opinion and said: No, ... > > Arthur's was "how" - I said "http:" and "what" > > Ralf > > From rc040203 at freenet.de Thu Feb 15 09:57:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 10:57:30 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <16de708d0702150046n2af8f9f9l188c01e4da28b5b7@mail.gmail.com> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <16de708d0702150046n2af8f9f9l188c01e4da28b5b7@mail.gmail.com> Message-ID: <1171533450.3622.509.camel@mccallum.corsepiu.local> On Fri, 2007-02-16 at 02:46 +0000, Arthur Pemberton wrote: > On 2/16/07, Ralf Corsepius wrote: > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > On 2/16/07, Ralf Corsepius wrote: > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > I don't think you've ever said how the information is being sent > > > without user permission or what the personal data is that is being > > > sent. > > The smolt developers would be the ones to reply this. > > > > AFAIS (I banned smolt from my installations), it transmits > > a machine-id, several HW details (CPU brand, type, peripherials, > > bogomips) and OS details via http. > > > > i.e. they have the IP, they have a "machine-id", and they have > > information which is not publicly available elsewhere. > > > > Ralf > > > > Fair enough. However the machine-id cannot legally id your computer, > nor is it supposed to be able to. As far as I understand, your > machine-id will be specific to Fedora. > > But considiering you have to TELL IT to transmit thoise things, how > can there be any legal problems? There is one dead-beat argument likely rendering this discussion moot: Not wrt. smolt, because the server is hosted in a foreign country, therefore the data, unless it's contents is lawful, is likely not subject to German laws (To be verified by a German lawyer). => Case closed from a US-biased, RH/Fedora-biased view. The actual problems remain: "trust" and "safety". The thresholds to trust any such site probably are much higher in Germany than in other countries because people are aware about different standards of "privacy policies" in different countries/institutions. [This applies even within Germany. Media are filled with warnings and flames on certain enterprises on what "public opinion considers abuse of data privacy"] > Or are you saying it is illegal to > ask someone to fillout a survey form , No, it is not, but (at least some) Germans probably will be very reluctant to fill out such forms and be very careful about what they fill out. > where they can simply ignore, > in your country? Common practice on "statistical survey forms" is them to carry an explicit "data-privacy disclaimer", which people explicitly have to check (== opt-in), which details what the data is being used for, to whom it will be passed on and when it will be deleted. Typical are disclaimers similar to [ ] Personalized data and survey data will be kept strictly separate. Survey data does not allow any conclusion to the person having submitted the data. Personalized data will only be used for administrational purposes during this survey and will be deleted upon termination of the survey () Or in case of a "commercial customer survey": "[ ] I acknowledge that the data obtained during this survey may be passed on to other parties." Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 15 10:11:36 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 15 Feb 2007 11:11:36 +0100 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <45D36766.70408@redhat.com> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> <1171479058.4077.7.camel@pensja.lam.pl> <45D36766.70408@redhat.com> Message-ID: <20070215111136.28ee7425@python3.es.egwn.lan> Mike McGrath wrote : > Leszek Matok wrote: > > Dnia 14-02-2007, ?ro o godzinie 19:01 +0100, David Nielsen napisa?(a): > > > >> Smolt is doubleplus good, I vote yes. > >> > > I don't know nice 1984-ish word for "not so good", but: > > > > Can Smolt work from behind a proxy server, faking the User-Agent? > > Because, you know, I've tried to register some machines from a real > > production environment, with no luck. setenv http_proxy doesn't work, > > probably because our proxy rejects most of UA-s (or because Smolt > > doesn't honor http_proxy at all). > > This is a must, I'll contact you as soon as its ready. Just to confirm what I've already reported here : smoltSendProfile fails to send any data for me from behind a transparent proxy, which doesn't block anything specific, just logs and caches. I get this : [...] Transmitting ... Error contacting server: [Errno 14] HTTP Error 500: Server: Squid/2.4.STABLE7 Mime-Version: 1.0 Date: Wed, 14 Feb 2007 17:56:29 GMT Content-Type: text/html Content-Length: 788 Expires: Wed, 14 Feb 2007 17:56:29 GMT X-Squid-Error: ERR_READ_ERROR 104 X-Cache: MISS from proxy.lan Connection: keep-alive So before making the http_proxy env work, there's maybe general proxy fixing to do, as I don't think this proxy has any weird settings... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.47 0.52 0.47 From pemboa at gmail.com Thu Feb 15 10:35:10 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 16 Feb 2007 04:35:10 +1800 Subject: Smolt: firsboot revisited In-Reply-To: <1171533450.3622.509.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <16de708d0702150046n2af8f9f9l188c01e4da28b5b7@mail.gmail.com> <1171533450.3622.509.camel@mccallum.corsepiu.local> Message-ID: <16de708d0702150235o599b3907n1fcf3a08ce842c0d@mail.gmail.com> On 2/16/07, Ralf Corsepius wrote: > On Fri, 2007-02-16 at 02:46 +0000, Arthur Pemberton wrote: > > On 2/16/07, Ralf Corsepius wrote: > > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > > On 2/16/07, Ralf Corsepius wrote: > > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > > > I don't think you've ever said how the information is being sent > > > > without user permission or what the personal data is that is being > > > > sent. > > > The smolt developers would be the ones to reply this. > > > > > > AFAIS (I banned smolt from my installations), it transmits > > > a machine-id, several HW details (CPU brand, type, peripherials, > > > bogomips) and OS details via http. > > > > > > i.e. they have the IP, they have a "machine-id", and they have > > > information which is not publicly available elsewhere. > > > > > > Ralf > > > > > > > Fair enough. However the machine-id cannot legally id your computer, > > nor is it supposed to be able to. As far as I understand, your > > machine-id will be specific to Fedora. > > > > But considiering you have to TELL IT to transmit thoise things, how > > can there be any legal problems? > > There is one dead-beat argument likely rendering this discussion moot: > > Not wrt. smolt, because the server is hosted in a foreign country, > therefore the data, unless it's contents is lawful, is likely not > subject to German laws (To be verified by a German lawyer). Maybe Fedora needs to simply not run smolt in german countries. You make it seem as if there is some special, useful data being stored. The data is only interesting from a statistical point of view, and to a limited audience. > => Case closed from a US-biased, RH/Fedora-biased view. > > > The actual problems remain: "trust" and "safety". > > The thresholds to trust any such site probably are much higher in > Germany than in other countries because people are aware about different > standards of "privacy policies" in different countries/institutions. > > [This applies even within Germany. Media are filled with warnings and > flames on certain enterprises on what "public opinion considers abuse of > data privacy"] > > > Or are you saying it is illegal to > > ask someone to fillout a survey form , > No, it is not, but (at least some) Germans probably will be very > reluctant to fill out such forms and be very careful about what they > fill out. Okay. So what's the differene bween not filling out the form and not running smolt? > > where they can simply ignore, > > in your country? > Common practice on "statistical survey forms" is them to carry an > explicit "data-privacy disclaimer", which people explicitly have to > check (== opt-in), which details what the data is being used for, to > whom it will be passed on and when it will be deleted. There is no fundamental difference between smolt and a survey form - down to to the fac that machine readable survey forms do have id numbers (in this case the machine id - may be it should be called the smolt id since there is no such thing as a machine id, yet at least) > Typical are disclaimers similar to > [ ] Personalized data and survey data will be kept strictly separate. > Survey data does not allow any conclusion to the person having submitted > the data. Personalized data will only be used for administrational > purposes during this survey and will be deleted upon termination of the > survey () I'm pretty sure a disclaimer will be there, implied...or can be easily added. > Or in case of a "commercial customer survey": > "[ ] I acknowledge that the data obtained during this survey may be > passed on to other parties." > > Ralf > -- Fedora Core 6 and proud From mschwendt.tmp0701.nospam at arcor.de Thu Feb 15 10:42:10 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 15 Feb 2007 11:42:10 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <1171533450.3622.509.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <16de708d0702150046n2af8f9f9l188c01e4da28b5b7@mail.gmail.com> <1171533450.3622.509.camel@mccallum.corsepiu.local> Message-ID: <20070215114210.01010ae8.mschwendt.tmp0701.nospam@arcor.de> This entire discussion would be easier if it discussed specific issues with "smolt" instead of trying to cover general problems related to data acquisition and data protection. "smolt" is not about personal data, such as name, address, data of birth, phone numbers. If you are concerned that the IP address is stored, too, and is some form of personalisation or could lead to illegal data acquisition activities, you should not use the Internet, not connect to any server, not use Yum, not use AptRPM, not send mails, not enable Cookies, nothing. > > Or are you saying it is illegal to > > ask someone to fillout a survey form , > > No, it is not, but (at least some) Germans probably will be very > reluctant to fill out such forms and be very careful about what they > fill out. What has this to do with smolt? Generally paranoid or overcautious people would not opt-in for smolt even if it came with a long legal disclaimer and if it displayed exactly the raw data it wants to transfer. I don't think there is reason to worry, because this is an open source piece of software, opt-in, not running in the background, not running unattended, can be removed again. And, of course, Red Hat would be playing with fire if any questionable data acquisition practices ever turned up in "smolt". > > where they can simply ignore, > > in your country? > Common practice on "statistical survey forms" is them to carry an > explicit "data-privacy disclaimer", which people explicitly have to > check (== opt-in), which details what the data is being used for, to > whom it will be passed on and when it will be deleted. I think the "when it will be deleted" is not well-defined in the majority of cases. Further, if you agree that your data may be passed on to third parties, you've lost already. From buildsys at redhat.com Thu Feb 15 10:59:23 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 15 Feb 2007 05:59:23 -0500 Subject: rawhide report: 20070215 changes Message-ID: <200702151059.l1FAxNsk012308@hs20-bc2-6.build.redhat.com> Updated Packages: acpid-1.0.4-7.fc7 ----------------- * Wed Feb 14 2007 Phil Knirsch - 1.0.4-7.fc7 - Dropped /var/log/acpid ownership as per review (225237) autoconf213-2.13-14 ------------------- * Wed Feb 14 2007 Karsten Hopp 2.13-14 - buildrequire perl for autoscan script * Wed Feb 14 2007 Karsten Hopp 2.13-13 - buildroot fixed - removed textutils requirement - dot removed from summary - requires gawk, but not perl - use install-info - use BuildArch - replace tabs with spaces - fix defattr - use 'make install DESTDIR=...' cairo-1.3.14-1.fc7 ------------------ * Wed Feb 14 2007 Carl Worth 1.3.14-1 - Update to 1.3.14 cairo-java-1.0.5-4.fc7 ---------------------- * Wed Feb 14 2007 Stepan Kasal - 1.0.5-4 - Move doc/api to -devel. control-center-1:2.17.91-2.fc7 ------------------------------ * Wed Feb 14 2007 Matthias Clasen - 2.17.91-2 - Fix scriptlets coreutils-6.7-5.fc7 ------------------- * Wed Feb 14 2007 Tim Waugh 6.7-5 - Removed unnecessary stuff in pre scriptlet (bug #225655). - Prefix sources with 'coreutils-' (bug #225655). - Avoid %makeinstall (bug #225655). cups-1:1.2.8-1.fc7 ------------------ * Wed Feb 14 2007 Tim Waugh 1:1.2.8-1 - 1.2.8. device-mapper-1.02.17-6.fc7 --------------------------- * Wed Feb 14 2007 Alasdair Kergon - 1.02.17-6 - Move shared library into a separate -libs package. flac-1.1.4-3.fc7 ---------------- * Wed Feb 14 2007 - Bastien Nocera - 1.1.4-3 - Also include the new pkgconfig files * Wed Feb 14 2007 - Bastien Nocera - 1.1.4-2 - Update link-ogg patch for 1.1.4 * Wed Feb 14 2007 - Bastien Nocera - 1.1.4-1 - Update to upstream 1.1.4 ftp-0.17-39.fc7 --------------- * Wed Feb 14 2007 Marcela Maslanova - 0.17-39 - review again gcc-4.1.2-1 ----------- * Wed Feb 14 2007 Jakub Jelinek 4.1.2-1 - update from gcc-4_1-branch (-r121738:121962) - GCC 4.1.2 release - PRs fortran/24783, testsuite/30649, middle-end/30313 - fix ICE in dwarf2out with limbo die nodes in namespace context (Alexandre Oliva, #227376) - fix a SRA bug with bitfields (Alexandre Oliva, #223576) glib-java-0.2.6-4.fc7 --------------------- * Wed Feb 14 2007 Stepan Kasal - 0.2.6-4 - Move doc/api to -devel. gnome-screensaver-2.17.7-3.fc7 ------------------------------ * Wed Feb 14 2007 Matthias Clasen - 2.17.7-3 - Create ~/Pictures folder for new users, so the slideshow screensaver has a dropspot for screensavers * Wed Feb 14 2007 Matthias Clasen - 2.17.7-2 - Make the switch user button go directly to gdm gnome-terminal-2.17.91-2.fc7 ---------------------------- * Wed Feb 14 2007 Matthias Clasen - 2.17.91-2 - Package review feedback gtkspell-2.0.11-3.fc7 --------------------- * Wed Feb 14 2007 Matthew Barnes - 2.0.11-3.fc7 - Add patch for RH bug #216142 (symbols missing "static" qualifier). hplip-1.7.1-1.fc7 ----------------- * Wed Feb 14 2007 Tim Waugh 1.7.1-1 - 1.7.1. kdemultimedia-6:3.5.6-2.fc7 --------------------------- * Wed Feb 14 2007 Than Ngo 6:3.5.6-2.fc7 - rebuild kernel-2.6.20-1.2930.fc7 ------------------------ * Wed Feb 14 2007 Dave Jones - 2.6.20-git10 * Tue Feb 13 2007 Dave Jones - Resurrect the signed modules patches. libglade-java-2.12.5-4.fc7 -------------------------- * Wed Feb 14 2007 Stepan Kasal - 2.12.5-4 - Move doc/api to -devel. libgnome-java-2.12.4-4.fc7 -------------------------- * Wed Feb 14 2007 Stepan Kasal - 2.12.4-4 - Move doc/api to -devel. libvirt-0.2.0-1.fc7 ------------------- * Wed Feb 14 2007 Daniel Veillard 0.2.0-1.fc7 - support for KVM and QEmu - support for network configuration - assorted fixes lvm2-2.02.22-2.fc7 ------------------ * Wed Feb 14 2007 Alasdair Kergon - 2.02.22-2 - Rebuild after device-mapper package split. * Wed Feb 14 2007 Alasdair Kergon - 2.02.22-1 - Add ncurses-static BuildRequires after package split. - Fix loading of segment_libraries. - If a PV reappears after it was removed from its VG, make it an orphan. - Don't update metadata automatically if VGIDs don't match. - Fix some vgreduce --removemissing command line validation. - Trivial man page corrections (-b and -P). - Add global/units to example.conf. - Remove readline support from lvm.static. m17n-db-1.3.4-7.fc7 ------------------- * Thu Feb 15 2007 Mayank Jain - Added ZWNJ (U+200d) needed in kn-* keymaps, resolved - 221965 - Added kn-itrans-ZWNJ-221965.patch * Thu Feb 15 2007 Mayank Jain - Added itrans layout for Marahi, resolved - 225561 opal-2.2.5-1.fc7 ---------------- * Wed Feb 14 2007 Daniel Veillard - 2.2.5-1 - upstream release of 2.2.5 postgresql-8.2.3-2.fc7 ---------------------- * Wed Feb 14 2007 Karsten Hopp 8.2.3-2 - rebuild with tcl-8.4 pwlib-1.10.4-1.fc7 ------------------ * Wed Feb 14 2007 Daniel Veillard - 1.10.4-1 - Update to 1.10.4 pykickstart-0.95-1.fc7 ---------------------- * Wed Feb 14 2007 Chris Lumens - 0.95-1 - KickstartParser no longer takes a version argument. - Be more lenient in what strings stringToVersion accepts. - Allow setting state on one data object from multiple files. radvd-1.0-3.fc7 --------------- * Wed Feb 14 2007 Martin Bacovsky - 1.0-3.fc7 - specfile cleanup for review rhdb-utils-8.2.0-1.fc7 ---------------------- * Wed Feb 14 2007 Tom Lane 8.2.0-1 - Update pg_filedump to version 8.2.0, to support PostgreSQL 8.2. Resolves: #224175 selinux-policy-2.5.3-2.fc7 -------------------------- * Wed Feb 14 2007 Dan Walsh 2.5.3-2 - Fix file context for nemiver * Sun Feb 11 2007 Dan Walsh 2.5.3-1 - Remove include sym link * Mon Feb 05 2007 Dan Walsh 2.5.2-6 - Allow mozilla, evolution and thunderbird to read dev_random. Resolves: #227002 - Allow spamd to connect to smtp port Resolves: #227184 - Fixes to make ypxfr work Resolves: #227237 setools-3.1-2.fc7 ----------------- * Wed Feb 14 2007 Dan Walsh 3.1-2 - Fix permissions on shared libraries texi2html-1.77-0.1.20070214cvs.fc7 ---------------------------------- * Wed Feb 14 2007 Jindrich Novy 1.77-0.1.20070214cvs - update to 1.77 release candidate (#226487) tn5250-0.17.3-10.fc7 -------------------- * Wed Feb 14 2007 Karsten Hopp 0.17.3-10 - rename icon files to tn5250.{png,xpm} - remove Mimetype from desktop file - move category to desktop file - use vendor fedora for desktop-file-install - touch files to avoid autotools run vorbis-tools-1:1.1.1-5.fc7 -------------------------- * Wed Feb 14 2007 Karsten Hopp 1.1.1-5 - rebuild with libFLAC.so.8, link with libogg instead of libOggFLAC xfsprogs-2.8.18-2.fc7 --------------------- * Wed Feb 14 2007 Miroslav Lichvar 2.8.18-2 - Disable readline support for now (#223781) * Sun Feb 04 2007 Jarod Wilson 2.8.18-1 - Post-facto changelog addition to note bump to 2.8.18 yum-3.1.1-3.fc7 --------------- * Wed Feb 14 2007 Jeremy Katz - 3.1.1-3 - learn about kernel-debug (#228709) * Tue Feb 13 2007 James Bowes - 3.1.1-2 - Spec file updates from the merge review: use correct buildroot, mark logrotate file as noreplace, require correct versions of python and rpm, use name macro in source0. * Thu Feb 08 2007 Jeremy Katz - 3.1.1-1 - update to 3.1.1 - keep config bits in old locations for now Broken deps for ia64 ---------------------------------------------------------- apr-devel - 1.2.7-10.ia64 requires gcc = 0:4.1.1 ekiga - 2.0.4-1.fc7.ia64 requires libpt_linux_ia64_r.so.1.10.3()(64bit) gnome-volume-manager - 2.17.0-3.fc7.ia64 requires kernel >= 0:2.6 k3b - 0.12.17-1.ia64 requires libFLAC.so.7()(64bit) k3b - 0.12.17-1.ia64 requires libFLAC++.so.5()(64bit) pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for s390 ---------------------------------------------------------- apr-devel - 1.2.7-10.s390 requires gcc = 0:4.1.1 ekiga - 2.0.4-1.fc7.s390 requires libpt_linux_s390_r.so.1.10.3 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- apr-devel - 1.2.7-10.i386 requires gcc = 0:4.1.1 apr-devel - 1.2.7-10.x86_64 requires gcc = 0:4.1.1 ekiga - 2.0.4-1.fc7.x86_64 requires libpt_linux_x86_64_r.so.1.10.3()(64bit) k3b - 0.12.17-1.x86_64 requires libFLAC++.so.5()(64bit) k3b - 0.12.17-1.x86_64 requires libFLAC.so.7()(64bit) Broken deps for ppc ---------------------------------------------------------- apr-devel - 1.2.7-10.ppc requires gcc = 0:4.1.1 ekiga - 2.0.4-1.fc7.ppc requires libpt_linux_ppc_r.so.1.10.3 k3b - 0.12.17-1.ppc requires libFLAC.so.7 k3b - 0.12.17-1.ppc requires libFLAC++.so.5 Broken deps for ppc64 ---------------------------------------------------------- apr-devel - 1.2.7-10.ppc64 requires gcc = 0:4.1.1 ekiga - 2.0.4-1.fc7.ppc64 requires libpt_linux_ppc64_r.so.1.10.3()(64bit) k3b - 0.12.17-1.ppc64 requires libFLAC++.so.5()(64bit) k3b - 0.12.17-1.ppc64 requires libFLAC.so.7()(64bit) Broken deps for i386 ---------------------------------------------------------- apr-devel - 1.2.7-10.i386 requires gcc = 0:4.1.1 ekiga - 2.0.4-1.fc7.i386 requires libpt_linux_x86_r.so.1.10.3 k3b - 0.12.17-1.i386 requires libFLAC.so.7 k3b - 0.12.17-1.i386 requires libFLAC++.so.5 Broken deps for s390x ---------------------------------------------------------- apr-devel - 1.2.7-10.s390x requires gcc = 0:4.1.1 apr-devel - 1.2.7-10.s390 requires gcc = 0:4.1.1 ekiga - 2.0.4-1.fc7.s390x requires libpt_linux_s390x_r.so.1.10.3()(64bit) From rc040203 at freenet.de Thu Feb 15 11:10:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 12:10:06 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <16de708d0702150235o599b3907n1fcf3a08ce842c0d@mail.gmail.com> References: <45D33FD7.4010001@redhat.com> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <16de708d0702150046n2af8f9f9l188c01e4da28b5b7@mail.gmail.com> <1171533450.3622.509.camel@mccallum.corsepiu.local> <16de708d0702150235o599b3907n1fcf3a08ce842c0d@mail.gmail.com> Message-ID: <1171537806.3622.536.camel@mccallum.corsepiu.local> On Fri, 2007-02-16 at 04:35 +0000, Arthur Pemberton wrote: > On 2/16/07, Ralf Corsepius wrote: > > On Fri, 2007-02-16 at 02:46 +0000, Arthur Pemberton wrote: > > > On 2/16/07, Ralf Corsepius wrote: > > > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > > > On 2/16/07, Ralf Corsepius wrote: > > > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > > > > > I don't think you've ever said how the information is being sent > > > > > without user permission or what the personal data is that is being > > > > > sent. > > > > The smolt developers would be the ones to reply this. > > > > > > > > AFAIS (I banned smolt from my installations), it transmits > > > > a machine-id, several HW details (CPU brand, type, peripherials, > > > > bogomips) and OS details via http. > > > > > > > > i.e. they have the IP, they have a "machine-id", and they have > > > > information which is not publicly available elsewhere. > > > > > > > > Ralf > > > > > > > > > > Fair enough. However the machine-id cannot legally id your computer, > > > nor is it supposed to be able to. As far as I understand, your > > > machine-id will be specific to Fedora. > > > > > > But considiering you have to TELL IT to transmit thoise things, how > > > can there be any legal problems? > > > > There is one dead-beat argument likely rendering this discussion moot: > > > > Not wrt. smolt, because the server is hosted in a foreign country, > > therefore the data, unless it's contents is lawful, is likely not > > subject to German laws (To be verified by a German lawyer). > > Maybe Fedora needs to simply not run smolt in german countries. You > make it seem as if there is some special, useful data being stored. Absolutely not. I am only commenting from a German perspective, because I am living in Germany, because I am familiar with the situation around here. I am pretty sure, what I said applies to many other countries as well. > The data is only interesting from a statistical point of view, and to > a limited audience. For YOU, but ... the fact "$big business" is running 42 Fedora 6 machines with 9 of them being equipped with a topsecret "IBMINTAMD" processor at 50 GHz in their development departments might be a business secret. > > > Or are you saying it is illegal to > > > ask someone to fillout a survey form , > > No, it is not, but (at least some) Germans probably will be very > > reluctant to fill out such forms and be very careful about what they > > fill out. > > Okay. So what's the differene bween not filling out the form and not > running smolt? What is the difference between not installing smolt and having to fill out a form? Basically: security, less exposure to risks. > > > where they can simply ignore, > > > in your country? > > Common practice on "statistical survey forms" is them to carry an > > explicit "data-privacy disclaimer", which people explicitly have to > > check (== opt-in), which details what the data is being used for, to > > whom it will be passed on and when it will be deleted. > > There is no fundamental difference between smolt and a survey form - > down to to the fac that machine readable survey forms do have id > numbers (in this case the machine id - may be it should be called the > smolt id since there is no such thing as a machine id, yet at least) German laws probably would mandate to keep the machine id separate from the IP or not to record the IP at all. Ralf From jwboyer at jdub.homelinux.org Thu Feb 15 12:13:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 15 Feb 2007 06:13:39 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171524991.15716.12.camel@dawkins> References: <45D33FD7.4010001@redhat.com> <200702141200.47197.jkeating@redhat.com> <1171472906.4003.103.camel@zod.rchland.ibm.com> <1171524991.15716.12.camel@dawkins> Message-ID: <1171541619.15310.4.camel@vader.jdub.homelinux.org> On Thu, 2007-02-15 at 08:36 +0100, David Nielsen wrote: > ons, 14 02 2007 kl. 11:08 -0600, skrev Josh Boyer: > > On Wed, 2007-02-14 at 12:00 -0500, Jesse Keating wrote: > > > On Wednesday 14 February 2007 11:59, Mike McGrath wrote: > > > > So smolt is still setup in firstboot and still is opt in. My question > > > > is do we want to install smolt as part of a default configuration with > > > > F7. My vote is yes. > > > > > > I vote yes too, but I want to see other votes before I just do it (: > > > > For which spins? Desktop, Server, and KDE? I would say sure. You'd > > have to ask the KDE spin guys though. And I don't think it should be > > functional on the LiveCD really... > > It might be useful to have it available. I often boot a LiveCD on > friends machines to see if the hardware is generally supported. It would > be helpful to have a nice little frontend to tell the stats page "This > is the liveCD, all this hardware works" (ands maybe even flag something > as problematic). > > I de realise this is more a LCHD (or whatever that larger database is > called - honestly it needs a sexier name). Right, I think that belongs more in the other project you mention. We don't want to bloat smolt numbers with LiveCD statistics unless people actually _install_ Fedora from the LiveCD. And if they do that, then it's a firstboot option anyway. josh From dennis at ausil.us Thu Feb 15 12:42:52 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 06:42:52 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171524021.3622.419.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> Message-ID: <200702150642.53141.dennis@ausil.us> Once upon a time Thursday 15 February 2007 1:20 am, Ralf Corsepius wrote: > I.e. from a German point of view. Smolt's "machine id" in connection > with the IP address needs to be legally reviewed if this qualifies as > "personalized data". I for one regard it as such. Ralf Did you look at the code like i asked last time ? IP's are not collected. the data is transmitted by post so there is is no way to tie a UUID to an ip and it is completely opt in you see exactly what is going to be sent before it is sent. So what you are arguing for is exactly what smolt does. Stop spreading FUD now. you are perfectly free to uncheck smolt from your installs and not participate. that is your right to do. Seriously look at the code Dennis From dennis at ausil.us Thu Feb 15 12:46:39 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 06:46:39 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171528355.3622.467.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> Message-ID: <200702150646.39750.dennis@ausil.us> Once upon a time Thursday 15 February 2007 2:32 am, Ralf Corsepius wrote: > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > On 2/16/07, Ralf Corsepius wrote: > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > I don't think you've ever said how the information is being sent > > without user permission or what the personal data is that is being > > sent. > > The smolt developers would be the ones to reply this. > > AFAIS (I banned smolt from my installations), it transmits > a machine-id, several HW details (CPU brand, type, peripherials, > bogomips) and OS details via http. Only if you choose to. send your information there is no mechanism for automatically sending the data without your consent. and you are free to not install smolt. > i.e. they have the IP, they have a "machine-id", and they have > information which is not publicly available elsewhere. we have no way to tie a UUID to an IP web log information is publicliy available. as is the ability for me to look up your ip via mail headers in mail you send. but i still cant tell what machine is yours if you choose to send in a profile. they only way i could know that would be if you personally gave me your uuid Stop spreading FUD From dennis at ausil.us Thu Feb 15 12:48:28 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 06:48:28 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171529027.3622.474.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171528664.27965.318.camel@cutter> <1171529027.3622.474.camel@mccallum.corsepiu.local> Message-ID: <200702150648.29172.dennis@ausil.us> Once upon a time Thursday 15 February 2007 2:43 am, Ralf Corsepius wrote: > Yes, but this thread started with "Shall smolt be installed by default", > so the question wasn't "opt-in/opt-out", it was "installed by default" > > I expressed my opinion and said: No, ... by installed by default we want to give users the option at first boot to send in their profile if they so choose. nothing more Stop making this about more than it is From dennis at ausil.us Thu Feb 15 12:50:45 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 06:50:45 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171537806.3622.536.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <16de708d0702150235o599b3907n1fcf3a08ce842c0d@mail.gmail.com> <1171537806.3622.536.camel@mccallum.corsepiu.local> Message-ID: <200702150650.45783.dennis@ausil.us> Once upon a time Thursday 15 February 2007 5:10 am, Ralf Corsepius wrote: > > German laws probably would mandate to keep the machine id separate from > the IP or not to record the IP at all. The IP is only collected in the web logs and there is no way to tie the ip to the UUID so we are already doing this you are being very petty without facts please stop From rc040203 at freenet.de Thu Feb 15 13:03:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 14:03:36 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <200702150646.39750.dennis@ausil.us> References: <45D33FD7.4010001@redhat.com> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <200702150646.39750.dennis@ausil.us> Message-ID: <1171544616.20765.24.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 06:46 -0600, Dennis Gilmore wrote: > Once upon a time Thursday 15 February 2007 2:32 am, Ralf Corsepius wrote: > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > On 2/16/07, Ralf Corsepius wrote: > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > i.e. they have the IP, they have a "machine-id", and they have > > information which is not publicly available elsewhere. > > we have no way to tie a UUID to an IP web log information is publicliy > available. as is the ability for me to look up your ip via mail headers in > mail you send. but i still cant tell what machine is yours if you choose to > send in a profile. You can, if you want to, it's all under your control. > they only way i could know that would be if you > personally gave me your uuid > > Stop spreading FUD Give me one reason why I should trust you more than anybody else. Ralf From hughsient at gmail.com Thu Feb 15 13:08:44 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 15 Feb 2007 13:08:44 +0000 Subject: Smolt: firsboot revisited In-Reply-To: <1171544616.20765.24.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <200702150646.39750.dennis@ausil.us> <1171544616.20765.24.camel@mccallum.corsepiu.local> Message-ID: <15e53e180702150508s252bcbe1oe8ff8c226231b862@mail.gmail.com> On 15/02/07, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 06:46 -0600, Dennis Gilmore wrote: > > Once upon a time Thursday 15 February 2007 2:32 am, Ralf Corsepius wrote: > > Stop spreading FUD > Give me one reason why I should trust you more than anybody else. Can you please stop wasting our time. Many thanks. Richard. From dennis at ausil.us Thu Feb 15 13:13:55 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 07:13:55 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171544616.20765.24.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <200702150646.39750.dennis@ausil.us> <1171544616.20765.24.camel@mccallum.corsepiu.local> Message-ID: <200702150713.56219.dennis@ausil.us> Once upon a time Thursday 15 February 2007, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 06:46 -0600, Dennis Gilmore wrote: > > Once upon a time Thursday 15 February 2007 2:32 am, Ralf Corsepius wrote: > > > On Fri, 2007-02-16 at 02:19 +0000, Arthur Pemberton wrote: > > > > On 2/16/07, Ralf Corsepius wrote: > > > > > On Thu, 2007-02-15 at 02:33 -0500, seth vidal wrote: > > > > > > On Thu, 2007-02-15 at 08:20 +0100, Ralf Corsepius wrote: > > > > > > i.e. they have the IP, they have a "machine-id", and they have > > > information which is not publicly available elsewhere. > > > > we have no way to tie a UUID to an IP web log information is publicliy > > available. as is the ability for me to look up your ip via mail headers > > in mail you send. but i still cant tell what machine is yours if you > > choose to send in a profile. > > You can, if you want to, it's all under your control. How? > > they only way i could know that would be if you > > personally gave me your uuid > > > > Stop spreading FUD > > Give me one reason why I should trust you more than anybody else. Since your contining to be unreasonable and overly paranoid i dont think anything i say or do will have you trust me. but then how can you trust anything anyone does? you really shouldn't use a computer someone at some stage may have set up something to gather your data. oh mail headers, http headers., What smolt collects is less personally identifiable than those. Dennis From jkeating at redhat.com Thu Feb 15 13:19:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 08:19:22 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171544616.20765.24.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <200702150646.39750.dennis@ausil.us> <1171544616.20765.24.camel@mccallum.corsepiu.local> Message-ID: <200702150819.22336.jkeating@redhat.com> On Thursday 15 February 2007 08:03, Ralf Corsepius wrote: > Give me one reason why I should trust you more than anybody else. Because the source to the application/server we're talking about is opensource and available for you to review and form your own conclusions. Which you should do, instead of continually spreading FUD. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From linux_4ever at yahoo.com Thu Feb 15 13:31:53 2007 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 15 Feb 2007 05:31:53 -0800 (PST) Subject: BuildRoot in spec files? Message-ID: <20070215133153.28089.qmail@web51504.mail.yahoo.com> Hi, Why is BuildRoot in spec files? (Don't say tradition.) It seems to me that its a _build system_ tunable and not something that each spec file should do differently. Can we define that in rpmmacros and take it out of all spec files? The fact that it comes up in spec file reviews and we are supposed to have the _same thing_ in each file just screams to be relocated to a central place and no longer controlled by each spec file. -Steve ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ From jkeating at redhat.com Thu Feb 15 13:38:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 08:38:02 -0500 Subject: BuildRoot in spec files? In-Reply-To: <20070215133153.28089.qmail@web51504.mail.yahoo.com> References: <20070215133153.28089.qmail@web51504.mail.yahoo.com> Message-ID: <200702150838.02616.jkeating@redhat.com> On Thursday 15 February 2007 08:31, Steve G wrote: > Why is BuildRoot in spec files? (Don't say tradition.) It seems to me that > its a _build system_ tunable and not something that each spec file should > do differently. Can we define that in rpmmacros and take it out of all spec > files? The fact that it comes up in spec file reviews and we are supposed > to have the _same thing_ in each file just screams to be relocated to a > central place and no longer controlled by each spec file. A macro doesn't work. It won't get used unless BuildRoot is in the spec file. yes this is a "bug" in rpm. There have been patches submitted to rpm.org upstream to set BuildRoot completely internal to rpm and remove it completely from the spec file. However it will take some time for this change to get integrated and put into a release of rpm we ship, and may not be ported to older releases for which we still maintain packages. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Thu Feb 15 13:46:02 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Feb 2007 08:46:02 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <1171519385.27965.290.camel@cutter> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <1171519385.27965.290.camel@cutter> Message-ID: <1171547162.5277.2.camel@localhost.localdomain> On Thu, 2007-02-15 at 01:03 -0500, seth vidal wrote: > On Thu, 2007-02-15 at 06:58 +0100, Ralf Corsepius wrote: > > On Thu, 2007-02-15 at 00:34 -0500, seth vidal wrote: > > > On Thu, 2007-02-15 at 05:48 +0100, Ralf Corsepius wrote: > > > > On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > > > > > So smolt is still setup in firstboot and still is opt in. My question > > > > > is do we want to install smolt as part of a default configuration with > > > > > F7. My vote is yes. > > > > > > > > My vote is no. > > > > > > > > > > > * is legally questionable. > > > > > > If you have a concern here, please file a bug on it and I will make sure > > > it gets passed into the legal queue for evaluation. > > > > Everything that needed to be said had been communicated to Mr. McGrath. > > It's up to him to decide on what to do with it. > > > > > Please list the > > > country where you think the law might be violated. > > Probably most parts of the world outside of the US, definitely in > > Europe, definitely in Germany, probably also in some part of Asia. > > > > Besides this, you should understand that data-privacy plays a much more > > important role than what you are used to in many countries and > > communities - As I already said: You are playing with a loaded gun, > > right in front of your face. > > > > Here in Germany, many folks consider any such transition from user to > > vendor as "hostile espionage". Press is full of articles flaming > > manufactures for this and related topics. > > > > It will definitely be reason for users not to choose Fedora in future > > (It might have escaped you, but Microsoft and other vendors having done > > the similar is the reason why many users choose to switch to Linux). > > No need for such a screed. I wasn't arguing with you. I was simply > volunteering to take the issues through the board to legal to get them > addressed. I'll talk to Mike and make sure I have a firm handle on your > concerns so I can make sure they are represented. This is as much, or more, a PR issue, not just a legal issue. In Italy we have one of the most restrictive privacy laws as well, and I can confirm Ralf point of view. If you want to send user data to a vendor, you better make it very clear to the user what data is transmitted and make it very optional (ie. ask for confirmation and offer to disable the tool at the first run). Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From jima at beer.tclug.org Thu Feb 15 13:56:54 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 15 Feb 2007 07:56:54 -0600 (CST) Subject: Smolt: firsboot revisited In-Reply-To: <1171537806.3622.536.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <1171519104.3622.358.camel@mccallum.corsepiu.local> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <1171524811.27965.307.camel@cutter> <1171527338.3622.457.camel@mccallum.corsepiu.local> <16de708d0702150019g58235456q945176454a72f82b@mail.gmail.com> <1171528355.3622.467.camel@mccallum.corsepiu.local> <16de708d0702150046n2af8f9f9l188c01e4da28b5b7@mail.gmail.com> <1171533450.3622.509.camel@mccallum.corsepiu.local> <16de708d0702150235o599b3907n1fcf3a08ce842c0d@mail.gmail.com> <1171537806.3622.536.camel@mccallum.corsepiu.local> Message-ID: On Thu, 15 Feb 2007, Ralf Corsepius wrote: > For YOU, but ... the fact "$big business" is running 42 Fedora 6 > machines with 9 of them being equipped with a topsecret "IBMINTAMD" > processor at 50 GHz in their development departments might be a business > secret. Then $big business should either not check "Yes" (i.e., changing the default) or (more likely) they're installing via kickstart anyway and won't even install Smolt, much less run it. >>> No, it is not, but (at least some) Germans probably will be very >>> reluctant to fill out such forms and be very careful about what they >>> fill out. Yes, there are people like this all over the world. This is not uniquely a German trait. > German laws probably would mandate to keep the machine id separate from > the IP or not to record the IP at all. As Dennis said, we do keep the IP logged separately. The information (including system ID) is transmitted via POST, therefore none of that data ends up in the web log, just in the database. Jima From sundaram at fedoraproject.org Thu Feb 15 13:59:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 Feb 2007 19:29:53 +0530 Subject: Smolt: firsboot revisited In-Reply-To: <1171547162.5277.2.camel@localhost.localdomain> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <1171519385.27965.290.camel@cutter> <1171547162.5277.2.camel@localhost.localdomain> Message-ID: <45D46759.6090506@fedoraproject.org> Simo Sorce wrote: > This is as much, or more, a PR issue, not just a legal issue. It was expressed as a legal issue. > In Italy we have one of the most restrictive privacy laws as well, and I > can confirm Ralf point of view. > If you want to send user data to a vendor, you better make it very clear > to the user what data is transmitted and make it very optional (ie. ask > for confirmation and offer to disable the tool at the first run). > ... which is what is being done already. Rahul From stickster at gmail.com Thu Feb 15 14:02:59 2007 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 15 Feb 2007 09:02:59 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <200702150819.22336.jkeating@redhat.com> References: <45D33FD7.4010001@redhat.com> <200702150646.39750.dennis@ausil.us> <1171544616.20765.24.camel@mccallum.corsepiu.local> <200702150819.22336.jkeating@redhat.com> Message-ID: <1171548179.27919.27.camel@localhost.localdomain> On Thu, 2007-02-15 at 08:19 -0500, Jesse Keating wrote: > On Thursday 15 February 2007 08:03, Ralf Corsepius wrote: > > Give me one reason why I should trust you more than anybody else. > > Because the source to the application/server we're talking about is opensource > and available for you to review and form your own conclusions. Which you > should do, instead of continually spreading FUD. Yes, let's please put this thread to rest. Any users/administrators have at least three junctures at which they can block smolt on their system, and can take advantage of any of them: 1. Don't install it; use a kickstart file that removes smolt from the installation, or make a custom repo without it. 2. Disable the firstboot module by twiddling around with the bits in the %post section. 3. When smolt asks you if you want to send any information, choose the default NO action. Ralf, you are trying to assert opinions about the law without any credentials, and about the code apparently without having looked at it. Your concerns have been noted and will be give due consideration. Time to move on. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 linux_4ever at yahoo.com Thu Feb 15 14:21:34 2007 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 15 Feb 2007 06:21:34 -0800 (PST) Subject: BuildRoot in spec files? In-Reply-To: <200702150838.02616.jkeating@redhat.com> Message-ID: <20070215142134.63703.qmail@web51502.mail.yahoo.com> >A macro doesn't work. It won't get used unless BuildRoot is in the spec file. I don't buy this at all. To start with, we can define a macro: %buildrootdir %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) This could be used in spec files: BuildRoot: %{buildrootdir} Just doing that much would be an improvement. Then I look at somethings we did in the past like RPM_OPT_FLAGS and how we had to put that in spec files by hand and then someone figured out how to get that done automatically. I think we can make this get applied automatically, too. -Steve ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 From ssorce at redhat.com Thu Feb 15 14:29:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Feb 2007 09:29:10 -0500 Subject: Smolt: firsboot revisited In-Reply-To: <45D46759.6090506@fedoraproject.org> References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <1171519385.27965.290.camel@cutter> <1171547162.5277.2.camel@localhost.localdomain> <45D46759.6090506@fedoraproject.org> Message-ID: <1171549750.5277.4.camel@localhost.localdomain> On Thu, 2007-02-15 at 19:29 +0530, Rahul Sundaram wrote: > Simo Sorce wrote: > > > This is as much, or more, a PR issue, not just a legal issue. > > It was expressed as a legal issue. Yeah, I saw it, that's why I am trying to say it is more a PR thing imo. > > In Italy we have one of the most restrictive privacy laws as well, and I > > can confirm Ralf point of view. > > If you want to send user data to a vendor, you better make it very clear > > to the user what data is transmitted and make it very optional (ie. ask > > for confirmation and offer to disable the tool at the first run). > > > > ... which is what is being done already. That's great, then I see no problem at all. Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From mmcgrath at redhat.com Thu Feb 15 14:40:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 15 Feb 2007 08:40:23 -0600 Subject: Wiki outage (upgrade) Message-ID: <45D470D7.4060702@redhat.com> I'll be doing a wiki upgrade from 8:00 a.m. to 5:00 p.m. (CST) on February 21st (Wed). I'll be trying to minimize downtime and, in theory, the wiki won't every be unavailable, just un-writeable. During our tests it has been determined that there are very few changes that need to be made so we'll just fix things as they come up. -Mike From dennis at ausil.us Thu Feb 15 14:46:16 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 08:46:16 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171545215.20765.36.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <200702150648.29172.dennis@ausil.us> <1171545215.20765.36.camel@mccallum.corsepiu.local> Message-ID: <200702150846.16280.dennis@ausil.us> On Thursday 15 February 2007 07:13, you wrote: > On Thu, 2007-02-15 at 06:48 -0600, Dennis Gilmore wrote: > > Once upon a time Thursday 15 February 2007 2:43 am, Ralf Corsepius wrote: > > > Yes, but this thread started with "Shall smolt be installed by > > > default", so the question wasn't "opt-in/opt-out", it was "installed by > > > default" > > > > > > I expressed my opinion and said: No, ... > > > > by installed by default we want to give users the option at first boot to > > send in their profile if they so choose. nothing more > > > > Stop making this about more than it is > > Gradually I am loosing patience. Are you smolt guys really so narrow > minded and blind? Don't take things off list please you need to look at the code of not use smolt i don't care either way. no one is making you use smolt so don't > > I perceive smolt as SPYWARE, spying at data which I am not interested in > to communicate to anybody, nor being traded nor whatelse. Neither to > Fedora nor to RH nor the NSA the FSB or anybody nor a hacker having > cracked into anywhere inbetween. > > > And before you start shoot at me accusing you to implement spyware, you > want look up spyware in Wikipedia: > > http://de.wikipedia.org/wiki/Spyware: > > "Als Spyware wird ?blicherweise Software bezeichnet, die pers?nliche > Daten eines PC-Benutzers ohne dessen Wissen oder Zustimmung an den > Hersteller der Software (Call Home) oder an Dritte sendet oder dazu > genutzt wird, dem Benutzer direkt Produkte anzubieten." > > Rough, almost literal translation: > > "Spyware is the common naming of software, which transmits a PC-users's > personal data without his knowledge or consent to the manufacturer of > the software (Call Home) or to third parties or which is being used to > directly offer a user products." > > That is, they key it to "transmission" and the definition of "personal > data". Smolt does not transmit anything without anyones consent and there is nothing personaly identifiable in there. unless you give the key out i.e your UUID. all data is transmitted with the full consent of the user only. > Now compare this to the one found on the English wikipedia. They differ > substantially. > > Yet another indication for a major cultural/natural background. > Apparently one, preventing people at RH to understand what all this fuzz > is about. I personally have nothing to do with RH im not a employee nor am I a share holder. Ralf, I'm going to ask you to stop what you are doing now as you are making yourself look like an idiot. everything you say smolt should do it does. its opt in, it has nothing personally identifiable. you don't listen to anybody and you don't base your arguments on facts. the code to smolt is released under the GPL you are free to audit it at any point in time and file bugs for things. you are not being forced to use it. Open your narrow mind and see the big picture here. for now shut up and stop wasting peoples times with your rants and FUD. -- Dennis Gilmore, RHCE From mmcgrath at redhat.com Thu Feb 15 15:04:59 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 15 Feb 2007 09:04:59 -0600 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <20070215111136.28ee7425@python3.es.egwn.lan> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> <1171479058.4077.7.camel@pensja.lam.pl> <45D36766.70408@redhat.com> <20070215111136.28ee7425@python3.es.egwn.lan> Message-ID: <45D4769B.2040407@redhat.com> Matthias Saou wrote: > I get this : > > [...] > Transmitting ... > Error contacting server: [Errno 14] HTTP Error 500: Server: > Squid/2.4.STABLE7 Mime-Version: 1.0 > Date: Wed, 14 Feb 2007 17:56:29 GMT > Content-Type: text/html > Content-Length: 788 > Expires: Wed, 14 Feb 2007 17:56:29 GMT > X-Squid-Error: ERR_READ_ERROR 104 > X-Cache: MISS from proxy.lan > Connection: keep-alive > > So before making the http_proxy env work, there's maybe general proxy > fixing to do, as I don't think this proxy has any weird settings... > To me this looks like the client is honoring the proxy settings but then the smolt server is failing? I'll take a closer look, I might contact you off list for a test if that's ok? -Mike From sundaram at fedoraproject.org Thu Feb 15 15:11:15 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 Feb 2007 20:41:15 +0530 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <45D47813.3080306@fedoraproject.org> Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. > I would also like to have a menu entry on the DE's like GNOME and KDE if that is not too much work. Rahul From mmcgrath at redhat.com Thu Feb 15 15:11:27 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 15 Feb 2007 09:11:27 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <45D47813.3080306@fedoraproject.org> References: <45D33FD7.4010001@redhat.com> <45D47813.3080306@fedoraproject.org> Message-ID: <45D4781F.2080301@redhat.com> Rahul Sundaram wrote: > Mike McGrath wrote: >> So smolt is still setup in firstboot and still is opt in. My >> question is do we want to install smolt as part of a default >> configuration with F7. My vote is yes. >> > I would also like to have a menu entry on the DE's like GNOME and KDE > if that is not too much work. This should be very doable, Toshio's already wrote some stuff that would be perfect there. -Mike From dennis at ausil.us Thu Feb 15 15:15:35 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 09:15:35 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <1171552017.20765.109.camel@mccallum.corsepiu.local> References: <45D33FD7.4010001@redhat.com> <200702150846.16280.dennis@ausil.us> <1171552017.20765.109.camel@mccallum.corsepiu.local> Message-ID: <200702150915.36130.dennis@ausil.us> On Thursday 15 February 2007 09:06, Ralf Corsepius wrote: > On Thu, 2007-02-15 at 08:46 -0600, Dennis Gilmore wrote: > > for now shut up and stop wasting peoples times with your rants and FUD. > > -- > > Dennis Gilmore, RHCE > > Great, how you proved your competence on privacy and replied to a PM on > a list. > > I am expecting an excuse. Ralf, none of the valid discussions on implementing smolt which is optional should be taken in private. Fedora Does not make its decisions in private. They are made in public. As is all my communications with you. -- Dennis Gilmore, RHCE From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 15 15:16:11 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 15 Feb 2007 16:16:11 +0100 Subject: Smolt from behind a proxy (Re: Smolt: firsboot revisited) In-Reply-To: <45D4769B.2040407@redhat.com> References: <45D33FD7.4010001@redhat.com> <1171476093.13377.0.camel@dawkins> <1171479058.4077.7.camel@pensja.lam.pl> <45D36766.70408@redhat.com> <20070215111136.28ee7425@python3.es.egwn.lan> <45D4769B.2040407@redhat.com> Message-ID: <20070215161611.0c3726d7@python3.es.egwn.lan> Mike McGrath wrote : > Matthias Saou wrote: > > I get this : > > > > [...] > > Transmitting ... > > Error contacting server: [Errno 14] HTTP Error 500: Server: > > Squid/2.4.STABLE7 Mime-Version: 1.0 > > Date: Wed, 14 Feb 2007 17:56:29 GMT > > Content-Type: text/html > > Content-Length: 788 > > Expires: Wed, 14 Feb 2007 17:56:29 GMT > > X-Squid-Error: ERR_READ_ERROR 104 > > X-Cache: MISS from proxy.lan > > Connection: keep-alive > > > > So before making the http_proxy env work, there's maybe general proxy > > fixing to do, as I don't think this proxy has any weird settings... > > > To me this looks like the client is honoring the proxy settings but then > the smolt server is failing? I don't have any proxy settings, it's a transparent proxy. Right now, I've been getting a different error for the last few hours, as if the smolt server was having a problem : [...] Transmitting ... Error contacting server: [Errno 14] HTTP Error 500: Date: Thu, 15 Feb 2007 15:14:21 GMT Server: CherryPy/2.2.1 Content-Length: 3532 Content-Type: text/html; charset=UTF-8 X-Cache: MISS from proxy1.fedora.phx.redhat.com X-Cache: MISS from proxy.lan Connection: keep-alive > I'll take a closer look, I might contact > you off list for a test if that's ok? Sure, feel free to contact me off-list for any testing or debugging. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 5.33 4.56 4.13 From katzj at redhat.com Thu Feb 15 15:20:39 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 10:20:39 -0500 Subject: Fedora 7 media sets Message-ID: <1171552839.19239.16.camel@aglarond.local> Since test1 and FUDcon there's been a lot of feedback on what media sets we should actually build, test and distribute by default. It's pretty clear that the mix of "desktop bits without any development" didn't really fit the needs of a lot of our users. And the incredibly long thread about what belongs in a server spin showed that we don't really have a good handle on what use cases we're actually trying to fill with it. Given this, the board stepped back to think a bit about what we're trying to achieve and what the problems we were trying to fix. The list was pretty short: 1. Must provide a way for people to do their own custom versions including packages from all of the Fedora universe. 2. Want to provide at least one installable "single CD Fedora" to help in parts of the world with less bandwidth 3. Need to provide a way to install via media for the following cases: * Desktop environment * Developer use * Simple LAMP server 4. Try to be as little of a burden on our mirror and testing infrastructure as possible. Given the above, we'd like to look at doing a somewhat different set of bits for Fedora 7 than was previously in the plan. But, we're still open to feedback to change things somewhat. The on the table things are: * Fedora 7 Desktop LiveCD. It's installable and it's a single CD, so it's a good step towards the single installable desktop CD case. * Fedora 7 DVD. With everything for desktop, development and "mainstream" server tasks. This ends up replacing what was previously Fedora Core. There's something of an open question as to whether we'd provide CD isos here or not. Or CD isos via bittorrent only? * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a stick at. Not available on the mirrors; bittorrent only. Hopefully can share the first disc with the Fedora 7 DVD. This would be the most at-risk and the most likely to fall off due to time pressure. * Make your own Fedora 7 step-by-step guide. This is important to help ensure that people understand and can make their own custom spins. Also, Rex is continuing to lead the efforts for the Fedora 7 KDE release and hopefully the Fedora 7 KDE LiveCD. This feels like it'll get us to a place that's reasonable for Fedora 7 and to where we can then actually get experimentation done with "hey, how can I get a single CD" rather than putting Fedora 7 on the line for the experimentation. Comments? Flames? ... Jeremy From rc040203 at freenet.de Thu Feb 15 15:31:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 16:31:42 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <200702150915.36130.dennis@ausil.us> References: <45D33FD7.4010001@redhat.com> <200702150846.16280.dennis@ausil.us> <1171552017.20765.109.camel@mccallum.corsepiu.local> <200702150915.36130.dennis@ausil.us> Message-ID: <1171553502.20765.127.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 09:15 -0600, Dennis Gilmore wrote: > On Thursday 15 February 2007 09:06, Ralf Corsepius wrote: > > On Thu, 2007-02-15 at 08:46 -0600, Dennis Gilmore wrote: > > > for now shut up and stop wasting peoples times with your rants and FUD. > > > -- > > > Dennis Gilmore, RHCE > > > > Great, how you proved your competence on privacy and replied to a PM on > > a list. > > > > I am expecting an excuse. > As is all my communications with you. By having violated the netiquette 2 times in a row, you've broken the camel's back. I am closing down all communications with you, now. From andrewparker at bigfoot.com Thu Feb 15 15:32:28 2007 From: andrewparker at bigfoot.com (Andrew Parker) Date: Thu, 15 Feb 2007 10:32:28 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <6c3f5e6c0702150732qb73fe0cr18176948c836bebe@mail.gmail.com> On 2/15/07, Jeremy Katz wrote: > Since test1 and FUDcon there's been a lot of feedback on what media sets > we should actually build, test and distribute by default. It's pretty > clear that the mix of "desktop bits without any development" didn't > really fit the needs of a lot of our users. And the incredibly long > thread about what belongs in a server spin showed that we don't really > have a good handle on what use cases we're actually trying to fill with > it. > > Given this, the board stepped back to think a bit about what we're > trying to achieve and what the problems we were trying to fix. The list > was pretty short: > > 1. Must provide a way for people to do their own custom versions > including packages from all of the Fedora universe. > 2. Want to provide at least one installable "single CD Fedora" to > help in parts of the world with less bandwidth > 3. Need to provide a way to install via media for the following > cases: > > * Desktop environment > * Developer use > * Simple LAMP server > > 4. Try to be as little of a burden on our mirror and testing > infrastructure as possible. > > > Given the above, we'd like to look at doing a somewhat different set of > bits for Fedora 7 than was previously in the plan. But, we're still > open to feedback to change things somewhat. The on the table things > are: > > * Fedora 7 Desktop LiveCD. It's installable and it's a single CD, > so it's a good step towards the single installable desktop CD > case. > * Fedora 7 DVD. With everything for desktop, development and > "mainstream" server tasks. This ends up replacing what was > previously Fedora Core. There's something of an open question as > to whether we'd provide CD isos here or not. Or CD isos via > bittorrent only? > * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a > stick at. Not available on the mirrors; bittorrent only. > Hopefully can share the first disc with the Fedora 7 DVD. This > would be the most at-risk and the most likely to fall off due to > time pressure. > * Make your own Fedora 7 step-by-step guide. This is important to > help ensure that people understand and can make their own custom > spins. > > Also, Rex is continuing to lead the efforts for the Fedora 7 KDE release > and hopefully the Fedora 7 KDE LiveCD. > > This feels like it'll get us to a place that's reasonable for Fedora 7 > and to where we can then actually get experimentation done with "hey, > how can I get a single CD" rather than putting Fedora 7 on the line for > the experimentation. Sounds to me live several moves in the right direction. >> Fedora 7 Everything. 2+ DVDs: "This would be the most at-risk and the most likely to fall off due to time pressure." i'm not aware of whats required to do this, but the concept sounds simple and not time consuming (use teh standard DVD and make 1+ DVDs with all the other RPMs). could you enlighten me as to what the process and time involved is? NB this is not a criticism, i just need enlightening. Thanks From steve at silug.org Thu Feb 15 15:37:42 2007 From: steve at silug.org (Steven Pritchard) Date: Thu, 15 Feb 2007 09:37:42 -0600 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <20070215153742.GA2716@osiris.silug.org> On Thu, Feb 15, 2007 at 10:20:39AM -0500, Jeremy Katz wrote: > And the incredibly long thread about what belongs in a server spin > showed that we don't really have a good handle on what use cases we're > actually trying to fill with > it. Given that the *vast* majority of my installs/upgrades are on servers, I still think a single-CD server spin would be *extremely* useful. (I started putting DVD-ROM drives in all my servers a while back, but a lot of them are old enough that they only have CD-ROMs.) That said... > * Make your own Fedora 7 step-by-step guide. This is important to > help ensure that people understand and can make their own custom > spins. I'm sure if there isn't an official server spin, I'll be creating my own. How hard would it be to make unofficial spins from Fedora contributors available via torrent.fedoraproject.org? Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From jfrieben at gmx.de Thu Feb 15 15:40:02 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Thu, 15 Feb 2007 16:40:02 +0100 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <20070215154002.24510@gmx.net> > 3. Need to provide a way to install via media for the following > cases: > > * Desktop environment > * Developer use Isn't the "workstation" class an already well established term and preferable to chose? > * Fedora 7 DVD. With everything for desktop, development and > "mainstream" server tasks. This ends up replacing what was > previously Fedora Core. There's something of an open question as > to whether we'd provide CD isos here or not. Or CD isos via > bittorrent only? > * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a > stick at. Not available on the mirrors; bittorrent only. > Hopefully can share the first disc with the Fedora 7 DVD. This > would be the most at-risk and the most likely to fall off due to > time pressure. Going for "Bittorrent" only for certain spins is a -very- bad idea. "Bittorrent" is blocked in certain academic and probably also enterprise environments. It's very frustrating to sit behind a "firewall" and have the necessary bandwith but no images to download. Even if "Fedora" will increase in size, it won't do that by an order of magnitude but only by a factor of 2 or so. After all, the overwhelming part of download bandwith is provided [voluntarily] by mirror sites, so I do not see a problem here. Up to now, I have not been able to download any "FC6" respin image because they can only be retrieved via "Bittorrent" .. #@!&*# -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out From karsten at redhat.com Thu Feb 15 15:44:08 2007 From: karsten at redhat.com (Karsten Hopp) Date: Thu, 15 Feb 2007 16:44:08 +0100 Subject: RFC: drop old autofoo spackages Message-ID: <45D47FC8.2050900@redhat.com> Hello, We're currently shipping several quite old automake/autoconf packages just to keep a few other old packages building. I'd like to drop the following packages: autoconf213 (8 years since the last upstream maintenance) automake14 (5 years since the last upstream maintenance) automake15 (6 years since the last upstream maintenance) automake16 (5 years since the last upstream maintenance) Packages with build dependencies on those packages: in Core: autoconf213: esc pam_smb tetex vnc automake14: libwmf automake15: nss_db automake16: gmp krbafs in Extras: autoconf213: glib gtk+ automake14: gdk-pixbuf glib gtk+ imlib WindowMaker automake16: aplus-fsf qalculate-kde Maintainers are encouraged to switch to more recent releases of the autoconf tools and work with upstream to get this done. They also should make sure if it is really necessary to run p.e. automake at all. -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From katzj at redhat.com Thu Feb 15 15:20:39 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 10:20:39 -0500 Subject: Fedora 7 media sets Message-ID: <1171552839.19239.16.camel@aglarond.local> Since test1 and FUDcon there's been a lot of feedback on what media sets we should actually build, test and distribute by default. It's pretty clear that the mix of "desktop bits without any development" didn't really fit the needs of a lot of our users. And the incredibly long thread about what belongs in a server spin showed that we don't really have a good handle on what use cases we're actually trying to fill with it. Given this, the board stepped back to think a bit about what we're trying to achieve and what the problems we were trying to fix. The list was pretty short: 1. Must provide a way for people to do their own custom versions including packages from all of the Fedora universe. 2. Want to provide at least one installable "single CD Fedora" to help in parts of the world with less bandwidth 3. Need to provide a way to install via media for the following cases: * Desktop environment * Developer use * Simple LAMP server 4. Try to be as little of a burden on our mirror and testing infrastructure as possible. Given the above, we'd like to look at doing a somewhat different set of bits for Fedora 7 than was previously in the plan. But, we're still open to feedback to change things somewhat. The on the table things are: * Fedora 7 Desktop LiveCD. It's installable and it's a single CD, so it's a good step towards the single installable desktop CD case. * Fedora 7 DVD. With everything for desktop, development and "mainstream" server tasks. This ends up replacing what was previously Fedora Core. There's something of an open question as to whether we'd provide CD isos here or not. Or CD isos via bittorrent only? * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a stick at. Not available on the mirrors; bittorrent only. Hopefully can share the first disc with the Fedora 7 DVD. This would be the most at-risk and the most likely to fall off due to time pressure. * Make your own Fedora 7 step-by-step guide. This is important to help ensure that people understand and can make their own custom spins. Also, Rex is continuing to lead the efforts for the Fedora 7 KDE release and hopefully the Fedora 7 KDE LiveCD. This feels like it'll get us to a place that's reasonable for Fedora 7 and to where we can then actually get experimentation done with "hey, how can I get a single CD" rather than putting Fedora 7 on the line for the experimentation. Comments? Flames? ... Jeremy From katzj at redhat.com Thu Feb 15 15:51:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 10:51:33 -0500 Subject: Fedora 7 media sets In-Reply-To: <6c3f5e6c0702150732qb73fe0cr18176948c836bebe@mail.gmail.com> References: <1171552839.19239.16.camel@aglarond.local> <6c3f5e6c0702150732qb73fe0cr18176948c836bebe@mail.gmail.com> Message-ID: <1171554693.19239.22.camel@aglarond.local> On Thu, 2007-02-15 at 10:32 -0500, Andrew Parker wrote: > >> Fedora 7 Everything. 2+ DVDs: "This would be the most at-risk and > the most likely to fall off due to time pressure." > > i'm not aware of whats required to do this, but the concept sounds > simple and not time consuming (use teh standard DVD and make 1+ DVDs > with all the other RPMs). could you enlighten me as to what the > process and time involved is? NB this is not a criticism, i just need > enlightening. Just putting the bits on the DVD isn't enough to be able to install from it. The metadata on the first disc has to encompass all of them, there has to be some kind of reasonable way to opt-in to the fact that you've got everything, package ordering could be ... interesting. Also, the fact that the metadata will have everything ends up meaning that the memory requirements are higher due to "more bits". Or how do you drop the bits you no longer need. It's just a few little things that are in high-impact areas so the changes need to be made with a fair bit of care and testing. And given the schedule, I'm not that confident of being able to get them done. Jeremy From jwilliam at xmission.com Thu Feb 15 15:53:01 2007 From: jwilliam at xmission.com (Jerry Williams) Date: Thu, 15 Feb 2007 08:53:01 -0700 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <003301c75119$5f686d60$020aa8c0@a18> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Jeremy Katz > Sent: Thursday, February 15, 2007 8:21 AM > To: fedora-devel-list > Subject: Fedora 7 media sets > > Since test1 and FUDcon there's been a lot of feedback on what media sets > we should actually build, test and distribute by default. It's pretty > clear that the mix of "desktop bits without any development" didn't > really fit the needs of a lot of our users. And the incredibly long > thread about what belongs in a server spin showed that we don't really > have a good handle on what use cases we're actually trying to fill with > it. > > Given this, the board stepped back to think a bit about what we're > trying to achieve and what the problems we were trying to fix. The list > was pretty short: > > 1. Must provide a way for people to do their own custom versions > including packages from all of the Fedora universe. > 2. Want to provide at least one installable "single CD Fedora" to > help in parts of the world with less bandwidth > 3. Need to provide a way to install via media for the following > cases: > > * Desktop environment > * Developer use > * Simple LAMP server > > 4. Try to be as little of a burden on our mirror and testing > infrastructure as possible. > > > Given the above, we'd like to look at doing a somewhat different set of > bits for Fedora 7 than was previously in the plan. But, we're still > open to feedback to change things somewhat. The on the table things > are: > > * Fedora 7 Desktop LiveCD. It's installable and it's a single CD, > so it's a good step towards the single installable desktop CD > case. > * Fedora 7 DVD. With everything for desktop, development and > "mainstream" server tasks. This ends up replacing what was > previously Fedora Core. There's something of an open question as > to whether we'd provide CD isos here or not. Or CD isos via > bittorrent only? > * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a > stick at. Not available on the mirrors; bittorrent only. > Hopefully can share the first disc with the Fedora 7 DVD. This > would be the most at-risk and the most likely to fall off due to > time pressure. > * Make your own Fedora 7 step-by-step guide. This is important to > help ensure that people understand and can make their own custom > spins. > > Also, Rex is continuing to lead the efforts for the Fedora 7 KDE release > and hopefully the Fedora 7 KDE LiveCD. > > This feels like it'll get us to a place that's reasonable for Fedora 7 > and to where we can then actually get experimentation done with "hey, > how can I get a single CD" rather than putting Fedora 7 on the line for > the experimentation. > > Comments? Flames? ... > > Jeremy > Sounds good to me. I would like to see the minimal install option put back. I would like to be able to get the box up and running with just enough to be able to add more later. It would be nice to have a text interface to pirut so that it would be easy to add packages later. Or maybe something as simple as some kind of text interface that would allow you to check the different yum groups and install them. Kind of like the one used to pick ipv6 in the linux rescue. Another option might be to be able to boot from the original media and have it detect that it was running the same version and just have the option to install more software or modify the system packages. It just seems like such a waste of time to install everything and then turn around and have to update it with 200-300 MB of updates. Jerry From katzj at redhat.com Thu Feb 15 15:53:57 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 10:53:57 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215153742.GA2716@osiris.silug.org> References: <1171552839.19239.16.camel@aglarond.local> <20070215153742.GA2716@osiris.silug.org> Message-ID: <1171554837.19239.26.camel@aglarond.local> On Thu, 2007-02-15 at 09:37 -0600, Steven Pritchard wrote: > On Thu, Feb 15, 2007 at 10:20:39AM -0500, Jeremy Katz wrote: > > * Make your own Fedora 7 step-by-step guide. This is important to > > help ensure that people understand and can make their own custom > > spins. > > I'm sure if there isn't an official server spin, I'll be creating my > own. > > How hard would it be to make unofficial spins from Fedora contributors > available via torrent.fedoraproject.org? Hopefully not hard at all. But they do take space, so a little bit of thought will have to happen on how to pick and choose and avoid using all of the disk space we have available Jeremy From katzj at redhat.com Thu Feb 15 15:56:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 10:56:13 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215154002.24510@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> Message-ID: <1171554973.19239.29.camel@aglarond.local> On Thu, 2007-02-15 at 16:40 +0100, Joachim Frieben wrote: > > * Fedora 7 DVD. With everything for desktop, development and > > "mainstream" server tasks. This ends up replacing what was > > previously Fedora Core. There's something of an open question as > > to whether we'd provide CD isos here or not. Or CD isos via > > bittorrent only? > > * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a > > stick at. Not available on the mirrors; bittorrent only. > > Hopefully can share the first disc with the Fedora 7 DVD. This > > would be the most at-risk and the most likely to fall off due to > > time pressure. > > Going for "Bittorrent" only for certain spins is a -very- bad idea. "Bittorrent" is blocked in certain academic and probably also enterprise environments. It's very frustrating to sit behind a "firewall" and have the necessary bandwith but no images to download. Even if "Fedora" will increase in size, it won't do that by an order of magnitude but only by a factor of 2 or so. After all, the overwhelming part of download bandwith is provided [voluntarily] by mirror sites, so I do not see a problem here. > Up to now, I have not been able to download any "FC6" respin image because they can only be retrieved via "Bittorrent" .. #@!&*# Anyone is welcome to take the bits from bittorrent and then provide FTP, HTTP, etc. But the problem is that anything on download.fedora really needs to be mirrored. And we've got a massive amount of content to be mirrored; making it available in more ISO-type chunks is duplication of what they're carrying and makes for less than happy mirror admins. Jeremy From rdieter at math.unl.edu Thu Feb 15 16:01:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Feb 2007 10:01:00 -0600 Subject: RFC: drop old autofoo spackages In-Reply-To: <45D47FC8.2050900@redhat.com> References: <45D47FC8.2050900@redhat.com> Message-ID: <45D483BC.6070901@math.unl.edu> Karsten Hopp wrote: > We're currently shipping several quite old automake/autoconf packages > just to keep > a few other old packages building. I'd like to drop the following packages: > > autoconf213 (8 years since the last upstream maintenance) > automake14 (5 years since the last upstream maintenance) > automake15 (6 years since the last upstream maintenance) > automake16 (5 years since the last upstream maintenance) By drop, you mean orphan? (: Perhaps someone more interested in the legacy aspects could take over maintainership of these. Some of these *really* are needed by some of the quasi-legacy apps/libraries Fedora (Extras) still contains. -- Rex From dimitris at glezos.com Thu Feb 15 16:01:46 2007 From: dimitris at glezos.com (Dimitrios Glezos) Date: Thu, 15 Feb 2007 16:01:46 +0000 Subject: Fedora 7 media sets In-Reply-To: <20070215154002.24510@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> Message-ID: <45D483EA.5070804@glezos.com> O/H Joachim Frieben ??????: >> 3. Need to provide a way to install via media for the following >> cases: >> >> * Desktop environment >> * Developer use > > Isn't the "workstation" class an already well established term and preferable to chose? Since I've been asked a couple of times why we are planning on shipping a Desktop spin and not a Laptop spin (!), this argument might indeed have a base. It is more accurate (the "opposite" of Server is Workstation, not Dekstop) and more correctly translated to other languages. Also, I suggest to also ship a *Minimal* spin. For the users who have aDSL (which are probably most of our users), downloading the needed packages via Anaconda is probably quicker than downloading a whole DVD (besides, burning a CD is cheaper than a DVD). I usually download only one CD (which I write on a CDRW) to do the install, so it would be nice if that iso was 100 instead of 600MB. Besides, now that Anaconda has "Extras" support, more users would actually make use of this Minimal spin, since it doesn't reflect to "minimal installation" but more to "minimal download size". Finally, would it be possible to install from minimal and have it download *updated* packages instead of the default-release ones? This way, installing FC7 4 months after its release would mean downloading only 100MB + 2GB instead of 4GB (DVD) plus 1GB (updates). My 2 cents. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From pertusus at free.fr Thu Feb 15 16:00:20 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 Feb 2007 17:00:20 +0100 Subject: RFC: drop old autofoo spackages In-Reply-To: <45D47FC8.2050900@redhat.com> References: <45D47FC8.2050900@redhat.com> Message-ID: <20070215160020.GC2797@free.fr> On Thu, Feb 15, 2007 at 04:44:08PM +0100, Karsten Hopp wrote: > Hello, > > We're currently shipping several quite old automake/autoconf packages just > to keep > a few other old packages building. I'd like to drop the following packages: > > autoconf213 (8 years since the last upstream maintenance) > automake14 (5 years since the last upstream maintenance) > automake15 (6 years since the last upstream maintenance) > automake16 (5 years since the last upstream maintenance) I think we should keep them. There are still software that use those, and also it can be very helpful when using old version of software, for example to understand when a bug was introduced. Of course sometime the libs are too old anyway but not everytime. Anyway it seems to me that the best would be to get merge them and if you don't want to maintain them orphan them, say, right after fedora 7 release. I would volunteer to maintain them, if nobody else want. It would still be usefull to try to remove any dependency on them. -- Pat From katzj at redhat.com Thu Feb 15 16:05:06 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 11:05:06 -0500 Subject: Fedora 7 media sets In-Reply-To: <45D483EA.5070804@glezos.com> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <45D483EA.5070804@glezos.com> Message-ID: <1171555506.19239.31.camel@aglarond.local> On Thu, 2007-02-15 at 16:01 +0000, Dimitrios Glezos wrote: > Also, I suggest to also ship a *Minimal* spin. For the users who have aDSL > (which are probably most of our users), downloading the needed packages via > Anaconda is probably quicker than downloading a whole DVD (besides, burning a CD > is cheaper than a DVD). I usually download only one CD (which I write on a CDRW) > to do the install, so it would be nice if that iso was 100 instead of 600MB. > Besides, now that Anaconda has "Extras" support, more users would actually make > use of this Minimal spin, since it doesn't reflect to "minimal installation" but > more to "minimal download size". How is this different from the rescue CD which we have today (and will continue to have)? > Finally, would it be possible to install from minimal and have it download > *updated* packages instead of the default-release ones? This way, installing FC7 > 4 months after its release would mean downloading only 100MB + 2GB instead of > 4GB (DVD) plus 1GB (updates). You can point at updates now; we don't list it by default because there are some non-fun interactions with media based installs. Jeremy From cra at WPI.EDU Thu Feb 15 16:09:17 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 15 Feb 2007 11:09:17 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171554973.19239.29.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> Message-ID: <20070215160917.GB3334@angus.ind.WPI.EDU> On Thu, Feb 15, 2007 at 10:56:13AM -0500, Jeremy Katz wrote: > Anyone is welcome to take the bits from bittorrent and then provide FTP, > HTTP, etc. But the problem is that anything on download.fedora really > needs to be mirrored. And we've got a massive amount of content to be > mirrored; making it available in more ISO-type chunks is duplication of > what they're carrying and makes for less than happy mirror admins. Can we start including jigdo commands in the compose process so that .jigdo and .template files are made available for those who choose to use them? I volunteer to help with this. What parts need to be modified? Pungi? From chris at idlelion.net Thu Feb 15 16:28:09 2007 From: chris at idlelion.net (chris at idlelion.net) Date: Thu, 15 Feb 2007 10:28:09 -0600 (CST) Subject: Fedora 7 media sets In-Reply-To: <20070215155804.C30BB731AE@hormel.redhat.com> References: <20070215155804.C30BB731AE@hormel.redhat.com> Message-ID: Speaking as a fan and user of Fedora on several machines, I would very much like to see the detailed instructions on making one's own distribution based on Fedora, or a very minimal install. I have a couple of old laptops with no CD drive that I would really like to put Fedora on because I know how to administer it. I've made my own boot floppy sets (that still don't seem to work quite right for FC6) and plan to start looking into initrd so my old 486 laptop with 36MB RAM will install something. Chris From mattdm at mattdm.org Thu Feb 15 16:54:22 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Feb 2007 11:54:22 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <20070215165422.GA17565@jadzia.bu.edu> On Thu, Feb 15, 2007 at 10:20:39AM -0500, Jeremy Katz wrote: > * Make your own Fedora 7 step-by-step guide. This is important to > help ensure that people understand and can make their own custom > spins. The first step should be: "Do you really need this? In many cases you could just download the 8MB boot ISO and do a net install. But if you would benefit from making a disc set with a certain subset of packages for redistribution, here's how...." -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From paul at city-fan.org Thu Feb 15 16:29:28 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Feb 2007 16:29:28 +0000 Subject: RFC: drop old autofoo spackages In-Reply-To: <45D483BC.6070901@math.unl.edu> References: <45D47FC8.2050900@redhat.com> <45D483BC.6070901@math.unl.edu> Message-ID: <45D48A68.40707@city-fan.org> Rex Dieter wrote: > Karsten Hopp wrote: > >> We're currently shipping several quite old automake/autoconf packages >> just to keep >> a few other old packages building. I'd like to drop the following >> packages: >> >> autoconf213 (8 years since the last upstream maintenance) >> automake14 (5 years since the last upstream maintenance) >> automake15 (6 years since the last upstream maintenance) >> automake16 (5 years since the last upstream maintenance) > > By drop, you mean orphan? (: > > Perhaps someone more interested in the legacy aspects could take over > maintainership of these. > > Some of these *really* are needed by some of the quasi-legacy > apps/libraries Fedora (Extras) still contains. Like the Gnome-1 stack for instance. I intend to tweak imlib (which I've recently un-orphaned) to take a patch rather than use autotools during the RPM build, but I'll be wanting to use the same version of the autotools as upstream used originally to make/maintain the patch and keep it to a sensible size. So although the actual package build will no longer need the old autotools, I as a maintainer will still need them. Paul. From mattdm at mattdm.org Thu Feb 15 16:56:38 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Feb 2007 11:56:38 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215154002.24510@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> Message-ID: <20070215165638.GB17565@jadzia.bu.edu> On Thu, Feb 15, 2007 at 04:40:02PM +0100, Joachim Frieben wrote: > > * Desktop environment > > * Developer use > Isn't the "workstation" class an already well established term and > preferable to chose? I find it confusing. Many Unix workstation systems weren't/aren't developor machines at all. > "Bittorrent" is blocked in certain academic and probably also enterprise > environments. It's very frustrating to sit behind a "firewall" and have > the necessary bandwith but no images to download. Even if "Fedora" will If you're in this situation, see my other post about net installs. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kloczek at zie.pg.gda.pl Thu Feb 15 17:01:32 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 15 Feb 2007 18:01:32 +0100 Subject: RFC: drop old autofoo spackages In-Reply-To: <45D47FC8.2050900@redhat.com> References: <45D47FC8.2050900@redhat.com> Message-ID: <1171558892.12269.2.camel@kloczek01.pracownicy.zie> Dnia 15-02-2007, czw o godzinie 16:44 +0100, Karsten Hopp napisa?(a): > automake14: > libwmf For fix this put: rm configure.ac autoreconf -f -i before %configure kloczek From jfrieben at gmx.de Thu Feb 15 17:06:26 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Thu, 15 Feb 2007 18:06:26 +0100 Subject: Fedora 7 media sets In-Reply-To: <1171554973.19239.29.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> Message-ID: <20070215170626.255630@gmx.net> > Anyone is welcome to take the bits from bittorrent and then provide FTP, > HTTP, etc. But the problem is that anything on download.fedora really > needs to be mirrored. And we've got a massive amount of content to be > mirrored; making it available in more ISO-type chunks is duplication of > what they're carrying and makes for less than happy mirror admins. > > Jeremy However, this means that many users will have to rely on the mercy of some volunteers who might step up or not, and they will be essentially cut off from official media supply. This is a big penalty and really prone of driving users away from the distribution. The example of "Fedora Unity" already shows that your suggestion is far fetched and unrealistic. I haven't found a single site yet which is mirroring the respun images. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From bofh1234 at hotmail.com Thu Feb 15 17:07:32 2007 From: bofh1234 at hotmail.com (Adam Turk) Date: Thu, 15 Feb 2007 12:07:32 -0500 Subject: Fedora 7 media sets Message-ID: Jeremy Katz wrote: >Just putting the bits on the DVD isn't enough to be able to install from >it. The metadata on the first disc has to encompass all of them, there >has to be some kind of reasonable way to opt-in to the fact that you've >got everything, package ordering could be ... interesting. Also, the >fact that the metadata will have everything ends up meaning that the >memory requirements are higher due to "more bits". Or how do you drop >the bits you no longer need. I did something like that a long time ago. Translated to current times and Linux it should be as easy as: 1 On the first DVD create two directories. fc7dvd and everything for example fc7dvd contains the metadata for the first dvd only. everything contains the metadata for the 2nd dvd. If the user selects an everything install anaconda reads the metadata from both fc7dvd and everything (I don't know how hard this is to do). Or just have the full metadata for both dvds in \everything. This might waste a little space as I don't know how much space is used by the metadata. 2 At the boot screen the default is fedora dvd and reads from the fc7dvd directory. If the types linux everything then anaconda reads from the everything directory or from both depending on which way you go. Just my 2 pennies. _________________________________________________________________ Check out all that glitters with the MSN Entertainment Guide to the Academy Awards? http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2 From sundaram at fedoraproject.org Thu Feb 15 17:13:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 15 Feb 2007 22:43:01 +0530 Subject: Fedora 7 media sets In-Reply-To: <20070215170626.255630@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215170626.255630@gmx.net> Message-ID: <45D4949D.3090604@fedoraproject.org> Joachim Frieben wrote: >> Anyone is welcome to take the bits from bittorrent and then provide FTP, >> HTTP, etc. But the problem is that anything on download.fedora really >> needs to be mirrored. And we've got a massive amount of content to be >> mirrored; making it available in more ISO-type chunks is duplication of >> what they're carrying and makes for less than happy mirror admins. >> >> Jeremy > > However, this means that many users will have to rely on the mercy of some volunteers who might step up or not, and they will be essentially cut off from official media supply. This is a big penalty and really prone of driving users away from the distribution. They could do it themselves instead of being in the "mercy" of volunteers. Enabling everyone to able to customize their own deployment is a very big benefit. > The example of "Fedora Unity" already shows that your suggestion is far fetched and unrealistic. I haven't found a single site yet which is mirroring the respun images. Do you have any suggestions? Rahul From notting at redhat.com Thu Feb 15 17:10:29 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 12:10:29 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215160917.GB3334@angus.ind.WPI.EDU> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215160917.GB3334@angus.ind.WPI.EDU> Message-ID: <20070215171029.GD11994@nostromo.devel.redhat.com> Chuck Anderson (cra at WPI.EDU) said: > Can we start including jigdo commands in the compose process so that > .jigdo and .template files are made available for those who choose to > use them? I volunteer to help with this. What parts need to be > modified? Pungi? Does jigdo create bit-identical iso images? Bill From jfrieben at gmx.de Thu Feb 15 17:12:51 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Thu, 15 Feb 2007 18:12:51 +0100 Subject: Fedora 7 media sets In-Reply-To: <20070215165638.GB17565@jadzia.bu.edu> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <20070215165638.GB17565@jadzia.bu.edu> Message-ID: <20070215171251.255620@gmx.net> > > environments. It's very frustrating to sit behind a "firewall" and have > > the necessary bandwith but no images to download. Even if "Fedora" will > > If you're in this situation, see my other post about net installs. > > > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> Sure that's what I do most of the time [at work]. However, I also have a system at home which only has a modem connection. What do you recommend in that case? -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From notting at redhat.com Thu Feb 15 17:12:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 12:12:03 -0500 Subject: Fedora 7 media sets In-Reply-To: <003301c75119$5f686d60$020aa8c0@a18> References: <1171552839.19239.16.camel@aglarond.local> <003301c75119$5f686d60$020aa8c0@a18> Message-ID: <20070215171203.GE11994@nostromo.devel.redhat.com> Jerry Williams (jwilliam at xmission.com) said: > It just seems like such a waste of time to install everything and then turn > around and have to update it with 200-300 MB of updates. Updates can be added to the install repos for network based installs. There are anaconda/yum bugs that prevent it for media-based installs at the moment. Bill From pknirsch at redhat.com Thu Feb 15 17:18:04 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 15 Feb 2007 18:18:04 +0100 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <45D495CC.9040909@redhat.com> Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. > > -Mike > I r German, and i vote for yes! ;) Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From cra at WPI.EDU Thu Feb 15 17:20:17 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 15 Feb 2007 12:20:17 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215171029.GD11994@nostromo.devel.redhat.com> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215160917.GB3334@angus.ind.WPI.EDU> <20070215171029.GD11994@nostromo.devel.redhat.com> Message-ID: <20070215172017.GS29154@angus.ind.WPI.EDU> On Thu, Feb 15, 2007 at 12:10:29PM -0500, Bill Nottingham wrote: > Chuck Anderson (cra at WPI.EDU) said: > > Can we start including jigdo commands in the compose process so that > > .jigdo and .template files are made available for those who choose to > > use them? I volunteer to help with this. What parts need to be > > modified? Pungi? > > Does jigdo create bit-identical iso images? Yes, that is the intent. During template creation, it searches the big monolithic file (in this case .iso) and finds the bits that match files in the filesystem path that you point it to (tree). It then writes a template that contains only the bits that don't match the tree. During image recreation, it uses the .template and .jigdo to rebuild the original image, gathering the component files from the tree either locally or via FTP/HTTP and filling in the missing bits from the template. The result is a bit-for-bit identical copy of the original image. From jfrieben at gmx.de Thu Feb 15 17:25:45 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Thu, 15 Feb 2007 18:25:45 +0100 Subject: Fedora 7 media sets In-Reply-To: <45D4949D.3090604@fedoraproject.org> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215170626.255630@gmx.net> <45D4949D.3090604@fedoraproject.org> Message-ID: <20070215172545.255650@gmx.net> > > The example of "Fedora Unity" already shows that your suggestion is far > fetched and unrealistic. I haven't found a single site yet which is > mirroring the respun images. > > Do you have any suggestions? > > Rahul Of course, leave things as they are: create install media for all spins and let them mirror by the usual suspects! As I stated in my initial posting, even including "Extras", the global size of the distribution is going to grow not more than a factor of 2, and the creation of particular install classes with specially tailored and reduced media size leads me to the conclusion that (per user) download volumes are even likely to decrease. Again, "Bittorrent" is blocked in many academic and corporate environments, but if somebody comes up with an alternative tool I will be the first to use it. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From cra at WPI.EDU Thu Feb 15 17:31:49 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 15 Feb 2007 12:31:49 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215172545.255650@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215170626.255630@gmx.net> <45D4949D.3090604@fedoraproject.org> <20070215172545.255650@gmx.net> Message-ID: <20070215173149.GT29154@angus.ind.WPI.EDU> On Thu, Feb 15, 2007 at 06:25:45PM +0100, Joachim Frieben wrote: > Again, "Bittorrent" is blocked in many academic and corporate > environments, but if somebody comes up with an alternative tool I > will be the first to use it. Have you checked out jigdo that I mentioned in another part of this thread? From rdieter at math.unl.edu Thu Feb 15 17:38:17 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Feb 2007 11:38:17 -0600 Subject: F7 kde package manifest Message-ID: <45D49A89.2030501@math.unl.edu> First (very) rough draft stab at a package manifest: http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/PackageList Now, I'll go see if it actually works. (: -- Rex From jfrieben at gmx.de Thu Feb 15 17:38:38 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Thu, 15 Feb 2007 18:38:38 +0100 Subject: Fedora 7 media sets In-Reply-To: <20070215173149.GT29154@angus.ind.WPI.EDU> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215170626.255630@gmx.net> <45D4949D.3090604@fedoraproject.org> <20070215172545.255650@gmx.net> <20070215173149.GT29154@angus.ind.WPI.EDU> Message-ID: <20070215173838.255630@gmx.net> > Have you checked out jigdo that I mentioned in another part of this > thread? No, I haven't, but right now, I do not see how one would reduce download volume by downloading packages and creating install media locally instead of downloading the media in the first place .. (?) -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out From green at redhat.com Thu Feb 15 16:29:32 2007 From: green at redhat.com (Anthony Green) Date: Thu, 15 Feb 2007 08:29:32 -0800 Subject: Creating a jackuser group In-Reply-To: <1170920896.13307.38.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> <1170876965.3444.7.camel@localhost.localdomain> <1170920896.13307.38.camel@localhost.localdomain> Message-ID: <1171556972.3635.15.camel@localhost.localdomain> On Thu, 2007-02-08 at 01:48 -0600, Callum Lerwick wrote: > > So handing out RT privs has to be done very carefully. I don't want to lose momentum on this issue... IIRC... a) There was an objection to using groups to manage RT privs. b) There was an objection to forcing users to answer a question about RT privs the first time they run qjackctl. c) There was an objection about requiring RT privs to run jackd via qjackctl. So, one at a time... a) There was an objection to using groups to manage RT privs. As Callum mentions above, I think we need to be careful about handing out RT privs. Not every user should have them. Using groups to handle this is standard practice in the Linux audio community, and I believe it's the kind of thing that groups are intended to manage. There was also one suggestion to name the group after the permissions granted. I don't think this is a workable solution. Perhaps there's a chance that pulseaudio and jackd permissions will be similar, but real-time java users will want something very different. I think we should stick to workload-defined groups. Whether or not some of these groups end up in the base system or are managed in add-on packages is an open question. b) There was an objection to forcing users to answer a question about RT privs the first time they run qjackctl. I don't really see this as any different from forcing users to answer questions when they first run evolution or the gimp. We just need to phrase the question is a user-friendly way. c) There was an objection about requiring RT privs to run jackd via qjackctl. Fair enough. This is a bug and I'll file it when I get online later today (I'm on a plane right now). Given all this, I would still like to move ahead with creating a jackuser group in the base system and implement the qjackctl question-asking code. Are there still objections? AG From katzj at redhat.com Thu Feb 15 17:43:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 12:43:45 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215172545.255650@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215170626.255630@gmx.net> <45D4949D.3090604@fedoraproject.org> <20070215172545.255650@gmx.net> Message-ID: <1171561425.19239.40.camel@aglarond.local> On Thu, 2007-02-15 at 18:25 +0100, Joachim Frieben wrote: > > > The example of "Fedora Unity" already shows that your suggestion is far > > fetched and unrealistic. I haven't found a single site yet which is > > mirroring the respun images. > > > > Do you have any suggestions? > > > > Rahul > > Of course, leave things as they are: create install media for all spins and let > them mirror by the usual suspects! As I stated in my initial posting, even > including "Extras", the global size of the distribution is going to grow not more > than a factor of 2, That's the thing, though -- it _IS_ growing by more than that because of the ISOs; many of the mirrors already carry Extras so the packages aren't really an increase there. Every set of CDs has to contain the kernel for example, which isn't exactly small :) > and the creation of particular install classes with specially > tailored and reduced media size leads me to the conclusion that (per user) download > volumes are even likely to decrease. Download volume isn't really the main problem as much as backend storage constraints. Download volume is only really a concern when we've decided "this is the release" and have to get however many gigs of bits to the mirrors in a short period of time so we can release. Jeremy From notting at redhat.com Thu Feb 15 17:48:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 12:48:07 -0500 Subject: Creating a jackuser group In-Reply-To: <1171556972.3635.15.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> <1170876965.3444.7.camel@localhost.localdomain> <1170920896.13307.38.camel@localhost.localdomain> <1171556972.3635.15.camel@localhost.localdomain> Message-ID: <20070215174807.GA12697@nostromo.devel.redhat.com> Anthony Green (green at redhat.com) said: > b) There was an objection to forcing users to answer a question about RT > privs the first time they run qjackctl. > > I don't really see this as any different from forcing users to answer > questions when they first run evolution or the gimp. We just need to > phrase the question is a user-friendly way. The issue here is that for things like evolution or the gimp, these are all questions that can lead to a resolution by the user himself - in this case it's '... failed. Please contact an administrator to fix this for you.' Bill From chitlesh at fedoraproject.org Thu Feb 15 18:00:25 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 15 Feb 2007 19:00:25 +0100 Subject: F7 kde package manifest In-Reply-To: <45D49A89.2030501@math.unl.edu> References: <45D49A89.2030501@math.unl.edu> Message-ID: <13dbfe4f0702151000u61981cffnd6054b05882d9502@mail.gmail.com> On 2/15/07, Rex Dieter wrote: > First (very) rough draft stab at a package manifest: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/PackageList > > Now, I'll go see if it actually works. (: I'm just curious about some packages: 1) *-extras 2) yum-updatesd (does it already support a notification on kde for updates ) ? 3) kdegraphics-extras and gwenview sounds be providing extras image viewers, why do we need more that two image viewer ? 4) compiz - it requires many gnome dependencies such as gnome-session: - unanswered RFE (easy fix): - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212987 - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212239 - desktop-effects kmenu entry I still don't see why beryl isn't among the kde spin default packages. At least it has some features towards kde which compiz doesnt have. If compiz is going in anyway, that would require lots of work in that perspective. Chitlesh -- http://clunixchit.blogspot.com From katzj at redhat.com Thu Feb 15 18:04:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 13:04:22 -0500 Subject: F7 kde package manifest In-Reply-To: <13dbfe4f0702151000u61981cffnd6054b05882d9502@mail.gmail.com> References: <45D49A89.2030501@math.unl.edu> <13dbfe4f0702151000u61981cffnd6054b05882d9502@mail.gmail.com> Message-ID: <1171562662.19239.41.camel@aglarond.local> On Thu, 2007-02-15 at 19:00 +0100, Chitlesh GOORAH wrote: > 2) yum-updatesd (does it already support a notification on kde for updates ) ? yum-updatesd just does a dbus notification that anything could listen for. puplet not working with KDE is due to a bug with GtkStatusIcon[1] Jeremy [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214222 From bruno at wolff.to Thu Feb 15 18:11:42 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 15 Feb 2007 12:11:42 -0600 Subject: Fedora 7 media sets In-Reply-To: References: <20070215155804.C30BB731AE@hormel.redhat.com> Message-ID: <20070215181142.GA5610@wolff.to> On Thu, Feb 15, 2007 at 10:28:09 -0600, chris at idlelion.net wrote: > > I have a couple of old laptops with no CD drive that I would really like > to put Fedora on because I know how to administer it. I've made my own > boot floppy sets (that still don't seem to work quite right for FC6) and > plan to start looking into initrd so my old 486 laptop with 36MB RAM will > install something. I think you want to look into the Rule project. Anaconda won't run on those machines, so you need to do something else to get things installed. The Rule project is specifically for having a way to install Fedora on machines where you can't run anaconda. From bruno at wolff.to Thu Feb 15 18:19:14 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Thu, 15 Feb 2007 12:19:14 -0600 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <20070215181914.GD5610@wolff.to> On Thu, Feb 15, 2007 at 10:20:39 -0500, Jeremy Katz wrote: > > Comments? Flames? ... I like the plan. From drago01 at gmail.com Thu Feb 15 18:22:04 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 15 Feb 2007 19:22:04 +0100 Subject: Fedora 7 media sets In-Reply-To: <20070215181914.GD5610@wolff.to> References: <1171552839.19239.16.camel@aglarond.local> <20070215181914.GD5610@wolff.to> Message-ID: <45D4A4CC.9070707@gmail.com> Bruno Wolff III wrote: > On Thu, Feb 15, 2007 at 10:20:39 -0500, > Jeremy Katz wrote: > >> Comments? Flames? ... >> > > I like the plan. > > me 2 From mattdm at mattdm.org Thu Feb 15 18:32:39 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Feb 2007 13:32:39 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215171251.255620@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <20070215165638.GB17565@jadzia.bu.edu> <20070215171251.255620@gmx.net> Message-ID: <20070215183239.GA3032@jadzia.bu.edu> On Thu, Feb 15, 2007 at 06:12:51PM +0100, Joachim Frieben wrote: > Sure that's what I do most of the time [at work]. However, I also have a > system at home which only has a modem connection. What do you recommend in > that case? Take your machine to work and install it there? :) But seriously, sounds like the "having good tools to make your own spin" should do it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at gmail.com Thu Feb 15 18:34:55 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Feb 2007 09:34:55 -0900 Subject: Fedora 7 media sets In-Reply-To: <20070215154002.24510@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> Message-ID: <604aa7910702151034p6a29eb24ta2e19542af4a6431@mail.gmail.com> On 2/15/07, Joachim Frieben wrote: > Going for "Bittorrent" only for certain spins is a -very- bad idea. "Bittorrent" is blocked in certain academic and probably also enterprise environments. I concur, this was actually a very real problem at my previous edu and gov addresses. I had enough pull with the it people and foresight to clear my usage of bittorrrent for the specific purpose of getting fedora, and got a specific ip address cleared to run a bt client, for a limited time period. But I'm sure everyone's pretty aware by now that i'm especially special, and it would be difficult to expect everyone to have such success poking holes in their academic/government/corporate firewalls for downloading fedora. If you do a bittorrent only iso, which proves to be very popular.. you may want a way for people who can't get the iso via bt to register a note so you can track how common the problem is, in proportion to the number of bt downloads. You may want to have a backup plan in place specifically to address the needs of people with local policy rules which limit the use of bt clients.. if its clear its a big enough problem and not just a couple of people. I think its a bigger problem then anyone realizes..but of course metrics are nigh impossible to obtain. -jef"Is there a potential here for some sort of bt to dynamic URL gateway?"spaleta From jkeating at redhat.com Thu Feb 15 18:35:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 13:35:25 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <200702151335.28896.jkeating@redhat.com> On Thursday 15 February 2007 10:20, Jeremy Katz wrote: > ? ? ? * Fedora 7 Desktop LiveCD. ?It's installable and it's a single CD, > ? ? ? ? so it's a good step towards the single installable desktop CD > ? ? ? ? case. I'm assuming that the Desktop SIG (does that exist?) will be on the hook for defining a manifest for this? > ? ? ? * Fedora 7 DVD. ?With everything for desktop, development and > ? ? ? ? "mainstream" server tasks. This ends up replacing what was > ? ? ? ? previously Fedora Core. There's something of an open question as > ? ? ? ? to whether we'd provide CD isos here or not. ?Or CD isos via > ? ? ? ? bittorrent only? So, who owns/helps with the manifest here? We have a good start at "Desktop" from Test1, who's going to fill in the parts for the Development, and Server stuff? Hopefully we're not going to do globs like *-devel* are we? > ? ? ? * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a > ? ? ? ? stick at. Not available on the mirrors; bittorrent only. > ? ? ? ? Hopefully can share the first disc with the Fedora 7 DVD. ?This > ? ? ? ? would be the most at-risk and the most likely to fall off due to > ? ? ? ? time pressure. This is easy enough, manifest "*" > ? ? ? * Make your own Fedora 7 step-by-step guide. This is important to > ? ? ? ? help ensure that people understand and can make their own custom > ? ? ? ? spins. I'll hopefully be working with the Docs team on this as we get near release (and pungi gets near 1.0 release) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Thu Feb 15 18:53:31 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 19:53:31 +0100 Subject: RFC: drop old autofoo spackages In-Reply-To: <45D47FC8.2050900@redhat.com> References: <45D47FC8.2050900@redhat.com> Message-ID: <200702151953.45723.opensource@till.name> On Donnerstag 15 Februar 2007, Karsten Hopp wrote: > Packages with build dependencies on those packages: > in Core: > autoconf213: > tetex Afaik tetex will be replaced by TeXLive soon. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Thu Feb 15 19:04:34 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Feb 2007 14:04:34 -0500 Subject: Fedora 7 media sets In-Reply-To: <200702151335.28896.jkeating@redhat.com> References: <1171552839.19239.16.camel@aglarond.local> <200702151335.28896.jkeating@redhat.com> Message-ID: <1171566274.3425.5.camel@localhost.localdomain> On Thu, 2007-02-15 at 13:35 -0500, Jesse Keating wrote: > On Thursday 15 February 2007 10:20, Jeremy Katz wrote: > > * Fedora 7 Desktop LiveCD. It's installable and it's a single CD, > > so it's a good step towards the single installable desktop CD > > case. > > I'm assuming that the Desktop SIG (does that exist?) will be on the hook for > defining a manifest for this? What happened to the manifest that we had for test1 ? From notting at redhat.com Thu Feb 15 19:00:30 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 14:00:30 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171566274.3425.5.camel@localhost.localdomain> References: <1171552839.19239.16.camel@aglarond.local> <200702151335.28896.jkeating@redhat.com> <1171566274.3425.5.camel@localhost.localdomain> Message-ID: <20070215190030.GA14242@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > > I'm assuming that the Desktop SIG (does that exist?) will be on the hook for > > defining a manifest for this? > > What happened to the manifest that we had for test1 ? We have both the manifest for the desktop spin, and the manifest for the LiveCD. These probably need merged. Bill From cra at WPI.EDU Thu Feb 15 19:05:20 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 15 Feb 2007 14:05:20 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215173838.255630@gmx.net> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215170626.255630@gmx.net> <45D4949D.3090604@fedoraproject.org> <20070215172545.255650@gmx.net> <20070215173149.GT29154@angus.ind.WPI.EDU> <20070215173838.255630@gmx.net> Message-ID: <20070215190520.GU29154@angus.ind.WPI.EDU> On Thu, Feb 15, 2007 at 06:38:38PM +0100, Joachim Frieben wrote: > > Have you checked out jigdo that I mentioned in another part of this > > thread? > > No, I haven't, but right now, I do not see how one would reduce > download volume by downloading packages and creating install media > locally instead of downloading the media in the first place .. (?) You download the needed packages once and use them to create multiple media sets, instead of downloading multiple media sets which contain duplicated data. From mclasen at redhat.com Thu Feb 15 19:12:09 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Feb 2007 14:12:09 -0500 Subject: Fedora 7 media sets In-Reply-To: <20070215190030.GA14242@nostromo.devel.redhat.com> References: <1171552839.19239.16.camel@aglarond.local> <200702151335.28896.jkeating@redhat.com> <1171566274.3425.5.camel@localhost.localdomain> <20070215190030.GA14242@nostromo.devel.redhat.com> Message-ID: <1171566729.3425.7.camel@localhost.localdomain> On Thu, 2007-02-15 at 14:00 -0500, Bill Nottingham wrote: > Matthias Clasen (mclasen at redhat.com) said: > > > I'm assuming that the Desktop SIG (does that exist?) will be on the hook for > > > defining a manifest for this? > > > > What happened to the manifest that we had for test1 ? > > We have both the manifest for the desktop spin, and the manifest for > the LiveCD. These probably need merged. > > Bill > Merged in what way ? Isn't the one a subset of the other ? From green at redhat.com Thu Feb 15 19:10:33 2007 From: green at redhat.com (Anthony Green) Date: Thu, 15 Feb 2007 11:10:33 -0800 Subject: Creating a jackuser group In-Reply-To: <20070215174807.GA12697@nostromo.devel.redhat.com> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> <1170876965.3444.7.camel@localhost.localdomain> <1170920896.13307.38.camel@localhost.localdomain> <1171556972.3635.15.camel@localhost.localdomain> <20070215174807.GA12697@nostromo.devel.redhat.com> Message-ID: <1171566633.3975.11.camel@localhost.localdomain> On Thu, 2007-02-15 at 12:48 -0500, Bill Nottingham wrote: > The issue here is that for things like evolution or the gimp, these > are all questions that can lead to a resolution by the user himself - > in this case it's '... failed. Please contact an administrator to fix > this for you.' Ok, but is this so terrible? Surely it's a lot better than not providing a nice way to get appropriate privileges. At the very least the user becomes aware of the issue. AG From cra at WPI.EDU Thu Feb 15 19:10:49 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 15 Feb 2007 14:10:49 -0500 Subject: yum-updatesd Message-ID: <20070215191049.GV29154@angus.ind.WPI.EDU> On Thu, Feb 15, 2007 at 01:04:22PM -0500, Jeremy Katz wrote: > On Thu, 2007-02-15 at 19:00 +0100, Chitlesh GOORAH wrote: > > 2) yum-updatesd (does it already support a notification on kde for updates ) ? > > yum-updatesd just does a dbus notification that anything could listen > for. Has yum-updatesd been fixed to actually work? I really hope some work has gone into it so that we don't end up with the situation like in FC6 where there are probably thousands of installations that are not getting updates unbeknownst to their owners: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212507 From notting at redhat.com Thu Feb 15 19:10:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Feb 2007 14:10:31 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171566729.3425.7.camel@localhost.localdomain> References: <1171552839.19239.16.camel@aglarond.local> <200702151335.28896.jkeating@redhat.com> <1171566274.3425.5.camel@localhost.localdomain> <20070215190030.GA14242@nostromo.devel.redhat.com> <1171566729.3425.7.camel@localhost.localdomain> Message-ID: <20070215191031.GA14370@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > Merged in what way ? Isn't the one a subset of the other ? I thought the F7t1 LiveCD mainfest was just the F6 one copied. Bill From rdieter at math.unl.edu Thu Feb 15 19:20:02 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Feb 2007 13:20:02 -0600 Subject: F7 kde package manifest References: <45D49A89.2030501@math.unl.edu> <13dbfe4f0702151000u61981cffnd6054b05882d9502@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > On 2/15/07, Rex Dieter wrote: >> First (very) rough draft stab at a package manifest: >> http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/PackageList >> >> Now, I'll go see if it actually works. (: > > > I'm just curious about some packages: > 1) *-extras about? > 2) yum-updatesd (does it support a notification on kde for updates) jeremy chimed in on that. >3) kdegraphics-extras and gwenview sounds be providing extras image > viewers, why do we need more that two image viewer ? These are what are on the media, not necessarily installed by default. (: > I still don't see why beryl isn't among the kde spin default packages. Good point, I forgot about that. -- Rex From jkeating at redhat.com Thu Feb 15 19:28:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 14:28:03 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171566274.3425.5.camel@localhost.localdomain> References: <1171552839.19239.16.camel@aglarond.local> <200702151335.28896.jkeating@redhat.com> <1171566274.3425.5.camel@localhost.localdomain> Message-ID: <200702151428.03176.jkeating@redhat.com> On Thursday 15 February 2007 14:04, Matthias Clasen wrote: > What happened to the manifest that we had for test1 ? That's the installable spin manifest which equals 3~ CDs in size. Not suitable for a LiveCD. Jeremy reused the FC6 LiveCD manifest, and there are some things missing that need to be fixed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dimitris at glezos.com Thu Feb 15 21:36:32 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Thu, 15 Feb 2007 21:36:32 +0000 Subject: Fedora 7 media sets In-Reply-To: <1171555506.19239.31.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <45D483EA.5070804@glezos.com> <1171555506.19239.31.camel@aglarond.local> Message-ID: <45D4D260.7090708@glezos.com> O/H Jeremy Katz ??????: > On Thu, 2007-02-15 at 16:01 +0000, Dimitrios Glezos wrote: >> Also, I suggest to also ship a *Minimal* spin. For the users who have aDSL >> (which are probably most of our users), downloading the needed packages via >> Anaconda is probably quicker than downloading a whole DVD (besides, burning a CD >> is cheaper than a DVD). I usually download only one CD (which I write on a CDRW) >> to do the install, so it would be nice if that iso was 100 instead of 600MB. >> Besides, now that Anaconda has "Extras" support, more users would actually make >> use of this Minimal spin, since it doesn't reflect to "minimal installation" but >> more to "minimal download size". > > How is this different from the rescue CD which we have today (and will > continue to have)? Glad to hear that we already have the infrastructure/plans for it, Jeremy. I didn't know that the rescueCD was installable. This sounds like a marketing mistake of ours: if a contributor didn't know about it, imagine the rest of the world. So maybe it would be better to dub it "Fedora minimal/rescue spin" and start listing it as one of the media we ship. >> Finally, would it be possible to install from minimal and have it download >> *updated* packages instead of the default-release ones? This way, installing FC7 >> 4 months after its release would mean downloading only 100MB + 2GB instead of >> 4GB (DVD) plus 1GB (updates). > > You can point at updates now; we don't list it by default because there > are some non-fun interactions with media based installs. Right. Just wanted to point out that it makes even more sense to download a minimal spin if months have passed since the release. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From grgoffe at yahoo.com Thu Feb 15 19:38:27 2007 From: grgoffe at yahoo.com (George R Goffe) Date: Thu, 15 Feb 2007 11:38:27 -0800 (PST) Subject: Possible problem with yum update. Message-ID: <895484.55176.qm@web90407.mail.mud.yahoo.com> Howdy, I just ran "yum -y update" and got some messages that, when I investigate them, seem to point to a link between /lib/modules/linux* kernel versions. I'm enclosing the whole file but here's an example below. Note the link from the 2911 kernel modules to the 2895 kernel modules. Is this a problem? Regards, George... ls -al /lib/modules/2.6.19-1.2911.fc6xen/weak-updates/em8300/adv717x.ko lrwxrwxrwx 1 root root 57 Feb 14 11:22 /lib/modules/2.6.19-1.2911.fc6xen/weak-updates/em8300/adv717x.ko -> /lib/modules/2.6.19-1.2895.fc6xen/extra/em8300/adv717x.ko ===== _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/ _/_/_/_/ _/_/_/_/ ----- _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/_/_/_/ _/ _/ _/_/_/ _/ _/_/ _/_/_/_/ ----- _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/ _/ _/_/_/_/ _/_/_/_/ ----- "It's not what you know that hurts you, It's what you know that ain't so." Will Rogers ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: what Type: application/octet-stream Size: 13779 bytes Desc: 1626052143-what URL: From katzj at redhat.com Thu Feb 15 19:45:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Feb 2007 14:45:42 -0500 Subject: Fedora 7 media sets In-Reply-To: <45D4D260.7090708@glezos.com> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <45D483EA.5070804@glezos.com> <1171555506.19239.31.camel@aglarond.local> <45D4D260.7090708@glezos.com> Message-ID: <1171568742.19239.44.camel@aglarond.local> On Thu, 2007-02-15 at 21:36 +0000, Dimitris Glezos wrote: > O/H Jeremy Katz ??????: > > On Thu, 2007-02-15 at 16:01 +0000, Dimitrios Glezos wrote: > >> Also, I suggest to also ship a *Minimal* spin. For the users who have aDSL > >> (which are probably most of our users), downloading the needed packages via > >> Anaconda is probably quicker than downloading a whole DVD (besides, burning a CD > >> is cheaper than a DVD). I usually download only one CD (which I write on a CDRW) > >> to do the install, so it would be nice if that iso was 100 instead of 600MB. > >> Besides, now that Anaconda has "Extras" support, more users would actually make > >> use of this Minimal spin, since it doesn't reflect to "minimal installation" but > >> more to "minimal download size". > > > > How is this different from the rescue CD which we have today (and will > > continue to have)? > > Glad to hear that we already have the infrastructure/plans for it, Jeremy. > > I didn't know that the rescueCD was installable. This sounds like a marketing > mistake of ours: if a contributor didn't know about it, imagine the rest of the > world. So maybe it would be better to dub it "Fedora minimal/rescue spin" and > start listing it as one of the media we ship. Yeah, I was already thinking with the syslinux menu stuff that we should make it more obvious. I definitely agree that it's something that could/should be advertised better. Jeremy From jkeating at redhat.com Thu Feb 15 19:54:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 14:54:35 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171568742.19239.44.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> <45D4D260.7090708@glezos.com> <1171568742.19239.44.camel@aglarond.local> Message-ID: <200702151454.35902.jkeating@redhat.com> On Thursday 15 February 2007 14:45, Jeremy Katz wrote: > > I didn't know that the rescueCD was installable. This sounds like a > > marketing mistake of ours: if a contributor didn't know about it, imagine > > the rest of the world. So maybe it would be better to dub it "Fedora > > minimal/rescue spin" and start listing it as one of the media we ship. > > Yeah, I was already thinking with the syslinux menu stuff that we should > make it more obvious. ?I definitely agree that it's something that > could/should be advertised better. We also now put the rescue.iso in the same iso/ dir as the rest, we could probably rename it. In the past, it was rescue as it would by default go to rescue mode, but with the new gui syslinux stuff that jeremy is talking about, we could not do that, but still make it painfully obvious how to rescue from it, and name it something more generic. There is also boot.iso and boot.img which are even smaller and can do many of the same things, they just don't have stage2 on them. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zaitcev at redhat.com Thu Feb 15 19:58:42 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 15 Feb 2007 11:58:42 -0800 Subject: Kernel bugs dispatch Message-ID: <20070215115842.49a5692e.zaitcev@redhat.com> Hi, Dave & Chuck (cc: to DKL) The old algorithm for kernel hackers when picking bugs was to add davej@ to cc: and reassign. Now that Chuck is online, do we need an adjustment? I can't add two cc's in one Bugzilla op though... Or can I? Like, over a comma? -- Pete From Matt_Domsch at dell.com Thu Feb 15 20:18:09 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 15 Feb 2007 14:18:09 -0600 Subject: Kernel bugs dispatch In-Reply-To: <20070215115842.49a5692e.zaitcev@redhat.com> References: <20070215115842.49a5692e.zaitcev@redhat.com> Message-ID: <20070215201809.GA26664@lists.us.dell.com> On Thu, Feb 15, 2007 at 11:58:42AM -0800, Pete Zaitcev wrote: > Hi, Dave & Chuck (cc: to DKL) > > The old algorithm for kernel hackers when picking bugs was to add davej@ > to cc: and reassign. Now that Chuck is online, do we need an adjustment? > I can't add two cc's in one Bugzilla op though... Or can I? Like, > over a comma? commas work fine, I do it all the time. -- 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 jspaar at users.sourceforge.net Thu Feb 15 20:24:11 2007 From: jspaar at users.sourceforge.net (Jack Spaar) Date: Thu, 15 Feb 2007 20:24:11 +0000 (UTC) Subject: Smolt: firsboot revisited References: <45D33FD7.4010001@redhat.com> <1171514916.3622.345.camel@mccallum.corsepiu.local> <1171517676.27965.287.camel@cutter> <1171519104.3622.358.camel@mccallum.corsepiu.local> <1171519385.27965.290.camel@cutter> <1171547162.5277.2.camel@localhost.localdomain> <45D46759.6090506@fedoraproject.org> Message-ID: On Thu, 15 Feb 2007 19:29:53 +0530, Rahul Sundaram wrote: > Simo Sorce wrote: > >> This is as much, or more, a PR issue, not just a legal issue. > > It was expressed as a legal issue. > [rest of comments snipped...] Since it is both legal and PR, maybe smolt could publish a specific privacy policy under which the data would be collected and used. That should stand to answer questions and guide any future code changes. I'm concerned about privacy issues more than most, and I've looked at smolt and read what Mike has said publicly. I for one am satisfied that the approach taken serves a useful purpose while doing a decent job of protecting privacy. IMHO, the only thing missing is an actual published policy which expresses formally what Mike has already said. [From what I understand: it's informed consent, opt-in, with no personally identifying information sent, and nothing is ever sent without the user's permission. It *does* store a randomly-generated GUID cookie on your drive which is transmitted as part of the profile upon installation or whenever smolt is run manually by the user. IP addresses are never retained, MAC addresses, Serial Numbers, or other UIDs are never sent.] --Jack Spaar From dblistsub-fedora at yahoo.it Thu Feb 15 21:18:20 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Thu, 15 Feb 2007 22:18:20 +0100 Subject: Creating a jackuser group In-Reply-To: <1171556972.3635.15.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <1170920896.13307.38.camel@localhost.localdomain> <1171556972.3635.15.camel@localhost.localdomain> Message-ID: <200702152218.20733.dblistsub-fedora@yahoo.it> On Thursday 15 February 2007 17:29:32 Anthony Green wrote: > a) There was an objection to using groups to manage RT privs. > > As Callum mentions above, I think we need to be careful about handing > out RT privs. Not every user should have them. Using groups to handle > this is standard practice in the Linux audio community, and I believe > it's the kind of thing that groups are intended to manage. Well, if I understand this correctly, could the above be obtained using consolehelper(8) and creating /etc/pam.d/qjackctl, which would have session required pam_limits.so conf=/etc/security/qjackctl.conf where qjackctl.conf would have * - memlock 131072 * . rtprio or am I missing something ? No groups to create, and files which RPM can add in directories which are likely to just be there. Just my $0.02, Davide Bolcioni -- There is no place like /home. From jkeating at redhat.com Thu Feb 15 22:17:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 17:17:29 -0500 Subject: First stab at the Fedora "Classic" spin Message-ID: <200702151717.29913.jkeating@redhat.com> So I took the Desktop manifest from Test1, added the Mandatory and Defaults from these groups: gnome-software-development x-software-development java-development development-libs development-tools web-server dns-server server-cfg news-server smb-server sql-server mail-server printing mysql ftp-server network-server legacy-network-server Then I did a spin. I wound up with 3.5~ CDs worth of content. http://people.redhat.com/jkeating/f7-classic.manifest is the manifest. http://people.redhat.com/jkeating/f7-classic.list is the full package list. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jdogalt at yahoo.com Thu Feb 15 23:43:12 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Thu, 15 Feb 2007 15:43:12 -0800 (PST) Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> Message-ID: <20070215234312.13355.qmail@web56912.mail.re3.yahoo.com> --- Jeremy Katz wrote: > Since test1 and FUDcon there's been a lot of feedback on what media > sets > we should actually build, test and distribute by default. It's > pretty > clear that the mix of "desktop bits without any development" didn't > really fit the needs of a lot of our users. And the incredibly long > thread about what belongs in a server spin showed that we don't > really > have a good handle on what use cases we're actually trying to fill > with > it. > > Given this, the board stepped back to think a bit about what we're > trying to achieve and what the problems we were trying to fix. The > list > was pretty short: > > 1. Must provide a way for people to do their own custom versions > including packages from all of the Fedora universe. Yes. And make it _really easy_. > 2. Want to provide at least one installable "single CD Fedora" > to > help in parts of the world with less bandwidth > 3. Need to provide a way to install via media for the following > cases: > > * Desktop environment > * Developer use > * Simple LAMP server > > 4. Try to be as little of a burden on our mirror and testing > infrastructure as possible. > > > Given the above, we'd like to look at doing a somewhat different set > of > bits for Fedora 7 than was previously in the plan. But, we're still > open to feedback to change things somewhat. The on the table things > are: > > * Fedora 7 Desktop LiveCD. It's installable and it's a single > CD, > so it's a good step towards the single installable desktop CD > case. > * Fedora 7 DVD. With everything for desktop, development and > "mainstream" server tasks. This ends up replacing what was > previously Fedora Core. There's something of an open question > as > to whether we'd provide CD isos here or not. Or CD isos via > bittorrent only? > * Fedora 7 Everything. 2+ DVDs. More bits than you can shake a > stick at. Not available on the mirrors; bittorrent only. > Hopefully can share the first disc with the Fedora 7 DVD. > This > would be the most at-risk and the most likely to fall off due > to > time pressure. How about some forward thinking- 1 hd-dvd/bluray iso. To anyone who complains about not having said hardware, tell them how easy it is to launch this live-iso in qemu, and then run the simple commandline/gui to generate any standard spin (or any arbitrary customization of any standard spin). Again, reiterating above ... make it _really easy to do this_. Also, make it trivial to copy this iso to a usb harddisk, along with a simple way to boot from the iso on the harddisk (bootloader install on the harddisk and/or small floppy/cdrom bootstrap come to mind, but I'm just thinking out loud here) > * Make your own Fedora 7 step-by-step guide. This is important > to > help ensure that people understand and can make their own > custom > spins. In my best Mr. Burns voice... Exccccelllent :) > > Also, Rex is continuing to lead the efforts for the Fedora 7 KDE > release > and hopefully the Fedora 7 KDE LiveCD. > > This feels like it'll get us to a place that's reasonable for Fedora > 7 > and to where we can then actually get experimentation done with "hey, > how can I get a single CD" rather than putting Fedora 7 on the line > for > the experimentation. > > Comments? Flames? ... Sounds like things are moving in a good direction to me. -dmc/jdog > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 From florin at andrei.myip.org Fri Feb 16 00:23:02 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 15 Feb 2007 16:23:02 -0800 Subject: Creating a jackuser group In-Reply-To: <20070215174807.GA12697@nostromo.devel.redhat.com> References: <1170790351.3564.12.camel@localhost.localdomain> <20070207015951.GC3162@nostromo.devel.redhat.com> <1170849384.2877.5.camel@localhost.localdomain> <45CA24ED.4070702@andrei.myip.org> <1170876965.3444.7.camel@localhost.localdomain> <1170920896.13307.38.camel@localhost.localdomain> <1171556972.3635.15.camel@localhost.localdomain> <20070215174807.GA12697@nostromo.devel.redhat.com> Message-ID: <45D4F966.8050901@andrei.myip.org> Bill Nottingham wrote: > Anthony Green (green at redhat.com) said: >> b) There was an objection to forcing users to answer a question about RT >> privs the first time they run qjackctl. >> >> I don't really see this as any different from forcing users to answer >> questions when they first run evolution or the gimp. We just need to >> phrase the question is a user-friendly way. > > The issue here is that for things like evolution or the gimp, these > are all questions that can lead to a resolution by the user himself - > in this case it's '... failed. Please contact an administrator to fix > this for you.' Please keep in mind that jackd users tend to be more savvy than average. -- Florin Andrei http://florin.myip.org/ From lists at sapience.com Fri Feb 16 01:20:55 2007 From: lists at sapience.com (Mail List) Date: Thu, 15 Feb 2007 20:20:55 -0500 Subject: F7 kde package manifest In-Reply-To: <45D49A89.2030501@math.unl.edu> References: <45D49A89.2030501@math.unl.edu> Message-ID: <200702152020.55500.lists@sapience.com> The 1 or 2 DVD everything spin mentioned in other thread - will it include KDE - or if not will there be an everything kde dvd? g/ From jkeating at redhat.com Fri Feb 16 01:28:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 20:28:41 -0500 Subject: F7 kde package manifest In-Reply-To: <200702152020.55500.lists@sapience.com> References: <45D49A89.2030501@math.unl.edu> <200702152020.55500.lists@sapience.com> Message-ID: <200702152028.44547.jkeating@redhat.com> On Thursday 15 February 2007 20:20, Mail List wrote: > The 1 or 2 DVD everything spin mentioned in other thread - will it include > KDE - or if not will there be an everything kde dvd? See, it is questions like this that make me smile. "Will an EVERYTHING set include KDE?" Its EVERYTHING, literally a manifest of "*". See what happens if you do 'yum install \*' -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pemboa at gmail.com Fri Feb 16 02:31:30 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 15 Feb 2007 20:31:30 -0600 Subject: F7 kde package manifest In-Reply-To: <1171562662.19239.41.camel@aglarond.local> References: <45D49A89.2030501@math.unl.edu> <13dbfe4f0702151000u61981cffnd6054b05882d9502@mail.gmail.com> <1171562662.19239.41.camel@aglarond.local> Message-ID: <16de708d0702151831ia8ac5aes8c22d8bfdb727a4a@mail.gmail.com> On 2/15/07, Jeremy Katz wrote: > On Thu, 2007-02-15 at 19:00 +0100, Chitlesh GOORAH wrote: > > 2) yum-updatesd (does it already support a notification on kde for updates ) ? > > yum-updatesd just does a dbus notification that anything could listen > for. puplet not working with KDE is due to a bug with GtkStatusIcon[1] > > Jeremy > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214222 Well I've never seen pup yet myself, and I didn't not install it. So if the program doesn't (yet?) work with KDE, and yumupdatesd seems to cause more than its fair share of issues, right put it in the KDE spin right now? -- Fedora Core 6 and proud From herrold at owlriver.com Fri Feb 16 02:47:12 2007 From: herrold at owlriver.com (R P Herrold) Date: Thu, 15 Feb 2007 21:47:12 -0500 (EST) Subject: Smolt: firsboot revisited In-Reply-To: <200702150642.53141.dennis@ausil.us> References: <45D33FD7.4010001@redhat.com> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <200702150642.53141.dennis@ausil.us> Message-ID: On Thu, 15 Feb 2007, Dennis Gilmore wrote: > Did you look at the code like i asked last time ? IP's are > not collected. the data is transmitted by post so there is > is no way to tie a UUID to an ip ummm ... don't be silly -- it is trivial to associate an originating IP to a POST This test widget at http://www.herrold.com/post/ has this HTML code to the client:
Digits only please:
and reveals the REMOTE_ADDR quite readily. The source PHP may be viewed at: http://www.herrold.com/post/index.phps -- Russ Herrold From naoki at valuecommerce.com Fri Feb 16 02:58:53 2007 From: naoki at valuecommerce.com (Naoki) Date: Fri, 16 Feb 2007 11:58:53 +0900 Subject: rawhide report: 20070215 changes In-Reply-To: <200702151059.l1FAxNsk012308@hs20-bc2-6.build.redhat.com> References: <200702151059.l1FAxNsk012308@hs20-bc2-6.build.redhat.com> Message-ID: <1171594733.26788.4.camel@dragon.valuecommerce.ne.jp> > kernel-2.6.20-1.2930.fc7 > ------------------------ > * Wed Feb 14 2007 Dave Jones > - 2.6.20-git10 > > * Tue Feb 13 2007 Dave Jones > - Resurrect the signed modules patches. Fails to boot for me with "switchroot : No such file or directory" and then a panic. (Same error as reported here : http://kerneltrap.org/node/7627) Anybody else see this, I've got nothing in my messages indicating where the problem might lie. From pemboa at gmail.com Fri Feb 16 04:30:31 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 15 Feb 2007 22:30:31 -0600 Subject: Smolt: firsboot revisited In-Reply-To: References: <45D33FD7.4010001@redhat.com> <45D3FBE6.4040706@leemhuis.info> <1171524021.3622.419.camel@mccallum.corsepiu.local> <200702150642.53141.dennis@ausil.us> Message-ID: <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> On 2/15/07, R P Herrold wrote: > On Thu, 15 Feb 2007, Dennis Gilmore wrote: > > > Did you look at the code like i asked last time ? IP's are > > not collected. the data is transmitted by post so there is > > is no way to tie a UUID to an ip > > ummm ... don't be silly -- it is trivial to associate an > originating IP to a POST > > This test widget at http://www.herrold.com/post/ has this > HTML code to the client: > >
> Digits only please:
> >
> > and reveals the REMOTE_ADDR quite readily. > > The source PHP may be viewed at: > > http://www.herrold.com/post/index.phps > > -- Russ Herrold I have to agree with this. Not that I think that this is specifically a problem. But it was false to imply that an HTTP Post is immune to IP harvesting. -- Fedora Core 6 and proud From dennis at ausil.us Fri Feb 16 04:56:01 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 22:56:01 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> References: <45D33FD7.4010001@redhat.com> <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> Message-ID: <200702152256.09194.dennis@ausil.us> Once upon a time Thursday 15 February 2007, Arthur Pemberton wrote: > On 2/15/07, R P Herrold wrote: > > On Thu, 15 Feb 2007, Dennis Gilmore wrote: > > > Did you look at the code like i asked last time ? IP's are > > > not collected. the data is transmitted by post so there is > > > is no way to tie a UUID to an ip > > > > ummm ... don't be silly -- it is trivial to associate an > > originating IP to a POST > > > > This test widget at http://www.herrold.com/post/ has this > > HTML code to the client: > > > >
> > Digits only please:
> > > >
> > > > and reveals the REMOTE_ADDR quite readily. > > > > The source PHP may be viewed at: > > > > http://www.herrold.com/post/index.phps > > > > -- Russ Herrold > > I have to agree with this. Not that I think that this is specifically > a problem. But it was false to imply that an HTTP Post is immune to IP > harvesting. sure it could be done if smolt was coded to do so but if it was in a GET it would be in the logs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pemboa at gmail.com Fri Feb 16 05:24:10 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 15 Feb 2007 23:24:10 -0600 Subject: Smolt: firsboot revisited In-Reply-To: <200702152256.09194.dennis@ausil.us> References: <45D33FD7.4010001@redhat.com> <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> <200702152256.09194.dennis@ausil.us> Message-ID: <16de708d0702152124w44e29439yac50c77f9fa1f1cf@mail.gmail.com> On 2/15/07, Dennis Gilmore wrote: > Once upon a time Thursday 15 February 2007, Arthur Pemberton wrote: > > On 2/15/07, R P Herrold wrote: > > > On Thu, 15 Feb 2007, Dennis Gilmore wrote: > > > > Did you look at the code like i asked last time ? IP's are > > > > not collected. the data is transmitted by post so there is > > > > is no way to tie a UUID to an ip > > > > > > ummm ... don't be silly -- it is trivial to associate an > > > originating IP to a POST > > > > > > This test widget at http://www.herrold.com/post/ has this > > > HTML code to the client: > > > > > >
> > > Digits only please:
> > > > > >
> > > > > > and reveals the REMOTE_ADDR quite readily. > > > > > > The source PHP may be viewed at: > > > > > > http://www.herrold.com/post/index.phps > > > > > > -- Russ Herrold > > > > I have to agree with this. Not that I think that this is specifically > > a problem. But it was false to imply that an HTTP Post is immune to IP > > harvesting. > sure it could be done if smolt was coded to do so but if it was in a GET it > would be in the logs. > How does one establish an HTTP connection without making your IP available to the server? -- Fedora Core 6 and proud From jima at beer.tclug.org Fri Feb 16 05:59:34 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 15 Feb 2007 23:59:34 -0600 (CST) Subject: Smolt: firsboot revisited In-Reply-To: <16de708d0702152124w44e29439yac50c77f9fa1f1cf@mail.gmail.com> References: <45D33FD7.4010001@redhat.com> <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> <200702152256.09194.dennis@ausil.us> <16de708d0702152124w44e29439yac50c77f9fa1f1cf@mail.gmail.com> Message-ID: On Thu, 15 Feb 2007, Arthur Pemberton wrote: > On 2/15/07, Dennis Gilmore wrote: >> sure it could be done if smolt was coded to do so but if it was in a GET >> it >> would be in the logs. > > How does one establish an HTTP connection without making your IP > available to the server? Of course the IP is exposed to the server; that doesn't mean the CGI script needs to make use of that information (which, in this case, it doesn't). The POST-vs-GET is only a matter of whether the submitted data (i.e., UUID) ends up in the log, the same place the IP does. Jima From aoliva at redhat.com Fri Feb 16 06:09:01 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 16 Feb 2007 04:09:01 -0200 Subject: Smolt: firsboot revisited In-Reply-To: <16de708d0702152124w44e29439yac50c77f9fa1f1cf@mail.gmail.com> (Arthur Pemberton's message of "Thu\, 15 Feb 2007 23\:24\:10 -0600") References: <45D33FD7.4010001@redhat.com> <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> <200702152256.09194.dennis@ausil.us> <16de708d0702152124w44e29439yac50c77f9fa1f1cf@mail.gmail.com> Message-ID: On Feb 16, 2007, "Arthur Pemberton" wrote: > How does one establish an HTTP connection without making your IP > available to the server? TOR? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at linux.duke.edu Fri Feb 16 06:11:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 16 Feb 2007 01:11:21 -0500 Subject: Smolt: firsboot revisited In-Reply-To: References: <45D33FD7.4010001@redhat.com> <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> <200702152256.09194.dennis@ausil.us> <16de708d0702152124w44e29439yac50c77f9fa1f1cf@mail.gmail.com> Message-ID: <1171606281.25527.67.camel@cutter> On Fri, 2007-02-16 at 04:09 -0200, Alexandre Oliva wrote: > On Feb 16, 2007, "Arthur Pemberton" wrote: > > > How does one establish an HTTP connection without making your IP > > available to the server? > > TOR? > I almost said the exact same thing :) -sv From jfrieben at gmx.de Fri Feb 16 07:02:38 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Fri, 16 Feb 2007 08:02:38 +0100 Subject: Fedora 7 media sets In-Reply-To: <20070215190520.GU29154@angus.ind.WPI.EDU> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <1171554973.19239.29.camel@aglarond.local> <20070215170626.255630@gmx.net> <45D4949D.3090604@fedoraproject.org> <20070215172545.255650@gmx.net> <20070215173149.GT29154@angus.ind.WPI.EDU> <20070215173838.255630@gmx.net> <20070215190520.GU29154@angus.ind.WPI.EDU> Message-ID: <20070216070238.173590@gmx.net> > > No, I haven't, but right now, I do not see how one would reduce > > download volume by downloading packages and creating install media > > locally instead of downloading the media in the first place .. (?) > > You download the needed packages once and use them to create multiple > media sets, instead of downloading multiple media sets which contain > duplicated data. So what? The same holds for downloading the image files [(1 x "Core" + 1 X "Extras") / arch] and extracting packages locally at will to recompose them for a custom install class [At least if you feel the need to do so. Using an appropriate kickstart file would do the job as well without tinkering with the install media. So, I wonder what this spin frenzy is about]. This corresponds to the standard media as those distributed for earlier releases [albeit doubled by adding "Extras" now]. Moreover, this is the only way to make sure that you have access to all available packages after installing the system without relying on permanent and high speed network access. Btw, I think nobody ever asked for all possible custom or contributed install classes to be mirrored as "ISO" images. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From ssorce at redhat.com Fri Feb 16 07:21:43 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 16 Feb 2007 02:21:43 -0500 Subject: Smolt: firsboot revisited In-Reply-To: References: <45D33FD7.4010001@redhat.com> <16de708d0702152030q7b341204i9a75218b76b08ea0@mail.gmail.com> <200702152256.09194.dennis@ausil.us> <16de708d0702152124w44e29439yac50c77f9fa1f1cf@mail.gmail.com> Message-ID: <1171610503.32599.0.camel@localhost.localdomain> On Fri, 2007-02-16 at 04:09 -0200, Alexandre Oliva wrote: > On Feb 16, 2007, "Arthur Pemberton" wrote: > > > How does one establish an HTTP connection without making your IP > > available to the server? > > TOR? Also anonymizing proxies. Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From kevin.kofler at chello.at Fri Feb 16 08:11:15 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 16 Feb 2007 08:11:15 +0000 (UTC) Subject: F7 kde package manifest References: <45D49A89.2030501@math.unl.edu> Message-ID: Rex Dieter math.unl.edu> writes: > First (very) rough draft stab at a package manifest: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/PackageList What about adding kde*-devel (at least kdelibs-devel)? The GNOME-based spin is adding development stuff (as well as server stuff, but I don't think we want that on the KDE spin, do we?) now. Kevin Kofler From kms at passback.co.uk Fri Feb 16 09:22:16 2007 From: kms at passback.co.uk (Keith Sharp) Date: Fri, 16 Feb 2007 09:22:16 +0000 Subject: Smolt: firsboot revisited In-Reply-To: <1171548179.27919.27.camel@localhost.localdomain> References: <45D33FD7.4010001@redhat.com> <200702150646.39750.dennis@ausil.us> <1171544616.20765.24.camel@mccallum.corsepiu.local> <200702150819.22336.jkeating@redhat.com> <1171548179.27919.27.camel@localhost.localdomain> Message-ID: <1171617736.3508.23.camel@animal.passback.co.uk> On Thu, 2007-02-15 at 09:02 -0500, Paul W. Frields wrote: > On Thu, 2007-02-15 at 08:19 -0500, Jesse Keating wrote: > > On Thursday 15 February 2007 08:03, Ralf Corsepius wrote: > > > Give me one reason why I should trust you more than anybody else. > > > > Because the source to the application/server we're talking about is opensource > > and available for you to review and form your own conclusions. Which you > > should do, instead of continually spreading FUD. > > Yes, let's please put this thread to rest. Any users/administrators > have at least three junctures at which they can block smolt on their > system, and can take advantage of any of them: > > 1. Don't install it; use a kickstart file that removes smolt from the > installation, or make a custom repo without it. > 2. Disable the firstboot module by twiddling around with the bits in > the %post section. > 3. When smolt asks you if you want to send any information, choose the > default NO action. 4. Explicitly block access to the Smolt server on your firewall or proxy. Keith. PS. Not that I'll be doing any of these, I think Smolt is a great idea. From buildsys at redhat.com Fri Feb 16 12:39:26 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 16 Feb 2007 07:39:26 -0500 Subject: rawhide report: 20070216 changes Message-ID: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.23-1 -------------------- * Wed Feb 14 2007 Peter Jones - 11.2.0.23-1 - Get rid of unused X mouse handling (dcantrell) - Update for newer createrepo (jkeating) - Update for device-mapper/device-mapper-libs split apr-1.2.8-4 ----------- * Thu Feb 15 2007 Joe Orton 1.2.8-4 - add BR for python * Thu Feb 15 2007 Joe Orton 1.2.8-3 - update to pick up new libtool, drop specific gcc requirement * Mon Dec 04 2006 Joe Orton 1.2.8-2 - update to 1.2.8 autoconf-2.61-4.fc7 ------------------- * Thu Feb 15 2007 Karsten Hopp 2.61-4 - add disttag - replace tabs with spaces - fix buildroot - use Requires(post), Requires(preun) - use make install DESTDIR=.... - drop perl requirement as it gets pulled it automatically autoconf213-2.13-16.fc7 ----------------------- * Thu Feb 15 2007 Karsten Hopp 2.13-16 - delete old autoconf.info file * Thu Feb 15 2007 Karsten Hopp 2.13-15 - add autoconf213 info entry - add disttag autofs-1:5.0.1-0.rc3.22 ----------------------- * Fri Feb 16 2007 Ian Kent - 5.0.1-0.rc3.22 - fix localhost replicated mounts not working (bz 208757). automake14-1.4p6-14.fc7 ----------------------- * Thu Feb 15 2007 Karsten Hopp 1.4p6-14 - misc. fixes for review bzip2-1.0.4-6.fc7 ----------------- * Fri Feb 16 2007 Ivana Varekova 1.0.4-6 - incorporate the next review feedback * Thu Feb 15 2007 Ivana Varekova 1.0.4-5 - incorporate package review feedback evolution-2.9.91-3.fc7 ---------------------- * Thu Feb 15 2007 Matthew Barnes - 2.9.91-3.fc7 - Revise patch for GNOME bug #362638 to fix RH bug #220714 (certificate prompt causes crash). * Tue Feb 13 2007 Matthew Barnes - 2.9.91-2.fc7 - Require GConf2 in post. - Require scrollkeeper in post and postun. ftp-0.17-40.fc7 --------------- * Thu Feb 15 2007 Marcela Maslanova - 0.17-40 - review again gnome-menus-2.17.91-2.fc7 ------------------------- * Thu Feb 15 2007 Matthias Clasen - 2.17.91-2 - Show the Preferences menu gnome-terminal-2.17.91-3.fc7 ---------------------------- * Thu Feb 15 2007 Matthias Clasen - 2.17.91-3 - Add System to desktop file categories gnome-volume-manager-2.17.0-4.fc7 --------------------------------- * Thu Feb 15 2007 Jesse Keating - 2.17.0-4 - Drop Req on kernel 2.6, we've been shipping that for a while k3b-0:1.0.0-0.rc6.1.fc7 ----------------------- * Thu Feb 15 2007 Harald Hoyer - 0:1.0.0-0.rc6.1 - version k3b-1.0rc6 * Wed Feb 07 2007 Harald Hoyer - 0:1.0.0-0.rc5.1 - version k3b-1.0rc5 * Wed Jan 17 2007 Harald Hoyer - 0:1.0.0-0.rc4.1 - version k3b-1.0rc4 kernel-2.6.20-1.2932.fc7 ------------------------ * Wed Feb 14 2007 Adam Jackson - nouveau drm libvirt-0.2.0-2.fc7 ------------------- * Thu Feb 15 2007 Daniel P. Berrange - 0.2.0-2.fc7 - Fixed path to qemu daemon for autostart - Fixed generation of block in XML - Pre-create config directory at startup libwmf-0.2.8.4-14.fc7 --------------------- * Thu Feb 15 2007 Caolan McNamara 0.2.8.4-14 - remove use of archaic autotools libxslt-1.1.20-1.fc7 -------------------- * Thu Feb 15 2007 Adam Jackson - Add dist tag to Release to fix 6->7 upgrades. man-pages-2.43-7.fc7 -------------------- * Thu Feb 15 2007 Ivana Varekova 2.43-5 - fix rand.3 man page (#228662) thanks Mark Summerfield * Tue Feb 13 2007 Ivana Varekova 2.43-6 - Resolves: 227260 fix iso-8859 (koi8-r) man pages * Mon Jan 29 2007 Ivana Varekova 2.43-4 - fix rt_sigprocmask.2 (#219074) - remove pciconfig_{read,write,iobase}.2 (#219827) - fix swapon.2 (#222493) man-pages-ja-20070215-1 ----------------------- * Thu Feb 15 2007 Akira TAGOH - 20070215-1 - updates to 20070215. mc-1:4.6.1a-43.20070124cvs.fc7 ------------------------------ * Thu Feb 15 2007 Jindrich Novy 4.6.1a-43 - display free space correctly for multiple filesystems (#225153) (thanks to Tomas Heinrich for patch) - fix up configs * Fri Feb 09 2007 Jindrich Novy 4.6.1a-42 - update to new CVS snapshot * Tue Feb 06 2007 Jindrich Novy 4.6.1a-41 - merge review spec fixes (#226133) mutt-5:1.5.13-2.20070212cvs.fc7 ------------------------------- * Thu Feb 15 2007 Miroslav Lichvar 5:1.5.13-2.20070212cvs - update to latest CVS - enable libidn support (#228158) php-pear-1:1.5.0-1 ------------------ * Thu Feb 15 2007 Joe Orton 1:1.5.0-1 - update to 1.5.0 * Mon Feb 05 2007 Joe Orton 1:1.4.11-4 - fix Group, mark pear.conf noreplace (#226295) python-pyblock-0.27-3 --------------------- * Thu Feb 15 2007 Peter Jones - 0.27-3 - Make it a BuildRequires on device-mapper-devel but a Requires on device-mapper-libs . quota-1:3.14-1.fc7 ------------------ * Thu Feb 15 2007 Steve Dickson 3.14-1 - Upgraded to version 3.14 (bz# 213641) tcl-1:8.4.13-10.fc7 ------------------- * Thu Feb 15 2007 Marcela Maslanova - 1:8.4.13-10 - review tk-1:8.4.13-4.fc7 ----------------- * Wed Feb 14 2007 Marcela Maslanova - 1:8.4.13-4 - rhbz#226494 review xorg-x11-drv-ark-0.6.0-3.fc7 ---------------------------- * Thu Feb 15 2007 Adam Jackson 0.6.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-ati-6.6.3-2.fc7 ---------------------------- * Thu Feb 15 2007 Adam Jackson 6.6.3-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-calcomp-1.1.0-2.fc7 -------------------------------- * Thu Feb 15 2007 Adam Jackson 1.1-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-chips-1.1.1-3.fc7 ------------------------------ * Thu Feb 15 2007 Adam Jackson 1.1.1-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-cirrus-1.1.0-3.fc7 ------------------------------- * Thu Feb 15 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-nv-1.2.2.1-3.fc7 ----------------------------- * Thu Feb 15 2007 Adam Jackson 1.2.2.1-3 - Initial nouveau driver build. Utterly untested. Broken deps for s390 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390 requires libpt_linux_s390_r.so.1.10.3 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ia64 requires libpt_linux_ia64_r.so.1.10.3()(64bit) pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.i386 requires libpt_linux_x86_r.so.1.10.3 Broken deps for x86_64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.x86_64 requires libpt_linux_x86_64_r.so.1.10.3()(64bit) Broken deps for ppc ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc requires libpt_linux_ppc_r.so.1.10.3 Broken deps for ppc64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc64 requires libpt_linux_ppc64_r.so.1.10.3()(64bit) Broken deps for s390x ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390x requires libpt_linux_s390x_r.so.1.10.3()(64bit) From drago01 at gmail.com Fri Feb 16 13:28:49 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 16 Feb 2007 14:28:49 +0100 Subject: rawhide report: 20070216 changes In-Reply-To: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> References: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> Message-ID: <45D5B191.200@gmail.com> > xorg-x11-drv-nv-1.2.2.1-3.fc7 > ----------------------------- > * Thu Feb 15 2007 Adam Jackson 1.2.2.1-3 > - Initial nouveau driver build. Utterly untested. > > does this mean that nouveau is going to replace nv? From jkeating at redhat.com Fri Feb 16 13:38:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 08:38:38 -0500 Subject: rawhide report: 20070216 changes In-Reply-To: <45D5B191.200@gmail.com> References: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> <45D5B191.200@gmail.com> Message-ID: <200702160838.42219.jkeating@redhat.com> On Friday 16 February 2007 08:28, dragoran wrote: > does this mean that nouveau is going to replace nv? In some distant future perhaps. Now it is being included for testing, much like the i810/intel driver set. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tbrinkman at sbcglobal.net Fri Feb 16 15:22:57 2007 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Fri, 16 Feb 2007 09:22:57 -0600 Subject: rawhide report: 20070215 changes In-Reply-To: <1171594733.26788.4.camel@dragon.valuecommerce.ne.jp> References: <200702151059.l1FAxNsk012308@hs20-bc2-6.build.redhat.com> <1171594733.26788.4.camel@dragon.valuecommerce.ne.jp> Message-ID: <200702160922.57335.tbrinkman@sbcglobal.net> On Thursday 15 February 2007, Naoki wrote: > > kernel-2.6.20-1.2930.fc7 > > ------------------------ > > * Wed Feb 14 2007 Dave Jones > > - 2.6.20-git10 > > > > * Tue Feb 13 2007 Dave Jones > > - Resurrect the signed modules patches. > > Fails to boot for me with "switchroot : No such file or > directory" and then a panic. (Same error as reported here : > http://kerneltrap.org/node/7627) > > Anybody else see this, I've got nothing in my messages indicating > where the problem might lie. All F7 kernels up to an including 2925 boot normally. 2930 & (today's) 2932 fail with can't resolve LABEL=/stor4/ which is my sata drive. System is two pata drives, one sata storage drive. $ df Filesystem Size Used Avail Use% Mounted on /dev/sdb1 9.9G 4.6G 4.9G 49% / /dev/sda1 92M 45M 42M 53% /boot tmpfs 502M 0 502M 0% /dev/shm /dev/sdb2 27G 9.1G 16G 37% /home /dev/sda8 41G 27G 13G 69% /stor2 /dev/sdc1 151G 114G 29G 80% /stor4 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Unfortunately I've already deleted the post that gave the lkml link, but it does seem to be the same VT6420 issue -- Tom Brinkman Corpus Christi, Texas From jwilson at redhat.com Fri Feb 16 16:25:18 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 16 Feb 2007 11:25:18 -0500 Subject: rawhide report: 20070215 changes In-Reply-To: <1171594733.26788.4.camel@dragon.valuecommerce.ne.jp> References: <200702151059.l1FAxNsk012308@hs20-bc2-6.build.redhat.com> <1171594733.26788.4.camel@dragon.valuecommerce.ne.jp> Message-ID: <200702161125.21787.jwilson@redhat.com> On Thursday 15 February 2007 21:58:53 Naoki wrote: > > kernel-2.6.20-1.2930.fc7 > > ------------------------ > > * Wed Feb 14 2007 Dave Jones > > - 2.6.20-git10 > > > > * Tue Feb 13 2007 Dave Jones > > - Resurrect the signed modules patches. > > Fails to boot for me with "switchroot : No such file or directory" and > then a panic. (Same error as reported here : > http://kerneltrap.org/node/7627) > > Anybody else see this, I've got nothing in my messages indicating where > the problem might lie. If ya got scsi drives, check out bug 220470... Could be something similar happening for ata/sata as well though... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220470 -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jdogalt at yahoo.com Fri Feb 16 17:06:07 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Fri, 16 Feb 2007 09:06:07 -0800 (PST) Subject: Fedora 7 media sets In-Reply-To: <20070216070238.173590@gmx.net> Message-ID: <232800.41803.qm@web56908.mail.re3.yahoo.com> --- Joachim Frieben wrote: > > > No, I haven't, but right now, I do not see how one would reduce > > > download volume by downloading packages and creating install > media > > > locally instead of downloading the media in the first place .. > (?) > > > > You download the needed packages once and use them to create > multiple > > media sets, instead of downloading multiple media sets which > contain > > duplicated data. > > So what? The same holds for downloading the image files [(1 x "Core" > + 1 X "Extras") / arch] and extracting packages locally at will to > recompose them for a custom install class [At least if you feel the > need to do so. Using an appropriate kickstart file would do the job > as well without tinkering with the install media. So, I wonder what > this spin frenzy is about]. ... Its about inheritance and variety. In a way that IMO more intuitively/intelligently integrates the kickstart file(s) with the install media. -dmc/jdog ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 From jfrieben at gmx.de Fri Feb 16 17:22:39 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Fri, 16 Feb 2007 18:22:39 +0100 Subject: Fedora 7 media sets In-Reply-To: <232800.41803.qm@web56908.mail.re3.yahoo.com> References: <232800.41803.qm@web56908.mail.re3.yahoo.com> Message-ID: <20070216172239.124160@gmx.net> > Its about inheritance and variety. In a way that IMO more > intuitively/intelligently integrates the kickstart file(s) with the > install media. > > -dmc/jdog There is nothing intelligent or intuitive about not providing "everything" install media which can be used by interested parties to spin their own subclasses and in the same let others proceed to a standard install without being restricted to a subsample of packages. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From zaitcev at redhat.com Fri Feb 16 18:51:45 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 16 Feb 2007 10:51:45 -0800 Subject: Kernel git repo hosting In-Reply-To: <200702071323.49975.jkeating@redhat.com> References: <20070207100344.8efbb97c.zaitcev@redhat.com> <200702071323.49975.jkeating@redhat.com> Message-ID: <20070216105145.38b29e29.zaitcev@redhat.com> On Wed, 7 Feb 2007 13:23:49 -0500, Jesse Keating wrote: > > Do I have any options within the project? I'm not on welfare, I can pay > > my own hosting... Just thought to ask because I feel more comfortable > > within our own tent. > > http://hosted.fedoraproject.org has git space should you need it. Uses the > Fedora Account System for authentication for write, otherwise you can pull > anonymously (once we get gitweb setup correctly). You can have a git repo > without having a Trac instance, should you not want/need it. This sounds pefect. I was reading the Wiki and it looks like I need to create a project as a first step. Do I get it right? -- Pete From jdogalt at yahoo.com Fri Feb 16 18:55:52 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Fri, 16 Feb 2007 10:55:52 -0800 (PST) Subject: Fedora 7 media sets In-Reply-To: <20070216172239.124160@gmx.net> Message-ID: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> --- Joachim Frieben wrote: > > > Its about inheritance and variety. In a way that IMO more > > intuitively/intelligently integrates the kickstart file(s) with the > > install media. > > > > -dmc/jdog > > There is nothing intelligent or intuitive about not providing > "everything" install media which can be used by interested parties to > spin their own subclasses and in the same let others proceed to a > standard install without being restricted to a subsample of packages. Trust me, "everything" install media as you described will exist for F7. Maybe it'll just be a 20G bluray iso since nobody cares enough to do the whole disc-split-pkgorder stuff, but it'll be there. (wearing only my non-corporate-sponsored bad-track-history prognostication hat). -dmc/jdog ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php From jkeating at redhat.com Fri Feb 16 19:06:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 14:06:46 -0500 Subject: Kernel git repo hosting In-Reply-To: <20070216105145.38b29e29.zaitcev@redhat.com> References: <20070207100344.8efbb97c.zaitcev@redhat.com> <200702071323.49975.jkeating@redhat.com> <20070216105145.38b29e29.zaitcev@redhat.com> Message-ID: <200702161406.49507.jkeating@redhat.com> On Friday 16 February 2007 13:51, Pete Zaitcev wrote: > This sounds pefect. I was reading the Wiki and it looks like I need to > create a project as a first step. Do I get it right? Only if you want a project page. If you don't want a project space in Trac, we can still accomidate you with a git repo. I did notice that there is already a set of git kernel repos on the git server: http://git.fedoraproject.org/kernel/ Do you know anything about those? I don't quite know who all uses them, I've been putting new repos into the /git/hosted/ directory space, and managing access via Fedora Account System. Oh, and git:// is working fine for anon clones. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jfrieben at gmx.de Fri Feb 16 19:18:17 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Fri, 16 Feb 2007 20:18:17 +0100 Subject: Fedora 7 media sets In-Reply-To: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> References: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> Message-ID: <20070216191817.164210@gmx.net> > Trust me, "everything" install media as you described will exist for > F7. Maybe it'll just be a 20G bluray iso since nobody cares enough to > do the whole disc-split-pkgorder stuff, but it'll be there. (wearing > only my non-corporate-sponsored bad-track-history prognostication hat). Yes, but the question is wether it will be only accessible by "Bittorrent" or not as expressed earlier in this thread. Btw, a total size 20 GB is largely exaggerated. I would rather expect 2 standard DVD images per architecture [not counting the sources which have always been shipped separately]. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From overholt at redhat.com Fri Feb 16 19:27:59 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 16 Feb 2007 14:27:59 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> Message-ID: <20070216192759.GB17022@redhat.com> * Michel Salim [2007-02-12 17:09]: > I *did* try running Fedora Eclipse against Sun Java (by mistake; the > path to the JVM got added in front of /usr/bin when I reorganized my > login scripts) and it did produce the same error. Can you file a bug about this? I've done this myself and had no issues. While we can't support running with the proprietary JVMs, i'm interested to see what the issue is. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Feb 16 19:42:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Feb 2007 14:42:33 -0500 Subject: rawhide report: 20070216 changes In-Reply-To: <45D5B191.200@gmail.com> References: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> <45D5B191.200@gmail.com> Message-ID: <20070216194233.GA2513@nostromo.devel.redhat.com> dragoran (drago01 at gmail.com) said: > >xorg-x11-drv-nv-1.2.2.1-3.fc7 > >----------------------------- > >* Thu Feb 15 2007 Adam Jackson 1.2.2.1-3 > >- Initial nouveau driver build. Utterly untested. > > does this mean that nouveau is going to replace nv? Note that the DRI bits are not (yet) in the shipped Mesa packages for 3D rendering to be testable. Bill From pemboa at gmail.com Fri Feb 16 19:48:00 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 16 Feb 2007 13:48:00 -0600 Subject: Fedora 7 media sets In-Reply-To: <20070216191817.164210@gmx.net> References: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> <20070216191817.164210@gmx.net> Message-ID: <16de708d0702161148o7617dc71y4fecb2f581b60918@mail.gmail.com> On 2/16/07, Joachim Frieben wrote: > > Trust me, "everything" install media as you described will exist for > > F7. Maybe it'll just be a 20G bluray iso since nobody cares enough to > > do the whole disc-split-pkgorder stuff, but it'll be there. (wearing > > only my non-corporate-sponsored bad-track-history prognostication hat). > > Yes, but the question is wether it will be only accessible by "Bittorrent" or not as expressed earlier in this thread. Btw, a total size 20 GB is largely exaggerated. I would rather expect 2 standard DVD images per architecture [not counting the sources which have always been shipped separately]. If I was a betting man, I would put a lot of money down against 2 DVDs - I think you underestimate Extras' size -- Fedora Core 6 and proud From jkeating at redhat.com Fri Feb 16 19:49:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 14:49:57 -0500 Subject: Fedora 7 media sets In-Reply-To: <16de708d0702161148o7617dc71y4fecb2f581b60918@mail.gmail.com> References: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> <20070216191817.164210@gmx.net> <16de708d0702161148o7617dc71y4fecb2f581b60918@mail.gmail.com> Message-ID: <200702161449.57876.jkeating@redhat.com> On Friday 16 February 2007 14:48, Arthur Pemberton wrote: > If I was a betting man, I would put a lot of money down against 2 DVDs > - I think you underestimate Extras' size A pungi manifest of '*' gives me 2~ DVDs for i386, and most likely 3 DVDs for x86-64 and ppc due to multilib. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Fri Feb 16 19:51:24 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 16 Feb 2007 11:51:24 -0800 (PST) Subject: Kernel git repo hosting In-Reply-To: Jesse Keating's message of Friday, 16 February 2007 14:06:46 -0500 <200702161406.49507.jkeating@redhat.com> Message-ID: <20070216195124.6BCFC180076@magilla.sf.frob.com> > I did notice that there is already a set of git kernel repos on the git > server: http://git.fedoraproject.org/kernel/ I publish my utrace GIT repo there. That was set up before all the fancier Fedora project stuff was there. From pemboa at gmail.com Fri Feb 16 19:53:26 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 16 Feb 2007 13:53:26 -0600 Subject: Fedora 7 media sets In-Reply-To: <200702161449.57876.jkeating@redhat.com> References: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> <20070216191817.164210@gmx.net> <16de708d0702161148o7617dc71y4fecb2f581b60918@mail.gmail.com> <200702161449.57876.jkeating@redhat.com> Message-ID: <16de708d0702161153q6878e9afse8f1a48f9c15077c@mail.gmail.com> On 2/16/07, Jesse Keating wrote: > On Friday 16 February 2007 14:48, Arthur Pemberton wrote: > > If I was a betting man, I would put a lot of money down against 2 DVDs > > - I think you underestimate Extras' size > > A pungi manifest of '*' gives me 2~ DVDs for i386, and most likely 3 DVDs for > x86-64 and ppc due to multilib. > > -- > Jesse Keating > Release Engineer: Fedora > Okay, and that's just for now. Ideally, extras would grow. -- Fedora Core 6 and proud From jkeating at redhat.com Fri Feb 16 20:03:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 15:03:46 -0500 Subject: Fedora 7 media sets In-Reply-To: <16de708d0702161153q6878e9afse8f1a48f9c15077c@mail.gmail.com> References: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> <200702161449.57876.jkeating@redhat.com> <16de708d0702161153q6878e9afse8f1a48f9c15077c@mail.gmail.com> Message-ID: <200702161503.46687.jkeating@redhat.com> On Friday 16 February 2007 14:53, Arthur Pemberton wrote: > Okay, and that's just for now. Ideally, extras would grow. Absolutely. Grow/shrink will happen as software evolves. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Feb 16 21:08:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Feb 2007 16:08:05 -0500 Subject: Announcing a change in the Fedora 7 schedule Message-ID: <200702161608.14572.jkeating@redhat.com> One of the big Features of Fedora 7 is a merged core and extras. In order to accomplish this, we need some improvements to the buildsystem currently used by Fedora Extras. We need these improvements done or mostly done by the Feature Freeze of Fedora 7, which was originally set to be the 20th of February, 4 days from now. It is very clear that these changes will not be ready by then. To accomplish these changes (and others) in time for the Feature Freeze, we have added another month to the schedule, introducing a Test 4, and moving the Feature Freeze as well as String Freeze up to Test 3 freeze, March 19. This moves the general availability date from April 26 to May 24. For further discussion on this topic, please use the fedora-maintainers list, which I am attempting to set reply-to. For reference: http://fedoraproject.org/wiki/Releases/7/Schedule -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jdogalt at yahoo.com Fri Feb 16 21:36:41 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Fri, 16 Feb 2007 13:36:41 -0800 (PST) Subject: Fedora 7 media sets In-Reply-To: <20070216191817.164210@gmx.net> Message-ID: <854043.41554.qm@web56914.mail.re3.yahoo.com> --- Joachim Frieben wrote: > > Trust me, "everything" install media as you described will exist > for > > F7. Maybe it'll just be a 20G bluray iso since nobody cares enough > to > > do the whole disc-split-pkgorder stuff, but it'll be there. > (wearing > > only my non-corporate-sponsored bad-track-history prognostication > hat). > > Yes, but the question is wether it will be only accessible by > "Bittorrent" or not as expressed earlier in this thread. Btw, a total > size 20 GB is largely exaggerated. I would rather expect 2 standard > DVD images per architecture [not counting the sources which have > always been shipped separately]. Is "Bittorrent" something different from bittorrent? Honestly, I think this has been said before- but if a set of data available via bittorrent is not popular enough that someone decides to mirror it with http, thats just too bad. Of course, now I'm thinking about whether its possible to use a combination of fuse, iso9660, bittorrent, and yum to provide a software repository distribution mechanism that doesn't rely on http mirrors with lots of space and bandwidth... (i.e. think fuse-bittorentfs with an iso9660 layer in there, and a default yum base config that plays well with such a configuration. Probably too much overhead in there, but it sounds tempting to me) -dmc/jdog ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 From jdogalt at yahoo.com Fri Feb 16 21:58:35 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Fri, 16 Feb 2007 13:58:35 -0800 (PST) Subject: Fedora 7 media sets In-Reply-To: <854043.41554.qm@web56914.mail.re3.yahoo.com> Message-ID: <307050.12178.qm@web56909.mail.re3.yahoo.com> --- Jane Dogalt wrote: > > --- Joachim Frieben wrote: > > > > Trust me, "everything" install media as you described will exist > > for > > > F7. Maybe it'll just be a 20G bluray iso since nobody cares > enough > > to > > > do the whole disc-split-pkgorder stuff, but it'll be there. > > (wearing > > > only my non-corporate-sponsored bad-track-history prognostication > > hat). > > > > Yes, but the question is wether it will be only accessible by > > "Bittorrent" or not as expressed earlier in this thread. Btw, a > total > > size 20 GB is largely exaggerated. I would rather expect 2 standard > > DVD images per architecture [not counting the sources which have > > always been shipped separately]. > > Is "Bittorrent" something different from bittorrent? Honestly, I > think > this has been said before- but if a set of data available via > bittorrent is not popular enough that someone decides to mirror it > with > http, thats just too bad. > > Of course, now I'm thinking about whether its possible to use a > combination of fuse, iso9660, bittorrent, and yum to provide a > software > repository distribution mechanism that doesn't rely on http mirrors > with lots of space and bandwidth... > > (i.e. think fuse-bittorentfs with an iso9660 layer in there, and a > default yum base config that plays well with such a configuration. > Probably too much overhead in there, but it sounds tempting to me) And of course to encourage participation in the fedora-skynet-grid you make it an enablable option checkbox right next to the smolt enable checkbox, along with an explanation that if they do so, 10% of their average used CPU time, 10% of their average used disk space, and 10% of their average used network bandwidth, will be used to participate in this grid (just a big bittorrent mirror of the master 30G all-arches F8 snapshot live iso). Anybody know if bittorrent handles well the case when you have 1000 clients offering 10G of space to communally mirror a 100G file? That sounds like a "community operating system" to me :) (for updates, I'm thinking a master server builds a daily snapshot iso, then distributes it to other mirrors via xdelta from the master iso bits of the prior day, then all the clients access via the same bittorrent-iso-fuse-fs thing. Though there are probably a couple holes that need filling in that design...) bhh... -dmc/jdog ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 From pemboa at gmail.com Fri Feb 16 22:25:10 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 17 Feb 2007 16:25:10 +1800 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702161608.14572.jkeating@redhat.com> References: <200702161608.14572.jkeating@redhat.com> Message-ID: <16de708d0702161425w68dd9b16p416f26eb519565da@mail.gmail.com> On 2/17/07, Jesse Keating wrote: > One of the big Features of Fedora 7 is a merged core and extras. In order to > accomplish this, we need some improvements to the buildsystem currently used > by Fedora Extras. We need these improvements done or mostly done by the > Feature Freeze of Fedora 7, which was originally set to be the 20th of > February, 4 days from now. It is very clear that these changes will not be > ready by then. > > To accomplish these changes (and others) in time for the Feature Freeze, we > have added another month to the schedule, introducing a Test 4, and moving > the Feature Freeze as well as String Freeze up to Test 3 freeze, March 19. > > This moves the general availability date from April 26 to May 24. > > For further discussion on this topic, please use the fedora-maintainers list, > which I am attempting to set reply-to. > > For reference: http://fedoraproject.org/wiki/Releases/7/Schedule > > -- > Jesse Keating > Release Engineer: Fedora I would vote for delaying F7 as long as necessary, since the new changes is the big update to be looked forward to in F7. -- Fedora Core 6 and proud From rdieter at math.unl.edu Sat Feb 17 00:18:25 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Feb 2007 18:18:25 -0600 Subject: F7 kde package manifest In-Reply-To: References: <45D49A89.2030501@math.unl.edu> Message-ID: <45D649D1.7040106@math.unl.edu> Kevin Kofler wrote: > Rex Dieter math.unl.edu> writes: >> First (very) rough draft stab at a package manifest: >> http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/PackageList > > What about adding kde*-devel Good spot, will do. (As a matter of fact, we currently don't include any of *-devel). -- Rex From stickster at gmail.com Sat Feb 17 01:03:47 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Feb 2007 20:03:47 -0500 Subject: Fedora 7 media sets In-Reply-To: <1171552839.19239.16.camel@aglarond.local> References: <1171552839.19239.16.camel@aglarond.local> Message-ID: <1171674227.15333.28.camel@localhost.localdomain> On Thu, 2007-02-15 at 10:20 -0500, Jeremy Katz wrote: > * Make your own Fedora 7 step-by-step guide. This is important to > help ensure that people understand and can make their own custom > spins. We (Docs) want to help with this. In fact, I'll volunteer to help turn any raw content you can provide, or point out for me, into DocBook and prepare it for release with F7. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project Board: http://fedoraproject.org/wiki/Board Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject -------------- 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 aoliva at redhat.com Sat Feb 17 07:44:15 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Sat, 17 Feb 2007 05:44:15 -0200 Subject: Fedora 7 media sets In-Reply-To: <20070216191817.164210@gmx.net> (Joachim Frieben's message of "Fri\, 16 Feb 2007 20\:18\:17 +0100") References: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> <20070216191817.164210@gmx.net> Message-ID: On Feb 16, 2007, "Joachim Frieben" wrote: >> Trust me, "everything" install media as you described will exist for >> F7. Maybe it'll just be a 20G bluray iso since nobody cares enough to >> do the whole disc-split-pkgorder stuff, but it'll be there. (wearing >> only my non-corporate-sponsored bad-track-history prognostication hat). > Yes, but the question is wether it will be only accessible by > "Bittorrent" or not as expressed earlier in this thread. Since individual packages will be available for http, I guess we could at least make jigdo files for the iso images available over http as well. Then mirrors won't be burdened in space by a multitude of content duplication across even multiple sets packaged as installable media, but people will still be able to obtain such media. Although it will burden mirrors with multiple rpm requests. I'm not sure which would they'd prefer... -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From buildsys at redhat.com Sat Feb 17 10:52:21 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 17 Feb 2007 05:52:21 -0500 Subject: rawhide report: 20070217 changes Message-ID: <200702171052.l1HAqLe2010342@hs20-bc2-6.build.redhat.com> Updated Packages: amtu-1.0.4-6.fc7 ---------------- * Fri Feb 16 2007 Steve Grubb 1.0.4-6 - change buildroot anaconda-11.2.0.24-1 -------------------- * Fri Feb 16 2007 David Cantrell - 11.2.0.24-1 - Fix compiler warnings in wlite code - Remove obsolete code from network_gui.py - Rebuild to link with new libdhcp6client and new libdhcp audit-1.4.1-1.fc7 ----------------- * Fri Feb 16 2007 Steve Grubb 1.4.1-1 - updated audit_rule_fieldpair_data to handle perm correctly (#226780) - Finished search options for audit parsing library - Fix ausearch -se to work correctly - Fix auditd init script for /usr on netdev (#228528) - Parse avc seperms better when there are more than one coreutils-6.7-6.fc7 ------------------- * Fri Feb 16 2007 Tim Waugh 6.7-6 - Provide version for stat (bug #225655). - Fixed permissions on profile scripts (bug #225655). dhcp-12:3.0.5-20.fc7 -------------------- * Fri Feb 16 2007 David Cantrell - 12:3.0.5-20 - Review cleanups (#225691) * Fri Feb 09 2007 David Cantrell - 12:3.0.5-19 - Require openldap-devel on dhcp-devel and libdhcp4client-devel packages * Thu Feb 08 2007 David Cantrell - 12:3.0.5-18 - Fix libdhcp4client visibility _again_ (#198496) dhcpv6-0.10-40.fc7 ------------------ * Fri Feb 16 2007 David Cantrell - 0.10-40 - Remove strlcat(), we don't use it or need it - Close socket correctly in gethwid() (#229005) libdhcp-1.20-2.fc7 ------------------ * Fri Feb 16 2007 David Cantrell - 1.20-2 - Rebuild for new libdhcp6client * Fri Feb 16 2007 David Cantrell - 1.20-1 - Make sure network interface is enabled in pumpSetupInterface (#224072) libvirt-0.2.0-3.fc7 ------------------- * Fri Feb 16 2007 Daniel P. Berrange - 0.2.0-3.fc7 - Disable kqemu support since its not in Fedora qemu binary - Fix for -vnc arg syntax change in 0.9.0 QEMU mod_python-3.3.1-2 ------------------ * Fri Feb 16 2007 Joe Orton 3.3.1-2 - update to 3.3.1 - fix BuildRoot, Summary, drop BR for autoconf perl-Archive-Tar-1.30-2.fc7 --------------------------- * Fri Feb 16 2007 Robin Norwood - 1.30-2 - Resolves: rhbz#226239 - Remove tabs from spec file for package review php-5.2.1-2 ----------- * Thu Feb 15 2007 Joe Orton 5.2.1-2 - update to 5.2.1 - fix regression in str_{i,}replace (from upstream) - add Requires(pre) for httpd - trim %changelog to versions >= 5.0.0 policycoreutils-2.0.1-2.fc7 --------------------------- * Thu Feb 15 2007 Dan Walsh 2.0.1-2 - Cleanup man pages syntax - Add sepolgen * Mon Feb 12 2007 Dan Walsh 2.0.1-1 - Update to upstream * Merged small fix to correct include of errcodes.h in semodule_deps from Dan Walsh. selinux-policy-2.5.3-3.fc7 -------------------------- * Thu Feb 15 2007 Dan Walsh 2.5.3-3 - Add sepolgen support - Add bugzilla policy vnc-4.1.2-11.fc7 ---------------- * Fri Feb 16 2007 Adam Tkac 4.1.2-11.fc7 - major build-process changes in vnc - vnc is now completely built by autotools - new package (vnc-libs) contains remote framebuffer library and vncviewer and server is linked against this - specfile cleanup xorg-x11-drv-amd-0.0-8.20061016git.fc7 -------------------------------------- * Mon Oct 16 2006 Adam Jackson 0.0-8.20061016git.fc7 - Today's snapshot: More Xv love. - Add check for (and abort on existance of) .git directory in the work dir. xorg-x11-drv-ast-0.81.0-4.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 0.81.0-4 - ExclusiveArch -> ExcludeArch xorg-x11-drv-citron-2.2.0-2.fc7 ------------------------------- * Fri Feb 16 2007 Adam Jackson 2.2.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-digitaledge-1.1.0-2.fc7 ------------------------------------ * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-dmc-1.1.0-3.fc7 ---------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-dummy-0.2.0-3.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 0.2.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-dynapro-1.1.0-3.fc7 -------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-elo2300-1.1.0-2.fc7 -------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-elographics-1.1.0-2.fc7 ------------------------------------ * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-evdev-1.1.2-3.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 1.1.2-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-fbdev-0.3.1-2.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 0.3.1-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-fpit-1.1.0-2.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-glint-1.1.1-5.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 1.1.1-5 - ExclusiveArch -> ExcludeArch xorg-x11-drv-hyperpen-1.1.0-3.fc7 --------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-i128-1.2.0-5.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 1.2.0-5 - ExclusiveArch -> ExcludeArch xorg-x11-drv-i740-1.1.0-3.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-jamstudio-1.1.0-2.fc7 ---------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-joystick-1.1.0-2.fc7 --------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-keyboard-1.1.0-3.fc7 --------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-magellan-1.1.0-2.fc7 --------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-mga-1.4.6.1-2.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 1.4.6.1-2 - ExclusiveArch -> ExcludeArch - DRI on all arches xorg-x11-drv-microtouch-1.1.0-2.fc7 ----------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-mouse-1.2.1-2.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 1.2.1-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-mutouch-1.1.0-3.fc7 -------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-palmax-1.1.0-2.fc7 ------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-penmount-1.1.0-3.fc7 --------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-rendition-4.1.3-2.fc7 ---------------------------------- * Fri Feb 16 2007 Adam Jackson 4.1.3-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-s3-0.5.0-2.fc7 --------------------------- * Fri Feb 16 2007 Adam Jackson 0.5.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-s3virge-1.9.1-3.fc7 -------------------------------- * Fri Feb 16 2007 Adam Jackson 1.9.1-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-savage-2.1.2-2.fc7 ------------------------------- * Fri Feb 16 2007 Adam Jackson 2.1.2-2 - ExclusiveArch -> ExcludeArch - Enable DRI on all arches xorg-x11-drv-siliconmotion-1.4.1-3.fc7 -------------------------------------- * Fri Feb 16 2007 Adam Jackson 1.4.1-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-sis-0.9.3-2.fc7 ---------------------------- * Fri Feb 16 2007 Adam Jackson 0.9.3-2 - ExclusiveArch -> ExcludeArch * Fri Dec 01 2006 Adam Jackson 0.9.3-1 - Update to 0.9.3 * Sun Oct 01 2006 Jesse Keating - 0.9.1-7 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 xorg-x11-drv-sisusb-0.8.1-5.fc7 ------------------------------- * Fri Feb 16 2007 Adam Jackson 0.8.1-5 - ExclusiveArch -> ExcludeArch xorg-x11-drv-spaceorb-1.1.0-2.fc7 --------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-summa-1.1.0-2.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-tdfx-1.3.0-3.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 1.3.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-tek4957-1.1.0-2.fc7 -------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-trident-1.2.3-3.fc7 -------------------------------- * Fri Feb 16 2007 Adam Jackson 1.2.3-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-tseng-1.1.0-4.fc7 ------------------------------ * Fri Feb 16 2007 Adam Jackson 1.1.0-4 - ExclusiveArch -> ExcludeArch xorg-x11-drv-ur98-1.1.0-2.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-2 - ExclusiveArch -> ExcludeArch xorg-x11-drv-v4l-0.1.1-5.fc7 ---------------------------- * Fri Feb 16 2007 Adam Jackson 0.1.1-5 - ExclusiveArch -> ExcludeArch xorg-x11-drv-vesa-1.3.0-3.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 1.3.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-vga-4.1.0-3.fc7 ---------------------------- * Fri Feb 16 2007 Adam Jackson 4.1.0-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-void-1.1.0-4.fc7 ----------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-4 - ExclusiveArch -> ExcludeArch xorg-x11-drv-voodoo-1.1.0-4.fc7 ------------------------------- * Fri Feb 16 2007 Adam Jackson 1.1.0-4 - ExclusiveArch -> ExcludeArch xterm-224-1.fc7 --------------- * Fri Feb 16 2007 Miroslav Lichvar 224-1 - update to 224 - drop utempter group before creating pty - add Icon to desktop file (#227925) Broken deps for s390 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390 requires libpt_linux_s390_r.so.1.10.3 mod_python - 3.3.1-2.s390 requires python-abi = 0:%{pyver} systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ia64 requires libpt_linux_ia64_r.so.1.10.3()(64bit) mod_python - 3.3.1-2.ia64 requires python-abi = 0:%{pyver} pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for ppc64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc64 requires libpt_linux_ppc64_r.so.1.10.3()(64bit) mod_python - 3.3.1-2.ppc64 requires python-abi = 0:%{pyver} Broken deps for x86_64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.x86_64 requires libpt_linux_x86_64_r.so.1.10.3()(64bit) mod_python - 3.3.1-2.x86_64 requires python-abi = 0:%{pyver} Broken deps for s390x ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390x requires libpt_linux_s390x_r.so.1.10.3()(64bit) mod_python - 3.3.1-2.s390x requires python-abi = 0:%{pyver} Broken deps for i386 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.i386 requires libpt_linux_x86_r.so.1.10.3 mod_python - 3.3.1-2.i386 requires python-abi = 0:%{pyver} Broken deps for ppc ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc requires libpt_linux_ppc_r.so.1.10.3 mod_python - 3.3.1-2.ppc requires python-abi = 0:%{pyver} From drago01 at gmail.com Sat Feb 17 12:01:07 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 17 Feb 2007 13:01:07 +0100 Subject: xorg 7.2 for FC6 Message-ID: <45D6EE83.5010209@gmail.com> Hello, Are they any plans for updated xorg packages for FC6? From nicolas.mailhot at laposte.net Sat Feb 17 13:32:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Feb 2007 22:32:18 +0900 Subject: Default MTA for Fedora 7 In-Reply-To: <1170534841.3775.0.camel@dawkins> References: <1170534841.3775.0.camel@dawkins> Message-ID: <45D703E2.90102@laposte.net> David Nielsen a ?crit : > l?r, 03 02 2007 kl. 16:47 +0100, skrev Thomas M Steenholdt: > >> I noticed that Exim is being installed as the default MTA, at least on >> the Desktop installation of Fedora 7 test1. Is this change intentional? >> I can't seem to find it mentioned anywhere?!? >> > > What in a desktop install could possibly require an MTA.. it seems a bit > daft to me. > A fetchmail -> local mta with spam filtering -> local imap server will do wonders on a desktop system. Benefits over using mail client spam filtering : - it just works - you don't have to reconfigure the filtering each time you switch mail clients or upgrade them - you can use as many mail/webmail clients in parallel over the same backend as you want - it filters even when the user session is closed, no need to wait minutes for the mail client to digest new mails in the morning - it can be wickedly more efficient than GUI stuff - it just works What's daft is not using a full MTA but serverising mail clients so they process stuff in the background (except you lose as soon as you close your GUI sessions, GUI writers don't know zip about keeping compatibility, the GUI clients fight each other, the good spam filters are server-side, etc etc) The MTA config time investment is quickly repaid The huge webmail wins these past years are directly linked to their server-side spam processing and the PITA GUI mail client SPAM filtering is From michel.salim at gmail.com Sat Feb 17 16:13:54 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 11:13:54 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <20070216192759.GB17022@redhat.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> <20070216192759.GB17022@redhat.com> Message-ID: <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> 2007/2/16, Andrew Overholt : > * Michel Salim [2007-02-12 17:09]: > > I *did* try running Fedora Eclipse against Sun Java (by mistake; the > > path to the JVM got added in front of /usr/bin when I reorganized my > > login scripts) and it did produce the same error. > > Can you file a bug about this? I've done this myself and had no issues. > While we can't support running with the proprietary JVMs, i'm interested > to see what the issue is. > Certainly! The reason I posted here first, though, is ... which component do I file this against? -- Michel Salim http://hircus.wordpress.com/ From michel.salim at gmail.com Sat Feb 17 16:27:39 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 11:27:39 -0500 Subject: ekiga needs rebuild Message-ID: <883cfe6d0702170827t3bf1c806kc6115d5b32438276@mail.gmail.com> Probably not worth Bugzilla-ing, but could someone rebuild Ekiga? It depends on the old version of pwlib, thus blocking the pwlib and opal upgrade (opal is rebuilt against the new version) Thanks, -- Michel Salim http://hircus.wordpress.com/ From darrellpf at gmail.com Sat Feb 17 16:28:04 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 17 Feb 2007 08:28:04 -0800 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> <20070216192759.GB17022@redhat.com> <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> Message-ID: On 2/17/07, Michel Salim wrote: > 2007/2/16, Andrew Overholt : > > * Michel Salim [2007-02-12 17:09]: > > > I *did* try running Fedora Eclipse against Sun Java (by mistake; the > > > path to the JVM got added in front of /usr/bin when I reorganized my > > > login scripts) and it did produce the same error. > > > > Can you file a bug about this? I've done this myself and had no issues. > > While we can't support running with the proprietary JVMs, i'm interested > > to see what the issue is. > > > Certainly! The reason I posted here first, though, is ... which > component do I file this against? > I'm using eclipse.org version of Eclipse 3.2 along with Sun JDK 1.6.0 on an updated rawhide. Eclipse has always worked perfectly until a couple of days ago. Currently checkboxes are broken. They don't seem to highlight correctly when pressed and also seem to act as a button group even though they're not. It makes even simple things (like using the file import dialog to import files into a project) very difficult. I'm waiting to see if an update to rawhide in the next couple of days will fix it. darrell From michel.salim at gmail.com Sat Feb 17 16:41:36 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 11:41:36 -0500 Subject: External drives not detected at boot time? Message-ID: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> In Rawhide, USB external drives are not detected if they are plugged in at boot time, requiring power-cycling before the required device nodes are created in /dev and gnome-volume-manager works. Has there been any changes in the boot process that might have caused this? -- Michel Salim http://hircus.wordpress.com/ From kevin.kofler at chello.at Sat Feb 17 17:46:48 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 17 Feb 2007 17:46:48 +0000 (UTC) Subject: Problem running SWT apps on Sun JVM on Fedora 7? References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> <20070216192759.GB17022@redhat.com> <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> Message-ID: darrell pfeifer gmail.com> writes: > Currently checkboxes are broken. They don't seem to highlight > correctly when pressed and also seem to act as a button group even > though they're not. It makes even simple things (like using the file > import dialog to import files into a project) very difficult. This one has also been seen with the pygtk2-based system-config apps, see: http://www.redhat.com/archives/fedora-test-list/2007-February/msg00463.html Kevin Kofler From kevin.kofler at chello.at Sat Feb 17 17:55:36 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 17 Feb 2007 17:55:36 +0000 (UTC) Subject: rawhide report: 20070217 changes References: <200702171052.l1HAqLe2010342@hs20-bc2-6.build.redhat.com> Message-ID: redhat.com> writes: > - Disable kqemu support since its not in Fedora qemu binary Can't this be enabled now that it's GPL? I'm not asking you or anyone else to maintain the kmod, just to build QEMU and libvirt with support for it so someone else can build it and have it just work. I currently only use QEMU to emulate different arches, so I don't personally have a use for kqemu, but other people may. Kevin Kofler From lsof at nodata.co.uk Sat Feb 17 18:57:29 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 17 Feb 2007 19:57:29 +0100 Subject: External drives not detected at boot time? In-Reply-To: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> References: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> Message-ID: <1171738649.3331.0.camel@sb-home.lan> Am Samstag, den 17.02.2007, 11:41 -0500 schrieb Michel Salim: > In Rawhide, USB external drives are not detected if they are plugged > in at boot time, What happens if you plug it in after boot? > requiring power-cycling before the required device > nodes are created in /dev and gnome-volume-manager works. Power cycling of the external drive or the PC? > > Has there been any changes in the boot process that might have caused this? > > -- > Michel Salim > http://hircus.wordpress.com/ > From bofh1234 at hotmail.com Sat Feb 17 20:23:47 2007 From: bofh1234 at hotmail.com (Adam Turk) Date: Sat, 17 Feb 2007 15:23:47 -0500 Subject: fedora-devel-list Digest, Vol 36, Issue 58 In-Reply-To: <20070217170004.768BB72F76@hormel.redhat.com> Message-ID: From: "Michel Salim" >In Rawhide, USB external drives are not detected if they are plugged >in at boot time, requiring power-cycling before the required device >nodes are created in /dev and gnome-volume-manager works. > >Has there been any changes in the boot process that might have caused this? This problem has been around since August 2006. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204396 for the details. The short version is it works for a little while then it stops working due to some update. It works again, stops working. repeat. There is no rhyme or reason to it. _________________________________________________________________ Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE.? http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline From michel.salim at gmail.com Sat Feb 17 21:34:02 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 16:34:02 -0500 Subject: External drives not detected at boot time? In-Reply-To: <1171738649.3331.0.camel@sb-home.lan> References: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> <1171738649.3331.0.camel@sb-home.lan> Message-ID: <883cfe6d0702171334v6102357bhd78578a60a285ebf@mail.gmail.com> 2007/2/17, nodata : > Am Samstag, den 17.02.2007, 11:41 -0500 schrieb Michel Salim: > > In Rawhide, USB external drives are not detected if they are plugged > > in at boot time, > > What happens if you plug it in after boot? > Same as if I power-cycle the drive (easier than unplugging and re-plugging the USB cable): it's detected as a USB mass-storage device, is then scanned for partititions and the device nodes created. > > requiring power-cycling before the required device > > nodes are created in /dev and gnome-volume-manager works. > > Power cycling of the external drive or the PC? > The external drive For some reason it seems that when the USB modules are first loaded, mass storage devices are not properly initialized (my USB mouse, on the other hand, works just fine) -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From wart at kobold.org Sat Feb 17 21:46:35 2007 From: wart at kobold.org (Wart) Date: Sat, 17 Feb 2007 13:46:35 -0800 Subject: External drives not detected at boot time? In-Reply-To: <883cfe6d0702171334v6102357bhd78578a60a285ebf@mail.gmail.com> References: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> <1171738649.3331.0.camel@sb-home.lan> <883cfe6d0702171334v6102357bhd78578a60a285ebf@mail.gmail.com> Message-ID: <45D777BB.6060808@kobold.org> Michel Salim wrote: > 2007/2/17, nodata : >> Am Samstag, den 17.02.2007, 11:41 -0500 schrieb Michel Salim: >> > In Rawhide, USB external drives are not detected if they are plugged >> > in at boot time, >> >> What happens if you plug it in after boot? >> > Same as if I power-cycle the drive (easier than unplugging and > re-plugging the USB cable): it's detected as a USB mass-storage > device, is then scanned for partititions and the device nodes created. > >> > requiring power-cycling before the required device >> > nodes are created in /dev and gnome-volume-manager works. >> >> Power cycling of the external drive or the PC? >> > The external drive > > For some reason it seems that when the USB modules are first loaded, > mass storage devices are not properly initialized (my USB mouse, on > the other hand, works just fine) I've heard of similar problems when using devices connected to a USB hub. If the hub draws power from the USB bus, then some power-hungry devices don't get properly detected at boot time. But if the USB hub has its own power source, things would work better. --Wart From nman64 at n-man.com Sat Feb 17 21:47:03 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sat, 17 Feb 2007 15:47:03 -0600 Subject: Google's Summer of Code 2007 Message-ID: <200702171547.08941.nman64@n-man.com> Google recently announced that they will host the third annual Summer of Code. The Fedora Project has participated in each of the previous years, and, unless I hear any strong objections, I intend to lead our participation again this year. We will be able to apply for participation from the 5th of March to the 12th of March. I'll be happy to hear any feedback on the subject until that time. Of course, if we do participate again this year, we'll need to produce more ideas for students to try for. Remember that, whether or not the project is completed according to the original idea, we have nothing to lose, and we can give these students a great opportunity to experience open source development. http://code.google.com/soc/ http://fedoraproject.org/wiki/SummerOfCode -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bofh1234 at hotmail.com Sat Feb 17 21:45:22 2007 From: bofh1234 at hotmail.com (Adam Turk) Date: Sat, 17 Feb 2007 16:45:22 -0500 Subject: External drives not detected at boot time? Message-ID: From: "Michel Salim" >In Rawhide, USB external drives are not detected if they are plugged >in at boot time, requiring power-cycling before the required device >nodes are created in /dev and gnome-volume-manager works. > >Has there been any changes in the boot process that might have caused this? This problem has been around since August 2006. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204396 for the details. The short version is it works for a little while then it stops working due to some update. It works again, stops working. repeat. There is no rhyme or reason to it. _________________________________________________________________ Want a degree but can't afford to quit? Top school degrees online - in as fast as 1 year http://forms.nextag.com/goto.jsp?url=/serv/main/buyer/education.jsp?doSearch=n&tm=y&search=education_text_links_88_h288c&s=4079&p=5116 From michel.salim at gmail.com Sun Feb 18 01:03:23 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 20:03:23 -0500 Subject: External drives not detected at boot time? In-Reply-To: References: Message-ID: <883cfe6d0702171703t2b3a3230g4a23995ec2edad25@mail.gmail.com> 2007/2/17, Adam Turk : > From: "Michel Salim" > > >In Rawhide, USB external drives are not detected if they are plugged > >in at boot time, requiring power-cycling before the required device > >nodes are created in /dev and gnome-volume-manager works. > > > >Has there been any changes in the boot process that might have caused this? > > This problem has been around since August 2006. See > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204396 for the details. > > The short version is it works for a little while then it stops working due > to some update. It works again, stops working. repeat. There is no rhyme or > reason to it. > Hmm, I've not had that problem with FC6. Guess I was lucky until now. -- Michel Salim http://hircus.wordpress.com/ From michel.salim at gmail.com Sun Feb 18 01:05:36 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 20:05:36 -0500 Subject: External drives not detected at boot time? In-Reply-To: <45D777BB.6060808@kobold.org> References: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> <1171738649.3331.0.camel@sb-home.lan> <883cfe6d0702171334v6102357bhd78578a60a285ebf@mail.gmail.com> <45D777BB.6060808@kobold.org> Message-ID: <883cfe6d0702171705s55e73530o92c42c1ac1dadc57@mail.gmail.com> 2007/2/17, Wart : > Michel Salim wrote: > > 2007/2/17, nodata : > >> Am Samstag, den 17.02.2007, 11:41 -0500 schrieb Michel Salim: > >> > In Rawhide, USB external drives are not detected if they are plugged > >> > in at boot time, > >> > >> What happens if you plug it in after boot? > >> > > Same as if I power-cycle the drive (easier than unplugging and > > re-plugging the USB cable): it's detected as a USB mass-storage > > device, is then scanned for partititions and the device nodes created. > > > >> > requiring power-cycling before the required device > >> > nodes are created in /dev and gnome-volume-manager works. > >> > >> Power cycling of the external drive or the PC? > >> > > The external drive > > > > For some reason it seems that when the USB modules are first loaded, > > mass storage devices are not properly initialized (my USB mouse, on > > the other hand, works just fine) > > I've heard of similar problems when using devices connected to a USB > hub. If the hub draws power from the USB bus, then some power-hungry > devices don't get properly detected at boot time. But if the USB hub > has its own power source, things would work better. > The USB hub is powered, and furthermore, the drive itself has its own power adapter. Culprit seems to be the new ub USB driver, as discussed in the Bugzilla entry that Adam posted below. -- Michel Salim http://hircus.wordpress.com/ From michel.salim at gmail.com Sun Feb 18 01:11:53 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 17 Feb 2007 20:11:53 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> <20070216192759.GB17022@redhat.com> <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> Message-ID: <883cfe6d0702171711p57339443k5c577b6006923fd9@mail.gmail.com> 2007/2/17, darrell pfeifer : > On 2/17/07, Michel Salim wrote: > > 2007/2/16, Andrew Overholt : > > > * Michel Salim [2007-02-12 17:09]: > > > > I *did* try running Fedora Eclipse against Sun Java (by mistake; the > > > > path to the JVM got added in front of /usr/bin when I reorganized my > > > > login scripts) and it did produce the same error. > > > > > > Can you file a bug about this? I've done this myself and had no issues. > > > While we can't support running with the proprietary JVMs, i'm interested > > > to see what the issue is. > > > > > Certainly! The reason I posted here first, though, is ... which > > component do I file this against? > > > > I'm using eclipse.org version of Eclipse 3.2 along with Sun JDK 1.6.0 > on an updated rawhide. Eclipse has always worked perfectly until a > couple of days ago. > When I use the 32-bit JDK or JRE with the 32-bit Eclipse (SWT has to be compiled against GTK on Unix platforms, thus SWT-using applications are not arch-independent) everything works fine (apart from the checkboxes). The problem I mentioned only affect Java/x86_64 and 64-bit SWT apps. > Currently checkboxes are broken. They don't seem to highlight > correctly when pressed and also seem to act as a button group even > though they're not. It makes even simple things (like using the file > import dialog to import files into a project) very difficult. > Yup. As Kevin mentioned, this affects PyGTK apps as well. Native GTK apps (and Firefox) works fine for some strange reason. -- Michel Salim http://hircus.wordpress.com/ From davehoz at gmail.com Sun Feb 18 02:19:12 2007 From: davehoz at gmail.com (David Hunter) Date: Sun, 18 Feb 2007 13:19:12 +1100 Subject: ekiga needs rebuild In-Reply-To: <883cfe6d0702170827t3bf1c806kc6115d5b32438276@mail.gmail.com> References: <883cfe6d0702170827t3bf1c806kc6115d5b32438276@mail.gmail.com> Message-ID: <6bb886180702171819n310ae933sa2bf09c0221f07c@mail.gmail.com> I would rebuild it if I had the knowladge. On 18/02/07, Michel Salim wrote: > > Probably not worth Bugzilla-ing, but could someone rebuild Ekiga? It > depends on the old version of pwlib, thus blocking the pwlib and opal > upgrade (opal is rebuilt against the new version) > > Thanks, > > -- > Michel Salim > http://hircus.wordpress.com/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Sun Feb 18 02:30:12 2007 From: opensource at till.name (Till Maas) Date: Sun, 18 Feb 2007 03:30:12 +0100 Subject: rawhide report: 20070217 changes In-Reply-To: References: <200702171052.l1HAqLe2010342@hs20-bc2-6.build.redhat.com> Message-ID: <200702180330.20718.opensource@till.name> On Samstag 17 Februar 2007, Kevin Kofler wrote: > redhat.com> writes: > > - Disable kqemu support since its not in Fedora qemu binary > > Can't this be enabled now that it's GPL? I'm not asking you or anyone else > to maintain the kmod, just to build QEMU and libvirt with support for it so > someone else can build it and have it just work. Yes please, there is a dkms at freshrpms btw. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From overholt at redhat.com Sun Feb 18 02:47:44 2007 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 17 Feb 2007 21:47:44 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> <20070216192759.GB17022@redhat.com> <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> Message-ID: <20070218024744.GA13617@redhat.com> Adding Ben Konrath to thread * Michel Salim [2007-02-17 11:14]: > 2007/2/16, Andrew Overholt : > >* Michel Salim [2007-02-12 17:09]: > >> I *did* try running Fedora Eclipse against Sun Java (by mistake; the > >> path to the JVM got added in front of /usr/bin when I reorganized my > >> login scripts) and it did produce the same error. > > > >Can you file a bug about this? I've done this myself and had no issues. > >While we can't support running with the proprietary JVMs, i'm interested > >to see what the issue is. > > > Certainly! The reason I posted here first, though, is ... which > component do I file this against? eclipse. Bug components are created by SRPM and libswt3-gtk2 is a sub-package of the eclipse SRPM. Please provide details of how your ran Eclipse and the output of: which java which javac readlink -f `which java` readlink -f `which javac` rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" | egrep \ "eclipse|swt|^java-1|gcj" It for sure doesn't work with eclipse -vm /bin/java ? And it *does* work with libgcj? Ben: can you think of anything I'm missing here? Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From markmc34 at verizon.net Sun Feb 18 05:59:23 2007 From: markmc34 at verizon.net (Markus McLaughlin) Date: Sun, 18 Feb 2007 00:59:23 -0500 Subject: Intro : Mark McLaughlin And Suggestions Message-ID: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> Hello folks! My name is Mark McLaughlin, I am a Writer and a FAN of Fedora! Here are suggestions for FUTURE Fedora Releases... Borrowing from Windows Vista : An Expanded Start Menu, showing additional helpful info A Sidebar of Widgets of Weather Forecasts, Alarm Clock, Stock Ticker, Sports Ticker, News Ticker. Borrowing from MAC OS X : Spotlight, a QUICK means to find whatever you need to find. Songbird Software Integration that works with an IPOD a la itunes. My Ideas : Star Wars Scrollup Screen Saver, text you type in, scroll into outer space just like in those classic movies! A very good modular video editor, burrowing ideas from Final Cut Express. A very good Podcast Studio software, something similar to Audacity and GarageBand. Finally, older Windoze 98/2000/XP games should be supported via WINEX or something similar. I maintain a BLOG at fedoraworld.blogspot.com, if you have any inside news on Fedora 7 and beyond, please e-mail anything to me so I can include it on my blog, thanks! Mark McLaughlin - fedoraworld.blogspot.com From zaitcev at redhat.com Sun Feb 18 06:46:58 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 17 Feb 2007 22:46:58 -0800 Subject: External drives not detected at boot time? In-Reply-To: References: Message-ID: <20070217224658.3fe2506e.zaitcev@redhat.com> On Sat, 17 Feb 2007 16:45:22 -0500, "Adam Turk" wrote: > From: "Michel Salim" > >In Rawhide, USB external drives are not detected if they are plugged > >in at boot time, requiring power-cycling before the required device > >nodes are created in /dev and gnome-volume-manager works. > > > >Has there been any changes in the boot process that might have caused this? > > This problem has been around since August 2006. See > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204396 for the details. The bug 204396 obviously has nothing to do with Michel's problem, because it refers to a specific failure scenario which cannot be affected by a power cycle. For the case of libusual, Dave Jones have not dropped ub from Rawhide kernels yet. Perhaps he's giving me time to find an acceptable workaround or somehow work the class-based notifier into upstream. But neither the notifier patch is applied, so we continue to have this problem. So, once Michel figures out his problem, he may run into the 204396, and would need to apply one of the workarounds listed there. -- Pete From mladen.kuntner at triera.net Sun Feb 18 09:07:31 2007 From: mladen.kuntner at triera.net (Mladen Kuntner) Date: Sun, 18 Feb 2007 10:07:31 +0100 Subject: no networking after latest update Message-ID: <1171789651.2311.5.camel@cpe1-23-149.cable.triera.net> After latest update networking does not work. (kernel-2.6.20-1.2932.fc7) It is working on kernel-2.6.20-1.2922.fc7. Gigabyte motherboard with nforce chipset. mladen kuntner From luya_tfz at thefinalzone.com Sun Feb 18 09:33:41 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Sun, 18 Feb 2007 04:33:41 -0500 Subject: Intro : Mark McLaughlin And Suggestions In-Reply-To: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> References: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> Message-ID: <1171791221.45d81d75b9ab5@ssl.mecca.ca> Quoting Markus McLaughlin : > Borrowing from Windows Vista : > > An Expanded Start Menu, showing additional helpful info Too cluttered IMHO. > A Sidebar of Widgets of Weather Forecasts, Alarm Clock, Stock Ticker, > Sports > Ticker, News Ticker. Already available with an application called gdesklets and superkaramba in KDE. Microsoft Windows Vista is not that innovative at all because most of features are already available in both Linux, BSD and OSX (Yahoo widget formely known as Konbafulator which can be used in Windows XP/2000/2003). > Borrowing from MAC OS X : > > Spotlight, a QUICK means to find whatever you need to find. Already available with an search engine like Beagle to name a few. > Songbird Software Integration that works with an IPOD a la itunes. Songbird can be made available for Fedora with gstreamer as backend engine without patented formats. > My Ideas : > > Star Wars Scrollup Screen Saver, text you type in, scroll into outer > space just like in > those classic movies! > Already available AFAIK through xscreensavers. > A very good modular video editor, burrowing ideas from Final Cut > Express. Try Kino. Cinerrela is another tool but is not included in repository due to the use of patented format. > > A very good Podcast Studio software, something similar to Audacity > and GarageBand. Audacity is already available for Fedora in repository. > > Finally, older Windoze 98/2000/XP games should be supported via WINEX > or something similar. Wine is already available and can run most of Windows games. BTW, Winex is now known as Cedega. -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From luya_tfz at thefinalzone.com Sun Feb 18 09:40:10 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Sun, 18 Feb 2007 04:40:10 -0500 Subject: Intro : Mark McLaughlin And Suggestions In-Reply-To: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> References: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> Message-ID: <1171791610.45d81efa53228@ssl.mecca.ca> Additional point is starting with Fedora 7, users will be able to further customize their own Fedora right before the installation. Only limit is the user creativity. -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From mladen.kuntner at triera.net Sun Feb 18 10:26:57 2007 From: mladen.kuntner at triera.net (Mladen Kuntner) Date: Sun, 18 Feb 2007 11:26:57 +0100 Subject: no networking after latest update In-Reply-To: <1171789651.2311.5.camel@cpe1-23-149.cable.triera.net> References: <1171789651.2311.5.camel@cpe1-23-149.cable.triera.net> Message-ID: <1171794417.2688.3.camel@cpe1-23-149.cable.triera.net> On Sun, 2007-02-18 at 10:07 +0100, Mladen Kuntner wrote: > After latest update networking does not work. > (kernel-2.6.20-1.2932.fc7) > > It is working on kernel-2.6.20-1.2922.fc7. > > Gigabyte motherboard with nforce chipset. > > mladen kuntner > Already in bugzilla 229099. mladen kuntner From chitlesh at fedoraproject.org Sun Feb 18 12:31:49 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 18 Feb 2007 13:31:49 +0100 Subject: Intro : Mark McLaughlin And Suggestions In-Reply-To: <1171791610.45d81efa53228@ssl.mecca.ca> References: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> <1171791610.45d81efa53228@ssl.mecca.ca> Message-ID: <13dbfe4f0702180431n4801b263qf27c89250bef3ac1@mail.gmail.com> On 2/18/07, Luya Tshimbalanga wrote: > Additional point is starting with Fedora 7, users will be able to further > customize their own Fedora right before the installation. Only limit is the > user creativity. Or perhaps we can add as "documents" or "attached to Release Notes" some notes and screenshots of those features that Fedora is shipping. Not everyone knows all the list of packages fedora is shipping and how they can be used. Possibly, if we can write somewhere in the spin, what people can do to customize their own fedora with fedora packages will be fun. We have now Fedora Statistics showing how far Fedora has been successful and we are having more and more end users trying fedora. it would be nice to let them know the features fedora provides that are not setup by default. Perhaps after Fosdem, I'll start doing my own list for the kde spin. Chitlesh -- http://clunixchit.blogspot.com From gilboad at gmail.com Sun Feb 18 12:39:31 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 18 Feb 2007 14:39:31 +0200 Subject: External drives not detected at boot time? In-Reply-To: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> References: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> Message-ID: <1171802371.9730.0.camel@gilboa-work-dev.localdomain> On Sat, 2007-02-17 at 11:41 -0500, Michel Salim wrote: > In Rawhide, USB external drives are not detected if they are plugged > in at boot time, requiring power-cycling before the required device > nodes are created in /dev and gnome-volume-manager works. > > Has there been any changes in the boot process that might have caused this? > > -- > Michel Salim > http://hircus.wordpress.com/ > Seems like it has something to do with BZ# 174887 [1] - Gilboa [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174887 From cra at WPI.EDU Sun Feb 18 15:37:31 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 18 Feb 2007 10:37:31 -0500 Subject: Fedora 7 media sets In-Reply-To: References: <20070216185552.40314.qmail@web56912.mail.re3.yahoo.com> <20070216191817.164210@gmx.net> Message-ID: <20070218153731.GB23624@angus.ind.WPI.EDU> On Sat, Feb 17, 2007 at 05:44:15AM -0200, Alexandre Oliva wrote: > Then mirrors won't be burdened in space by a multitude of content > duplication across even multiple sets packaged as installable media, > but people will still be able to obtain such media. Although it will > burden mirrors with multiple rpm requests. I'm not sure which would > they'd prefer... Once you have some of the rpm files locally, you don't need to download them again to recreate a different iso image. You could point jigdo at the local tree, or even a loopback mounted iso image. From bloch at verdurin.com Sun Feb 18 15:39:26 2007 From: bloch at verdurin.com (bloch at verdurin.com) Date: Sun, 18 Feb 2007 15:39:26 +0000 Subject: rawhide report: 20070216 changes In-Reply-To: <20070216194233.GA2513@nostromo.devel.redhat.com> References: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> <45D5B191.200@gmail.com> <20070216194233.GA2513@nostromo.devel.redhat.com> Message-ID: <20070218153926.GA19449@bloch.config> On Fri, 16 Feb 2007, Bill Nottingham wrote: > dragoran (drago01 at gmail.com) said: > > >xorg-x11-drv-nv-1.2.2.1-3.fc7 > > >----------------------------- > > >* Thu Feb 15 2007 Adam Jackson 1.2.2.1-3 > > >- Initial nouveau driver build. Utterly untested. > > > > does this mean that nouveau is going to replace nv? > > Note that the DRI bits are not (yet) in the shipped Mesa packages > for 3D rendering to be testable. > If it has dual-head support, that will be very useful on its own. From stickster at gmail.com Sun Feb 18 17:16:49 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 18 Feb 2007 12:16:49 -0500 Subject: Intro : Mark McLaughlin And Suggestions In-Reply-To: <13dbfe4f0702180431n4801b263qf27c89250bef3ac1@mail.gmail.com> References: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> <1171791610.45d81efa53228@ssl.mecca.ca> <13dbfe4f0702180431n4801b263qf27c89250bef3ac1@mail.gmail.com> Message-ID: <1171819009.4101.30.camel@localhost.localdomain> On Sun, 2007-02-18 at 13:31 +0100, Chitlesh GOORAH wrote: > On 2/18/07, Luya Tshimbalanga wrote: > > Additional point is starting with Fedora 7, users will be able to further > > customize their own Fedora right before the installation. Only limit is the > > user creativity. > > Or perhaps we can add as "documents" or "attached to Release Notes" > some notes and screenshots of those features that Fedora is shipping. > Not everyone knows all the list of packages fedora is shipping and how > they can be used. Possibly, if we can write somewhere in the spin, > what people can do to customize their own fedora with fedora packages > will be fun. There has been a "Tours" section? in the wiki ever since Core 5, so I encourage you to get involved for F7 and put these sorts of pointers there. The Release Notes need to stay oriented on what has changed since previous versions, and aren't well-suited to housing lists of fun facts and pointers. The Wiki is a better place for that, and we already link to the Tours section in the Release Notes "Overview" section. There may be other suitable documents that the Docs Project has already, such as the Desktop User Guide or a Customization Guide. = = = ? http://fedoraproject.org/wiki/Tours -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 chitlesh at fedoraproject.org Sun Feb 18 17:31:59 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 18 Feb 2007 18:31:59 +0100 Subject: Intro : Mark McLaughlin And Suggestions In-Reply-To: <1171819009.4101.30.camel@localhost.localdomain> References: <55F7C263-52DF-491E-A003-73156DF0B5F6@verizon.net> <1171791610.45d81efa53228@ssl.mecca.ca> <13dbfe4f0702180431n4801b263qf27c89250bef3ac1@mail.gmail.com> <1171819009.4101.30.camel@localhost.localdomain> Message-ID: <13dbfe4f0702180931lf5fc9a3ta53ebc3674ada25f@mail.gmail.com> On 2/18/07, Paul W. Frields wrote: > There has been a "Tours" section? in the wiki ever since Core 5, so I > encourage you to get involved for F7 and put these sorts of pointers > there. True, that should do it. Chitlesh -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Sun Feb 18 20:20:15 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 18 Feb 2007 21:20:15 +0100 Subject: F7 kde package manifest In-Reply-To: <45D649D1.7040106@math.unl.edu> References: <45D49A89.2030501@math.unl.edu> <45D649D1.7040106@math.unl.edu> Message-ID: <13dbfe4f0702181220x1a192a9bx181023ae1269bbd8@mail.gmail.com> Hello, Well I see no progress since our last IRC meeting, So I made a brief "easy" list of items which we can do before the next meeting: http://fedoraproject.org/wiki/ChitleshGoorah/kde Any one want to take over any items listed ? Comments, suggestions ?? The "Extras extras splits" section entails further extras packages which I'm proposing to move to the kdeutils-extras package. What do you think, is it worth ? I can do it myself since, I already split the recommended apps (from http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE). see https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148301 And, It don't know where to send my proposed split spec file, I've chosen their respective review request, though kdeutils has already been approved. Any one has a better solution ?? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194375 Chitlesh -- http://clunixchit.blogspot.com From markmc34 at verizon.net Sun Feb 18 21:58:54 2007 From: markmc34 at verizon.net (Markus McLaughlin) Date: Sun, 18 Feb 2007 16:58:54 -0500 Subject: Fedora Creative Suite Proposal Message-ID: <0643B7A3-0B9D-4D46-A81A-58318E756144@verizon.net> What's needed for a Creative Person such as myself in a Multimedia Fedora Spin... The latest OpenOffice 2.1(openoffice.org;) NVU.com, (Web Editor;) GIMPshop (very good hack of GIMP;) Scribus (newsletter;) Kino (Video Editor;) Audacity (Sound Editor;) VideoLAN Client; WINE support for Picasa (iphoto clone;) Firefox 2, Thunderbird 2, and GAIM. A special Live CD or DVD with just multimedia software enabled would be SOOOOO cool! Mark McLaughlin - fedoraworld.blogspot.com From jwboyer at jdub.homelinux.org Mon Feb 19 00:54:52 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 18 Feb 2007 18:54:52 -0600 Subject: Fedora Creative Suite Proposal In-Reply-To: <0643B7A3-0B9D-4D46-A81A-58318E756144@verizon.net> References: <0643B7A3-0B9D-4D46-A81A-58318E756144@verizon.net> Message-ID: <1171846492.2777.2.camel@vader.jdub.homelinux.org> On Sun, 2007-02-18 at 16:58 -0500, Markus McLaughlin wrote: > What's needed for a Creative Person such as myself in a Multimedia > Fedora Spin... > > The latest OpenOffice 2.1(openoffice.org;) NVU.com, (Web Editor;) > GIMPshop (very good hack of GIMP;) Scribus (newsletter;) Kino (Video > Editor;) Audacity (Sound Editor;) VideoLAN Client; WINE support for > Picasa (iphoto clone;) Firefox 2, Thunderbird 2, and GAIM. > > A special Live CD or DVD with just multimedia software enabled would > be SOOOOO cool! Fortunately, the excellent contributors in Fedora are making tools that should enable you to build this set yourself. Then you can master the images and share with the rest of the community. josh From nman64 at n-man.com Mon Feb 19 01:02:13 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sun, 18 Feb 2007 19:02:13 -0600 Subject: Fedora Creative Suite Proposal In-Reply-To: <0643B7A3-0B9D-4D46-A81A-58318E756144@verizon.net> References: <0643B7A3-0B9D-4D46-A81A-58318E756144@verizon.net> Message-ID: <200702181902.16883.nman64@n-man.com> On Sunday 18 February 2007, Markus McLaughlin wrote: > What's needed for a Creative Person such as myself in a Multimedia > Fedora Spin... > > The latest OpenOffice 2.1(openoffice.org;) NVU.com, (Web Editor;) > GIMPshop (very good hack of GIMP;) Scribus (newsletter;) Kino (Video > Editor;) Audacity (Sound Editor;) VideoLAN Client; WINE support for > Picasa (iphoto clone;) Firefox 2, Thunderbird 2, and GAIM. > > A special Live CD or DVD with just multimedia software enabled would > be SOOOOO cool! > One of the goals of the changes made for Fedora 7 is to allow users to create customized spins that may contain whatever software they like. Fedora has a firm commitment to Free and Open Source Software. As such, tools like Picasa cannot be included in Fedora. The download provided by Google can be installed and used on Fedora, though I cannot personally recommend it. If you look through some of the other packages available in Fedora, you may be surprised at some of the alternatives that are present. OpenOffice.org 2.2, Scribus, Audacity, Wine, Firefox, Thunderbird and Gaim are already in the Fedora trees. GIMP and a few other similar tools are also included, though nobody has felt it worthwhile to package GIMPshop for inclusion. Nvu also awaits a patient packager, though RPMs are available elsewhere. Kino and VLC make extensive use of patented formats and so are not eligible for inclusion in Fedora, but Fedora-compatible RPMs are available from third parties. http://fedoraproject.org/wiki/ForbiddenItems With the new tools and architecture of Fedora 7, you can gather these packages and produce your own media containing just what you want, not that you couldn't already, it's just easier now. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Mon Feb 19 02:48:17 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 18 Feb 2007 19:48:17 -0700 Subject: Detecting version in a SPEC file Message-ID: <200702181948.22568.lamont@gurulabs.com> All, I'm refactoring a package (perl module) that needs to build on CentOS4/RHEL4 and FC6/RHEL5. This package depends on GnuPG, whose version changed from FC3 -> FC6. The change from gpg 1.2 to gpg 1.4 actually means that the tests (%check) will fail unless I use a different set of test results for the two versions. I would like to test (in a %if %endif block) which version of GnuPG is installed on the system. I could run an "rpm --queryformat" command to get the version, but I was hoping that there is a better way, since rpmbuild already can check versions of installed packages for BuildRequires. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Mon Feb 19 03:11:17 2007 From: roland at redhat.com (Roland McGrath) Date: Sun, 18 Feb 2007 19:11:17 -0800 (PST) Subject: Detecting version in a SPEC file In-Reply-To: Lamont Peterson's message of Sunday, 18 February 2007 19:48:17 -0700 <200702181948.22568.lamont@gurulabs.com> Message-ID: <20070219031117.B4E85180076@magilla.sf.frob.com> Your Buildrequires are your declaration of what is required for the build the spec wants to do. You don't want it to depend on what happens to be around. I think what you want to do is: %define gnupg_version 1.2 %if "%fedora" >= "6" %define gnupg_version 1.4 %endif %if "%rhel" >= "5" %define gnupg_version 1.4 %endif ... BuildRequires: gnupg = %{gnupg_version} ... %check %if "%gnupg_version" = "1.2" this data %else that data %endif From Matt_Domsch at dell.com Mon Feb 19 04:31:21 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Feb 2007 22:31:21 -0600 Subject: Core x86_64 rawhide rebuild in mock status 2007-02-18 Message-ID: <20070218223121.A18485@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for x86_64 Sun Feb 18 21:01:07 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1157 Number failed to build: 61 Number expected to fail due to ExclusiveArch or ExcludeArch: 16 Leaving: 45 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 45 ---------------------------------- alacarte-0.11.3-2.fc7 amanda-2.5.0p2-4 automake16-1.6.3-8 automake17-1.7.9-7 boost-1.33.1-10.fc7 castor-0.9.5-1jpp.7 compat-gcc-32-3.2.3-61 compat-gcc-34-3.4.6-4 expect-5.43.0-8 g-wrap-1.9.6-7.1 gnome-media-2.17.91-1.fc7 gnome-sharp-2.16.0-1.fc6 gnucash-2.0.4-1.fc6 grub-0.97-13 icon-naming-utils-0.8.1-1.fc6 jgroups-2.2.9.2-3jpp.2 kasumi-2.0.1-1.1.fc6 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libgssapi-0.10-1 linux-atm-2.5.0-1.20050118cvs memtest86+-1.70-1.fc7 mikmod-3.1.6-39.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-7.2 openldap-2.3.30-1.1.fc7 perl-5.8.8-12.fc7 ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 readahead-1.3-6.fc6 scim-anthy-1.2.2-1.fc7 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 syslinux-3.36-1.fc7 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 tk-8.4.13-4.fc7 tomcat5-5.5.17-6jpp.2 totem-2.17.91-1.fc7 valgrind-3.2.3-2 velocity-1.4-6jpp.1 w3m-0.5.1-15.fc6 xen-3.0.4-6.fc7 xferstats-2.16-14.1 With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Mon Feb 19 04:31:27 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Feb 2007 22:31:27 -0600 Subject: Core i386 rawhide rebuild in mock status 2007-02-18 Message-ID: <20070218223127.A18504@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for i386 Sun Feb 18 21:03:27 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1158 Number failed to build: 46 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 37 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 37 ---------------------------------- amanda-2.5.0p2-4 automake16-1.6.3-8 automake17-1.7.9-7 castor-0.9.5-1jpp.7 expect-5.43.0-8 g-wrap-1.9.6-7.1 gnome-media-2.17.91-1.fc7 gnome-sharp-2.16.0-1.fc6 gnucash-2.0.4-1.fc6 grub-0.97-13 icon-naming-utils-0.8.1-1.fc6 jgroups-2.2.9.2-3jpp.2 kasumi-2.0.1-1.1.fc6 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libgssapi-0.10-1 linux-atm-2.5.0-1.20050118cvs mikmod-3.1.6-39.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-7.2 openldap-2.3.30-1.1.fc7 perl-5.8.8-12.fc7 ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 readahead-1.3-6.fc6 scim-anthy-1.2.2-1.fc7 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 tk-8.4.13-4.fc7 tomcat5-5.5.17-6jpp.2 totem-2.17.91-1.fc7 velocity-1.4-6jpp.1 w3m-0.5.1-15.fc6 xferstats-2.16-14.1 With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Mon Feb 19 04:31:38 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Feb 2007 22:31:38 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-18 Message-ID: <20070218223138.A18516@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Sun Feb 18 21:10:50 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2641 Number failed to build: 75 Number expected to fail due to ExclusiveArch or ExcludeArch: 19 Leaving: 56 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 56 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de atitvout-0.4-6 andreas.bierfert at lowlatency.de audacity-1.3.2-7.20070106cvs.fc7 gemi at bluewin.ch banshee-0.11.5-1.fc7 caillon at redhat.com boo-0.7.6.2237-12.fc7 paul at all-the-johnsons.co.uk compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com darcs-1.0.8-4.fc7 petersen at redhat.com em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libreadline-java-0.8.0-13.fc6 ifoox at redhat.com mlton-20061107-2.fc7 adam at spicenitz.org nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com perl-Log-Log4perl-1.09-1.fc7 jpo at di.uminho.pt php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.9-7.fc7 jamatos at fc.up.pt python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com python-reportlab-2.0-2.fc7 bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu skencil-0.6.17-12.fc7 gemi at bluewin.ch socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 giallu at gmail.com toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Mon Feb 19 04:32:01 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Feb 2007 22:32:01 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-02-18 Message-ID: <20070218223201.A18534@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Sun Feb 18 21:15:52 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2641 Number failed to build: 49 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 47 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 46 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de banshee-0.11.5-1.fc7 caillon at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com darcs-1.0.8-4.fc7 petersen at redhat.com em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libreadline-java-0.8.0-13.fc6 ifoox at redhat.com nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu skencil-0.6.17-12.fc7 gemi at bluewin.ch socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 giallu at gmail.com toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 jacliburn at bellsouth.net Mon Feb 19 03:30:51 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 18 Feb 2007 21:30:51 -0600 Subject: Fedora power management Message-ID: <20070218213051.388fd6c0@osprey.hogchain.net> I'm trying to hack/test a network driver's ability to suspend, resume, and wake-on-lan (while suspended). This is on a rawhide x86_64 desktop system. Is the Fedora pm-stuff documented anywhere? I can't seem to find anything on the wiki, and the only related manpage is for pm-pmu. FWIW, suspend didn't seem to work, but hibernate did (aside from a bunch of lockdep warnings). As near as I can tell though, my network module is unloaded instead of suspended because I think it gets swept up in the modunload() function of /etc/pm/functions. It'd help if I could find some documentation on Fedora power management, to try and get an understanding of how it's all supposed to work. Any ideas where I can find some docs? Jay From hughsient at gmail.com Mon Feb 19 09:11:10 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Feb 2007 09:11:10 +0000 Subject: Fedora power management In-Reply-To: <20070218213051.388fd6c0@osprey.hogchain.net> References: <20070218213051.388fd6c0@osprey.hogchain.net> Message-ID: <1171876270.4839.3.camel@hughsie-laptop> On Sun, 2007-02-18 at 21:30 -0600, Jay Cliburn wrote: > I'm trying to hack/test a network driver's ability to suspend, resume, > and wake-on-lan (while suspended). This is on a rawhide x86_64 desktop > system. Is the Fedora pm-stuff documented anywhere? I can't seem to > find anything on the wiki, and the only related manpage is for pm-pmu. > > FWIW, suspend didn't seem to work, but hibernate did (aside from a > bunch of lockdep warnings). As near as I can tell though, my network > module is unloaded instead of suspended because I think it gets swept > up in the modunload() function of /etc/pm/functions. > > It'd help if I could find some documentation on Fedora power > management, to try and get an understanding of how it's all supposed > to work. Any ideas where I can find some docs? Well, there's a link to quite an old presentation I wrote here http://people.freedesktop.org/~hughsient/public/gnome-power-manager.pdf which mentions how pm-utils fits into the stack, although the document needs updating with the latest PolicyKit and ConsoleKit coolness. I've also attached the pm-utils README file from CVS which might help. I agree, this stuff needs better documenting - a wiki page might be best, or maybe just manpages for the other tools. Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: README Type: text/x-patch Size: 2357 bytes Desc: not available URL: From gilboad at gmail.com Mon Feb 19 10:17:37 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 19 Feb 2007 12:17:37 +0200 Subject: Smolt: firsboot revisited In-Reply-To: <45D33FD7.4010001@redhat.com> References: <45D33FD7.4010001@redhat.com> Message-ID: <1171880257.673.0.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-14 at 10:59 -0600, Mike McGrath wrote: > So smolt is still setup in firstboot and still is opt in. My question > is do we want to install smolt as part of a default configuration with > F7. My vote is yes. > > -Mike > /+1. - Gilboa From rdieter at math.unl.edu Mon Feb 19 12:44:30 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Feb 2007 06:44:30 -0600 Subject: F7 kde package manifest References: <45D49A89.2030501@math.unl.edu> <45D649D1.7040106@math.unl.edu> <13dbfe4f0702181220x1a192a9bx181023ae1269bbd8@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > Hello, > Well I see no progress since our last IRC meeting, So I made a brief > "easy" list of items which we can do before the next meeting: > http://fedoraproject.org/wiki/ChitleshGoorah/kde Feel free to modify FeatureFedoraKDE and/or make pages under that. > The "Extras extras splits" section entails further extras packages > which I'm proposing to move to the kdeutils-extras package. What do > you think, is it worth ? I can do it myself since, I already split the > recommended apps (from > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE). I suspect we'll have a much better of idea after this weeks' meeting, where Than (and Florian) will (hopefully) attend. -- Rex From rdieter at math.unl.edu Mon Feb 19 12:46:02 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Feb 2007 06:46:02 -0600 Subject: Detecting version in a SPEC file References: <200702181948.22568.lamont@gurulabs.com> <20070219031117.B4E85180076@magilla.sf.frob.com> Message-ID: Roland McGrath wrote: > Your Buildrequires are your declaration of what is required for the build > the spec wants to do. You don't want it to depend on what happens to be > around. > > I think what you want to do is: > > %define gnupg_version 1.2 > %if "%fedora" >= "6" > %define gnupg_version 1.4 > %endif > %if "%rhel" >= "5" > %define gnupg_version 1.4 > %endif Or if you like the shorter, but slightly harder to read: %if 0%{?fedora} >= 6 || 0%{?rhel} >= 5 %define gnupg_version 1.4 %endif -- Rex From jos at xos.nl Mon Feb 19 12:57:03 2007 From: jos at xos.nl (Jos Vos) Date: Mon, 19 Feb 2007 13:57:03 +0100 Subject: Detecting version in a SPEC file In-Reply-To: <20070219031117.B4E85180076@magilla.sf.frob.com>; from roland@redhat.com on Sun, Feb 18, 2007 at 07:11:17PM -0800 References: <200702181948.22568.lamont@gurulabs.com> <20070219031117.B4E85180076@magilla.sf.frob.com> Message-ID: <20070219135703.A2971@xos037.xos.nl> On Sun, Feb 18, 2007 at 07:11:17PM -0800, Roland McGrath wrote: > I think what you want to do is: > > %define gnupg_version 1.2 > %if "%fedora" >= "6" > %define gnupg_version 1.4 > %endif > %if "%rhel" >= "5" > %define gnupg_version 1.4 > %endif I don't know about Fedora, but on RHEL nothing on the system predefines the %rhel macro, that's purely an internal define in the RH build system. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jkeating at redhat.com Mon Feb 19 13:13:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 08:13:16 -0500 Subject: Detecting version in a SPEC file In-Reply-To: <20070219135703.A2971@xos037.xos.nl> References: <200702181948.22568.lamont@gurulabs.com> <20070219031117.B4E85180076@magilla.sf.frob.com> <20070219135703.A2971@xos037.xos.nl> Message-ID: <200702190813.19348.jkeating@redhat.com> On Monday 19 February 2007 07:57, Jos Vos wrote: > I don't know about Fedora, but on RHEL nothing on the system predefines > the %rhel macro, that's purely an internal define in the RH build system. Correct, both Fedora and RHEL (5+)'s buildsystem defines %fedora for fedora and %rhel for RHEL, as part of the definition of %{?dist} to .el5 for RHEL, .fc5 for Fedora Core 5, .fc6 for Fedora Core 6, and .fc7 for Fedora 7. All it requires is a macro file on the system building the packages for you that defines these macros. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Feb 19 13:30:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 19:00:21 +0530 Subject: Archives of Fedora IRC channels Message-ID: <45D9A66D.3060805@fedoraproject.org> Hi If we have to retain public archives of all Fedora IRC channels, what would be the best way to do that? Is there a online services that offer this or should we running bots on all of these channels or something else? There are many instances where contributors are not able to participate in a meeting or discussions. Having public archives would help them go back and look at what was discussed anytime they want. Rahul From bkonrath at redhat.com Mon Feb 19 13:40:11 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Mon, 19 Feb 2007 08:40:11 -0500 Subject: Problem running SWT apps on Sun JVM on Fedora 7? In-Reply-To: <20070218024744.GA13617@redhat.com> References: <883cfe6d0702101825m79d81582i51ea39d8fd45f018@mail.gmail.com> <1171311648.25026.7.camel@localhost.localdomain> <883cfe6d0702121409h48f49745q80906be859d397b0@mail.gmail.com> <20070216192759.GB17022@redhat.com> <883cfe6d0702170813q7ed29ca8y980628b9457aa46e@mail.gmail.com> <20070218024744.GA13617@redhat.com> Message-ID: <1171892412.19663.2.camel@plug> On Sat, 2007-02-17 at 21:47 -0500, Andrew Overholt wrote: > Adding Ben Konrath to thread > > * Michel Salim [2007-02-17 11:14]: > > 2007/2/16, Andrew Overholt : > > >* Michel Salim [2007-02-12 17:09]: > > >> I *did* try running Fedora Eclipse against Sun Java (by mistake; the > > >> path to the JVM got added in front of /usr/bin when I reorganized my > > >> login scripts) and it did produce the same error. > > > > > >Can you file a bug about this? I've done this myself and had no issues. > > >While we can't support running with the proprietary JVMs, i'm interested > > >to see what the issue is. > > > > > Certainly! The reason I posted here first, though, is ... which > > component do I file this against? > > eclipse. Bug components are created by SRPM and libswt3-gtk2 is a > sub-package of the eclipse SRPM. > > Please provide details of how your ran Eclipse and the output of: > > which java > which javac > readlink -f `which java` > readlink -f `which javac` > rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" | egrep \ > "eclipse|swt|^java-1|gcj" > > It for sure doesn't work with eclipse -vm /bin/java ? And > it *does* work with libgcj? > > Ben: can you think of anything I'm missing here? The only thing I have to add is if the problem occurs with an upstream download and a proprietary VM, then it's an upstream problem and you should file a bug in the eclipse.org bugzilla. Please post the bug number if you end up filing it so that we can track it and / or help out if we can. Thanks, Ben From Matt_Domsch at dell.com Mon Feb 19 13:46:32 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 19 Feb 2007 07:46:32 -0600 Subject: Archives of Fedora IRC channels In-Reply-To: <45D9A66D.3060805@fedoraproject.org> References: <45D9A66D.3060805@fedoraproject.org> Message-ID: <20070219134632.GA5609@lists.us.dell.com> On Mon, Feb 19, 2007 at 07:00:21PM +0530, Rahul Sundaram wrote: > Hi > > If we have to retain public archives of all Fedora IRC channels have to, or would like to? > what would be the best way to do that? Is there a online services > that offer this or should we running bots on all of these channels > or something else? There are many instances where contributors are > not able to participate in a meeting or discussions. Having public > archives would help them go back and look at what was discussed > anytime they want. I run a boringly simple eggdrop (mdomschbot) in a few channels, which I use to generate the FPB meeting minutes. I don't believe there's a service on FreeNode (ala ChanServ) that offers this, which is why I set up my own bot. Are you thinking such a bot could be run by Infrastructure or somesuch? 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 sundaram at fedoraproject.org Mon Feb 19 14:08:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 19:38:36 +0530 Subject: Archives of Fedora IRC channels In-Reply-To: <20070219134632.GA5609@lists.us.dell.com> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> Message-ID: <45D9AF64.3000203@fedoraproject.org> Matt Domsch wrote: > On Mon, Feb 19, 2007 at 07:00:21PM +0530, Rahul Sundaram wrote: >> Hi >> >> If we have to retain public archives of all Fedora IRC channels > > have to, or would like to? Like to I guess. > >> what would be the best way to do that? Is there a online services >> that offer this or should we running bots on all of these channels >> or something else? There are many instances where contributors are >> not able to participate in a meeting or discussions. Having public >> archives would help them go back and look at what was discussed >> anytime they want. > > I run a boringly simple eggdrop (mdomschbot) in a few channels, which > I use to generate the FPB meeting minutes. I don't believe there's a > service on FreeNode (ala ChanServ) that offers this, which is why I > set up my own bot. Are you thinking such a bot could be run by > Infrastructure or somesuch? Yes. If we are running such a bot across all channels, it could probably do other useful things too. For example, there is a cluebot in #fedorabot channel which is very useful for bug triaging. Rahul From jwboyer at jdub.homelinux.org Mon Feb 19 14:09:31 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Feb 2007 08:09:31 -0600 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702161608.14572.jkeating@redhat.com> References: <200702161608.14572.jkeating@redhat.com> Message-ID: <1171894171.24204.21.camel@zod.rchland.ibm.com> On Fri, 2007-02-16 at 16:08 -0500, Jesse Keating wrote: > One of the big Features of Fedora 7 is a merged core and extras. In order to > accomplish this, we need some improvements to the buildsystem currently used > by Fedora Extras. We need these improvements done or mostly done by the > Feature Freeze of Fedora 7, which was originally set to be the 20th of > February, 4 days from now. It is very clear that these changes will not be > ready by then. > > To accomplish these changes (and others) in time for the Feature Freeze, we > have added another month to the schedule, introducing a Test 4, and moving > the Feature Freeze as well as String Freeze up to Test 3 freeze, March 19. > > This moves the general availability date from April 26 to May 24. > > For further discussion on this topic, please use the fedora-maintainers list, > which I am attempting to set reply-to. > > For reference: http://fedoraproject.org/wiki/Releases/7/Schedule Just a reminder for everyone, this means that FC-5 will be maintained for a slightly longer period of time. The lifetime of releases is N+2 plus one month. So FC-5 will be maintained until one month after F7 is release. Happy Hacking. josh From jwboyer at jdub.homelinux.org Mon Feb 19 14:11:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Feb 2007 08:11:14 -0600 Subject: Archives of Fedora IRC channels In-Reply-To: <45D9AF64.3000203@fedoraproject.org> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> Message-ID: <1171894274.24204.23.camel@zod.rchland.ibm.com> On Mon, 2007-02-19 at 19:38 +0530, Rahul Sundaram wrote: > Matt Domsch wrote: > > On Mon, Feb 19, 2007 at 07:00:21PM +0530, Rahul Sundaram wrote: > >> Hi > >> > >> If we have to retain public archives of all Fedora IRC channels > > > > have to, or would like to? > > Like to I guess. > > > > >> what would be the best way to do that? Is there a online services > >> that offer this or should we running bots on all of these channels > >> or something else? There are many instances where contributors are > >> not able to participate in a meeting or discussions. Having public > >> archives would help them go back and look at what was discussed > >> anytime they want. > > > > I run a boringly simple eggdrop (mdomschbot) in a few channels, which > > I use to generate the FPB meeting minutes. I don't believe there's a > > service on FreeNode (ala ChanServ) that offers this, which is why I > > set up my own bot. Are you thinking such a bot could be run by > > Infrastructure or somesuch? > > Yes. If we are running such a bot across all channels, it could probably > do other useful things too. For example, there is a cluebot in > #fedorabot channel which is very useful for bug triaging. Please don't run cluebot in -devel. Or, more specifically, don't have it do bugzilla lookups based on keywords. It gets very annoying. Having it done on explicit request would be ok I suppose. josh From jacliburn at bellsouth.net Mon Feb 19 13:11:23 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Mon, 19 Feb 2007 07:11:23 -0600 Subject: Fedora power management In-Reply-To: <1171876270.4839.3.camel@hughsie-laptop> References: <20070218213051.388fd6c0@osprey.hogchain.net> <1171876270.4839.3.camel@hughsie-laptop> Message-ID: <20070219071123.491bb0ac@osprey.hogchain.net> On Mon, 19 Feb 2007 09:11:10 +0000 Richard Hughes wrote: > Well, there's a link to quite an old presentation I wrote > I've also attached the pm-utils README file from CVS which might help. Thanks a lot for this info Richard. I really appreciate it. So to make my nic driver suspend (instead of being removed with "modprobe -r"), I need only add the module name to the SUSPEND_MODULES line of /etc/pm/config? Like this? (my driver name is atl1) SUSPEND_MODULES="button atl1" HIBERNATE_RESUME_POST_VIDEO="no" DISABLE_HIBERNATE="no" DISABLE_SUSPEND="no" From katzj at redhat.com Mon Feb 19 14:14:16 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Feb 2007 09:14:16 -0500 Subject: Fedora power management In-Reply-To: <20070219071123.491bb0ac@osprey.hogchain.net> References: <20070218213051.388fd6c0@osprey.hogchain.net> <1171876270.4839.3.camel@hughsie-laptop> <20070219071123.491bb0ac@osprey.hogchain.net> Message-ID: <1171894456.3005.2.camel@aglarond.local> On Mon, 2007-02-19 at 07:11 -0600, Jay Cliburn wrote: > On Mon, 19 Feb 2007 09:11:10 +0000 > Richard Hughes wrote: > > Well, there's a link to quite an old presentation I wrote > > > I've also attached the pm-utils README file from CVS which might help. > > Thanks a lot for this info Richard. I really appreciate it. > > So to make my nic driver suspend (instead of being removed with > "modprobe -r"), I need only add the module name to the SUSPEND_MODULES > line of /etc/pm/config? Like this? (my driver name is atl1) The default is for the driver to be suspended normally; SUSPEND_MODULES is to list (broken) modules that have to be removed and reinserted around the suspend process. Jeremy From sundaram at fedoraproject.org Mon Feb 19 14:21:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 19:51:51 +0530 Subject: Archives of Fedora IRC channels In-Reply-To: <1171894274.24204.23.camel@zod.rchland.ibm.com> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <1171894274.24204.23.camel@zod.rchland.ibm.com> Message-ID: <45D9B27F.7010802@fedoraproject.org> Josh Boyer wrote: > Please don't run cluebot in -devel. Or, more specifically, don't have > it do bugzilla lookups based on keywords. It gets very annoying. > Having it done on explicit request would be ok I suppose. I dont maintain cluebot. Max Kanat-Alexander from http://www.fedorafaq.org/ does. That was just an example of where bots could serve other uses besides logging discussions. Rahul From jlb17 at duke.edu Mon Feb 19 14:24:13 2007 From: jlb17 at duke.edu (Joshua Baker-LePain) Date: Mon, 19 Feb 2007 09:24:13 -0500 (EST) Subject: Fedora power management In-Reply-To: <1171894456.3005.2.camel@aglarond.local> References: <20070218213051.388fd6c0@osprey.hogchain.net> <1171876270.4839.3.camel@hughsie-laptop> <20070219071123.491bb0ac@osprey.hogchain.net> <1171894456.3005.2.camel@aglarond.local> Message-ID: On Mon, 19 Feb 2007 at 9:14am, Jeremy Katz wrote > The default is for the driver to be suspended normally; SUSPEND_MODULES > is to list (broken) modules that have to be removed and reinserted > around the suspend process. Is it considered a (fixable, bugzillable) bug if normal suspending works but has undesirable effects? Example -- on my Thinkpad Z61t, suspend and wake-up worked out of the box with FC6, but the power drain was impressive (I have the figures at home, but it was >50% battery of capacity overnight). Some experimenting demonstarted that removing the USB modules before going to sleep dropped the sleeping power consumption considerably, so I put those in SUSPEND_MODULES. I figured this was model specific so I didn't bugzilla it. Should I? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From jacliburn at bellsouth.net Mon Feb 19 14:52:50 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Mon, 19 Feb 2007 08:52:50 -0600 Subject: Fedora power management In-Reply-To: <1171894456.3005.2.camel@aglarond.local> References: <20070218213051.388fd6c0@osprey.hogchain.net> <1171876270.4839.3.camel@hughsie-laptop> <20070219071123.491bb0ac@osprey.hogchain.net> <1171894456.3005.2.camel@aglarond.local> Message-ID: <20070219085250.28160775@osprey.hogchain.net> On Mon, 19 Feb 2007 09:14:16 -0500 Jeremy Katz wrote: > The default is for the driver to be suspended normally; > SUSPEND_MODULES is to list (broken) modules that have to be removed > and reinserted around the suspend process. Thanks for the clarification. I'm getting fairly spectacular failures whenever I execute pm-suspend. The failure mode is variable. In this particular example, I end up with slab corruption. I presume this should be passed upstream? Feb 19 08:40:01 osprey ntpd[2061]: ntpd exiting on signal 15 Feb 19 08:40:05 osprey restorecond: Read error (Interrupted system call) Feb 19 08:40:05 osprey kernel: Stopping tasks ... done. Feb 19 08:40:05 osprey kernel: Suspending console(s) Feb 19 08:40:05 osprey kernel: pnp: Device 00:0c disabled. Feb 19 08:40:05 osprey kernel: pnp: Device 00:07 disabled. Feb 19 08:40:05 osprey kernel: ACPI: PCI interrupt for device 0000:02:00.0 disabled Feb 19 08:40:05 osprey kernel: ACPI: PCI interrupt for device 0000:00:1f.2 disabled Feb 19 08:40:05 osprey kernel: ACPI: PCI interrupt for device 0000:00:1f.1 disabled Feb 19 08:40:05 osprey kernel: pci_set_power_state(): 0000:00:1f.1: state=3, current state=5 Feb 19 08:40:05 osprey kernel: ACPI: PCI interrupt for device 0000:00:1d.7 disabled Feb 19 08:40:05 osprey kernel: ACPI: PCI interrupt for device 0000:00:1d.3 disabled Feb 19 08:40:05 osprey kernel: ACPI: PCI interrupt for device 0000:00:1d.2 disabled Feb 19 08:40:05 osprey kernel: ACPI: PCI interrupt for device 0000:00:1d.1 disabled Feb 19 08:40:09 osprey kernel: ACPI: PCI interrupt for device 0000:00:1d.0 disabled Feb 19 08:40:09 osprey kernel: ACPI: PCI interrupt for device 0000:00:1b.0 disabled Feb 19 08:40:09 osprey kernel: Disabling non-boot CPUs ... Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: ======================================================= Feb 19 08:40:09 osprey kernel: [ INFO: possible circular locking dependency detected ] Feb 19 08:40:09 osprey kernel: 2.6.20-1.2932.fc7 #1 Feb 19 08:40:09 osprey kernel: ------------------------------------------------------- Feb 19 08:40:09 osprey kernel: pm-suspend/2840 is trying to acquire lock: Feb 19 08:40:09 osprey kernel: (cpu_bitmask_lock){--..}, at: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: but task is already holding lock: Feb 19 08:40:09 osprey kernel: (workqueue_mutex){--..}, at: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: which lock already depends on the new lock. Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: the existing dependency chain (in reverse order) is: Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: -> #3 (workqueue_mutex){--..}: Feb 19 08:40:09 osprey kernel: [] __lock_acquire+0xa1c/0xbc4 Feb 19 08:40:09 osprey kernel: [] lock_acquire+0x4c/0x65 Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] __mutex_lock_slowpath+0xff/0x299 Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] __create_workqueue+0x78/0x160 Feb 19 08:40:09 osprey kernel: [] cpufreq_governor_dbs+0xb7/0x37b [cpufreq_ondemand] Feb 19 08:40:09 osprey kernel: [] cpufreq_governor_userspace+0x207/0x214 Feb 19 08:40:09 osprey kernel: [] __cpufreq_governor+0x71/0xae Feb 19 08:40:09 osprey kernel: [] __cpufreq_set_policy+0x18c/0x208 Feb 19 08:40:09 osprey kernel: [] store_scaling_governor+0x18b/0x1eb Feb 19 08:40:09 osprey kernel: [] handle_update+0x0/0x36 Feb 19 08:40:09 osprey kernel: [] store+0x4c/0x66 Feb 19 08:40:09 osprey kernel: [] sysfs_write_file+0xec/0x123 Feb 19 08:40:09 osprey kernel: [] vfs_write+0xcf/0x178 Feb 19 08:40:09 osprey kernel: [] sys_write+0x47/0x70 Feb 19 08:40:09 osprey kernel: [] system_call+0x7e/0x83 Feb 19 08:40:09 osprey kernel: [] 0xffffffffffffffff Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: -> #2 (dbs_mutex){--..}: Feb 19 08:40:09 osprey kernel: [] __lock_acquire+0xa1c/0xbc4 Feb 19 08:40:09 osprey kernel: [] lock_acquire+0x4c/0x65 Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] __mutex_lock_slowpath+0xff/0x299 Feb 19 08:40:09 osprey kernel: [] trace_hardirqs_on+0x136/0x15a Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] cpufreq_governor_dbs+0x95/0x37b [cpufreq_ondemand] Feb 19 08:40:09 osprey kernel: [] cpufreq_governor_userspace+0x207/0x214 Feb 19 08:40:09 osprey kernel: [] __cpufreq_governor+0x71/0xae Feb 19 08:40:09 osprey kernel: [] __cpufreq_set_policy+0x18c/0x208 Feb 19 08:40:09 osprey kernel: [] store_scaling_governor+0x18b/0x1eb Feb 19 08:40:09 osprey kernel: [] handle_update+0x0/0x36 Feb 19 08:40:09 osprey kernel: [] store+0x4c/0x66 Feb 19 08:40:09 osprey kernel: [] sysfs_write_file+0xec/0x123 Feb 19 08:40:09 osprey kernel: [] vfs_write+0xcf/0x178 Feb 19 08:40:09 osprey kernel: [] sys_write+0x47/0x70 Feb 19 08:40:09 osprey kernel: [] system_call+0x7e/0x83 Feb 19 08:40:09 osprey kernel: [] 0xffffffffffffffff Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: -> #1 (&policy->lock){--..}: Feb 19 08:40:09 osprey kernel: [] __lock_acquire+0xa1c/0xbc4 Feb 19 08:40:09 osprey kernel: [] lock_acquire+0x4c/0x65 Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] __mutex_lock_slowpath+0xff/0x299 Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] cpufreq_set_policy+0x37/0xa2 Feb 19 08:40:09 osprey kernel: [] cpufreq_add_dev+0x3ea/0x4f4 Feb 19 08:40:09 osprey kernel: [] handle_update+0x0/0x36 Feb 19 08:40:09 osprey kernel: [] _spin_unlock_irqrestore+0x3f/0x47 Feb 19 08:40:09 osprey kernel: [] sysdev_driver_register+0x7d/0xd1 Feb 19 08:40:09 osprey kernel: [] cpufreq_register_driver+0xc2/0x19e Feb 19 08:40:09 osprey kernel: [] centrino_init+0xbb/0xc4 Feb 19 08:40:09 osprey kernel: [] init+0x1e7/0x3ae Feb 19 08:40:09 osprey kernel: [] trace_hardirqs_on+0x136/0x15a Feb 19 08:40:09 osprey kernel: [] child_rip+0xa/0x12 Feb 19 08:40:09 osprey kernel: [] _spin_unlock_irq+0x2b/0x31 Feb 19 08:40:09 osprey kernel: [] restore_args+0x0/0x30 Feb 19 08:40:09 osprey kernel: [] init+0x0/0x3ae Feb 19 08:40:09 osprey kernel: [] child_rip+0x0/0x12 Feb 19 08:40:09 osprey kernel: [] 0xffffffffffffffff Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: -> #0 (cpu_bitmask_lock){--..}: Feb 19 08:40:09 osprey kernel: [] print_circular_bug_entry+0x48/0x4f Feb 19 08:40:09 osprey kernel: [] __lock_acquire+0x916/0xbc4 Feb 19 08:40:09 osprey kernel: [] lock_acquire+0x4c/0x65 Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] __mutex_lock_slowpath+0xff/0x299 Feb 19 08:40:09 osprey kernel: [] trace_hardirqs_on+0x136/0x15a Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] lock_cpu_hotplug+0x7a/0x86 Feb 19 08:40:09 osprey kernel: [] cpufreq_driver_target+0x37/0x75 Feb 19 08:40:09 osprey kernel: [] cpufreq_cpu_callback+0x52/0x63 Feb 19 08:40:09 osprey kernel: [] notifier_call_chain+0x29/0x3e Feb 19 08:40:09 osprey kernel: [] raw_notifier_call_chain+0x9/0xb Feb 19 08:40:09 osprey kernel: [] _cpu_down+0x58/0x21e Feb 19 08:40:09 osprey kernel: [] disable_nonboot_cpus+0x8d/0x11c Feb 19 08:40:09 osprey kernel: [] enter_state+0x11f/0x1b0 Feb 19 08:40:09 osprey kernel: [] state_store+0x68/0x86 Feb 19 08:40:09 osprey kernel: [] subsys_attr_store+0x24/0x26 Feb 19 08:40:09 osprey kernel: [] sysfs_write_file+0xec/0x123 Feb 19 08:40:09 osprey kernel: [] vfs_write+0xcf/0x178 Feb 19 08:40:09 osprey kernel: [] sys_write+0x47/0x70 Feb 19 08:40:09 osprey kernel: [] tracesys+0xdc/0xe1 Feb 19 08:40:09 osprey kernel: [] 0xffffffffffffffff Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: other info that might help us debug this: Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: 4 locks held by pm-suspend/2840: Feb 19 08:40:09 osprey kernel: #0: (pm_mutex){--..}, at: [] enter_state+0x44/0x1b0 Feb 19 08:40:09 osprey kernel: #1: (cpu_add_remove_lock){--..}, at: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: #2: (cache_chain_mutex){--..}, at: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: #3: (workqueue_mutex){--..}, at: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: stack backtrace: Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: Call Trace: Feb 19 08:40:09 osprey kernel: [] print_circular_bug_tail+0x70/0x7b Feb 19 08:40:09 osprey kernel: [] print_circular_bug_entry+0x48/0x4f Feb 19 08:40:09 osprey kernel: [] __lock_acquire+0x916/0xbc4 Feb 19 08:40:09 osprey kernel: [] lock_acquire+0x4c/0x65 Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] __mutex_lock_slowpath+0xff/0x299 Feb 19 08:40:09 osprey kernel: [] trace_hardirqs_on+0x136/0x15a Feb 19 08:40:09 osprey kernel: [] mutex_lock+0x2a/0x2e Feb 19 08:40:09 osprey kernel: [] lock_cpu_hotplug+0x7a/0x86 Feb 19 08:40:09 osprey kernel: [] cpufreq_driver_target+0x37/0x75 Feb 19 08:40:09 osprey kernel: [] cpufreq_cpu_callback+0x52/0x63 Feb 19 08:40:09 osprey kernel: [] notifier_call_chain+0x29/0x3e Feb 19 08:40:09 osprey kernel: [] raw_notifier_call_chain+0x9/0xb Feb 19 08:40:09 osprey kernel: [] _cpu_down+0x58/0x21e Feb 19 08:40:09 osprey kernel: [] disable_nonboot_cpus+0x8d/0x11c Feb 19 08:40:09 osprey kernel: [] enter_state+0x11f/0x1b0 Feb 19 08:40:09 osprey kernel: [] state_store+0x68/0x86 Feb 19 08:40:09 osprey kernel: [] subsys_attr_store+0x24/0x26 Feb 19 08:40:09 osprey kernel: [] sysfs_write_file+0xec/0x123 Feb 19 08:40:09 osprey kernel: [] vfs_write+0xcf/0x178 Feb 19 08:40:09 osprey kernel: [] sys_write+0x47/0x70 Feb 19 08:40:09 osprey kernel: [] tracesys+0xdc/0xe1 Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: Breaking affinity for irq 14 Feb 19 08:40:09 osprey kernel: Breaking affinity for irq 20 Feb 19 08:40:09 osprey kernel: Breaking affinity for irq 23 Feb 19 08:40:09 osprey kernel: Breaking affinity for irq 2301 Feb 19 08:40:09 osprey kernel: CPU 1 is now offline Feb 19 08:40:09 osprey kernel: lockdep: not fixing up alternatives. Feb 19 08:40:09 osprey kernel: CPU1 is down Feb 19 08:40:09 osprey kernel: Enabling non-boot CPUs ... Feb 19 08:40:09 osprey kernel: lockdep: not fixing up alternatives. Feb 19 08:40:09 osprey kernel: Booting processor 1/2 APIC 0x1 Feb 19 08:40:09 osprey kernel: Initializing CPU#1 Feb 19 08:40:09 osprey kernel: Calibrating delay using timer specific routine.. 4265.91 BogoMIPS (lpj=2132957) Feb 19 08:40:09 osprey kernel: CPU: L1 I cache: 32K, L1 D cache: 32K Feb 19 08:40:09 osprey kernel: CPU: L2 cache: 2048K Feb 19 08:40:09 osprey kernel: CPU 1/1 -> Node 0 Feb 19 08:40:09 osprey kernel: CPU: Physical Processor ID: 0 Feb 19 08:40:09 osprey kernel: CPU: Processor Core ID: 1 Feb 19 08:40:09 osprey kernel: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz stepping 06 Feb 19 08:40:09 osprey kernel: speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPI config is deprecated. Feb 19 08:40:09 osprey kernel: Use X86_ACPI_CPUFREQ (acpi-cpufreq) instead. Feb 19 08:40:09 osprey kernel: CPU1 is up Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 19 (level, low) -> IRQ 19 Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, low) -> IRQ 20 Feb 19 08:40:09 osprey kernel: usb usb1: root hub lost power or was reset Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 17 Feb 19 08:40:09 osprey kernel: usb usb2: root hub lost power or was reset Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18 Feb 19 08:40:09 osprey kernel: usb usb3: root hub lost power or was reset Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 19 Feb 19 08:40:09 osprey kernel: usb usb4: root hub lost power or was reset Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, low) -> IRQ 20 Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 22 (level, low) -> IRQ 22 Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 23 (level, low) -> IRQ 23 Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 23 (level, low) -> IRQ 23 Feb 19 08:40:09 osprey kernel: ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17 Feb 19 08:40:09 osprey kernel: atl1: eth0 link is up 100 Mbps full duplex Feb 19 08:40:09 osprey kernel: pnp: Device 00:07 activated. Feb 19 08:40:09 osprey kernel: pnp: Failed to activate device 00:0a. Feb 19 08:40:09 osprey kernel: pnp: Device 00:0c activated. Feb 19 08:40:09 osprey kernel: ttyS0: LSR safety check engaged! Feb 19 08:40:09 osprey kernel: ATA: abnormal status 0x7F on port 0x0000000000010177 Feb 19 08:40:09 osprey kernel: ATA: abnormal status 0x7F on port 0x000000000001b007 Feb 19 08:40:09 osprey kernel: usbdev1.3_ep00: PM: resume from 0, parent 1-1 still 2 Feb 19 08:40:09 osprey kernel: usbhid 1-1:1.0: PM: resume from 2, parent 1-1 still 2 Feb 19 08:40:09 osprey kernel: usbdev1.3_ep81: PM: resume from 0, parent 1-1:1.0 still 2 Feb 19 08:40:09 osprey kernel: usbdev1.3: PM: resume from 0, parent 1-1 still 2 Feb 19 08:40:09 osprey kernel: Restarting tasks ... <6>usb 1-1: USB disconnect, address 3 Feb 19 08:40:09 osprey kernel: done. Feb 19 08:40:09 osprey kernel: ttyS0: LSR safety check engaged! Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 1 Feb 19 08:40:09 osprey kernel: input: Power Button (FF) as /class/input/input7 Feb 19 08:40:09 osprey kernel: ACPI: Power Button (FF) [PWRF] Feb 19 08:40:09 osprey kernel: input: Power Button (CM) as /class/input/input8 Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 2 Feb 19 08:40:09 osprey kernel: ACPI: Power Button (CM) [PWRB] Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 3 Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 4 Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 5 Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 6 Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 7 Feb 19 08:40:09 osprey kernel: hub 5-0:1.0: over-current change on port 8 Feb 19 08:40:09 osprey kernel: ata1.00: configured for UDMA/33 Feb 19 08:40:09 osprey kernel: usb 1-1: new low speed USB device using uhci_hcd and address 4 Feb 19 08:40:09 osprey kernel: usb 1-1: configuration #1 chosen from 1 choice Feb 19 08:40:09 osprey kernel: input: HID 1241:1177 as /class/input/input9 Feb 19 08:40:09 osprey kernel: input: USB HID v1.00 Mouse [HID 1241:1177] on usb-0000:00:1d.0-1 Feb 19 08:40:09 osprey kernel: ata3.00: configured for UDMA/133 Feb 19 08:40:09 osprey kernel: SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) Feb 19 08:40:09 osprey kernel: sda: Write Protect is off Feb 19 08:40:09 osprey kernel: SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Feb 19 08:40:09 osprey kernel: vbetool[3100]: segfault at 000000000048d810 rip 0000000000425e46 rsp 00007ffff8db90e0 error 4 Feb 19 08:40:09 osprey kernel: Slab corruption: (Not tainted) start=ffff810037c33d68, len=512 Feb 19 08:40:09 osprey kernel: Redzone: 0x5a2cf071/0x5a2cf071. Feb 19 08:40:09 osprey kernel: Last user: [](skb_release_data+0x95/0x9a) Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: Call Trace: Feb 19 08:40:09 osprey kernel: [] check_poison_obj+0x7f/0x1f9 Feb 19 08:40:09 osprey kernel: [] load_elf_binary+0xcfb/0x18c1 Feb 19 08:40:09 osprey kernel: [] load_elf_binary+0xcfb/0x18c1 Feb 19 08:40:09 osprey kernel: [] cache_alloc_debugcheck_after+0x35/0x1db Feb 19 08:40:09 osprey kernel: [] up_write+0x26/0x2a Feb 19 08:40:09 osprey kernel: [] __kmalloc+0x147/0x157 Feb 19 08:40:09 osprey kernel: [] load_elf_binary+0xcfb/0x18c1 Feb 19 08:40:09 osprey kernel: [] load_script+0x0/0x1c4 Feb 19 08:40:09 osprey kernel: [] load_elf_binary+0x0/0x18c1 Feb 19 08:40:09 osprey kernel: [] load_elf_binary+0x0/0x18c1 Feb 19 08:40:09 osprey kernel: [] search_binary_handler+0xcc/0x273 Feb 19 08:40:09 osprey kernel: [] load_script+0x0/0x1c4 Feb 19 08:40:09 osprey kernel: [] load_script+0x1af/0x1c4 Feb 19 08:40:09 osprey kernel: [] load_elf_binary+0x0/0x18c1 Feb 19 08:40:09 osprey kernel: [] search_binary_handler+0xcc/0x273 Feb 19 08:40:09 osprey kernel: [] do_execve+0x1a4/0x261 Feb 19 08:40:09 osprey kernel: [] sys_execve+0x36/0x4d Feb 19 08:40:09 osprey kernel: [] stub_execve+0x67/0xb0 Feb 19 08:40:09 osprey kernel: Feb 19 08:40:09 osprey kernel: 090: 6b 6b 6b 6b 6b 6b 6b 6b 5a 5a 5a 5a 5a 5a 5a 5a Feb 19 08:40:09 osprey kernel: 0a0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a Feb 19 08:40:09 osprey kernel: 0b0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a Feb 19 08:40:09 osprey kernel: 0c0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a Feb 19 08:40:10 osprey kernel: 0d0: 5a 5a 5a 5a 5a 5a 5a 5a 6b 6b 6b 6b 6b 6b 6b 6b Feb 19 08:40:10 osprey kernel: Prev obj: start=ffff810037c33b50, len=512 Feb 19 08:40:10 osprey kernel: Redzone: 0x170fc2a5/0x170fc2a5. Feb 19 08:40:10 osprey kernel: Last user: [](__kmalloc_node+0x25/0x2a) Feb 19 08:40:10 osprey kernel: 000: 00 00 00 00 20 00 00 00 10 00 00 00 00 00 00 00 Feb 19 08:40:10 osprey kernel: 010: 01 00 00 00 ad 4e ad de ff ff ff ff 5a 5a 5a 5a Feb 19 08:40:13 osprey kernel: Slab corruption: (Not tainted) start=ffff81001e565000, len=4096 Feb 19 08:40:13 osprey kernel: Feb 19 08:40:13 osprey kernel: Call Trace: Feb 19 08:40:13 osprey kernel: [] check_poison_obj+0x7f/0x1f9 Feb 19 08:40:13 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:13 osprey kernel: [] cache_alloc_debugcheck_after+0x35/0x1db Feb 19 08:40:13 osprey kernel: [] __alloc_skb+0x41/0x144 Feb 19 08:40:13 osprey kernel: [] kmem_cache_alloc_node+0x129/0x136 Feb 19 08:40:13 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:13 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:13 osprey kernel: [] __alloc_skb+0x6d/0x144 Feb 19 08:40:13 osprey kernel: [] sock_alloc_send_skb+0x80/0x1e1 Feb 19 08:40:13 osprey kernel: [] unix_stream_sendmsg+0x172/0x350 Feb 19 08:40:13 osprey kernel: [] sock_aio_write+0x127/0x13f Feb 19 08:40:13 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:13 osprey kernel: [] sock_aio_write+0x0/0x13f Feb 19 08:40:13 osprey kernel: [] do_sync_readv_writev+0xe0/0x128 Feb 19 08:40:13 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:13 osprey kernel: [] file_has_perm+0xa7/0xb6 Feb 19 08:40:13 osprey kernel: [] autoremove_wake_function+0x0/0x38 Feb 19 08:40:13 osprey kernel: [] do_readv_writev+0xe1/0x1bc Feb 19 08:40:13 osprey kernel: [] audit_syscall_entry+0x148/0x17e Feb 19 08:40:13 osprey kernel: [] vfs_writev+0x3e/0x49 Feb 19 08:40:13 osprey kernel: [] sys_writev+0x47/0x94 Feb 19 08:40:13 osprey kernel: [] tracesys+0xdc/0xe1 Feb 19 08:40:13 osprey kernel: Feb 19 08:40:13 osprey kernel: 2c0: 41 4c 49 44 00 00 00 00 17 00 00 00 52 4f 4c 45 Feb 19 08:40:13 osprey kernel: 2d0: 5f 41 43 43 45 4c 45 52 41 54 4f 52 5f 4c 41 42 Feb 19 08:40:13 osprey kernel: 2e0: 45 4c 00 00 0b 00 00 00 52 4f 4c 45 5f 41 4c 45 Feb 19 08:40:13 osprey kernel: 2f0: 52 54 00 00 0f 00 00 00 52 4f 4c 45 5f 41 4e 49 Feb 19 08:40:19 osprey kernel: ttyS0: LSR safety check engaged! Feb 19 08:40:26 osprey ntpd[3145]: ntpd 4.2.4 at 1.1437 Mon Jan 29 13:39:14 UTC 2007 (1) Feb 19 08:40:26 osprey ntpd[3146]: precision = 1.000 usec Feb 19 08:40:26 osprey ntpd[3146]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Feb 19 08:40:26 osprey ntpd[3146]: Listening on interface #1 wildcard, ::#123 Disabled Feb 19 08:40:26 osprey ntpd[3146]: Listening on interface #2 lo, ::1#123 Enabled Feb 19 08:40:26 osprey ntpd[3146]: Listening on interface #3 eth0, fe80::218:f3ff:fe74:5924#123 Enabled Feb 19 08:40:26 osprey ntpd[3146]: Listening on interface #4 lo, 127.0.0.1#123 Enabled Feb 19 08:40:26 osprey ntpd[3146]: Listening on interface #5 eth0, 192.168.1.3#123 Enabled Feb 19 08:40:26 osprey ntpd[3146]: kernel time sync status 0040 Feb 19 08:40:28 osprey ntpd[3146]: frequency initialized -0.870 PPM from /var/lib/ntp/drift Feb 19 08:40:29 osprey kernel: ttyS0: LSR safety check engaged! Feb 19 08:40:31 osprey kernel: Slab corruption: (Not tainted) start=ffff810037c140d8, len=512 Feb 19 08:40:31 osprey kernel: Redzone: 0x5a2cf071/0x170fc2a5. Feb 19 08:40:31 osprey kernel: Last user: [](__kmalloc_node_track_caller+0x25/0x2a) Feb 19 08:40:31 osprey kernel: Feb 19 08:40:31 osprey kernel: Call Trace: Feb 19 08:40:31 osprey kernel: [] check_poison_obj+0x7f/0x1f9 Feb 19 08:40:31 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:31 osprey kernel: [] cache_alloc_debugcheck_after+0x35/0x1db Feb 19 08:40:31 osprey kernel: [] __alloc_skb+0x41/0x144 Feb 19 08:40:31 osprey kernel: [] kmem_cache_alloc_node+0x129/0x136 Feb 19 08:40:31 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:31 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:31 osprey kernel: [] __alloc_skb+0x6d/0x144 Feb 19 08:40:31 osprey kernel: [] sock_alloc_send_skb+0x80/0x1e1 Feb 19 08:40:31 osprey kernel: [] unix_stream_sendmsg+0x172/0x350 Feb 19 08:40:31 osprey kernel: [] sock_aio_write+0x127/0x13f Feb 19 08:40:31 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:31 osprey kernel: [] __sigqueue_free+0x3b/0x3f Feb 19 08:40:31 osprey kernel: [] sock_aio_write+0x0/0x13f Feb 19 08:40:31 osprey kernel: [] do_sync_readv_writev+0xe0/0x128 Feb 19 08:40:31 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:31 osprey kernel: [] file_has_perm+0xa7/0xb6 Feb 19 08:40:31 osprey kernel: [] autoremove_wake_function+0x0/0x38 Feb 19 08:40:31 osprey kernel: [] do_readv_writev+0xe1/0x1bc Feb 19 08:40:31 osprey kernel: [] sys_rt_sigreturn+0x28f/0x357 Feb 19 08:40:31 osprey kernel: [] audit_syscall_entry+0x148/0x17e Feb 19 08:40:31 osprey kernel: [] vfs_writev+0x3e/0x49 Feb 19 08:40:31 osprey kernel: [] sys_writev+0x47/0x94 Feb 19 08:40:31 osprey kernel: [] tracesys+0xdc/0xe1 Feb 19 08:40:31 osprey kernel: Feb 19 08:40:31 osprey kernel: 1e0: 6b 6b 6b 6b 6b 6b 6b 6b 5a 5a 5a 5a 5a 5a 5a 5a Feb 19 08:40:31 osprey kernel: 1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a a5 Feb 19 08:40:31 osprey kernel: Next obj: start=ffff810037c142f0, len=512 Feb 19 08:40:31 osprey kernel: Redzone: 0x170fc2a5/0x5a2cf071. Feb 19 08:40:31 osprey kernel: Last user: [](skb_release_data+0x95/0x9a) Feb 19 08:40:31 osprey kernel: 000: 3c 34 3e 46 65 62 20 31 39 20 30 38 3a 34 30 3a Feb 19 08:40:31 osprey kernel: 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Feb 19 08:40:31 osprey kernel: slab error in cache_alloc_debugcheck_after(): cache `size-512': double free, or memory outside object was overwritten Feb 19 08:40:31 osprey kernel: Feb 19 08:40:31 osprey kernel: Call Trace: Feb 19 08:40:31 osprey kernel: [] __slab_error+0x24/0x26 Feb 19 08:40:31 osprey kernel: [] cache_alloc_debugcheck_after+0xab/0x1db Feb 19 08:40:31 osprey kernel: [] __alloc_skb+0x41/0x144 Feb 19 08:40:31 osprey kernel: [] kmem_cache_alloc_node+0x129/0x136 Feb 19 08:40:31 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:31 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:31 osprey kernel: [] __alloc_skb+0x6d/0x144 Feb 19 08:40:31 osprey kernel: [] sock_alloc_send_skb+0x80/0x1e1 Feb 19 08:40:31 osprey kernel: [] unix_stream_sendmsg+0x172/0x350 Feb 19 08:40:31 osprey kernel: [] sock_aio_write+0x127/0x13f Feb 19 08:40:31 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:31 osprey kernel: [] __sigqueue_free+0x3b/0x3f Feb 19 08:40:31 osprey kernel: [] sock_aio_write+0x0/0x13f Feb 19 08:40:31 osprey kernel: [] do_sync_readv_writev+0xe0/0x128 Feb 19 08:40:31 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:32 osprey kernel: [] file_has_perm+0xa7/0xb6 Feb 19 08:40:32 osprey kernel: [] autoremove_wake_function+0x0/0x38 Feb 19 08:40:32 osprey kernel: [] do_readv_writev+0xe1/0x1bc Feb 19 08:40:32 osprey kernel: [] sys_rt_sigreturn+0x28f/0x357 Feb 19 08:40:32 osprey kernel: [] audit_syscall_entry+0x148/0x17e Feb 19 08:40:32 osprey kernel: [] vfs_writev+0x3e/0x49 Feb 19 08:40:32 osprey kernel: [] sys_writev+0x47/0x94 Feb 19 08:40:32 osprey kernel: [] tracesys+0xdc/0xe1 Feb 19 08:40:32 osprey kernel: Feb 19 08:40:32 osprey kernel: ffff810037c140d0: redzone 1:0x5a2cf071, redzone 2:0x170fc2a5 Feb 19 08:40:32 osprey kernel: Slab corruption: (Not tainted) start=ffff810037c142f0, len=512 Feb 19 08:40:32 osprey kernel: Redzone: 0x170fc2a5/0x5a2cf071. Feb 19 08:40:32 osprey kernel: Last user: [](skb_release_data+0x95/0x9a) Feb 19 08:40:32 osprey kernel: Feb 19 08:40:32 osprey kernel: Call Trace: Feb 19 08:40:32 osprey kernel: [] check_poison_obj+0x7f/0x1f9 Feb 19 08:40:32 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:32 osprey kernel: [] cache_alloc_debugcheck_after+0x35/0x1db Feb 19 08:40:32 osprey kernel: [] __alloc_skb+0x41/0x144 Feb 19 08:40:32 osprey kernel: [] kmem_cache_alloc_node+0x129/0x136 Feb 19 08:40:32 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:32 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:32 osprey kernel: [] __alloc_skb+0x6d/0x144 Feb 19 08:40:32 osprey kernel: [] sock_alloc_send_skb+0x80/0x1e1 Feb 19 08:40:32 osprey kernel: [] unix_stream_sendmsg+0x172/0x350 Feb 19 08:40:32 osprey kernel: [] sock_aio_write+0x127/0x13f Feb 19 08:40:32 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:32 osprey kernel: [] __sigqueue_free+0x3b/0x3f Feb 19 08:40:32 osprey kernel: [] sock_aio_write+0x0/0x13f Feb 19 08:40:32 osprey kernel: [] do_sync_readv_writev+0xe0/0x128 Feb 19 08:40:32 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:32 osprey kernel: [] file_has_perm+0xa7/0xb6 Feb 19 08:40:32 osprey kernel: [] autoremove_wake_function+0x0/0x38 Feb 19 08:40:32 osprey kernel: [] do_readv_writev+0xe1/0x1bc Feb 19 08:40:32 osprey kernel: [] sys_rt_sigreturn+0x28f/0x357 Feb 19 08:40:32 osprey kernel: [] audit_syscall_entry+0x148/0x17e Feb 19 08:40:32 osprey kernel: [] vfs_writev+0x3e/0x49 Feb 19 08:40:32 osprey kernel: [] sys_writev+0x47/0x94 Feb 19 08:40:32 osprey kernel: [] tracesys+0xdc/0xe1 Feb 19 08:40:32 osprey kernel: Feb 19 08:40:32 osprey kernel: 000: 3c 34 3e 46 65 62 20 31 39 20 30 38 3a 34 30 3a Feb 19 08:40:32 osprey kernel: Prev obj: start=ffff810037c140d8, len=512 Feb 19 08:40:32 osprey kernel: Redzone: 0x170fc2a5/0x170fc2a5. Feb 19 08:40:32 osprey kernel: Last user: [](__kmalloc_node_track_caller+0x25/0x2a) Feb 19 08:40:32 osprey kernel: 000: 6e 02 f2 08 6f e8 1e 00 01 00 00 00 00 00 00 00 Feb 19 08:40:32 osprey kernel: 010: 00 00 00 00 00 00 00 00 00 08 00 20 04 04 00 00 Feb 19 08:40:32 osprey kernel: Next obj: start=ffff810037c14508, len=512 Feb 19 08:40:32 osprey kernel: Redzone: 0x170fc2a5/0x170fc2a5. Feb 19 08:40:32 osprey kernel: Last user: [](vc_allocate+0x88/0x135) Feb 19 08:40:32 osprey kernel: 000: 07 00 00 00 50 00 00 00 19 00 00 00 a0 00 00 00 Feb 19 08:40:32 osprey kernel: 010: 90 01 00 00 00 00 00 00 00 90 a5 1d 00 81 ff ff Feb 19 08:40:32 osprey kernel: slab error in cache_alloc_debugcheck_after(): cache `size-512': double free, or memory outside object was overwritten Feb 19 08:40:32 osprey kernel: Feb 19 08:40:32 osprey kernel: Call Trace: Feb 19 08:40:32 osprey kernel: [] __slab_error+0x24/0x26 Feb 19 08:40:32 osprey kernel: [] cache_alloc_debugcheck_after+0xab/0x1db Feb 19 08:40:32 osprey kernel: [] __alloc_skb+0x41/0x144 Feb 19 08:40:32 osprey kernel: [] kmem_cache_alloc_node+0x129/0x136 Feb 19 08:40:32 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:32 osprey kernel: [] __kmalloc_node_track_caller+0x25/0x2a Feb 19 08:40:32 osprey kernel: [] __alloc_skb+0x6d/0x144 Feb 19 08:40:32 osprey kernel: [] sock_alloc_send_skb+0x80/0x1e1 Feb 19 08:40:32 osprey kernel: [] unix_stream_sendmsg+0x172/0x350 Feb 19 08:40:32 osprey kernel: [] sock_aio_write+0x127/0x13f Feb 19 08:40:32 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:32 osprey kernel: [] __sigqueue_free+0x3b/0x3f Feb 19 08:40:32 osprey kernel: [] sock_aio_write+0x0/0x13f Feb 19 08:40:32 osprey kernel: [] do_sync_readv_writev+0xe0/0x128 Feb 19 08:40:32 osprey kernel: [] avc_has_perm+0x49/0x5b Feb 19 08:40:32 osprey kernel: [] file_has_perm+0xa7/0xb6 Feb 19 08:40:32 osprey kernel: [] autoremove_wake_function+0x0/0x38 Feb 19 08:40:32 osprey kernel: [] do_readv_writev+0xe1/0x1bc Feb 19 08:40:32 osprey kernel: [] sys_rt_sigreturn+0x28f/0x357 Feb 19 08:40:32 osprey kernel: [] audit_syscall_entry+0x148/0x17e Feb 19 08:40:32 osprey kernel: [] vfs_writev+0x3e/0x49 Feb 19 08:40:32 osprey kernel: [] sys_writev+0x47/0x94 Feb 19 08:40:32 osprey kernel: [] tracesys+0xdc/0xe1 Feb 19 08:40:32 osprey kernel: Feb 19 08:40:32 osprey kernel: ffff810037c142e8: redzone 1:0x170fc2a5, redzone 2:0x5a2cf071 Feb 19 08:40:39 osprey kernel: ttyS0: LSR safety check engaged! From jkeating at redhat.com Mon Feb 19 15:04:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 10:04:15 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <1171894171.24204.21.camel@zod.rchland.ibm.com> References: <200702161608.14572.jkeating@redhat.com> <1171894171.24204.21.camel@zod.rchland.ibm.com> Message-ID: <200702191004.19461.jkeating@redhat.com> On Monday 19 February 2007 09:09, Josh Boyer wrote: > Just a reminder for everyone, this means that FC-5 will be maintained > for a slightly longer period of time. ?The lifetime of releases is N+2 > plus one month. ?So FC-5 will be maintained until one month after F7 is > release. > > Happy Hacking. Hrm, I don't remember any official decisions wrt FC-5. I thought we had agreed to do this for FC6, but was unclear about FC-5. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Feb 19 15:10:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Feb 2007 10:10:48 -0500 Subject: Fedora power management In-Reply-To: References: <20070218213051.388fd6c0@osprey.hogchain.net> <1171876270.4839.3.camel@hughsie-laptop> <20070219071123.491bb0ac@osprey.hogchain.net> <1171894456.3005.2.camel@aglarond.local> Message-ID: <1171897848.3005.13.camel@aglarond.local> On Mon, 2007-02-19 at 09:24 -0500, Joshua Baker-LePain wrote: > On Mon, 19 Feb 2007 at 9:14am, Jeremy Katz wrote > > The default is for the driver to be suspended normally; SUSPEND_MODULES > > is to list (broken) modules that have to be removed and reinserted > > around the suspend process. > > Is it considered a (fixable, bugzillable) bug if normal suspending works > but has undesirable effects? Example -- on my Thinkpad Z61t, suspend and > wake-up worked out of the box with FC6, but the power drain was impressive > (I have the figures at home, but it was >50% battery of capacity > overnight). Some experimenting demonstarted that removing the USB modules > before going to sleep dropped the sleeping power consumption considerably, > so I put those in SUSPEND_MODULES. I figured this was model specific so I > didn't bugzilla it. Should I? It definitely doesn't hurt to file it so that it can be tracked. And should probably be filed against kernel Jeremy From katzj at redhat.com Mon Feb 19 15:12:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Feb 2007 10:12:55 -0500 Subject: Fedora power management In-Reply-To: <20070219085250.28160775@osprey.hogchain.net> References: <20070218213051.388fd6c0@osprey.hogchain.net> <1171876270.4839.3.camel@hughsie-laptop> <20070219071123.491bb0ac@osprey.hogchain.net> <1171894456.3005.2.camel@aglarond.local> <20070219085250.28160775@osprey.hogchain.net> Message-ID: <1171897975.3005.15.camel@aglarond.local> On Mon, 2007-02-19 at 08:52 -0600, Jay Cliburn wrote: > I'm getting fairly spectacular failures whenever I execute pm-suspend. > The failure mode is variable. In this particular example, I end up with > slab corruption. I presume this should be passed upstream? Yep. Thanks! Jeremy From stickster at gmail.com Mon Feb 19 16:04:23 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 19 Feb 2007 11:04:23 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <200702191004.19461.jkeating@redhat.com> References: <200702161608.14572.jkeating@redhat.com> <1171894171.24204.21.camel@zod.rchland.ibm.com> <200702191004.19461.jkeating@redhat.com> Message-ID: <1171901063.20354.30.camel@localhost.localdomain> On Mon, 2007-02-19 at 10:04 -0500, Jesse Keating wrote: > On Monday 19 February 2007 09:09, Josh Boyer wrote: > > Just a reminder for everyone, this means that FC-5 will be maintained > > for a slightly longer period of time. The lifetime of releases is N+2 > > plus one month. So FC-5 will be maintained until one month after F7 is > > release. > > > > Happy Hacking. > > Hrm, I don't remember any official decisions wrt FC-5. I thought we had > agreed to do this for FC6, but was unclear about FC-5. There will be an official announcement on this from the Board, after we settle some issues wrt. resource requirements. As Jesse says, it's still under discussion for now. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Feb 19 16:19:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 11:19:09 -0500 Subject: Archives of Fedora IRC channels In-Reply-To: <45D9AF64.3000203@fedoraproject.org> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> Message-ID: <20070219161909.GC26885@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > >have to, or would like to? > > Like to I guess. If I may ask... why? Bill From jwboyer at jdub.homelinux.org Mon Feb 19 16:22:32 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Feb 2007 10:22:32 -0600 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <1171901063.20354.30.camel@localhost.localdomain> References: <200702161608.14572.jkeating@redhat.com> <1171894171.24204.21.camel@zod.rchland.ibm.com> <200702191004.19461.jkeating@redhat.com> <1171901063.20354.30.camel@localhost.localdomain> Message-ID: <1171902152.24204.25.camel@zod.rchland.ibm.com> On Mon, 2007-02-19 at 11:04 -0500, Paul W. Frields wrote: > On Mon, 2007-02-19 at 10:04 -0500, Jesse Keating wrote: > > On Monday 19 February 2007 09:09, Josh Boyer wrote: > > > Just a reminder for everyone, this means that FC-5 will be maintained > > > for a slightly longer period of time. The lifetime of releases is N+2 > > > plus one month. So FC-5 will be maintained until one month after F7 is > > > release. > > > > > > Happy Hacking. > > > > Hrm, I don't remember any official decisions wrt FC-5. I thought we had > > agreed to do this for FC6, but was unclear about FC-5. > > There will be an official announcement on this from the Board, after we > settle some issues wrt. resource requirements. As Jesse says, it's > still under discussion for now. Seems I jumped the gun. Apologies. josh From sundaram at fedoraproject.org Mon Feb 19 16:26:31 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Feb 2007 21:56:31 +0530 Subject: Archives of Fedora IRC channels In-Reply-To: <20070219161909.GC26885@nostromo.devel.redhat.com> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> Message-ID: <45D9CFB7.8070801@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >>> have to, or would like to? >> Like to I guess. > > If I may ask... why? > > Bill I did explain that in the original mail. For contributors and users to look back at what discussions happened in any Fedora channel at any time. Meetings planned or adhoc. Questions that were answered before etc. Rahul From green at redhat.com Mon Feb 19 16:30:15 2007 From: green at redhat.com (Anthony Green) Date: Mon, 19 Feb 2007 08:30:15 -0800 Subject: Creating a jackuser group In-Reply-To: <200702152218.20733.dblistsub-fedora@yahoo.it> References: <1170790351.3564.12.camel@localhost.localdomain> <1170920896.13307.38.camel@localhost.localdomain> <1171556972.3635.15.camel@localhost.localdomain> <200702152218.20733.dblistsub-fedora@yahoo.it> Message-ID: <1171902616.9028.8.camel@localhost.localdomain> On Thu, 2007-02-15 at 22:18 +0100, Davide Bolcioni wrote: > Well, if I understand this correctly, could the above be obtained using > consolehelper(8) and creating /etc/pam.d/qjackctl, which would have > > session required pam_limits.so conf=/etc/security/qjackctl.conf > > where qjackctl.conf would have > > * - memlock 131072 > * . rtprio > > or am I missing something ? No groups to create, and files which RPM can add > in directories which are likely to just be there. Thanks for this suggestion. It forced me to learn a little about PAM. As I understand it, this would give RT privs to any user who runs qjackctl. One thing that wasn't clear to me is what constitutes a "session". If they run qjackctl, do the limit changes affect anything the user does from that point on? Or is it limited to the qjackctl process and whatever it runs. This is pretty neat, but I think one of our goals was to require admin privs to grant RT privs to users because of the inherent dangers of handing them out to everybody. Is this not really a worthwhile goal? AG From stickster at gmail.com Mon Feb 19 16:33:48 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 19 Feb 2007 11:33:48 -0500 Subject: Announcing a change in the Fedora 7 schedule In-Reply-To: <1171902152.24204.25.camel@zod.rchland.ibm.com> References: <200702161608.14572.jkeating@redhat.com> <1171894171.24204.21.camel@zod.rchland.ibm.com> <200702191004.19461.jkeating@redhat.com> <1171901063.20354.30.camel@localhost.localdomain> <1171902152.24204.25.camel@zod.rchland.ibm.com> Message-ID: <1171902828.20354.35.camel@localhost.localdomain> On Mon, 2007-02-19 at 10:22 -0600, Josh Boyer wrote: > On Mon, 2007-02-19 at 11:04 -0500, Paul W. Frields wrote: > > On Mon, 2007-02-19 at 10:04 -0500, Jesse Keating wrote: > > > On Monday 19 February 2007 09:09, Josh Boyer wrote: > > > > Just a reminder for everyone, this means that FC-5 will be maintained > > > > for a slightly longer period of time. The lifetime of releases is N+2 > > > > plus one month. So FC-5 will be maintained until one month after F7 is > > > > release. > > > > > > > > Happy Hacking. > > > > > > Hrm, I don't remember any official decisions wrt FC-5. I thought we had > > > agreed to do this for FC6, but was unclear about FC-5. > > > > There will be an official announcement on this from the Board, after we > > settle some issues wrt. resource requirements. As Jesse says, it's > > still under discussion for now. > > Seems I jumped the gun. Apologies. No worries. Notice will come here and to f-announce-l. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 ajackson at redhat.com Mon Feb 19 16:39:48 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 19 Feb 2007 11:39:48 -0500 Subject: xorg 7.2 for FC6 In-Reply-To: <45D6EE83.5010209@gmail.com> References: <45D6EE83.5010209@gmail.com> Message-ID: <1171903188.13597.19.camel@localhost.localdomain> On Sat, 2007-02-17 at 13:01 +0100, dragoran wrote: > Hello, > Are they any plans for updated xorg packages for FC6? In an ideal world, I'd like to focus on FC7 as much as possible, and land that as an FC6 update once we're happy with it. So, not yet. Beyond that, it's a bit of a hassle to do this right now without manual intervention from a brew guru, because the build system for updates trees doesn't work the way I expect. Essentially, the buildroot is populated from dist-fc6-updates (which inherits from dist-fc6), but the output of the build goes to a pile called dist-fc6-updates-candidate. Packages normally only move from -updates-candidate to -updates once I've filled out an update request and a release engineer has approved it, which means a long propagation delay between building package A and package B, when B BuildRequires a newer version of A than was in FC6. (Ironically, modularisation of the X source made this worse!) brew has a 'chain-build' command that _almost_ does what I want. The syntax is about what you'd expect: brew chain-build a b c : d e : f Which runs a b and c as a set, then d and e after the first set land in the collection, and then f after the second set. The reason it works for rawhide is that it creates a new buildroot for every package, but in rawhide the build output collection is the same as the collection you create the buildroot with. In other words, my buildroot is constructed from dist-fc7, and successfully built packages also go to dist-fc7. For updates this isn't true. Updates buildroots are created from dist-fc6-updates, but the built package goes to dist-fc6-updates-candidate. What I need, I think, is a way to tell brew (possibly mock) to keep a buildroot around for multiple related jobs, with an additional "update" phase corresponding to the :'s above, in which the output of the previous passes become available for use as BuildRequires. This would be useful outside the scope of updates too; say I wanted to fix a .pc file to list fewer needless libraries, and I wanted to rebuild everything downstream of that package to verify that they all still build. - ajax From jkeating at redhat.com Mon Feb 19 17:12:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Feb 2007 12:12:47 -0500 Subject: xorg 7.2 for FC6 In-Reply-To: <1171903188.13597.19.camel@localhost.localdomain> References: <45D6EE83.5010209@gmail.com> <1171903188.13597.19.camel@localhost.localdomain> Message-ID: <200702191212.47314.jkeating@redhat.com> On Monday 19 February 2007 11:39, Adam Jackson wrote: > What I need, I think, is a way to tell brew (possibly mock) to keep a > buildroot around for multiple related jobs, with an additional "update" > phase corresponding to the :'s above, in which the output of the > previous passes become available for use as BuildRequires. ?This would > be useful outside the scope of updates too; say I wanted to fix a .pc > file to list fewer needless libraries, and I wanted to rebuild > everything downstream of that package to verify that they all still > build. Close, but not quite the RFE I've expressed for Koji, the buildsystem we'll use for the merged Core/Extras. Instead of keeping the buildroot and reusing it, it would instead make the just built packages available for your next buildroot, yours alone. This would allow you to chainbuild a list of intertwined packages using previous results in the buildroot but still using a fresh buildroot each time, and still landing all the builds in -candidate. Most likely not possible in F7 timeframe though. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jfrieben at gmx.de Mon Feb 19 17:14:44 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Mon, 19 Feb 2007 18:14:44 +0100 Subject: xorg 7.2 for FC6 In-Reply-To: <1171903188.13597.19.camel@localhost.localdomain> References: <45D6EE83.5010209@gmail.com> <1171903188.13597.19.camel@localhost.localdomain> Message-ID: <20070219171444.62700@gmx.net> > > Are they any plans for updated xorg packages for FC6? > > In an ideal world, I'd like to focus on FC7 as much as possible, and > land that as an FC6 update once we're happy with it. So, not yet. Rebuilding the "Xorg 7.2" packages for "FC5" was straightforward except for tweaking some "GNOME" packages and the kernel for the "965Q" chipset which I needed it for. Since "FC6" is much "closer" and has "compiz/AIGLX" support built in already, this should be even easier for users who feel the need to update asap. -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out From dblistsub-fedora at yahoo.it Mon Feb 19 18:01:03 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Mon, 19 Feb 2007 19:01:03 +0100 Subject: Creating a jackuser group In-Reply-To: <1171902616.9028.8.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <200702152218.20733.dblistsub-fedora@yahoo.it> <1171902616.9028.8.camel@localhost.localdomain> Message-ID: <200702191901.03579.dblistsub-fedora@yahoo.it> On Monday 19 February 2007 17:30:15 Anthony Green wrote: > On Thu, 2007-02-15 at 22:18 +0100, Davide Bolcioni wrote: > > Well, if I understand this correctly, could the above be obtained using > > consolehelper(8) and creating /etc/pam.d/qjackctl, which would have > > > > session required pam_limits.so conf=/etc/security/qjackctl.conf > > > > where qjackctl.conf would have > > > > * - memlock 131072 > > * . rtprio > > > > or am I missing something ? No groups to create, and files which RPM can > > add in directories which are likely to just be there. > > Thanks for this suggestion. It forced me to learn a little about PAM. > > As I understand it, this would give RT privs to any user who runs > qjackctl. One thing that wasn't clear to me is what constitutes a > "session". If they run qjackctl, do the limit changes affect anything > the user does from that point on? Or is it limited to the qjackctl > process and whatever it runs. You could write instead @jackusers - memlock 131072 @jackusers - rtprio but then you'd be back with adding the group jackusers (which is not hard, but requires care) and adding users to said group. I think this is not necessary provided we have: /usr/bin/qjackctl -> consolehelper /usr/sbin/qjackctl /etc/pam.d/qjackctl so that when a normal user invokes qjackctl, consolehelper kicks in and authenticates against PAM (this step could be skipped if qjackctl, by himself, explicitly used PAM for authentication). Then we would have something (warning: UNTESTED) along the lines of %PAM-1.0 auth sufficient pam_rootok.so auth required pam_console.so account required pam_permit.so session required pam_limits.so conf=/etc/security/qjackctl.conf in /etc/pam.d/qjackctl. > This is pretty neat, but I think one of our goals was to require admin > privs to grant RT privs to users because of the inherent dangers of > handing them out to everybody. Is this not really a worthwhile goal? The idea above is to grant RT privilege only to qjackctl and its child processes when run from console; after all, it's not the user which requires RT privileges, it's qjackctl. I believe that consolehelper(8) is only necessary as a wrapper for PAM-unaware binaries, but I have not verified this. Thank you for your consideration, Davide Bolcioni -- There is no place like /home. From jdogalt at yahoo.com Mon Feb 19 20:28:20 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Mon, 19 Feb 2007 12:28:20 -0800 (PST) Subject: Fedora power management In-Reply-To: <20070218213051.388fd6c0@osprey.hogchain.net> Message-ID: <594060.89415.qm@web56907.mail.re3.yahoo.com> --- Jay Cliburn wrote: > I'm trying to hack/test a network driver's ability to suspend, > resume, > and wake-on-lan (while suspended). This is on a rawhide x86_64 > desktop > system. Is the Fedora pm-stuff documented anywhere? I can't seem to > find anything on the wiki, and the only related manpage is for > pm-pmu. I would specifically like to know the process for moving to a new swap partition(file?) or creating a new one after install. I.e. how the whole suspend1 hibernate pulls that in. Does mkinitrd pull in the first swap entry from fstab? Is there any user documentation that explains limitations. I.e. is it possible to use swapfiles now with the default suspend. I admit, my case of using the atrpms suspend2 packages probably makes my case unsupportable, but it does seem to me that suspend1 was added in fc5 with no documentation, and I haven't run into any documentation since. Just my 2 cents worth of end user confusion... -dmc/jdog P.S. also, if anyone can help me with suspend2, the cpuspeed management seems to stop working on my core duo after the first hibernate, and occasionally I get in a state where hibernation fails and the machine enters swap thrash effectively failure mode. I'm sure the answer is "suspend2 is crap", but having to use swap partitions I find rather crappy as well. (again, if that limitation of default hibernate in fc6 is gone, I'd love to be pointed towards any kind of reasonable documentation. Also, can default fc6 suspend do hibernate to lvm swap partition?). ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 From notting at redhat.com Mon Feb 19 20:30:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 15:30:11 -0500 Subject: First stab at the Fedora "Classic" spin In-Reply-To: <200702151717.29913.jkeating@redhat.com> References: <200702151717.29913.jkeating@redhat.com> Message-ID: <20070219203011.GA1580@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > gnome-software-development > x-software-development > java-development > development-libs > development-tools > web-server > dns-server > server-cfg > news-server > smb-server > sql-server > mail-server > printing > mysql > ftp-server > network-server > legacy-network-server > > Then I did a spin. I wound up with 3.5~ CDs worth of content. Mmm, crickets. So, things I think we should add that are currently marked 'optional': - Admin pessulus - Auth & Pub conglomerate scribus - Base . Otherwise, booting with 'linux xfs' isn't going to actually do anything. ;) - Base X mathml-fonts xorg-x11-server-{Xnest,Xvfb} xscreensaver*? - Development Tools cogito dejagnu ElectricFence bzr? git memtest86+ mercurial monotone? mock quilt rpmdevtools rpmlint trac? - Dialup pptp - Eclipse eclipse-pde - Editors emacs joe gobby? - Games I dunno. Something. - GNOME deskbar-applet gconf-editor gnome-keyring-manager? gnome-themes-extras? hal-gnome? istanbul nautilus-open-terminal sabayon - GNOME software dev anjuta & docs glibmm24-devel gtkmm24-devel gconfmm26-devel gnome-common libglade24mm-devel libgnomemm26-deel libgnomeuimm26-devel - Graphical Internet epiphany epiphany-extensions evolution-connector gnome-blog gossip? thunderbird - Graphics f-spot inkscape gwenview? - Hardware support ? Everything? - KDE Ask the KDE spin folks. - Mail Server clamav* cyrus-imapd squirrelmail exim? postfix? :) - MySQL mod_auth_mysql php-mysql - Network Server dhcp dhcpv6 flumotion icecast krb5-server NetworkManager-vpnc <- wtf is this doing *here*? openldap-servers openswan openvpn puppet-server radvd vnc-server ypserv - News Server (this should probably die as a separate category) cleanfeed - Office abiword contacts? dates? dia glabels gnucash gnumeric koffice-suite lyx/klyx openoffice.org-* taskjuggler? - Sound and Video amarok? dvgrab k3b? - SQL Server postgresql-* qt-ODBC libdbi-dbd-pgsql - System Tools aide? apcupsd? arptables_jf audit avahi-tools createrepo ebtables fuse mrtg nagios nmap-frontend oddjob powerman puppet pwgen rdiff-backup sabayon ttywatch vpnc wireshark-gnome - Text Internet bittorrent (or something) irssi - Web development django (Is this the ONLY web devel thing we have? I don't think so.) - Web server awstats mediawiki mod_auth_kerb mod_auth_mysql mod_auth_pgsql moin moin-latex php-odbc php-pgsql plone tomcat5 TurboGears Bill From green at redhat.com Mon Feb 19 21:47:25 2007 From: green at redhat.com (Anthony Green) Date: Mon, 19 Feb 2007 13:47:25 -0800 Subject: Creating a jackuser group In-Reply-To: <200702191901.03579.dblistsub-fedora@yahoo.it> References: <1170790351.3564.12.camel@localhost.localdomain> <200702152218.20733.dblistsub-fedora@yahoo.it> <1171902616.9028.8.camel@localhost.localdomain> <200702191901.03579.dblistsub-fedora@yahoo.it> Message-ID: <1171921645.9028.34.camel@localhost.localdomain> On Mon, 2007-02-19 at 19:01 +0100, Davide Bolcioni wrote: > I think this is not necessary > provided we have: > > /usr/bin/qjackctl -> consolehelper > /usr/sbin/qjackctl > /etc/pam.d/qjackctl > > so that when a normal user invokes qjackctl, consolehelper kicks in and > authenticates against PAM (this step could be skipped if qjackctl, by > himself, explicitly used PAM for authentication). Then we would have > something (warning: UNTESTED) along the lines of > > %PAM-1.0 > auth sufficient pam_rootok.so > auth required pam_console.so > account required pam_permit.so > session required pam_limits.so conf=/etc/security/qjackctl.conf > > in /etc/pam.d/qjackctl. I tried this (but with jackd instead of qjackctl). It works as advertised after I created an empty file /etc/security/console.apps/jackd. Pardon my ignorance, but one thing I noticed is that it actually runs jackd as root, which means that the user can't terminate it with Ctrl-C. Is this expected and is there a solution? AG From notting at redhat.com Mon Feb 19 22:01:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Feb 2007 17:01:51 -0500 Subject: First stab at the Fedora "Classic" spin In-Reply-To: <20070219203011.GA1580@nostromo.devel.redhat.com> References: <200702151717.29913.jkeating@redhat.com> <20070219203011.GA1580@nostromo.devel.redhat.com> Message-ID: <20070219220151.GA4346@nostromo.devel.redhat.com> Also, the livecd includes: alsa-utils chkconfig dhclient gnome-mag gnome-python2-canvas gnome-theme-clearlooks-bigpack gparted gucharmap m17n-lib NetworkManager-openvpn ntfs-3g ntfsprogs redhat-artwork scim-libs xscreensaver-extras-gss xscreensaver-gl-extras-gss These were not included in the desktop manifest (although a good chunk were probably pulled in via deps.) Bill From dblistsub-fedora at yahoo.it Mon Feb 19 23:22:18 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Tue, 20 Feb 2007 00:22:18 +0100 Subject: Creating a jackuser group In-Reply-To: <1171921645.9028.34.camel@localhost.localdomain> References: <1170790351.3564.12.camel@localhost.localdomain> <200702191901.03579.dblistsub-fedora@yahoo.it> <1171921645.9028.34.camel@localhost.localdomain> Message-ID: <200702200022.18654.dblistsub-fedora@yahoo.it> On Monday 19 February 2007 22:47:25 Anthony Green wrote: > On Mon, 2007-02-19 at 19:01 +0100, Davide Bolcioni wrote: > > I think this is not necessary > > provided we have: > > > > /usr/bin/qjackctl -> consolehelper > > /usr/sbin/qjackctl > > /etc/pam.d/qjackctl > > > > so that when a normal user invokes qjackctl, consolehelper kicks in and > > authenticates against PAM (this step could be skipped if qjackctl, by > > himself, explicitly used PAM for authentication). Then we would have > > something (warning: UNTESTED) along the lines of > > > > %PAM-1.0 > > auth sufficient pam_rootok.so > > auth required pam_console.so > > account required pam_permit.so > > session required pam_limits.so conf=/etc/security/qjackctl.conf > > > > in /etc/pam.d/qjackctl. > > I tried this (but with jackd instead of qjackctl). It works as > advertised after I created an empty > file /etc/security/console.apps/jackd. > > Pardon my ignorance, but one thing I noticed is that it actually runs > jackd as root, which means that the user can't terminate it with Ctrl-C. > Is this expected and is there a solution? I believe consolehelper(8) is intended to do exactly that, see userhelper(8) which is the workhorse invoked by consolehelper(8). It might be that setting USER="" in /etc/security/console.apps/jackd as documented in userhelper(8) would launch it as the console user; I do not know if this would cause the attempt to set memlock and rtprio to fail because of insufficient privileges, however. If jackd, as the name seems to suggest, is a daemon (listens for commands), this approach might be insecure, or at least way outside the original design framework of consolehelper(8), and should probably be reviewed by someone more knowledgeable in such matters. Davide Bolcioni -- There is no place like /home. From mspevack at redhat.com Tue Feb 20 02:26:24 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 19 Feb 2007 21:26:24 -0500 (EST) Subject: Archives of Fedora IRC channels In-Reply-To: <45D9CFB7.8070801@fedoraproject.org> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> Message-ID: On Mon, 19 Feb 2007, Rahul Sundaram wrote: > I did explain that in the original mail. For contributors and users to > look back at what discussions happened in any Fedora channel at any > time. Meetings planned or adhoc. Questions that were answered before > etc. I wonder how useful something like that would end up being, just as a bunch of raw data. At least the mailman archives are pretty easy to navigate. Piles of IRC logs... shudder. Without some way of organizing the information in the logs, it kind of seems like a waste of time, no? And wouldn't the time spent organizing (or writing a program to organize) that info be better spent elsewhere in Fedora? My .02 --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From buildsys at redhat.com Tue Feb 20 10:51:24 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 20 Feb 2007 05:51:24 -0500 Subject: rawhide report: 20070220 changes Message-ID: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> Updated Packages: anthy-8616-1.fc7 ---------------- * Mon Feb 19 2007 Akira TAGOH - 8616-1 - New upstream release. autoconf-2.61-5.fc7 ------------------- * Mon Feb 19 2007 Karsten Hopp 2.61-5 - use ./configure - filter dependencies * Thu Feb 15 2007 Karsten Hopp 2.61-4 - add disttag - replace tabs with spaces - fix buildroot - use Requires(post), Requires(preun) - use make install DESTDIR=.... - drop perl requirement as it gets pulled it automatically * Thu Jan 18 2007 Karsten Hopp 2.61-3 - don't abort (un)install scriptlets when _excludedocs is set (Ville Skytt??) autofs-1:5.0.1-0.rc3.24 ----------------------- * Tue Feb 20 2007 Ian Kent - 5.0.1-0.rc3.24 - add "condrestart" to init script (bz 228860). - add "@network" and .domain.name export check. - fix display map name in mount entry for "-hosts" map. automake14-1.4p6-15.fc7 ----------------------- * Mon Feb 19 2007 Karsten Hopp 1.4p6-15 - drop autoconf BR - drop perl requirement busybox-1:1.2.2-6.fc7 --------------------- * Mon Feb 19 2007 Ivana Varekova - 1:1.2.2-6 - incorporate package review feedback bzip2-1.0.4-7.fc7 ----------------- * Mon Feb 19 2007 Jesse Keating 1.0.4-7 - Temporarily add static lib back in for rpm cvs-1.11.22-9.fc7 ----------------- * Mon Feb 19 2007 Jindrich Novy - 1.11.22-9 - fix permissions of cvs.sh, add cvs.csh to /etc/profile.d (#225672) * Fri Jan 05 2007 Jindrich Novy - 1.11.22-8 - fix post/preun scriptlets so that they won't fail with docs disabled * Fri Dec 01 2006 Jindrich Novy - 1.11.22-7 - remove/replace obsolete rpm tags, fix rpmlint errors file-4.19-3.fc7 --------------- * Mon Feb 19 2007 Martin Bacovsky - 4.19-3.fc7 - Resolves: #225750 - Merge Review: file * Thu Jan 25 2007 Martin Bacovsky - 4.19-2.fc7 - Resolves: #223297 - file does not recognize OpenOffice "native" formats - Resolves: #224344 - Magic rules should be in file-libs * Tue Jan 09 2007 Martin Bacovsky - 4.19-1.fc7 - Resolves: #208880 - Pointless file(1) error message while detecting ELF 64-bit file thanks to for patch - Resolves: #214992 - file-devel should own %_includedir/* %_libdir/lib*.so - Resolves: #203548 - a -devel package should be split out for libmagic - upgrade to new upstream 4.19 - patch revision and cleaning - split package to file, file-devel and file-libs fonts-indic-2.1.3-1.fc7 ----------------------- * Mon Feb 19 2007 Parag Nemade - 2.1.3-1 - Resolved Bugs from Parag Nemade - Bug 202401: [ta_IN] New codepoints/glyphs in Unicode 5.0 - Bug 223774: [kn_IN] Some Ligature rules are wrong in the font file - Bug 223971: [kn_IN] Consonant + Halant + Consonant + Dependent Vowel not appearing properly in some rare cases - Bug 227971: [kn_IN] Combinations with 2 Halants not rendering properly gphoto2-2.3.1-4.fc7 ------------------- * Mon Feb 19 2007 Jindrich Novy 2.3.1-4 - ACL handling is now moved into HAL (#229230) less-394-8.fc7 -------------- * Mon Feb 19 2007 Ivana Varekova - 394-8 - change LICENSE permissions libdrm-2.3.0-4.fc7 ------------------ * Mon Feb 19 2007 Adam Jackson 2.3.0-4 - Update nouveau patch - Fix License tag and other rpmlint noise mod_python-3.3.1-3 ------------------ * Mon Feb 19 2007 Jeremy Katz - 3.3.1-3 - don't use legacy python-abi requires syntax ncurses-5.6-5.20070217.fc7 -------------------------- * Mon Feb 19 2007 Miroslav Lichvar 5.6-5.20070217 - update to patch 20070217 - replace libcurses.so symlink with linker script (#228891) net-tools-1.60-78.fc7 --------------------- * Mon Feb 19 2007 Radek Vok??l - 1.60-78 - spec file cleanup (#226193) openldap-2.3.34-0.fc7 --------------------- * Mon Feb 19 2007 Jay Fenlason 2.3.34-1.fc7 - New upstream release - Upgrade the scripts for migrating the database so that they might actually work. - change bind-libbind-devel to bind-devel in BuildPreReq openoffice.org-1:2.2.0-8.1 -------------------------- * Mon Feb 19 2007 Caolan McNamara - 1:2.2.0-8.1 - next version * Wed Feb 14 2007 Caolan McNamara - 1:2.2.0-7.2 - Resolves: rhbz#228629 mistranslation for properties in or-IN - drop dictionaries, they're in hunspell-?? now perl-Archive-Tar-1.30-3.fc7 --------------------------- * Mon Feb 19 2007 Robin Norwood - 1.30-3 - Incorporate specfile improvements from Jose Oliveira. php-5.2.1-3 ----------- * Mon Feb 19 2007 Joe Orton 5.2.1-3 - fix regression in str_{i,}replace (from upstream) rhgb-0.17.1-1.fc7 ----------------- * Mon Feb 19 2007 Matthias Clasen - 0.17.1-1 - Fix some glitches in the new theme rpm-4.4.2-40.fc7 ---------------- * Mon Feb 19 2007 Jeremy Katz - 4.4.2-40 - rpm-build should require findutils rsync-2.6.9-2.fc7 ----------------- * Mon Feb 19 2007 Adam Jackson 2.6.9-2 - Add dist tag to Release to fix upgrades from FC5 or FC6. * Mon Feb 19 2007 Simo Sorce - 2.6.9-2 - fix acl/xattr bug with --delete: (bz#229145) slang-2.0.7-2.fc7 ----------------- * Mon Feb 19 2007 Miroslav Lichvar - 2.0.7-2 - ignore background color of trailing spaces if terminal has bce (#217276) - move static library to -static subpackage - spec cleanup tftp-0.42-4 ----------- * Mon Feb 19 2007 Maros Barabas - 0.42-4 - make some changes in spec file (review) - Resolves #226489 * Mon Dec 04 2006 Maros Barabas - 0.42-3.2 - change BuildRequires from tcp_wrappers to tcp_wrappers-devel xorg-x11-drivers-7.2-2.fc7 -------------------------- * Mon Feb 19 2007 Adam Jackson 7.2-2 - Package review feedback fixes: (#226573) - Remove URL, misleading - Remove the Obsoletes: xorg-x11 - Fix License tag xorg-x11-proto-devel-7.2-2.fc7 ------------------------------ * Mon Feb 19 2007 Adam Jackson 7.2-2 - randrproto 1.2.1 Broken deps for ia64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ia64 requires libpt_linux_ia64_r.so.1.10.3()(64bit) pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 xorg-x11-drivers - 7.2-2.fc7.ia64 requires xorg-x11-drv-apm Broken deps for s390 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390 requires libpt_linux_s390_r.so.1.10.3 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.i386 requires libpt_linux_x86_r.so.1.10.3 Broken deps for x86_64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.x86_64 requires libpt_linux_x86_64_r.so.1.10.3()(64bit) Broken deps for ppc64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc64 requires libpt_linux_ppc64_r.so.1.10.3()(64bit) xorg-x11-drivers - 7.2-2.fc7.ppc64 requires xorg-x11-drv-magictouch xorg-x11-drivers - 7.2-2.fc7.ppc64 requires xorg-x11-drv-acecad xorg-x11-drivers - 7.2-2.fc7.ppc64 requires xorg-x11-drv-apm xorg-x11-drivers - 7.2-2.fc7.ppc64 requires xorg-x11-drv-aiptek Broken deps for ppc ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc requires libpt_linux_ppc_r.so.1.10.3 xorg-x11-drivers - 7.2-2.fc7.ppc requires xorg-x11-drv-apm Broken deps for s390x ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390x requires libpt_linux_s390x_r.so.1.10.3()(64bit) From gilboad at gmail.com Tue Feb 20 11:22:17 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 20 Feb 2007 13:22:17 +0200 Subject: rawhide report: 20070220 changes In-Reply-To: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> Message-ID: <1171970537.18231.3.camel@gilboa-work-dev.localdomain> On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > > Updated Packages: > libdrm-2.3.0-4.fc7 > ------------------ > * Mon Feb 19 2007 Adam Jackson 2.3.0-4 > - Update nouveau patch > - Fix License tag and other rpmlint noise OT question (that might not be related...) Any idea when the latest DRI drivers (especially, mach64 and nv) will imported into the kernel tree? - Gilboa From mail at robertoragusa.it Tue Feb 20 12:50:58 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Tue, 20 Feb 2007 13:50:58 +0100 Subject: anaconda update time needs to be improved (really) In-Reply-To: <45423F30.7030600@feuerpokemon.de> References: <45423F30.7030600@feuerpokemon.de> Message-ID: <45DAEEB2.8060700@robertoragusa.it> dragoran wrote: > Update time was ~90-120min depending on the sys. > Why does the update take that long? A reinstall is much faster.. (This is an old thread but my reply seems pertinent here.) I can confirm that upgrading takes really a long time, even on powerful hardware and by using local nfs instead of optical discs. I'm trying to upgrade a ppc machine (2x1.8GHz G5, 512MiB RAM, SATA disk) from FC4 to FC6 by DVD and the first estimated remaining time was more than 1600 minutes. Reports from top, vmstat, ps pointed me to one big bottleneck: every package involving libs runs ldconfig, which takes a lot of time. So I renamed /mnt/sysconfig/sbin/ldconfig away and replaced with a copy of /bin/true. The installation speed went up a lot, I'd say it's 10 times faster now. I suppose that running ldconfig continously is not useful, it could be done just once at the end of the upgrade. The upgrade is still in progress so I don't know if the system will have problems caused by this trick. Comments? Best regards. -- Roberto Ragusa mail at robertoragusa.it From gilboad at gmail.com Tue Feb 20 13:50:01 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 20 Feb 2007 15:50:01 +0200 Subject: Fedora 7 media sets In-Reply-To: <45D483EA.5070804@glezos.com> References: <1171552839.19239.16.camel@aglarond.local> <20070215154002.24510@gmx.net> <45D483EA.5070804@glezos.com> Message-ID: <1171979401.18231.25.camel@gilboa-work-dev.localdomain> On Thu, 2007-02-15 at 16:01 +0000, Dimitrios Glezos wrote: > O/H Joachim Frieben ??????: > >> 3. Need to provide a way to install via media for the following > >> cases: > >> > >> * Desktop environment > >> * Developer use > > > > Isn't the "workstation" class an already well established term and preferable to chose? > > Since I've been asked a couple of times why we are planning on shipping a > Desktop spin and not a Laptop spin (!), this argument might indeed have a base. > It is more accurate (the "opposite" of Server is Workstation, not Dekstop) and > more correctly translated to other languages. > > Also, I suggest to also ship a *Minimal* spin. For the users who have aDSL > (which are probably most of our users), downloading the needed packages via > Anaconda is probably quicker than downloading a whole DVD (besides, burning a CD > is cheaper than a DVD). I usually download only one CD (which I write on a CDRW) > to do the install, so it would be nice if that iso was 100 instead of 600MB. > Besides, now that Anaconda has "Extras" support, more users would actually make > use of this Minimal spin, since it doesn't reflect to "minimal installation" but > more to "minimal download size". > > Finally, would it be possible to install from minimal and have it download > *updated* packages instead of the default-release ones? This way, installing FC7 > 4 months after its release would mean downloading only 100MB + 2GB instead of > 4GB (DVD) plus 1GB (updates). > > My 2 cents. > > -d A. It can already be done with the rescue image. (linux askmethod) B. It only makes sense -if- Anaconda also supports -updates out of the box. There's no sense in download the package once (during the initial installation) just to download it again once you hit the first upgrade. - Gilboa From nphilipp at redhat.com Tue Feb 20 14:09:12 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 20 Feb 2007 15:09:12 +0100 Subject: anaconda update time needs to be improved (really) In-Reply-To: <45DAEEB2.8060700@robertoragusa.it> References: <45423F30.7030600@feuerpokemon.de> <45DAEEB2.8060700@robertoragusa.it> Message-ID: <1171980552.21468.5.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-02-20 at 13:50 +0100, Roberto Ragusa wrote: > So I renamed /mnt/sysconfig/sbin/ldconfig away and replaced with > a copy of /bin/true. The installation speed went up a lot, I'd say > it's 10 times faster now. > > I suppose that running ldconfig continously is not useful, it could > be done just once at the end of the upgrade. Not quite I think. Other (later-run) scripts might use those libraries so ldconfig has to be be run before them so they can work. Perhaps those calls could be clustered into one, but I don't know whether this can be done without changes to RPM. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 giallu at gmail.com Tue Feb 20 15:32:54 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 20 Feb 2007 16:32:54 +0100 Subject: automatic login with gdm Message-ID: Is it possible that last gdm update I did yesterday (1:2.16.5-1.fc6) broke the autologin feature ? I had it automatically logging into my wife's account but today at boot it gives: Authentication failed. Letters must be typed in the correct case. Did I mention now I can _not_ login with any other user??? ;) Cheers Gianluca From ajackson at redhat.com Tue Feb 20 15:24:58 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 20 Feb 2007 10:24:58 -0500 Subject: rawhide report: 20070220 changes In-Reply-To: <1171970537.18231.3.camel@gilboa-work-dev.localdomain> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> <1171970537.18231.3.camel@gilboa-work-dev.localdomain> Message-ID: <1171985098.13597.52.camel@localhost.localdomain> On Tue, 2007-02-20 at 13:22 +0200, Gilboa Davara wrote: > On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > > > > > Updated Packages: > > > libdrm-2.3.0-4.fc7 > > ------------------ > > * Mon Feb 19 2007 Adam Jackson 2.3.0-4 > > - Update nouveau patch > > - Fix License tag and other rpmlint noise > > OT question (that might not be related...) > Any idea when the latest DRI drivers (especially, mach64 and nv) will > imported into the kernel tree? nv already is, though I might be a bit behind. If there are significant mach64 changes since the last time Dave Airlie pushed stuff upstream, it's news to me, but I admit to not watching mach64 development very closely. - ajax From ajackson at redhat.com Tue Feb 20 15:44:02 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 20 Feb 2007 10:44:02 -0500 Subject: rawhide report: 20070220 changes In-Reply-To: <1171985098.13597.52.camel@localhost.localdomain> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> <1171970537.18231.3.camel@gilboa-work-dev.localdomain> <1171985098.13597.52.camel@localhost.localdomain> Message-ID: <1171986242.13597.53.camel@localhost.localdomain> On Tue, 2007-02-20 at 10:24 -0500, Adam Jackson wrote: > On Tue, 2007-02-20 at 13:22 +0200, Gilboa Davara wrote: > > On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > > > > > > > > Updated Packages: > > > > > libdrm-2.3.0-4.fc7 > > > ------------------ > > > * Mon Feb 19 2007 Adam Jackson 2.3.0-4 > > > - Update nouveau patch > > > - Fix License tag and other rpmlint noise > > > > OT question (that might not be related...) > > Any idea when the latest DRI drivers (especially, mach64 and nv) will > > imported into the kernel tree? > > nv already is, though I might be a bit behind. > > If there are significant mach64 changes since the last time Dave Airlie > pushed stuff upstream, it's news to me, but I admit to not watching > mach64 development very closely. I should clarify. The DRM is pretty close to current, afaik. Mesa is behindish; not sure what the right thing to do there is. - ajax From cra at WPI.EDU Tue Feb 20 15:59:15 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 20 Feb 2007 10:59:15 -0500 Subject: anaconda update time needs to be improved (really) In-Reply-To: <1171980552.21468.5.camel@gibraltar.stuttgart.redhat.com> References: <45423F30.7030600@feuerpokemon.de> <45DAEEB2.8060700@robertoragusa.it> <1171980552.21468.5.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20070220155915.GH3334@angus.ind.WPI.EDU> On Tue, Feb 20, 2007 at 03:09:12PM +0100, Nils Philippsen wrote: > > I suppose that running ldconfig continously is not useful, it could > > be done just once at the end of the upgrade. > > Not quite I think. Other (later-run) scripts might use those libraries > so ldconfig has to be be run before them so they can work. Perhaps those > calls could be clustered into one, but I don't know whether this can be > done without changes to RPM. I wonder if ld.so could be changed to run the cache update as needed, on-the-fly? From jwilson at redhat.com Tue Feb 20 16:58:50 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 20 Feb 2007 11:58:50 -0500 Subject: Call for beryl package maintenance help Message-ID: <45DB28CA.5080507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello there, So I've been a bit behind the curve keeping up with each beryl release. I don't actually *use* beryl most of the time or have time to track what all is going on upstream. That being the case, I would *really* like to hand these bits off to someone else to maintain, though I would be willing to either stick around as a co-maintainer or at least provide guidance, when needed. Anyone interested? - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF2yjKtO+bni+75QMRAm6wAKCI6sjwybzvQq/mFuxSPn5KjY+JawCdEJmJ mihJvF93rDmyw5GaZClccdM= =BVU1 -----END PGP SIGNATURE----- From gilboad at gmail.com Tue Feb 20 17:02:22 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 20 Feb 2007 19:02:22 +0200 Subject: rawhide report: 20070220 changes In-Reply-To: <1171985098.13597.52.camel@localhost.localdomain> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> <1171970537.18231.3.camel@gilboa-work-dev.localdomain> <1171985098.13597.52.camel@localhost.localdomain> Message-ID: <1171990942.25575.11.camel@gilboa-work-dev.localdomain> On Tue, 2007-02-20 at 10:24 -0500, Adam Jackson wrote: > On Tue, 2007-02-20 at 13:22 +0200, Gilboa Davara wrote: > > On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > > > > > > > > Updated Packages: > > > > > libdrm-2.3.0-4.fc7 > > > ------------------ > > > * Mon Feb 19 2007 Adam Jackson 2.3.0-4 > > > - Update nouveau patch > > > - Fix License tag and other rpmlint noise > > > > OT question (that might not be related...) > > Any idea when the latest DRI drivers (especially, mach64 and nv) will > > imported into the kernel tree? > > nv already is, though I might be a bit behind. > > If there are significant mach64 changes since the last time Dave Airlie > pushed stuff upstream, it's news to me, but I admit to not watching > mach64 development very closely. > > - ajax Here's the problem. The current mesa/DRI package (including the FC6 one) includes full DRI support for the mach64 chipsets. However, while considered stable [ 1], the kernel driver part of the equation has yet to be imported into the mainline kernel tree. - Gilboa [1] http://lists.freedesktop.org/archives/xorg/2006-November/019363.html From sundaram at fedoraproject.org Tue Feb 20 17:14:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 20 Feb 2007 22:44:56 +0530 Subject: Archives of Fedora IRC channels In-Reply-To: References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> Message-ID: <45DB2C90.8010600@fedoraproject.org> Max Spevack wrote: > On Mon, 19 Feb 2007, Rahul Sundaram wrote: > >> I did explain that in the original mail. For contributors and users to >> look back at what discussions happened in any Fedora channel at any >> time. Meetings planned or adhoc. Questions that were answered before etc. > > I wonder how useful something like that would end up being, just as a > bunch of raw data. At least the mailman archives are pretty easy to > navigate. Piles of IRC logs... shudder. > > Without some way of organizing the information in the logs, it kind of > seems like a waste of time, no? And wouldn't the time spent organizing > (or writing a program to organize) that info be better spent elsewhere > in Fedora? It's just a matter of running a bot (which already exists) on all the channels. I guess it wouldnt take more than an hour to setup for someone more familiar with it. Rahul From fedora at leemhuis.info Tue Feb 20 17:28:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Feb 2007 18:28:03 +0100 Subject: Archives of Fedora IRC channels In-Reply-To: <45DB2C90.8010600@fedoraproject.org> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> <45DB2C90.8010600@fedoraproject.org> Message-ID: <45DB2FA3.50603@leemhuis.info> Rahul Sundaram schrieb: > It's just a matter of running a bot (which already exists) on all the > channels. I guess it wouldnt take more than an hour to setup for someone > more familiar with it. Just playing devils advocate and quoting the last section from http://freenode.net/channel_guidelines.shtml : ---- If you're considering publishing channel logs, think it through. The freenode network is an interactive environment. Even on public channels, most users don't weigh their comments with the idea that they'll be enshrined in perpetuity. For that reason, few participants publish logs. If you're publishing logs on an ongoing basis, your channel topic should reflect that fact. Be sure to provide a way for users to make comments without logging, and get permission from the channel owners before you start. If you're thinking of "anonymizing" your logs (removing information that identifies the specific users), be aware that it's difficult to do it well?replies and general context often provide identifying information which is hard to filter. If you just want to publish a single conversation, be careful to get permission from each participant. Provide as much context as you can. Avoid the temptation to publish or distribute logs without permission in order to portray someone in a bad light. The reputation you save will most likely be your own. ---- I think the work and the implication to realize logging are not worth the trouble and the benefits. CU thl From david at fubar.dk Tue Feb 20 17:28:04 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 20 Feb 2007 12:28:04 -0500 Subject: rawhide report: 20070220 changes In-Reply-To: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> Message-ID: <1171992484.25545.25.camel@zelda.fubar.dk> On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > gphoto2-2.3.1-4.fc7 > ------------------- > * Mon Feb 19 2007 Jindrich Novy 2.3.1-4 > - ACL handling is now moved into HAL (#229230) This update removed a bit too much https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229230 so that bug is now reopened. David From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 20 17:35:02 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Feb 2007 18:35:02 +0100 Subject: Call for beryl package maintenance help In-Reply-To: <45DB28CA.5080507@redhat.com> References: <45DB28CA.5080507@redhat.com> Message-ID: <20070220183502.7f9cbd22@python3.es.egwn.lan> Jarod Wilson wrote : > So I've been a bit behind the curve keeping up with each beryl release. > I don't actually *use* beryl most of the time or have time to track what > all is going on upstream. > > That being the case, I would *really* like to hand these bits off to > someone else to maintain, though I would be willing to either stick > around as a co-maintainer or at least provide guidance, when needed. > > Anyone interested? I use it on my main workstation (hint: keep another networked machine close and be ready to log in and "killall beryl" :-)), so I'd definitely be interested in co-maintainership :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.19 0.42 0.44 From jacliburn at bellsouth.net Tue Feb 20 17:43:00 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Tue, 20 Feb 2007 11:43:00 -0600 Subject: F7t2 and QA Meeting In-Reply-To: <1171991344.3072.41.camel@metroid.rdu.redhat.com> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> Message-ID: <45DB3324.3040407@bellsouth.net> Will Woods wrote: > As Jesse announced on fedora-devel-list, the code freeze for Fedora 7, > Test 2 is today (this evening, US EST). I'm not sure when you intend to freeze the kernel for F7T2 (perhaps today?), but the current kernel -git, along with the existing rawhide 2930 and 2932 kernels (and maybe the previous one, too), won't boot from a VIA SATA 6420, 6421, or 8237A controller. I'd guess this affects a pretty good number F7 testers who use SATA on a VIA chipset motherboard. A patch to fix the problem was accepted into the libata tree this morning, so it should show up in the mainline kernel -git soon. Jay From green at redhat.com Tue Feb 20 17:44:57 2007 From: green at redhat.com (Anthony Green) Date: Tue, 20 Feb 2007 09:44:57 -0800 Subject: Creating a jackuser group In-Reply-To: <200702200022.18654.dblistsub-fedora@yahoo.it> References: <1170790351.3564.12.camel@localhost.localdomain> <200702191901.03579.dblistsub-fedora@yahoo.it> <1171921645.9028.34.camel@localhost.localdomain> <200702200022.18654.dblistsub-fedora@yahoo.it> Message-ID: <1171993497.9028.54.camel@localhost.localdomain> On Tue, 2007-02-20 at 00:22 +0100, Davide Bolcioni wrote: > I believe consolehelper(8) is intended to do exactly that, see userhelper(8) > which is the workhorse invoked by consolehelper(8). I don't think this can be made to work if it forces jackd to run as root. I'd still like to go ahead with the jackuser group plan. AG From wwoods at redhat.com Tue Feb 20 17:54:39 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 20 Feb 2007 12:54:39 -0500 Subject: F7t2 and QA Meeting In-Reply-To: <45DB3324.3040407@bellsouth.net> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> Message-ID: <1171994079.3072.47.camel@metroid.rdu.redhat.com> On Tue, 2007-02-20 at 11:43 -0600, Jay Cliburn wrote: > Will Woods wrote: > > > As Jesse announced on fedora-devel-list, the code freeze for Fedora 7, > > Test 2 is today (this evening, US EST). > > I'm not sure when you intend to freeze the kernel for F7T2 (perhaps > today?), but the current kernel -git, along with the existing rawhide > 2930 and 2932 kernels (and maybe the previous one, too), won't boot from > a VIA SATA 6420, 6421, or 8237A controller. I'd guess this affects a > pretty good number F7 testers who use SATA on a VIA chipset motherboard. > > A patch to fix the problem was accepted into the libata tree this > morning, so it should show up in the mainline kernel -git soon. kernel-2.6.20-1.2932 is fairly explodey in general - it BUGs in ahci_init on my ICH6 SATA machine. We won't be releasing with this one. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Tue Feb 20 18:33:49 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 20 Feb 2007 13:33:49 -0500 Subject: Archives of Fedora IRC channels In-Reply-To: <45DB2FA3.50603@leemhuis.info> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> <45DB2C90.8010600@fedoraproject.org> <45DB2FA3.50603@leemhuis.info> Message-ID: <1171996429.28200.26.camel@cutter> On Tue, 2007-02-20 at 18:28 +0100, Thorsten Leemhuis wrote: > Rahul Sundaram schrieb: > > > It's just a matter of running a bot (which already exists) on all the > > channels. I guess it wouldnt take more than an hour to setup for someone > > more familiar with it. > > Just playing devils advocate and quoting the last section from > http://freenode.net/channel_guidelines.shtml : > > ---- > If you're considering publishing channel logs, think it through. The > freenode network is an interactive environment. Even on public channels, > most users don't weigh their comments with the idea that they'll be > enshrined in perpetuity. For that reason, few participants publish logs. > > If you're publishing logs on an ongoing basis, your channel topic should > reflect that fact. Be sure to provide a way for users to make comments > without logging, and get permission from the channel owners before you > start. If you're thinking of "anonymizing" your logs (removing > information that identifies the specific users), be aware that it's > difficult to do it well?replies and general context often provide > identifying information which is hard to filter. > > If you just want to publish a single conversation, be careful to get > permission from each participant. Provide as much context as you can. > Avoid the temptation to publish or distribute logs without permission in > order to portray someone in a bad light. The reputation you save will > most likely be your own. > ---- > > I think the work and the implication to realize logging are not worth > the trouble and the benefits. +1 no logs. -sv From jdieter at gmail.com Tue Feb 20 18:39:01 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 20 Feb 2007 20:39:01 +0200 Subject: Call for beryl package maintenance help In-Reply-To: <45DB28CA.5080507@redhat.com> References: <45DB28CA.5080507@redhat.com> Message-ID: <1171996741.6950.3.camel@jndwidescreen.lesbg.loc> On Tue, 2007-02-20 at 11:58 -0500, Jarod Wilson wrote: > Hello there, > > So I've been a bit behind the curve keeping up with each beryl release. > I don't actually *use* beryl most of the time or have time to track what > all is going on upstream. > > That being the case, I would *really* like to hand these bits off to > someone else to maintain, though I would be willing to either stick > around as a co-maintainer or at least provide guidance, when needed. > > Anyone interested? > > - -- > Jarod Wilson > jwilson at redhat.com I have switched from Compiz to Beryl on my main desktop. I don't maintain any packages, so Matthias is probably much more qualified than I am for this, but I'll at least put my name out there as someone interested in co-maintainership. Jonathan Dieter -------------- 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 jwilson at redhat.com Tue Feb 20 18:58:17 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 20 Feb 2007 13:58:17 -0500 Subject: Call for beryl package maintenance help In-Reply-To: <20070220183502.7f9cbd22@python3.es.egwn.lan> References: <45DB28CA.5080507@redhat.com> <20070220183502.7f9cbd22@python3.es.egwn.lan> Message-ID: <45DB44C9.9010706@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias Saou wrote: > Jarod Wilson wrote : > >> So I've been a bit behind the curve keeping up with each beryl release. >> I don't actually *use* beryl most of the time or have time to track what >> all is going on upstream. >> >> That being the case, I would *really* like to hand these bits off to >> someone else to maintain, though I would be willing to either stick >> around as a co-maintainer or at least provide guidance, when needed. >> >> Anyone interested? > > I use it on my main workstation (hint: keep another networked machine > close and be ready to log in and "killall beryl" :-)), so I'd definitely > be interested in co-maintainership :-) Sold. /me tries to remember exactly what needs to be done to add a co-maintainer... FYI, I'm pushing 0.1.9999.2 beryl bits through the build system today. - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF20TJtO+bni+75QMRAutiAJ96F+JYT1Hj9gNR3ZgIzExUqzTmOACfQSGX +AKXunAz9Eils5RwE15iJoM= =wT0r -----END PGP SIGNATURE----- From jwilson at redhat.com Tue Feb 20 18:59:44 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 20 Feb 2007 13:59:44 -0500 Subject: Call for beryl package maintenance help In-Reply-To: <1171996741.6950.3.camel@jndwidescreen.lesbg.loc> References: <45DB28CA.5080507@redhat.com> <1171996741.6950.3.camel@jndwidescreen.lesbg.loc> Message-ID: <45DB4520.9040708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Dieter wrote: > On Tue, 2007-02-20 at 11:58 -0500, Jarod Wilson wrote: >> Hello there, >> >> So I've been a bit behind the curve keeping up with each beryl release. >> I don't actually *use* beryl most of the time or have time to track what >> all is going on upstream. >> >> That being the case, I would *really* like to hand these bits off to >> someone else to maintain, though I would be willing to either stick >> around as a co-maintainer or at least provide guidance, when needed. >> >> Anyone interested? >> >> - -- >> Jarod Wilson >> jwilson at redhat.com > > I have switched from Compiz to Beryl on my main desktop. I don't > maintain any packages, so Matthias is probably much more qualified than > I am for this, but I'll at least put my name out there as someone > interested in co-maintainership. Do you have cvs access? If you don't maintain any packages already, I'm not sure you do, or what the process is to get it w/o submitting your own new package... At least for the moment, we'll roll with adding Matthias as a co-maintainer. - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF20UgtO+bni+75QMRAozqAJ9/jHXGZuRoXdnbVG+Rp3UVS3d1JwCgsXNb 7MG/Ho/wHE47QyWCqA1/Vqo= =8OMU -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Tue Feb 20 19:07:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 00:37:08 +0530 Subject: Call for beryl package maintenance help In-Reply-To: <45DB4520.9040708@redhat.com> References: <45DB28CA.5080507@redhat.com> <1171996741.6950.3.camel@jndwidescreen.lesbg.loc> <45DB4520.9040708@redhat.com> Message-ID: <45DB46DC.1070601@fedoraproject.org> Jarod Wilson wrote: > Do you have cvs access? If you don't maintain any packages already, I'm > not sure you do, or what the process is to get it w/o submitting your > own new package... This is the policy being drafted for that. http://fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership Rahul From markw at mohawksoft.com Tue Feb 20 18:50:41 2007 From: markw at mohawksoft.com (markw at mohawksoft.com) Date: Tue, 20 Feb 2007 13:50:41 -0500 (EST) Subject: PHP/MCache Beta Help, web cluster In-Reply-To: <20070220170004.D98617361F@hormel.redhat.com> References: <20070220170004.D98617361F@hormel.redhat.com> Message-ID: <17906.24.91.171.78.1171997441.squirrel@mail.mohawksoft.com> Hey, I have an extension to PHP that enables the session management extension to spread across multiple web servers easily. It used to be called "msession" and an old broken version is still included in PHP. I have just finished up a new version of it, fixed a lot of bugs, and added a better persistent session storage system. If you are struggling with a number of web servers behind a load balancer and need a solution, I'd like you to try MCache and tell me what you think. I need testers. It has been lightly tested on PHP 4.4.5 and should work on later versions. It is in beta and I am looking for help with it. MCache is GPL and the Phoenix library it requires is LGPL. You can find it at http://www.mohawksoft.org. Look at the "MCache Handbook" for more information. There are two tarballs under "Download." What I need: Does it compile on your machines? (If not, what are your problems?) How does it perform? It is probably not 64bit compatible, but I am willing to work with someone with a 64 bit machine to make it so. Anything else you want to help out with. I think this is a neat system for reasonably sized web farms and could potentially make clustered PHP a snap. From drago01 at gmail.com Tue Feb 20 19:16:21 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 20 Feb 2007 20:16:21 +0100 Subject: anaconda update time needs to be improved (really) (speed up yum/ld config) In-Reply-To: <20070220155915.GH3334@angus.ind.WPI.EDU> References: <45423F30.7030600@feuerpokemon.de> <45DAEEB2.8060700@robertoragusa.it> <1171980552.21468.5.camel@gibraltar.stuttgart.redhat.com> <20070220155915.GH3334@angus.ind.WPI.EDU> Message-ID: <45DB4905.9070900@gmail.com> Chuck Anderson wrote: > On Tue, Feb 20, 2007 at 03:09:12PM +0100, Nils Philippsen wrote: > >>> I suppose that running ldconfig continously is not useful, it could >>> be done just once at the end of the upgrade. >>> >> Not quite I think. Other (later-run) scripts might use those libraries >> so ldconfig has to be be run before them so they can work. Perhaps those >> calls could be clustered into one, but I don't know whether this can be >> done without changes to RPM. >> > > I wonder if ld.so could be changed to run the cache update as needed, > on-the-fly? > > should be possible (using inotify and only add the new created files to the cache) but for this we need a ld daemon (dunno if its possible to update only a part of the cache) /sbin/ldconfig can check if the daemon is running and if yes just do nothing, else work as it used to be (like it did before). (still works when daemon is not running). this would also speed up yum updates too. about yum: afaik currently yum works like this get metadata for repo A get metadata for repo B ... parse metadata for repo A parse metadata fro repo B ... why waiting so long until parsing metadata of repo B ? why not do it after download while downloading b? so yum can just create a thread for each repo to do the download + parse for each repo in a thread and do this for many repos in parrallel. this should speed up yum init (dunno by how much and dunno if it benifits from smp systems or not but it should) but why only doing this for repo parsing? why not for getting package headers (there are not that big so bandwith should not be the bottleneck, but waiting for nothing is it) I don't have any code (and so no benchmarks) but I think this ideas could speed up the install/update of packages alot (not only a few %). From jdieter at gmail.com Tue Feb 20 19:27:40 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 20 Feb 2007 21:27:40 +0200 Subject: Call for beryl package maintenance help In-Reply-To: <45DB4520.9040708@redhat.com> References: <45DB28CA.5080507@redhat.com> <1171996741.6950.3.camel@jndwidescreen.lesbg.loc> <45DB4520.9040708@redhat.com> Message-ID: <1171999660.6950.8.camel@jndwidescreen.lesbg.loc> On Tue, 2007-02-20 at 13:59 -0500, Jarod Wilson wrote: > Do you have cvs access? If you don't maintain any packages already, I'm > not sure you do, or what the process is to get it w/o submitting your > own new package... No, I don't have cvs access. I was just interested in helping out with Fedora and thought this might be an opportunity. I read the wiki page Rahul mentioned, and it looks like it might be a better idea to wait until all the ACL stuff is worked out. > > At least for the moment, we'll roll with adding Matthias as a co-maintainer. Sounds like a good idea. :) Jonathan -------------- 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 jwilson at redhat.com Tue Feb 20 19:30:25 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 20 Feb 2007 14:30:25 -0500 Subject: Call for beryl package maintenance help In-Reply-To: <1171999660.6950.8.camel@jndwidescreen.lesbg.loc> References: <45DB28CA.5080507@redhat.com> <1171996741.6950.3.camel@jndwidescreen.lesbg.loc> <45DB4520.9040708@redhat.com> <1171999660.6950.8.camel@jndwidescreen.lesbg.loc> Message-ID: <45DB4C51.8080800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Dieter wrote: > On Tue, 2007-02-20 at 13:59 -0500, Jarod Wilson wrote: >> Do you have cvs access? If you don't maintain any packages already, I'm >> not sure you do, or what the process is to get it w/o submitting your >> own new package... > No, I don't have cvs access. I was just interested in helping out with > Fedora and thought this might be an opportunity. I read the wiki page > Rahul mentioned, and it looks like it might be a better idea to wait > until all the ACL stuff is worked out. >> At least for the moment, we'll roll with adding Matthias as a co-maintainer. > Sounds like a good idea. :) You've got my endorsement to be the 3rd wheel, per that wiki page Rahul linked to, once that's feasible. :) - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF20xRtO+bni+75QMRAkWnAJ9IPSOvzCorKWu5ELO3E1DqxdquuACgyWSE FpwlSEHMPi3qLotxsA5bKjQ= =l1LP -----END PGP SIGNATURE----- From tbrinkman at sbcglobal.net Tue Feb 20 18:41:54 2007 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Tue, 20 Feb 2007 12:41:54 -0600 Subject: F7t2 and QA Meeting In-Reply-To: <45DB3324.3040407@bellsouth.net> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> Message-ID: <200702201241.54939.tbrinkman@sbcglobal.net> On Tuesday 20 February 2007, Jay Cliburn wrote: > Will Woods wrote: > > As Jesse announced on fedora-devel-list, the code freeze for > > Fedora 7, Test 2 is today (this evening, US EST). > > I'm not sure when you intend to freeze the kernel for F7T2 > (perhaps today?), but the current kernel -git, along with the > existing rawhide 2930 and 2932 kernels (and maybe the previous > one, too), won't boot from a VIA SATA 6420, 6421, or 8237A > controller. I'd guess this affects a pretty good number F7 > testers who use SATA on a VIA chipset motherboard. > > A patch to fix the problem was accepted into the libata tree this > morning, so it should show up in the mainline kernel -git soon. > > Jay +1 Mine is a 6420. Boot is on pata 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) ....but I have a sata storage drive that prevents boot. 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 2.6.20-1.2925.fc7 boots with no problems -- Tom Brinkman Corpus Christi, Texas From stickster at gmail.com Tue Feb 20 19:55:26 2007 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 20 Feb 2007 14:55:26 -0500 Subject: Archives of Fedora IRC channels In-Reply-To: <45DB2C90.8010600@fedoraproject.org> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> <45DB2C90.8010600@fedoraproject.org> Message-ID: <1172001326.30064.17.camel@localhost.localdomain> On Tue, 2007-02-20 at 22:44 +0530, Rahul Sundaram wrote: > Max Spevack wrote: > > On Mon, 19 Feb 2007, Rahul Sundaram wrote: > > > >> I did explain that in the original mail. For contributors and users to > >> look back at what discussions happened in any Fedora channel at any > >> time. Meetings planned or adhoc. Questions that were answered before etc. > > > > I wonder how useful something like that would end up being, just as a > > bunch of raw data. At least the mailman archives are pretty easy to > > navigate. Piles of IRC logs... shudder. > > > > Without some way of organizing the information in the logs, it kind of > > seems like a waste of time, no? And wouldn't the time spent organizing > > (or writing a program to organize) that info be better spent elsewhere > > in Fedora? > > It's just a matter of running a bot (which already exists) on all the > channels. I guess it wouldnt take more than an hour to setup for someone > more familiar with it. I could see running one on #fedora-meeting, but the folks having meetings there aren't having any problem getting their minutes and logs out, so this seems like overkill. Speaking for Docs (or at least as a single FDSCo member), I doubt we'd want one in our channel. It's an important social structure to have graduations of publicity, from highest to lowest: 1. Web pages, wiki, blogs 2. Mailing lists 3. IRC/IM 4. Private email 5. IRC/IM PrivMsg 6. Phone 7. PGP/GPG-encrypted ninja carrier pigeon? We can ensure transparency by carrying things up the stack as needed. It's an important part of FOSS leadership to actually *do* that work, and we should deal with failures in a less drastic way than by eliminating levels of privacy that I think are necessary social structures. People need to feel they have a place to go "off the record" and relax a little bit, and not worry about every word being tracked for all eternity. There's already plenty of ways to embarrass oneself publicly (some of which have absolutely nothing to do with pubs)! So, +1 to "no bots" generally, except in #fedora-meeting where it would be expected and not unwelcome, even if completely redundant. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 zaitcev at redhat.com Tue Feb 20 20:51:47 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 20 Feb 2007 12:51:47 -0800 Subject: Archives of Fedora IRC channels In-Reply-To: <1172001326.30064.17.camel@localhost.localdomain> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> <45DB2C90.8010600@fedoraproject.org> <1172001326.30064.17.camel@localhost.localdomain> Message-ID: <20070220125147.1b8dc6c1.zaitcev@redhat.com> On Tue, 20 Feb 2007 14:55:26 -0500, "Paul W. Frields" wrote: > [...] People need to feel they have a place to go "off the > record" and relax a little bit, and not worry about every word being > tracked for all eternity. There's already plenty of ways to embarrass > oneself publicly (some of which have absolutely nothing to do with > pubs)! Such people need to stay away from a computer, I'm afraid. To conunt on an IRC channel not being logged is hugely retarded. I find the the argument for not doing it officially persuasive, but mostly because of the waste of resources angle. -- Pete From jkeating at redhat.com Tue Feb 20 22:58:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 17:58:15 -0500 Subject: DVD only for Fedora "Classic" spin? Message-ID: <200702201758.15925.jkeating@redhat.com> For Test2, I'm planning on doing the Fedora "Classic" spin for folks to work with. Doing the Everything spin at this point is just going to take up a LOT of bandwidth / space for such a temporary thing. I do believe we'll have a Desktop (Gnome) LiveCD as well, perhaps a KDE one if the KDE folks kick some butt. That said, we've toyed with the idea of doing DVD iso only for the Classic (and Everything) spin. Easy enough for me to do in pungi, I'll just set the cd size to 4.5G and produce one iso. So, how much hate will be thrown my way if we just do a DVD sized iso for Test2's Classic spin? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mike at miketc.com Tue Feb 20 23:24:05 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 20 Feb 2007 17:24:05 -0600 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <1172013845.6741.2.camel@scrappy.miketc.com> On Tue, 2007-02-20 at 17:58 -0500, Jesse Keating wrote: > For Test2, I'm planning on doing the Fedora "Classic" spin for folks to work > with. Doing the Everything spin at this point is just going to take up a LOT > of bandwidth / space for such a temporary thing. I do believe we'll have a > Desktop (Gnome) LiveCD as well, perhaps a KDE one if the KDE folks kick some > butt. > > That said, we've toyed with the idea of doing DVD iso only for the Classic > (and Everything) spin. Easy enough for me to do in pungi, I'll just set the > cd size to 4.5G and produce one iso. > > So, how much hate will be thrown my way if we just do a DVD sized iso for > Test2's Classic spin? How does that affect doing nfs/network based installs? Last I tired (during test 1 and before ), I couldn't get them to work, except against the ISO's. And if using DVD iso means having to mount it before hand, and jumping through couple more hurdles, then for me anyway, it suxors hahahhaa. I can burn the DVD I guess, but just rather not if don't have to. Or have to learn how to do it differently. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From jkeating at redhat.com Tue Feb 20 23:29:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 18:29:28 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <1172013845.6741.2.camel@scrappy.miketc.com> References: <200702201758.15925.jkeating@redhat.com> <1172013845.6741.2.camel@scrappy.miketc.com> Message-ID: <200702201829.28577.jkeating@redhat.com> On Tuesday 20 February 2007 18:24, Mike Chambers wrote: > How does that affect doing nfs/network based installs? ?Last I tired > (during test 1 and before ), I couldn't get them to work, except against > the ISO's. ?And if using DVD iso means having to mount it before hand, > and jumping through couple more hurdles, then for me anyway, it suxors > hahahhaa. ?I can burn the DVD I guess, but just rather not if don't have > to. ?Or have to learn how to do it differently. You shouldn't have to do anything special to do a network install against the single DVD iso. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From motk at internode.on.net Tue Feb 20 23:32:19 2007 From: motk at internode.on.net (Rob K) Date: Wed, 21 Feb 2007 10:32:19 +1100 Subject: Archives of Fedora IRC channels In-Reply-To: <1171996429.28200.26.camel@cutter> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> <45DB2C90.8010600@fedoraproject.org> <45DB2FA3.50603@leemhuis.info> <1171996429.28200.26.camel@cutter> Message-ID: <45DB8503.9010406@internode.on.net> > no logs. What Seth said. > -sv -- Rob k From mike at miketc.com Tue Feb 20 23:33:32 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 20 Feb 2007 17:33:32 -0600 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201829.28577.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> <1172013845.6741.2.camel@scrappy.miketc.com> <200702201829.28577.jkeating@redhat.com> Message-ID: <1172014412.2311.1.camel@scrappy.miketc.com> On Tue, 2007-02-20 at 18:29 -0500, Jesse Keating wrote: > You shouldn't have to do anything special to do a network install against the > single DVD iso. Well, I tried before and was told that you had to manually mount it, unless the cd isos, in which I just download to my already nfs mounted dir and it just works. So you can just d/l the dvd iso to an nfs dir and you can install gainst? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From motk at internode.on.net Tue Feb 20 23:34:16 2007 From: motk at internode.on.net (Rob K) Date: Wed, 21 Feb 2007 10:34:16 +1100 Subject: Archives of Fedora IRC channels In-Reply-To: <20070220125147.1b8dc6c1.zaitcev@redhat.com> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> <45DB2C90.8010600@fedoraproject.org> <1172001326.30064.17.camel@localhost.localdomain> <20070220125147.1b8dc6c1.zaitcev@redhat.com> Message-ID: <45DB8578.5030107@internode.on.net> Pete Zaitcev wrote: > Such people need to stay away from a computer, I'm afraid. To conunt on > an IRC channel not being logged is hugely retarded. I find the the > argument for not doing it officially persuasive, but mostly because > of the waste of resources angle. The logging doesn't matter as such - I keep logs, and grep for what I need, but publishing them is a rotten idea. The fedora-* channels right now are plain and simple, they're best left that way. -- Rob K From giallu at gmail.com Tue Feb 20 23:35:29 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Feb 2007 00:35:29 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201829.28577.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> <1172013845.6741.2.camel@scrappy.miketc.com> <200702201829.28577.jkeating@redhat.com> Message-ID: On 2/21/07, Jesse Keating wrote: > On Tuesday 20 February 2007 18:24, Mike Chambers wrote: > > How does that affect doing nfs/network based installs? Last I tired > > (during test 1 and before ), I couldn't get them to work, except against > > the ISO's. And if using DVD iso means having to mount it before hand, > > and jumping through couple more hurdles, then for me anyway, it suxors > > hahahhaa. I can burn the DVD I guess, but just rather not if don't have > > to. Or have to learn how to do it differently. > > You shouldn't have to do anything special to do a network install against the > single DVD iso. > Like with NFS/FTP/HTTP or what ? From jkeating at redhat.com Tue Feb 20 23:57:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 18:57:15 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <1172014412.2311.1.camel@scrappy.miketc.com> References: <200702201758.15925.jkeating@redhat.com> <200702201829.28577.jkeating@redhat.com> <1172014412.2311.1.camel@scrappy.miketc.com> Message-ID: <200702201857.15609.jkeating@redhat.com> On Tuesday 20 February 2007 18:33, Mike Chambers wrote: > Well, I tried before and was told that you had to manually mount it, > unless the cd isos, in which I just download to my already nfs mounted > dir and it just works. ?So you can just d/l the dvd iso to an nfs dir > and you can install gainst? I do believe so. I would have to verify personally, but in this case I think it will work as it will just mount the isos that are sitting there. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Feb 20 23:58:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Feb 2007 18:58:41 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: References: <200702201758.15925.jkeating@redhat.com> <200702201829.28577.jkeating@redhat.com> Message-ID: <200702201858.41438.jkeating@redhat.com> On Tuesday 20 February 2007 18:35, Gianluca Sforna wrote: > Like with NFS/FTP/HTTP or what ? NFS you can install from a directory that just has the DVD iso file in it. ftp you'll need to loopback mount it as disc1 in a directory available via ftp. Not sure if this works for http, I've only tested ftp. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Wed Feb 21 00:04:03 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Feb 2007 01:04:03 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201858.41438.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> <200702201829.28577.jkeating@redhat.com> <200702201858.41438.jkeating@redhat.com> Message-ID: On 2/21/07, Jesse Keating wrote: > On Tuesday 20 February 2007 18:35, Gianluca Sforna wrote: > > Like with NFS/FTP/HTTP or what ? > > NFS you can install from a directory that just has the DVD iso file in it. > > ftp you'll need to loopback mount it as disc1 in a directory available via > ftp. Not sure if this works for http, I've only tested ftp. > Thanks. Sorry for bothering but I have this cute little pet on my desk (http://www.norhtec.com/products/mcjr/index.html) so I'm trying to determine which path is best for an installation. Do you think is there a significative advantage (in terms of needed RAM) between those? I have 128Mb total so I guess every free bit counts... From katzj at redhat.com Wed Feb 21 00:20:27 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Feb 2007 19:20:27 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201858.41438.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> <200702201829.28577.jkeating@redhat.com> <200702201858.41438.jkeating@redhat.com> Message-ID: <1172017227.14119.0.camel@aglarond.local> On Tue, 2007-02-20 at 18:58 -0500, Jesse Keating wrote: > On Tuesday 20 February 2007 18:35, Gianluca Sforna wrote: > > Like with NFS/FTP/HTTP or what ? > > NFS you can install from a directory that just has the DVD iso file in it. > > ftp you'll need to loopback mount it as disc1 in a directory available via > ftp. Not sure if this works for http, I've only tested ftp. Actually, you can loopback mount the DVD as whatever you want -- just point to the directory where you mounted it Jeremy From davej at redhat.com Wed Feb 21 03:44:15 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Feb 2007 22:44:15 -0500 Subject: F7t2 and QA Meeting In-Reply-To: <45DB3324.3040407@bellsouth.net> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> Message-ID: <20070221034415.GC32402@redhat.com> On Tue, Feb 20, 2007 at 11:43:00AM -0600, Jay Cliburn wrote: > Will Woods wrote: > > > As Jesse announced on fedora-devel-list, the code freeze for Fedora 7, > > Test 2 is today (this evening, US EST). > > I'm not sure when you intend to freeze the kernel for F7T2 (perhaps > today?), but the current kernel -git, along with the existing rawhide > 2930 and 2932 kernels (and maybe the previous one, too), won't boot from > a VIA SATA 6420, 6421, or 8237A controller. I'd guess this affects a > pretty good number F7 testers who use SATA on a VIA chipset motherboard. > > A patch to fix the problem was accepted into the libata tree this > morning, so it should show up in the mainline kernel -git soon. That specific bug /should/ be fixed in the fedora kernel that'll hit rawhide tomorrow. Dave -- http://www.codemonkey.org.uk From bruno at wolff.to Wed Feb 21 04:44:53 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 20 Feb 2007 22:44:53 -0600 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <20070221044453.GA13708@wolff.to> On Tue, Feb 20, 2007 at 17:58:15 -0500, Jesse Keating wrote: > For Test2, I'm planning on doing the Fedora "Classic" spin for folks to work > with. Doing the Everything spin at this point is just going to take up a LOT > of bandwidth / space for such a temporary thing. I do believe we'll have a > Desktop (Gnome) LiveCD as well, perhaps a KDE one if the KDE folks kick some > butt. > > That said, we've toyed with the idea of doing DVD iso only for the Classic > (and Everything) spin. Easy enough for me to do in pungi, I'll just set the > cd size to 4.5G and produce one iso. > > So, how much hate will be thrown my way if we just do a DVD sized iso for > Test2's Classic spin? I'll be happy if I can install off the boot iso. I am just waiting for kernel and anaconda updates that fix the problems blocking me from installing. I'll try again after test 2 is released to test the kernel update. When I checked anaconda earlier today, there still wasn't a changelog entry indicating that multiple software raid arrays are being properly detected during install now. So I don't have much hope of being able to do more than test the kernel update. From esr at thyrsus.com Wed Feb 21 08:03:50 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 03:03:50 -0500 (EST) Subject: Goodbye, Fedora Message-ID: <20070221080350.3711A3C1AC6@snark.thyrsus.com> After thirteen years as a loyal Red Hat and Fedora user, I reached my limit today, when an attempt to upgrade one (1) package pitched me into a four-hour marathon of dependency chasing, at the end of which an attempt to get around a trivial file conflict rendered my system unusable. The proximate causes of this failure were (1) incompetent repository maintenance, making any nontrivial upgrade certain to founder on a failed dependency, and (2) the fact that rpm is not statically linked -- so it's possible to inadvertently remove a shared library it depends on and be unrecoverably screwed. But the underlying problems run much deeper. Over the last five years, I've watched Red Hat/Fedora throw away what was at one time a near-unassailable lead in technical prowess, market share and community prestige. The blunders have been legion on both technical and political levels. They have included, but were not limited to: * Chronic governance problems. * Persistent failure to maintain key repositories in a sane, consistent state from which upgrades might actually be possible. * A murky, poorly-documented, over-complex submission process. * Allowing RPM development to drift and stagnate -- then adding another layer of complexity, bugs, and wretched performance with yum. * Effectively abandoning the struggle for desktop market share. * Failure to address the problem of proprietary multimedia formats with any attitude other than blank denial. In retrospect, I should probably have cut my losses years ago. But I had so much history with Red-Hat/Fedora, and had invested so much effort in trying to fix the problems, that it was hard to even imagine breaking away. If I thought the state of Fedora were actually improving, I might hang in there. But it isn't. I've been on the fedora-devel list for years, and the trend is clear. The culture of the project's core group has become steadily more unhealthy, more inward-looking, more insistent on narrow "free software" ideological purity, and more disconnected from the technical and evangelical challenges that must be met to make Linux a world-changing success that liberates a majority of computer users. I have watched Ubuntu rise to these challenges as Fedora fell away from them. Canonical's recent deal with Linspire, which will give Linux users legal access to WMF and other key proprietary codecs, is precisely the sort of thing Red-Hat/Fedora could and should have taken the lead in. Not having done so bespeaks a failure of vision which I now believe will condemn Fedora to a shrinking niche in the future. This afternoon, I installed Edgy Eft on my main development machine -- from one CD, not five. In less than three hours' work I was able to recreate the key features of my day-to-day toolkit. The after-installation mass upgrade to current packages, always a frightening prospect under Fedora, went off without a hitch. I'm not expecting Ubuntu to be perfect, but I am now certain it will be enough better to compensate me for the fact that I need to learn a new set of administration tools. Fedora, you had every advantage, and you had my loyalty, and you blew it. And that is a damn, dirty shame. -- Eric S. Raymond From gilboad at gmail.com Wed Feb 21 08:09:53 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 10:09:53 +0200 Subject: rawhide report: 20070220 changes In-Reply-To: <1171986242.13597.53.camel@localhost.localdomain> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> <1171970537.18231.3.camel@gilboa-work-dev.localdomain> <1171985098.13597.52.camel@localhost.localdomain> <1171986242.13597.53.camel@localhost.localdomain> Message-ID: <1172045393.9201.0.camel@gilboa-work-dev.localdomain> On Tue, 2007-02-20 at 10:44 -0500, Adam Jackson wrote: > On Tue, 2007-02-20 at 10:24 -0500, Adam Jackson wrote: > > On Tue, 2007-02-20 at 13:22 +0200, Gilboa Davara wrote: > > > On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > > > > > > > > > > > Updated Packages: > > > > > > > libdrm-2.3.0-4.fc7 > > > > ------------------ > > > > * Mon Feb 19 2007 Adam Jackson 2.3.0-4 > > > > - Update nouveau patch > > > > - Fix License tag and other rpmlint noise > > > > > > OT question (that might not be related...) > > > Any idea when the latest DRI drivers (especially, mach64 and nv) will > > > imported into the kernel tree? > > > > nv already is, though I might be a bit behind. > > > > If there are significant mach64 changes since the last time Dave Airlie > > pushed stuff upstream, it's news to me, but I admit to not watching > > mach64 development very closely. > > I should clarify. The DRM is pretty close to current, afaik. Mesa is > behindish; not sure what the right thing to do there is. > > - ajax > Would the latest Mesa/DRM combo will find it's way into F7? - Gilboa From giallu at gmail.com Wed Feb 21 08:11:11 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Feb 2007 09:11:11 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: On 2/21/07, Eric S. Raymond wrote: > Fedora, you had every advantage, and you had my loyalty, and you blew it. > And that is a damn, dirty shame. /me bets this is going to be one of the longest threads in the fedora-devel history... From Christian.Iseli at licr.org Wed Feb 21 08:17:38 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 21 Feb 2007 09:17:38 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <20070221091738.0794fe3d@ludwig-alpha.unil.ch> +-------------------+ .:\:\:/:/:. | PLEASE DO NOT | :.:\:\:/:/:.: | FEED THE TROLLS | :=.' - - '.=: | | '=(\ 9 9 /)=' | Thank you, | ( (_) ) | Management | /`-vvv-'\ +-------------------+ / \ | | @@@ / /|,,,,,|\ \ | | @@@ /_// /^\ \\_\ @x@@x@ | | |/ WW( ( ) )WW \||||/ | | \| __\,,\ /,,/__ \||/ | | | (______Y______) /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ================================================================== From gilboad at gmail.com Wed Feb 21 08:30:58 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 10:30:58 +0200 Subject: Goodbye, Fedora In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172046658.9201.11.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 09:11 +0100, Gianluca Sforna wrote: > On 2/21/07, Eric S. Raymond wrote: > > Fedora, you had every advantage, and you had my loyalty, and you blew it. > > And that is a damn, dirty shame. > > /me bets this is going to be one of the longest threads in the > fedora-devel history... > *Sigh* - Gilboa "Thankfully my cable provider doesn't charge me for extra bandwidth because this is gonna get very ugly, very fast... kinda like the ESR's previous drive by posting" Davara. From miles.lane at gmail.com Wed Feb 21 08:38:08 2007 From: miles.lane at gmail.com (Miles Lane) Date: Wed, 21 Feb 2007 00:38:08 -0800 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: Regarding package management, I have found apt to work much better that either SuSE's YAST or Redhat's yum. dpkg and rpm are both challenging for me, and I have struggled with dependency issues with each. I tried to track OpenSuSE and found it completely undoable. Now I track Rawhide and Ubuntu's development packages. I have had repeated success upgrading installations to Ubuntu's development tree. What I appreciate in Fedora is the SELinux integration and all the patches that get applied to the kernels. The kernel expertise at Redhat is fantastic. Although I know that eventually the Gnome folks will whittle all the beryl options down to a manageable few, with a more spare configuration UI, compiz lacks any configuration UI. Since Ubuntu has gone with Beryl and Fedora is more committed to compiz, I have found it easier to get a pretty solid 3D desktop under Ubuntu. Currently, I have almost identical desktop environments under the Fedora and Ubuntu development installations. I contribute bug reports to both. I find that Fedora bugs tend to get more rapid fixes that Ubuntu. This is really important to me. I contribute testing to Linux desktops because I want to see Linux and OSS contribute to empowering users globally. I have been contributing for about eight years, and have been very happy with the progress that has been made. I have recently been tracking the work being done under by folks associated with the desktop-wireless summits (under the auspices of OSDL). There is still a lot of work to do with wireless support. I've been glad to see both Fedora and Ubuntu get on the NetworkManager integration bandwagon. We need strong distributions that can put finishing touches on all the integrated projects. We still have a ways to go with desktop usability and so forth. I hope that Fedora will flourish and continue to play a vital role in coordinating, evolving and integrating all the codebases that feed into it. It's an invaluable role. From luya_tfz at thefinalzone.com Wed Feb 21 08:45:49 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Wed, 21 Feb 2007 03:45:49 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172047549.45dc06bd50c1a@ssl.mecca.ca> Quoting "Eric S. Raymond" : > * Persistent failure to maintain key repositories in a sane, > consistent state from which upgrades might actually be possible. Core and Extras merged on future Fedora 7 so there is only one official Fedora repository. > * Effectively abandoning the struggle for desktop market share. > * Failure to address the problem of proprietary multimedia formats with > any attitude other than blank denial. Sorry Eric. It seems you are willing to compromise Fedora philosophies on what it is not: a distribution with default installed closed sources . Since the installation of Fedora can be customized with the ability to add an external repository, the point is completely irrelevant. > > I have watched Ubuntu rise to these challenges as Fedora fell away > from them. Canonical's recent deal with Linspire, which will give > Linux users legal access to WMF and other key proprietary codecs, is > precisely the sort of thing Red-Hat/Fedora could and should have taken > the lead in. Not having done so bespeaks a failure of vision which I > now believe will condemn Fedora to a shrinking niche in the future. I think you threw away the FOSS philosophies that Fedora applied for a benefit of patented codecs and popularity. IMHO, Linspire/Canonical means Canonical is seeking a way to earn moneys with the inclusion of patented codecs on their free distribution. Have you eared the term "victim of its own success"? There will be a price to pay. > This afternoon, I installed Edgy Eft on my main development machine -- > from one CD, not five. In less than three hours' work I was able to > recreate the key features of my day-to-day toolkit. The > after-installation mass upgrade to current packages, always a > frightening prospect under Fedora, went off without a hitch. > You should know you can use a boot disk to do a network install a system. Five CD is aiming for people who don't have broadband connection which is still the case on many countries. > I'm not expecting Ubuntu to be perfect, but I am now certain it will > be enough better to compensate me for the fact that I need to learn > a new set of administration tools. > > Fedora, you had every advantage, and you had my loyalty, and you blew it. > And that is a damn, dirty shame. > -- > Eric S. Raymond > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From jfrieben at gmx.de Wed Feb 21 08:53:33 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Wed, 21 Feb 2007 09:53:33 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <20070221085333.239590@gmx.net> > For Test2, I'm planning on doing the Fedora "Classic" spin for folks to > work > with. That's excellent news when "FC7T1" e.g. did not even include "gcc". I do not know about other users, but in my case, only about [downloaded] 100 MB of packages from "Fedora Extras" are part of my default setup, whereas I certainly have about 85% of the "Core" packages installed [the remainder is essentially composed of "KDE" related packages]. This makes me really wonder if removing the distinction between "Core" and "Extras" was a worthwile task [whereas I fully welcome the use of a unified build system for both]. Doubling the volume of the distribution to increase package coverage [by usage] by less than 10% still seems questionable to me, especially when the impact on install media distribution ["bittorrent"] is so severe. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From andy at warmcat.com Wed Feb 21 08:59:18 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 21 Feb 2007 08:59:18 +0000 Subject: Goodbye, /lib/* In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <45DC09E6.10804@warmcat.com> Eric S. Raymond wrote: > After thirteen years as a loyal Red Hat and Fedora user, I reached my > limit today, when an attempt to upgrade one (1) package pitched me > into a four-hour marathon of dependency chasing, at the end of which > an attempt to get around a trivial file conflict rendered my system > unusable. > > The proximate causes of this failure were (1) incompetent repository > maintenance, making any nontrivial upgrade certain to founder on a > failed dependency, and (2) the fact that rpm is not statically linked > -- so it's possible to inadvertently remove a shared library it > depends on and be unrecoverably screwed. But the underlying problems > run much deeper. If I understood this, you deleted something down /lib that rpm depended on. That's not unrecoverably screwed: you can boot into the rescue CD and bring over the libs or the rpm the libs came from and use rpm2cpio. I have done this in the past, and recovered from it, and my assessment of the proximate cause of the failure was that 1) I was a careless idiot. RPM being monolithic would help in that situation, but then it's open to you to delete rpm if you're up for deleting shared libs. Likewise Ubuntu is going to have things that can be deleted that will render it equally "unrecoverable". Basically there isn't much to be done to protect a tired or stupid admin using rm as root on important files: but the recovery boot is there to get you out of even very bad trouble. I don't think we should entirely absolve the wielder of the rm machete from blame even if he didn't ask to be swinging it about. -Andy From naoki at valuecommerce.com Wed Feb 21 09:15:54 2007 From: naoki at valuecommerce.com (Naoki) Date: Wed, 21 Feb 2007 18:15:54 +0900 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172049354.24764.35.camel@dragon.valuecommerce.ne.jp> I'll bite. On Wed, 2007-02-21 at 03:03 -0500, Eric S. Raymond wrote: > After thirteen years as a loyal Red Hat and Fedora user, I reached my > limit today, when an attempt to upgrade one (1) package pitched me > into a four-hour marathon of dependency chasing, at the end of which > an attempt to get around a trivial file conflict rendered my system > unusable. I've been using RH/Fedora for about the same amount of time. I've never broken my system to that level outside of test / rawhide. Not going to argue that dependencies couldn't be better, because they always can. Heck, I'd love to build a server with some graphical config tools and not require printing libraries, but there you go.. > * Allowing RPM development to drift and stagnate -- then adding another layer of complexity, bugs, and wretched performance with yum. Yeah, RPM did stagnate, but at least the RPM based distros are trying to do something about it. > * Effectively abandoning the struggle for desktop market share. > * Failure to address the problem of proprietary multimedia formats with > any attitude other than blank denial. Nobody ever said it "should" be a major desktop alternative or play mp3s. The goal of Fedora is "..the rapid progress of free and open source software and content". Fedora "allows" you to do what you want with it, it's not everything to everyone and doesn't try to be. > I have watched Ubuntu rise to these challenges as Fedora fell away > from them. Canonical's recent deal with Linspire, which will give > Linux users legal access to WMF and other key proprietary codecs, is > precisely the sort of thing Red-Hat/Fedora could and should have taken > the lead in. Not having done so bespeaks a failure of vision which I > now believe will condemn Fedora to a shrinking niche in the future. That's all well and nice for Ubuntu which seems to be a desktop centric OS. But I've always seen Fedora as primarily a server platform (given it's the basis for RHEL). And that is fine for me because I don't want to play windows media. I want Apache, Fedora Directory Service and a fast kernel. Web browsing and email are great for a workstation but everything else is a luxury. At the end of the day if I really "need" to see that video of the Chimp falling out of the tree after smelling his finger then I'll drop mplayer on from a public repo. If you want that standard then yeah, maybe Fedora isn't for you. I can't debate the submission process because I don't submit, but I do know from the devel list discussions that people are trying to make that (along with other things) easier with the merge. > This afternoon, I installed Edgy Eft on my main development machine -- > from one CD, not five. In less than three hours' work I was able to > recreate the key features of my day-to-day toolkit. The > after-installation mass upgrade to current packages, always a > frightening prospect under Fedora, went off without a hitch. I can network install a working fedora box with what I need in 10 minutes. That's not much of a technical argument, especially as fedora is openly committed to allowing custom spins. So you will be able to build a box based on whatever you like soon enough. That is moving in the right direction. > I'm not expecting Ubuntu to be perfect, That's lucky. > but I am now certain it will > be enough better to compensate me for the fact that I need to learn > a new set of administration tools. > > Fedora, you had every advantage, and you had my loyalty, and you blew it. > And that is a damn, dirty shame. Sleep on it. Fedora is open, and people are committed to it, so it improves with each release. From abraxis at telkomsa.net Wed Feb 21 09:52:53 2007 From: abraxis at telkomsa.net (Neil Thompson) Date: Wed, 21 Feb 2007 11:52:53 +0200 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <20070221095253.GB12314@eeyore.32.boerneef.vornavalley> On Wed, Feb 21, 2007 at 03:03:50AM -0500, Eric S. Raymond wrote: [ a vast amount of crap (as usual) deleted] Don't let the door hit you on the way out. -- Cheers! (Relax...have a homebrew) Neil THEOREM: VI is perfect. PROOF: VI in roman numerals is 6. The natural numbers < 6 which divide 6 are 1, 2, and 3. 1+2+3 = 6. So 6 is a perfect number. Therefore, VI is perfect. QED -- Arthur Tateishi From jnovy at redhat.com Wed Feb 21 11:18:41 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 21 Feb 2007 12:18:41 +0100 Subject: rawhide report: 20070220 changes In-Reply-To: <1171992484.25545.25.camel@zelda.fubar.dk> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> <1171992484.25545.25.camel@zelda.fubar.dk> Message-ID: <1172056721.2385.0.camel@redhat.usu> On Tue, 2007-02-20 at 12:28 -0500, David Zeuthen wrote: > On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > gphoto2-2.3.1-4.fc7 > > ------------------- > > * Mon Feb 19 2007 Jindrich Novy 2.3.1-4 > > - ACL handling is now moved into HAL (#229230) > > This update removed a bit too much > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229230 > > so that bug is now reopened. The 10-camera-libgphoto2.fdi is now added back. Jindrich From mschwendt.tmp0701.nospam at arcor.de Wed Feb 21 11:58:43 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 21 Feb 2007 12:58:43 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> On Wed, 21 Feb 2007 03:03:50 -0500 (EST), Eric S. Raymond wrote: > After thirteen years as a loyal Red Hat and Fedora user, I reached my > limit today, when an attempt to upgrade one (1) package pitched me > into a four-hour marathon of dependency chasing, at the end of which > an attempt to get around a trivial file conflict rendered my system > unusable. Without details it is hardly possible to comment on it. But pointing out the following should be allowed: The Fedora Extras 6 repository currently is free of broken dependencies. The Fedora Extras 5 repository contains a single broken package that is broken for 131 days (linphone). Conflicts in Fedora Extras are due to the committee's refusal to publish related policies. Instead, packagers and reviewers are confronted with lots of minor policies and bureaucracy. > The proximate causes of this failure were (1) incompetent repository > maintenance, "Incompetent" in what way? At least on the Fedora Extras side we haven't had any broken metadata, unsigned rpms or permission problems for a very very long time. That part of the repository maintenance has been flawless. In the "development" repositories, broken dependencies could only be prevented in Core, because Core and Extras are still separate and use separate build systems, too. When and if they are merged for Fedora 7, it would be possible to only publish packages (or sets of packages), which don't break any install-time dependencies. Still, it would not guarantee that the development side of Fedora is usable and free of problems always. From fedora at leemhuis.info Wed Feb 21 12:18:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Feb 2007 13:18:48 +0100 Subject: Conflicts policy (Was: Re: Goodbye, Fedora) In-Reply-To: <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45DC38A8.4020306@leemhuis.info> On 21.02.2007 12:58, Michael Schwendt wrote: > On Wed, 21 Feb 2007 03:03:50 -0500 (EST), Eric S. Raymond wrote: >> After thirteen years as a loyal Red Hat and Fedora user, I reached my >> limit today, when an attempt to upgrade one (1) package pitched me >> into a four-hour marathon of dependency chasing, at the end of which >> an attempt to get around a trivial file conflict rendered my system >> unusable. > > Without details it is hardly possible to comment on it. But pointing out > the following should be allowed: > > The Fedora Extras 6 repository currently is free of broken dependencies. > > The Fedora Extras 5 repository contains a single broken package that > is broken for 131 days (linphone). > > Conflicts in Fedora Extras are due to the committee's refusal to publish > related policies. Instead, packagers and reviewers are confronted with > lots of minor policies and bureaucracy. [...] That reminds me: When will the conflicts policy/guidelines ever get finished and made effective by the Packaging Committee? I think it was voted and accepted (not sure), but it's still in the drafts section: http://www.fedoraproject.org/wiki/PackagingDrafts/Conflicts CU thl From alan at redhat.com Wed Feb 21 12:27:43 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 21 Feb 2007 07:27:43 -0500 Subject: F7t2 and QA Meeting In-Reply-To: <20070221034415.GC32402@redhat.com> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> Message-ID: <20070221122743.GB2557@devserv.devel.redhat.com> On Tue, Feb 20, 2007 at 10:44:15PM -0500, Dave Jones wrote: > > A patch to fix the problem was accepted into the libata tree this > > morning, so it should show up in the mainline kernel -git soon. > > That specific bug /should/ be fixed in the fedora kernel that'll hit > rawhide tomorrow. The current libata tree is totally broken, cable detect is broken on intel chipsets at least, the resource changes cause the pcmcia driver to panic and various other stuff seems to have been upset in the current set of changes. Alan From alan at redhat.com Wed Feb 21 12:33:07 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 21 Feb 2007 07:33:07 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <20070221123307.GC2557@devserv.devel.redhat.com> On Wed, Feb 21, 2007 at 03:03:50AM -0500, Eric S. Raymond wrote: > * Failure to address the problem of proprietary multimedia formats with > any attitude other than blank denial. That would be because we believe in Free Software and doing the right thing (a practice you appear to have given up on). Maybe it is time the term "open source" also did the decent thing and died out with you. > I'm not expecting Ubuntu to be perfect, but I am now certain it will > be enough better to compensate me for the fact that I need to learn > a new set of administration tools. I'm sure they will be delighted to have you Alan -- "That was said by Eric Raymond who belongs to another movement" - Richard Stallman From hughsient at gmail.com Wed Feb 21 12:51:35 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Feb 2007 12:51:35 +0000 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172062295.3957.17.camel@hughsie-laptop> (cutting media cc's) I told myself I wasn't going to respond, but couldn't resist seeing as I publicly blogged about switching to Ubuntu 6 months ago, but came back to Fedora. > * Persistent failure to maintain key repositories in a sane, > consistent state from which upgrades might actually be possible. You mean rawhide? Rawhide is *meant* to eat babies. > * A murky, poorly-documented, over-complex submission process. Getting better - the core+extras merge was never going to be pretty but I think it's going well and will evolve over a short amount of time to be very sane. > * Allowing RPM development to drift and stagnate -- then adding > another layer of complexity, bugs, and wretched performance with > yum. Aye, but as other replies have said, RPM is going to be fixed. Yum on the other hand I agree with. pup, pirut and yum-updatesd all fight for control for me, and none of them are easy to use or HIG compliant. I'm using synaptic - which seems to be much faster and easier to use then pirut. The ubuntu software install and update tools are very slick compared with Fedora. > * Effectively abandoning the struggle for desktop market share. Really? Have you hung out in IRC or read the mailing lists recently? Have you seen the really cool ConsoleKit, PolicyKit and HAL work that's being done to make fast user switching work? FC7 will be the first distro supporting ACL's on device objects and allowing users to switch desktops with stuff like pulseaudio and gnome-power-manager JUST WORKING. That's real innovation, and really not abandoning the struggle for the desktop. Please stop making unquantifiable statements. > * Failure to address the problem of proprietary multimedia formats > with any attitude other than blank denial. Fedoras stance on this is stated. Sure, I watch DVD's and such with the help of a really easy to use repo beginning with l. Not shipping the non-free bits makes zero difference to me. So, please stop using your position and trying to get a headline on slashdot. Many thanks. Richard. From markw at mohawksoft.com Wed Feb 21 13:32:23 2007 From: markw at mohawksoft.com (markw at mohawksoft.com) Date: Wed, 21 Feb 2007 08:32:23 -0500 (EST) Subject: fedora-devel-list Digest, Vol 36, Issue 67 In-Reply-To: <20070221081119.689E9736DB@hormel.redhat.com> References: <20070221081119.689E9736DB@hormel.redhat.com> Message-ID: <21913.24.91.171.78.1172064743.squirrel@mail.mohawksoft.com> > Date: Wed, 21 Feb 2007 03:03:50 -0500 (EST) > From: esr at thyrsus.com (Eric S. Raymond) > Subject: Goodbye, Fedora > To: fedora-devel-list at redhat.com > Cc: lwn at lwn.net, editors at newsforge.com, sjvn at vna1.com, > editors at linuxtoday.com > Message-ID: <20070221080350.3711A3C1AC6 at snark.thyrsus.com> > > After thirteen years as a loyal Red Hat and Fedora user, I reached my > limit today, when an attempt to upgrade one (1) package pitched me > into a four-hour marathon of dependency chasing, at the end of which > an attempt to get around a trivial file conflict rendered my system > unusable. [SNIP] Over the years I have heard Eric S Raymond pontificate and assail and I grow more tired each time I am subjected to one of his ramblings. ESR, as he is frequently called, is a harm to the free software movement, and I for one, welcome his departure from this list. Damn it, but now I have the potential of having to read his crap on the Ubuntu forums. What's the over/under on the number of days/weeks before he makes some sort of proclamation about what's wrong with Ubuntu? Eric, why don't you just shut up and roll your own release? Oh, wait, that's right, you are all talk and no action. In free software, we contribute when we can and help when we can, whining and quitting is for losers. Mark L. Woodward From camilo at mesias.co.uk Wed Feb 21 13:12:23 2007 From: camilo at mesias.co.uk (Cam) Date: Wed, 21 Feb 2007 13:12:23 +0000 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <45DC4537.7060605@mesias.co.uk> Eric I've followed your comments on Fedora and multimedia with interest. I recall thinking you'd be better off with Ubuntu. I'd be genuinely interested if you plan to write up your Ubuntu experiences, good and bad. I searched for a blog but what I found was mainly political (Islam etc.). Do you plan to write about your experiences with Ubuntu somewhere? -Cam -- camilo at mesias.co.uk <-- From mark at opus11.net Wed Feb 21 13:26:46 2007 From: mark at opus11.net (Mark Knoop) Date: Wed, 21 Feb 2007 13:26:46 +0000 Subject: Goodbye, Fedora In-Reply-To: <45DC4537.7060605@mesias.co.uk> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC4537.7060605@mesias.co.uk> Message-ID: <20070221132646.382535dd@brahms.leipzig> At 13:12 on 21 Feb 2007, Cam wrote: > Eric > > I've followed your comments on Fedora and multimedia with interest. I > recall thinking you'd be better off with Ubuntu. > > I'd be genuinely interested if you plan to write up your Ubuntu > experiences, good and bad. I searched for a blog but what I found was > mainly political (Islam etc.). Do you plan to write about your > experiences with Ubuntu somewhere? I just made the mistake of looking for ESR's blog. Unfortunately, I found it - http://esr.ibiblio.org/ - what a truly hideous individual he appears to be. Good riddance. -- Mark Knoop From mschwendt.tmp0701.nospam at arcor.de Wed Feb 21 13:32:49 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 21 Feb 2007 14:32:49 +0100 Subject: Conflicts policy (Was: Re: Goodbye, Fedora) In-Reply-To: <45DC38A8.4020306@leemhuis.info> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> <45DC38A8.4020306@leemhuis.info> Message-ID: <20070221143249.25b6fa77.mschwendt.tmp0701.nospam@arcor.de> On Wed, 21 Feb 2007 13:18:48 +0100, Thorsten Leemhuis wrote: > That reminds me: When will the conflicts policy/guidelines ever get > finished and made effective by the Packaging Committee? I think it was > voted and accepted (not sure), but it's still in the drafts section: > > http://www.fedoraproject.org/wiki/PackagingDrafts/Conflicts * No package for %{dist} must conflict with any other package for the same %{dist} (multi-lib issues left aside!). Neither implicitly nor explicitly. This is a policy FESCo could decide on without having to wait for the Packaging Comittee. There is no technical knowlegde needed to decide on that. Does FESCo like surprises during full installations or when future updates pull in a conflicting dep-chain? * Exceptions? Perhaps "lazy packaging" in compat*-devel packages as mentioned in above document? Though, it should be possible to relocate header files and modify foo-config scripts appropriately. Packages with a completely disjunct target group? E.g. "qstat" vs. "torque" in Fedora Extras. Still, with the background of torque, it would be justified if the qstat package (upstream!) renamed its files in order to resolve that conflict. From knightmerc at yahoo.com Wed Feb 21 13:35:41 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Wed, 21 Feb 2007 08:35:41 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221123307.GC2557@devserv.devel.redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> Message-ID: <1172064941.3634.16.camel@localhost.localdomain> On Wed, 2007-02-21 at 07:33 -0500, Alan Cox wrote: > On Wed, Feb 21, 2007 at 03:03:50AM -0500, Eric S. Raymond wrote: > > * Failure to address the problem of proprietary multimedia formats with > > any attitude other than blank denial. > > That would be because we believe in Free Software and doing the right thing > (a practice you appear to have given up on). Maybe it is time the term > "open source" also did the decent thing and died out with you. Who the hell made you the arbiter of what's right and wrong? You? I've about had it up to here with this New Slavery crap, this pseudo-socialist movement in the Linux world being pushed by self styled self aggrandizing arrogant ivory tower elitists intent on a fascist enforcement of the licensing policies of THEIR choice dictated from inside a closed circle-jerk where everybody pats themselves on the back and laughs about how stupid the "outsiders" are. The Greg KH's and Andrew Mortons of the world that are hell bent on telling programmers how to license their own code at the point of a gun. It's repugnant, just about as repugnant as this self-important arrogant post of yours. > > I'm not expecting Ubuntu to be perfect, but I am now certain it will > > be enough better to compensate me for the fact that I need to learn > > a new set of administration tools. > > I'm sure they will be delighted to have you > > Alan And it's the toy-hat dictators and the toy-hat fascists that are pushing him out the door. Socialism was the mother of both fascism and communism, and it's the same thing that's destroying Fedora, thanks in part to you. Welcome to the New Slavery. It's the same as the Old Slavery. > -- > "That was said by Eric Raymond who belongs to another movement" > - Richard Stallman > > > LX -- ??????????????????????????????????????????????????? "Anybody else wanna negotiate?" -- Maj. Korben Dallas Registered Linux User #268899 http://counter.li.org/ ??????????????????????????????????????????????????? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 21 13:51:17 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 21 Feb 2007 14:51:17 +0100 Subject: Goodbye, Fedora In-Reply-To: <1172064941.3634.16.camel@localhost.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> Message-ID: <20070221145117.0aa92f5b@python3.es.egwn.lan> Lyvim Xaphir wrote : > I've about had it up to here with this New Slavery crap, this > pseudo-socialist movement in the Linux world being pushed by self styled > self aggrandizing arrogant ivory tower elitists intent on a fascist > enforcement of the licensing policies of THEIR choice dictated from > inside a closed circle-jerk where everybody pats themselves on the back > and laughs about how stupid the "outsiders" are. The Greg KH's and > Andrew Mortons of the world that are hell bent on telling programmers > how to license their own code at the point of a gun. It's repugnant, > just about as repugnant as this self-important arrogant post of yours. Yeah, I mean, who are we to enforce our copyrights and licensing choices!? Even go as far as FORCE freedom upon our users, huh? :P > And it's the toy-hat dictators and the toy-hat fascists that are pushing > him out the door. Socialism was the mother of both fascism and > communism, and it's the same thing that's destroying Fedora, thanks in > part to you. Welcome to the New Slavery. It's the same as the Old > Slavery. You've lost me here, as none of the above makes any sense to me. But it does seem that you haven't really understood the basic goals of the Fedora Project. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.58 0.50 0.56 From denis at poolshark.org Wed Feb 21 13:52:04 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 21 Feb 2007 14:52:04 +0100 Subject: Goodbye, Fedora In-Reply-To: <1172064941.3634.16.camel@localhost.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> Message-ID: <45DC4E84.5020602@poolshark.org> Lyvim Xaphir wrote: > And it's the toy-hat dictators and the toy-hat fascists that are pushing > him out the door. Socialism was the mother of both fascism and > communism, and it's the same thing that's destroying Fedora, thanks in > part to you. Godwin's Law achieved! In a record-breaking 5 hours! From mark at opus11.net Wed Feb 21 13:58:36 2007 From: mark at opus11.net (Mark Knoop) Date: Wed, 21 Feb 2007 13:58:36 +0000 Subject: Goodbye, Fedora In-Reply-To: <45DC4E84.5020602@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> Message-ID: <20070221135836.71a23315@brahms.leipzig> At 14:52 on 21 Feb 2007, Denis Leroy wrote: > Lyvim Xaphir wrote: > > And it's the toy-hat dictators and the toy-hat fascists that are > > pushing him out the door. Socialism was the mother of both fascism > > and communism, and it's the same thing that's destroying Fedora, > > thanks in part to you. > > Godwin's Law achieved! In a record-breaking 5 hours! 5:32, actually... Must try harder. -- Mark Knoop From fedora at leemhuis.info Wed Feb 21 13:59:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Feb 2007 14:59:51 +0100 Subject: Conflicts policy (Was: Re: Goodbye, Fedora) In-Reply-To: <20070221143249.25b6fa77.mschwendt.tmp0701.nospam@arcor.de> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> <45DC38A8.4020306@leemhuis.info> <20070221143249.25b6fa77.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45DC5057.8070409@leemhuis.info> On 21.02.2007 14:32, Michael Schwendt wrote: > On Wed, 21 Feb 2007 13:18:48 +0100, Thorsten Leemhuis wrote: >> That reminds me: When will the conflicts policy/guidelines ever get >> finished and made effective by the Packaging Committee? I think it was >> voted and accepted (not sure), but it's still in the drafts section: >> http://www.fedoraproject.org/wiki/PackagingDrafts/Conflicts > > * No package for %{dist} must conflict with any other package for the > same %{dist} (multi-lib issues left aside!). Neither implicitly nor > explicitly. > > This is a policy FESCo could decide on without having to wait for the > Packaging Comittee. Agreed, with the new world order (PC below FESCo and the new merged FESCo for both Core and Extras) that could be done by FESCo -- when I was still in FESCo and it was still Extras only I tried to avoid such a move because I didn't want to have such a thing as Extras-specific rule. > There is no technical knowlegde needed to decide on > that. Well, it will quickly raise questions like "Is 'Conflicts kernel < 2.6.17' okay?" > Does FESCo like surprises during full installations or when future > updates pull in a conflicting dep-chain? Seems nobody is targeting anymore to make "full installations" possible. >[...] CU thl From oisin.feeley at gmail.com Wed Feb 21 14:00:39 2007 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Wed, 21 Feb 2007 09:00:39 -0500 Subject: Goodbye, Fedora In-Reply-To: <1172064941.3634.16.camel@localhost.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> Message-ID: On 2/21/07, Lyvim Xaphir wrote: > I've about had it up to here with this New Slavery crap, [snip etc] This is a parody to make ESR look bad... right? (Don't bother answering, it was a rhetorical question.) On a more useful note, does anyone have any idea of exactly which package ESR is claiming caused the complete meltdown of his system? Is he actually claiming that "yum update " on a FC6 system caused the problems that he mentions? Or is he actually referring to how the ItEatsBabiesAndYouWereWarned rawhide ate his babies? This sort of bug report is not helpful as it's slim on concrete details and leaves a murky wake of confusion. There's some good advice on how to avoid that type of thing in these two links: http://www.catb.org/~esr/faqs/smart-questions.html#symptoms http://www.catb.org/~esr/faqs/smart-questions.html#id273206 Oisin Feeley From gilboad at gmail.com Wed Feb 21 14:01:16 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 16:01:16 +0200 Subject: Goodbye, Fedora In-Reply-To: <45DC4E84.5020602@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> Message-ID: <1172066476.9201.36.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 14:52 +0100, Denis Leroy wrote: > Lyvim Xaphir wrote: > > And it's the toy-hat dictators and the toy-hat fascists that are pushing > > him out the door. Socialism was the mother of both fascism and > > communism, and it's the same thing that's destroying Fedora, thanks in > > part to you. > > Godwin's Law achieved! In a record-breaking 5 hours! > Somehow I doubt that the neither OP nor the troll above have any idea what Godwin's Law is, nor do they seem to care. Time to make fedora-devel developers/maintainers/etc only? - Gilboa From gilboad at gmail.com Wed Feb 21 14:02:49 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 16:02:49 +0200 Subject: Conflicts policy (Was: Re: Goodbye, Fedora) In-Reply-To: <45DC5057.8070409@leemhuis.info> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> <45DC38A8.4020306@leemhuis.info> <20070221143249.25b6fa77.mschwendt.tmp0701.nospam@arcor.de> <45DC5057.8070409@leemhuis.info> Message-ID: <1172066569.9201.38.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 14:59 +0100, Thorsten Leemhuis wrote: > On 21.02.2007 14:32, Michael Schwendt wrote: > > On Wed, 21 Feb 2007 13:18:48 +0100, Thorsten Leemhuis wrote: [snip] > > Does FESCo like surprises during full installations or when future > > updates pull in a conflicting dep-chain? > > Seems nobody is targeting anymore to make "full installations" possible. > Is it even theoretically possible? - Gilboa From jkeating at redhat.com Wed Feb 21 14:13:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 09:13:17 -0500 Subject: Conflicts policy (Was: Re: Goodbye, Fedora) In-Reply-To: <1172066569.9201.38.camel@gilboa-work-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC5057.8070409@leemhuis.info> <1172066569.9201.38.camel@gilboa-work-dev.localdomain> Message-ID: <200702210913.18050.jkeating@redhat.com> On Wednesday 21 February 2007 09:02, Gilboa Davara wrote: > Is it even theoretically possible? It should be. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Wed Feb 21 14:19:05 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 21 Feb 2007 15:19:05 +0100 Subject: Conflicts policy (Was: Re: Goodbye, Fedora) In-Reply-To: <45DC5057.8070409@leemhuis.info> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> <45DC38A8.4020306@leemhuis.info> <20070221143249.25b6fa77.mschwendt.tmp0701.nospam@arcor.de> <45DC5057.8070409@leemhuis.info> Message-ID: <20070221151905.d2b0d4d3.mschwendt.tmp0701.nospam@arcor.de> On Wed, 21 Feb 2007 14:59:51 +0100, Thorsten Leemhuis wrote: > > There is no technical knowlegde needed to decide on > > that. > > Well, it will quickly raise questions like "Is 'Conflicts kernel < > 2.6.17' okay?" No, the question is irrelevant in the context of the %{dist} package space where the kernel is known to be >= 2.6.17. Conflicts of Fedora 7 with packages from Red Hat Linux 9 are outside the scope of such a policy. The primary focus should be on what conflicts can occur if somebody does a [fresh] install of Fedora 7? And what conflicts are possible a few months later after hundreds of updates? > > Does FESCo like surprises during full installations or when future > > updates pull in a conflicting dep-chain? > > Seems nobody is targeting anymore to make "full installations" possible. Possibly not at install-time. But all packages are available after firstboot. From mschwendt.tmp0701.nospam at arcor.de Wed Feb 21 14:45:20 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 21 Feb 2007 15:45:20 +0100 Subject: Conflicts policy (Was: Re: Goodbye, Fedora) In-Reply-To: <1172066569.9201.38.camel@gilboa-work-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221125843.b92c928d.mschwendt.tmp0701.nospam@arcor.de> <45DC38A8.4020306@leemhuis.info> <20070221143249.25b6fa77.mschwendt.tmp0701.nospam@arcor.de> <45DC5057.8070409@leemhuis.info> <1172066569.9201.38.camel@gilboa-work-dev.localdomain> Message-ID: <20070221154520.be1fb427.mschwendt.tmp0701.nospam@arcor.de> On Wed, 21 Feb 2007 16:02:49 +0200, Gilboa Davara wrote: > > Seems nobody is targeting anymore to make "full installations" possible. > > > > Is it even theoretically possible? If the allocated disk space is large enough and all packages can be installed without conflicts, it boils down to whether all packages can coexist, for example whether they use the alternatives system to replace eachother or whether they fight for resources. Imagine somebody, who tries to install all -devel packages, because compiling software from tarballs needs many of them. All sorts of conflicts that request user input are like poison. But even without full installs, imagine somebody installs Fedora 7 and adds a customised selection of packages later. After updating the installation regularly without problems, suddenly an update leads to a needed chain of dependencies, which is rejected due to conflicts, because either a) there are a packaging bug, or b) there are explicit "Conflicts:" in the packages. Hence it is important that all conflicts inside %dist package set are examined closely. From tbrinkman at sbcglobal.net Wed Feb 21 14:45:06 2007 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Wed, 21 Feb 2007 08:45:06 -0600 Subject: Goodbye, Fedora In-Reply-To: <1172066476.9201.36.camel@gilboa-work-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> Message-ID: <200702210845.07064.tbrinkman@sbcglobal.net> On Wednesday 21 February 2007, Gilboa Davara wrote: > On Wed, 2007-02-21 at 14:52 +0100, Denis Leroy wrote: > > Lyvim Xaphir wrote: > > > And it's the toy-hat dictators and the toy-hat fascists that > > > are pushing him out the door. Socialism was the mother of > > > both fascism and communism, and it's the same thing that's > > > destroying Fedora, thanks in part to you. > > > > Godwin's Law achieved! In a record-breaking 5 hours! > > Somehow I doubt that the neither OP nor the troll above have any > idea what Godwin's Law is, nor do they seem to care. > > Time to make fedora-devel developers/maintainers/etc only? > > - Gilboa 'etc' should include those who actually run fc6-test and/or f7-rawhide. LX uses neither (fc5-unity). -- Tom Brinkman Corpus Christi, Texas From gilboad at gmail.com Wed Feb 21 14:46:08 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 16:46:08 +0200 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <00ab01c755c4$729e33b0$6701a8c0@copernicus> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> Message-ID: <1172069168.9201.48.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 09:27 -0500, Tony Downey wrote: > > > > Time to make fedora-devel developers/maintainers/etc only? > > > > Wouldn't that just prove the "trolls'" assertions? > > I've been a RH/Fedora user since 1996. I'd LOVE to contribute to Fedora. I > don't have the amount of free time, though, that I believe is necessary to > constitute an honest effort. > > Having said that, I remain subscribed to the devel list in order to stay > informed and learn. > > Restricting access to the mailing list would, IMO, just paint a picture of > Fedora developers as elitists -- and I don't think that's what you're hoping > to achieve. > > > TD > Unless I'm mistaken, the original idea was that -devel members has to be sponsored before given rw rights. Being a fedora developer and/or an active -extras maintainer will just speed things up. I'm not saying that -devel should be limited to RH/FC/Extras members -only-, I am saying that something must be done to improve the signal-to-noise ratio. - Gilboa From kip.thomas at gmail.com Wed Feb 21 14:51:06 2007 From: kip.thomas at gmail.com (Kip Thomas) Date: Wed, 21 Feb 2007 09:51:06 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221123307.GC2557@devserv.devel.redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> Message-ID: <64520b910702210651h68c91033j6f045203d1a12003@mail.gmail.com> Whoa! The big gun AC-130 coming out and hang with RMS with that footnote quote from RMS. I like it. It's ironic that a freedom loving guy ESR would selectively deviate on issues of the contrary. I secretly hope someday the ESR ship will turn around. I really do. I'll wait. Personally, I always actively run different distros so that I can acquire the ability to approximately compare apples to apples. Three times now Fedora managed to win me back. I hope my experience means this opinion is balanced. I do see problems of not including codecs and how it'd affect desktop adoption. I think that's a problem for Marketing. Oh yeah, I use Fedora for desktop. Actually a powerful latop as desktop. I just don't like noise. "That was said by Eric Raymond who belongs to another movement" - Richard Stallman ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This post completed with hijacking of RMS's quote. :) On 2/21/07, Alan Cox wrote: > > On Wed, Feb 21, 2007 at 03:03:50AM -0500, Eric S. Raymond wrote: > > * Failure to address the problem of proprietary multimedia formats with > > any attitude other than blank denial. > > That would be because we believe in Free Software and doing the right > thing > (a practice you appear to have given up on). Maybe it is time the term > "open source" also did the decent thing and died out with you. > > > I'm not expecting Ubuntu to be perfect, but I am now certain it will > > be enough better to compensate me for the fact that I need to learn > > a new set of administration tools. > > I'm sure they will be delighted to have you > > Alan > -- > "That was said by Eric Raymond who belongs to another movement" > - Richard Stallman > > > > -- > 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 kloczek at zie.pg.gda.pl Wed Feb 21 14:51:12 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 21 Feb 2007 15:51:12 +0100 Subject: rawhide report: 20070216 changes In-Reply-To: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> References: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> Message-ID: <1172069472.10910.4.camel@kloczek01.pracownicy.zie> Dnia 16-02-2007, pi? o godzinie 07:39 -0500, buildsys at redhat.com napisa?(a): [..] > gnome-terminal-2.17.91-3.fc7 > ---------------------------- > * Thu Feb 15 2007 Matthias Clasen - 2.17.91-3 > - Add System to desktop file categories I just found some bug which seems does not exist in 2.17.90. g-t runned with "-x ssh " negotiates $TERM "dumb". If I run g-t and in this term session run "ssh " $TERM is correct ("xterm"). kloczek From pvrabec at redhat.com Wed Feb 21 14:59:05 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Wed, 21 Feb 2007 15:59:05 +0100 Subject: default syslogd In-Reply-To: <200702091033.59011.jkeating@redhat.com> References: <20070209161713.19ca2838@wrabco.brq.redhat.com> <200702091033.59011.jkeating@redhat.com> Message-ID: <20070221155905.3a85de36@wrabco.brq.redhat.com> On Fri, 9 Feb 2007 10:33:58 -0500 Jesse Keating wrote: > On Friday 09 February 2007 10:17, Peter Vrabec wrote: > > don't we want to change default syslogd in F7? > > Are you signing up to be responsible to drive this change, have it > testable by Test1 (oops, too late), feature frozen by Test2? There > is a lot involved with changing syslog, and these types of things > don't just magically happen, they need a driver. Care to drive? Sorry for late response, I was off last week. What do we need to do, before we turn it on by default? > From ch.nolte at noltec.org Wed Feb 21 14:59:59 2007 From: ch.nolte at noltec.org (Christian Nolte) Date: Wed, 21 Feb 2007 15:59:59 +0100 Subject: Goodbye, Eric! In-Reply-To: <20070221132646.382535dd@brahms.leipzig> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC4537.7060605@mesias.co.uk> <20070221132646.382535dd@brahms.leipzig> Message-ID: <45DC5E6F.8030309@noltec.org> Mark Knoop wrote: > At 13:12 on 21 Feb 2007, Cam wrote: > I just made the mistake of looking for ESR's blog. Unfortunately, I > found it - http://esr.ibiblio.org/ - what a truly hideous individual he > appears to be. > > Good riddance. > Let's say it with his own words: "Well, screw you and the camel you rode in. I will not be silenced, and we will not be silenced." - Eric S. Raymond [1] Sorry, but I could not resist... [1] http://esr.ibiblio.org/?p=290 -- Christian Nolte mailto:ch.nolte at noltec.org key : http://www.noltec.org/christian-nolte.asc or : www.keyserver.net GPG-fingerprint: 1088 6C2D 1496 0A34 D159 1108 08D8 C0D2 77E1 5BBC ---------------------------------------------------------------------- For more than 4 generations the IT Professionals were the guardians of quality and stability in software. Before the dark times. Before Microsoft... ---------------------------------------------------------------------- From mclasen at redhat.com Wed Feb 21 15:05:01 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 21 Feb 2007 10:05:01 -0500 Subject: rawhide report: 20070216 changes In-Reply-To: <1172069472.10910.4.camel@kloczek01.pracownicy.zie> References: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> <1172069472.10910.4.camel@kloczek01.pracownicy.zie> Message-ID: <1172070301.3256.0.camel@dhcp83-33.boston.redhat.com> On Wed, 2007-02-21 at 15:51 +0100, Tomasz K?oczko wrote: > Dnia 16-02-2007, pi? o godzinie 07:39 -0500, buildsys at redhat.com > napisa?(a): > [..] > > gnome-terminal-2.17.91-3.fc7 > > ---------------------------- > > * Thu Feb 15 2007 Matthias Clasen - 2.17.91-3 > > - Add System to desktop file categories > > I just found some bug which seems does not exist in 2.17.90. > g-t runned with "-x ssh " negotiates $TERM "dumb". > If I run g-t and in this term session run "ssh " $TERM is > correct ("xterm"). > > kloczek > There is an open bug about this in RH bugzilla, and it is already fixed in upstream svn. From andy at warmcat.com Wed Feb 21 15:06:07 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 21 Feb 2007 15:06:07 +0000 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <1172069168.9201.48.camel@gilboa-work-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> Message-ID: <45DC5FDF.8020509@warmcat.com> Gilboa Davara wrote: >> Restricting access to the mailing list would, IMO, just paint a picture of >> Fedora developers as elitists -- and I don't think that's what you're hoping >> to achieve. > I'm not saying that -devel should be limited to RH/FC/Extras members > -only-, I am saying that something must be done to improve the > signal-to-noise ratio. Is that really true about the ratio? This ESR "from Hell's heart I stab at thee" stuff is going to stay in its own thread. You can score the thread to nothing, but really since it does exist and involves Fedora maybe it should get read. This "core/moderator only" and "I mustn't be recorded" stuff going on is a pattern I have seen elsewhere. I hope others have seen where it leads too and maybe have some caution about it :-( A good idea is a good idea even if it came from the keyboard of a non-anointed person... -Andy From jkeating at redhat.com Wed Feb 21 15:12:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 10:12:29 -0500 Subject: default syslogd In-Reply-To: <20070221155905.3a85de36@wrabco.brq.redhat.com> References: <20070209161713.19ca2838@wrabco.brq.redhat.com> <200702091033.59011.jkeating@redhat.com> <20070221155905.3a85de36@wrabco.brq.redhat.com> Message-ID: <200702211012.30031.jkeating@redhat.com> On Wednesday 21 February 2007 09:59, Peter Vrabec wrote: > Sorry for late response, I was off last week. > > What do we need to do, before we turn it on by default? First thing, you'd have to sign up to drive this change and get it added to the feature list. Then you'd have to do all the research and testing and such to see if there is a reasonable thing to switch to, and discover what all needs to change to make the swich, and have it done by the new feature freeze, which is Test3, in a month. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed Feb 21 15:12:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Feb 2007 09:12:24 -0600 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <45DC5FDF.8020509@warmcat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC5FDF.8020509@warmcat.com> Message-ID: <1172070744.24204.163.camel@zod.rchland.ibm.com> On Wed, 2007-02-21 at 15:06 +0000, Andy Green wrote: > Gilboa Davara wrote: > > >> Restricting access to the mailing list would, IMO, just paint a picture of > >> Fedora developers as elitists -- and I don't think that's what you're hoping > >> to achieve. > > > I'm not saying that -devel should be limited to RH/FC/Extras members > > -only-, I am saying that something must be done to improve the > > signal-to-noise ratio. > > Is that really true about the ratio? This ESR "from Hell's heart I stab > at thee" stuff is going to stay in its own thread. You can score the > thread to nothing, but really since it does exist and involves Fedora > maybe it should get read. > > This "core/moderator only" and "I mustn't be recorded" stuff going on is > a pattern I have seen elsewhere. I hope others have seen where it leads > too and maybe have some caution about it :-( A good idea is a good idea > even if it came from the keyboard of a non-anointed person... The trend is going the opposite way anyway. Lists are opening up rather than being private. See the F-A-B list as an example. josh From kevin.kofler at chello.at Wed Feb 21 15:11:13 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 21 Feb 2007 15:11:13 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles Message-ID: I have uploaded my current set of specfiles and parallel-installability patches for KDE 3.80.3. These build on my live FC6 system, Mock builds for FC5, FC6 and devel still need to be tested. Note that you'll probably need to export QA_RPATHS=0x0003 to shut up Mock's rpath checking. (There's actually 2 issues here: 1. CMake's rpath handling is all or nothing, if you enable rpaths for /opt/kde4/lib, you also get them for /usr/lib and 2. Mock complains even about the rpaths in /opt/kde4/lib.) There's another RPM issue too: the debuginfo extraction doesn't want to do its job on the libraries in /opt/kde4/lib, whereas strangely it works for the binaries in /opt/kde4/bin. So you end up with unstripped libraries in the main package and missing debuginfo sources in /usr/src/debug. I currently have packages for kdelibs4, kdepimlibs4 and kdebase4. This is what I'm most interested in, because it's all that's needed to port most KDE apps (the porting scripts in kdesdk can be helpful, but luckily they're scripts so you don't have to compile them ;-) ). It would be best if the people most interested in getting the rest of the packages done (e.g. those who can't wait for Okular, Ligature or whatever ;-) ) would step in to help getting the rest done. Be warned that /opt/kde4/bin/konqueror crashes immediately if you run it without an argument, but if you give it a URL to open, it works (to some extent... it's obviously not ready for daily use, this is pre-alpha software after all). Note that I don't know if the kde4.desktop in /usr/share/xsessions actually does anything useful, I took that from Chitlesh and fixed the obvious syntax error, but I haven't tested it, I'm not interested in running full KDE 4 sessions anyway at this stage of KDE development. My specfiles are here: http://www.tigen.org/kevin.kofler/pcprogs/kde-3.80.3-1-specs.tar.bz2 Kevin Kofler From warren at togami.com Wed Feb 21 15:15:20 2007 From: warren at togami.com (Warren Togami) Date: Wed, 21 Feb 2007 10:15:20 -0500 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <1172069168.9201.48.camel@gilboa-work-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> Message-ID: <45DC6208.3070104@togami.com> Gilboa Davara wrote: > > Unless I'm mistaken, the original idea was that -devel members has to be > sponsored before given rw rights. > Being a fedora developer and/or an active -extras maintainer will just > speed things up. No. fedora-devel-list was originally meant to be developer discussion only. End-user support does not belong here at all. Unfortunately, this list has been increasingly failing us for a few reasons: - "developer discussion" is a gray area - policing is a manual process of constant vigilance. Effort today leaves no lasting effects in a few days. What if more list members helped in the policing, making it an actively hostile place for end-users to post support questions? I dunno... > > I'm not saying that -devel should be limited to RH/FC/Extras members > -only-, I am saying that something must be done to improve the > signal-to-noise ratio. > fedora-maintainers was created as an invite only list for this purpose. The signal to noise ratio is a bit better there. I am personally fine with inviting anybody with cvsextras access, or who has done something substantive in infrastructure or docs to that list. Warren Togami wtogami at redhat.com From rwwyatt01 at gmail.com Wed Feb 21 15:22:09 2007 From: rwwyatt01 at gmail.com (Randy Wyatt) Date: Wed, 21 Feb 2007 07:22:09 -0800 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <45DC6208.3070104@togami.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC6208.3070104@togami.com> Message-ID: <34e52d0c0702210722u4e3669d6vc7d51f5e1f0cf34e@mail.gmail.com> > Gilboa Davara wrote: > > > > Unless I'm mistaken, the original idea was that -devel members has to be > > sponsored before given rw rights. > > Being a fedora developer and/or an active -extras maintainer will just > > speed things up. > > No. fedora-devel-list was originally meant to be developer discussion > only. End-user support does not belong here at all. Unfortunately, > this list has been increasingly failing us for a few reasons: > > - "developer discussion" is a gray area > - policing is a manual process of constant vigilance. Effort today > leaves no lasting effects in a few days. > > What if more list members helped in the policing, making it an actively > hostile place for end-users to post support questions? I dunno... Making any list actively hostile to end-users is a quick way to lose end-users. This is one of the reasons I no longer use openSuSE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcantrell at redhat.com Wed Feb 21 15:31:24 2007 From: dcantrell at redhat.com (David Cantrell) Date: Wed, 21 Feb 2007 15:31:24 +0000 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172071884.3444.52.camel@mortise.boston.redhat.com> On Wed, 2007-02-21 at 03:03 -0500, Eric S. Raymond wrote: > After thirteen years as a loyal Red Hat and Fedora user, I reached my > limit today We got this email last year, Eric, but it had slightly different content. I think. Maybe. It's hard to read your messages. They are SO BORING. They read like anything in the USA Today. https://www.redhat.com/archives/fedora-devel-list/2006-March/msg01286.html From your post last year, you were "threatening to jump very publicly to another distribution and orphan several Fedora-related HOWTOs in the process" and it looks like [from the content of last year's email], we fixed a lot of things that bothered you about FC3 and FC4 and we have been able to keep you as a loyal user for 13 years now. Clearly threatening us gets us to fix things that bother people. Last year you noted that our infrastructure by FC5 was great. Yum was doing upgrades well and we no longer suffered from "egregious fuckups." But now you say it's a huge problem again in the current email by noting our "incompetent repository maintenance" and our non-statically linked rpm. So what is the problem? Is it user incompetence or are you actually aware of the infrastructure changes that take place or are taking place? Reading your message, my guess is you are just misinformed and that frustrates you. It also looks like you failed on this issue from last year's message from you: ...it's clear from the devel-list traffic that the submission pathway for new packages has got most if not all of the process issues shaken out of it. I had meant to get more directly involved in that, there are four or five things I want to package and submit myself, but higher-priority tasks ate my bandwidth. One of my resolutions for 2006 is to make time for those submissions. But then in the new message, you say: * A murky, poorly-documented, over-complex submission process. So, did you get your four or five packages done and submitted? And that's about all of the message I can take. Looking forward to next year's post. Consider an InfoGraphic for next year's post. Imagine what you can say with a chart! -- David Cantrell Red Hat / Westford, MA -------------- 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 gilboad at gmail.com Wed Feb 21 15:32:21 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 17:32:21 +0200 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <45DC6208.3070104@togami.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC6208.3070104@togami.com> Message-ID: <1172071941.9201.61.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 10:15 -0500, Warren Togami wrote: > Gilboa Davara wrote: > > > > Unless I'm mistaken, the original idea was that -devel members has to be > > sponsored before given rw rights. > > Being a fedora developer and/or an active -extras maintainer will just > > speed things up. > > No. fedora-devel-list was originally meant to be developer discussion > only. End-user support does not belong here at all. Unfortunately, > this list has been increasingly failing us for a few reasons: > > - "developer discussion" is a gray area > - policing is a manual process of constant vigilance. Effort today > leaves no lasting effects in a few days. Ouch. Bad phrasing on my side. I meant: A couple of of months ago it was suggest that the -devel ML will become semi-closed - pushing the public debates into a newly formed ML. > > What if more list members helped in the policing, making it an actively > hostile place for end-users to post support questions? I dunno... Personally, I can live with support questions. However, politics, flame-wars and the occasional troll makes my skin crawl. > > > > > I'm not saying that -devel should be limited to RH/FC/Extras members > > -only-, I am saying that something must be done to improve the > > signal-to-noise ratio. > > > > fedora-maintainers was created as an invite only list for this purpose. > The signal to noise ratio is a bit better there. I am personally fine > with inviting anybody with cvsextras access, or who has done something > substantive in infrastructure or docs to that list. /+1 I'm suggesting that -devel should mirror this behavior. (AFAIK maintainers is for packaging/cvs/extras/etc questions/problems - IMHO a similar ML should be created for development/long-term discussions) > > Warren Togami > wtogami at redhat.com - Gilboa From gilboad at gmail.com Wed Feb 21 15:33:07 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 17:33:07 +0200 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <34e52d0c0702210722u4e3669d6vc7d51f5e1f0cf34e@mail.gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC6208.3070104@togami.com> <34e52d0c0702210722u4e3669d6vc7d51f5e1f0cf34e@mail.gmail.com> Message-ID: <1172071987.9201.62.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 07:22 -0800, Randy Wyatt wrote: > > Gilboa Davara wrote: > > > > Unless I'm mistaken, the original idea was that -devel > members has to be > > sponsored before given rw rights. > > Being a fedora developer and/or an active -extras maintainer > will just > > speed things up. > > No. fedora-devel-list was originally meant to be developer > discussion > only. End-user support does not belong here at > all. Unfortunately, > this list has been increasingly failing us for a few reasons: > > - "developer discussion" is a gray area > - policing is a manual process of constant vigilance. Effort > today > leaves no lasting effects in a few days. > > What if more list members helped in the policing, making it an > actively > hostile place for end-users to post support questions? I > dunno... > > > Making any list actively hostile to end-users is a quick way to lose > end-users. This is one of the reasons I no longer use openSuSE. > ... but should end-users (with support questions) post in -devel? - Gilboa From wtogami at redhat.com Wed Feb 21 15:35:50 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Feb 2007 10:35:50 -0500 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <34e52d0c0702210722u4e3669d6vc7d51f5e1f0cf34e@mail.gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC6208.3070104@togami.com> <34e52d0c0702210722u4e3669d6vc7d51f5e1f0cf34e@mail.gmail.com> Message-ID: <45DC66D6.8080404@redhat.com> Randy Wyatt wrote: > > Making any list actively hostile to end-users is a quick way to lose > end-users. This is one of the reasons I no longer use openSuSE. > There are far better places to get end-user support, like fedoraforum.org or Bugzilla. It is simply off-topic to ask for end-user support on this list. It HURTS the project to increase the noise on this list, because it discourages useful people (developers) from reading the list on a regular basis. Warren Togami wtogami at redhat.com From kagesenshi.87 at gmail.com Wed Feb 21 15:45:26 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Wed, 21 Feb 2007 23:45:26 +0800 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <45DC66D6.8080404@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC6208.3070104@togami.com> <34e52d0c0702210722u4e3669d6vc7d51f5e1f0cf34e@mail.gmail.com> <45DC66D6.8080404@redhat.com> Message-ID: On 2/21/07, Warren Togami wrote: > Randy Wyatt wrote: > There are far better places to get end-user support, like > fedoraforum.org or Bugzilla. > > It is simply off-topic to ask for end-user support on this list. It > HURTS the project to increase the noise on this list, because it > discourages useful people (developers) from reading the list on a > regular basis. > I'm new here btw .. How about questions that related to codes or how something works internally - eg: how pilgrim does it job on making a liveCD rw (I know this question dont belong here but on fedora-livecd-list .. its juz an example ) .. for the reason of doing something that involve development / student research ?? .. Its not quite end user and not quite developer .. but something in the middle .. more technical than end user , but less than an actual development .. not to forget young/newbie developers who still learning on how to help in oss development is here is the right place to refer or theres somewhere else for that? > Warren Togami > wtogami at redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From andy at warmcat.com Wed Feb 21 15:51:47 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 21 Feb 2007 15:51:47 +0000 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <45DC5FDF.8020509@warmcat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC5FDF.8020509@warmcat.com> Message-ID: <45DC6A93.7040501@warmcat.com> Andy Green wrote: > Gilboa Davara wrote: > >>> Restricting access to the mailing list would, IMO, just paint a >>> picture of >>> Fedora developers as elitists -- and I don't think that's what you're >>> hoping >>> to achieve. > >> I'm not saying that -devel should be limited to RH/FC/Extras members >> -only-, I am saying that something must be done to improve the >> signal-to-noise ratio. > > Is that really true about the ratio? This ESR "from Hell's heart I stab > at thee" stuff is going to stay in its own thread. You can score the ...and it's not like pulling the bedcovers over the head and bouncing everyone who is not "one of us, one of us" out is going to resolve the actual issue either: http://www.linux.com/article.pl?sid=07/02/21/1340237 ''ESR gives up on Fedora Wednesday February 21, 2007 (01:33 PM GMT) By: Eric S. Raymond The following letter was received from ESR, who has sent it to a number of Linux-related publications and mailing lists. It is presented verbatim, except for the addition of HTML code. ...'' -Andy From gilboad at gmail.com Wed Feb 21 16:03:14 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 21 Feb 2007 18:03:14 +0200 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <45DC5FDF.8020509@warmcat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC5FDF.8020509@warmcat.com> Message-ID: <1172073794.9201.64.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 15:06 +0000, Andy Green wrote: > Gilboa Davara wrote: > > >> Restricting access to the mailing list would, IMO, just paint a picture of > >> Fedora developers as elitists -- and I don't think that's what you're hoping > >> to achieve. > > > I'm not saying that -devel should be limited to RH/FC/Extras members > > -only-, I am saying that something must be done to improve the > > signal-to-noise ratio. > > Is that really true about the ratio? This ESR "from Hell's heart I stab > at thee" stuff is going to stay in its own thread. You can score the > thread to nothing, but really since it does exist and involves Fedora > maybe it should get read. > This "core/moderator only" and "I mustn't be recorded" stuff going on is > a pattern I have seen elsewhere. I hope others have seen where it leads > too and maybe have some caution about it :-( A good idea is a good idea > even if it came from the keyboard of a non-anointed person... > I'm not saying that non-contributing user's voice should not be heard. Far from it. I am saying that fedora-devel should be dedicated to.... fedora developers/maintainers. - Gilboa From jfrieben at gmx.de Wed Feb 21 16:08:13 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Wed, 21 Feb 2007 17:08:13 +0100 Subject: rawhide report: 20070216 changes In-Reply-To: <1172069472.10910.4.camel@kloczek01.pracownicy.zie> References: <200702161239.l1GCdQUP027420@hs20-bc2-6.build.redhat.com> <1172069472.10910.4.camel@kloczek01.pracownicy.zie> Message-ID: <20070221160813.88640@gmx.net> > > gnome-terminal-2.17.91-3.fc7 > > ---------------------------- > > * Thu Feb 15 2007 Matthias Clasen - 2.17.91-3 > > - Add System to desktop file categories > > I just found some bug which seems does not exist in 2.17.90. > g-t runned with "-x ssh " negotiates $TERM "dumb". > If I run g-t and in this term session run "ssh " $TERM is > correct ("xterm"). There are issues with "vte-0.15.3", e.g. reported here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228720 Try to downgrade "vte" to version 0.15.2 or apply the patch attached to the above bug report. It's already fixed in "GNOME CVS". -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out From chitlesh at fedoraproject.org Wed Feb 21 16:13:16 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 21 Feb 2007 17:13:16 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <13dbfe4f0702210813y3e03a464icbc44e23a43b0ab0@mail.gmail.com> On 2/20/07, Jesse Keating wrote: > of bandwidth / space for such a temporary thing. I do believe we'll have a > Desktop (Gnome) LiveCD as well, perhaps a KDE one if the KDE folks kick some > butt. Perhaps the merge process of kde items should be pushed as well to let KDE folks work on this packages: http://fedoraproject.org/wiki/Extras/SIGs/KDE?action=AttachFile&do=get&target=meeting-2007-02-20_pm.txt Chitlesh -- http://clunixchit.blogspot.com From esr at thyrsus.com Wed Feb 21 16:19:00 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 11:19:00 -0500 Subject: Goodbye, Fedora In-Reply-To: <45DC4537.7060605@mesias.co.uk> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC4537.7060605@mesias.co.uk> Message-ID: <20070221161900.GB29340@thyrsus.com> Cam : > I'd be genuinely interested if you plan to write up your Ubuntu > experiences, good and bad. I searched for a blog but what I found was > mainly political (Islam etc.). Do you plan to write about your > experiences with Ubuntu somewhere? It's likely. -- Eric S. Raymond From sundaram at fedoraproject.org Wed Feb 21 16:20:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 21:50:13 +0530 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070221085333.239590@gmx.net> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> Message-ID: <45DC713D.7050007@fedoraproject.org> Joachim Frieben wrote: > > That's excellent news when "FC7T1" e.g. did not even include "gcc". That's because its a desktop cd and space is not infinite. I do not know about other users, but in my case, only about [downloaded] 100 MB of packages from "Fedora Extras" are part of my default setup, whereas I certainly have about 85% of the "Core" packages installed [the remainder is essentially composed of "KDE" related packages]. This makes me really wonder if removing the distinction between "Core" and "Extras" was a worthwile task [whereas I fully welcome the use of a unified build system for both]. Doubling the volume of the distribution to increase package coverage [by usage] by less than 10% still seems questionable to me, especially when the impact on install media distribution ["bittorrent"] is so severe. You have to taken into consideration the general case. Not just yourself. Rahul From karsten at redhat.com Wed Feb 21 16:35:08 2007 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 21 Feb 2007 11:35:08 -0500 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc?) In-Reply-To: <45DC66D6.8080404@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC6208.3070104@togami.com> <34e52d0c0702210722u4e3669d6vc7d51f5e1f0cf34e@mail.gmail.com> <45DC66D6.8080404@redhat.com> Message-ID: <45DC74BC.5060003@redhat.com> Warren Togami schrieb: > Randy Wyatt wrote: >> >> Making any list actively hostile to end-users is a quick way to lose >> end-users. This is one of the reasons I no longer use openSuSE. >> > > There are far better places to get end-user support, like > fedoraforum.org or Bugzilla. > Bugzilla is NOT a place to get support, please go back and read the main page again: 'Bugzilla is not an avenue for technical assistance or support, but simply a bug tracking system.' I'd appreciate it if you wouldn't encourage our users to clog bugzilla with support requests. Thanks Karsten From jfrieben at gmx.de Wed Feb 21 16:33:19 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Wed, 21 Feb 2007 17:33:19 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <45DC713D.7050007@fedoraproject.org> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> <45DC713D.7050007@fedoraproject.org> Message-ID: <20070221163319.24790@gmx.net> > That's excellent news when "FC7T1" e.g. did not even include "gcc". > > That's because its a desktop cd and space is not infinite. No it's a 2.5 out of 4.5 GB DVD, and there were no other spins available for users with needs going beyond a pure desktop setup. > I do not know about other users, but in my case, only about > [downloaded] 100 MB of packages from "Fedora Extras" are part of my > default setup, whereas I certainly have about 85% of the "Core" packages > installed [the remainder is essentially composed of "KDE" related > packages]. This makes me really wonder if removing the distinction > between "Core" and "Extras" was a worthwile task [whereas I fully > welcome the use of a unified build system for both]. Doubling the volume > of the distribution to increase package coverage [by usage] by less than > 10% still seems questionable to me, especially when the impact on > install media distribution ["bittorrent"] is so severe. > > You have to taken into consideration the general case. Not just yourself. That's why I wrote "I do not know about other users", but even as a poor individual, I am presumably entitled to raise the **question** of how many of the most popular/needed packages are to be found in the respective respositories [50/50, 95/05, etc. (?)] .. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From sundaram at fedoraproject.org Wed Feb 21 16:39:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 22:09:55 +0530 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070221163319.24790@gmx.net> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> <45DC713D.7050007@fedoraproject.org> <20070221163319.24790@gmx.net> Message-ID: <45DC75DB.4000900@fedoraproject.org> Joachim Frieben wrote: >> That's excellent news when "FC7T1" e.g. did not even include "gcc". >> >> That's because its a desktop cd and space is not infinite. > > No it's a 2.5 out of 4.5 GB DVD, and there were no other spins available for users with needs going beyond a pure desktop setup. Right. It was clearly mentioned within the release announcement itself. No point harping on it. Right? > That's why I wrote "I do not know about other users", but even as a poor individual, I am presumably entitled to raise the **question** of how many of the most popular/needed packages are to be found in the respective respositories [50/50, 95/05, etc. (?)] .. Nobody has any metrics there but it is quite large for some users. There is a plan to add package lists to smolt in a optional way to collect this. See Fedora advisory board list archives for details. Rahul From jwboyer at jdub.homelinux.org Wed Feb 21 16:40:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Feb 2007 10:40:08 -0600 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <45DC713D.7050007@fedoraproject.org> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> <45DC713D.7050007@fedoraproject.org> Message-ID: <1172076008.24204.179.camel@zod.rchland.ibm.com> On Wed, 2007-02-21 at 21:50 +0530, Rahul Sundaram wrote: > Joachim Frieben wrote: > > > > That's excellent news when "FC7T1" e.g. did not even include "gcc". > > That's because its a desktop cd and space is not infinite. > > I do not know about other users, but in my case, only about > [downloaded] 100 MB of packages from "Fedora Extras" are part of my > default setup, whereas I certainly have about 85% of the "Core" packages > installed [the remainder is essentially composed of "KDE" related > packages]. This makes me really wonder if removing the distinction > between "Core" and "Extras" was a worthwile task [whereas I fully > welcome the use of a unified build system for both]. Doubling the volume > of the distribution to increase package coverage [by usage] by less than > 10% still seems questionable to me, especially when the impact on > install media distribution ["bittorrent"] is so severe. > > You have to taken into consideration the general case. Not just yourself. Yet you question the merge based on _your_ currently installed package set? Um... wtf? josh From jkeating at redhat.com Wed Feb 21 16:42:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 11:42:41 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070221163319.24790@gmx.net> References: <200702201758.15925.jkeating@redhat.com> <45DC713D.7050007@fedoraproject.org> <20070221163319.24790@gmx.net> Message-ID: <200702211142.45308.jkeating@redhat.com> On Wednesday 21 February 2007 11:33, Joachim Frieben wrote: > That's why I wrote "I do not know about other users", but even as a poor > individual, I am presumably entitled to raise the **question** of how many > of the most popular/needed packages are to be found in the respective > respositories [50/50, 95/05, etc. (?)] .. It isn't about popularity. It's about putting all the packages into the same place so that the same people can work on all the packages, and that (build)deps can work out correctly. Continuing to have an arbitrary split doesn't help anybody. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Feb 21 16:43:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 22:13:14 +0530 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <45DC76A2.5000404@fedoraproject.org> Eric S. Raymond wrote: > The proximate causes of this failure were (1) incompetent repository > maintenance, making any nontrivial upgrade certain to founder on a > failed dependency, and (2) the fact that rpm is not statically linked > -- so it's possible to inadvertently remove a shared library it > depends on and be unrecoverably screwed. But the underlying problems > run much deeper. We only have your analysis of the problem. Not a description of the actual problem. That would be more helpful. Perhaps a bug report. > * Chronic governance problems. More details required. I have a special interest in this. * Persistent failure to maintain key repositories in a sane, consistent state from which upgrades might actually be possible. > > * A murky, poorly-documented, over-complex submission process. Last time you claimed this, I requested you to point out specific issues which you agreed to. That was never delivered. Your actual submission was struck after the reviewer pointed out some things to fix https://www.redhat.com/archives/fedora-devel-list/2006-December/msg00538.html https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220736 > * Allowing RPM development to drift and stagnate -- then adding > another layer of complexity, bugs, and wretched performance with yum. RPM indeed drifted but I dont think it actually stagnated. Anyway http://rpm.org for more details. RPM doesnt do automatic dependency resolving. Yum does. I did read somewhere your claim that introducing yum was a big change that put Fedora in a position of advantage or some such thing. > * Effectively abandoning the struggle for desktop market share. Unless this is just about proprietary codecs, Red Hat continues to do a lot of work on the desktop http://fedoraproject.org/wiki/RedHatContributions > * Failure to address the problem of proprietary multimedia formats with > any attitude other than blank denial. We spend a lot of time even recently on FUDCon Boston 2007 discussing this. See http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy Rahul From bruno at wolff.to Wed Feb 21 16:42:14 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 21 Feb 2007 10:42:14 -0600 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070221163319.24790@gmx.net> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> <45DC713D.7050007@fedoraproject.org> <20070221163319.24790@gmx.net> Message-ID: <20070221164214.GA3047@wolff.to> On Wed, Feb 21, 2007 at 17:33:19 +0100, Joachim Frieben wrote: > > That's excellent news when "FC7T1" e.g. did not even include "gcc". > > > > That's because its a desktop cd and space is not infinite. > > No it's a 2.5 out of 4.5 GB DVD, and there were no other spins available for users with needs going beyond a pure desktop setup. It isn't that hard to make an everything DVD out of F7 core. You can use lftp to mirror it, remove some redundant packages (at times there are two copies openoffice in the repo) to get the space down, add a dummy .discinfo file and then make a dvd iso to burn. I can't do the last step from memory, but have a short script. You can also use pungi to make your own install dvd. Several lists of packages have been posted that you could use as a basis. However to do this you either need an FC6 system with mock or F7. I am using FC5 right now, so I couldn't use Pungi. From buildsys at redhat.com Wed Feb 21 16:46:48 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 21 Feb 2007 11:46:48 -0500 Subject: rawhide report: 20070221 changes Message-ID: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> Updated Packages: amanda-2.5.1p3-1.fc7 -------------------- * Mon Feb 19 2007 Jay Fenlason 2.5.1p3-1.fc7 - Upgrade to new upstream release, now that 2.5.1 is somewhat stable. - Note that this requires changing the xinetd configuration and amanda.conf because of the new authentication mechanism. - -server subpackage does not require xinetd. - -server scriptlets do not need to reload xinetd. anaconda-11.2.0.25-1 -------------------- * Tue Feb 20 2007 Chris Lumens - 11.2.0.25-1 - Add libtinfo to the stage2 images. - Use new pykickstart organization. - Change default French layout to latin9 (#229269). - Add maketreeinfo.py script (Will Woods ). at-3.1.10-8.fc7 --------------- * Tue Feb 20 2007 Marcela Maslanova - 3.1.10-8 - review - rhbz#225288 * Tue Jan 30 2007 Marcela Maslanova - 3.1.10-7 - no debug file - useless - new pam configuration - rhbz#224597 audit-1.4.2-1.fc7 ----------------- * Tue Feb 20 2007 Steve Grubb 1.4.2-1 - Add man pages - Reduce text relocations in parser library - Add -n option to auditd for no fork - Add exec option to space_left, admin_space_left, disk_full, and disk_error - eg EXEC /usr/local/script automake-1.10-5 --------------- * Tue Feb 20 2007 Karsten Hopp 1.10-5 - fix some rpmlint warnings * Tue Feb 20 2007 Karsten Hopp 1.10-4 - bz 225302: - make install DESTDIR=... - fix BuildRoot - fix post/preun requirements - define all directories on ./configure line - filter perl(Automake*) dependencies - replace all tabs with spaces - remove trailing dot from summary automake15-1.5-19 ----------------- * Tue Feb 20 2007 Karsten Hopp 1.5-19 - use ./configure * Mon Feb 19 2007 Karsten Hopp 1.5-18 - use spaces instead of tabs - remove trailing dot from summary - use make install DESTDIR=... - drop requirement on perl - install info files as automake15.info automake16-1.6.3-9 ------------------ * Tue Feb 20 2007 Karsten Hopp 1.6.3-9 - merge review fixes automake17-1.7.9-8 ------------------ * Mon Feb 19 2007 Karsten Hopp 1.7.9-8 - misc. cleanups for review checkpolicy-2.0.1-1.fc7 ----------------------- * Mon Nov 20 2006 Dan Walsh - 2.0.1-1 - Latest update from NSA * Merged patch to allow dots in class identifiers from Caleb Case. coolkey-1.1.0-1.fc7 ------------------- * Tue Feb 20 2007 Bob Relyea - 1.1.0-1 - Pick up lates release. coreutils-6.7-8.fc7 ------------------- * Tue Feb 20 2007 Tim Waugh 6.7-8 - Don't mark profile scripts as config files (bug #225655). - Avoid extra directory separators (bug #225655). * Mon Feb 19 2007 Tim Waugh 6.7-7 - Better Obsoletes/Provides versioning (bug #225655). - Use better defattr (bug #225655). - Be info file compression tolerant (bug #225655). - Moved changelog compression to %install (bug #225655). - Prevent upstream changes being masked (bug #225655). - Added a comment (bug #225655). - Use install -p for non-compiled files (bug #225655). - Use sysconfdir macro for /etc (bug #225655). - Use Requires(pre) etc for install-info (bug #225655). cpio-2.6-27.fc7 --------------- * Tue Feb 20 2007 Peter Vrabec 2.6-27 - fix typo in changelog * Thu Feb 08 2007 Ruben Kerkhof 2.6-26 - Preserve timestamps when installing files * Thu Feb 08 2007 Peter Vrabec 2.6-25 - set cpio bindir properly createrepo-0.4.8-1.fc7 ---------------------- * Wed Feb 21 2007 Jeremy Katz - 0.4.8-1 - update to 0.4.8 file-4.19-4.fc7 --------------- * Tue Feb 20 2007 Martin Bacovsky - 4.19-4.fc7 - rpath in file removal gtkhtml3-3.13.91-2.fc7 ---------------------- * Tue Feb 20 2007 Matthew Barnes - 3.13.91-2.fc7 - GtkHtml no longer depends on libgnomeprint[ui]. kernel-2.6.20-1.2936.fc7 ------------------------ * Tue Feb 20 2007 Dave Jones - 2.6.20-git15 * Sat Feb 17 2007 Dave Jones - 2.6.20-git14 (Now tickless on 32bit x86). - Fix up VIA SATA. less-394-9.fc7 -------------- * Tue Feb 20 2007 Ivana Varekova - 394-9 - change /etc/profile.d script's permissions libevent-1.2a-1 --------------- * Tue Feb 20 2007 Steve Dickson - Updated to latest upstream version 1.2a libselinux-2.0.1-1.fc7 ---------------------- * Tue Feb 20 2007 Dan Walsh - 2.0.1-1 - Upgrade to upstream * Merged patch from Todd Miller to convert int types over to C99 style. libsemanage-2.0.0-1.fc7 ----------------------- * Tue Feb 20 2007 Dan Walsh - 2.0.0-1 - Upgrade to latest from NSA * Merged Makefile test target patch from Caleb Case. * Merged get_commit_number function rename patch from Caleb Case. * Merged strnlen -> strlen patch from Todd Miller. logwatch-7.3.4-1.fc7 -------------------- * Tue Feb 20 2007 Ivana Varekova 7.3.4-1 - update to 7.3.4 mesa-6.5.2-5.fc7 ---------------- * Tue Feb 20 2007 Adam Jackson 6.5.2-5 - General spec cleanups - Require current libdrm - Build with -fvisibility=hidden - Redo the way mesa-source is generated - Add %{?_smp_mflags} where appropriate nfs-utils-lib-1.0.8-8.fc7 ------------------------- * Tue Feb 20 2007 Steve Dickson 1.0.8-8 - Updated libnfsidmap to the 0.19 release * Fri Dec 01 2006 Steve Dickson 1.0.8-7.3 - Fixed typo in the package description (bz 189652) pirut-1.3.0-1.fc7 ----------------- * Tue Feb 20 2007 Jeremy Katz - 1.3.0-1 - Fix a translation problem (#228237) - Start of support for CDs. To test for now, you need to have yum 3.1.2 and add a mediaid= line to your repo. mediaid is the first line of .discinfo from your media policycoreutils-2.0.2-3.fc7 --------------------------- * Tue Feb 20 2007 Dan Walsh 2.0.2-3 - Updated newrole NONBlOCK patch * Tue Feb 20 2007 Dan Walsh 2.0.2-2 - Remove Requires: policycoreutils-plugins * Tue Feb 20 2007 Dan Walsh 2.0.2-1 - Update to upstream * Merged seobject exception handler fix from Caleb Case. * Merged setfiles memory leak patch from Todd Miller. pykickstart-0.96-1.fc7 ---------------------- * Tue Feb 20 2007 Chris Lumens - 0.96-1 - Fix __str__ methods for langsupport and reboot commands. - Renamed BaseHandler.empty to BaseHandler.maskAllExcept. - Split command objects out into their own files in commands/. - Rename command objects to start with Version_. - Support extended group selection syntax. python-virtinst-0.101.0-2.fc7 ----------------------------- * Tue Feb 20 2007 Daniel P. Berrange - 0.101.0-2.fc7 - Remove obsolete patches * Tue Feb 20 2007 Daniel P. Berrange - 0.101.0-1.fc7 - Updated to 0.101.0 to enable QEMU support samba-0:3.0.24-2.fc7 -------------------- * Tue Feb 20 2007 Simo Sorce 3.0.24-2.fc7 - New upstream release - Fix packaging issue wrt idmap modules used only by smbd - Addedd Vista Patchset for compatibility with Windows Vista - Change default of "msdfs root", it seem to cause problems with some applications and it has been proposed to change it for 3.0.25 upstream * Fri Sep 01 2006 Jay Fenlason 3.0.23c-2 - New upstream release. * Tue Aug 08 2006 Jay Fenlason 3.0.23b-2 - New upstream release. selinux-policy-2.5.4-1.fc7 -------------------------- setools-3.1-3.fc7 ----------------- * Tue Feb 20 2007 Dan Walsh 3.1-3 - Fix conflict with tcl/init.tcl setroubleshoot-1.9.1-1.fc7 -------------------------- * Fri Feb 16 2007 Dan Walsh - 1.9.1-1 - Split into server and gui packages * Fri Feb 16 2007 Dan Walsh - 1.8.19-1 - Remove use of ctypes in uuid, which is causing bad avc messages sound-juicer-2.16.3-1.fc7 ------------------------- * Tue Feb 20 2007 - Bastien Nocera - 2.16.3-1 - Update to 2.16.3 spamassassin-3.1.8-2.fc7 ------------------------ * Mon Feb 19 2007 Warren Togami 3.1.8-2 - Fix sa-learn regression (#228968) sysklogd-1.4.1-48.fc7 --------------------- * Tue Feb 20 2007 Peter Vrabec 1.4.1-48 - fixing another issues from (#226448) * Tue Feb 20 2007 Peter Vrabec 1.4.1-47 - fix spec file to meet Fedora standards (#226448) totem-2.17.92-2.fc7 ------------------- * Wed Feb 21 2007 - Bastien Nocera - 2.17.92-2 - Add gstreamer-plugins-good as a builddep so that gconfaudiosink can be found during configure * Wed Feb 21 2007 - Bastien Nocera - 2.17.92-1 - Update to 2.17.92 virt-manager-0.3.1-2.fc7 ------------------------ * Tue Feb 20 2007 Daniel P. Berrange - 0.3.1-2.fc7 - Only check for HVM on Xen hypervisor * Tue Feb 20 2007 Daniel P. Berrange - 0.3.1-1.fc7 - Added support for managing QEMU domains - Automatically grab mouse pointer to workaround dual-cursor crazyness xorg-x11-drv-acecad-1.1.0-3.fc7 ------------------------------- * Tue Feb 20 2007 Adam Jackson 1.1.0-3 - ExclusiveArch -> ExcludeArch - Disown directories xorg-x11-drv-aiptek-1.0.1-3.fc7 ------------------------------- * Tue Feb 20 2007 Adam Jackson 1.0.1-3 - ExclusiveArch -> ExcludeArch - Don't own directories already owned by Xorg xorg-x11-drv-apm-1.1.1-3.fc7 ---------------------------- * Thu Feb 15 2007 Adam Jackson 1.1.1-3 - ExclusiveArch -> ExcludeArch xorg-x11-drv-magictouch-1.0.0.5-3.fc7 ------------------------------------- * Tue Feb 20 2007 Adam Jackson 1.0.0.5-3 - ExclusiveArch -> ExcludeArch - Disown the driver directory xorg-x11-server-1.2.0-6.fc7 --------------------------- * Mon Feb 05 2007 Adam Jackson 1.2.0-6 - xorg-x11-server-Red-Hat-extramodes.patch: - Add 1360x768 normal and reduced-blanking. - Add reduced-blanking versions of 1680x1050 and 1920x{1200,1080}. - Remove the >60Hz versions of 2560x1600. Even leaving the 60Hz timing is kind of ridiculous, since every real LCD that size I've seen uses the reduced blanking timings. But presumably if you have that nice of a monitor, you also have a video card with working DDC. yum-3.1.2-1.fc7 --------------- * Wed Feb 21 2007 Jeremy Katz - 3.1.2-1 - 3.1.2 * Wed Feb 14 2007 Jeremy Katz - 3.1.1-3 - learn about kernel-debug (#228709) * Tue Feb 13 2007 James Bowes - 3.1.1-2 - Spec file updates from the merge review: use correct buildroot, mark logrotate file as noreplace, require correct versions of python and rpm, use name macro in source0. zlib-1.2.3-7.fc7 ---------------- * Tue Feb 20 2007 Adam Tkac - 1.2.3-7 - building is now automatized - specfile cleanup * Tue Feb 20 2007 Ivana Varekova - 1.2.3-6 - remove the compilation part to build section some minor changes * Mon Feb 19 2007 Ivana Varekova - 1.2.3-5 - incorporate package review feedback Broken deps for i386 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.i386 requires libpt_linux_x86_r.so.1.10.3 nfs-utils - 1:1.0.10-4.fc7.i386 requires librpcsecgss.so.2 nfs-utils - 1:1.0.10-4.fc7.i386 requires libevent-1.1a.so.1 Broken deps for x86_64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.x86_64 requires libpt_linux_x86_64_r.so.1.10.3()(64bit) nfs-utils - 1:1.0.10-4.fc7.x86_64 requires librpcsecgss.so.2()(64bit) nfs-utils - 1:1.0.10-4.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc64 requires libpt_linux_ppc64_r.so.1.10.3()(64bit) nfs-utils - 1:1.0.10-4.fc7.ppc64 requires librpcsecgss.so.2()(64bit) nfs-utils - 1:1.0.10-4.fc7.ppc64 requires libevent-1.1a.so.1()(64bit) Broken deps for ia64 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ia64 requires libpt_linux_ia64_r.so.1.10.3()(64bit) nfs-utils - 1:1.0.10-4.fc7.ia64 requires librpcsecgss.so.2()(64bit) nfs-utils - 1:1.0.10-4.fc7.ia64 requires libevent-1.1a.so.1()(64bit) pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.ppc requires libpt_linux_ppc_r.so.1.10.3 nfs-utils - 1:1.0.10-4.fc7.ppc requires librpcsecgss.so.2 nfs-utils - 1:1.0.10-4.fc7.ppc requires libevent-1.1a.so.1 Broken deps for s390 ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390 requires libpt_linux_s390_r.so.1.10.3 nfs-utils - 1:1.0.10-4.fc7.s390 requires librpcsecgss.so.2 nfs-utils - 1:1.0.10-4.fc7.s390 requires libevent-1.1a.so.1 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- ekiga - 2.0.4-1.fc7.s390x requires libpt_linux_s390x_r.so.1.10.3()(64bit) nfs-utils - 1:1.0.10-4.fc7.s390x requires librpcsecgss.so.2()(64bit) nfs-utils - 1:1.0.10-4.fc7.s390x requires libevent-1.1a.so.1()(64bit) From mattdm at mattdm.org Wed Feb 21 16:51:22 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Feb 2007 11:51:22 -0500 Subject: Goodbye, Fedora In-Reply-To: <45DC76A2.5000404@fedoraproject.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> Message-ID: <20070221165122.GA29425@jadzia.bu.edu> On Wed, Feb 21, 2007 at 10:13:14PM +0530, Rahul Sundaram wrote: > >The proximate causes of this failure were (1) incompetent repository > >maintenance, making any nontrivial upgrade certain to founder on a > >failed dependency, and (2) the fact that rpm is not statically linked > >-- so it's possible to inadvertently remove a shared library it > >depends on and be unrecoverably screwed. But the underlying problems > >run much deeper. > We only have your analysis of the problem. Not a description of the > actual problem. That would be more helpful. Perhaps a bug report. Yes, excellent advice. Eric, here's a document which may help you get better answers rather than the storm of flames: . -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Wed Feb 21 16:57:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 22:27:02 +0530 Subject: Goodbye, Fedora In-Reply-To: <45DC76A2.5000404@fedoraproject.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> Message-ID: <45DC79DE.2040009@fedoraproject.org> > Eric S. Raymond wrote: > > * Persistent failure to maintain key repositories in a sane, > consistent state from which upgrades might actually be possible. Ah. Forgot to add. F7 update system should fix the major problems proactively by adding checks to ensure that dependencies are resolving and there is a proper update path for every package being pushed out but repositories doesnt seem to be in a bad state with regards to upgrades as per the EVR check reports in fedora-maintainers list. http://fedoraproject.org/wiki/Releases/FeatureUpdateSystem Rahul From fedora at camperquake.de Wed Feb 21 17:15:53 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 21 Feb 2007 18:15:53 +0100 Subject: rawhide report: 20070221 changes In-Reply-To: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> References: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> Message-ID: <20070221181553.3e3f8854@banea.int.addix.net> Hi. On Wed, 21 Feb 2007 11:46:48 -0500, buildsys at redhat.com wrote: > kernel-2.6.20-1.2936.fc7 > ------------------------ > * Tue Feb 20 2007 Dave Jones > - 2.6.20-git15 > > * Sat Feb 17 2007 Dave Jones > - 2.6.20-git14 (Now tickless on 32bit x86). > - Fix up VIA SATA. Something is strage with this one, at least with the header files. kernel-PAE-devel-2.6.20-1.2936.fc7: include/linux/timex.h includes include/asm/timex.h includes include/asm/tsc.h which just contains #include which is not in the devel files. include/asm/asm-i386.h contains the same, so there is a kind of a system. The kernel seems to run fine, however. Is there a way to "see" that tickless works? From selinux at gmail.com Wed Feb 21 17:21:59 2007 From: selinux at gmail.com (Tom London) Date: Wed, 21 Feb 2007 09:21:59 -0800 Subject: rawhide report: 20070221 changes In-Reply-To: <20070221181553.3e3f8854@banea.int.addix.net> References: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> <20070221181553.3e3f8854@banea.int.addix.net> Message-ID: <4c4ba1530702210921k5f6b5f10p531e530e34a8e2d9@mail.gmail.com> On 2/21/07, Ralf Ertzinger wrote: > Hi. > > On Wed, 21 Feb 2007 11:46:48 -0500, buildsys at redhat.com wrote: > > > kernel-2.6.20-1.2936.fc7 > > ------------------------ > > * Tue Feb 20 2007 Dave Jones > > - 2.6.20-git15 > > > > * Sat Feb 17 2007 Dave Jones > > - 2.6.20-git14 (Now tickless on 32bit x86). > > - Fix up VIA SATA. > > Something is strage with this one, at least with the header files. > > kernel-PAE-devel-2.6.20-1.2936.fc7: > include/linux/timex.h includes > include/asm/timex.h includes > include/asm/tsc.h which just contains > > #include > > which is not in the devel files. > > include/asm/asm-i386.h contains the same, so there is a kind of > a system. > > The kernel seems to run fine, however. Is there a way to "see" that > tickless works? > BZ'ed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229489 -- Tom London From giallu at gmail.com Wed Feb 21 17:40:37 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Feb 2007 18:40:37 +0100 Subject: rawhide report: 20070221 changes In-Reply-To: <20070221181553.3e3f8854@banea.int.addix.net> References: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> <20070221181553.3e3f8854@banea.int.addix.net> Message-ID: On 2/21/07, Ralf Ertzinger wrote: > Hi. > > On Wed, 21 Feb 2007 11:46:48 -0500, buildsys at redhat.com wrote: > > > kernel-2.6.20-1.2936.fc7 > > ------------------------ > > * Tue Feb 20 2007 Dave Jones > > - 2.6.20-git15 > > > > * Sat Feb 17 2007 Dave Jones > > - 2.6.20-git14 (Now tickless on 32bit x86). > > - Fix up VIA SATA. > > Something is strage with this one, at least with the header files. > > kernel-PAE-devel-2.6.20-1.2936.fc7: > include/linux/timex.h includes > include/asm/timex.h includes > include/asm/tsc.h which just contains > > #include > > which is not in the devel files. > And my rebuild of sysprof-kmod failed for this reason. From davej at redhat.com Wed Feb 21 17:51:05 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Feb 2007 12:51:05 -0500 Subject: F7t2 and QA Meeting In-Reply-To: <20070221122743.GB2557@devserv.devel.redhat.com> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> Message-ID: <20070221175105.GG19851@redhat.com> On Wed, Feb 21, 2007 at 07:27:43AM -0500, Alan Cox wrote: > On Tue, Feb 20, 2007 at 10:44:15PM -0500, Dave Jones wrote: > > > A patch to fix the problem was accepted into the libata tree this > > > morning, so it should show up in the mainline kernel -git soon. > > > > That specific bug /should/ be fixed in the fedora kernel that'll hit > > rawhide tomorrow. > > The current libata tree is totally broken, cable detect is broken on intel > chipsets at least, the resource changes cause the pcmcia driver to panic and > various other stuff seems to have been upset in the current set of changes. FWIW, 2.6.20 isn't faring much better right now either. The pending FC5/FC6 update got it's first cut at a testable RPM last night, and fell over in so many spectacular ways I'd be embarressed to release it. With .21 in rc now, hopefully the final .21 will be a lot better for F7. F6 is in need of much surgery though. Dave -- http://www.codemonkey.org.uk From jfrieben at gmx.de Wed Feb 21 17:51:38 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Wed, 21 Feb 2007 18:51:38 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <45DC75DB.4000900@fedoraproject.org> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> <45DC713D.7050007@fedoraproject.org> <20070221163319.24790@gmx.net> <45DC75DB.4000900@fedoraproject.org> Message-ID: <20070221175138.36510@gmx.net> > Nobody has any metrics there but it is quite large for some users. There > is a plan to add package lists to smolt in a optional way to collect > this. See Fedora advisory board list archives for details. > > Rahul It appears to me more logical to have started with exactly investigating these metrics before doubling the whole distribution by adding "Extras" to "Core". The qualifier "quite large" sounds fairly fuzzy. Maybe some other "Fedora" users would like to step in and let us know how much of "Extras" they actually use [preferably in terms of MB]? -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From ajackson at redhat.com Wed Feb 21 17:47:10 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 21 Feb 2007 12:47:10 -0500 Subject: rawhide report: 20070220 changes In-Reply-To: <1172045393.9201.0.camel@gilboa-work-dev.localdomain> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> <1171970537.18231.3.camel@gilboa-work-dev.localdomain> <1171985098.13597.52.camel@localhost.localdomain> <1171986242.13597.53.camel@localhost.localdomain> <1172045393.9201.0.camel@gilboa-work-dev.localdomain> Message-ID: <1172080030.29812.3.camel@localhost.localdomain> On Wed, 2007-02-21 at 10:09 +0200, Gilboa Davara wrote: > On Tue, 2007-02-20 at 10:44 -0500, Adam Jackson wrote: > > On Tue, 2007-02-20 at 10:24 -0500, Adam Jackson wrote: > > > On Tue, 2007-02-20 at 13:22 +0200, Gilboa Davara wrote: > > > > On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > > > > > > > > > > > > > > Updated Packages: > > > > > > > > > libdrm-2.3.0-4.fc7 > > > > > ------------------ > > > > > * Mon Feb 19 2007 Adam Jackson 2.3.0-4 > > > > > - Update nouveau patch > > > > > - Fix License tag and other rpmlint noise > > > > > > > > OT question (that might not be related...) > > > > Any idea when the latest DRI drivers (especially, mach64 and nv) will > > > > imported into the kernel tree? > > > > > > nv already is, though I might be a bit behind. > > > > > > If there are significant mach64 changes since the last time Dave Airlie > > > pushed stuff upstream, it's news to me, but I admit to not watching > > > mach64 development very closely. > > > > I should clarify. The DRM is pretty close to current, afaik. Mesa is > > behindish; not sure what the right thing to do there is. > > > > - ajax > > > > Would the latest Mesa/DRM combo will find it's way into F7? The question is how much breakage people are willing to put up with. Mesa doesn't release very often, and has a lot of churn. While I certainly _can_ start doing snapshots... That said I'm looking at some Mesa stuff this week, so hopefully I'll get a better idea of how stable head is right now. - ajax From jkeating at redhat.com Wed Feb 21 18:00:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 13:00:26 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070221175138.36510@gmx.net> References: <200702201758.15925.jkeating@redhat.com> <45DC75DB.4000900@fedoraproject.org> <20070221175138.36510@gmx.net> Message-ID: <200702211300.27123.jkeating@redhat.com> On Wednesday 21 February 2007 12:51, Joachim Frieben wrote: > It appears to me more logical to have started with exactly investigating > these metrics before doubling the whole distribution by adding "Extras" to > "Core". The qualifier "quite large" sounds fairly fuzzy. Maybe some other > "Fedora" users would like to step in and let us know how much of "Extras" > they actually use [preferably in terms of MB]? You are missing the point. We aren't adding Extras to Core to make the distro bigger, or to get these Extras packages on media. We're merging so that the entire Fedora community has access to directly contribute (ie write access to SCM) to what is the Fedora distribution. We're still going to make decisions about what to put on media and what not to put on media (with the exception of the silly EVERYTHING spin that so many people seem to want, and would have wanted it to include Extras before). The whole point of the merger though is to get all the software in one place, to allow for things that were previously in Core to BuildRequire things that are in Extras without having to move them into Core, and to allow the community at large maintain the distribution at large. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Feb 21 18:02:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Feb 2007 23:32:32 +0530 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070221175138.36510@gmx.net> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> <45DC713D.7050007@fedoraproject.org> <20070221163319.24790@gmx.net> <45DC75DB.4000900@fedoraproject.org> <20070221175138.36510@gmx.net> Message-ID: <45DC8938.2080904@fedoraproject.org> Joachim Frieben wrote: >> Nobody has any metrics there but it is quite large for some users. There >> is a plan to add package lists to smolt in a optional way to collect >> this. See Fedora advisory board list archives for details. >> >> Rahul > > It appears to me more logical to have started with exactly investigating these metrics before doubling the whole distribution by adding "Extras" to "Core". The qualifier "quite large" sounds fairly fuzzy. Maybe some other "Fedora" users would like to step in and let us know how much of "Extras" they actually use [preferably in terms of MB]? Idealistic. If we had lots of contributors and time, we could have the right amount of data before we do anything but the result of Free software in general is that users can take and use things without letting anyone including the developers know about it. We know we need to collect more information and those have to be opt-in (which means it is guaranteed to be incomplete but better than having no data at all). Are you willing to help with infrastructure to get this metrics? How do you propose we do that for F7 or in the absence of that how do you want F7 media sets to be? You are questioning the whole merger of core and extras just by your usage of a few extras packages while the benefits are much more than just being able to put more packages into the media. In fact putting all the packages into media doesnt require a merge at all. Rahul From jfrieben at gmx.de Wed Feb 21 18:05:55 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Wed, 21 Feb 2007 19:05:55 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <45DC8938.2080904@fedoraproject.org> References: <200702201758.15925.jkeating@redhat.com> <20070221085333.239590@gmx.net> <45DC713D.7050007@fedoraproject.org> <20070221163319.24790@gmx.net> <45DC75DB.4000900@fedoraproject.org> <20070221175138.36510@gmx.net> <45DC8938.2080904@fedoraproject.org> Message-ID: <20070221180555.36510@gmx.net> > Are you willing to help with infrastructure to get this metrics? How do > you propose we do that for F7 or in the absence of that how do you want > F7 media sets to be? You are questioning the whole merger of core and > extras just by your usage of a few extras packages while the benefits > are much more than just being able to put more packages into the media. > In fact putting all the packages into media doesnt require a merge at all. > > Rahul Ok, ok. Let's stop here. There is no objection whatsoever. I welcome the common build system and the merger as such. I was simply concerned by the possible implications for the accessibility of install media due to the increased distribution size discussed earlier on this list. Thanks! -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out From kloczek at zie.pg.gda.pl Wed Feb 21 15:18:13 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 21 Feb 2007 16:18:13 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172071093.10910.25.camel@kloczek01.pracownicy.zie> Dnia 21-02-2007, ?ro o godzinie 03:03 -0500, Eric S. Raymond napisa?(a): [..] > I have watched Ubuntu rise to these challenges as Fedora fell away > from them. Canonical's recent deal with Linspire, which will give > Linux users legal access to WMF and other key proprietary codecs, is > precisely the sort of thing Red-Hat/Fedora could and should have taken > the lead in. Not having done so bespeaks a failure of vision which I > now believe will condemn Fedora to a shrinking niche in the future. But .. WMF is *fully supported in Fedora* 8-> Look at libwmf package wchich provides library for handling this format. This package provides library for handling WMF files and also gtk+ DSO loader which enalbes using WMF files for examle in all GTK+/GNOME applications. You wrote "WMF" but probably in this case you though about "WMV". Packages with codecs for this and other proprietar formats as sam as in in Ubunt case are maintained _outside_ core packages set (leagal reasons) .. so there is no *big/any* diffrence beetween Fedora and Ubuntu on this area. Please decide Raymond .. are you have technical problems with Fedora "packages dependencies" (why are you not describe all your problems on this list ?) or with legion of "political problems" ? (own problems ?). kloczek From esr at thyrsus.com Wed Feb 21 18:25:01 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 13:25:01 -0500 Subject: Goodbye, Fedora In-Reply-To: <45DC76A2.5000404@fedoraproject.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> Message-ID: <20070221182501.GA31710@thyrsus.com> Rahul Sundaram : > We only have your analysis of the problem. Not a description of the > actual problem. That would be more helpful. Perhaps a bug report. You have half of it. rpm should be statically linked to avoid this sort of cul-de-sac. It's not like multople instances of it running are going to be a frequent occurrence. I can tell you the library in question was libcom_err, and I think I deleted it when removing e2fsprogs-libs to get around a file conflict. But with rpm not working I couldn't reinstall the library. Boot failed, ssh/sshd failed -- I had to kluge with netcat and tar just to back up my files. It was horrible. Alas, I no longer have the logs, as I lost them during installation. I don't recall what the file was, but the conflict was completely avoidable and would never have occurred if the repo and RPMs had been in a sane state. > >* Chronic governance problems. > > More details required. I have a special interest in this. I was thinking of the the endless internal wrangling over what to do about the core/extras split, and the years the project has spent failing to engage with third-party developers and repo maintainers. That IRC-session parody of Fedora politics somebody wrote back around 2002 remains as painfully on-point today as it was then. The Fedora project has never resolved the tension between Red Hat's business need for it to be an adjunct of RHEL development and its core group's stated aim to be community-facing. The result is a sociology that has increasingly combined the least useful features of a corporate project with the least useful snakepit-like features of 'community' politics -- as perfectly illustrated by the list response to my goodbye note. > >* A murky, poorly-documented, over-complex submission process. > > Last time you claimed this, I requested you to point out specific issues > which you agreed to. That was never delivered. Your actual submission > was struck after the reviewer pointed out some things to fix I was doing what I told Jesse Keating I'd do -- using that submission as a probe of the process, and planning to write up a narrative of the difficulties and some recommendations once it was done. (I'll note that I thought the reviewer did a good job of critique, so the early indications were somewhat positive.) The things I could address in that particular submission were trivial and are fixed, as I noted in a comment attached to the bug. I was waiting on resubmitting until Mike Smith shipped a new stylesheet RPM, as that was critical to fixing the man-page glitches. Now it's no longer my problem. > >* Allowing RPM development to drift and stagnate -- then adding > > another layer of complexity, bugs, and wretched performance with yum. > > RPM indeed drifted but I dont think it actually stagnated. Anyway > http://rpm.org for more details. RPM doesnt do automatic dependency > resolving. Yum does. I did read somewhere your claim that introducing > yum was a big change that put Fedora in a position of advantage or some > such thing. Yes, I thought so at the time. But yum failed to live up to what I thought was considerable early promise. It remained painfully slow and buggy. Improvements in dependency resolution that seemed conceptually obvious to me were never made. The most obvious of these would have been a clique analysis of mass updates to fail the smallest possible subset hanging on a missing dependency, rather than failing the entire update. I used to be a mathematician, I have the graph-theory chops to do something about this, and I tried to contribute some refactoring patches that would have led in this direction. They were rejected, and I had other things to do. > >* Effectively abandoning the struggle for desktop market share. > > Unless this is just about proprietary codecs, Red Hat continues to do a > lot of work on the desktop To no visible result. You had the developers, the first-mover advantage, and the corporate backing; you lacked the vision and the will to follow through. Ubuntu shows what could have been done -- but if you guys had executed correctly, Ubuntu's market- and mindshare would be at best statistical noise (if it existed at all). > >* Failure to address the problem of proprietary multimedia formats with > > any attitude other than blank denial. > > We spend a lot of time even recently on FUDCon Boston 2007 discussing > this. See http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy Again, to no visible result. And with zealots screaming their heads off against it whenever the topic came up on fedora-devel. I wound up expecting that any Fedora 'solution' would be half-hearted and ineffective and involve far too much sneering at users' actual needs and too little effort spent on actually meeting them. The wiki page does nothing to disabuse me of this expectation by using terms like "brainwashing". The contempt for mere users this exhibits is very revealing, and is a significant part of the reason I've decamped. Meanwhile, Ubuntu and Linspire are actually addressing the problem at its root. They might get it solved in time to meet the 64-bit deadline Rob Landley and I have seen coming, but Fedora clearly will not. So much for Fedora. -- Eric S. Raymond From ianburrell at gmail.com Wed Feb 21 18:28:22 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Wed, 21 Feb 2007 10:28:22 -0800 Subject: Goodbye, Fedora In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> Message-ID: On 2/21/07, Oisin Feeley wrote: > > On a more useful note, does anyone have any idea of exactly which > package ESR is claiming caused the complete meltdown of his system? > Is he actually claiming that "yum update " on a FC6 system > caused the problems that he mentions? Or is he actually referring to > how the ItEatsBabiesAndYouWereWarned rawhide ate his babies? > > This sort of bug report is not helpful as it's slim on concrete > details and leaves a murky wake of confusion. There's some good > advice on how to avoid that type of thing in these two links: > The ekiga update from today has broken dependencies. Error: Missing Dependency: opal >= 2.2.5 is needed by package ekiga Error: Missing Dependency: libpt_linux_x86_r.so.1.10.4 is needed by package ekiga Error: Missing Dependency: pwlib >= 1.10.4 is needed by package ekiga It looks like the opal and pwlib versions it needs are in updates-testing. Excluding ekiga with "yum --exclude=ekiga update" allows the rest of the packages to update. Enabling updates-testing repository with "yum --enablerepo=updates-testing update ekiga" allows ekiga to be updated. - Ian From lsof at nodata.co.uk Wed Feb 21 18:33:22 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 21 Feb 2007 19:33:22 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172082803.19442.1.camel@sb-home.lan> [snip] I figured, OK, since the morning is shot anyway, I might as well go to the diner for some breakfast. It?s one of those classic New York diners, like the one on Seinfeld. There?s a thirty page menu and a kitchen the size of a phone booth. It doesn?t make sense. They must have Star Trek technology to get all those ingredients into such a small space. Maybe they rearrange atoms on the spot. I was sitting by the cash register. An older woman came up to pay her check. As she was paying, she said to the owner, ?you know, I?ve been coming here for years and years, and that waiter was really rather rude to me.? The owner was furious. ?What do you mean? No he wasn?t! He?s a good waiter! I never had a complaint!? The customer couldn?t believe it. Here she was, a loyal customer, and she wanted to help out the owner by letting him know that one of his waiters needed a little bit of help in the manners department, but the owner was arguing with her! ?Well, that?s fine, but I?ve been coming here for years, and everybody is always very nice to me, but that guy was rude to me,? she explained, patiently. ?I don?t care if you?ve been coming here forever. My waiters are not rude.? The owner proceeded to yell at her. ?I never had no problems. Why are you making problems?? ?Look, if you?re going to treat me this way I won?t come back.? ?I don?t care!? said the owner. One of the great things about owning a diner in New York is that there are so many people in the city that you can offend every single customer who ever comes into your diner and you?ll still have a lot of customers. ?Don?t come back! I don?t want you as a customer!? Good for you, I thought. Here?s a 60-something year old man, owner of a diner, and you won some big moral victory against a little old lady. Are you proud of yourself? How macho do you have to be? Does the moral victory make you feel better? Did you really have to lose a repeat customer? Would it have made you feel totally emasculated to say, ?I?m so sorry. I?ll have a word with him?? It?s easy to get caught up in the emotional heat of the moment when someone is complaining. -- http://www.joelonsoftware.com/articles/customerservice.html From fedora at leemhuis.info Wed Feb 21 18:41:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Feb 2007 19:41:10 +0100 Subject: [EPEL] EPEL -- the way forward Message-ID: <45DC9246.6060307@leemhuis.info> Hi all! The idea to build Fedora (Extras) Packages for RHEL and compatible distros like CentOS in the scope of the Fedora Project is over half a year old now, but didn't really take of yet. This mail (and some other work in other places like the wiki) tries to actually get the idea running a bit more faster now in the hope that the project actually takes of soon. So what needs to be done: - actually discuss the way forward with contributors and get some feedback of potential users and contributors -- done in parts now that you read the mail, as this is one of the purposes why it was written ;-) - find the final name -- done already, there was (still|once again) some discussion to use a different name for the Project. It was agreed (agreed=no one did yell until now) on by certain EPEL SIG members that we use a slightly variant of what was used until now -- e.g. instead of "Extras Packages for Enterprise Linux" we'll use "(Fedora) Extra Packages for Enterprise Linux" (note: Extra and not Extra*s*) and will stick to EPEL as FLA (four letter acronym). - update the wiki and put some useful and crucial informations into it -- done mostly already. See http://fedoraproject.org/wiki/EPEL for the current state. Some stuff will probably be added depending on what this discussion brings up. Note that there are quite more informations in the wiki (including a FAQ) then this mail contains. Also note that everything in the wiki is still under discussion and might change. - create a fully functional SIG (see http://fedoraproject.org/wiki/EPEL/SIG ) that takes care of EPEL, meets on IRC regularly and make sure things are moving forward. In progress already. Want to join? Simply add your name to the SIG list in the wiki. - create a "EPEL Release Manager group", that together with the package owners is actually responsible for the EL repo. They step up if maintainers don't react in time to fix stuff like security fixes, broken deps and similar issues that create problems for our userbase. - allow all Extras contributors to maintain their packages in EPEL, if they want to and are aware of the consequences; means: -- the package needs to be supported until the End Of Life (EOL) of the Distributions they were build for -- round about seven years. Sure, nobody of us knows if he still be around then. But you should not build packages for EPEL if you plan to moe oer to other stuff soon or find packaging really annoying -- realize that the rules in EPEL are stricter -- if you don't keep track of you package properly someone from the "EPEL Release Manager group" might just fix your package. If that happens multiple times the package might get hand over to somebody else, if that the best for the repo as a whole - find a kind of update and release policy. See http://www.fedoraproject.org/wiki/EnterpriseExtras/FAQ#head-e5ac329823844f8d9a4136a88591e10ae3a58289 ; proposed is to have a kind of rolling release, but with a careful and strict update policy where only stuff that really needs a update for a good reasons gets done. Updating to the latest and greatest version is not possible quite often in any case, as a lot of newer packages will depend on new versions of certain core-libs (say gtk, qt, and a lot of others), which we in quite a lot of cases simply won't have available when the distribution we support is 12 months or older. So why update parts to the latest and greatest while keeping other parts on older ersions and having a distro as a base that people are paying for because it doesn't change - actually start building the repo up with packages people want to maintain and the most important packages from Fedora Extras. Maybe we get some very rough stats from the Fedora Extras repository servers to actually have a rough idea of which packages are popular, so we get them build for EPEL soon and from the beginning. Ask the Fedora package maintainers if they want to maintain them in EPEL -- if not try to find another maintainer for EPEL quickly (the people interested in EPEL probably might have to take care of a lot of packages in the beginning). - get the inital batch of important and popular packages online into a testing channel until end of march - Make sure we have a group of people watching the usual security lists and file bugs for open issues. - and move them to a proper channel after some weeks if everything seems to work. - In parallel try to the second batch try to get all the other Fedora packages into EPEL, but leave the "obscure" stuff out of it. - EL-4 branches will get created from the FE-3 branch, EL-5 packages from the FC-6 branch I probably missed a lot of stuff. But that's why I wrote this mail, so you can tell me and the other members of the EPEL Sig what we missed so we can actually take care of it. Your interested to help? Then join the SIG by adding your name to the EPEL-SIG page in the wiki and join us in the first meeting -- that's scheduled for Sunday, the 25th at 16:00 UTC in #fedora-meeting on the freenode network. The mailing list for further discussions around EPEL will be fedora-devel-list (this list); please use the tag [EPEL] in the subject so people that are not interested in the other stuff from fedora-devel-list can filter for it. Thanks in advance. Cu thl From jkeating at redhat.com Wed Feb 21 18:50:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 13:50:50 -0500 Subject: Goodbye, Fedora In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <200702211350.53468.jkeating@redhat.com> On Wednesday 21 February 2007 13:28, Ian Burrell wrote: > The ekiga update from today has broken dependencies. > > Error: Missing Dependency: opal >= 2.2.5 is needed by package ekiga > Error: Missing Dependency: libpt_linux_x86_r.so.1.10.4 is needed by > package ekiga > Error: Missing Dependency: pwlib >= 1.10.4 is needed by package ekiga > > It looks like the opal and pwlib versions it needs are in updates-testing. > > Excluding ekiga with "yum --exclude=ekiga update" allows the rest of > the packages to update. ?Enabling updates-testing repository with "yum > --enablerepo=updates-testing update ekiga" allows ekiga to be updated. I honestly have no idea how this happened. I did a depcheck before pushing the update. That said, I'm pushing the missing packages now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From icon at fedoraproject.org Wed Feb 21 18:50:13 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 21 Feb 2007 13:50:13 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: On 2/21/07, Eric S. Raymond wrote: > I was thinking of the the endless internal wrangling over what to do > about the core/extras split, and the years the project has spent > failing to engage with third-party developers and repo maintainers. > That IRC-session parody of Fedora politics somebody wrote back around > 2002 remains as painfully on-point today as it was then. No, it's not. Every point I've raised in that mockalogue has been largely addressed. Red Hat is not even conflicted by Fedora any more, as it seems to have finally gotten through to the sales drones that people who are using Fedora aren't likely to pay for a RHEL license anyway, so offering Fedora does not translate into lost sales. Lots of problems remain, especially now that the Core/Extras merger is making everyone's life miserable due to the fact that packaging procedures have been changing daily (or so it seems) since early February, but that's a hurdle that is being actively worked on -- once the dust settles, things will clear up and new docs will be written. Everything is far from being "broken" as you imply, and you will find that grass may not necessarily be greener on the other side -- just different flavours of the same weed. -- Konstantin Ryabitsev Montr?al, Qu?bec From andy at warmcat.com Wed Feb 21 18:55:28 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 21 Feb 2007 18:55:28 +0000 Subject: The Long Goodbye In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <45DC95A0.3030801@warmcat.com> Eric S. Raymond wrote: > I can tell you the library in question was libcom_err, and I think I > deleted it when removing e2fsprogs-libs to get around a file conflict. > But with rpm not working I couldn't reinstall the library. Boot failed, > ssh/sshd failed -- I had to kluge with netcat and tar just to back up > my files. It was horrible. > > Alas, I no longer have the logs, as I lost them during installation. > I don't recall what the file was, but the conflict was completely > avoidable and would never have occurred if the repo and RPMs had been > in a sane state. Why does "booted from the install media in recovery mode" not feature in this anywhere? Then you could have wgetted http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/Fedora/RPMS/e2fsprogs-libs-1.39-7.i386.rpm from inside the recovery boot and installed it after a chroot or with --root= on rpm. Yesterday I rendered this laptop unbootable by broken code I added to the iwlwifi driver sources: I was back up in five minutes thanks to the recovery boot, deleting the driver and rebooting into the kernel so I could fix it and go on. That experience, like each time I use the recovery boot, left me feeling grateful for the feature and empowered, that even with a half trashed system I can force it back to life. Whereas without it, you were left feeling very different. > To no visible result. You had the developers, the first-mover > advantage, and the corporate backing; you lacked the vision and the > will to follow through. Ubuntu shows what could have been done -- but > if you guys had executed correctly, Ubuntu's market- and mindshare > would be at best statistical noise (if it existed at all). ... > its root. They might get it solved in time to meet the 64-bit > deadline Rob Landley and I have seen coming, but Fedora clearly will > not. So much for Fedora. Rob sent me a link to your thesis some weeks ago, but as I told him then it seems completely bogus to me. Some geeky metric like the sizeof(int) going to control whether the man in the street switches OS or not. Crushing Ubuntu isn't what the other OSes are about. If you look at it from, say, a Gnome or kernel perspective where RHAT are active, is it a loser globally for RHAT if Gnome or the kernel are gaining in popularity in another distro? So it is a lot more nuanced, Fedora is not a commercial entity where there is per-user revenue and retarding the competition advances yourself. While there are hundreds of thousands of users it has a lot of meaning, especially seen as a Fedora / RHEL / CentOS axis where the OS semantics are all compatible. I paid to get my *RH*CE, a Canonical or Linspire version won't do. -Andy From jwhiter at redhat.com Wed Feb 21 18:58:06 2007 From: jwhiter at redhat.com (Josef Whiter) Date: Wed, 21 Feb 2007 13:58:06 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <20070221185806.GD4451@korben.rdu.redhat.com> On Wed, Feb 21, 2007 at 01:25:01PM -0500, Eric S. Raymond wrote: > Rahul Sundaram : > > We only have your analysis of the problem. Not a description of the > > actual problem. That would be more helpful. Perhaps a bug report. > > You have half of it. rpm should be statically linked to avoid this sort > of cul-de-sac. It's not like multople instances of it running are > going to be a frequent occurrence. > Then why did you not propose this till now? If this is something that is such a big issue for you, why not bring it up until this rather noisy uneeded exit? If you had before hand then I apologize and please show me where I can read what happened, but if not, isn't the wonderful thing about open source building a better produce through collaboration? > I can tell you the library in question was libcom_err, and I think I > deleted it when removing e2fsprogs-libs to get around a file conflict. > But with rpm not working I couldn't reinstall the library. Boot failed, > ssh/sshd failed -- I had to kluge with netcat and tar just to back up > my files. It was horrible. > > Alas, I no longer have the logs, as I lost them during installation. > I don't recall what the file was, but the conflict was completely > avoidable and would never have occurred if the repo and RPMs had been > in a sane state. > What repo? What was the conflict? Did you file a bugzilla before you went hacking away? If there is a problem it needs to be tracked and fixed. Again, I thought this was how Open Source software was supposed to work. > > >* Chronic governance problems. > > > > More details required. I have a special interest in this. > > I was thinking of the the endless internal wrangling over what to do > about the core/extras split, and the years the project has spent > failing to engage with third-party developers and repo maintainers. > That IRC-session parody of Fedora politics somebody wrote back around > 2002 remains as painfully on-point today as it was then. > AFAIK core/extras is no longer split, I'm not sure my head has been in the sand for the last 4 or 5 months. What 3rd party developers and repo maintainers specifically are you talking about? Have you offered up a solution to this so-called problem? > The Fedora project has never resolved the tension between Red Hat's > business need for it to be an adjunct of RHEL development and its core > group's stated aim to be community-facing. The result is a sociology > that has increasingly combined the least useful features of a corporate > project with the least useful snakepit-like features of 'community' > politics -- as perfectly illustrated by the list response to my goodbye > note. > Welcome to human nature. This community is not what the problem is, it is simple human nature to take your angry tirade marking all of the things we "do wrong" without any suggestions of what to do right and to lash out against it, as its a personal offense to everybody who has worked on this project in order to make it better. This is a wonderful and helpful community, and if you write things as you do to be offensive to those humans in the community, then expect some/many of them to react as any other human would, with anger. > > >* Allowing RPM development to drift and stagnate -- then adding > > > another layer of complexity, bugs, and wretched performance with yum. > > > > RPM indeed drifted but I dont think it actually stagnated. Anyway > > http://rpm.org for more details. RPM doesnt do automatic dependency > > resolving. Yum does. I did read somewhere your claim that introducing > > yum was a big change that put Fedora in a position of advantage or some > > such thing. > > Yes, I thought so at the time. But yum failed to live up to what I thought > was considerable early promise. It remained painfully slow and buggy. > Improvements in dependency resolution that seemed conceptually obvious > to me were never made. > Then fix it. If the problems are so obvious to you why did you not submit patches? Yum works fine for me, so I'm not going to try and fix it, but if its not working for you, where are the bugzillas detailing the problems you have, and the patches to fix them? I know you are a capable programmer, if these things are so obvious and so much of a pain, why did you not fix them yourself and submit them upstream? Isn't that the open source way? > The most obvious of these would have been a clique analysis of mass > updates to fail the smallest possible subset hanging on a missing > dependency, rather than failing the entire update. I used to be a > mathematician, I have the graph-theory chops to do something about > this, and I tried to contribute some refactoring patches that would > have led in this direction. They were rejected, and I had other > things to do. > Ok so instead of working with the developers in order to get these things resolved, you just dropped them to do other things. So who's fault is this again? It works fine for me, and apparently other people as well, we aren't just going to read your mind or pick up after your work, if you feel that something needs to be changed then why not try your hardest until some sort of solution is gained? All I see through this little tirade of yours is that you have no interest in actually fixing problems, just complaining about them, and then not even complaining about them in a manner which gets them fixed, just in inflammatory ways in order to get attention. As I said before, the way things are done now work fine for me, so I'm not going to change them, and this goes for every individual, if it does what they need it to, they aren't going to change it. So if it doesn't do what you need it to do, change it, or make sure somebody knows it doesn't do what you need it to and try to work towards a solution. Josef From hughsient at gmail.com Wed Feb 21 18:59:34 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Feb 2007 18:59:34 +0000 Subject: Goodbye, Fedora In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <1172084374.11813.6.camel@hughsie-laptop> On Wed, 2007-02-21 at 13:25 -0500, Eric S. Raymond wrote: > I can tell you the library in question was libcom_err, and I think I > deleted it when removing e2fsprogs-libs to get around a file conflict. > But with rpm not working I couldn't reinstall the library. So you manually removed a critical system library and wondered why things broke? Have you ever tried randomly deleting .dll files in Windows XP? Richard. From tbrinkman at sbcglobal.net Wed Feb 21 18:17:45 2007 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Wed, 21 Feb 2007 12:17:45 -0600 Subject: F7t2 and QA Meeting In-Reply-To: <200702201241.54939.tbrinkman@sbcglobal.net> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <200702201241.54939.tbrinkman@sbcglobal.net> Message-ID: <200702211217.45436.tbrinkman@sbcglobal.net> On Tuesday 20 February 2007, Tom Brinkman wrote: > On Tuesday 20 February 2007, Jay Cliburn wrote: > > Will Woods wrote: > > > As Jesse announced on fedora-devel-list, the code freeze for > > > Fedora 7, Test 2 is today (this evening, US EST). > > > > I'm not sure when you intend to freeze the kernel for F7T2 > > (perhaps today?), but the current kernel -git, along with the > > existing rawhide 2930 and 2932 kernels (and maybe the previous > > one, too), won't boot from a VIA SATA 6420, 6421, or 8237A > > controller. I'd guess this affects a pretty good number F7 > > testers who use SATA on a VIA chipset motherboard. > > > > A patch to fix the problem was accepted into the libata tree > > this morning, so it should show up in the mainline kernel -git > > soon. > > > > Jay > > +1 Mine is a 6420. Boot is on pata > 00:0f.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > > ....but I have a sata storage drive that prevents boot. > 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 > SATA RAID Controller (rev 80) > > 2.6.20-1.2925.fc7 boots with no problems 2936 fixed my sata issues. Thanks! -- Tom Brinkman Corpus Christi, Texas From sundaram at fedoraproject.org Wed Feb 21 19:21:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Feb 2007 00:51:41 +0530 Subject: Goodbye, Fedora In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <45DC9BC5.6080704@fedoraproject.org> Eric S. Raymond wrote: > I can tell you the library in question was libcom_err, and I think I > deleted it when removing e2fsprogs-libs to get around a file conflict. > But with rpm not working I couldn't reinstall the library. Boot failed, > ssh/sshd failed -- I had to kluge with netcat and tar just to back up > my files. It was horrible. Well, deleting a critical library in a random fashion to avoid conflicts isnt exactly a bright idea. > Alas, I no longer have the logs, as I lost them during installation. > I don't recall what the file was, but the conflict was completely > avoidable and would never have occurred if the repo and RPMs had been > in a sane state. Perhaps but a proper bug report on the conflict and RFE's on whatever suggestions you had on improving it would have been better. We cant verify or deny your problem now. > I was thinking of the the endless internal wrangling over what to do > about the core/extras split, and the years the project has spent > failing to engage with third-party developers and repo maintainers. I dont think we had any internal wrangling about that. Mostly it was clear we had to bring them together as much as possible and the idea that we are going to combine them in some way has been floating for a while. The merge is very disruptive but it is a very significant step forward. Possibly the best step we have every taken since the project launch. Third party repo maintainers like Mathias and Axel continue to be heavily involved in Fedora now. I would say we did engage them. > That IRC-session parody of Fedora politics somebody wrote back around > 2002 remains as painfully on-point today as it was then. Except it appears that the person who wrote it doesnt now agree with you on that. > I was doing what I told Jesse Keating I'd do -- using that submission > as a probe of the process, and planning to write up a narrative of the > difficulties and some recommendations once it was done. (I'll note > that I thought the reviewer did a good job of critique, so the early > indications were somewhat positive.) I dont see how you could continue claiming that it is poorly documented if you hadnt gone through the process completely. Please either specify the problem or drop your claim. Spending a lot of time on something only to get vague criticism repeatedly is very frustrating. >>> * Effectively abandoning the struggle for desktop market share. >> Unless this is just about proprietary codecs, Red Hat continues to do a >> lot of work on the desktop > > To no visible result. You had the developers, the first-mover > advantage, and the corporate backing; you lacked the vision and the > will to follow through. Ubuntu shows what could have been done -- but > if you guys had executed correctly, Ubuntu's market- and mindshare > would be at best statistical noise (if it existed at all). I wouldnt describe the work on fundamental pieces of desktop such as HAL, DBus, Network Manager, AIGLX and so on as having no visible result. >> We spend a lot of time even recently on FUDCon Boston 2007 discussing >> this. See http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy > > Again, to no visible result. And with zealots screaming their heads off > against it whenever the topic came up on fedora-devel. I wound up > expecting that any Fedora 'solution' would be half-hearted and ineffective > and involve far too much sneering at users' actual needs and too little > effort spent on actually meeting them. You are just too early to see any results of this work. Judging the list discussion to be reflective on the software development assumes that the list discussions is actually from the developers. > The wiki page does nothing to disabuse me of this expectation by using > terms like "brainwashing". The contempt for mere users this exhibits is > very revealing, and is a significant part of the reason I've decamped. You just lose your sense of humor there. Rahul From Axel.Thimm at ATrpms.net Wed Feb 21 19:35:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 21 Feb 2007 20:35:55 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <20070221193555.GO7699@neu.nirvana> On Wed, Feb 21, 2007 at 01:25:01PM -0500, Eric S. Raymond wrote: > Rahul Sundaram : > > We only have your analysis of the problem. Not a description of the > > actual problem. That would be more helpful. Perhaps a bug report. > > You have half of it. rpm should be statically linked to avoid this sort > of cul-de-sac. It's not like multople instances of it running are > going to be a frequent occurrence. No, that's not really an issue, see below for the kernel analogon. > I can tell you the library in question was libcom_err, and I think I > deleted it when removing e2fsprogs-libs to get around a file > conflict. Whatever the conflict may have been, in order to rip out a library needed by other bits you need to use force (--nodeps) or an equivalent step in a higher level tool. E.g. this does not happen accidentally, you had to remove the safety pin. It's like removing ext3.ko from the kernel and rebooting. If you can access your data anymore would you conclude that a monolithic kernel would had been better? In fact the package system employed in Fedora (rpm) did have the dependencies in place and warned you when you tried to remove the package w/o using --nodeps. There is no such safety mechanism for the kernel, so would you recommend even stringer to have monolithic kernels? And even if rpm was build statically, you (or another user) may have accidentially used rpm -e --nodeps rpm or even simpler rm -f /bin/rpm and be in the same situation. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Wed Feb 21 19:42:07 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 21 Feb 2007 20:42:07 +0100 Subject: rawhide report: 20070221 changes In-Reply-To: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> References: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> Message-ID: <45DCA08F.8080508@gmail.com> > kernel-2.6.20-1.2936.fc7 > ------------------------ > * Tue Feb 20 2007 Dave Jones > - 2.6.20-git15 > > * Sat Feb 17 2007 Dave Jones > - 2.6.20-git14 (Now tickless on 32bit x86). > - Fix up VIA SATA. > why only 32bit? any plans for a tickless kernel for 64bit? I am running x86_64 on my core2duo based laptop and would like to see how much power this saves / how it affects battery life. From davej at redhat.com Wed Feb 21 19:51:27 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Feb 2007 14:51:27 -0500 Subject: rawhide report: 20070221 changes In-Reply-To: <45DCA08F.8080508@gmail.com> References: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> <45DCA08F.8080508@gmail.com> Message-ID: <20070221195127.GC13794@redhat.com> On Wed, Feb 21, 2007 at 08:42:07PM +0100, dragoran wrote: > > > kernel-2.6.20-1.2936.fc7 > > ------------------------ > > * Tue Feb 20 2007 Dave Jones > > - 2.6.20-git15 > > > > * Sat Feb 17 2007 Dave Jones > > - 2.6.20-git14 (Now tickless on 32bit x86). > > - Fix up VIA SATA. > > > why only 32bit? because thats all thats been merged upstream so far. > any plans for a tickless kernel for 64bit? should be eventually. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Wed Feb 21 19:51:06 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 21 Feb 2007 20:51:06 +0100 Subject: rawhide report: 20070217 changes In-Reply-To: References: <200702171052.l1HAqLe2010342@hs20-bc2-6.build.redhat.com> Message-ID: <45DCA2AA.1030408@gmail.com> Kevin Kofler wrote: > redhat.com> writes: > >> - Disable kqemu support since its not in Fedora qemu binary >> > > Can't this be enabled now that it's GPL? I'm not asking you or anyone else to > maintain the kmod, just to build QEMU and libvirt with support for it so > someone else can build it and have it just work. > > I currently only use QEMU to emulate different arches, so I don't personally > have a use for kqemu, but other people may. > > +1 I use kvm on my laptop (it has vmx) and kqemu + qemu on my (no hvm capable) opteron box. so please enable support for this. having to rebuild it for each update to get it working with a gpl module sux. it should just work when the module is here. > Kevin Kofler > > From esr at thyrsus.com Wed Feb 21 19:59:19 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 14:59:19 -0500 Subject: Goodbye, Fedora In-Reply-To: <45DC9BC5.6080704@fedoraproject.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> Message-ID: <20070221195919.GB4620@thyrsus.com> Rahul Sundaram : > Perhaps but a proper bug report on the conflict and RFE's on whatever > suggestions you had on improving it would have been better. We cant > verify or deny your problem now. I would have been happy to give you a detailed bug report -- if my system had remained *usable*. As it is, I was too busy trying to figure out a way not to lose all of my personal files in the reinstall. > >The wiki page does nothing to disabuse me of this expectation by using > >terms like "brainwashing". The contempt for mere users this exhibits is > >very revealing, and is a significant part of the reason I've decamped. > > You just lose your sense of humor there. Oh, yes, it's very funny that Greg deKoenigsberg -- who is supposed to be some kind of responsible adult supervision -- implies that anybody who wants to watch YouTube or listen to a podcast is a glassy-eyed zombie. Ha ha. See me laugh. Yes, that is *exactly* the kind of attitude that will get us above 4% market share. Not. -- Eric S. Raymond From jkeating at redhat.com Wed Feb 21 20:10:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 15:10:49 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221195919.GB4620@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> Message-ID: <200702211510.49895.jkeating@redhat.com> On Wednesday 21 February 2007 14:59, Eric S. Raymond wrote: > Yes, that is *exactly* the kind of attitude that > will get us above 4% market share. ?Not. Market share means nothing if we sacrifice our core values for a few more percentage points. Why do we care if people use Linux? Well we want them to use opensource software and contribute. We want to free them from proprietary lock in. We want to give them freedom. Handing them a stack of closed source software is not the way to accomplish those goals. All it does is muddy the line between us in the %4, and the other guys in the remaining %. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Wed Feb 21 20:09:33 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 21 Feb 2007 21:09:33 +0100 Subject: rawhide report: 20070221 changes In-Reply-To: <20070221195127.GC13794@redhat.com> References: <200702211646.l1LGkmpr027883@hs20-bc2-6.build.redhat.com> <45DCA08F.8080508@gmail.com> <20070221195127.GC13794@redhat.com> Message-ID: <45DCA6FD.4080104@gmail.com> Dave Jones wrote > On Wed, Feb 21, 2007 at 08:42:07PM +0100, dragoran wrote: > > > > > kernel-2.6.20-1.2936.fc7 > > > ------------------------ > > > * Tue Feb 20 2007 Dave Jones > > > - 2.6.20-git15 > > > > > > * Sat Feb 17 2007 Dave Jones > > > - 2.6.20-git14 (Now tickless on 32bit x86). > > > - Fix up VIA SATA. > > > > > why only 32bit? > > because thats all thats been merged upstream so far. > > ok good answer ;) > > any plans for a tickless kernel for 64bit? > > should be eventually. > ok hope this gets in (upstream) before the feature freeze. do you now whats holding it from being merged. (I haven't tracked tickless development recently so I have no idea whats happening) > Dave > > From sundaram at fedoraproject.org Wed Feb 21 20:16:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Feb 2007 01:46:23 +0530 Subject: Goodbye, Fedora In-Reply-To: <20070221195919.GB4620@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> Message-ID: <45DCA897.5000403@fedoraproject.org> Eric S. Raymond wrote: > > Oh, yes, it's very funny that Greg deKoenigsberg -- who is supposed to be > some kind of responsible adult supervision -- implies that anybody who > wants to watch YouTube or listen to a podcast is a glassy-eyed zombie. > Ha ha. See me laugh. Yes, that is *exactly* the kind of attitude that > will get us above 4% market share. Not. Just a quite note. Bill Nottingham wrote that. Not Greg Dek. Just so that you can blame the right people for some self depreciating humor .. or not. Rahul From drago01 at gmail.com Wed Feb 21 20:18:38 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 21 Feb 2007 21:18:38 +0100 Subject: The Long Goodbye In-Reply-To: <45DC95A0.3030801@warmcat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <45DC95A0.3030801@warmcat.com> Message-ID: <45DCA91E.2050406@gmail.com> Andy Green wrote: > Eric S. Raymond wrote: > > Why does "booted from the install media in recovery mode" not feature > in this anywhere? Then you could have wgetted > > http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/Fedora/RPMS/e2fsprogs-libs-1.39-7.i386.rpm > > > from inside the recovery boot and installed it after a chroot or with > --root= on rpm. > > Yesterday I rendered this laptop unbootable by broken code I added to > the iwlwifi driver sources: I was back up in five minutes thanks to > the recovery boot, deleting the driver and rebooting into the kernel > so I could fix it and go on. > > That experience, like each time I use the recovery boot, left me > feeling grateful for the feature and empowered, that even with a half > trashed system I can force it back to life. Whereas without it, you > were left feeling very different. same here wanted to install d80211 and deleted all my kernel modules by acciedent (only noticed after reboot; only one kernel installed) I reinstalled the kernel in rescue mode and the system was up and running again in less then 10 min. From mmcgrath at redhat.com Wed Feb 21 20:28:45 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Feb 2007 14:28:45 -0600 Subject: The wiki is upgraded! Message-ID: <45DCAB7D.7000406@redhat.com> The wiki is now upgraded! There's bound to be minor odds and ends to fix up over the coming days, I ask that if anyone finds something broken they email me and I'll start fixing issues one by one. -Mike From esr at thyrsus.com Wed Feb 21 20:30:08 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 15:30:08 -0500 Subject: Core values In-Reply-To: <200702211510.49895.jkeating@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> Message-ID: <20070221203008.GA5696@thyrsus.com> Jesse Keating : > Market share means nothing if we sacrifice our core values for a few more > percentage points. This is so out of contact with reality that it makes me grind my teeth. Want to fix or scrap the damned patent system? Want to get the damned DMCA repealed? Do you want even as little a thing as 3D graphics and wireless cards with open specs? To get these things, we certainly need market share over 30% and probably need market share over 50%. We need politicians and vendors to fear our wrath. It wasn't 'sacrificing our core values' to ship a binary Netscape blob until Mozilla was ready. It won't be sacrificing our core values to ship proprietary codecs until we are positioned to crush them out of existence. The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is nowhere near the only reason I'm gone, but it's a big one. -- Eric S. Raymond -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jima at beer.tclug.org Wed Feb 21 20:32:22 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 21 Feb 2007 14:32:22 -0600 (CST) Subject: The wiki is upgraded! In-Reply-To: <45DCAB7D.7000406@redhat.com> References: <45DCAB7D.7000406@redhat.com> Message-ID: On Wed, 21 Feb 2007, Mike McGrath wrote: > The wiki is now upgraded! There's bound to be minor odds and ends to fix up > over the coming days, I ask that if anyone finds something broken they email > me and I'll start fixing issues one by one. I imagine I speak for a number of people when I say: Thanks, Mike! Jima From mail at robertoragusa.it Wed Feb 21 20:46:03 2007 From: mail at robertoragusa.it (Roberto Ragusa) Date: Wed, 21 Feb 2007 21:46:03 +0100 Subject: anaconda update time needs to be improved (really) In-Reply-To: <1171980552.21468.5.camel@gibraltar.stuttgart.redhat.com> References: <45423F30.7030600@feuerpokemon.de> <45DAEEB2.8060700@robertoragusa.it> <1171980552.21468.5.camel@gibraltar.stuttgart.redhat.com> Message-ID: <45DCAF8B.30506@robertoragusa.it> Nils Philippsen wrote: > On Tue, 2007-02-20 at 13:50 +0100, Roberto Ragusa wrote: > >> So I renamed /mnt/sysconfig/sbin/ldconfig away and replaced with >> a copy of /bin/true. The installation speed went up a lot, I'd say >> it's 10 times faster now. >> >> I suppose that running ldconfig continously is not useful, it could >> be done just once at the end of the upgrade. > > Not quite I think. Other (later-run) scripts might use those libraries > so ldconfig has to be be run before them so they can work. Perhaps those > calls could be clustered into one, but I don't know whether this can be > done without changes to RPM. Good point. Anyway, the installation completed and I don't see evident problems. The complete process was quite interesting: 1) launched update from FC4 to FC6; after a few hours anaconda apparently locked: from what I saw, the system was out of memory (512MiB, the swap partition already present on the disk was not autoactivated) 2) started the update process again (from FC6 to FC6, according to anaconda), activated the swap partition manually 3) at about 25% of (slow) progress, renamed the ldconfig exe away 4) at the end of the upgrade, renamed ldconfig back and, maybe, chrooted and ran ldconfig (I don't remember if I did that or not) 5) rebooted the system At that point the system appeared perfectly working, but any attempt to start X or reconfigure X (including using system-config-display) failed, even if the xorg.conf file was apparently ok. I investigated around and discovered "rpm -qa" was giving many duplicate entries; I was going to blame the first aborted update, but soon realized it was all good, just ppc+ppc64 versions. Assuming the problems with X could have been related to failed upgrading scripts (according to your hint), I just launched a full "yum update", hoping that the missing scripts would be run successfully somewhere in those 1.1GB of updates. The X problem persisted, but the issue was really trivial: no xorg-x11-drv* package had been installed! After the installation of xorg-x11-drivers everything appears ok on the system, the KDE desktop runs perfectly. So, at the end of all this, I can say that the ldconfig trick, while certainly dirty, didn't result as dangerous as you thought. Maybe the first aborted installation (with normal ldconfig) did help, by correctly upgrading the fundamental parts of the system (glibc,...) and so avoiding script failures later (when ldconfig was off). I still hope some way to speedup the FC update process will come out, as it is becoming more and more annoying with new versions. (and the FC6->FC7 upgrade will include extras...) Best regards. -- Roberto Ragusa mail at robertoragusa.it From gmaxwell at gmail.com Wed Feb 21 21:09:20 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 21 Feb 2007 16:09:20 -0500 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: On 2/21/07, Eric S. Raymond wrote: [snip] > Want to fix or scrap the damned patent system? Want to get the damned > DMCA repealed? Do you want even as little a thing as 3D graphics and > wireless cards with open specs? > To get these things, we certainly need market share over 30% and probably > need market share over 50%. We need politicians and vendors to fear > our wrath. Why not make them irrelevant or obsolete by providing alternatives, educating people, and making progress a step at a time? [snip] > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > nowhere near the only reason I'm gone, but it's a big one. You have your own positions and your own goals. You are entitled to have them. Other people sometimes have differing goals, and differing positions. This doesn't make people wrong. If I wanted an OS stuffed with proprietary software I could run MacOS X. After many years, a desktop of completely free software finally satisfies my needs with virtually no compromise. This is not true for everyone, but it is true for some people. I've been in a situation of having a mixed system, and it stinks. I don't want to go back. Not an *inch*. Be thankful that there exists a Linux distribution which, apparently, shares your value of short term ease over other factors. This saves you the trouble of stuffing your free operating system full of proprietary stuff on your own. You preference is already provided by someone else, so please don't demand that I lose the ability to choose a reasonable mainstream distribution which contains Free Software. If you are right than surely your solution will win at the end of the day. So if you are convinced that you are right, why are you wasting your time ranting about this? From janina at rednote.net Wed Feb 21 21:20:27 2007 From: janina at rednote.net (Janina Sajka) Date: Wed, 21 Feb 2007 16:20:27 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <20070221212027.GC4179@rednote.net> Jesse Keating writes: > So, how much hate will be thrown my way if we just do a DVD sized iso for > Test2's Classic spin? Works here. I'm actually surprised you didn't suggest this sooner. Janina From gmaxwell at gmail.com Wed Feb 21 21:09:20 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 21 Feb 2007 16:09:20 -0500 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: On 2/21/07, Eric S. Raymond wrote: [snip] > Want to fix or scrap the damned patent system? Want to get the damned > DMCA repealed? Do you want even as little a thing as 3D graphics and > wireless cards with open specs? > To get these things, we certainly need market share over 30% and probably > need market share over 50%. We need politicians and vendors to fear > our wrath. Why not make them irrelevant or obsolete by providing alternatives, educating people, and making progress a step at a time? [snip] > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > nowhere near the only reason I'm gone, but it's a big one. You have your own positions and your own goals. You are entitled to have them. Other people sometimes have differing goals, and differing positions. This doesn't make people wrong. If I wanted an OS stuffed with proprietary software I could run MacOS X. After many years, a desktop of completely free software finally satisfies my needs with virtually no compromise. This is not true for everyone, but it is true for some people. I've been in a situation of having a mixed system, and it stinks. I don't want to go back. Not an *inch*. Be thankful that there exists a Linux distribution which, apparently, shares your value of short term ease over other factors. This saves you the trouble of stuffing your free operating system full of proprietary stuff on your own. You preference is already provided by someone else, so please don't demand that I lose the ability to choose a reasonable mainstream distribution which contains Free Software. If you are right than surely your solution will win at the end of the day. So if you are convinced that you are right, why are you wasting your time ranting about this? From jspaleta at gmail.com Wed Feb 21 21:16:34 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Feb 2007 12:16:34 -0900 Subject: Archives of Fedora IRC channels In-Reply-To: <45DB2C90.8010600@fedoraproject.org> References: <45D9A66D.3060805@fedoraproject.org> <20070219134632.GA5609@lists.us.dell.com> <45D9AF64.3000203@fedoraproject.org> <20070219161909.GC26885@nostromo.devel.redhat.com> <45D9CFB7.8070801@fedoraproject.org> <45DB2C90.8010600@fedoraproject.org> Message-ID: <604aa7910702211316s3090a56ej25cdff04baf95502@mail.gmail.com> On 2/20/07, Rahul Sundaram wrote: > It's just a matter of running a bot (which already exists) on all the > channels. I guess it wouldnt take more than an hour to setup for someone > more familiar with it. In general, I think most of the discussions on most of the channels aren't worth the diskspace to log or the cpu cycles to grep. If you log indescrimately, you're gonna catch a heck of a lot of noise. A signal to noise ratio worthy of Google's best search agorithm gurus. That being said, I've found the availability of the irclogs in the wiki from pre-annouced/agenda'd meetings as a useful resource, In the same way I find audio/video recording archives of real-life public town meetings to be useful. And of course I mean ogg vorbis and ogg theora archives of public town meetings. -jef"Hmm what would the Fedora version of C-SPAN be called.... F-AN... Fedora Affairs Network?"spaleta From mknepher at bluethingy.com Wed Feb 21 21:24:49 2007 From: mknepher at bluethingy.com (Michael Knepher) Date: Wed, 21 Feb 2007 13:24:49 -0800 Subject: Goodbye, Fedora In-Reply-To: <20070221195919.GB4620@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> Message-ID: <45DCB8A1.1020708@bluethingy.com> Eric S. Raymond wrote: > Rahul Sundaram : > >>> The wiki page does nothing to disabuse me of this expectation by using >>> terms like "brainwashing". The contempt for mere users this exhibits is >>> very revealing, and is a significant part of the reason I've decamped. >>> >> You just lose your sense of humor there. >> > > Oh, yes, it's very funny that Greg deKoenigsberg -- who is supposed to be > some kind of responsible adult supervision -- implies that anybody who > wants to watch YouTube or listen to a podcast is a glassy-eyed zombie. > Ha ha. See me laugh. Yes, that is *exactly* the kind of attitude that > will get us above 4% market share. Not. > Um, the brainwashing mentioned is on the part of the Fedora community - a jest (admittedly weak) about "indoctrinating" users into the free software way of thinking. Probably not as brilliant as showing up at a protest dressed as Obi Wan Kenobi, but we can't all be Important, Serious People. From davej at redhat.com Wed Feb 21 21:30:09 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Feb 2007 16:30:09 -0500 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: <20070221213009.GC12834@redhat.com> On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > nowhere near the only reason I'm gone, but it's a big one. Didn't you leave already? Dave -- http://www.codemonkey.org.uk From gemi at bluewin.ch Wed Feb 21 21:30:01 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 21 Feb 2007 22:30:01 +0100 Subject: Change in ncurses in devel? Message-ID: <1172093401.8843.4.camel@scriabin.tannenrauch.ch> I tried to rebuild ucblogo to use ncurses and not termcap, and got a link error specific to the ncurses in devel. I found out that I needed to link with cursesw instead of curses (support for wide characters). This is because "ncurses/ncurses.h" pulls in "ncursesw/ncurses_dll.h" instead of just "ncurses/ncurses_dll.h" as it does on FC6. The ncursesw version adds a symbol "ospeed" absent from libcurses but present in libcursesw? Is this a bug, or is there a rationale behind? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From cweyl at alumni.drew.edu Wed Feb 21 21:30:39 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 21 Feb 2007 13:30:39 -0800 Subject: Goodbye, Fedora In-Reply-To: <1172082803.19442.1.camel@sb-home.lan> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172082803.19442.1.camel@sb-home.lan> Message-ID: <7dd7ab490702211330r23186ac3ocd9b067aa217e9d5@mail.gmail.com> On 2/21/07, nodata wrote: > It's easy to get caught up in the emotional heat of the moment when > someone is complaining. > > -- http://www.joelonsoftware.com/articles/customerservice.html +1. Good criticism leads to healthy, if sometimes painful, self-examination, debate, and improvement. -Chris -- Chris Weyl Ex astris, scientia From bojan at rexursive.com Wed Feb 21 21:40:39 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 21 Feb 2007 21:40:39 +0000 (UTC) Subject: Goodbye, Fedora References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> Message-ID: Rahul Sundaram fedoraproject.org> writes: > Perhaps a bug report. Celebrities don't file bugs, Rahul. They throw tantrums! You should know that by now ;-) -- Bojan From chtaylo4 at gmail.com Wed Feb 21 22:26:49 2007 From: chtaylo4 at gmail.com (Chris Taylor) Date: Wed, 21 Feb 2007 17:26:49 -0500 Subject: a question abotu the .spec file Message-ID: Hi, First off let me caveat this by saying that I came across this while trying to apply the skas patch to the 2.6.19.src.rpm for fc5. I had previously installed other versions of the source rpm and now when trying to build a kernel rpm I'm having some issues. It appears that when I prep the kernel sources (rpm -bp) the default .spec file tries to apply all config files in the current directory. from line 1111 of kernel-2.6.spec: # now run oldconfig over all the config files for i in *.config do mv $i .config Arch=`head -1 .config | cut -b 3-` make ARCH=$Arch nonint_oldconfig > /dev/null echo "# $Arch" > configs/$i cat .config >> configs/$i done since there are different .config files for each iteration of the kernel ( i.e kernel-2.6.19-i586.config vs kernel-2.6.18-i586.config) should the .spec file be specific to the kernel that it's intended for? I guess what I'm trying to say is, shouldn't there be a /SPECS/kernel-2.6.19.spec and a /SPECS/kernel-2.6.17.spec file? In the file the it would look for *$(kversion)*.spec instead of *.config . There might be a few other places in this file this would apply. I'd be happy to submit a patch if you'd be interested in this change? Respectfully, Chris Respectfully, Christopher Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsof at nodata.co.uk Wed Feb 21 22:29:25 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 21 Feb 2007 23:29:25 +0100 Subject: Goodbye, Fedora In-Reply-To: <1172084374.11813.6.camel@hughsie-laptop> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <1172084374.11813.6.camel@hughsie-laptop> Message-ID: <1172096965.3046.2.camel@sb-home.lan> Am Mittwoch, den 21.02.2007, 18:59 +0000 schrieb Richard Hughes: > On Wed, 2007-02-21 at 13:25 -0500, Eric S. Raymond wrote: > > I can tell you the library in question was libcom_err, and I think I > > deleted it when removing e2fsprogs-libs to get around a file conflict. > > But with rpm not working I couldn't reinstall the library. > > So you manually removed a critical system library and wondered why > things broke? Have you ever tried randomly deleting .dll files in > Windows XP? > > Richard. > XP has locking :) From bojan at rexursive.com Wed Feb 21 22:40:11 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 21 Feb 2007 22:40:11 +0000 (UTC) Subject: Goodbye, Fedora References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: Eric S. Raymond thyrsus.com> writes: > I had to kluge with netcat and tar just to back up > my files. It was horrible. And here we see the real problem - there was no proper backup of the system BEFORE any of this was attempted. I'm sure that's Fedora's fault... PS. I also hit the e2fsprogs-libs/libcom_err problem (while upgrading ot Rawhide at some point in the past) and somehow managed NOT to screw up my system. But even if I did, it wouldn't have been a problem - I had backup. -- Bojan From jspaleta at gmail.com Wed Feb 21 22:49:01 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Feb 2007 13:49:01 -0900 Subject: Goodbye, Fedora In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <604aa7910702211449j432dfb46tc684b0a12ece2670@mail.gmail.com> On 2/21/07, Bojan Smojver wrote: > And here we see the real problem - there was no proper backup of the system > BEFORE any of this was attempted. I'm sure that's Fedora's fault... speaking of backups...... I'm looking to submit a set of safekeep packages into the fedora package universe. If you are running rdiff-backup based backups now, you might want to take these packages for a spin and see if you like safekeep's features. http://jspaleta.thecodergeek.com/Fedora%20SRPMS/safekeep/FC6/ -jef From esr at thyrsus.com Wed Feb 21 22:49:18 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 17:49:18 -0500 Subject: Goodbye, Fedora In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <20070221224918.GB10229@thyrsus.com> Bojan Smojver : > And here we see the real problem - there was no proper backup of the system > BEFORE any of this was attempted. I'm sure that's Fedora's fault... Actually, there was. But it was a couple of days old. I didn't expect a *single-package update* to be so dangerous that I needed to do a full backup first. How foolishly optimistic of me. -- Eric S. Raymond From mjg59 at srcf.ucam.org Wed Feb 21 22:38:10 2007 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Wed, 21 Feb 2007 22:38:10 +0000 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: <20070221223810.GA9626@srcf.ucam.org> On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > nowhere near the only reason I'm gone, but it's a big one. For really bizarrely limited definitions of "The Ubuntu crowd", perhaps. (Speaking as a member of the Ubuntu technical board) -- Matthew Garrett | mjg59 at srcf.ucam.org From esr at thyrsus.com Wed Feb 21 22:52:42 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 17:52:42 -0500 Subject: Core values In-Reply-To: <20070221223810.GA9626@srcf.ucam.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221223810.GA9626@srcf.ucam.org> Message-ID: <20070221225242.GC10229@thyrsus.com> Matthew Garrett : > > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > > nowhere near the only reason I'm gone, but it's a big one. > > For really bizarrely limited definitions of "The Ubuntu crowd", perhaps. > > (Speaking as a member of the Ubuntu technical board) I'm gathering that it wasn't you who did the deal with Linspire to get Ubuntu's hands on their codecs, then. -- Eric S. Raymond From mjg59 at srcf.ucam.org Wed Feb 21 22:57:13 2007 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Wed, 21 Feb 2007 22:57:13 +0000 Subject: Core values In-Reply-To: <20070221225242.GC10229@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221223810.GA9626@srcf.ucam.org> <20070221225242.GC10229@thyrsus.com> Message-ID: <20070221225713.GA10099@srcf.ucam.org> On Wed, Feb 21, 2007 at 05:52:42PM -0500, Eric S. Raymond wrote: > I'm gathering that it wasn't you who did the deal with Linspire to get > Ubuntu's hands on their codecs, then. The fact that I'm not employed by Canonical does mean I don't generally get involved in business deals, yes. The Linspire/Ubuntu deal is a commercial issue, not one that's been in any way shaped by the opinions of the Ubuntu community or governance structure. -- Matthew Garrett | mjg59 at srcf.ucam.org From bojan at rexursive.com Wed Feb 21 23:06:35 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 21 Feb 2007 23:06:35 +0000 (UTC) Subject: Goodbye, Fedora References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <20070221224918.GB10229@thyrsus.com> Message-ID: Eric S. Raymond thyrsus.com> writes: > Actually, there was. But it was a couple of days old. I didn't expect > a *single-package update* to be so dangerous that I needed to do > a full backup first. How foolishly optimistic of me. You mean "the single package update that involved manual removal, by YOU, of a crucial component from the system". And you didn't have to do a full backup. You could just do a quick incremental instead. Unless you had terabytes of new stuff, it wouldn't have taken that long. Even after you created that problem for yourself by removing a vital component from your system, you had options. Instead, as usual, you've chosen to throw a tantrum on the list. Not cool. -- Bojan From mschwendt.tmp0701.nospam at arcor.de Wed Feb 21 23:16:54 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 22 Feb 2007 00:16:54 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221224918.GB10229@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <20070221224918.GB10229@thyrsus.com> Message-ID: <20070222001654.594fc1cd.mschwendt.tmp0701.nospam@arcor.de> On Wed, 21 Feb 2007 17:49:18 -0500, Eric S. Raymond wrote: > Bojan Smojver: > > And here we see the real problem - there was no proper backup of the system > > BEFORE any of this was attempted. I'm sure that's Fedora's fault... > > Actually, there was. But it was a couple of days old. I didn't expect > a *single-package update* to be so dangerous that I needed to do > a full backup first. How foolishly optimistic of me. You still haven't filled in the missing details. What repositories? Rawhide? FC6? What conflict? I don't want to know why you choose to broke something by using the --nodeps or --force options. I am just interested in what conflict or broken dependency caused you to take a try at fixing it without asking somebody for help. From esr at thyrsus.com Wed Feb 21 23:13:56 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 21 Feb 2007 18:13:56 -0500 Subject: Core values In-Reply-To: <20070221225713.GA10099@srcf.ucam.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221223810.GA9626@srcf.ucam.org> <20070221225242.GC10229@thyrsus.com> <20070221225713.GA10099@srcf.ucam.org> Message-ID: <20070221231356.GB11195@thyrsus.com> Matthew Garrett : > > I'm gathering that it wasn't you who did the deal with Linspire to get > > Ubuntu's hands on their codecs, then. > > The fact that I'm not employed by Canonical does mean I don't generally > get involved in business deals, yes. The Linspire/Ubuntu deal is a > commercial issue, not one that's been in any way shaped by the opinions > of the Ubuntu community or governance structure. OK. Then I think I may safely deduce that Mark Shuttleworth gets it, but that the extent to which his enlightenment is shared by the 'community' part of the project is not established. Thank you for the correction. -- Eric S. Raymond From alan at redhat.com Wed Feb 21 23:19:49 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 21 Feb 2007 18:19:49 -0500 Subject: Goodbye, Fedora In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <20070221231949.GA13773@devserv.devel.redhat.com> On Wed, Feb 21, 2007 at 01:25:01PM -0500, Eric S. Raymond wrote: > You have half of it. rpm should be statically linked to avoid this sort > of cul-de-sac. It's not like multople instances of it running are > going to be a frequent occurrence. If you've lost a critical library then you may well have other problems if you just ran a static rpm - such as the scripts. Normal users on being told there is a package file collision believe the package manager and don't randomly delete stuff breaking their system. Experts go and check the dependancy tree and then decide not to do it. > But with rpm not working I couldn't reinstall the library. Boot failed, > ssh/sshd failed -- I had to kluge with netcat and tar just to back up > my files. It was horrible. You boot the rescue CD and use rpm --root to do the reinstall of the package. If you aren't an expert you ask on the user list and get told how to do that. Asking would have received a fairly prompt answer. Folks who run rawhide all the time are pretty familiar with scenarios like "this glibc is bad" and getting out of them. Alan From mjg59 at srcf.ucam.org Wed Feb 21 23:25:34 2007 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Wed, 21 Feb 2007 23:25:34 +0000 Subject: Core values In-Reply-To: <20070221231356.GB11195@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221223810.GA9626@srcf.ucam.org> <20070221225242.GC10229@thyrsus.com> <20070221225713.GA10099@srcf.ucam.org> <20070221231356.GB11195@thyrsus.com> Message-ID: <20070221232534.GA10542@srcf.ucam.org> On Wed, Feb 21, 2007 at 06:13:56PM -0500, Eric S. Raymond wrote: > OK. Then I think I may safely deduce that Mark Shuttleworth gets it, but > that the extent to which his enlightenment is shared by the 'community' > part of the project is not established. I should clarify that despite being elected by the community, I am in no direct position to represent their opinions. I reply merely to make it clear that it's not possible to claim that the Ubuntu community "get" anything without asking them directly. To that extent, I agree with you. My own opinions are certainly incompatible with yours in this respect, and I suspect that the same is true of many others, but I have absolutely no ability to provide you with any judgement over the "community opinion". -- Matthew Garrett | mjg59 at srcf.ucam.org From dennis at ausil.us Wed Feb 21 23:27:29 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 21 Feb 2007 17:27:29 -0600 Subject: Core values In-Reply-To: <20070221231356.GB11195@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221225713.GA10099@srcf.ucam.org> <20070221231356.GB11195@thyrsus.com> Message-ID: <200702211727.29935.dennis@ausil.us> On Wednesday 21 February 2007 05:13:56 pm Eric S. Raymond wrote: > Matthew Garrett : > > > I'm gathering that it wasn't you who did the deal with Linspire to get > > > Ubuntu's hands on their codecs, then. > > > > The fact that I'm not employed by Canonical does mean I don't generally > > get involved in business deals, yes. The Linspire/Ubuntu deal is a > > commercial issue, not one that's been in any way shaped by the opinions > > of the Ubuntu community or governance structure. > > OK. Then I think I may safely deduce that Mark Shuttleworth gets it, but > that the extent to which his enlightenment is shared by the 'community' > part of the project is not established. > > Thank you for the correction. > -- > Eric S. Raymond I thought you were gone already. If you can't participate in a manner that is not troll like please don't participate at all. Fedora has a clear set of goals an objectives. and proprietary anything has no place in Fedora. of course you are free to produce your own distro and call it something else with the bits added. we even provide tools for you to do it. you just cant call it Fedora. -- Dennis Gilmore, RHCE From alan at redhat.com Wed Feb 21 23:31:28 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 21 Feb 2007 18:31:28 -0500 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: <20070221233128.GC13773@devserv.devel.redhat.com> On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: > This is so out of contact with reality that it makes me grind my teeth. Eric I think you lost the plot, actually I don't think you ever got the plot in the first place but that is another story > Want to fix or scrap the damned patent system? Want to get the damned > DMCA repealed? Do you want even as little a thing as 3D graphics and > wireless cards with open specs? I spend material amounts of time with people like politicians. They don't care about 30% market share, they care (on the whole) about doing the right thing and where there isn't an easy answer picking a path that doesn't result in chaos. > need market share over 50%. We need politicians and vendors to fear > our wrath. Ah yes its the gun/power thing again. "Me got big gun, me scary", which usually results in "me dead". You don't win hearts and minds by being scary and violent (see Iraq for a worked example). > It wasn't 'sacrificing our core values' to ship a binary Netscape > blob until Mozilla was ready. It won't be sacrificing our core values The real free distributions didn't ship binary netscape blobs. > to ship proprietary codecs until we are positioned to crush them out > of existence. There is a much easier way to work with these people. You support those who open source stuff (eg intel video), you ignore those who won't (eg AMD bugs get a lot less time nowdays and will continue to do so until ATI grow up) For proprietary codecs its up to end users if they want to install them, yum provides a mechanism for anyone on the planet to distribute new repositories not just livna and friends. You've got a nice level playing field and a business opportunity. The moment Fedora includes non-free stuff it becomes a problem for all the people who redistribute and respin it, and it becomes unfair in the proprietary world in the eyes of everyone who didn't get included. Alan From pemboa at gmail.com Thu Feb 22 01:25:31 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Feb 2007 19:25:31 +1800 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: <16de708d0702211725v5d398775w6ea4502bd9bde895@mail.gmail.com> On 2/22/07, Eric S. Raymond wrote: > Jesse Keating : > > Market share means nothing if we sacrifice our core values for a few more > > percentage points. > > This is so out of contact with reality that it makes me grind my teeth. > > Want to fix or scrap the damned patent system? Want to get the damned > DMCA repealed? Do you want even as little a thing as 3D graphics and > wireless cards with open specs? > > To get these things, we certainly need market share over 30% and probably > need market share over 50%. We need politicians and vendors to fear > our wrath. > > It wasn't 'sacrificing our core values' to ship a binary Netscape > blob until Mozilla was ready. It won't be sacrificing our core values > to ship proprietary codecs until we are positioned to crush them out > of existence. > > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > nowhere near the only reason I'm gone, but it's a big one. Seem slike Ubuntu people tend to be people just to cheap to buy a Mac. What it *sounds* like you need/want is a Mac. They are really quite nice - I was on one the other day - all the multimedia that you can possibly shale a stick at. I kinda like Fedora though, and I'll be here for awhile, and when I get a contracts for projects, i'll be sure to suggest CentOS or RHEL. But yah...head over to an apple store. Macs are quite nice. -- Fedora Core 6 and proud From zaitcev at redhat.com Thu Feb 22 01:29:43 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 21 Feb 2007 17:29:43 -0800 Subject: a question abotu the .spec file In-Reply-To: References: Message-ID: <20070221172943.d659109a.zaitcev@redhat.com> On Wed, 21 Feb 2007 17:26:49 -0500, "Chris Taylor" wrote: > # now run oldconfig over all the config files > for i in *.config > since there are different .config files for each iteration of the kernel ( > i.e kernel-2.6.19-i586.config vs kernel-2.6.18-i586.config) should the > .spec file be specific to the kernel that it's intended for? I suspect that you're mistaken in your diagnosis. The scriptlet you quoted runs in the top of the build tree. A few lines earlier, this happens: cp -f %{all_arch_configs} . The dot was removed, then untarred and patched, at the beginning of build. Thus, the *.config is not globbed over a bunch of different configs left over in the unclean .../SOURCES/. It cannot possibly run across different revisions. Right? Or I am missing something? So, if your SKAS patch causes nohint_oldconfig to abort, it's something other than pollution by old configs. You're still advised to remove old sources before running rpm -i on an SRPM. -- Pete From mschwendt.tmp0701.nospam at arcor.de Wed Feb 21 20:59:50 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 21 Feb 2007 21:59:50 +0100 Subject: FC6 updates broken deps? (was: Re: Goodbye, Fedora) In-Reply-To: <200702211350.53468.jkeating@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> Message-ID: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> On Wed, 21 Feb 2007 13:50:50 -0500, Jesse Keating wrote: > On Wednesday 21 February 2007 13:28, Ian Burrell wrote: > > The ekiga update from today has broken dependencies. > > > > Error: Missing Dependency: opal >= 2.2.5 is needed by package ekiga > > Error: Missing Dependency: libpt_linux_x86_r.so.1.10.4 is needed by > > package ekiga > > Error: Missing Dependency: pwlib >= 1.10.4 is needed by package ekiga > > > > It looks like the opal and pwlib versions it needs are in updates-testing. > > > > Excluding ekiga with "yum --exclude=ekiga update" allows the rest of > > the packages to update. ?Enabling updates-testing repository with "yum > > --enablerepo=updates-testing update ekiga" allows ekiga to be updated. > > I honestly have no idea how this happened. I did a depcheck before pushing > the update. That said, I'm pushing the missing packages now. Does that depcheck also cover multi-lib? Because except for the first one, I still see these: source rpm: python-virtinst-0.98.0-1.fc6.src.rpm package: python-virtinst - 0.98.0-1.fc6.noarch from fedora-core-updates-6-ppc unresolved deps: libvirt-python >= 0:0.1.4-4 source rpm: bind-9.3.4-2.fc6.src.rpm package: bind-devel - 31:9.3.4-2.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libdns.so.22 libbind9.so.0 libisccc.so.0 liblwres.so.9 libisccfg.so.1 libisc.so.11 source rpm: compiz-0.3.6-2.fc6.src.rpm package: compiz-devel - 0.3.6-2.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libdecoration.so.0 source rpm: kdeedu-3.5.6-0.1.fc6.src.rpm package: kdeedu - 3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libpython2.4.so.1.0 source rpm: kdeutils-3.5.6-0.1.fc6.src.rpm package: kdeutils-devel - 6:3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libkmilo.so.1 libkregexpeditorcommon.so.1 libksimcore.so.1 libkhexeditcommon.so.0 libkcmlaptop.so.0 source rpm: poppler-0.5.4-5.fc6.src.rpm package: poppler-devel - 0.5.4-5.fc6.i386 from fedora-core-updates-6-x86_64 unresolved deps: libpoppler-qt.so.1 From jkeating at redhat.com Thu Feb 22 01:50:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 20:50:21 -0500 Subject: FC6 updates broken deps? (was: Re: Goodbye, Fedora) In-Reply-To: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200702212050.21732.jkeating@redhat.com> On Wednesday 21 February 2007 15:59, Michael Schwendt wrote: > Does that depcheck also cover multi-lib? Because except for the > first one, I still see these: > > source rpm: python-virtinst-0.98.0-1.fc6.src.rpm > package: python-virtinst - 0.98.0-1.fc6.noarch from > fedora-core-updates-6-ppc unresolved deps: > libvirt-python >= 0:0.1.4-4 > > source rpm: bind-9.3.4-2.fc6.src.rpm > package: bind-devel - 31:9.3.4-2.fc6.i386 from fedora-core-updates-6-x86_64 > unresolved deps: > libdns.so.22 > libbind9.so.0 > libisccc.so.0 > liblwres.so.9 > libisccfg.so.1 > libisc.so.11 > > source rpm: compiz-0.3.6-2.fc6.src.rpm > package: compiz-devel - 0.3.6-2.fc6.i386 from fedora-core-updates-6-x86_64 > unresolved deps: > libdecoration.so.0 > > source rpm: kdeedu-3.5.6-0.1.fc6.src.rpm > package: kdeedu - 3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64 > unresolved deps: > libpython2.4.so.1.0 > > source rpm: kdeutils-3.5.6-0.1.fc6.src.rpm > package: kdeutils-devel - 6:3.5.6-0.1.fc6.i386 from > fedora-core-updates-6-x86_64 unresolved deps: > libkmilo.so.1 > libkregexpeditorcommon.so.1 > libksimcore.so.1 > libkhexeditcommon.so.0 > libkcmlaptop.so.0 > > source rpm: poppler-0.5.4-5.fc6.src.rpm > package: poppler-devel - 0.5.4-5.fc6.i386 from fedora-core-updates-6-x86_64 > unresolved deps: > libpoppler-qt.so.1 Hrm, I'm not entirely sure, I'll have to defer to Luke Macken on that one. I'm surprised that these haven't been reported before, people are generally really quick to notice broken deps in the updates repos. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From n0dalus+redhat at gmail.com Thu Feb 22 02:35:46 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 22 Feb 2007 13:05:46 +1030 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <6280325c0702211835rb5c8070y77ad9c8a9b2c3c1d@mail.gmail.com> On 2/21/07, Jesse Keating wrote: > So, how much hate will be thrown my way if we just do a DVD sized iso for > Test2's Classic spin? > Where I live the majority of computers don't have a DVD drive, so this move would be unfortunate. I have done installs on older computers that didn't have internet connections or dvd drives or anything like that, and I think it's a shame Fedora and other modern distros tend to ignore this part of the market (mainly because most developers have broadband and reasonably recent hardware). Would it be possible to provide CD versions, and a cross-platform tool that could generate a DVD-sized iso with it? n0dalus. From jreiser at BitWagon.com Thu Feb 22 02:38:01 2007 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 21 Feb 2007 18:38:01 -0800 Subject: a question about the .spec file In-Reply-To: <20070221172943.d659109a.zaitcev@redhat.com> References: <20070221172943.d659109a.zaitcev@redhat.com> Message-ID: <45DD0209.3090807@BitWagon.com> Pete Zaitcev wrote: > On Wed, 21 Feb 2007 17:26:49 -0500, "Chris Taylor" wrote: > > >># now run oldconfig over all the config files >>for i in *.config > > >>since there are different .config files for each iteration of the kernel ( >>i.e kernel-2.6.19-i586.config vs kernel-2.6.18-i586.config) should the >>.spec file be specific to the kernel that it's intended for? > > > I suspect that you're mistaken in your diagnosis. The scriptlet you > quoted runs in the top of the build tree. A few lines earlier, this > happens: > > cp -f %{all_arch_configs} . > > The dot was removed, then untarred and patched, at the beginning of build. > Thus, the *.config is not globbed over a bunch of different configs left > over in the unclean .../SOURCES/. It cannot possibly run across different > revisions. > > Right? Or I am missing something? About one year ago in kernel-2.6.15-1.1977_FC5 there was a problem with the .spec not defending itself against old *.config files. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182950 In the .spec for the current kernel-2.6.20-1.2936.fc7 the defense is contained in lines such as: %define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-*.config which includes %{kversion} in the relevant filenames. However, kversion is only 2.6.%{sublevel}, so the defense is not necessarily exhaustive. > ... You're still advised to remove > old sources before running rpm -i on an SRPM. This advice confirms that some .spec files do/did have such misfeatures; and/or the misdesign of rpm for not anticipating the use of SOURCES as an uncontrolled cache, multiple simultaneous builds [inhibiting "rm -f SOURCES/*"], etc. -- John Reiser, jreiser at BitWagon.com From mattdm at mattdm.org Thu Feb 22 02:38:21 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Feb 2007 21:38:21 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <6280325c0702211835rb5c8070y77ad9c8a9b2c3c1d@mail.gmail.com> References: <200702201758.15925.jkeating@redhat.com> <6280325c0702211835rb5c8070y77ad9c8a9b2c3c1d@mail.gmail.com> Message-ID: <20070222023821.GA28848@jadzia.bu.edu> On Thu, Feb 22, 2007 at 01:05:46PM +1030, n0dalus wrote: > Would it be possible to provide CD versions, and a cross-platform tool > that could generate a DVD-sized iso with it? There's a cross-platform tool that will make any-sized versions. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From benny+usenet at amorsen.dk Thu Feb 22 06:49:50 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 22 Feb 2007 07:49:50 +0100 Subject: Goodbye, Fedora References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <20070221231949.GA13773@devserv.devel.redhat.com> Message-ID: >>>>> "AC" == Alan Cox writes: AC> You boot the rescue CD and use rpm --root to do the reinstall of AC> the package. If you aren't an expert you ask on the user list and AC> get told how to do that. Normally you can rescue a deleted file by finding a process holding the file open and doing a cp from /proc/123/fd/. Unfortunately libraries tend to only be mmapped, with the fd long gone. Is there a way to rescue a file which is only mmapped? /Benny From naoki at valuecommerce.com Thu Feb 22 07:42:14 2007 From: naoki at valuecommerce.com (Naoki) Date: Thu, 22 Feb 2007 16:42:14 +0900 Subject: Goodbye, Fedora (Limiting -devel to maintainers/contributers/etc - A bad idea) In-Reply-To: <1172073794.9201.64.camel@gilboa-work-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> <1172064941.3634.16.camel@localhost.localdomain> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <00ab01c755c4$729e33b0$6701a8c0@copernicus> <1172069168.9201.48.camel@gilboa-work-dev.localdomain> <45DC5FDF.8020509@warmcat.com> <1172073794.9201.64.camel@gilboa-work-dev.localdomain> Message-ID: <1172130134.24764.122.camel@dragon.valuecommerce.ne.jp> You can't quantify "contributions" in any easy way. And it's going to get pretty ugly if you start telling generally useful people they can't be on the list simply because you don't want to reduce the OT posting. We all understand the fedora-devel list is for developers, and technically you can restrict write access to people with a certain level of access. But at what cost? I test rawhide on various hardware, so I'm not technically a fedora developer, but I'd like to think that my meager testing and occasional bug reports do more good than harm to fedora. Restriction still will not solve your problem of somebody spamming a personal gripe into the list, even developers aren't immune to that from time to time so your cost benefit ratio isn't great, probably negative. What we have here is one person spamming the list with a personal gripe. No amount of policing the list can ever stop this from happening. The problem here was only caused by those of us (myself most definitely included) who responded to an off topic posting. Besides, an open devel process, even with a few warts, is better than a closed elitist one. From gilboad at gmail.com Thu Feb 22 08:43:31 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 22 Feb 2007 10:43:31 +0200 Subject: rawhide report: 20070220 changes In-Reply-To: <1172080030.29812.3.camel@localhost.localdomain> References: <200702201051.l1KApOB5011485@hs20-bc2-6.build.redhat.com> <1171970537.18231.3.camel@gilboa-work-dev.localdomain> <1171985098.13597.52.camel@localhost.localdomain> <1171986242.13597.53.camel@localhost.localdomain> <1172045393.9201.0.camel@gilboa-work-dev.localdomain> <1172080030.29812.3.camel@localhost.localdomain> Message-ID: <1172133811.12437.7.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 12:47 -0500, Adam Jackson wrote: > On Wed, 2007-02-21 at 10:09 +0200, Gilboa Davara wrote: > > On Tue, 2007-02-20 at 10:44 -0500, Adam Jackson wrote: > > > On Tue, 2007-02-20 at 10:24 -0500, Adam Jackson wrote: > > > > On Tue, 2007-02-20 at 13:22 +0200, Gilboa Davara wrote: > > > > > On Tue, 2007-02-20 at 05:51 -0500, buildsys at redhat.com wrote: > > > > > > > > > > > > > > > > > > Updated Packages: > > > > > > > > > > > libdrm-2.3.0-4.fc7 > > > > > > ------------------ > > > > > > * Mon Feb 19 2007 Adam Jackson 2.3.0-4 > > > > > > - Update nouveau patch > > > > > > - Fix License tag and other rpmlint noise > > > > > > > > > > OT question (that might not be related...) > > > > > Any idea when the latest DRI drivers (especially, mach64 and nv) will > > > > > imported into the kernel tree? > > > > > > > > nv already is, though I might be a bit behind. > > > > > > > > If there are significant mach64 changes since the last time Dave Airlie > > > > pushed stuff upstream, it's news to me, but I admit to not watching > > > > mach64 development very closely. > > > > > > I should clarify. The DRM is pretty close to current, afaik. Mesa is > > > behindish; not sure what the right thing to do there is. > > > > > > - ajax > > > > > > > Would the latest Mesa/DRM combo will find it's way into F7? > > The question is how much breakage people are willing to put up with. > Mesa doesn't release very often, and has a lot of churn. While I > certainly _can_ start doing snapshots... > > That said I'm looking at some Mesa stuff this week, so hopefully I'll > get a better idea of how stable head is right now. > > - ajax > Thanks. - Gilboa From mlichvar at redhat.com Thu Feb 22 09:35:41 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 22 Feb 2007 10:35:41 +0100 Subject: Change in ncurses in devel? In-Reply-To: <1172093401.8843.4.camel@scriabin.tannenrauch.ch> References: <1172093401.8843.4.camel@scriabin.tannenrauch.ch> Message-ID: <20070222093541.GD7475@localhost> On Wed, Feb 21, 2007 at 10:30:01PM +0100, G?rard Milmeister wrote: > I tried to rebuild ucblogo to use ncurses and not termcap, and got a > link error specific to the ncurses in devel. Here is the error: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -I/usr/include -O0 coms.o error.o eval.o files.o graphics.o init.o intern.o libloc.o lists.o logodata.o main.o math.o mem.o paren.o parse.o print.o term.o wrksp.o xgraphics.o nographics.o -lSM -lICE -L/usr/lib -lbsd -lm -lcurses -lX11 -o logo /usr/bin/ld: term.o(.debug_info+0xc0c): unresolvable R_386_32 relocation against symbol `ospeed' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status > I found out that I needed > to link with cursesw instead of curses (support for wide characters). > This is because "ncurses/ncurses.h" pulls in "ncursesw/ncurses_dll.h" > instead of just "ncurses/ncurses_dll.h" as it does on FC6. ncursesw headers are compatible with ncurses headers, only ncursesw headers are installed now. > The ncursesw > version adds a symbol "ospeed" absent from libcurses but present in > libcursesw? Symbol ospeed is in libtinfo and libncurse depend on this library, so that shouldn't be the problem. libncursesw have it's own libtinfo included as there is an issue that needs to be resolved before both libraries can use the same libtinfo. > Is this a bug, or is there a rationale behind? ucblogo needs a bit of patching, term.c declares ospeed as short, but it should be unsigned int. -- Miroslav Lichvar From gilboad at gmail.com Thu Feb 22 09:58:43 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 22 Feb 2007 11:58:43 +0200 Subject: Goodbye, Fedora In-Reply-To: <1172096965.3046.2.camel@sb-home.lan> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <1172084374.11813.6.camel@hughsie-laptop> <1172096965.3046.2.camel@sb-home.lan> Message-ID: <1172138323.12437.14.camel@gilboa-work-dev.localdomain> On Wed, 2007-02-21 at 23:29 +0100, nodata wrote: > Am Mittwoch, den 21.02.2007, 18:59 +0000 schrieb Richard Hughes: > > On Wed, 2007-02-21 at 13:25 -0500, Eric S. Raymond wrote: > > > I can tell you the library in question was libcom_err, and I think I > > > deleted it when removing e2fsprogs-libs to get around a file conflict. > > > But with rpm not working I couldn't reinstall the library. > > > > So you manually removed a critical system library and wondered why > > things broke? Have you ever tried randomly deleting .dll files in > > Windows XP? > > > > Richard. > > > > XP has locking :) > With huge holes in it. Try deleting random registry entries from HKEY_LOCAL_MACHINE and you'll see what I mean... :) - Gilboa From tmus at tmus.dk Thu Feb 22 09:40:31 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Feb 2007 10:40:31 +0100 Subject: Goodbye, Fedora In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <20070221224918.GB10229@thyrsus.com> Message-ID: Bojan Smojver wrote: > Eric S. Raymond thyrsus.com> writes: > >> Actually, there was. But it was a couple of days old. I didn't expect >> a *single-package update* to be so dangerous that I needed to do >> a full backup first. How foolishly optimistic of me. > > You mean "the single package update that involved manual removal, by YOU, of a > crucial component from the system". > > And you didn't have to do a full backup. You could just do a quick incremental > instead. Unless you had terabytes of new stuff, it wouldn't have taken that long. > > Even after you created that problem for yourself by removing a vital component > from your system, you had options. Instead, as usual, you've chosen to throw a > tantrum on the list. Not cool. > > -- > Bojan > In all fairness, I wouldn't have performed that backup neither, as I expect is true for a lot of even semi-knowledgable sysadmins and generic linux powerusers. Not sor something as simple as this. However - There is still the rescue mode that's been mentioned a few times already, which could have fixed the issue in a matter of minutes. Without the backup! /Thomas From tmus at tmus.dk Thu Feb 22 09:25:55 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Feb 2007 10:25:55 +0100 Subject: FC6 updates broken deps? In-Reply-To: <200702212050.21732.jkeating@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Wednesday 21 February 2007 15:59, Michael Schwendt wrote: >> Does that depcheck also cover multi-lib? Because except for the >> first one, I still see these: >> >> source rpm: python-virtinst-0.98.0-1.fc6.src.rpm >> package: python-virtinst - 0.98.0-1.fc6.noarch from >> fedora-core-updates-6-ppc unresolved deps: >> libvirt-python >= 0:0.1.4-4 >> >> source rpm: bind-9.3.4-2.fc6.src.rpm >> package: bind-devel - 31:9.3.4-2.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libdns.so.22 >> libbind9.so.0 >> libisccc.so.0 >> liblwres.so.9 >> libisccfg.so.1 >> libisc.so.11 >> >> source rpm: compiz-0.3.6-2.fc6.src.rpm >> package: compiz-devel - 0.3.6-2.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libdecoration.so.0 >> >> source rpm: kdeedu-3.5.6-0.1.fc6.src.rpm >> package: kdeedu - 3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libpython2.4.so.1.0 >> >> source rpm: kdeutils-3.5.6-0.1.fc6.src.rpm >> package: kdeutils-devel - 6:3.5.6-0.1.fc6.i386 from >> fedora-core-updates-6-x86_64 unresolved deps: >> libkmilo.so.1 >> libkregexpeditorcommon.so.1 >> libksimcore.so.1 >> libkhexeditcommon.so.0 >> libkcmlaptop.so.0 >> >> source rpm: poppler-0.5.4-5.fc6.src.rpm >> package: poppler-devel - 0.5.4-5.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libpoppler-qt.so.1 > > Hrm, I'm not entirely sure, I'll have to defer to Luke Macken on that one. > > I'm surprised that these haven't been reported before, people are generally > really quick to notice broken deps in the updates repos. > > Fact of the matter is, that even though people should report such iregularities, it would be a lot less work for everybody, if yum would update the largest portion of updates that do not have any dependency problems. I know we've been over this like a thousand times, but I still see no valid reason not to make yum do this! That would cause the 1 or 2 or 3 packages with probles to be held back, not the rest. /Thomas /Thomas From tmus at tmus.dk Thu Feb 22 09:29:27 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Feb 2007 10:29:27 +0100 Subject: Goodbye, Fedora In-Reply-To: <1172084374.11813.6.camel@hughsie-laptop> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <1172084374.11813.6.camel@hughsie-laptop> Message-ID: Richard Hughes wrote: > On Wed, 2007-02-21 at 13:25 -0500, Eric S. Raymond wrote: >> I can tell you the library in question was libcom_err, and I think I >> deleted it when removing e2fsprogs-libs to get around a file conflict. >> But with rpm not working I couldn't reinstall the library. > > So you manually removed a critical system library and wondered why > things broke? Have you ever tried randomly deleting .dll files in > Windows XP? > > Richard. > Actually, this is probably a silly example, since XP has the silly-admin-avoidance-system (or whatever it's called) that would automatically restore vital .dll files upon deletion. /Thomas From bojan at rexursive.com Thu Feb 22 10:53:27 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 22 Feb 2007 10:53:27 +0000 (UTC) Subject: Goodbye, Fedora References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <20070221224918.GB10229@thyrsus.com> Message-ID: Thomas M Steenholdt tmus.dk> writes: > In all fairness, I wouldn't have performed that backup neither, as I > expect is true for a lot of even semi-knowledgable sysadmins and generic > linux powerusers. Well, been there, done that. Experienced cold sweat etc. OK, next time I blow up one of my own systems, I'll write one of those letters. Actually, hang on - just a few days ago I forgot to run grub install on a disk I replaced and the system wouldn't boot after that. Consider it done - I'm co-signing ESR's letter - it's all Fedora's fault! Never mind that the system wasn't actually running Fedora... ;-) -- Bojan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 22 10:59:48 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 22 Feb 2007 11:59:48 +0100 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: <20070222115948.3e4f4f25@python3.es.egwn.lan> Eric S. Raymond wrote : [...] > To get these things, we certainly need market share over 30% and probably > need market share over 50%. We need politicians and vendors to fear > our wrath. This starts to sound a bit too much like your views on terrorism. Ouch. > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > nowhere near the only reason I'm gone, but it's a big one. You're gone? Oh, but you didn't want to miss the fun troll-fest!!! :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.25 0.46 0.56 From tmus at tmus.dk Thu Feb 22 09:27:29 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Feb 2007 10:27:29 +0100 Subject: FC6 updates broken deps? In-Reply-To: <200702212050.21732.jkeating@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Wednesday 21 February 2007 15:59, Michael Schwendt wrote: >> Does that depcheck also cover multi-lib? Because except for the >> first one, I still see these: >> >> source rpm: python-virtinst-0.98.0-1.fc6.src.rpm >> package: python-virtinst - 0.98.0-1.fc6.noarch from >> fedora-core-updates-6-ppc unresolved deps: >> libvirt-python >= 0:0.1.4-4 >> >> source rpm: bind-9.3.4-2.fc6.src.rpm >> package: bind-devel - 31:9.3.4-2.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libdns.so.22 >> libbind9.so.0 >> libisccc.so.0 >> liblwres.so.9 >> libisccfg.so.1 >> libisc.so.11 >> >> source rpm: compiz-0.3.6-2.fc6.src.rpm >> package: compiz-devel - 0.3.6-2.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libdecoration.so.0 >> >> source rpm: kdeedu-3.5.6-0.1.fc6.src.rpm >> package: kdeedu - 3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libpython2.4.so.1.0 >> >> source rpm: kdeutils-3.5.6-0.1.fc6.src.rpm >> package: kdeutils-devel - 6:3.5.6-0.1.fc6.i386 from >> fedora-core-updates-6-x86_64 unresolved deps: >> libkmilo.so.1 >> libkregexpeditorcommon.so.1 >> libksimcore.so.1 >> libkhexeditcommon.so.0 >> libkcmlaptop.so.0 >> >> source rpm: poppler-0.5.4-5.fc6.src.rpm >> package: poppler-devel - 0.5.4-5.fc6.i386 from fedora-core-updates-6-x86_64 >> unresolved deps: >> libpoppler-qt.so.1 > > Hrm, I'm not entirely sure, I'll have to defer to Luke Macken on that one. > > I'm surprised that these haven't been reported before, people are generally > really quick to notice broken deps in the updates repos. > > Really - The reason dependency issues are such a big issue for fedora is that all updates are held back because of a single package missing a dependency. I'm sure everybody would feel better holding back one package instead of all updates on this account. /Thomas From pemboa at gmail.com Thu Feb 22 11:26:34 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 23 Feb 2007 05:26:34 +1800 Subject: Core values In-Reply-To: <20070222115948.3e4f4f25@python3.es.egwn.lan> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070222115948.3e4f4f25@python3.es.egwn.lan> Message-ID: <16de708d0702220326i41c525a4ocd6e8f6591f0166d@mail.gmail.com> On 2/23/07, Matthias Saou wrote: > Eric S. Raymond wrote : > > [...] > > To get these things, we certainly need market share over 30% and probably > > need market share over 50%. We need politicians and vendors to fear > > our wrath. > > This starts to sound a bit too much like your views on terrorism. Ouch. I wouldn't have understood this comment had I not read this guy's (ESR) blog, which was frankly kinda scary and troubling > > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > > nowhere near the only reason I'm gone, but it's a big one. > > You're gone? Oh, but you didn't want to miss the fun troll-fest!!! :-) > > Matthias I hear good things about Ubuntu, and I don't really believe in distro "wars", but just know that people like him use, and champion Ubuntu gives me a sick feeling about it. I some times want to recommend Ubuntu to newbies interested in Linux because I hear that it is so user friendly, but it always seems like a bad idea after I think it through. -- Fedora Core 6 and proud From mls at suse.de Thu Feb 22 11:36:12 2007 From: mls at suse.de (Michael Schroeder) Date: Thu, 22 Feb 2007 12:36:12 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221182501.GA31710@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> Message-ID: <20070222113612.GA28803@suse.de> On Wed, Feb 21, 2007 at 01:25:01PM -0500, Eric S. Raymond wrote: > Rahul Sundaram : > > We only have your analysis of the problem. Not a description of the > > actual problem. That would be more helpful. Perhaps a bug report. > > You have half of it. rpm should be statically linked to avoid this sort > of cul-de-sac. That doesn't help. We (SUSE) had a statically linked rpm for years and switched to a dynamically linked one. Statically linked doesn't work because rpm needs to lookup passwd entries when installing packages and the nss code in the passwd lookup uses dynamically loaded plugins. You get lots of unpleasant effects if the statically linked glibc code can't work with plugins from a glibc update. Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From buildsys at redhat.com Thu Feb 22 11:47:10 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 22 Feb 2007 06:47:10 -0500 Subject: rawhide report: 20070222 changes Message-ID: <200702221147.l1MBlA4U007063@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.26-1 -------------------- * Wed Feb 21 2007 Chris Lumens - 11.2.0.26-1 - Add dpi flag when starting X to fix tiny font size (#224665). - Set the default timezone for languages we can't display (#227625). - Add termcap files we were missing to fix b&w console (#228596, #229236). - Add files from vnc-libs package to fix VNC installs. ekiga-2.0.5-2.fc7 ----------------- * Mon Feb 19 2007 Jeremy Katz - 2.0.5-2 - rebuild * Wed Feb 14 2007 Daniel Veillard - 2.0.5-1 - Upgrade to ekiga-2.0.5 fedora-logos-6.0.92-1.fc7 ------------------------- * Wed Feb 21 2007 Matthias Clasen - 6.0.92-1 - New lock dialog * Tue Feb 20 2007 Matthias Clasen - 6.0.91-3 - Some more new anaconda images - Slight update to one rhgb image * Sun Feb 18 2007 Matthias Clasen - 6.0.91-2 - Add new gnome splash - New firstboot images - Add some new anaconda images - Add new grub image gtk2-engines-2.9.3-2.fc7 ------------------------ * Wed Feb 21 2007 Matthias Clasen - 2.9.3-2 - Fix the active checkbox drawing bug nfs-utils-1:1.0.10-7.fc7 ------------------------ * Wed Feb 21 2007 Steve Dickson 1.0.10-7 - Added FS_Location support * Mon Dec 18 2006 Karel Zak 1.0.10-6 - add support for mount options that contain commas (bz 219645) * Wed Dec 13 2006 Steve Dickson 1.0.10-5 - Stopped v4 umounts from ping rpc.mountd (bz 215553) pirut-1.3.2-1.fc7 ----------------- * Wed Feb 21 2007 Jeremy Katz - 1.3.1-1 - Actually include CD support python file - Add xen to rebootpkgs - Lazy import the cd bits pykickstart-0.97-1.fc7 ---------------------- * Wed Feb 21 2007 Chris Lumens - 0.97-1 - Fix traceback when not overriding default mappings (#229505). zlib-1.2.3-8.fc7 ---------------- * Wed Feb 21 2007 Adam Tkac - 1.2.3-8 - fixed broken version of libz Broken deps for ia64 ---------------------------------------------------------- pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From skvidal at linux.duke.edu Thu Feb 22 12:39:06 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 22 Feb 2007 07:39:06 -0500 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> Message-ID: <1172147946.8256.49.camel@cutter> On Thu, 2007-02-22 at 10:25 +0100, Thomas M Steenholdt wrote: > Jesse Keating wrote: > > On Wednesday 21 February 2007 15:59, Michael Schwendt wrote: > >> Does that depcheck also cover multi-lib? Because except for the > >> first one, I still see these: > >> > >> source rpm: python-virtinst-0.98.0-1.fc6.src.rpm > >> package: python-virtinst - 0.98.0-1.fc6.noarch from > >> fedora-core-updates-6-ppc unresolved deps: > >> libvirt-python >= 0:0.1.4-4 > >> > >> source rpm: bind-9.3.4-2.fc6.src.rpm > >> package: bind-devel - 31:9.3.4-2.fc6.i386 from fedora-core-updates-6-x86_64 > >> unresolved deps: > >> libdns.so.22 > >> libbind9.so.0 > >> libisccc.so.0 > >> liblwres.so.9 > >> libisccfg.so.1 > >> libisc.so.11 > >> > >> source rpm: compiz-0.3.6-2.fc6.src.rpm > >> package: compiz-devel - 0.3.6-2.fc6.i386 from fedora-core-updates-6-x86_64 > >> unresolved deps: > >> libdecoration.so.0 > >> > >> source rpm: kdeedu-3.5.6-0.1.fc6.src.rpm > >> package: kdeedu - 3.5.6-0.1.fc6.i386 from fedora-core-updates-6-x86_64 > >> unresolved deps: > >> libpython2.4.so.1.0 > >> > >> source rpm: kdeutils-3.5.6-0.1.fc6.src.rpm > >> package: kdeutils-devel - 6:3.5.6-0.1.fc6.i386 from > >> fedora-core-updates-6-x86_64 unresolved deps: > >> libkmilo.so.1 > >> libkregexpeditorcommon.so.1 > >> libksimcore.so.1 > >> libkhexeditcommon.so.0 > >> libkcmlaptop.so.0 > >> > >> source rpm: poppler-0.5.4-5.fc6.src.rpm > >> package: poppler-devel - 0.5.4-5.fc6.i386 from fedora-core-updates-6-x86_64 > >> unresolved deps: > >> libpoppler-qt.so.1 > > > > Hrm, I'm not entirely sure, I'll have to defer to Luke Macken on that one. > > > > I'm surprised that these haven't been reported before, people are generally > > really quick to notice broken deps in the updates repos. > > > > > > Fact of the matter is, that even though people should report such > iregularities, it would be a lot less work for everybody, if yum would > update the largest portion of updates that do not have any dependency > problems. I know we've been over this like a thousand times, but I still > see no valid reason not to make yum do this! > > That would cause the 1 or 2 or 3 packages with probles to be held back, > not the rest. > and it would give users very little awareness that something didn't get patched. giving them a false sense of security. -sv From fedora-gmane.00003 at genesis-x.nildram.co.uk Thu Feb 22 12:24:37 2007 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Thu, 22 Feb 2007 12:24:37 +0000 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <9le0b4-5kg.ln1@sky.matrix> Verily I say unto thee, that Eric S. Raymond spake thusly: > This afternoon, I installed Edgy Eft on my main development machine -- Did Kevin Carmony approve your switch to Ubuntu, or are you just testing the package base for inclusion in Linspire, whilst generating some valuable publicity. > Fedora, you had every advantage Except a financial one, apparently. -- K. http://slated.org - Slated, Rated & Blogged .---- | "We shall pay any price, bear any burden, meet any hardship, support | any friend, oppose any foe, in order to assure the survival and the | success of liberty." - John F. Kennedy `---- Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.19-1.2288.fc5 12:22:44 up 2 days, 23:48, 2 users, load average: 0.03, 0.06, 0.04 From gemi at bluewin.ch Thu Feb 22 13:23:00 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 22 Feb 2007 14:23:00 +0100 Subject: Change in ncurses in devel? In-Reply-To: <20070222093541.GD7475@localhost> References: <1172093401.8843.4.camel@scriabin.tannenrauch.ch> <20070222093541.GD7475@localhost> Message-ID: <1172150580.31633.0.camel@scriabin.tannenrauch.ch> On Thu, 2007-02-22 at 10:35 +0100, Miroslav Lichvar wrote: > ucblogo needs a bit of patching, term.c declares ospeed as short, but > it should be unsigned int. Thanks, simply removing the ospeed declaration fixes the problem. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From fedora-gmane.00003 at genesis-x.nildram.co.uk Thu Feb 22 13:29:51 2007 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Thu, 22 Feb 2007 13:29:51 +0000 Subject: Goodbye, Fedora In-Reply-To: <604aa7910702211449j432dfb46tc684b0a12ece2670@mail.gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <604aa7910702211449j432dfb46tc684b0a12ece2670@mail.gmail.com> Message-ID: Verily I say unto thee, that Jeff Spaleta spake thusly: > I'm looking to submit a set of safekeep packages into the fedora > package universe. > If you are running rdiff-backup based backups now, you might want to > take these packages for a spin and see if you like safekeep's > features. > > http://jspaleta.thecodergeek.com/Fedora%20SRPMS/safekeep/FC6/ Oh, that's new. Hmm, will give it a spin. I'm a backup junkie. -- K. http://slated.org - Slated, Rated & Blogged .---- | "Future archaeologists will be able to identify a 'Vista Upgrade | Layer' when they go through our landfill sites" - Sian Berry, the | Green Party. `---- Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.19-1.2288.fc5 13:27:46 up 3 days, 53 min, 2 users, load average: 0.02, 0.04, 0.00 From fedora-gmane.00003 at genesis-x.nildram.co.uk Thu Feb 22 13:24:50 2007 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Thu, 22 Feb 2007 13:24:50 +0000 Subject: Core values In-Reply-To: <20070221213009.GC12834@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221213009.GC12834@redhat.com> Message-ID: <66i0b4-6ah.ln1@sky.matrix> Verily I say unto thee, that Dave Jones spake thusly: > On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: > > > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > > nowhere near the only reason I'm gone, but it's a big one. > > Didn't you leave already? I don't think he's generated enough publicity for Ubuntu/Linspire yet, to justify his paycheck. -- K. http://slated.org - Slated, Rated & Blogged .---- | "We shall pay any price, bear any burden, meet any hardship, support | any friend, oppose any foe, in order to assure the survival and the | success of liberty." - John F. Kennedy `---- Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.19-1.2288.fc5 13:21:46 up 3 days, 47 min, 2 users, load average: 0.06, 0.04, 0.00 From cra at WPI.EDU Thu Feb 22 14:03:37 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 22 Feb 2007 09:03:37 -0500 Subject: anaconda update time needs to be improved (really) (speed up yum/ld config) In-Reply-To: <45DB4905.9070900@gmail.com> References: <45423F30.7030600@feuerpokemon.de> <45DAEEB2.8060700@robertoragusa.it> <1171980552.21468.5.camel@gibraltar.stuttgart.redhat.com> <20070220155915.GH3334@angus.ind.WPI.EDU> <45DB4905.9070900@gmail.com> Message-ID: <20070222140337.GJ3334@angus.ind.WPI.EDU> On Tue, Feb 20, 2007 at 08:16:21PM +0100, dragoran wrote: > >I wonder if ld.so could be changed to run the cache update as needed, > >on-the-fly? > > > > > should be possible (using inotify and only add the new created files to > the cache) > but for this we need a ld daemon (dunno if its possible to update only a > part of the cache) > /sbin/ldconfig can check if the daemon is running and if yes just do > nothing, else work as it used to be (like it did before). (still works > when daemon is not running). > this would also speed up yum updates too. I was thinking more like this: When ld.so loads the ELF binary to run, it resolves library requirements. Instead of printing error messages and exiting when it can't find the required libs, just do what ldconfig would do instead, then retry loading the program again. From dnjinc at wowway.com Thu Feb 22 14:15:51 2007 From: dnjinc at wowway.com (Demond) Date: Thu, 22 Feb 2007 09:15:51 -0500 Subject: FC6 updates broken deps? In-Reply-To: <1172147946.8256.49.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <1172147946.8256.49.camel@cutter> Message-ID: <45DDA597.3010308@wowway.com> seth vidal wrote: > On Thu, 2007-02-22 at 10:25 +0100, Thomas M Steenholdt wrote: > >> Fact of the matter is, that even though people should report such >> iregularities, it would be a lot less work for everybody, if yum would >> update the largest portion of updates that do not have any dependency >> problems. I know we've been over this like a thousand times, but I still >> see no valid reason not to make yum do this! >> >> That would cause the 1 or 2 or 3 packages with probles to be held back, >> not the rest. >> >> > > and it would give users very little awareness that something didn't get > patched. > > giving them a false sense of security. > > -sv > > > The burden of a broken repo/updates should not be placed on the end user. If there is a dependency problem, then the maintainer of the repo and/or package should be notified and is responsible for fixing the problem. What good does it do for the end user? If yum, pup, or pirut notes that packages x,y & z were not updated then no one would get a false sense of security (no more a false sense than when none of the packages are updated anyway). Plus this would be a little more presentable and user friendly. Demond - beating a dead horse From skvidal at linux.duke.edu Thu Feb 22 14:19:19 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 22 Feb 2007 09:19:19 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45DDA597.3010308@wowway.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <1172147946.8256.49.camel@cutter> <45DDA597.3010308@wowway.com> Message-ID: <1172153959.8256.53.camel@cutter> On Thu, 2007-02-22 at 09:15 -0500, Demond wrote: > seth vidal wrote: > The burden of a broken repo/updates should not be placed on the end > user. If there is a dependency problem, then the maintainer of the repo > and/or package should be notified and is responsible for fixing the > problem. What good does it do for the end user? So they can file the bug to let us know. We all make mistakes and we need lots of people to catch them. It's not just the end user I'm thinking about here, it's all end users. -sv From dhollis at davehollis.com Thu Feb 22 14:56:09 2007 From: dhollis at davehollis.com (David Hollis) Date: Thu, 22 Feb 2007 09:56:09 -0500 Subject: FC6 updates broken deps? In-Reply-To: <1172147946.8256.49.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <1172147946.8256.49.camel@cutter> Message-ID: <1172156169.5175.2.camel@dhollis-lnx.sunera.com> On Thu, 2007-02-22 at 07:39 -0500, seth vidal wrote: > > and it would give users very little awareness that something didn't get > patched. > > giving them a false sense of security. > And also leave them potentially vulnerable to a larger number of issues. In some cases, some patching is better than no patching. If httpd doesn't get updated for a hot zero-day exploit because of a dependency issue with gimp and my system gets exploited, that seems like a bad thing. -- David Hollis From skvidal at linux.duke.edu Thu Feb 22 15:07:03 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 22 Feb 2007 10:07:03 -0500 Subject: FC6 updates broken deps? In-Reply-To: <1172156169.5175.2.camel@dhollis-lnx.sunera.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <1172147946.8256.49.camel@cutter> <1172156169.5175.2.camel@dhollis-lnx.sunera.com> Message-ID: <1172156823.8256.81.camel@cutter> On Thu, 2007-02-22 at 09:56 -0500, David Hollis wrote: > On Thu, 2007-02-22 at 07:39 -0500, seth vidal wrote: > > > > > and it would give users very little awareness that something didn't get > > patched. > > > > giving them a false sense of security. > > > > And also leave them potentially vulnerable to a larger number of issues. > In some cases, some patching is better than no patching. If httpd > doesn't get updated for a hot zero-day exploit because of a dependency > issue with gimp and my system gets exploited, that seems like a bad > thing. > and this is why the update system is writing out update data. So, we can differentiate b/t update for feature and update for security, or different grades of a security update. then we can work more intelligently on: yum update security-critical-only (as an example) and have it do those only. -sv From dnjinc at wowway.com Thu Feb 22 15:06:16 2007 From: dnjinc at wowway.com (Demond) Date: Thu, 22 Feb 2007 10:06:16 -0500 Subject: FC6 updates broken deps? In-Reply-To: <1172153959.8256.53.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <1172147946.8256.49.camel@cutter> <45DDA597.3010308@wowway.com> <1172153959.8256.53.camel@cutter> Message-ID: <45DDB168.7000409@wowway.com> seth vidal wrote: > On Thu, 2007-02-22 at 09:15 -0500, Demond wrote: > >> seth vidal wrote: >> The burden of a broken repo/updates should not be placed on the end >> user. If there is a dependency problem, then the maintainer of the repo >> and/or package should be notified and is responsible for fixing the >> problem. What good does it do for the end user? >> > > So they can file the bug to let us know. We all make mistakes and we > need lots of people to catch them. > > Also complain in all the outlets available to them that yum is broken. Perhaps we should look at an automatic/silent notification of dependency problems. This problem only really shows up when you have multiple repos that are dependant on each other or in rawhide. Rawhide is understandable but there should be someway of sparing the end user of a released Fedora 7 from these update problems. They can then concentrate on higher level bugs. Demond From esr at thyrsus.com Thu Feb 22 15:41:25 2007 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 22 Feb 2007 10:41:25 -0500 Subject: Core values In-Reply-To: <66i0b4-6ah.ln1@sky.matrix> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221213009.GC12834@redhat.com> <66i0b4-6ah.ln1@sky.matrix> Message-ID: <20070222154125.GA5712@thyrsus.com> Keith G. Robertson-Turner : > I don't think he's generated enough publicity for Ubuntu/Linspire yet, > to justify his paycheck. Linspire hasn't paid me anything for being on the *Freespire* advisory board, nor will they. -- Eric S. Raymond From tmus at tmus.dk Thu Feb 22 15:26:29 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Feb 2007 16:26:29 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172156823.8256.81.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <1172147946.8256.49.camel@cutter> <1172156169.5175.2.camel@dhollis-lnx.sunera.com> <1172156823.8256.81.camel@cutter> Message-ID: seth vidal wrote: > > and this is why the update system is writing out update data. So, we can > differentiate b/t update for feature and update for security, or > different grades of a security update. > > then we can work more intelligently on: > yum update security-critical-only (as an example) > That would be a nice thing for sure, but would really depend on the inclusion of some sort of --continue-on-failure functionality of yum. It makes no sense to provide a "security updates only" option, if the 20 security updates in there could potentially be held back because of a dep problem with one of them. I've said this a thousand times over and I'll say it again. I would *much* rather have 1 package with a known security problem (held back because of a dep issue with that package), than 20. /Thomas From notting at redhat.com Thu Feb 22 16:46:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Feb 2007 11:46:39 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070222023821.GA28848@jadzia.bu.edu> References: <200702201758.15925.jkeating@redhat.com> <6280325c0702211835rb5c8070y77ad9c8a9b2c3c1d@mail.gmail.com> <20070222023821.GA28848@jadzia.bu.edu> Message-ID: <20070222164639.GG323@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Thu, Feb 22, 2007 at 01:05:46PM +1030, n0dalus wrote: > > Would it be possible to provide CD versions, and a cross-platform tool > > that could generate a DVD-sized iso with it? > > There's a cross-platform tool that will make any-sized versions. It will spit out a series of 300 floppies? Bill From alan at redhat.com Thu Feb 22 17:03:23 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Feb 2007 12:03:23 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070222164639.GG323@nostromo.devel.redhat.com> References: <200702201758.15925.jkeating@redhat.com> <6280325c0702211835rb5c8070y77ad9c8a9b2c3c1d@mail.gmail.com> <20070222023821.GA28848@jadzia.bu.edu> <20070222164639.GG323@nostromo.devel.redhat.com> Message-ID: <20070222170323.GC2552@devserv.devel.redhat.com> On Thu, Feb 22, 2007 at 11:46:39AM -0500, Bill Nottingham wrote: > Matthew Miller (mattdm at mattdm.org) said: > > On Thu, Feb 22, 2007 at 01:05:46PM +1030, n0dalus wrote: > > > Would it be possible to provide CD versions, and a cross-platform tool > > > that could generate a DVD-sized iso with it? > > > > There's a cross-platform tool that will make any-sized versions. > > It will spit out a series of 300 floppies? I'd be interested in this, not for the floppies but to spit out an image or two for CF cards or USB sticks. From peter at thecodergeek.com Thu Feb 22 17:07:11 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 22 Feb 2007 09:07:11 -0800 (PST) Subject: Goodbye, Fedora In-Reply-To: <9le0b4-5kg.ln1@sky.matrix> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <9le0b4-5kg.ln1@sky.matrix> Message-ID: <41021.207.233.88.250.1172164031.squirrel@thecodergeek.com> Keith G. Robertson-Turner wrote: >> Fedora, you had every advantage > > Except a financial one, apparently. > I'm somewhat confused by your statement - what lack of financial do you see in Fedora? Red Hat is one of the primary financial sponsors of the Fedora Project; even so far as to have many of its [Fedora's] primary developers on its [Red Hat's] payroll. Please clarify this for me. Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From drago01 at gmail.com Thu Feb 22 17:10:58 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 22 Feb 2007 18:10:58 +0100 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <1172147946.8256.49.camel@cutter> <1172156169.5175.2.camel@dhollis-lnx.sunera.com> <1172156823.8256.81.camel@cutter> Message-ID: <45DDCEA2.4050303@gmail.com> Thomas M Steenholdt schrieb: > seth vidal wrote: >> >> and this is why the update system is writing out update data. So, we can >> differentiate b/t update for feature and update for security, or >> different grades of a security update. >> >> then we can work more intelligently on: >> yum update security-critical-only (as an example) >> > > That would be a nice thing for sure, but would really depend on the > inclusion of some sort of --continue-on-failure functionality of yum. > It makes no sense to provide a "security updates only" option, if the > 20 security updates in there could potentially be held back because of > a dep problem with one of them. > > I've said this a thousand times over and I'll say it again. I would > *much* rather have 1 package with a known security problem (held back > because of a dep issue with that package), than 20. > +1 ! there is no reason to hold back an update because of a broken dep thats not even related to it. > /Thomas > From pemboa at gmail.com Thu Feb 22 17:11:44 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Feb 2007 11:11:44 -0600 Subject: Goodbye, Fedora In-Reply-To: <41021.207.233.88.250.1172164031.squirrel@thecodergeek.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <9le0b4-5kg.ln1@sky.matrix> <41021.207.233.88.250.1172164031.squirrel@thecodergeek.com> Message-ID: <16de708d0702220911i7087b099vd64530e199c21f2c@mail.gmail.com> On 2/22/07, Peter Gordon wrote: > Keith G. Robertson-Turner wrote: > >> Fedora, you had every advantage > > > > Except a financial one, apparently. > > > > I'm somewhat confused by your statement - what lack of financial > do you see in Fedora? Red Hat is one of the primary financial sponsors > of the Fedora Project; even so far as to have many of its [Fedora's] > primary developers on its [Red Hat's] payroll. > > Please clarify this for me. Thanks. I could be just in a bad mood, or simply wrong....but I believe he meant financial advantage for the OP / complainer. -- Fedora Core 6 and proud From tmus at tmus.dk Thu Feb 22 17:29:12 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Feb 2007 18:29:12 +0100 Subject: Core values In-Reply-To: <66i0b4-6ah.ln1@sky.matrix> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221213009.GC12834@redhat.com> <66i0b4-6ah.ln1@sky.matrix> Message-ID: Keith G. Robertson-Turner wrote: > Verily I say unto thee, that Dave Jones spake thusly: >> On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: >> >> > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is >> > nowhere near the only reason I'm gone, but it's a big one. >> >> Didn't you leave already? > > I don't think he's generated enough publicity for Ubuntu/Linspire yet, > to justify his paycheck. > Color me old-fashioned, but isn't now a good time to stop the mud slinging contest?!? I really doubt anything constructive will ever come from that. /Thomas From florin at andrei.myip.org Thu Feb 22 17:35:41 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 22 Feb 2007 09:35:41 -0800 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> Message-ID: <45DDD46D.6030109@andrei.myip.org> Thomas M Steenholdt wrote: > Really - The reason dependency issues are such a big issue for fedora is > that all updates are held back because of a single package missing a > dependency. I'm sure everybody would feel better holding back one > package instead of all updates on this account. If I'm not mistaken, yum seems fairly unique in this regard. I mean, heck, look at Microsoft for example. Their update thing applies as many patches as possible, and those that cannot be applied, well duh, they don't get applied and the user is notified by big honking red icons that something failed. But a single error doesn't nuke the whole process. yum is _really_ boneheaded from this perspective. Your argument that a possibly much more important security update might get masked by a dependency error and is not applied is a very serious one and I don't think there can be any logical rebuttal. yum needs to be fixed, NOW. At this moment the update process puts everyone at risk. -- Florin Andrei http://florin.myip.org/ From pemboa at gmail.com Thu Feb 22 17:37:08 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Feb 2007 11:37:08 -0600 Subject: Core values In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221213009.GC12834@redhat.com> <66i0b4-6ah.ln1@sky.matrix> Message-ID: <16de708d0702220937l37bfcdfeid283a7f67f1b245@mail.gmail.com> On 2/22/07, Thomas M Steenholdt wrote: > Keith G. Robertson-Turner wrote: > > Verily I say unto thee, that Dave Jones spake thusly: > >> On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: > >> > >> > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > >> > nowhere near the only reason I'm gone, but it's a big one. > >> > >> Didn't you leave already? > > > > I don't think he's generated enough publicity for Ubuntu/Linspire yet, > > to justify his paycheck. > > > > Color me old-fashioned, but isn't now a good time to stop the mud > slinging contest?!? I really doubt anything constructive will ever come > from that. > > /Thomas To which mudslinging do you refer to exactly? -- Fedora Core 6 and proud From peter at thecodergeek.com Thu Feb 22 17:39:06 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 22 Feb 2007 09:39:06 -0800 (PST) Subject: Goodbye, Fedora In-Reply-To: <16de708d0702220911i7087b099vd64530e199c21f2c@mail.gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <9le0b4-5kg.ln1@sky.matrix> <41021.207.233.88.250.1172164031.squirrel@thecodergeek.com> <16de708d0702220911i7087b099vd64530e199c21f2c@mail.gmail.com> Message-ID: <11979.207.233.88.250.1172165946.squirrel@thecodergeek.com> Arthur Pemberton wrote: >> Please clarify this for me. Thanks. > > I could be just in a bad mood, or simply wrong....but I believe he > meant financial advantage for the OP / complainer. That would make a lot of sense given the context of his post. Thanks for the hopeful explanation. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From alan at redhat.com Thu Feb 22 17:46:09 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Feb 2007 12:46:09 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45DDD46D.6030109@andrei.myip.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> Message-ID: <20070222174609.GB6591@devserv.devel.redhat.com> On Thu, Feb 22, 2007 at 09:35:41AM -0800, Florin Andrei wrote: > yum needs to be fixed, NOW. At this moment the update process puts > everyone at risk. Send patches. From ssorce at redhat.com Thu Feb 22 17:50:19 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Feb 2007 12:50:19 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45DDD46D.6030109@andrei.myip.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> Message-ID: <1172166619.12199.41.camel@localhost.localdomain> On Thu, 2007-02-22 at 09:35 -0800, Florin Andrei wrote: > Thomas M Steenholdt wrote: > > > Really - The reason dependency issues are such a big issue for fedora is > > that all updates are held back because of a single package missing a > > dependency. I'm sure everybody would feel better holding back one > > package instead of all updates on this account. > > If I'm not mistaken, yum seems fairly unique in this regard. > > I mean, heck, look at Microsoft for example. Their update thing applies > as many patches as possible, and those that cannot be applied, well duh, > they don't get applied and the user is notified by big honking red icons > that something failed. You don't need to go as far as pointing to a broken update service like MS's one. Other Linux distributions (Ubuntu) update as much as possible and warn the user that some packages can't be updated (it also goes as far as telling you that you should do a dist-upgrade instead of just an upgrade in some cases), and they stay in the list of updates as long as the problem is not fixed. And it makes perfectly sense. I had on one of my systems a custom package that kept another one from being updated and it was OK for me. I would have been pissed off if I had to manually update or had to remove and reinstall my package each time to let the update process get through for all the other gazillion of packages. > But a single error doesn't nuke the whole process. yum is _really_ > boneheaded from this perspective. Your argument that a possibly much > more important security update might get masked by a dependency error > and is not applied is a very serious one and I don't think there can be > any logical rebuttal. +1 > yum needs to be fixed, NOW. At this moment the update process puts > everyone at risk. +1 Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From fedora-gmane.00003 at genesis-x.nildram.co.uk Thu Feb 22 17:42:05 2007 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Thu, 22 Feb 2007 17:42:05 +0000 Subject: Goodbye, Fedora In-Reply-To: <16de708d0702220911i7087b099vd64530e199c21f2c@mail.gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <9le0b4-5kg.ln1@sky.matrix> <41021.207.233.88.250.1172164031.squirrel@thecodergeek.com> <16de708d0702220911i7087b099vd64530e199c21f2c@mail.gmail.com> Message-ID: Verily I say unto thee, that Arthur Pemberton spake thusly: > On 2/22/07, Peter Gordon wrote: >> Keith G. Robertson-Turner wrote: >> >> Fedora, you had every advantage >> > >> > Except a financial one, apparently. >> > >> >> I'm somewhat confused by your statement - what lack of financial >> do you see in Fedora? Red Hat is one of the primary financial sponsors >> of the Fedora Project; even so far as to have many of its [Fedora's] >> primary developers on its [Red Hat's] payroll. >> >> Please clarify this for me. Thanks. > > I could be just in a bad mood, or simply wrong....but I believe he > meant financial advantage for the OP / complainer. Correct. Oh and I'm probably wrong too, and in a bad mood. -- K. http://slated.org - Slated, Rated & Blogged .---- | "Future archaeologists will be able to identify a 'Vista Upgrade | Layer' when they go through our landfill sites" - Sian Berry, the | Green Party. `---- Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.19-1.2288.fc5 17:39:59 up 3 days, 5:05, 2 users, load average: 0.00, 0.00, 0.00 From benny+usenet at amorsen.dk Thu Feb 22 17:53:02 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 22 Feb 2007 18:53:02 +0100 Subject: DVD only for Fedora "Classic" spin? References: <200702201758.15925.jkeating@redhat.com> <6280325c0702211835rb5c8070y77ad9c8a9b2c3c1d@mail.gmail.com> <20070222023821.GA28848@jadzia.bu.edu> <20070222164639.GG323@nostromo.devel.redhat.com> <20070222170323.GC2552@devserv.devel.redhat.com> Message-ID: >>>>> "AC" == Alan Cox writes: AC> I'd be interested in this, not for the floppies but to spit out an AC> image or two for CF cards or USB sticks. There must be a minimal size though; surely the tool doesn't split stage2.img or individual RPM's. /Benny From tmus at tmus.dk Thu Feb 22 18:04:10 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Feb 2007 19:04:10 +0100 Subject: Core values In-Reply-To: <16de708d0702220937l37bfcdfeid283a7f67f1b245@mail.gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221213009.GC12834@redhat.com> <66i0b4-6ah.ln1@sky.matrix> <16de708d0702220937l37bfcdfeid283a7f67f1b245@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > On 2/22/07, Thomas M Steenholdt wrote: >> Keith G. Robertson-Turner wrote: >> > Verily I say unto thee, that Dave Jones spake thusly: >> >> On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: >> >> >> >> > The Ubuntu crowd gets this. The Fedora crowd doesn't. That >> difference is >> >> > nowhere near the only reason I'm gone, but it's a big one. >> >> >> >> Didn't you leave already? >> > >> > I don't think he's generated enough publicity for Ubuntu/Linspire yet, >> > to justify his paycheck. >> > >> >> Color me old-fashioned, but isn't now a good time to stop the mud >> slinging contest?!? I really doubt anything constructive will ever come >> from that. >> >> /Thomas > > To which mudslinging do you refer to exactly? Mudslinging, name-calling and negatively worded posts, without a real value to the debate, in general... Who cares who's paid for what and by whom. Some possible areas of improvement was brought up. Perhaps we can use some that as valuable input to improve Fedora, perhaps not. So we should all filter the input to end up with something we can use constructively, rather than to keep "feeding the fire". I'm all for the debate, but some of the posts are just not constructive at all. So lets try to focus on what we can use the input for, rather than spending a lot of time getting all worked up. /Thomas From benny+usenet at amorsen.dk Thu Feb 22 18:46:43 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 22 Feb 2007 19:46:43 +0100 Subject: FC6 updates broken deps? References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> Message-ID: >>>>> "FA" == Florin Andrei writes: FA> If I'm not mistaken, yum seems fairly unique in this regard. FA> I mean, heck, look at Microsoft for example. Their update thing FA> applies as many patches as possible, and those that cannot be FA> applied, well duh, they don't get applied and the user is notified FA> by big honking red icons that something failed. Yum just doesn't follow the Unix commandline tradition. Unix commands should succeed quietly, and only show output if it is something the user asks for. They don't ask whether you really mean it when you tell them to do something -- heck even cp needs -i to ask whether you want to clobber a file, and that one is AFAIK a GNUism. They don't block SIGINT except when absolutely needed, and then only for a short time. Yum's interface is made for a GUI, where all this interactivity makes sense. The default should be to do exactly what the user asked, unless it is impossible. That is, it should take an extra switch to let it upgrade even when there are broken dependencies, but that extra switch should not be -y. -y is almost as bad as --force for rpm. There should probably be a switches to stop yum from upgrading or removing packages when doing an install. Add -i and --progress switches to get back the current behaviour, if people can't live without it. The --progress thing would actually make sense, if package fetching is slow sometimes. /Benny (Sorry for the gripe. Yum is a godsend, it is just the interface which is a pain) From jspaleta at gmail.com Thu Feb 22 19:05:11 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 Feb 2007 10:05:11 -0900 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) Message-ID: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> On 2/22/07, Thomas M Steenholdt wrote: > In all fairness, I wouldn't have performed that backup neither, as I > expect is true for a lot of even semi-knowledgable sysadmins and generic > linux powerusers. Not sor something as simple as this. However - There > is still the rescue mode that's been mentioned a few times already, > which could have fixed the issue in a matter of minutes. Without the backup! In an effort to chart a new course of constructive discussion... is it worth brainstorming a bit about how to make rescue mode better or more accessible? For the purposes of this discussion, we will take it for granted that at some point in the course of a 3 or 4 releases, many (i dare not say most..but many) people who are acting as the primary sysadmin for a fedora install will experience some sort of human error which will render their system unbootable. This is an unasailable axiom for the rest of this discussion. What can we do in the timescale of an F8 release to make using the rescue mode easier and more obvious course of action. Are there ways we can advertise its existence as part of sysadmin interaction with a normal operating system? Would it be helpful to slip in a rescue environment as a grub menu option instead of relying on install media? Does it make sense to spend some effort making a more featurefull rescue-like environment with guided troubleshooting characteristics? What are the top three implementable ideas which would encourage casual admins to reach for the rescue environment instead of a full wipe and re-install? -jef"we ran out of coffee at work, I've resorted to going outside and rubbing snow on my face to stay awake"spaleta From andy at warmcat.com Thu Feb 22 19:20:57 2007 From: andy at warmcat.com (Andy Green) Date: Thu, 22 Feb 2007 19:20:57 +0000 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> Message-ID: <45DDED19.4050009@warmcat.com> Jeff Spaleta wrote: > For the purposes of this discussion, we will take it for granted that > at some point in the course of a 3 or 4 releases, many (i dare not say > most..but many) people who are acting as the primary sysadmin for a > fedora install will experience some sort of human error which will > render their system unbootable. This is an unasailable axiom for the > rest of this discussion. > > What can we do in the timescale of an F8 release to make using the > rescue mode easier and more obvious course of action. Are there ways > we can advertise its existence as part of sysadmin interaction with a > normal operating system? Would it be helpful to slip in a rescue > environment as a grub menu option instead of relying on install media? That would be cool, another related improvement would be to stick the rescue image itself in /boot or in some rescue partition that can be defined in Anaconda. IIRC it was 80MB or something to download the rescue-only ISO, that's lost in the noise nowadays for most cases. > Does it make sense to spend some effort making a more featurefull > rescue-like environment with guided troubleshooting characteristics? > What are the top three implementable ideas which would encourage > casual admins to reach for the rescue environment instead of a full > wipe and re-install? I know what would help people "reach for it": if something noticeably fatal happens during the boot, reboot into the rescue image automatically right away with a path to the broken dmesg and/or initscript output sitting there along with some help text. Maybe even use a HW watchdog action to get into the rescue even after something really fatal. Extra bonus power if it can catch the full dmesg / panic somewhere the survives the warm boot. Super invulnerability power points if sshd comes up too if it can find the original /etc/sysconfig stuff so even remote servers can be adminned after a panic. -Andy From katzj at redhat.com Thu Feb 22 19:20:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Feb 2007 14:20:10 -0500 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> Message-ID: <1172172010.14287.13.camel@aglarond.local> On Thu, 2007-02-22 at 10:05 -0900, Jeff Spaleta wrote: > Does it make sense to spend some effort making a more featurefull > rescue-like environment with guided troubleshooting characteristics? This is something that comes up time and time again (there's an open bug about it as well) and that I think makes a lot of sense to do, it's just that it's something the core anaconda team never gets around to. But it's something that should be pretty easy to dive into; for the most part, there isn't the same high cost of entry that there is for most anaconda hacking and even just "script to run to fix $FOO" could be used to populate the start of a "fix common problems" menu for rescue mode. Given the fact that this keeps coming up, I just started a page at http://fedoraproject.org/wiki/Anaconda/RescueMode to somewhat track what needs doing and some of the ideas. If someone were to start looking at it, we could probably even get some simple stuff done for F7 since we're not talking about huge amounts of stuff. Also, once we have the basics, we can think about things like integrating the functionality into the live CD as well. Jeremy From alan at redhat.com Thu Feb 22 19:33:45 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Feb 2007 14:33:45 -0500 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> Message-ID: <20070222193345.GA15900@devserv.devel.redhat.com> On Thu, Feb 22, 2007 at 10:05:11AM -0900, Jeff Spaleta wrote: > In an effort to chart a new course of constructive discussion... is it > worth brainstorming a bit about how to make rescue mode better or more > accessible? I would really like to see an "autorecovery" button which went through the basic processes that are used in recovery It would run rpm verify and filter it for app problems clean up any rpm locks/mess dependancy check and essential package check replace packages where possible via net or the CD as last resort when faulty restore critical missing packages Then allow a kernel/initrd regenerate Alan From jdieter at gmail.com Thu Feb 22 19:36:42 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 22 Feb 2007 21:36:42 +0200 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <20070222193345.GA15900@devserv.devel.redhat.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> <20070222193345.GA15900@devserv.devel.redhat.com> Message-ID: <1172173002.3776.8.camel@jndwidescreen.lesbg.loc> On Thu, 2007-02-22 at 14:33 -0500, Alan Cox wrote: > On Thu, Feb 22, 2007 at 10:05:11AM -0900, Jeff Spaleta wrote: > > In an effort to chart a new course of constructive discussion... is it > > worth brainstorming a bit about how to make rescue mode better or more > > accessible? > > I would really like to see an "autorecovery" button which went through > the basic processes that are used in recovery > > It would run > rpm verify and filter it for app problems > clean up any rpm locks/mess > dependancy check and essential package check > replace packages where possible via net or the CD as last resort > when faulty > restore critical missing packages > > Then allow a kernel/initrd regenerate > > Alan > And reinstall grub in the MBR (if that's where it was installed the first time)? Jonathan -------------- 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 kmaraas at broadpark.no Thu Feb 22 11:14:37 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Thu, 22 Feb 2007 12:14:37 +0100 Subject: F7t2 and QA Meeting In-Reply-To: <20070221175105.GG19851@redhat.com> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> <20070221175105.GG19851@redhat.com> Message-ID: <1172142877.2960.1.camel@rivendell> ons, 21.02.2007 kl. 12.51 -0500, skrev Dave Jones: > On Wed, Feb 21, 2007 at 07:27:43AM -0500, Alan Cox wrote: > > On Tue, Feb 20, 2007 at 10:44:15PM -0500, Dave Jones wrote: > > > > A patch to fix the problem was accepted into the libata tree this > > > > morning, so it should show up in the mainline kernel -git soon. > > > > > > That specific bug /should/ be fixed in the fedora kernel that'll hit > > > rawhide tomorrow. > > > > The current libata tree is totally broken, cable detect is broken on intel > > chipsets at least, the resource changes cause the pcmcia driver to panic and > > various other stuff seems to have been upset in the current set of changes. > > FWIW, 2.6.20 isn't faring much better right now either. > The pending FC5/FC6 update got it's first cut at a testable RPM last night, > and fell over in so many spectacular ways I'd be embarressed to release it. > > With .21 in rc now, hopefully the final .21 will be a lot better for F7. > F6 is in need of much surgery though. > Are these libata problems the cause of my VIA based laptop not enabling DMA on the IDE attached HD after resume too maybe? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227724 Cheers Kjartan From denis at poolshark.org Thu Feb 22 19:40:36 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 22 Feb 2007 20:40:36 +0100 Subject: FC6 updates broken deps? In-Reply-To: <20070222174609.GB6591@devserv.devel.redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> Message-ID: <45DDF1B4.5090001@poolshark.org> Alan Cox wrote: > On Thu, Feb 22, 2007 at 09:35:41AM -0800, Florin Andrei wrote: >> yum needs to be fixed, NOW. At this moment the update process puts >> everyone at risk. > > Send patches. Well the yum plugins already exist. Certainly a good start would be to gather the myriad of yum plugins and include them in the main yum distribution, so at least these things get shipped together (how is an end-user supposed to learn about yum-skip-broken ?). From notting at redhat.com Thu Feb 22 19:45:24 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Feb 2007 14:45:24 -0500 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <20070222193345.GA15900@devserv.devel.redhat.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> <20070222193345.GA15900@devserv.devel.redhat.com> Message-ID: <20070222194524.GB12925@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > I would really like to see an "autorecovery" button which went through > the basic processes that are used in recovery > > It would run > rpm verify and filter it for app problems > clean up any rpm locks/mess > dependancy check and essential package check > replace packages where possible via net or the CD as last resort > when faulty > restore critical missing packages re-run grub-install ? > Then allow a kernel/initrd regenerate Bill From katzj at redhat.com Thu Feb 22 19:20:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Feb 2007 14:20:10 -0500 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> Message-ID: <1172172010.14287.13.camel@aglarond.local> On Thu, 2007-02-22 at 10:05 -0900, Jeff Spaleta wrote: > Does it make sense to spend some effort making a more featurefull > rescue-like environment with guided troubleshooting characteristics? This is something that comes up time and time again (there's an open bug about it as well) and that I think makes a lot of sense to do, it's just that it's something the core anaconda team never gets around to. But it's something that should be pretty easy to dive into; for the most part, there isn't the same high cost of entry that there is for most anaconda hacking and even just "script to run to fix $FOO" could be used to populate the start of a "fix common problems" menu for rescue mode. Given the fact that this keeps coming up, I just started a page at http://fedoraproject.org/wiki/Anaconda/RescueMode to somewhat track what needs doing and some of the ideas. If someone were to start looking at it, we could probably even get some simple stuff done for F7 since we're not talking about huge amounts of stuff. Also, once we have the basics, we can think about things like integrating the functionality into the live CD as well. Jeremy From mattdm at mattdm.org Thu Feb 22 20:17:06 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Feb 2007 15:17:06 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45DDF1B4.5090001@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> Message-ID: <20070222201706.GA10813@jadzia.bu.edu> On Thu, Feb 22, 2007 at 08:40:36PM +0100, Denis Leroy wrote: > >>yum needs to be fixed, NOW. At this moment the update process puts > >>everyone at risk. > >Send patches. > Well the yum plugins already exist. Certainly a good start would be to > gather the myriad of yum plugins and include them in the main yum > distribution, so at least these things get shipped together (how is an > end-user supposed to learn about yum-skip-broken ?). I don't think lumping them into the yum rpm is a good approach from a system maintenance perspective. How is an end-user supposed to learn about any functionality of any package? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From brugolsky at telemetry-investments.com Thu Feb 22 20:22:01 2007 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 22 Feb 2007 15:22:01 -0500 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <1172172010.14287.13.camel@aglarond.local> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> <1172172010.14287.13.camel@aglarond.local> Message-ID: <20070222202201.GC942@ti64.telemetry-investments.com> On Thu, Feb 22, 2007 at 02:20:10PM -0500, Jeremy Katz wrote: > If someone were to start looking at it, we could probably even get some > simple stuff done for F7 since we're not talking about huge amounts of > stuff. Also, once we have the basics, we can think about things like > integrating the functionality into the live CD as well. The last time this came up, IIRC, was Jeff Layton's mkinitrd rescue mode patch. I haven't looked at anaconda since then, so I have no idea where things were taken for FC6+. My firm is currently rolling our own initramfs that we use for PXE installs, as well as providing a ramfs-based rescue mode. I've encouraged my colleague to package this as a mkinitrd replacement that might be more generally useful. As I mentioned last go-round, GRUB (and perhaps the other boot loaders) can load multiple initramfs payloads. That means that one can have a small standard *kernel-independent* payload, a kernel-dependent payload (modules, probably udev at the rate we are going :-|), perhaps an install-specific image (e.g., localization info -- fonts, keyboard maps), and a large, static rescue payload. With suitable hooks in the standard payloads to test for the existence of various files (just like /fastboot, /forcefsck, etc.), task-specific initramfs payloads could be dropped into /boot and do their bit automatically. E.g., one of the things that we are doing is failing out and doing an upgrade on half of a RAID1; if the upgrade fails, we boot back into the old image. Another oft-requested task is running parted to move partitions around. Regards, Bill Rugolsky From alan at redhat.com Thu Feb 22 20:47:50 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Feb 2007 15:47:50 -0500 Subject: F7t2 and QA Meeting In-Reply-To: <1172142877.2960.1.camel@rivendell> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> <20070221175105.GG19851@redhat.com> <1172142877.2960.1.camel@rivendell> Message-ID: <20070222204750.GA20999@devserv.devel.redhat.com> On Thu, Feb 22, 2007 at 12:14:37PM +0100, Kjartan Maraas wrote: > Are these libata problems the cause of my VIA based laptop not enabling > DMA on the IDE attached HD after resume too maybe? They might get you UDMA33 limited on resume and we seem to have a problem with simplex handling which you are eeing and I'm working on which gets you stuck in PIO4. The other problem you have though is Feb 5 09:16:08 rivendell kernel: pnp: Device 00:02 activated. Feb 5 09:16:08 rivendell kernel: pnp: Failed to activate device 00:05. Feb 5 09:16:08 rivendell kernel: pnp: Device 00:0a does not support activation. Has someone compiled in both PNP BIOS and ACPI. At the moment if you do that you get both in use which isn't allowed because the PNPBIOS code doesn't disable itself when ACPI is live. From florin at andrei.myip.org Thu Feb 22 21:00:02 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 22 Feb 2007 13:00:02 -0800 Subject: FC6 updates broken deps? In-Reply-To: <20070222201706.GA10813@jadzia.bu.edu> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> Message-ID: <45DE0452.4090901@andrei.myip.org> Matthew Miller wrote: > On Thu, Feb 22, 2007 at 08:40:36PM +0100, Denis Leroy wrote: >>>> yum needs to be fixed, NOW. At this moment the update process puts >>>> everyone at risk. >>> Send patches. >> Well the yum plugins already exist. Certainly a good start would be to >> gather the myriad of yum plugins and include them in the main yum >> distribution, so at least these things get shipped together (how is an >> end-user supposed to learn about yum-skip-broken ?). > > I don't think lumping them into the yum rpm is a good approach from a system > maintenance perspective. > > How is an end-user supposed to learn about any functionality of any package? They don't have to learn much, if the defaults are sensible. Which, of course, brings us to the discussion about what is "sensible" and what is not. ;-) -- Florin Andrei http://florin.myip.org/ From fedora-gmane.00003 at genesis-x.nildram.co.uk Thu Feb 22 21:34:24 2007 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Thu, 22 Feb 2007 21:34:24 +0000 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> Message-ID: <4se1b4-aol.ln1@sky.matrix> Verily I say unto thee, that Jeff Spaleta spake thusly: > In an effort to chart a new course of constructive discussion... is > it worth brainstorming a bit about how to make rescue mode better or > more accessible? The current rescue mode is certainly sufficient for experienced admins, however it would be a good idea to implement some helper scripts, and possibly even a fluxbox minimal environment. The latter would be especially useful to facilitate administering LVM via system-config-lvm, as I must admit the lvm command syntax is still a mystery to me. The logical procedure should be, identify (as far as possible) what *can* go wrong, think about how *you* would fix it, see if there's any way to (semi)automate that process with helper scripts, and compare that with what's currently available in the rescue environment. Off the top of my head, I'd suggest: 1) Enable installing an immutable rescue partition, and add as a grub entry. 2) Add a minimal graphical environment. 3) Add a "Rescue Install" to Anaconda. 4) Add the various system-config-* helpers. 5) Have a dedicated RPM rescue tool, since this is a special case. I.e. is rpm + all deps correctly installed, are there stale locks, sanity check on the database, etc. 6) Anaconda suggests a backup partition, or asks for a network backup location, and sets up a cron job (SafeKeep?). I.e. push hard to make backup mandatory(ish). I'd also suggest Disk Druid, etc., pushes the suggestion of LVM *and* a snapshot partition, which is IMHO essential. You could do some checks to see if the default root system is bootable, etc., then automatically fall back to rescue mode if not (GRUB patch?), rather than allow the init to proceed then fail. This is essential on a headless server, where it's "stuck" and you can't ssh in to see why. If the idea of a GUI doesn't appeal to you (and for network admins it probably doesn't), I'd suggest the implementation of a ncurses interface for some of the helper tools (long term). As a side note, though not directly related to "rescue", I advocate that yum should be patched to enable partial-failure, i.e. "update as much as possible, root notify failures". I understand it is not a popular theory, but broken deps/repos break automatic updates completely, rather than partially, which could be a problem, e.g. on a large network (like mine) where an essential security update (and all other updates) are not deployed, simply because of *one* broken, and non-essential, package. This just doesn't make any logical sense, and could be an issue for those relying on automated mass system updates. Anyway, back on topic, let's say *I* ask *you*, my sysadmin, to fix the following. What would you (i.e. the script) need to do to (semi)automate this? Not all of these *have* solutions, that can be implemented in software, but even the *hardware* issues could be given more verbose notification/suggestions: 1) swapon ... won't activate, because the swap drive is dead, but this is a low memory system set to automatically boot into X. 2) root filesystem mount failure. 3) Missing/corrupt initrd/bzimage. 4) Missing/non-funtional SCSI/IDE drivers in an *updated* kernel, so cannot mount root filesystem (but previous kernel works). 5) service segfaults and halts init. 6) service has (missing files | other problem) and waits forever (does not detach to daemon). (hint for 5 and 6 - watchdog timer) 7) Initscripts are b0rked, typo, non-fatal error, etc. (I recently caught one, still unresolved, nfs mountd problem). Why is this needed for rescue mode? Because not all startup errors are noticed by the (unobservant | people who blink a lot). :) A way of running through ($chroot)/init.d in rescue mode looking for non-zero return codes, and suggesting updates/workarounds etc., would be handy. But maybe this is stretching "rescue mode" a little too far. 8) RPM is b0rked. How do I reinstall RPM ... without RPM??? Cyclic dependency error 101: Arrrrggghh! 9) Again, maybe stretching "rescue" too far, but how about fslint in rescue mode, to clean up all those "#PRELINK", "foobar~", and other junk. Especially on a monolithic install (all under /) where /tmp is full. 10) Only other thing I can think of is, SMART disk health checks, however, according to Google's recent report (they did a massive test), SMART is next to useless at actually predicting failure. That's it. I'm sure 99% of the above is useless, but hey ... that's why they call it brainstorming :) -- K. http://slated.org - Slated, Rated & Blogged .---- | "Future archaeologists will be able to identify a 'Vista Upgrade | Layer' when they go through our landfill sites" - Sian Berry, the | Green Party. `---- Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.19-1.2288.fc5 21:32:25 up 3 days, 8:57, 2 users, load average: 0.26, 0.31, 0.27 From lsof at nodata.co.uk Thu Feb 22 21:45:06 2007 From: lsof at nodata.co.uk (nodata) Date: Thu, 22 Feb 2007 22:45:06 +0100 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> Message-ID: <1172180707.3033.5.camel@sb-home.lan> Am Donnerstag, den 22.02.2007, 19:46 +0100 schrieb Benny Amorsen: > Yum just doesn't follow the Unix commandline tradition. Unix commands > should succeed quietly, and only show output if it is something the > user asks for. Yes you're right. Yum's current mode should be the verbose mode. A benefit of showing stuff is that it makes the command seem faster. When should yum be quiet? # yum install package Should be quiet unless a dependency needs to be pulled in, otherwise it should fail. To counter this: # yum -r install package could resolve dependencies. Shall I file an RFE? From lsof at nodata.co.uk Thu Feb 22 21:46:29 2007 From: lsof at nodata.co.uk (nodata) Date: Thu, 22 Feb 2007 22:46:29 +0100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <1172180789.3033.7.camel@sb-home.lan> Am Dienstag, den 20.02.2007, 17:58 -0500 schrieb Jesse Keating: > For Test2, I'm planning on doing the Fedora "Classic" spin for folks to work > with. Doing the Everything spin at this point is just going to take up a LOT > of bandwidth / space for such a temporary thing. I do believe we'll have a > Desktop (Gnome) LiveCD as well, perhaps a KDE one if the KDE folks kick some > butt. > > That said, we've toyed with the idea of doing DVD iso only for the Classic > (and Everything) spin. Easy enough for me to do in pungi, I'll just set the > cd size to 4.5G and produce one iso. > > So, how much hate will be thrown my way if we just do a DVD sized iso for > Test2's Classic spin? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Please could "Classic" be named something more obvious to people not inside Fedora? From sundaram at fedoraproject.org Thu Feb 22 21:49:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 Feb 2007 03:19:33 +0530 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <1172180789.3033.7.camel@sb-home.lan> References: <200702201758.15925.jkeating@redhat.com> <1172180789.3033.7.camel@sb-home.lan> Message-ID: <45DE0FED.2020703@fedoraproject.org> nodata wrote: > Am Dienstag, den 20.02.2007, 17:58 -0500 schrieb Jesse Keating: >> For Test2, I'm planning on doing the Fedora "Classic" spin for folks to work >> with. Doing the Everything spin at this point is just going to take up a LOT >> of bandwidth / space for such a temporary thing. I do believe we'll have a >> Desktop (Gnome) LiveCD as well, perhaps a KDE one if the KDE folks kick some >> butt. >> >> That said, we've toyed with the idea of doing DVD iso only for the Classic >> (and Everything) spin. Easy enough for me to do in pungi, I'll just set the >> cd size to 4.5G and produce one iso. >> >> So, how much hate will be thrown my way if we just do a DVD sized iso for >> Test2's Classic spin? >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Please could "Classic" be named something more obvious to people not > inside Fedora? Yes. Thats the plan. It is just a internal reference name for the current discussion. Rahul From ml at deadbabylon.de Thu Feb 22 21:51:08 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 22 Feb 2007 22:51:08 +0100 Subject: Experimental KDE 3.80.3 specfiles In-Reply-To: References: Message-ID: <20070222225108.693e5e73@localhost.localdomain> Am Wed, 21 Feb 2007 15:11:13 +0000 (UTC) schrieb Kevin Kofler : Thank you very much for the SPECS. But is there an official place for the tarballs? I've extractet the Tarballs for my tests from the suse-rpms at: http://software.opensuse.org/download/KDE:/KDE4/openSUSE_10.2/src/ > Mock builds for FC5, FC6 and devel still need to be tested. I was able to build them in mock for fc6-i386. There were no problems with the rpath. > Note that I don't know if the kde4.desktop in /usr/share/xsessions > actually does anything useful, Only crashes the login under 10 seconds. :) Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From overholt at redhat.com Thu Feb 22 22:00:07 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 22 Feb 2007 17:00:07 -0500 Subject: Fwd: eclipse-cdt-3.1.2 with Autotools 0.0.8 support available Message-ID: <20070222220006.GG388@redhat.com> Jeff's not on fedora-devel-list yet so his post was rejected. We'd appreciate any testing that people do with this. More information can be found here: http://sourceware.org/eclipse/autotools I'll try to write up a blog entry with some screenshots or animated gifs tomorrow. ----- Forwarded message from Jeff Johnston ----- > From: Jeff Johnston > To: fedora-devel-list at redhat.com, fedora-devel-java-list at redhat.com > Cc: > Date: Thu, 22 Feb 2007 16:49:20 -0500 > Subject: eclipse-cdt-3.1.2 with Autotools 0.0.8 support > available > > This is to announce that version 3.1.2 of the Eclipse CDT is now > available for Fedora. The RPMs also contain the latest Autotools plugin > release, 0.0.8. > > The Autotools 0.0.8 plug-in has been updated from 0.0.7 to contain an > improved Autoconf editor including outline support and rudimentary > syntax parsing. As this project is under heavy development, we would > greatly appreciate any testing and feedback. > > For FC6, the RPMs can be installed from the updates-testing repo. For > F7, the RPMs can be installed from Rawhide. > > Any bugs should be submitted to bugzilla.redhat.com for Fedora Core > under component eclipse-cdt. > ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu Feb 22 22:15:48 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 Feb 2007 13:15:48 -0900 Subject: The future of pfmon? Message-ID: <604aa7910702221415s19d9a3e4t3f8a07a7960a110e@mail.gmail.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229711 At least for fc6... the kernel doesnt support perfmon, which makes the existance of pfmon in Core a bit amusing. So I have to ask, in the F7 timeframe, pfmon isn't on a defined spin is it? Even the 'classic' spin, That would be somewhat wasteful. I won't question its overall worth in the Fedora repository, I'm sure people roll their own kernels and find a use for this tool. -jef From pemboa at gmail.com Thu Feb 22 22:32:18 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Feb 2007 16:32:18 -0600 Subject: Slightly OT: bad rap for Fedora, and realistic effects Message-ID: <16de708d0702221432m578a1889ye344f61cf665588a@mail.gmail.com> Well I'm not sure how many of you all have seen this: http://linux.slashdot.org/article.pl?sid=07/02/22/207231 And this may or may not be the correct -list for this, but here goes. I think its fair to say that a lot of the louder voices on the internet do not like Fedora for fair and unfair reasons. My question is what does this do to Fedora, and RedHat by association. I can't imagine that anything good is coming of this. All the developers here are bound by the 24hr daily limit, ie. there is a finite amount of work that any developer can accomplish, esp. those not being paid to work on Fedora. Making the assumption that all these negative word of mouth is bleeding Fedora of contributors, then what's the plan? A few loyalist bound by the laws of Physics can only accomplish so much, and I'm even more worried that the bad karma trickles down to RedHat, who I believe is the Cinderella of the Linux community - one day I hope to be in the position to purchase RHEL licenses, but I'm becoming worried that it may not be around by time I get there. Peace -- Fedora Core 6 and proud From Axel.Thimm at ATrpms.net Thu Feb 22 22:41:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 22 Feb 2007 23:41:07 +0100 Subject: NVIDIA graphics driver version format announcement In-Reply-To: <7c1574a90702221330m2661b2d5he2466c75d90c075d@mail.gmail.com> References: <7c1574a90702221330m2661b2d5he2466c75d90c075d@mail.gmail.com> Message-ID: <20070222224107.GB20372@neu.nirvana> On Thu, Feb 22, 2007 at 01:30:03PM -0800, Lonni J Friedman wrote: > This post is an early notification to anyone that repackages the > NVIDIA UNIX Graphics Driver. > > Starting in the Release 100 driver series, NVIDIA will revise the > format of the version number for the UNIX Graphics Driver. > > In the past, the NVIDIA UNIX Graphics Driver version format was > "1.0-XXXX" (e.g., "1.0-9746"). Starting in Release 100, the new > format will be a collection of period-separated fields (e.g., > "100.17.03"). > > The left-most field will indicate the major release series ("Release > 100", Release "105", etc.). The second field and optional third or > additional fields will be used for NVIDIA tracking. > > The version number will be a variable number of fields, however it > will consist only of digits and periods. > > This version format change will apply to both the package filenames, > and the names of the libraries. > > Examples: > > /usr/lib/libGLcore.so.100.17 do you intend to do so with libGL.so.1, too? Because that would break a lot of stuff and would render the nvidia-graphics libs not adequate for in-place-substitutes for any system shipped libGL.so.1 anymore. > NVIDIA-Linux-x86-100.17-pkg1.run > NVIDIA-Linux-x86_64-100.17-pkg2.run > NVIDIA-Solaris-x86-100.17.run > NVIDIA-FreeBSD-x86-100.17.tar.gz > > # glxinfo | grep "OpenGL version string" > OpenGL version string: 2.1.1 NVIDIA 100.17 > > # cat /proc/driver/nvidia/version > NVRM version: NVIDIA UNIX x86 Kernel Module 100.17 Mon Feb 12 > 14:37:08 PST 2007 > GCC version: gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) > > After the Release 100 driver series is released, we will make a > similar change to the 1.0-96xx and 1.0-71xx legacy GPU release > branches. > > Thanks, > Lonni J Friedman > NVIDIA Corp > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Feb 22 22:47:21 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 Feb 2007 22:47:21 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles References: <20070222225108.693e5e73@localhost.localdomain> Message-ID: Sebastian Vahl deadbabylon.de> writes: > Thank you very much for the SPECS. But is there an official place for > the tarballs? I've extractet the Tarballs for my tests from the > suse-rpms at: > http://software.opensuse.org/download/KDE:/KDE4/openSUSE_10.2/src/ 3.80.3 hasn't been officially announced yet for some reason. I'll make full SRPMs available ASAP anyway. > > Mock builds for FC5, FC6 and devel still need to be tested. > > I was able to build them in mock for fc6-i386. There were no problems > with the rpath. Thanks. I guess I'll upload some SRPMs, hopefully Rex Dieter will have the time to build them into the kde-redhat repo. > > Note that I don't know if the kde4.desktop in /usr/share/xsessions > > actually does anything useful, > > Only crashes the login under 10 seconds. :) Wow, that's not good. I guess I should not install this for now, given that it doesn't work at all. Kevin Kofler From blizzard at redhat.com Thu Feb 22 22:56:20 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 22 Feb 2007 17:56:20 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <1172180789.3033.7.camel@sb-home.lan> References: <200702201758.15925.jkeating@redhat.com> <1172180789.3033.7.camel@sb-home.lan> Message-ID: <1172184980.27976.31.camel@localhost.localdomain> On Thu, 2007-02-22 at 22:46 +0100, nodata wrote: > Please could "Classic" be named something more obvious to people not > inside Fedora? > Yeah, "Classic" is my fault. Sorry about that. I hope it doesn't stick around forever. --Chris From kevin.kofler at chello.at Thu Feb 22 22:51:32 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 Feb 2007 22:51:32 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles References: Message-ID: Another interesting issue: The Qt Designer 4 plugin for the KDE 4 widgets doesn't work. I tried to copy or symlink /opt/kde4/lib/kde4/plugins/designer/kdewidgets.so into /usr/lib/qt4/plugins/designer, but this doesn't seem to work. A symlink apparently gets ignored completely; with a copy, I get: - pluginName='/usr/lib/qt4/plugins/designer/kdewidgets.so' - error='QLibrary::resolve_sys: Symbol "qt_plugin_instance" undefined in /usr/lib/qt4/plugins/designer/kdewidgets.so (/usr/lib/qt4/plugins/designer/kdewidgets.so: undefined symbol: qt_plugin_instance)' I tried to troubleshoot this, but didn't find anything yet, I'll probably have to ask the upstream KDE folks for help. Kevin Kofler From skvidal at linux.duke.edu Thu Feb 22 22:58:13 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 22 Feb 2007 17:58:13 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <1172184980.27976.31.camel@localhost.localdomain> References: <200702201758.15925.jkeating@redhat.com> <1172180789.3033.7.camel@sb-home.lan> <1172184980.27976.31.camel@localhost.localdomain> Message-ID: <1172185093.13830.61.camel@cutter> On Thu, 2007-02-22 at 17:56 -0500, Christopher Blizzard wrote: > On Thu, 2007-02-22 at 22:46 +0100, nodata wrote: > > Please could "Classic" be named something more obvious to people not > > inside Fedora? > > > > Yeah, "Classic" is my fault. Sorry about that. I hope it doesn't stick > around forever. Should we call it Pepsi? -sv From denis at poolshark.org Thu Feb 22 23:09:17 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 23 Feb 2007 00:09:17 +0100 Subject: FC6 updates broken deps? In-Reply-To: <20070222201706.GA10813@jadzia.bu.edu> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> Message-ID: <45DE229D.4010306@poolshark.org> Matthew Miller wrote: > On Thu, Feb 22, 2007 at 08:40:36PM +0100, Denis Leroy wrote: >>>> yum needs to be fixed, NOW. At this moment the update process puts >>>> everyone at risk. >>> Send patches. >> Well the yum plugins already exist. Certainly a good start would be to >> gather the myriad of yum plugins and include them in the main yum >> distribution, so at least these things get shipped together (how is an >> end-user supposed to learn about yum-skip-broken ?). > > I don't think lumping them into the yum rpm is a good approach from a system > maintenance perspective. I actually meant integrated into yum. For the same reasons we want kernel RPMs to be pushed upstream. The idea here is to have more people contribute to yum. From chtaylo4 at gmail.com Thu Feb 22 23:17:44 2007 From: chtaylo4 at gmail.com (Chris Taylor) Date: Thu, 22 Feb 2007 18:17:44 -0500 Subject: a question about the .spec file In-Reply-To: <45DD0209.3090807@BitWagon.com> References: <20070221172943.d659109a.zaitcev@redhat.com> <45DD0209.3090807@BitWagon.com> Message-ID: > In the .spec for the current kernel-2.6.20-1.2936.fc7 the defense > is contained in lines such as: > %define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-*.config > which includes %{kversion} in the relevant filenames. However, kversion > is only 2.6.%{sublevel}, so the defense is not necessarily exhaustive. > > > ... You're still advised to remove > > old sources before running rpm -i on an SRPM. > > This advice confirms that some .spec files do/did have such misfeatures; > and/or the misdesign of rpm for not anticipating the use of SOURCES > as an uncontrolled cache, multiple simultaneous builds [inhibiting > "rm -f SOURCES/*"], etc. > > So basically this is how to recreate the problem: install the srpm for kernel-2.6.18 build the rpm from source install the 2.6.18 rpm install the srpm for kernel-2.6.19 build the rpm from source watch all config files applied (2.6.18 and 2.6.19) this happens becuase the config files from all_arch_configs are never deleted when building the 2.6.18 rpm. I see two options: 1) delete the *.configs when you're done with them (akin to cleaning up your space when you're done using it) 2) specify to loop only over kernel-%{kversion}*.config I did #2 and it worked for me, but I can see the reasoning in doing any of the following 1 2 1 and 2 Respectfully, Christopher Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu Feb 22 23:40:54 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 Feb 2007 14:40:54 -0900 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> Message-ID: <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> On 2/22/07, Arthur Pemberton wrote: > And this may or may not be the correct -list for this, but here goes. > I think its fair to say that a lot of the louder voices on the > internet do not like Fedora for fair and unfair reasons. My question > is what does this do to Fedora, and RedHat by association. I can't > imagine that anything good is coming of this. All the developers here > are bound by the 24hr daily limit, ie. there is a finite amount of > work that any developer can accomplish, esp. those not being paid to > work on Fedora. Making the assumption that all these negative word of > mouth is bleeding Fedora of contributors, then what's the plan? First I'd stop making unfounded assumptions about how the contributor numbers are falling. There's no real evidence of that at all. We we saw this week was another chapter of the lack of contribution from the same person, a person with a long standing personal agenda which is at odds with the policies of this project, and someone who consistently speaks based on information which appears to be based on the a view of the fedora project which is 6 months to a year out of date. At the end of the day, this was not a suddenly new development, and it was not the loss of an active contributor. What we have been seeing this week is a skilled politician using what have become very standard tricks of the trade. Its messy and its ugly, but anyone whose lived through the last decade of US national political cycles should recognize it for what it is. To re-use a phrase, Fedora's been swift-boated. It's really unfortunate that such political skill has been squandered for such a petty purpose. I fear for the health of the freespire project if a board member of that project needs to publicly attack a competing project via personal letters directly to the press. But unlike politicians, we aren't gearing up for an election day. There is no drop-dead date by which we need to convince a majority of contributors to work with us for X number of years. That's sort of the great thing about... community. We don't need to strong arm, or twist the truth, or talk smack about competing ideas. Fedora does not need to win a decisive victory at the expense of other community projects. Fedora can continue to build an active community and continue to make the long term impact that it needs to make and fulfill its stated mission. All we need to do is do our best is to be upfront about what this project is, what its goals are, and to be as encompassing and supportive of as many people's individual itches inside that framework. If we wanted to run a counter political campaign, then I would very much suggest everyone who is interested, write Max Spevack with a short personal testimony with your positive personal pov as to what you get out of being a contributor to Fedora. What you feel is important about Fedora that makes it worth the time. Because that's what matters. its not the number of contributors, or size of the codebase, or the size of the userbase. What matters when choosing to be a volunteer for any organization or project is knowing that by contributing your time and your talents you are personally growing from the experience and that your efforts are making a difference. I'm sure Max won't mind compiling selected testimonials into a PR piece to counter-balance any further poltical manipulation of the laypress. If we don't attract people who are looking for personal control, instead of personal growth.. that is a perfectly acceptable outcome to me. We don't need to attract everybody, niether as a user nor as a contributor. We need to do our best to attract the people who would work well inside the scope of the project... and at the same time help others find projects which fit best for them. Fedora should be the linux distribution like Progressive is to car insurance. If we aren't the best choice for you, we'll help you find the distribution that is. For some outspoken media-savvy people, a position on the freespire board may very well be the project that fits them best. It's just unfortunate that it took that person as long as it did to figure that out. If I regret anything with regard to how this project has treated said individual, it is that we didn't try hard enough earlier on to help him find linspire sooner. Does this project has problems to solve? Absolutely, but the important ones the Fedora needs to focus on right now have nothing to do with the screed we saw in the press this week. But every single important problem that this project faces is the result of growth, and growing pains can hurt like hell some times. -jef"Fedora's growing up, soon there will be hair growing on it in some very sensitive places"spaleta From alan at redhat.com Thu Feb 22 23:52:54 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Feb 2007 18:52:54 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <1172185093.13830.61.camel@cutter> References: <200702201758.15925.jkeating@redhat.com> <1172180789.3033.7.camel@sb-home.lan> <1172184980.27976.31.camel@localhost.localdomain> <1172185093.13830.61.camel@cutter> Message-ID: <20070222235254.GC32109@devserv.devel.redhat.com> On Thu, Feb 22, 2007 at 05:58:13PM -0500, seth vidal wrote: > > Yeah, "Classic" is my fault. Sorry about that. I hope it doesn't stick > > around forever. > > Should we call it Pepsi? "Old Hat" ? From pemboa at gmail.com Fri Feb 23 00:00:18 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Feb 2007 18:00:18 -0600 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> Message-ID: <16de708d0702221600w5e758b1brb3406bc22fc272fe@mail.gmail.com> On 2/22/07, Jeff Spaleta wrote: > On 2/22/07, Arthur Pemberton wrote: > > And this may or may not be the correct -list for this, but here goes. > > I think its fair to say that a lot of the louder voices on the > > internet do not like Fedora for fair and unfair reasons. My question > > is what does this do to Fedora, and RedHat by association. I can't > > imagine that anything good is coming of this. All the developers here > > are bound by the 24hr daily limit, ie. there is a finite amount of > > work that any developer can accomplish, esp. those not being paid to > > work on Fedora. Making the assumption that all these negative word of > > mouth is bleeding Fedora of contributors, then what's the plan? > > First I'd stop making unfounded assumptions about how the contributor > numbers are falling. > There's no real evidence of that at all. We we saw this week was > another chapter of the lack of contribution from the same person, a > person with a long standing personal agenda which is at odds with the > policies of this project, and someone who consistently speaks based on > information which appears to be based on the a view of the fedora > project which is 6 months to a year out of date. At the end of the > day, this was not a suddenly new development, and it was not the loss > of an active contributor. What we have been seeing this week is a > skilled politician using what have become very standard tricks of the > trade. Its messy and its ugly, but anyone whose lived through the > last decade of US national political cycles should recognize it for > what it is. To re-use a phrase, Fedora's been swift-boated. It's > really unfortunate that such political skill has been squandered for > such a petty purpose. I fear for the health of the freespire project > if a board member of that project needs to publicly attack a competing > project via personal letters directly to the press. > > But unlike politicians, we aren't gearing up for an election day. > There is no drop-dead date > by which we need to convince a majority of contributors to work with > us for X number of years. That's sort of the great thing about... > community. We don't need to strong arm, or twist the truth, or talk > smack about competing ideas. Fedora does not need to win a decisive > victory at the expense of other community projects. Fedora can > continue to build an active community and continue to make the long > term impact that it needs to make and fulfill its stated mission. All > we need to do is do our best is to be upfront about what this project > is, what its goals are, and to be as encompassing and supportive of as > many people's individual itches inside that framework. > > If we wanted to run a counter political campaign, then I would very > much suggest everyone who is interested, write Max Spevack with a > short personal testimony with your positive personal pov as to what > you get out of being a contributor to Fedora. What you feel is > important about Fedora that makes it worth the time. Because that's > what matters. its not the number of contributors, or size of the > codebase, or the size of the userbase. What matters when choosing to > be a volunteer for any organization or project is knowing that by > contributing your time and your talents you are personally growing > from the experience and that your efforts are making a difference. > I'm sure Max won't mind compiling selected testimonials into a PR > piece to counter-balance any further poltical manipulation of the > laypress. > > If we don't attract people who are looking for personal control, > instead of personal growth.. that is a perfectly acceptable outcome to > me. We don't need to attract everybody, niether as a user nor as a > contributor. We need to do our best to attract the people who would > work well inside the scope of the project... and at the same time help > others find projects which fit best for them. Fedora should be the > linux distribution like Progressive is to car insurance. If we aren't > the best choice for you, we'll help you find the distribution that is. > For some outspoken media-savvy people, a position on the freespire > board may very well be the project that fits them best. It's just > unfortunate that it took that person as long as it did to figure that > out. If I regret anything with regard to how this project has treated > said individual, it is that we didn't try hard enough earlier on to > help him find linspire sooner. > > Does this project has problems to solve? Absolutely, but the important > ones the Fedora needs to focus on right now have nothing to do with > the screed we saw in the press this week. But every single important > problem that this project faces is the result of growth, and growing > pains can hurt like hell some times. > > -jef"Fedora's growing up, soon there will be hair growing on it in > some very sensitive places"spaleta > > -- Okay, I see your point, and I believe that I understand it. Somewhat along those lines, is there an official list of awknowledged problems in Fedora? I seem to rarely run into most of these issues myself, so when I hear of supposedly large problems in Fedora, it takes me a bit of guard and I become curious as to their factual worth. -- Fedora Core 6 and proud From knightmerc at yahoo.com Fri Feb 23 00:03:34 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Thu, 22 Feb 2007 19:03:34 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <200702222256.20754.kaj@haulrich.net> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> Message-ID: <1172189014.3743.154.camel@localhost.localdomain> On Thu, 2007-02-22 at 22:56 +0100, Kaj Haulrich wrote: > Due to my lousy English - "Danglish" - I referred to the (K)ubuntu > install, not FC6 (Where I actually lurked on the ML some months > before installing it so I avoided the LVM and SELinux stuff). The > default (K)ubuntu install is open source only, if someone want the > proprietary stuff further repos must be enabled, just like FC. > > Mark Shuttleworth has some remarks on non-free drivers here : > > http://www.markshuttleworth.com/archives/95 > > I was a bit surprised when the (K)ubuntu installed an ATI driver all > by itself, but it seems that the driver (UTAH) is open source as > well. > > Kaj. There needs to be a balance between the right of individuals to own their own property (specifically in our realm of discussion, intellectual property) and the right of individuals to control the source to the operating system they run. Currently the trend with the Cox's of the world is to abolish the rights of companies and individuals to protect their own intellectual property rights; at any cost. The plain simple definition of socialism is the abolition of personal property to another jurisdiction other than the true owner of that personal property; be that a dictator or a government, or a group of socio-fascist developers. In this case, the developers seek to take the decision about intellectual property rights OUT of the public domain (the "Market") and to FORCIBLY TAKE AWAY the right of the company or individual to license driver-code the way the code authors see fit. This is not "freedom", it is in reality a form of slavery. The way they seek to accomplish this is by writing the kernel so that it will reject any module that it (the kernel) perceives as NOT open source. This is not a technical task, it is an ideological task. The problem I have and that I have always had is that ideological decisions are the domain of the USER, NOT THE KERNEL. Furthermore, and more to the point, ideological decisions are the purview of the USER and NOT THE DEVELOPERS. The kernel is and has always been a product of technical merit (which was freely given, as opposed to forcibly taken); the ideologues in the developer community seek to slave the kernel itself to their own personal ideological goals. THAT is where the line is being crossed; THAT is the abhorrent corruption we are faced with. The developers have no rights to other people's intellectual property rights or software licensing decisions, OR the JURISDICTION THEREOF; yet in face of that fact they seek to forcibly TAKE or CONTROL what is not theirs by *force*. How? Because since they control the kernel, they essentially have monopoly power over the Linux operating system. They are currently abusing that leverage to execute forced licensing upon any developer that writes driver code. No longer is the programmer the arbiter of the license of his own work. The use of such a monopoly power for ideological ends is force and is therefore by definition fascism. Fascism is nothing less than an advanced aspect of socialism; the same is true of communism. Both fascism and communism are *consequences* of socialism. In the linux world today we are now seeing both consequences manifest themselves in the religious fanatic RMS sectors of the community. The ONLY thing that has stopped this process.....and I do mean the ONLY thing, is Linus Torvalds. He has made it clear that the Linux kernel will NOT be turned into an ideological tool (but even as he has made this clear, the offending messages remain entrenched in the kernel right now as we speak, running prospective developers away and causing many developers to question the domain of Linux as being anything near fruitful). For this he has suffered much criticism and hate mail. In the same regard, ESR has suffered much criticism and hate mail. This is the modern rendition of the medieval persecution of the Jews by the Flagellants during the Black Plague. We have the religious fanatics, and we have the innocent heros, deprived of justice. The only difference is that instead of maniacal religious zealots beating themselves with chains and murdering Jews, we have the present day maniacal religious Stallman nose pickers, and instead of the Jews we have Torvalds, ESR, and those of us with sufficient testosterone to support their cause. LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From mattdm at mattdm.org Fri Feb 23 00:51:05 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Feb 2007 19:51:05 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45DE229D.4010306@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> <45DE229D.4010306@poolshark.org> Message-ID: <20070223005105.GA31821@jadzia.bu.edu> On Fri, Feb 23, 2007 at 12:09:17AM +0100, Denis Leroy wrote: > >I don't think lumping them into the yum rpm is a good approach from a > >system maintenance perspective. > I actually meant integrated into yum. For the same reasons we want > kernel RPMs to be pushed upstream. The idea here is to have more people > contribute to yum. But all these things are already in yum-utils. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Fri Feb 23 00:51:05 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Feb 2007 19:51:05 -0500 Subject: F7t2 and QA Meeting In-Reply-To: <20070222204750.GA20999@devserv.devel.redhat.com> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> <20070221175105.GG19851@redhat.com> <1172142877.2960.1.camel@rivendell> <20070222204750.GA20999@devserv.devel.redhat.com> Message-ID: <20070223005105.GA25845@redhat.com> On Thu, Feb 22, 2007 at 03:47:50PM -0500, Alan Cox wrote: > On Thu, Feb 22, 2007 at 12:14:37PM +0100, Kjartan Maraas wrote: > > Are these libata problems the cause of my VIA based laptop not enabling > > DMA on the IDE attached HD after resume too maybe? > > They might get you UDMA33 limited on resume and we seem to have a problem > with simplex handling which you are eeing and I'm working on which gets you > stuck in PIO4. > > The other problem you have though is > Feb 5 09:16:08 rivendell kernel: pnp: Device 00:02 activated. > Feb 5 09:16:08 rivendell kernel: pnp: Failed to activate device 00:05. > Feb 5 09:16:08 rivendell kernel: pnp: Device 00:0a does not support activation. > > Has someone compiled in both PNP BIOS and ACPI. At the moment if you do that > you get both in use which isn't allowed because the PNPBIOS code doesn't > disable itself when ACPI is live. CONFIG_PNPBIOS has been disabled for a looong time. It blew up on far too many machines when it was last attempted (FC2 era). Dave -- http://www.codemonkey.org.uk From bloch at verdurin.com Fri Feb 23 01:14:57 2007 From: bloch at verdurin.com (bloch at verdurin.com) Date: Fri, 23 Feb 2007 01:14:57 +0000 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> Message-ID: <20070223011457.GD2068@bloch.config> On Thu, 22 Feb 2007, Jeff Spaleta wrote: > In an effort to chart a new course of constructive discussion... is it > worth brainstorming a bit about how to make rescue mode better or more > accessible? > > For the purposes of this discussion, we will take it for granted that > at some point in the course of a 3 or 4 releases, many (i dare not say > most..but many) people who are acting as the primary sysadmin for a > fedora install will experience some sort of human error which will > render their system unbootable. This is an unasailable axiom for the > rest of this discussion. > > What can we do in the timescale of an F8 release to make using the > rescue mode easier and more obvious course of action. Are there ways > we can advertise its existence as part of sysadmin interaction with a > normal operating system? Would it be helpful to slip in a rescue > environment as a grub menu option instead of relying on install media? > Does it make sense to spend some effort making a more featurefull > rescue-like environment with guided troubleshooting characteristics? > What are the top three implementable ideas which would encourage > casual admins to reach for the rescue environment instead of a full > wipe and re-install? > Tangentially related to this, I think the guidance available via the function keys before booting the kernel could do with a lot more detail about (for instance) kernel parameters. A more detailed introduction to rescue mode would also be helpful From gmaxwell at gmail.com Fri Feb 23 01:25:33 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 22 Feb 2007 20:25:33 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172189014.3743.154.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> Message-ID: On 2/22/07, Lyvim Xaphir wrote: [snip] > Currently the trend with the > Cox's of the world is to abolish the rights of companies and individuals > to protect their own intellectual property rights; at any cost. [snip] Please take your drivel someplace other than my mailbox. I'm sure you will take this as a horrible affront to your right to spew bullshit. But rest assured that just as Alan doesn't care if you choose to wear shackles in private, I don't get a heck about what you do when it doesn't impact me. [snip] > The ONLY thing that has stopped this process.....and I do mean the > ONLY thing, is Linus Torvalds. He has made it clear that the Linux > kernel will NOT be turned into an ideological tool For his next feat of magic perhaps he will somehow make ESR (and apparently you too) less of a tool. ... But I suspect that would be asking too much. Thanks. From zaitcev at redhat.com Fri Feb 23 01:34:45 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 22 Feb 2007 17:34:45 -0800 Subject: a question about the .spec file In-Reply-To: References: <20070221172943.d659109a.zaitcev@redhat.com> <45DD0209.3090807@BitWagon.com> Message-ID: <20070222173445.b4a41822.zaitcev@redhat.com> On Thu, 22 Feb 2007 18:17:44 -0500, "Chris Taylor" wrote: > So basically this is how to recreate the problem: > install the srpm for kernel-2.6.18 > build the rpm from source > install the 2.6.18 rpm > install the srpm for kernel-2.6.19 > build the rpm from source > watch all config files applied (2.6.18 and 2.6.19) I do "rm rpms/SOURCES/*" before the "install the srpm for ..." step. My ~/.rpmmacros is this: %_topdir /q/zaitcev/rpms %_packager Pete Zaitcev Some run Mike Harris' .rpmmacros, which allows to preserve sets of sources: %_topdir /q/zaitcev/rpms %_packager Pete Zaitcev %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} %_specdir %{_sourcedir} In that case, "rm -rf rpms/SOURCES/kernel-whatever" is the answer. But the main point is to do the cleanup before installing an SRPM, not once you're done playing. You'll never remember doing the cleanup if you postpone it. -- Pete From lists at ralii.com Fri Feb 23 02:36:58 2007 From: lists at ralii.com (Robert Locke) Date: Thu, 22 Feb 2007 21:36:58 -0500 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <16de708d0702221432m578a1889ye344f61cf665588a@mail.gmail.com> References: <16de708d0702221432m578a1889ye344f61cf665588a@mail.gmail.com> Message-ID: <1172198218.3456.81.camel@localhost.localdomain> On Thu, 2007-02-22 at 16:32 -0600, Arthur Pemberton wrote: > Well I'm not sure how many of you all have seen this: > http://linux.slashdot.org/article.pl?sid=07/02/22/207231 > > And this may or may not be the correct -list for this, but here goes. > I think its fair to say that a lot of the louder voices on the > internet do not like Fedora for fair and unfair reasons. My question > is what does this do to Fedora, and RedHat by association. I can't > imagine that anything good is coming of this. All the developers here > are bound by the 24hr daily limit, ie. there is a finite amount of > work that any developer can accomplish, esp. those not being paid to > work on Fedora. Making the assumption that all these negative word of > mouth is bleeding Fedora of contributors, then what's the plan? > > A few loyalist bound by the laws of Physics can only accomplish so > much, and I'm even more worried that the bad karma trickles down to > RedHat, who I believe is the Cinderella of the Linux community - one > day I hope to be in the position to purchase RHEL licenses, but I'm > becoming worried that it may not be around by time I get there. > > Peace > The sky is falling, the sky is falling.... I think you misunderstand how open source works..... The bulk of what is available in Fedora is all managed "upstream" in the individual projects and simply bundled into Fedora. The things that are perhaps unique to Fedora are being contributed to by people who are unlikely to be swayed by the rumblings of esr and the like. Those that contribute to the upstream projects will continue to do so whether they are doing it from a Fedora system or an Ubuntu system or a RHEL system or a CentOS system or a Debian system or an openSuse system. I think you get the point. What's the difference? The point of OPEN SOURCE is one of choice. It is, in fact, not a good thing for everyone to be using RHEL and Fedora. These two distributions are providing very SPECIFIC capabilities for very SPECIFIC subsets of the Linux space. The beauty of RHEL is being able, as an organization relying on a Linux server, to call a company that employs many of the developers and provides superior support (according to any of the software support surveys done over the last few years). The fee is for the support. No one provides better corporate level support than Red Hat in the Linux space. The beauty of Fedora is to provide me, as someone who relies on Red Hat for my corporate Linux machines, to experience where much of this technology might be going. Let's face it, I learn more when stuff occasionally breaks. I got to see SELinux grow in Fedora before it found it's way into RHEL. I got to see NetworkManager grow a bit recently before being included in RHEL. We have seen yum grow a bit before it finds it's way into RHEL5 (if one is to believe the beta). And the list goes on.... I have always seen Fedora as a leading edge, closely following upstream distribution that is ideal for people in the Red Hat sphere of Linux. Ideal for people who support RHEL or CentOS on their servers. Ideal for contributors to the Red Hat universe. Ideal for the "enthusiasts" of Linux and true Open Source. The desire for stability in Fedora is certainly to be explored but not when we sacrifice forward progress. In theory forward progress includes "better software". The point of "choice" is to allow individual distributions to focus on different aspects and offer a unique perspective. For most of us in Fedora, I think adhering to our "principles" of "free and open" is more important than being the "choice" of those abandoning Windows.... I do not think compromising our principles solves the problem of "closed-source" just to get them on to Fedora. Is everything ideal? No way. Are there things that still need to be done? Of course. Do threads like this and the others over the last couple of days (ignoring the name calling and politicking) offer potential for self-examination and improvement? Sure. Is Fedora the perfect distribution for everyone? I hope not. Can it be? No. I do not think you have to worry about whether or not RHEL will be around when you can finally afford that support contract.... --Rob From notting at redhat.com Fri Feb 23 02:34:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Feb 2007 21:34:52 -0500 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <1172185093.13830.61.camel@cutter> References: <200702201758.15925.jkeating@redhat.com> <1172180789.3033.7.camel@sb-home.lan> <1172184980.27976.31.camel@localhost.localdomain> <1172185093.13830.61.camel@cutter> Message-ID: <20070223023452.GA18943@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > > Yeah, "Classic" is my fault. Sorry about that. I hope it doesn't stick > > around forever. > > Should we call it Pepsi? New Fedora. Fedora Tab! Bill From chtaylo4 at gmail.com Fri Feb 23 02:50:13 2007 From: chtaylo4 at gmail.com (Chris Taylor) Date: Thu, 22 Feb 2007 21:50:13 -0500 Subject: a question about the .spec file In-Reply-To: <20070222173445.b4a41822.zaitcev@redhat.com> References: <20070221172943.d659109a.zaitcev@redhat.com> <45DD0209.3090807@BitWagon.com> <20070222173445.b4a41822.zaitcev@redhat.com> Message-ID: Pete, OK, I see what you're saying .... really /SOURCES/ shouldn't be just a generic dumping ground. I agree, it seems a lot cleaner under /SOURCES/kernel-2.6.19 or whatever.... stupid question time .... why don't src.rpms place them accordingly? or is that they whole purpose of Mike Harris' .rpmmacros? Respectfully, Christopher Taylor P.S. I sent this to the author alone originally, my apologies to Pete ... gmail doesn't handle lists well like that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Fri Feb 23 03:09:42 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 Feb 2007 18:09:42 -0900 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <20070223023452.GA18943@nostromo.devel.redhat.com> References: <200702201758.15925.jkeating@redhat.com> <1172180789.3033.7.camel@sb-home.lan> <1172184980.27976.31.camel@localhost.localdomain> <1172185093.13830.61.camel@cutter> <20070223023452.GA18943@nostromo.devel.redhat.com> Message-ID: <604aa7910702221909l75ae7bbbobd662a7f95f7b17@mail.gmail.com> On 2/22/07, Bill Nottingham wrote: > Fedora Tab! Fedora the Un-Desktop -jef From gilboad at gmail.com Fri Feb 23 03:58:21 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 23 Feb 2007 05:58:21 +0200 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> Message-ID: <1172203101.8388.12.camel@gilboa-home-dev.localdomain> On Thu, 2007-02-22 at 19:46 +0100, Benny Amorsen wrote: > >>>>> "FA" == Florin Andrei writes: > > FA> If I'm not mistaken, yum seems fairly unique in this regard. > > FA> I mean, heck, look at Microsoft for example. Their update thing > FA> applies as many patches as possible, and those that cannot be > FA> applied, well duh, they don't get applied and the user is notified > FA> by big honking red icons that something failed. > > Yum just doesn't follow the Unix commandline tradition. Unix commands > should succeed quietly, and only show output if it is something the > user asks for. They don't ask whether you really mean it when you tell > them to do something -- heck even cp needs -i to ask whether you want > to clobber a file, and that one is AFAIK a GNUism. They don't block > SIGINT except when absolutely needed, and then only for a short time. Aya. Blocking SIGINT is one of my "favorites". Having to Ctrl-Z + kill -9 %% every time I need to kill yum is -very- annoying. (Ignoring, for a second, that lack of consistency with other command line application. > > Yum's interface is made for a GUI, where all this interactivity makes > sense. The default should be to do exactly what the user asked, unless > it is impossible. That is, it should take an extra switch to let it > upgrade even when there are broken dependencies, but that extra switch > should not be -y. -y is almost as bad as --force for rpm. There should > probably be a switches to stop yum from upgrading or removing packages > when doing an install. > Add -i and --progress switches to get back the current behaviour, if > people can't live without it. The --progress thing would actually make > sense, if package fetching is slow sometimes. > --skip upgrade should be enabled by default. Yum should show up a list of packages that are about to upgraded, and more importantly, packages that are skipped. (With an option to see why package X has been skipped) Did I mention that Ctrl-C should be kill yum and -not- switch mirrors??!?!??! > > /Benny > > (Sorry for the gripe. Yum is a godsend, it is just the interface which > is a pain) > > From gilboad at gmail.com Fri Feb 23 04:07:25 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 23 Feb 2007 06:07:25 +0200 Subject: Goodbye, Fedora In-Reply-To: <20070221080350.3711A3C1AC6@snark.thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> Message-ID: <1172203645.8388.18.camel@gilboa-home-dev.localdomain> On Wed, 2007-02-21 at 03:03 -0500, Eric S. Raymond wrote: [snip, snip, snip] Am I the only one that finds ESR's post even more amusing now that Microsoft lost a 1.52B$ patent case against Alcatel-Lucent concerning the use of MP3 technology in WMP? [1] - Gilboa [1] http://www.dailytech.com/article.aspx?newsid=6198 From pmr at pajato.com Thu Feb 22 18:45:10 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Thu, 22 Feb 2007 13:45:10 -0500 Subject: Core values In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> <20070221213009.GC12834@redhat.com> <66i0b4-6ah.ln1@sky.matrix> <16de708d0702220937l37bfcdfeid283a7f67f1b245@mail.gmail.com> Message-ID: <45DDE4B6.3020909@pajato.com> Thomas M Steenholdt wrote: > Arthur Pemberton wrote: >> On 2/22/07, Thomas M Steenholdt wrote: >>> Keith G. Robertson-Turner wrote: >>> > Verily I say unto thee, that Dave Jones spake thusly: >>> >> On Wed, Feb 21, 2007 at 03:30:08PM -0500, Eric S. Raymond wrote: >>> >> >>> >> > The Ubuntu crowd gets this. The Fedora crowd doesn't. That >>> difference is >>> >> > nowhere near the only reason I'm gone, but it's a big one. >>> >> >>> >> Didn't you leave already? >>> > >>> > I don't think he's generated enough publicity for Ubuntu/Linspire >>> yet, >>> > to justify his paycheck. >>> > >>> >>> Color me old-fashioned, but isn't now a good time to stop the mud >>> slinging contest?!? I really doubt anything constructive will ever come >>> from that. >>> >>> /Thomas >> >> To which mudslinging do you refer to exactly? > > Mudslinging, name-calling and negatively worded posts, without a real > value to the debate, in general... > > Who cares who's paid for what and by whom. Some possible areas of > improvement was brought up. Perhaps we can use some that as valuable > input to improve Fedora, perhaps not. So we should all filter the > input to end up with something we can use constructively, rather than > to keep "feeding the fire". > > I'm all for the debate, but some of the posts are just not > constructive at all. So lets try to focus on what we can use the input > for, rather than spending a lot of time getting all worked up. You are to be praised for this post. In a thread filled with way too much venom, way too much arrogance, there have been too few who, like you, seem to possess reason and sense. Maybe Eric does have some points. Maybe Fedora can be better because of his rant. But most important of all, he has every right to speak his mind, as do all the naysayers. I have been there. Fedora in general and Rawhide in particular drives me nuts. I am not as technically astute as many on this list. But I'd sure like to be. So I hang in there. And I'd like to help make Fedora better than it is. Because of what you said, I will look for an opportunity to help you. Thank you, Thomas. -pmr > > /Thomas > From pmr at pajato.com Thu Feb 22 19:19:06 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Thu, 22 Feb 2007 14:19:06 -0500 Subject: FC6 to Rawhide via repo switch Message-ID: <45DDECAA.8080100@pajato.com> I recently got my system wedged without having good notes about what happened. So I figured that the simplest path to getting back to a running Rawhide was to install minimally FC6 and change the repos to select development (should extras development be enabled?) and then do an update. I did that and midway through the 1000+ package update the system rebooted leaving me scratching my head wondering if I should distrust this approach or just reboot and try again with another update and hope for the best. I did the latter and have been beset by weird behavior ever since. Like checkbox buttons not echoing properly on GUIs and non elf format conflicts in some bin programs and libraries. In any case, if it will help to perform that FC6->Rawhide update in a more controlled fashion, I will do so, but only if somebody in particular cares or will define what constraints and expectations are relevant. Doing this at random does seem fraught with the risk of doing so right about the time some normal Rawhide breakage has been unleashed. Left to my own devices I'll start with a less risky approach to getting to a running Rawhide that I feel is sufficiently "correct" to file bug reports against. To that end I'm open to suggestion, especially references. Thanks, -pmr From kevin.kofler at chello.at Fri Feb 23 04:26:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Feb 2007 04:26:35 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles References: <20070222225108.693e5e73@localhost.localdomain> Message-ID: Sebastian Vahl deadbabylon.de> writes: > > Note that I don't know if the kde4.desktop in /usr/share/xsessions > > actually does anything useful, > > Only crashes the login under 10 seconds. :) This is probably the klauncher crash Aaron J. Seigo just fixed: http://websvn.kde.org/trunk/KDE/kdelibs/kinit/klauncher_main.cpp?r1=628269&r2=636337 ("need to provide a name to the app here so it doesn't hit an assert and die"). I'll backport that into my next kdelibs4 spin. Kevin Kofler From pertusus at free.fr Fri Feb 23 07:58:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 23 Feb 2007 08:58:44 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172189014.3743.154.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> Message-ID: <20070223075524.GA3037@free.fr> On Thu, Feb 22, 2007 at 07:03:34PM -0500, Lyvim Xaphir wrote: > > There needs to be a balance between the right of individuals to own > their own property (specifically in our realm of discussion, > intellectual property) and the right of individuals to control the > source to the operating system they run. Currently the trend with the > Cox's of the world is to abolish the rights of companies and individuals > to protect their own intellectual property rights; at any cost. The > plain simple definition of socialism is the abolition of personal > property to another jurisdiction other than the true owner of that > personal property; be that a dictator or a government, or a group of > socio-fascist developers. In this case, the developers seek to take the > decision about intellectual property rights OUT of the public domain > (the "Market") and to FORCIBLY TAKE AWAY the right of the company or > individual to license driver-code the way the code authors see fit. > This is not "freedom", it is in reality a form of slavery. Intellectual properties (be it art, code, knowledge) are not like other properties/goods. They are "non rival goods"; it means that a representation, an idea, a piece of code can be reused at infinity by the same or another person without being consumed. To maximize the utility the non rival goods should be freely available once produced. So it is logical to have some regulation on the property rights of this kind of goods. If those goods are available freely then individuals don't have a financiary incentive to produce them, therefore some may be protected by some rights (patents). Also one may consider that the producer right to define the rights on his production is above considerations of welfare maximization, that's the case with artistic productions, at least to a temporal extent (before they go in the public domain). Currently ideas cannot be protected, ie they are always public domain, code and art are automatically protected (there is the fair use exception for art) and it is the author who chose the license, and inventions may be patented for a given duration of time in a strictly regulated environment. Even in the US intellectual property rights are heavily regulated. Public good like software is a special case of an externality, and even in a capitalist society it may be worth regulating them, even if the regulation is only through the definition of rights that can become part of a market. I haven't read it, but I guess the wikipedia page has some interesting information: http://en.wikipedia.org/wiki/Externality By the way socialism (as an economic system opposed to capitalism) is not defined by a state that owns all the properties, but the state owns the capital of the firms and makes the decisions about investment and production, instead of the capital owners in a capitalist society. -- Pat From fedora at camperquake.de Fri Feb 23 08:12:55 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 23 Feb 2007 09:12:55 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172203101.8388.12.camel@gilboa-home-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> Message-ID: <20070223091255.1bec8fee@banea.int.addix.net> Hi. On Fri, 23 Feb 2007 05:58:21 +0200, Gilboa Davara wrote: > Did I mention that Ctrl-C should be kill yum and -not- switch > mirrors??!?!??! That is actually useful. Typing it twice or thrice should kill yum, however, at least it did some time ago. From rc040203 at freenet.de Fri Feb 23 09:17:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 23 Feb 2007 10:17:23 +0100 Subject: FC6 updates broken deps? In-Reply-To: <20070223091255.1bec8fee@banea.int.addix.net> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> Message-ID: <1172222243.23237.405.camel@mccallum.corsepiu.local> On Fri, 2007-02-23 at 09:12 +0100, Ralf Ertzinger wrote: > Hi. > > On Fri, 23 Feb 2007 05:58:21 +0200, Gilboa Davara wrote: > > > Did I mention that Ctrl-C should be kill yum and -not- switch > > mirrors??!?!??! > > That is actually useful. I disagree - All programs should immediately terminate upon "Ctrl-C". Switching to a different mirror should be done by any arbitrary key. Ralf From fedora at camperquake.de Fri Feb 23 09:24:20 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 23 Feb 2007 10:24:20 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172222243.23237.405.camel@mccallum.corsepiu.local> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> Message-ID: <20070223102420.2e298618@banea.int.addix.net> Hi. On Fri, 23 Feb 2007 10:17:23 +0100, Ralf Corsepius wrote: > > That is actually useful. > I disagree - All programs should immediately terminate upon "Ctrl-C". > > Switching to a different mirror should be done by any arbitrary key. Oh, you can move that to a different key for all I care (SIGINT?), as long as the functionality itself is there. From knightmerc at yahoo.com Fri Feb 23 09:39:16 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Fri, 23 Feb 2007 04:39:16 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <20070223075524.GA3037@free.fr> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> Message-ID: <1172223556.3743.257.camel@localhost.localdomain> On Fri, 2007-02-23 at 08:58 +0100, Patrice Dumas wrote: > On Thu, Feb 22, 2007 at 07:03:34PM -0500, Lyvim Xaphir wrote: > > > > There needs to be a balance between the right of individuals to own > > their own property (specifically in our realm of discussion, > > intellectual property) and the right of individuals to control the > > source to the operating system they run. Currently the trend with the > > Cox's of the world is to abolish the rights of companies and individuals > > to protect their own intellectual property rights; at any cost. The > > plain simple definition of socialism is the abolition of personal > > property to another jurisdiction other than the true owner of that > > personal property; be that a dictator or a government, or a group of > > socio-fascist developers. In this case, the developers seek to take the > > decision about intellectual property rights OUT of the public domain > > (the "Market") and to FORCIBLY TAKE AWAY the right of the company or > > individual to license driver-code the way the code authors see fit. > > This is not "freedom", it is in reality a form of slavery. > > Intellectual properties (be it art, code, knowledge) are not like other > properties/goods. They are "non rival goods"; it means that a > representation, an idea, a piece of code can be reused at infinity by > the same or another person without being consumed. To maximize the > utility the non rival goods should be freely available once produced. NOT if the intellectual property was produced by work that was not freely given. If the programmer creates original product (IP) thru his/her own effort and work, then that person has the right to the fruits of that labor. This is basic and not hard to understand. Intellectual property can be re-categorized and pidgeonholed at your leisure, but the real right and wrong truth still and always will exist; namely that the person or company that worked for and invested in the R&D deserves the benefits. When those benefits are taken away forcibly, it is still theft, and today's laws recognize that fact for the most part. You cannot divorce the idea from the credit deserved by the person who originated the idea, no matter how much sophistry is applied. If the ideas are freely given away, that's another case entirely, but that's not what I'm talking about here. I'm talking about forced licensing by monopolistic power outside the market. > So it is logical to have some regulation on the property rights of this > kind of goods. Which I agree with in principle, with that statement taken by itself; but you are discussing a different type of regulation. The situation I'm concerned with is when the programmer wishes to profit from his work; which is a form of regulation, but again I don't think that's what you mean here. My point is that if the person originates the work, then they automatically have the rights to that work, and as such they also have the intrinsic right to license it any way they like. It's their work. It's their right. This right is forcibly taken from them in the case of forced licensing, which is presently occurring within the context of a false-freedom ideology. > If those goods are available freely then individuals > don't have a financiary incentive to produce them, therefore some > may be protected by some rights (patents). Also one may consider that > the producer right to define the rights on his production is above > considerations of welfare maximization, that's the case with > artistic productions, at least to a temporal extent (before they go in > the public domain). > > Currently ideas cannot be protected, This is your view and in my view it's false. There are consequences today for stealing intellectual property and many people have felt the legal brunt of those consequences. I don't agree with things like the DMCA, I think that the old copyright laws were perfectly OK before liberal lobbyists got the law situation bastardized. But at the same time I'm not going to sit back and watch an ivory tower circle jerk sell doe-eyed idealists a "freedom" package that's designed to steal their freedom. The authors should decide what to do with their own work. NOT ANYBODY ELSE. LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From davehoz at gmail.com Fri Feb 23 09:39:31 2007 From: davehoz at gmail.com (David Hunter) Date: Fri, 23 Feb 2007 20:39:31 +1100 Subject: DVD only for Fedora "Classic" spin? In-Reply-To: <200702201758.15925.jkeating@redhat.com> References: <200702201758.15925.jkeating@redhat.com> Message-ID: <6bb886180702230139p78020eaftc7efea9b6bdc6226@mail.gmail.com> Oh no - I?ve got an older machine and it can?t boot DVD?s an excuse to upgrade I guess. On 21/02/07, Jesse Keating wrote: > > For Test2, I'm planning on doing the Fedora "Classic" spin for folks to > work > with. Doing the Everything spin at this point is just going to take up a > LOT > of bandwidth / space for such a temporary thing. I do believe we'll have > a > Desktop (Gnome) LiveCD as well, perhaps a KDE one if the KDE folks kick > some > butt. > > That said, we've toyed with the idea of doing DVD iso only for the Classic > (and Everything) spin. Easy enough for me to do in pungi, I'll just set > the > cd size to 4.5G and produce one iso. > > So, how much hate will be thrown my way if we just do a DVD sized iso for > Test2's Classic spin? > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at poolshark.org Fri Feb 23 09:54:18 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 23 Feb 2007 10:54:18 +0100 Subject: FC6 updates broken deps? In-Reply-To: <20070223005105.GA31821@jadzia.bu.edu> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> <45DE229D.4010306@poolshark.org> <20070223005105.GA31821@jadzia.bu.edu> Message-ID: <45DEB9CA.60805@poolshark.org> Matthew Miller wrote: > On Fri, Feb 23, 2007 at 12:09:17AM +0100, Denis Leroy wrote: >>> I don't think lumping them into the yum rpm is a good approach from a >>> system maintenance perspective. >> I actually meant integrated into yum. For the same reasons we want >> kernel RPMs to be pushed upstream. The idea here is to have more people >> contribute to yum. > > But all these things are already in yum-utils. I love yum-utils, but I was talking about all the yum plugins packages out there : # yum list | grep ^yum- | wc -l 17 From knightmerc at yahoo.com Fri Feb 23 10:21:59 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Fri, 23 Feb 2007 05:21:59 -0500 Subject: Goodbye, Fedora In-Reply-To: <200702210845.07064.tbrinkman@sbcglobal.net> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC4E84.5020602@poolshark.org> <1172066476.9201.36.camel@gilboa-work-dev.localdomain> <200702210845.07064.tbrinkman@sbcglobal.net> Message-ID: <1172226119.5995.7.camel@localhost.localdomain> On Wed, 2007-02-21 at 08:45 -0600, Tom Brinkman wrote: > On Wednesday 21 February 2007, Gilboa Davara wrote: > > On Wed, 2007-02-21 at 14:52 +0100, Denis Leroy wrote: > > > Lyvim Xaphir wrote: > > > > And it's the toy-hat dictators and the toy-hat fascists that > > > > are pushing him out the door. Socialism was the mother of > > > > both fascism and communism, and it's the same thing that's > > > > destroying Fedora, thanks in part to you. > > > > > > Godwin's Law achieved! In a record-breaking 5 hours! > > > > Somehow I doubt that the neither OP nor the troll above have any > > idea what Godwin's Law is, nor do they seem to care. > > > > Time to make fedora-devel developers/maintainers/etc only? > > > > - Gilboa > > 'etc' should include those who actually run fc6-test and/or > f7-rawhide. LX uses neither (fc5-unity). And now you're an LXpert? You're in a Texas trailer park several states away but yet you know what I have here? 2.6.19-1.2911.fc6 is running on my primary workstation not including my five other test boxes. LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From knightmerc at yahoo.com Fri Feb 23 10:27:04 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Fri, 23 Feb 2007 05:27:04 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> Message-ID: <1172226424.5995.13.camel@localhost.localdomain> On Thu, 2007-02-22 at 20:25 -0500, Gregory Maxwell wrote: > On 2/22/07, Lyvim Xaphir wrote: > [snip] > > Currently the trend with the > > Cox's of the world is to abolish the rights of companies and individuals > > to protect their own intellectual property rights; at any cost. > [snip] > > Please take your drivel someplace other than my mailbox. Sorry but I don't control what you send out, so if you want the drivel out of your box you need to stop authoring email that you will get back. *******snip...eh, drivel************** LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From pertusus at free.fr Fri Feb 23 10:46:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 23 Feb 2007 11:46:06 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172223556.3743.257.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> Message-ID: <20070223104606.GA2838@free.fr> On Fri, Feb 23, 2007 at 04:39:16AM -0500, Lyvim Xaphir wrote: > > NOT if the intellectual property was produced by work that was not > freely given. If the programmer creates original product (IP) thru > his/her own effort and work, then that person has the right to the > fruits of that labor. This is basic and not hard to understand. The fact that freely available non rival goods maximize welfare is also easy to understand. So here there is clearly a possible opposition on normative issues. The political/ideological issue is on how to balance the freedom to license against welfare maximisation since both principles are antagonist in the case of non rival goods. > Which I agree with in principle, with that statement taken by itself; > but you are discussing a different type of regulation. The situation > I'm concerned with is when the programmer wishes to profit from his > work; which is a form of regulation, but again I don't think that's what > you mean here. Indeed, what I call regulation here is what is commonly understood in the field of social choice economy. It is the action of a collective body to set rules. > My point is that if the person originates the work, then they > automatically have the rights to that work, and as such they also have > the intrinsic right to license it any way they like. It's their work. > It's their right. This right is forcibly taken from them in the case of > forced licensing, which is presently occurring within the context of a > false-freedom ideology. You are saying that freedom to keep rights on intelectual production is the highest principle (above welfare maximization, at least). That's a view, but other people may disagree. I am not stating my personnal view here, just explaining that a way to understand this opposition is to state it that way. > > Currently ideas cannot be protected, > > > This is your view and in my view it's false. There are consequences > today for stealing intellectual property and many people have felt the > legal brunt of those consequences. I don't agree with things like the Ideas, knowledge cannot be protected. Reusing knowledge and ideas cannot be prosecuted. The fields of intellectual property are innovation (through patents), trademark, copyright (for art and software representations), commercial secrets. Exceptions are entering now and then (like genetic codes, software patents that may protect some ideas that are not really innovations, informations stored in database), but basically all you read in a book cannot be protected by the book author. The copyright protects the wording, not the ideas. -- Pat From alan at redhat.com Fri Feb 23 11:00:45 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 23 Feb 2007 06:00:45 -0500 Subject: FC6 updates broken deps? In-Reply-To: <1172222243.23237.405.camel@mccallum.corsepiu.local> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> Message-ID: <20070223110045.GB29094@devserv.devel.redhat.com> On Fri, Feb 23, 2007 at 10:17:23AM +0100, Ralf Corsepius wrote: > I disagree - All programs should immediately terminate upon "Ctrl-C". > Switching to a different mirror should be done by any arbitrary key. Someone please fix emacs to terminate immediately on ctrl-C then ;) Very large numbers of programs override ^C to be an internal interrupt, including things like ftp. Others specifically ignore it (try using ssh without that) From tmus at tmus.dk Fri Feb 23 10:16:38 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 23 Feb 2007 11:16:38 +0100 Subject: Goodbye, Fedora In-Reply-To: <1172203645.8388.18.camel@gilboa-home-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> Message-ID: Gilboa Davara wrote: > On Wed, 2007-02-21 at 03:03 -0500, Eric S. Raymond wrote: > [snip, snip, snip] > > Am I the only one that finds ESR's post even more amusing now that > Microsoft lost a 1.52B$ patent case against Alcatel-Lucent concerning > the use of MP3 technology in WMP? [1] > > - Gilboa > [1] http://www.dailytech.com/article.aspx?newsid=6198 > > Amusing or not, it does confirm that our current policy of keeping all the proprietary stuff away from Fedora, is really for the best. Even if users have to pull those packages from 3rd party repos. /Thomas From buildsys at redhat.com Fri Feb 23 11:24:11 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 23 Feb 2007 06:24:11 -0500 Subject: rawhide report: 20070223 changes Message-ID: <200702231124.l1NBOBSB011639@hs20-bc2-6.build.redhat.com> Updated Packages: fedora-logos-6.0.92-4.fc7 ------------------------- * Thu Feb 22 2007 Jeremy Katz - 6.0.92-4 - resave the syslinux splash so that it works (lalalala....) * Thu Feb 22 2007 Matthias Clasen - 6.0.92-3 - Improve the branded lock dialog * Wed Feb 21 2007 Matthias Clasen - 6.0.92-2 - Some more new images kernel-2.6.20-1.2940.fc7 ------------------------ * Wed Feb 21 2007 Kristian H??gsberg - Rediff firewire patch, include fixes for #228017. * Wed Feb 21 2007 Dave Jones - 2.6.21-rc1 libtool-1.5.22-10 ----------------- * Wed Feb 21 2007 Karsten Hopp 1.5.22-10 - fix libtool-ltdl post/postun requirements Broken deps for ia64 ---------------------------------------------------------- pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 11:55:40 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 12:55:40 +0100 Subject: FC6 updates broken deps? In-Reply-To: <20070223091255.1bec8fee@banea.int.addix.net> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> Message-ID: <20070223125540.1384bc91.mschwendt.tmp0701.nospam@arcor.de> On Fri, 23 Feb 2007 09:12:55 +0100, Ralf Ertzinger wrote: > Hi. > > On Fri, 23 Feb 2007 05:58:21 +0200, Gilboa Davara wrote: > > > Did I mention that Ctrl-C should be kill yum and -not- switch > > mirrors??!?!??! > > That is actually useful. Typing it twice or thrice should kill > yum, however, at least it did some time ago. A common scenario for newbies, which make you bow your head in shame: You had thought they would prefer the graphical package tools, you have not recommended the command-line, but they know Google and have found lots of documentation about how to install something with Yum. And what happens? Metadata checksum failures on apparently all mirrors. ^C doesn't help. Yum switches through all available mirrors. WTF? Some time later, 78 updates are available. Newbie is caught in a loop of download failures, mirror-switching, ^C attempts, low through-put, and reacts very surprised and disappointed about "this Linux stuff". From mattdm at mattdm.org Fri Feb 23 11:56:42 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Feb 2007 06:56:42 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45DEB9CA.60805@poolshark.org> References: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> <45DE229D.4010306@poolshark.org> <20070223005105.GA31821@jadzia.bu.edu> <45DEB9CA.60805@poolshark.org> Message-ID: <20070223115642.GA13939@jadzia.bu.edu> On Fri, Feb 23, 2007 at 10:54:18AM +0100, Denis Leroy wrote: > >But all these things are already in yum-utils. > I love yum-utils, but I was talking about all the yum plugins packages > out there : > # yum list | grep ^yum- | wc -l > 17 $ rpm -q --qf '%{sourcerpm}\n' yum-skip-broken yum-utils-1.1.1-1.fc7.src.rpm -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Fri Feb 23 12:15:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Feb 2007 13:15:54 +0100 Subject: keeping all he proprietary stuff away from Fedora (Was: Re: Goodbye, Fedora) In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> Message-ID: <45DEDAFA.1070806@leemhuis.info> On 23.02.2007 11:16, Thomas M Steenholdt wrote: > Gilboa Davara wrote: >> On Wed, 2007-02-21 at 03:03 -0500, Eric S. Raymond wrote: >> [snip, snip, snip] >> Am I the only one that finds ESR's post even more amusing now that >> Microsoft lost a 1.52B$ patent case against Alcatel-Lucent concerning >> the use of MP3 technology in WMP? [1] >> - Gilboa >> [1] http://www.dailytech.com/article.aspx?newsid=6198 > Amusing or not, it does confirm that our current policy of keeping all > the proprietary stuff away from Fedora, is really for the best. Even if > users have to pull those packages from 3rd party repos. Agreed. Nevertheless it IMHO would be helpful, - if we had one major 3rd party repo instead of multiple ones that are conflicting with each other sometimes - if that 3rd party repo would have be slitted in non-free stuff and potential harmful stuff, so users and contributors from the US and some other country's can safely work with the non-free repo without getting involved with the more problematic stuff - if we had some kind backing for a non-free repo from Red Hat or some other "Big Company" when it comes to knocking of doors to ask questions like "Hi Adobe, may we include a Adobe Reader RPM in the non-free community repo foo? They would do some some minor adjustments to the RPM to make it perfectly work with Fedora; that best for both sides" Just my 2 cent. CU thl From mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 12:35:17 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 13:35:17 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> Message-ID: <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> On Thu, 22 Feb 2007 14:40:54 -0900, Jeff Spaleta wrote: > On 2/22/07, Arthur Pemberton wrote: > > And this may or may not be the correct -list for this, but here goes. > > I think its fair to say that a lot of the louder voices on the > > internet do not like Fedora for fair and unfair reasons. My question > > is what does this do to Fedora, and RedHat by association. I can't > > imagine that anything good is coming of this. All the developers here > > are bound by the 24hr daily limit, ie. there is a finite amount of > > work that any developer can accomplish, esp. those not being paid to > > work on Fedora. Making the assumption that all these negative word of > > mouth is bleeding Fedora of contributors, then what's the plan? > > First I'd stop making unfounded assumptions about how the contributor > numbers are falling. Still, the merge of Core+Extras will put the Fedora Project at a test. There are several issues I still don't understand and which sometimes make me shake my head in disbelief. For instance, but not limited to: * heavy use of Red Hat internal mailing-lists for Fedora related matters, * weird procedures by which Red Hat's Fedora Core package owners need sponsorship for cvs_extras and either get blanket approval or are really "sponsored" by community contributors without that the sponsors' responsibilities and duties are documented, * more closed circles, in which decisions are made -- including mysteries like brew, koji, and code transfer for the new Updates System, * unclear role of FESCo, not enough steering -- instead: the drive that "you don't need to be in FESCo to get something done", * the community used to have full control over Extras -- this control is lost, instead: even sponsors would need to ask their sponsorees for permission before they could fix or veto anything in CVS, * changes to infrastructure and policies/guidelines, respectively, without prior communication, * annoying cross-posts due to an overly complex and unclear choice of mailing-lists -- still: the feeling that some lists are missing, because vital communication and coordination (e.g. about things done in Core) is missing. From mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 12:47:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 13:47:28 +0100 Subject: keeping all he proprietary stuff away from Fedora (Was: Re: Goodbye, Fedora) In-Reply-To: <45DEDAFA.1070806@leemhuis.info> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> <45DEDAFA.1070806@leemhuis.info> Message-ID: <20070223134728.68e5c8af.mschwendt.tmp0701.nospam@arcor.de> On Fri, 23 Feb 2007 13:15:54 +0100, Thorsten Leemhuis wrote: > - if we had some kind backing for a non-free repo from Red Hat or some > other "Big Company" when it comes to knocking of doors to ask questions > like "Hi Adobe, may we include a Adobe Reader RPM in the non-free > community repo foo? They would do some some minor adjustments to the RPM > to make it perfectly work with Fedora; that best for both sides" ?? Contradictory. It's closed-source. Basically, you don't want to include it in that repo at all. From fedora at leemhuis.info Fri Feb 23 12:57:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Feb 2007 13:57:21 +0100 Subject: keeping all he proprietary stuff away from Fedora (Was: Re: Goodbye, Fedora) In-Reply-To: <20070223134728.68e5c8af.mschwendt.tmp0701.nospam@arcor.de> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> <45DEDAFA.1070806@leemhuis.info> <20070223134728.68e5c8af.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45DEE4B1.2030104@leemhuis.info> On 23.02.2007 13:47, Michael Schwendt wrote: > On Fri, 23 Feb 2007 13:15:54 +0100, Thorsten Leemhuis wrote: > >> - if we had some kind backing for a non-free repo from Red Hat or some >> other "Big Company" when it comes to knocking of doors to ask questions >> like "Hi Adobe, may we include a Adobe Reader RPM in the non-free >> community repo foo? They would do some some minor adjustments to the RPM >> to make it perfectly work with Fedora; that best for both sides" > ?? Contradictory. It's closed-source. Basically, you don't want to > include it in that repo at all. Well, or yet another repo (but that might be to confusing) -- that depends on the definition of "non-free" in this case. CU thl From jkeating at redhat.com Fri Feb 23 13:17:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Feb 2007 08:17:36 -0500 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200702230817.39895.jkeating@redhat.com> On Friday 23 February 2007 07:35, Michael Schwendt wrote: > * heavy use of Red Hat internal mailing-lists for Fedora related matters, This is complete BS. Maybe one or three messages a month pop up on internal lists, and those are immediately redirected to external lists. The idea that we have long and involved threads regarding core on some hidden lists is completely false. > * weird procedures by which Red Hat's Fedora Core package owners need > sponsorship for cvs_extras and either get blanket approval or are > really "sponsored" by community contributors without that the > sponsors' responsibilities and duties are documented, Yes, because it is quite difficult to define what is needed for CURRENT maintainers. All our policies are designed around NEW maintainers joining the fold. Many of these RH employees were already in the fold as maintainers. > * more closed circles, in which decisions are made -- including mysteries > like brew, koji, and code transfer for the new Updates System, These decisions were made at the Fedora summit, with the Fedora board and other community folks, complete with an IRC channel during the live discussions. Further discussion has happened in Fedora board meetings and public Fedora lists. > * unclear role of FESCo, not enough steering -- instead: the drive > that "you don't need to be in FESCo to get something done", I don't even know what you mean by this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Fri Feb 23 13:20:33 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 23 Feb 2007 14:20:33 +0100 Subject: FC6 updates broken deps? In-Reply-To: <20070223115642.GA13939@jadzia.bu.edu> References: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> <45DE229D.4010306@poolshark.org> <20070223005105.GA31821@jadzia.bu.edu> <45DEB9CA.60805@poolshark.org> <20070223115642.GA13939@jadzia.bu.edu> Message-ID: <45DEEA21.50007@poolshark.org> Matthew Miller wrote: > On Fri, Feb 23, 2007 at 10:54:18AM +0100, Denis Leroy wrote: >>> But all these things are already in yum-utils. >> I love yum-utils, but I was talking about all the yum plugins packages >> out there : >> # yum list | grep ^yum- | wc -l >> 17 > > $ rpm -q --qf '%{sourcerpm}\n' yum-skip-broken > yum-utils-1.1.1-1.fc7.src.rpm I'm not sure I get your point. Are you saying all the 17 plugins were written by the same person ? My point is: most of the plugins should be part of the core yum package and therefore installed by default on all fedora distros ('installed' not being equal to 'enabled by default'), and people - community members - should be working on making yum better, rather than writing plugins to work around the known yum limitations. From emmanuel.seyman at club-internet.fr Fri Feb 23 13:23:37 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 23 Feb 2007 14:23:37 +0100 Subject: Goodbye, Fedora In-Reply-To: <1172203645.8388.18.camel@gilboa-home-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> Message-ID: <20070223132337.GA6117@orient.maison.lan> * Gilboa Davara [23/02/2007 07:28]: > > Am I the only one that finds ESR's post even more amusing now that > Microsoft lost a 1.52B$ patent case against Alcatel-Lucent concerning > the use of MP3 technology in WMP? [1] Nope. I also find it amusing that the two companies that he claims are "succesful" in marketing Linux are both bleeding money like there's no tomorrow. Emmanuel From piotr.baranowski at altkom.pl Fri Feb 23 13:28:04 2007 From: piotr.baranowski at altkom.pl (Piotr Baranowski) Date: Fri, 23 Feb 2007 14:28:04 +0100 (CET) Subject: FC6 updates broken deps? In-Reply-To: <20070223110045.GB29094@devserv.devel.redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> Message-ID: <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> Alan Cox wrote(a): > On Fri, Feb 23, 2007 at 10:17:23AM +0100, Ralf Corsepius wrote: >> I disagree - All programs should immediately terminate upon "Ctrl-C". >> Switching to a different mirror should be done by any arbitrary key. > > Someone please fix emacs to terminate immediately on ctrl-C then ;) > > Very large numbers of programs override ^C to be an internal interrupt, > including things like ftp. Others specifically ignore it (try using ssh > without that) I think we can accept such weirdness of some applications. Most people will understand WHY ^c is overriden in ssh for example. For me after 10 years of linux experience it was great mistery why a hell does yum override ^c. There is no clear reason for it to behave like that. My suggestion ? ^m and a startup message like: "If you want to switch from one mirror to another press CTRL+M" regards -- Piotr Baranowski - RHCX @ Altkom Akademia S.A. Dlaczego informatycy myl? Halloween z Bo?ym Narodzeniem ? ...bo 31oct==25dec :) From jnovy at redhat.com Fri Feb 23 13:29:26 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 23 Feb 2007 14:29:26 +0100 Subject: AFK till 27th March Message-ID: <1172237366.2385.15.camel@redhat.usu> Hi all, I want to inform you that I'll be AFK till 27th March, starting from tomorrow, because of my trip to Vietnam. Jindrich From kevin.kofler at chello.at Fri Feb 23 13:34:42 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Feb 2007 13:34:42 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles References: Message-ID: Kevin Kofler chello.at> writes: > - error='QLibrary::resolve_sys: Symbol "qt_plugin_instance" undefined > in /usr/lib/qt4/plugins/designer/kdewidgets.so I found the problem: qt4 in FE6 is built without visibility support, KDE 3.80.3 enables visibility support by default. This leads to Q_DECL_EXPORT being empty instead of __attribute__((visibility("default"))), but the plugin being built with -fvisibility=hidden. Thus the symbol doesn't get exported. I'll workaround this in my next KDE 4 build, and also install the plugin properly. I'll upload the SRPMs once this is fixed. Kevin Kofler From tmus at tmus.dk Fri Feb 23 13:37:31 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 23 Feb 2007 14:37:31 +0100 Subject: FC6 updates broken deps? In-Reply-To: <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> Message-ID: Piotr Baranowski wrote: > Alan Cox wrote(a): >> On Fri, Feb 23, 2007 at 10:17:23AM +0100, Ralf Corsepius wrote: >>> I disagree - All programs should immediately terminate upon "Ctrl-C". >>> Switching to a different mirror should be done by any arbitrary key. >> Someone please fix emacs to terminate immediately on ctrl-C then ;) >> >> Very large numbers of programs override ^C to be an internal interrupt, >> including things like ftp. Others specifically ignore it (try using ssh >> without that) > > I think we can accept such weirdness of some applications. > > Most people will understand WHY ^c is overriden in ssh for example. > > For me after 10 years of linux experience it was great mistery why a hell > does yum override ^c. > > There is no clear reason for it to behave like that. > > My suggestion ? > ^m and a startup message like: > > "If you want to switch from one mirror to another press CTRL+M" > > regards > That would probably also help the fact, that (last i checked) ^C does switch mirrors, but it also prevents anything useful from happening at the end of the download process. I.e. yum -y update would download packages, ^C cause it to switch mirrors and keep downloading, but the expected update at the end of the download is skipped. /Thomas From kmaraas at broadpark.no Fri Feb 23 13:50:21 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Fri, 23 Feb 2007 14:50:21 +0100 Subject: F7t2 and QA Meeting In-Reply-To: <20070223005105.GA25845@redhat.com> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> <20070221175105.GG19851@redhat.com> <1172142877.2960.1.camel@rivendell> <20070222204750.GA20999@devserv.devel.redhat.com> <20070223005105.GA25845@redhat.com> Message-ID: <1172238621.4455.1.camel@rivendell> tor, 22.02.2007 kl. 19.51 -0500, skrev Dave Jones: > On Thu, Feb 22, 2007 at 03:47:50PM -0500, Alan Cox wrote: > > On Thu, Feb 22, 2007 at 12:14:37PM +0100, Kjartan Maraas wrote: > > > Are these libata problems the cause of my VIA based laptop not enabling > > > DMA on the IDE attached HD after resume too maybe? > > > > They might get you UDMA33 limited on resume and we seem to have a problem > > with simplex handling which you are eeing and I'm working on which gets you > > stuck in PIO4. > > > > The other problem you have though is > > Feb 5 09:16:08 rivendell kernel: pnp: Device 00:02 activated. > > Feb 5 09:16:08 rivendell kernel: pnp: Failed to activate device 00:05. > > Feb 5 09:16:08 rivendell kernel: pnp: Device 00:0a does not support activation. > > > > Has someone compiled in both PNP BIOS and ACPI. At the moment if you do that > > you get both in use which isn't allowed because the PNPBIOS code doesn't > > disable itself when ACPI is live. > > CONFIG_PNPBIOS has been disabled for a looong time. It blew up on far > too many machines when it was last attempted (FC2 era). > I just updated the bugreport above with dmesg output from a boot/suspend to disk/resume cycle which looks like this: Cheers Kjartan Linux version 2.6.20-1.2940.fc7 (brewbuilder at hs20-bc2-4.build.redhat.com) (gcc version 4.1.2 20070220 (Red Hat 4.1.2-2)) #1 SMP Thu Feb 22 13:11:42 EST 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2 copy_e820_map() start: 00000000000e0000 size: 0000000000020000 end: 0000000000100000 type: 2 copy_e820_map() start: 0000000000100000 size: 000000003ded0000 end: 000000003dfd0000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 000000003dfd0000 size: 0000000000020c00 end: 000000003dff0c00 type: 2 copy_e820_map() start: 000000003dff0c00 size: 000000000000b400 end: 000000003dffc000 type: 4 copy_e820_map() start: 000000003dffc000 size: 0000000000004000 end: 000000003e000000 type: 2 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003dfd0000 (usable) BIOS-e820: 000000003dfd0000 - 000000003dff0c00 (reserved) BIOS-e820: 000000003dff0c00 - 000000003dffc000 (ACPI NVS) BIOS-e820: 000000003dffc000 - 000000003e000000 (reserved) 95MB HIGHMEM available. 896MB LOWMEM available. Using x86 segment limits to approximate NX protection Entering add_active_range(0, 0, 253904) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem 229376 -> 253904 early_node_map[1] active PFN ranges 0: 0 -> 253904 On node 0 totalpages: 253904 DMA zone: 52 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4044 pages, LIFO batch:0 Normal zone: 2860 pages used for memmap Normal zone: 222420 pages, LIFO batch:31 HighMem zone: 311 pages used for memmap HighMem zone: 24217 pages, LIFO batch:3 DMI 2.3 present. Using APIC driver default ACPI: RSDP 000F7840, 0014 (r0 COMPAQ) ACPI: RSDT 3DFF0C84, 002C (r1 COMPAQ CPQ005A 10120420 CPQ 1) ACPI: FACP 3DFF0C00, 0084 (r2 COMPAQ CPQ005A 2 CPQ 1) ACPI: DSDT 3DFF0CB0, 607E (r1 COMPAQ EVON800 10000 MSFT 100000E) ACPI: FACS 3DFFBE80, 0040 ACPI: SSDT 3DFF6D2E, 02E9 (r1 COMPAQ CPQGysr 1001 MSFT 100000E) ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 40000000 (gap: 3e000000:c2000000) Detected 597.096 MHz processor. Built 1 zonelists. Total pages: 250681 Kernel command line: ro root=LABEL=/ rhgb quiet selinux=off Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (01cab000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c079e000 soft=c077e000 PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS: 2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1096 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 991788k/1015616k available (2148k kernel code, 23104k reserved, 1138k data, 248k init, 98112k highmem) virtual kernel memory layout: fixmap : 0xffc56000 - 0xfffff000 (3748 kB) pkmap : 0xff800000 - 0xffc00000 (4096 kB) vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc073b000 - 0xc0779000 ( 248 kB) .data : 0xc06190f1 - 0xc0735cb4 (1138 kB) .text : 0xc0400000 - 0xc06190f1 (2148 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1195.35 BogoMIPS (lpj=597679) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: afe9f9bf 00000000 00000000 00000000 00000180 00000000 00000000 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 2048K CPU: After all inits, caps: afe9f1bf 00000000 00000000 00002040 00000180 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 12k freed ACPI: Core revision 20070126 ACPI: setting ELCR to 0200 (from 0c20) CPU0: Intel(R) Pentium(R) M processor 1.80GHz stepping 06 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs sizeof(vma)=84 bytes sizeof(page)=52 bytes sizeof(inode)=564 bytes sizeof(dentry)=156 bytes sizeof(ext3inode)=800 bytes sizeof(buffer_head)=56 bytes sizeof(skbuff)=176 bytes sizeof(task_struct)=2704 bytes HP Compaq Laptop series board detected. Selecting BIOS-method for reboots. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf031f, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [C044] (0000:00) PCI: Probing PCI hardware (bus 00) PCI quirk: region 1000-103f claimed by ali7101 ACPI PCI quirk: region 1100-111f claimed by ali7101 SMB Boot video device is 0000:01:05.0 ACPI: PCI Interrupt Routing Table [\_SB_.C044._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.C044.C045._PRT] ACPI: PCI Interrupt Link [C0C4] (IRQs 5 *10 11) ACPI: PCI Interrupt Link [C0C5] (IRQs 5 *10 11) ACPI: PCI Interrupt Link [C0C6] (IRQs 5 10 *11) ACPI: PCI Interrupt Link [C0C7] (IRQs 5 10 11) *0, disabled. ACPI: PCI Interrupt Link [C0C8] (IRQs 5 *10 11) ACPI: PCI Interrupt Link [C0C9] (IRQs *5 10 11) ACPI: PCI Interrupt Link [C0CA] (IRQs 5 10 *11) ACPI: PCI Interrupt Link [C0CB] (IRQs 5 10 *11) ACPI: Power Resource [C15A] (on) ACPI: Power Resource [C15F] (on) ACPI: Power Resource [C169] (on) ACPI: Power Resource [C17A] (on) ACPI: Power Resource [C1F2] (off) ACPI: Power Resource [C1F3] (off) ACPI: Power Resource [C1F4] (off) ACPI: Power Resource [C1F5] (off) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 15 devices usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved pnp: 00:00: iomem range 0xe0000-0xfffff could not be reserved pnp: 00:00: iomem range 0x100000-0x3dffffff could not be reserved pnp: 00:0c: iomem range 0xffb00000-0xffbfffff has been reserved pnp: 00:0c: iomem range 0xfff00000-0xffffffff has been reserved pnp: 00:0d: ioport range 0x1000-0x107f could not be reserved pnp: 00:0d: ioport range 0x1100-0x111f has been reserved pnp: 00:0d: iomem range 0x98500000-0x98500fff has been reserved pnp: 00:0e: iomem range 0xcf000-0xcffff has been reserved PCI: Bridge: 0000:00:01.0 IO window: 2000-2fff MEM window: 90000000-900fffff PREFETCH window: 94000000-97ffffff PCI: Bus 2, cardbus bridge: 0000:00:0b.0 IO window: 00001400-000014ff IO window: 00001800-000018ff PREFETCH window: 40000000-43ffffff MEM window: 44000000-47ffffff PCI: Bus 6, cardbus bridge: 0000:00:0b.1 IO window: 00001c00-00001cff IO window: 00003c00-00003cff PREFETCH window: 48000000-4bffffff MEM window: 4c000000-4fffffff ACPI: PCI Interrupt Link [C0C6] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [C0C6] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt 0000:00:0b.1[A] -> Link [C0C6] -> GSI 11 (level, low) -> IRQ 11 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 65536 (order: 9, 2359296 bytes) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) TCP: Hash tables configured (established 65536 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 2781k freed apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. audit: initializing netlink socket (disabled) audit(1172236548.499:1): initialized highmem bounce pool size: 64 pages Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) ksign: Installing public key data Loading keyring - Added public key 50FF7A121872AA0A - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Activating ISA DMA hang workarounds. pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI: Transitioning device [C1F6] to D3 ACPI: Transitioning device [C1F6] to D3 ACPI: Fan [C1F6] (off) ACPI: Transitioning device [C1F7] to D3 ACPI: Transitioning device [C1F7] to D3 ACPI: Fan [C1F7] (off) ACPI: Transitioning device [C1F8] to D3 ACPI: Transitioning device [C1F8] to D3 ACPI: Fan [C1F8] (off) ACPI: Transitioning device [C1F9] to D3 ACPI: Transitioning device [C1F9] to D3 ACPI: Fan [C1F9] (off) ACPI: Invalid PBLK length [7] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3]) ACPI: Thermal Zone [TZ1] (61 C) ACPI: Thermal Zone [TZ2] (55 C) ACPI: Thermal Zone [TZ3] (39 C) isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Real Time Clock Driver v1.12ac Non-volatile memory driver v1.2 Linux agpgart interface v0.102 (c) Dave Jones agpgart: Detected Ati IGP345M chipset agpgart: AGP aperture is 64M @ 0x9c000000 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS2 at I/O 0x3e8 (irq = 3) is a 16550A 00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ACPI: PCI Interrupt Link [C0CA] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [C0CA] -> GSI 11 (level, low) -> IRQ 11 0000:00:08.0: ttyS1 at I/O 0x3428 (irq = 11) is a 8250 0000:00:08.0: ttyS3 at I/O 0x3440 (irq = 11) is a 8250 Couldn't register serial port 0000:00:08.0: -28 RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize input: Macintosh mouse button emulation as /class/input/input0 Yenta: CardBus bridge found at 0000:00:0b.0 [0e11:005a] Yenta O2: res at 0x94/0xD4: 00/ea Yenta O2: enabling read prefetch/write burst Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Socket status: 30000006 Yenta: CardBus bridge found at 0000:00:0b.1 [0e11:005a] Yenta: ISA IRQ mask 0x04b8, PCI irq 11 Socket status: 30000006 usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: PS/2 Controller [PNP0303:C177,PNP0f13:C178] at 0x60,0x64 irq 1,12 i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /class/input/input1 TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPI config is deprecated. Use X86_ACPI_CPUFREQ (acpi-cpufreq) instead. Using IPI No-Shortcut mode Time: acpi_pm clocksource has been installed. Switched to high resolution mode on CPU 0 Freeing unused kernel memory: 248k freed Write protecting the kernel read-only data: 840k USB Universal Host Controller Interface driver v3.0 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ACPI: PCI Interrupt Link [C0C5] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10 ohci_hcd 0000:00:12.0: OHCI Host Controller ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:12.0: irq 10, io mem 0x98380000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ACPI: PCI Interrupt 0000:00:12.1[B] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10 ohci_hcd 0000:00:12.1: OHCI Host Controller ohci_hcd 0000:00:12.1: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:12.1: irq 10, io mem 0x98400000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected Synaptics Touchpad, model: 1, fw: 5.9, id: 0x1b6eb1, caps: 0xa84793/0x100000 serio: Synaptics pass-through port at isa0060/serio4/input0 input: SynPS/2 Synaptics TouchPad as /class/input/input2 ACPI: PCI Interrupt 0000:00:12.2[C] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10 ehci_hcd 0000:00:12.2: EHCI Host Controller ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 3 usb 1-3: new full speed USB device using ohci_hcd and address 2 ehci_hcd 0000:00:12.2: irq 10, io mem 0x98480000 ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 5 ports detected SCSI subsystem initialized libata version 2.10 loaded. ACPI: PCI Interrupt Link [C0C4] enabled at IRQ 10 ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [C0C4] -> GSI 10 (level, low) -> IRQ 10 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00013800 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x00013808 irq 15 scsi0 : pata_ali ata1.00: ATA-6: HTS541080G9AT00, MB4OA60A, max UDMA/100 ata1.00: 156301488 sectors, multi 16: LBA48 ata1.00: configured for UDMA/100 scsi1 : pata_ali usb 1-3: new full speed USB device using ohci_hcd and address 3 scsi 0:0:0:0: Direct-Access ATA HTS541080G9AT00 MB4O PQ: 0 ANSI: 5 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 < sda5 > sd 0:0:0:0: Attached scsi disk sda usb 1-3: configuration #1 chosen from 1 choice kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. input: PS/2 Generic Mouse as /class/input/input3 cs: IO port probe 0x100-0x3af: excluding 0x378-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. cs: IO port probe 0x100-0x3af: excluding 0x378-0x37f cs: IO port probe 0x3e0-0x4ff: excluding 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 cs: IO port probe 0x820-0x8ff: clean. cs: IO port probe 0xc00-0xcf7: clean. cs: IO port probe 0xa00-0xaff: clean. Floppy drive(s): fd0 is 1.44M sd 0:0:0:0: Attached scsi generic sg0 type 0 alim7101_wdt: Steve Hill . alim7101_wdt: Detected old alim7101 revision 'a1d'. If this is a cobalt board, set the 'use_gpio' module parameter. floppy0: no floppy controllers found ali15x3_smbus 0000:00:11.0: ALI15X3_smb region uninitialized - upgrade BIOS or use force_addr=0xaddr ali15x3_smbus 0000:00:11.0: ALI15X3 not detected, module not inserted. alim7101_wdt: Steve Hill . alim7101_wdt: Detected old alim7101 revision 'a1d'. If this is a cobalt board, set the 'use_gpio' module parameter. ACPI: PCI Interrupt Link [C0CB] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [C0CB] -> GSI 11 (level, low) -> IRQ 11 input: PC Speaker as /class/input/input4 tpm_inf_pnp 00:05: Found C16C with ID IFX0101 tpm_inf_pnp 00:05: TPM found: config base 0x7e, io base 0x1410, chip version 0x0006, vendor id 0x15d1 (Infineon), product id 0x0006 (SLD 9630 TT 1.1) parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: HCI USB driver ver 2.9 usbcore: registered new interface driver hci_usb AC'97 1 does not respond - RESET AC'97 1 access is not valid [0xffffffff], removing mixer. ali mixer 1 creating error. tg3.c:v3.73 (February 12, 2007) ACPI: PCI Interrupt Link [C0C8] enabled at IRQ 10 ACPI: PCI Interrupt 0000:00:13.0[A] -> Link [C0C8] -> GSI 10 (level, low) -> IRQ 10 eth0: Tigon3 [partno(BCM5705mA1) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000Base-T Ethernet 00:11:85:84:99:ae eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[0] TSOcap[1] eth0: dma_rwctrl[763f0000] dma_mask[64-bit] rtc_cmos 00:09: rtc core: registered rtc_cmos as rtc0 pnp: Device 00:09 does not support disabling. rtc_cmos: probe of 00:09 failed with error -16 Floppy drive(s): fd0 is 1.44M floppy0: no floppy controllers found lp0: using parport0 (interrupt-driven). lp0: console ready sonypi: Sony Programmable I/O Controller Driver v1.26. NET: Registered protocol family 10 lo: Disabled Privacy Extensions Mobile IPv6 [drm] Initialized drm 1.1.0 20060810 ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [C0C4] -> GSI 10 (level, low) -> IRQ 10 [drm] Initialized radeon 1.25.0 20060524 on minor 0 ACPI: AC Adapter [C137] (off-line) ACPI: Battery Slot [C139] (battery present) ACPI: Battery Slot [C138] (battery absent) No dock devices found. input: Power Button (FF) as /class/input/input5 ACPI: Power Button (FF) [PWRF] input: Sleep Button (CM) as /class/input/input6 ACPI: Sleep Button (CM) [C13B] input: Lid Switch as /class/input/input7 ACPI: Lid Switch [C13A] ibm_acpi: ec object not found ACPI: Video Device [C046] (multi-head: yes rom: no post: no) md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel at redhat.com EXT3 FS on sda2, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on sda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sda5, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 2048276k swap on /dev/sda3. Priority:-1 extents:1 across:2048276k Clocksource tsc unstable (delta = 79208949 ns) ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (7934 buckets, 63472 max) PM: Writing back config space on device 0000:00:13.0 at offset b (was 165d14e4, writing 5a0e11) PM: Writing back config space on device 0000:00:13.0 at offset 3 (was 0, writing 4010) PM: Writing back config space on device 0000:00:13.0 at offset 2 (was 2000000, writing 2000003) PM: Writing back config space on device 0000:00:13.0 at offset 1 (was 2b00000, writing 2b00006) ADDRCONF(NETDEV_UP): eth0: link is not ready PM: Writing back config space on device 0000:00:13.0 at offset b (was 165d14e4, writing 5a0e11) PM: Writing back config space on device 0000:00:13.0 at offset 3 (was 0, writing 4010) PM: Writing back config space on device 0000:00:13.0 at offset 2 (was 2000000, writing 2000003) PM: Writing back config space on device 0000:00:13.0 at offset 1 (was 2b00000, writing 2b00006) Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 Bluetooth: HIDP (Human Interface Emulation) ver 1.1 agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V2 device at 0000:01:05.0 into 4x mode [drm] Setting GART location based on old memory map [drm] writeback test succeeded in 1 usecs Stopping tasks ... done. Shrinking memory... -\|done (38974 pages freed) Freed 155896 kbytes in 0.53 seconds (294.14 MB/s) Suspending console(s) pnp: Device 00:04 disabled. pnp: Device 00:02 disabled. ACPI: PCI interrupt for device 0000:00:12.2 disabled ACPI: PCI interrupt for device 0000:00:12.1 disabled ACPI: PCI interrupt for device 0000:00:12.0 disabled ACPI: PCI interrupt for device 0000:00:06.0 disabled pci_set_power_state(): 0000:00:00.0: state=3, current state=5 Disabling non-boot CPUs ... swsusp: critical section: swsusp: Need to copy 114846 pages Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. PM: Writing back config space on device 0000:00:06.0 at offset 1 (was c2900007, writing c2900003) ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [C0CB] -> GSI 11 (level, low) -> IRQ 11 Yenta O2: res at 0x94/0xD4: 00/ea Yenta O2: enabling read prefetch/write burst BUG: warning at drivers/pci/pci.c:823/pcim_enable_device() (Not tainted) [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] pcim_enable_device+0x9e/0xbb [] ata_pci_device_do_resume+0x1f/0x5d [libata] [] ata_pci_device_resume+0x10/0x23 [libata] [] ali_reinit_one+0x12/0x15 [pata_ali] [] pci_device_resume+0x1a/0x44 [] resume_device+0xa7/0xe0 [] dpm_resume+0x7c/0xd5 [] device_resume+0x44/0x5d [] pm_suspend_disk+0x279/0x28d [] enter_state+0x51/0x189 [] state_store+0x86/0x9c [] subsys_attr_store+0x20/0x25 [] sysfs_write_file+0xc6/0xee [] vfs_write+0xaf/0x163 [] sys_write+0x3d/0x61 [] syscall_call+0x7/0xb ======================= PCI: Enabling device 0000:00:12.0 (0000 -> 0002) ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10 PCI: Enabling device 0000:00:12.1 (0000 -> 0002) ACPI: PCI Interrupt 0000:00:12.1[B] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI Interrupt 0000:00:12.2[C] -> Link [C0C5] -> GSI 10 (level, low) -> IRQ 10 usb usb3: root hub lost power or was reset ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [C0C4] -> GSI 10 (level, low) -> IRQ 10 pnp: Device 00:02 activated. pnp: Device 00:04 activated. pnp: Failed to activate device 00:05. pnp: Device 00:0a does not support activation. pnp: Device 00:0b does not support activation. usb usb1: root hub lost power or was reset usb usb2: root hub lost power or was reset ata1: soft resetting port usbdev1.3_ep00: PM: resume from 0, parent 1-3 still 1 hci_usb 1-3:1.0: PM: resume from 1, parent 1-3 still 1 usbdev1.3_ep81: PM: resume from 0, parent 1-3:1.0 still 1 usbdev1.3_ep02: PM: resume from 0, parent 1-3:1.0 still 1 usbdev1.3_ep82: PM: resume from 0, parent 1-3:1.0 still 1 hci_usb 1-3:1.1: PM: resume from 1, parent 1-3 still 1 usb 1-3:1.2: PM: resume from 1, parent 1-3 still 1 usbdev1.3: PM: resume from 0, parent 1-3 still 1 usbdev1.3_ep03: PM: resume from 0, parent 1-3:1.1 still 1 usbdev1.3_ep83: PM: resume from 0, parent 1-3:1.1 still 1 hci0: PM: resume from 0, parent 1-3:1.0 still 1 Restarting tasks ... done. ata1.00: simplex DMA is claimed by other device, disabling DMA ata1.00: configured for PIO4 ata1: EH complete SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 usb 1-3: USB disconnect, address 3 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA input: Power Button (FF) as /class/input/input8 ACPI: Power Button (FF) [PWRF] input: Sleep Button (CM) as /class/input/input9 ACPI: Sleep Button (CM) [C13B] input: Lid Switch as /class/input/input10 ACPI: Lid Switch [C13A] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V2 device at 0000:01:05.0 into 4x mode From jkeating at redhat.com Fri Feb 23 13:55:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Feb 2007 08:55:27 -0500 Subject: FC6 updates broken deps? In-Reply-To: <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> Message-ID: <200702230855.27734.jkeating@redhat.com> On Friday 23 February 2007 08:28, Piotr Baranowski wrote: > For me after 10 years of linux experience it was great mistery why a hell > does yum override ^c. I do believe it has something to do with interaction with rpmlib and rpmlib trapping and doing nothing with the ^c while it does stuff with the DB. I could be wrong, but I'm pretty sure that's what is going on. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Fri Feb 23 14:06:47 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 Feb 2007 09:06:47 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172223556.3743.257.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> Message-ID: <1172239607.9691.13.camel@localhost.localdomain> On Fri, 2007-02-23 at 04:39 -0500, Lyvim Xaphir wrote: > The authors should decide what to do with their own work. NOT ANYBODY > ELSE. You should understand that "property" is natural only for physical objects, just because possession of a physical object can be controlled by physical means and cannot be easily replicated. Abstract objects like ideas, but also anything that can be replicated at zero cost without destroying the original, can't be subject to real property. Only society rules, abstract themselves!, can grant anything. Still, even if you declare by law that the world is flat, you are not changing reality, you are just making a rule. "Intellectual Property" is a brainwashing term that tries to make you think non physical matter can be owned the same way physical matter can be. That's not true, and applying that way of thinking to non physical goods can only lead to stupid consequences. As it is _not natural_ to treat "Intellectual Property" like physical property, as it is not, the maximum you can achieve is social tension at best. That said I'd like to remember you that EVERYBODY here base their own work and rules ON copyright. By this very fact it means that everybody IS following the rules of this CAPITALISTIC society, and you have no right whatsoever to say the contrary until you bring proof people is acting against the rules. Your babbling about socialism, communism, fascism, and whatnot, is just bi-speaking and mystification, and is based on nothing concrete. Drivers developers know the rules of the Kernel, the rules based on society rules called COPYRIGHT, and rules DECIDED by the AUTHORS that decided WHAT TO DO WITH THEIR OWN WORK. So please go show your bi-speak somewhere else, this is a development list, not a "failed mad politician list". Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From alan at redhat.com Fri Feb 23 14:28:48 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 23 Feb 2007 09:28:48 -0500 Subject: FC6 updates broken deps? In-Reply-To: <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> References: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> Message-ID: <20070223142848.GB7609@devserv.devel.redhat.com> On Fri, Feb 23, 2007 at 02:28:04PM +0100, Piotr Baranowski wrote: > Most people will understand WHY ^c is overriden in ssh for example. > > For me after 10 years of linux experience it was great mistery why a hell > does yum override ^c. It behaves much like ftp in that respect > "If you want to switch from one mirror to another press CTRL+M" Not a good idea - ^M is newline 8) From alan at redhat.com Fri Feb 23 14:30:55 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 23 Feb 2007 09:30:55 -0500 Subject: F7t2 and QA Meeting In-Reply-To: <1172238621.4455.1.camel@rivendell> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> <20070221175105.GG19851@redhat.com> <1172142877.2960.1.camel@rivendell> <20070222204750.GA20999@devserv.devel.redhat.com> <20070223005105.GA25845@redhat.com> <1172238621.4455.1.camel@rivendell> Message-ID: <20070223143055.GC7609@devserv.devel.redhat.com> On Fri, Feb 23, 2007 at 02:50:21PM +0100, Kjartan Maraas wrote: > Yenta O2: res at 0x94/0xD4: 00/ea > Yenta O2: enabling read prefetch/write burst > BUG: warning at drivers/pci/pci.c:823/pcim_enable_device() (Not tainted) Known bug, fix in the libata GIT tree already. > Restarting tasks ... done. > ata1.00: simplex DMA is claimed by other device, disabling DMA > ata1.00: configured for PIO4 Known bug, working on it at the emoment. From tmraz at redhat.com Fri Feb 23 14:39:59 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 23 Feb 2007 15:39:59 +0100 Subject: FC6 updates broken deps? In-Reply-To: <200702230855.27734.jkeating@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> <200702230855.27734.jkeating@redhat.com> Message-ID: <1172241599.3116.6.camel@perun.kabelta.loc> On Fri, 2007-02-23 at 08:55 -0500, Jesse Keating wrote: > On Friday 23 February 2007 08:28, Piotr Baranowski wrote: > > For me after 10 years of linux experience it was great mistery why a hell > > does yum override ^c. > > I do believe it has something to do with interaction with rpmlib and rpmlib > trapping and doing nothing with the ^c while it does stuff with the DB. I > could be wrong, but I'm pretty sure that's what is going on. By a brief look at the rpmlib source it seems so but I didn't study it thoroughly. I understand the necessity to block the signals when db is opened but perhaps rpmlib should block the signal so it can be delivered later when it is unblocked and not just ignore it. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From bruno at wolff.to Fri Feb 23 14:43:42 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 23 Feb 2007 08:43:42 -0600 Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) In-Reply-To: <4se1b4-aol.ln1@sky.matrix> References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> <4se1b4-aol.ln1@sky.matrix> Message-ID: <20070223144342.GA16092@wolff.to> On Thu, Feb 22, 2007 at 21:34:24 +0000, "Keith G. Robertson-Turner" wrote: > > 10) Only other thing I can think of is, SMART disk health checks, > however, according to Google's recent report (they did a massive > test), SMART is next to useless at actually predicting failure. That wasn't what they concluded. What they found is that something like half of the disk drive failures occured that were ot detectable by smart. The also found that disk drives that had even one reallocated block, had a 10 times higher chance of failing over the next 60 days compared to disk drives that had no reallocated sectors. There were one or two other smart attributes where a single event had a similar correlation with drive failures. From bruno at wolff.to Fri Feb 23 14:46:54 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 23 Feb 2007 08:46:54 -0600 Subject: FC6 to Rawhide via repo switch In-Reply-To: <45DDECAA.8080100@pajato.com> References: <45DDECAA.8080100@pajato.com> Message-ID: <20070223144654.GB16092@wolff.to> On Thu, Feb 22, 2007 at 14:19:06 -0500, Paul Michael Reilly wrote: > I recently got my system wedged without having good notes about what > happened. So I figured that the simplest path to getting back to a > running Rawhide was to install minimally FC6 and change the repos to > select development (should extras development be enabled?) and then do > an update. I did that and midway through the 1000+ package update the > system rebooted leaving me scratching my head wondering if I should > distrust this approach or just reboot and try again with another update > and hope for the best. I did the latter and have been beset by weird > behavior ever since. Like checkbox buttons not echoing properly on GUIs > and non elf format conflicts in some bin programs and libraries. If you have a high speed network connection, you are probably better off booting from the rawhide boot iso and doing a network install. (Unless you specifically want to test upgrading.) From nphilipp at redhat.com Fri Feb 23 14:47:37 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 Feb 2007 15:47:37 +0100 Subject: Goodbye, Fedora In-Reply-To: <20070221224918.GB10229@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070221182501.GA31710@thyrsus.com> <20070221224918.GB10229@thyrsus.com> Message-ID: <1172242057.17211.10.camel@gibraltar.stuttgart.redhat.com> On Wed, 2007-02-21 at 17:49 -0500, Eric S. Raymond wrote: > Bojan Smojver : > > And here we see the real problem - there was no proper backup of the system > > BEFORE any of this was attempted. I'm sure that's Fedora's fault... > > Actually, there was. But it was a couple of days old. I didn't expect > a *single-package update* to be so dangerous that I needed to do > a full backup first. How foolishly optimistic of me. According to what I've read out of the scarce info about your problem, /usr/lib/rpm/rpm2cpio.sh could easily have helped you (unless you managed to damage other vital system stuff as well). No need to resort to drastic methods like static linking ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 jacliburn at bellsouth.net Fri Feb 23 14:19:03 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Fri, 23 Feb 2007 08:19:03 -0600 Subject: F7t2 and QA Meeting In-Reply-To: <1172238621.4455.1.camel@rivendell> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> <20070221175105.GG19851@redhat.com> <1172142877.2960.1.camel@rivendell> <20070222204750.GA20999@devserv.devel.redhat.com> <20070223005105.GA25845@redhat.com> <1172238621.4455.1.camel@rivendell> Message-ID: <20070223081903.1416ca0d@osprey.hogchain.net> On Fri, 23 Feb 2007 14:50:21 +0100 Kjartan Maraas wrote: > BUG: warning at drivers/pci/pci.c:823/pcim_enable_device() (Not > tainted) [] show_trace_log_lvl+0x1a/0x2f > [] show_trace+0x12/0x14 > [] dump_stack+0x16/0x18 > [] pcim_enable_device+0x9e/0xbb > [] ata_pci_device_do_resume+0x1f/0x5d [libata] > [] ata_pci_device_resume+0x10/0x23 [libata] > [] ali_reinit_one+0x12/0x15 [pata_ali] > [] pci_device_resume+0x1a/0x44 > [] resume_device+0xa7/0xe0 > [] dpm_resume+0x7c/0xd5 > [] device_resume+0x44/0x5d > [] pm_suspend_disk+0x279/0x28d > [] enter_state+0x51/0x189 > [] state_store+0x86/0x9c > [] subsys_attr_store+0x20/0x25 > [] sysfs_write_file+0xc6/0xee > [] vfs_write+0xaf/0x163 > [] sys_write+0x3d/0x61 > [] syscall_call+0x7/0xb This part is a known problem in the kernel and is awaiting a patch from the author. Jay From nphilipp at redhat.com Fri Feb 23 15:20:36 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 Feb 2007 16:20:36 +0100 Subject: FC6 updates broken deps? In-Reply-To: <20070223142848.GB7609@devserv.devel.redhat.com> References: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> <20070223142848.GB7609@devserv.devel.redhat.com> Message-ID: <1172244036.17211.19.camel@gibraltar.stuttgart.redhat.com> On Fri, 2007-02-23 at 09:28 -0500, Alan Cox wrote: > > "If you want to switch from one mirror to another press CTRL+M" > > Not a good idea - ^M is newline 8) So make that Ctrl plus any other character that isn't a control sequence already. You could also make it Ctrl+Alt+Backspace so that the yum maintainers finally get their "yum kills X" bug reports they must have been missing for years ;-P. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 15:25:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 16:25:28 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <200702230817.39895.jkeating@redhat.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <200702230817.39895.jkeating@redhat.com> Message-ID: <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> [repost] On Fri, 23 Feb 2007 08:17:36 -0500, Jesse Keating wrote: > On Friday 23 February 2007 07:35, Michael Schwendt wrote: > > * heavy use of Red Hat internal mailing-lists for Fedora related matters, > > This is complete BS. Disagree as much as you like, but please avoid the strong language. > Maybe one or three messages a month pop up on internal > lists, and those are immediately redirected to external lists. Repeatedly, there have been references to relevant topics on internal lists, involving Fedora or Core. I've pointed out a few examples long ago. With regard to the Fedora Merge, most recent is this one: https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00577.html Now, I guess somebody will deny that it's relevant discussion. Still, you cannot deny that internal lists plus interal IRC plus additional forms of internal communication don't do a community project any good when public communication channels are criticised for their poor s/n ratio. > > * more closed circles, in which decisions are made -- including mysteries > > like brew, koji, and code transfer for the new Updates System, > > These decisions were made at the Fedora summit, with the Fedora board and > other community folks, complete with an IRC channel during the live > discussions. Further discussion has happened in Fedora board meetings and > public Fedora lists. Which lists exactly? > > * unclear role of FESCo, not enough steering -- instead: the drive > > that "you don't need to be in FESCo to get something done", > > I don't even know what you mean by this. That's sad. But you're not listed as a FESCo member anyway. Perhaps I should lose my hope that somebody else in FESCo still has a clue what I refer to. From jwboyer at jdub.homelinux.org Fri Feb 23 15:38:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 23 Feb 2007 09:38:19 -0600 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1172245099.24204.230.camel@zod.rchland.ibm.com> On Fri, 2007-02-23 at 16:25 +0100, Michael Schwendt wrote: > [repost] > > On Fri, 23 Feb 2007 08:17:36 -0500, Jesse Keating wrote: > > > On Friday 23 February 2007 07:35, Michael Schwendt wrote: > > > * heavy use of Red Hat internal mailing-lists for Fedora related matters, > > > > This is complete BS. > > Disagree as much as you like, but please avoid the strong language. > > > Maybe one or three messages a month pop up on internal > > lists, and those are immediately redirected to external lists. > > Repeatedly, there have been references to relevant topics on internal > lists, involving Fedora or Core. I've pointed out a few examples long > ago. With regard to the Fedora Merge, most recent is this one: > > https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00577.html That is possibly the worst example you could have picked. Max was sending an email to his employees for education. Not to discuss some super secret plan or something. I'm sorry that you cannot recognize that everyone within Red Hat is not fully aware of Fedora and what needs to be done, and therefore needs to be educated as to what the goals are. And these "other forums" discussions aren't limited to just Red Hat either. There was a ton of stuff discussed at FUDCon, which included several _community_ members. I have yet to see an executive summary of everything that was decided. It cuts both ways. The fact that you and I and others are not privy to every single Fedora based discussion is just a fact of life. I think both Red Hat and the community are doing a _good_ job of being transparent, despite how difficult it can be to do that at times. josh From jkeating at redhat.com Fri Feb 23 15:46:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Feb 2007 10:46:52 -0500 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200702231046.52584.jkeating@redhat.com> On Friday 23 February 2007 10:25, Michael Schwendt wrote: > Repeatedly, there have been references to relevant topics on internal > lists, involving Fedora or Core. I've pointed out a few examples long > ago. With regard to the Fedora Merge, most recent is this one: > > https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00577.ht >ml > > Now, I guess somebody will deny that it's relevant discussion. Still, you > cannot deny that internal lists plus interal IRC plus additional forms of > internal communication don't do a community project any good when public > communication channels are criticised for their poor s/n ratio. Here's the deal with this one, it was sent to internal lists, because many RH maintainers weren't reading external lists. We wanted to make sure they read this message. And much of the thread was about how Red Hat Engineering would interact with Fedora in the merged world, and what that means for RHEL. Some of that just couldn't be spoken about externally. Also, this isn't indicative that there are other threads going on, the internal lists are pretty devoid of actual Fedora content. > > > * more closed circles, in which decisions are made -- including > > > mysteries like brew, koji, and code transfer for the new Updates > > > System, > > > > These decisions were made at the Fedora summit, with the Fedora board and > > other community folks, complete with an IRC channel during the live > > discussions. ?Further discussion has happened in Fedora board meetings > > and public Fedora lists. > > Which lists exactly? Fedora Advisory Board, fedora-devel-list, fedora-infrastructure-list to name a few. > > > > * unclear role of FESCo, not enough steering -- instead: the drive > > > that "you don't need to be in FESCo to get something done", > > > > I don't even know what you mean by this. > > That's sad. But you're not listed as a FESCo member anyway. That's unfortunate, as I was dragged back into FESCo recently. > Perhaps I should lose my hope that somebody else in FESCo still has > a clue what I refer to. You seem very bitter. My comment above was more "I don't understand the language used." I could take a guess at what you meant, but that would be an assumption, and we all know how fun those are. If you're referring to our desire to see work done by non-fesco people, well I applaud that. It is absolutely silly to have to be ON Fesco to do anything of importance. All that does is make FESCo far too huge to accomplish anything, or it makes people feel that their contributions to the project are unwanted if they aren't in FESCo. Neither is something I'd like to see. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michel.salim at gmail.com Fri Feb 23 15:55:11 2007 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 23 Feb 2007 10:55:11 -0500 Subject: External drives not detected at boot time? In-Reply-To: <1171802371.9730.0.camel@gilboa-work-dev.localdomain> References: <883cfe6d0702170841t73ebf476x421de95776c2b211@mail.gmail.com> <1171802371.9730.0.camel@gilboa-work-dev.localdomain> Message-ID: <883cfe6d0702230755v1d7fa170x4f52a4bb083526bb@mail.gmail.com> 2007/2/18, Gilboa Davara : > On Sat, 2007-02-17 at 11:41 -0500, Michel Salim wrote: > > In Rawhide, USB external drives are not detected if they are plugged > > in at boot time, requiring power-cycling before the required device > > nodes are created in /dev and gnome-volume-manager works. > > > > Has there been any changes in the boot process that might have caused this? > > > > -- > > Michel Salim > > http://hircus.wordpress.com/ > > > > Seems like it has something to do with BZ# 174887 [1] > > - Gilboa > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174887 > Something like that -- I commented on the wrong bug, but this is what I said: libusual actually detects my external hard drive, but claimed that it could not find usb_storage. On Fedora Core 6 it works (both in Anaconda and in the installed system) -- to the point that if I don't unplug the external hard drive, it actually appears *before* the internal one (sda vs sdb). The joys of device numbering.. -- Michel -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From mclasen at redhat.com Fri Feb 23 16:00:49 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 23 Feb 2007 11:00:49 -0500 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1172246449.3710.11.camel@localhost.localdomain> On Fri, 2007-02-23 at 16:25 +0100, Michael Schwendt wrote: > [repost] > > On Fri, 23 Feb 2007 08:17:36 -0500, Jesse Keating wrote: > > > On Friday 23 February 2007 07:35, Michael Schwendt wrote: > > > * heavy use of Red Hat internal mailing-lists for Fedora related matters, > > > > This is complete BS. > > Disagree as much as you like, but please avoid the strong language. > This is not an opinion to disagree on, Jesse is simply stating that you have the facts wrong (in colorful language...) > > Maybe one or three messages a month pop up on internal > > lists, and those are immediately redirected to external lists. > > Repeatedly, there have been references to relevant topics on internal > lists, involving Fedora or Core. I've pointed out a few examples long > ago. With regard to the Fedora Merge, most recent is this one: > > https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00577.html > > Now, I guess somebody will deny that it's relevant discussion. Still, you > cannot deny that internal lists plus interal IRC plus additional forms of > internal communication don't do a community project any good when public > communication channels are criticised for their poor s/n ratio. I hope you agree that a company needs internal communication channels. Do you also object to us talking to our cube neighbours directly, rather than using public irc ? From mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 16:13:48 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 17:13:48 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <200702231046.52584.jkeating@redhat.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> Message-ID: <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> On Fri, 23 Feb 2007 10:46:52 -0500, Jesse Keating wrote: > > > > * more closed circles, in which decisions are made -- including > > > > mysteries like brew, koji, and code transfer for the new Updates > > > > System, > > > > > > These decisions were made at the Fedora summit, with the Fedora board and > > > other community folks, complete with an IRC channel during the live > > > discussions. ?Further discussion has happened in Fedora board meetings > > > and public Fedora lists. > > > > Which lists exactly? > > Fedora Advisory Board "Needle in the haystack" syndroms possibly? I've searched that list, but only find lots of "why I'm using Ubuntu instead of Fedora ATM". Threads like "how to govern and manage the new combined repository (second proposal from thl)" are rare. > fedora-devel-list Doubtful. > fedora-infrastructure-list to name a few. Most likely you mix up plenty of stuff that is talked about on IRC and the few bits that make it to the public. Everybody who does not lurk on IRC 24/7 is uninformed in many Fedora matters. > You seem very bitter. Thanks to the Fedora School. From mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 16:17:31 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 17:17:31 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <1172246449.3710.11.camel@localhost.localdomain> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <1172246449.3710.11.camel@localhost.localdomain> Message-ID: <20070223171731.7c3946a7.mschwendt.tmp0701.nospam@arcor.de> On Fri, 23 Feb 2007 11:00:49 -0500, Matthias Clasen wrote: > I hope you agree that a company needs internal communication channels. Sure, but I hope you agree that running a community project requires additional communication channels. > Do you also object to us talking to our cube neighbours directly, rather > than using public irc ? No, ... and bad jokes are inappropriate and superfluous. From kwade at redhat.com Fri Feb 23 16:47:43 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 23 Feb 2007 08:47:43 -0800 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <45DC9246.6060307@leemhuis.info> References: <45DC9246.6060307@leemhuis.info> Message-ID: <1172249263.4651.18.camel@erato.phig.org> On Wed, 2007-02-21 at 19:41 +0100, Thorsten Leemhuis wrote: > Hi all! > > The idea to build Fedora (Extras) Packages for RHEL and compatible > distros like CentOS in the scope of the Fedora Project is over half a > year old now, but didn't really take of yet. This mail (and some other > work in other places like the wiki) tries to actually get the idea > running a bit more faster now in the hope that the project actually > takes of soon. Thanks for stepping up and organizing us this far. It's really helping make EPEL happen. > -- the package needs to be supported until the End Of Life (EOL) of the > Distributions they were build for -- round about seven years. Sure, > nobody of us knows if he still be around then. But you should not build > packages for EPEL if you plan to moe oer to other stuff soon or find > packaging really annoying One idea we want to promote is making the packaging into a job role instead of a personal side-project. This is possible and useful where your employer or other outside organization benefits from your package in EPEL. For example, your infrastructure requires package Foo be rebuilt in EPEL. If you make package maintenance part of your job role, you gain: * The ability to pass on package maintenance when you move job roles or leave the organization * Protection of the longevity of the package * More institutional knowledge of why it is a Good Thing to maintain packages in Fedora * A small portion of your compensation now covers working on Fedora (!) To that end, I have this first draft of a 'job description'. It is designed to be generic enough that it can be adjusted to fit into other, existing job descriptions. We need your help to make sure the job duties are complete and accurate: http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription When it has improved some, I'm going to run this by folks who deal in job descriptions for a living. This should help make it easier to use it in your organization. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 jwboyer at jdub.homelinux.org Fri Feb 23 16:51:12 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 23 Feb 2007 10:51:12 -0600 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <1172249263.4651.18.camel@erato.phig.org> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> Message-ID: <1172249472.24204.237.camel@zod.rchland.ibm.com> On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote: > On Wed, 2007-02-21 at 19:41 +0100, Thorsten Leemhuis wrote: > > Hi all! > > > > The idea to build Fedora (Extras) Packages for RHEL and compatible > > distros like CentOS in the scope of the Fedora Project is over half a > > year old now, but didn't really take of yet. This mail (and some other > > work in other places like the wiki) tries to actually get the idea > > running a bit more faster now in the hope that the project actually > > takes of soon. > > Thanks for stepping up and organizing us this far. It's really helping > make EPEL happen. > > > -- the package needs to be supported until the End Of Life (EOL) of the > > Distributions they were build for -- round about seven years. Sure, > > nobody of us knows if he still be around then. But you should not build > > packages for EPEL if you plan to moe oer to other stuff soon or find > > packaging really annoying > > One idea we want to promote is making the packaging into a job role > instead of a personal side-project. This is possible and useful where > your employer or other outside organization benefits from your package > in EPEL. For example, your infrastructure requires package Foo be > rebuilt in EPEL. If you make package maintenance part of your job role, > you gain: Is your intention to preclude people that _are_ doing it as a side project? josh From kevin.kofler at chello.at Fri Feb 23 16:50:54 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Feb 2007 16:50:54 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles (now SRPMs too) References: Message-ID: I updated my kdelibs4 package with a few fixes: - apply upstream patch to fix klauncher crash - hack around Qt 4 being built with no visibility support - install Qt Designer plugin and suggest rebuilding the kdepimlibs4 and kdebase4 packages against the new kdelibs4 because of the visibility patch (I bumped %{release} for that reason). The klauncher crash may or may not fix the "full KDE 4 session crashes" problem. The visibility patch works: the Qt Designer plugin now loads properly. SRPMs: http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdelibs4-3.80.3-2.fc6.kde.src.rpm http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdepimlibs4-3.80.3-2.fc6.kde.src.rpm http://osdn.dl.sourceforge.net/sourceforge/kde-redhat/kdebase4-3.80.3-2.fc6.kde.src.rpm Specfiles and patches only: http://www.tigen.org/kevin.kofler/pcprogs/kde-3.80.3-2-specs.tar.bz2 I hope these will make their way into the kde-redhat unstable repo soon. Kevin Kofler From mmcgrath at redhat.com Fri Feb 23 16:55:29 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 23 Feb 2007 10:55:29 -0600 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <45DC9246.6060307@leemhuis.info> References: <45DC9246.6060307@leemhuis.info> Message-ID: <45DF1C81.1080201@redhat.com> Thorsten Leemhuis wrote: > - get the inital batch of important and popular packages online into a > testing channel until end of march > I still haven't heard back from Stacy on this, I'll send a follow up. > I probably missed a lot of stuff. But that's why I wrote this mail, so > you can tell me and the other members of the EPEL Sig what we missed so > we can actually take care of it. > Emphasis on co-maintainership. -Mike From nphilipp at redhat.com Fri Feb 23 16:57:38 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 23 Feb 2007 17:57:38 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223171731.7c3946a7.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <1172246449.3710.11.camel@localhost.localdomain> <20070223171731.7c3946a7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1172249858.21806.5.camel@gibraltar.stuttgart.redhat.com> On Fri, 2007-02-23 at 17:17 +0100, Michael Schwendt wrote: > On Fri, 23 Feb 2007 11:00:49 -0500, Matthias Clasen wrote: > > > I hope you agree that a company needs internal communication channels. > > Sure, but I hope you agree that running a community project requires > additional communication channels. Nobody denies that. > > Do you also object to us talking to our cube neighbours directly, rather > > than using public irc ? > > No, ... and bad jokes are inappropriate and superfluous. Not on Fridays ;-P. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase 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 mmcgrath at redhat.com Fri Feb 23 16:58:50 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 23 Feb 2007 10:58:50 -0600 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <1172249472.24204.237.camel@zod.rchland.ibm.com> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> Message-ID: <45DF1D4A.5080002@redhat.com> Josh Boyer wrote: > On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote: > >> One idea we want to promote is making the packaging into a job role >> instead of a personal side-project. This is possible and useful where >> your employer or other outside organization benefits from your package >> in EPEL. For example, your infrastructure requires package Foo be >> rebuilt in EPEL. If you make package maintenance part of your job role, >> you gain: >> > > Is your intention to preclude people that _are_ doing it as a side > project? > not preclude but join them together. I suspect the climate for EPEL will be a lot different from Extras. It'll be interesting to see if someone like IBM comes in and starts working with Joe Blow on package B because IBM needs to roll it out to 20,000 customers. -Mike From mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 14:15:31 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 15:15:31 +0100 (CET) Subject: Slightly OT: bad rap for Fedora, and realistic effects Message-ID: <3266461.1172240131076.JavaMail.ngmail@webmail16> On Fri, 23 Feb 2007 08:17:36 -0500, Jesse Keating wrote: > On Friday 23 February 2007 07:35, Michael Schwendt wrote: > > * heavy use of Red Hat internal mailing-lists for Fedora related matters, > > This is complete BS. Disagree as much as you like, but please avoid the strong language. > Maybe one or three messages a month pop up on internal > lists, and those are immediately redirected to external lists. Repeatedly, there have been references to relevant topics on internal lists, involving Fedora or Core. I've pointed out a few examples long ago. With regard to the Fedora Merge, most recent is this one: https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00577.html Now, I guess somebody will deny that it's relevant discussion. Still, you cannot deny that internal lists plus interal IRC plus additional forms of internal communication don't do a community project any good when public communication channels are criticised for their poor s/n ratio. > > * more closed circles, in which decisions are made -- including mysteries > > like brew, koji, and code transfer for the new Updates System, > > These decisions were made at the Fedora summit, with the Fedora board and > other community folks, complete with an IRC channel during the live > discussions. Further discussion has happened in Fedora board meetings and > public Fedora lists. Which lists exactly? > > * unclear role of FESCo, not enough steering -- instead: the drive > > that "you don't need to be in FESCo to get something done", > > I don't even know what you mean by this. That's sad. But you're not listed as a FESCo member anyway. Perhaps I should lose my hope that somebody else in FESCo still has a clue what I refer to. Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 44,85 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From florin at andrei.myip.org Fri Feb 23 17:20:07 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Feb 2007 09:20:07 -0800 Subject: FC6 updates broken deps? In-Reply-To: <20070223125540.1384bc91.mschwendt.tmp0701.nospam@arcor.de> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <20070223125540.1384bc91.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45DF2247.5050808@andrei.myip.org> Michael Schwendt wrote: > > A common scenario for newbies, which make you bow your head in shame: You > had thought they would prefer the graphical package tools, you have not > recommended the command-line, but they know Google and have found lots of > documentation about how to install something with Yum. And what happens? > Metadata checksum failures on apparently all mirrors. ^C doesn't help. > Yum switches through all available mirrors. WTF? Some time later, 78 > updates are available. Newbie is caught in a loop of download failures, > mirror-switching, ^C attempts, low through-put, and reacts very surprised > and disappointed about "this Linux stuff". So true. :-( -- Florin Andrei http://florin.myip.org/ From kevin at scrye.com Fri Feb 23 17:23:39 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 23 Feb 2007 10:23:39 -0700 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070223102339.299b8741@ningauble.scrye.com> On Fri, 23 Feb 2007 13:35:17 +0100 mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > Still, the merge of Core+Extras will put the Fedora Project at a test. > There are several issues I still don't understand and which sometimes > make me shake my head in disbelief. For instance, but not limited to: Yeah, It's a big task, and there will be mis-steps I am sure, but we do the best we can and press on. ;) > > * heavy use of Red Hat internal mailing-lists for Fedora related > matters, I don't know off hand of anything like that. I think there has been a effort to make sure RedHat internal people know that they have to follow the package guidelines, etc. > > * weird procedures by which Red Hat's Fedora Core package owners need > sponsorship for cvs_extras and either get blanket approval or are > really "sponsored" by community contributors without that the > sponsors' responsibilities and duties are documented, Well, the problem is that all the current RedHat internal maintainers of packages formerly in "core" need access to CVS to maintain their packages. In the last FESCO meeting (see the wiki for meeting minutes), Warren talked about having a Redhat sponsor available at each physical RedHat site that would be able to help other maintainers there with guidelines and process questions and be able to sponsor them. I think thats a great idea. I think the responsibilities of sponsors are the same as they have always been (although no where written down), namely: - Make sure the people you sponsor try and follow the guidelines. - Help answer questions they may have. - Fix problems that they cause if mistakes are made and they can't figure out how to fix them. - Revoke sponsorship in the event that the person refuses to follow rules, and deal with that persons leftover packages. > * more closed circles, in which decisions are made -- including > mysteries like brew, koji, and code transfer for the new Updates > System, Yeah, but the problem here is that much of that is still in flux. From what I know: - brew = internal redhat build system. We don't need to care about it anymore. - koji = fork of brew blessed by the lawyers and available for Fedora use. This will be our new build system hopefully if it can all be made to work. - Updates system - No idea where that is... it is still not finished from what I know. Perhaps someone else could fill this in? > > * unclear role of FESCo, not enough steering -- instead: the drive > that "you don't need to be in FESCo to get something done", What items do you think need addressing? The problem is that there is all kinds of change right now. I suspect once the buildsystem is figured and the merge is figured we can look at more longer term issues. Please do bring up on the lists or if you prefer personal email to me any issues you want to have addressed. > * the community used to have full control over Extras -- this control > is lost, instead: even sponsors would need to ask their sponsorees > for permission before they could fix or veto anything in CVS, Yeah, I think that should be changed. I think either sponsors should be able to access any package at all, or any package that has a maintainer they sponsored at the least. > * changes to infrastructure and policies/guidelines, respectively, > without prior communication, Such as? The package review guidelines have been a big source of confusion lately, but nothing was changed until it was pretty well agreed on in maintainers, then approved by FESCO. I agree that the wiki should be updated to reflect this. I will see if I can get someone to do that or do it myself today. > * annoying cross-posts due to an overly complex and unclear > choice of mailing-lists -- still: the feeling that some lists are > missing, because vital communication and coordination (e.g. about > things done in Core) is missing. Agreed. I wish we would just move all the mailing lists per thl's last suggestion. It would be pain and another bit of chaos, but I think we should just bite the bullet and do it. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Fri Feb 23 17:39:30 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Feb 2007 12:39:30 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45DEEA21.50007@poolshark.org> References: <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> <45DE229D.4010306@poolshark.org> <20070223005105.GA31821@jadzia.bu.edu> <45DEB9CA.60805@poolshark.org> <20070223115642.GA13939@jadzia.bu.edu> <45DEEA21.50007@poolshark.org> Message-ID: <20070223173930.GA7496@jadzia.bu.edu> On Fri, Feb 23, 2007 at 02:20:33PM +0100, Denis Leroy wrote: > >>I love yum-utils, but I was talking about all the yum plugins packages > >>out there : [...] > >$ rpm -q --qf '%{sourcerpm}\n' yum-skip-broken > >yum-utils-1.1.1-1.fc7.src.rpm > I'm not sure I get your point. Are you saying all the 17 plugins were > written by the same person ? My point is: most of the plugins should be My point is, these plugins are all collected as part of the yum-utils rpm already. There's little reason to move them to the yum package. > part of the core yum package and therefore installed by default on all > fedora distros ('installed' not being equal to 'enabled by default'), > and people - community members - should be working on making yum better, > rather than writing plugins to work around the known yum limitations. If you want them installed by default, why not just advocate for that? That's a whole separate issue. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Fri Feb 23 17:43:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 23 Feb 2007 23:13:10 +0530 Subject: FC6 updates broken deps? In-Reply-To: <45DEEA21.50007@poolshark.org> References: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> <45DE229D.4010306@poolshark.org> <20070223005105.GA31821@jadzia.bu.edu> <45DEB9CA.60805@poolshark.org> <20070223115642.GA13939@jadzia.bu.edu> <45DEEA21.50007@poolshark.org> Message-ID: <45DF27AE.1060409@fedoraproject.org> Denis Leroy wrote: > Matthew Miller wrote: >> On Fri, Feb 23, 2007 at 10:54:18AM +0100, Denis Leroy wrote: >>>> But all these things are already in yum-utils. >>> I love yum-utils, but I was talking about all the yum plugins >>> packages out there : >>> # yum list | grep ^yum- | wc -l >>> 17 >> >> $ rpm -q --qf '%{sourcerpm}\n' yum-skip-broken >> yum-utils-1.1.1-1.fc7.src.rpm > > I'm not sure I get your point. Are you saying all the 17 plugins were > written by the same person ? My point is: most of the plugins should be > part of the core yum package and therefore installed by default on all > fedora distros ('installed' not being equal to 'enabled by default'), > and people - community members - should be working on making yum better, > rather than writing plugins to work around the known yum limitations. Does extensions in Firefox extend the capabilities of Firefox or work around its limitations? Rahul From rdieter at math.unl.edu Fri Feb 23 17:51:38 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Feb 2007 11:51:38 -0600 Subject: Experimental KDE 3.80.3 specfiles References: Message-ID: Kevin Kofler wrote: > Kevin Kofler chello.at> writes: >> - error='QLibrary::resolve_sys: Symbol "qt_plugin_instance" undefined >> in /usr/lib/qt4/plugins/designer/kdewidgets.so > > I found the problem: qt4 in FE6 is built without visibility support Hrm, can't remember the reason (if any) why I did that. Well, maybe I'll try (re)enabling that for devel/rawhide, to see what breaks. (: -- Rex From smooge at gmail.com Fri Feb 23 17:55:06 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 23 Feb 2007 10:55:06 -0700 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <45DF1D4A.5080002@redhat.com> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> <45DF1D4A.5080002@redhat.com> Message-ID: <80d7e4090702230955x73e97bdatb78d2554d217be7f@mail.gmail.com> On 2/23/07, Mike McGrath wrote: > Josh Boyer wrote: > > On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote: > > > >> One idea we want to promote is making the packaging into a job role > >> instead of a personal side-project. This is possible and useful where > >> your employer or other outside organization benefits from your package > >> in EPEL. For example, your infrastructure requires package Foo be > >> rebuilt in EPEL. If you make package maintenance part of your job role, > >> you gain: > >> > > > > Is your intention to preclude people that _are_ doing it as a side > > project? > > > not preclude but join them together. I suspect the climate for EPEL > will be a lot different from Extras. It'll be interesting to see if > someone like IBM comes in and starts working with Joe Blow on package B > because IBM needs to roll it out to 20,000 customers. > One of the things I have run into for needs for Extras for Enterprise at various sites is that there are three different camps you need to be able to satisfy. Camp1 wants the same release for the lifetime of the product until it can no longer be patched. So if clamav-0.88.1 was what was released then they want patches backported until the end of the 7 years of support for say RHEL-4. So when 4.5.1 comes out, they want only things updated that have security updates and not API/ABI changes. Currently they will take FCL-3 for say RHEL-4 and use whatever is in that repo til time ends. Camp2 wants general updates to match the quarterly release cycle. They dont want to upgrade every 4 days to the latest, but they want technology upgrades at regular times. So say clamav is the same for RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at that time. Currently they are taking a src.rpm from say FCL-5 and when FCL-6 comes out upgrading to what was in there. They will upgrade other stuff when it is needed. Camp3 wants to get the latest stuff when it is available. They need it for whatever project and are basically wanting a 'barely-qa'd rawhide'. Currently they are taking Fedora rawhide and compiling it to meet daily/weekly needs. One thing we need to figure out what we can afford to do. I think Camp3 is the easiest for volunteers to do.. and Camp2 has the largest number of people. Camp1 should be left to people who are going to be paid for it. It takes the most work and has the least 'reward'. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mschwendt.tmp0701.nospam at arcor.de Fri Feb 23 18:05:24 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 23 Feb 2007 19:05:24 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223102339.299b8741@ningauble.scrye.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> Message-ID: <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> On Fri, 23 Feb 2007 10:23:39 -0700, Kevin Fenzi wrote: > I think the responsibilities of sponsors are the same as they have > always been (although no where written down), namely: The fact that they are not written down makes it useless. After several years of using the sponsorship system, we don't even have a draft somewhere in the Wiki. Why is that? Because nobody has the time to do it? Or because nobody knows what the sponsors' responsibilities are actually? Do we use the terms "sponsor" and "sponsorship" just for fun or because it is a hardcoded scheme in the FAS? Can we assume that every sponsored contributor is observed by a sponsor during activities in cvs and bugzilla, for example? Does that apply also to Red Hat packagers, who should know their stuff, and blanket approvals? Is sponsorship a *life-time* process? For example, some of the fellow contributors I've sponsored have been the FESCo chair or still are FESCo members. Others can be trusted, also with regard to their technical abilities. How does that affect the person's status in the FAS and my responsibilities as a sponsor of those people? > - Fix problems that they cause if mistakes are made and they can't > figure out how to fix them. You know this has become impossible with the ACLs. The original intent of the Vacation page in the Wiki is void, too. Packagers would need to lift the acls on all their packagers, before they could allow trusted contributors to help out during vacation. > - Revoke sponsorship in the event that the person refuses to follow > rules, and deal with that persons leftover packages. The second part is new to me. Leftover packages would be orphaned. > - koji = fork of brew blessed by the lawyers and available for Fedora > use The source code smelled like that, but relevant lists don't mention koji with a single word. > - Updates system - No idea where that is... it is still not finished > from what I know. Perhaps someone else could fill this in? I know where it is, I am subscribed to the Wiki page, too, but there is some secret relationship between it and what is used at Red Hat. Smells a bit like another fork/semi-rewrite of an existing code base, which creates a situation like "aha, somebody is working on transfering more and more existant code piece by piece, so it's just matter of time before all of it is published". > > * unclear role of FESCo, not enough steering -- instead: the drive > > that "you don't need to be in FESCo to get something done", > > What items do you think need addressing? Guiding the community to prepare for Fedora 7. The contributor community needs a roadmap. There are 1129 fc6 packages (based on their src.rpm name) in the devel tree, while Core has reached test2 already. The upgradecheck report lists several invalid upgrade paths. The broken deps report lists other issues. The FE7Target tracker lists even more issues. And I guarantee, more issues are undiscovered. From mastahnke at gmail.com Fri Feb 23 18:07:53 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 23 Feb 2007 12:07:53 -0600 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <80d7e4090702230955x73e97bdatb78d2554d217be7f@mail.gmail.com> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> <45DF1D4A.5080002@redhat.com> <80d7e4090702230955x73e97bdatb78d2554d217be7f@mail.gmail.com> Message-ID: <7874d9dd0702231007x16030f2fged8779927a03824c@mail.gmail.com> On 2/23/07, Stephen John Smoogen wrote: > On 2/23/07, Mike McGrath wrote: > > Josh Boyer wrote: > > > On Fri, 2007-02-23 at 08:47 -0800, Karsten Wade wrote: > > > > > >> One idea we want to promote is making the packaging into a job role > > >> instead of a personal side-project. This is possible and useful where > > >> your employer or other outside organization benefits from your package > > >> in EPEL. For example, your infrastructure requires package Foo be > > >> rebuilt in EPEL. If you make package maintenance part of your job role, > > >> you gain: > > >> > > > > > > Is your intention to preclude people that _are_ doing it as a side > > > project? > > > If a company has need for package foo that requires 15 other packages, would you like that company to be responsable for the 15 dependencies also? > > not preclude but join them together. I suspect the climate for EPEL > > will be a lot different from Extras. It'll be interesting to see if > > someone like IBM comes in and starts working with Joe Blow on package B > > because IBM needs to roll it out to 20,000 customers. > > > > One of the things I have run into for needs for Extras for Enterprise > at various sites is that there are three different camps you need to > be able to satisfy. > > Camp1 wants the same release for the lifetime of the product until it > can no longer be patched. So if clamav-0.88.1 was what was released > then they want patches backported until the end of the 7 years of > support for say RHEL-4. So when 4.5.1 comes out, they want only things > updated that have security updates and not API/ABI changes. Currently > they will take FCL-3 for say RHEL-4 and use whatever is in that repo > til time ends. > > Camp2 wants general updates to match the quarterly release cycle. They > dont want to upgrade every 4 days to the latest, but they want > technology upgrades at regular times. So say clamav is the same for > RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at > that time. Currently they are taking a src.rpm from say FCL-5 and when > FCL-6 comes out upgrading to what was in there. They will upgrade > other stuff when it is needed. > > Camp3 wants to get the latest stuff when it is available. They need it > for whatever project and are basically wanting a 'barely-qa'd > rawhide'. Currently they are taking Fedora rawhide and compiling it to > meet daily/weekly needs. > > One thing we need to figure out what we can afford to do. I think > Camp3 is the easiest for volunteers to do.. and Camp2 has the largest > number of people. Camp1 should be left to people who are going to be > paid for it. It takes the most work and has the least 'reward'. > Couldn't have said this better myself. This has been where most of questions about EPEL have stemmed from. > > -- > Stephen J Smoogen. -- CSIRT/Linux System Administrator > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From florin at andrei.myip.org Fri Feb 23 18:10:28 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Feb 2007 10:10:28 -0800 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <16de708d0702221432m578a1889ye344f61cf665588a@mail.gmail.com> References: <16de708d0702221432m578a1889ye344f61cf665588a@mail.gmail.com> Message-ID: <45DF2E14.2080103@andrei.myip.org> Arthur Pemberton wrote: > > And this may or may not be the correct -list for this, but here goes. > I think its fair to say that a lot of the louder voices on the > internet do not like Fedora for fair and unfair reasons. My question > is what does this do to Fedora, and RedHat by association. The dogs are barking, the caravan keeps going. (meaning: much ado about nothing) -- Florin Andrei http://florin.myip.org/ From dennis at ausil.us Fri Feb 23 18:13:58 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 23 Feb 2007 12:13:58 -0600 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <45DF1C81.1080201@redhat.com> References: <45DC9246.6060307@leemhuis.info> <45DF1C81.1080201@redhat.com> Message-ID: <200702231213.59033.dennis@ausil.us> On Friday 23 February 2007 10:55:29 am Mike McGrath wrote: > Thorsten Leemhuis wrote: > > - get the inital batch of important and popular packages online into a > > testing channel until end of march > > I still haven't heard back from Stacy on this, I'll send a follow up. we have space now i need to work out how to get packages there. http://download.fedora.redhat.com/pub/epel/ > > I probably missed a lot of stuff. But that's why I wrote this mail, so > > you can tell me and the other members of the EPEL Sig what we missed so > > we can actually take care of it. > > Emphasis on co-maintainership. > > -Mike -- Dennis Gilmore, RHCE From wtogami at redhat.com Fri Feb 23 18:36:33 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Feb 2007 13:36:33 -0500 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45DF3431.8020905@redhat.com> Michael Schwendt wrote: > On Fri, 23 Feb 2007 10:23:39 -0700, Kevin Fenzi wrote: > >> I think the responsibilities of sponsors are the same as they have >> always been (although no where written down), namely: > > The fact that they are not written down makes it useless. > This is a fair criticism that I've been thinking to solve lately, especially with the need to bring on many additional cvsextras members from the RH engineers. >> - Fix problems that they cause if mistakes are made and they can't >> figure out how to fix them. > > You know this has become impossible with the ACLs. The original intent of > the Vacation page in the Wiki is void, too. Packagers would need to lift > the acls on all their packagers, before they could allow trusted > contributors to help out during vacation. PLEASE STOP ASSUMING HOW THINGS ARE TODAY ARE HOW WE WANT IT TO BE FOREVER. https://admin.fedoraproject.org/pkgdb/ Toshio has been making some faster than expected progress on the PackageDB. The first goal is to get rid of owners.list and to manage the ACL's entirely via the database. Later possible steps in the evolution of this system include: - (discussed yesterday in #fedora-admin) group and "rank" based ACL's. For example, as a package owner I may want any cvsextras rank to have access to most of my packages. But I may want only sponsor and higher ranks to have write access to spamassassin. groups might also be useful for convenient group maintenance of SIG's, like Games SIG. - There is a strong desire to allow a sponsor to have some level of control over a sponsoree's packages, but the exact policy details of how to do this has to be figured out. - Drive package reviews with an optimally designed workflow, getting rid of all the extraneous noise and ambiguity of using Bugzilla for this purpose. There are a number of large moving pieces now, and you are right that need to be doing a better job of communicating the overall status and roadmap of all this. Hm... Warren From kmaraas at broadpark.no Fri Feb 23 19:10:10 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Fri, 23 Feb 2007 20:10:10 +0100 Subject: F7t2 and QA Meeting In-Reply-To: <20070223143055.GC7609@devserv.devel.redhat.com> References: <1171991344.3072.41.camel@metroid.rdu.redhat.com> <45DB3324.3040407@bellsouth.net> <20070221034415.GC32402@redhat.com> <20070221122743.GB2557@devserv.devel.redhat.com> <20070221175105.GG19851@redhat.com> <1172142877.2960.1.camel@rivendell> <20070222204750.GA20999@devserv.devel.redhat.com> <20070223005105.GA25845@redhat.com> <1172238621.4455.1.camel@rivendell> <20070223143055.GC7609@devserv.devel.redhat.com> Message-ID: <1172257810.2968.6.camel@rivendell> fre, 23.02.2007 kl. 09.30 -0500, skrev Alan Cox: > On Fri, Feb 23, 2007 at 02:50:21PM +0100, Kjartan Maraas wrote: > > Yenta O2: res at 0x94/0xD4: 00/ea > > Yenta O2: enabling read prefetch/write burst > > BUG: warning at drivers/pci/pci.c:823/pcim_enable_device() (Not tainted) > > Known bug, fix in the libata GIT tree already. > > > Restarting tasks ... done. > > ata1.00: simplex DMA is claimed by other device, disabling DMA > > ata1.00: configured for PIO4 > > Known bug, working on it at the emoment. > Great. Thanks for the feedback. Cheers Kjartan From drago01 at gmail.com Fri Feb 23 19:07:21 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 23 Feb 2007 20:07:21 +0100 Subject: NVIDIA graphics driver version format announcement In-Reply-To: <20070222224107.GB20372@neu.nirvana> References: <7c1574a90702221330m2661b2d5he2466c75d90c075d@mail.gmail.com> <20070222224107.GB20372@neu.nirvana> Message-ID: <45DF3B69.5080909@gmail.com> Axel Thimm wrote: > On Thu, Feb 22, 2007 at 01:30:03PM -0800, Lonni J Friedman wrote: > >> This post is an early notification to anyone that repackages the >> NVIDIA UNIX Graphics Driver. >> >> Starting in the Release 100 driver series, NVIDIA will revise the >> format of the version number for the UNIX Graphics Driver. >> >> In the past, the NVIDIA UNIX Graphics Driver version format was >> "1.0-XXXX" (e.g., "1.0-9746"). Starting in Release 100, the new >> format will be a collection of period-separated fields (e.g., >> "100.17.03"). >> >> The left-most field will indicate the major release series ("Release >> 100", Release "105", etc.). The second field and optional third or >> additional fields will be used for NVIDIA tracking. >> >> The version number will be a variable number of fields, however it >> will consist only of digits and periods. >> >> This version format change will apply to both the package filenames, >> and the names of the libraries. >> >> Examples: >> >> /usr/lib/libGLcore.so.100.17 >> > > do you intend to do so with libGL.so.1, too? Because that would break > a lot of stuff and would render the nvidia-graphics libs not adequate > for in-place-substitutes for any system shipped libGL.so.1 anymore. > > libGL.so.1 was a symlink in the old releases so I think its safe to say that it will be a symlink to libGL.so.100.17 >> NVIDIA-Linux-x86-100.17-pkg1.run >> NVIDIA-Linux-x86_64-100.17-pkg2.run >> NVIDIA-Solaris-x86-100.17.run >> NVIDIA-FreeBSD-x86-100.17.tar.gz >> >> # glxinfo | grep "OpenGL version string" >> OpenGL version string: 2.1.1 NVIDIA 100.17 >> >> # cat /proc/driver/nvidia/version >> NVRM version: NVIDIA UNIX x86 Kernel Module 100.17 Mon Feb 12 >> 14:37:08 PST 2007 >> GCC version: gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) >> >> After the Release 100 driver series is released, we will make a >> similar change to the 1.0-96xx and 1.0-71xx legacy GPU release >> branches. >> >> Thanks, >> Lonni J Friedman >> NVIDIA Corp >> >> > > From avi at argo.co.il Fri Feb 23 19:09:22 2007 From: avi at argo.co.il (Avi Kivity) Date: Fri, 23 Feb 2007 21:09:22 +0200 Subject: [Mandrakeot] ESR gives up on Fedora Message-ID: <45DF3BE2.3010204@argo.co.il> Simo Sorce wrote: > You should understand that "property" is natural only for physical > objects, just because possession of a physical object can be controlled > by physical means and cannot be easily replicated. > > Abstract objects like ideas, but also anything that can be replicated at > zero cost without destroying the original, can't be subject to real > property. > You mean I can't put a license on my code that says: you may use this, but if you change it and redistribute it you must also redistribute your changes? Because that also means that I control what is done with my code. You make it sound like all ideas should be in the public domain. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Axel.Thimm at ATrpms.net Fri Feb 23 19:14:52 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 23 Feb 2007 20:14:52 +0100 Subject: NVIDIA graphics driver version format announcement In-Reply-To: <45DF3B69.5080909@gmail.com> References: <7c1574a90702221330m2661b2d5he2466c75d90c075d@mail.gmail.com> <20070222224107.GB20372@neu.nirvana> <45DF3B69.5080909@gmail.com> Message-ID: <20070223191452.GI21659@neu.nirvana> On Fri, Feb 23, 2007 at 08:07:21PM +0100, dragoran wrote: > Axel Thimm wrote: > >On Thu, Feb 22, 2007 at 01:30:03PM -0800, Lonni J Friedman wrote: > > > >>This post is an early notification to anyone that repackages the > >>NVIDIA UNIX Graphics Driver. > >> > >>Starting in the Release 100 driver series, NVIDIA will revise the > >>format of the version number for the UNIX Graphics Driver. > >> > >>In the past, the NVIDIA UNIX Graphics Driver version format was > >>"1.0-XXXX" (e.g., "1.0-9746"). Starting in Release 100, the new > >>format will be a collection of period-separated fields (e.g., > >>"100.17.03"). > >> > >>The left-most field will indicate the major release series ("Release > >>100", Release "105", etc.). The second field and optional third or > >>additional fields will be used for NVIDIA tracking. > >> > >>The version number will be a variable number of fields, however it > >>will consist only of digits and periods. > >> > >>This version format change will apply to both the package filenames, > >>and the names of the libraries. > >> > >>Examples: > >> > >> /usr/lib/libGLcore.so.100.17 > >> > > > >do you intend to do so with libGL.so.1, too? Because that would break > >a lot of stuff and would render the nvidia-graphics libs not adequate > >for in-place-substitutes for any system shipped libGL.so.1 anymore. > > > > > libGL.so.1 was a symlink in the old releases so I think its safe to say > that it will be > a symlink to libGL.so.100.17 It's not only the symlink that matters, but the SONAME. > >> NVIDIA-Linux-x86-100.17-pkg1.run > >> NVIDIA-Linux-x86_64-100.17-pkg2.run > >> NVIDIA-Solaris-x86-100.17.run > >> NVIDIA-FreeBSD-x86-100.17.tar.gz > >> > >> # glxinfo | grep "OpenGL version string" > >> OpenGL version string: 2.1.1 NVIDIA 100.17 > >> > >> # cat /proc/driver/nvidia/version > >> NVRM version: NVIDIA UNIX x86 Kernel Module 100.17 Mon Feb 12 > >>14:37:08 PST 2007 > >> GCC version: gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) > >> > >>After the Release 100 driver series is released, we will make a > >>similar change to the 1.0-96xx and 1.0-71xx legacy GPU release > >>branches. > >> > >>Thanks, > >>Lonni J Friedman > >>NVIDIA Corp > >> > >> > > > > > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Fri Feb 23 19:35:37 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 23 Feb 2007 14:35:37 -0500 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <200702231046.52584.jkeating@redhat.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> Message-ID: <1172259337.4278.2.camel@Chuck> On Fri, 2007-02-23 at 10:46 -0500, Jesse Keating wrote: > On Friday 23 February 2007 10:25, Michael Schwendt wrote: > > > > > > * unclear role of FESCo, not enough steering -- instead: the drive > > > > that "you don't need to be in FESCo to get something done", > > > > > > I don't even know what you mean by this. > > > > That's sad. But you're not listed as a FESCo member anyway. > > That's unfortunate, as I was dragged back into FESCo recently. My fault for forgetting to update the FESCo page for the the recent FESCo additions. I'll update the page accordingly. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Fri Feb 23 19:38:38 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 23 Feb 2007 20:38:38 +0100 Subject: FC6 updates broken deps? In-Reply-To: <45DF27AE.1060409@fedoraproject.org> References: <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <20070222174609.GB6591@devserv.devel.redhat.com> <45DDF1B4.5090001@poolshark.org> <20070222201706.GA10813@jadzia.bu.edu> <45DE229D.4010306@poolshark.org> <20070223005105.GA31821@jadzia.bu.edu> <45DEB9CA.60805@poolshark.org> <20070223115642.GA13939@jadzia.bu.edu> <45DEEA21.50007@poolshark.org> <45DF27AE.1060409@fedoraproject.org> Message-ID: <20070223203838.59ce1530@nausicaa.camperquake.de> Hi. Rahul Sundaram wrote: > Does extensions in Firefox extend the capabilities of Firefox or work > around its limitations? That's a question of definitons. Both, if you like. -- TRUST NO ONE. KEEP YOUR LASER HANDY. THE COMPUTER IS YOUR FRIEND. -- "Paranoia," Avalon Hill From dominik at greysector.net Fri Feb 23 19:43:51 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 23 Feb 2007 20:43:51 +0100 Subject: Goodbye, Fedora In-Reply-To: <45DC76A2.5000404@fedoraproject.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> Message-ID: <20070223194351.GB16285@ryvius.pekin.waw.pl> On Wednesday, 21 February 2007 at 17:43, Rahul Sundaram wrote: > Eric S. Raymond wrote: [...] > >* Allowing RPM development to drift and stagnate -- then adding > > another layer of complexity, bugs, and wretched performance with yum. > > RPM indeed drifted but I dont think it actually stagnated. Anyway > http://rpm.org for more details. > RPM doesnt do automatic dependency resolving. Actually, that sentence is not exactly true. Given a rpmdb with all available packages, rpm can suggest packages to satisfy missing dependencies. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From ssorce at redhat.com Fri Feb 23 19:46:17 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 Feb 2007 14:46:17 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45DF3BE2.3010204@argo.co.il> References: <45DF3BE2.3010204@argo.co.il> Message-ID: <1172259977.13382.31.camel@localhost.localdomain> On Fri, 2007-02-23 at 21:09 +0200, Avi Kivity wrote: > Simo Sorce wrote: > > You should understand that "property" is natural only for physical > > objects, just because possession of a physical object can be > controlled > > by physical means and cannot be easily replicated. > > > > Abstract objects like ideas, but also anything that can be > replicated at > > zero cost without destroying the original, can't be subject to real > > property. > > > > You mean I can't put a license on my code that says: you may use > this, > but if you change it and redistribute it you must also redistribute > your > changes? No, what I mean is that "Intellectual Property" is not natural law, children do not understand ownership of a song, they just sing it if they like. Children do understand perfectly ownership of an apple, just because only one can hold the same apple, and it can be eaten only once. "Intellectual Property" it is an artificial construct made up by societies to achieve some goal in the belief that these rules are an overall benefit to the society as a whole. For the American society the goal should be to "promote the Progress of Science and useful Arts"(from the constitution), the mean is Copyright/Patents. You cannot physically posses a piece of code, you can physically own the specific instance of the code you have saved on your disk. But the code by itself is abstract, if I copy it from you, you still have your copy and it is intact. So "taking" your code didn't leave you without it. Property make sense only when taking something from someone leaves him without it. Copyright can be seen as a form of property, as if I have the copyright on something, you don't. But you have to realize that this works at a different level. You own the "right to copy" the code, an artifact made by law, you do not technically own the code itself. > Because that also means that I control what is done with my code. > You > make it sound like all ideas should be in the public domain. Ideas are technically and by law in the "public domain", as they are abstract and you can't copyright nor patent an ideas. Code is a different thing, see above. Finally, can we close this thread on a devel list? I am happy to debate around law philosophy elsewhere if you like. Simo. /IANAL -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From sundaram at fedoraproject.org Fri Feb 23 19:47:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 24 Feb 2007 01:17:50 +0530 Subject: Goodbye, Fedora In-Reply-To: <20070223194351.GB16285@ryvius.pekin.waw.pl> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070223194351.GB16285@ryvius.pekin.waw.pl> Message-ID: <45DF44E6.1050107@fedoraproject.org> Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 21 February 2007 at 17:43, Rahul Sundaram wrote: >> Eric S. Raymond wrote: > [...] >>> * Allowing RPM development to drift and stagnate -- then adding >>> another layer of complexity, bugs, and wretched performance with yum. >> RPM indeed drifted but I dont think it actually stagnated. Anyway >> http://rpm.org for more details. >> RPM doesnt do automatic dependency resolving. > > Actually, that sentence is not exactly true. Given a rpmdb with all available > packages, rpm can suggest packages to satisfy missing dependencies. > Pointing out libraries or packages is different from automatically downloading and actually resolving them. Rahul From fedora at leemhuis.info Fri Feb 23 20:01:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Feb 2007 21:01:40 +0100 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <80d7e4090702230955x73e97bdatb78d2554d217be7f@mail.gmail.com> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> <45DF1D4A.5080002@redhat.com> <80d7e4090702230955x73e97bdatb78d2554d217be7f@mail.gmail.com> Message-ID: <45DF4824.10205@leemhuis.info> Stephen John Smoogen schrieb: > > One of the things I have run into for needs for Extras for Enterprise > at various sites is that there are three different camps you need to > be able to satisfy. > > Camp1 wants the same release for the lifetime of the product until it > can no longer be patched. So if clamav-0.88.1 was what was released > then they want patches backported until the end of the 7 years of > support for say RHEL-4. So when 4.5.1 comes out, they want only things > updated that have security updates and not API/ABI changes. Currently > they will take FCL-3 for say RHEL-4 and use whatever is in that repo > til time ends. > > Camp2 wants general updates to match the quarterly release cycle. They > dont want to upgrade every 4 days to the latest, but they want > technology upgrades at regular times. So say clamav is the same for > RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at > that time. Currently they are taking a src.rpm from say FCL-5 and when > FCL-6 comes out upgrading to what was in there. They will upgrade > other stuff when it is needed. > > Camp3 wants to get the latest stuff when it is available. They need it > for whatever project and are basically wanting a 'barely-qa'd > rawhide'. Currently they are taking Fedora rawhide and compiling it to > meet daily/weekly needs. > > One thing we need to figure out what we can afford to do. I think > Camp3 is the easiest for volunteers to do.. and Camp2 has the largest > number of people. Camp1 should be left to people who are going to be > paid for it. It takes the most work and has the least 'reward'. My 2 cent: Agreed for Camp1 -- it should be left to people who are going to be paid for it. For the other stuff: I'm targeting something like a mix in the middle between Camp2 and Camp3 (with some bits of Camp1 maybe) for EPEL (maybe a bit more closer to Camp2 than Camp3). Always the latest stuff IMHO is what we have Fedora for; I also think that's its unrealistic to even try to always ship the latest apps: Just try now to build a certain apps from Extras for RHEL4 -- you will run into trouble now and then, as RHEL4 ships with gtk2-2.4, but there are quite a few apps these days that require gtk2-2.6. Cu thl From tbrinkman at sbcglobal.net Fri Feb 23 20:03:35 2007 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Fri, 23 Feb 2007 14:03:35 -0600 Subject: Goodbye, Fedora In-Reply-To: <1172226119.5995.7.camel@localhost.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702210845.07064.tbrinkman@sbcglobal.net> <1172226119.5995.7.camel@localhost.localdomain> Message-ID: <200702231403.36059.tbrinkman@sbcglobal.net> On Friday 23 February 2007, Lyvim Xaphir wrote: > 2.6.19-1.2911.fc6 is running on my primary workstation not > including my five other test boxes. > > LX "About fedora-devel-list English (USA) This list is only for discussion of development issues in the Fedora Project. THIS IS NOT A SUPPORT LIST. THIS LIST IS FOR CORE DEVELOPMENT DISCUSSION ONLY." (their emphasis, not mine) https://www.redhat.com/mailman/listinfo/fedora-devel-list Take your moronic B$ back to OT, where it's at least tolerated, found amusing. As is ESR I apologize to the rest of y'all -- Tom Brinkman Corpus Christi, Texas From dominik at greysector.net Fri Feb 23 20:05:20 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 23 Feb 2007 21:05:20 +0100 Subject: Goodbye, Fedora In-Reply-To: <45DF44E6.1050107@fedoraproject.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC76A2.5000404@fedoraproject.org> <20070223194351.GB16285@ryvius.pekin.waw.pl> <45DF44E6.1050107@fedoraproject.org> Message-ID: <20070223200520.GC16285@ryvius.pekin.waw.pl> On Friday, 23 February 2007 at 20:47, Rahul Sundaram wrote: > Dominik 'Rathann' Mierzejewski wrote: > >On Wednesday, 21 February 2007 at 17:43, Rahul Sundaram wrote: > >>Eric S. Raymond wrote: > >[...] > >>>* Allowing RPM development to drift and stagnate -- then adding > >>> another layer of complexity, bugs, and wretched performance with yum. > >>RPM indeed drifted but I dont think it actually stagnated. Anyway > >>http://rpm.org for more details. > >>RPM doesnt do automatic dependency resolving. > > > >Actually, that sentence is not exactly true. Given a rpmdb with all > >available > >packages, rpm can suggest packages to satisfy missing dependencies. > > > > Pointing out libraries or packages is different from automatically > downloading and actually resolving them. Not very much. It actually resolves them (after all, rpm operates on rpmdb), it just can't download them. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mastahnke at gmail.com Fri Feb 23 20:08:25 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 23 Feb 2007 14:08:25 -0600 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <45DF4824.10205@leemhuis.info> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> <45DF1D4A.5080002@redhat.com> <80d7e4090702230955x73e97bdatb78d2554d217be7f@mail.gmail.com> <45DF4824.10205@leemhuis.info> Message-ID: <7874d9dd0702231208s2977dca0pd8d05e3ed9424c10@mail.gmail.com> On 2/23/07, Thorsten Leemhuis wrote: > Stephen John Smoogen schrieb: > > > > One of the things I have run into for needs for Extras for Enterprise > > at various sites is that there are three different camps you need to > > be able to satisfy. > > > > Camp1 wants the same release for the lifetime of the product until it > > can no longer be patched. So if clamav-0.88.1 was what was released > > then they want patches backported until the end of the 7 years of > > support for say RHEL-4. So when 4.5.1 comes out, they want only things > > updated that have security updates and not API/ABI changes. Currently > > they will take FCL-3 for say RHEL-4 and use whatever is in that repo > > til time ends. > > > > Camp2 wants general updates to match the quarterly release cycle. They > > dont want to upgrade every 4 days to the latest, but they want > > technology upgrades at regular times. So say clamav is the same for > > RHEL-4.5.0 but want 4.6.0 to have whatever is considered stable at > > that time. Currently they are taking a src.rpm from say FCL-5 and when > > FCL-6 comes out upgrading to what was in there. They will upgrade > > other stuff when it is needed. > > > > Camp3 wants to get the latest stuff when it is available. They need it > > for whatever project and are basically wanting a 'barely-qa'd > > rawhide'. Currently they are taking Fedora rawhide and compiling it to > > meet daily/weekly needs. > > > > One thing we need to figure out what we can afford to do. I think > > Camp3 is the easiest for volunteers to do.. and Camp2 has the largest > > number of people. Camp1 should be left to people who are going to be > > paid for it. It takes the most work and has the least 'reward'. > > My 2 cent: > > Agreed for Camp1 -- it should be left to people who are going to be paid > for it. > > For the other stuff: I'm targeting something like a mix in the middle > between Camp2 and Camp3 (with some bits of Camp1 maybe) for EPEL (maybe > a bit more closer to Camp2 than Camp3). Always the latest stuff IMHO is > what we have Fedora for; I also think that's its unrealistic to even try > to always ship the latest apps: Just try now to build a certain apps > from Extras for RHEL4 -- you will run into trouble now and then, as > RHEL4 ships with gtk2-2.4, but there are quite a few apps these days > that require gtk2-2.6. > > Cu > thl > Has the demand for one particular type of application been higher than another? For example, most shops I see with RHEL/CentOS are in runlevel 3, so QT/GTK applications are minimal. Is anyone seeing things that are different? Also, will things like Tremulous be allwoed in EPEL? It's not that I want it in there, I am just curious. I would love to show real value of EPEL to my employer as it matures. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From alan at redhat.com Fri Feb 23 20:22:45 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 23 Feb 2007 15:22:45 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45DF3BE2.3010204@argo.co.il> References: <45DF3BE2.3010204@argo.co.il> Message-ID: <20070223202245.GA30297@devserv.devel.redhat.com> On Fri, Feb 23, 2007 at 09:09:22PM +0200, Avi Kivity wrote: > > zero cost without destroying the original, can't be subject to real > > property. > > > You mean I can't put a license on my code that says: you may use this, > but if you change it and redistribute it you must also redistribute your > changes? So called "IPR" isn't a property right, its a temporary monopoly right - if you call them "Intellectual Monopoly Rights" it makes much more sense both in how the work, what they do and how they need to be regulated > Because that also means that I control what is done with my code. You > make it sound like all ideas should be in the public domain. That is the natural order of things. "Information wants to be free" is pretty sound economics. Copyright and friends exist[ed] to motivate people to behave in a way that benefitted society. Alan From tonynelson at georgeanelson.com Fri Feb 23 20:24:02 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 23 Feb 2007 15:24:02 -0500 Subject: yum and Ctl-C (was Re: FC6 updates broken deps? In-Reply-To: <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> Message-ID: At 2:28 PM +0100 2/23/07, Piotr Baranowski wrote: >Alan Cox wrote(a): >> On Fri, Feb 23, 2007 at 10:17:23AM +0100, Ralf Corsepius wrote: >>> I disagree - All programs should immediately terminate upon "Ctrl-C". >>> Switching to a different mirror should be done by any arbitrary key. >> >> Someone please fix emacs to terminate immediately on ctrl-C then ;) >> >> Very large numbers of programs override ^C to be an internal interrupt, >> including things like ftp. Others specifically ignore it (try using ssh >> without that) > >I think we can accept such weirdness of some applications. > >Most people will understand WHY ^c is overriden in ssh for example. > >For me after 10 years of linux experience it was great mistery why a hell >does yum override ^c. ... Yum does not override Ctl-?. RPM does. Look at the RPM source, say rpmsq.c. RPM does not block the signals, but rather saves them and if a signal has been caught, terminates with extreme prejudice at the end of whatever it was doing. Thus, signals are not processed immediately and always terminate RPM's operation. Not to start any wars here, but I wrote a yum plugin for FC5 (and just updated it for FC6, laziness on my part) that provides, among other things, sane Ctl-C handling (during downloading) in a way I believe safe for RPM. -- ____________________________________________________________________ TonyN.:' ' From pertusus at free.fr Fri Feb 23 20:34:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 23 Feb 2007 21:34:11 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <20070223202245.GA30297@devserv.devel.redhat.com> References: <45DF3BE2.3010204@argo.co.il> <20070223202245.GA30297@devserv.devel.redhat.com> Message-ID: <20070223203411.GB2827@free.fr> On Fri, Feb 23, 2007 at 03:22:45PM -0500, Alan Cox wrote: > > > Because that also means that I control what is done with my code. You > > make it sound like all ideas should be in the public domain. > > That is the natural order of things. "Information wants to be free" is pretty > sound economics. Copyright and friends exist[ed] to motivate people to > behave in a way that benefitted society. It's completely off-topic, but still... I am not completely sure about that (at least for art). In France, there is a kind of property right which tie a piece of work to the author in a very specific way. It cannot be abandonned or transfered (although strangely it is possible to fake the author). It is called le 'droit moral'. It covers the right to divulgate to public or not, right to be recognized as the author, right to enforce respect on the piece of art and the right to remove the piece of art from the commercial circuit. The jurisprudence may limit in fact that right. -- Pat From fedora at leemhuis.info Fri Feb 23 20:41:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Feb 2007 21:41:02 +0100 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <7874d9dd0702231208s2977dca0pd8d05e3ed9424c10@mail.gmail.com> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> <45DF1D4A.5080002@redhat.com> <80d7e4090702230955x73e97bdatb78d2554d217be7f@mail.gmail.com> <45DF4824.10205@leemhuis.info> <7874d9dd0702231208s2977dca0pd8d05e3ed9424c10@mail.gmail.com> Message-ID: <45DF515E.3010403@leemhuis.info> Michael Stahnke schrieb: > On 2/23/07, Thorsten Leemhuis wrote: >> Stephen John Smoogen schrieb: >> My 2 cent: >> Agreed for Camp1 -- it should be left to people who are going to be paid >> for it. >> For the other stuff: I'm targeting something like a mix in the middle >> between Camp2 and Camp3 (with some bits of Camp1 maybe) for EPEL (maybe >> a bit more closer to Camp2 than Camp3). Always the latest stuff IMHO is >> what we have Fedora for; I also think that's its unrealistic to even try >> to always ship the latest apps: Just try now to build a certain apps >> from Extras for RHEL4 -- you will run into trouble now and then, as >> RHEL4 ships with gtk2-2.4, but there are quite a few apps these days >> that require gtk2-2.6. > Has the demand for one particular type of application been higher than > another? For example, most shops I see with RHEL/CentOS are in > runlevel 3, so QT/GTK applications are minimal. Is anyone seeing > things that are different? Well, I assume that besides those that run RHEL/CentOS on Servers in runlevel 3 there are a lot of people out there that run it on their workstation; Fedora afaics moves to fast for a lot of people that prefer to have a "stable" desktop -- they afaics prefer to only upgrade their machine all 18-24 months (or even more seldom) to a new release. > Also, will things like Tremulous be > allwoed in EPEL? /me looks up what tremulous -- ohh, a "First Person Shooter game based on the Quake 3 engine", that why I don't know about it. Well, I didn't build the games I maintain for EPEL yet, but I suppose some people expect them to find in EPEL. I think we should ship them, if the maintainer wants, but games IMHO have not a high priority. CU thl From ssorce at redhat.com Fri Feb 23 20:46:13 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 Feb 2007 15:46:13 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <20070223203411.GB2827@free.fr> References: <45DF3BE2.3010204@argo.co.il> <20070223202245.GA30297@devserv.devel.redhat.com> <20070223203411.GB2827@free.fr> Message-ID: <1172263573.20914.4.camel@localhost.localdomain> On Fri, 2007-02-23 at 21:34 +0100, Patrice Dumas wrote: > On Fri, Feb 23, 2007 at 03:22:45PM -0500, Alan Cox wrote: > > > > > Because that also means that I control what is done with my code. You > > > make it sound like all ideas should be in the public domain. > > > > That is the natural order of things. "Information wants to be free" is pretty > > sound economics. Copyright and friends exist[ed] to motivate people to > > behave in a way that benefitted society. > > It's completely off-topic, but still... > > I am not completely sure about that (at least for art). In France, there > is a kind of property right which tie a piece of work to the author in a > very specific way. It cannot be abandonned or transfered (although > strangely it is possible to fake the author). It is called le 'droit > moral'. It covers the right to divulgate to public or not, right to be > recognized as the author, right to enforce respect on the piece of art > and the right to remove the piece of art from the commercial circuit. > The jurisprudence may limit in fact that right. And yet, amazingly, it is all just a convention between people, information itself is abstract and you can't physically own it no matter how hard you try. Law may declare the world is flat, that doesn't change the physical nature of the world, it may decree the end of your life if you dissent though ... Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From avi at argo.co.il Fri Feb 23 20:47:54 2007 From: avi at argo.co.il (Avi Kivity) Date: Fri, 23 Feb 2007 22:47:54 +0200 Subject: [Mandrakeot] ESR gives up on Fedora Message-ID: <45DF52FA.2030806@argo.co.il> Alan Cox wrote: > On Fri, Feb 23, 2007 at 09:09:22PM +0200, Avi Kivity wrote: > >>> zero cost without destroying the original, can't be subject to real >>> property. >>> >>> >> You mean I can't put a license on my code that says: you may use this, >> but if you change it and redistribute it you must also redistribute your >> changes? >> > > So called "IPR" isn't a property right, its a temporary monopoly right - if > you call them "Intellectual Monopoly Rights" it makes much more sense both > in how the work, what they do and how they need to be regulated > > Isn't property a monopoly? I have a bicycle, I'm the only one who can ride it. I may license it to you for a ride if you ask (but please, I don't want any modifications). I write a book, no one else can print it. Even if they buy a physical copy, they can't do what they like with it (like photocopy it for backup purposes, and maybe give the copies to friends). I own the monopoly on the contents of the book. >> Because that also means that I control what is done with my code. You >> make it sound like all ideas should be in the public domain. >> > > That is the natural order of things. "Information wants to be free" is pretty > sound economics. Information, by itself, wants to bitrot. You actually have to expend effort to push it around networks, explain it to people, port it to latest -git, etc. > Copyright and friends exist[ed] to motivate people to > behave in a way that benefitted society. > Exactly. If we are to hypothesize about what IPR/IMR should be like, it shouldn't be done from the point of view of right and wrong, or what information wants (who cares what it wants anyway), but from the point of view of how it benefits society. Right now that means that people need to be given control over their creation, because greed is a major motivation and control allows them to reap the rewards. The laws also need to at least seem right, otherwise people won't accept them. That's applicable to all laws as well. If people naturally behaved in a way that benefited society, we wouldn't need them. But we aren't bees, unfortunately (and the bees' work doesn't benefit the bees, it benefits the beekeeper). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From avi at argo.co.il Fri Feb 23 20:53:43 2007 From: avi at argo.co.il (Avi Kivity) Date: Fri, 23 Feb 2007 22:53:43 +0200 Subject: [Mandrakeot] ESR gives up on Fedora Message-ID: <45DF5457.8070500@argo.co.il> Simo Sorce wrote: > On Fri, 2007-02-23 at 21:34 +0100, Patrice Dumas wrote: > >> On Fri, Feb 23, 2007 at 03:22:45PM -0500, Alan Cox wrote: >> >>>> Because that also means that I control what is done with my code. You >>>> make it sound like all ideas should be in the public domain. >>>> >>> That is the natural order of things. "Information wants to be free" is pretty >>> sound economics. Copyright and friends exist[ed] to motivate people to >>> behave in a way that benefitted society. >>> >> It's completely off-topic, but still... >> >> I am not completely sure about that (at least for art). In France, there >> is a kind of property right which tie a piece of work to the author in a >> very specific way. It cannot be abandonned or transfered (although >> strangely it is possible to fake the author). It is called le 'droit >> moral'. It covers the right to divulgate to public or not, right to be >> recognized as the author, right to enforce respect on the piece of art >> and the right to remove the piece of art from the commercial circuit. >> The jurisprudence may limit in fact that right. >> > > And yet, amazingly, it is all just a convention between people, > information itself is abstract and you can't physically own it no matter > how hard you try. > > Law may declare the world is flat, that doesn't change the physical > nature of the world, it may decree the end of your life if you dissent > though ... > Physical ownership is as much a fiction as information ownership. There's no physical law that says that just because you gave a shopkeeper some green pieces of paper, I can't take your new iPod when you aren't looking [1]. It's just a convention that allows society to work. [1] Or even if you are looking. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri Feb 23 21:00:33 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 Feb 2007 16:00:33 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45DF5457.8070500@argo.co.il> References: <45DF5457.8070500@argo.co.il> Message-ID: <1172264433.20914.10.camel@localhost.localdomain> On Fri, 2007-02-23 at 22:53 +0200, Avi Kivity wrote: > Physical ownership is as much a fiction as information ownership. > There's no physical law that says that just because you gave a > shopkeeper some green pieces of paper, I can't take your new iPod > when > you aren't looking [1]. It's just a convention that allows society to > work. > > [1] Or even if you are looking. Yeah, but then there is nothing that say I can't give you a kick if you try. It's all a matter of convention in the end, but physical good are limited, abstract ones are not, that's the whole difference. If you take my CD I may object, if you just copy the data on it, I may never notice. If I give you a CD, I don't have it anymore. If I give you an idea, I still have it and intact. If you are deaf to my ideas it's your problem :) And this is all for me, we are way OT. Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From rubin at xs4all.nl Fri Feb 23 21:00:57 2007 From: rubin at xs4all.nl (Rubin) Date: Fri, 23 Feb 2007 22:00:57 +0100 Subject: Broken version check in eclipse-emf? Message-ID: <45DF5609.4090207@xs4all.nl> Hi all, Got this since yesterday night: # yum update (yadayada) ... --> Processing Dependency: eclipse-platform < 1:3.2.2 for package: eclipse-emf --> Finished Dependency Resolution Error: Missing Dependency: eclipse-platform < 1:3.2.2 is needed by package eclipse-emf # rpm -q eclipse-platform eclipse-platform-3.2.1-23.fc6 # rpm -q eclipse-emf eclipse-emf-2.2.1-9.fc6 Am I correct in assuming the eclipse-emf package is either version_check_in_requires_line_broken or too old for the newer eclipse-platform package? Kind regards, Rubin. From avi at argo.co.il Fri Feb 23 21:06:48 2007 From: avi at argo.co.il (Avi Kivity) Date: Fri, 23 Feb 2007 23:06:48 +0200 Subject: [Mandrakeot] ESR gives up on Fedora Message-ID: <45DF5768.3050301@argo.co.il> Simo Sorce wrote: > No, what I mean is that "Intellectual Property" is not natural law, > children do not understand ownership of a song, they just sing it if > they like. Children do understand perfectly ownership of an apple, just > because only one can hold the same apple, and it can be eaten only once. > > It's just a matter of age. Very young children do not understand ownership at all. Older children understand physical ownership, but things like information are too abstract for them. Nor do we want to base our society on how children behave. > "Intellectual Property" it is an artificial construct made up by > societies to achieve some goal in the belief that these rules are an > overall benefit to the society as a whole. For the American society the > goal should be to "promote the Progress of Science and useful Arts"(from > the constitution), the mean is Copyright/Patents. > > You cannot physically posses a piece of code, you can physically own the > specific instance of the code you have saved on your disk. But the code > by itself is abstract, if I copy it from you, you still have your copy > and it is intact. So "taking" your code didn't leave you without it. > > Property make sense only when taking something from someone leaves him > without it. > If you borrow my bicycle while I'm asleep, I'm still have it when I wake up, but you've undermined by bicycle-rental business. Think of licensing intellectual property as renting a bicycle. Copying my code (or book, or movie) doesn't leave me without it, but it takes away my freedom to do what I want with it, including witholding it from others, or charging them for it. > Copyright can be seen as a form of property, as if I have the copyright > on something, you don't. But you have to realize that this works at a > different level. You own the "right to copy" the code, an artifact made > by law, you do not technically own the code itself. > > Ok. I have a bicycle, I own the right to decide how it's used. Even if you promise to return it later, I can still choose not to let you ride it. >> Because that also means that I control what is done with my code. >> You >> make it sound like all ideas should be in the public domain. >> > > Ideas are technically and by law in the "public domain", as they are > abstract and you can't copyright nor patent an ideas. > Code is a different thing, see above. > > Finally, can we close this thread on a devel list? > I am happy to debate around law philosophy elsewhere if you like. > Ok. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From overholt at redhat.com Fri Feb 23 21:08:43 2007 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 23 Feb 2007 16:08:43 -0500 Subject: Broken version check in eclipse-emf? In-Reply-To: <45DF5609.4090207@xs4all.nl> References: <45DF5609.4090207@xs4all.nl> Message-ID: <20070223210843.GE7821@redhat.com> Hi, * Rubin [2007-02-23 16:01]: > ... > --> Processing Dependency: eclipse-platform < 1:3.2.2 for package: > eclipse-emf > --> Finished Dependency Resolution > Error: Missing Dependency: eclipse-platform < 1:3.2.2 is needed by > package eclipse-emf > > [...] > > Am I correct in assuming the eclipse-emf package is either > version_check_in_requires_line_broken or too old for the newer > eclipse-platform package? I need to update it to the Callisto winter maintenance release. While the old one will probably work with 3.2.2 and the new one will probably work with 3.2.1, I wanted to ensure they moved in lock step. I'll try to get to it in the next few days. I need to do GEF as well. Sorry, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lsof at nodata.co.uk Fri Feb 23 21:16:31 2007 From: lsof at nodata.co.uk (nodata) Date: Fri, 23 Feb 2007 22:16:31 +0100 Subject: yum and Ctl-C (was Re: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> Message-ID: <1172265391.3027.0.camel@sb-home.lan> Am Freitag, den 23.02.2007, 15:24 -0500 schrieb Tony Nelson: > At 2:28 PM +0100 2/23/07, Piotr Baranowski wrote: > >Alan Cox wrote(a): > >> On Fri, Feb 23, 2007 at 10:17:23AM +0100, Ralf Corsepius wrote: > >>> I disagree - All programs should immediately terminate upon "Ctrl-C". > >>> Switching to a different mirror should be done by any arbitrary key. > >> > >> Someone please fix emacs to terminate immediately on ctrl-C then ;) > >> > >> Very large numbers of programs override ^C to be an internal interrupt, > >> including things like ftp. Others specifically ignore it (try using ssh > >> without that) > > > >I think we can accept such weirdness of some applications. > > > >Most people will understand WHY ^c is overriden in ssh for example. > > > >For me after 10 years of linux experience it was great mistery why a hell > >does yum override ^c. > ... > > Yum does not override Ctl-?. RPM does. Look at the RPM source, say > rpmsq.c. RPM does not block the signals, but rather saves them and if a > signal has been caught, terminates with extreme prejudice at the end of > whatever it was doing. Thus, signals are not processed immediately and > always terminate RPM's operation. > > Not to start any wars here, but I wrote a yum plugin for FC5 (and just > updated it for FC6, laziness on my part) that provides, among other things, > sane Ctl-C handling (during downloading) in a way I believe safe for RPM. > > -- > ____________________________________________________________________ > TonyN.:' > ' > Err.. wasn't this fixed recently, so that ^C exits rather than switches mirror? From zaitcev at redhat.com Fri Feb 23 21:38:19 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 23 Feb 2007 13:38:19 -0800 Subject: yum and Ctl-C (was Re: FC6 updates broken deps? In-Reply-To: <1172265391.3027.0.camel@sb-home.lan> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> <1172265391.3027.0.camel@sb-home.lan> Message-ID: <20070223133819.6fe39543.zaitcev@redhat.com> On Fri, 23 Feb 2007 22:16:31 +0100, nodata wrote: > Err.. wasn't this fixed recently, so that ^C exits rather than switches > mirror? No, this wasn't changed. Some people LIKE the "switch mirror" behaviour. I think the ideal approach would be to emulate what mpg123 does. If you hit ^C once, it goes to the next track, but if you hit it twice, it exits. However, implementing this in yum was seen as unreliable. So, instead, yum was made to exit at the SIGQUIT (^\ on keyboard). -- Pete From lsof at nodata.co.uk Fri Feb 23 21:45:43 2007 From: lsof at nodata.co.uk (nodata) Date: Fri, 23 Feb 2007 22:45:43 +0100 Subject: yum and Ctl-C (was Re: FC6 updates broken deps? In-Reply-To: <20070223133819.6fe39543.zaitcev@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> <1172265391.3027.0.camel@sb-home.lan> <20070223133819.6fe39543.zaitcev@redhat.com> Message-ID: <1172267143.3571.2.camel@sb-home.lan> Am Freitag, den 23.02.2007, 13:38 -0800 schrieb Pete Zaitcev: > On Fri, 23 Feb 2007 22:16:31 +0100, nodata wrote: > > > Err.. wasn't this fixed recently, so that ^C exits rather than switches > > mirror? > > No, this wasn't changed. Some people LIKE the "switch mirror" > behaviour. I think the ideal approach would be to emulate what > mpg123 does. If you hit ^C once, it goes to the next track, but > if you hit it twice, it exits. However, implementing this in yum > was seen as unreliable. So, instead, yum was made to exit at > the SIGQUIT (^\ on keyboard). > > -- Pete > > I'm confused. "this should be fixed in 2.9.6 - due out soon." -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139459 From drago01 at gmail.com Fri Feb 23 21:51:13 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 23 Feb 2007 22:51:13 +0100 Subject: FC6 updates broken deps? In-Reply-To: <45DDD46D.6030109@andrei.myip.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> Message-ID: <45DF61D1.5030609@gmail.com> Florin Andrei wrote: > Thomas M Steenholdt wrote: > >> Really - The reason dependency issues are such a big issue for fedora >> is that all updates are held back because of a single package >> missing a dependency. I'm sure everybody would feel better holding >> back one package instead of all updates on this account. > > If I'm not mistaken, yum seems fairly unique in this regard. > > I mean, heck, look at Microsoft for example. Their update thing > applies as many patches as possible, and those that cannot be applied, > well duh, they don't get applied and the user is notified by big > honking red icons that something failed. > > But a single error doesn't nuke the whole process. yum is _really_ > boneheaded from this perspective. Your argument that a possibly much > more important security update might get masked by a dependency error > and is not applied is a very serious one and I don't think there can > be any logical rebuttal. > > yum needs to be fixed, NOW. At this moment the update process puts > everyone at risk. > correct. I think we should agree that yum _is_ broken here and needs to be fixed. and no including a optional plugin won't help, the default behavior is broken ( I would even say its a security bug) From kevin at scrye.com Fri Feb 23 21:55:22 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 23 Feb 2007 14:55:22 -0700 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070223145522.73d24777@ningauble.scrye.com> On Fri, 23 Feb 2007 19:05:24 +0100 mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > On Fri, 23 Feb 2007 10:23:39 -0700, Kevin Fenzi wrote: > > > I think the responsibilities of sponsors are the same as they have > > always been (although no where written down), namely: > > The fact that they are not written down makes it useless. I think thats a bit strong, but you are right, they should be written down so everyone has the same expectations. I will try and write something up in the wiki and ask for comments, then get it approved. > > After several years of using the sponsorship system, we don't even > have a draft somewhere in the Wiki. > > Why is that? Because nobody has the time to do it? Or because nobody > knows what the sponsors' responsibilities are actually? Do we use the > terms "sponsor" and "sponsorship" just for fun or because it is a > hardcoded scheme in the FAS? Can we assume that every sponsored > contributor is observed by a sponsor during activities in cvs and > bugzilla, for example? Does that apply also to Red Hat packagers, who > should know their stuff, and blanket approvals? Is sponsorship a > *life-time* process? For example, some of the fellow contributors > I've sponsored have been the FESCo chair or still are FESCo members. > Others can be trusted, also with regard to their technical abilities. > How does that affect the person's status in the FAS and my > responsibilities as a sponsor of those people? All good questions. Would you be willing to assist me in drafting a sponsor responsibilities document? I have a rough draft here: http://www.fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy Feel free to edit/add/comment. > > > - Fix problems that they cause if mistakes are made and they can't > > figure out how to fix them. > > You know this has become impossible with the ACLs. For now, for new packages, yes. For existing extras packages they should still be open to anyone unless the maintainer has placed a pkg.acl in place. > The original > intent of the Vacation page in the Wiki is void, too. Packagers would > need to lift the acls on all their packagers, before they could allow > trusted contributors to help out during vacation. Agreed. > > - Revoke sponsorship in the event that the person refuses to follow > > rules, and deal with that persons leftover packages. > > The second part is new to me. Leftover packages would be orphaned. Sure, but there might be open bugs to close, other packages that depend on those packages that a new maintainer should be found for, binary rpms to remove from repositories, etc. > > > - koji = fork of brew blessed by the lawyers and available for > > Fedora use > > The source code smelled like that, but relevant lists don't mention > koji with a single word. yeah. > > > - Updates system - No idea where that is... it is still not finished > > from what I know. Perhaps someone else could fill this in? > > I know where it is, I am subscribed to the Wiki page, too, but there > is some secret relationship between it and what is used at Red Hat. I think it is based off the internal tool in use for redhat, yes. > Smells a bit like another fork/semi-rewrite of an existing code base, > which creates a situation like "aha, somebody is working on > transfering more and more existant code piece by piece, so it's just > matter of time before all of it is published". I haven't looked at it, so I have no idea. > > > * unclear role of FESCo, not enough steering -- instead: the drive > > > that "you don't need to be in FESCo to get something done", > > > > What items do you think need addressing? > > Guiding the community to prepare for Fedora 7. The contributor > community needs a roadmap. There are 1129 fc6 packages (based on > their src.rpm name) in the devel tree, while Core has reached test2 > already. The upgradecheck report lists several invalid upgrade paths. > The broken deps report lists other issues. The FE7Target tracker > lists even more issues. And I guarantee, more issues are undiscovered. Of course. I attempted to clean up the EVR and broken dependency issues a while back and made some progress on it, but I have been trying to look at core merge reviews lately instead of working more on that. I found that often you could find a solution to the issue, report a bug on it (with patch or offer to fix it) and the maintainer would happily accept it. What do you see such a roadmap containing? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tonynelson at georgeanelson.com Fri Feb 23 22:39:56 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 23 Feb 2007 17:39:56 -0500 Subject: yum and Ctl-C (was Re: FC6 updates broken deps? In-Reply-To: <20070223133819.6fe39543.zaitcev@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> <1172265391.3027.0.camel@sb-home.lan> <20070223133819.6fe39543.zaitcev@redhat.com> Message-ID: At 1:38 PM -0800 2/23/07, Pete Zaitcev wrote: >On Fri, 23 Feb 2007 22:16:31 +0100, nodata wrote: > >> Err.. wasn't this fixed recently, so that ^C exits rather than switches >> mirror? Not on my system, which for months now has been using yum without stablemirror. Ctl-C sometimes would switch mirrors and sometimes would cause yum to exit, as others have been complaining. From looking at yum and the libraries it uses, the behavior seems to me to be accidental. >No, this wasn't changed. Some people LIKE the "switch mirror" >behaviour. I think the ideal approach would be to emulate what >mpg123 does. If you hit ^C once, it goes to the next track, but >if you hit it twice, it exits. However, implementing this in yum >was seen as unreliable. So, instead, yum was made to exit at >the SIGQUIT (^\ on keyboard). I like to choose between switching mirrors or quitting yum when I press Ctl-C. Stablemirror seems to do it reliably, using the YumRepository.setupGrab.grabfunc.opts.interrupt_callback hook. Yum's top-level KeyboardInterrupt handler never gets the exception -- it usually didn't anyway, as RPM had already siezed SIGINT. -- ____________________________________________________________________ TonyN.:' ' From kwade at redhat.com Fri Feb 23 22:43:14 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 23 Feb 2007 14:43:14 -0800 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <1172249472.24204.237.camel@zod.rchland.ibm.com> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> Message-ID: <1172270594.4651.38.camel@erato.phig.org> On Fri, 2007-02-23 at 10:51 -0600, Josh Boyer wrote: > > Is your intention to preclude people that _are_ doing it as a side > project? Certainly not! Yeek! Thanks for the question, I didn't see that interpretation. The purpose of the job description is to make it easier for people who maintain packages to get at least some of the work "guaranteed" by their employer. Obviously it is not a guarantee or a contract to support the package. This is where the wording matters. It is just about extending the personal responsibility to the organization. For example, an individual can orphan a package for any reason, and their responsibility is just to announce the orphaning. The same should hold true for an organization. I'll make some changes in the page[1] for that. - Karsten [1] ref. http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri Feb 23 23:03:33 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Feb 2007 14:03:33 -0900 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <1172270594.4651.38.camel@erato.phig.org> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> <1172270594.4651.38.camel@erato.phig.org> Message-ID: <604aa7910702231503y2f99f1b9te6d463a1427462e5@mail.gmail.com> On 2/23/07, Karsten Wade wrote: > The purpose of the job description is to make it easier for people who > maintain packages to get at least some of the work "guaranteed" by their > employer. Obviously it is not a guarantee or a contract to support the > package. This is where the wording matters. It is just about extending > the personal responsibility to the organization. For example, an > individual can orphan a package for any reason, and their responsibility > is just to announce the orphaning. The same should hold true for an > organization. Do you have buy-in or feedback from organizations at the organizational level on this approach? From manager-like entities who would be making this commitment on behalf of their organization or company? Not to name names or anything..but after FudCon I was on the same flight back with dgilmore, and we had a little chat about EPEL and the contributor landscape for it. It was obvious to both of us that IT people in smaller organizations would very much be interested consumers of this material, but it wasn't clear that they would have organizational support to maintain this material as part of their job. I think some rather valid observations were made concerning the possible reluctance of IT people in a corporate setting to be involved in a maintainership role, exactly because it would appear to be an additional worktime commitment, not supported by their organizations. -jef From mkearey at redhat.com Sat Feb 24 00:14:36 2007 From: mkearey at redhat.com (Mike Kearey) Date: Sat, 24 Feb 2007 10:14:36 +1000 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45DF836C.10401@redhat.com> Michael Schwendt wrote: I just want to address the myth that there is a boatload of 'internal' discussion on Fedora. I work for Red Hat. I am privy to all the internal email lists. I use Fedora as a desktop at work and at home. I participate as much as I am able in the Fedora Community, and lurk mostly on the Fedora mailing lists. I am not a developer. I can tell you with clarity, confidence and complete honesty - THERE IS NO SECRET COBALE within Red Hat that discusses or steers the Fedora project. It is a Community Project. The only discussions I see internally about Fedora are 'How can we make it better, how can we be more open, and how do we make our ( Red Hat ) contributions to the Fedora Project better'. I get the feeling you have managed to convince yourself that there is some malevolent influence at work in Fedora, and we may never convince you otherwise... But we can try. Cheers, Michael From alan at clueserver.org Sat Feb 24 00:21:03 2007 From: alan at clueserver.org (alan) Date: Fri, 23 Feb 2007 16:21:03 -0800 (PST) Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <45DF836C.10401@redhat.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> <45DF836C.10401@redhat.com> Message-ID: On Sat, 24 Feb 2007, Mike Kearey wrote: > I can tell you with clarity, confidence and complete honesty - THERE IS > NO SECRET COBALE within Red Hat that discusses or steers the Fedora > project. It is a Community Project. I think you mean "CABAL" or "COBOL". -- "Invoking the supernatural can explain anything, and hence explains nothing." - University of Utah bioengineering professor Gregory Clark From wart at kobold.org Sat Feb 24 00:23:29 2007 From: wart at kobold.org (Michael Thomas) Date: Fri, 23 Feb 2007 16:23:29 -0800 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> <45DF836C.10401@redhat.com> Message-ID: <45DF8581.90905@kobold.org> alan wrote: > On Sat, 24 Feb 2007, Mike Kearey wrote: > >> I can tell you with clarity, confidence and complete honesty - THERE IS >> NO SECRET COBALE within Red Hat that discusses or steers the Fedora >> project. It is a Community Project. > > I think you mean "CABAL" or "COBOL". I certainly hope there's no COBOL in RedHat, and if there is, that it never leaks into Fedora. Ewww... --Wart From mkearey at redhat.com Sat Feb 24 00:22:45 2007 From: mkearey at redhat.com (Mike Kearey) Date: Sat, 24 Feb 2007 10:22:45 +1000 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> <45DF836C.10401@redhat.com> Message-ID: <45DF8555.5030401@redhat.com> alan wrote: > On Sat, 24 Feb 2007, Mike Kearey wrote: > >> I can tell you with clarity, confidence and complete honesty - THERE IS >> NO SECRET COBALE within Red Hat that discusses or steers the Fedora >> project. It is a Community Project. > I shall turn on the spell checker :) Thanks A message from the "CABAL" <----- From jspaleta at gmail.com Sat Feb 24 01:06:16 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Feb 2007 16:06:16 -0900 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <45DF836C.10401@redhat.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> <45DF836C.10401@redhat.com> Message-ID: <604aa7910702231706h756df4y3aae4eff7171ecd1@mail.gmail.com> On 2/23/07, Mike Kearey wrote: > I get the feeling you have managed to convince yourself that there is > some malevolent influence at work in Fedora, and we may never convince > you otherwise... But we can try. I'd almost like it more if there were a smoke-filled room inside RH-HQ manipulating things in an organized way. But really, the problem is more of the opposite. It's obvious to me that there's been a lack of organization of interests inside the fenceline. Luckily for you and the other corporate serfs, I'm not in charge of Red Hat's internal Fedora education program. My seminars focus primarily on the use of tactile educational reinforcement, in the form of a baseball bat and kneecaps. Though if your manager at Red Hat is interested, I can be hired for just this sort of task on a consulting basis. That lack of internal organization on Red Hat's part, as a managing entity, has probably been the most frustrating thing to community leaders who want to work inside the project without having their work obsoleted by work being done internally that wasn't communicated externally. I'd be more specific, but the point of this email isn't to dredge up bad blood so I won't. I will say, that I am hopeful that the merger process is going to shake the most frustrating issues out (though I'm sure we will find new frustrations), as more and more of RedHat's engineers are asked to do work as part of the merged Fedora project. I don't expect it to go perfectly smoothly either. Injecting a group of new people with a common working culture, into another working culture, is bound to cause...friction...and some control issues. But at the end of the day, most of us are hungry enough for the resulting omelet even if we know we'll be a little messy cooking it. Though its not just the engineers, RedHat's employees who deal with things like training need to be encouraged to engage in the Fedora project as part of the job as well. So really the idea of the 'merger' between Core and Extras has to be bigger than just what we currently have as the Fedora codebase. We have to continue to 'merge' the interests of different groups inside RedHat's existing corporate culture with the overlapping but not dis-similar interests of external contributors in the Fedora community. -jef From mkearey at redhat.com Sat Feb 24 01:32:08 2007 From: mkearey at redhat.com (Mike Kearey) Date: Sat, 24 Feb 2007 11:32:08 +1000 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <604aa7910702231706h756df4y3aae4eff7171ecd1@mail.gmail.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> <45DF836C.10401@redhat.com> <604aa7910702231706h756df4y3aae4eff7171ecd1@mail.gmail.com> Message-ID: <45DF9598.8080206@redhat.com> Hey Jeff :) The point I wanted to make was that there is no _deliberately_ sekret activity behind the scenes. It is the opposite in fact, where it is all in public, embarrassing sometimes. And yes more people inside the fence need to get active. I am one of them :) Cheers Michael From bruno at wolff.to Sat Feb 24 04:06:06 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 23 Feb 2007 22:06:06 -0600 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <200702230817.39895.jkeating@redhat.com> <20070223162528.0d90c498.mschwendt.tmp0701.nospam@arcor.de> <200702231046.52584.jkeating@redhat.com> <20070223171348.c2db5265.mschwendt.tmp0701.nospam@arcor.de> <45DF836C.10401@redhat.com> Message-ID: <20070224040606.GB18997@wolff.to> On Fri, Feb 23, 2007 at 16:21:03 -0800, alan wrote: > On Sat, 24 Feb 2007, Mike Kearey wrote: > > >I can tell you with clarity, confidence and complete honesty - THERE IS > >NO SECRET COBALE within Red Hat that discusses or steers the Fedora > >project. It is a Community Project. > > I think you mean "CABAL" or "COBOL". He just wants us to think he is denying a CABAL, when in fact he was denying a COBALE and later if the CABAL is found out, he can say he wasn't lying. From michel.salim at gmail.com Sat Feb 24 05:14:37 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 24 Feb 2007 00:14:37 -0500 Subject: hald keeps dying? Message-ID: <883cfe6d0702232114x53d37dcbx9510012b1d01a832@mail.gmail.com> Recently I've been having to restart haldaemon periodically (to get battery status from gnome-power-manager back), and after a few minutes 'service haldaemon status' will report that hald is stopped. Nothing about hald shows up in /var/log/messages, and setroubleshooter is quiet. There's this bug in Bugzilla, but it's probably a different problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229580 Has anyone noticed something similar? Thanks, -- Michel Salim http://hircus.wordpress.com/ From seg at haxxed.com Sat Feb 24 05:16:00 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 23 Feb 2007 23:16:00 -0600 Subject: Goodbye, Fedora In-Reply-To: <20070221095253.GB12314@eeyore.32.boerneef.vornavalley> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221095253.GB12314@eeyore.32.boerneef.vornavalley> Message-ID: <1172294161.4322.58.camel@localhost.localdomain> On Wed, 2007-02-21 at 11:52 +0200, Neil Thompson wrote: > On Wed, Feb 21, 2007 at 03:03:50AM -0500, Eric S. Raymond wrote: > > [ a vast amount of crap (as usual) deleted] > > Don't let the door hit you on the way out. Seconded! (gets out the party hats) Who wants cake? -------------- 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 seg at haxxed.com Sat Feb 24 06:06:55 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 24 Feb 2007 00:06:55 -0600 Subject: FC6 updates broken deps? In-Reply-To: <45DF61D1.5030609@gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> Message-ID: <1172297215.4322.62.camel@localhost.localdomain> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: > I think we should agree that yum _is_ broken here and needs to be fixed. > and no including a optional plugin won't help, the default behavior is > broken ( I would even say its a security bug) Does anyone else have an odd feeling of deja-vu? -------------- 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 rc040203 at freenet.de Sat Feb 24 07:01:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Feb 2007 08:01:22 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223145522.73d24777@ningauble.scrye.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> Message-ID: <1172300482.23237.508.camel@mccallum.corsepiu.local> On Fri, 2007-02-23 at 14:55 -0700, Kevin Fenzi wrote: > On Fri, 23 Feb 2007 19:05:24 +0100 > mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > > > On Fri, 23 Feb 2007 10:23:39 -0700, Kevin Fenzi wrote: > > > - Fix problems that they cause if mistakes are made and they can't > > > figure out how to fix them. > > > > You know this has become impossible with the ACLs. > > For now, for new packages, yes. For existing extras packages they > should still be open to anyone unless the maintainer has placed a > pkg.acl in place. == severe regression, rendering the sponsorship model useless and non-functional => fix it ASAP (now) or revert this change. Ralf From sundaram at fedoraproject.org Sat Feb 24 07:05:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 24 Feb 2007 12:35:12 +0530 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <1172300482.23237.508.camel@mccallum.corsepiu.local> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <1172300482.23237.508.camel@mccallum.corsepiu.local> Message-ID: <45DFE3A8.60603@fedoraproject.org> Ralf Corsepius wrote: > On Fri, 2007-02-23 at 14:55 -0700, Kevin Fenzi wrote: >> On Fri, 23 Feb 2007 19:05:24 +0100 >> mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: >> >>> On Fri, 23 Feb 2007 10:23:39 -0700, Kevin Fenzi wrote: > >>>> - Fix problems that they cause if mistakes are made and they can't >>>> figure out how to fix them. >>> You know this has become impossible with the ACLs. >> For now, for new packages, yes. For existing extras packages they >> should still be open to anyone unless the maintainer has placed a >> pkg.acl in place. > > == severe regression, rendering the sponsorship model useless and non-functional > > => fix it ASAP (now) or revert this change. Existing packages do not have ACL's by default. This is the same as before. In other words, it is not a regression. Rahul From rc040203 at freenet.de Sat Feb 24 07:12:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Feb 2007 08:12:35 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <45DFE3A8.60603@fedoraproject.org> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <1172300482.23237.508.camel@mccallum.corsepiu.local> <45DFE3A8.60603@fedoraproject.org> Message-ID: <1172301156.23237.517.camel@mccallum.corsepiu.local> On Sat, 2007-02-24 at 12:35 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Fri, 2007-02-23 at 14:55 -0700, Kevin Fenzi wrote: > >> On Fri, 23 Feb 2007 19:05:24 +0100 > >> mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > >> > >>> On Fri, 23 Feb 2007 10:23:39 -0700, Kevin Fenzi wrote: > > > >>>> - Fix problems that they cause if mistakes are made and they can't > >>>> figure out how to fix them. > >>> You know this has become impossible with the ACLs. > >> For now, for new packages, yes. For existing extras packages they > >> should still be open to anyone unless the maintainer has placed a > >> pkg.acl in place. > > > > == severe regression, rendering the sponsorship model useless and non-functional > > > > => fix it ASAP (now) or revert this change. > > Existing packages do not have ACL's by default. This is the same as > before. In other words, it is not a regression. Sponsors can not intervene into newly added packages! => this ACL crap has rendered the sponsorship model NON-APPLICABLE This is the REGRESSION. I for one don't see any possibility to sponsor anybody anymore and don't see any possibility anymore to approve packages having been submitted by new-comers. Ralf From knightmerc at yahoo.com Sat Feb 24 09:53:02 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Sat, 24 Feb 2007 04:53:02 -0500 Subject: Goodbye, Fedora In-Reply-To: <200702231403.36059.tbrinkman@sbcglobal.net> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702210845.07064.tbrinkman@sbcglobal.net> <1172226119.5995.7.camel@localhost.localdomain> <200702231403.36059.tbrinkman@sbcglobal.net> Message-ID: <1172310782.4297.12.camel@localhost.localdomain> On Fri, 2007-02-23 at 14:03 -0600, Tom Brinkman wrote: > On Friday 23 February 2007, Lyvim Xaphir wrote: > > > 2.6.19-1.2911.fc6 is running on my primary workstation not > > including my five other test boxes. > > > > LX > > "About fedora-devel-list English (USA) > This list is only for discussion of development issues in the > Fedora Project. > > THIS IS NOT A SUPPORT LIST. THIS LIST IS FOR CORE DEVELOPMENT > DISCUSSION ONLY." (their emphasis, not mine) > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Take your moronic B$ back to OT, where it's at least tolerated, > found amusing. As is ESR Go see your doctor about your meds. LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From knightmerc at yahoo.com Sat Feb 24 10:58:32 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Sat, 24 Feb 2007 05:58:32 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <20070223104606.GA2838@free.fr> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> Message-ID: <1172314712.4297.64.camel@localhost.localdomain> On Fri, 2007-02-23 at 11:46 +0100, Patrice Dumas wrote: > On Fri, Feb 23, 2007 at 04:39:16AM -0500, Lyvim Xaphir wrote: > > > > NOT if the intellectual property was produced by work that was not > > freely given. If the programmer creates original product (IP) thru > > his/her own effort and work, then that person has the right to the > > fruits of that labor. This is basic and not hard to understand. > > The fact that freely available non rival goods maximize welfare > is also easy to understand. Once again, I don't disagree. But the difference is wether the intellectual property was freely given or not. We have all seen freely given intellectual property maximize the general welfare, but that's not the issue here. If you are advocating stealing intellectual property for the general welfare, then that's clearly criminal. Truthfully I don't think you are or would advocate such a thing, but there are those here who are. > So here there is clearly a possible > opposition on normative issues. The political/ideological issue is > on how to balance the freedom to license against welfare maximisation > since both principles are antagonist in the case of non rival goods. Which is simple enough; the freedom to license lies with the authors of the work. Period. Any attempt to remove that right or force licensing on the authors of the work is a criminal action against the authors. > > Which I agree with in principle, with that statement taken by itself; > > but you are discussing a different type of regulation. The situation > > I'm concerned with is when the programmer wishes to profit from his > > work; which is a form of regulation, but again I don't think that's what > > you mean here. > > Indeed, what I call regulation here is what is commonly understood in > the field of social choice economy. It is the action of a collective > body to set rules. Setting rules and forcing rules on others is two entirely different things. I'm concerned with the latter (and I give you the benefit of the doubt that you are only talking about the former.) > > > My point is that if the person originates the work, then they > > automatically have the rights to that work, and as such they also have > > the intrinsic right to license it any way they like. It's their work. > > It's their right. This right is forcibly taken from them in the case of > > forced licensing, which is presently occurring within the context of a > > false-freedom ideology. > > You are saying that freedom to keep rights on intelectual production > is the highest principle (above welfare maximization, at least). That's > a view, but other people may disagree. I am not stating my personnal view > here, just explaining that a way to understand this opposition is to > state it that way. I understand. But...the assumption you start from in the above paragraph is that it's an EITHER OR situation with regard to intellectual production "rights". It's not. The current IT universe is diverse and today we have freely given intellectual property which is under the jurisdiction of the GPL, and we also have other differently-licensed intellectual properties which work together with the GPL properties. There's a wide variety of rights available. Within a _current status quo there will ALWAYS be freely-given intellectual production _and_ profit-oriented intellectual production. Currently they work together fine, and the MARKET is the deciding factor about what is used and what is not used. We have different people, different organizations and different financial needs all being served by different licensing solutions. The criminal action comes in when a self-appointed closed ideological group attempts to force their licensing scheme on others against their will by virtue of their level of control over the kernel. When THEY think THEY can unilaterally decide what is right or wrong (taking that decision away from the great unwashed, the users, the Market). As I've stated before, such criminal actions are consequences of socialism. Kernel development should be strictly within the domain of technical dominion, and should have nothing to do with ideology. Ideology is the purview of the user. That has been the key to Ubuntu's success; they understand that principle. They trust the users to make the correct decisions. If the developers want to write code under the authority of technical merit, fine. If they want to march up and down the roads in black robes as the New Flagellants, beating themselves with chains and cursing the dissenters and the New Jews, that's fine too. But PICK ONE. > > > Currently ideas cannot be protected, > > > > > > This is your view and in my view it's false. There are consequences > > today for stealing intellectual property and many people have felt the > > legal brunt of those consequences. I don't agree with things like the > > Ideas, knowledge cannot be protected. (grin) You keep saying that and I will keep disagreeing. :) I'm telling you that there are people in jail now for violation of intellectual property law. Perhaps we should extend the discussion to the nature of protection? If we both decide that protection is possible at the point of a gun, then we both agree that indeed intellectual property is indeed being protected today as we speak. > Reusing knowledge and ideas cannot be prosecuted. Galileo would disagree with you. As would a number of other prominent individuals living (or dying) during the Enlightenment. > The fields of intellectual property are innovation > (through patents), trademark, copyright (for art and software > representations), commercial secrets. Exceptions are entering now and > then (like genetic codes, software patents that may protect some ideas > that are not really innovations, informations stored in database), The genetics I DO NOT agree with. Genetics represents already-existant information (prior to the genesis of human technology) and therefore has not been authored by an individual; so to me the copyright of an existing gene should be rendered criminal. The processes in the probing and manipulation of genes are rightfully intellectual property, but the genomes themselves should be considered outside that domain. They are already "owned", in a sense, and do not represent work involved in their creation by humanity. You could almost say that they were already there, were freely given, and now should be under a sort of "genetic GPL" license. The creation of a new gene would be rightfully considered intellectual property. Clearly there are abuses of intellectual property licensing. My position is that abuses are occurring in not just one arena, but also in increasingly socio-fascist sectors of the IT world. Forced licensing is definitely an abuse and an affront to real freedom. It's just as criminal as patenting a part of the human genome. > but basically all you read in a book cannot be protected by the book > author. The copyright protects the wording, not the ideas. > > -- > Pat If a man's patent holds for a number of years on his ideas for a successful invention, then no matter what the interpretations may be, his ideas have been protected and he profits from that successful invention. The synopsis is that his ideas were protected from others for fear of lawsuit or criminal prosecution. LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From drago01 at gmail.com Sat Feb 24 11:00:00 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 24 Feb 2007 12:00:00 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172297215.4322.62.camel@localhost.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> Message-ID: <45E01AB0.5060401@gmail.com> Callum Lerwick wrote: > On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: > >> I think we should agree that yum _is_ broken here and needs to be fixed. >> and no including a optional plugin won't help, the default behavior is >> broken ( I would even say its a security bug) >> > > Does anyone else have an odd feeling of deja-vu? > I now that we had this discussion in the past, but the problem is still there so it will keeps coming up again until its fixed. From tmus at tmus.dk Sat Feb 24 10:04:39 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 24 Feb 2007 11:04:39 +0100 Subject: yum and Ctl-C (was Re: FC6 updates broken deps? In-Reply-To: <20070223133819.6fe39543.zaitcev@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> <1172265391.3027.0.camel@sb-home.lan> <20070223133819.6fe39543.zaitcev@redhat.com> Message-ID: Pete Zaitcev wrote: > On Fri, 23 Feb 2007 22:16:31 +0100, nodata wrote: > >> Err.. wasn't this fixed recently, so that ^C exits rather than switches >> mirror? > > No, this wasn't changed. Some people LIKE the "switch mirror" > behaviour. I think the ideal approach would be to emulate what > mpg123 does. If you hit ^C once, it goes to the next track, but > if you hit it twice, it exits. However, implementing this in yum > was seen as unreliable. So, instead, yum was made to exit at > the SIGQUIT (^\ on keyboard). > > -- Pete > I wonder if anyone knows how to make that char on a danisk keyboard... \ is AltGr+[ backslash key ] adding a ctrl to that combo just doesnt work. Perhaps it's doable, perhaps it's not?!? Anyone? /Thomas From buildsys at redhat.com Sat Feb 24 11:19:11 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 24 Feb 2007 06:19:11 -0500 Subject: rawhide report: 20070224 changes Message-ID: <200702241119.l1OBJBpq016132@hs20-bc2-6.build.redhat.com> Removed package gimp-data-extras Updated Packages: fedora-logos-6.0.93-1.fc7 ------------------------- * Fri Feb 23 2007 Matthias Clasen - 6.0.93-1 - New backgrounds (dual versions still missing) * Fri Feb 23 2007 Matthias Clasen - 6.0.92-5 - Directory ownership fixes fedora-release-6.91-1 --------------------- * Fri Feb 23 2007 Jesse Keating - 6.91-1 - Bump for Test 2 * Tue Feb 13 2007 Jesse Keating - 6.90-4 - Specfile cleanups * Mon Feb 05 2007 Jesse Keating - 6.90-3 - Drop the legacy repo file. gnome-session-2.17.91-2.fc7 --------------------------- * Fri Feb 23 2007 Jeremy Katz - 2.17.91-2 - disable a11y registry timeout so that we don't get the popup with the livecd (#227214) initscripts-8.51-1 ------------------ * Fri Feb 23 2007 Bill Nottingham 8.51-1 - fix 'Fedora Fedora' in rc.sysinit - halt: use kexec -x to not shut down network (#223932, ) - network_functions: fix is_bonding_device logic (#229643) - translation updates: nb * Mon Feb 19 2007 Bill Nottingham 8.50-1 - lang.csh, lang.sh: if $LANG is set, don't override it (#229102) - initlog.1: fix man page formatting () - network-functions: simplify bonding test (#215887, ) - fix ifup-post when lookup fails (#220318, ) - add bridging docs (#221412, ) - release bonding slaves properly (#220525) - fix ppp-watch with ONBOOT=yes (#216749) - support VLAN_PLUS_VID_NO_PAD (#222975, #223011) - remove NETWORKING_IPV6; to disable, use a modprobe rule - translation updates: ms, de, el, pt_BR, fi, bs, sr, it, ko * Tue Dec 19 2006 Bill Nottingham 8.49-1 - rc.sysinit: remove raidautorn (#219226) - ifup-eth: set MACADDR, MTU before initializing bonding slaves, etc (#218792) - translation updates: mr, ms, hi, te, ml kernel-2.6.20-1.2942.fc7 ------------------------ * Thu Feb 22 2007 Dave Jones - Disable speedstep-centrino in favour of acpi-cpufreq * Thu Feb 22 2007 John W. Linville - Add new wireless infrastructure from wireless-dev git tree libvirt-0.2.0-4.fc7 ------------------- * Fri Feb 23 2007 Daniel P. Berrange - 0.2.0-4.fc7 - Fix loading of guest & network configs Broken deps for ia64 ---------------------------------------------------------- pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From fedora at camperquake.de Sat Feb 24 11:48:42 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 24 Feb 2007 12:48:42 +0100 Subject: rawhide report: 20070224 changes In-Reply-To: <200702241119.l1OBJBpq016132@hs20-bc2-6.build.redhat.com> References: <200702241119.l1OBJBpq016132@hs20-bc2-6.build.redhat.com> Message-ID: <20070224124842.223eac78@lain.camperquake.de> Hi. On Sat, 24 Feb 2007 06:19:11 -0500, buildsys at redhat.com wrote > kernel-2.6.20-1.2942.fc7 > ------------------------ > * Thu Feb 22 2007 Dave Jones > - Disable speedstep-centrino in favour of acpi-cpufreq > > * Thu Feb 22 2007 John W. Linville > - Add new wireless infrastructure from wireless-dev git tree Would that be d80211? If yes, what version? From drago01 at gmail.com Sat Feb 24 12:06:18 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 24 Feb 2007 13:06:18 +0100 Subject: rawhide report: 20070224 changes In-Reply-To: <20070224124842.223eac78@lain.camperquake.de> References: <200702241119.l1OBJBpq016132@hs20-bc2-6.build.redhat.com> <20070224124842.223eac78@lain.camperquake.de> Message-ID: <45E02A3A.1080506@gmail.com> Ralf Ertzinger wrote: > Hi. > > On Sat, 24 Feb 2007 06:19:11 -0500, buildsys at redhat.com wrote > > >> kernel-2.6.20-1.2942.fc7 >> ------------------------ >> * Thu Feb 22 2007 Dave Jones >> - Disable speedstep-centrino in favour of acpi-cpufreq >> >> * Thu Feb 22 2007 John W. Linville >> - Add new wireless infrastructure from wireless-dev git tree >> > > Would that be d80211? If yes, what version? > > yes it is + rt2x00,zd1211rw,adm8211,p54,bcm43xx (d80211 based one) drivers but no iwlwifi (yet?) as for version dunno its what was in wireless-git on 22 feb 2007. From fedora at leemhuis.info Sat Feb 24 12:08:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 24 Feb 2007 13:08:25 +0100 Subject: rawhide report: 20070224 changes In-Reply-To: <20070224124842.223eac78@lain.camperquake.de> References: <200702241119.l1OBJBpq016132@hs20-bc2-6.build.redhat.com> <20070224124842.223eac78@lain.camperquake.de> Message-ID: <45E02AB9.2000800@leemhuis.info> Ralf Ertzinger schrieb: > On Sat, 24 Feb 2007 06:19:11 -0500, buildsys at redhat.com wrote >> kernel-2.6.20-1.2942.fc7 >> ------------------------ >> * Thu Feb 22 2007 Dave Jones >> - Disable speedstep-centrino in favour of acpi-cpufreq >> >> * Thu Feb 22 2007 John W. Linville >> - Add new wireless infrastructure from wireless-dev git tree > > Would that be d80211? Yes. > If yes, what version? CVS is your friend ;-) http://cvs.fedora.redhat.com/viewcvs/devel/kernel/git-wireless-dev.patch?rev=1.1&view=markup Quoting: > This patch aggregates the changes available in the wireless-dev git > tree. This includes the new wireless stack, the associated drivers, the > new wireless configuration mechanisms, and some b44 changes related to > hardware in common with bcm43xx (i.e. the SSB bus). > > This is the output of 'git diff from-linus..mm-master' on 22 Feb 2007 on > the tree available here: > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git > > Current from-linus: c8f71b01a50597e298dc3214a2f2be7b8d31170c > Current mm-master: f0142f49c820e1b169eea09c46cea8548430eab2 > Current master: db1eee24ed04ea33587f899b00dde9be8cd2e7e1 Cu thl From mschwendt.tmp0701.nospam at arcor.de Sat Feb 24 12:40:09 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 24 Feb 2007 13:40:09 +0100 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223145522.73d24777@ningauble.scrye.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> Message-ID: <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> On Fri, 23 Feb 2007 14:55:22 -0700, Kevin Fenzi wrote: > > > - Revoke sponsorship in the event that the person refuses to follow > > > rules, and deal with that persons leftover packages. > > > > The second part is new to me. Leftover packages would be orphaned. > > Sure, but there might be open bugs to close, other packages that depend > on those packages that a new maintainer should be found for, binary > rpms to remove from repositories, etc. Now it's getting interesting. Being a sponsor has never before implied that you have to fix orphans or take over packages when a sponsored person leaves the project or is AWOL. With such a requirement, the sponsorship system would be too burdensome and too much of a risk. > > > > * unclear role of FESCo, not enough steering -- instead: the drive > > > > that "you don't need to be in FESCo to get something done", > > > > > > What items do you think need addressing? > > > > Guiding the community to prepare for Fedora 7. The contributor > > community needs a roadmap. There are 1129 fc6 packages (based on > > their src.rpm name) in the devel tree, while Core has reached test2 > > already. The upgradecheck report lists several invalid upgrade paths. > > The broken deps report lists other issues. The FE7Target tracker > > lists even more issues. And I guarantee, more issues are undiscovered. > > Of course. I attempted to clean up the EVR and broken dependency issues > a while back and made some progress on it, but I have been trying to > look at core merge reviews lately instead of working more on that. > I found that often you could find a solution to the issue, report a bug > on it (with patch or offer to fix it) and the maintainer would happily > accept it. > > What do you see such a roadmap containing? Points that give the impression that there is the desire to have a product ready when Fedora 7 will be released. When to have packages rebuilt and ready, whether and when there will be any sort of freeze (especially with regard to ABI and API breakage), "last resort"/"last minutes" procedures for fixing packages where package owners have not met the deadline. I see Matt Domsch' build failure report, I see the complicated and lengthy AWOL procedure, I see that test2 is close, but Extras 7 is broken in many areas, I see ACLs which lock down packages in CVS, and all that would benefit from plans on how to bring Extras 7 in shape in time. From david at fubar.dk Sat Feb 24 16:31:51 2007 From: david at fubar.dk (David Zeuthen) Date: Sat, 24 Feb 2007 11:31:51 -0500 Subject: hald keeps dying? In-Reply-To: <883cfe6d0702232114x53d37dcbx9510012b1d01a832@mail.gmail.com> References: <883cfe6d0702232114x53d37dcbx9510012b1d01a832@mail.gmail.com> Message-ID: <1172334711.24088.0.camel@zelda.fubar.dk> On Sat, 2007-02-24 at 00:14 -0500, Michel Salim wrote: > Recently I've been having to restart haldaemon periodically (to get > battery status from gnome-power-manager back), and after a few minutes > 'service haldaemon status' will report that hald is stopped. > > Nothing about hald shows up in /var/log/messages, and setroubleshooter > is quiet. There's this bug in Bugzilla, but it's probably a different > problem: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229580 > > Has anyone noticed something similar? Yes, seen this (but a lot less often) on x86 too. Is working on a fix. David From mclasen at redhat.com Sat Feb 24 16:39:02 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 24 Feb 2007 11:39:02 -0500 Subject: hald keeps dying? In-Reply-To: <1172334711.24088.0.camel@zelda.fubar.dk> References: <883cfe6d0702232114x53d37dcbx9510012b1d01a832@mail.gmail.com> <1172334711.24088.0.camel@zelda.fubar.dk> Message-ID: <1172335142.4190.0.camel@localhost.localdomain> On Sat, 2007-02-24 at 11:31 -0500, David Zeuthen wrote: > On Sat, 2007-02-24 at 00:14 -0500, Michel Salim wrote: > > Recently I've been having to restart haldaemon periodically (to get > > battery status from gnome-power-manager back), and after a few minutes > > 'service haldaemon status' will report that hald is stopped. > > > > Nothing about hald shows up in /var/log/messages, and setroubleshooter > > is quiet. There's this bug in Bugzilla, but it's probably a different > > problem: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229580 > > > > Has anyone noticed something similar? > > Yes, seen this (but a lot less often) on x86 too. Is working on a fix. > What i noticed is that /sbin/service haldaemon status reports "stopped" when run as a user, but "running", when running as root, so there is probably some permission problem somewhere. From michel.salim at gmail.com Sat Feb 24 17:03:16 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 24 Feb 2007 12:03:16 -0500 Subject: hald keeps dying? In-Reply-To: <1172335142.4190.0.camel@localhost.localdomain> References: <883cfe6d0702232114x53d37dcbx9510012b1d01a832@mail.gmail.com> <1172334711.24088.0.camel@zelda.fubar.dk> <1172335142.4190.0.camel@localhost.localdomain> Message-ID: <883cfe6d0702240903g43b02712kda2e6172bb34c504@mail.gmail.com> 2007/2/24, Matthias Clasen : > On Sat, 2007-02-24 at 11:31 -0500, David Zeuthen wrote: > > On Sat, 2007-02-24 at 00:14 -0500, Michel Salim wrote: > > > Recently I've been having to restart haldaemon periodically (to get > > > battery status from gnome-power-manager back), and after a few minutes > > > 'service haldaemon status' will report that hald is stopped. > > > > > > Nothing about hald shows up in /var/log/messages, and setroubleshooter > > > is quiet. There's this bug in Bugzilla, but it's probably a different > > > problem: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229580 > > > > > > Has anyone noticed something similar? > > > > Yes, seen this (but a lot less often) on x86 too. Is working on a fix. > > > > What i noticed is that /sbin/service haldaemon status reports > "stopped" when run as a user, but "running", when running as root, so > there is probably some permission problem somewhere. > Ah, you're right. I was a bit puzzled about that -- sometimes hald is really dead (no g-p-m icon in notification area), more often it's actually still running. -- Michel Salim http://hircus.wordpress.com/ From michel.salim at gmail.com Sat Feb 24 17:34:12 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 24 Feb 2007 12:34:12 -0500 Subject: Detecting the need for additional kernel options? Message-ID: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> Is Anaconda currently checking the machine configuration against a compatibility database? On some AMD64 laptops (including my HP L2000), the machine would lock up randomly (without any log message) if booted without "noapic" (I added "nosmp" for good measure). Perhaps a user-maintainable database; we can consider tying it in with Smolt so that only users who own a particular model can submit required kernel options for it (to verify ownership, give the user a token that they must pass to Smolt, e.g. smoltSendProfile --key=AF32EBD4008) Speaking of Smolt, the CPUspeed reported does not seem that useful, unless it interfaces with CPUspeed to first set the clockspeed to minimum, take a measurement, then set it to maximum, measure, and then restore the original setting? My 2GHz laptop was reported as a 1.6 .. -- Michel Salim http://hircus.wordpress.com/ From fedora at leemhuis.info Sat Feb 24 17:56:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 24 Feb 2007 18:56:59 +0100 Subject: Detecting the need for additional kernel options? In-Reply-To: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> References: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> Message-ID: <45E07C6B.7000205@leemhuis.info> Michel Salim schrieb: > Is Anaconda currently checking the machine configuration against a > compatibility database? On some AMD64 laptops (including my HP L2000), > the machine would lock up randomly (without any log message) if booted > without "noapic" (I added "nosmp" for good measure). > > Perhaps a user-maintainable database; we can consider tying it in with > Smolt so that only users who own a particular model can submit > required kernel options for it (to verify ownership, give the user a > token that they must pass to Smolt, e.g. smoltSendProfile > --key=AF32EBD4008) Why not fix it in the kernel once and for all? That has benefits for everyone, as no user has to care about options ever again and the problems get fixed in all distributions over time... CU thl From davej at redhat.com Sat Feb 24 17:56:53 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 24 Feb 2007 12:56:53 -0500 Subject: Detecting the need for additional kernel options? In-Reply-To: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> References: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> Message-ID: <20070224175653.GC4519@redhat.com> On Sat, Feb 24, 2007 at 12:34:12PM -0500, Michel Salim wrote: > Is Anaconda currently checking the machine configuration against a > compatibility database? On some AMD64 laptops (including my HP L2000), > the machine would lock up randomly (without any log message) if booted > without "noapic" (I added "nosmp" for good measure). > > Perhaps a user-maintainable database; we can consider tying it in with > Smolt so that only users who own a particular model can submit > required kernel options for it (to verify ownership, give the user a > token that they must pass to Smolt, e.g. smoltSendProfile > --key=AF32EBD4008) > > Speaking of Smolt, the CPUspeed reported does not seem that useful, > unless it interfaces with CPUspeed to first set the clockspeed to > minimum, take a measurement, then set it to maximum, measure, and then > restore the original setting? My 2GHz laptop was reported as a 1.6 .. instead of faffing about changing speeds, it could just report the contents of /sys/devices/system/cpu/*/cpufreq/scaling_available_frequencies if present. Dave -- http://www.codemonkey.org.uk From fedora at camperquake.de Sat Feb 24 18:04:27 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 24 Feb 2007 19:04:27 +0100 Subject: rawhide report: 20070224 changes In-Reply-To: <200702241119.l1OBJBpq016132@hs20-bc2-6.build.redhat.com> References: <200702241119.l1OBJBpq016132@hs20-bc2-6.build.redhat.com> Message-ID: <20070224190427.1487be8b@lain.camperquake.de> Hi. On Sat, 24 Feb 2007 06:19:11 -0500, buildsys at redhat.com wrote > kernel-2.6.20-1.2942.fc7 > ------------------------ > * Thu Feb 22 2007 Dave Jones > - Disable speedstep-centrino in favour of acpi-cpufreq > > * Thu Feb 22 2007 John W. Linville > - Add new wireless infrastructure from wireless-dev git tree Just a heads up: i386 headers are stil broken on this one. From pmatilai at laiskiainen.org Sat Feb 24 21:02:47 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 24 Feb 2007 23:02:47 +0200 (EET) Subject: FC6 updates broken deps? In-Reply-To: <1172297215.4322.62.camel@localhost.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> Message-ID: On Sat, 24 Feb 2007, Callum Lerwick wrote: > On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: >> I think we should agree that yum _is_ broken here and needs to be fixed. >> and no including a optional plugin won't help, the default behavior is >> broken ( I would even say its a security bug) > > Does anyone else have an odd feeling of deja-vu? Yes, and a strong one at that. This and "but it shouldn't abort when unresolvable dependencies are present" threads (among various other non-yum related ones) keep recurring every few months. Somebody with too much time on their hands, analysis of these threads might be interesting subject: do these things recur N months before/after release, only during certain months when it's cold as hell in certain parts of the world or what :) - Panu - From mike.cohler at gmail.com Sat Feb 24 21:56:25 2007 From: mike.cohler at gmail.com (Mike Cohler) Date: Sat, 24 Feb 2007 21:56:25 +0000 Subject: d80211 and iwlwifi Message-ID: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> I hope this is not a repeat question but is it planned to have d80211 and iwlwifi in the F7 release? If so is it planned to put these into updates for FC6 at some point? -- mike cohler From eric.tanguy at univ-nantes.fr Sat Feb 24 22:18:40 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 24 Feb 2007 23:18:40 +0100 Subject: d80211 and iwlwifi In-Reply-To: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> Message-ID: <1172355520.19751.3.camel@bureau.maison> Le samedi 24 f?vrier 2007 ? 21:56 +0000, Mike Cohler a ?crit : > I hope this is not a repeat question but is it planned to have d80211 > and iwlwifi in the F7 release? > > If so is it planned to put these into updates for FC6 at some point? > For the d80211 stack it will be in the kernel when it will be ready but if i remember well there was 2 stacks, one from intel and an other one. I heard something soon because i heard for 2.6.21 but i'm not sure. Dave, have you got news about this ? Concerning iwlwifi, i think it will be a license problem so not in fedora but maybe in an other repo. Eric From fedora at camperquake.de Sat Feb 24 22:20:13 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 24 Feb 2007 23:20:13 +0100 Subject: d80211 and iwlwifi In-Reply-To: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> Message-ID: <20070224232013.558b370e@lain.camperquake.de> Hi. On Sat, 24 Feb 2007 21:56:25 +0000, Mike Cohler wrote > I hope this is not a repeat question but is it planned to have d80211 > and iwlwifi in the F7 release? d80211 has landed in RH today. From mike.cohler at gmail.com Sat Feb 24 22:55:52 2007 From: mike.cohler at gmail.com (Mike Cohler) Date: Sat, 24 Feb 2007 22:55:52 +0000 (UTC) Subject: d80211 and iwlwifi References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070224232013.558b370e@lain.camperquake.de> Message-ID: Ralf Ertzinger camperquake.de> writes: > d80211 has landed in RH today. > Great - there has certainly been a lot of activity on both fronts in the ipw3945 devel list of late. From benny+usenet at amorsen.dk Sun Feb 25 00:52:02 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 25 Feb 2007 01:52:02 +0100 Subject: [Mandrakeot] ESR gives up on Fedora References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> Message-ID: >>>>> "LX" == Lyvim Xaphir writes: LX> If you are advocating stealing intellectual property for the LX> general welfare, then that's clearly criminal. Truthfully I don't LX> think you are or would advocate such a thing, but there are those LX> here who are. I am one of them. I advocate getting rid of intellectual property entirely. I do not see what is criminal about a free market. /Benny From benny+usenet at amorsen.dk Sun Feb 25 00:59:26 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 25 Feb 2007 01:59:26 +0100 Subject: [Mandrakeot] ESR gives up on Fedora References: <45DF5457.8070500@argo.co.il> Message-ID: >>>>> "AK" == Avi Kivity writes: AK> Physical ownership is as much a fiction as information ownership. AK> There's no physical law that says that just because you gave a AK> shopkeeper some green pieces of paper, I can't take your new iPod AK> when you aren't looking [1]. It's just a convention that allows AK> society to work. One important difference is that if I steal your bicycle, you will notice. If I give a copy of your program to a friend, you will not notice. /Benny From benny+usenet at amorsen.dk Sun Feb 25 01:02:28 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 25 Feb 2007 02:02:28 +0100 Subject: FC6 updates broken deps? References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> Message-ID: >>>>> "AC" == Alan Cox writes: AC> Someone please fix emacs to terminate immediately on ctrl-C then AC> ;) AC> Very large numbers of programs override ^C to be an internal AC> interrupt, including things like ftp. Others specifically ignore AC> it (try using ssh without that) emacs, ftp in command mode, and ssh are all interactive. yum has no reason to be interactive, it does not offer a command prompt or connect you to another system with a command prompt. /Benny From mkearey at redhat.com Sun Feb 25 01:08:53 2007 From: mkearey at redhat.com (Mike Kearey) Date: Sun, 25 Feb 2007 11:08:53 +1000 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> Message-ID: <45E0E1A5.60104@redhat.com> Benny Amorsen wrote: > > emacs, ftp in command mode, and ssh are all interactive. yum has no > reason to be interactive, it does not offer a command prompt or > connect you to another system with a command prompt. yum shell: # yum shell Loading "protectbase" plugin Loading "installonlyn" plugin Loading "fastestmirror" plugin Setting up Yum Shell > It is shell like :) Cheers From piotr.baranowski at altkom.pl Sun Feb 25 01:34:25 2007 From: piotr.baranowski at altkom.pl (Piotr Baranowski) Date: Sun, 25 Feb 2007 02:34:25 +0100 (CET) Subject: FC6 updates broken deps? In-Reply-To: <45E0E1A5.60104@redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <45E0E1A5.60104@redhat.com> Message-ID: <63881.ZgEtUWFHE1E=.1172367265.squirrel@nmail.altkom.pl> Mike Kearey napisa?(a): > Benny Amorsen wrote: > >> >> emacs, ftp in command mode, and ssh are all interactive. yum has no >> reason to be interactive, it does not offer a command prompt or >> connect you to another system with a command prompt. > > yum shell: > > > # yum shell > Loading "protectbase" plugin > Loading "installonlyn" plugin > Loading "fastestmirror" plugin > Setting up Yum Shell Anybody really using that stuff ? Functionality seems to be cool but any real-life scenarios of yum shell monkey-super-powers in action ? -- Piotr Baranowski - RHCX @ Altkom Akademia S.A. Dlaczego informatycy myl? Halloween z Bo?ym Narodzeniem ? ...bo 31oct==25dec :) From benny+usenet at amorsen.dk Sun Feb 25 01:51:28 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 25 Feb 2007 02:51:28 +0100 Subject: FC6 updates broken deps? References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <45E0E1A5.60104@redhat.com> Message-ID: >>>>> "MK" == Mike Kearey writes: MK> Benny Amorsen wrote: >> emacs, ftp in command mode, and ssh are all interactive. yum has >> no reason to be interactive, it does not offer a command prompt or >> connect you to another system with a command prompt. MK> yum shell: MK> # yum shell Loading "protectbase" plugin Loading "installonlyn" MK> plugin Loading "fastestmirror" plugin Setting up Yum Shell >> MK> It is shell like :) I had no idea that existed. Thanks for the information. yum can certainly intercept Ctrl-C when it is running in interactive mode. It should still keep its hands off in command mode. /Benny From mkearey at redhat.com Sun Feb 25 01:51:32 2007 From: mkearey at redhat.com (Mike Kearey) Date: Sun, 25 Feb 2007 11:51:32 +1000 Subject: FC6 updates broken deps? In-Reply-To: <63881.ZgEtUWFHE1E=.1172367265.squirrel@nmail.altkom.pl> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <45E0E1A5.60104@redhat.com> <63881.ZgEtUWFHE1E=.1172367265.squirrel@nmail.altkom.pl> Message-ID: <45E0EBA4.10504@redhat.com> Piotr Baranowski wrote: > Anybody really using that stuff ? > > Functionality seems to be cool but any real-life scenarios of yum shell > monkey-super-powers in action ? > One scenario I recently used it for was to install an un-signed rpm package from a trustworthy source. It saved me having to edit /etc/yum.conf to turn off gpgcheck and then do yum localinstall .ie : yum shell ... > config gpgcheck 0 > locallinstall /path/to/rpm/file.rpm It really just amounts to 'yet another way to do things' I can imagine there are more monkey-super-powers in there I have not thought of.. This is not really development discussion however, so this is where my posting ends on this subject :) Cheers, Michael From peter at thecodergeek.com Sun Feb 25 02:00:52 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 24 Feb 2007 18:00:52 -0800 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> Message-ID: <1172368852.15891.0.camel@localhost> On Sun, 2007-02-25 at 02:02 +0100, Benny Amorsen wrote: > [...] yum has no > reason to be interactive, it does not offer a command prompt or > connect you to another system with a command prompt. Nope. `yum shell` gives you a nice interactive interface. :) -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 linville at redhat.com Sun Feb 25 02:35:27 2007 From: linville at redhat.com (John W. Linville) Date: Sat, 24 Feb 2007 21:35:27 -0500 Subject: d80211 and iwlwifi In-Reply-To: <1172355520.19751.3.camel@bureau.maison> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> Message-ID: <20070225023527.GA8693@redhat.com> On Sat, Feb 24, 2007 at 11:18:40PM +0100, Tanguy Eric wrote: > Le samedi 24 f?vrier 2007 ? 21:56 +0000, Mike Cohler a ?crit : > > I hope this is not a repeat question but is it planned to have d80211 > > and iwlwifi in the F7 release? > > > > If so is it planned to put these into updates for FC6 at some point? > > > For the d80211 stack it will be in the kernel when it will be ready but It is in rawhide as of today, and it should be upstream in -mm soon. > if i remember well there was 2 stacks, one from intel and an other one. I think you are confused by the fact that Intel is packaging a snapshot of the stack to enable their driver on older kernels. This should not be necessary for us. > I heard something soon because i heard for 2.6.21 but i'm not sure. > Dave, have you got news about this ? > Concerning iwlwifi, i think it will be a license problem so not in > fedora but maybe in an other repo. The iwlwifi driver is the new version, that does _not_ require binary userland bits. There should be no licensing issue with the driver in Fedora. I'm not 100% sure what the firmware license will be, but that shouldn't be significantly different from the current ipw2x00 drivers. Hth! John -- John W. Linville linville at redhat.com From linville at redhat.com Sun Feb 25 02:38:31 2007 From: linville at redhat.com (John W. Linville) Date: Sat, 24 Feb 2007 21:38:31 -0500 Subject: d80211 and iwlwifi In-Reply-To: <20070225023527.GA8693@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> Message-ID: <20070225023831.GB8693@redhat.com> On Sat, Feb 24, 2007 at 09:35:27PM -0500, John W. Linville wrote: > On Sat, Feb 24, 2007 at 11:18:40PM +0100, Tanguy Eric wrote: > > Le samedi 24 f?vrier 2007 ? 21:56 +0000, Mike Cohler a ?crit : > > > I hope this is not a repeat question but is it planned to have d80211 > > > and iwlwifi in the F7 release? > > > > > > If so is it planned to put these into updates for FC6 at some point? > > > > > For the d80211 stack it will be in the kernel when it will be ready but > > It is in rawhide as of today, and it should be upstream in -mm soon. > > > if i remember well there was 2 stacks, one from intel and an other one. > > I think you are confused by the fact that Intel is packaging a > snapshot of the stack to enable their driver on older kernels. > This should not be necessary for us. > > > I heard something soon because i heard for 2.6.21 but i'm not sure. > > Dave, have you got news about this ? > > Concerning iwlwifi, i think it will be a license problem so not in > > fedora but maybe in an other repo. > > The iwlwifi driver is the new version, that does _not_ require binary > userland bits. There should be no licensing issue with the driver in > Fedora. I'm not 100% sure what the firmware license will be, but that > shouldn't be significantly different from the current ipw2x00 drivers. I should add that Intel has _not_ submitted an upstream patch for iwlwifi at this time. I anticipate they will do so "soon". John -- John W. Linville linville at redhat.com From florin at andrei.myip.org Sun Feb 25 02:47:32 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Sat, 24 Feb 2007 18:47:32 -0800 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> Message-ID: <45E0F8C4.6000406@andrei.myip.org> Panu Matilainen wrote: > On Sat, 24 Feb 2007, Callum Lerwick wrote: > >> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: >>> I think we should agree that yum _is_ broken here and needs to be fixed. >>> and no including a optional plugin won't help, the default behavior is >>> broken ( I would even say its a security bug) >> >> Does anyone else have an odd feeling of deja-vu? > > Yes, and a strong one at that. > > This and "but it shouldn't abort when unresolvable dependencies are > present" threads (among various other non-yum related ones) keep > recurring every few months. Perhaps there is a connection with the fact that yum _is_ broken? I suggest you should study the relation between cause and effect, it's really illuminating once you learn it. http://en.wikipedia.org/wiki/Causality -- Florin Andrei http://florin.myip.org/ From jwilson at redhat.com Sun Feb 25 06:04:52 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 25 Feb 2007 01:04:52 -0500 Subject: Detecting the need for additional kernel options? In-Reply-To: <20070224175653.GC4519@redhat.com> References: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> <20070224175653.GC4519@redhat.com> Message-ID: <45E12704.6080306@redhat.com> Dave Jones wrote: > On Sat, Feb 24, 2007 at 12:34:12PM -0500, Michel Salim wrote: > > Is Anaconda currently checking the machine configuration against a > > compatibility database? On some AMD64 laptops (including my HP L2000), > > the machine would lock up randomly (without any log message) if booted > > without "noapic" (I added "nosmp" for good measure). > > > > Perhaps a user-maintainable database; we can consider tying it in with > > Smolt so that only users who own a particular model can submit > > required kernel options for it (to verify ownership, give the user a > > token that they must pass to Smolt, e.g. smoltSendProfile > > --key=AF32EBD4008) > > > > Speaking of Smolt, the CPUspeed reported does not seem that useful, > > unless it interfaces with CPUspeed to first set the clockspeed to > > minimum, take a measurement, then set it to maximum, measure, and then > > restore the original setting? My 2GHz laptop was reported as a 1.6 .. > > instead of faffing about changing speeds, it could just report > the contents of /sys/devices/system/cpu/*/cpufreq/scaling_available_frequencies > if present. +1. Or if its preferable to only have the max speed, just grab it from /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq if present, and fall back to looking in /proc/cpuinfo scaling_max_freq isn't there. -- Jarod Wilson jwilson at redhat.com From nman64 at n-man.com Sun Feb 25 07:13:15 2007 From: nman64 at n-man.com (Patrick W. Barnes) Date: Sun, 25 Feb 2007 01:13:15 -0600 Subject: Goodbye, Fedora In-Reply-To: <20070221123307.GC2557@devserv.devel.redhat.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <20070221123307.GC2557@devserv.devel.redhat.com> Message-ID: <200702250113.18082.nman64@n-man.com> On Wednesday 21 February 2007, Alan Cox wrote: > > I'm sure they will be delighted to have you > ...maybe at first, but not for long. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://n-man.com/ LinkedIn: http://linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From baris at teamforce.name.tr Sun Feb 25 08:16:00 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Sun, 25 Feb 2007 10:16:00 +0200 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: References: <45DF5457.8070500@argo.co.il> Message-ID: <1172391360.3327.10.camel@localhost.localdomain> On Sun, 2007-02-25 at 01:59 +0100, Benny Amorsen wrote: > >>>>> "AK" == Avi Kivity writes: > > AK> Physical ownership is as much a fiction as information ownership. > AK> There's no physical law that says that just because you gave a > AK> shopkeeper some green pieces of paper, I can't take your new iPod > AK> when you aren't looking [1]. It's just a convention that allows > AK> society to work. > > One important difference is that if I steal your bicycle, you will > notice. If I give a copy of your program to a friend, you will not > notice. What if you got 10.000 bicycle and you did not notice of a theft accident since you counted it wrong or don't have a good stock management? Does it void your bicycle ownership and excuse the thief? Not that I'm trying to support IP, just trying to express that your analogy sounds wrong. > > > /Benny > > From pertusus at free.fr Sun Feb 25 10:24:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 25 Feb 2007 11:24:56 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172391360.3327.10.camel@localhost.localdomain> References: <45DF5457.8070500@argo.co.il> <1172391360.3327.10.camel@localhost.localdomain> Message-ID: <20070225102456.GA3012@free.fr> On Sun, Feb 25, 2007 at 10:16:00AM +0200, Baris Cicek wrote: > What if you got 10.000 bicycle and you did not notice of a theft > accident since you counted it wrong or don't have a good stock > management? Does it void your bicycle ownership and excuse the thief? Maybe noticing isn't the right word. Point is that information, when consumed don't show a decrease in its stock. It may be consumed by anybody at any time without decreasing the amount other have (it is a non rival good). http://en.wikipedia.org/wiki/Rivalry_%28economics%29 -- Pat From buildsys at redhat.com Sun Feb 25 11:22:05 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 25 Feb 2007 06:22:05 -0500 Subject: rawhide report: 20070225 changes Message-ID: <200702251122.l1PBM5VY027754@hs20-bc2-6.build.redhat.com> Updated Packages: (none) Broken deps for ia64 ---------------------------------------------------------- pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From ssorce at redhat.com Sun Feb 25 17:34:42 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 25 Feb 2007 12:34:42 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172391360.3327.10.camel@localhost.localdomain> References: <45DF5457.8070500@argo.co.il> <1172391360.3327.10.camel@localhost.localdomain> Message-ID: <1172424882.25282.25.camel@localhost.localdomain> On Sun, 2007-02-25 at 10:16 +0200, Baris Cicek wrote: > On Sun, 2007-02-25 at 01:59 +0100, Benny Amorsen wrote: > > >>>>> "AK" == Avi Kivity writes: > > > > AK> Physical ownership is as much a fiction as information ownership. > > AK> There's no physical law that says that just because you gave a > > AK> shopkeeper some green pieces of paper, I can't take your new iPod > > AK> when you aren't looking [1]. It's just a convention that allows > > AK> society to work. > > > > One important difference is that if I steal your bicycle, you will > > notice. If I give a copy of your program to a friend, you will not > > notice. > What if you got 10.000 bicycle and you did not notice of a theft > accident since you counted it wrong or don't have a good stock > management? Does it void your bicycle ownership and excuse the thief? What if I have a revolutionary machine that can copy your bicycle and reproduce it perfectly? Would it be theft if I come and copy yours and than go away leaving yours intact? > Not that I'm trying to support IP, just trying to express that your > analogy sounds wrong. Analogies are always wrong, simply because we are not comparing apples to apples, a bicycle is a physical object, software is not. Persisting in trying to treat "Intellectual Property" like traditional forms of property on physical objects is just plain stupid. Unless it is done on purpose, to confuse people, in which case it is criminal imo, as it is a form of fraud. Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From michel.salim at gmail.com Sun Feb 25 17:39:25 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 25 Feb 2007 12:39:25 -0500 Subject: Detecting the need for additional kernel options? In-Reply-To: <45E07C6B.7000205@leemhuis.info> References: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> <45E07C6B.7000205@leemhuis.info> Message-ID: <883cfe6d0702250939i1d7b828q57a741ce1bfa3e28@mail.gmail.com> 2007/2/24, Thorsten Leemhuis : > Michel Salim schrieb: > > Is Anaconda currently checking the machine configuration against a > > compatibility database? On some AMD64 laptops (including my HP L2000), > > the machine would lock up randomly (without any log message) if booted > > without "noapic" (I added "nosmp" for good measure). > > > > Perhaps a user-maintainable database; we can consider tying it in with > > Smolt so that only users who own a particular model can submit > > required kernel options for it (to verify ownership, give the user a > > token that they must pass to Smolt, e.g. smoltSendProfile > > --key=AF32EBD4008) > > Why not fix it in the kernel once and for all? That has benefits for > everyone, as no user has to care about options ever again and the > problems get fixed in all distributions over time... > That'd be ideal, unfortunately, in this case I just realize my original quickfix is probably not right -- I still get intermittent crashes (with the screen going a bit blurry if the monitor is on at that moment). Cheers, -- Michel Salim http://hircus.wordpress.com/ From kevin at scrye.com Sun Feb 25 18:21:33 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 25 Feb 2007 11:21:33 -0700 Subject: F7 Release Discussion (was Re: Slightly OT: bad rap for Fedora, and realistic effects) In-Reply-To: <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070225112133.4d3cb9af@ningauble.scrye.com> On Sat, 24 Feb 2007 13:40:09 +0100 mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > On Fri, 23 Feb 2007 14:55:22 -0700, Kevin Fenzi wrote: > > > > > - Revoke sponsorship in the event that the person refuses to > > > > follow rules, and deal with that persons leftover packages. > > > > > > The second part is new to me. Leftover packages would be orphaned. > > > > Sure, but there might be open bugs to close, other packages that > > depend on those packages that a new maintainer should be found for, > > binary rpms to remove from repositories, etc. > > Now it's getting interesting. Being a sponsor has never before implied > that you have to fix orphans or take over packages when a sponsored > person leaves the project or is AWOL. With such a requirement, the > sponsorship system would be too burdensome and too much of a risk. ok. So, who should handle those things? FESCo? No one? Would you like to update that wiki page with your thoughts on it? > > What do you see such a roadmap containing? > > Points that give the impression that there is the desire to have a > product ready when Fedora 7 will be released. When to have packages > rebuilt and ready, whether and when there will be any sort of freeze > (especially with regard to ABI and API breakage), "last resort"/"last > minutes" procedures for fixing packages where package owners have not > met the deadline. I see Matt Domsch' build failure report, I see the > complicated and lengthy AWOL procedure, I see that test2 is close, > but Extras 7 is broken in many areas, I see ACLs which lock down > packages in CVS, and all that would benefit from plans on how to > bring Extras 7 in shape in time. For much of this with the merged tree, we will be using the procedure that former Core used to use? http://www.fedoraproject.org/wiki/JesseKeating/RelEng Perhaps Jesse could comment and put up a more exacting page with dates where broken packages must be fixed, procedures for freeze, etc? I agree it would be good to have a schedule with dates for each step, when freezes are, what to do about packages that are still broken by freeze, etc. Some of the E-V-R and broken deps problems have been fixed, but not pushed out in devel since we are in test2 freeze, it looks like? Also, it doesn't look like the broken EVR report mails anyone, just goes to the list. Could you change it to mail owners? I think some people might be missing the problem. I think we could also figure out the core owners for the core packages that have broken EVR, and mail them too... or I can do so manually. On the subject of broken deps, I can look at assisting people with those. Will go file bugs and see if there are any that are easy to fix. Does the script just run 'repoclosure' ? I look at csound and paraview the other day, and neither of those look to be a simple fix. ;( kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bojan at rexursive.com Sun Feb 25 20:09:53 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sun, 25 Feb 2007 20:09:53 +0000 (UTC) Subject: Is there room for improvement in rescue mode? (was Re: Goodbye, Fedora) References: <604aa7910702221105s37c486c1m146d4d2ea1031f92@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > > On 2/22/07, Thomas M Steenholdt tmus.dk> wrote: > > In all fairness, I wouldn't have performed that backup neither, as I > > expect is true for a lot of even semi-knowledgable sysadmins and generic > > linux powerusers. Not sor something as simple as this. However - There > > is still the rescue mode that's been mentioned a few times already, > > which could have fixed the issue in a matter of minutes. Without the backup! > > In an effort to chart a new course of constructive discussion... is it > worth brainstorming a bit about how to make rescue mode better or more > accessible? Let's just make sure that we don't advertise that not doing backups before performing dangerous stuff on your system is the way to go. Once you enter the rescue mode, you have to be thinking "even if this doesn't work, I'm still good", not "shit, if this doesn't work, I'm completely screwed". Going back to the original problem of ESR not using the rescue disk, do we actually know why he didn't use it? Did he even know of its existence? Maybe that's the problem - people don't know it's there and what can be done with it... -- Bojan From mschwendt.tmp0701.nospam at arcor.de Sun Feb 25 20:31:46 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 25 Feb 2007 21:31:46 +0100 Subject: F7 Release Discussion (was Re: Slightly OT: bad rap for Fedora, and realistic effects) In-Reply-To: <20070225112133.4d3cb9af@ningauble.scrye.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> <20070225112133.4d3cb9af@ningauble.scrye.com> Message-ID: <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> On Sun, 25 Feb 2007 11:21:33 -0700, Kevin Fenzi wrote: > > > > > - Revoke sponsorship in the event that the person refuses to > > > > > follow rules, and deal with that persons leftover packages. > > > > > > > > The second part is new to me. Leftover packages would be orphaned. > > > > > > Sure, but there might be open bugs to close, other packages that > > > depend on those packages that a new maintainer should be found for, > > > binary rpms to remove from repositories, etc. > > > > Now it's getting interesting. Being a sponsor has never before implied > > that you have to fix orphans or take over packages when a sponsored > > person leaves the project or is AWOL. With such a requirement, the > > sponsorship system would be too burdensome and too much of a risk. > > ok. So, who should handle those things? FESCo? > No one? Quite obviously, those are not the only two options. And hence the answer to the latter two questions is "no". > Would you like to update that wiki page with your thoughts on it? Such thoughts ought to come from the governing body of the project, since 1) the CLA and the contributor sponsorship system is their sphere of responsibility, 2) a successful sponsorship system makes it possible to scale, and 3) it can also happen that sponsors leave the project. > > > What do you see such a roadmap containing? > > > > Points that give the impression that there is the desire to have a > > product ready when Fedora 7 will be released. When to have packages > > rebuilt and ready, whether and when there will be any sort of freeze > > (especially with regard to ABI and API breakage), "last resort"/"last > > minutes" procedures for fixing packages where package owners have not > > met the deadline. I see Matt Domsch' build failure report, I see the > > complicated and lengthy AWOL procedure, I see that test2 is close, > > but Extras 7 is broken in many areas, I see ACLs which lock down > > packages in CVS, and all that would benefit from plans on how to > > bring Extras 7 in shape in time. > > For much of this with the merged tree, we will be using the procedure > that former Core used to use? Is that a question? Apart from that, we don't have "the merged tree" yet, so it is more interesting how to proceed until test3 and beyond. > http://www.fedoraproject.org/wiki/JesseKeating/RelEng > > Perhaps Jesse could comment and put up a more exacting page with dates > where broken packages must be fixed, procedures for freeze, etc? > > I agree it would be good to have a schedule with dates for each step, > when freezes are, what to do about packages that are still broken by > freeze, etc. > > Some of the E-V-R and broken deps problems have been fixed, but not > pushed out in devel since we are in test2 freeze, it looks like? Well, Core is frozen, Extras doesn't have any schedule ;-), but right, after the topic had come up on maintainers-list, Extras devel is sort of in a freeze, too, and pushed to only on demand. > Also, it doesn't look like the broken EVR report mails anyone, just > goes to the list. Could you change it to mail owners? I think some > people might be missing the problem. The code that would do that [without creating too much spam] is missing. > I think we could also figure out > the core owners for the core packages that have broken EVR, and mail > them too... or I can do so manually. What is needed is a clear word that those issues are considered bugs that need addressing and will be fixed. It is an unthankful task for any contributor to spend time on filing such issues, if the tickets stay open for a very long time (e.g. until the affected dist will see EOL). > On the subject of broken deps, I can look at assisting people with > those. Will go file bugs and see if there are any that are easy to > fix. Does the script just run 'repoclosure' ? A modified version, but running the original repoclosure from yum-utils should work to check packages and local builds, too. From fellacious at gmail.com Mon Feb 26 01:04:30 2007 From: fellacious at gmail.com (Abdul Al-Felashis) Date: Sun, 25 Feb 2007 20:04:30 -0500 Subject: GNAA announces switch to Windows Vista Message-ID: GNAA announces switch to Windows Vista fellacious (GNAP) Intercourse, PA- Windows Vista appears to finally be taking off, at least within one Fortune 100 company. The GNAA had for the past 13 years been using Red Hat Linux and it's successor, Fedora Core, but growing discontent with the free software operating system forced CTO Jmax to declare on Wednesday that the company was to be switching its entire infrastructure to the new version of Windows, effective immediately. "I'm not going to theatrically claim that I wasn't expecting to have to do this," Jmax said. "This has been coming for quite some time." The GNAA's troubles with Red Hat's Linux system included chronic governance problems, a persistent failure to maintain key repositories, a complex and undocumented submission process which has kept the GNAA's free trolling utilities off the Red Hat-based desktops of thousands of would-be trolls, inability to keep RPM up to date, and a failure to address the problem of Firefox not crashing a entire computer when the user loads Last Measure. "The deal-breaker, though, was when a key Last Measure server remained down for four hours while our entire Intercourse development team tried desperately to bring it up despite not having statically-linked package manager binaries." What had happened was Dikky, visiting from Norway, wanted to play the child pornography mod of Doom 3 on that server- which had to drag several libraries with it. "In addition," said Jmax, "several key software applications used in the GNAA's corporate workflow are proprietary software- which means that they had to be run in an Ubuntu compatibility environment anyway." However, being as those unnamed applications were written in C#.NET, "We expect that our transition to Windows Vista will come off without a hitch." About Jmax: The CTO of the GNAA, Jmax also has a seat on Microsoft's board of directors. His resume can be accessed at http://goatse.fr/ About Windows Vista: The fastest-growing desktop operating system on the market, Windows Vista combines the legendary security of Windows 98 with the legendary ease of use of those computer interfaces you see in the movies into one ultra-fast, ultra-stable computing platform. About Red Hat: A failure of a computer company, Red Hat burns through investor money while giving its products away for free. It is currently under investigation from the SEC for misuse of invested funds, and being sued by the GNAA for breach of contract for sucking more than specified in the GNAA's contract with Red Hat. About the Linux community: Trolled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.wiktowy at gmail.com Mon Feb 26 02:57:03 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Sun, 25 Feb 2007 21:57:03 -0500 Subject: GNAA announces switch to Windows Vista In-Reply-To: References: Message-ID: <3e4ec4600702251857k3baee9b5m6bfd164b376f6e20@mail.gmail.com> On 2/25/07, Abdul Al-Felashis wrote: > GNAA announces switch to Windows Vista OT ... please take this to other lists that haven't just recently been flooded with a zillion ESR-switching publicity-troll threads. That would preclude taking it to any fedora/redhat-based mailing list. From gmaxwell at gmail.com Mon Feb 26 02:59:28 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 25 Feb 2007 21:59:28 -0500 Subject: GNAA announces switch to Windows Vista In-Reply-To: <3e4ec4600702251857k3baee9b5m6bfd164b376f6e20@mail.gmail.com> References: <3e4ec4600702251857k3baee9b5m6bfd164b376f6e20@mail.gmail.com> Message-ID: On 2/25/07, Michael Wiktowy wrote: > On 2/25/07, Abdul Al-Felashis wrote: > > GNAA announces switch to Windows Vista > > OT ... please take this to other lists that haven't just recently been > flooded with a zillion ESR-switching publicity-troll threads. That > would preclude taking it to any fedora/redhat-based mailing list. I dunno, I think it is useful to see usability complaints from a group who is less well known for trolling than ESR. From wtogami at redhat.com Mon Feb 26 04:57:08 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 25 Feb 2007 23:57:08 -0500 Subject: GNAA announces switch to Windows Vista In-Reply-To: References: <3e4ec4600702251857k3baee9b5m6bfd164b376f6e20@mail.gmail.com> Message-ID: <45E268A4.1000600@redhat.com> Gregory Maxwell wrote: > On 2/25/07, Michael Wiktowy wrote: >> On 2/25/07, Abdul Al-Felashis wrote: >> > GNAA announces switch to Windows Vista >> >> OT ... please take this to other lists that haven't just recently been >> flooded with a zillion ESR-switching publicity-troll threads. That >> would preclude taking it to any fedora/redhat-based mailing list. > > I dunno, I think it is useful to see usability complaints from a group > who is less well known for trolling than ESR. > I am seriously confused by this thread. At first I thought this might be a parody making fun of ESR... but huh!? http://www.encyclopediadramatica.com/index.php/GNAA It is difficult to know for sure based upon the reputable sources online, but GNAA seems to be some kind of trolling organization that operates in a manner that aims to annoy just about everyone, for seemingly no purpose. http://www.gnaa.us/press.phtml Fedora was just the latest drive-by trolling victim. So I guess in a way, this is a parody of ESR. Although it wasn't funny. Just confusing. Best to ignore trolls. If you react, it encourages them to troll more. Just shrug your shoulders and move on. Warren Togami wtogami at redhat.com From eric.tanguy at univ-nantes.fr Mon Feb 26 05:54:10 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 26 Feb 2007 06:54:10 +0100 Subject: d80211 and iwlwifi In-Reply-To: <20070225023527.GA8693@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> Message-ID: <1172469250.3142.2.camel@bureau.maison> Le samedi 24 f?vrier 2007 ? 21:35 -0500, John W. Linville a ?crit : > On Sat, Feb 24, 2007 at 11:18:40PM +0100, Tanguy Eric wrote: > > Le samedi 24 f?vrier 2007 ? 21:56 +0000, Mike Cohler a ?crit : > > > I hope this is not a repeat question but is it planned to have d80211 > > > and iwlwifi in the F7 release? > > > > > > If so is it planned to put these into updates for FC6 at some point? > > > > > For the d80211 stack it will be in the kernel when it will be ready but > > It is in rawhide as of today, and it should be upstream in -mm soon. > > > if i remember well there was 2 stacks, one from intel and an other one. > > I think you are confused by the fact that Intel is packaging a > snapshot of the stack to enable their driver on older kernels. > This should not be necessary for us. Thanks for the explanation. Will these kernels be available for fc-6 ? These kernels contains the free ralink driver rt2x00 ? > > > I heard something soon because i heard for 2.6.21 but i'm not sure. > > Dave, have you got news about this ? > > Concerning iwlwifi, i think it will be a license problem so not in > > fedora but maybe in an other repo. > > The iwlwifi driver is the new version, that does _not_ require binary > userland bits. There should be no licensing issue with the driver in > Fedora. I'm not 100% sure what the firmware license will be, but that > shouldn't be significantly different from the current ipw2x00 drivers. > > Hth! > > John > -- > John W. Linville > linville at redhat.com > From aoliva at redhat.com Mon Feb 26 07:07:33 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 26 Feb 2007 04:07:33 -0300 Subject: Goodbye, Fedora In-Reply-To: (Thomas M. Steenholdt's message of "Fri\, 23 Feb 2007 11\:16\:38 +0100") References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> Message-ID: On Feb 23, 2007, Thomas M Steenholdt wrote: > Amusing or not, it does confirm that our current policy of keeping all > the proprietary stuff away from Fedora, is really for the best. Just a small clarification. Patent-encumbered doesn't mean proprietary. Many of the multi-media packages that are kept out of Fedora *are* Free Software, but they can't be shipped from the US because of software patents. Fedora actually helps weaken the software patents system by rejecting even such Free Software packages, and promoting Free Software implementations of Free Standards instead. A wise use of the fifth freedom: http://www.fsfla.org/?q=en/node/139#1 But if it weren't for legal, patent-related reasons, Fedora could include such packages without breaking its vow to not ship non-Free Software (other than policy allowing for non-Free firmware). -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Mon Feb 26 07:16:44 2007 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 26 Feb 2007 04:16:44 -0300 Subject: keeping all he proprietary stuff away from Fedora In-Reply-To: <45DEDAFA.1070806@leemhuis.info> (Thorsten Leemhuis's message of "Fri\, 23 Feb 2007 13\:15\:54 +0100") References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> <45DEDAFA.1070806@leemhuis.info> Message-ID: On Feb 23, 2007, Thorsten Leemhuis wrote: > - if that 3rd party repo would have be slitted in non-free stuff and > potential harmful stuff, so users and contributors from the US and > some other country's can safely work with the non-free repo without > getting involved with the more problematic stuff I for one would love to be able to enable third-party repositories containing only Free Software, even if encumbered by patents (that are worth nothing in Brazil, where I live), without the risk of pulling in some non-Free Software by accident. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From gilboad at gmail.com Mon Feb 26 09:33:15 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 26 Feb 2007 11:33:15 +0200 Subject: FC6 updates broken deps? In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <1172203101.8388.12.camel@gilboa-home-dev.localdomain> <20070223091255.1bec8fee@banea.int.addix.net> <1172222243.23237.405.camel@mccallum.corsepiu.local> <20070223110045.GB29094@devserv.devel.redhat.com> <8374.YFF3UmUVE1E=.1172237284.squirrel@nmail.altkom.pl> Message-ID: <1172482395.3625.4.camel@gilboa-work-dev.localdomain> On Fri, 2007-02-23 at 14:37 +0100, Thomas M Steenholdt wrote: > Piotr Baranowski wrote: > > Alan Cox wrote(a): > >> On Fri, Feb 23, 2007 at 10:17:23AM +0100, Ralf Corsepius wrote: > >>> I disagree - All programs should immediately terminate upon "Ctrl-C". > >>> Switching to a different mirror should be done by any arbitrary key. > >> Someone please fix emacs to terminate immediately on ctrl-C then ;) > >> > >> Very large numbers of programs override ^C to be an internal interrupt, > >> including things like ftp. Others specifically ignore it (try using ssh > >> without that) > > > > I think we can accept such weirdness of some applications. > > > > Most people will understand WHY ^c is overriden in ssh for example. > > > > For me after 10 years of linux experience it was great mistery why a hell > > does yum override ^c. > > > > There is no clear reason for it to behave like that. > > > > My suggestion ? > > ^m and a startup message like: > > > > "If you want to switch from one mirror to another press CTRL+M" > > > > regards > > > > That would probably also help the fact, that (last i checked) ^C does > switch mirrors, but it also prevents anything useful from happening at > the end of the download process. I.e. yum -y update would download > packages, ^C cause it to switch mirrors and keep downloading, but the > expected update at the end of the download is skipped. > > /Thomas > /+1 Switch mirror doesn't always work. BTW, there's an assortments of bugs about it. [1] - Gilboa [1] https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora +Core&component=yum&bug_status=NEW&bug_status=VERIFIED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=FAILS_QA&bug_status=RELEASE_PENDING&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=Ctrl-C From gilboad at gmail.com Mon Feb 26 09:37:58 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 26 Feb 2007 11:37:58 +0200 Subject: FC6 updates broken deps? In-Reply-To: <1172297215.4322.62.camel@localhost.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> Message-ID: <1172482678.3625.5.camel@gilboa-work-dev.localdomain> On Sat, 2007-02-24 at 00:06 -0600, Callum Lerwick wrote: > On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: > > I think we should agree that yum _is_ broken here and needs to be fixed. > > and no including a optional plugin won't help, the default behavior is > > broken ( I would even say its a security bug) > > Does anyone else have an odd feeling of deja-vu? It's so annoying that I'm thinking about learning python just so I can submit a patch to fix it... :( - Gilboa From johannbg at hi.is Mon Feb 26 10:15:01 2007 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Mon, 26 Feb 2007 10:15:01 +0000 Subject: 2. Questions?? Message-ID: <45E2B325.20509@hi.is> Still noticed when I downloaded and installed FC6 of dvd that the I586 Issue had not been fixed, Some how I my brain thought that a new dvd would be released that would contain the correct kernel ( I686 or I386) Unless there is some reason for it not to be addressed? Thought that creating a new DVD Image would be better than letting all FC6 newcomers have to figure out of it on their own. In the upcoming release of FC7, Core and Extras become one repository :) Wouldnt it be splended if Maintainers of Freshrpms and Livna would join hands and merge as well :) Keep up the good work Best Regards J?hann B. -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From kagesenshi.87 at gmail.com Mon Feb 26 10:39:23 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Mon, 26 Feb 2007 18:39:23 +0800 Subject: 2. Questions?? In-Reply-To: <45E2B325.20509@hi.is> References: <45E2B325.20509@hi.is> Message-ID: On 2/26/07, "J?hann B. Gu?mundsson" wrote: > > In the upcoming release of FC7, Core and Extras become one repository :) > Wouldnt it be splended if Maintainers of Freshrpms and Livna would join > hands and merge as well :) I dont think thats possible .. Freshrpms and Livna provides proprietary packages , Fedora strive to provide only Free softwares -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com GPG: http://www.rootshell.be/~kagesens/public-key.asc Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From johannbg at hi.is Mon Feb 26 10:59:04 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 26 Feb 2007 10:59:04 +0000 Subject: 2. Questions?? In-Reply-To: References: <45E2B325.20509@hi.is> Message-ID: <45E2BD78.9040501@hi.is> Hikaru Amano wrote: > On 2/26/07, "J?hann B. Gu?mundsson" wrote: >> >> In the upcoming release of FC7, Core and Extras become one repository :) >> Wouldnt it be splended if Maintainers of Freshrpms and Livna would join >> hands and merge as well :) > > I dont think thats possible .. Freshrpms and Livna provides > proprietary packages , Fedora strive to provide only Free softwares > I was not talking about merging it with the Fedora repos I was succesting about Freshrpms and Livna joining into one "unofficial" repo One place for official && one place for unofficial. I would think that if they would team up and work together it would provide better end results instead of both reinventing the wheel intheir own corners. Best regards J?hann B. -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From avi at argo.co.il Mon Feb 26 06:31:00 2007 From: avi at argo.co.il (Avi Kivity) Date: Mon, 26 Feb 2007 08:31:00 +0200 Subject: [Mandrakeot] ESR gives up on Fedora Message-ID: <45E27EA4.2030603@argo.co.il> Simo Sorce wrote: > What if I have a revolutionary machine that can copy your bicycle and > reproduce it perfectly? > Would it be theft if I come and copy yours and than go away leaving > yours intact? > > It destroys my bicycle rental business, which is based on my unique bicycle-for-fourteen design. Go clone your own bike and leave mine alone. >> Not that I'm trying to support IP, just trying to express that your >> analogy sounds wrong. >> > > Analogies are always wrong, simply because we are not comparing apples > to apples, a bicycle is a physical object, software is not. > > Persisting in trying to treat "Intellectual Property" like traditional > forms of property on physical objects is just plain stupid. Unless it is > done on purpose, to confuse people, in which case it is criminal imo, as > it is a form of fraud. > One motivation in creating new ideas (and in writing software) is to be able to be rewarded by it. If anyone can copy my software, my movie, my song, my cookie recipe, or my bicycle design, I may just not do it, and wait for you to come up with it instead. Producing ideas, software, movies, songs, cookie recipes, and bicycle design takes considerable effort, just like acquiring physical objects. Ownership over an object means control, and so does ownership over ideas. It's okay for you or your employer to place all the results of your efforts in the public domain if you wish (and no, the GPL isn't public domain) but that is the result of your own choice. Forcing others to do so will cause others either stop stop producing ideas or to tie them into physical objects so that one can't steal them ("appliances"). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giallu at gmail.com Mon Feb 26 11:11:23 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 26 Feb 2007 12:11:23 +0100 Subject: 2. Questions?? In-Reply-To: <45E2B325.20509@hi.is> References: <45E2B325.20509@hi.is> Message-ID: On 2/26/07, "J?hann B. Gu?mundsson" wrote: > Still noticed when I downloaded and installed FC6 of dvd > that the I586 Issue had not been fixed, Some how I my brain thought > that a new dvd would be released that would contain the correct kernel ( > I686 or I386) > Unless there is some reason for it not to be addressed? It is. But new DVD images (aka respins) are not published by the Fedora Project itself. You may want to have look here: http://fedoraunity.org/re-spins From buildsys at redhat.com Mon Feb 26 11:12:21 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 26 Feb 2007 06:12:21 -0500 Subject: rawhide report: 20070226 changes Message-ID: <200702261112.l1QBCLAV002324@hs20-bc2-6.build.redhat.com> Updated Packages: kernel-2.6.20-1.2947.fc7 ------------------------ * Sun Feb 25 2007 David Woodhouse - Revert commit 8d610dd52dd1da696e199e4b4545f33a2a5de5c6 which moved rootfs population (and free_initrd()) much later in the init sequence. It seems to cause memory corruption. * Sat Feb 24 2007 John W. Linville - Back-out bcm43xx changes related to recent hardware spec changes * Sat Feb 24 2007 David Woodhouse - Disable PlayStation 3 support temporarily; its drivers break on non-PS3 and it's not quite working fully yet anyway Broken deps for ia64 ---------------------------------------------------------- pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From kagesenshi.87 at gmail.com Mon Feb 26 11:22:47 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Mon, 26 Feb 2007 19:22:47 +0800 Subject: 2. Questions?? In-Reply-To: <45E2BD78.9040501@hi.is> References: <45E2B325.20509@hi.is> <45E2BD78.9040501@hi.is> Message-ID: On 2/26/07, "J?hann B. Gu?mundsson" wrote: > I was not talking about merging it with the Fedora repos > > I was succesting about Freshrpms and Livna joining into one "unofficial" > repo > One place for official && one place for unofficial. > > I would think that if they would team up and work together it would provide > better end results instead of both reinventing the wheel intheir own > corners. This matter should be asked to the repo maintainers / the repo's mailing list .. rather than to this mailing list .. -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com GPG: http://www.rootshell.be/~kagesens/public-key.asc Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From johannbg at hi.is Mon Feb 26 11:33:54 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 26 Feb 2007 11:33:54 +0000 Subject: 2. Questions?? In-Reply-To: References: <45E2B325.20509@hi.is> Message-ID: <45E2C5A2.4090208@hi.is> Why not? Is it not better for the end user to always have the latest copy? ( Less to update, Bugs fixed that were in the first release etc etc ) What logical reason does the publishing team at the Fedora-Project provide for not providing the latest respins? ( given that respins are made every 30 days or so ) Interested in what the man/team who's in charge has to say about this. Gianluca Sforna wrote: > On 2/26/07, "J?hann B. Gu?mundsson" wrote: >> Still noticed when I downloaded and installed FC6 of dvd >> that the I586 Issue had not been fixed, Some how I my brain thought >> that a new dvd would be released that would contain the correct kernel ( >> I686 or I386) >> Unless there is some reason for it not to be addressed? > > It is. But new DVD images (aka respins) are not published by the > Fedora Project itself. > > You may want to have look here: > http://fedoraunity.org/re-spins > -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From johannbg at hi.is Mon Feb 26 11:53:09 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 26 Feb 2007 11:53:09 +0000 Subject: 2. Questions?? In-Reply-To: References: <45E2B325.20509@hi.is> <45E2BD78.9040501@hi.is> Message-ID: <45E2CA25.7090700@hi.is> I Disagree What better place to meet and discuss this, than here on the ground they're building on? Letting the whole community here hear theyr opinions instead of everybody running between mailing lists. Best Regards J?hann B. Hikaru Amano wrote: > On 2/26/07, "J?hann B. Gu?mundsson" wrote: >> I was not talking about merging it with the Fedora repos >> >> I was succesting about Freshrpms and Livna joining into one "unofficial" >> repo >> One place for official && one place for unofficial. >> >> I would think that if they would team up and work together it would >> provide >> better end results instead of both reinventing the wheel intheir own >> corners. > > This matter should be asked to the repo maintainers / the repo's > mailing list .. rather than to this mailing list .. > -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From sundaram at fedoraproject.org Mon Feb 26 11:58:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Feb 2007 17:28:48 +0530 Subject: 2. Questions?? In-Reply-To: <45E2C5A2.4090208@hi.is> References: <45E2B325.20509@hi.is> <45E2C5A2.4090208@hi.is> Message-ID: <45E2CB78.1090603@fedoraproject.org> J?hann B. Gu?mundsson wrote: > Why not? > > Is it not better for the end user to always have the latest copy? > ( Less to update, Bugs fixed that were in the first release etc etc ) > > What logical reason does the publishing team at the Fedora-Project provide > for not providing the latest respins? ( given that respins are made > every 30 days or so ) > > Interested in what the man/team who's in charge has to say about this. > We have limited resources. A respin requires not only the ability to merge back updates easily but also the ability to do the full QA that we do before the general releases. Doing it on a regular interval of say every month (otherwise the updates would be very large) is lot of work. There is work being done to solve these. Distribution spin tool - https://hosted.fedoraproject.org/projects/pungi Automated test suite - http://fedoraproject.org/wiki/QA/Beaker The problem that respins resolve ( large number of updates for users on low bandwidth networks) can potentially be solved usually other methods Delta RPMS - https://hosted.fedoraproject.org/projects/presto Adding more metadata and providing the ability for users to pick only security updates for example. http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem Rahul From kagesenshi.87 at gmail.com Mon Feb 26 12:16:33 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Mon, 26 Feb 2007 20:16:33 +0800 Subject: 2. Questions?? In-Reply-To: <45E2CA25.7090700@hi.is> References: <45E2B325.20509@hi.is> <45E2BD78.9040501@hi.is> <45E2CA25.7090700@hi.is> Message-ID: On 2/26/07, "J?hann B. Gu?mundsson" wrote: > I Disagree > > What better place to meet and discuss this, than here > on the ground they're building on? > > Letting the whole community here hear theyr opinions instead > of everybody running between mailing lists. Well .. its because the repo is not maintained / owned by Fedora itself , but by the repo's own team .. therefore - unofficial ... I personally would agree Freshrpms and Livna to merge ... its something great .. but its still the owners decision whether to merge or not .. about the getting community opinion about that .. fedora-list is more appropriate IMO .. and not fedora-devel-list .. (to moderators: Is this matter on topic or off topic of this mailing list?? thanks ) -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com GPG: http://www.rootshell.be/~kagesens/public-key.asc Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From markw at mohawksoft.com Mon Feb 26 13:05:34 2007 From: markw at mohawksoft.com (markw at mohawksoft.com) Date: Mon, 26 Feb 2007 08:05:34 -0500 (EST) Subject: PHP Webserver Cluster Tool Message-ID: <19536.24.91.171.78.1172495134.squirrel@mail.mohawksoft.com> I'm not looking to spam these discussions, but I am in need of some beta testers and good old fashioned QA and feedback. I have an GPL Free/OpenSource software project called MCache. Its primary goal is to facilitate and augment web cluster session management, primarily in PHP but can easily be used for Java. My open source site is: http://www.mohawksoft.org. A brief discussion is located here: http://www.mohawksoft.org/?q=node/36 The main documentation is located here: http://www.mohawksoft.org/?q=node/8 Any and all help in this project is appreciated. From dcbw at redhat.com Mon Feb 26 12:41:25 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 26 Feb 2007 07:41:25 -0500 Subject: d80211 and iwlwifi In-Reply-To: <1172469250.3142.2.camel@bureau.maison> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> <1172469250.3142.2.camel@bureau.maison> Message-ID: <1172493685.3061.4.camel@localhost.localdomain> On Mon, 2007-02-26 at 06:54 +0100, Tanguy Eric wrote: > Le samedi 24 f?vrier 2007 ? 21:35 -0500, John W. Linville a ?crit : > > On Sat, Feb 24, 2007 at 11:18:40PM +0100, Tanguy Eric wrote: > > > Le samedi 24 f?vrier 2007 ? 21:56 +0000, Mike Cohler a ?crit : > > > > I hope this is not a repeat question but is it planned to have d80211 > > > > and iwlwifi in the F7 release? > > > > > > > > If so is it planned to put these into updates for FC6 at some point? > > > > > > > For the d80211 stack it will be in the kernel when it will be ready but > > > > It is in rawhide as of today, and it should be upstream in -mm soon. > > > > > if i remember well there was 2 stacks, one from intel and an other one. > > > > I think you are confused by the fact that Intel is packaging a > > snapshot of the stack to enable their driver on older kernels. > > This should not be necessary for us. > > Thanks for the explanation. Will these kernels be available for fc-6 ? > These kernels contains the free ralink driver rt2x00 ? I'd hope d80211 and the associated drivers are _not_ shipped for FC6 (unless in testing) until they have settled down quite a bit. They still have quite a lot of maturing to do. Dan > > > > > I heard something soon because i heard for 2.6.21 but i'm not sure. > > > Dave, have you got news about this ? > > > Concerning iwlwifi, i think it will be a license problem so not in > > > fedora but maybe in an other repo. > > > > The iwlwifi driver is the new version, that does _not_ require binary > > userland bits. There should be no licensing issue with the driver in > > Fedora. I'm not 100% sure what the firmware license will be, but that > > shouldn't be significantly different from the current ipw2x00 drivers. > > > > Hth! > > > > John > > -- > > John W. Linville > > linville at redhat.com > > > From johannbg at hi.is Mon Feb 26 13:31:56 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 26 Feb 2007 13:31:56 +0000 Subject: 2. Questions?? In-Reply-To: <45E2CB78.1090603@fedoraproject.org> References: <45E2B325.20509@hi.is> <45E2C5A2.4090208@hi.is> <45E2CB78.1090603@fedoraproject.org> Message-ID: <45E2E14C.5020902@hi.is> Rahul Sundaram wrote: "We have limited resources. A respin requires not only the ability to merge back updates easily but also the ability to do the full QA that we do before the general releases. Doing it on a regular interval of say every month (otherwise the updates would be very large) is lot of work. There is work being done to solve these. Distribution spin tool - https://hosted.fedoraproject.org/projects/pungi Automated test suite - http://fedoraproject.org/wiki/QA/Beaker " It's good that work is being done to easy/automate creation of spin. Yet doesn't justify releasing an ISO that build against wrong kernel-arch ( I586 ) and not fixing it. QA? Correct me if I'm wrong but would it be enought to simple change the "default" kernel architecture line in the installation process to I686 and rebuild the image... "The problem that respins resolve ( large number of updates for users on low bandwidth networks) can potentially be solved usually other methods Delta RPMS - https://hosted.fedoraproject.org/projects/presto" Be it as it may you still have to download the ISO in the first place so it doesnt matter if you download a re-spin or not which *smashed* the bugs that "slipped through" in the initial release.... Adding more metadata and providing the ability for users to pick only security updates for example. More options means more complication which means more things can go wrong. ALWAYS expect the user who is setting up the system to be a complete novice. Best Regards J?hann B. Rahul Sundaram wrote: > J?hann B. Gu?mundsson wrote: >> Why not? >> >> Is it not better for the end user to always have the latest copy? >> ( Less to update, Bugs fixed that were in the first release etc etc ) >> >> What logical reason does the publishing team at the Fedora-Project >> provide >> for not providing the latest respins? ( given that respins are made >> every 30 days or so ) >> >> Interested in what the man/team who's in charge has to say about this. >> > > The problem that respins resolve ( large number of updates for users > on low bandwidth networks) can potentially be solved usually other > methods > > Delta RPMS - https://hosted.fedoraproject.org/projects/presto > > Adding more metadata and providing the ability for users to pick only > security updates for example. > > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem > > Rahul > -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From sundaram at fedoraproject.org Mon Feb 26 13:41:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Feb 2007 19:11:29 +0530 Subject: 2. Questions?? In-Reply-To: <45E2E14C.5020902@hi.is> References: <45E2B325.20509@hi.is> <45E2C5A2.4090208@hi.is> <45E2CB78.1090603@fedoraproject.org> <45E2E14C.5020902@hi.is> Message-ID: <45E2E389.1040806@fedoraproject.org> J?hann B. Gu?mundsson wrote: > It's good that work is being done to easy/automate creation of spin. > Yet doesn't justify releasing an ISO that build against wrong > kernel-arch ( I586 ) > and not fixing it. QA? The tools to do respins help when we invariably run into bugs that needs to be fixed or when folks want to redistribute Fedora with the updates included. The existence of bugs only justifies the need for more QA and a community effort would require that you contribute back by helping to fix the bugs by participating in such efforts. It is a collective responsibility. Join the QA team, report bugs, help triage bugs etc. > Correct me if I'm wrong but would it be enought to simple change the > "default" kernel architecture line > in the installation process to I686 and rebuild the image.. A updated ISO was indeed released anyway. http://fedoraproject.org/wiki/Bugs/FC6Common . > Be it as it may you still have to download the ISO in the first place so > it doesnt matter if you download a re-spin or not > which *smashed* the bugs that "slipped through" in the initial release.... That's only true if it is a installer issue. Otherwise the updates do fix the problem in the initial release. > More options means more complication which means more things can go wrong. It depends on how you expose the options. If you are willing to do the respins as part of Fedora, you are most welcome to do so. Rahul From jkeating at redhat.com Mon Feb 26 13:46:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 08:46:29 -0500 Subject: 2. Questions?? In-Reply-To: <45E2E14C.5020902@hi.is> References: <45E2B325.20509@hi.is> <45E2CB78.1090603@fedoraproject.org> <45E2E14C.5020902@hi.is> Message-ID: <200702260846.32699.jkeating@redhat.com> On Monday 26 February 2007 08:31, J?hann B. Gu?mundsson wrote: > Correct me if I'm wrong but would it be enought to simple change the > "default" kernel architecture line > in the installation process to I686 and rebuild the image... No, there was a bug in yum that made this happen. It wasn't something that could easily be fixed in the installer. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmus at tmus.dk Mon Feb 26 13:28:46 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Feb 2007 14:28:46 +0100 Subject: Goodbye, Fedora In-Reply-To: References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <1172203645.8388.18.camel@gilboa-home-dev.localdomain> Message-ID: Alexandre Oliva wrote: > On Feb 23, 2007, Thomas M Steenholdt wrote: > >> Amusing or not, it does confirm that our current policy of keeping all >> the proprietary stuff away from Fedora, is really for the best. > > Just a small clarification. Patent-encumbered doesn't mean > proprietary. Many of the multi-media packages that are kept out of > Fedora *are* Free Software, but they can't be shipped from the US > because of software patents. > > Fedora actually helps weaken the software patents system by rejecting > even such Free Software packages, and promoting Free Software > implementations of Free Standards instead. A wise use of the fifth > freedom: http://www.fsfla.org/?q=en/node/139#1 > > But if it weren't for legal, patent-related reasons, Fedora could > include such packages without breaking its vow to not ship non-Free > Software (other than policy allowing for non-Free firmware). > Absolutely! /Thomas From denis at poolshark.org Mon Feb 26 14:34:03 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 26 Feb 2007 15:34:03 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172482678.3625.5.camel@gilboa-work-dev.localdomain> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> Message-ID: <45E2EFDB.30903@poolshark.org> Gilboa Davara wrote: > On Sat, 2007-02-24 at 00:06 -0600, Callum Lerwick wrote: >> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: >>> I think we should agree that yum _is_ broken here and needs to be fixed. >>> and no including a optional plugin won't help, the default behavior is >>> broken ( I would even say its a security bug) >> Does anyone else have an odd feeling of deja-vu? > > It's so annoying that I'm thinking about learning python just so I can > submit a patch to fix it... :( While learning Python is a great idea, writing yum patches is unfortunately known to be a complete and utter waste of time :-( From sundaram at fedoraproject.org Mon Feb 26 14:38:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Feb 2007 20:08:02 +0530 Subject: FC6 updates broken deps? In-Reply-To: <45E2EFDB.30903@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> Message-ID: <45E2F0CA.7060605@fedoraproject.org> Denis Leroy wrote: > Gilboa Davara wrote: >> On Sat, 2007-02-24 at 00:06 -0600, Callum Lerwick wrote: >>> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: >>>> I think we should agree that yum _is_ broken here and needs to be >>>> fixed. >>>> and no including a optional plugin won't help, the default behavior >>>> is broken ( I would even say its a security bug) >>> Does anyone else have an odd feeling of deja-vu? >> >> It's so annoying that I'm thinking about learning python just so I can >> submit a patch to fix it... :( > > While learning Python is a great idea, writing yum patches is > unfortunately known to be a complete and utter waste of time :-( What patches did you submit? Rahul From skvidal at linux.duke.edu Mon Feb 26 14:38:51 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Feb 2007 09:38:51 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45E2EFDB.30903@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> Message-ID: <1172500731.25220.11.camel@cutter> On Mon, 2007-02-26 at 15:34 +0100, Denis Leroy wrote: > Gilboa Davara wrote: > > On Sat, 2007-02-24 at 00:06 -0600, Callum Lerwick wrote: > >> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: > >>> I think we should agree that yum _is_ broken here and needs to be fixed. > >>> and no including a optional plugin won't help, the default behavior is > >>> broken ( I would even say its a security bug) > >> Does anyone else have an odd feeling of deja-vu? > > > > It's so annoying that I'm thinking about learning python just so I can > > submit a patch to fix it... :( > > While learning Python is a great idea, writing yum patches is > unfortunately known to be a complete and utter waste of time :-( It is? Since when? -sv From denis at poolshark.org Mon Feb 26 14:43:54 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 26 Feb 2007 15:43:54 +0100 Subject: FC6 updates broken deps? In-Reply-To: <45E2EFDB.30903@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> Message-ID: <45E2F22A.7040302@poolshark.org> Denis Leroy wrote: > Gilboa Davara wrote: >> On Sat, 2007-02-24 at 00:06 -0600, Callum Lerwick wrote: >>> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: >>>> I think we should agree that yum _is_ broken here and needs to be >>>> fixed. >>>> and no including a optional plugin won't help, the default behavior >>>> is broken ( I would even say its a security bug) >>> Does anyone else have an odd feeling of deja-vu? >> >> It's so annoying that I'm thinking about learning python just so I can >> submit a patch to fix it... :( > > While learning Python is a great idea, writing yum patches is > unfortunately known to be a complete and utter waste of time :-( Correcting statement above: s/patches/patches that add new features to yum/ From skvidal at linux.duke.edu Mon Feb 26 14:48:46 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Feb 2007 09:48:46 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45E2F22A.7040302@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> Message-ID: <1172501326.25220.16.camel@cutter> On Mon, 2007-02-26 at 15:43 +0100, Denis Leroy wrote: > Denis Leroy wrote: > > Gilboa Davara wrote: > >> On Sat, 2007-02-24 at 00:06 -0600, Callum Lerwick wrote: > >>> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: > >>>> I think we should agree that yum _is_ broken here and needs to be > >>>> fixed. > >>>> and no including a optional plugin won't help, the default behavior > >>>> is broken ( I would even say its a security bug) > >>> Does anyone else have an odd feeling of deja-vu? > >> > >> It's so annoying that I'm thinking about learning python just so I can > >> submit a patch to fix it... :( > > > > While learning Python is a great idea, writing yum patches is > > unfortunately known to be a complete and utter waste of time :-( > > Correcting statement above: > > s/patches/patches that add new features to yum/ ?? What're you talking about? -sv From ssorce at redhat.com Mon Feb 26 14:59:59 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 26 Feb 2007 09:59:59 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45E27EA4.2030603@argo.co.il> References: <45E27EA4.2030603@argo.co.il> Message-ID: <1172501999.28880.5.camel@localhost.localdomain> On Mon, 2007-02-26 at 08:31 +0200, Avi Kivity wrote: > Simo Sorce wrote: > > What if I have a revolutionary machine that can copy your bicycle > and > > reproduce it perfectly? > > Would it be theft if I come and copy yours and than go away leaving > > yours intact? > > > > > > It destroys my bicycle rental business, which is based on my unique > bicycle-for-fourteen design. Go clone your own bike and leave mine > alone. I understand your reasoning, since the invention of the light bulb destroyed candle makers business I think we should go back and forbid the use of light bulbs, it hurt their business after all. This argument is soo trollish. The rest is reiteration of the same concept, which shows you didn't even put effort in understanding what I am talking about, so there is no point in arguing again. Thread Closed. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From rafael.espindola at gmail.com Mon Feb 26 15:00:12 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Mon, 26 Feb 2007 07:00:12 -0800 Subject: Synaptics touchpad doesn't work on a mac book pro Message-ID: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> I am trying to make the synaptics touchpad work on fedora. I am following the instructions on http://gentoo-wiki.com/HARDWARE_Apple_MacBook/ The first problem is that some modules (mousedev, usbhid and evdev) are compiled builtin. Why?. I compiled a custom kernel with them as modules. To force the order in which they are loaded, I added the following line to modprobe.conf: install mousedev /sbin/modprobe usbhid && /sbin/modprobe --ignore-install mousedev install usbhid /sbin/modprobe appletouch && /sbin/modprobe --ignore-install usbhid install appletouch /sbin/modprobe evdev && /sbin/modprobe --ignore-install appletouch install evdev /sbin/modprobe uhci_hcd && /sbin/modprobe --ignore-install evdev Is there a better way to do it? Unfortunately, X still can't find the synaptics: Query no Synaptics: 6003C8 (EE) Synaptics Touchpad no synaptics touchpad detected and no repeater device (EE) Synaptics Touchpad Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device "Synaptics Touchpad" I will try to upgrade the synaptics driver. Does anyone has another suggestion? Cheers, Rafael From denis at poolshark.org Mon Feb 26 14:59:43 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 26 Feb 2007 15:59:43 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172501326.25220.16.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> Message-ID: <45E2F5DF.3060100@poolshark.org> seth vidal wrote: > On Mon, 2007-02-26 at 15:43 +0100, Denis Leroy wrote: >> Denis Leroy wrote: >>> Gilboa Davara wrote: >>>> On Sat, 2007-02-24 at 00:06 -0600, Callum Lerwick wrote: >>>>> On Fri, 2007-02-23 at 22:51 +0100, dragoran wrote: >>>>>> I think we should agree that yum _is_ broken here and needs to be >>>>>> fixed. >>>>>> and no including a optional plugin won't help, the default behavior >>>>>> is broken ( I would even say its a security bug) >>>>> Does anyone else have an odd feeling of deja-vu? >>>> It's so annoying that I'm thinking about learning python just so I can >>>> submit a patch to fix it... :( >>> While learning Python is a great idea, writing yum patches is >>> unfortunately known to be a complete and utter waste of time :-( >> Correcting statement above: >> >> s/patches/patches that add new features to yum/ > > ?? What're you talking about? Maybe I'm mistaken. If I submit a patch that integrates --skip-broken into yum, will you accept it ? I'd be more than happy to write that patch. From skvidal at linux.duke.edu Mon Feb 26 15:02:44 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Feb 2007 10:02:44 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45E2F5DF.3060100@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> Message-ID: <1172502164.25220.18.camel@cutter> On Mon, 2007-02-26 at 15:59 +0100, Denis Leroy wrote: > Maybe I'm mistaken. If I submit a patch that integrates --skip-broken > into yum, will you accept it ? I'd be more than happy to write that patch. It really depends on how the patch is implemented. Though I'm curious why integrating it is important if the plugin works well enough? -sv From denis at poolshark.org Mon Feb 26 15:29:41 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 26 Feb 2007 16:29:41 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172502164.25220.18.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> Message-ID: <45E2FCE5.20005@poolshark.org> seth vidal wrote: > On Mon, 2007-02-26 at 15:59 +0100, Denis Leroy wrote: > >> Maybe I'm mistaken. If I submit a patch that integrates --skip-broken >> into yum, will you accept it ? I'd be more than happy to write that patch. > > It really depends on how the patch is implemented. Though I'm curious > why integrating it is important if the plugin works well enough? let me try to answer that. 1. because the plugin is not installed by default, much less enabled by default. As a new user, I would be confused by a large update failing because of a single broken dep. My instinctive reaction would be to look for an option in yum to change that behavior (assuming i even know about yum, rather than just using the update applet). Having to launch pirut and search for a plugin seems counter-intuitive to me. 2. I find that strictly relying on plugins to work around issues, change default behaviors and add new functionality, or more generally accepting contributions from the community, is a strange way of managing a project. At least that's the way I understand yum is managed right now, based on what Tom Callaway said sunday at FOSDEM. But if you tell me that's not the case, I'll certainly believe you. From drago01 at gmail.com Mon Feb 26 15:34:07 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 26 Feb 2007 16:34:07 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172502164.25220.18.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> Message-ID: <45E2FDEF.4020702@gmail.com> seth vidal wrote: > On Mon, 2007-02-26 at 15:59 +0100, Denis Leroy wrote: > > >> Maybe I'm mistaken. If I submit a patch that integrates --skip-broken >> into yum, will you accept it ? I'd be more than happy to write that patch. >> > > It really depends on how the patch is implemented. Though I'm curious > why integrating it is important if the plugin works well enough? > > because this way its nothing but a hack that does not solve the main problem: yum should _NOT_ fail to update a package because a unreleated package has a dep problem. > -sv > > > From drago01 at gmail.com Mon Feb 26 15:35:18 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 26 Feb 2007 16:35:18 +0100 Subject: d80211 and iwlwifi In-Reply-To: <1172469250.3142.2.camel@bureau.maison> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> <1172469250.3142.2.camel@bureau.maison> Message-ID: <45E2FE36.6050102@gmail.com> Tanguy Eric wrote: > These kernels contains the free ralink driver rt2x00 ? > yes they do ;) From johannbg at hi.is Mon Feb 26 15:42:11 2007 From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=) Date: Mon, 26 Feb 2007 15:42:11 +0000 Subject: 2. Questions?? In-Reply-To: <45E2E389.1040806@fedoraproject.org> References: <45E2B325.20509@hi.is> <45E2C5A2.4090208@hi.is> <45E2CB78.1090603@fedoraproject.org> <45E2E14C.5020902@hi.is> <45E2E389.1040806@fedoraproject.org> Message-ID: <45E2FFD3.2030405@hi.is> Rahul Sundaram wrote: Join the QA team, report bugs, help triage bugs etc. Putting money where my mouth is, Where do I sign up :) Best Regards. J?hann B. -- J?hann B. Gu?mundsson. RHCE,CCSA Unix Kerfistj?ri. Kerfistj?rn. Reiknistofnun H?sk?la ?slands. T?knigar?i, Dunhaga 5. Rafp?stur: johannbg at hi.is 107 Reykjav?k. S?mi: 525-4267 ?sland. Br?fas?mi: 552-8801 Johann B. Gudmundsson. RHCE,CCSA Unix System Engineer. IT Management. Reiknistofnun University of Iceland. Taeknigardi, Dunhaga 5. Email: johannbg at hi.is IS-107 Reykjavik. Phone: +354-525-4267 Iceland. Fax: +354-552-8801 From skvidal at linux.duke.edu Mon Feb 26 15:45:59 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Feb 2007 10:45:59 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45E2FCE5.20005@poolshark.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> <45E2FCE5.20005@poolshark.org> Message-ID: <1172504759.25220.43.camel@cutter> On Mon, 2007-02-26 at 16:29 +0100, Denis Leroy wrote: > let me try to answer that. > > 1. because the plugin is not installed by default, much less enabled by > default. As a new user, I would be confused by a large update failing > because of a single broken dep. My instinctive reaction would be to look > for an option in yum to change that behavior (assuming i even know about > yum, rather than just using the update applet). Having to launch pirut > and search for a plugin seems counter-intuitive to me. > 2. I find that strictly relying on plugins to work around issues, change > default behaviors and add new functionality, or more generally accepting > contributions from the community, is a strange way of managing a > project. At least that's the way I understand yum is managed right now, > based on what Tom Callaway said sunday at FOSDEM. But if you tell me > that's not the case, I'll certainly believe you. I don't know what Spot said at fosdem so I can't really comment on that. Mostly we've been focusing on optimization, fixing bugs and changing a fair bit of behavior. The plugins are there so we don't have to get bogged down in feature requests and can let users do a lot of it on their own. The other reason the plugins exist is b/c once something makes it into the base yum code it has to stay there for a while. It has to be supported and has to be lugged along. -sv From knightmerc at yahoo.com Mon Feb 26 15:50:04 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Mon, 26 Feb 2007 10:50:04 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> Message-ID: <1172505004.4816.3.camel@localhost.localdomain> On Sun, 2007-02-25 at 01:52 +0100, Benny Amorsen wrote: > >>>>> "LX" == Lyvim Xaphir writes: > > LX> If you are advocating stealing intellectual property for the > LX> general welfare, then that's clearly criminal. Truthfully I don't > LX> think you are or would advocate such a thing, but there are those > LX> here who are. > > I am one of them. I advocate getting rid of intellectual property > entirely. I do not see what is criminal about a free market. > > > /Benny You don't understand what a free market is. A free market, as in capitalism, is based on private property ownership. Slavery has it's basis in advocating no ownership rights by the slave; since the slave has no rights to start with. The right to own and license your own work is an intrinsic right of any human. Therefore you are advocating a form of slavery. LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From katzj at redhat.com Mon Feb 26 15:53:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Feb 2007 10:53:10 -0500 Subject: Detecting the need for additional kernel options? In-Reply-To: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> References: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> Message-ID: <1172505190.12387.1.camel@erebor.boston.redhat.com> On Sat, 2007-02-24 at 12:34 -0500, Michel Salim wrote: > Is Anaconda currently checking the machine configuration against a > compatibility database? On some AMD64 laptops (including my HP L2000), > the machine would lock up randomly (without any log message) if booted > without "noapic" (I added "nosmp" for good measure). Instead of having a database of things like this, maybe it makes more sense to fix them in the kernel? :-) And if there is a real hardware need for things like this, it's very possible to use dmi for setting a lot of it -- and that even helps the case for when you boot into the installer! Or a live CD, etc etc etc Jeremy From tiemann at redhat.com Mon Feb 26 16:07:04 2007 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 26 Feb 2007 11:07:04 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172505004.4816.3.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> <1172505004.4816.3.camel@localhost.localdomain> Message-ID: <1172506024.4722.31.camel@localhost.localdomain> On Mon, 2007-02-26 at 10:50 -0500, Lyvim Xaphir wrote: > On Sun, 2007-02-25 at 01:52 +0100, Benny Amorsen wrote: > > >>>>> "LX" == Lyvim Xaphir writes: > > > > LX> If you are advocating stealing intellectual property for the > > LX> general welfare, then that's clearly criminal. Truthfully I don't > > LX> think you are or would advocate such a thing, but there are those > > LX> here who are. > > > > I am one of them. I advocate getting rid of intellectual property > > entirely. I do not see what is criminal about a free market. > > > > > > /Benny > > You don't understand what a free market is. A free market, as in > capitalism, is based on private property ownership. I think it is you who do not understand what a free market is. A free market is one in which two parties can agree to trade without seeking the explicit permission of the government to do so. The less permission/regulation exerted by the government, the freer the market. The move invasive and pervasive the controls exerted by the government, the less free the market. Property rights are orthogonal to the freeness of a market. They are highly relevant to certain economic assumptions, but one can have a free market without property rights. See http://en.wikipedia.org/wiki/Free_market M From jkeating at redhat.com Mon Feb 26 16:44:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 11:44:16 -0500 Subject: A slight change to the freeze/release times Message-ID: <200702261144.17161.jkeating@redhat.com> In the past we've had a few different strategies for freezing and releasing test and final releases of Fedora. At times we would freeze on a Monday, to release the following Monday. This gave us roughly until Friday to have a "golden tree" so that the mirrors could sync all weekend. However many mirror admins hated Monday releases, so we adjusted a bit and started targetting Tuesday's for release. This was accomplished by moving the freeze day from Monday to Tuesday. However this shortened the amount of time we had to get a tree ready and we would often lose the weekend for syncing by not having a tree ready in time, and continually slipping until Thursday. Moving the freeze to Thursday and targetting the next Thursday for the release is not optimal either, as we still have two days of freeze where little work may get done (the weekend). I've taken a look at what motivates our freeze time. A) Have enough time where the tree doesn't change from under us so that we can stabilize things and target specific fixes B) Have a tree ready for the mirrors at least 2 days before the release date so that we can ensure many mirrors are fully synced C) Minimize the amount of time where development is stifled. Motivation C really got me thinking. How are the freezes stifling development? In the past with previous build systems, Release Engineering would completely lock a buildroot. During a freeze, nobody would be able to build a package for the development collection, instead all builds were redirected to a development-HEAD like collection and sit there. Rel-eng would have to interactively "move" any of these builds back into the development collection to be included in whatever release we were freezing for (as well as rawhide for public testing). This was tedious and often broken, especially when the freeze was lifted and trying to merge those builds back in. With the new buildsystem we're using, we can create new tags very cheaply, so we've tried freezing a different way. The day/time of the freeze, Release Engineering will create a new "freeze" tag and tag all the latest packages from the development collection with this new tag. We would adjust the rawhide compose so that it composed from this new tag. Developers could continue to build things into the development collection without change, rel-eng would tag specific builds we wanted in our release (and rawhide) with the freeze tag. At the end of the freeze, the rawhide compose was again pointed at the development collection and thus no builds were lost. This is better for keeping development from being stifled, however there is still the act of "turning off" rawhide. Why do we turn off rawhide, or rather make it compose from the freeze tag? Mostly it is so that the community at large are using the same package versions we hope to have on the release. Now with pungi, it is also so that folks "playing along at home" can do composes with the package set as well. We used to keep rawhide "shut off" until the release day of the test release. This was to hopefully catch any last minute bugs and possibly call off the test release. However I think we need to re-think this a bit, since once we release something to the mirrors it is extremely difficult to prevent that from leaking out. So, for a proposal, I propose that we keep the current freeze day of Tuesday. This allows for the general weekend/Monday clean up and final rush for the freeze. I propose that we move the anticipated release day to Wed/Thu, leaving it somewhat vague. We'd like to hit Wed, but more often than not it may be Thu. I just don't want to send a slip note every single time we miss Wed. I also propose that we "turn on" rawhide once we release the tree to the mirrors. This should be either Monday or Tuesday of the release week. This keeps the time development is "stifled" short, while maximizing the number of business days that we have to get the tree in shape in time for the mirrors to sync, and adjusts the schedule to something a bit closer to reality. Thoughts? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Feb 26 16:46:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Feb 2007 11:46:34 -0500 Subject: F7 Release Discussion (was Re: Slightly OT: bad rap for Fedora, and realistic effects) In-Reply-To: <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> <20070225112133.4d3cb9af@ningauble.scrye.com> <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070226164633.GA24833@nostromo.devel.redhat.com> Michael Schwendt (mschwendt.tmp0701.nospam at arcor.de) said: > > I think we could also figure out > > the core owners for the core packages that have broken EVR, and mail > > them too... or I can do so manually. > > What is needed is a clear word that those issues are considered bugs that > need addressing and will be fixed. It is an unthankful task for any > contributor to spend time on filing such issues, if the tickets stay open > for a very long time (e.g. until the affected dist will see EOL). I state, as a member of FESCo, and as someone who has some standing in the old Core process, that broken EVRs that prevents upgrades are a bug, and should be fixed, and if they're still sticking around close to relese, *will* be fixed one way or another. Good enough? Bill From notting at redhat.com Mon Feb 26 16:58:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Feb 2007 11:58:16 -0500 Subject: A slight change to the freeze/release times In-Reply-To: <200702261144.17161.jkeating@redhat.com> References: <200702261144.17161.jkeating@redhat.com> Message-ID: <20070226165816.GE24833@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > So, for a proposal, I propose that we keep the current freeze day of Tuesday. > This allows for the general weekend/Monday clean up and final rush for the > freeze. I propose that we move the anticipated release day to Wed/Thu, > leaving it somewhat vague. We'd like to hit Wed, but more often than not it > may be Thu. I just don't want to send a slip note every single time we miss > Wed. I also propose that we "turn on" rawhide once we release the tree to > the mirrors. This should be either Monday or Tuesday of the release week. > This keeps the time development is "stifled" short, while maximizing the > number of business days that we have to get the tree in shape in time for the > mirrors to sync, and adjusts the schedule to something a bit closer to > reality. I think we still need actual release dates for test releases - having 'Wednesday or Thursday' just doesn't seem right to me. Aside from that, looks OK. Bill From sundaram at fedoraproject.org Mon Feb 26 17:22:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Feb 2007 22:52:55 +0530 Subject: 2. Questions?? In-Reply-To: <45E2FFD3.2030405@hi.is> References: <45E2B325.20509@hi.is> <45E2C5A2.4090208@hi.is> <45E2CB78.1090603@fedoraproject.org> <45E2E14C.5020902@hi.is> <45E2E389.1040806@fedoraproject.org> <45E2FFD3.2030405@hi.is> Message-ID: <45E3176F.7040306@fedoraproject.org> J?hann B. Gu?mundsson wrote: > Rahul Sundaram wrote: > > Join the QA team, report bugs, help triage bugs etc. > > Putting money where my mouth is, Where do I sign up :) Thanks for volunteering. I just wrote up some instructions at http://fedoraproject.org/wiki/QA. Let me know if you have more questions. Rahul From drago01 at gmail.com Mon Feb 26 17:38:00 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 26 Feb 2007 18:38:00 +0100 Subject: A slight change to the freeze/release times In-Reply-To: <20070226165816.GE24833@nostromo.devel.redhat.com> References: <200702261144.17161.jkeating@redhat.com> <20070226165816.GE24833@nostromo.devel.redhat.com> Message-ID: <45E31AF8.4040000@gmail.com> Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > >> So, for a proposal, I propose that we keep the current freeze day of Tuesday. >> This allows for the general weekend/Monday clean up and final rush for the >> freeze. I propose that we move the anticipated release day to Wed/Thu, >> leaving it somewhat vague. We'd like to hit Wed, but more often than not it >> may be Thu. I just don't want to send a slip note every single time we miss >> Wed. I also propose that we "turn on" rawhide once we release the tree to >> the mirrors. This should be either Monday or Tuesday of the release week. >> This keeps the time development is "stifled" short, while maximizing the >> number of business days that we have to get the tree in shape in time for the >> mirrors to sync, and adjusts the schedule to something a bit closer to >> reality. >> > > I think we still need actual release dates for test releases - having > 'Wednesday or Thursday' just doesn't seem right to me. Aside from that, > looks OK. > > what about simple say Thursday = release day? if its ready on Wednesday it should not hurt, open the mirrors on Thursday and thats it.... > Bill > > From jkeating at redhat.com Mon Feb 26 17:55:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 12:55:35 -0500 Subject: A slight change to the freeze/release times In-Reply-To: <45E31AF8.4040000@gmail.com> References: <200702261144.17161.jkeating@redhat.com> <20070226165816.GE24833@nostromo.devel.redhat.com> <45E31AF8.4040000@gmail.com> Message-ID: <200702261255.39175.jkeating@redhat.com> On Monday 26 February 2007 12:38, dragoran wrote: > what about simple say Thursday = release day? if its ready on Wednesday > it should not hurt, open the mirrors on Thursday and thats it.... Certainly doable. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Feb 26 17:56:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 12:56:24 -0500 Subject: A slight change to the freeze/release times In-Reply-To: <20070226165816.GE24833@nostromo.devel.redhat.com> References: <200702261144.17161.jkeating@redhat.com> <20070226165816.GE24833@nostromo.devel.redhat.com> Message-ID: <200702261256.24850.jkeating@redhat.com> On Monday 26 February 2007 11:58, Bill Nottingham wrote: > I think we still need actual release dates for test releases - having > 'Wednesday or Thursday' just doesn't seem right to me. Aside from that, > looks OK. Certainly, I meant that we would say the date that corresponds with that week's Wed or Thu. I think I'm in favor of saying Thu and if we happent to get things synced up early, good for us. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Feb 26 18:33:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Feb 2007 13:33:37 -0500 Subject: Slight slip of Fedora 7 Test 2 Message-ID: <200702261333.37545.jkeating@redhat.com> We've ran into some kernel difficulties on PPC, some VNC issues, and more fun with figuring out what to spin and how. As such we were not able to have a tree ready on Friday for the mirrors to sync. We cannot release Tomorrow. We expect to have a final tree done (late?) today to give to the mirrors for a Thursday (March 1st) release. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at scrye.com Mon Feb 26 18:29:10 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 26 Feb 2007 11:29:10 -0700 Subject: F7 Release Discussion (was Re: Slightly OT: bad rap for Fedora, and realistic effects) In-Reply-To: <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> <20070225112133.4d3cb9af@ningauble.scrye.com> <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070226112910.24fe83d4@ningauble.scrye.com> On Sun, 25 Feb 2007 21:31:46 +0100 mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > On Sun, 25 Feb 2007 11:21:33 -0700, Kevin Fenzi wrote: > > > Now it's getting interesting. Being a sponsor has never before > > > implied that you have to fix orphans or take over packages when a > > > sponsored person leaves the project or is AWOL. With such a > > > requirement, the sponsorship system would be too burdensome and > > > too much of a risk. > > > > ok. So, who should handle those things? FESCo? > > No one? > > Quite obviously, those are not the only two options. And hence the > answer to the latter two questions is "no". Perhaps I wasn't being clear... What are your thoughts/opinions on how this should work? I would love to hear your input. > > > Would you like to update that wiki page with your thoughts on it? > > Such thoughts ought to come from the governing body of the project, > since 1) the CLA and the contributor sponsorship system is their > sphere of responsibility, 2) a successful sponsorship system makes it > possible to scale, and 3) it can also happen that sponsors leave the > project. Sure, agreed. However, such thoughts should also allow for input from the community to come up with a plan that tries to meet all the needs involved. Since I just started a draft, I would love to hear ideas from the community before presenting it to FESCo to agree on. > > For much of this with the merged tree, we will be using the > > procedure that former Core used to use? > > Is that a question? Not really. > Apart from that, we don't have "the merged tree" yet, so it is more > interesting how to proceed until test3 and beyond. Agreed. > > Some of the E-V-R and broken deps problems have been fixed, but not > > pushed out in devel since we are in test2 freeze, it looks like? > > Well, Core is frozen, Extras doesn't have any schedule ;-), but right, > after the topic had come up on maintainers-list, Extras devel is sort > of in a freeze, too, and pushed to only on demand. Right. > > Also, it doesn't look like the broken EVR report mails anyone, just > > goes to the list. Could you change it to mail owners? I think some > > people might be missing the problem. > > The code that would do that [without creating too much spam] is > missing. ok. Fair enough I will bug maintainers directly about it. Is there any easy way to run that script locally for me to see what current EVR issues are? (Hopefully using the needsign repo so I can not worry about packages that will be pushed after the freeze is over). > > I think we could also figure out > > the core owners for the core packages that have broken EVR, and mail > > them too... or I can do so manually. > > What is needed is a clear word that those issues are considered bugs > that need addressing and will be fixed. It is an unthankful task for > any contributor to spend time on filing such issues, if the tickets > stay open for a very long time (e.g. until the affected dist will see > EOL). Yes. They are bugs. They must be fixed. > > On the subject of broken deps, I can look at assisting people with > > those. Will go file bugs and see if there are any that are easy to > > fix. Does the script just run 'repoclosure' ? > > A modified version, but running the original repoclosure from > yum-utils should work to check packages and local builds, too. I mailed every maintainer with a broken dep from the last report with a email telling them they needed a simple rebuild or that they had a more serious problem and where to look to fix it. Many of them have fixed things. I will go through probibly tomorrow and find any that didn't get fixed yet. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From florin at andrei.myip.org Mon Feb 26 19:11:03 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 26 Feb 2007 11:11:03 -0800 Subject: FC6 updates broken deps? In-Reply-To: <45E2FDEF.4020702@gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> <45E2FDEF.4020702@gmail.com> Message-ID: <45E330C7.8060705@andrei.myip.org> dragoran wrote: > because this way its nothing but a hack that does not solve the main > problem: > yum should _NOT_ fail to update a package because a unreleated package > has a dep problem. Let me re-phrase it: The light in the kitchen should not fail to function because a bulb in the basement is broken. Having a modular architecture is fine and all, but basic functionality _must_ be included in the core. The skip-broken thing is so obvious, it boggles the mind there's even a discussion about it. It would be nice if Red Hat could conduct (more) usability tests on software that's important for the OS. That would probably de-nerdify a lot of applications. -- Florin Andrei http://florin.myip.org/ From skvidal at linux.duke.edu Mon Feb 26 19:15:34 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Feb 2007 14:15:34 -0500 Subject: FC6 updates broken deps? In-Reply-To: <45E330C7.8060705@andrei.myip.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> <45E2FDEF.4020702@gmail.com> <45E330C7.8060705@andrei.myip.org> Message-ID: <1172517334.26721.12.camel@cutter> On Mon, 2007-02-26 at 11:11 -0800, Florin Andrei wrote: > dragoran wrote: > > > because this way its nothing but a hack that does not solve the main > > problem: > > yum should _NOT_ fail to update a package because a unreleated package > > has a dep problem. > > Let me re-phrase it: > > The light in the kitchen should not fail to function because a bulb in > the basement is broken. to extend the analogy: if the bulb in the basement being out means there could well be a murderer down there, then maybe the door to the house shouldn't open at all. :) > Having a modular architecture is fine and all, but basic functionality > _must_ be included in the core. The skip-broken thing is so obvious, it > boggles the mind there's even a discussion about it. > > It would be nice if Red Hat could conduct (more) usability tests on > software that's important for the OS. That would probably de-nerdify a > lot of applications. To be clear: If you'd like to help with yum, I'd appreciate it. Yelling the same thing over and over again isn't really helping. -sv From sundaram at fedoraproject.org Mon Feb 26 19:19:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Feb 2007 00:49:39 +0530 Subject: FC6 updates broken deps? In-Reply-To: <45E330C7.8060705@andrei.myip.org> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> <45E2FDEF.4020702@gmail.com> <45E330C7.8060705@andrei.myip.org> Message-ID: <45E332CB.4080903@fedoraproject.org> Florin Andrei wrote: > It would be nice if Red Hat could conduct (more) usability tests on > software that's important for the OS. That would probably de-nerdify a > lot of applications. How about you dont depend on one entity to do that? Usability can be a community and volunteer driven process or atleast we should attempt to do that. Recording user actions on the desktop is trivial to do these days. There is http://fedoraproject.org/wiki/Usability. We could probably get a place to upload those desktop recordings. What else do you need? Rahul From avi at argo.co.il Mon Feb 26 19:42:31 2007 From: avi at argo.co.il (Avi Kivity) Date: Mon, 26 Feb 2007 21:42:31 +0200 Subject: [Mandrakeot] ESR gives up on Fedora Message-ID: <45E33827.1020903@argo.co.il> Simo Sorce wrote: > On Mon, 2007-02-26 at 08:31 +0200, Avi Kivity wrote: > >> Simo Sorce wrote: >> >>> What if I have a revolutionary machine that can copy your bicycle >>> >> and >> >>> reproduce it perfectly? >>> Would it be theft if I come and copy yours and than go away leaving >>> yours intact? >>> >>> >>> >> It destroys my bicycle rental business, which is based on my unique >> bicycle-for-fourteen design. Go clone your own bike and leave mine >> alone. >> > > I understand your reasoning, since the invention of the light bulb > destroyed candle makers business I think we should go back and forbid > the use of light bulbs, it hurt their business after all. > > The light bulb makers used their own brains to invent something new, without stealing the candlemaker's bright ideas. That's called progress. The bicycle cloners invented nothing (except the cloning machine; they could be rich unless someone cloned _that_), they took someone else's painstaking research and painful field trials, and sell it or use it as if it's their own, damaging those who invented the bicycle. If you're a software developer, you can probably appreciate the amount of effort that goes into producing software. That effort has value. Allowing anyone to copy it reduces that value. > This argument is soo trollish. > > The rest is reiteration of the same concept, which shows you didn't even > put effort in understanding what I am talking about, so there is no > point in arguing again. Thread Closed. > We can close a thread by agreeing to disagree, but hurling insults and saying "Thread Closed" is not the way to do it. I didn't insult you, and I did read what you've written quite carefully. Even if you think there's no inherent value in a clonable entity, you'll find there is much value in carrying out a conversation in an adult manner. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvrabec at redhat.com Mon Feb 26 19:44:16 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Mon, 26 Feb 2007 20:44:16 +0100 Subject: default syslogd In-Reply-To: <200702211012.30031.jkeating@redhat.com> References: <20070209161713.19ca2838@wrabco.brq.redhat.com> <200702091033.59011.jkeating@redhat.com> <20070221155905.3a85de36@wrabco.brq.redhat.com> <200702211012.30031.jkeating@redhat.com> Message-ID: <20070226204416.431cd7aa@a05-0705a.kn.vutbr.cz> On Wed, 21 Feb 2007 10:12:29 -0500 Jesse Keating wrote: > On Wednesday 21 February 2007 09:59, Peter Vrabec wrote: > > Sorry for late response, I was off last week. > > > > What do we need to do, before we turn it on by default? > > First thing, you'd have to sign up to drive this change and get it > added to the feature list. http://fedoraproject.org/wiki/Releases/FeatureSyslogNG?highlight=%28CategoryFedora7Features%29 > Then you'd have to do all the research and testing and such to see in progress by jpo > if there is a reasonable thing to switch to, - alive development(upstream) - ipv6 - tcp connections - secure connections - possibility to filter message contents using regular expressions. > and discover what all needs > to change to make the swich, and have it done by the new feature > freeze, which is Test3, in a month. > From dominik at greysector.net Mon Feb 26 19:45:49 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 26 Feb 2007 20:45:49 +0100 Subject: 2. Questions?? In-Reply-To: <45E2BD78.9040501@hi.is> References: <45E2B325.20509@hi.is> <45E2BD78.9040501@hi.is> Message-ID: <20070226194549.GD21229@ryvius.pekin.waw.pl> On Monday, 26 February 2007 at 11:59, "J?hann B. Gu?mundsson" wrote: [...] > I was not talking about merging it with the Fedora repos > > I was succesting about Freshrpms and Livna joining into one "unofficial" > repo > One place for official && one place for unofficial. I can say that there are indications that things may be moving in that direction. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From davej at redhat.com Mon Feb 26 19:51:09 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 26 Feb 2007 14:51:09 -0500 Subject: d80211 and iwlwifi In-Reply-To: <1172493685.3061.4.camel@localhost.localdomain> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> <1172469250.3142.2.camel@bureau.maison> <1172493685.3061.4.camel@localhost.localdomain> Message-ID: <20070226195109.GC1990@redhat.com> On Mon, Feb 26, 2007 at 07:41:25AM -0500, Dan Williams wrote: > On Mon, 2007-02-26 at 06:54 +0100, Tanguy Eric wrote: > > Le samedi 24 f?vrier 2007 ? 21:35 -0500, John W. Linville a ?crit : > > > On Sat, Feb 24, 2007 at 11:18:40PM +0100, Tanguy Eric wrote: > > > > Le samedi 24 f?vrier 2007 ? 21:56 +0000, Mike Cohler a ?crit : > > > > > I hope this is not a repeat question but is it planned to have d80211 > > > > > and iwlwifi in the F7 release? > > > > > > > > > > If so is it planned to put these into updates for FC6 at some point? > > > > > > > > > For the d80211 stack it will be in the kernel when it will be ready but > > > > > > It is in rawhide as of today, and it should be upstream in -mm soon. > > > > > > > if i remember well there was 2 stacks, one from intel and an other one. > > > > > > I think you are confused by the fact that Intel is packaging a > > > snapshot of the stack to enable their driver on older kernels. > > > This should not be necessary for us. > > > > Thanks for the explanation. Will these kernels be available for fc-6 ? > > These kernels contains the free ralink driver rt2x00 ? > > I'd hope d80211 and the associated drivers are _not_ shipped for FC6 > (unless in testing) until they have settled down quite a bit. They > still have quite a lot of maturing to do. Right, the current plan is F7+ only for d80211. Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Mon Feb 26 20:14:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Feb 2007 01:44:12 +0530 Subject: PHP Webserver Cluster Tool In-Reply-To: <19536.24.91.171.78.1172495134.squirrel@mail.mohawksoft.com> References: <19536.24.91.171.78.1172495134.squirrel@mail.mohawksoft.com> Message-ID: <45E33F94.8070602@fedoraproject.org> markw at mohawksoft.com wrote: > I'm not looking to spam these discussions, but I am in need of some beta > testers and good old fashioned QA and feedback. > > I have an GPL Free/OpenSource software project called MCache. Its primary > goal is to facilitate and augment web cluster session management, > primarily in PHP but can easily be used for Java. > > My open source site is: http://www.mohawksoft.org. > > A brief discussion is located here: http://www.mohawksoft.org/?q=node/36 > The main documentation is located here: http://www.mohawksoft.org/?q=node/8 > > Any and all help in this project is appreciated. Getting it packaged into Fedora would probably make it easier to get feedback. More users wont help in that line either. http://fedoraproject.org/wiki/Extras Rahul From frank at scirocco-5v-turbo.de Mon Feb 26 20:21:04 2007 From: frank at scirocco-5v-turbo.de (Frank Arnold) Date: Mon, 26 Feb 2007 21:21:04 +0100 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> Message-ID: <1172521264.7161.21.camel@dipsy> Am Montag, den 26.02.2007, 07:00 -0800 schrieb Rafael Esp?ndola: > I am trying to make the synaptics touchpad work on fedora. I am > following the instructions on > http://gentoo-wiki.com/HARDWARE_Apple_MacBook/ > > The first problem is that some modules (mousedev, usbhid and evdev) > are compiled builtin. Why?. I compiled a custom kernel with them as > modules. Works for me with the stock Fedora kernels on my PowerBook. There's no need for fiddling around with /etc/modprobe.conf. Is your touchpad working without synaptics, or more specifically is the appletouch module getting loaded? > Unfortunately, X still can't find the synaptics: > > Query no Synaptics: 6003C8 > (EE) Synaptics Touchpad no synaptics touchpad detected and no repeater device > (EE) Synaptics Touchpad Unable to query/initialize Synaptics hardware. > (EE) PreInit failed for input device "Synaptics Touchpad" Do you have chosen the right device? Here are the relevant portions of my /etc/X11/xorg.conf: Section "ServerLayout" ... InputDevice "Mouse0" InputDevice "Synaptics Touchpad" ... EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" Option "Protocol" "IMPS/2" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Synaptics Touchpad" Driver "synaptics" Option "SendCoreEvents" "true" Option "Device" "/dev/input/mice" Option "Protocol" "auto-dev" ... EndSection HTH, Frank From bojan at rexursive.com Mon Feb 26 20:39:12 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 27 Feb 2007 07:39:12 +1100 Subject: How does new F7 schedule affect Firefox Message-ID: <1172522352.11406.8.camel@shrek.rexursive.com> Now that the planned release date for F7 is 24 May 2007 (a month after EOL for FF 1.5) and keeping in mind that FC6 will be supported until F8T2 (so, say until about September 2007 or so), isn't that going to cause the need for backporting of fixes to FF 1.5 for about 4 to 5 months? Wouldn't it be better (i.e. less effort) to bite the bullet now and just upgrade the whole FC6 to FF 2.0? PS. Yes, I'm aware that similar questions have been asked before, but F7 was on a different schedule then. -- Bojan From overholt at redhat.com Mon Feb 26 21:03:13 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 26 Feb 2007 16:03:13 -0500 Subject: Broken version check in eclipse-emf? In-Reply-To: <20070223210843.GE7821@redhat.com> References: <45DF5609.4090207@xs4all.nl> <20070223210843.GE7821@redhat.com> Message-ID: <20070226210313.GJ17289@redhat.com> * Andrew Overholt [2007-02-23 16:09]: > I need to update it to the Callisto winter maintenance release. I did this on the weekend and just verified that the mirror my machine picked had the updated eclipse-emf. Is it fixed for you as well? Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Lam at Lam.pl Mon Feb 26 21:05:27 2007 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 26 Feb 2007 22:05:27 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45E33827.1020903@argo.co.il> References: <45E33827.1020903@argo.co.il> Message-ID: <1172523927.3824.29.camel@pensja.lam.pl> Dnia 26-02-2007, pon o godzinie 21:42 +0200, Avi Kivity napisa?(a): > The light bulb makers used their own brains to invent something new, > without stealing the candlemaker's bright ideas. No, it's the same idea - an idea that we can make light when it's dark. It's only a difference in implementation. If you don't get that, think about the invention of CFL when there are already light bulbs. > That's called > progress. The bicycle cloners invented nothing It's hard to clone something. They would rather make their own implementation of an idea. In order to sell their bicycles they would have to make it better in some way. We'd get bicycles that are cheaper/better/lighter/whatever than original. _That's_ called progress. It's also called competition, which is good for the consumer. You, on the other hand, are advocating monopolies. > (except the cloning > machine; they could be rich unless someone cloned _that_) Yeah, yeah. Whenever someone clones the real clone machine (that can clone anything) and starts to sell that, next day there will be no famine in the world. But you say it's bad for mankind to clone things. > you can probably appreciate > the amount of effort that goes into producing software. That effort > has > value. Allowing anyone to copy it reduces that value. How many times did you buy a program that had 1000 functions, but you needed it for just one? Is the program worth $1000 for you? No. But hey, the idea of that one function is patented and no one can write a simple program doing just that. I fully understand that making The Big Program took 10 years of work for 100 programmers. But don't make me pay for things I don't need. Again, there's also the monopoly behind such program which idea can't be copied. The company will stop making any improvements because they already know you will pay anyhow and no one can make a better program anyhow. If you're so convinced that we have to protect ideas, because otherwise people will stop inventing things, make a software patent last 1 year. If the company can make a good product out of the brilliant idea, they can make billions during the year. Otherwise, don't stop the competition from doing it better. And please, think, what takes more time - thinking about a nice feature or actually implementing it? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From michel.salim at gmail.com Mon Feb 26 21:12:05 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 26 Feb 2007 16:12:05 -0500 Subject: Detecting the need for additional kernel options? In-Reply-To: <1172505190.12387.1.camel@erebor.boston.redhat.com> References: <883cfe6d0702240934t3d755b8fyd016c30964aa2819@mail.gmail.com> <1172505190.12387.1.camel@erebor.boston.redhat.com> Message-ID: <883cfe6d0702261312q2e9a1582va6a589b5afb4333c@mail.gmail.com> 2007/2/26, Jeremy Katz : > On Sat, 2007-02-24 at 12:34 -0500, Michel Salim wrote: > > Is Anaconda currently checking the machine configuration against a > > compatibility database? On some AMD64 laptops (including my HP L2000), > > the machine would lock up randomly (without any log message) if booted > > without "noapic" (I added "nosmp" for good measure). > > Instead of having a database of things like this, maybe it makes more > sense to fix them in the kernel? :-) And if there is a real hardware > need for things like this, it's very possible to use dmi for setting a > lot of it -- and that even helps the case for when you boot into the > installer! Or a live CD, etc etc etc > In this particular instance it turns out (most likely) to be an overheating issue -- once I removed one of my two RAM modules everything is more stable. So noapic is not the culprit in this case. It might still be useful to have such a database, so 1) users of affected hardware don't spend too much time diagnosing the problem 2) kernel developers have a single place to look for compatibility issues Regards, -- Michel Salim http://hircus.wordpress.com/ From fellacious at gmail.com Mon Feb 26 21:29:23 2007 From: fellacious at gmail.com (Abdul Al-Felashis) Date: Mon, 26 Feb 2007 16:29:23 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172506024.4722.31.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> <1172505004.4816.3.camel@localhost.localdomain> <1172506024.4722.31.camel@localhost.localdomain> Message-ID: > > > LX> If you are advocating stealing intellectual property for the > > > LX> general welfare, then that's clearly criminal. ... > > > LX> there are those here who are. > > > I am one of them. I advocate getting rid of intellectual property > > > entirely. I do not see what is criminal about a free market. > > You don't understand what a free market is. A free market, as in > > capitalism, is based on private property ownership. ... > > Therefore you are advocating a form of slavery. > I think it is you who do not understand what a free market is. ... > See http://en.wikipedia.org/wiki/Free_market Jesus christ, sirs. I came here to troll you with my article about the GNAA, but it seems that you are doing a fine job of trolling yourselves. ~fellacious -- Are you GAY? Are you a NIGGER? Are you a GAY NIGGER? If you answered YES to all of the above questions, the GAY NIGGER ASSOCIATION OF AMERICA might be just what you are looking for! From lsof at nodata.co.uk Mon Feb 26 21:38:12 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 26 Feb 2007 22:38:12 +0100 Subject: rfe: ignore thread in evolution In-Reply-To: References: <200702221656.09198.kaj@haulrich.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> <1172505004.4816.3.camel@localhost.localdomain> <1172506024.4722.31.camel@localhost.localdomain> Message-ID: <1172525892.3171.1.camel@sb-home.lan> [snip] Wow. This thread is still going! Might as well hijack it. If you use Evolution, and wish it had an "ignore thread" feature, join this bug: http://bugzilla.gnome.org/show_bug.cgi?id=300871 From hughsient at gmail.com Mon Feb 26 21:47:55 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Feb 2007 21:47:55 +0000 Subject: d80211 and iwlwifi In-Reply-To: <20070226195109.GC1990@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> <1172469250.3142.2.camel@bureau.maison> <1172493685.3061.4.camel@localhost.localdomain> <20070226195109.GC1990@redhat.com> Message-ID: <1172526475.2728.6.camel@localhost.localdomain> On Mon, 2007-02-26 at 14:51 -0500, Dave Jones wrote: > > I'd hope d80211 and the associated drivers are _not_ shipped for FC6 > > (unless in testing) until they have settled down quite a bit. They > > still have quite a lot of maturing to do. > > Right, the current plan is F7+ only for d80211. Cool. I'm finding the zd1211rw_d80211 much more stable than the zd121rw softmac driver. Plus, ipw3945 has an experimental d80211 driver which does not require the userspace regulatory binary. Richard. From mschwendt.tmp0701.nospam at arcor.de Mon Feb 26 21:52:25 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 26 Feb 2007 22:52:25 +0100 Subject: F7 Release Discussion (was Re: Slightly OT: bad rap for Fedora, and realistic effects) In-Reply-To: <20070226112910.24fe83d4@ningauble.scrye.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> <20070225112133.4d3cb9af@ningauble.scrye.com> <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> <20070226112910.24fe83d4@ningauble.scrye.com> Message-ID: <20070226225225.4a2851ef.mschwendt.tmp0701.nospam@arcor.de> On Mon, 26 Feb 2007 11:29:10 -0700, Kevin Fenzi wrote: > > > > Now it's getting interesting. Being a sponsor has never before > > > > implied that you have to fix orphans or take over packages when a > > > > sponsored person leaves the project or is AWOL. With such a > > > > requirement, the sponsorship system would be too burdensome and > > > > too much of a risk. > > > > > > ok. So, who should handle those things? FESCo? > > > No one? > > > > Quite obviously, those are not the only two options. And hence the > > answer to the latter two questions is "no". > > Perhaps I wasn't being clear... > > What are your thoughts/opinions on how this should work? > I would love to hear your input. Do you disagree? Do you think that if somebody leaves the project, the sponsor is responsible for the orphaned packages? > > > Also, it doesn't look like the broken EVR report mails anyone, just > > > goes to the list. Could you change it to mail owners? I think some > > > people might be missing the problem. > > > > The code that would do that [without creating too much spam] is > > missing. > > ok. Fair enough I will bug maintainers directly about it. > Is there any easy way to run that script locally for me to see what > current EVR issues are? (Hopefully using the needsign repo so I can not > worry about packages that will be pushed after the freeze is over). These tools are in "fedora" cvs. Sometimes the scripts are tweaked for the buildsys installation environment and may need a few modifications if used elsewhere. The upgradecheck.py script simply takes an external config file with definitions of SRPMS repos. Whether it would work to include the needsign repo, I don't know, because the needsign repo is a multi-arch repo -- all archs including SRPMS in a single repo. :) From tmraz at redhat.com Mon Feb 26 21:50:48 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 26 Feb 2007 22:50:48 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172523927.3824.29.camel@pensja.lam.pl> References: <45E33827.1020903@argo.co.il> <1172523927.3824.29.camel@pensja.lam.pl> Message-ID: <1172526648.3086.12.camel@perun.kabelta.loc> On Mon, 2007-02-26 at 22:05 +0100, Leszek Matok wrote: > Dnia 26-02-2007, pon o godzinie 21:42 +0200, Avi Kivity napisa?(a): > > (except the cloning > > machine; they could be rich unless someone cloned _that_) > Yeah, yeah. Whenever someone clones the real clone machine (that can > clone anything) and starts to sell that, next day there will be no > famine in the world. But you say it's bad for mankind to clone things. Of course! Can you imagine all of the cloned Rolls Royces and Ferraris everywhere? All the heaps of cloned Rolex watches, bottles of champagne from the year 1953, cloned high-end audio and huge TVs on all corners. Dunno if the famine really stopped because people would be cloning useless crap first and drowning in heaps of it. :-) :-) Please please, can we stop this long ago very OT thread? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From tom at impact-crater.com Mon Feb 26 21:52:01 2007 From: tom at impact-crater.com (Tom Rivers) Date: Mon, 26 Feb 2007 16:52:01 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: References: <200702221656.09198.kaj@haulrich.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> <1172505004.4816.3.camel@localhost.localdomain> <1172506024.4722.31.camel@localhost.localdomain> Message-ID: <45E35681.4070602@impact-crater.com> Abdul Al-Felashis wrote: > Jesus christ, sirs. I came here to troll you with my article about > the GNAA, but it seems that you are doing a fine job of trolling > yourselves. > > ~fellacious > -- > Are you GAY? Are you a NIG... > Are there any list moderators around who could respond appropriately to this 'individual'? From avi at argo.co.il Mon Feb 26 21:57:15 2007 From: avi at argo.co.il (Avi Kivity) Date: Mon, 26 Feb 2007 23:57:15 +0200 Subject: [Mandrakeot] ESR gives up on Fedora Message-ID: <45E357BB.3020305@argo.co.il> Leszek Matok wrote: > Dnia 26-02-2007, pon o godzinie 21:42 +0200, Avi Kivity napisa?(a): > >> The light bulb makers used their own brains to invent something new, >> without stealing the candlemaker's bright ideas. >> > No, it's the same idea - an idea that we can make light when it's dark. > It's only a difference in implementation. If you don't get that, think > about the invention of CFL when there are already light bulbs. > > CFL is a new idea. A better one, too. I don't think the inventor of the lightbulb was granted a patent on light, or even artificial light. Just a way of producing light by applying current to a metal filament which heats and emits light. >> That's called >> progress. The bicycle cloners invented nothing >> > It's hard to clone something. They would rather make their own > implementation of an idea. In order to sell their bicycles they would > have to make it better in some way. We'd get bicycles that are > cheaper/better/lighter/whatever than original. _That's_ called progress. > It's also called competition, which is good for the consumer. Right, so write your own code/film your own movie/record your own song. That's competition and that's good for the consumers. Copying someone elses code is _not_ competition. Allowing people to copy music/movies/non-free software and redistribute it is not competition. > You, on > the other hand, are advocating monopolies. > > Certainly not. You want to compete with my bicycle rental business, design and build your own bikes, may the best cycle win. I _am_ advocating that you can have a monopoly on your own creation, but not that you can prevent someone else from creating. >> (except the cloning >> machine; they could be rich unless someone cloned _that_) >> > Yeah, yeah. Whenever someone clones the real clone machine (that can > clone anything) and starts to sell that, next day there will be no > famine in the world. But you say it's bad for mankind to clone things. > > Let's drop the cloning machine thing. It's too far-fetched to make good analogies. I hope we don't have a cloning machine as it's most likely we'll be gone soon afterwards. >> you can probably appreciate >> the amount of effort that goes into producing software. That effort >> has >> value. Allowing anyone to copy it reduces that value. >> > How many times did you buy a program that had 1000 functions, but you > needed it for just one? Well, I use open source software, so I rarely have pay for it. I did pay Red Hat back in the 9 days to get updates, because I appreciated the effort that went into those updates. I also pay for my LWN subscription. Sure, downloading the articles somehow wouldn't take them away from them, but I wouldn't do it even if I could. > Is the program worth $1000 for you? No. But hey, > the idea of that one function is patented and no one can write a simple > program doing just that. > I oppose software patents, at least as currently abused. I think a better solution is trade secrets, but I admit that I haven't given it much thought. > I fully understand that making The Big Program took 10 years of work for > 100 programmers. But don't make me pay for things I don't need. > > I'm with you on that. But that doesn't mean you can freely copy the $1000 program, just because you want to use part of the functionality. > Again, there's also the monopoly behind such program which idea can't be > copied. The company will stop making any improvements because they > already know you will pay anyhow and no one can make a better program > anyhow. > If they stop making innovations, others will, and the customers will switch to them. > If you're so convinced that we have to protect ideas, because otherwise > people will stop inventing things, make a software patent last 1 year. > If the company can make a good product out of the brilliant idea, they > can make billions during the year. Otherwise, don't stop the competition > from doing it better. > > That could work. The worst thing about software patents IMO is that they make it impossible for small companies to write software without infringing. The large ones are mostly cross-licensed, and they have the pockets and patent portfolios to fight a patent war. And it's the small companies that do the innovations. > And please, think, what takes more time - thinking about a nice feature > or actually implementing it? > Implementation, of course, but what has that to do with abolishing copyright? Copying non-free software (or movies, or songs) steals both the value of the idea and the value of the implementation effort. Free software is great, but it has to be voluntary. Forcing all software to be free is wrong. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matt_Domsch at dell.com Mon Feb 26 21:58:37 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 26 Feb 2007 15:58:37 -0600 Subject: Core x86_64 rawhide rebuild in mock status 2007-02-26 Message-ID: <20070226155837.A5614@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for x86_64 Mon Feb 26 15:27:48 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1156 Number failed to build: 57 Number expected to fail due to ExclusiveArch or ExcludeArch: 15 Leaving: 42 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 42 ---------------------------------- alacarte-0.11.3-2.fc7 automake16-1.6.3-9 boost-1.33.1-10.fc7 castor-0.9.5-1jpp.7 compat-gcc-32-3.2.3-61 compat-gcc-34-3.4.6-4 expect-5.43.0-8 g-wrap-1.9.6-7.1 gnome-media-2.17.91-1.fc7 gnome-sharp-2.16.0-1.fc6 gnucash-2.0.4-1.fc6 grub-0.97-13 icon-naming-utils-0.8.1-1.fc6 jgroups-2.2.9.2-3jpp.2 kasumi-2.0.1-1.1.fc6 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libevent-1.2a-1 libgssapi-0.10-1 linux-atm-2.5.0-1.20050118cvs memtest86+-1.70-1.fc7 mikmod-3.1.6-39.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-8.fc7 perl-5.8.8-12.fc7 ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 readahead-1.3-6.fc6 scim-anthy-1.2.2-1.fc7 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 syslinux-3.36-1.fc7 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 tk-8.4.13-4.fc7 tomcat5-5.5.17-6jpp.2 valgrind-3.2.3-2 velocity-1.4-6jpp.1 w3m-0.5.1-15.fc6 xen-3.0.4-6.fc7 xferstats-2.16-14.1 With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Mon Feb 26 21:58:41 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 26 Feb 2007 15:58:41 -0600 Subject: Core i386 rawhide rebuild in mock status 2007-02-26 Message-ID: <20070226155841.A5629@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for i386 Mon Feb 26 15:30:05 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1157 Number failed to build: 42 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 33 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 33 ---------------------------------- castor-0.9.5-1jpp.7 expect-5.43.0-8 g-wrap-1.9.6-7.1 gnome-media-2.17.91-1.fc7 gnome-sharp-2.16.0-1.fc6 gnucash-2.0.4-1.fc6 grub-0.97-13 icon-naming-utils-0.8.1-1.fc6 jgroups-2.2.9.2-3jpp.2 kasumi-2.0.1-1.1.fc6 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libevent-1.2a-1 libgssapi-0.10-1 linux-atm-2.5.0-1.20050118cvs mikmod-3.1.6-39.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-8.fc7 perl-5.8.8-12.fc7 ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 readahead-1.3-6.fc6 scim-anthy-1.2.2-1.fc7 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 tk-8.4.13-4.fc7 tomcat5-5.5.17-6jpp.2 velocity-1.4-6jpp.1 w3m-0.5.1-15.fc6 xferstats-2.16-14.1 With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Mon Feb 26 21:58:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 26 Feb 2007 15:58:45 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-26 Message-ID: <20070226155845.A5641@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Mon Feb 26 15:37:09 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2646 Number failed to build: 66 Number expected to fail due to ExclusiveArch or ExcludeArch: 20 Leaving: 46 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 46 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com SIMVoleon-2.0.1-6.fc7 rc040203 at freenet.de SoQt-1.4.1-5.fc7 rc040203 at freenet.de airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de atitvout-0.4-6 andreas.bierfert at lowlatency.de audacity-1.3.2-7.20070106cvs.fc7 gemi at bluewin.ch,bugs.michael at gmx.net banshee-0.11.5-1.fc7 caillon at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libreadline-java-0.8.0-13.fc6 ifoox at redhat.com mlton-20061107-2.fc7 adam at spicenitz.org nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.9-7.fc7 jamatos at fc.up.pt python-reportlab-2.0-2.fc7 bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Mon Feb 26 21:59:06 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 26 Feb 2007 15:59:06 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-02-26 Message-ID: <20070226155906.A5660@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Mon Feb 26 15:41:50 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2646 Number failed to build: 43 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 41 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 41 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com SIMVoleon-2.0.1-6.fc7 rc040203 at freenet.de SoQt-1.4.1-5.fc7 rc040203 at freenet.de airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de banshee-0.11.5-1.fc7 caillon at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libreadline-java-0.8.0-13.fc6 ifoox at redhat.com nomadsync-0.4.2-13.fc6 triad at df.lth.se octave-2.9.9-2.fc7 qspencer at ieee.org openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 giallu at gmail.com toped-0.8.2-2.fc6 cgoorah at yahoo.com.au wine-0.9.31-1.fc7 andreas.bierfert at lowlatency.de xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 lsof at nodata.co.uk Mon Feb 26 22:12:54 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 26 Feb 2007 23:12:54 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45E35681.4070602@impact-crater.com> References: <200702221656.09198.kaj@haulrich.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> <1172505004.4816.3.camel@localhost.localdomain> <1172506024.4722.31.camel@localhost.localdomain> <45E35681.4070602@impact-crater.com> Message-ID: <1172527974.3171.6.camel@sb-home.lan> Am Montag, den 26.02.2007, 16:52 -0500 schrieb Tom Rivers: > Abdul Al-Felashis wrote: > > Jesus christ, sirs. I came here to troll you with my article about > > the GNAA, but it seems that you are doing a fine job of trolling > > yourselves. > > > > ~fellacious > > -- > > Are you GAY? Are you a NIG... > > > Are there any list moderators around who could respond appropriately to > this 'individual'? > Don't feed the trolls. From bojan at rexursive.com Mon Feb 26 22:19:03 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 26 Feb 2007 22:19:03 +0000 (UTC) Subject: Extras i386 rawhide rebuild in mock status 2007-02-26 References: <20070226155906.A5660@humbolt.us.dell.com> Message-ID: Matt Domsch dell.com> writes: > libapreq2-2.09-0.rc2.1.fc7 FYI, this is held back by: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197841 -- Bojan From mschwendt.tmp0701.nospam at arcor.de Mon Feb 26 23:10:00 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 27 Feb 2007 00:10:00 +0100 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-26 In-Reply-To: <20070226155845.A5641@humbolt.us.dell.com> References: <20070226155845.A5641@humbolt.us.dell.com> Message-ID: <20070227001000.be011e4a.mschwendt.tmp0701.nospam@arcor.de> On Mon, 26 Feb 2007 15:58:45 -0600, Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for x86_64 Mon Feb 26 15:37:09 CST 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > toped-0.8.2-2.fc6 cgoorah at yahoo.com.au This needs the fixed Mesa (6.5.2-6) to appear in Rawhide first. Else freeglut fails. From denis at poolshark.org Mon Feb 26 23:55:39 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 27 Feb 2007 00:55:39 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172517334.26721.12.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> <45E2FDEF.4020702@gmail.com> <45E330C7.8060705@andrei.myip.org> <1172517334.26721.12.camel@cutter> Message-ID: <45E3737B.7000205@poolshark.org> seth vidal wrote: > to extend the analogy: > if the bulb in the basement being out means there could well be a > murderer down there, then maybe the door to the house shouldn't open at > all. :) That analogy works both ways :-) If you just installed FC-6 from DVD, you're missing all security updates issued since FC-6 was released. Say a package maintainer is on vacation and a broken dep is still around. You have a dark house full of murderers, but you can't turn on the lights to expose them because a closet light bulb is out... From rafael.espindola at gmail.com Tue Feb 27 04:30:26 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Mon, 26 Feb 2007 20:30:26 -0800 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <1172521264.7161.21.camel@dipsy> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> <1172521264.7161.21.camel@dipsy> Message-ID: <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> > Works for me with the stock Fedora kernels on my PowerBook. There's no > need for fiddling around with /etc/modprobe.conf. Is your touchpad > working without synaptics, or more specifically is the appletouch module > getting loaded? It works without the appletouch module, but it is very limited (can't drag). With the modprobre hacks the appletouch driver is loaded, but the X synaptic driver doesn't work. I have the same error with /dev/input/mice and /dev/input/mouse0 Thanks, Rafael From naoki at valuecommerce.com Tue Feb 27 05:42:31 2007 From: naoki at valuecommerce.com (Naoki) Date: Tue, 27 Feb 2007 14:42:31 +0900 Subject: Slight slip of Fedora 7 Test 2 In-Reply-To: <200702261333.37545.jkeating@redhat.com> References: <200702261333.37545.jkeating@redhat.com> Message-ID: <1172554951.2911.25.camel@localhost.localdomain> Do these issues include the "does not boot due to VFS kernel panic" problem seen in the last two (three) 2.6.20 releases? On Mon, 2007-02-26 at 13:33 -0500, Jesse Keating wrote: > We've ran into some kernel difficulties on PPC, some VNC issues, and more fun > with figuring out what to spin and how. As such we were not able to have a > tree ready on Friday for the mirrors to sync. We cannot release Tomorrow. > We expect to have a final tree done (late?) today to give to the mirrors for > a Thursday (March 1st) release. From naoki at valuecommerce.com Tue Feb 27 05:51:40 2007 From: naoki at valuecommerce.com (Naoki) Date: Tue, 27 Feb 2007 14:51:40 +0900 Subject: Slight slip of Fedora 7 Test 2 In-Reply-To: <1172554951.2911.25.camel@localhost.localdomain> References: <200702261333.37545.jkeating@redhat.com> <1172554951.2911.25.camel@localhost.localdomain> Message-ID: <1172555500.2911.32.camel@localhost.localdomain> Replying to myself.. The issue is the 'switchroot' problem that began with rawhide update 20070215 and the introduction of kernel-2.6.20-1.2930.fc7. I think the problem I'm talking about is : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220470 Is it just me or is the 2.6.20 kernel about as bad as we've had so far.. Doesn't boot on SCSI (reports of SATA too) and IRQ migration completely (hard) locks SMP boxes ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227972 ). On Tue, 2007-02-27 at 14:42 +0900, Naoki wrote: > Do these issues include the "does not boot due to VFS kernel panic" > problem seen in the last two (three) 2.6.20 releases? > > On Mon, 2007-02-26 at 13:33 -0500, Jesse Keating wrote: > > We've ran into some kernel difficulties on PPC, some VNC issues, and more fun > > with figuring out what to spin and how. As such we were not able to have a > > tree ready on Friday for the mirrors to sync. We cannot release Tomorrow. > > We expect to have a final tree done (late?) today to give to the mirrors for > > a Thursday (March 1st) release. From frank at scirocco-5v-turbo.de Tue Feb 27 07:48:32 2007 From: frank at scirocco-5v-turbo.de (Frank Arnold) Date: Tue, 27 Feb 2007 08:48:32 +0100 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> <1172521264.7161.21.camel@dipsy> <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> Message-ID: <1172562512.7161.50.camel@dipsy> Am Montag, den 26.02.2007, 20:30 -0800 schrieb Rafael Esp?ndola: > > Works for me with the stock Fedora kernels on my PowerBook. There's no > > need for fiddling around with /etc/modprobe.conf. Is your touchpad > > working without synaptics, or more specifically is the appletouch module > > getting loaded? > > It works without the appletouch module, but it is very limited (can't > drag). With the modprobre hacks the appletouch driver is loaded, but > the X synaptic driver doesn't work. >From what I read so far, the MacBook touchpad operates in a normal mouse mode if not told otherwise. The appletouch module sets it to another mode, where the touchpad reports raw data of its sensors. If appletouch isn't loaded automatically, I suspect the product ID of your touchpad is not listed inside the appletouch driver. With the appletouch module loaded I get this inside the output of 'cat /proc/bus/input/devices': I: Bus=0003 Vendor=05ac Product=020f Version=0028 N: Name="appletouch" P: Phys=usb-0001:10:1a.0-2/input0 S: Sysfs=/class/input/input7 H: Handlers=mouse2 event7 B: EV=b B: KEY=6420 0 10000 0 0 0 0 0 0 0 0 B: ABS=1000003 Without appletouch this section is missing. Maybe the easiest way to get your product ID is to start up the System Profiler of MacOSX and look at the values of 'USB => USB-Bus => Apple Internal Keyboard/Trackpad'. Then you can verify it with the list inside the appletouch source. Somewhere in appletouch I found a comment 'No 17" Macbooks (yet)'. Could that be the culprit? Frank From tla at rasmil.dk Tue Feb 27 08:19:40 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Tue, 27 Feb 2007 09:19:40 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172502164.25220.18.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> Message-ID: <45E3E99C.8090602@rasmil.dk> seth vidal wrote: > On Mon, 2007-02-26 at 15:59 +0100, Denis Leroy wrote: > > >> Maybe I'm mistaken. If I submit a patch that integrates --skip-broken >> into yum, will you accept it ? I'd be more than happy to write that patch. >> > > It really depends on how the patch is implemented. Though I'm curious > why integrating it is important if the plugin works well enough? > > -sv > > > I wrote the skip-broken plugin because Seth asked me too, we agreed that it was best to make it as a plugin because the check skip-broken does take extra time, so you don't want to do it every time. Integration of the skip-broken option into yum cli base, will not solve the issue for the new users because they use pup to update the system, so the have to be build some support for skip-broken into pup. In yumex i am planning to ask the user if they want to remove packages with broken depencies, if dependency error is found in the transaction. I think that the plugin is fine for yum-cli, but extra stuff can be build into the gui's like pup,pirut & yumex. Tim Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.strandman at telia.com Tue Feb 27 08:22:47 2007 From: simon.strandman at telia.com (Simon Strandman) Date: Tue, 27 Feb 2007 09:22:47 +0100 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> Message-ID: <45E3EA57.4060801@telia.com> Rafael Esp?ndola skrev: > I am trying to make the synaptics touchpad work on fedora. I am > following the instructions on > http://gentoo-wiki.com/HARDWARE_Apple_MacBook/ > > The first problem is that some modules (mousedev, usbhid and evdev) > are compiled builtin. Why?. I compiled a custom kernel with them as > modules. > > To force the order in which they are loaded, I added the following > line to modprobe.conf: > > install mousedev /sbin/modprobe usbhid && /sbin/modprobe > --ignore-install mousedev > install usbhid /sbin/modprobe appletouch && /sbin/modprobe > --ignore-install usbhid > install appletouch /sbin/modprobe evdev && /sbin/modprobe > --ignore-install appletouch > install evdev /sbin/modprobe uhci_hcd && /sbin/modprobe > --ignore-install evdev > > Is there a better way to do it? > > Unfortunately, X still can't find the synaptics: > > Query no Synaptics: 6003C8 > (EE) Synaptics Touchpad no synaptics touchpad detected and no repeater > device > (EE) Synaptics Touchpad Unable to query/initialize Synaptics hardware. > (EE) PreInit failed for input device "Synaptics Touchpad" > > I will try to upgrade the synaptics driver. Does anyone has another > suggestion? > > Cheers, > Rafael > I have the same problem on my macbook (not pro). The touchpad is identified as a generic mouse and lacks a lot of features. This is fedora 7 test1 btw. Simon From kagesenshi.87 at gmail.com Tue Feb 27 11:02:35 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Tue, 27 Feb 2007 19:02:35 +0800 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45E357BB.3020305@argo.co.il> References: <45E357BB.3020305@argo.co.il> Message-ID: On 2/27/07, Avi Kivity wrote: > Free software is great, but it has to be voluntary. Forcing all > software to be free is wrong. > They didnt force u to make your fully owned software free .. But if you choose to use their code to make your software, you have to follow their rules .. if your software 100% owned by you .. nobody forcing you to opensource it ... GPL to me is still some sort of Intelectual Property protection .. it protect free codes from being manipulated into closed source apps ... The programmer have done big effort to give away to free software community ... and they want others who use their code to respect that ... I'm totally against software patents .. I dont mind closed source their apps .... but making the procedure patented is totally wrong ... its like saying music genres (hip-hop / rock / jazz etc) are patented... music are procedures of playing with instruments afterall ... -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com GPG: http://www.rootshell.be/~kagesens/public-key.asc Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From kagesenshi.87 at gmail.com Tue Feb 27 11:07:27 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Tue, 27 Feb 2007 19:07:27 +0800 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: References: <45E357BB.3020305@argo.co.il> Message-ID: On 2/27/07, Hikaru Amano wrote: > I'm totally against software patents .. I dont mind closed source > their apps .... but making the procedure patented is totally wrong ... oops .. dangerous typo .. supposed to be "I dont mind developers closed sourced their apps" From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 11:45:40 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 12:45:40 +0100 Subject: d80211 and iwlwifi In-Reply-To: <1172526475.2728.6.camel@localhost.localdomain> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> <1172469250.3142.2.camel@bureau.maison> <1172493685.3061.4.camel@localhost.localdomain> <20070226195109.GC1990@redhat.com> <1172526475.2728.6.camel@localhost.localdomain> Message-ID: <20070227124540.482d1f52@python3.es.egwn.lan> Richard Hughes wrote : > On Mon, 2007-02-26 at 14:51 -0500, Dave Jones wrote: > > > I'd hope d80211 and the associated drivers are _not_ shipped for FC6 > > > (unless in testing) until they have settled down quite a bit. They > > > still have quite a lot of maturing to do. > > > > Right, the current plan is F7+ only for d80211. > > Cool. I'm finding the zd1211rw_d80211 much more stable than the zd121rw > softmac driver. Plus, ipw3945 has an experimental d80211 driver which > does not require the userspace regulatory binary. If you need the firmware for that new ipw3945 driver, it's waiting for a review over here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230096 (which is basically waiting for a final agreement on firmware name space) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.12 0.52 0.81 From buildsys at redhat.com Tue Feb 27 11:48:09 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 27 Feb 2007 06:48:09 -0500 Subject: rawhide report: 20070227 changes Message-ID: <200702271148.l1RBm9Wr008298@hs20-bc2-6.build.redhat.com> Updated Packages: kernel-2.6.20-1.2949.fc7 ------------------------ * Mon Feb 26 2007 Dave Jones - Fix up radeonfb backlight. - Revert forcedeth changes so that it works again. vnc-4.1.2-13.fc7 ---------------- * Mon Feb 26 2007 Adam Tkac 4.1.2-13.fc7 - remove wild implementation of vsnprintf (this caused sigfaults on 64bits) (#229702) - added post & postun sections to vnc-libs - menu tooltip is HIG compliant (#229941) - specfile has been standardized (checked by rpmlint) * Fri Feb 23 2007 Adam Tkac 4.1.2-12.fc7 - new colormap policy in Xvnc - Xvnc now always use framebuffer (like Xvfb) - obsolete patches have been removed Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 From laroche at redhat.com Tue Feb 27 12:23:12 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 27 Feb 2007 13:23:12 +0100 Subject: [karsten@redhat.com: rpmdiff Resultate] Message-ID: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> Hello all, This is a check where we do an "everything"-install and rebuild all packages. All newly built packages are compared against currently existing packages. Newly picked up deps can be due to newer libs or also point at missing BuildRequires. Missing build deps could also point at regressions compared to pre-mock buildroots which are as small as possible. Many such cases have already been cleaned up in the past, so the list isn't too long anymore. regards, Florian La Roche ----- Forwarded message from Karsten Hopp ----- From: Karsten Hopp Subject: rpmdiff Resultate To: florian.laroche at redhat.de Date: Tue, 27 Feb 2007 12:04:28 +0100 Hier sind die aktuellen Ergebnisse eines rpmdiffs zwischen brew-Paketen und Paketen, die in einer Komplettinstallation gebaut wurden: ################################# am-utils-6.1.5-5.i386.rpm removed REQUIRES libc.so.6(GLIBC_2.2) added REQUIRES libwrap.so.0 ################################# axis-1.2.1-2jpp.6.i386.rpm added REQUIRES libm.so.6(GLIBC_2.0) ################################# bsh-manual-1.3.0-9jpp.1.i386.rpm added /usr/share/doc/bsh-manual-1.3.0/faq/faq.html added /usr/share/doc/bsh-manual-1.3.0/manual/appletmode.html added /usr/share/doc/bsh-manual-1.3.0/manual/bsf.html added /usr/share/doc/bsh-manual-1.3.0/manual/bshcommands.html added /usr/share/doc/bsh-manual-1.3.0/manual/bshdoc.html added /usr/share/doc/bsh-manual-1.3.0/manual/bshmanual.html added /usr/share/doc/bsh-manual-1.3.0/manual/classpath.html added /usr/share/doc/bsh-manual-1.3.0/manual/commands.html added /usr/share/doc/bsh-manual-1.3.0/manual/contents.html added /usr/share/doc/bsh-manual-1.3.0/manual/credit.html added /usr/share/doc/bsh-manual-1.3.0/manual/desktop.html added /usr/share/doc/bsh-manual-1.3.0/manual/embeddedmode.html added /usr/share/doc/bsh-manual-1.3.0/manual/execscripts.html added /usr/share/doc/bsh-manual-1.3.0/manual/index.html added /usr/share/doc/bsh-manual-1.3.0/manual/interfaces.html added /usr/share/doc/bsh-manual-1.3.0/manual/intro.html added /usr/share/doc/bsh-manual-1.3.0/manual/jconsole.html added /usr/share/doc/bsh-manual-1.3.0/manual/methods.html added /usr/share/doc/bsh-manual-1.3.0/manual/more.html added /usr/share/doc/bsh-manual-1.3.0/manual/objects.html added /usr/share/doc/bsh-manual-1.3.0/manual/parser.html added /usr/share/doc/bsh-manual-1.3.0/manual/quickstart.html added /usr/share/doc/bsh-manual-1.3.0/manual/reflectivestyle.html added /usr/share/doc/bsh-manual-1.3.0/manual/remotemode.html added /usr/share/doc/bsh-manual-1.3.0/manual/scope.html added /usr/share/doc/bsh-manual-1.3.0/manual/servletmode.html added /usr/share/doc/bsh-manual-1.3.0/manual/specialvarsvalues.html added /usr/share/doc/bsh-manual-1.3.0/manual/standalonemode.html added /usr/share/doc/bsh-manual-1.3.0/manual/strictjava.html added /usr/share/doc/bsh-manual-1.3.0/manual/syntax.html ################################# crash-4.0-3.3.i386.rpm added REQUIRES libtinfo.so.5 ################################# gftp-2.0.18-3.2.2.i386.rpm added REQUIRES libpng12.so.0 ################################# giflib-4.1.3-7.1.i386.rpm added REQUIRES libICE.so.6 added REQUIRES libSM.so.6 ################################# giflib-utils-4.1.3-7.1.i386.rpm added REQUIRES libICE.so.6 added REQUIRES libSM.so.6 ################################# gnome-applet-vm-0.1.2-1.i386.rpm removed REQUIRES libxml2.so.2 added REQUIRES libpng12.so.0 added REQUIRES librt.so.1 ################################# gnome-vfs2-monikers-2.15.3-2.i386.rpm removed REQUIRES libm.so.6 added REQUIRES librt.so.1 ################################# gnupg-1.4.6-3.i386.rpm removed REQUIRES libncurses.so.5 added REQUIRES libtermcap.so.2 ################################# gtkhtml2-2.11.0-3.i386.rpm removed REQUIRES libart_lgpl_2.so.2 removed REQUIRES libgnomecanvas-2.so.0 removed REQUIRES libpangoft2-1.0.so.0 removed REQUIRES libz.so.1 added REQUIRES libpng12.so.0 ################################# icon-slicer-0.3-7.2.2.i386.rpm added REQUIRES libpng12.so.0 ################################# info-4.8-15.i386.rpm added REQUIRES libtinfo.so.5 ################################# iptstate-1.4-1.1.2.2.i386.rpm added REQUIRES libtinfo.so.5 ################################# jakarta-commons-codec-javadoc-1.3-7jpp.2.i386.rpm added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/binary/Base64-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/binary/BinaryCodec-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/binary/BinaryCodec.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/binary/Hex-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/binary/Hex.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/digest added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/digest/DigestUtils-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/digest/DigestUtils.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/digest/classes.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/digest/package-summary.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/digest/tree.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/DoubleMetaphone-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/DoubleMetaphone.DoubleMetaphoneResult-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/DoubleMetaphone.DoubleMetaphoneResult.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/DoubleMetaphone.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/Metaphone-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/Metaphone.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/RefinedSoundex-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/RefinedSoundex.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/Soundex-uses.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/Soundex.html added /usr/share/javadoc/jakarta-commons-codec-1.3/org/apache/commons/codec/language/SoundexUtils-uses.html ...... ################################# kdbg-2.0.2-1.2.1.i386.rpm removed REQUIRES libfam.so.0 added REQUIRES libutempter.so.0 ################################# krb5-auth-dialog-0.7-1.i386.rpm removed REQUIRES libz.so.1 added REQUIRES libpng12.so.0 added REQUIRES librt.so.1 ################################# krb5-workstation-clients-1.6-1.i386.rpm added REQUIRES libtermcap.so.2 added REQUIRES libtinfo.so.5 ################################# krb5-workstation-servers-1.6-1.i386.rpm added REQUIRES libtermcap.so.2 ################################# libao-0.8.6-4.i386.rpm added REQUIRES librt.so.1 ################################# libcroco-0.6.1-2.1.i386.rpm removed REQUIRES libm.so.6 removed REQUIRES libz.so.1 ################################# libgail-gnome-1.1.3-1.2.1.i386.rpm removed REQUIRES libxml2.so.2 removed REQUIRES libz.so.1 added REQUIRES libpng12.so.0 added REQUIRES librt.so.1 ################################# libgnomecups-0.2.2-8.i386.rpm added REQUIRES librt.so.1 ################################# libvolume_id-devel-104-2.i386.rpm added REQUIRES libvolume_id.so.0 ################################# linuxwacom-0.7.4_1-2.1.i386.rpm added REQUIRES libtinfo.so.5 ################################# minicom-2.1-3.i386.rpm removed REQUIRES libncurses.so.5 added REQUIRES libtinfo.so.5 ################################# mtr-0.71-3.1.i386.rpm added REQUIRES libtermcap.so.2 added REQUIRES libtinfo.so.5 ################################# mtr-gtk-0.71-3.1.i386.rpm added REQUIRES libpng12.so.0 added REQUIRES libtermcap.so.2 added REQUIRES libtinfo.so.5 ################################# mx-2.0.6-3.i386.rpm removed REQUIRES libc.so.6(GLIBC_2.2) removed REQUIRES libpthread.so.0(GLIBC_2.1) removed REQUIRES libpthread.so.0(GLIBC_2.2) added REQUIRES libpython2.5.so.1.0 ################################# nmap-4.20-1.i386.rpm added REQUIRES libpcap.so.0.9 ################################# nmap-frontend-4.20-1.i386.rpm added REQUIRES libpng12.so.0 ################################# openoffice.org-sdk-doc-2.2.0-8.1.i386.rpm removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/c-s_Anonymous__10.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/c-s_Anonymous__13.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/c-s_Anonymous__17.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/c-s_Anonymous__18.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/c-s_Anonymous__25.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/c-s_Anonymous__28.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/e-e_Anonymous__10.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/e-e_Anonymous__13.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/e-e_Anonymous__17.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/e-e_Anonymous__18.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/e-e_Anonymous__25.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/e-e_Anonymous__28.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__10 removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__10/d.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__10/o.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__13 removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__13/d.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__13/o.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__17 added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__17/d.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__17/o.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__18 removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__18/d.html removed /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__18/o.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__25 added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__25/d.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__25/o.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__28 added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__28/d.html added /usr/lib/openoffice.org/sdk/docs/cpp/ref/names/s_Anonymous__28/o.html ################################# procps-3.2.7-10.i386.rpm added REQUIRES libtinfo.so.5 ################################# psmisc-22.2-5.i386.rpm removed REQUIRES libncurses.so.5 added REQUIRES libtinfo.so.5 ################################# pyOpenSSL-0.6-1.p24.9.i386.rpm removed REQUIRES libc.so.6(GLIBC_2.1) removed REQUIRES libc.so.6(GLIBC_2.2) removed REQUIRES libc.so.6(GLIBC_2.3) removed REQUIRES libpthread.so.0(GLIBC_2.1) removed REQUIRES libpthread.so.0(GLIBC_2.2) added REQUIRES libpython2.5.so.1.0 ################################# pyorbit-2.14.1-2.i386.rpm removed REQUIRES libdl.so.2 removed REQUIRES libgmodule-2.0.so.0 removed REQUIRES libm.so.6 added REQUIRES libgobject-2.0.so.0 added REQUIRES librt.so.1 ################################# python-ldap-2.2.0-3.i386.rpm removed REQUIRES libc.so.6(GLIBC_2.1) removed REQUIRES libc.so.6(GLIBC_2.2) removed REQUIRES libc.so.6(GLIBC_2.3) removed REQUIRES libpthread.so.0(GLIBC_2.0) removed REQUIRES libpthread.so.0(GLIBC_2.1) removed REQUIRES libpthread.so.0(GLIBC_2.2) added REQUIRES libpython2.5.so.1.0 ################################# python-numeric-24.2-3.i386.rpm removed REQUIRES libc.so.6(GLIBC_2.1) removed REQUIRES libc.so.6(GLIBC_2.2) removed REQUIRES libc.so.6(GLIBC_2.3) removed REQUIRES libpthread.so.0(GLIBC_2.1) removed REQUIRES libpthread.so.0(GLIBC_2.2) added REQUIRES libpython2.5.so.1.0 ################################# PyXML-0.8.4-5.i386.rpm removed REQUIRES libc.so.6(GLIBC_2.1) removed REQUIRES libc.so.6(GLIBC_2.2) removed REQUIRES libpthread.so.0(GLIBC_2.0) removed REQUIRES libpthread.so.0(GLIBC_2.1) removed REQUIRES libpthread.so.0(GLIBC_2.2) added REQUIRES libpython2.5.so.1.0 ################################# sane-frontends-1.0.14-1.2.2.i386.rpm added REQUIRES libexif.so.12 added REQUIRES libpng12.so.0 ################################# sharutils-4.6.1-2.i386.rpm removed /usr/bin/compress-dummy ################################# telnet-0.17-37.i386.rpm added REQUIRES libtinfo.so.5 ################################# tftp-0.42-4.i386.rpm added REQUIRES libreadline.so.5 added REQUIRES libtermcap.so.2 ################################# timidity++-2.13.2-1.2.2.i386.rpm added REQUIRES libX11.so.6 added REQUIRES librt.so.1 added REQUIRES libslang.so.2 added REQUIRES libslang.so.2(SLANG2) added REQUIRES libtinfo.so.5 ################################# usermode-gtk-1.87-3.i386.rpm removed REQUIRES libz.so.1 added REQUIRES libpng12.so.0 added REQUIRES libstartup-notification-1.so.0 added REQUIRES libwnck-1.so.18 ################################# valgrind-3.2.3-2.i386.rpm added REQUIRES libc.so.6(GLIBC_2.1.3) added REQUIRES libdl.so.2 added REQUIRES libmpi.so.0 added REQUIRES libnsl.so.1 added REQUIRES libopal.so.0 added REQUIRES liborte.so.0 added REQUIRES libpthread.so.0 added REQUIRES libpthread.so.0(GLIBC_2.0) added REQUIRES libutil.so.1 added PROVIDES libmpiwrap.so added /usr/lib/valgrind/x86-linux/libmpiwrap.so ################################# xalan-j2-2.7.0-6jpp.1.i386.rpm added REQUIRES libm.so.6(GLIBC_2.0) ################################# xcdroast-0.98a15-12.2.2.i386.rpm added REQUIRES libpng12.so.0 ################################# xerces-j2-2.7.1-7jpp.2.i386.rpm added REQUIRES libgcc_s.so.1(GLIBC_2.0) -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de ----- End forwarded message ----- From knightmerc at yahoo.com Tue Feb 27 12:33:14 2007 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Tue, 27 Feb 2007 07:33:14 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172506024.4722.31.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> <1172505004.4816.3.camel@localhost.localdomain> <1172506024.4722.31.camel@localhost.localdomain> Message-ID: <1172579594.4816.56.camel@localhost.localdomain> On Mon, 2007-02-26 at 11:07 -0500, Michael Tiemann wrote: > On Mon, 2007-02-26 at 10:50 -0500, Lyvim Xaphir wrote: > > On Sun, 2007-02-25 at 01:52 +0100, Benny Amorsen wrote: > > > >>>>> "LX" == Lyvim Xaphir writes: > > > > > > LX> If you are advocating stealing intellectual property for the > > > LX> general welfare, then that's clearly criminal. Truthfully I don't > > > LX> think you are or would advocate such a thing, but there are those > > > LX> here who are. > > > > > > I am one of them. I advocate getting rid of intellectual property > > > entirely. I do not see what is criminal about a free market. > > > > > > > > > /Benny > > > > You don't understand what a free market is. A free market, as in > > capitalism, is based on private property ownership. > > I think it is you who do not understand what a free market is. A free > market is one in which two parties can agree to trade without seeking > the explicit permission of the government to do so. The less > permission/regulation exerted by the government, the freer the market. To a point. I generally am in agreement with libertarian models, however there is a sweet spot of government presence in the market; in other words there has to be some kind of legal consequence for scams and unethical activity. Obviously free trade cannot take place in an anarchy where you can get shot and then people just take your goods; the existence of it depends on civilized behavior which is not available without some form of government. Otherwise corruption prevents anything meaningful from taking place; aka a soprano state. (that is different from regulations on free trade, which is not what I'm discussing in this case) The unethical activity I've been talking about here is forced licensing, where other licenses bearing other agendas are not tolerated because of ideology. > The move invasive and pervasive the controls exerted by the government, > the less free the market. Property rights are orthogonal to the > freeness of a market. They are highly relevant to certain economic > assumptions, but one can have a free market without property rights. > See http://en.wikipedia.org/wiki/Free_market Perhaps, but where's your existing successful model after many thousands of years of human effort, trial and error? You can do anything you want to in theory, it's in practice where the truth is told. Alot of models have already been tried, the cream generally rises to the top, and it has. In any case, a *real* free market would allow both property ownership and non-ownership (which btw it does already currently), and what I'm talking about is the right of the author to either freely give his own work or license it the way he sees fit within current infrastructure, which makes your last statement above a non-sequitur. The author retains the intrinsic rights over his own production. The right to own property is also central to principles the United States was founded on, which currently has the most successful economic model in practice, in history. Nobody's talking about either/or. The main point that I'm making is simply that people have the rights to their own work and that you or anybody else does not have the right to tell them how to license that work. That's the way it's working currently (for the *most* part) in the US, and those values and practices create a solid revenue stream for many people. There are many "economic assumptions", but alot of those can be tossed out the door by observing successful economic strategies, aka the United States, and the practices of the 50 individual states (which are all individual economic experiments on their own to a degree). There is after all a huge trial and error database to draw from, what works what doesn't work. In the largely successful economic "model" of the United States there are provisions for the protection of intellectual property. I believe in minimal government involvement (regulation) as well but that's another discussion. > > M > LX -- ??????????????????????????????????????????????????? A Kernel Of Socialism greatunwashed: module license 'great_unwashed' taints kernel. ich: no version for "unwashed_register_device" found: kernel tainted. Symbol usb_register_driver is being used by a non-GPL module, which will not be allowed in the future Please see the file Documentation/feature-removal-schedule.txt in the kernel source tree for more details. ??????????????????????????????????????????????????? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 13:01:49 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 14:01:49 +0100 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> Message-ID: <20070227140149.616d1383@python3.es.egwn.lan> Florian La Roche wrote : > This is a check where we do an "everything"-install and rebuild > all packages. All newly built packages are compared against currently > existing packages. Newly picked up deps can be due to newer libs > or also point at missing BuildRequires. Missing build deps could also > point at regressions compared to pre-mock buildroots which are as small > as possible. > > Many such cases have already been cleaned up in the past, so the > list isn't too long anymore. This is neat, and ultimately quite useful. Would somebody be willing to try this with Extras too? (I guess "everything" will be a bit more difficult because of more explicit conflicts) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.03 0.10 0.09 From laroche at redhat.com Tue Feb 27 13:06:04 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 27 Feb 2007 14:06:04 +0100 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227140149.616d1383@python3.es.egwn.lan> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> <20070227140149.616d1383@python3.es.egwn.lan> Message-ID: <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> > This is neat, and ultimately quite useful. Would somebody be willing to > try this with Extras too? (I guess "everything" will be a bit more > difficult because of more explicit conflicts) We can run this test again in 2 or 3 weeks to see how F7 looks like and then also add the FE packages to what we currently call a "full FC" chroot. regards, Florian La Roche From jkeating at redhat.com Tue Feb 27 13:09:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Feb 2007 08:09:05 -0500 Subject: Slight slip of Fedora 7 Test 2 In-Reply-To: <1172555500.2911.32.camel@localhost.localdomain> References: <200702261333.37545.jkeating@redhat.com> <1172554951.2911.25.camel@localhost.localdomain> <1172555500.2911.32.camel@localhost.localdomain> Message-ID: <200702270809.08745.jkeating@redhat.com> On Tuesday 27 February 2007 00:51, Naoki wrote: > Replying to myself.. > > The issue is the 'switchroot' problem that began with rawhide update > 20070215 and the introduction of kernel-2.6.20-1.2930.fc7. > > I think the problem I'm talking about is : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220470 > > > Is it just me or is the 2.6.20 kernel about as bad as we've had so far.. > Doesn't boot on SCSI (reports of SATA too) and IRQ migration completely > (hard) locks SMP boxes > ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227972 ). I do not know if these issues are resolved. The Xen kernel hasn't been changed from Test1 I do believe. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 13:14:57 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 14:14:57 +0100 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> <20070227140149.616d1383@python3.es.egwn.lan> <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> Message-ID: <20070227141457.202809d6@python3.es.egwn.lan> Florian La Roche wrote : > > This is neat, and ultimately quite useful. Would somebody be willing to > > try this with Extras too? (I guess "everything" will be a bit more > > difficult because of more explicit conflicts) > > We can run this test again in 2 or 3 weeks to see how F7 looks like > and then also add the FE packages to what we currently call a > "full FC" chroot. It would be a good idea, since I'm pretty sure interesting results will pop-up, especially some ("used to be") Core packages being able to include some optional functionality provided by ("used to be") Extras packages... some of which we might even want/like to have. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.29 1.09 0.67 From laroche at redhat.com Tue Feb 27 13:21:32 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 27 Feb 2007 14:21:32 +0100 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227141457.202809d6@python3.es.egwn.lan> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> <20070227140149.616d1383@python3.es.egwn.lan> <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> <20070227141457.202809d6@python3.es.egwn.lan> Message-ID: <20070227132132.GA7551@dudweiler.stuttgart.redhat.com> On Tue, Feb 27, 2007 at 02:14:57PM +0100, Matthias Saou wrote: > Florian La Roche wrote : > > > > This is neat, and ultimately quite useful. Would somebody be willing to > > > try this with Extras too? (I guess "everything" will be a bit more > > > difficult because of more explicit conflicts) > > > > We can run this test again in 2 or 3 weeks to see how F7 looks like > > and then also add the FE packages to what we currently call a > > "full FC" chroot. > > It would be a good idea, since I'm pretty sure interesting results > will pop-up, especially some ("used to be") Core packages being able to > include some optional functionality provided by ("used to be") Extras > packages... some of which we might even want/like to have. Other possibility is that maybe Matt Domsch could also pick this up for his rebuild scripts? Matt, ?? regards, Florian La Roche From avi at argo.co.il Tue Feb 27 13:19:51 2007 From: avi at argo.co.il (Avi Kivity) Date: Tue, 27 Feb 2007 15:19:51 +0200 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: References: <45E357BB.3020305@argo.co.il> Message-ID: <45E42FF7.1060807@argo.co.il> Hikaru Amano wrote: > On 2/27/07, Avi Kivity wrote: >> Free software is great, but it has to be voluntary. Forcing all >> software to be free is wrong. >> > > They didnt force u to make your fully owned software free .. But if > you choose to use their code to make your software, you have to follow > their rules .. if your software 100% owned by you .. nobody forcing > you to opensource it ... > You've lost the thread. I'm not against the GPL (I've released GPL'ed software), I am against abolishing copyright (and thus placing all software and media in the public domain). -- error compiling committee.c: too many arguments to function From fedora at leemhuis.info Tue Feb 27 13:22:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Feb 2007 14:22:03 +0100 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> <20070227140149.616d1383@python3.es.egwn.lan> <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> Message-ID: <45E4307B.3090309@leemhuis.info> On 27.02.2007 14:06, Florian La Roche wrote: >> This is neat, and ultimately quite useful. Would somebody be willing to >> try this with Extras too? (I guess "everything" will be a bit more >> difficult because of more explicit conflicts) > We can run this test again in 2 or 3 weeks to see how F7 looks like > and then also add the FE packages to what we currently call a > "full FC" chroot. It would be really nice to have this and similar scripts (for example those that checks for file conflicts or unowned directories) running on dedicated machine/Xen instance regularly. CU thl From jacliburn at bellsouth.net Tue Feb 27 13:22:57 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Tue, 27 Feb 2007 07:22:57 -0600 Subject: rawhide report: 20070227 changes In-Reply-To: <200702271148.l1RBm9Wr008298@hs20-bc2-6.build.redhat.com> References: <200702271148.l1RBm9Wr008298@hs20-bc2-6.build.redhat.com> Message-ID: <45E430B1.1030702@bellsouth.net> buildsys at redhat.com wrote: > kernel-2.6.20-1.2949.fc7 > ------------------------ > * Mon Feb 26 2007 Dave Jones > - Fix up radeonfb backlight. > - Revert forcedeth changes so that it works again. There's a fix on the street for the forcedeth problem. http://lkml.org/lkml/2007/2/27/109 Jay From kagesenshi.87 at gmail.com Tue Feb 27 13:27:46 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Tue, 27 Feb 2007 21:27:46 +0800 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45E42FF7.1060807@argo.co.il> References: <45E357BB.3020305@argo.co.il> <45E42FF7.1060807@argo.co.il> Message-ID: On 2/27/07, Avi Kivity wrote: > You've lost the thread. I'm not against the GPL (I've released GPL'ed > software), I am against abolishing copyright (and thus placing all > software and media in the public domain). > woops ... XD .. I thought this thread was about IP and forcing ppl to release softwares with the source ... anyway .. sorry then :D .. (gotta read from top again) From laroche at redhat.com Tue Feb 27 13:28:58 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 27 Feb 2007 14:28:58 +0100 Subject: Core values In-Reply-To: <20070221203008.GA5696@thyrsus.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <45DC9BC5.6080704@fedoraproject.org> <20070221195919.GB4620@thyrsus.com> <200702211510.49895.jkeating@redhat.com> <20070221203008.GA5696@thyrsus.com> Message-ID: <20070227132858.GB7590@dudweiler.stuttgart.redhat.com> > The Ubuntu crowd gets this. The Fedora crowd doesn't. That difference is > nowhere near the only reason I'm gone, but it's a big one. We keep high goals from the Red Hat side and hope to share these with a growing Linux community. regards, Florian La Roche From bernie at develer.com Tue Feb 27 13:35:09 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Tue, 27 Feb 2007 14:35:09 +0100 Subject: [ANNOUNCE]: FC6 ia64 ISOs available In-Reply-To: <454A174E.7080803@warmcat.com> References: <454A0679.3080505@redhat.com> <200611021008.27113.jkeating@redhat.com> <454A0CD4.9060309@warmcat.com> <200611021037.57855.jkeating@redhat.com> <20061102164114.0cfd3569@banea.int.addix.net> <454A14EB.4070205@warmcat.com> <20061102170213.053559ac@banea.int.addix.net> <454A174E.7080803@warmcat.com> Message-ID: <45E4338D.9010601@develer.com> Andy Green wrote: > Hi Ralf - > > I wonder what they think I ought to do when I gave my stepson a copy of > the FC6 binary DVD! Have you also given your stepson a written offer, valid for at least three years, to give him the source code? If you forgot, then you're violating section 6c of the GPL and any Fedora contributor on this list could sue you any time :-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rafael.espindola at gmail.com Tue Feb 27 14:38:35 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Tue, 27 Feb 2007 06:38:35 -0800 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <1172562512.7161.50.camel@dipsy> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> <1172521264.7161.21.camel@dipsy> <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> <1172562512.7161.50.camel@dipsy> Message-ID: <564d96fb0702270638g444fef74r1d0de7fce7ba2e5e@mail.gmail.com> > If appletouch isn't loaded automatically, I suspect the product ID of > your touchpad is not listed inside the appletouch driver. With the > appletouch module loaded I get this inside the output of > 'cat /proc/bus/input/devices': I think that you have found the problem. I have a Geiser IV ISO (according to AppleUSBTrackpad.kext). The appletouch driver supports up to Geiser III only. I will try to add support for it. Thanks! Rafael From ssorce at redhat.com Tue Feb 27 14:53:47 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 Feb 2007 09:53:47 -0500 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <45E42FF7.1060807@argo.co.il> References: <45E357BB.3020305@argo.co.il> <45E42FF7.1060807@argo.co.il> Message-ID: <1172588027.637.114.camel@localhost.localdomain> On Tue, 2007-02-27 at 15:19 +0200, Avi Kivity wrote: > Hikaru Amano wrote: > > On 2/27/07, Avi Kivity wrote: > >> Free software is great, but it has to be voluntary. Forcing all > >> software to be free is wrong. > >> > > > > They didnt force u to make your fully owned software free .. But if > > you choose to use their code to make your software, you have to follow > > their rules .. if your software 100% owned by you .. nobody forcing > > you to opensource it ... > > > > You've lost the thread. I'm not against the GPL (I've released GPL'ed > software), I am against abolishing copyright (and thus placing all > software and media in the public domain). Then you lost the thread, we were talking about the GPL and the kernel, and how following the rules set by kernel devs. is the right thing. The secondary thread, was on the nature of Intellectual Property, not about abolishing it. Simo. -- Simo Sorce Sr Software Engineer Base Operating Systems Red Hat Inc. From alex at tvtransilvania.ro Tue Feb 27 15:02:59 2007 From: alex at tvtransilvania.ro (Alexandru Ciobanu) Date: Tue, 27 Feb 2007 17:02:59 +0200 Subject: HP500 notebook synaptics touchpad not recognized and fix Message-ID: <45E44823.5020004@tvtransilvania.ro> On my HP500 notebook the synaptics touchpad is not recognized by neither FC6 nor FC7t1. The error is: PNP: PS/2 Controller [PNP0303:C1A4,PNP0f13:C1A5] at 0x60,0x64 irq 1,12 Failed to disable AUX port, but continuing anyway... Is this a SiS? If AUX port is really absent please use the 'i8042.noaux' option. After some googleing around I've found that the PNP PS/2 detection routine in drivers/input/serio/i8042.c from the kernel tree is responsible of this. I've found a hint on a Gentoo forum, made a kernel patch [patch attached] and build a custom kernel, which fixed my touchpad issue. I'm new in the "RedHat Bugzilla land" and I'm not a kernel hacker nor an C/C++ developer, hence my question: Should I bugzilla this? -------------- next part -------------- A non-text attachment was scrubbed... Name: i8042.c.patch Type: text/x-patch Size: 226 bytes Desc: not available URL: From bruno at wolff.to Tue Feb 27 16:25:52 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 27 Feb 2007 10:25:52 -0600 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172579594.4816.56.camel@localhost.localdomain> References: <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> <20070223075524.GA3037@free.fr> <1172223556.3743.257.camel@localhost.localdomain> <20070223104606.GA2838@free.fr> <1172314712.4297.64.camel@localhost.localdomain> <1172505004.4816.3.camel@localhost.localdomain> <1172506024.4722.31.camel@localhost.localdomain> <1172579594.4816.56.camel@localhost.localdomain> Message-ID: <20070227162552.GD14029@wolff.to> On Tue, Feb 27, 2007 at 07:33:14 -0500, Lyvim Xaphir wrote: > On Mon, 2007-02-26 at 11:07 -0500, Michael Tiemann wrote: > > > > I think it is you who do not understand what a free market is. A free > > market is one in which two parties can agree to trade without seeking > > the explicit permission of the government to do so. The less > > permission/regulation exerted by the government, the freer the market. > > To a point. I generally am in agreement with libertarian models, > however there is a sweet spot of government presence in the market; in For economics, a Free Market usually assumes that the parties have complete information about the exchange. Government intervention in preventing false claims about the goods is related to this. Providing money to make exchanges more efficient and preventing theft also help provide an environment for Free Markets. > other words there has to be some kind of legal consequence for scams and > unethical activity. Obviously free trade cannot take place in an anarchy > where you can get shot and then people just take your goods; the > existence of it depends on civilized behavior which is not available > without some form of government. Otherwise corruption prevents anything > meaningful from taking place; aka a soprano state. (that is different > from regulations on free trade, which is not what I'm discussing in this > case) The unethical activity I've been talking about here is forced > licensing, where other licenses bearing other agendas are not tolerated > because of ideology. You are assuming certain things are naturally property which not everyone aggrees is. That is resulting in different takes on whether some activities are ethical. This isn't really the forum to discuss this and any argument here isn't likely to convince the people involved to switch their positions. From Matt_Domsch at dell.com Tue Feb 27 17:46:17 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 27 Feb 2007 11:46:17 -0600 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227132132.GA7551@dudweiler.stuttgart.redhat.com> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> <20070227140149.616d1383@python3.es.egwn.lan> <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> <20070227141457.202809d6@python3.es.egwn.lan> <20070227132132.GA7551@dudweiler.stuttgart.redhat.com> Message-ID: <20070227174617.GB6148@lists.us.dell.com> On Tue, Feb 27, 2007 at 02:21:32PM +0100, Florian La Roche wrote: > On Tue, Feb 27, 2007 at 02:14:57PM +0100, Matthias Saou wrote: > > Florian La Roche wrote : > > > > > > This is neat, and ultimately quite useful. Would somebody be willing to > > > > try this with Extras too? (I guess "everything" will be a bit more > > > > difficult because of more explicit conflicts) > > > > > > We can run this test again in 2 or 3 weeks to see how F7 looks like > > > and then also add the FE packages to what we currently call a > > > "full FC" chroot. > > > > It would be a good idea, since I'm pretty sure interesting results > > will pop-up, especially some ("used to be") Core packages being able to > > include some optional functionality provided by ("used to be") Extras > > packages... some of which we might even want/like to have. > > Other possibility is that maybe Matt Domsch could also pick this > up for his rebuild scripts? Matt, ?? They already do. :-) http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-core/i386/00-rpmdiff-added-or-removed.txt http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-core/x86_64/00-rpmdiff-added-or-removed.txt http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-extras/i386/00-rpmdiff-added-or-removed.txt http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-extras/x86_64/00-rpmdiff-added-or-removed.txt is the rollup, and each rpm directory under there has their own rpmdiff (against what's on the download servers) http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-extras/i386/915resolution-0.5.2-4.fc7.src.rpm/result/rpmdiff.log and rpmlint http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-extras/i386/915resolution-0.5.2-4.fc7.src.rpm/result/rpmlint.log -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 18:11:39 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 19:11:39 +0100 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227174617.GB6148@lists.us.dell.com> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> <20070227140149.616d1383@python3.es.egwn.lan> <20070227130604.GA7030@dudweiler.stuttgart.redhat.com> <20070227141457.202809d6@python3.es.egwn.lan> <20070227132132.GA7551@dudweiler.stuttgart.redhat.com> <20070227174617.GB6148@lists.us.dell.com> Message-ID: <20070227191139.32e3a1e7@python3.es.egwn.lan> Matt Domsch wrote : > On Tue, Feb 27, 2007 at 02:21:32PM +0100, Florian La Roche wrote: > > On Tue, Feb 27, 2007 at 02:14:57PM +0100, Matthias Saou wrote: > > > Florian La Roche wrote : > > > > > > > > This is neat, and ultimately quite useful. Would somebody be willing to > > > > > try this with Extras too? (I guess "everything" will be a bit more > > > > > difficult because of more explicit conflicts) > > > > > > > > We can run this test again in 2 or 3 weeks to see how F7 looks like > > > > and then also add the FE packages to what we currently call a > > > > "full FC" chroot. > > > > > > It would be a good idea, since I'm pretty sure interesting results > > > will pop-up, especially some ("used to be") Core packages being able to > > > include some optional functionality provided by ("used to be") Extras > > > packages... some of which we might even want/like to have. > > > > Other possibility is that maybe Matt Domsch could also pick this > > up for his rebuild scripts? Matt, ?? > > They already do. :-) > http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-core/i386/00-rpmdiff-added-or-removed.txt > http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-core/x86_64/00-rpmdiff-added-or-removed.txt > http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-extras/i386/00-rpmdiff-added-or-removed.txt > http://linux.dell.com/files/fedora/fixbuildrequires/mock-results-extras/x86_64/00-rpmdiff-added-or-removed.txt s/fixbuildrequires/FixBuildRequires/ Wow! It uncovers SO MANY BUGS!!! Many noarch python packages ending up using the sitearch dir when rebuilt on x86_64, for instance. It would really be interesting going through most of these. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.15 1.11 0.73 From fedora at leemhuis.info Tue Feb 27 18:17:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Feb 2007 19:17:31 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions Message-ID: <45E475BB.1080806@leemhuis.info> Hi, as some of you know, I'd prefer to have a separate mailing list for discussions around EPEL. I didn't bring that topic up much until now, but two people in private mails heavily insisted to have a special EPEL mailing list. So I'm trying to move this discussion here. Do you guys want a separate mailing list for EPEL? The usual advantages and disadvantages apply. Maily: Users that are only interested in EPEL don't have to subscribe to a mailinglist that has 95% of traffic they are not interested in (advantage). Yet another mailing list, where we need to get people that are interested subscribed while most Fedora Contrbutors are already subscribed to fedora-devel (disadvantage). Opinions? CU thl From wtogami at redhat.com Tue Feb 27 18:17:50 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 27 Feb 2007 13:17:50 -0500 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <45E475BB.1080806@leemhuis.info> References: <45E475BB.1080806@leemhuis.info> Message-ID: <45E475CE.9090301@redhat.com> Thorsten Leemhuis wrote: > Hi, > > as some of you know, I'd prefer to have a separate mailing list for > discussions around EPEL. I didn't bring that topic up much until now, > but two people in private mails heavily insisted to have a special EPEL > mailing list. So I'm trying to move this discussion here. > > Do you guys want a separate mailing list for EPEL? > > The usual advantages and disadvantages apply. Maily: Users that are only > interested in EPEL don't have to subscribe to a mailinglist that has 95% > of traffic they are not interested in (advantage). Yet another mailing > list, where we need to get people that are interested subscribed while > most Fedora Contrbutors are already subscribed to fedora-devel > (disadvantage). > > Opinions? > > CU > thl > I've already requested epel-devel-list to be created. You folks can decide whether you want to use it or not. Warren From smooge at gmail.com Tue Feb 27 18:18:25 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 27 Feb 2007 11:18:25 -0700 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <45E475BB.1080806@leemhuis.info> References: <45E475BB.1080806@leemhuis.info> Message-ID: <80d7e4090702271018t17679933qb30c918a7e3b2c6a@mail.gmail.com> On 2/27/07, Thorsten Leemhuis wrote: > Hi, > > as some of you know, I'd prefer to have a separate mailing list for > discussions around EPEL. I didn't bring that topic up much until now, > but two people in private mails heavily insisted to have a special EPEL > mailing list. So I'm trying to move this discussion here. > > Do you guys want a separate mailing list for EPEL? > > The usual advantages and disadvantages apply. Maily: Users that are only > interested in EPEL don't have to subscribe to a mailinglist that has 95% > of traffic they are not interested in (advantage). Yet another mailing > list, where we need to get people that are interested subscribed while > most Fedora Contrbutors are already subscribed to fedora-devel > (disadvantage). > To be honest I see EPEL as being a seperate project from main Fedora Development. It has different schedules and needs and a lot of that will be 90degrees from FD. > Opinions? > > CU > thl > > -- > 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 How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jkeating at redhat.com Tue Feb 27 18:24:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Feb 2007 13:24:50 -0500 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> Message-ID: <1172600690.23221.9.camel@localhost.localdomain> On Tue, 2007-02-27 at 13:23 +0100, Florian La Roche wrote: > This is a check where we do an "everything"-install and rebuild > all packages. All newly built packages are compared against currently > existing packages. Newly picked up deps can be due to newer libs > or also point at missing BuildRequires. Missing build deps could also > point at regressions compared to pre-mock buildroots which are as > small > as possible. > > Many such cases have already been cleaned up in the past, so the > list isn't too long anymore. > Is rpmdiff available for public user somewhere? -- Jesse Keating Release Engineer: Fedora -------------- 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 jwboyer at jdub.homelinux.org Tue Feb 27 18:25:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Feb 2007 12:25:24 -0600 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <45E475BB.1080806@leemhuis.info> References: <45E475BB.1080806@leemhuis.info> Message-ID: <1172600724.3885.4.camel@zod.rchland.ibm.com> On Tue, 2007-02-27 at 19:17 +0100, Thorsten Leemhuis wrote: > Hi, > > as some of you know, I'd prefer to have a separate mailing list for > discussions around EPEL. I didn't bring that topic up much until now, > but two people in private mails heavily insisted to have a special EPEL > mailing list. So I'm trying to move this discussion here. I'd be interested in the reasons why people are heavily insisting, but personally I don't care either way. josh From paul at city-fan.org Tue Feb 27 18:28:49 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 27 Feb 2007 18:28:49 +0000 Subject: [karsten@redhat.com: rpmdiff Resultate] In-Reply-To: <1172600690.23221.9.camel@localhost.localdomain> References: <20070227122312.GA5044@dudweiler.stuttgart.redhat.com> <1172600690.23221.9.camel@localhost.localdomain> Message-ID: <45E47861.5040805@city-fan.org> Jesse Keating wrote: > On Tue, 2007-02-27 at 13:23 +0100, Florian La Roche wrote: >> This is a check where we do an "everything"-install and rebuild >> all packages. All newly built packages are compared against currently >> existing packages. Newly picked up deps can be due to newer libs >> or also point at missing BuildRequires. Missing build deps could also >> point at regressions compared to pre-mock buildroots which are as >> small >> as possible. >> >> Many such cases have already been cleaned up in the past, so the >> list isn't too long anymore. >> > > Is rpmdiff available for public user somewhere? rpmdiff is included in the rpmlint package. Or are you asking something else? Paul. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 18:34:58 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 19:34:58 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <45E475BB.1080806@leemhuis.info> References: <45E475BB.1080806@leemhuis.info> Message-ID: <20070227193458.10c8afe7@python3.es.egwn.lan> Thorsten Leemhuis wrote : > Do you guys want a separate mailing list for EPEL? I do. New fedora development features don't have much to do with rebuilding packages for Red Hat Enterprise Linux... Mathias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.18 1.17 1.09 From stiffler.to at gmail.com Tue Feb 27 18:51:17 2007 From: stiffler.to at gmail.com (Artur Bartek) Date: Tue, 27 Feb 2007 19:51:17 +0100 Subject: (no subject) Message-ID: <4104a9490702271051h4077d57ej8eaca673d2b8878@mail.gmail.com> Hello, lately I found nice stuff http://www.gnomefiles.org/app.php/Mac_Menubar_for_GNOME_and_Xfce , but I can't compile gtk2 with patch need for macmenu and I can't compile macmenu too;/ I think it's very good thing for the people who migrate from macosx to fedora ;] Maybe somebody will make a two little packages for fedora community ?:> Have a nice day! Stiffler -------------- next part -------------- An HTML attachment was scrubbed... URL: From stiffler.to at gmail.com Tue Feb 27 18:53:35 2007 From: stiffler.to at gmail.com (Artur Bartek) Date: Tue, 27 Feb 2007 19:53:35 +0100 Subject: (no subject) In-Reply-To: <4104a9490702271051h4077d57ej8eaca673d2b8878@mail.gmail.com> References: <4104a9490702271051h4077d57ej8eaca673d2b8878@mail.gmail.com> Message-ID: <4104a9490702271053v12584e34hd2f1c51e8ff09926@mail.gmail.com> sorry for "no subject" ;/ I first wrote on the mailing list, I'm so stressed ;] 2007/2/27, Artur Bartek : > > Hello, > lately I found nice stuff > http://www.gnomefiles.org/app.php/Mac_Menubar_for_GNOME_and_Xfce , but I > can't compile gtk2 with patch need for macmenu and I can't compile macmenu > too;/ I think it's very good thing for the people who migrate from macosx to > fedora ;] Maybe somebody will make a two little packages for fedora > community ?:> > > Have a nice day! > Stiffler > > -- > 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 frank at scirocco-5v-turbo.de Tue Feb 27 19:12:42 2007 From: frank at scirocco-5v-turbo.de (Frank Arnold) Date: Tue, 27 Feb 2007 20:12:42 +0100 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <564d96fb0702270638g444fef74r1d0de7fce7ba2e5e@mail.gmail.com> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> <1172521264.7161.21.camel@dipsy> <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> <1172562512.7161.50.camel@dipsy> <564d96fb0702270638g444fef74r1d0de7fce7ba2e5e@mail.gmail.com> Message-ID: <1172603563.7161.89.camel@dipsy> Am Dienstag, den 27.02.2007, 06:38 -0800 schrieb Rafael Esp?ndola: > I think that you have found the problem. I have a Geiser IV ISO > (according to AppleUSBTrackpad.kext). The appletouch driver supports > up to Geiser III only. Support for Geyser IV was added around mid November. Your product ID should be 0x021B, according to appletouch.c. Then I must say sorry. I should have read the Gentoo page entirely. There's indeed the problem that usbhid starts the device in legacy mouse mode, and appletouch can't claim the device afterwards. So usbhid should be prevented to handle these devices. But we can stop here. This problem is known: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208721 Further discussion should go there... or not, because it's simply waiting for _someone_ to work that out ;) Frank From dyek at real.com Tue Feb 27 19:15:22 2007 From: dyek at real.com (Daniel Yek) Date: Tue, 27 Feb 2007 11:15:22 -0800 Subject: Is there a String Resource equivalent in RPM? Message-ID: <6.2.1.2.2.20070227110450.059ac750@mailone.real.com> Hi, Is there a String Resource or equivalence in RPM package that one can edit using Hex Editor and have the package still valid without another rebuild? It can be text or binary, but it needs to be uncompressed, and not affecting RPM package checksum. It would be best if #postinst script can easily query the value of the String Resource. I guess a less-optimal compromise is to repackage the RPM only, without rebuild the binary tar ball, so that files can be modified or added before repackaging. What is the least effort, best practice? Thanks in advance for any information. -- Daniel Yek From dennis at ausil.us Tue Feb 27 19:15:32 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 27 Feb 2007 13:15:32 -0600 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <45E475BB.1080806@leemhuis.info> References: <45E475BB.1080806@leemhuis.info> Message-ID: <200702271315.33911.dennis@ausil.us> On Tuesday 27 February 2007 12:17:31 pm Thorsten Leemhuis wrote: > Hi, > > as some of you know, I'd prefer to have a separate mailing list for > discussions around EPEL. I didn't bring that topic up much until now, > but two people in private mails heavily insisted to have a special EPEL > mailing list. So I'm trying to move this discussion here. > > Do you guys want a separate mailing list for EPEL? > > The usual advantages and disadvantages apply. Maily: Users that are only > interested in EPEL don't have to subscribe to a mailinglist that has 95% > of traffic they are not interested in (advantage). Yet another mailing > list, where we need to get people that are interested subscribed while > most Fedora Contrbutors are already subscribed to fedora-devel > (disadvantage). > OK its setup now https://www.redhat.com/mailman/listinfo/epel-devel-list everyone interested please subscribe and we will take the discussion there. -- Dennis Gilmore, RHCE From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 19:23:12 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 20:23:12 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <200702271315.33911.dennis@ausil.us> References: <45E475BB.1080806@leemhuis.info> <200702271315.33911.dennis@ausil.us> Message-ID: <20070227202312.67b7713e@python3.es.egwn.lan> Dennis Gilmore wrote : > On Tuesday 27 February 2007 12:17:31 pm Thorsten Leemhuis wrote: > > Hi, > > > > as some of you know, I'd prefer to have a separate mailing list for > > discussions around EPEL. I didn't bring that topic up much until now, > > but two people in private mails heavily insisted to have a special EPEL > > mailing list. So I'm trying to move this discussion here. > > > > Do you guys want a separate mailing list for EPEL? > > > > The usual advantages and disadvantages apply. Maily: Users that are only > > interested in EPEL don't have to subscribe to a mailinglist that has 95% > > of traffic they are not interested in (advantage). Yet another mailing > > list, where we need to get people that are interested subscribed while > > most Fedora Contrbutors are already subscribed to fedora-devel > > (disadvantage). > > > OK its setup now > https://www.redhat.com/mailman/listinfo/epel-devel-list > > everyone interested please subscribe and we will take the discussion there. "The current archive is only available to the list members." I suppose this is just what it defaulted to. Can we open it up? Matthias, now subscribed -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.37 1.41 1.15 From dennis at ausil.us Tue Feb 27 19:24:43 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 27 Feb 2007 13:24:43 -0600 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <20070227202312.67b7713e@python3.es.egwn.lan> References: <45E475BB.1080806@leemhuis.info> <200702271315.33911.dennis@ausil.us> <20070227202312.67b7713e@python3.es.egwn.lan> Message-ID: <200702271324.43727.dennis@ausil.us> On Tuesday 27 February 2007 01:23:12 pm Matthias Saou wrote: > Dennis Gilmore wrote : > > OK its setup now > > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > > everyone interested please subscribe and we will take the discussion > > there. > > "The current archive is only available to the list members." > > I suppose this is just what it defaulted to. Can we open it up? > > Matthias, now subscribed > it was im still learning how to setup and look after a mailling list. its now open. -- Dennis Gilmore, RHCE From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 19:32:39 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 20:32:39 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <200702271324.43727.dennis@ausil.us> References: <45E475BB.1080806@leemhuis.info> <200702271315.33911.dennis@ausil.us> <20070227202312.67b7713e@python3.es.egwn.lan> <200702271324.43727.dennis@ausil.us> Message-ID: <20070227203239.685325a9@python3.es.egwn.lan> Dennis Gilmore wrote : > > "The current archive is only available to the list members." > > > > I suppose this is just what it defaulted to. Can we open it up? > > > > Matthias, now subscribed > > > it was im still learning how to setup and look after a mailling list. its > now open. Thanks. You might want to correct the current summary, too :-) "EPEL development disccusion" Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.59 1.04 1.10 From hughsient at gmail.com Tue Feb 27 19:46:34 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Feb 2007 19:46:34 +0000 Subject: d80211 and iwlwifi In-Reply-To: <20070227124540.482d1f52@python3.es.egwn.lan> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> <1172469250.3142.2.camel@bureau.maison> <1172493685.3061.4.camel@localhost.localdomain> <20070226195109.GC1990@redhat.com> <1172526475.2728.6.camel@localhost.localdomain> <20070227124540.482d1f52@python3.es.egwn.lan> Message-ID: <1172605594.2688.9.camel@localhost.localdomain> On Tue, 2007-02-27 at 12:45 +0100, Matthias Saou wrote: > If you need the firmware for that new ipw3945 driver, it's waiting for > a review over here : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230096 > (which is basically waiting for a final agreement on firmware name > space) Is there a plan to include the iwlwifi driver in the fedora kernel? It's little point having the firmware without the driver IMO. Richard From hughsient at gmail.com Tue Feb 27 19:49:07 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Feb 2007 19:49:07 +0000 Subject: XOrg weirdness Message-ID: <1172605747.2688.14.camel@localhost.localdomain> Rawhide is working great recently, with one exception: gnome-terminal seems to make the xorg process use 100% of the CPU for a 2-3 seconds when scrolling text such as dmesg. Does not happen with xterm, but I was wondering if anyone else had noticed anything like this? I'm not sure what component to file this for in bugzilla, or how to debug this. Thanks, Richard. From katzj at redhat.com Tue Feb 27 19:50:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 27 Feb 2007 14:50:22 -0500 Subject: d80211 and iwlwifi In-Reply-To: <1172605594.2688.9.camel@localhost.localdomain> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <1172355520.19751.3.camel@bureau.maison> <20070225023527.GA8693@redhat.com> <1172469250.3142.2.camel@bureau.maison> <1172493685.3061.4.camel@localhost.localdomain> <20070226195109.GC1990@redhat.com> <1172526475.2728.6.camel@localhost.localdomain> <20070227124540.482d1f52@python3.es.egwn.lan> <1172605594.2688.9.camel@localhost.localdomain> Message-ID: <1172605822.18590.21.camel@erebor.boston.redhat.com> On Tue, 2007-02-27 at 19:46 +0000, Richard Hughes wrote: > On Tue, 2007-02-27 at 12:45 +0100, Matthias Saou wrote: > > If you need the firmware for that new ipw3945 driver, it's waiting for > > a review over here : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230096 > > (which is basically waiting for a final agreement on firmware name > > space) > > Is there a plan to include the iwlwifi driver in the fedora kernel? It's > little point having the firmware without the driver IMO. When Intel submits iwlwifi for the wireless-dev tree, then we'll get the driver for Fedora. And note that the firmware won't be included without the driver as one of the requirements for the redistributable firmware exception is that it must enable open code which is already shipped to be able to fully work. Jeremy From drago01 at gmail.com Tue Feb 27 19:51:49 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 27 Feb 2007 20:51:49 +0100 Subject: FC6 updates broken deps? In-Reply-To: <1172517334.26721.12.camel@cutter> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> <45E2FDEF.4020702@gmail.com> <45E330C7.8060705@andrei.myip.org> <1172517334.26721.12.camel@cutter> Message-ID: <45E48BD5.20808@gmail.com> seth vidal wrote: > On Mon, 2007-02-26 at 11:11 -0800, Florin Andrei wrote: > >> dragoran wrote: >> >> >>> because this way its nothing but a hack that does not solve the main >>> problem: >>> yum should _NOT_ fail to update a package because a unreleated package >>> has a dep problem. >>> >> Let me re-phrase it: >> >> The light in the kitchen should not fail to function because a bulb in >> the basement is broken. >> > > to extend the analogy: > if the bulb in the basement being out means there could well be a > murderer down there, then maybe the door to the house shouldn't open at > all. :) > > > I still don't get this.. do you really think that having no updates is better than having all non broken updates? sorry but this does not make any sense to me... lets say there is a security hole in httpd -> update released there is a bugfix (non security update) for a game but with a broken dep (can happen...) -> this blocks the whole update process... so its better in your opinion to let the system vunerable to attacks only because a unrelated package has a broken dep? even if package 2 was a security update too there is no reason to block 1 because this one has broken deps .. sure there is a problem when suchs things happen but why let our users systems with unpatched security holes even when the fix is released? From ajackson at redhat.com Tue Feb 27 19:52:30 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 27 Feb 2007 14:52:30 -0500 Subject: XOrg weirdness In-Reply-To: <1172605747.2688.14.camel@localhost.localdomain> References: <1172605747.2688.14.camel@localhost.localdomain> Message-ID: <1172605950.22136.18.camel@localhost.localdomain> On Tue, 2007-02-27 at 19:49 +0000, Richard Hughes wrote: > Rawhide is working great recently, with one exception: > > gnome-terminal seems to make the xorg process use 100% of the CPU for a > 2-3 seconds when scrolling text such as dmesg. Does not happen with > xterm, but I was wondering if anyone else had noticed anything like > this? I'm not sure what component to file this for in bugzilla, or how > to debug this. Well it's at least partly Xorg's fault, but it would be helpful to know what the slow path is there; so if you do file a bug against Xorg, please accompany it with oprofile goodness. - ajax From opensource at till.name Tue Feb 27 21:23:52 2007 From: opensource at till.name (Till Maas) Date: Tue, 27 Feb 2007 22:23:52 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <45E475CE.9090301@redhat.com> References: <45E475BB.1080806@leemhuis.info> <45E475CE.9090301@redhat.com> Message-ID: <200702272224.01015.opensource@till.name> On Dienstag 27 Februar 2007, Warren Togami wrote: > I've already requested epel-devel-list to be created. You folks can > decide whether you want to use it or not. Iirc there was a proposal to drop the -list suffix for new lists. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue Feb 27 16:43:39 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 27 Feb 2007 17:43:39 +0100 Subject: KDE-Live-Spin Message-ID: <20070227174339.50469e76@localhost.localdomain> Hi. I don't know if somebody is working on this but I've created a live cd with KDE for fc6-i386 with the livecd-tools. So far it seems to work quite fine. The livecd-files based on the ones from David Zeuthen [1]. I've just created a config for a kde live spin which requires livecd-base-package. What I have done: - created 20-fedora-livecd-kde.conf - removed most gnome packages and gnome settings - included kde packages [2] (just to fill the cd) - not included gdm to start kdm automatically - inserted "startkde" in /home/fedora/.xsession - made autologin for user "fedora" work with kdm - also set user "fedora" as default and recent user (if somebody logs out of kde) - replaced redhat-web.desktop and redhat-email.desktop with "konqueror --profile webbrowsing" and kmail in kicker (firefox and evolution are not included) The size of the cd is actually ~570 MB. The files to create the live cd could be found here: http://www.deadbabylon.de/fedora/livecd/ Perhaps this could be a start for someone (eg. the KDE-SIG?). Sebastian [1] http://people.redhat.com/davidz/livecd/i386/ [2] http://www.deadbabylon.de/fedora/livecd/20-fedora-livecd-kde.conf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rafael.espindola at gmail.com Tue Feb 27 21:50:04 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Tue, 27 Feb 2007 13:50:04 -0800 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <1172603563.7161.89.camel@dipsy> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> <1172521264.7161.21.camel@dipsy> <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> <1172562512.7161.50.camel@dipsy> <564d96fb0702270638g444fef74r1d0de7fce7ba2e5e@mail.gmail.com> <1172603563.7161.89.camel@dipsy> Message-ID: <564d96fb0702271350q206d4188vd04a6dbab0960e0e@mail.gmail.com> > Support for Geyser IV was added around mid November. Your product ID > should be 0x021B, according to appletouch.c. I am downloading linus git tree and I will try to port the patch to the fedora 2.6.20 kernel. > Then I must say sorry. I should have read the Gentoo page entirely. > There's indeed the problem that usbhid starts the device in legacy mouse > mode, and appletouch can't claim the device afterwards. So usbhid should > be prevented to handle these devices. > > But we can stop here. This problem is known: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208721 > > Further discussion should go there... or not, because it's simply > waiting for _someone_ to work that out ;) I will post the patch in there. > Frank Thanks, Rafael From hughsient at gmail.com Tue Feb 27 21:59:07 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Feb 2007 21:59:07 +0000 Subject: XOrg weirdness In-Reply-To: <1172605950.22136.18.camel@localhost.localdomain> References: <1172605747.2688.14.camel@localhost.localdomain> <1172605950.22136.18.camel@localhost.localdomain> Message-ID: <1172613547.2699.2.camel@localhost.localdomain> On Tue, 2007-02-27 at 14:52 -0500, Adam Jackson wrote: > > > Well it's at least partly Xorg's fault, but it would be helpful to > know > what the slow path is there; so if you do file a bug against Xorg, > please accompany it with oprofile goodness. Well, I get this: CPU: Core Solo / Duo, speed 1662.57 MHz (estimated) Counted CPU_CLK_UNHALTED events (Unhalted clock cycles) with a unit mask of 0x00 (Unhalted core cycles) count 860000 CPU_CLK_UNHALT...| samples| %| ------------------ 12704 82.6330 /usr/bin/Xorg CPU_CLK_UNHALT...| samples| %| ------------------ 12066 94.9780 /usr/lib/xorg/modules/libfb.so 286 2.2513 /usr/bin/Xorg 216 1.7003 /usr/lib/xorg/modules/drivers/nv_drv.so 75 0.5904 /lib/libc-2.5.90.so 48 0.3778 /usr/lib/xorg/modules/libxaa.so 6 0.0472 /usr/lib/xorg/modules/extensions/libextmod.so 3 0.0236 /lib/librt-2.5.90.so 1 0.0079 /usr/lib/libXfont.so.1.4.1 1 0.0079 /usr/lib/xorg/modules/input/mouse_drv.so 1 0.0079 /usr/lib/xorg/modules/input/synaptics_drv.so 1 0.0079 /usr/lib/xorg/modules/libramdac.so But also I get this (!!!): oprofile: using NMI interrupt. ================================= [ INFO: inconsistent lock state ] 2.6.20-1.2949.fc7 #1 --------------------------------- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes: (oprofilefs_lock){+-..}, at: [] nmi_cpu_setup+0x15/0x4f [oprofile] {hardirq-on-W} state was registered at: [] __lock_acquire+0x448/0xba4 [] lock_acquire+0x56/0x6f [] _spin_lock+0x2b/0x38 [] oprofilefs_ulong_from_user+0x4e/0x74 [oprofile] [] ulong_write_file+0x2a/0x38 [oprofile] [] vfs_write+0xaf/0x163 [] sys_write+0x3d/0x61 [] syscall_call+0x7/0xb [] 0xffffffff irq event stamp: 23424902 hardirqs last enabled at (23424901): [] _spin_unlock_irqrestore+0x36/0x3c hardirqs last disabled at (23424902): [] call_function_interrupt+0x29/0x38 softirqs last enabled at (23424892): [] __do_softirq +0xdc/0xe2 softirqs last disabled at (23424885): [] do_softirq+0x61/0xd0 other info that might help us debug this: no locks held by swapper/0. stack backtrace: [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] print_usage_bug+0x141/0x14b [] mark_lock+0xa2/0x419 [] __lock_acquire+0x3b9/0xba4 [] lock_acquire+0x56/0x6f [] _spin_lock+0x2b/0x38 [] nmi_cpu_setup+0x15/0x4f [oprofile] [] smp_call_function_interrupt+0x3f/0x5b [] call_function_interrupt+0x33/0x38 [] _spin_unlock+0x16/0x20 [] clockevents_notify+0x3e/0x42 [] acpi_state_timer_broadcast+0x2e/0x31 [] acpi_processor_idle+0x285/0x419 [] cpu_idle+0xb7/0xdd [] start_secondary+0x330/0x338 [<00000000>] 0x0 ======================= Why do the simplest bugs always turn into the most complicated ones ;-) Richard. From che666 at gmail.com Tue Feb 27 22:17:56 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 27 Feb 2007 23:17:56 +0100 Subject: [Mandrakeot] ESR gives up on Fedora In-Reply-To: <1172189014.3743.154.camel@localhost.localdomain> References: <200702221656.09198.kaj@haulrich.net> <200702222019.25290.kaj@haulrich.net> <200702221527.20947.tbrinkman@sbcglobal.net> <200702222256.20754.kaj@haulrich.net> <1172189014.3743.154.camel@localhost.localdomain> Message-ID: 2007/2/23, Lyvim Xaphir : > On Thu, 2007-02-22 at 22:56 +0100, Kaj Haulrich wrote: > > > Due to my lousy English - "Danglish" - I referred to the (K)ubuntu > > install, not FC6 (Where I actually lurked on the ML some months > > before installing it so I avoided the LVM and SELinux stuff). The > > default (K)ubuntu install is open source only, if someone want the > > proprietary stuff further repos must be enabled, just like FC. > > > > Mark Shuttleworth has some remarks on non-free drivers here : > > > > http://www.markshuttleworth.com/archives/95 > > > > I was a bit surprised when the (K)ubuntu installed an ATI driver all > > by itself, but it seems that the driver (UTAH) is open source as > > well. > > > > Kaj. > > > > There needs to be a balance between the right of individuals to own > their own property (specifically in our realm of discussion, > intellectual property) and the right of individuals to control the > source to the operating system they run. Currently the trend with the > Cox's of the world is to abolish the rights of companies and individuals > to protect their own intellectual property rights; at any cost. The > plain simple definition of socialism is the abolition of personal > property to another jurisdiction other than the true owner of that > personal property; be that a dictator or a government, or a group of > socio-fascist developers. In this case, the developers seek to take the > decision about intellectual property rights OUT of the public domain > (the "Market") and to FORCIBLY TAKE AWAY the right of the company or > individual to license driver-code the way the code authors see fit. > This is not "freedom", it is in reality a form of slavery. > > The way they seek to accomplish this is by writing the kernel so that > it will reject any module that it (the kernel) perceives as NOT open > source. This is not a technical task, it is an ideological task. The > problem I have and that I have always had is that ideological decisions > are the domain of the USER, NOT THE KERNEL. Furthermore, and more to > the point, ideological decisions are the purview of the USER and NOT THE > DEVELOPERS. The kernel is and has always been a product of technical > merit (which was freely given, as opposed to forcibly taken); the > ideologues in the developer community seek to slave the kernel itself to > their own personal ideological goals. > > THAT is where the line is being crossed; THAT is the abhorrent > corruption we are faced with. The developers have no rights to other > people's intellectual property rights or software licensing decisions, > OR the JURISDICTION THEREOF; yet in face of that fact they seek to > forcibly TAKE or CONTROL what is not theirs by *force*. How? Because > since they control the kernel, they essentially have monopoly power over > the Linux operating system. They are currently abusing that leverage to > execute forced licensing upon any developer that writes driver code. No > longer is the programmer the arbiter of the license of his own work. The > use of such a monopoly power for ideological ends is force and is > therefore by definition fascism. Fascism is nothing less than an > advanced aspect of socialism; the same is true of communism. Both > fascism and communism are *consequences* of socialism. In the linux > world today we are now seeing both consequences manifest themselves in > the religious fanatic RMS sectors of the community. > > The ONLY thing that has stopped this process.....and I do mean the > ONLY thing, is Linus Torvalds. He has made it clear that the Linux > kernel will NOT be turned into an ideological tool (but even as he has > made this clear, the offending messages remain entrenched in the kernel > right now as we speak, running prospective developers away and causing > many developers to question the domain of Linux as being anything near > fruitful). For this he has suffered much criticism and hate mail. In > the same regard, ESR has suffered much criticism and hate mail. This is > the modern rendition of the medieval persecution of the Jews by the > Flagellants during the Black Plague. We have the religious fanatics, > and we have the innocent heros, deprived of justice. The only difference > is that instead of maniacal religious zealots beating themselves with > chains and murdering Jews, we have the present day maniacal religious > Stallman nose pickers, and instead of the Jews we have Torvalds, ESR, > and those of us with sufficient testosterone to support their cause. > > > > > > LX > -- > > ??????????????????????????????????????????????????? > A Kernel Of Socialism > > greatunwashed: module license 'great_unwashed' taints kernel. > ich: no version for "unwashed_register_device" found: kernel tainted. > Symbol usb_register_driver is being used by a non-GPL module, > which will not be allowed in the future > Please see the file Documentation/feature-removal-schedule.txt > in the kernel source tree for more details. > ??????????????????????????????????????????????????? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > you didnt realize yet i guess that your signature turns the whole thing into a cold war instead of discussing the real issues behind some of the decisions which are also technical. why would a distro ship something to users it cant support because theres no sourcecode available to fix the pending issues? are you going to convince the nvidia developers to make their drivers work e.g. with accelerated framebuffer drivers? i have reported the issue years ago and as it usually is with nonfree/proprietary software it didnt get fixed. just a reallife example and well from what i read its that _you_ have political issues for some of your opinions... best luck with your next try of finding some valid arguments instead of trying to convince us all that binary drivers are a great thing. if its so great just use it and respect the opinions of others that they dont want them or dont want to have to support them. will you support people with issues on tainted kernels? have you made any efforts in fixing the current pending "wontfix" issues? if no... hot air to me. regards, Rudolf Kastl From rdieter at math.unl.edu Tue Feb 27 23:08:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Feb 2007 17:08:56 -0600 Subject: KDE-Live-Spin In-Reply-To: <20070227174339.50469e76@localhost.localdomain> References: <20070227174339.50469e76@localhost.localdomain> Message-ID: Sebastian Vahl wrote: > I don't know if somebody is working on this but I've created a live cd > with KDE for fc6-i386 with the livecd-tools. So far it seems to work > quite fine. > > The livecd-files based on the ones from David Zeuthen [1]. I've just > created a config for a kde live spin which requires livecd-base-package. ... > The files to create the live cd could be found here: > http://www.deadbabylon.de/fedora/livecd/ > > > Perhaps this could be a start for someone (eg. the KDE-SIG?). > [1] http://people.redhat.com/davidz/livecd/i386/ > [2] http://www.deadbabylon.de/fedora/livecd/20-fedora-livecd-kde.conf Good work, would you be interested in joining the KDE-SIG to move this along? I ask because our current focus is on producing a KDE spin, and for lack of someone to step up to drive the effort for a kde livecd, the odds of completing it are less. -- Rex From ajackson at redhat.com Tue Feb 27 22:42:51 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 27 Feb 2007 17:42:51 -0500 Subject: XOrg weirdness In-Reply-To: <1172613547.2699.2.camel@localhost.localdomain> References: <1172605747.2688.14.camel@localhost.localdomain> <1172605950.22136.18.camel@localhost.localdomain> <1172613547.2699.2.camel@localhost.localdomain> Message-ID: <1172616171.22136.25.camel@localhost.localdomain> On Tue, 2007-02-27 at 21:59 +0000, Richard Hughes wrote: > Well, I get this: > > CPU: Core Solo / Duo, speed 1662.57 MHz (estimated) > Counted CPU_CLK_UNHALTED events (Unhalted clock cycles) with a unit mask > of 0x00 (Unhalted core cycles) count 860000 > CPU_CLK_UNHALT...| > samples| %| > ------------------ > 12704 82.6330 /usr/bin/Xorg > CPU_CLK_UNHALT...| > samples| %| > ------------------ > 12066 94.9780 /usr/lib/xorg/modules/libfb.so That's pretty well expected. If anything's going to be burning CPU time it's either fb or GLcore. (Or the driver itself when it sits in infinite loops waiting for the command queue to catch up, but that case usually means wedged hardware.) More interesting is knowing which functions it's hitting, if you can get that. Would also like to know whether the same slowdown happens when using Option "ShadowFB". If not then we can assume the slowdown is being caused by a software fallback to something that happens to be in card memory, and there might be a reasonable heuristic for evicting things from card memory when that happens, or just a smarter way to write that routine that hits the bus less. But if it's still slow when shadowfb'd then either it's some particularly naive code, or g-t is just asking us to do a lot of really painful things. > But also I get this (!!!): > > oprofile: using NMI interrupt. > > ================================= > [ INFO: inconsistent lock state ] > 2.6.20-1.2949.fc7 #1 Yow! - ajax From hughsient at gmail.com Tue Feb 27 23:07:34 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Feb 2007 23:07:34 +0000 Subject: XOrg weirdness In-Reply-To: <1172616171.22136.25.camel@localhost.localdomain> References: <1172605747.2688.14.camel@localhost.localdomain> <1172605950.22136.18.camel@localhost.localdomain> <1172613547.2699.2.camel@localhost.localdomain> <1172616171.22136.25.camel@localhost.localdomain> Message-ID: <1172617654.2846.2.camel@localhost.localdomain> On Tue, 2007-02-27 at 17:42 -0500, Adam Jackson wrote: > Would also like to know whether the same slowdown happens when using > Option "ShadowFB". Using this option returns the console output to blindingly fast. Do you want me to file this in bugzilla, or continue to debug this with OProfile? Thanks for your help with this. Richard. From ajackson at redhat.com Tue Feb 27 23:11:14 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 27 Feb 2007 18:11:14 -0500 Subject: XOrg weirdness In-Reply-To: <1172617654.2846.2.camel@localhost.localdomain> References: <1172605747.2688.14.camel@localhost.localdomain> <1172605950.22136.18.camel@localhost.localdomain> <1172613547.2699.2.camel@localhost.localdomain> <1172616171.22136.25.camel@localhost.localdomain> <1172617654.2846.2.camel@localhost.localdomain> Message-ID: <1172617874.22136.55.camel@localhost.localdomain> On Tue, 2007-02-27 at 23:07 +0000, Richard Hughes wrote: > On Tue, 2007-02-27 at 17:42 -0500, Adam Jackson wrote: > > Would also like to know whether the same slowdown happens when using > > Option "ShadowFB". > > Using this option returns the console output to blindingly fast. > > Do you want me to file this in bugzilla, or continue to debug this with > OProfile? Still would like some oprofile with symbol names for the non-shadowfb case (although I have a reasonable idea), but yes, bz would be excellent. Re reasonable idea: Software alpha-blending of text just sucks. In principle g-t is double-buffered, so the composition should be something like CA blend to the backing pixmap followed by blit to the front buffer, and therefore the backing pixmap could come out of card memory, which would turn the blit into hostdata upload, which isn't _that_ painful. You could even damage-track the blending if you wanted, although that might not be a win. Plus if you start evicting everything you do text blends to, you might not have a lot left in card memory. Tough to say. Also it's not clear whether this is just latent sucking, or something introduced between FC6 and now. Swapping out the X server to test might be an idea, it should be reasonably independent. - ajax From dwmw2 at infradead.org Tue Feb 27 23:29:21 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 27 Feb 2007 18:29:21 -0500 Subject: Is there a String Resource equivalent in RPM? In-Reply-To: <6.2.1.2.2.20070227110450.059ac750@mailone.real.com> References: <6.2.1.2.2.20070227110450.059ac750@mailone.real.com> Message-ID: <1172618962.4032.39.camel@shinybook.infradead.org> On Tue, 2007-02-27 at 11:15 -0800, Daniel Yek wrote: > I guess a less-optimal compromise is to repackage the RPM only, without > rebuild the binary tar ball, so that files can be modified or added before > repackaging. > > What is the least effort, best practice? If you want to _add_ files, it's best to ship them in a separate package. If you're thinking of separate codecs, for example, that's probably the best way to do it. Modifying files sounds wrong, unless it's just configuration stuff which could be done in %post. What exactly are you trying to do? -- dwmw2 From kwade at redhat.com Tue Feb 27 23:56:55 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 27 Feb 2007 15:56:55 -0800 Subject: [EPEL] EPEL -- the way forward In-Reply-To: <604aa7910702231503y2f99f1b9te6d463a1427462e5@mail.gmail.com> References: <45DC9246.6060307@leemhuis.info> <1172249263.4651.18.camel@erato.phig.org> <1172249472.24204.237.camel@zod.rchland.ibm.com> <1172270594.4651.38.camel@erato.phig.org> <604aa7910702231503y2f99f1b9te6d463a1427462e5@mail.gmail.com> Message-ID: <1172620615.4651.199.camel@erato.phig.org> On Fri, 2007-02-23 at 14:03 -0900, Jeff Spaleta wrote: > On 2/23/07, Karsten Wade wrote: > > The purpose of the job description is to make it easier for people who > > maintain packages to get at least some of the work "guaranteed" by their > > employer. Obviously it is not a guarantee or a contract to support the > > package. This is where the wording matters. It is just about extending > > the personal responsibility to the organization. For example, an > > individual can orphan a package for any reason, and their responsibility > > is just to announce the orphaning. The same should hold true for an > > organization. > > > Do you have buy-in or feedback from organizations at the > organizational level on this approach? From manager-like entities who > would be making this commitment on behalf of their organization or > company? I would think this is something that should be approached at the hiring manager level, that is, the level where the manager is directly involved in deciding/defining job descriptions. > Not to name names or anything..but after FudCon I was on the same > flight back with dgilmore, and we had a little chat about EPEL and the > contributor landscape for it. It was obvious to both of us that IT > people in smaller organizations would very much be interested > consumers of this material, but it wasn't clear that they would have > organizational support to maintain this material as part of their job. > I think some rather valid observations were made concerning the > possible reluctance of IT people in a corporate setting to be involved > in a maintainership role, exactly because it would appear to be an > additional worktime commitment, not supported by their organizations. If I read you correctly, you are bringing up the exact reasoning I had for putting together a generic job description people can use. My approach is a first stab; obviously many more of you are experienced with this. I may not get paid for my Fedora work, but I have an easier time justifying my time spent. :) What approach would you take? Is this the right one? Whatever approach this community recommends is probably exactly what I'll recommend to Red Hat to incorporate. To make it clear, I think it is the job of the EL distributor (Red Hat, or CentOS, or whoever) to help promote joining the EPEL community. To that end, my goal at Red Hat is to have a set of materials that "make sense" for ISVs, IHVs, and customers; then make sure those materials are in the hands of the marketing, support, and service organizations who have direct contact with the target audience. Any help in that direction is (likely) Good For All. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 david at fubar.dk Wed Feb 28 00:00:52 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 27 Feb 2007 19:00:52 -0500 Subject: XOrg weirdness In-Reply-To: <1172617874.22136.55.camel@localhost.localdomain> References: <1172605747.2688.14.camel@localhost.localdomain> <1172605950.22136.18.camel@localhost.localdomain> <1172613547.2699.2.camel@localhost.localdomain> <1172616171.22136.25.camel@localhost.localdomain> <1172617654.2846.2.camel@localhost.localdomain> <1172617874.22136.55.camel@localhost.localdomain> Message-ID: <1172620852.5097.191.camel@zelda.fubar.dk> On Tue, 2007-02-27 at 18:11 -0500, Adam Jackson wrote: > Also it's not clear whether this is just latent sucking, or something > introduced between FC6 and now. Swapping out the X server to test might > be an idea, it should be reasonably independent. I'm seeing this on Rawhide with X.org packages from FC6 (binary ATI crap for my Macbook Pro). It didn't use to be like this (and it's forcing me to use xterm - yuck!) so it points to something above X. David From hughsient at gmail.com Wed Feb 28 00:07:40 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Feb 2007 00:07:40 +0000 Subject: XOrg weirdness In-Reply-To: <1172620852.5097.191.camel@zelda.fubar.dk> References: <1172605747.2688.14.camel@localhost.localdomain> <1172605950.22136.18.camel@localhost.localdomain> <1172613547.2699.2.camel@localhost.localdomain> <1172616171.22136.25.camel@localhost.localdomain> <1172617654.2846.2.camel@localhost.localdomain> <1172617874.22136.55.camel@localhost.localdomain> <1172620852.5097.191.camel@zelda.fubar.dk> Message-ID: <1172621260.13643.2.camel@localhost.localdomain> On Tue, 2007-02-27 at 19:00 -0500, David Zeuthen wrote: > > I'm seeing this on Rawhide with X.org packages from FC6 (binary ATI > crap for my Macbook Pro). It didn't use to be like this (and it's > forcing me to use xterm - yuck!) so it points to something above X. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230294 Or for the mailing list; hughsie at localhost:~$ opreport -cl --demangle=smart `which Xorg` warning: /usr/bin/Xorg could not be read. CPU: Core Solo / Duo, speed 1662.68 MHz (estimated) Counted CPU_CLK_UNHALTED events (Unhalted clock cycles) with a unit mask of 0x00 (Unhalted core cycles) count 860000 samples % image name symbol name ------------------------------------------------------------------------------- 1582 88.2812 libfb.so fbCompositeSolidMask_nx8888x8888Cmmx 1582 100.000 libfb.so fbCompositeSolidMask_nx8888x8888Cmmx [self] ------------------------------------------------------------------------------- 136 7.5893 libfb.so fbCompositeSrcAdd_8888x8888mmx 136 100.000 libfb.so fbCompositeSrcAdd_8888x8888mmx [self] ------------------------------------------------------------------------------- 65 3.6272 nv_drv.so NVSync 65 100.000 nv_drv.so NVSync [self] ------------------------------------------------------------------------------- 5 0.2790 Xorg (no symbols) 5 100.000 Xorg (no symbols) [self] ------------------------------------------------------------------------------- 2 0.1116 libfb.so fbPolySegment32 2 100.000 libfb.so fbPolySegment32 [self] ------------------------------------------------------------------------------- 1 0.0558 libc-2.5.90.so free 1 100.000 libc-2.5.90.so free [self] ------------------------------------------------------------------------------- 1 0.0558 libfb.so fbSolidFillmmx 1 100.000 libfb.so fbSolidFillmmx [self] ------------------------------------------------------------------------------- It's interesting davidz is getting this too on different hardware. Richard. From florin at andrei.myip.org Wed Feb 28 00:53:40 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 27 Feb 2007 16:53:40 -0800 Subject: FC6 updates broken deps? In-Reply-To: <45E48BD5.20808@gmail.com> References: <20070221080350.3711A3C1AC6@snark.thyrsus.com> <200702211350.53468.jkeating@redhat.com> <20070221215950.b9c53030.mschwendt.tmp0701.nospam@arcor.de> <200702212050.21732.jkeating@redhat.com> <45DDD46D.6030109@andrei.myip.org> <45DF61D1.5030609@gmail.com> <1172297215.4322.62.camel@localhost.localdomain> <1172482678.3625.5.camel@gilboa-work-dev.localdomain> <45E2EFDB.30903@poolshark.org> <45E2F22A.7040302@poolshark.org> <1172501326.25220.16.camel@cutter> <45E2F5DF.3060100@poolshark.org> <1172502164.25220.18.camel@cutter> <45E2FDEF.4020702@gmail.com> <45E330C7.8060705@andrei.myip.org> <1172517334.26721.12.camel@cutter> <45E48BD5.20808@gmail.com> Message-ID: <45E4D294.6060107@andrei.myip.org> dragoran wrote: > I still don't get this.. do you really think that having no updates is > better than having all non broken updates? sorry but this does not make > any sense to me... Exactly. I have yet to see a rational argument that justifies the current update policy implemented by yum. All the replies just ignore this valid and important question. -- Florin Andrei http://florin.myip.org/ From kevin at scrye.com Wed Feb 28 00:50:15 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 27 Feb 2007 17:50:15 -0700 Subject: F7 Release Discussion (was Re: Slightly OT: bad rap for Fedora, and realistic effects) In-Reply-To: <20070226225225.4a2851ef.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> <20070225112133.4d3cb9af@ningauble.scrye.com> <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> <20070226112910.24fe83d4@ningauble.scrye.com> <20070226225225.4a2851ef.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070227175015.54917029@ningauble.scrye.com> On Mon, 26 Feb 2007 22:52:25 +0100 mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) wrote: > On Mon, 26 Feb 2007 11:29:10 -0700, Kevin Fenzi wrote: > > > > > > Now it's getting interesting. Being a sponsor has never before > > > > > implied that you have to fix orphans or take over packages > > > > > when a sponsored person leaves the project or is AWOL. With > > > > > such a requirement, the sponsorship system would be too > > > > > burdensome and too much of a risk. > > > > > > > > ok. So, who should handle those things? FESCo? > > > > No one? > > > > > > Quite obviously, those are not the only two options. And hence the > > > answer to the latter two questions is "no". > > > > Perhaps I wasn't being clear... > > > > What are your thoughts/opinions on how this should work? > > I would love to hear your input. > > Do you disagree? Do you think that if somebody leaves the project, the > sponsor is responsible for the orphaned packages? Perhaps I am not being clear on what I am proposing. Of course a sponsor shouldn't be required to start maintaining all the leaving maintainers packages. There's no way that would work. What I am saying is that they should be able to drive forward the AWOLmaintainer process for those packages, and do things like posting emails to the list saying "I sponsored maintainer foo, who is no longer around, the following packages are orphaned, does anyone want to take over them?". Is that more clear? > These tools are in "fedora" cvs. Sometimes the scripts are tweaked > for the buildsys installation environment and may need a few > modifications if used elsewhere. The upgradecheck.py script simply > takes an external config file with definitions of SRPMS repos. > Whether it would work to include the needsign repo, I don't know, > because the needsign repo is a multi-arch repo -- all archs including > SRPMS in a single repo. :) ok. I can take a look. Thanks for all your hard work on those scripts. :) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rafael.espindola at gmail.com Wed Feb 28 03:28:38 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Tue, 27 Feb 2007 19:28:38 -0800 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <564d96fb0702271350q206d4188vd04a6dbab0960e0e@mail.gmail.com> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> <1172521264.7161.21.camel@dipsy> <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> <1172562512.7161.50.camel@dipsy> <564d96fb0702270638g444fef74r1d0de7fce7ba2e5e@mail.gmail.com> <1172603563.7161.89.camel@dipsy> <564d96fb0702271350q206d4188vd04a6dbab0960e0e@mail.gmail.com> Message-ID: <564d96fb0702271928i5b0f36ccm937ab9f9a9fac017@mail.gmail.com> > I am downloading linus git tree and I will try to port the patch to > the fedora 2.6.20 kernel. It is on the 2.6.20 kernel already :-) rpmbuilding it right now Rafael From rodd at clarkson.id.au Wed Feb 28 03:34:20 2007 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 28 Feb 2007 14:34:20 +1100 Subject: rawhide report: 20070227 changes In-Reply-To: <45E430B1.1030702@bellsouth.net> References: <200702271148.l1RBm9Wr008298@hs20-bc2-6.build.redhat.com> <45E430B1.1030702@bellsouth.net> Message-ID: <1172633660.22602.4.camel@localhost.localdomain> On Tue, 2007-02-27 at 07:22 -0600, Jay Cliburn wrote: > buildsys at redhat.com wrote: > > > kernel-2.6.20-1.2949.fc7 > > ------------------------ > > * Mon Feb 26 2007 Dave Jones > > - Fix up radeonfb backlight. > > - Revert forcedeth changes so that it works again. > > There's a fix on the street for the forcedeth problem. > > http://lkml.org/lkml/2007/2/27/109 > > Jay Is this forcedeth issue the one causing problems with network cards connecting. I'm unable to use NetworkManager to connect, but if I stop NetworkManager and then ifdown/ifup my network card then it works fine. R. -- "It's a fine line between denial and faith. It's much better on my side" From lightsolphoenix at gmail.com Wed Feb 28 05:12:37 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 28 Feb 2007 00:12:37 -0500 Subject: KDE-Live-Spin In-Reply-To: References: <20070227174339.50469e76@localhost.localdomain> Message-ID: <200702280012.37970.lightsolphoenix@gmail.com> I'm a Fedora KDE user, and I'm willing to help out with the Fedora KDE spin if anything needs to be done. Just let me know. On Tuesday 27 February 2007 6:08:56 pm Rex Dieter wrote: > Sebastian Vahl wrote: > > I don't know if somebody is working on this but I've created a live cd > > with KDE for fc6-i386 with the livecd-tools. So far it seems to work > > quite fine. > > > > The livecd-files based on the ones from David Zeuthen [1]. I've just > > created a config for a kde live spin which requires livecd-base-package. > > ... > > > The files to create the live cd could be found here: > > http://www.deadbabylon.de/fedora/livecd/ > > > > > > Perhaps this could be a start for someone (eg. the KDE-SIG?). > > > > [1] http://people.redhat.com/davidz/livecd/i386/ > > [2] http://www.deadbabylon.de/fedora/livecd/20-fedora-livecd-kde.conf > > Good work, would you be interested in joining the KDE-SIG to move this > along? > > I ask because our current focus is on producing a KDE spin, and for lack > of someone to step up to drive the effort for a kde livecd, the odds of > completing it are less. > > -- Rex -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From panemade at gmail.com Wed Feb 28 05:46:23 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 28 Feb 2007 11:16:23 +0530 Subject: Core packages are using %config for files being installed under /usr Message-ID: Hi, While reviewing some fonts-* packages , I saw files being installed under /usr are marked as %config in their SPECS as shown below %config(noreplace) %verify(not md5 size mtime) %{ttfontdir}/fonts.alias %config(noreplace) %verify(not md5 size mtime) %{bmpfontdir}/fonts.alias some are even have %config(noreplace) %verify(not md5 size mtime) /usr/share/fonts/%{ISONAME}/100dpi/fonts.alias That made rpmlint to report following types of rpmlint messages on those packages E: fonts-ISO8859-2-100dpi file-in-usr-marked-as-conffile /usr/share/fonts/ISO8859-2/100dpi/fonts.alias A file in /usr is marked as being a configuration file. Store your conf files in /etc/ instead. Also i am reviewing hwdata(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225893 ) Core package and i even saw there %config /usr/share/hwdata/* and rpmlint is giving error. How to handle this issue? Regards, Parag. From fedora at leemhuis.info Wed Feb 28 06:27:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Feb 2007 07:27:42 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <200702272224.01015.opensource@till.name> References: <45E475BB.1080806@leemhuis.info> <45E475CE.9090301@redhat.com> <200702272224.01015.opensource@till.name> Message-ID: <45E520DE.6030907@leemhuis.info> On 27.02.2007 22:23, Till Maas wrote: > On Dienstag 27 Februar 2007, Warren Togami wrote: >> I've already requested epel-devel-list to be created. You folks can >> decide whether you want to use it or not. > Iirc there was a proposal to drop the -list suffix for new lists. I'm also wondering if the "devel" in the lists name was a good idea. That afaics implies that we sooner or later (probably sooner) might need a separate list where users can ask questions about EPEL -- or we teach them to ask users questions on a devel list because they can't locate a users list. That sucks. I would have much preferred just a "epel" list for both users and developers for now, to split out the developers list later *if* it becomes to noisy. CU thl From elliot.li.tech at gmail.com Wed Feb 28 07:55:13 2007 From: elliot.li.tech at gmail.com (Yan Li) Date: Wed, 28 Feb 2007 15:55:13 +0800 Subject: Why Firefox's About Window is Resizable Message-ID: <20070228075513.GB15997@yantp.dyndns.org> Hi, I just wonder why Firefox's About window is resizable on Linux, but not on Windows? As to my personal feeling, a resizable static window indicates a not carefully tested product. :) Sorry if OT, since I haven't tried Firefox on distros other than Fedora. -- Sincerely yours, Li, Yan From delymyth at delymyth.net Wed Feb 28 08:09:08 2007 From: delymyth at delymyth.net (DElyMyth) Date: Wed, 28 Feb 2007 09:09:08 +0100 Subject: Why Firefox's About Window is Resizable In-Reply-To: <20070228075513.GB15997@yantp.dyndns.org> References: <20070228075513.GB15997@yantp.dyndns.org> Message-ID: On 2/28/07, Yan Li wrote: > > Sorry if OT, since I haven't tried Firefox on distros other than > Fedora. It's resizable on SuSE too, I guess it's related to the browser itself and not to the distribution... Elena. -- => Don't Let Your Fears Stand in The Way of Your Dreams !!! <= => http://www.delymyth.net/ ~ http://wiki.delymyth.net/ <= => FREE Hardware Anti-Virus!!! - /dev/brain <= From pbrobinson at gmail.com Wed Feb 28 09:17:02 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 28 Feb 2007 09:17:02 +0000 Subject: rawhide report: 20070227 changes In-Reply-To: <1172633660.22602.4.camel@localhost.localdomain> References: <200702271148.l1RBm9Wr008298@hs20-bc2-6.build.redhat.com> <45E430B1.1030702@bellsouth.net> <1172633660.22602.4.camel@localhost.localdomain> Message-ID: <5256d0b0702280117p27f91afcw9a96e9c65682c96a@mail.gmail.com> > > > kernel-2.6.20-1.2949.fc7 > > > ------------------------ > > > * Mon Feb 26 2007 Dave Jones > > > - Fix up radeonfb backlight. > > > - Revert forcedeth changes so that it works again. > > > > There's a fix on the street for the forcedeth problem. > > > > http://lkml.org/lkml/2007/2/27/109 > > > > Jay > > Is this forcedeth issue the one causing problems with network cards > connecting. > > I'm unable to use NetworkManager to connect, but if I stop > NetworkManager and then ifdown/ifup my network card then it works fine. forcedeth is the Nvidea ethernet module on boards that have nvidea chipsets so it would be just with the nics using those drivers. Peter From petersen at redhat.com Wed Feb 28 09:24:09 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 28 Feb 2007 19:24:09 +1000 Subject: naming scheme for fonts packages? Message-ID: <45E54A39.7030104@redhat.com> I am currently reviewing a Tibetan font for inclusion in Fedora. It is called Tibetan Machine Uni, and we have had a lengthy polite discussion on the naming of the package both in and out of bugzilla, also with the upstream maintainer. (The project is hosted on SourceForge and GPL fwiw). The package was submitted as tibetan-machine-uni-fonts, so I suggested fonts-tibetan. However since the font is also good for Bhutanese, the submitter and the maintainer think fonts-tibetan-dzongkha (bhutanese) would be more appropriate. It occurred to me that we really need some guideline about naming of fonts packages. Most of our international fonts follow the naming scheme "fonts-*" where "*" is the generally the English name of the language, which makes the package pretty easy to find. And the remainder are mostly suffixed with "-fonts". Currently in F7T2 there are: fonts-ISO8859-2 fonts-KOI8-R fonts-arabic fonts-bengali fonts-chinese fonts-gujarati fonts-hebrew fonts-hindi fonts-japanese fonts-kannada fonts-korean fonts-malayalam fonts-oriya fonts-punjabi fonts-sinhala fonts-tamil fonts-telugu and: bitmap-fonts bitstream-vera-fonts dejavu-lgc-fonts ghostscript-fonts tetex-fonts urw-fonts xorg-x11-fonts In Extras the fonts tend to be more alternative/miscellaneous I guess: VLGothic-fonts artwiz-aleczapka-fonts charis-fonts dejavu-fonts doulos-fonts gentium-fonts hunky-fonts linux-libertine-fonts mathml-fonts mgopen-fonts terminus-font, and fonts-hebrew-fancy So perhaps we need to set two naming conventions: using "fonts-" for standard international fonts and "-fonts" for alternative general fonts? Of course "fonts-" doesn't quite solve the problem for the Tibetan font... ;) The name fonts-tibetan-script was also brought up, and even fonts-bodic. It would probably be good to add some text about in on http://fedoraproject.org/wiki/Packaging/NamingGuidelines anyway. Comments? Opinions? Jens From nicolas.mailhot at laposte.net Wed Feb 28 10:03:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Feb 2007 11:03:32 +0100 (CET) Subject: naming scheme for fonts packages? In-Reply-To: <45E54A39.7030104@redhat.com> References: <45E54A39.7030104@redhat.com> Message-ID: <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> Le Mer 28 f?vrier 2007 10:24, Jens Petersen a ?crit : > So perhaps we need to set two naming conventions: using > "fonts-" for standard international fonts and "-fonts" > for alternative general fonts? fonts-foo are usually a mashup of fonts for a specific encoding, and foo-fonts fonts with distinct style that may span several languages areas. To be honest I'm not too fond of foo-font packages. They're a necessary 8-bit legacy stopgap, but I'd rather have vibrant font projects competing on quality and international coverage. You don't get that if you bundle different upstreams in neutraly named packages. (the fact that FC was more fonts-foo and FE foo-fonts reflects a rather utilitarian view of fonts RH-side, and the huge weight of the fossilized fonts sourced from xfree86/xorg) IMHO (which if worth what it's worth) you're not packaging generic fonts for tibetan but a specific font project, and it deserves name recognition just like any other upstream. So upstreamname-fonts seems more respectful for me. Also have you though of what will happen should someone want to package another tibetan font in a few months ? -- Nicolas Mailhot From ml at deadbabylon.de Wed Feb 28 10:07:47 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 28 Feb 2007 11:07:47 +0100 Subject: KDE-Live-Spin In-Reply-To: References: <20070227174339.50469e76@localhost.localdomain> Message-ID: <20070228110747.0ee377ed@localhost.localdomain> Am Tue, 27 Feb 2007 17:08:56 -0600 schrieb Rex Dieter : > Good work, would you be interested in joining the KDE-SIG to move this > along? Thx. I really like to. :) > I ask because our current focus is on producing a KDE spin, and for > lack of someone to step up to drive the effort for a kde livecd, the > odds of completing it are less. My problem at the moment is that I am one of the people that could not boot the f7test1 live cd (no /dev/root) [1]. Also a f7 spin from my rpms (with up to date rawhide) produces the same error. Because of that it could be a little bit difficult for me to test the live spins. Only in vmware I got them working. But I would see what I can do and added myself to KDE-SIG. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Wed Feb 28 11:18:38 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 28 Feb 2007 12:18:38 +0100 Subject: KDE-Live-Spin In-Reply-To: <20070228110747.0ee377ed@localhost.localdomain> References: <20070227174339.50469e76@localhost.localdomain> <20070228110747.0ee377ed@localhost.localdomain> Message-ID: <13dbfe4f0702280318y104a4f12l6e6d22ece6625f43@mail.gmail.com> On 2/28/07, Sebastian Vahl wrote: > My problem at the moment is that I am one of the people that could not > boot the f7test1 live cd (no /dev/root) [1]. Also a f7 spin from my > rpms (with up to date rawhide) produces the same error. Because of that > it could be a little bit difficult for me to test the live spins. Only > in vmware I got them working. > But I would see what I can do and added myself to KDE-SIG. Hello, Sebastian, file a bug if you haven't yet. It may happens that you are not the only one. I'll try to build the live cd from your config file later tonight. Rex, who will build the official iso for KDE ? Chitlesh -- http://clunixchit.blogspot.com From panemade at gmail.com Wed Feb 28 11:12:15 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 28 Feb 2007 16:42:15 +0530 Subject: naming scheme for fonts packages? In-Reply-To: <45E54A39.7030104@redhat.com> References: <45E54A39.7030104@redhat.com> Message-ID: Hi, On 2/28/07, Jens Petersen wrote: > I am currently reviewing a Tibetan font for inclusion in Fedora. > It is called Tibetan Machine Uni, and we have had a lengthy > polite discussion on the naming of the package both in and out > of bugzilla, also with the upstream maintainer. (The project is hosted > on SourceForge and GPL fwiw). The package was submitted as > tibetan-machine-uni-fonts, so I suggested fonts-tibetan. However since > the font is also good for Bhutanese, the submitter and the maintainer > think fonts-tibetan-dzongkha (bhutanese) would be more appropriate. +1. I agree with fonts-tibetan-dzongkha-bhutanese package name. > > It occurred to me that we really need some guideline about naming of > fonts packages. Most of our international fonts follow the naming > scheme "fonts-*" where "*" is the generally the English name of the > language, which makes the package pretty easy to find. And the > remainder are mostly suffixed with "-fonts". Currently in F7T2 there are: > > fonts-ISO8859-2 fonts-KOI8-R fonts-arabic fonts-bengali fonts-chinese > fonts-gujarati fonts-hebrew fonts-hindi fonts-japanese fonts-kannada > fonts-korean fonts-malayalam fonts-oriya fonts-punjabi fonts-sinhala > fonts-tamil fonts-telugu > > and: > > bitmap-fonts bitstream-vera-fonts dejavu-lgc-fonts ghostscript-fonts > tetex-fonts urw-fonts xorg-x11-fonts > > In Extras the fonts tend to be more alternative/miscellaneous I guess: > > VLGothic-fonts artwiz-aleczapka-fonts charis-fonts dejavu-fonts > doulos-fonts gentium-fonts hunky-fonts linux-libertine-fonts > mathml-fonts mgopen-fonts terminus-font, and fonts-hebrew-fancy > > So perhaps we need to set two naming conventions: using > "fonts-" for standard international fonts and "-fonts" > for alternative general fonts? +1. Good point. > > Of course "fonts-" doesn't quite solve the problem for the > Tibetan font... ;) The name fonts-tibetan-script was also brought up, > and even fonts-bodic. > > It would probably be good to add some text about in on > http://fedoraproject.org/wiki/Packaging/NamingGuidelines anyway. > This is now really needed and FESCO should discuss this in tomorrow's meeting. > Comments? Opinions? > > Jens > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From mschwendt.tmp0701.nospam at arcor.de Wed Feb 28 11:45:31 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 28 Feb 2007 12:45:31 +0100 Subject: Sponsor responsibilities (was: Re: F7 Release Discussion) In-Reply-To: <20070227175015.54917029@ningauble.scrye.com> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> <20070223145522.73d24777@ningauble.scrye.com> <20070224134009.28964062.mschwendt.tmp0701.nospam@arcor.de> <20070225112133.4d3cb9af@ningauble.scrye.com> <20070225213146.a432899d.mschwendt.tmp0701.nospam@arcor.de> <20070226112910.24fe83d4@ningauble.scrye.com> <20070226225225.4a2851ef.mschwendt.tmp0701.nospam@arcor.de> <20070227175015.54917029@ningauble.scrye.com> Message-ID: <20070228124531.136fcb9b.mschwendt.tmp0701.nospam@arcor.de> On Tue, 27 Feb 2007 17:50:15 -0700, Kevin Fenzi wrote: > Perhaps I am not being clear on what I am proposing. > Of course a sponsor shouldn't be required to start maintaining all the > leaving maintainers packages. There's no way that would work. Right. > What I am saying is that they should be able to drive forward the > AWOLmaintainer process for those packages, and do things like posting > emails to the list saying "I sponsored maintainer foo, who is no longer > around, the following packages are orphaned, does anyone want to take > over them?". > > Is that more clear? This is similar but not equal to http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers which involves FESCo in the process. It highly depends on the new FAS and PackageDB and any additional tools based on it. If a contributor is AWOL or has left the project, the sponsor may choose to withdraw the sponsorship at some point. The corresponding data changes in the FAS could propagate into the PackageDB, and a list of new orphans would be created and announced. Co-maintainers and people in Cc might receive a notification, too. Open tickets in bugzilla might be reassigned semi-automatically, too. More interesting are answers to the key questions: - what happens with built and released packages when the package becomes orphaned? - whether and when to delete orphaned rpms in the repository? This is not something the sponsor may decide alone. It needs policies, so the sponsors know exactly how to proceed. In general, I'm more interested in how-tos than in questions. Finding new maintainers for orphans can be tiresome and unsuccessful. Having to clean up the mess without clear policies can be burdensome. > Thanks for all your hard work on those scripts. :) upgradecheck.py is not mine, though. From mschwendt.tmp0701.nospam at arcor.de Wed Feb 28 11:55:13 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 28 Feb 2007 12:55:13 +0100 Subject: bittorrent downgrade (was: Re: [Fedora Project Wiki] Update of "Extras/RepoRequests" by PaulHowarth) In-Reply-To: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> Message-ID: <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: > Request removal of broken rawhide bittorrent package so that it can be downgraded without an epoch bump > > + > + * devel bittorrent-5.0.5-2.fc7.src.rpm Do we have any policy/guideline with regard to things like this? The least thing I'd like to suggest is a warning-mail posted to relevant mailing lists. From ml at deadbabylon.de Wed Feb 28 11:53:16 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 28 Feb 2007 12:53:16 +0100 Subject: KDE-Live-Spin In-Reply-To: <13dbfe4f0702280318y104a4f12l6e6d22ece6625f43@mail.gmail.com> References: <20070227174339.50469e76@localhost.localdomain> <20070228110747.0ee377ed@localhost.localdomain> <13dbfe4f0702280318y104a4f12l6e6d22ece6625f43@mail.gmail.com> Message-ID: <20070228125316.5737fddf@localhost.localdomain> Am Wed, 28 Feb 2007 12:18:38 +0100 schrieb "Chitlesh GOORAH" : > Hello, > Sebastian, file a bug if you haven't yet. It may happens that you are > not the only one. No, I'm not. And the bug is already filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=Fedora7LiveCD Just forgotten to put the link in the first mail (in [1]). Later this day I will post my experiences to fedora-livecd-ml. > I'll try to build the live cd from your config file later tonight. Thx. I've uploaded new rpms which do no include k3b-extras in 20-fedora-livecd-kde.conf (broken in rawhide (at least last night on my mirror)). Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at redhat.com Wed Feb 28 12:07:35 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 28 Feb 2007 07:07:35 -0500 Subject: rawhide report: 20070228 changes Message-ID: <200702281207.l1SC7Zu4014380@hs20-bc2-6.build.redhat.com> Removed package xorg-x11-drv-joystick Removed package xorg-x11-drv-elo2300 Updated Packages: GConf2-2.16.1-1.fc7 ------------------- * Tue Feb 27 2007 Matthias Clasen - 2.16.1-1 - Update to 2.16.1 ORBit2-2.14.7-1.fc7 ------------------- * Tue Feb 27 2007 Matthias Clasen - 2.14.7-1 - Update to 2.14.7 acl-2.2.39-3.fc7 ---------------- * Fri Feb 23 2007 Karsten Hopp 2.2.39-3 - fix buildroot - remove trailing dot from summary - -devel requires same version of libacl - escape macro in changelog - make .so symlink relative * Thu Feb 22 2007 Steve Grubb 2.2.39-2 - Apply patch to make order consistent. anaconda-11.2.0.27-1 -------------------- * Mon Feb 26 2007 Chris Lumens - 11.2.0.27-1 - Clean up partitioning text (katzj, #228198, #221791). - Write out the fstab after migrating (katzj, #223215). - More partitioning text fixes (#229959). - Desensitize drive selection box for custom layouts (#219207). - Support new kickstart extended group syntax. - Handle port numbers in the exception scp dialog (#227909). - Don't attempt to load a module when the device line is wrong (#227510). - Fix selecting the kernel-xen-devel package (dlehman, #226784). - Desensitize partition review checkbox when going back (dlehman, #220951). - Add key handling UI (dlehman). - Fix writing out /etc/sysconfig/network-scripts/ files (#227250). - Verify added repos when going back to the tasksel screen (#227762). - Don't include /usr/share/zonetab/zone.tab for translation (#229729). - Documentation updates (#189292, #173641). - Delete /etc/mtab if it exists on upgrade (#213818). - Add atl1.ko module to loader (#229641). - Don't traceback when cancel is pressed on iscsi add dialog (#229694). - Don't relabel disks that contain protected partitions (dlehman, #220331). - Clear non-protected partitions from disks if initAll is set (dlehman). - Allow access to regkey screen when going back (dlehman, #219361). ant-0:1.6.5-2jpp.3.fc7 ---------------------- * Tue Feb 20 2007 Permaine Cheung 1.6.5-2jpp.3 - Add endorsed dir and create symlinks for xml-commons-apis and jaxp_parser_impl there, and add the option when running ant. - Add missing BR - Fix some rpmlint issues anthy-8622-1.fc7 ---------------- * Mon Feb 26 2007 Akira TAGOH - 8622-1 - New upstream release. apr-util-1.2.8-3 ---------------- * Tue Feb 27 2007 Joe Orton 1.2.8-3 - build DBD drivers as DSOs (w/Bojan Smojver, #192922) - split out pgsql driver into -pgsql subpackage arts-8:1.5.6-2.fc7 ------------------ * Mon Feb 26 2007 Than Ngo - 6:1.5.6-2.fc7 - cleanup specfile aspell-af-50:0.50-5.fc7 ----------------------- * Thu Feb 22 2007 Ivana Varekova - 50:0.50-5 - incorporate package review feedback (225257) aspell-bg-50:0.50-12.fc7 ------------------------ * Thu Feb 22 2007 Ivana Varekova - 50:0.50-12 - spec file cleanup aspell-br-50:0.50-5.fc7 ----------------------- * Thu Feb 22 2007 Ivana Varekova - 50:0.50-5 - spec file cleanup aspell-ca-50:0.50-5.fc7 ----------------------- * Thu Feb 22 2007 Ivana Varekova - 50:0.50-5 - spec file cleanup aspell-cs-50:0.51-4.fc7 ----------------------- * Fri Feb 23 2007 Ivana Varekova - 50:0.51-4 - spec file cleanup aspell-cy-50:0.50-5.fc7 ----------------------- * Fri Feb 23 2007 Ivana Varekova - 50:0.50-5 - spec file cleanup aspell-da-50:0.50-13.fc7 ------------------------ * Fri Feb 23 2007 Ivana Varekova - 50:0.50-13 - spec file cleanup at-spi-1.17.2-1.fc7 ------------------- * Tue Feb 27 2007 Matthias Clasen - 1.17.2-1 - Update to 1.17.2 * Tue Feb 27 2007 Matthias Clasen - 1.17.1-1 - Update to 1.17.1 * Thu Feb 22 2007 Matthias Clasen - 1.17.0-2 - Bump atk requirement attr-2.4.32-2.fc7 ----------------- * Fri Feb 23 2007 Karsten Hopp 2.4.32-2 - add disttag - remove trailing dot from summary - fix buildroot - -devel package requires same libattr version - change prereq to Requires(post) - escape macro in changelog - replace absolute link with relative link (libattr.so) - use %doc macro autoconf-2.61-8.fc7 ------------------- * Tue Feb 27 2007 Karsten Hopp 2.61-8 - own %{_datadir}/emacs/ (#225296) * Mon Feb 26 2007 Karsten Hopp 2.61-7 - add Requires: grep * Thu Feb 22 2007 Karsten Hopp 2.61-6 - drop gawk, sed requirements (#225296) - add some comments autoconf213-2.13-17.fc7 ----------------------- * Mon Feb 26 2007 Karsten Hopp 2.13-17 - our tarball hat different size and timestamps then the upstream tarball. No changes, though. - rebuild with upstream sources autofs-1:5.0.1-2 ---------------- * Fri Feb 23 2007 Ian Kent - 5.0.1-2 - update "@network" matching patch. * Thu Feb 22 2007 Ian Kent - 5.0.1-1 - update to release tar. - fix return check for getpwuid_r and getgrgid_r. - patch to give up trying to update exports list while host is mounted. - fix to "@network" matching. - patch to check for fstab update and retry if not updated. automake15-1.5-20 ----------------- * Thu Feb 22 2007 Karsten Hopp 1.5-20 - add missing buildrequirement texinfo (#229572) bc-1.06-26 ---------- * Mon Feb 26 2007 Thomas Woerner 1.06-26 - removed grep and mktemp usage from post script, also the requires * Mon Feb 26 2007 Karsten Hopp 1.06-25 - fex supports -8 now (pmachata) * Fri Feb 23 2007 Karsten Hopp 1.06-24 - fix buildroot - remove trailing dot from summary - fix post/preun requirements - use make install DESTDIR=... - convert changelog to utf-8 - use smp flags - use 'flex -I' instead 'flex -I8' (not supported anymore) - run autofoo stuff to update files for current automake beagle-0.2.16.2-1.fc7 --------------------- * Thu Feb 22 2007 Matthias Clasen - 0.2.16.2-1 - Update to 0.2.16.2 bind-31:9.3.4-7.fc7 ------------------- * Thu Feb 15 2007 Adam Tkac 31:9.3.4-7.fc7 - minor cleanup in bind-chroot-admin script bitmap-fonts-0.3-5.1.2.fc7 -------------------------- * Tue Feb 27 2007 Mayank Jain - 0.3-5.1.2 - Changed BuildRoot to /var/tmp/bitmap-fonts-0.3-5.1.2.fc7-root-brewbuilder - Changed Prereq tag to Requires(pre) - In the "cjk" subpackage summary, CJK is now spelt with capital letters. - Added .fc7 to the Release tag bug-buddy-1:2.17.4-1.fc7 ------------------------ * Tue Feb 27 2007 Matthias Clasen - 1:2.17.4-1 - Update to 2.17.4 cdrdao-1.2.2-2 -------------- * Tue Feb 27 2007 Harald Hoyer - 1.2.2-2 - fixed specfile issues (bug #225639) cman-2.0.60-3.fc7 ----------------- * Fri Feb 23 2007 Chris Feist - 2.0.60-2 - Added Obsoletes for ccs, fence & dlm - Resolves: rhbz#229822 * Tue Jan 23 2007 Chris Feist - 2.0.60-1 - fence_tool now times out after 300 seconds - Resolves: rhbz#222933 * Tue Jan 16 2007 Chris Feist - 2.0.59-1 - New upstream sources - Resolves: rhbz#222744 rhbz#222838 rhbz#222686 control-center-1:2.17.92-1.fc7 ------------------------------ * Wed Feb 28 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 - Drop obsolete patches coreutils-6.7-9.fc7 ------------------- * Thu Feb 22 2007 Tim Waugh 6.7-9 - Use sed instead of perl for text replacement (bug #225655). - Use install-info scriptlets from the guidelines (bug #225655). cpuspeed-1:1.2.1-1.56.fc7 ------------------------- * Wed Feb 21 2007 Jarod Wilson - Default to ondemand governor w/acpi-cpufreq driver - Minor initscript output cleanup crontabs-1.10-14.fc7 -------------------- * Tue Feb 27 2007 Marcela Maslanova 1.10-14 - review again * Thu Feb 08 2007 Marcela Maslanova 1.10-13 - rhbz#225662 review cups-1:1.2.8-2.fc7 ------------------ * Mon Feb 26 2007 Tim Waugh 1:1.2.8-2 - Applied fix for STR #2264 (bug #230116). curl-7.16.1-3.fc7 ----------------- * Mon Feb 19 2007 Jindrich Novy 7.16.1-3 - don't create/ship static libraries (#225671) * Mon Feb 05 2007 Jindrich Novy 7.16.1-2 - merge review related spec fixes (#225671) cyrus-sasl-2.1.22-6 ------------------- * Mon Feb 26 2007 Nalin Dahyabhai 2.1.22-6 - install config files and init scripts using -p - pull in patch to build with current automake (#229010, Jacek Konieczny and Robert Scheck) - remove prereq on ldconfig, RPM should pick it up based on the -libs scriptlets - pull in patch to correctly detect gsskrb5_register_acceptor_identity (#200892, Mirko Streckenbach) - move sasldb auxprop modules into the -lib subpackage, so that we'll pick it up for multilib systems * Thu Feb 22 2007 Nalin Dahyabhai - pull CVS fix for not tripping over extra commas in digest-md5 challenges (#229640) * Fri Feb 16 2007 Nalin Dahyabhai - remove static build, which is no longer a useful option because not all of our dependencies are available as static libraries - drop patches which were needed to keep static builds going - drop gssapi-generic patch due to lack of interest - update the bundled copy of db to 4.5.20 (#229012) - drop dbconverter-2, as we haven't bundled v1 libraries since FC4 dasher-4.3.5-1.fc7 ------------------ * Wed Feb 28 2007 Matthias Clasen - 4.3.5-1 - Update to 4.3.5 device-mapper-1.02.17-7.fc7 --------------------------- * Tue Feb 27 2007 Alasdair Kergon - 1.02.17-7 - The -libs package Obsoletes pre-split packages. dictd-1.9.15-9 -------------- * Wed Feb 21 2007 Karsten Hopp 1.9.15-9 - misc. merge review fixes dosfstools-2.11-7.fc7 --------------------- * Wed Feb 21 2007 Peter Vrabec 2.11-7 - fix debuginfo package (#225707) dvd+rw-tools-7.0-3.fc7 ---------------------- * Tue Feb 27 2007 Harald Hoyer - 7.0-3.fc7 - fixed specfile issues (#209985) e2fsprogs-1.39-11 ----------------- * Fri Feb 23 2007 Karsten Hopp 1.39-11 - fix post/preun requirements - use smp flags echo-icon-theme-0.2-0.20070223wiki.fc7 -------------------------------------- * Fri Feb 23 2007 Matthias Clasen - 0.2-2.20070223wiki - New snapshot - Fix some scriptlet issues - Own the icon cache eclipse-cdt-1:3.1.2-2.fc7 ------------------------- * Tue Feb 27 2007 Jeff Johnston 3.1.2-2 - Resolves: #229891, #230253, #205310, #229893 - Rebase autotools to 0.0.8.1 source. * Wed Feb 21 2007 Jeff Johnston 3.1.2-1 - Rebase CDT to 3.1.2. - Rebase autotools to 0.0.8 source. - Replace subconsole patch with new build console patch. emacs-22.0.93-7.fc7 ------------------- * Fri Feb 23 2007 Chip Coldwell - 22.0.93-7 - fix po-mode-init.el (Kjartan Maraas #228143) eog-2.17.92-1.fc7 ----------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 epiphany-2.17.92-1.fc7 ---------------------- * Tue Feb 27 2007 Matthias Clasen 2.17.92-1 - Update to 2.17.92 esound-1:0.2.37-1.fc7 --------------------- * Tue Feb 27 2007 Matthias Clasen - 1:0.2.37-1 - Update to 0.2.37 evolution-2.9.92-1.fc7 ---------------------- * Mon Feb 26 2007 Matthew Barnes - 2.9.92-1.fc7 - Update to 2.9.92. - Require gtkhtml3 >= 3.13.92. - Add missing libgnomeprintui22 requirements. - Remove patch for GNOME bug #350253 (fixed upstream). - Remove patch for GNOME bug #356177 (fixed upstream). - Remove patch for GNOME bug #360946 (fixed upstream). - Remove evolution-2.5.4-move-autosave-file.patch (fixed upstream). - Add minimum version to intltool requirement (currently >= 0.35.5). * Thu Feb 15 2007 Matthew Barnes - 2.9.91-3.fc7 - Revise patch for GNOME bug #362638 to fix RH bug #220714 (certificate prompt causes crash). * Tue Feb 13 2007 Matthew Barnes - 2.9.91-2.fc7 - Require GConf2 in post. - Require scrollkeeper in post and postun. evolution-connector-2.9.92-2.fc7 -------------------------------- * Tue Feb 27 2007 Matthew Barnes - 2.9.92-2.fc7 - Add missing libgnomeprint22 requirements. - Add flag to disable deprecated GNOME symbols. * Mon Feb 26 2007 Matthew Barnes - 2.9.92-1.fc7 - Update to 2.9.92 - Reverting -Werror due to bonobo-i18n.h madness. - Add minimum version to intltool requirement (currently >= 0.35.5). evolution-data-server-1.9.92-1.fc7 ---------------------------------- * Mon Feb 26 2007 Matthew Barnes - 1.9.92-1.fc7 - Update to 1.9.92 - Remove patch for GNOME bug #356177 (fixed upstream). - Add minimum version to intltool requirement (current >= 0.35.5). evolution-webcal-2.9.92-1.fc7 ----------------------------- * Tue Feb 27 2007 Matthew Barnes - 2.9.92-1.fc7 - Update to 2.9.92 fast-user-switch-applet-2.17.4-1.fc7 ------------------------------------ * Tue Feb 27 2007 Matthias Clasen 2.17.4-1 - Update to 2.17.4 file-roller-2.17.92-1.fc7 ------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 firefox-2.0.0.2-1.fc7 --------------------- * Fri Feb 23 2007 Martin Stransky 2.0.0.2-1 - Update to 2002 * Wed Feb 21 2007 David Woodhouse 2.0.0.1-6 - Fix PPC64 runtime - Fix firefox script to use 32-bit browser by default on PPC64 hardware freeradius-1.1.3-3 ------------------ * Fri Feb 23 2007 Karsten Hopp 1.1.3-3 - remove trailing dot from summary - fix buildroot - fix post/postun/preun requirements - use rpm macros gcalctool-5.9.13-1.fc7 ---------------------- * Tue Feb 27 2007 Matthias Clasen - 5.9.13-1 - Update to 5.9.13 gcc-4.1.2-3 ----------- * Thu Feb 22 2007 Jakub Jelinek 4.1.2-3 - update from gcc-4_1-branch (-r122163:122219) - PR ada/30684 - fix !$omp space space parsing in Fortran - fix Fortran -ff2c (Tobias Schlueter, #229110, PR fortran/25392) - add gnu.java.util.ZoneInfo class, use tzdata files for libgcj timezone stuff (#227888) * Tue Feb 20 2007 Jakub Jelinek 4.1.2-2 - merge from redhat/gcc-4_1-branch-java-merge-20070117 to get an eclipse based Java 1.5 gcc-java/libgcj - update from gcc-4_1-branch (-r121962:122163) - PRs fortran/30478, fortran/30799, middle-end/24427, other/27843, rtl-optimization/28173, rtl-optimization/28772, rtl-optimization/29599, rtl-optimization/30787, target/19087, tree-optimization/30823 gconf-editor-2.17.0-2.fc7 ------------------------- * Fri Feb 23 2007 Matthias Clasen - 2.17.0-2 - Fix small issues gd-2.0.34-2.fc7 --------------- * Thu Feb 22 2007 Ivana Varekova 2.0.34-2 - incorporate package review feedback gdb-6.6-4.fc7 ------------- * Sun Feb 25 2007 Jan Kratochvil - 6.6-4 - Backport + testcase for PPC Power6/DFP instructions disassembly (BZ 230000). * Mon Feb 05 2007 Jan Kratochvil - 6.6-3 - Fix a race during attaching to dying threads; backport (BZ 209445). - Testcase of unwinding has now marked its unsolvable cases (for BZ 140532). * Fri Jan 26 2007 Jan Kratochvil - 6.6-2 - Backported post gdb-6.6 release PPC `show endian' fixup. - Fix displaying of numeric char arrays as strings (BZ 224128). - Simplified patches by merging upstream accepted ones into a single file. gdm-1:2.17.7-5.fc7 ------------------ * Sat Feb 24 2007 Matthias Clasen - 1:2.17.7-5 - Fix keynav in the face browser * Fri Feb 23 2007 David Zeuthen - 1:2.17.7-4 - Add some enhancements to the greeter (bgo #411427) * Fri Feb 23 2007 Ray Strode - 1:2.17.7-3 - Update to 2.17.7 gedit-1:2.17.6-1.fc7 -------------------- * Tue Feb 27 2007 Matthias Clasen - 1:2.17.6-1 - Update to 2.17.6 * Tue Feb 13 2007 Matthias Clasen - 1:2.17.5-1 - Update to 2.17.5 gettext-0.16.1-5.fc7 -------------------- * Fri Feb 23 2007 Karsten Hopp 0.16.1-5 - rebuild to pick up dependency on libgcj.so.8rh instead libgcj.so.7rh gfs2-utils-0.1.25-1.fc7 ----------------------- gftp-1:2.0.18-4.fc7 ------------------- * Sun Feb 25 2007 Matthias Clasen - 1:2.0.18-4 - Take the GDK lock early enough (#229943) - Don't add invalid/obsolete categories to the desktop file glib-java-0.2.6-5.fc7 --------------------- * Wed Feb 21 2007 Andrew Overholt 0.2.6-5 - Bump for new gcj. - Add patch for gcjh -> gjavah. gmp-4.1.4-12 ------------ * Fri Feb 23 2007 Karsten Hopp 4.1.4-12 - remove trailing dot from summary - fix buildroot - fix post/postun/... requirements - use make install DESTDIR=... - replace tabs with spaces - convert changelog to utf-8 gnome-applets-1:2.17.90-1.fc7 ----------------------------- * Tue Feb 27 2007 Matthias Clasen - 1:2.17.90-1 - Update to 2.17.90 gnome-desktop-2.17.92-1.fc7 --------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 gnome-games-1:2.17.92-1.fc7 --------------------------- * Tue Feb 27 2007 Matthias Clasen - 1:2.17.92-1 - Update to 2.17.92 gnome-keyring-0.7.92-1.fc7 -------------------------- * Sat Feb 24 2007 Matthias Clasen - 0.7.92-1 - Update to 0.7.92 gnome-menus-2.17.92-1.fc7 ------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 - Drop obsolete patch gnome-panel-2.17.92-1.fc7 ------------------------- * Wed Feb 28 2007 Matthias Clasen 2.17.92-1 - Update to 2.17.92 gnome-power-manager-2.17.92-1.fc7 --------------------------------- * Wed Feb 28 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 gnome-python2-2.17.92-2.fc7 --------------------------- * Mon Feb 26 2007 Matthew Barnes - 2.17.92-2.fc7 - Rebuild * Sun Feb 25 2007 Matthew Barnes - 2.17.92-1.fc7 - Update to 2.17.92 * Mon Feb 05 2007 Matthew Barnes - 2.17.2-2 - Rename spec file to gnome-python2.spec (RH bug #225834). gnome-python2-extras-2.14.3-1.fc7 --------------------------------- * Sun Feb 25 2007 Matthew Barnes - 2.14.3-1.fc7 - Update to 2.14.3 gnome-session-2.17.92-1.fc7 --------------------------- * Wed Feb 28 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 gnome-speech-0.4.10-1.fc7 ------------------------- * Tue Feb 27 2007 Matthias Clasen - 0.4.10-1 - Update to 0.4.10 gnome-system-monitor-2.17.94-1.fc7 ---------------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.94-1 - Update to 2.17.94 * Mon Feb 12 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 gnome-terminal-2.17.92-1.fc7 ---------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 gnome-themes-2.17.91-2.fc7 -------------------------- * Fri Feb 23 2007 Matthias Clasen - 2.17.91-2 - Own the icon caches gnucash-2.0.5-1.fc6 ------------------- * Mon Feb 19 2007 Bill Nottingham - 2.0.5-1 - update to 2.0.5 - fixes: CVE-2007-0007 gnupg-1.4.6-4 ------------- * Tue Feb 27 2007 Nalin Dahyabhai - 1.4.6-4 - flip the switch on libtermcap/ncurses (#230187) - rpmlint fixups gok-1.2.1-3.fc7 --------------- * Sat Feb 24 2007 David Zeuthen - 1.2.1-3 - Make gok work under gdm (bgo #383514) gphoto2-2.3.1-5.fc7 ------------------- * Wed Feb 21 2007 Jindrich Novy 2.3.1-5 - include back the 10-camera-libgphoto2.fdi removed in the previous build (#229230) gthumb-2.9.3-1.fc7 ------------------ * Tue Feb 27 2007 Matthias Clasen - 2.9.3-1 - Update to 2.9.3 * Wed Feb 21 2007 Matthias Clasen - 2.9.2-1 - Update to 2.9.2 - Move libgthumb.so out of libdir gtk-doc-1.8-1.fc7 ----------------- * Wed Feb 21 2007 Matthias Clasen - 1.8-1 - Update to 1.8 - Fix some directory ownership issues gtk2-engines-2.9.4-2.fc7 ------------------------ * Tue Feb 27 2007 Matthias Clasen - 2.9.4-2 - Add a knob to Clearlooks to make scrollbars work better in dark themes, needed for the gdm theme * Mon Feb 26 2007 Matthias Clasen - 2.9.4-1 - Update to 2.9.4 gtkhtml3-3.13.92-2.fc7 ---------------------- * Tue Feb 27 2007 Matthew Barnes - 3.13.92-2.fc7 - Add flag to disable deprecated GNOME symbols. * Mon Feb 26 2007 Matthew Barnes - 3.13.92-1.fc7 - Update to 3.13.92 - Add mimimum version to intltool requirement (currently >= 0.35.5). hicolor-icon-theme-0.10-2 ------------------------- * Fri Feb 23 2007 Matthias Clasen - 0.10-2 - Own the icon cache hwdata-0.198-1.fc7 ------------------ * Tue Feb 27 2007 Adam Jackson 0.198-1 - Fix the intel entry in videodrivers to be tab-delimited (#227591) - Add a check for same to the 'check' target - Add clog target to Makefile * Mon Feb 26 2007 Karsten Hopp 0.197-1 - add disttag * Wed Feb 21 2007 Karsten Hopp 0.196-1 - review fixes icon-naming-utils-0.8.2-1.fc7 ----------------------------- * Mon Feb 26 2007 Matthias Clasen - 0.8.2-1 - Update to 0.8.2 - Small spec file cleanups intltool-0.35.5-1.fc7 --------------------- * Sat Feb 24 2007 Matthias Clasen - 0.35.5-1 - Update to 0.35.5 iputils-20020927-42.fc7 ----------------------- * Thu Feb 22 2007 Martin Bacovsky - 20020927-42 - Resolves: #218706 - now defines the destination address along RFC3484 - Resolves: #229630 - ifenslave(8) man page added - Resolves: #213716 - arping doesn't work on InfiniBand ipoib interfaces ipv6calc-0.61-2.fc7 ------------------- * Tue Feb 27 2007 Marcela Maslanova - 0.61-2 - package merge review - rhbz#225910 irda-utils-0.9.18-2.fc7 ----------------------- * Wed Feb 21 2007 Karsten Hopp 0.9.18-2 - review cleanups joe-3.5-3.fc7 ------------- * Fri Feb 23 2007 Ivana Varekova 3.5-3 - incorporate the package review feedback jpilot-0.99.9-3.fc7 ------------------- * Fri Feb 23 2007 Ivana Varekova - 0.99.9-3 - incorporate package review feedback (#225951) kdeaccessibility-1:3.5.6-2.fc7 ------------------------------ * Mon Feb 26 2007 Than Ngo - 1:3.5.6-2.fc7 - cleanup specfile kdeaddons-3.5.6-2.fc7 --------------------- * Tue Feb 27 2007 Than Ngo - 3.5.6-2.fc7 - cleanup specfile - kde* package splitting in -extras - fedora as metabar default setting kernel-2.6.20-1.2953.fc7 ------------------------ ksh-20070111-1 -------------- * Wed Feb 21 2007 Karsten Hopp 20070111-1 - new upstream version - fix invalid write in uname function libIDL-0.8.8-1.fc7 ------------------ * Tue Feb 27 2007 Matthias Clasen - 0.8.8-1 - Update to 0.8.8 libXrandr-1.2.0-1.fc7 --------------------- * Wed Feb 21 2007 Adam Jackson 1.2.0-1 - libXrandr 1.2.0 libart_lgpl-2.3.18-1.fc7 ------------------------ * Tue Feb 27 2007 Matthias Clasen - 2.3.18-1 - Update to 2.3.18 libbonobo-2.17.92-1.fc7 ----------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 libbonoboui-2.17.94-1.fc7 ------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.94-1 - Update to 2.17.94 * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 libcap-1.10-29 -------------- * Fri Feb 23 2007 Karsten Hopp 1.10-29 - add CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL (#229833) * Wed Feb 21 2007 Karsten Hopp 1.10-28 - drop obsolete ia64 patch - rpmlint fixes * Wed Feb 21 2007 Karsten Hopp 1.10-27 - misc. review fixes - add debian patch to make it build with a recent glibc - remove static lib libgnome-2.17.92-1.fc7 ---------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 * Mon Jan 22 2007 Matthias Clasen - 2.17.90-1 - Update to 2.17.90 libgnomeprint22-2.17.92-1.fc7 ----------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 libgnomeprintui22-2.17.92-1.fc7 ------------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 libgnomeui-2.17.92-1.fc7 ------------------------ * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 libgtop2-2.14.8-1.fc7 --------------------- * Tue Feb 27 2007 Matthias Clasen - 2.14.8-1 - Update to 2.14.8 libselinux-2.0.5-1.fc7 ---------------------- * Tue Feb 27 2007 Dan Walsh - 2.0.5-1 - Upgrade to upstream * Merged init_selinuxmnt() and is_selinux_enabled() improvements from Steve Grubb. * Wed Feb 21 2007 Dan Walsh - 2.0.4-1 - Upgrade to upstream * Removed sending of setrans init message. * Merged matchpathcon memory leak fix from Steve Grubb. * Tue Feb 20 2007 Dan Walsh - 2.0.2-1 - Upgrade to upstream * Merged more swig initializers from Dan Walsh. libuser-0.56.1-1 ---------------- * Fri Feb 23 2007 Miloslav Trmac - 0.56.1-1 - When changing passwords, only silently ignore know shadow markers, not all invalid hashes Resolves: #225495 libwnck-2.17.92-1.fc7 --------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 lksctp-tools-1.0.6-3.fc7 ------------------------ * Wed Feb 21 2007 Karsten Hopp 1.0.6-3 - add post/postun requirements - review fixes * Tue Sep 19 2006 Karsten Hopp 1.0.6-2 - fix fileconflict (#205225) lynx-2.8.6-3.fc7 ---------------- * Fri Feb 23 2007 Ivana Varekova - 2.8.6-3 - incorporate package review feedback (#226113) mailx-8.1.1-45.fc7 ------------------ * Fri Feb 23 2007 Ivana Varekova - 8.1.1-45 - incorporate the package review feedback (226118) make-1:3.81-5.fc7 ----------------- * Thu Feb 22 2007 Petr Machata - 1:3.81-5 - Fix newline handling for quoted SHELL. - Resolves: #228732 * Fri Feb 02 2007 Petr Machata - 1:3.81-4 - Tidy up the specfile per rpmlint comments - Use utf-8 and fix national characters in contributor's names man-pages-2.43-8.fc7 -------------------- * Tue Feb 27 2007 Ivana Varekova 2.43-8 - fix 229870 - bug in fadvise(2) - fix 229204 - bug in passwd(5) * Thu Feb 15 2007 Ivana Varekova 2.43-7 - fix rand.3 man page (#228662) thanks Mark Summerfield * Tue Feb 13 2007 Ivana Varekova 2.43-6 - Resolves: 227260 fix iso-8859 (koi8-r) man pages mcstrans-0.2.4-1.fc7 -------------------- * Mon Feb 26 2007 Dan Walsh 0.2.4-1 - Translate range if fully specified correctly mesa-6.5.2-6.fc7 ---------------- * Mon Feb 26 2007 Adam Jackson 6.5.2-6 - mesa-6.5.2-libgl-visibility.patch: Fix non-exported GLX symbols (#229808) - Require a sufficiently new libdrm at runtime too - Make the arch macros do something sensible in the general case metacity-2.17.8-1.fc7 --------------------- * Wed Feb 28 2007 Matthias Clasen - 2.17.8-1 - Update to 2.17.8 * Thu Feb 22 2007 Matthias Clasen - 2.17.5-2 - Fix a spec file typo - Don't ship static libraries mkinitrd-6.0.8-1 ---------------- * Tue Feb 27 2007 Peter Jones - 6.0.8-1 - nash and mkinitrd shouldn't both provide libbdevid.so.* * Tue Feb 13 2007 Peter Jones - Query modules for firmware and try to copy it into the image. * Thu Feb 01 2007 Peter Jones - Add support for ">>" in nash for better debugging of thaw from hibernate. mktemp-3:1.5-25.fc7 ------------------- * Wed Feb 21 2007 Peter Vrabec 3:1.5-25 - applying build patch is fixing both: stripping and binary permission - fix spec file issues * Tue Jan 30 2007 Florian La Roche 3:1.5-24 - do not strip debuginfo data - add dist to release tag * Wed Jul 12 2006 Jesse Keating - 3:1.5-23.2.2 - rebuild mod_perl-2.0.3-6 ---------------- * Tue Feb 27 2007 Joe Orton 2.0.3-6 - filter more Apache::Test requirements * Mon Feb 26 2007 Joe Orton 2.0.3-5 - repackage set of trimmed modules, but only in -devel mutt-5:1.5.14-1.fc7 ------------------- * Fri Feb 23 2007 Miroslav Lichvar 5:1.5.14-1 - update to 1.5.14 nautilus-2.17.92-1.fc7 ---------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 * Tue Feb 13 2007 Matthias Clasen - 2.17.91-1 - Update to 2.17.91 * Wed Feb 07 2007 Matthias Clasen - 2.17.90-4 - Add DesktopSettings category to nautilus-file-management-properties.desktop nautilus-cd-burner-2.17.8-1.fc7 ------------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.8-1 - Update to 2.17.8 neon-0.25.5-6 ------------- * Mon Feb 05 2007 Joe Orton 0.25.5-6 - remove trailing dot in -devel Summary - use standard BuildRoot - change Group to System Environment/Libraries - drop Prefix net-snmp-1:5.4-10.fc7 --------------------- * Mon Feb 26 2007 Vitezslav Crhonek - 5.4-10 - fix net-snmp-config strange values for --libs (#228588) * Fri Feb 23 2007 Radek Vok??l - 5.4-9 - fix dependency on lm_sensors-devel (#229109) - spec file cleanups net-tools-1.60-79.fc7 --------------------- * Thu Feb 22 2007 Radek Vok??l - 1.60-79 - quiet sctp (#229232) newt-perl-1.08-13 ----------------- * Tue Feb 27 2007 Joe Orton 1.08-12 - clean up URL, Source, BuildRoot, BuildRequires * Thu Dec 14 2006 Joe Orton 1.08-12 - fix test.pl (Charlie Brady, #181674) nmap-2:4.20-3.fc7 ----------------- * Tue Feb 27 2007 Harald Hoyer - 2:4.20-3.fc7 - specfile cleanup - fixed Florian La Roche's patch * Tue Jan 30 2007 Florian La Roche - 2:4.20-2.fc7 - do not strip away debuginfo * Tue Jan 09 2007 Florian La Roche - 2:4.20-1 - version 4.20 nspr-4.6.5-2 ------------ * Sat Feb 24 2007 Kai Engert - 4.6.5-2 - Update to latest ipv6 upstream patch - Add upstream patch to fix a thread cleanup issue - Now requires pkgconfig nss-3.11.5-1.fc7 ---------------- * Sat Feb 24 2007 Kai Engert - 3.11.5-1 - Update to 3.11.5 - This update fixes two security vulnerabilities with SSL 2 - Do not use -rpath link option - Added several unsupported tools to tools package * Tue Jan 09 2007 Bob Relyea - 3.11.4-4 - disable ECC, cleanout dead code * Tue Nov 28 2006 Kai Engert - 3.11.4-1 - Update to 3.11.4 nss_db-2.2-36 ------------- * Mon Feb 19 2007 Nalin Dahyabhai - 2.2-36 - update to use DB 4.5.20 - make our obsoletion of nss_db-compat a versioned one - mark the makefile %config(noreplace) - change buildroot to the prescribed value - change buildprereq to buildrequires to make rpmlint happy nss_ldap-254-1 -------------- * Mon Feb 26 2007 Nalin Dahyabhai - 254-1 - update to nss_ldap 254 - use the upstream version scripts - stop trying to isolate us from the apps by building with static libraries, though that means we're tied to /usr now - move the nsswitch module to %{_libdir}; its deps aren't available without a mounted /usr anyway - make rpmlint happier openssh-4.5p1-3.fc7 ------------------- * Thu Feb 22 2007 Tomas Mraz - 4.5p1-3 - improve Buildroot - remove duplicate /etc/ssh from files orca-2.17.92-1.fc7 ------------------ * Wed Feb 28 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 pam-0.99.7.1-3.fc7 ------------------ * Wed Feb 21 2007 Tomas Mraz 0.99.7.1-3 - correctly relabel tty in the default case (#229542) - pam_unix: cleanup of bigcrypt support - pam_unix: allow modification of '*' passwords to root pango-1.16.0-1.fc7 ------------------ * Tue Feb 27 2007 Matthias Clasen - 1.16.0-1 - Update to 1.16.0 perl-4:5.8.8-13.fc7 ------------------- * Sat Feb 03 2007 Tom "spot" Callaway - 4:5.8.8-13 - massive cleanups * Wed Jan 24 2007 Jindrich Novy - 4:5.8.8-12 - put dist tag directly to perlrel to fix dependency to suidperl * Tue Jan 23 2007 Jindrich Novy - 4:5.8.8-11 - rebuild against new db4 - use dist tag php-pear-1:1.5.0-2 ------------------ * Mon Feb 19 2007 Joe Orton 1:1.5.0-2 - update builtin module provides (Remi Collet, #226295) - drop patch 0 pinfo-0.6.9-3.fc7 ----------------- * Fri Feb 23 2007 Miroslav Lichvar 0.6.9-3 - save section of first man page to history (#208738) - remove dot from summary policycoreutils-2.0.6-3.fc7 --------------------------- * Tue Feb 27 2007 Dan Walsh 2.0.6-3 - Update to upstream -sepolgen * Merged support for enabling parser debugging from Karl MacMillan. - Add sgrupp cleanup of restorcon init script * Mon Feb 26 2007 Dan Walsh 2.0.6-2 - Add Bill Nottinham patch to run restorcond condrestart in postun * Fri Feb 23 2007 Dan Walsh 2.0.6-1 - Update to upstream - policycoreutils * Merged newrole O_NONBLOCK fix from Linda Knippers. * Merged sepolgen and audit2allow patches to leave generated files in the current directory from Karl MacMillan. * Merged restorecond memory leak fix from Steve Grubb. -sepolgen * Merged patch to leave generated files (e.g. local.te) in current directory from Karl MacMillan. * Merged patch to make run-tests.py use unittest.main from Karl MacMillan. * Merged patch to update PLY from Karl MacMillan. * Merged patch to update the sepolgen parser to handle the latest reference policy from Karl MacMillan. prctl-1.5-2 ----------- * Wed Feb 21 2007 Karsten Hopp 1.5-2 - review fixes privoxy-3.0.6-5.fc7 ------------------- * Mon Feb 26 2007 Karsten Hopp 3.0.6-5 - add disttag - don't convert manpage to UTF-8 - use dynamic pcre - drop license text from spec file, it's already covered in %doc * Thu Feb 22 2007 Karsten Hopp 3.0.6-4 - remove changelog from init script - added many spec file fixes from Sarantis Paskalis : - remove unnecessary perl invocation - fix Requires(pre), (post), (preun) and (postun) for scriptlets - fix rpmlint 'conffile-marked-as-executable' - fix other stuff, so that it can actually be installed and erased - do not remove user/group on erase because due to logs remaining - major cleanup of the spec file pykickstart-0.98-1.fc7 ---------------------- * Mon Feb 26 2007 Chris Lumens - 0.98-1 - Fix device command syntax to match anaconda. - Fix __call__ on method command. pyorbit-2.14.2-1 ---------------- * Sun Feb 25 2007 Matthew Barnes - 2.14.2-1.fc7 - Update to 2.14.2 redhat-artwork-5.0.10-3.fc7 --------------------------- * Fri Feb 23 2007 Matthias Clasen 5.0.10-3 - Own the icon cache * Fri Feb 23 2007 Matthias Clasen 5.0.10-2 - Fix #221757 redhat-lsb-3.1-13 ----------------- * Wed Feb 21 2007 Lawrence Lim - 3.1-13 - fixed Bug 226363 rgmanager-2.0.23-2.fc7 ---------------------- * Wed Jan 17 2007 Chris Feist - 2.0.23-1 - New upstream sources. - Resolves: rhbz#222961 * Tue Jan 16 2007 Chris Feist - 2.0.22-1 - New upstream sources. - Resolves: rhbz#222485 * Mon Dec 18 2006 Chris Feist - 2.0.21-1 - New upstream sources. - Resolves: rhbz#218697 rhgb-0.17.2-1.fc7 ----------------- * Wed Feb 21 2007 Matthias Clasen - 0.17.2-1 - Fix some small color issues rhythmbox-0.9.8-1.fc7 --------------------- * Wed Feb 21 2007 - Bastien Nocera - 0.9.8-1.fc7 - Update to 0.9.8, drop unneeded requirements and patches - Change iradio default stations location - Add new rhythmbox-core library scim-bridge-0.4.10-1.fc7 ------------------------ * Mon Feb 26 2007 Jens Petersen - 0.4.10-1 - update to 0.4.10 selinux-policy-2.5.5-2.fc7 -------------------------- * Fri Feb 23 2007 Dan Walsh 2.5.5-2 - Policy for consolekit * Fri Feb 23 2007 Dan Walsh 2.5.5-1 - Update to latest from upstream * Wed Feb 21 2007 Dan Walsh 2.5.4-2 - Revert Nemiver change - Set sudo as a corecmd so prelink will work, remove sudoedit mapping, since this will not work, it does not transition. - Allow samba to execute useradd setarch-2.0-4.fc7 ----------------- * Tue Feb 20 2007 Jindrich Novy 2.0-4 - preserve timestamps of installed files - remove -Wall, it's already in RPM_OPT_FLAGS setroubleshoot-1.9.2-1.fc7 -------------------------- * Thu Feb 22 2007 Dan Walsh - 1.9.2-1 - Suck in AuditMsg since audit libs are dropping support slrn-0.9.8.1pl1-2.fc7 --------------------- * Thu Feb 22 2007 Miroslav Lichvar 0.9.8.1pl1-2 - fix author search (#229597) - spec cleanup smartmontools-1:5.37-1.fc7 -------------------------- * Tue Feb 27 2007 Vitezslav Crhonek - 1:5.37-1 - new upstream version sox-13.0.0-1 ------------ * Mon Feb 26 2007 Thomas Woerner 13.0.0-1 - new version 13.0.0 - spec file cleanup (#227429) - new ldconfig calls for post and postun sudo-1.6.8p12-13.fc7 -------------------- * Mon Feb 26 2007 Peter Vrabec 1.6.8p12-13 - fix some spec file issues * Thu Dec 14 2006 Peter Vrabec 1.6.8p12-12 - fix rpmlint issue symlinks-1.2-29.fc7 ------------------- * Fri Feb 23 2007 Tim Waugh 1.2-29 - Use smp_mflags (bug #226445). - Better default attributes (bug #226445). - Make setup macro quiet (bug #226445). - Clean build root in %install section (bug #226445). sysklogd-1.4.2-1.fc7 -------------------- * Mon Feb 26 2007 Peter Vrabec 1.4.2-1 - new upstream(RH) release. system-config-date-1.8.13-1.fc7 ------------------------------- * Fri Feb 23 2007 Nils Philippsen 1.8.13 - pick up updated translations (#229727) * Tue Jan 16 2007 Nils Philippsen 1.8.12 - pick up updated translations (#220952) * Mon Jan 08 2007 Nils Philippsen - ask whether the configuration should be revisited on NTP problems (#220952) system-config-printer-0.7.55-1.fc7 ---------------------------------- * Tue Feb 27 2007 Tim Waugh 0.7.55-1 - 0.7.55: - Use converted value for job option widgets. * Tue Feb 27 2007 Tim Waugh 0.7.54-1 - 0.7.54: - Removed debugging code. * Tue Feb 27 2007 Tim Waugh 0.7.53-1 - No longer requires rhpl (since 0.7.53). - 0.7.53: - Use gettext instead of rhpl.translate. - Better layout for PPD options. - Added scrollbars to main printer list (bug #229453). - Set maximum width of default printer label (bug #229453). - Handle applying changes correctly when switching to another printer (bug #229378). - Don't crash when failing to fetch the PPD (bug #229406). - Make the text entry boxes sensitive but not editable for remote printers (bug #229381). - Better job options screen layout (bug #222272). tcl-1:8.4.13-12.fc7 ------------------- * Tue Feb 27 2007 Marcela Maslanova - 1:8.4.13-12 - review * Wed Feb 21 2007 Marcela Maslanova - 1:8.4.13-11 - review * Thu Feb 15 2007 Marcela Maslanova - 1:8.4.13-10 - review tcsh-6.14-15 ------------ * Mon Feb 26 2007 Miloslav Trmac - 6.14-15 - Fix License: Related: #226483. time-1.7-29.fc7 --------------- * Tue Feb 27 2007 Karsten Hopp 1.7-29 - remove trailing dot from summary - replace tabs with spaces - replace PreReq with Requires(post)/Requires(preun) - include license file in %doc - add smp flags - use make install DESTDIR= tk-1:8.4.13-5.fc7 ----------------- * Tue Feb 20 2007 Marcela Maslanova - 1:8.4.13-5 - rhbz#226494 review again tn5250-0.17.3-13.fc7 -------------------- * Tue Feb 27 2007 Karsten Hopp 0.17.3-13 - drop buildrequirement libtool - update icon cache on install/uninstall * Mon Feb 26 2007 Karsten Hopp 0.17.3-12 - misc review fixes (#226496) * Wed Feb 21 2007 Karsten Hopp 0.17.3-11 - fix permissions - touch only patched files tomboy-0.5.9-1.fc7 ------------------ * Wed Feb 28 2007 Matthias Clasen - 0.5.9-1 - Update to 0.5.9 tzdata-2007c-1.fc7 ------------------ * Mon Feb 26 2007 Petr Machata - 2007c-1 - Upstream 2007c - Pulaski County, Indiana, switched back to eastern time. - Turkey switches at 01:00 standard time, not at 01:00 UTC. - Upstream 2007b - Changes to the commentary in "leapseconds". * Wed Feb 07 2007 Petr Machata - 2007a-2 - tidy up the specfile per rpmlint comments udev-105-1 ---------- * Wed Feb 21 2007 Harald Hoyer - 105-1 - version 105 vim-2:7.0.201-1.fc7 ------------------- * Wed Feb 21 2007 Karsten Hopp 7.0.195-2 - rpmlint fixes (#226526) * Tue Feb 13 2007 Karsten Hopp 7.0.195-1 - patchlevel 195 vino-2.17.92-1.fc7 ------------------ * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 - Drop obsolete patches * Wed Jan 24 2007 Matthias Clasen - 2.17.5-2 - Fix some careless gconf value handling - use libnotify - Improve category in the desktop file vte-0.15.5-1.fc7 ---------------- * Tue Feb 27 2007 Matthias Clasen 0.15.5-1 - Update to 0.15.5 w3m-0.5.1-17.fc7 ---------------- * Mon Feb 26 2007 Parag Nemade - 0.5.1-17 - Resolves #229799 * Wed Feb 21 2007 Parag Nemade - 0.5.1-16 - Modified SPEC file to add new patchfile to resolve rh#222914. * Fri Feb 02 2007 Parag Nemade - 0.5.1-15.1 - Resolves: rh#226535 Review Merge - Modified SPEC file. xorg-x11-drivers-7.2-4.fc7 -------------------------- * Tue Feb 27 2007 Adam Jackson 7.2-4 - Remove elo2300 and joystick for being utterly broken. * Mon Feb 26 2007 Adam Jackson 7.2-3 - Fix the i810 ifarch to include all the relevant arches. xorg-x11-drv-i810-1.6.5-12.fc7 ------------------------------ * Tue Feb 27 2007 Adam Jackson 1.6.5-12 - Nuke %with_dri, since the arch list exactly matched the ExclusiveArch list - Remove ivch and ch7017 from the install since they aren't hooked up to the code anywhere - Disown the module xorg-x11-drv-mga-1.4.6.1-3.fc7 ------------------------------ * Mon Feb 26 2007 Adam Jackson 1.4.6.1-3 - Late-bind a call into a loadable module - Disown the module directory xorg-x11-drv-nv-1.2.2.1-4.fc7 ----------------------------- * Tue Feb 27 2007 Adam Jackson 1.2.2.1-4 - nouveau update: Fix a typo that would cause a crash if anyone was insane enough to still be using an nv3 card. xorg-x11-drv-s3-0.5.0-3.fc7 --------------------------- * Mon Feb 26 2007 Adam Jackson 0.5.0-3 - Fix Xv to not crash instantly - Don't attempt to own the module dir xorg-x11-drv-savage-2.1.2-3.fc7 ------------------------------- * Mon Feb 26 2007 Adam Jackson 2.1.2-3 - Delete a call to a symbol that's never existed. Wacky. - Disown the module directory xorg-x11-drv-trident-1.2.3-4.fc7 -------------------------------- * Mon Feb 26 2007 Adam Jackson 1.2.3-4 - Don't compile a dead file xorg-x11-drv-vesa-1.3.0-4.fc7 ----------------------------- * Tue Feb 27 2007 Adam Jackson 1.3.0-4 - vesa-1.3.0-range-hack.patch: Work around broken ATI video BIOSes. - Disown the module dir - Fix the License xorg-x11-proto-devel-7.2-3.fc7 ------------------------------ * Fri Feb 23 2007 Adam Jackson 7.2-3 - damageproto 1.1.0 xorg-x11-server-1.2.0-9.fc7 --------------------------- * Mon Feb 26 2007 Adam Tkac 1.2.0-9 - Created new package (xorg-x11-server-source) which is needed to build VNC server. * Fri Feb 23 2007 Adam Jackson 1.2.0-8 - xserver-1.2.0-proper-randr-version.patch: Report the RANDR version we actually implement, instead of the version defined by the protocol headers. * Thu Feb 22 2007 Adam Jackson 1.2.0-7 - Various backports from git master: - xserver-1.2.0-xfixes-clientgone-check.patch: Avoids a crash when sending events to clients that just disconnected. - xserver-1.2.0-os-memory-leak.patch: Plugs a per-connection memory leak. - xserver-1.2.0-int10-rdtsc.patch: Implement rdtsc in the int10 emulator. - xserver-1.2.0-glcore-visual-count.patch: Count glcore visuals properly, fixes crash at exit. zenity-2.17.92-1.fc7 -------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 zsh-4.2.6-5.fc7 --------------- * Tue Feb 27 2007 James Antill - 4.2.6-5 - Fix sed typo. - Fix skel expansion problem. - Add Requires for mktemp/info/etc. - Use cp again due to SELinux context. Resolves: rhbz#226813 * Tue Feb 27 2007 James Antill - 4.2.6-4 - Fix buildroot to new Fedora default. - Remove /etc/skel from ownership. - Remove explicit libcap dep. - Tweak postun script. - Move checking to generic rpm infrastructure. Resolves: rhbz#226813 Broken deps for i386 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh devhelp - 0.13-3.fc7.i386 requires gecko-libs = 0:1.8.1.1 frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh yelp - 2.16.2-3.fc7.i386 requires gecko-libs = 0:1.8.1.1 Broken deps for ia64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) devhelp - 0.13-3.fc7.ia64 requires gecko-libs = 0:1.8.1.1 gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel yelp - 2.16.2-3.fc7.ia64 requires gecko-libs = 0:1.8.1.1 Broken deps for ppc ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc requires libgcj.so.7rh devhelp - 0.13-3.fc7.ppc requires gecko-libs = 0:1.8.1.1 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel yelp - 2.16.2-3.fc7.ppc requires gecko-libs = 0:1.8.1.1 Broken deps for ppc64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) devhelp - 0.13-3.fc7.ppc64 requires gecko-libs = 0:1.8.1.1 gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel yelp - 2.16.2-3.fc7.ppc64 requires gecko-libs = 0:1.8.1.1 Broken deps for x86_64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh devhelp - 0.13-3.fc7.i386 requires gecko-libs = 0:1.8.1.1 devhelp - 0.13-3.fc7.x86_64 requires gecko-libs = 0:1.8.1.1 frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh yelp - 2.16.2-3.fc7.x86_64 requires gecko-libs = 0:1.8.1.1 Broken deps for s390 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh devhelp - 0.13-3.fc7.s390 requires gecko-libs = 0:1.8.1.1 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 yelp - 2.16.2-3.fc7.s390 requires gecko-libs = 0:1.8.1.1 Broken deps for s390x ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh cairo-java - 1.0.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) devhelp - 0.13-3.fc7.s390 requires gecko-libs = 0:1.8.1.1 devhelp - 0.13-3.fc7.s390x requires gecko-libs = 0:1.8.1.1 gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel yelp - 2.16.2-3.fc7.s390x requires gecko-libs = 0:1.8.1.1 From rdieter at math.unl.edu Wed Feb 28 12:52:52 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Feb 2007 06:52:52 -0600 Subject: KDE-Live-Spin References: <20070227174339.50469e76@localhost.localdomain> <20070228110747.0ee377ed@localhost.localdomain> <13dbfe4f0702280318y104a4f12l6e6d22ece6625f43@mail.gmail.com> Message-ID: Chitlesh GOORAH wrote: > Rex, who will build the official iso for KDE ? Jessie, most likely (leave that to the pros). (: -- Rex From giallu at gmail.com Wed Feb 28 12:59:20 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 28 Feb 2007 13:59:20 +0100 Subject: yum remove scrollkeeper fails Message-ID: I just tried a: yum remove scrollkeeper this pulled in for removal zenity, but then failed like this: Running Transaction Removing : scrollkeeper ######################### [1/2] Removing : zenity ######################### [2/2] /var/tmp/rpm-tmp.9852: line 1: scrollkeeper-update: command not found error: %postun(zenity-2.16.3-1.fc6.i386) scriptlet failed, exit status 127 because it seems scrollkeeper was removed before the potsun scriptlet run the scrollkeeper-update command. is this something for BZ? if so which component? From jnansi at gmail.com Wed Feb 28 13:01:13 2007 From: jnansi at gmail.com (Jatin Nansi) Date: Wed, 28 Feb 2007 18:31:13 +0530 Subject: naming scheme for fonts packages? In-Reply-To: References: <45E54A39.7030104@redhat.com> Message-ID: <53d4ffb80702280501l553785e1g7493889452a880ee@mail.gmail.com> On 2/28/07, Parag N(????) wrote: > > Hi, > On 2/28/07, Jens Petersen wrote: > > I am currently reviewing a Tibetan font for inclusion in Fedora. > > It is called Tibetan Machine Uni, and we have had a lengthy > > polite discussion on the naming of the package both in and out > > of bugzilla, also with the upstream maintainer. (The project is hosted > > on SourceForge and GPL fwiw). The package was submitted as > > tibetan-machine-uni-fonts, so I suggested fonts-tibetan. However since > > the font is also good for Bhutanese, the submitter and the maintainer > > think fonts-tibetan-dzongkha (bhutanese) would be more appropriate. > +1. I agree with fonts-tibetan-dzongkha-bhutanese package name. > > > > > It occurred to me that we really need some guideline about naming of > > fonts packages. Most of our international fonts follow the naming > > scheme "fonts-*" where "*" is the generally the English name of the > > language, which makes the package pretty easy to find. And the > > remainder are mostly suffixed with "-fonts". Currently in F7T2 there > are: > > > > fonts-ISO8859-2 fonts-KOI8-R fonts-arabic fonts-bengali fonts-chinese > > fonts-gujarati fonts-hebrew fonts-hindi fonts-japanese fonts-kannada > > fonts-korean fonts-malayalam fonts-oriya fonts-punjabi fonts-sinhala > > fonts-tamil fonts-telugu Why not fonts- instead of fonts-. For example, fonts-hindi is also the font used for marathi, nepali, and sanskrit. So just use fonts-devnagri. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 28 13:07:46 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 28 Feb 2007 14:07:46 +0100 Subject: yum remove scrollkeeper fails In-Reply-To: References: Message-ID: <20070228140746.79b0a2a1@python3.es.egwn.lan> Gianluca Sforna wrote : > I just tried a: > > yum remove scrollkeeper > > this pulled in for removal zenity, but then failed like this: > > Running Transaction > Removing : scrollkeeper ######################### [1/2] > Removing : zenity ######################### [2/2] > /var/tmp/rpm-tmp.9852: line 1: scrollkeeper-update: command not found > error: %postun(zenity-2.16.3-1.fc6.i386) scriptlet failed, exit status 127 > > because it seems scrollkeeper was removed before the potsun scriptlet > run the scrollkeeper-update command. > > is this something for BZ? > if so which component? My guess would be that this is a known issue in rpm 4.4.2's erase ordering. I can't seem to find any bugzilla entry for it, though... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.61 0.32 0.22 From mclasen at redhat.com Wed Feb 28 13:12:23 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 28 Feb 2007 08:12:23 -0500 Subject: yum remove scrollkeeper fails In-Reply-To: References: Message-ID: <1172668343.3356.0.camel@dhcp83-33.boston.redhat.com> On Wed, 2007-02-28 at 13:59 +0100, Gianluca Sforna wrote: > I just tried a: > > yum remove scrollkeeper > > this pulled in for removal zenity, but then failed like this: > > Running Transaction > Removing : scrollkeeper ######################### [1/2] > Removing : zenity ######################### [2/2] > /var/tmp/rpm-tmp.9852: line 1: scrollkeeper-update: command not found > error: %postun(zenity-2.16.3-1.fc6.i386) scriptlet failed, exit status 127 > > because it seems scrollkeeper was removed before the potsun scriptlet > run the scrollkeeper-update command. > > is this something for BZ? > if so which component? > rpm, I'd say. From jkeating at redhat.com Wed Feb 28 13:14:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Feb 2007 08:14:50 -0500 Subject: bittorrent downgrade (was: Re: [Fedora Project Wiki] Update of "Extras/RepoRequests" by PaulHowarth) In-Reply-To: <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200702280814.50210.jkeating@redhat.com> On Wednesday 28 February 2007 06:55, Michael Schwendt wrote: > Do we have any policy/guideline with regard to things like this? > > The least thing I'd like to suggest is a warning-mail posted to relevant > mailing lists. We've kicked around some ideas. I like the idea of no broken upgrade paths after the final test release, but up to the final test release one can drop version without invoking epoch. Thoughts? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 28 13:22:01 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 Feb 2007 22:22:01 +0900 Subject: yum remove scrollkeeper fails In-Reply-To: References: Message-ID: <45E581F9.6000400@ioa.s.u-tokyo.ac.jp> Gianluca Sforna wrote: > I just tried a: > > yum remove scrollkeeper > > this pulled in for removal zenity, but then failed like this: > > Running Transaction > Removing : scrollkeeper ######################### [1/2] > Removing : zenity ######################### [2/2] > /var/tmp/rpm-tmp.9852: line 1: scrollkeeper-update: command not found > error: %postun(zenity-2.16.3-1.fc6.i386) scriptlet failed, exit status 127 > This seems to be fixed on rpm-4.4.2-36 on rawhide (related to bz 196590) Mamoru From paul at city-fan.org Wed Feb 28 13:42:01 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 Feb 2007 13:42:01 +0000 Subject: bittorrent downgrade In-Reply-To: <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45E586A9.90608@city-fan.org> Michael Schwendt wrote: > On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: > >> Request removal of broken rawhide bittorrent package so that it can be downgraded without an epoch bump >> >> + >> + * devel bittorrent-5.0.5-2.fc7.src.rpm > > Do we have any policy/guideline with regard to things like this? > > The least thing I'd like to suggest is a warning-mail posted to relevant > mailing lists. I did ask about whether this was OK earlier in the month (http://www.redhat.com/archives/fedora-devel-list/2007-February/msg00514.html) and although there wasn't any direct reply, Jesse did suggest in the thread that downgrades without epoch bumps would be OK by him up to test 3, and I don't recall any dissenting voices. Is an announcement (once the downgrade is done) to fedora-devel-list sufficient, or are there any other appropriate mailing lists deemed relevant? The downgraded package was built and released yesterday, but effectively never made it into the repo because the existing broken package has a higher EVR. Once the existing package is nuked, will I need to resubmit a build request for the downgrade package, and will I need to bump the release to avoid an "invalid build" since it's already been built and "released" before? Paul. From david at lovesunix.net Wed Feb 28 14:33:35 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 28 Feb 2007 15:33:35 +0100 Subject: bittorrent downgrade (was: Re: [Fedora Project Wiki] Update of "Extras/RepoRequests" by PaulHowarth) In-Reply-To: <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1172673215.3982.0.camel@dawkins> ons, 28 02 2007 kl. 12:55 +0100, skrev Michael Schwendt: > On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: > > > Request removal of broken rawhide bittorrent package so that it can be downgraded without an epoch bump > > > > + > > + * devel bittorrent-5.0.5-2.fc7.src.rpm > > Do we have any policy/guideline with regard to things like this? > > The least thing I'd like to suggest is a warning-mail posted to relevant > mailing lists. I might have missed this but why are we downgrading bittorrent (outside of the gui throwing a segfault on startup). - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From katzj at redhat.com Wed Feb 28 14:39:17 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 Feb 2007 09:39:17 -0500 Subject: KDE-Live-Spin In-Reply-To: <20070228125316.5737fddf@localhost.localdomain> References: <20070227174339.50469e76@localhost.localdomain> <20070228110747.0ee377ed@localhost.localdomain> <13dbfe4f0702280318y104a4f12l6e6d22ece6625f43@mail.gmail.com> <20070228125316.5737fddf@localhost.localdomain> Message-ID: <1172673557.19660.2.camel@aglarond.local> On Wed, 2007-02-28 at 12:53 +0100, Sebastian Vahl wrote: > > Sebastian, file a bug if you haven't yet. It may happens that you are > > not the only one. > > No, I'm not. And the bug is already filed: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=Fedora7LiveCD > Just forgotten to put the link in the first mail (in [1]). This is just a tracking bug. Putting comments there doesn't help to solve problems. Filing bugs and make them block the bug, on the other hand, makes sure that each individual bug can be tracked. Jeremy From jonathan.underwood at gmail.com Wed Feb 28 14:46:19 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 28 Feb 2007 14:46:19 +0000 Subject: bittorrent downgrade (was: Re: [Fedora Project Wiki] Update of "Extras/RepoRequests" by PaulHowarth) In-Reply-To: <1172673215.3982.0.camel@dawkins> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> <1172673215.3982.0.camel@dawkins> Message-ID: <645d17210702280646h45ccdf21w4aca62dcb992cdd0@mail.gmail.com> n 28/02/07, David Nielsen wrote: > ons, 28 02 2007 kl. 12:55 +0100, skrev Michael Schwendt: > > On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: > > > > > Request removal of broken rawhide bittorrent package so that it can be downgraded without an epoch bump > > > > > > + > > > + * devel bittorrent-5.0.5-2.fc7.src.rpm > > > > Do we have any policy/guideline with regard to things like this? > > > > The least thing I'd like to suggest is a warning-mail posted to relevant > > mailing lists. > > I might have missed this but why are we downgrading bittorrent (outside > of the gui throwing a segfault on startup). > Not sure, but I notice there's a newer version (5.0.6) of bittorrent available, that may or may not address the reason why 5.0.5 is being dropped: http://download.bittorrent.com/dl/BitTorrent-5.0.6.tar.gz Jonathan. From paul at city-fan.org Wed Feb 28 14:46:47 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 Feb 2007 14:46:47 +0000 Subject: bittorrent downgrade In-Reply-To: <1172673215.3982.0.camel@dawkins> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> <1172673215.3982.0.camel@dawkins> Message-ID: <45E595D7.6050200@city-fan.org> David Nielsen wrote: > ons, 28 02 2007 kl. 12:55 +0100, skrev Michael Schwendt: >> On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: >> >>> Request removal of broken rawhide bittorrent package so that it can be downgraded without an epoch bump >>> >>> + >>> + * devel bittorrent-5.0.5-2.fc7.src.rpm >> Do we have any policy/guideline with regard to things like this? >> >> The least thing I'd like to suggest is a warning-mail posted to relevant >> mailing lists. > > I might have missed this but why are we downgrading bittorrent (outside > of the gui throwing a segfault on startup). That's not a good enough reason is it? Paul. From paul at city-fan.org Wed Feb 28 15:00:09 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 Feb 2007 15:00:09 +0000 Subject: bittorrent downgrade In-Reply-To: <645d17210702280646h45ccdf21w4aca62dcb992cdd0@mail.gmail.com> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> <1172673215.3982.0.camel@dawkins> <645d17210702280646h45ccdf21w4aca62dcb992cdd0@mail.gmail.com> Message-ID: <45E598F9.5040508@city-fan.org> Jonathan Underwood wrote: > n 28/02/07, David Nielsen wrote: >> ons, 28 02 2007 kl. 12:55 +0100, skrev Michael Schwendt: >> > On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: >> > >> > > Request removal of broken rawhide bittorrent package so that it >> can be downgraded without an epoch bump >> > > >> > > + >> > > + * devel bittorrent-5.0.5-2.fc7.src.rpm >> > >> > Do we have any policy/guideline with regard to things like this? >> > >> > The least thing I'd like to suggest is a warning-mail posted to >> relevant >> > mailing lists. >> >> I might have missed this but why are we downgrading bittorrent (outside >> of the gui throwing a segfault on startup). >> > > Not sure, but I notice there's a newer version (5.0.6) of bittorrent > available, that may or may not address the reason why 5.0.5 is being > dropped: > > http://download.bittorrent.com/dl/BitTorrent-5.0.6.tar.gz Whilst there are some changes in the logging code that causes the segfault in 5.0.5, 5.0.6 still segfaults with wxPython 2.8. Paul. From david at lovesunix.net Wed Feb 28 15:05:42 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 28 Feb 2007 16:05:42 +0100 Subject: bittorrent downgrade In-Reply-To: <45E595D7.6050200@city-fan.org> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> <1172673215.3982.0.camel@dawkins> <45E595D7.6050200@city-fan.org> Message-ID: <1172675142.5355.2.camel@dawkins> ons, 28 02 2007 kl. 14:46 +0000, skrev Paul Howarth: > David Nielsen wrote: > > ons, 28 02 2007 kl. 12:55 +0100, skrev Michael Schwendt: > >> On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: > >> > >>> Request removal of broken rawhide bittorrent package so that it can be downgraded without an epoch bump > >>> > >>> + > >>> + * devel bittorrent-5.0.5-2.fc7.src.rpm > >> Do we have any policy/guideline with regard to things like this? > >> > >> The least thing I'd like to suggest is a warning-mail posted to relevant > >> mailing lists. > > > > I might have missed this but why are we downgrading bittorrent (outside > > of the gui throwing a segfault on startup). > > That's not a good enough reason is it? I would consider it a good reason to file bugs.. I was wondering if the license changed or something which would be the only reason I could come up with. - David -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From paul at city-fan.org Wed Feb 28 15:13:35 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 Feb 2007 15:13:35 +0000 Subject: bittorrent downgrade In-Reply-To: <1172675142.5355.2.camel@dawkins> References: <20070228083838.32206.44190@app2.fedora.phx.redhat.com> <20070228125513.986cb4db.mschwendt.tmp0701.nospam@arcor.de> <1172673215.3982.0.camel@dawkins> <45E595D7.6050200@city-fan.org> <1172675142.5355.2.camel@dawkins> Message-ID: <45E59C1F.3090209@city-fan.org> David Nielsen wrote: > ons, 28 02 2007 kl. 14:46 +0000, skrev Paul Howarth: >> David Nielsen wrote: >>> ons, 28 02 2007 kl. 12:55 +0100, skrev Michael Schwendt: >>>> On Wed, 28 Feb 2007 08:38:38 -0000, fedorawiki wrote: >>>> >>>>> Request removal of broken rawhide bittorrent package so that it can be downgraded without an epoch bump >>>>> >>>>> + >>>>> + * devel bittorrent-5.0.5-2.fc7.src.rpm >>>> Do we have any policy/guideline with regard to things like this? >>>> >>>> The least thing I'd like to suggest is a warning-mail posted to relevant >>>> mailing lists. >>> I might have missed this but why are we downgrading bittorrent (outside >>> of the gui throwing a segfault on startup). >> That's not a good enough reason is it? > > I would consider it a good reason to file bugs.. I was wondering if the > license changed or something which would be the only reason I could come > up with. Bugs have been filed, but upstream is not working with wxPython 2.8 so there's little prospect of it working before FC7 is released. Hence the downgrade back to 4.4.0, which does work. Paul. From chitlesh at fedoraproject.org Wed Feb 28 15:19:37 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 28 Feb 2007 16:19:37 +0100 Subject: Experimental KDE 3.80.3 specfiles (now SRPMs too) In-Reply-To: References: Message-ID: <13dbfe4f0702280719v679d1f5en7fa93330b6e39ced@mail.gmail.com> On 2/23/07, Kevin Kofler wrote: > I hope these will make their way into the kde-redhat unstable repo soon. Hello, Great work Kevin. I've rebuilt those 3 src.rpms with QA_RPATHS=0x0003; export QA_RPATHS; rpmbuild -ba kdebase4.spec but I have a crashed after 10 seconds on login. I would like to know how you exported your QA_RPATHS. thanks, Chitlesh -- http://clunixchit.blogspot.com From kevin.kofler at chello.at Wed Feb 28 16:46:42 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 28 Feb 2007 16:46:42 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles (now SRPMs too) References: <13dbfe4f0702280719v679d1f5en7fa93330b6e39ced@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > I've rebuilt those 3 src.rpms with > QA_RPATHS=0x0003; export QA_RPATHS; rpmbuild -ba kdebase4.spec > > but I have a crashed after 10 seconds on login. > > I would like to know how you exported your QA_RPATHS. I just built it on a live system, I didn't have any QA_RPATHS to set at all. But this issue is not related to QA_RPATHS. It's some plain old bug which prevents full sessions from working. Sebastian Vahl had the same happen to him. Running some KDE 4 apps in a KDE 3 session does work, but Konqueror only works if you pass a URL to load (otherwise it crashes), and KControl crashes too (but kcmshell works, so you can use that to do configuration). Don't forget that this is a developer snapshot, it's not quite ready for full-time use. Kevin Kofler From vonbrand at inf.utfsm.cl Wed Feb 28 17:03:48 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 28 Feb 2007 14:03:48 -0300 Subject: Halfway populated mirrors, broken package lists? Message-ID: <16209.1172682228@laptop13.inf.utfsm.cl> When trying to update today (rawhide on i686) yum got kernel-devel, but no other kernel-* package, emacs-common is there but yum doesn't know about it, and others (yes, they are at download.redhat.com, and I'm getting it from there via "rpm -ihv http://..." right now). There are lots of -devel packages missing. Was createrepo run halfway through the updating of the site perhaps? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From wwoods at redhat.com Wed Feb 28 17:08:12 2007 From: wwoods at redhat.com (Will Woods) Date: Wed, 28 Feb 2007 17:08:12 +0000 Subject: Halfway populated mirrors, broken package lists? In-Reply-To: <16209.1172682228@laptop13.inf.utfsm.cl> References: <16209.1172682228@laptop13.inf.utfsm.cl> Message-ID: <1172682492.19600.9.camel@metroid.rdu.redhat.com> On Wed, 2007-02-28 at 14:03 -0300, Horst H. von Brand wrote: > When trying to update today (rawhide on i686) yum got kernel-devel, but > no other kernel-* package, emacs-common is there but yum doesn't know > about it, and others (yes, they are at download.redhat.com, and I'm > getting it from there via "rpm -ihv http://..." right now). There are > lots of -devel packages missing. Was createrepo run halfway through the > updating of the site perhaps? Yeah, there's currently some metadata badness on i386 (x86_64 seems to be OK, haven't checked ppc.) Jesse's working on rebuilding the metadata and such for rawhide right now. I'm not sure how long it will take to make it to the mirrors, but A Fix Is On The Way. See also: http://bugzilla.redhat.com/230365 -w -------------- 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 david at lovesunix.net Wed Feb 28 17:51:26 2007 From: david at lovesunix.net (David Nielsen) Date: Wed, 28 Feb 2007 18:51:26 +0100 Subject: Halfway populated mirrors, broken package lists? In-Reply-To: <1172682492.19600.9.camel@metroid.rdu.redhat.com> References: <16209.1172682228@laptop13.inf.utfsm.cl> <1172682492.19600.9.camel@metroid.rdu.redhat.com> Message-ID: <1172685086.5355.23.camel@dawkins> ons, 28 02 2007 kl. 17:08 +0000, skrev Will Woods: > On Wed, 2007-02-28 at 14:03 -0300, Horst H. von Brand wrote: > > When trying to update today (rawhide on i686) yum got kernel-devel, but > > no other kernel-* package, emacs-common is there but yum doesn't know > > about it, and others (yes, they are at download.redhat.com, and I'm > > getting it from there via "rpm -ihv http://..." right now). There are > > lots of -devel packages missing. Was createrepo run halfway through the > > updating of the site perhaps? > > Yeah, there's currently some metadata badness on i386 (x86_64 seems to > be OK, haven't checked ppc.) x86_64 seems bad here.. guess I'll wait for that update. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From buildsys at redhat.com Wed Feb 28 19:47:25 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 28 Feb 2007 14:47:25 -0500 Subject: rawhide report: 20070228 changes Message-ID: <200702281947.l1SJlPx9016955@hs20-bc2-6.build.redhat.com> Updated Packages: a2ps-4.13b-61.fc7 ----------------- * Wed Feb 28 2007 Tim Waugh 4.13b-61 - Clean up tmpdir in pdiff (bug #214400). - Fixed permissions on C source files (bug #225235). - Use %configure (bug #225235). - Preserve timestamps (bug #225235). - Use smp_mflags (bug #225235). - Requires install-info for post and preun scriptlets (bug #225235). - Avoid tabs (bug #225235). - Explicity versioning for obsoletes/provides (bug #225235). - PreReq->Requires(post) (bug #225235). - Fixed macros in changelog (bug #225235). - Fixed summary (bug #225235). - Converted spec file to UTF-8 (bug #225235). - Fixed build root (bug #225235). - Remove ExcludeArch (bug #225235). - Use buildroot macro consistently (bug #225235). - Don't ship the library file or header (bug #203536). apr-util-1.2.8-4 ---------------- * Wed Feb 28 2007 Joe Orton 1.2.8-4 - add mysql driver in -mysql subpackage (Bojan Smojver, #222237) cdrtools-9:2.01-11.fc7 ---------------------- * Wed Feb 28 2007 Harald Hoyer - 9:2.01-11.fc7 - specfile review devhelp-0.13-4.fc7 ------------------ * Wed Feb 28 2007 Matthew Barnes - 0.13-4 - Rebuild against newer gecko. dialog-1.1-1.20070227svn.fc7 ---------------------------- * Wed Feb 28 2007 Harald Hoyer - 1.1-1.20070227svn.fc7 - version 1.1-20070227 - added devel subpackage - specfile fixes (bug#225693) - Resolves: rhbz#225693 f-spot-0.3.4-1.fc7 ------------------ * Wed Feb 28 2007 Matthias Clasen - 0.3.4-1 - Update to 0.3.4 gdm-1:2.17.8-1.fc7 ------------------ * Wed Feb 28 2007 Matthias Clasen - 1:2.17.8-1 - Update to 2.17.8 gnome-python2-desktop-2.17.93-1.fc7 ----------------------------------- * Wed Feb 28 2007 Matthias Clasen - 2.17.93-1 - Update to 2.17.93 gnome-screensaver-2.17.8-1.fc7 ------------------------------ * Wed Feb 28 2007 Ray Strode - 2.17.8-1 - Update to 2.17.8 (Matthias) - Drop obsolete patches (Matthias) - rework smart card patch gnome-themes-2.17.92-1.fc7 -------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 gok-1.2.2-1.fc7 --------------- * Tue Feb 27 2007 Matthias Clasen - 1.2.2-1 - Update to 1.2.2 libart_lgpl-2.3.19-1.fc7 ------------------------ * Wed Feb 28 2007 Matthias Clasen - 2.3.19-1 - Update to 2.3.19 libbtctl-0.8.2-3.fc7 -------------------- * Wed Feb 28 2007 Harald Hoyer - 0.8.2-3.fc7 - specfile review - portet crash patch to 0.8.2 * Thu Dec 07 2006 Jeremy Katz - 0.8.2-2.fc7 - rebuild for python 2.5 * Mon Nov 13 2006 Harald Hoyer - 0.8.2-1.fc7 - version 0.8.2 - Resolves: rhbz#215230 mod_perl-2.0.3-7 ---------------- * Wed Feb 28 2007 Joe Orton 2.0.3-7 - also restore Apache::Test to devel - add BR for perl-devel openswan-2.4.7-2.fc7 -------------------- * Wed Feb 28 2007 Harald Hoyer - 2.4.7-2.fc7 - specfile review shadow-utils-2:4.0.18.1-10.fc7 ------------------------------ * Wed Feb 28 2007 Peter Vrabec 2:4.0.18.1-10 - spec file fixes to meet fedora standarts. - fix useless call of restorecon(). (#222159) tn5250-0.17.3-14.fc7 -------------------- * Wed Feb 28 2007 Karsten Hopp 0.17.3-14 - copy readme instead of moving it - fix desktop file - fix scriptlets vixie-cron-4:4.1-75.fc7 ----------------------- * Wed Feb 28 2007 Marcela Maslanova - 4:4.1-75 - rhbz#226529 merge review yelp-2.16.2-5.fc7 ----------------- * Wed Feb 28 2007 Matthew Barnes - 2.16.2-5 - Rebuild against newer gecko. * Fri Feb 23 2007 Matthias Clasen 2.16.2-4 - Don't own /usr/share/icons/hicolor Broken deps for s390 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh Broken deps for x86_64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.x86_64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) Broken deps for ia64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for ppc64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel Broken deps for ppc ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel Broken deps for s390x ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh cairo-java - 1.0.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.s390x requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel From rafael.espindola at gmail.com Wed Feb 28 19:57:32 2007 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Wed, 28 Feb 2007 11:57:32 -0800 Subject: Synaptics touchpad doesn't work on a mac book pro In-Reply-To: <564d96fb0702271928i5b0f36ccm937ab9f9a9fac017@mail.gmail.com> References: <564d96fb0702260700u710f93f6j79e9141133cfb217@mail.gmail.com> <1172521264.7161.21.camel@dipsy> <564d96fb0702262030j1468bd42v18ef8438f94eb885@mail.gmail.com> <1172562512.7161.50.camel@dipsy> <564d96fb0702270638g444fef74r1d0de7fce7ba2e5e@mail.gmail.com> <1172603563.7161.89.camel@dipsy> <564d96fb0702271350q206d4188vd04a6dbab0960e0e@mail.gmail.com> <564d96fb0702271928i5b0f36ccm937ab9f9a9fac017@mail.gmail.com> Message-ID: <564d96fb0702281157m3ca9480cue5729d5d812de527@mail.gmail.com> > It is on the 2.6.20 kernel already :-) > > rpmbuilding it right now I have a kernel panic during boot :-(. Using acpi=off solves the problem. The appletouch module is auto loads and the X synaptic driver kinda of works. It halts from time to time. Looks like it is missing interrupts... I will try to backport the patches to the 2.6.19 fc6 kernel to isolate the problem. Rafael From ml at deadbabylon.de Wed Feb 28 20:08:25 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 28 Feb 2007 21:08:25 +0100 Subject: KDE-Live-Spin In-Reply-To: <1172673557.19660.2.camel@aglarond.local> References: <20070227174339.50469e76@localhost.localdomain> <20070228110747.0ee377ed@localhost.localdomain> <13dbfe4f0702280318y104a4f12l6e6d22ece6625f43@mail.gmail.com> <20070228125316.5737fddf@localhost.localdomain> <1172673557.19660.2.camel@aglarond.local> Message-ID: <20070228210825.01f5fa95@localhost.localdomain> Am Wed, 28 Feb 2007 09:39:17 -0500 schrieb Jeremy Katz : > On Wed, 2007-02-28 at 12:53 +0100, Sebastian Vahl wrote: > > > Sebastian, file a bug if you haven't yet. It may happens that you > > > are not the only one. > > > > No, I'm not. And the bug is already filed: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=Fedora7LiveCD > > Just forgotten to put the link in the first mail (in [1]). > > This is just a tracking bug. Putting comments there doesn't help to > solve problems. Filing bugs and make them block the bug, on the other > hand, makes sure that each individual bug can be tracked. Ok. I`ve found the normal bug and answered there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227734 When I replied to the tracking bug yesterday this one was not blocking it. And because there were other answer I replied to it to. Sorry for that. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From petersen at redhat.com Wed Feb 28 23:21:40 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 01 Mar 2007 09:21:40 +1000 Subject: naming scheme for fonts packages? In-Reply-To: <53d4ffb80702280501l553785e1g7493889452a880ee@mail.gmail.com> References: <45E54A39.7030104@redhat.com> <53d4ffb80702280501l553785e1g7493889452a880ee@mail.gmail.com> Message-ID: <45E60E84.5010006@redhat.com> Jatin Nansi wrote: > Why not fonts- instead of fonts-. For > example, fonts-hindi is also the font used for marathi, nepali, and > sanskrit. So just use fonts-devnagri. Right, I do agree with that. We really need to distinguish the (spoken/written) language from the script itself. And some languages can also be written in more than one script for example. (Which is why I still rather like the name fonts-tibetan for the Tibetan script fonts.) Having said that, using script names rather than language names does make the naming a little less obvious to non-native users and developers. But I see that as less of a problem since normal users shouldn't really have to worry about the names of fonts packages for languages but just use pirut to add appropriate language support. Jens From michel.salim at gmail.com Wed Feb 28 23:23:49 2007 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 28 Feb 2007 18:23:49 -0500 Subject: Fedora power management In-Reply-To: <1171894456.3005.2.camel@aglarond.local> References: <20070218213051.388fd6c0@osprey.hogchain.net> <1171876270.4839.3.camel@hughsie-laptop> <20070219071123.491bb0ac@osprey.hogchain.net> <1171894456.3005.2.camel@aglarond.local> Message-ID: <883cfe6d0702281523q58d11af3gc973d2041ad6b983@mail.gmail.com> 2007/2/19, Jeremy Katz : > On Mon, 2007-02-19 at 07:11 -0600, Jay Cliburn wrote: > > On Mon, 19 Feb 2007 09:11:10 +0000 > > Richard Hughes wrote: > > > Well, there's a link to quite an old presentation I wrote > > > > > I've also attached the pm-utils README file from CVS which might help. > > > > Thanks a lot for this info Richard. I really appreciate it. > > > > So to make my nic driver suspend (instead of being removed with > > "modprobe -r"), I need only add the module name to the SUSPEND_MODULES > > line of /etc/pm/config? Like this? (my driver name is atl1) > > The default is for the driver to be suspended normally; SUSPEND_MODULES > is to list (broken) modules that have to be removed and reinserted > around the suspend process. > Speaking of SUSPEND_MODULES, there seems to be a bug in /etc/pm/functions that causes the parsing to fail if more than one modules are listed (in my case, /etc/pm/config lists "button", but I need to have it unload ath_pci as well) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230488 -- Michel Salim http://hircus.wordpress.com/ From petersen at redhat.com Wed Feb 28 23:29:28 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 01 Mar 2007 09:29:28 +1000 Subject: [Fedora-i18n-list] Re: naming scheme for fonts packages? In-Reply-To: <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> Message-ID: <45E61058.1020801@redhat.com> Hi, Thanks for the followup. Nicolas Mailhot wrote: > fonts-foo are usually a mashup of fonts for a specific encoding, and > foo-fonts fonts with distinct style that may span several languages areas. Well the prospect of good free fonts with really wide unicode glyph coverage is not something that is going to happen anytime soon I'm afraid. Having lived 12 years in Japan my perspective is probably a bit different from many Fedora developers. We really really need those fonts-* packages for Asian languages and scripts. :) And as a data-point the big desktop OSs also ship lots of separate fonts for them AFAIK. > To be honest I'm not too fond of foo-font packages. Sorry, did you mean "fonts-*"? > They're a necessary 8-bit legacy stopgap, but I'd rather have vibrant font projects competing > on quality and international coverage. You don't get that if you bundle > different upstreams in neutraly named packages. (the fact that FC was more > fonts-foo and FE foo-fonts reflects a rather utilitarian view of fonts > RH-side, and the huge weight of the fossilized fonts sourced from > xfree86/xorg) I agree with you for fonts for Western languages for which it is possible to have reasonable coverage with limited resources. > IMHO (which if worth what it's worth) you're not packaging generic fonts > for tibetan but a specific font project, and it deserves name recognition > just like any other upstream. So upstreamname-fonts seems more respectful > for me. Also have you though of what will happen should someone want to > package another tibetan font in a few months ? Well in the review we are actually now discussing putting two GPL Tibetan fonts in the same package if it is going by the generic language name. Jens From mailinglists at erwinrol.com Wed Feb 28 23:34:09 2007 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 01 Mar 2007 00:34:09 +0100 Subject: *-devel.x86_64 Message-ID: <1172705649.10428.73.camel@lat.home.erwinrol.com> What happened to a lot of devel.x86_64 packages. For example i can't compile X11 apps that use pkg-config anymore because things like xproto.pc only exist in /usr/lib/pkgconfig/ and not in /usr/lib64/pkgconfig/, but /usr/lib64/pkgconfig/x11.pc has a require xproto. Any idea what happend here, i already tried to install .x86_64 versions but they are just not available. TIA, Erwin From axel.azerty at laposte.net Wed Feb 28 23:59:24 2007 From: axel.azerty at laposte.net (Axel) Date: Thu, 01 Mar 2007 00:59:24 +0100 Subject: kernels oops - bug report Message-ID: <45E6175C.8040805@laposte.net> Hello I d like to report a kernel oops, but I don't know how to catch the kernel log. After an upgrade to kernel 2.6.19-1.2911, the system crashes at boot. I didn't had this problem with 2.6.19-1.2895 version. I didn't found such a bug in the bugzilla. Is it possible to save the stacktrace in order to fill a bug report ? How can I do that ? Thanks in advance. Regards.