From jnovy at redhat.com Fri Dec 1 08:55:32 2006 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 01 Dec 2006 09:55:32 +0100 Subject: compat-db and db4 is now (finally) updated Message-ID: <1164963332.3676.1.camel@redhat.usu> Hi all, this is just a heads-up that compat-db and db4 is now updated. It means that db4.3.29 together with db4.2.52 is now part of compat-db-4.3.29 and db4 is now updated to 4.5.20. If your package has a dependency on libdb-4.3.so or libdb_cxx-4.3.so (list attached) then it became dependent on compat-db since yesterday. Thus if your package Buildrequires: db4-devel, it will be linked against db4.5 libraries in your next build. If you don't want to, switch to BuildRequires: compat-db (or the libraries directly) and update spec accordingly if your package still needs to be built against 4.3 or 4.2 db for some reason. compat-db contains header files for db4.3 and db4.2 (in %{_includedir}/db4.3.29 and %{_includedir}/db4.2.52) so there shouldn't be problem to build packages against say db4.2 if you have problems with higher version dbs (netatalk, etc.) Jindrich -------------- next part -------------- Direct db4 library dependencies: p: libdb-4.3.so <- postfix-2.3.4-1 [development] p: libdb_cxx-4.3.so <- kdeaddons-3.5.5-0.1.fc6 [development] p: libdb-4.3.so <- kdesdk-3.5.5-0.1.fc6 [development] p: libdb-4.3.so <- kdevelop-3.3.5-0.1.fc6 [development] p: libdb-4.3.so <- openoffice.org-core-2.1.0-5.5 [development] p: libdb-4.3.so <- apr-util-1.2.7-4 [development] p: libdb-4.3.so <- httpd-2.2.3-6 [development] p: libdb-4.3.so <- iproute-2.6.18-3.fc7 [development] p: libdb-4.3.so <- perl-5.8.8 [development] p: libdb-4.3.so <- subversion-1.4.2-3 [development] p: libdb-4.3.so <- netatalk-2.0.3-7.fc6 [development] p: libdb-4.3.so <- php-cli-5.2.0-7 [development] p: libdb-4.3.so <- evolution-data-server-1.9.2-3.fc7 [development] p: libdb-4.3.so <- php-dba-5.2.0-7 [development] p: libdb-4.3.so <- sendmail-8.13.8-3 [development] p: libdb-4.3.so <- mod_perl-2.0.2-6.1 [development] p: libdb-4.3.so <- webalizer-2.01_10-30.1 [development] p: libdb-4.3.so <- python-2.4.4-1.fc7 [development] p: libdb-4.3.so <- libetpan-0.48-1.fc7 [extras-development] p: libdb-4.3.so <- pam_abl-0.2.3-2.fc6 [extras-development] p: libdb-4.3.so <- nmh-1.1-19.fc6 [extras-development] p: libdb-4.3.so <- squidGuard-1.2.0-14.fc6 [extras-development] p: libdb-4.3.so <- jigdo-0.7.3-3.fc7 [extras-development] p: libdb-4.3.so <- gift-openft-0.2.1.6-3.fc6 [extras-development] p: libdb-4.3.so <- perl-BerkeleyDB-0.31-2.fc6 [extras-development] p: libdb-4.3.so <- exim-4.63-5.fc6 [extras-development] p: libdb-4.3.so <- poedit-1.3.6-1.1.fc7 [extras-development] p: libdb_cxx-4.3.so <- xca-0.5.1-6.fc6 [extras-development] p: libdb-4.3.so <- clisp-2.41-1.fc6 [extras-development] p: libdb-4.3.so <- cfengine-2.1.21-3.fc7 [extras-development] p: libdb-4.3.so <- libapreq2-2.09-0.rc2.1.fc7 [extras-development] p: libdb-4.3.so <- sylpheed-claws-plugins-pgp-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- sylpheed-claws-plugins-bogofilter-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- sylpheed-claws-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- compat-libgda-1.2.3-4.fc6 [extras-development] p: libdb-4.3.so <- sylpheed-claws-plugins-dillo-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- bogofilter-1.0.3-1.fc6 [extras-development] p: libdb-4.3.so <- perl-libapreq2-2.09-0.rc2.1.fc7 [extras-development] p: libdb-4.3.so <- perl-eperl-2.2.14-3.fc6 [extras-development] p: libdb-4.3.so <- sylpheed-claws-plugins-clamav-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- sylpheed-claws-plugins-spamassassin-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- jabberd-2.0-0.s11.11.fc6 [extras-development] p: libdb-4.3.so <- libgda-1.9.100-10.fc6 [extras-development] p: libdb-4.3.so <- rapidsvn-0.9.3-2.fc6 [extras-development] p: libdb-4.3.so <- sylpheed-claws-plugins-maildir-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- sylpheed-claws-plugins-etpan-privacy-2.6.0-1.fc7 [extras-development] p: libdb-4.3.so <- cyrus-imapd-2.3.7-4.fc6 [extras-development] p: libdb-4.3.so <- cyrus-imapd-utils-2.3.7-4.fc6 [extras-development] p: libdb-4.3.so <- ruby-bdb-0.6.0-1.fc7 [extras-development] Other db4 dependencies: P: db4 <- pam_ccreds-3-5 [development] P: db4-devel <- apr-util-devel-1.2.7-4 [development] P: db4-utils <- cyrus-imapd-2.3.7-4.fc6 [extras-development] P: db4-devel <- libetpan-devel-0.48-1.fc7 [extras-development] P: db4-devel <- compat-libgda-devel-1.2.3-4.fc6 [extras-development] P: db4-devel <- libgda-devel-1.9.100-10.fc6 [extras-development] From mlichvar at redhat.com Fri Dec 1 08:56:54 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 1 Dec 2006 09:56:54 +0100 Subject: libtermcap => libncurses In-Reply-To: <456F03AE.2090100@kobold.org> References: <20061130144515.GA9862@localhost> <456F03AE.2090100@kobold.org> Message-ID: <20061201085654.GC19280@localhost> On Thu, Nov 30, 2006 at 08:15:42AM -0800, Wart wrote: > This list is missing 'readline-devel'. The base 'readline' package does > not require libtermcap, but if you look at the spec file, you'll see > that 'readline-devel' Requires: libtermcap-devel. This means that any > package that has a BR: readline-devel likely gets linked with and ends > up with an implicit Requires: on libtermcap... readline-devel-5.2-2.fc7 requires ncurses-devel. -- Miroslav Lichvar From buildsys at fedoraproject.org Fri Dec 1 10:21:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 1 Dec 2006 05:21:44 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-01 Message-ID: <20061201102144.A8FA815212E@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) UNKNOWN OWNER (possibly Core package): audit FC5-updates > FC7 (0:1.3-2.fc5 > 0:1.3-1.fc7) FC6-updates > FC7 (0:1.3-2.fc6 > 0:1.3-1.fc7) authconfig FC6-updates > FC7 (0:5.3.12-1.fc6 > 0:5.3.10-1) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) gnome-netstatus FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libvirt FC5-updates > FC6 (0:0.1.7-3.FC5 > 0:0.1.7-2) libxml2 FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) system-config-soundcard FC6-updates > FC7 (0:2.0.5-2.fc6 > 0:2.0.5-1.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) ch.nolte AT fh-wolfenbuettel.de: kbibtex FE4 > FE6 (0:0.1.5-3.fc4 > 0:0.1.5-1.fc6) FE4 > FE7 (0:0.1.5-3.fc4 > 0:0.1.5-2.fc7) FE5 > FE6 (0:0.1.5-3.fc5 > 0:0.1.5-1.fc6) FE5 > FE7 (0:0.1.5-3.fc5 > 0:0.1.5-2.fc7) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) ---------------------------------------------------------------------- audit: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.3-2.fc5 > 0:1.3-1.fc7) FC6-updates > FC7 (0:1.3-2.fc6 > 0:1.3-1.fc7) authconfig: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:5.3.12-1.fc6 > 0:5.3.10-1) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gnome-netstatus: UNKNOWN OWNER (possibly Core package) FC6 > FC7 (0:2.12.0-5.1 > 0:2.12.0-5.fc7) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kbibtex: ch.nolte AT fh-wolfenbuettel.de FE4 > FE6 (0:0.1.5-3.fc4 > 0:0.1.5-1.fc6) FE4 > FE7 (0:0.1.5-3.fc4 > 0:0.1.5-2.fc7) FE5 > FE6 (0:0.1.5-3.fc5 > 0:0.1.5-1.fc6) FE5 > FE7 (0:0.1.5-3.fc5 > 0:0.1.5-2.fc7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-3.FC5 > 0:0.1.7-2) libxml2: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) smart: Axel.Thimm AT ATrpms.net FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) system-config-soundcard: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.0.5-2.fc6 > 0:2.0.5-1.fc7) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From deisenst at gtw.net Sat Dec 2 10:03:41 2006 From: deisenst at gtw.net (David D. Eisenstein) Date: Sat, 02 Dec 2006 04:03:41 -0600 Subject: Seamonkey for fc4 In-Reply-To: <20061130144515.GA9862@localhost> References: <20061130144515.GA9862@localhost> Message-ID: <45714F7D.6000501@gtw.net> Trying to build seamonkey for fc4. x86_64 build errors. Any clues? Thanks. Warm regards, David Eisenstein From deisenst at gtw.net Sat Dec 2 10:12:06 2006 From: deisenst at gtw.net (David D. Eisenstein) Date: Sat, 02 Dec 2006 04:12:06 -0600 Subject: Seamonkey for fc4 Message-ID: <45715176.9080907@gtw.net> David D. Eisenstein wrote: > Trying to build seamonkey for fc4. x86_64 build errors. Any clues? > > Thanks. > > Warm regards, > David Eisenstein > Oops--- here is the URL: http://turbosphere.fedoralegacy.org/logs/fedora-4-core/187-seamonkey-1.0.6-0.3.fc4/x86_64/ Thanks! -David From deisenst at gtw.net Sat Dec 2 10:05:21 2006 From: deisenst at gtw.net (David D. Eisenstein) Date: Sat, 02 Dec 2006 04:05:21 -0600 Subject: Seamonkey for fc4 In-Reply-To: <45714F7D.6000501@gtw.net> References: <20061130144515.GA9862@localhost> <45714F7D.6000501@gtw.net> Message-ID: <45714FE1.5090802@gtw.net> David D. Eisenstein wrote: > Trying to build seamonkey for fc4. x86_64 build errors. Any clues? > > Thanks. > > Warm regards, > David Eisenstein > Oops--- here is the URL: http://turbosphere.fedoralegacy.org/logs/fedora-4-core/187-seamonkey-1.0.6-0.3.fc4/x86_64/ Thanks! -David From buildsys at fedoraproject.org Sat Dec 2 11:25:01 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 2 Dec 2006 06:25:01 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-02 Message-ID: <20061202112501.E22E415212E@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libvirt FC5-updates > FC6 (0:0.1.7-3.FC5 > 0:0.1.7-2) libxml2 FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) ch.nolte AT fh-wolfenbuettel.de: kbibtex FE4 > FE6 (0:0.1.5-3.fc4 > 0:0.1.5-1.fc6) FE4 > FE7 (0:0.1.5-3.fc4 > 0:0.1.5-2.fc7) FE5 > FE6 (0:0.1.5-3.fc5 > 0:0.1.5-1.fc6) FE5 > FE7 (0:0.1.5-3.fc5 > 0:0.1.5-2.fc7) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) rdieter AT math.unl.edu: gnupg2 FE6 > FE7 (0:2.0.1-1.fc6 > 0:2.0.1-0.3.rc1.fc7) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gnupg2: rdieter AT math.unl.edu FE6 > FE7 (0:2.0.1-1.fc6 > 0:2.0.1-0.3.rc1.fc7) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kbibtex: ch.nolte AT fh-wolfenbuettel.de FE4 > FE6 (0:0.1.5-3.fc4 > 0:0.1.5-1.fc6) FE4 > FE7 (0:0.1.5-3.fc4 > 0:0.1.5-2.fc7) FE5 > FE6 (0:0.1.5-3.fc5 > 0:0.1.5-1.fc6) FE5 > FE7 (0:0.1.5-3.fc5 > 0:0.1.5-2.fc7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-3.FC5 > 0:0.1.7-2) libxml2: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) smart: Axel.Thimm AT ATrpms.net FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From tibbs at math.uh.edu Sat Dec 2 17:00:16 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Dec 2006 11:00:16 -0600 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <20061202112501.E22E415212E@buildsys.fedoraproject.org> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> Message-ID: >Axel.Thimm AT ATrpms.net: > smart > FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) I wonder if it would be reasonable to suppress rawhide in this report until we get closer to test time. Since rawhide occasionally doesn't build, and maintainers often concentrate on released versions when fixing important bugs or pushing security fixes, the information often isn't pertinent. - J< From Axel.Thimm at ATrpms.net Sat Dec 2 17:10:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Dec 2006 18:10:26 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> Message-ID: <20061202171026.GL22797@neu.nirvana> On Sat, Dec 02, 2006 at 11:00:16AM -0600, Jason L Tibbitts III wrote: > >Axel.Thimm AT ATrpms.net: > > smart > > FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > > FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > > FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > > I wonder if it would be reasonable to suppress rawhide in this report > until we get closer to test time. Since rawhide occasionally doesn't > build, and maintainers often concentrate on released versions when > fixing important bugs or pushing security fixes, the information often > isn't pertinent. FWIW the smart build fails on KDE not liking the newest autoconf: *** YOU'RE USING autoconf (GNU Autoconf) 2.61. *** KDE requires autoconf 2.52, 2.53 or 2.54 Are there other packages affected that way? But I agree rawhide in fast development mode creates a lot of noise in such reports. Maybe two sections, one w/o rawhide and one only checking releases vs rawhide? -- 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 nicolas.mailhot at laposte.net Sat Dec 2 18:16:22 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 02 Dec 2006 19:16:22 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> Message-ID: <1165083386.1427.2.camel@rousalka.dyndns.org> Le samedi 02 d?cembre 2006 ? 11:00 -0600, Jason L Tibbitts III a ?crit : > >Axel.Thimm AT ATrpms.net: > > smart > > FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > > FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > > FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > > I wonder if it would be reasonable to suppress rawhide in this report > until we get closer to test time. Since rawhide occasionally doesn't > build, and maintainers often concentrate on released versions when > fixing important bugs or pushing security fixes, the information often > isn't pertinent. I wonder how you think you'll get any rawhide testers if maintainers are encouraged to let rawhide bitrot till test1. Also, I wonder how many people will dare test test1 if no one ran devel before. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From caillon at redhat.com Sat Dec 2 18:28:15 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 02 Dec 2006 13:28:15 -0500 Subject: Seamonkey for fc4 In-Reply-To: <45715176.9080907@gtw.net> References: <45715176.9080907@gtw.net> Message-ID: <4571C5BF.2090608@redhat.com> David D. Eisenstein wrote: > David D. Eisenstein wrote: >> Trying to build seamonkey for fc4. x86_64 build errors. Any clues? You don't want to run regchrome, regxpcom, or anything of the sort. Those functions are now done at run time by the user (running them will IIRC make it so the user can't start the browser except as the build user). If you're pulling that from old mozilla spec files, the entire containing pushd/popd blocks can be removed. Since seamonkey 1.0 is much closer to firefox 1.5, it might make sense to start there instead of using mozilla as a base. From caillon at redhat.com Sat Dec 2 18:30:36 2006 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 02 Dec 2006 13:30:36 -0500 Subject: Seamonkey for fc4 In-Reply-To: <4571C5BF.2090608@redhat.com> References: <45715176.9080907@gtw.net> <4571C5BF.2090608@redhat.com> Message-ID: <4571C64C.4060607@redhat.com> Christopher Aillon wrote: > Since seamonkey 1.0 is > much closer to firefox 1.5, it might make sense to start there instead > of using mozilla as a base. Or work with Martin Stransky, who has (is) doing this for FC5 now. From tibbs at math.uh.edu Sat Dec 2 19:09:42 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Dec 2006 13:09:42 -0600 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <1165083386.1427.2.camel@rousalka.dyndns.org> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <1165083386.1427.2.camel@rousalka.dyndns.org> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> I wonder how you think you'll get any rawhide testers if NM> maintainers are encouraged to let rawhide bitrot till test1. I'm sorry, I fail to notice where anyone was encouraging anyone to let rawhide bitrot. I also fail to see where I said that the reports should be suppressed until test1 is released. Are you simply trying to be offensively argumentative? If not, perhaps you could elide the hyperbole and address my suggestion in an intelligent and reasoned manner. Thank you. - J< From peter at thecodergeek.com Sat Dec 2 23:16:01 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 02 Dec 2006 15:16:01 -0800 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> Message-ID: <1165101361.15171.2.camel@tuxhugger> On Sat, 2006-12-02 at 11:00 -0600, Jason L Tibbitts III wrote: > >Axel.Thimm AT ATrpms.net: > > smart > > FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > > FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > > FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > > I wonder if it would be reasonable to suppress rawhide in this report > until we get closer to test time. Since rawhide occasionally doesn't > build, and maintainers often concentrate on released versions when > fixing important bugs or pushing security fixes, the information often > isn't pertinent. I think suppressing the Rawhide stuff would be quite harmful. Most people tend to test rawhide by installing the latest release, then upgrading from there. However, if the EVR for an FC6 package is greater than that of the corresponding FC7/devel package (or FC7 greater than FC8/devel, et al.), then that package will not be upgraded and the person is not fully testing a rawhide install (especially when some stuff is rawhide-only and mixing stable and rawhide versions of things can cause major breakage). -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Sat Dec 2 23:44:52 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 3 Dec 2006 00:44:52 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <1165101361.15171.2.camel@tuxhugger> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <1165101361.15171.2.camel@tuxhugger> Message-ID: <20061203004452.b972cc1b.bugs.michael@gmx.net> On Sat, 02 Dec 2006 15:16:01 -0800, Peter Gordon wrote: > On Sat, 2006-12-02 at 11:00 -0600, Jason L Tibbitts III wrote: > > >Axel.Thimm AT ATrpms.net: > > > smart > > > FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > > > FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > > > FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > > > > I wonder if it would be reasonable to suppress rawhide in this report > > until we get closer to test time. Since rawhide occasionally doesn't > > build, and maintainers often concentrate on released versions when > > fixing important bugs or pushing security fixes, the information often > > isn't pertinent. Is it that all this breakage is due to failed rebuild attempts? Or is it that Rawhide and FE Development are just in bad shape because most (or all) package maintainers don't even know that they are supposed to prepare their packages in there, too? (read: no roadmap for Fedora Extras, no guidance by FESCO) In case there are failed rebuild attempts that might benefit from exposure and contributions, why not open a bugzilla ticket and make it block the FE7Target tracker bug? Recently I've mentioned that I've filed a couple of bugs about broken upgrade paths (which affect FC6 or older), and the activity in those tickets is, well, poor. From ville.skytta at iki.fi Sun Dec 3 10:41:50 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 03 Dec 2006 12:41:50 +0200 Subject: libtermcap => libncurses In-Reply-To: <20061201085654.GC19280@localhost> References: <20061130144515.GA9862@localhost> <456F03AE.2090100@kobold.org> <20061201085654.GC19280@localhost> Message-ID: <1165142510.3435.43.camel@viper.local> On Fri, 2006-12-01 at 09:56 +0100, Miroslav Lichvar wrote: > On Thu, Nov 30, 2006 at 08:15:42AM -0800, Wart wrote: > > This list is missing 'readline-devel'. The base 'readline' package does > > not require libtermcap, but if you look at the spec file, you'll see > > that 'readline-devel' Requires: libtermcap-devel. This means that any > > package that has a BR: readline-devel likely gets linked with and ends > > up with an implicit Requires: on libtermcap... > > readline-devel-5.2-2.fc7 requires ncurses-devel. While at it, now that there's (AFAIU) only one alternative providing the termcap stuff in the distro, would it be possible to also get rid of undefined non-weak symbols in libreadline by explicitly linking it with libncurses? $ ldd -d -r /usr/lib64/libreadline.so.5 | grep undef undefined symbol: PC (/usr/lib64/libreadline.so.5) undefined symbol: UP (/usr/lib64/libreadline.so.5) undefined symbol: BC (/usr/lib64/libreadline.so.5) undefined symbol: tgetflag (/usr/lib64/libreadline.so.5) undefined symbol: tgetent (/usr/lib64/libreadline.so.5) undefined symbol: tputs (/usr/lib64/libreadline.so.5) undefined symbol: tgoto (/usr/lib64/libreadline.so.5) undefined symbol: tgetnum (/usr/lib64/libreadline.so.5) undefined symbol: tgetstr (/usr/lib64/libreadline.so.5) From fedora at leemhuis.info Sun Dec 3 11:30:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Dec 2006 12:30:32 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <20061202171026.GL22797@neu.nirvana> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> Message-ID: <4572B558.1060006@leemhuis.info> Axel Thimm schrieb: > On Sat, Dec 02, 2006 at 11:00:16AM -0600, Jason L Tibbitts III wrote: >>> Axel.Thimm AT ATrpms.net: >>> smart >>> FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) >>> FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) >>> FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) >> I wonder if it would be reasonable to suppress rawhide in this report >> until we get closer to test time. Since rawhide occasionally doesn't >> build, and maintainers often concentrate on released versions when >> fixing important bugs or pushing security fixes, the information often >> isn't pertinent. > FWIW the smart build fails on KDE not liking the newest autoconf: > [...] Why can't you simply run autofoo on a FC-6 machine, create a patch, bzip2 it and import it to the look aside cache and then use it as %patch from the spec file? That what several people recommend on different fedora-lists in the past, as they say "it's bad to run autofoo in a spec file". CU thl From buildsys at fedoraproject.org Sun Dec 3 11:38:04 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 3 Dec 2006 06:38:04 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-03 Message-ID: <20061203113804.CE39F15212E@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libvirt FC5-updates > FC6 (0:0.1.7-3.FC5 > 0:0.1.7-2) libxml2 FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) andreas.bierfert AT lowlatency.de: libopensync-plugin-irmc FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) ch.nolte AT fh-wolfenbuettel.de: kbibtex FE4 > FE6 (0:0.1.5-3.fc4 > 0:0.1.5-1.fc6) FE4 > FE7 (0:0.1.5-3.fc4 > 0:0.1.5-2.fc7) FE5 > FE6 (0:0.1.5-3.fc5 > 0:0.1.5-1.fc6) FE5 > FE7 (0:0.1.5-3.fc5 > 0:0.1.5-2.fc7) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kbibtex: ch.nolte AT fh-wolfenbuettel.de FE4 > FE6 (0:0.1.5-3.fc4 > 0:0.1.5-1.fc6) FE4 > FE7 (0:0.1.5-3.fc4 > 0:0.1.5-2.fc7) FE5 > FE6 (0:0.1.5-3.fc5 > 0:0.1.5-1.fc6) FE5 > FE7 (0:0.1.5-3.fc5 > 0:0.1.5-2.fc7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libopensync-plugin-irmc: andreas.bierfert AT lowlatency.de FE4 > FE5 (0:0.19-1.fc4 > 0:0.18-6.fc5) libvirt: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:0.1.7-3.FC5 > 0:0.1.7-2) libxml2: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) smart: Axel.Thimm AT ATrpms.net FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From Axel.Thimm at ATrpms.net Sun Dec 3 12:26:04 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 3 Dec 2006 13:26:04 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <4572B558.1060006@leemhuis.info> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> Message-ID: <20061203122604.GA18467@neu.nirvana> On Sun, Dec 03, 2006 at 12:30:32PM +0100, Thorsten Leemhuis wrote: > Axel Thimm schrieb: > > On Sat, Dec 02, 2006 at 11:00:16AM -0600, Jason L Tibbitts III wrote: > >>> Axel.Thimm AT ATrpms.net: > >>> smart > >>> FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > >>> FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > >>> FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > >> I wonder if it would be reasonable to suppress rawhide in this report > >> until we get closer to test time. Since rawhide occasionally doesn't > >> build, and maintainers often concentrate on released versions when > >> fixing important bugs or pushing security fixes, the information often > >> isn't pertinent. > > FWIW the smart build fails on KDE not liking the newest autoconf: > > [...] > > Why can't you simply run autofoo on a FC-6 machine, create a patch, > bzip2 it and import it to the look aside cache and then use it as %patch > from the spec file? That what several people recommend on different > fedora-lists in the past, as they say "it's bad to run autofoo in a spec > file". You end up with undeterministic builds that fail only sometimes. That's because if master and generated files are changed at the same time, e.g. through a patch, then make may consider the generated files not to be newer that the master and will try to regenerate nonetheless. The way out would be to either use configure switches to disable these Makefile rules, or if not available to make two patches and add a sleep 1 in between. But the true trouble is in kde and autoconf not liking each other and that needs to be fixed instead of pasted over :) Furthermore such an issue gets lost in the tides of time: If I would now use patches made by FC6's autoconf and FC7 upwards cannot regenerate the patches either through the main autoconf or any compatibility autoconf (and there currently is no compatibility autoconf for FC6's), then I'll get in trouble on the next fix needed on the master files (unless I keep a copy of FC6 forever). Finally yet another argument against pregenerated patches to autotools generated files is that this way one would never detect the need for an autotools compatibility package. So all in all IMHO a distro must be able to regenerate the autotool generated files. -- 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 rc040203 at freenet.de Sun Dec 3 14:12:54 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 03 Dec 2006 15:12:54 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <20061203122604.GA18467@neu.nirvana> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> Message-ID: <1165155174.20287.202.camel@mccallum.corsepiu.local> On Sun, 2006-12-03 at 13:26 +0100, Axel Thimm wrote: > On Sun, Dec 03, 2006 at 12:30:32PM +0100, Thorsten Leemhuis wrote: > > Axel Thimm schrieb: > > > On Sat, Dec 02, 2006 at 11:00:16AM -0600, Jason L Tibbitts III wrote: > > >>> Axel.Thimm AT ATrpms.net: > > >>> smart > > >>> FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > > >>> FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > > >>> FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > > >> I wonder if it would be reasonable to suppress rawhide in this report > > >> until we get closer to test time. Since rawhide occasionally doesn't > > >> build, and maintainers often concentrate on released versions when > > >> fixing important bugs or pushing security fixes, the information often > > >> isn't pertinent. > > > FWIW the smart build fails on KDE not liking the newest autoconf: This a stupid and broken script in smart's source (contrib/ksmarttray/admin/cvs.sh). Either fix this script, kickass upstream to fix it or abandon ksmarttray. > > > [...] > > > > Why can't you simply run autofoo on a FC-6 machine, create a patch, > > bzip2 it and import it to the look aside cache and then use it as %patch > > from the spec file? That what several people recommend on different > > fedora-lists in the past, as they say "it's bad to run autofoo in a spec > > file". > > You end up with undeterministic builds that fail only > sometimes. > > That's because if master and generated files are changed at > the same time, e.g. through a patch, then make may consider the > generated files not to be newer that the master and will try to > regenerate nonetheless. Sorry, Axel, this is nonsense. Ralf From Axel.Thimm at ATrpms.net Sun Dec 3 14:27:54 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 3 Dec 2006 15:27:54 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <1165155174.20287.202.camel@mccallum.corsepiu.local> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> <1165155174.20287.202.camel@mccallum.corsepiu.local> Message-ID: <20061203142754.GA21313@neu.nirvana> On Sun, Dec 03, 2006 at 03:12:54PM +0100, Ralf Corsepius wrote: > On Sun, 2006-12-03 at 13:26 +0100, Axel Thimm wrote: > > On Sun, Dec 03, 2006 at 12:30:32PM +0100, Thorsten Leemhuis wrote: > > > Axel Thimm schrieb: > > > > On Sat, Dec 02, 2006 at 11:00:16AM -0600, Jason L Tibbitts III wrote: > > > >>> Axel.Thimm AT ATrpms.net: > > > >>> smart > > > >>> FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > > > >>> FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > > > >>> FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > > > > FWIW the smart build fails on KDE not liking the newest autoconf: > > This a stupid and broken script in smart's source > (contrib/ksmarttray/admin/cvs.sh). > > Either fix this script, kickass upstream to fix it or abandon > ksmarttray. This script is an old copy from kde's sdk, it's no invention from smart. In fact this shows that pregenerating files (in this case by copying a static version over) can be more harmful than generating in %build. > > > > [...] > > > > > > Why can't you simply run autofoo on a FC-6 machine, create a patch, > > > bzip2 it and import it to the look aside cache and then use it as %patch > > > from the spec file? That what several people recommend on different > > > fedora-lists in the past, as they say "it's bad to run autofoo in a spec > > > file". > > > > You end up with undeterministic builds that fail only > > sometimes. > > > > That's because if master and generated files are changed at > > the same time, e.g. through a patch, then make may consider the > > generated files not to be newer that the master and will try to > > regenerate nonetheless. > > Sorry, Axel, this is nonsense. Really? Try in an arbitray project touch configure.ac configure and then watch how make will try to regenerate configure. That will redefine your perception of "nonsense" ;) -- 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 rc040203 at freenet.de Mon Dec 4 05:08:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Dec 2006 06:08:06 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <20061203142754.GA21313@neu.nirvana> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> <1165155174.20287.202.camel@mccallum.corsepiu.local> <20061203142754.GA21313@neu.nirvana> Message-ID: <1165208887.20287.218.camel@mccallum.corsepiu.local> On Sun, 2006-12-03 at 15:27 +0100, Axel Thimm wrote: > On Sun, Dec 03, 2006 at 03:12:54PM +0100, Ralf Corsepius wrote: > > On Sun, 2006-12-03 at 13:26 +0100, Axel Thimm wrote: > > > On Sun, Dec 03, 2006 at 12:30:32PM +0100, Thorsten Leemhuis wrote: > > > > Axel Thimm schrieb: > > > > > On Sat, Dec 02, 2006 at 11:00:16AM -0600, Jason L Tibbitts III wrote: > > > > >>> Axel.Thimm AT ATrpms.net: > > > > >>> smart > > > > >>> FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) > > > > >>> FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) > > > > >>> FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) > > > > > > FWIW the smart build fails on KDE not liking the newest autoconf: > > > > This a stupid and broken script in smart's source > > (contrib/ksmarttray/admin/cvs.sh). > > > > Either fix this script, kickass upstream to fix it or abandon > > ksmarttray. > > This script is an old copy from kde's sdk, it's no invention from smart. > > In fact this shows that pregenerating files (in this case by copying a > static version over) can be more harmful than generating in %build. BS. This freaking script is trying to dynamically generate a auto* *source* files and badly stumbles over its feet, because a) its buggy (The version checks are completely non-functional) b) they are abusing the autotools > > > > > [...] > > > > > > > > Why can't you simply run autofoo on a FC-6 machine, create a patch, > > > > bzip2 it and import it to the look aside cache and then use it as %patch > > > > from the spec file? That what several people recommend on different > > > > fedora-lists in the past, as they say "it's bad to run autofoo in a spec > > > > file". > > > > > > You end up with undeterministic builds that fail only > > > sometimes. > > > > > > That's because if master and generated files are changed at > > > the same time, e.g. through a patch, then make may consider the > > > generated files not to be newer that the master and will try to > > > regenerate nonetheless. > > > > Sorry, Axel, this is nonsense. > > Really? Try in an arbitray project > > touch configure.ac configure > and then watch how make will try to regenerate configure. C'mon, you really should know better. > That will > redefine your perception of "nonsense" ;) Nope, you are spreading FUD. Ralf From mlichvar at redhat.com Mon Dec 4 09:27:32 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 4 Dec 2006 10:27:32 +0100 Subject: libtermcap => libncurses In-Reply-To: <1165142510.3435.43.camel@viper.local> References: <20061130144515.GA9862@localhost> <456F03AE.2090100@kobold.org> <20061201085654.GC19280@localhost> <1165142510.3435.43.camel@viper.local> Message-ID: <20061204092732.GA28360@localhost> On Sun, Dec 03, 2006 at 12:41:50PM +0200, Ville Skytt? wrote: > On Fri, 2006-12-01 at 09:56 +0100, Miroslav Lichvar wrote: > > readline-devel-5.2-2.fc7 requires ncurses-devel. > > While at it, now that there's (AFAIU) only one alternative providing the > termcap stuff in the distro, would it be possible to also get rid of > undefined non-weak symbols in libreadline by explicitly linking it with > libncurses? There are still two options - libncurses and libncursesw. libreadline could be linked with libncurses only if it wouldn't conflict with libncursesw. Not sure if there is a ncurses program using readline... -- Miroslav Lichvar From Axel.Thimm at ATrpms.net Mon Dec 4 12:37:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Dec 2006 13:37:06 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <1165208887.20287.218.camel@mccallum.corsepiu.local> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> <1165155174.20287.202.camel@mccallum.corsepiu.local> <20061203142754.GA21313@neu.nirvana> <1165208887.20287.218.camel@mccallum.corsepiu.local> Message-ID: <20061204123706.GB13290@neu.nirvana> On Mon, Dec 04, 2006 at 06:08:06AM +0100, Ralf Corsepius wrote: > > > > > > FWIW the smart build fails on KDE not liking the newest > > > > > > autoconf: > > > > > > This a stupid and broken script in smart's source > > > (contrib/ksmarttray/admin/cvs.sh). > > > > > > Either fix this script, kickass upstream to fix it or abandon > > > ksmarttray. > > > > This script is an old copy from kde's sdk, it's no invention from > > smart. > > > > In fact this shows that pregenerating files (in this case by > > copying a static version over) can be more harmful than generating > > in %build. > > BS. Please Ralf, you're getting off track with your choice of language, why? > This freaking script is trying to dynamically generate a auto* > *source* files and badly stumbles over its feet, because > > a) its buggy (The version checks are completely non-functional) > b) they are abusing the autotools Great, this is a script from kdesdk, so try complaining to upstream, e.g. kde developers. smart is just a consumer. > > > > > > [...] > > > > > > > > > > Why can't you simply run autofoo on a FC-6 machine, create a patch, > > > > > bzip2 it and import it to the look aside cache and then use it as %patch > > > > > from the spec file? That what several people recommend on different > > > > > fedora-lists in the past, as they say "it's bad to run autofoo in a spec > > > > > file". > > > > > > > > You end up with undeterministic builds that fail only > > > > sometimes. > > > > > > > > That's because if master and generated files are changed at > > > > the same time, e.g. through a patch, then make may consider the > > > > generated files not to be newer that the master and will try to > > > > regenerate nonetheless. > > > > > > Sorry, Axel, this is nonsense. > > > > Really? Try in an arbitray project > > > > touch configure.ac configure > > and then watch how make will try to regenerate configure. > > C'mon, you really should know better. So could be said of you. I'd prefer arguments instead of hand waving, though. The issue stands: If you patch master and generated files and their dependency is cast in always enabled Makefile rules you lose. > > That will redefine your perception of "nonsense" ;) > Nope, you are spreading FUD. Well, have it as you like. People that have done packaging which involved patching configure and configure.ac will know that this is reality and no FUD at all. But foremost, please stop using words like "nonsense", "BS" and the like, let's keep it attribute-free, OK? -- 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 rc040203 at freenet.de Mon Dec 4 13:03:12 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Dec 2006 14:03:12 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <20061204123706.GB13290@neu.nirvana> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> <1165155174.20287.202.camel@mccallum.corsepiu.local> <20061203142754.GA21313@neu.nirvana> <1165208887.20287.218.camel@mccallum.corsepiu.local> <20061204123706.GB13290@neu.nirvana> Message-ID: <1165237393.20287.225.camel@mccallum.corsepiu.local> On Mon, 2006-12-04 at 13:37 +0100, Axel Thimm wrote: > On Mon, Dec 04, 2006 at 06:08:06AM +0100, Ralf Corsepius wrote: > > > > > > > FWIW the smart build fails on KDE not liking the newest > > > > > > > autoconf: > > > > > > > > This a stupid and broken script in smart's source > > > > (contrib/ksmarttray/admin/cvs.sh). > > > > > > > > Either fix this script, kickass upstream to fix it or abandon > > > > ksmarttray. > > > > > > This script is an old copy from kde's sdk, it's no invention from > > > smart. > > > > > > In fact this shows that pregenerating files (in this case by > > > copying a static version over) can be more harmful than generating > > > in %build. > > > > BS. > > Please Ralf, you're getting off track with your choice of language, > why? Because your apparent lack of understanding and stubbornness doesn't leave me any alternative. > > This freaking script is trying to dynamically generate a auto* > > *source* files and badly stumbles over its feet, because > > > > a) its buggy (The version checks are completely non-functional) > > b) they are abusing the autotools > > Great, this is a script from kdesdk, so try complaining to > upstream, e.g. kde developers. smart is just a consumer. So what? This stuff is broken in _smart_, that's the topic we are taking about. Whether it's smart maintainers or Kde maintainer or you who is to blame doesn't matter. > > C'mon, you really should know better. > > So could be said of you. I'd prefer arguments instead of hand waving, > though. The issue stands: If you patch master and generated files and > their dependency is cast in always enabled Makefile rules you lose. > > > > That will redefine your perception But foremost, please stop using words like "nonsense", "BS" and the > like, let's keep it attribute-free, OK? > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainersof "nonsense" ;) > > > Nope, you are spreading FUD. > > Well, have it as you like. People that have done packaging which > involved patching configure and configure.ac will know that this is > reality and no FUD at all. Yes, packaging monkeys. Programmers should know what they are doing. Embarrassed, Ralf From Axel.Thimm at ATrpms.net Mon Dec 4 13:42:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Dec 2006 14:42:03 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <1165237393.20287.225.camel@mccallum.corsepiu.local> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> <1165155174.20287.202.camel@mccallum.corsepiu.local> <20061203142754.GA21313@neu.nirvana> <1165208887.20287.218.camel@mccallum.corsepiu.local> <20061204123706.GB13290@neu.nirvana> <1165237393.20287.225.camel@mccallum.corsepiu.local> Message-ID: <20061204134203.GE13290@neu.nirvana> On Mon, Dec 04, 2006 at 02:03:12PM +0100, Ralf Corsepius wrote: > > > BS. > > > > Please Ralf, you're getting off track with your choice of language, > > why? > Because your apparent lack of understanding and stubbornness doesn't > leave me any alternative. > Embarrassed, > Ralf Well, the best way to kill a conversation is repeatedly crossing the line of self-understood etiquette. -- 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 wart at kobold.org Mon Dec 4 16:11:28 2006 From: wart at kobold.org (Wart) Date: Mon, 04 Dec 2006 08:11:28 -0800 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <20061203142754.GA21313@neu.nirvana> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> <1165155174.20287.202.camel@mccallum.corsepiu.local> <20061203142754.GA21313@neu.nirvana> Message-ID: <457448B0.3000004@kobold.org> Axel Thimm wrote: > On Sun, Dec 03, 2006 at 03:12:54PM +0100, Ralf Corsepius wrote: >> On Sun, 2006-12-03 at 13:26 +0100, Axel Thimm wrote: ... >>> That's because if master and generated files are changed at >>> the same time, e.g. through a patch, then make may consider the >>> generated files not to be newer that the master and will try to >>> regenerate nonetheless. >> Sorry, Axel, this is nonsense. > > Really? Try in an arbitray project > > touch configure.ac configure > > and then watch how make will try to regenerate configure. That will > redefine your perception of "nonsense" ;) Packagers just need to be careful about preserving timestamps when patching autotools-generated files such as 'configure'. This has been discussed on f-e-l before: https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00512.html ...and again here: https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00438.html --Wart From twoerner at redhat.com Mon Dec 4 17:05:50 2006 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 04 Dec 2006 18:05:50 +0100 Subject: tcp_wrappers Message-ID: <4574556E.4040008@redhat.com> Hello, tcp_wrappers has two new sub packages: tcp_wrappers-devel and tcp_wrappers-libs. All build requirements for tcp_wrappers have to get changed to tcp_wrappers-devel. Thanks, Thomas -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner D-70178 Stuttgart Web : http://www.redhat.de/ From Axel.Thimm at ATrpms.net Mon Dec 4 18:17:44 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Dec 2006 19:17:44 +0100 Subject: Package EVR problems in FC+FE 2006-12-02 In-Reply-To: <1165155174.20287.202.camel@mccallum.corsepiu.local> References: <20061202112501.E22E415212E@buildsys.fedoraproject.org> <20061202171026.GL22797@neu.nirvana> <4572B558.1060006@leemhuis.info> <20061203122604.GA18467@neu.nirvana> <1165155174.20287.202.camel@mccallum.corsepiu.local> Message-ID: <20061204181744.GB21765@neu.nirvana> On Sun, Dec 03, 2006 at 03:12:54PM +0100, Ralf Corsepius wrote: > > You end up with undeterministic builds that fail only > > sometimes. > > > > That's because if master and generated files are changed at > > the same time, e.g. through a patch, then make may consider the > > generated files not to be newer that the master and will try to > > regenerate nonetheless. > > Sorry, Axel, this is nonsense. Thanks to Wart's post on threads previously made on this topic one can find you yourself confirming the above "nonsense". (https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00536.html): On Mon, 12 Jun 2006 03:26:42 +0200, Ralf Corsepius wrote: > The down-side would be users rebuilding a package and having the > autotools installed, would see the autotools be run, i.e. > non-deterministic "user-builts". -- 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 dwmw2 at infradead.org Tue Dec 5 14:28:17 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 05 Dec 2006 14:28:17 +0000 Subject: Seamonkey for fc4 In-Reply-To: <45714F7D.6000501@gtw.net> References: <20061130144515.GA9862@localhost> <45714F7D.6000501@gtw.net> Message-ID: <1165328897.5253.93.camel@pmac.infradead.org> On Sat, 2006-12-02 at 04:03 -0600, David D. Eisenstein wrote: > Trying to build seamonkey for fc4. x86_64 build errors. Any clues? No idea about x86_64, but it builds and runs fine on FC4/PowerPC. -- dwmw2 From buildsys at fedoraproject.org Wed Dec 6 14:01:34 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 6 Dec 2006 09:01:34 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-06 Message-ID: <20061206140134.A3AEE15212E@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) eclipse FC6-updates > FC7 (1:3.2.1-23.fc6 > 1:3.2.1-22.fc7) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libsepol FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) libxml2 FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) tar FC6-updates > FC7 (2:1.15.1-22.fc6 > 2:1.15.1-21.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) pertusus AT free.fr: grads FE5 > FE6 (0:1.9b4-19.fc5 > 0:1.9b4-18.fc6.1) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) eclipse: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:3.2.1-23.fc6 > 1:3.2.1-22.fc7) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) grads: pertusus AT free.fr FE5 > FE6 (0:1.9b4-19.fc5 > 0:1.9b4-18.fc6.1) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libsepol: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) libxml2: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) smart: Axel.Thimm AT ATrpms.net FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) tar: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (2:1.15.1-22.fc6 > 2:1.15.1-21.fc7) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From ndbecker2 at gmail.com Wed Dec 6 14:40:22 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 6 Dec 2006 09:40:22 -0500 Subject: config file in /usr Message-ID: <200612060940.23032.ndbecker2@gmail.com> I'm not sure what to do with this rpm error. I'm looking at packaging pinot, part of xapian search. Builds OK, but rpmlint says: E: pinot-omega file-in-usr-marked-as-conffile /usr/share/pinot/engines/OmegaDescription.xml According to the author, this could be user-editable - similar to /usr/lib/firefox-1.5.0.8/searchplugins/* What should I do with this? From rc040203 at freenet.de Wed Dec 6 15:03:52 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Dec 2006 16:03:52 +0100 Subject: config file in /usr In-Reply-To: <200612060940.23032.ndbecker2@gmail.com> References: <200612060940.23032.ndbecker2@gmail.com> Message-ID: <1165417432.23106.101.camel@mccallum.corsepiu.local> On Wed, 2006-12-06 at 09:40 -0500, Neal Becker wrote: > I'm not sure what to do with this rpm error. > > I'm looking at packaging pinot, part of xapian search. > > Builds OK, but rpmlint says: > E: pinot-omega > file-in-usr-marked-as-conffile /usr/share/pinot/engines/OmegaDescription.xml > > According to the author, this could be user-editable => Must be below /etc > - similar > to /usr/lib/firefox-1.5.0.8/searchplugins/* > > What should I do with this? Hack the package to pick it up from somewhere below /etc Ralf From rdieter at math.unl.edu Wed Dec 6 15:11:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 06 Dec 2006 09:11:28 -0600 Subject: config file in /usr In-Reply-To: <1165417432.23106.101.camel@mccallum.corsepiu.local> References: <200612060940.23032.ndbecker2@gmail.com> <1165417432.23106.101.camel@mccallum.corsepiu.local> Message-ID: <4576DDA0.4060709@math.unl.edu> Ralf Corsepius wrote: > On Wed, 2006-12-06 at 09:40 -0500, Neal Becker wrote: >> I'm not sure what to do with this rpm error. >> >> I'm looking at packaging pinot, part of xapian search. >> >> Builds OK, but rpmlint says: >> E: pinot-omega >> file-in-usr-marked-as-conffile /usr/share/pinot/engines/OmegaDescription.xml >> >> According to the author, this could be user-editable > => Must be below /etc I'd say, SHOULD, if reaonably possible, to be FHS-friendly. Simple-stoopid implementation would to move said file (or directory) to somewhere under /etc, then symlink the old location to the new. -- Rex From rc040203 at freenet.de Wed Dec 6 15:29:05 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Dec 2006 16:29:05 +0100 Subject: config file in /usr In-Reply-To: <4576DDA0.4060709@math.unl.edu> References: <200612060940.23032.ndbecker2@gmail.com> <1165417432.23106.101.camel@mccallum.corsepiu.local> <4576DDA0.4060709@math.unl.edu> Message-ID: <1165418945.23106.107.camel@mccallum.corsepiu.local> On Wed, 2006-12-06 at 09:11 -0600, Rex Dieter wrote: > Ralf Corsepius wrote: > > On Wed, 2006-12-06 at 09:40 -0500, Neal Becker wrote: > >> I'm not sure what to do with this rpm error. > >> > >> I'm looking at packaging pinot, part of xapian search. > >> > >> Builds OK, but rpmlint says: > >> E: pinot-omega > >> file-in-usr-marked-as-conffile /usr/share/pinot/engines/OmegaDescription.xml > >> > >> According to the author, this could be user-editable > > => Must be below /etc > > I'd say, SHOULD, if reaonably possible, to be FHS-friendly. /usr is supposed to be mountable readonly => MUST /usr/share can network mounted ("share") => MUST > Simple-stoopid implementation would to move said file (or directory) to > somewhere under /etc, then symlink the old location to the new. Yep, this is a "stupid work-around", but should be applicable. Ralf From wolfy at nobugconsulting.ro Wed Dec 6 20:18:07 2006 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Wed, 06 Dec 2006 22:18:07 +0200 Subject: config file in /usr In-Reply-To: <1165418945.23106.107.camel@mccallum.corsepiu.local> References: <200612060940.23032.ndbecker2@gmail.com> <1165417432.23106.101.camel@mccallum.corsepiu.local> <4576DDA0.4060709@math.unl.edu> <1165418945.23106.107.camel@mccallum.corsepiu.local> Message-ID: <4577257F.8050402@nobugconsulting.ro> On 12/06/2006 05:29 PM, Ralf Corsepius wrote: > On Wed, 2006-12-06 at 09:11 -0600, Rex Dieter wrote: > >> Ralf Corsepius wrote: >> >>> On Wed, 2006-12-06 at 09:40 -0500, Neal Becker wrote: >>> >>>> I'm not sure what to do with this rpm error. >>>> >>>> I'm looking at packaging pinot, part of xapian search. >>>> >>>> Builds OK, but rpmlint says: >>>> E: pinot-omega >>>> file-in-usr-marked-as-conffile /usr/share/pinot/engines/OmegaDescription.xml >>>> >>>> According to the author, this could be user-editable >>>> >>> => Must be below /etc >>> >> I'd say, SHOULD, if reaonably possible, to be FHS-friendly. >> > > /usr is supposed to be mountable readonly => MUST > > /usr/share can network mounted ("share") => MUST > > >> Simple-stoopid implementation would to move said file (or directory) to >> somewhere under /etc, then symlink the old location to the new. >> > > Yep, this is a "stupid work-around", but should be applicable. > ... might break under SELinux... From fedora at leemhuis.info Wed Dec 6 20:18:57 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 06 Dec 2006 21:18:57 +0100 Subject: Plan for tomorrows FESCO meeting Message-ID: <457725B1.2090808@leemhuis.info> Hi! I for some weeks now wanted to send out a list of topics that are likely to come up in the next FESCo meeting (they are scheduled each Thursday at 18:00 UTC in #fedora-extras on freenode -- e.g. the next meering will happen in a bit less then 21 hours) ahead of the meeting so people know what will come up. Here is the rough plan in IRC format: > /topic FESCo meeting -- Meeting rules at [WWW] http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- push scripts for epel > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- disttag confusion > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- ship packages in EPEL for EL-Server that are part of EL-Client? > /topic FESCo meeting -- Opening Core - (warren, jeremy, rdieter) -- status update > /topic FESCO-Meeting -- Encourage co-maintainership -- c4chris > /topic FESCo meeting -- MISC -- what to do with all those broken deps and upgrade paths > /topic FESCo meeting -- MISC -- policy frontpage > /topic FESCo meeting -- Packaging Committee Report > /topic FESCO-Meeting -- kmod approval -- gspca [WWW] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209112 > /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple -- EOL plans > /topic FESCo meeting -- Alternative paths of membership advancement -- warren > /topic FESCo meeting -- Free discussion around Fedora Extras You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule The individual pages specific to the topics are linked from there. The same as above holds true: if you name is somewhere on the schedule page in the wiki please update the status in the wiki ahead of the meeting. Ohh, and please update it also directly after the meeting so it's update and prepared for next weeks meeting :-) Hint: If you want to know what FESCo is doing simply subscribe in the wiki to "Extras/Schedul.*" and you'll get mails if something changes in that areas of the wiki. That should give you a good idea of FESCo's work. CU thl P.S: Please remind me to send out mails similar like this one each week round about one day before the meeting and poke me if I forget it ;) From fedora at leemhuis.info Wed Dec 6 20:34:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 06 Dec 2006 21:34:12 +0100 Subject: Plan for tomorrows FESCO meeting In-Reply-To: <457725B1.2090808@leemhuis.info> References: <457725B1.2090808@leemhuis.info> Message-ID: <45772944.5080500@leemhuis.info> Me again ;) I forgot something: Thorsten Leemhuis schrieb: > [...] >> /topic FESCo meeting -- MISC -- what to do with all those broken deps and upgrade paths Special thanks of the week goes to: nirik/Kevin Fenzi -- after we discussed above topic in last weeks meeting he fixed a lot of the broken deps in fe5 and fe6. dgilmore also fixed the plague problems for fe3 and fe4 that lingered around for to long already. And some others people fixed their own or other peoples packages, too. Thanks for that! Note: They and a lot of other contributors are allowed to fix such stuff in other peoples packages; see http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages for details. >> /topic FESCo meeting -- MISC -- policy frontpage Second special "thanks of the week" goes to John Babich -- after my RFH in https://www.redhat.com/archives/fedora-extras-list/2006-December/msg00047.html he stepped up and took care of the AWOL policy page; he created a digest and did some clean ups. Thanks for that. Note: There are still some more policy pages that need a bit of love ;-) CU thl From tibbs at math.uh.edu Wed Dec 6 20:52:40 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Dec 2006 14:52:40 -0600 Subject: Packaging committee (non)report Message-ID: We unfortunately lacked a quorum this week, in part due to me getting called away just a few minutes before the meeting. The main topic of discussion this week was the Conflicts: draft: http://fedoraproject.org/wiki/PackagingDrafts/Conflicts The IRC log is at http://fedoraproject.org/wiki/Packaging/IRCLog20061205 The log is short as the meeting was brief, but there is plenty of good discussion in the fedora-packaging list. Of special note to FESCo is the issue of whether committee vote should be required before allowing a particular package to include Conflicts:. - J< From katzj at redhat.com Wed Dec 6 21:17:51 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Dec 2006 16:17:51 -0500 Subject: Heads-up: python 2.5 on its way Message-ID: <1165439871.8344.9.camel@aglarond.local> This is just a heads up that I'm in the progress of getting python 2.5 staged for the development tree. At this point, I'm doing the build on the side and trying to get a good chunk of the Core packages rebuilt against it before pushing to the development tree itself. I'm still hoping to be able to do the actual move over either later today or tomorrow (depending on how fast the Core build system decides to be) Full list of changes is available at http://docs.python.org/whatsnew/whatsnew25.html, but some of the important high points that are somewhat likely to be hit: 1) python-elementtree is now included with python, but the import is a little bit different 2) pysqlite is included, but a newer version than was previously included in Fedora. This ends up requiring a decent set of changes I'll send another note once I've actually moved the packages so that they'll definitely be hitting rawhide, but wanted to help make sure people understood it was coming (especially as I commit things to core CVS but the builds aren't showing up in rawhide) Jeremy From mattdm at mattdm.org Wed Dec 6 21:26:35 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 6 Dec 2006 16:26:35 -0500 Subject: Heads-up: python 2.5 on its way In-Reply-To: <1165439871.8344.9.camel@aglarond.local> References: <1165439871.8344.9.camel@aglarond.local> Message-ID: <20061206212635.GA21636@jadzia.bu.edu> On Wed, Dec 06, 2006 at 04:17:51PM -0500, Jeremy Katz wrote: > 1) python-elementtree is now included with python, but the import is a > little bit different > 2) pysqlite is included, but a newer version than was previously > included in Fedora. This ends up requiring a decent set of changes So, uh, does this risk breaking yum if we're not careful with the order we run our updates? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From katzj at redhat.com Wed Dec 6 21:38:42 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 06 Dec 2006 16:38:42 -0500 Subject: Heads-up: python 2.5 on its way In-Reply-To: <20061206212635.GA21636@jadzia.bu.edu> References: <1165439871.8344.9.camel@aglarond.local> <20061206212635.GA21636@jadzia.bu.edu> Message-ID: <1165441122.8344.19.camel@aglarond.local> On Wed, 2006-12-06 at 16:26 -0500, Matthew Miller wrote: > On Wed, Dec 06, 2006 at 04:17:51PM -0500, Jeremy Katz wrote: > > 1) python-elementtree is now included with python, but the import is a > > little bit different > > 2) pysqlite is included, but a newer version than was previously > > included in Fedora. This ends up requiring a decent set of changes > > So, uh, does this risk breaking yum if we're not careful with the order we > run our updates? That's why I'm carefully staging the update and not just throwing it in and seeing what breaks ;) I've done all of the necessary work upstream for yum and am pulling it back for the package as we speak. Jeremy From chitlesh at fedoraproject.org Thu Dec 7 08:47:25 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 7 Dec 2006 09:47:25 +0100 Subject: man pages going to the wrong spot? In-Reply-To: <1162583516.2527.4.camel@halflap.boston.devel.redhat.com> References: <1162583516.2527.4.camel@halflap.boston.devel.redhat.com> Message-ID: <13dbfe4f0612070047tc9fe737xcde949987ac1d640@mail.gmail.com> On 11/3/06, Ray Strode wrote: > > Hi, > > So Matthias was looking over a yelp bug when we noticed that some X man > pages were getting installed in /usr/share/man/man3 instead of > /usr/share/man/man3x despite having the .3x extension. > > This lead me to check my system for other occurances of the bug: > [rstrode at halflap] (~) <02:39 PM> > $ for mandir in /usr/share/man/man*; do find $mandir -type f -a ! -name > "*.$(basename $mandir | sed 's/^man//').gz" -exec rpm -qf {} \; ; done | > sort -u > file /usr/share/man/man3/Gaim.3pm is not owned by any package > file /usr/share/man/man3/Gaim::GtkUI.3pm is not owned by any package > gaim-2:2.0.0-0.16.beta4.fc7.i386 > imake-1.0.2-3.i386 > libdmx-devel-1.0.2-3.1.i386 > libtiff-devel-3.8.2-6.fc6.i386 > libX11-devel-1.0.3-4.fc6.i386 > libXau-devel-1.0.1-3.1.i386 > libXcursor-devel-1.1.7-1.1.i386 > libXext-devel-1.0.1-2.1.i386 > libXfixes-devel-4.0.1-2.1.i386 > libXi-devel-1.0.1-3.1.i386 > libXrandr-devel-1.1.1-3.1.i386 > libXScrnSaver-devel-1.1.0-3.1.i386 > libXt-devel-1.0.2-3.1.fc6.i386 > man-pages-2.39-7.noarch > mesa-libGL-devel-6.5.1-7.fc6.i386 > ncurses-5.5-24.20060715.i386 > ncurses-devel-5.5-24.20060715.i386 > openssl-0.9.8b-8.i686 > perl-4:5.8.8-10.i386 > perl-Archive-Tar-1.30-1.fc6.noarch > perl-Compress-Zlib-1.42-1.fc6.i386 > perl-Digest-HMAC-1.01-15.noarch > perl-Digest-SHA1-2.11-1.2.1.i386 > perl-HTML-Parser-3.55-1.fc6.i386 > perl-HTML-Tagset-3.10-2.1.1.noarch > perl-IO-Socket-INET6-2.51-2.fc6.noarch > perl-IO-Socket-SSL-1.01-1.fc6.noarch > perl-IO-Zlib-1.04-4.2.1.noarch > perl-libwww-perl-5.805-1.1.1.noarch > perl-Net-DNS-0.59-1.fc6.i386 > perl-Net-IP-1.25-2.fc6.noarch > perl-Net-SSLeay-1.30-4.fc6.i386 > perl-String-CRC32-1.4-2.fc6.i386 > perl-URI-1.35-3.noarch > perl-XML-Parser-2.34-6.1.2.2.1.i386 > spamassassin-3.1.4-1.fc6.i386 > xorg-x11-apps-7.1-3.fc6.i386 > xorg-x11-font-utils-1:7.1-2.i386 > xorg-x11-server-utils-7.1-4.fc6.i386 > xorg-x11-server-Xnest-1.1.1-47.fc6.i386 > xorg-x11-server-Xorg-1.1.1-47.fc6.i386 > xorg-x11-twm-1:1.0.1-3.1.i386 > xorg-x11-utils-7.1-2.fc6.i386 > xorg-x11-xauth-1:1.0.1-2.1.i386 > xorg-x11-xdm-1:1.0.5-5.fc6.i386 > xorg-x11-xfs-1:1.0.2-3.1.i386 > xorg-x11-xinit-1.0.2-12.fc6.i386 > xorg-x11-xkb-utils-1.0.2-2.1.i386 > > But then, this list is only the list of packages on my machine. > It would be useful if core and extras package maintainers would go through > their packages and fix things up. > > It would also be neat if we could automatically test this... Dave, John, > do you guys have any ideas on that front? > > --Ray my list from my machine: imake-1.0.2-3 libtiff-devel-3.8.2-6.fc6 libX11-devel-1.0.3-5.fc6 libXau-devel-1.0.1-3.1 libXaw-devel-1.0.2-8.1 libXcursor-devel-1.1.7-1.1 libXevie-devel-1.0.1-3.1 libXext-devel-1.0.1-2.1 libXfixes-devel-4.0.1-2.1 libXfontcache-devel-1.0.2-3.1 libXi-devel-1.0.1-3.1 libXpm-devel-3.5.5-3 libXrandr-devel-1.1.1-3.1 libXres-devel-1.0.1-3.1 libXScrnSaver-devel-1.1.0-3.1 libXt-devel-1.0.2-3.1.fc6 libXv-devel-1.0.1-4.1 libXxf86dga-devel-1.0.1-3.1 libXxf86misc-devel-1.0.1-3.1 libXxf86vm-devel-1.0.1-3.1 man-pages-2.39-5 mesa-libGL-devel-6.5.1-8.fc6 mesa-libGLU-devel-6.5.1-8.fc6 nas-1.8-10.fc6 ncurses-5.5-24.20060715 ncurses-devel-5.5-24.20060715 ngspice-doc-17-7.fc6 openssl-0.9.8b-8.3.fc6 openssl-devel-0.9.8b-8.3.fc6 perl-5.8.8-10 perl-Compress-Zlib-1.42-1.fc6 perl-DateManip-5.44-2.fc6 perl-DBI-1.52-1.fc6 perl-HTML-Parser-3.55-1.fc6 perl-HTML-Tagset-3.10-2.1.1 perl-libwww-perl-5.805-1.1.1 perl-String-CRC32-1.4-2.fc6 perl-URI-1.35-3 perl-Wx-0.64-1.fc6 perl-XML-DOM-1.44-2.fc6 perl-XML-Parser-2.34-6.1.2.2.1 perl-XML-RegExp-0.03-2.fc6 perl-XML-XQL-0.68-3.fc6 subversion-perl-1.4.2-2.fc6 xkeycaps-2.46-4.fc6 xorg-x11-apps-7.1-3.fc6 xorg-x11-font-utils-7.1-2 xorg-x11-resutils-7.1-2.fc6 xorg-x11-server-utils-7.1-4.fc6 xorg-x11-server-Xnest-1.1.1-47.1.fc6 xorg-x11-server-Xorg-1.1.1-47.1.fc6 xorg-x11-twm-1.0.1-3.1 xorg-x11-utils-7.1-2.fc6 xorg-x11-xauth-1.0.1-2.1 xorg-x11-xdm-1.0.5-5.fc6 xorg-x11-xfs-1.0.2-3.1 xorg-x11-xinit-1.0.2-15.fc6 xorg-x11-xkb-utils-1.0.2-2.1 -- http://clunixchit.blogspot.com From rc040203 at freenet.de Thu Dec 7 09:14:39 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 07 Dec 2006 10:14:39 +0100 Subject: man pages going to the wrong spot? In-Reply-To: <13dbfe4f0612070047tc9fe737xcde949987ac1d640@mail.gmail.com> References: <1162583516.2527.4.camel@halflap.boston.devel.redhat.com> <13dbfe4f0612070047tc9fe737xcde949987ac1d640@mail.gmail.com> Message-ID: <1165482879.28327.34.camel@mccallum.corsepiu.local> On Thu, 2006-12-07 at 09:47 +0100, Chitlesh GOORAH wrote: > On 11/3/06, Ray Strode wrote: > > > > Hi, > > > > So Matthias was looking over a yelp bug when we noticed that some X man > > pages were getting installed in /usr/share/man/man3 instead of > > /usr/share/man/man3x despite having the .3x extension. What makes you think this is a bug? AFAICT, neither the FHS, the GNU standards or the LSB mandate man3x/ nor do they even mention it. If yelp can't handle *.3x manpages in man3/, yelp is broken. Ralf From buildsys at fedoraproject.org Thu Dec 7 19:59:16 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 7 Dec 2006 14:59:16 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-07 Message-ID: <20061207195916.0E9B115212F@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libsepol FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) libxml2 FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) tar FC6-updates > FC7 (2:1.15.1-22.fc6 > 2:1.15.1-21.fc7) virt-manager FC6-updates > FC7 (0:0.2.6-2.fc6 > 0:0.2.6-1.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) pertusus AT free.fr: grads FE5 > FE6 (0:1.9b4-19.fc5 > 0:1.9b4-18.fc6.1) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.3-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.3-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) grads: pertusus AT free.fr FE5 > FE6 (0:1.9b4-19.fc5 > 0:1.9b4-18.fc6.1) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.4-1.fc6 > 0:0.2.1-1.fc6) libsepol: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) libxml2: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:2.6.27-1.FC6 > 0:2.6.27-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) smart: Axel.Thimm AT ATrpms.net FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) tar: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (2:1.15.1-22.fc6 > 2:1.15.1-21.fc7) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) virt-manager: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.2.6-2.fc6 > 0:0.2.6-1.fc7) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From katzj at redhat.com Thu Dec 7 21:04:37 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 07 Dec 2006 16:04:37 -0500 Subject: Heads-up: python 2.5 on its way In-Reply-To: <1165439871.8344.9.camel@aglarond.local> References: <1165439871.8344.9.camel@aglarond.local> Message-ID: <1165525478.24598.17.camel@orodruin.boston.redhat.com> On Wed, 2006-12-06 at 16:17 -0500, Jeremy Katz wrote: > This is just a heads up that I'm in the progress of getting python 2.5 > staged for the development tree. At this point, I'm doing the build on > the side and trying to get a good chunk of the Core packages rebuilt > against it before pushing to the development tree itself. I'm still > hoping to be able to do the actual move over either later today or > tomorrow (depending on how fast the Core build system decides to be) As warned, these packages are built and are now moving over so should be showing up in tomorrow's development push. I've rebuilt the majority of Core which showed up with a dep on python[1], but I'm sure I missed something in my query. Also, there's a healthy number of packages in Extras which will be hit by this as well. If anyone runs into any problems or has any questions, let me know. And if you need a python25 package to play with while on FC6, my slightly older packages are still available at http://people.redhat.com/~katzj/python/fc6/. The changes from that build are largely clean-ups and shouldn't impact any basic porting effort. Jeremy [1] A few packages failed to rebuild for reasons unrelated to the new version of python and I didn't dig into all of them to fix. From wtogami at redhat.com Fri Dec 8 03:39:15 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Dec 2006 22:39:15 -0500 Subject: Help Needed: Integration of Fedora Directory Server Message-ID: <4578DE63.4020900@redhat.com> Fedora Directory Server is really close to suitable for packaging and inclusion in the Fedora distribution. Only three issues remain: 1) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196401 Review Request: mozldap Some minor issues with the .so versioning need resolving. 2) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196393 Review Request: svrcore-devel Help is needed to properly convert svrcore into a dynamic .so library. It has been suggested that autotoolizing of svrcore would be very nice, but not a requirement. Upstream will then use this dynamic .so in future versions, including the FDS to be submitted to Fedora Package Review after these two issues are solved. http://directory.fedora.redhat.com/ The Fedora Directory Server project requests your assistance in fixing these two packages in order for FDS to become suitable for Fedora packaging standards. This work isn't very difficult, but it must be done properly and acceptable for upstream inclusion. 3) The last step is to confirm that the FDS .src.rpm works reliably with db4-4.3.x included in FC6. The FDS team indicated that they are a little nervous about version 4.3, because the OpenLDAP folks do not support db4.3 due to several instability problems they have experienced. Thus FDS with db4.3 will need to go through extensive reliability testing. If db4.3 proves to be too problematic, then the decision could be made to use compat-db42 (known good) or possibly experiment with db4.4 or db4.5. http://directory.fedora.redhat.com/wiki/Mailing_Lists If you are interested in lending a hand, please talk to the folks at the FDS project. Warren Togami wtogami at redhat.com From ndbecker2 at gmail.com Fri Dec 8 12:22:48 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 8 Dec 2006 07:22:48 -0500 Subject: Help Needed: Integration of Fedora Directory Server In-Reply-To: <4578DE63.4020900@redhat.com> References: <4578DE63.4020900@redhat.com> Message-ID: <200612080722.48825.ndbecker2@gmail.com> What is the plan for dealing with java? AFAIK, FDS doesn't run without proprietary java. From mmcgrath at fedoraproject.org Fri Dec 8 14:12:20 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 8 Dec 2006 08:12:20 -0600 Subject: Help Needed: Integration of Fedora Directory Server In-Reply-To: <200612080722.48825.ndbecker2@gmail.com> References: <4578DE63.4020900@redhat.com> <200612080722.48825.ndbecker2@gmail.com> Message-ID: <3237e4410612080612v23dbd86fm6569d9459ac027ac@mail.gmail.com> On 12/8/06, Neal Becker wrote: > What is the plan for dealing with java? AFAIK, FDS doesn't run without > proprietary java. > FDS runs fine its some of the management tools that don't. And while it requires proprietary java to run the code itself isn't proprietary, not an ideal situation I know but I'm sure they're working on it. -Mike From overholt at redhat.com Fri Dec 8 15:38:30 2006 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 08 Dec 2006 10:38:30 -0500 Subject: Help Needed: Integration of Fedora Directory Server In-Reply-To: <3237e4410612080612v23dbd86fm6569d9459ac027ac@mail.gmail.com> References: <4578DE63.4020900@redhat.com> <200612080722.48825.ndbecker2@gmail.com> <3237e4410612080612v23dbd86fm6569d9459ac027ac@mail.gmail.com> Message-ID: <1165592311.4436.14.camel@toxic.toronto.redhat.com> On Fri, 2006-08-12 at 08:12 -0600, Mike McGrath wrote: > On 12/8/06, Neal Becker wrote: > > What is the plan for dealing with java? AFAIK, FDS doesn't run without > > proprietary java. > > FDS runs fine its some of the management tools that don't. And while > it requires proprietary java to run the code itself isn't proprietary, > not an ideal situation I know but I'm sure they're working on it. I know Tom Fitzsimmons looked into this and I was pretty sure that the tools *did* run with recent Classpath/libgcj snapshots. Tom? Andrew -------------- 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 fitzsim at redhat.com Fri Dec 8 16:37:34 2006 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 08 Dec 2006 11:37:34 -0500 Subject: Help Needed: Integration of Fedora Directory Server In-Reply-To: <3237e4410612080612v23dbd86fm6569d9459ac027ac@mail.gmail.com> References: <4578DE63.4020900@redhat.com> <200612080722.48825.ndbecker2@gmail.com> <3237e4410612080612v23dbd86fm6569d9459ac027ac@mail.gmail.com> Message-ID: <457994CE.9060005@redhat.com> Mike McGrath wrote: > On 12/8/06, Neal Becker wrote: >> What is the plan for dealing with java? AFAIK, FDS doesn't run without >> proprietary java. >> > > > FDS runs fine its some of the management tools that don't. Which ones? The administration console runs, except for this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183962 The fix is simply to remove those unnecessary options. Remove those options from startconsole, then try running the script on a default FC-6 install. The console should work fine. Tom From buildsys at fedoraproject.org Fri Dec 8 23:23:53 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 8 Dec 2006 18:23:53 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-08 Message-ID: <20061208232353.EFC5615212F@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libsepol FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) quagga FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) tar FC6-updates > FC7 (2:1.15.1-22.fc6 > 2:1.15.1-21.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.4-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.4-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.5-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.5-1.fc6 > 0:0.2.1-1.fc6) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.4-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.4-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.5-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.5-1.fc6 > 0:0.2.1-1.fc6) libsepol: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) quagga: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) smart: Axel.Thimm AT ATrpms.net FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) tar: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (2:1.15.1-22.fc6 > 2:1.15.1-21.fc7) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From chris.stone at gmail.com Sat Dec 9 01:11:26 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 8 Dec 2006 17:11:26 -0800 Subject: Heads-up: python 2.5 on its way In-Reply-To: <1165525478.24598.17.camel@orodruin.boston.redhat.com> References: <1165439871.8344.9.camel@aglarond.local> <1165525478.24598.17.camel@orodruin.boston.redhat.com> Message-ID: On 12/7/06, Jeremy Katz wrote: > On Wed, 2006-12-06 at 16:17 -0500, Jeremy Katz wrote: > > This is just a heads up that I'm in the progress of getting python 2.5 > > staged for the development tree. At this point, I'm doing the build on > > the side and trying to get a good chunk of the Core packages rebuilt > > against it before pushing to the development tree itself. I'm still > > hoping to be able to do the actual move over either later today or > > tomorrow (depending on how fast the Core build system decides to be) > > As warned, these packages are built and are now moving over so should be > showing up in tomorrow's development push. > > I've rebuilt the majority of Core which showed up with a dep on > python[1], but I'm sure I missed something in my query. Also, there's a > healthy number of packages in Extras which will be hit by this as well. > > If anyone runs into any problems or has any questions, let me know. And > if you need a python25 package to play with while on FC6, my slightly > older packages are still available at > http://people.redhat.com/~katzj/python/fc6/. The changes from that > build are largely clean-ups and shouldn't impact any basic porting > effort. > > Jeremy > > [1] A few packages failed to rebuild for reasons unrelated to the new > version of python and I didn't dig into all of them to fix. One of my python packages is refusing to build on fc7 with the following error: error: invalid Python installation: unable to open /usr/include/python2.5/pyconfig-32.h (No such file or directory) All I'm doing is: %{__python} setup.py install -O1 --skip-build --root %{buildroot} And the setup.py script is some tiny file which doesn't look like it has any checks for this. Anyone have any idea what could be going on here? From chris.stone at gmail.com Sat Dec 9 01:20:06 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 8 Dec 2006 17:20:06 -0800 Subject: Heads-up: python 2.5 on its way In-Reply-To: References: <1165439871.8344.9.camel@aglarond.local> <1165525478.24598.17.camel@orodruin.boston.redhat.com> Message-ID: On 12/8/06, Christopher Stone wrote: > On 12/7/06, Jeremy Katz wrote: > > On Wed, 2006-12-06 at 16:17 -0500, Jeremy Katz wrote: > > > This is just a heads up that I'm in the progress of getting python 2.5 > > > staged for the development tree. At this point, I'm doing the build on > > > the side and trying to get a good chunk of the Core packages rebuilt > > > against it before pushing to the development tree itself. I'm still > > > hoping to be able to do the actual move over either later today or > > > tomorrow (depending on how fast the Core build system decides to be) > > > > As warned, these packages are built and are now moving over so should be > > showing up in tomorrow's development push. > > > > I've rebuilt the majority of Core which showed up with a dep on > > python[1], but I'm sure I missed something in my query. Also, there's a > > healthy number of packages in Extras which will be hit by this as well. > > > > If anyone runs into any problems or has any questions, let me know. And > > if you need a python25 package to play with while on FC6, my slightly > > older packages are still available at > > http://people.redhat.com/~katzj/python/fc6/. The changes from that > > build are largely clean-ups and shouldn't impact any basic porting > > effort. > > > > Jeremy > > > > [1] A few packages failed to rebuild for reasons unrelated to the new > > version of python and I didn't dig into all of them to fix. > > One of my python packages is refusing to build on fc7 with the following error: > > error: invalid Python installation: unable to open > /usr/include/python2.5/pyconfig-32.h (No such file or directory) > > All I'm doing is: > %{__python} setup.py install -O1 --skip-build --root %{buildroot} > > And the setup.py script is some tiny file which doesn't look like it > has any checks for this. Anyone have any idea what could be going on > here? > hrm, adding python-devel to the BR was needed to fix this. I was under the impressions that as of FC5 one no longer needed to do this? My package built fine with FC5 and FC6 without having python-devel in the BR, why is it needed now? From opensource at till.name Sat Dec 9 14:07:06 2006 From: opensource at till.name (Till Maas) Date: Sat, 09 Dec 2006 15:07:06 +0100 Subject: Heads-up: python 2.5 on its way In-Reply-To: References: <1165439871.8344.9.camel@aglarond.local> Message-ID: <200612091507.25874.opensource@till.name> On Saturday 09 December 2006 02:20, Christopher Stone wrote: > hrm, adding python-devel to the BR was needed to fix this. I was > under the impressions that as of FC5 one no longer needed to do this? > My package built fine with FC5 and FC6 without having python-devel in > the BR, why is it needed now? I don't know why, but offlineimap needed BR: python-devel, too. 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 fedora at leemhuis.info Sat Dec 9 15:06:29 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 09 Dec 2006 16:06:29 +0100 Subject: python-devel as BR (was: Re: Heads-up: python 2.5 on its way) In-Reply-To: <200612091507.25874.opensource@till.name> References: <1165439871.8344.9.camel@aglarond.local> <200612091507.25874.opensource@till.name> Message-ID: <457AD0F5.70905@leemhuis.info> Till Maas schrieb: > On Saturday 09 December 2006 02:20, Christopher Stone wrote: >> hrm, adding python-devel to the BR was needed to fix this. I was >> under the impressions that as of FC5 one no longer needed to do this? >> My package built fine with FC5 and FC6 without having python-devel in >> the BR, why is it needed now? > I don't know why, but offlineimap needed BR: python-devel, too. I'm not 100% sure, but the situation is like this afaics: python-devel gets pull in the default buildroot of FE5 and FE6 by some dep from the list at http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions That seems to have changed in devel. That was noticed for the first time some weeks ago -- some people discussed this in #fedora-extras iirc (or was it even discussed on one of the several lists? not sure, can't remember) and wanted to further investigate, but nothing "official" came out of it afaik. Anyway, how to proceed? python-devel is not in the Full Exception list from http://www.fedoraproject.org/wiki/Extras/FullExceptionList and thus should have been listed as BR normally in any case. It further seems people would like to keep the default buildroot as small as possible. Thus simply adding the BR:python-devel seems like the best to me. CU thl From opensource at till.name Sat Dec 9 15:33:14 2006 From: opensource at till.name (Till Maas) Date: Sat, 09 Dec 2006 16:33:14 +0100 Subject: python-devel as BR In-Reply-To: <457AD0F5.70905@leemhuis.info> References: <1165439871.8344.9.camel@aglarond.local> <200612091507.25874.opensource@till.name> <457AD0F5.70905@leemhuis.info> Message-ID: <200612091633.22847.opensource@till.name> On Saturday 09 December 2006 16:06, Thorsten Leemhuis wrote: > I'm not 100% sure, but the situation is like this afaics: python-devel > gets pull in the default buildroot of FE5 and FE6 by some dep from the > list at http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions Last monday python-devel was not needed for offlineimap to build in devel: http://buildsys.fedoraproject.org/logs/fedora-development-extras/22897-offlineimap-4.0.16-2.fc7/noarch/root.log In FC6, pyconfig-32.h is in python-devel, so it seems that there was a change that pyconfig-32.h is now (with python 2.5) required for some reason. 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 kevin at tummy.com Sat Dec 9 19:17:15 2006 From: kevin at tummy.com (Kevin Fenzi) Date: Sat, 9 Dec 2006 12:17:15 -0700 Subject: Package EVR problems in FC+FE 2006-12-08 In-Reply-To: <20061208232353.EFC5615212F@buildsys.fedoraproject.org> References: <20061208232353.EFC5615212F@buildsys.fedoraproject.org> Message-ID: <20061209121715.52d00e41@ningauble.scrye.com> On Fri, 8 Dec 2006 18:23:53 -0500 (EST) buildsys at fedoraproject.org wrote: Is there any way someone inside redhat could push to get these core EVR problems fixed? They have lingered around for quite a long time... The FC7/devel ones aren't as big of a deal, but the release ones really can mess up peoples machines and should be fixed asap. (IMHO) (I can start in on bugging people about the devel ones once we have the non devel ones taken care of) I've listed the bug numbers below for those that have them. As a side note, is this script sending emails to the maintainers (where known)? From the reaction of some extras folks when I bugged them to fix EVR issues it didn't sound like they knew about them... > UNKNOWN OWNER (possibly Core package): > device-mapper > FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208533 Open since 2006-09-29. > iscsi-initiator-utils > FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) > > libsepol > FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) > > lvm2 > FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219037 (just filed it) > mozilla > FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > > 37:1.7.13-1.1.fc4) > FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > > 37:1.7.13-1.1.fc5) This is a tricky one, but perhaps if FL3 could release a seamonkey that obsoleted mozilla it could be fixed? See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209167 > quagga > FC4-updates > FC5-updates (0:0.98.6-1.fc4 > 0:0.98.6-1.FC5) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219038 (just filed) > setools > FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) > > tar > FC6-updates > FC7 (2:1.15.1-22.fc6 > 2:1.15.1-21.fc7) > > xen > FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) > FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219039 (just filed) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Dec 10 22:22:47 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Dec 2006 00:22:47 +0200 Subject: libdvdread - OK for Extras? In-Reply-To: <20061127215025.GF15280@devserv.devel.redhat.com> References: <20061127211652.GD10795@rathann.pekin.waw.pl> <20061127215025.GF15280@devserv.devel.redhat.com> Message-ID: <1165789368.3505.7.camel@viper.local> On Mon, 2006-11-27 at 16:50 -0500, Jeff Garzik wrote: > Is there any chance of getting dvdauthor into Extras? It doesn't seem > to require anything outside of Core except for libdvdread. Hopefully there is: https://bugzilla.redhat.com/219103 From katzj at redhat.com Mon Dec 11 15:38:54 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 11 Dec 2006 10:38:54 -0500 Subject: python-devel as BR In-Reply-To: <200612091633.22847.opensource@till.name> References: <1165439871.8344.9.camel@aglarond.local> <200612091507.25874.opensource@till.name> <457AD0F5.70905@leemhuis.info> <200612091633.22847.opensource@till.name> Message-ID: <1165851534.2555.4.camel@aglarond.local> On Sat, 2006-12-09 at 16:33 +0100, Till Maas wrote: > On Saturday 09 December 2006 16:06, Thorsten Leemhuis wrote: > > I'm not 100% sure, but the situation is like this afaics: python-devel > > gets pull in the default buildroot of FE5 and FE6 by some dep from the > > list at http://www.fedoraproject.org/wiki/Packaging/Guidelines#Exceptions > > Last monday python-devel was not needed for offlineimap to build in devel: > http://buildsys.fedoraproject.org/logs/fedora-development-extras/22897-offlineimap-4.0.16-2.fc7/noarch/root.log > > In FC6, pyconfig-32.h is in python-devel, so it seems that there was a change > that pyconfig-32.h is now (with python 2.5) required for some reason. distutils is now using pyconfig for finding the config information that python was built with; previously, it used the bits under %{_libdir}/python2.4/config which arguably should be in python-devel as well. So while I could hack around to make things build with just python installed, I think that BR: python-devel is the more correct way to go. Seem sane to everyone? And apologies, I meant to include this in the second mail since I noticed it with a couple of packages in Core (3 packages needed modification for this), but it had slipped my mind by the time I sent mail. Jeremy From jkeating at redhat.com Mon Dec 11 15:54:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 11 Dec 2006 10:54:20 -0500 Subject: python-devel as BR In-Reply-To: <1165851534.2555.4.camel@aglarond.local> References: <1165439871.8344.9.camel@aglarond.local> <200612091633.22847.opensource@till.name> <1165851534.2555.4.camel@aglarond.local> Message-ID: <200612111054.20589.jkeating@redhat.com> On Monday 11 December 2006 10:38, Jeremy Katz wrote: > So while I could hack around to make things build with just python > installed, I think that BR: python-devel is the more correct way to go. > Seem sane to everyone? Seems sane to me. Separation of runtime vs buildtime stuff is always good (: -- 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 paul at city-fan.org Mon Dec 11 18:33:18 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 11 Dec 2006 18:33:18 +0000 Subject: Heads-up: python 2.5 on its way In-Reply-To: <1165525478.24598.17.camel@orodruin.boston.redhat.com> References: <1165439871.8344.9.camel@aglarond.local> <1165525478.24598.17.camel@orodruin.boston.redhat.com> Message-ID: <457DA46E.1020902@city-fan.org> Jeremy Katz wrote: > On Wed, 2006-12-06 at 16:17 -0500, Jeremy Katz wrote: > If anyone runs into any problems or has any questions, let me know. And > if you need a python25 package to play with while on FC6, my slightly > older packages are still available at > http://people.redhat.com/~katzj/python/fc6/. The changes from that > build are largely clean-ups and shouldn't impact any basic porting > effort. > > Jeremy > > [1] A few packages failed to rebuild for reasons unrelated to the new > version of python and I didn't dig into all of them to fix. One of these packages is pyOpenSSL; attached patch fixes build on Rawhide and does some general cleanups. Cheers, Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: pyOpenSSL-1.p24.9.patch Type: text/x-patch Size: 2722 bytes Desc: not available URL: From buildsys at fedoraproject.org Mon Dec 11 19:51:22 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 11 Dec 2006 14:51:22 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-11 Message-ID: <20061211195122.758B715212F@buildsys.fedoraproject.org> Axel.Thimm AT ATrpms.net: smart FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libsepol FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.4-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.4-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.5-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.5-1.fc6 > 0:0.2.1-1.fc6) orion AT cora.nwra.com: pytz FE4 > FE7 (0:2006p-1.fc4 > 0:2006g-1.fc6) FE5 > FE7 (0:2006p-1.fc5 > 0:2006g-1.fc6) FE6 > FE7 (0:2006p-1.fc6 > 0:2006g-1.fc6) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.4-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.4-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.5-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.5-1.fc6 > 0:0.2.1-1.fc6) libsepol: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) php-shout: fedora AT theholbrooks.org FE6 > FE7 (0:0.9.1-1.fc6 > 0:0.3.1-6.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) pytz: orion AT cora.nwra.com FE4 > FE7 (0:2006p-1.fc4 > 0:2006g-1.fc6) FE5 > FE7 (0:2006p-1.fc5 > 0:2006g-1.fc6) FE6 > FE7 (0:2006p-1.fc6 > 0:2006g-1.fc6) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) smart: Axel.Thimm AT ATrpms.net FE4 > FE7 (0:0.42-40.fc4 > 0:0.42-39.fc6) FE5 > FE7 (0:0.42-40.fc5 > 0:0.42-39.fc6) FE6 > FE7 (0:0.42-40.fc6 > 0:0.42-39.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From jspaleta at gmail.com Tue Dec 12 06:18:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 11 Dec 2006 21:18:16 -0900 Subject: Heads-up: python 2.5 on its way In-Reply-To: <1165439871.8344.9.camel@aglarond.local> References: <1165439871.8344.9.camel@aglarond.local> Message-ID: <604aa7910612112218j4732db35ib788b06368c97b38@mail.gmail.com> On 12/6/06, Jeremy Katz wrote: > This is just a heads up that I'm in the progress of getting python 2.5 > staged for the development tree. At this point, I'm doing the build on > the side and trying to get a good chunk of the Core packages rebuilt > against it before pushing to the development tree itself. I'm still > hoping to be able to do the actual move over either later today or > tomorrow (depending on how fast the Core build system decides to be) I need a clear policy statement with regard to how the frell I'm suppose to get my python packages in Extras rebuilt in a timely manner. Do i have the authority to bump release packages underneath mine as needed? Or do I have to sit on my hands waiting for the maintainers to have the time to deal with this? I'd like to avoid pissing all over someone little packaging empire, but I'm prepared to slash and burn my way through the heart of the python stack if need be to get scipy buildable again. Considering the holiday season I am very concerned that we will have an unbuildable python stack in Extras for another month, as we wait for maintainers to dribble back from a holiday afk, unless those of us with the time and the community goodwill are able to step and and punch bump/builds through the system in an orderly manner NOW. Do we have a ticking clock condition here? Am I suppose to wait some amount of time, gentlemanly-like, before I start hammering my way through the python package space cleaning this crap up? -jef"sharpening his new titanium eye-poking stick"spaleta From fedora at leemhuis.info Tue Dec 12 06:52:04 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 12 Dec 2006 07:52:04 +0100 Subject: Heads-up: python 2.5 on its way In-Reply-To: <604aa7910612112218j4732db35ib788b06368c97b38@mail.gmail.com> References: <1165439871.8344.9.camel@aglarond.local> <604aa7910612112218j4732db35ib788b06368c97b38@mail.gmail.com> Message-ID: <457E5194.2000504@leemhuis.info> Jeff Spaleta schrieb: > On 12/6/06, Jeremy Katz wrote: >> This is just a heads up that I'm in the progress of getting python >> 2.5 staged for the development tree. At this point, I'm doing the >> build on the side and trying to get a good chunk of the Core >> packages rebuilt against it before pushing to the development tree >> itself. I'm still hoping to be able to do the actual move over >> either later today or tomorrow (depending on how fast the Core >> build system decides to be) > > I need a clear policy statement with regard to how the frell I'm > suppose to get my python packages in Extras rebuilt in a timely > manner. > > Do i have the authority to bump release packages underneath mine as > needed? [...] IMHO: yes; see http://www.fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages We should add the current problem at hand to the section below to make it explicit for the future. > Minor, general or cleanup changes > > Sometimes there are situations where it's simply a lot easier to fix > stuff directly in cvs than via bugzilla and the proper maintainers. > So much easier that we should leave this path open. These situations > shouldn't arise that often. Some examples of situations were > bypassing the proper maintained is considered fine: > > * support for a new architecture -- that often requires that a lot of > packages need adjustments or patches that packagers often can't even > test themself. Getting all those modifications in via bugzilla is a > lot of annoying work, so these things can be fixed directly in the > devel branch of cvs without contacting the individual maintainers if > the general effort was announced beforehand. A SIG should handle the > stuff and continue with normal operations after the initial porting > efforts are finished. > * small fixes or adjustments for new or modified packaging guidelines > can be done directly in CVS after being announced some days in > advance. > * mass rebuilds CU thl From tgl at redhat.com Tue Dec 12 06:58:43 2006 From: tgl at redhat.com (Tom Lane) Date: Tue, 12 Dec 2006 01:58:43 -0500 Subject: Heads-up: python 2.5 on its way In-Reply-To: <604aa7910612112218j4732db35ib788b06368c97b38@mail.gmail.com> References: <1165439871.8344.9.camel@aglarond.local> <604aa7910612112218j4732db35ib788b06368c97b38@mail.gmail.com> Message-ID: <25375.1165906723@sss.pgh.pa.us> "Jeff Spaleta" writes: > On 12/6/06, Jeremy Katz wrote: >> This is just a heads up that I'm in the progress of getting python 2.5 >> staged for the development tree. > I need a clear policy statement with regard to how the frell I'm > suppose to get my python packages in Extras rebuilt in a timely > manner. > Do i have the authority to bump release packages underneath mine as > needed? Or do I have to sit on my hands waiting for the maintainers to > have the time to deal with this? Mebbe I shouldn't stick my neck out here, but: as long as I've been at Red Hat, it's been OK for any package maintainer to force a rebuild of someone else's dependent package. If you find that any noticeable source code changes are required then it'd be wise to consult, but if it's just a matter of bump-the-release-number-add-a-changelog-entry- and-rebuild, then go ahead and do it. Most maintainers will be happy that you didn't make them jump through such a silly hoop. (Some people actually have mass-rebuilds automated, particularly those reponsible for gcc, glibc, etc...) regards, tom lane From buildsys at fedoraproject.org Tue Dec 12 18:17:15 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 12 Dec 2006 13:17:15 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-12 Message-ID: <20061212181715.4578115212F@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) libsepol FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) setools FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) squid FC6-updates > FC7 (7:2.6.STABLE6-1.fc6 > 7:2.6.STABLE5-1.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xorg-x11-drv-tdfx FC6-updates > FC7 (0:1.3.0-2.fc6 > 0:1.3.0-1.fc7) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) i AT stingr.net: flow-tools FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) icon AT fedoraproject.org: cvs2svn FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) jwilson AT redhat.com: ip6sic FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) mdehaan AT redhat.com: cobbler FE5 > FE7 (0:0.3.4-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.4-1.fc6 > 0:0.2.8-1.fc6) koan FE5 > FE7 (0:0.2.5-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.5-1.fc6 > 0:0.2.1-1.fc6) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) cobbler: mdehaan AT redhat.com FE5 > FE7 (0:0.3.4-1.fc5 > 0:0.2.8-1.fc6) FE6 > FE7 (0:0.3.4-1.fc6 > 0:0.2.8-1.fc6) cvs2svn: icon AT fedoraproject.org FE5 > FE7 (0:1.5.0-1.fc5 > 0:1.4.0-2.fc6) FE6 > FE7 (0:1.5.0-1.fc6 > 0:1.4.0-2.fc6) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flow-tools: i AT stingr.net FE3 > FE7 (0:0.68-12.fc3 > 0:0.68-11.fc6) FE4 > FE7 (0:0.68-12.fc4 > 0:0.68-11.fc6) FE5 > FE7 (0:0.68-12.fc5 > 0:0.68-11.fc6) FE6 > FE7 (0:0.68-12.fc6 > 0:0.68-11.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) ip6sic: jwilson AT redhat.com FE6 > FE7 (0:0.1-5.fc6 > 0:0.1-4.fc6) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) koan: mdehaan AT redhat.com FE5 > FE7 (0:0.2.5-1.fc5 > 0:0.2.1-1.fc6) FE6 > FE7 (0:0.2.5-1.fc6 > 0:0.2.1-1.fc6) libsepol: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.15.3-1.fc6 > 0:1.15.3-1) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) setools: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:3.0-2.fc6 > 0:3.0-2) squid: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (7:2.6.STABLE6-1.fc6 > 7:2.6.STABLE5-1.fc7) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) xorg-x11-drv-tdfx: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.3.0-2.fc6 > 0:1.3.0-1.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From ajackson at redhat.com Tue Dec 12 18:58:21 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 12 Dec 2006 13:58:21 -0500 Subject: Package EVR problems in FC+FE 2006-12-12 In-Reply-To: <20061212181715.4578115212F@buildsys.fedoraproject.org> References: <20061212181715.4578115212F@buildsys.fedoraproject.org> Message-ID: <1165949901.7683.244.camel@localhost.localdomain> On Tue, 2006-12-12 at 13:17 -0500, buildsys at fedoraproject.org wrote: > xorg-x11-drv-tdfx > FC6-updates > FC7 (0:1.3.0-2.fc6 > 0:1.3.0-1.fc7) Whoops, cvs had the changes but they never got built. Should be fixed tomorrow. - ajax From jspaleta at gmail.com Tue Dec 12 20:48:49 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 12 Dec 2006 11:48:49 -0900 Subject: Heads-up: python 2.5 on its way In-Reply-To: <25375.1165906723@sss.pgh.pa.us> References: <1165439871.8344.9.camel@aglarond.local> <604aa7910612112218j4732db35ib788b06368c97b38@mail.gmail.com> <25375.1165906723@sss.pgh.pa.us> Message-ID: <604aa7910612121248y2fc673f7pa9d159efaf79f331@mail.gmail.com> On 12/11/06, Tom Lane wrote: > Mebbe I shouldn't stick my neck out here, but: as long as I've been at > Red Hat, it's been OK for any package maintainer to force a rebuild of > someone else's dependent package. Its a brave new world in Extras. A brave new world full of community personalities and opinions not constrained by the soul-sucking inertia of a delineated management structure, nor bound together by the anti-boat-tipping/anti-bridge-burning forces of a steady paycheck from a common green and lush oasis. So while there maybe a rational consensus with regard to good Samaritan best effort, I will always be wary of running into that one contributor who dissents. As much as I love mailinglist bloodsport and a host of other forms of metaphorical violence, I don't want to have to engage in such activities with such frequency that my tastes for them are dulled. We really haven't made it a requirement that contributors signoff on the whole, "I won't be an ass if someone else goes in and fixes trivial crap for me" concept. We should do that, we really need to have a "I won't be an ass" creed to go along with the "I won't be evil" creed. Make it as explicit as we can as to where the boundary of personal control is versus shared control over the codebase. And fined grained access control, is just going to make this sort of crap harder to deal with in the future... because then you'll have to identify those people with masterkeys to the cvs and they will be the ones expected to clear this sort of poopage up. Instead of making it easy for those of us with time to fix the trivial breakages. Because from release cycle to release cycle, different people will have the spare time to run point for these issues, and you'll be hard pressed to predict who those people are two months ahead of time. And no, I've absolutely no desire to be tapped as one of the poor suckers with wide access in the fine-grained access control future. -jef"I find a 5 minute shouting match is an effective an areobic excercise as 10 minutes of jogging"spaleta From bugs.michael at gmx.net Wed Dec 13 14:56:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Dec 2006 15:56:36 +0100 Subject: More Extras orphans on the hit list Message-ID: <20061213155636.8ad10d49.bugs.michael@gmx.net> The following Fedora Extras packages have been orphaned prior to December 1st and need a new maintainer: gdome2 gtranslator perl-String-Ediff python-htmltmpl python-id3 t1lib t1utils ttf2pt1 From williams at redhat.com Wed Dec 13 15:30:35 2006 From: williams at redhat.com (Clark Williams) Date: Wed, 13 Dec 2006 09:30:35 -0600 Subject: More Extras orphans on the hit list In-Reply-To: <20061213155636.8ad10d49.bugs.michael@gmx.net> References: <20061213155636.8ad10d49.bugs.michael@gmx.net> Message-ID: <45801C9B.5060108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: > The following Fedora Extras packages have been orphaned prior to > December 1st and need a new maintainer: > python-id3 I use this one and would hate to see it go away. I'll take it if no one else has a desire for it. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFgByaHyuj/+TTEp0RAiKQAKDYtubXdjrdU3OaLiVBJlyz/5cs8QCgw3dU 8WnbWfKqHXFY52tsX4bih00= =sqvH -----END PGP SIGNATURE----- From bpepple at fedoraproject.org Wed Dec 13 16:44:13 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 13 Dec 2006 11:44:13 -0500 Subject: More Extras orphans on the hit list In-Reply-To: <45801C9B.5060108@redhat.com> References: <20061213155636.8ad10d49.bugs.michael@gmx.net> <45801C9B.5060108@redhat.com> Message-ID: <1166028253.11616.3.camel@Chuck> On Wed, 2006-12-13 at 09:30 -0600, Clark Williams wrote: > Michael Schwendt wrote: > > The following Fedora Extras packages have been orphaned prior to > > December 1st and need a new maintainer: > > > python-id3 > > I use this one and would hate to see it go away. I'll take it if no one > else has a desire for it. Why not use python-eyeD3 which is already in FE? http://eyed3.nicfit.net/ /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 williams at redhat.com Wed Dec 13 17:00:06 2006 From: williams at redhat.com (Clark Williams) Date: Wed, 13 Dec 2006 11:00:06 -0600 Subject: More Extras orphans on the hit list In-Reply-To: <1166028253.11616.3.camel@Chuck> References: <20061213155636.8ad10d49.bugs.michael@gmx.net> <45801C9B.5060108@redhat.com> <1166028253.11616.3.camel@Chuck> Message-ID: <45803196.8010003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Pepple wrote: > On Wed, 2006-12-13 at 09:30 -0600, Clark Williams wrote: >> Michael Schwendt wrote: >>> The following Fedora Extras packages have been orphaned prior to >>> December 1st and need a new maintainer: >> >>> python-id3 >> I use this one and would hate to see it go away. I'll take it if no one >> else has a desire for it. > > Why not use python-eyeD3 which is already in FE? > http://eyed3.nicfit.net/ > Ummm, because I didn't know about it? :) I have a script that I wrote a couple of years back (ripit) that uses the CDDB and ID3 python modules and I haven't needed to change. I'll go take a look eyeD3 and see if I should port my script to it. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFgDGWHyuj/+TTEp0RAlK8AJ0Q5IMfemdLtb+Ixp55bsBXSGWjxgCgvNfq dNYbB0/B1ZDu4+GObLfPI+U= =UiRw -----END PGP SIGNATURE----- From fedora at leemhuis.info Wed Dec 13 18:24:50 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Dec 2006 19:24:50 +0100 Subject: Plan for tomorrows (20061213) FESCO meeting Message-ID: <45804572.5080809@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-extras on irc.freenode.org. > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- push scripts for epel > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- disttag confusion > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- open EPEL for sponsors and people maintaining more then 5 packages in Extras? > /topic FESCo meeting -- Opening Core - (warren, jeremy, rdieter) -- status update > /topic FESCO-Meeting -- Encourage co-maintainership -- c4chris > /topic FESCo meeting -- MISC -- what to do with all those broken deps and upgrade paths > /topic FESCo meeting -- MISC -- lots of python stuff that needs rebuilding > /topic FESCo meeting -- Packaging Committee Report > /topic FESCO-Meeting -- packages with static libs approval -- sparse (mdomsch) -- [WWW] https://www.redhat.com/archives/fedora-packaging/2006-December/msg00034.html > /topic FESCO-Meeting -- kmod approval -- gspca [WWW] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209112 > /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple -- EOL plans > /topic FESCo meeting -- Alternative paths of membership advancement -- warren > /topic FESCo meeting -- Free discussion around Fedora Extras You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule The individual pages specific to the topics are linked from there. The same as above holds true: if you name is somewhere on the schedule page in the wiki please update the status in the wiki ahead of the meeting. Ohh, and please update it also directly after the meeting so it's update and prepared for next weeks meeting :-) Hint: If you want to know what FESCo is doing simply subscribe in the wiki to "Extras/Schedul.*" and you'll get mails if something changes in that areas of the wiki. That should give you a good idea of FESCo's work. CU thl From jwilson at redhat.com Wed Dec 13 19:08:46 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 13 Dec 2006 14:08:46 -0500 Subject: Heads-up: python 2.5 on its way In-Reply-To: <1165439871.8344.9.camel@aglarond.local> References: <1165439871.8344.9.camel@aglarond.local> Message-ID: <200612131408.50138.jwilson@redhat.com> On Wednesday 06 December 2006 16:17, Jeremy Katz wrote: > This is just a heads up that I'm in the progress of getting python 2.5 > staged for the development tree. [...] Note to anyone with packages that build-require numpy: there was a problem building numpy with python 2.5, the fix for which has been incorporated in python 2.5-5.fc7, which should show up shortly. Once it does, numpy will get built, and then anything build-requiring numpy can finally get built. Sorry for the delay... -- 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 bugs.michael at gmx.net Wed Dec 13 22:37:47 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 13 Dec 2006 23:37:47 +0100 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <45804572.5080809@leemhuis.info> References: <45804572.5080809@leemhuis.info> Message-ID: <20061213233747.c18d920d.bugs.michael@gmx.net> On Wed, 13 Dec 2006 19:24:50 +0100, Thorsten Leemhuis wrote: > Hi all, > > find below the list of topics that are likely to come up in the next > FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in > #fedora-extras on irc.freenode.org. > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora Extras" phase. I'd like to see a quick decision on: "Stop running repoview for debuginfo packages!" The rationale is as follows: * I have strong doubts that browsing repoview pages for debuginfo packages (in _addition_ to normal packages!) is popular. Example: http://fedoraproject.org/extras/6/i386/debug/repodata/ * The repoview page for a main package ought to cover whether a debuginfo package is available and what its name is. Remember, its name is based on the src.rpm %{name}, not the binary sub-package name. * Running repoview takes time. * Running it on "debug" repositories takes additional time. The more stuff we run during repository maintenance, the sooner we will need to deal with delays because something has locked the repository, and we will need special features to interrupt update-jobs like repoview. [1] * Repoview for debuginfo packages creates many thousand HTML files in addition to the repoview pages for the normal packages, and it creates even many more updated files than updates packages because of the alphabetically sorted index of packages in the left frame of a repoview page. * It seems I'm not alone with my point of view. :) See e.g. https://www.redhat.com/mailman/private/fedora-infrastructure-list/2006-December/msg00054.html -- [1] Most likely we will end up with a queueing system for automated repository maintenance jobs (like repoprune, createrepo, repoview) anyway. But that is no reason to run stuff that is unnecessary. From jamatos at fc.up.pt Thu Dec 14 09:33:52 2006 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 14 Dec 2006 09:33:52 +0000 Subject: More Extras orphans on the hit list In-Reply-To: <20061213155636.8ad10d49.bugs.michael@gmx.net> References: <20061213155636.8ad10d49.bugs.michael@gmx.net> Message-ID: <200612140933.52848.jamatos@fc.up.pt> On Wednesday 13 December 2006 2:56 pm, Michael Schwendt wrote: > The following Fedora Extras packages have been orphaned prior to > December 1st and need a new maintainer: > > t1lib > t1utils > ttf2pt1 I have adopted these packages, I was co-maintainer in two of them already. -- Jos? Ab?lio From jwboyer at jdub.homelinux.org Thu Dec 14 14:25:26 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 14 Dec 2006 08:25:26 -0600 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <20061213233747.c18d920d.bugs.michael@gmx.net> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> Message-ID: <1166106326.6110.25.camel@zod.rchland.ibm.com> On Wed, 2006-12-13 at 23:37 +0100, Michael Schwendt wrote: > On Wed, 13 Dec 2006 19:24:50 +0100, Thorsten Leemhuis wrote: > > > Hi all, > > > > find below the list of topics that are likely to come up in the next > > FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in > > #fedora-extras on irc.freenode.org. > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora Extras" phase. > > I'd like to see a quick decision on: > > "Stop running repoview for debuginfo packages!" > > The rationale is as follows: FESCo can discuss this, but I think it's really an infrastructure item. Have you filed a ticket with the infrastructure team? josh From bugs.michael at gmx.net Thu Dec 14 14:50:39 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Dec 2006 15:50:39 +0100 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <1166106326.6110.25.camel@zod.rchland.ibm.com> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <1166106326.6110.25.camel@zod.rchland.ibm.com> Message-ID: <20061214155039.93afc1d9.bugs.michael@gmx.net> On Thu, 14 Dec 2006 08:25:26 -0600, Josh Boyer wrote: > > I'd like to see a quick decision on: > > > > "Stop running repoview for debuginfo packages!" > > > > The rationale is as follows: > > > > FESCo can discuss this, but I think it's really an infrastructure item. > Have you filed a ticket with the infrastructure team? I have the necessary access. All I need is an offical ACK or NAK. From rdieter at math.unl.edu Thu Dec 14 14:51:33 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Dec 2006 08:51:33 -0600 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <20061214155039.93afc1d9.bugs.michael@gmx.net> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <1166106326.6110.25.camel@zod.rchland.ibm.com> <20061214155039.93afc1d9.bugs.michael@gmx.net> Message-ID: <458164F5.4010801@math.unl.edu> Michael Schwendt wrote: > On Thu, 14 Dec 2006 08:25:26 -0600, Josh Boyer wrote: > >>> I'd like to see a quick decision on: >>> >>> "Stop running repoview for debuginfo packages!" >>> >>> The rationale is as follows: >> >> >> FESCo can discuss this, but I think it's really an infrastructure item. >> Have you filed a ticket with the infrastructure team? > > I have the necessary access. All I need is an offical ACK or NAK. I'd say just do it. (Unless it would be a lot more work to undo if someone screams). -- Rex From dennis at ausil.us Thu Dec 14 14:53:44 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 14 Dec 2006 08:53:44 -0600 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <1166106326.6110.25.camel@zod.rchland.ibm.com> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <1166106326.6110.25.camel@zod.rchland.ibm.com> Message-ID: <200612140853.44877.dennis@ausil.us> On Thursday 14 December 2006 08:25, Josh Boyer wrote: > On Wed, 2006-12-13 at 23:37 +0100, Michael Schwendt wrote: > > On Wed, 13 Dec 2006 19:24:50 +0100, Thorsten Leemhuis wrote: > > > Hi all, > > > > > > find below the list of topics that are likely to come up in the next > > > FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in > > > #fedora-extras on irc.freenode.org. > > > > > > You want something to be discussed? Send a note to the list in reply to > > > this mail and I'll add it to the schedule (I can't promise we will get > > > to it tomorrow, but we'll most likely will if we don't run out of > > > time). You can also propose topics in the meeting while it is in the > > > "Free discussion around Fedora Extras" phase. > > > > I'd like to see a quick decision on: > > > > "Stop running repoview for debuginfo packages!" > > > > The rationale is as follows: > > > > FESCo can discuss this, but I think it's really an infrastructure item. > Have you filed a ticket with the infrastructure team? > > josh I say drop it from the push scripts and wait for an outcry. ive personally never used it. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From jima at beer.tclug.org Thu Dec 14 15:44:22 2006 From: jima at beer.tclug.org (Jima) Date: Thu, 14 Dec 2006 09:44:22 -0600 (CST) Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <200612140853.44877.dennis@ausil.us> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <1166106326.6110.25.camel@zod.rchland.ibm.com> <200612140853.44877.dennis@ausil.us> Message-ID: On Thu, 14 Dec 2006, Dennis Gilmore wrote: > I say drop it from the push scripts and wait for an outcry. ive personally > never used it. Neither have I, and it's not like someone with a downstream mirror can't generate the data themselves (or ask someone else to) if they truly need it. Jima From jwilson at redhat.com Thu Dec 14 15:46:39 2006 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 14 Dec 2006 10:46:39 -0500 Subject: Heads-up: python 2.5 on its way In-Reply-To: <200612131408.50138.jwilson@redhat.com> References: <1165439871.8344.9.camel@aglarond.local> <200612131408.50138.jwilson@redhat.com> Message-ID: <200612141046.43503.jwilson@redhat.com> On Wednesday 13 December 2006 14:08, Jarod Wilson wrote: > On Wednesday 06 December 2006 16:17, Jeremy Katz wrote: > > This is just a heads up that I'm in the progress of getting python 2.5 > > staged for the development tree. > > [...] > > Note to anyone with packages that build-require numpy: there was a problem > building numpy with python 2.5, the fix for which has been incorporated in > python 2.5-5.fc7, which should show up shortly. Once it does, numpy will > get built, and then anything build-requiring numpy can finally get built. > Sorry for the delay... Okay, rawhide numpy 1.0.1 build against python 2.5-5.fc7 just finished, so have at it. -- 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 opensource at till.name Thu Dec 14 15:59:02 2006 From: opensource at till.name (Till Maas) Date: Thu, 14 Dec 2006 16:59:02 +0100 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <20061213233747.c18d920d.bugs.michael@gmx.net> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> Message-ID: <200612141659.10576.opensource@till.name> On Wednesday 13 December 2006 23:37, Michael Schwendt wrote: > * I have strong doubts that browsing repoview pages for debuginfo > packages (in _addition_ to normal packages!) is popular. > Example: http://fedoraproject.org/extras/6/i386/debug/repodata/ A link to the debuginfo rpm on the page with the arch rpm would be more useful imho. I don't know whether or not it is possible with repoview at the moment, but in the longterm it would be a good improvment. A link to the src.rpm would be good there too and when the debuginfo and src.rpm only differ in the suffix it won't take much more longer. 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 bpepple at fedoraproject.org Thu Dec 14 15:24:41 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 14 Dec 2006 10:24:41 -0500 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <458164F5.4010801@math.unl.edu> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <1166106326.6110.25.camel@zod.rchland.ibm.com> <20061214155039.93afc1d9.bugs.michael@gmx.net> <458164F5.4010801@math.unl.edu> Message-ID: <1166109881.3284.0.camel@Chuck> On Thu, 2006-12-14 at 08:51 -0600, Rex Dieter wrote: > Michael Schwendt wrote: > > On Thu, 14 Dec 2006 08:25:26 -0600, Josh Boyer wrote: > > > >>> I'd like to see a quick decision on: > >>> > >>> "Stop running repoview for debuginfo packages!" > >>> > >>> The rationale is as follows: > >> > >> > >> FESCo can discuss this, but I think it's really an infrastructure item. > >> Have you filed a ticket with the infrastructure team? > > > > I have the necessary access. All I need is an offical ACK or NAK. > > I'd say just do it. (Unless it would be a lot more work to undo if > someone screams). +1, I can't really see anyone being opposed to this. /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 cra at WPI.EDU Thu Dec 14 16:37:35 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 14 Dec 2006 11:37:35 -0500 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <20061213233747.c18d920d.bugs.michael@gmx.net> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> Message-ID: <20061214163735.GD4408@angus.ind.WPI.EDU> On Wed, Dec 13, 2006 at 11:37:47PM +0100, Michael Schwendt wrote: > * Repoview for debuginfo packages creates many thousand HTML files in > addition to the repoview pages for the normal packages, and it creates > even many more updated files than updates packages because of the > alphabetically sorted index of packages in the left frame of a repoview > page. Is there a way to run repoview on the normal packages such that it doesn't recreate new files on every run, wasting everyone's bandwidth who has to sync the new files over and over again, even though their contents should be identical to the ones generated before? From rdieter at math.unl.edu Thu Dec 14 16:43:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Dec 2006 10:43:54 -0600 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <20061214163735.GD4408@angus.ind.WPI.EDU> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <20061214163735.GD4408@angus.ind.WPI.EDU> Message-ID: <45817F4A.8050403@math.unl.edu> Chuck Anderson wrote: > On Wed, Dec 13, 2006 at 11:37:47PM +0100, Michael Schwendt wrote: >> * Repoview for debuginfo packages creates many thousand HTML files in >> addition to the repoview pages for the normal packages, and it creates >> even many more updated files than updates packages because of the >> alphabetically sorted index of packages in the left frame of a repoview >> page. > > Is there a way to run repoview on the normal packages such that it > doesn't recreate new files on every run, wasting everyone's bandwidth Only if you're not using rsync. (: -- Rex From tibbs at math.uh.edu Thu Dec 14 17:31:08 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Dec 2006 11:31:08 -0600 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <45817F4A.8050403@math.unl.edu> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <20061214163735.GD4408@angus.ind.WPI.EDU> <45817F4A.8050403@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> Only if you're not using rsync. (: But all of the repoview files are updated at each run, so rsync thinks it needs to transfer them over and over again. It may only checksum each side, but it still has to do work. I agree, it would be awesomely great if repoview didn't recreate the html files for those packages without changes. - J< From bugs.michael at gmx.net Thu Dec 14 19:17:50 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Dec 2006 20:17:50 +0100 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <20061214163735.GD4408@angus.ind.WPI.EDU> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <20061214163735.GD4408@angus.ind.WPI.EDU> Message-ID: <20061214201750.18886715.bugs.michael@gmx.net> On Thu, 14 Dec 2006 11:37:35 -0500, Chuck Anderson wrote: > Is there a way to run repoview on the normal packages such that it > doesn't recreate new files on every run, wasting everyone's bandwidth > who has to sync the new files over and over again, even though their > contents should be identical to the ones generated before? Short answer: It doesn't recreate files by default. Since end of October, any repoview page that is updated contains changes actually. Long answer: Inside the repoview code, it is called "smartWrite" and doesn't rewrite a html page when its checksum is unchanged, Still, Repoview recreates more files than necessary, because adding/removing packages changes the list of adjacent package names in the left frame of every page. But to make it worse, old code in the extras-repoview.py script removed the entire repoview directory prior to running createrepo, because its existence breaks createrepo <= 0.4.4. So, for a long time, all repoview files have been created from scratch. It has not been considered a problem, and I haven't had interest in the repoview script either until reviewing it begun. By chance, around the same time, Jakub Jelinek contacted me and told me that the thousands of recreated repoview pages cause a lot of unnecessary load for mirrors (even with rsync), and I committed a fix for it on Oct, 28th. Since that day, any file that is updated by Repoview contains changes actually. From bugs.michael at gmx.net Thu Dec 14 19:19:40 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 14 Dec 2006 20:19:40 +0100 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <20061214163735.GD4408@angus.ind.WPI.EDU> <45817F4A.8050403@math.unl.edu> Message-ID: <20061214201940.a36548f8.bugs.michael@gmx.net> On 14 Dec 2006 11:31:08 -0600, Jason L Tibbitts III wrote: > >>>>> "RD" == Rex Dieter writes: > > RD> Only if you're not using rsync. (: > > But all of the repoview files are updated at each run, so rsync thinks > it needs to transfer them over and over again. It may only checksum > each side, but it still has to do work. > > I agree, it would be awesomely great if repoview didn't recreate the > html files for those packages without changes. This is misinformation. Please wait for my reply to Chuck's message. From fedora at leemhuis.info Thu Dec 14 19:34:50 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 14 Dec 2006 20:34:50 +0100 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <1166106326.6110.25.camel@zod.rchland.ibm.com> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <1166106326.6110.25.camel@zod.rchland.ibm.com> Message-ID: <4581A75A.60700@leemhuis.info> Josh Boyer schrieb: > On Wed, 2006-12-13 at 23:37 +0100, Michael Schwendt wrote: >> On Wed, 13 Dec 2006 19:24:50 +0100, Thorsten Leemhuis wrote: >>> find below the list of topics that are likely to come up in the next >>> FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in >>> #fedora-extras on irc.freenode.org. >>> You want something to be discussed? Send a note to the list in reply to >>> this mail and I'll add it to the schedule (I can't promise we will get >>> to it tomorrow, but we'll most likely will if we don't run out of time). >>> You can also propose topics in the meeting while it is in the "Free >>> discussion around Fedora Extras" phase. >> I'd like to see a quick decision on: >> "Stop running repoview for debuginfo packages!" >> The rationale is as follows: > > FESCo can discuss this It did discuss this today and agreed to stop running repoview for debuginfo packages in the future. Cu thl BTW, it would have been fine for me, too, if this would have been changed without getting FESCo involved. A simple question on the list and simply doing it if nobody yelled after 24 or 48 hours is okay for stuff like this IMHO. From tibbs at math.uh.edu Thu Dec 14 19:52:01 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Dec 2006 13:52:01 -0600 Subject: Plan for tomorrows (20061213) FESCO meeting In-Reply-To: <20061214201940.a36548f8.bugs.michael@gmx.net> References: <45804572.5080809@leemhuis.info> <20061213233747.c18d920d.bugs.michael@gmx.net> <20061214163735.GD4408@angus.ind.WPI.EDU> <45817F4A.8050403@math.unl.edu> <20061214201940.a36548f8.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> This is misinformation. Please wait for my reply to Chuck's MS> message. My apologies; I hadn't noticed that things had gotten better since I stopped paying that much attention to my mirror logs. - J< From pknirsch at redhat.com Fri Dec 15 15:20:05 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 15 Dec 2006 16:20:05 +0100 Subject: Heads-up: python 2.5 on its way In-Reply-To: <1165439871.8344.9.camel@aglarond.local> References: <1165439871.8344.9.camel@aglarond.local> Message-ID: <4582BD25.3060807@redhat.com> Jeremy Katz wrote: > This is just a heads up that I'm in the progress of getting python 2.5 > staged for the development tree. At this point, I'm doing the build on > the side and trying to get a good chunk of the Core packages rebuilt > against it before pushing to the development tree itself. I'm still > hoping to be able to do the actual move over either later today or > tomorrow (depending on how fast the Core build system decides to be) > Just ran a few tests with it today and the version in the tree and i got a nice segfault when using the bsddb module: import bsddb db = bsddb.hashopen("/var/lib/rpm/Basenames", "r") died on me. Simply installing the latest db4 and db4-devel and then rebuilding python fixed it for me. 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 buildsys at fedoraproject.org Fri Dec 15 20:34:51 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 15 Dec 2006 15:34:51 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-15 Message-ID: <20061215203451.A531515212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) tor FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) tor: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.1.1.25-1.fc5 > 0:0.1.1.24-1.fc6) FE6 > FE7 (0:0.1.1.25-1.fc6 > 0:0.1.1.24-1.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From rich at phekda.gotadsl.co.uk Fri Dec 15 21:37:15 2006 From: rich at phekda.gotadsl.co.uk (Richard Dawe) Date: Fri, 15 Dec 2006 21:37:15 +0000 Subject: Heads-up: python 2.5 on its way In-Reply-To: <4582BD25.3060807@redhat.com> References: <1165439871.8344.9.camel@aglarond.local> <4582BD25.3060807@redhat.com> Message-ID: <4583158B.3030409@phekda.gotadsl.co.uk> Hello. Phil Knirsch wrote: > Jeremy Katz wrote: >> This is just a heads up that I'm in the progress of getting python 2.5 >> staged for the development tree. At this point, I'm doing the build on >> the side and trying to get a good chunk of the Core packages rebuilt >> against it before pushing to the development tree itself. I'm still >> hoping to be able to do the actual move over either later today or >> tomorrow (depending on how fast the Core build system decides to be) >> > > Just ran a few tests with it today and the version in the tree and i got > a nice segfault when using the bsddb module: > > import bsddb > db = bsddb.hashopen("/var/lib/rpm/Basenames", "r") > > died on me. Simply installing the latest db4 and db4-devel and then > rebuilding python fixed it for me. I filed a bug for this last weekend: Bug 219206: Crash in python 2.5 bsddb module I added your notes as a comment. Thanks, bye, Rich =] -- Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ] "You just amass stuff while you are alive. It's like stuff washed up on a beach somewhere, and that somewhere is you." -- Damien Hirst From Matt_Domsch at dell.com Sat Dec 16 00:21:22 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 15 Dec 2006 18:21:22 -0600 Subject: kernel-devel future? Message-ID: <20061216002122.GA14797@lists.us.dell.com> Per today's automatic deps report, kernel-devel is not provided for ppc. Is this a one-time bug, or a permanent change? kernel-devel exists in the repo for i386 and x86_64. If it's gone for good, what's replacing it (if anything)? 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 davej at redhat.com Sat Dec 16 00:33:55 2006 From: davej at redhat.com (Dave Jones) Date: Fri, 15 Dec 2006 19:33:55 -0500 Subject: kernel-devel future? In-Reply-To: <20061216002122.GA14797@lists.us.dell.com> References: <20061216002122.GA14797@lists.us.dell.com> Message-ID: <20061216003355.GA23970@redhat.com> On Fri, Dec 15, 2006 at 06:21:22PM -0600, Matt Domsch wrote: > Per today's automatic deps report, kernel-devel is not provided for > ppc. Is this a one-time bug, or a permanent change? kernel-devel > exists in the repo for i386 and x86_64. > > If it's gone for good, what's replacing it (if anything)? ppc temporarily disabled due to excessive build failures. Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Sat Dec 16 00:55:10 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 15 Dec 2006 18:55:10 -0600 Subject: kernel-devel future? In-Reply-To: <20061216003355.GA23970@redhat.com> References: <20061216002122.GA14797@lists.us.dell.com> <20061216003355.GA23970@redhat.com> Message-ID: <1166230511.4812.14.camel@vader.jdub.homelinux.org> On Fri, 2006-12-15 at 19:33 -0500, Dave Jones wrote: > On Fri, Dec 15, 2006 at 06:21:22PM -0600, Matt Domsch wrote: > > Per today's automatic deps report, kernel-devel is not provided for > > ppc. Is this a one-time bug, or a permanent change? kernel-devel > > exists in the repo for i386 and x86_64. > > > > If it's gone for good, what's replacing it (if anything)? > > ppc temporarily disabled due to excessive build failures. Where are the build logs? We should post those to fedora-ppc or here or somewhere. josh From davej at redhat.com Sat Dec 16 02:35:56 2006 From: davej at redhat.com (Dave Jones) Date: Fri, 15 Dec 2006 21:35:56 -0500 Subject: kernel-devel future? In-Reply-To: <1166230511.4812.14.camel@vader.jdub.homelinux.org> References: <20061216002122.GA14797@lists.us.dell.com> <20061216003355.GA23970@redhat.com> <1166230511.4812.14.camel@vader.jdub.homelinux.org> Message-ID: <20061216023555.GA23126@redhat.com> On Fri, Dec 15, 2006 at 06:55:10PM -0600, Josh Boyer wrote: > On Fri, 2006-12-15 at 19:33 -0500, Dave Jones wrote: > > On Fri, Dec 15, 2006 at 06:21:22PM -0600, Matt Domsch wrote: > > > Per today's automatic deps report, kernel-devel is not provided for > > > ppc. Is this a one-time bug, or a permanent change? kernel-devel > > > exists in the repo for i386 and x86_64. > > > > > > If it's gone for good, what's replacing it (if anything)? > > > > ppc temporarily disabled due to excessive build failures. > > Where are the build logs? We should post those to fedora-ppc or here or > somewhere. it's the 64bit division problem that has already been discussed on Linux-kernel. It should sort itself out in a day or so. Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Sat Dec 16 16:59:16 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 16 Dec 2006 10:59:16 -0600 Subject: kernel-devel future? In-Reply-To: <20061216023555.GA23126@redhat.com> References: <20061216002122.GA14797@lists.us.dell.com> <20061216003355.GA23970@redhat.com> <1166230511.4812.14.camel@vader.jdub.homelinux.org> <20061216023555.GA23126@redhat.com> Message-ID: <1166288356.4812.17.camel@vader.jdub.homelinux.org> On Fri, 2006-12-15 at 21:35 -0500, Dave Jones wrote: > On Fri, Dec 15, 2006 at 06:55:10PM -0600, Josh Boyer wrote: > > On Fri, 2006-12-15 at 19:33 -0500, Dave Jones wrote: > > > On Fri, Dec 15, 2006 at 06:21:22PM -0600, Matt Domsch wrote: > > > > Per today's automatic deps report, kernel-devel is not provided for > > > > ppc. Is this a one-time bug, or a permanent change? kernel-devel > > > > exists in the repo for i386 and x86_64. > > > > > > > > If it's gone for good, what's replacing it (if anything)? > > > > > > ppc temporarily disabled due to excessive build failures. > > > > Where are the build logs? We should post those to fedora-ppc or here or > > somewhere. > > it's the 64bit division problem that has already been discussed > on Linux-kernel. It should sort itself out in a day or so. Ok cool. But thinking in the general case, are the build logs for rawhide available anywhere? For generic PPC (or other arch) breakage, it would help the folks that care about those arches to be able to look at the build failures. josh From davej at redhat.com Sat Dec 16 17:06:23 2006 From: davej at redhat.com (Dave Jones) Date: Sat, 16 Dec 2006 12:06:23 -0500 Subject: kernel-devel future? In-Reply-To: <1166288356.4812.17.camel@vader.jdub.homelinux.org> References: <20061216002122.GA14797@lists.us.dell.com> <20061216003355.GA23970@redhat.com> <1166230511.4812.14.camel@vader.jdub.homelinux.org> <20061216023555.GA23126@redhat.com> <1166288356.4812.17.camel@vader.jdub.homelinux.org> Message-ID: <20061216170623.GH23368@redhat.com> On Sat, Dec 16, 2006 at 10:59:16AM -0600, Josh Boyer wrote: > > it's the 64bit division problem that has already been discussed > > on Linux-kernel. It should sort itself out in a day or so. > > Ok cool. But thinking in the general case, are the build logs for > rawhide available anywhere? For generic PPC (or other arch) breakage, > it would help the folks that care about those arches to be able to look > at the build failures. For stuff built in core, currently, no (afaik). With the core+extras amalgamation thats going to happen for FC7, it should just come out in the wash eventually, making it not really worthwhile to spend much effort on making the current build system mirror stuff out imo. Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Sat Dec 16 17:46:20 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 16 Dec 2006 11:46:20 -0600 Subject: kernel-devel future? In-Reply-To: <20061216170623.GH23368@redhat.com> References: <20061216002122.GA14797@lists.us.dell.com> <20061216003355.GA23970@redhat.com> <1166230511.4812.14.camel@vader.jdub.homelinux.org> <20061216023555.GA23126@redhat.com> <1166288356.4812.17.camel@vader.jdub.homelinux.org> <20061216170623.GH23368@redhat.com> Message-ID: <1166291180.4812.21.camel@vader.jdub.homelinux.org> On Sat, 2006-12-16 at 12:06 -0500, Dave Jones wrote: > On Sat, Dec 16, 2006 at 10:59:16AM -0600, Josh Boyer wrote: > > > > it's the 64bit division problem that has already been discussed > > > on Linux-kernel. It should sort itself out in a day or so. > > > > Ok cool. But thinking in the general case, are the build logs for > > rawhide available anywhere? For generic PPC (or other arch) breakage, > > it would help the folks that care about those arches to be able to look > > at the build failures. > > For stuff built in core, currently, no (afaik). > With the core+extras amalgamation thats going to happen for FC7, > it should just come out in the wash eventually, making it not > really worthwhile to spend much effort on making the current > build system mirror stuff out imo. Hm.. I'll begrudgingly agree. Until that happens, I'd like to just remind everyone that if you have a build failure on a non-x86 arch that you'd like some help with, feel free to ask on fedora-devel or here or on an arch specific list. josh From buildsys at fedoraproject.org Sun Dec 17 15:33:44 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 17 Dec 2006 10:33:44 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-17 Message-ID: <20061217153344.DF95115212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) qspencer AT ieee.org: lilypond-doc FE5 > FE6 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc6) FE5 > FE7 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc7) redhat-bugzilla AT linuxnetz.de: duplicity FE3 > FE4 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc4) FE3 > FE5 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc5) FE3 > FE6 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc6) FE3 > FE7 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc6) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) duplicity: redhat-bugzilla AT linuxnetz.de FE3 > FE4 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc4) FE3 > FE5 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc5) FE3 > FE6 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc6) FE3 > FE7 (0:0.4.2-4.fc3 > 0:0.4.2-3.fc6) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lilypond-doc: qspencer AT ieee.org FE5 > FE6 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc6) FE5 > FE7 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.36-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.36-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From peter at thecodergeek.com Sun Dec 17 23:02:14 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 17 Dec 2006 15:02:14 -0800 Subject: Offline: 2006-12-23 Through 2007-01-01 Message-ID: <1166396534.8636.59.camel@localhost> Hello, all. As I have noted on the Vacation wiki page [1] for the past couple of months, I will be away from December 23 (next Saturday) through the new year (on out-of-state vacation with family). During this time, I ask that other packagers and contributors maintain my packages [2] for me, watching for updates, bug reports (especially security issues that may potentially arise), needed rebuilds, et al. My current plans for each are as follows: * glabels All branches (FC-5, FC-6, devel) are currently tracking the stable 2.0.x release series. When I return, however, I plan to bump the Devel branch to track the newer 2.1.x series. (This is tentative and pending further discussion on the upstream development list.) * gaim-libnotify This is for Gaim 2.x (currently beta in Core of FC6+), and thus only has branches for FC-6 and devel. Both are tracking the upstream releases. Version 0.12 is currently the latest, but 0.13 is a work in progress with some bug fixes and re-additions of some features for the gaim 2.0-beta4 API (such as new-conversation-only notifications). * gnome-applet-music Upstream on this has been quiet, but active nonetheless. A bug-fix release (proper rhythmbox song change notification, updated translations, etc.) is currently in the upstream development tree. * gnome-theme-clearlooks-big pack and lucidlife Both of these packages have active upstreams, but are in a state of "It works nicely; so not much actual development is needed." I have the source tarball for gnome-theme-clearlooks-bigpack mirrored on my webspace to keep it versioned. Should a new version be out while I am away, I ask that someone else with some webspace rename it similarly and host it, since upstream has said that they do not want to name their tarballs with versions (which makes our job as packagers just a tad more difficult, unfortunately...) * labyrinth Don Scorgie (the main upstream developer of this) recently announced [3] that he is finishing up his Ph.D and going on a job hunt; and therefore won't have nearly as much time for Labyrinth hacking; but it is still in active (though quiet) development and there are several things he wants to review/commit when the opportunity arises. * obconf, obmenu, and openbox I no longer use these three (having recently placed them in the Potential Orphans category [4]), but I still try to keep them updated and watch for bug reports, et al. If anyone wants to take these as primary maintainers, especially active users of these, please feel free to do so. (Edit owners.list as appropriate; and re-assign any open bug reports to yourself.) * ots The current release (0.4.2) is somewhat older (from November of 2003); and a new version has been in development for quite some time. While no timeline of it is tentatively scheduled, it is used by the AbiWord summarizer plugin; and the previous maintainer of this in Extras (Michael Knox) had other obligations [5] to attend to. A demo of the next version is available (as Flash, unfortunately...) on their webpage [6]. * scribes and scribes-templates This is quiet for now, but development will pickup again soon. Many of us are experiencing seemingly random errors whereby the .scribesclient script hangs and causes a processor-intensive zombie task; and work is underway to triage this (as it is a very big pain in butt). However, it is very difficult to reproduce; and thus difficult to debug as well (tracking in upstream SourceForge bug #1617598). * viaideinfo This is another package that is in a mature-but-updated state. Its developer (Daniel Drake of kernel fame) adds new hardware IDs and whatnot from time to time, and therefore releases new versions. Thanks! [1] http://fedoraproject.org/wiki/Vacation [2] http://fedoraproject.org/wiki/PeterGordon#StuffIMaintain [3] http://mail-archive.com/labyrinth-devel at googlegroups.com/msg00067.html [4] http://fedoraproject.org/wiki/Extras/OrphanedPackages#incoming [5] https://redhat.com/archives/fedora-extras-list/2006-September/msg00435.html [6] http://libots.sourceforge.net/demo1.html -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Tue Dec 19 10:56:32 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 19 Dec 2006 05:56:32 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-19 Message-ID: <20061219105632.D55A915212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): am-utils FC6-updates > FC7 (5:6.1.5-4.1.fc6 > 5:6.1.5-4) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) qspencer AT ieee.org: lilypond-doc FE5 > FE6 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc6) FE5 > FE7 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc7) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) ville.skytta AT iki.fi: em8300-kmod FE5 > FE7 (0:0.16.0-1.2.6.18_1.2257.fc5 > 0:0.16.0-0.4.rc2.2.6.18_1.2849.fc6) FE6 > FE7 (0:0.16.0-5.2.6.18_1.2868.fc6 > 0:0.16.0-0.4.rc2.2.6.18_1.2849.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- am-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (5:6.1.5-4.1.fc6 > 5:6.1.5-4) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) em8300-kmod: ville.skytta AT iki.fi FE5 > FE7 (0:0.16.0-1.2.6.18_1.2257.fc5 > 0:0.16.0-0.4.rc2.2.6.18_1.2849.fc6) FE6 > FE7 (0:0.16.0-5.2.6.18_1.2868.fc6 > 0:0.16.0-0.4.rc2.2.6.18_1.2849.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lilypond-doc: qspencer AT ieee.org FE5 > FE6 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc6) FE5 > FE7 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From dwmw2 at infradead.org Tue Dec 19 10:57:47 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 19 Dec 2006 10:57:47 +0000 Subject: kernel-devel future? In-Reply-To: <1166291180.4812.21.camel@vader.jdub.homelinux.org> References: <20061216002122.GA14797@lists.us.dell.com> <20061216003355.GA23970@redhat.com> <1166230511.4812.14.camel@vader.jdub.homelinux.org> <20061216023555.GA23126@redhat.com> <1166288356.4812.17.camel@vader.jdub.homelinux.org> <20061216170623.GH23368@redhat.com> <1166291180.4812.21.camel@vader.jdub.homelinux.org> Message-ID: <1166525867.25827.86.camel@pmac.infradead.org> On Sat, 2006-12-16 at 11:46 -0600, Josh Boyer wrote: > Hm.. I'll begrudgingly agree. Until that happens, I'd like to just > remind everyone that if you have a build failure on a non-x86 arch that > you'd like some help with, feel free to ask on fedora-devel or here or > on an arch specific list. Or, for that matter, failures on x86. -- dwmw2 From rdieter at math.unl.edu Tue Dec 19 18:19:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 12:19:52 -0600 Subject: icon cache scriplet guideline update Message-ID: <45882D48.7080509@math.unl.edu> FYI, The packaging committee passed a new guidelines wrt icon cache scriptlets: http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache (pending FESCo/Core-cabal ratification). In short, replace existing scriptlets touch --no-create %{_datadir}/icons/hicolor || : %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : with %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : -- Rex From ndbecker2 at gmail.com Tue Dec 19 18:45:35 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 19 Dec 2006 13:45:35 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <45882D48.7080509@math.unl.edu> References: <45882D48.7080509@math.unl.edu> Message-ID: <200612191345.36090.ndbecker2@gmail.com> On Tuesday 19 December 2006 1:19 pm, Rex Dieter wrote: > FYI, > The packaging committee passed a new guidelines wrt icon cache scriptlets: > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > (pending FESCo/Core-cabal ratification). > > In short, replace existing scriptlets > touch --no-create %{_datadir}/icons/hicolor || : > %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > with > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > Did you mean replace the 2 lines (1 starting with 'touch' and 1 starting with %{_bindir}' with the 1 line shown (starting with %{_bindir})? Or just replace the gtk-update-icon... line with the xdg-icon-resource... line? From rdieter at math.unl.edu Tue Dec 19 18:57:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 12:57:40 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <200612191345.36090.ndbecker2@gmail.com> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> Message-ID: <45883624.5080801@math.unl.edu> Neal Becker wrote: > On Tuesday 19 December 2006 1:19 pm, Rex Dieter wrote: >> FYI, >> The packaging committee passed a new guidelines wrt icon cache scriptlets: >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >> (pending FESCo/Core-cabal ratification). >> >> In short, replace existing scriptlets >> touch --no-create %{_datadir}/icons/hicolor || : >> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : >> with >> %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > Did you mean replace the 2 lines (1 starting with 'touch' and 1 starting > with %{_bindir}' with the 1 line shown (starting with %{_bindir})? Or just > replace the gtk-update-icon... line with the xdg-icon-resource... line? Yes, intentional. The 'touch' is not needed... that's what 'forceupdate' already does. -- Rex From notting at redhat.com Tue Dec 19 19:02:34 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 14:02:34 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <45883624.5080801@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> <45883624.5080801@math.unl.edu> Message-ID: <20061219190234.GA28007@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Yes, intentional. The 'touch' is not needed... that's what > 'forceupdate' already does. How is replacing a call to a binary with a 837 line shell script (that will then call the binary) an improvement? What actual issues does it solve? Bill From tibbs at math.uh.edu Tue Dec 19 19:04:03 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2006 13:04:03 -0600 Subject: Packaging committee report 2006-12-19 Message-ID: Logs of this meeting are available at http://fedoraproject.org/wiki/Packaging/IRCLog20061219 Note that any linked drafts may not yet be updated with all of the changes approved in the meeting. A good meeting this week; we had 100% attendance and dealt with many items. The draft concerning the proper use of Provides: and Obsoletes: when packages are named or replaced by packages of equivalent functionality at http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes was considered first. It was noted that the epoch should be added in a few places. There was discussion about how long to keep Provides: for the old package name, and the decision was made that this should be done for two releases. The draft was approved with those changes. The draft about scriptlets for updating the icon cache at http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache was considered next. There was discussion about applicability to core packages in FC6 and older (which isn't possible because xdg-utils is in Extras). The draft was approved with minor changes (which seem to have already been made). Next there was a quick vote on linking to http://fedoraproject.org/wiki/Packaging/Debuginfo in the guidelines and adding a requirement that commentary is required in the spec if debuginfo generation is disabled. The proposal was accepted. We discussed package naming (and the jpackage naming in particular) as it relates to the Core/Extras merge and the upcoming mass review. Currently there are many packages which will not pass review because the naming guidelines are violated, including a large number of Java-related packages in core. We discussed making a sweep through the universe of packages to identify those with naming issues. This isn't strictly packaging committee territory, but nonetheless it needs to be done, and volunteers are appreciated. There was also some discussion about lower case package names; the general sentiment was that we shouldn't try to mandate anything like that. There are many interesting issues there and the discussion will probably return at some point. We discussed how to properly indicate packages needing review; there's a packagedb field, but in lieu of the packagedb we talked about putting a file in CVS. This is more FESCo territory and some us would like to bring it up there. We did a little work on the License: tag proposal; the general sentiment is that we should keep the License: tag as simple as possible. (There was a message to the packaging list proposing a structured field with various pieces of information, but this wasn't accepted.) An early draft proposal is at http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag - J< From mclasen at redhat.com Tue Dec 19 19:23:11 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 19 Dec 2006 14:23:11 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <45882D48.7080509@math.unl.edu> References: <45882D48.7080509@math.unl.edu> Message-ID: <1166556192.15528.6.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-19 at 12:19 -0600, Rex Dieter wrote: > FYI, > The packaging committee passed a new guidelines wrt icon cache scriptlets: > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > (pending FESCo/Core-cabal ratification). > > In short, replace existing scriptlets > touch --no-create %{_datadir}/icons/hicolor || : > %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > with > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > > -- Rex > It is interesting to note that this proposal doesn't actually address the one problem that there is with the current snipplets, namely that we keep regenerating the cache over and over. From chitlesh at fedoraproject.org Tue Dec 19 19:26:16 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Dec 2006 20:26:16 +0100 Subject: icon cache scriplet guideline update In-Reply-To: <45882D48.7080509@math.unl.edu> References: <45882D48.7080509@math.unl.edu> Message-ID: <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> On 12/19/06, Rex Dieter wrote: > In short, replace existing scriptlets > touch --no-create %{_datadir}/icons/hicolor || : > %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > with > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : I'm firing a RFE since we are talking about scriptlets! When installing more than 2 rpms with yum with scriptlets, installation is quite slow since for each rpm it has to %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : why not telling yum to do it once only ? Perhaps the same strategy might be used with ldconfig ? Chitlesh -- http://clunixchit.blogspot.com From tibbs at math.uh.edu Tue Dec 19 19:27:07 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2006 13:27:07 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <1166556192.15528.6.camel@golem.boston.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> It is interesting to note that this proposal doesn't actually MC> address the one problem that there is with the current snipplets, MC> namely that we keep regenerating the cache over and over. Well, the xdg script could do that. We certainly shouldn't push such logic into the scriptlets of every package. - J< From tibbs at math.uh.edu Tue Dec 19 19:27:50 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2006 13:27:50 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> Message-ID: >>>>> "CG" == Chitlesh GOORAH writes: CG> why not telling yum to do it once only ? You cannot assume that yum is even involved. - J< From notting at redhat.com Tue Dec 19 19:29:20 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 14:29:20 -0500 Subject: icon cache scriplet guideline update In-Reply-To: References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> Message-ID: <20061219192919.GA28461@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > MC> It is interesting to note that this proposal doesn't actually > MC> address the one problem that there is with the current snipplets, > MC> namely that we keep regenerating the cache over and over. > > Well, the xdg script could do that. We certainly shouldn't push such > logic into the scriptlets of every package. You seriously want a script to be handling per-transaction state of the updater that's running it? That sounds like a very wrong solution. Bill From dennis at ausil.us Tue Dec 19 19:30:53 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 19 Dec 2006 13:30:53 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> Message-ID: <200612191330.53550.dennis@ausil.us> On Tuesday 19 December 2006 13:26, Chitlesh GOORAH wrote: > On 12/19/06, Rex Dieter wrote: > > In short, replace existing scriptlets > > touch --no-create %{_datadir}/icons/hicolor || : > > %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > > with > > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > > I'm firing a RFE since we are talking about scriptlets! > When installing more than 2 rpms with yum with scriptlets, > installation is quite slow since for each rpm it has to > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > why not telling yum to do it once only ? > > Perhaps the same strategy might be used with ldconfig ? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 bug has been filed for a long time now. We need a propper answer and it is not yet found. it would be much simpler if gnome followed the freedesktop.org spec and all you needed was to update the directory time stamp. however as gnome goes further we now have this situation. if we have to run it it in the rpm transaction. it should be run only once per rpm transaction not once per rpm. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From tibbs at math.uh.edu Tue Dec 19 19:35:54 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2006 13:35:54 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <20061219192919.GA28461@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <20061219192919.GA28461@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> You seriously want a script to be handling per-transaction state BN> of the updater that's running it? That sounds like a very wrong BN> solution. Well, If you can point out where I said that, I'll surely correct myself because that certainly wasn't what I intended. - J< From jkeating at redhat.com Tue Dec 19 19:47:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Dec 2006 14:47:18 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <200612191330.53550.dennis@ausil.us> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> Message-ID: <200612191447.18707.jkeating@redhat.com> On Tuesday 19 December 2006 14:30, Dennis Gilmore wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 > bug has been filed for a long time now. ?We need a propper answer ?and it > is not yet found. it would be much simpler if gnome followed the > freedesktop.org spec ?and all you needed was to update the directory time > stamp. ?however as gnome goes further we now have this situation. The suggestion of using a --delay and gathering many updates into said --delay seems very sane. But as stated, no time to work on said feature. Patches welcome :/ -- 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 rc040203 at freenet.de Tue Dec 19 19:46:30 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 19 Dec 2006 20:46:30 +0100 Subject: icon cache scriplet guideline update In-Reply-To: <20061219190234.GA28007@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> <45883624.5080801@math.unl.edu> <20061219190234.GA28007@nostromo.devel.redhat.com> Message-ID: <1166557590.8099.17.camel@mccallum> On Tue, 2006-12-19 at 14:02 -0500, Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: > > Yes, intentional. The 'touch' is not needed... that's what > > 'forceupdate' already does. > > How is replacing a call to a binary with a 837 line shell script > (that will then call the binary) an improvement? It's called abstraction and encapsulation. > What actual issues does it solve? You can exchange anything underneath/inside without having to bother users nor to touch a spec, again (provided a tool's CLI is stable). Ralf From rdieter at math.unl.edu Tue Dec 19 19:46:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 13:46:36 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <1166556192.15528.6.camel@golem.boston.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> Message-ID: <4588419C.3070008@math.unl.edu> Matthias Clasen wrote: > On Tue, 2006-12-19 at 12:19 -0600, Rex Dieter wrote: >> FYI, >> The packaging committee passed a new guidelines wrt icon cache scriptlets: >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache >> (pending FESCo/Core-cabal ratification). >> >> In short, replace existing scriptlets >> touch --no-create %{_datadir}/icons/hicolor || : >> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : >> with >> %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > It is interesting to note that this proposal doesn't actually address > the one problem that there is with the current snipplets, namely that > we keep regenerating the cache over and over. True, other problems like needless cache regeneration is indeed (still) a problem, but, afaik, no solution exists for that, yet. Main problem *this* proposal is (trying to) address: The freedesktop.org icon spec only mandates 'touching' top-level icon dir, but current packaging guidelines include toolkit-specific (gtk2) cache implementation details. Removing those details without addressing related gtk2 RFE yields stale gtk2 icon cache. I proposed keeping the exising gtk-update-icon-cache as an option for icon scriptlets, and this was universally shot-down by the PC. They insisted on simplicity. So, this led to option 2: Propose using only xdg-utils. This simplifies the guidelines, uses desktop-agnostic tools, and (virtually) fixes the gtk2 issue, since it guarantees that the gtk2 icon cache is (should be!) kept current. -- Rex From chris.stone at gmail.com Tue Dec 19 19:52:44 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 19 Dec 2006 11:52:44 -0800 Subject: Packaging committee report 2006-12-19 In-Reply-To: References: Message-ID: On 19 Dec 2006 13:04:03 -0600, Jason L Tibbitts III wrote: > few places. There was discussion about how long to keep Provides: for > the old package name, and the decision was made that this should be > done for two releases. The draft was approved with those changes. Shouldn't it just be 1 release? We do not encourage upgrading from FC3 to FC5 for example... From mclasen at redhat.com Tue Dec 19 20:01:22 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 19 Dec 2006 15:01:22 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <200612191330.53550.dennis@ausil.us> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> Message-ID: <1166558482.7685.2.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-19 at 13:30 -0600, Dennis Gilmore wrote: > On Tuesday 19 December 2006 13:26, Chitlesh GOORAH wrote: > > On 12/19/06, Rex Dieter wrote: > > > In short, replace existing scriptlets > > > touch --no-create %{_datadir}/icons/hicolor || : > > > %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > > > with > > > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > > > > I'm firing a RFE since we are talking about scriptlets! > > When installing more than 2 rpms with yum with scriptlets, > > installation is quite slow since for each rpm it has to > > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > > why not telling yum to do it once only ? > > > > Perhaps the same strategy might be used with ldconfig ? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 > bug has been filed for a long time now. We need a propper answer and it is > not yet found. it would be much simpler if gnome followed the freedesktop.org > spec and all you needed was to update the directory time stamp. however as > gnome goes further we now have this situation. Not sure what you are talking about here. GNOME is following the freedesktop.org spec closely here. If you only touch the directory, things will work in so far that gtk will ignore the stale cache and use icons directly from the filesystem. Somebody still has to regenerate the icon cache though... > > if we have to run it it in the rpm transaction. it should be run only once > per rpm transaction not once per rpm. > That's one thing to consider for the "revive rpm development" effort. Matthias From sundaram at fedoraproject.org Tue Dec 19 19:56:42 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 20 Dec 2006 01:26:42 +0530 Subject: Packaging committee report 2006-12-19 In-Reply-To: References: Message-ID: <458843FA.5080401@fedoraproject.org> Christopher Stone wrote: > On 19 Dec 2006 13:04:03 -0600, Jason L Tibbitts III > wrote: >> few places. There was discussion about how long to keep Provides: for >> the old package name, and the decision was made that this should be >> done for two releases. The draft was approved with those changes. > > Shouldn't it just be 1 release? We do not encourage upgrading from > FC3 to FC5 for example... Why dont we? The whole point of extending the updates for every release as discussed in the Fedora Summit is for users to skip a release. http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess Rahul From jkeating at redhat.com Tue Dec 19 20:00:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 19 Dec 2006 15:00:34 -0500 Subject: Packaging committee report 2006-12-19 In-Reply-To: References: Message-ID: <200612191500.34451.jkeating@redhat.com> On Tuesday 19 December 2006 14:52, Christopher Stone wrote: > Shouldn't it just be 1 release? ?We do not encourage upgrading from > FC3 to FC5 for example... With changes to the lifespan, we're specifically setting this up as a possibility. Whether or not this works for the first couple releases remains to be seen. -- 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 jgarzik at redhat.com Tue Dec 19 19:58:07 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Tue, 19 Dec 2006 14:58:07 -0500 Subject: FC7 plan comments Message-ID: <20061219195807.GD2417@devserv.devel.redhat.com> Comments on the FC7 draft plan: 8. Rock Solid Wireless I would ping John Linville too. He already makes kernel RPMs with enhanced wireless based on his upstream maintainership work. 10. Boot and shutdown speedup Jens Axboe did some kernel work for this, fcache: http://lkml.org/lkml/2006/5/15/46 A lot of the boot slowness here comes from (a) udev [10+ seconds in startup], or (b) non-parallel initscripts. 12. rpm/yum enhancements Lack of decent pipelining seems to continue to hurt here. IMO yum should communicate with a download thread in the background. This thread would be responsibile for keeping HTTP pipelines full where possible, even to the extent of connecting to another mirror _while_ a connection to an existing mirror is plodding along. 18. Move to using libata for PATA support Please keep me and Alan Cox in the loop on this. NOTE: You might need some intelligence in mkinitrd to avoid adding spurious drivers such as pata_generic or ata_generic to the initrd, after matching more specific pata_* drivers. 19. Move to syslog-ng DANGER WILL ROBINSON, possible patent problems: http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html 23. Fix wakeups across the distribution An admirable task :) Is anyone collecting a list of stupid apps in a wiki? My additions: J1) (possibly not FC7 material) installer support for a few popular FUSE filesystems J2) Drop support for any hardware that does not support -march=i686 J3) When is GNOME ever going to save/restore the sessions of apps other than my terminals? Firefox, Thunderbird, and xchat all claim X session support, but GNOME never saves the window positions etc. From mclasen at redhat.com Tue Dec 19 20:06:03 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 19 Dec 2006 15:06:03 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <4588419C.3070008@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> Message-ID: <1166558763.7685.7.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-19 at 13:46 -0600, Rex Dieter wrote: > Matthias Clasen wrote: > > On Tue, 2006-12-19 at 12:19 -0600, Rex Dieter wrote: > >> FYI, > >> The packaging committee passed a new guidelines wrt icon cache scriptlets: > >> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > >> (pending FESCo/Core-cabal ratification). > >> > >> In short, replace existing scriptlets > >> touch --no-create %{_datadir}/icons/hicolor || : > >> %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : > >> with > >> %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > > > It is interesting to note that this proposal doesn't actually address > > the one problem that there is with the current snipplets, namely that > > we keep regenerating the cache over and over. > > True, other problems like needless cache regeneration is indeed (still) > a problem, but, afaik, no solution exists for that, yet. I have proposed a solution in the bug. But instead of working on that, people preferred to opt for the magical xdg bullet... > Main problem *this* proposal is (trying to) address: > The freedesktop.org icon spec only mandates 'touching' top-level icon > dir, but current packaging guidelines include toolkit-specific (gtk2) > cache implementation details. Removing those details without addressing > related gtk2 RFE yields stale gtk2 icon cache. Wrong. the icon cache specification is part of the icon theme spec. Nothing gtk-specific in there. Would you be happy if I rename gtk-update-icon-cache to update-icon-cache ? Matthias From chris.stone at gmail.com Tue Dec 19 20:09:14 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 19 Dec 2006 12:09:14 -0800 Subject: Packaging committee report 2006-12-19 In-Reply-To: <200612191500.34451.jkeating@redhat.com> References: <200612191500.34451.jkeating@redhat.com> Message-ID: On 12/19/06, Jesse Keating wrote: > On Tuesday 19 December 2006 14:52, Christopher Stone wrote: > > Shouldn't it just be 1 release? We do not encourage upgrading from > > FC3 to FC5 for example... > > With changes to the lifespan, we're specifically setting this up as a > possibility. Whether or not this works for the first couple releases remains > to be seen. Oh it may work, but the probability of it working 100% correctly diminishes pretty dramatically I would assume. Personally I think it is a bad idea and we should always encourage people to upgrade one distro release at a time. In my real-world experience, I have a package, namely pygame, that has a bunch of obsolete/provides from livna and other sources and I *really* want to trim these down as much as possible for FC-7 because it just added a few more with all the -devel sub package shenanigans. From notting at redhat.com Tue Dec 19 20:08:56 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 15:08:56 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <1166557590.8099.17.camel@mccallum> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> <45883624.5080801@math.unl.edu> <20061219190234.GA28007@nostromo.devel.redhat.com> <1166557590.8099.17.camel@mccallum> Message-ID: <20061219200856.GA28922@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > > How is replacing a call to a binary with a 837 line shell script > > (that will then call the binary) an improvement? > > It's called abstraction and encapsulation. It's also called 'slow and useless like libtool'. > > What actual issues does it solve? > > You can exchange anything underneath/inside without having to bother > users nor to touch a spec, again (provided a tool's CLI is stable). It doesn't solve *actual issues* now. I'd rather save any spec changes for a time when we have actual solutions to problems. Bill From notting at redhat.com Tue Dec 19 20:09:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 15:09:16 -0500 Subject: icon cache scriplet guideline update In-Reply-To: References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <20061219192919.GA28461@nostromo.devel.redhat.com> Message-ID: <20061219200916.GB28922@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > >>>>> "BN" == Bill Nottingham writes: > > BN> You seriously want a script to be handling per-transaction state > BN> of the updater that's running it? That sounds like a very wrong > BN> solution. > > Well, If you can point out where I said that, I'll surely correct > myself because that certainly wasn't what I intended. > > - J< > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From notting at redhat.com Tue Dec 19 20:09:53 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 15:09:53 -0500 Subject: icon cache scriplet guideline update In-Reply-To: References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <20061219192919.GA28461@nostromo.devel.redhat.com> Message-ID: <20061219200953.GC28922@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > BN> You seriously want a script to be handling per-transaction state > BN> of the updater that's running it? That sounds like a very wrong > BN> solution. > > Well, If you can point out where I said that, I'll surely correct > myself because that certainly wasn't what I intended. Matthias mentioned how this doesn't solve the 'regenerates the cache many many times' issue, and you stated that 'the xdg script could solve that.' Bill From notting at redhat.com Tue Dec 19 20:11:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 15:11:37 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <4588419C.3070008@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> Message-ID: <20061219201137.GD28922@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Main problem *this* proposal is (trying to) address: > The freedesktop.org icon spec only mandates 'touching' top-level icon > dir, but current packaging guidelines include toolkit-specific (gtk2) > cache implementation details. Removing those details without addressing > related gtk2 RFE yields stale gtk2 icon cache. > > I proposed keeping the exising gtk-update-icon-cache as an option for > icon scriptlets, and this was universally shot-down by the PC. They > insisted on simplicity. > > So, this led to option 2: > Propose using only xdg-utils. This simplifies the guidelines, uses > desktop-agnostic tools, and (virtually) fixes the gtk2 issue, since it > guarantees that the gtk2 icon cache is (should be!) kept current. But this doesn't 'solve' anything, or 'simiplify' anything - it just moves a touch into the shell script, and renames the command, and makes things slower. So, essentially, it boils down to an objection to the tool being named 'gtk2-...'? Bill From rdieter at math.unl.edu Tue Dec 19 20:16:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 14:16:20 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <1166558763.7685.7.camel@golem.boston.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <1166558763.7685.7.camel@golem.boston.devel.redhat.com> Message-ID: <45884894.7060508@math.unl.edu> Matthias Clasen wrote: > On Tue, 2006-12-19 at 13:46 -0600, Rex Dieter wrote: >> Main problem *this* proposal is (trying to) address: >> The freedesktop.org icon spec only mandates 'touching' top-level icon >> dir, but current packaging guidelines include toolkit-specific (gtk2) >> cache implementation details. Removing those details without addressing >> related gtk2 RFE yields stale gtk2 icon cache. > > Wrong. the icon cache specification is part of the icon theme spec. I remembering you mention that it was or should be there somewhere, but I've never been able to find it. Could you give me a hint/pointer? -- Rex From mclasen at redhat.com Tue Dec 19 20:27:46 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 19 Dec 2006 15:27:46 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <45884894.7060508@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <1166558763.7685.7.camel@golem.boston.devel.redhat.com> <45884894.7060508@math.unl.edu> Message-ID: <1166560066.7685.10.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-19 at 14:16 -0600, Rex Dieter wrote: > Matthias Clasen wrote: > > On Tue, 2006-12-19 at 13:46 -0600, Rex Dieter wrote: > > >> Main problem *this* proposal is (trying to) address: > >> The freedesktop.org icon spec only mandates 'touching' top-level icon > >> dir, but current packaging guidelines include toolkit-specific (gtk2) > >> cache implementation details. Removing those details without addressing > >> related gtk2 RFE yields stale gtk2 icon cache. > > > > Wrong. the icon cache specification is part of the icon theme spec. > > I remembering you mention that it was or should be there somewhere, but > I've never been able to find it. Could you give me a hint/pointer? > Argh, sorry. I stand corrected. It never made it back in the spec. What I had in mind was the shared-mime cache, which did make it back in the spec. So there you go, it is gtk-specific at this point. From arjan at fenrus.demon.nl Tue Dec 19 20:32:22 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 19 Dec 2006 21:32:22 +0100 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: <1166560342.3365.1279.camel@laptopd505.fenrus.org> > 23. Fix wakeups across the distribution > > An admirable task :) Is anyone collecting a list of stupid apps in a > wiki? does a bugzilla count? https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=204948 From rdieter at math.unl.edu Tue Dec 19 20:39:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 14:39:43 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <1166560066.7685.10.camel@golem.boston.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <1166558763.7685.7.camel@golem.boston.devel.redhat.com> <45884894.7060508@math.unl.edu> <1166560066.7685.10.camel@golem.boston.devel.redhat.com> Message-ID: <45884E0F.5010509@math.unl.edu> Matthias Clasen wrote: > On Tue, 2006-12-19 at 14:16 -0600, Rex Dieter wrote: >> Matthias Clasen wrote: >>> On Tue, 2006-12-19 at 13:46 -0600, Rex Dieter wrote: >>>> Main problem *this* proposal is (trying to) address: >>>> The freedesktop.org icon spec only mandates 'touching' top-level icon >>>> dir, but current packaging guidelines include toolkit-specific (gtk2) >>>> cache implementation details. Removing those details without addressing >>>> related gtk2 RFE yields stale gtk2 icon cache. >>> Wrong. the icon cache specification is part of the icon theme spec. >> I remembering you mention that it was or should be there somewhere, but >> I've never been able to find it. Could you give me a hint/pointer? ... > So there you go, it is gtk-specific at this point. Let's take this a step further, how keen would you be for the Packaging Guidelines to mandate including *more*, not less, desktop-specific freedesktop.org/XDG implementation details(1) into *all* packages (especially if it were for performance optimization only, not just for proper function)? What if such nonsense could simply be avoided (or better, abstracted)? (1) One kde-specific example (off the top of my head): * MUST: Packages installing .desktop files that register handling MimeTypes, MUST include scriptlet: %post %{_bindir}/kbuildsycoca --global -- Rex From chris.stone at gmail.com Tue Dec 19 20:41:18 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 19 Dec 2006 12:41:18 -0800 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: On 12/19/06, Jeff Garzik wrote: > > Comments on the FC7 draft plan: > > 8. Rock Solid Wireless > > I would ping John Linville too. He already makes kernel RPMs with > enhanced wireless based on his upstream maintainership work. Indeed. My wireless card actually crashes the kernel. I've been meaning to test John's kernel here: http://people.redhat.com/linville/kernels/fc6/ which supposedly fixes this. From rdieter at math.unl.edu Tue Dec 19 20:41:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 14:41:28 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <20061219201137.GD28922@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <20061219201137.GD28922@nostromo.devel.redhat.com> Message-ID: <45884E78.5060807@math.unl.edu> Bill Nottingham wrote: > But this doesn't 'solve' anything, or 'simiplify' anything - it just > moves a touch into the shell script, and renames the command, and makes > things slower. I'd bet the performance difference is not even measurable, so I don't think it's worth arguing that. > So, essentially, it boils down to an objection to the tool being named > 'gtk2-...'? Or, it seems to be, a reluctance to use or bias against http://portland.freedesktop.org ? -- Rex From rdieter at math.unl.edu Tue Dec 19 20:54:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 14:54:49 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <1166558763.7685.7.camel@golem.boston.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <1166558763.7685.7.camel@golem.boston.devel.redhat.com> Message-ID: <45885199.5010001@math.unl.edu> Matthias Clasen wrote: > On Tue, 2006-12-19 at 13:46 -0600, Rex Dieter wrote: >> True, other problems like needless cache regeneration is indeed (still) >> a problem, but, afaik, no solution exists for that, yet. > I have proposed a solution in the bug. But instead of working on that, > people preferred to opt for the magical xdg bullet... Until a better solution exists (not just a proposal), you betcha. And when you have something ready that works better, I'll be all for that too. -- Rex From notting at redhat.com Tue Dec 19 21:09:22 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 16:09:22 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <45884E78.5060807@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <20061219201137.GD28922@nostromo.devel.redhat.com> <45884E78.5060807@math.unl.edu> Message-ID: <20061219210922.GA29926@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > >But this doesn't 'solve' anything, or 'simiplify' anything - it just > >moves a touch into the shell script, and renames the command, and makes > >things slower. > > I'd bet the performance difference is not even measurable, so I don't > think it's worth arguing that. time to do touch && gtk-update-icon-cache, with cache warm, average, five runs: .166 time to do xdg-icon-resource..., with cache warm, average, five runs: .270 62% slower. It'd be even slower if I had KDE installed, from a quick glance over the script (or if I was running on a slower machine.) After all, it's a shell script that runs sed on the path to walk it itself; that *can't* be efficient. > >So, essentially, it boils down to an objection to the tool being named > >'gtk2-...'? > > Or, it seems to be, a reluctance to use or bias against > http://portland.freedesktop.org I'm against silly standards that make the system less efficient for no actual gain. Bill From rdieter at math.unl.edu Tue Dec 19 21:17:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 15:17:36 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <20061219210922.GA29926@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <20061219201137.GD28922@nostromo.devel.redhat.com> <45884E78.5060807@math.unl.edu> <20061219210922.GA29926@nostromo.devel.redhat.com> Message-ID: <458856F0.4010901@math.unl.edu> Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: >>> But this doesn't 'solve' anything, or 'simiplify' anything - it just >>> moves a touch into the shell script, and renames the command, and makes >>> things slower. >> I'd bet the performance difference is not even measurable, so I don't >> think it's worth arguing that. > > time to do touch && gtk-update-icon-cache, with cache warm, average, > five runs: .166 > > time to do xdg-icon-resource..., with cache warm, average, five runs: > .270 > > 62% slower. My typical results using both (on a not-so-hot laptop): # time /usr/bin/gtk-update-icon-cache --force /usr/share/icons/hicolor Cache file created successfully. real 0m0.637s user 0m0.492s sys 0m0.145s # time /usr/bin/xdg-icon-resource forceupdate --theme hicolor real 0m0.657s user 0m0.491s sys 0m0.166s Not nearly as big a difference as your findings. -- Rex From notting at redhat.com Tue Dec 19 21:30:38 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 19 Dec 2006 16:30:38 -0500 Subject: icon cache scriplet guideline update In-Reply-To: <1166558482.7685.2.camel@golem.boston.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <1166558482.7685.2.camel@golem.boston.devel.redhat.com> Message-ID: <20061219213038.GA30582@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > > if we have to run it it in the rpm transaction. it should be run only once > > per rpm transaction not once per rpm. > > That's one thing to consider for the "revive rpm development" effort. The logical place to do things like this would be in a yum plugin. However, that's going to run into the 'don't want to use yum' problem, so you start having to tie hooks into rpm itself, which leads you to macro-ization of everything, %define __post_transaction_hook, a mechanism to pass arbitrary transaction data from a commandline program to another commandline helper... fun. Bill From rdieter at math.unl.edu Tue Dec 19 21:36:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Dec 2006 15:36:40 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <20061219213038.GA30582@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <1166558482.7685.2.camel@golem.boston.devel.redhat.com> <20061219213038.GA30582@nostromo.devel.redhat.com> Message-ID: <45885B68.8040304@math.unl.edu> Bill Nottingham wrote: > Matthias Clasen (mclasen at redhat.com) said: >>> if we have to run it it in the rpm transaction. it should be run only once >>> per rpm transaction not once per rpm. >> That's one thing to consider for the "revive rpm development" effort. > > The logical place to do things like this would be in a yum plugin. > However, that's going to run into the 'don't want to use yum' problem, rpm plugins? (: > so you start having to tie hooks into rpm itself, which leads you to > macro-ization of everything, %define __post_transaction_hook, a mechanism > to pass arbitrary transaction data from a commandline program to another > commandline helper... fun. fun indeed. From what I've seen so far, something along those lines seems to be the best solution to this general type of problem (similar/same scriptlets being repeatedly run within the same rpm/yum job/transaction). From linville at redhat.com Tue Dec 19 21:38:25 2006 From: linville at redhat.com (John W. Linville) Date: Tue, 19 Dec 2006 16:38:25 -0500 Subject: FC7 plan comments In-Reply-To: References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: <20061219213825.GC11828@redhat.com> On Tue, Dec 19, 2006 at 12:41:18PM -0800, Christopher Stone wrote: > On 12/19/06, Jeff Garzik wrote: > > > >Comments on the FC7 draft plan: > > > >8. Rock Solid Wireless > > > >I would ping John Linville too. He already makes kernel RPMs with > >enhanced wireless based on his upstream maintainership work. > > Indeed. My wireless card actually crashes the kernel. I've been > meaning to test John's kernel here: > http://people.redhat.com/linville/kernels/fc6/ which supposedly fixes > this. Hmmmm...well, I hope so. Let me know if that is less than satisfactory... :-) John -- John W. Linville linville at redhat.com From ville.skytta at iki.fi Tue Dec 19 22:28:28 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 20 Dec 2006 00:28:28 +0200 Subject: icon cache scriplet guideline update In-Reply-To: <200612191447.18707.jkeating@redhat.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> Message-ID: <1166567308.4142.33.camel@viper.local> On Tue, 2006-12-19 at 14:47 -0500, Jesse Keating wrote: > On Tuesday 19 December 2006 14:30, Dennis Gilmore wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 > > bug has been filed for a long time now. We need a propper answer and it > > is not yet found. it would be much simpler if gnome followed the > > freedesktop.org spec and all you needed was to update the directory time > > stamp. however as gnome goes further we now have this situation. > > The suggestion of using a --delay and gathering many updates into said --delay > seems very sane. But as stated, no time to work on said feature. We already have the %posttrans scriptlet in rpm which implements delaying the invocation until the end of the transaction. While it does not reduce the number of invocations as of FC6, having it do that transparently too if sanely doable would be beneficial in many more cases than just the icon cache one at hand. By the way, wrapping the cache update in %post inside "if [ $1 -eq 1 ]" and doing it always in %postun like it is done now would save one update per package on upgrades already now. And that could be applied to some other similar cases too, not just icon cache updates, as long as the package in question is not a "multiversion" one such as kernel. From hp at redhat.com Tue Dec 19 22:35:44 2006 From: hp at redhat.com (Havoc Pennington) Date: Tue, 19 Dec 2006 17:35:44 -0500 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: <45886940.1040908@redhat.com> Jeff Garzik wrote: > J3) When is GNOME ever going to save/restore the sessions of apps other > than my terminals? Firefox, Thunderbird, and xchat all claim X session > support, but GNOME never saves the window positions etc. > For this to work requires a complex interaction among the app, gnome-session, and metacity (or whatever WM). Said complex interaction is poorly specified and poorly tested. To understand the poorly specified spec, each of the app developer, gnome-session developer, and WM developer probably have to spend several days messing around. Even then they probably interpreted things differently. Finally, if the app was not written with the SM spec in mind, e.g. something like Firefox or xchat which are pretty cross-platform, the app may require significant code rearranging to have a chance of working. If any of the app, SM, or WM get anything wrong, it doesn't work. Users never know where to report the bug when it doesn't work, since it could be in any of the three apps. Chances that this will *ever* reliably work for all apps you use: zero. Historical number of apps it works reliably with: very close to zero. Fundamental uselessness of XSMP specification for this reason: 100%. Excruciating details: http://mail.gnome.org/archives/desktop-devel-list/2006-September/msg00088.html Short answer, app window state saving won't work until somebody puts a bullet in trying to use XSMP to do it. Havoc From blizzard at redhat.com Tue Dec 19 22:36:48 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 19 Dec 2006 17:36:48 -0500 Subject: FC7 plan comments In-Reply-To: <45886940.1040908@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <45886940.1040908@redhat.com> Message-ID: <45886980.5060005@redhat.com> Havoc Pennington wrote: > Jeff Garzik wrote: >> J3) When is GNOME ever going to save/restore the sessions of apps other >> than my terminals? Firefox, Thunderbird, and xchat all claim X session >> support, but GNOME never saves the window positions etc. >> > > For this to work requires a complex interaction among the app, > gnome-session, and metacity (or whatever WM). Said complex interaction > is poorly specified and poorly tested. To understand the poorly > specified spec, each of the app developer, gnome-session developer, and > WM developer probably have to spend several days messing around. Even > then they probably interpreted things differently. Finally, if the app > was not written with the SM spec in mind, e.g. something like Firefox or > xchat which are pretty cross-platform, the app may require significant > code rearranging to have a chance of working. > > If any of the app, SM, or WM get anything wrong, it doesn't work. > > Users never know where to report the bug when it doesn't work, since it > could be in any of the three apps. > > Chances that this will *ever* reliably work for all apps you use: zero. > > Historical number of apps it works reliably with: very close to zero. > > Fundamental uselessness of XSMP specification for this reason: 100%. > > Excruciating details: > http://mail.gnome.org/archives/desktop-devel-list/2006-September/msg00088.html > > > Short answer, app window state saving won't work until somebody puts a > bullet in trying to use XSMP to do it. > With FF2 if you just close the window it saves its state now and will happily restore, SM or not. --Chris From jgarzik at redhat.com Tue Dec 19 22:54:39 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Tue, 19 Dec 2006 17:54:39 -0500 Subject: FC7 plan comments In-Reply-To: <45886940.1040908@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <45886940.1040908@redhat.com> Message-ID: <20061219225439.GF2417@devserv.devel.redhat.com> On Tue, Dec 19, 2006 at 05:35:44PM -0500, Havoc Pennington wrote: > Short answer, app window state saving won't work until somebody puts a > bullet in trying to use XSMP to do it. But.. but... each of said apps listed, all Gtk apps mind you, do save and restore their window position flawlessly under KDE. Jeff From jgarzik at redhat.com Tue Dec 19 22:57:31 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Tue, 19 Dec 2006 17:57:31 -0500 Subject: FC7 plan comments In-Reply-To: <20061219225439.GF2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <45886940.1040908@redhat.com> <20061219225439.GF2417@devserv.devel.redhat.com> Message-ID: <20061219225731.GG2417@devserv.devel.redhat.com> On Tue, Dec 19, 2006 at 05:54:39PM -0500, Jeff Garzik wrote: > On Tue, Dec 19, 2006 at 05:35:44PM -0500, Havoc Pennington wrote: > > Short answer, app window state saving won't work until somebody puts a > > bullet in trying to use XSMP to do it. > > But.. but... each of said apps listed, all Gtk apps mind you, do save > and restore their window position flawlessly under KDE. "betweens sessions" (i.e. log in/out), I should have said. Jeff From sandmann at redhat.com Tue Dec 19 23:38:08 2006 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: 19 Dec 2006 18:38:08 -0500 Subject: FC7 plan comments In-Reply-To: <45886980.5060005@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <45886940.1040908@redhat.com> <45886980.5060005@redhat.com> Message-ID: Christopher Blizzard writes: > With FF2 if you just close the window it saves its state now and will > happily restore, SM or not. And this is really the only reasonable way of doing it, as Havoc says in the 'excruciating details' mail. If applications want their windows restored, they should restore them. The two alternatives: - The window manager should guess, based on title and window type, what a new window might have been in a previous life and attempt to position it accordingly. - We should have complicated system through which applications can ask to be saved, which will then pass special command line arguments to applications when they are started. (Aka xsmp). are both obviously broken. Soren From skvidal at linux.duke.edu Wed Dec 20 06:55:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Dec 2006 01:55:36 -0500 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: <1166597736.25450.6.camel@cutter> On Tue, 2006-12-19 at 14:58 -0500, Jeff Garzik wrote: > > 12. rpm/yum enhancements > > Lack of decent pipelining seems to continue to hurt here. IMO yum > should communicate with a download thread in the background. This > thread would be responsibile for keeping HTTP pipelines full where > possible, even to the extent of connecting to another mirror _while_ a > connection to an existing mirror is plodding along. > In all of the various reports I've gotten of speed issues with yum very few of them have said we need to complicate the process with a background downloading thread in order to help it. In fact, given that we are communicating to multiple servers and we use keepalive it isn't really a big issue on the download. > 19. Move to syslog-ng > > DANGER WILL ROBINSON, possible patent problems: > http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html Why didn't this come up when syslog-ng was brought into extras many moons ago? -sv From buildsys at fedoraproject.org Wed Dec 20 12:12:24 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 20 Dec 2006 07:12:24 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-20 Message-ID: <20061220121224.9EB3215212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) qspencer AT ieee.org: lilypond-doc FE5 > FE6 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc6) FE5 > FE7 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc7) robert AT marcanoonline.com: eclipse-subclipse FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) roland AT redhat.com: monotone FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) eclipse-subclipse: robert AT marcanoonline.com FE6 > FE7 (0:1.1.8-2.fc6 > 0:1.1.5-2.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-6.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lilypond-doc: qspencer AT ieee.org FE5 > FE6 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc6) FE5 > FE7 (0:2.10.2-1.fc5 > 0:2.10.0-1.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) monotone: roland AT redhat.com FE5 > FE6 (0:0.31-1.fc5 > 0:0.30-1.fc6) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.8-1.fc6 > 0:1.5.0.7-5.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) FC5-updates > FC7 (0:3.0.3-1.fc5 > 0:3.0.3-1) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From mattdm at mattdm.org Wed Dec 20 12:46:45 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 20 Dec 2006 07:46:45 -0500 Subject: FC7 plan comments In-Reply-To: <1166597736.25450.6.camel@cutter> References: <20061219195807.GD2417@devserv.devel.redhat.com> <1166597736.25450.6.camel@cutter> Message-ID: <20061220124645.GA469@jadzia.bu.edu> On Wed, Dec 20, 2006 at 01:55:36AM -0500, seth vidal wrote: > > DANGER WILL ROBINSON, possible patent problems: > > http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html > Why didn't this come up when syslog-ng was brought into extras many > moons ago? Maybe I'm misreading, but are they really claiming that an existing program retroactively violates a patent they're just now filing? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From seg at haxxed.com Wed Dec 20 13:15:59 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 20 Dec 2006 07:15:59 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <200612191447.18707.jkeating@redhat.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> Message-ID: <1166620559.5608.13.camel@max.booze> On Tue, 2006-12-19 at 14:47 -0500, Jesse Keating wrote: > On Tuesday 19 December 2006 14:30, Dennis Gilmore wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170335 > > bug has been filed for a long time now. We need a propper answer and it > > is not yet found. it would be much simpler if gnome followed the > > freedesktop.org spec and all you needed was to update the directory time > > stamp. however as gnome goes further we now have this situation. > > The suggestion of using a --delay and gathering many updates into said --delay > seems very sane. But as stated, no time to work on said feature. Patches > welcome :/ I say this should be taken out of individual specs as much as possible. There should be a post-transaction script hook in RPM itself, rather than the package spec, which can handle these things. Either the the package postinstall script sets some flag somehow that the script sees, or better yet, the script is provided a list of all modified/added/removed files, which it can simply grep through, and make decisions like "Something changed in /usr/share/icons, better update the cache" or "Something changed in /usr/lib, better run ldconfig". The individual packages then don't have to worry about it at all. Centralization good. Duplication bad. Don't Repeat Yourself, Once and Only Once, etc. Simplification of specs, also good. -------------- 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 rdieter at math.unl.edu Wed Dec 20 13:43:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 07:43:47 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <1166620559.5608.13.camel@max.booze> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> Message-ID: <45893E13.2030703@math.unl.edu> Callum Lerwick wrote: > I say this should be taken out of individual specs as much as possible. ... > Centralization good. Duplication bad. Don't Repeat Yourself, Once and Only > Once, etc. Simplification of specs, also good Amen brother. > There should be a post-transaction script hook in RPM itself, rather > than the package spec, which can handle these things. > > Either the the package postinstall script sets some flag somehow that > the script sees, or better yet, the script is provided a list of all > modified/added/removed files, which it can simply grep through, and make > decisions like "Something changed in /usr/share/icons, better update the > cache" or "Something changed in /usr/lib, better run ldconfig". The > individual packages then don't have to worry about it at all. An ideal solution for a large class of packaging issues, certainly. Anyone have any concrete proposals of how to implement this? (And such discussions would best take place on the fedora-packaging list) Because, frankly, poo-pooing the current proposal/guidelines in favor of some handy-wavy theoretical lacking-actual-implementation solution, is no solution. -- Rex From Axel.Thimm at ATrpms.net Wed Dec 20 13:58:00 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 20 Dec 2006 14:58:00 +0100 Subject: FC7 plan comments In-Reply-To: <20061220124645.GA469@jadzia.bu.edu> References: <20061219195807.GD2417@devserv.devel.redhat.com> <1166597736.25450.6.camel@cutter> <20061220124645.GA469@jadzia.bu.edu> Message-ID: <20061220135800.GF4374@neu.nirvana> On Wed, Dec 20, 2006 at 07:46:45AM -0500, Matthew Miller wrote: > On Wed, Dec 20, 2006 at 01:55:36AM -0500, seth vidal wrote: > > > DANGER WILL ROBINSON, possible patent problems: > > > http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html > > Why didn't this come up when syslog-ng was brought into extras many > > moons ago? > > Maybe I'm misreading, but are they really claiming that an existing program > retroactively violates a patent they're just now filing? Looks like they claim that they filed the patent in time, but that the patent grant process is still ongoing, and until it's granted they cannot disclose its content. If the public work external to the patent holders is preceeding the filing date of the patent the patent would be invalid to start with. -- 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 seg at haxxed.com Wed Dec 20 14:00:07 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 20 Dec 2006 08:00:07 -0600 Subject: FC7 plan comments In-Reply-To: <45886980.5060005@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <45886940.1040908@redhat.com> <45886980.5060005@redhat.com> Message-ID: <1166623207.5608.38.camel@max.booze> On Tue, 2006-12-19 at 17:36 -0500, Christopher Blizzard wrote: > With FF2 if you just close the window it saves its state now and will > happily restore, SM or not. Exactly. Trying to handle this stuff centrally shows no signs of working very well, and is it even necessary? Each individual app can save and restore its own state just fine. Someday I'll write a long babble about my grand vision of "persistent computing", and it will turn out someone else has already beat me to it anyway. Basically, all apps are to checkpoint all their state on an ongoing basis. This has been partly implemented in a lot of apps already in the name of "crash recovery", which is nice but we can go beyond that... If Done Right(TM), kernel level hibernation would be obsolete. Instead of blindly dumping the entirety of RAM onto disk, each app could intelligently checkpoint their state and shut down. (And since the apps should be constantly checkpointing anyway, they'll already have this done...) ... From what I've seen, PDA/HPC/etc operating systems (Newton, WinCE...) already have this down pat. You can hit the reset button, or lose power completely, and once rebooted, everything appears exactly as it was. Web apps are also a good example, though that's kinda cheating because you've just moved everything to a central server... -------------- 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 leemhuis.info Wed Dec 20 14:07:38 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 20 Dec 2006 15:07:38 +0100 Subject: icon cache scriplet guideline update In-Reply-To: <45893E13.2030703@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> Message-ID: <458943AA.3040203@leemhuis.info> On 20.12.2006 14:43, Rex Dieter wrote: > Callum Lerwick wrote: >> There should be a post-transaction script hook in RPM itself, rather >> than the package spec, which can handle these things. >> >> Either the the package postinstall script sets some flag somehow that >> the script sees, or better yet, the script is provided a list of all >> modified/added/removed files, which it can simply grep through, and make >> decisions like "Something changed in /usr/share/icons, better update the >> cache" or "Something changed in /usr/lib, better run ldconfig". Well, ldconfig should probably be started directly, as other packages might want to start using the just installed package in their scripts. Otherwise agreed, e.g. for the Icon-Cache, scrollkeeeper or stuff like that putting back the actual work to the end of the transaction and running is just once for all freshly installed packages would be very nice and could save a lot of time afaics. >> The >> individual packages then don't have to worry about it at all. > An ideal solution for a large class of packaging issues, certainly. > Anyone have any concrete proposals of how to implement this? (And such > discussions would best take place on the fedora-packaging list) Just wondering if we should solve this completely or in parts directly in rpm... CU thl From seg at haxxed.com Wed Dec 20 14:17:15 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 20 Dec 2006 08:17:15 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <45893E13.2030703@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> Message-ID: <1166624235.5608.49.camel@max.booze> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote: > Because, frankly, poo-pooing the current proposal/guidelines in favor of > some handy-wavy theoretical lacking-actual-implementation solution, is > no solution. Well, the point is, the current proposal does not address the "multiple packages needlessly updating caches multiple times" problem at all. Thus people are questioning what problem this proposal actually solves. Also, I think people are wary of going through with the proposed change, only to have to go back through and change it all *again* once we Fix The Real Problem(TM). -------------- 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 rdieter at math.unl.edu Wed Dec 20 14:35:53 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 08:35:53 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <1166624235.5608.49.camel@max.booze> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> Message-ID: <45894A49.6040707@math.unl.edu> Callum Lerwick wrote: > On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote: >> Because, frankly, poo-pooing the current proposal/guidelines in favor of >> some handy-wavy theoretical lacking-actual-implementation solution, is >> no solution. > > Well, the point is, the current proposal does not address the "multiple > packages needlessly updating caches multiple times" problem at all. Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My findings so far are promising. >Thus people are questioning what problem this proposal actually solves. I've repeated myself several times what the current proposal does and does not address (it's also *in* the proposal itself). If folks, can't read, I can't help that. If folks disagree with the assertions: * packaging guidelines should not include toolkit-specific optimization hacks. * packaging guidelines should reference upstream specs/standards then just frickin say so. -- Rex From ajackson at redhat.com Wed Dec 20 14:33:53 2006 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 20 Dec 2006 09:33:53 -0500 Subject: FC7 plan comments In-Reply-To: <1166623207.5608.38.camel@max.booze> References: <20061219195807.GD2417@devserv.devel.redhat.com> <45886940.1040908@redhat.com> <45886980.5060005@redhat.com> <1166623207.5608.38.camel@max.booze> Message-ID: <1166625233.7683.457.camel@localhost.localdomain> On Wed, 2006-12-20 at 08:00 -0600, Callum Lerwick wrote: > On Tue, 2006-12-19 at 17:36 -0500, Christopher Blizzard wrote: > > With FF2 if you just close the window it saves its state now and will > > happily restore, SM or not. > > Exactly. Trying to handle this stuff centrally shows no signs of working > very well, and is it even necessary? Each individual app can save and > restore its own state just fine. > > Someday I'll write a long babble about my grand vision of "persistent > computing", and it will turn out someone else has already beat me to it > anyway. Basically, all apps are to checkpoint all their state on an > ongoing basis. This has been partly implemented in a lot of apps already > in the name of "crash recovery", which is nice but we can go beyond > that... > > If Done Right(TM), kernel level hibernation would be obsolete. Instead > of blindly dumping the entirety of RAM onto disk, each app could > intelligently checkpoint their state and shut down. (And since the apps > should be constantly checkpointing anyway, they'll already have this > done...) Hey look, you just reinvented smalltalk. Other languages make this really insanely easy. Look at how serialization is done in Lisp or Objective C. It's _in_ _the_ _language_. C just sucks, and yet we insist on writing a desktop with it. - ajax From rdieter at math.unl.edu Wed Dec 20 14:45:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 08:45:11 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <45894A49.6040707@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <1166624235.5608.49.camel@max.booze> <45894A49.6040707@math.unl.edu> Message-ID: <45894C77.4090903@math.unl.edu> Rex Dieter wrote: > Callum Lerwick wrote: >> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote: >>> Because, frankly, poo-pooing the current proposal/guidelines in favor >>> of some handy-wavy theoretical lacking-actual-implementation >>> solution, is no solution. >> >> Well, the point is, the current proposal does not address the "multiple >> packages needlessly updating caches multiple times" problem at all. > > Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My > findings so far are promising. I formally withdraw the iconcache proposal as-is, pending investigation of the previously unaddressed "needlessly updating cache multiple times" issue. -- Rex From seg at haxxed.com Wed Dec 20 14:52:51 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 20 Dec 2006 08:52:51 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <458943AA.3040203@leemhuis.info> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <458943AA.3040203@leemhuis.info> Message-ID: <1166626371.5608.62.camel@max.booze> On Wed, 2006-12-20 at 15:07 +0100, Thorsten Leemhuis wrote: > On 20.12.2006 14:43, Rex Dieter wrote: > > Callum Lerwick wrote: > >> Either the the package postinstall script sets some flag somehow that > >> the script sees, or better yet, the script is provided a list of all > >> modified/added/removed files, which it can simply grep through, and make > >> decisions like "Something changed in /usr/share/icons, better update the > >> cache" or "Something changed in /usr/lib, better run ldconfig". > > Well, ldconfig should probably be started directly, as other packages > might want to start using the just installed package in their scripts. Hmm, forgot about that. Is there a reason that the dynamic linker can't be made so that if it fails to find something in the cache, it falls back to a direct search through the filesystem? Or just trigger a cache update then and there? Another one I thought of, is getting rid of the damned prelink cron job, which has all the same problems that the "lets have an icon cache update cron job!" idea has and was rejected for. Run it post transaction, which is what Apple's updater does. Its the "Optimizing System Performance" step that takes a really loooong time, so we'd definitely want to trigger it in the *background* somehow. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hp at redhat.com Wed Dec 20 15:56:33 2006 From: hp at redhat.com (Havoc Pennington) Date: Wed, 20 Dec 2006 10:56:33 -0500 Subject: FC7 plan comments In-Reply-To: <20061219225731.GG2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <45886940.1040908@redhat.com> <20061219225439.GF2417@devserv.devel.redhat.com> <20061219225731.GG2417@devserv.devel.redhat.com> Message-ID: <45895D31.3060607@redhat.com> Jeff Garzik wrote: > On Tue, Dec 19, 2006 at 05:54:39PM -0500, Jeff Garzik wrote: >> On Tue, Dec 19, 2006 at 05:35:44PM -0500, Havoc Pennington wrote: >>> Short answer, app window state saving won't work until somebody puts a >>> bullet in trying to use XSMP to do it. >> But.. but... each of said apps listed, all Gtk apps mind you, do save >> and restore their window position flawlessly under KDE. > > "betweens sessions" (i.e. log in/out), I should have said. > My guess on that is that KWin tends to have more heuristic guesses at the right thing to do than I put in metacity. iirc (this was years ago) I didn't much try to make things work unless the letter of the spec was followed. Didn't want to deal with the endless bugstream about wrong guesses. KWin may also have heuristic window state saving unrelated to XSMP, e.g. based on window class, for apps that don't support XSMP. Not really an endorsement of XSMP when these heuristics kick in, only an endorsement of KWin. It could also just be a bug, or a different interpretation of the letter of the spec in any of app, SM, or WM. Doesn't change the basic point that the best way to fix it is to have apps (ideally helped by the toolkit) remember their own window state, thus avoiding the whole XSMP Rube Goldberg device. Though scaring the chicken into pecking the button that drops the weight etc. may work from time to time, it's still a stupid design. Havoc From dwmw2 at infradead.org Wed Dec 20 17:06:55 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Dec 2006 17:06:55 +0000 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: <1166634415.25827.262.camel@pmac.infradead.org> On Tue, 2006-12-19 at 14:58 -0500, Jeff Garzik wrote: > DANGER WILL ROBINSON, possible patent problems: > http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html One of these days I'm going to patent the business method of filing nuisance patents to disrupt competitors' business. Either that or I'm going to patent the practice of rolling over and playing dead at the first _hint_ of a patent filing which might cover obvious parts of software I shop. Maybe both. -- dwmw2 From fedora at leemhuis.info Wed Dec 20 18:13:34 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 20 Dec 2006 19:13:34 +0100 Subject: Plan for tomorrows (20061219) FESCO meeting Message-ID: <45897D4E.7030909@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next FESCo meeting that scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-extras on irc.freenode.org. > /topic FESCo meeting -- Improve FESCo's workflow > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- EPEL doesn't really lift of -- what do? > /topic FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- open epel to sponsors and people with 5 packages or more -- why wasn't that announced properly? > /topic FESCo meeting -- Opening Core - (warren, jeremy, rdieter) -- status update > /topic FESCO-Meeting -- Encourage co-maintainership -- c4chris > /topic FESCo meeting -- MISC -- lots of python stuff still needs rebuilding -- any better this week > /topic FESCo meeting -- Packaging Committee Report > /topic FESCo meeting -- Maintainer Responsibility Policy -- bpepple -- EOL plans > /topic FESCo meeting -- Alternative paths of membership advancement -- warren > /topic FESCo meeting -- Free discussion around Fedora Extras You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... The schedule page in the wiki has more details on the individual topics; see http://www.fedoraproject.org/wiki/Extras/Schedule The individual pages specific to the topics are linked from there. The same as above holds true: if you name is somewhere on the schedule page in the wiki please update the status in the wiki ahead of the meeting. Ohh, and please update it also directly after the meeting so it's update and prepared for next weeks meeting :-) Hint: If you want to know what FESCo is doing simply subscribe in the wiki to "Extras/Schedul.*" and you'll get mails if something changes in that areas of the wiki. That should give you a good idea of FESCo's work. CU thl From mbarnes at redhat.com Wed Dec 20 18:16:16 2006 From: mbarnes at redhat.com (Matthew Barnes) Date: Wed, 20 Dec 2006 13:16:16 -0500 Subject: gnome-python2-devel Message-ID: <1166638576.4586.27.camel@mbarnes.boston.redhat.com> Hey all, Chris Aillon alerted me to a boo-boo I made in a recent update to the gnome-python2 package, where I introduced a new gnome-python2-devel subpackage in Fedora Core 6 to fix a bug that was filed about it. The problem is two-fold. FC6 is supposed to be stable, and I didn't announce the change to anyone. Unfortunately the change already got pushed to FC6, so this is a heads-up. If your package BuildRequires gnome-python2 you may need to change that to gnome-python2-devel. Here's a list of packages that may be affected: autobuild-applet blogtk deskbar-applet gjots2 gnome-password-generator gnome-python2-bonobo gnome-python2-canvas gnome-python2-extras gnome-python2-gconf gnome-python2-gda gnome-python2-gnomevfs gourmet gramps hal-gnome hwbrowser listen meld policycoreutils-gui qa-assistant system-config-bind system-config-cluster system-config-httpd system-config-lvm system-config-netboot system-config-network Sorry for the inconvenience. Matthew Barnes From davej at redhat.com Wed Dec 20 18:49:52 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 13:49:52 -0500 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: <20061220184952.GB3248@redhat.com> On Tue, Dec 19, 2006 at 02:58:07PM -0500, Jeff Garzik wrote: > 10. Boot and shutdown speedup > > Jens Axboe did some kernel work for this, fcache: > http://lkml.org/lkml/2006/5/15/46 > > A lot of the boot slowness here comes from (a) udev [10+ seconds in > startup], or (b) non-parallel initscripts. The biggest wins will come from a) do less stuff. Why are we starting so many things up during boot? Do I need to be running a smartcard daemon on a system with no smartcard reader? Do I need a bluetooth service on a system with no bluetooth? etc etc b) do less stuff. For the apps that we *do* need to start up, make them behave properly instead of opening gazillions of files pointlessly. More IO tracing work needed here to find the latest round of bad juju. (It's a different set of culprits every release). c) minimise contention. Instead of having everything competing for disk bandwidth during startup, we could have say.. cups start up, and do nothing for a while, and when the disk becomes idle, /then/ do its IO pulling in configs etc. The set_ioprio syscalls added a few kernels back may also be interesting. > 18. Move to using libata for PATA support > > Please keep me and Alan Cox in the loop on this. > > NOTE: You might need some intelligence in mkinitrd to avoid adding > spurious drivers such as pata_generic or ata_generic to the initrd, > after matching more specific pata_* drivers. That bit sounds like it could be trickier than it sounds for some reason. We decide what goes into the initrd based on PCI ID, so if that matches before the real chip driver, it could go in. And blacklisting it not to go in at all would suck for chipsets we don't (yet) have drivers for. Sounds like some black magic is needed to make sure this happens at the end. I see 'ata_generic' but no 'pata_generic'. Did you mean 'pata_legacy' perhaps? We don't build that. (and probably won't). The biggest problem we've hit so far has been the "modprobe returns before the disks are found". We need some better smarts than what we currently have which amounts to something like.. while [ 5 seconds havent passed ] did /proc/scsi/scsi change? sleep 1 done Ugly hack, but Peter has been swamped of late, so hasn't got around to doing 'the right thing' for mkinitrd. > J1) (possibly not FC7 material) installer support for a few popular > FUSE filesystems Tricky, as the filesystems need to be in the installer image. What's the use-case for this ? The only one I can think of is for the fuse crypto stuff, and a better solution for crypto installs is probably going to be to use e2cryptfs. > J2) Drop support for any hardware that does not support -march=i686 I'd really like to drop the 586 kernel, but I fear there are still far too many people with old VIA EPIA's and the like out there. At some point, I think it makes sense for a spin-off of Fedora to happen for older machines, but it really needs someone with the time and energy to make it happen. Something more feasible would be to drop support for all the ancient ISA junk. We can't reasonably debug failures in these ancient drivers any more because a lot of the time they're board specific problems. I don't even have any systems with ISA slots any more, let alone ISA cards. It's completely unsupportable, and upstream seems to care less and less about ancient stuff all the time (not just sound cards, but others too). Worse yet, people seem to expect feature parity from 10 year old hardware. There are a number of "Why doesn't udev find my ISA sound card" bugs. The only spanner in the works is that some laptops for god knows what reason, have their sound devices on ISA busses. Dave [*] I should be careful, last time I said "I don't have any ISA cards" some joker left an ISA SB16 in my cube. -- http://www.codemonkey.org.uk From tmraz at redhat.com Wed Dec 20 19:25:30 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 20 Dec 2006 20:25:30 +0100 Subject: FC7 plan comments In-Reply-To: <20061220184952.GB3248@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> Message-ID: <1166642730.6458.8.camel@perun.kabelta.loc> On Wed, 2006-12-20 at 13:49 -0500, Dave Jones wrote: > On Tue, Dec 19, 2006 at 02:58:07PM -0500, Jeff Garzik wrote: > > > 10. Boot and shutdown speedup > > > > Jens Axboe did some kernel work for this, fcache: > > http://lkml.org/lkml/2006/5/15/46 > > > > A lot of the boot slowness here comes from (a) udev [10+ seconds in > > startup], or (b) non-parallel initscripts. > > The biggest wins will come from > a) do less stuff. > Why are we starting so many things up during boot? > Do I need to be running a smartcard daemon on a system with no smartcard reader? For example the egate cards are USB devices so the pcscd could theoretically be started by udev when the card is plugged in. But the library currently doesn't work right when the daemon is (re)started when it was already initialized. And even if this was fixed the reaction time for an app to actually discover that a smartcard was plugged in is already pretty long. So making it even longer due to having to start the pcscd is not too good idea. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From jgarzik at redhat.com Wed Dec 20 19:35:26 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Wed, 20 Dec 2006 14:35:26 -0500 Subject: FC7 plan comments In-Reply-To: <1166642730.6458.8.camel@perun.kabelta.loc> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> Message-ID: <20061220193525.GB7631@devserv.devel.redhat.com> On Wed, Dec 20, 2006 at 08:25:30PM +0100, Tomas Mraz wrote: > For example the egate cards are USB devices so the pcscd could > theoretically be started by udev when the card is plugged in. But the > library currently doesn't work right when the daemon is (re)started when > it was already initialized. And even if this was fixed the reaction time > for an app to actually discover that a smartcard was plugged in is > already pretty long. So making it even longer due to having to start the > pcscd is not too good idea. That's just a one-time cost. Once its running, you know the user uses smart cards, so no need add idle-out, daemon-stop complexity. I think adding a miniscule pause the first time a user uses a SmartCard after booting the system is just fine, compared to what it gains us. Jeff From chitlesh at fedoraproject.org Wed Dec 20 19:55:50 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 20 Dec 2006 20:55:50 +0100 Subject: icon cache scriplet guideline update In-Reply-To: <1166626371.5608.62.camel@max.booze> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <458943AA.3040203@leemhuis.info> <1166626371.5608.62.camel@max.booze> Message-ID: <13dbfe4f0612201155p662a9830y86ac901d07ea30d2@mail.gmail.com> Hello, So as from when, will this guidelines be applied ? In accordance to http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache (I know it's a draft) # 3 xdg-utils is not available for FC6 and earlier (Core) packages, so this policy does not apply there chitlesh(SPECS)[1]$rpm -q xdg-utils xdg-utils-1.0.1-1.fc6 Now it's already in FE! Chitlesh -- http://clunixchit.blogspot.com From rdieter at math.unl.edu Wed Dec 20 20:02:28 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Dec 2006 14:02:28 -0600 Subject: icon cache scriplet guideline update In-Reply-To: <13dbfe4f0612201155p662a9830y86ac901d07ea30d2@mail.gmail.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <458943AA.3040203@leemhuis.info> <1166626371.5608.62.camel@max.booze> <13dbfe4f0612201155p662a9830y86ac901d07ea30d2@mail.gmail.com> Message-ID: <458996D4.3030704@math.unl.edu> Chitlesh GOORAH wrote: > So as from when, will this guidelines be applied ? Stay tuned, after ratification by FESCo and the Core-cabal. > In accordance to > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache ... > # 3 > xdg-utils is not available for FC6 and earlier (Core) packages, so > this policy does not apply there ... > Now it's already in FE! "there" meaning the policy won't apply to pre-F7 *Core* packages (Core packages can't depend on anything from Extras). Extras pkgs are ok. -- Rex From sundaram at fedoraproject.org Wed Dec 20 20:07:45 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 21 Dec 2006 01:37:45 +0530 Subject: icon cache scriplet guideline update In-Reply-To: <13dbfe4f0612201155p662a9830y86ac901d07ea30d2@mail.gmail.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <200612191330.53550.dennis@ausil.us> <200612191447.18707.jkeating@redhat.com> <1166620559.5608.13.camel@max.booze> <45893E13.2030703@math.unl.edu> <458943AA.3040203@leemhuis.info> <1166626371.5608.62.camel@max.booze> <13dbfe4f0612201155p662a9830y86ac901d07ea30d2@mail.gmail.com> Message-ID: <45899811.109@fedoraproject.org> Chitlesh GOORAH wrote: > Hello, > So as from when, will this guidelines be applied ? > > In accordance to > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > (I know it's a draft) > # 3 > xdg-utils is not available for FC6 and earlier (Core) packages, so > this policy does not apply there > > chitlesh(SPECS)[1]$rpm -q xdg-utils > xdg-utils-1.0.1-1.fc6 > > Now it's already in FE! Core packages cannot depend on packages in extras. So while any package in extras can use xdg-utils, any core packages in FC5/6 cant. Rahul From fedora at camperquake.de Wed Dec 20 21:10:30 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 20 Dec 2006 22:10:30 +0100 Subject: icon cache scriplet guideline update In-Reply-To: <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> Message-ID: <20061220221030.520becbe@nausicaa.camperquake.de> Hi. "Chitlesh GOORAH" wrote: > I'm firing a RFE since we are talking about scriptlets! > When installing more than 2 rpms with yum with scriptlets, > installation is quite slow since for each rpm it has to > %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : > why not telling yum to do it once only ? I am not convinced that this can be done in a sane way, and I am, quite frankly, amazed that it does seem to work with %post -p (most often used with %post -p /sbin/ldconfig, as it seems). Assume you have three packages scheduled for update, A, B, and C. A and C provide libraries, and use "%post -p /sbin/ldconfig". As I understand it, rpm will only execute ldconfig once, at the end of the transaction. Now assume that B calls something in it's %post section that depends on a library installed from A. Will the linker find the library, if there has been a change of SONAME? This problem can be easily transformed into something that does not involve libraries :) -- The gates are down, the lights are flashing, but the train isn't coming. From mitr at redhat.com Wed Dec 20 21:15:27 2006 From: mitr at redhat.com (Miloslav Trmac) Date: Wed, 20 Dec 2006 22:15:27 +0100 Subject: icon cache scriplet guideline update In-Reply-To: <20061220221030.520becbe@nausicaa.camperquake.de> References: <45882D48.7080509@math.unl.edu> <13dbfe4f0612191126i1382c872ldd5e9c5585ed9914@mail.gmail.com> <20061220221030.520becbe@nausicaa.camperquake.de> Message-ID: <4589A7EF.4090501@redhat.com> Ralf Ertzinger napsal(a): > "Chitlesh GOORAH" wrote: >> When installing more than 2 rpms with yum with scriptlets, >> installation is quite slow since for each rpm it has to >> %{_bindir}/xdg-icon-resource forceupdate --theme hicolor || : >> why not telling yum to do it once only ? > I am not convinced that this can be done in a sane way, and I am, > quite frankly, amazed that it does seem to work with %post -p > (most often used with %post -p /sbin/ldconfig, as it seems). -p /sbin/ldconfig is special-cased within rpm. It is not a generally available feature. > Assume you have three packages scheduled for update, A, B, and C. > A and C provide libraries, and use "%post -p /sbin/ldconfig". As > I understand it, rpm will only execute ldconfig once, at the end > of the transaction. > > Now assume that B calls something in it's %post section that depends > on a library installed from A. Will the linker find the library, if > there has been a change of SONAME? IIRC rpm does know it needs run ldconfig before any further scriptlets. Mirek From fedora at camperquake.de Wed Dec 20 21:20:17 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 20 Dec 2006 22:20:17 +0100 Subject: FC7 plan comments In-Reply-To: <20061220184952.GB3248@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> Message-ID: <20061220222017.4a08a4d1@nausicaa.camperquake.de> Hi. Dave Jones wrote: > > J1) (possibly not FC7 material) installer support for a few popular > > FUSE filesystems > > Tricky, as the filesystems need to be in the installer image. > What's the use-case for this ? The only one I can think of is for the > fuse crypto stuff, and a better solution for crypto installs is > probably going to be to use e2cryptfs. I'd be happy for working dm-crypt support. The kernel bits work, but I can neither install (sanely) on such a device, and initrd support (for encrypted /) seems to be missing, too. -- 502 Permission denied, you spamming luser pusbucket. From katzj at redhat.com Wed Dec 20 21:23:38 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 16:23:38 -0500 Subject: FC7 plan comments In-Reply-To: <20061220222017.4a08a4d1@nausicaa.camperquake.de> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <20061220222017.4a08a4d1@nausicaa.camperquake.de> Message-ID: <1166649818.10717.60.camel@aglarond.local> On Wed, 2006-12-20 at 22:20 +0100, Ralf Ertzinger wrote: > Dave Jones wrote: > > > J1) (possibly not FC7 material) installer support for a few popular > > > FUSE filesystems > > > > Tricky, as the filesystems need to be in the installer image. > > What's the use-case for this ? The only one I can think of is for the > > fuse crypto stuff, and a better solution for crypto installs is > > probably going to be to use e2cryptfs. > > I'd be happy for working dm-crypt support. The kernel bits work, but I > can neither install (sanely) on such a device, and initrd support (for > encrypted /) seems to be missing, too. The problem is that how do you handle this in the initrd? You want to be able to prompt a user (in their native language) as well as support their native keymap. This could very easily require an X server and a lot of fonts and other bits. At which point, exactly what are you trying to accomplish? Encrypting data? Very interesting. Encrypting the OS bits that anyone can download? Much less interesting, IMHO Jeremy From kevin at tummy.com Wed Dec 20 22:03:08 2006 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 20 Dec 2006 15:03:08 -0700 Subject: FC7 plan comments In-Reply-To: <1166649818.10717.60.camel@aglarond.local> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <20061220222017.4a08a4d1@nausicaa.camperquake.de> <1166649818.10717.60.camel@aglarond.local> Message-ID: <20061220150308.5c62a372@ningauble.scrye.com> On Wed, 20 Dec 2006 16:23:38 -0500 katzj at redhat.com (Jeremy Katz) wrote: > On Wed, 2006-12-20 at 22:20 +0100, Ralf Ertzinger wrote: > > Dave Jones wrote: > > > > J1) (possibly not FC7 material) installer support for a few > > > > popular FUSE filesystems > > > > > > Tricky, as the filesystems need to be in the installer image. > > > What's the use-case for this ? The only one I can think of is for > > > the fuse crypto stuff, and a better solution for crypto installs > > > is probably going to be to use e2cryptfs. > > > > I'd be happy for working dm-crypt support. The kernel bits work, > > but I can neither install (sanely) on such a device, and initrd > > support (for encrypted /) seems to be missing, too. > > The problem is that how do you handle this in the initrd? You want to > be able to prompt a user (in their native language) as well as support > their native keymap. This could very easily require an X server and a > lot of fonts and other bits. At which point, exactly what are you > trying to accomplish? > > Encrypting data? Very interesting. > Encrypting the OS bits that anyone can download? Much less > interesting, IMHO I use a method described by my compatriot Sean at: http://www.tummy.com/journals/entries/jafo_20060326_215808 It simply uses a small script in /etc/sysconfig/modules/ (which runs right after udev) that loads the dm_crypt modules, and runs cyptsetup to prompt the user for the password on boot. If you have the encrypted volume mounted a boot it means you either can't have unattended boot, or get things breaking that need to access /home before it's mounted. If you mount at login time, you get breakage for things that need /home (like mail delivery or the like if you send it there). How do you handle multiple users? Remote logins? Backups? Lost passwords? This is not an easy problem to solve, but I think it's very important to get some mindpower working on it. Having encrypted data is very nice, especially for the expanding linux laptop market. We should probably move this discussion to a more appropriate list, but I'm not sure what that would be. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmraz at redhat.com Wed Dec 20 22:07:11 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 20 Dec 2006 23:07:11 +0100 Subject: FC7 plan comments In-Reply-To: <1166649818.10717.60.camel@aglarond.local> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <20061220222017.4a08a4d1@nausicaa.camperquake.de> <1166649818.10717.60.camel@aglarond.local> Message-ID: <1166652432.6458.20.camel@perun.kabelta.loc> On Wed, 2006-12-20 at 16:23 -0500, Jeremy Katz wrote: > On Wed, 2006-12-20 at 22:20 +0100, Ralf Ertzinger wrote: > > I'd be happy for working dm-crypt support. The kernel bits work, but I > > can neither install (sanely) on such a device, and initrd support (for > > encrypted /) seems to be missing, too. > > The problem is that how do you handle this in the initrd? You want to > be able to prompt a user (in their native language) as well as support > their native keymap. This could very easily require an X server and a > lot of fonts and other bits. At which point, exactly what are you > trying to accomplish? > > Encrypting data? Very interesting. > Encrypting the OS bits that anyone can download? Much less interesting, > IMHO At least an encrypted swap is a requirement so sensitive data are not left unencrypted on disk. /tmp and some /var subdirs are also questionable. The swap could be enabled after boot is finished when X server is running. /tmp and /var could be a tougher problem. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From fedora at camperquake.de Wed Dec 20 22:12:55 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 20 Dec 2006 23:12:55 +0100 Subject: FC7 plan comments In-Reply-To: <1166652432.6458.20.camel@perun.kabelta.loc> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <20061220222017.4a08a4d1@nausicaa.camperquake.de> <1166649818.10717.60.camel@aglarond.local> <1166652432.6458.20.camel@perun.kabelta.loc> Message-ID: <20061220231255.70cd89f9@lain.camperquake.de> Hi. On Wed, 20 Dec 2006 23:07:11 +0100, Tomas Mraz wrote > At least an encrypted swap is a requirement so sensitive data are not > left unencrypted on disk. /tmp and some /var subdirs are also > questionable. This works Right Now[tm]. man crypttab From davej at redhat.com Thu Dec 21 01:13:09 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Dec 2006 20:13:09 -0500 Subject: FC7 plan comments In-Reply-To: <20061220193525.GB7631@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> Message-ID: <20061221011309.GQ3248@redhat.com> On Wed, Dec 20, 2006 at 02:35:26PM -0500, Jeff Garzik wrote: > On Wed, Dec 20, 2006 at 08:25:30PM +0100, Tomas Mraz wrote: > > For example the egate cards are USB devices so the pcscd could > > theoretically be started by udev when the card is plugged in. But the > > library currently doesn't work right when the daemon is (re)started when > > it was already initialized. And even if this was fixed the reaction time > > for an app to actually discover that a smartcard was plugged in is > > already pretty long. So making it even longer due to having to start the > > pcscd is not too good idea. > > That's just a one-time cost. Once its running, you know the user uses > smart cards, so no need add idle-out, daemon-stop complexity. > > I think adding a miniscule pause the first time a user uses a SmartCard > after booting the system is just fine, compared to what it gains us. Right. Theres the option of doing it when its actually useful inconveniencing that user once each time they plug the device in, which takes maybe a few seconds. And then theres stealing the time of _every_ user even if they don't even own a smart card reader. Which just seems like a horrible waste of time. Multiply this by all the other unnecessary daemons and then wonder how much of your life is being wasted sitting waiting for the computer to become usable whilst it's sitting there in lala land doing pointless things. Dave -- http://www.codemonkey.org.uk From katzj at redhat.com Thu Dec 21 03:13:31 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 22:13:31 -0500 Subject: FC7 plan comments In-Reply-To: <20061221011309.GQ3248@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> Message-ID: <1166670811.10717.68.camel@aglarond.local> On Wed, 2006-12-20 at 20:13 -0500, Dave Jones wrote: > On Wed, Dec 20, 2006 at 02:35:26PM -0500, Jeff Garzik wrote: > > On Wed, Dec 20, 2006 at 08:25:30PM +0100, Tomas Mraz wrote: > > > For example the egate cards are USB devices so the pcscd could > > > theoretically be started by udev when the card is plugged in. But the > > > library currently doesn't work right when the daemon is (re)started when > > > it was already initialized. And even if this was fixed the reaction time > > > for an app to actually discover that a smartcard was plugged in is > > > already pretty long. So making it even longer due to having to start the > > > pcscd is not too good idea. > > > > That's just a one-time cost. Once its running, you know the user uses > > smart cards, so no need add idle-out, daemon-stop complexity. > > > > I think adding a miniscule pause the first time a user uses a SmartCard > > after booting the system is just fine, compared to what it gains us. > > Right. Theres the option of doing it when its actually useful inconveniencing > that user once each time they plug the device in, which takes maybe a few > seconds. And if the reader is plugged in at system boot, then it actually doesn't end up being a net difference as the daemon will _still_ be getting started during boot but the advantage is it will only be happening for the users who want it. I should really start filing this set of bugs as I think it's a pretty straight-forward set of fixes that should have a noticeable impact on boot time. Jeremy From katzj at redhat.com Thu Dec 21 03:22:25 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 22:22:25 -0500 Subject: FC7 plan comments In-Reply-To: <20061220150308.5c62a372@ningauble.scrye.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <20061220222017.4a08a4d1@nausicaa.camperquake.de> <1166649818.10717.60.camel@aglarond.local> <20061220150308.5c62a372@ningauble.scrye.com> Message-ID: <1166671345.10717.77.camel@aglarond.local> On Wed, 2006-12-20 at 15:03 -0700, Kevin Fenzi wrote: > On Wed, 20 Dec 2006 16:23:38 -0500 > katzj at redhat.com (Jeremy Katz) wrote: > > On Wed, 2006-12-20 at 22:20 +0100, Ralf Ertzinger wrote: > > > Dave Jones wrote: > > > > > J1) (possibly not FC7 material) installer support for a few > > > > > popular FUSE filesystems > > > > > > > > Tricky, as the filesystems need to be in the installer image. > > > > What's the use-case for this ? The only one I can think of is for > > > > the fuse crypto stuff, and a better solution for crypto installs > > > > is probably going to be to use e2cryptfs. > > > > > > I'd be happy for working dm-crypt support. The kernel bits work, > > > but I can neither install (sanely) on such a device, and initrd > > > support (for encrypted /) seems to be missing, too. > > > > The problem is that how do you handle this in the initrd? You want to > > be able to prompt a user (in their native language) as well as support > > their native keymap. This could very easily require an X server and a > > lot of fonts and other bits. At which point, exactly what are you > > trying to accomplish? > > > > Encrypting data? Very interesting. > > Encrypting the OS bits that anyone can download? Much less > > interesting, IMHO > > I use a method described by my compatriot Sean at: > > http://www.tummy.com/journals/entries/jafo_20060326_215808 > > It simply uses a small script in /etc/sysconfig/modules/ > (which runs right after udev) that loads the dm_crypt modules, and runs > cyptsetup to prompt the user for the password on boot. This can be a little bit better in terms of having the root filesystem mounted and thus you can use X to be able to prompt in the appropriate language and with the right keymap, but some of your questions below remain _very_ relevant as long as we're talking about encrypting the block devices. > If you have the encrypted volume mounted a boot it means you either > can't have unattended boot, or get things breaking that need to > access /home before it's mounted. If you mount at login time, you get > breakage for things that need /home (like mail delivery or the like if > you send it there). How do you handle multiple users? Remote logins? > Backups? Lost passwords? > > This is not an easy problem to solve, but I think it's very important > to get some mindpower working on it. Having encrypted data is very > nice, especially for the expanding linux laptop market. When we're talking _data_, I really think that an answer along the lines of ecryptfs[1] is a far more compelling answer than per-block device encryption. They're looking at doing encryption below a directory tree. This means that each user can have a separate passphrase (or more generally, token) for decryption and then they can even have ~/MyMoreSecretStuff which doesn't even get unlocked when they login. This also helps for some of the cases like mail delivery as you can specify that a subdir below the homedir that isn't encrypted for mail[2]. > We should probably move this discussion to a more appropriate list, but > I'm not sure what that would be. ;) fedora-devel-list? :) Jeremy [1] http://ecryptfs.sf.net, although the current version doesn't support everything that's really needed to make it compelling [2] Although arguably, you should just not deliver to homedirs in this case/have a dedicated mail server From katzj at redhat.com Thu Dec 21 03:25:07 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 22:25:07 -0500 Subject: FC7 plan comments In-Reply-To: <1166652432.6458.20.camel@perun.kabelta.loc> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <20061220222017.4a08a4d1@nausicaa.camperquake.de> <1166649818.10717.60.camel@aglarond.local> <1166652432.6458.20.camel@perun.kabelta.loc> Message-ID: <1166671507.10717.81.camel@aglarond.local> On Wed, 2006-12-20 at 23:07 +0100, Tomas Mraz wrote: > On Wed, 2006-12-20 at 16:23 -0500, Jeremy Katz wrote: > > Encrypting data? Very interesting. > > Encrypting the OS bits that anyone can download? Much less interesting, > > IMHO > > At least an encrypted swap is a requirement so sensitive data are not > left unencrypted on disk. /tmp and some /var subdirs are also > questionable. > > The swap could be enabled after boot is finished when X server is > running. /tmp and /var could be a tougher problem. swap is straight-forward; you don't really need to have a persistent key there. You could even just remake the swap partition with a new random key on every boot and it's not a big problem[1] For /tmp and /var, you likely want poly-instantiated dirs for the user bits and thus the encryption to be under the control of the user. You could also more generally use ecryptfs here to just do the specific subtrees of each that are cared about Jeremy [1] There are some interesting questions around hibernate, but it mostly requires sitting down and thinking about it From mclasen at redhat.com Thu Dec 21 03:30:09 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 20 Dec 2006 22:30:09 -0500 Subject: FC7 plan comments In-Reply-To: <1166670811.10717.68.camel@aglarond.local> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> Message-ID: <1166671809.4476.1.camel@localhost.localdomain> On Wed, 2006-12-20 at 22:13 -0500, Jeremy Katz wrote: > I should really start filing this set of bugs as I think it's a pretty > straight-forward set of fixes that should have a noticeable impact on > boot time. While we are talking about bugs and daemons, can we maybe rewrite yum-updatesd in a language that makes it use less than 10MB ? It is by far the biggest of the useless daemons... From seg at haxxed.com Thu Dec 21 05:45:08 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 20 Dec 2006 23:45:08 -0600 Subject: FC7 plan comments In-Reply-To: <1166671809.4476.1.camel@localhost.localdomain> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> Message-ID: <1166679909.11691.3.camel@localhost.localdomain> On Wed, 2006-12-20 at 22:30 -0500, Matthias Clasen wrote: > While we are talking about bugs and daemons, can we maybe rewrite > yum-updatesd in a language that makes it use less than 10MB ? It is by > far the biggest of the useless daemons... Why is it even a resident daemon? This seems like a job for anacron. And why does it check every hour by default? That seems a bit excessive. I've been changing my systems to check every 8 hours. -------------- 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 leemhuis.info Thu Dec 21 05:49:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 21 Dec 2006 06:49:47 +0100 Subject: FC7 plan comments In-Reply-To: <1166671809.4476.1.camel@localhost.localdomain> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> Message-ID: <458A207B.80605@leemhuis.info> On 21.12.2006 04:30, Matthias Clasen wrote: > On Wed, 2006-12-20 at 22:13 -0500, Jeremy Katz wrote: > >> I should really start filing this set of bugs as I think it's a pretty >> straight-forward set of fixes that should have a noticeable impact on >> boot time. > While we are talking about bugs and daemons, can we maybe rewrite > yum-updatesd in a language that makes it use less than 10MB ? It is by > far the biggest of the useless daemons... And on my notebook (Pentium M, 2 1/2 years old, 60 GB bug slow Harddisk) it's the one that takes the most time to start (thus I disabled it). Jeremy, is that know? Or shall I file a bug? CU thl From notting at redhat.com Thu Dec 21 05:52:58 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Dec 2006 00:52:58 -0500 Subject: FC7 plan comments In-Reply-To: <1166679909.11691.3.camel@localhost.localdomain> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> Message-ID: <20061221055258.GA19735@nostromo.devel.redhat.com> Callum Lerwick (seg at haxxed.com) said: > On Wed, 2006-12-20 at 22:30 -0500, Matthias Clasen wrote: > > While we are talking about bugs and daemons, can we maybe rewrite > > yum-updatesd in a language that makes it use less than 10MB ? It is by > > far the biggest of the useless daemons... > > Why is it even a resident daemon? It's used by the update applet - the applet queries it for available updates, and by having the daemon resident, it saves bloat and slowness in the applet. (Basically, the same code would have to be in one place or the other...) Bill From garrick at usc.edu Thu Dec 21 06:02:19 2006 From: garrick at usc.edu (Garrick Staples) Date: Wed, 20 Dec 2006 22:02:19 -0800 Subject: FC7 plan comments In-Reply-To: <20061221055258.GA19735@nostromo.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> <20061221055258.GA19735@nostromo.devel.redhat.com> Message-ID: <20061221060219.GK2297@polop.usc.edu> On Thu, Dec 21, 2006 at 12:52:58AM -0500, Bill Nottingham alleged: > Callum Lerwick (seg at haxxed.com) said: > > On Wed, 2006-12-20 at 22:30 -0500, Matthias Clasen wrote: > > > While we are talking about bugs and daemons, can we maybe rewrite > > > yum-updatesd in a language that makes it use less than 10MB ? It is by > > > far the biggest of the useless daemons... > > > > Why is it even a resident daemon? > > It's used by the update applet - the applet queries it for available > updates, and by having the daemon resident, it saves bloat and slowness > in the applet. (Basically, the same code would have to be in one > place or the other...) Then how about it doesn't launch until the applet is launched (maybe through dbus?) -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Dec 21 06:05:46 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 21 Dec 2006 01:05:46 -0500 Subject: FC7 plan comments In-Reply-To: <20061221060219.GK2297@polop.usc.edu> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> <20061221055258.GA19735@nostromo.devel.redhat.com> <20061221060219.GK2297@polop.usc.edu> Message-ID: <1166681146.32180.12.camel@cutter> On Wed, 2006-12-20 at 22:02 -0800, Garrick Staples wrote: > On Thu, Dec 21, 2006 at 12:52:58AM -0500, Bill Nottingham alleged: > > Callum Lerwick (seg at haxxed.com) said: > > > On Wed, 2006-12-20 at 22:30 -0500, Matthias Clasen wrote: > > > > While we are talking about bugs and daemons, can we maybe rewrite > > > > yum-updatesd in a language that makes it use less than 10MB ? It is by > > > > far the biggest of the useless daemons... > > > > > > Why is it even a resident daemon? > > > > It's used by the update applet - the applet queries it for available > > updates, and by having the daemon resident, it saves bloat and slowness > > in the applet. (Basically, the same code would have to be in one > > place or the other...) > > Then how about it doesn't launch until the applet is launched (maybe > through dbus?) so it launches as the user? -sv From garrick at usc.edu Thu Dec 21 06:16:18 2006 From: garrick at usc.edu (Garrick Staples) Date: Wed, 20 Dec 2006 22:16:18 -0800 Subject: FC7 plan comments In-Reply-To: <1166681146.32180.12.camel@cutter> References: <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> <20061221055258.GA19735@nostromo.devel.redhat.com> <20061221060219.GK2297@polop.usc.edu> <1166681146.32180.12.camel@cutter> Message-ID: <20061221061618.GL2297@polop.usc.edu> On Thu, Dec 21, 2006 at 01:05:46AM -0500, seth vidal alleged: > On Wed, 2006-12-20 at 22:02 -0800, Garrick Staples wrote: > > On Thu, Dec 21, 2006 at 12:52:58AM -0500, Bill Nottingham alleged: > > > Callum Lerwick (seg at haxxed.com) said: > > > > On Wed, 2006-12-20 at 22:30 -0500, Matthias Clasen wrote: > > > > > While we are talking about bugs and daemons, can we maybe rewrite > > > > > yum-updatesd in a language that makes it use less than 10MB ? It is by > > > > > far the biggest of the useless daemons... > > > > > > > > Why is it even a resident daemon? > > > > > > It's used by the update applet - the applet queries it for available > > > updates, and by having the daemon resident, it saves bloat and slowness > > > in the applet. (Basically, the same code would have to be in one > > > place or the other...) > > > > Then how about it doesn't launch until the applet is launched (maybe > > through dbus?) > > so it launches as the user? Can't we get a root process running from the system dbus in response to a user applet running? -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Thu Dec 21 06:22:36 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 20 Dec 2006 22:22:36 -0800 Subject: FC7 plan comments In-Reply-To: <20061221055258.GA19735@nostromo.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> <20061221055258.GA19735@nostromo.devel.redhat.com> Message-ID: <1166682156.26878.23.camel@localhost.localdomain> On Thu, 2006-12-21 at 00:52 -0500, Bill Nottingham wrote: > Callum Lerwick (seg at haxxed.com) said: > > On Wed, 2006-12-20 at 22:30 -0500, Matthias Clasen wrote: > > > While we are talking about bugs and daemons, can we maybe rewrite > > > yum-updatesd in a language that makes it use less than 10MB ? It is by > > > far the biggest of the useless daemons... > > > > Why is it even a resident daemon? > > It's used by the update applet - the applet queries it for available > updates, and by having the daemon resident, it saves bloat and slowness > in the applet. (Basically, the same code would have to be in one > place or the other...) What state does the daemon keep in memory in between talking to the applet that makes it useful as a daemon ? The whole mechanism is still pull based. Why doesn't something like the following work: * cron runs yum-update-check (which does essentially what the daemon does now) every N hours and leaves files with info about update state behind * applet looks at files to determine what needs to be done I am sure there is a variation on this that uses dbus for the communication from the cronjob to the applet (which could be as simple as 'applet check the files') David From skvidal at linux.duke.edu Thu Dec 21 06:42:50 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 21 Dec 2006 01:42:50 -0500 Subject: FC7 plan comments In-Reply-To: <1166682156.26878.23.camel@localhost.localdomain> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> <20061221055258.GA19735@nostromo.devel.redhat.com> <1166682156.26878.23.camel@localhost.localdomain> Message-ID: <1166683370.32180.35.camel@cutter> On Wed, 2006-12-20 at 22:22 -0800, David Lutterkort wrote: > On Thu, 2006-12-21 at 00:52 -0500, Bill Nottingham wrote: > > Callum Lerwick (seg at haxxed.com) said: > > > On Wed, 2006-12-20 at 22:30 -0500, Matthias Clasen wrote: > > > > While we are talking about bugs and daemons, can we maybe rewrite > > > > yum-updatesd in a language that makes it use less than 10MB ? It is by > > > > far the biggest of the useless daemons... > > > > > > Why is it even a resident daemon? > > > > It's used by the update applet - the applet queries it for available > > updates, and by having the daemon resident, it saves bloat and slowness > > in the applet. (Basically, the same code would have to be in one > > place or the other...) > > What state does the daemon keep in memory in between talking to the > applet that makes it useful as a daemon ? The whole mechanism is still > pull based. Why doesn't something like the following work: > * cron runs yum-update-check (which does essentially what the > daemon does now) every N hours and leaves files with info about > update state behind > * applet looks at files to determine what needs to be done > > I am sure there is a variation on this that uses dbus for the > communication from the cronjob to the applet (which could be as simple > as 'applet check the files') > 1. anacron isn't required by anything and relying on it is not the wisest of choices from what I've experienced 2. spawning something from cron every N hours implies a lot about the system being on and how often. Having a daemon that runs whenever it is awake lessens that problem. I don't generally run yum-updatesd b/c I like to play with yum stuff a bit and they can get in each other's way. However, when it has checked for updates it appears to have a size of about 35M virt and 22M res. That's with extras, core, updates and livna repos. When I run 'yum shell' and get it to list available packages it comes out to be much the same size. I'm sure there are places to save memory and we're working on some of them but I don't think translating the daemon into another language will really aid in that. -sv From skvidal at linux.duke.edu Thu Dec 21 06:43:21 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 21 Dec 2006 01:43:21 -0500 Subject: FC7 plan comments In-Reply-To: <20061221061618.GL2297@polop.usc.edu> References: <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> <20061221055258.GA19735@nostromo.devel.redhat.com> <20061221060219.GK2297@polop.usc.edu> <1166681146.32180.12.camel@cutter> <20061221061618.GL2297@polop.usc.edu> Message-ID: <1166683401.32180.37.camel@cutter> On Wed, 2006-12-20 at 22:16 -0800, Garrick Staples wrote: > Can't we get a root process running from the system dbus in response to > a user applet running? > I don't think we'd want to do that. If only b/c of multiuser systems. -sv From rdieter at math.unl.edu Thu Dec 21 13:58:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 07:58:20 -0600 Subject: gtk2 create/maintain icon cache (bug #170335) In-Reply-To: <1166558763.7685.7.camel@golem.boston.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <1166558763.7685.7.camel@golem.boston.devel.redhat.com> Message-ID: <458A92FC.7020803@math.unl.edu> Matthias Clasen wrote: > I have proposed a solution in the bug. But instead of working on that, > people preferred to opt for the magical xdg bullet... Your suggestion was a good one (thanks), but it appears that relying 100% on %posttrans isn't a reliable (or ideal) option either (see also fedora-packagers list for another thread on that). So, here are the questions that remain to be answered: 0 (premise) Relying solely upon rpm scriptlet hooks to keep icon cache fresh is problematic (all it takes is one package/instance of not calling gtk2-update-icon-cache) and inefficient. Agree/disagree? 1. gtk2 should include a %post scriptlet to (re)generate (possibly missing) initial icon cache. Agree/disagree? 2. gtk2 should include some mechanism to keep cache fresh. Agree/disagree? 0. Can be addressed by updating packaging guidelines to not mandate gtk2-update-icon-cache in scriptlets. I hope we can all agree at this point there are better ways of doing it. 1. Easy, should (imo) be a no-brainer to include in gtk2 package. 2. My proposed cron job is one way to address this, but many folks seem to cringe at that suggestion. Fine, come up with something better. -- Rex From rc040203 at freenet.de Thu Dec 21 16:14:06 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 21 Dec 2006 17:14:06 +0100 Subject: icon cache scriplet guideline update In-Reply-To: <20061219200856.GA28922@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> <45883624.5080801@math.unl.edu> <20061219190234.GA28007@nostromo.devel.redhat.com> <1166557590.8099.17.camel@mccallum> <20061219200856.GA28922@nostromo.devel.redhat.com> Message-ID: <1166717646.5079.10.camel@mccallum.corsepiu.local> On Tue, 2006-12-19 at 15:08 -0500, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > > How is replacing a call to a binary with a 837 line shell script > > > (that will then call the binary) an improvement? > > > > It's called abstraction and encapsulation. > > It's also called 'slow and useless like libtool'. Pardon, I am well aware about RH living on an "isolated island" and not caring much about the world out side of RH :( Ralf From rdieter at math.unl.edu Thu Dec 21 16:27:02 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 10:27:02 -0600 Subject: stop the madness In-Reply-To: <1166717646.5079.10.camel@mccallum.corsepiu.local> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> <45883624.5080801@math.unl.edu> <20061219190234.GA28007@nostromo.devel.redhat.com> <1166557590.8099.17.camel@mccallum> <20061219200856.GA28922@nostromo.devel.redhat.com> <1166717646.5079.10.camel@mccallum.corsepiu.local> Message-ID: <458AB5D6.8080006@math.unl.edu> Ralf Corsepius wrote: > On Tue, 2006-12-19 at 15:08 -0500, Bill Nottingham wrote: >>>> How is replacing a call to a binary with a 837 line shell script >>>> (that will then call the binary) an improvement? >>> It's called abstraction and encapsulation. >> It's also called 'slow and useless like libtool'. > Pardon, I am well aware about RH living on an "isolated island" and not > caring much about the world out side of RH :( Bill, I think you chose the wrong example to support your case. (: Ralf has a point, we all need to realize that we are on the same side here. There is a growing perception (valid or not, doesn't matter) that some (Core/rh) folks are thumbing their noses and/or slighting the significance of community-participatory groups, such as FESCo and the Packaging Committee. Such nonsense needs to stop. -- Rex From notting at redhat.com Thu Dec 21 16:42:03 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Dec 2006 11:42:03 -0500 Subject: stop the madness In-Reply-To: <458AB5D6.8080006@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> <45883624.5080801@math.unl.edu> <20061219190234.GA28007@nostromo.devel.redhat.com> <1166557590.8099.17.camel@mccallum> <20061219200856.GA28922@nostromo.devel.redhat.com> <1166717646.5079.10.camel@mccallum.corsepiu.local> <458AB5D6.8080006@math.unl.edu> Message-ID: <20061221164203.GB24540@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > Bill, I think you chose the wrong example to support your case. (: > > Ralf has a point, we all need to realize that we are on the same side > here. There is a growing perception (valid or not, doesn't matter) that > some (Core/rh) folks are thumbing their noses and/or slighting the > significance of community-participatory groups, such as FESCo and the > Packaging Committee. Such nonsense needs to stop. It's not a matter of the committee, it's the matter of the standard, A standard that that simply replaces two-lines XY with line A, that is slower, and only now has benefits in 'making something look agnostic', isn't something we should be worrying about, in my opinion. Bill From rdieter at math.unl.edu Thu Dec 21 16:49:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 21 Dec 2006 10:49:21 -0600 Subject: stop the madness In-Reply-To: <20061221164203.GB24540@nostromo.devel.redhat.com> References: <45882D48.7080509@math.unl.edu> <200612191345.36090.ndbecker2@gmail.com> <45883624.5080801@math.unl.edu> <20061219190234.GA28007@nostromo.devel.redhat.com> <1166557590.8099.17.camel@mccallum> <20061219200856.GA28922@nostromo.devel.redhat.com> <1166717646.5079.10.camel@mccallum.corsepiu.local> <458AB5D6.8080006@math.unl.edu> <20061221164203.GB24540@nostromo.devel.redhat.com> Message-ID: <458ABB11.9010103@math.unl.edu> Bill Nottingham wrote: > It's not a matter of the committee, it's the matter of the standard, > A standard that that simply replaces two-lines XY with line A, that > is slower, and only now has benefits in 'making something look agnostic', > isn't something we should be worrying about, in my opinion. Agreed, in general, though there's more to it than that. FYI, iconcache proposal was NACK'd/withdrawn, and updated accordingly pending further discussion/feedback, http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache -- Rex From dominik at greysector.net Thu Dec 21 21:14:56 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 21 Dec 2006 22:14:56 +0100 Subject: gtk2 create/maintain icon cache (bug #170335) In-Reply-To: <458A92FC.7020803@math.unl.edu> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <1166558763.7685.7.camel@golem.boston.devel.redhat.com> <458A92FC.7020803@math.unl.edu> Message-ID: <20061221211456.GA22133@ryvius.pekin.waw.pl> On Thursday, 21 December 2006 at 14:58, Rex Dieter wrote: > Matthias Clasen wrote: > > >I have proposed a solution in the bug. But instead of working on that, > >people preferred to opt for the magical xdg bullet... > > Your suggestion was a good one (thanks), but it appears that relying > 100% on %posttrans isn't a reliable (or ideal) option either (see also > fedora-packagers list for another thread on that). > > So, here are the questions that remain to be answered: > > 0 (premise) Relying solely upon rpm scriptlet hooks to keep icon cache > fresh is problematic (all it takes is one package/instance of not > calling gtk2-update-icon-cache) and inefficient. Agree/disagree? +1 > 1. gtk2 should include a %post scriptlet to (re)generate (possibly > missing) initial icon cache. Agree/disagree? +1 > 2. gtk2 should include some mechanism to keep cache fresh. Agree/disagree? 0 > 0. Can be addressed by updating packaging guidelines to not mandate > gtk2-update-icon-cache in scriptlets. I hope we can all agree at this > point there are better ways of doing it. > > 1. Easy, should (imo) be a no-brainer to include in gtk2 package. > > 2. My proposed cron job is one way to address this, but many folks seem > to cringe at that suggestion. Fine, come up with something better. I'll admit I know nothing about GTK, but couldn't this be done on-demand? I assume that when an application needs to display some icon, it calls some GTK function to do that. Couldn't this function check if the icon cache is old enough to rebuild it if the icons directory has been updated? 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 a.badger at gmail.com Thu Dec 21 22:23:01 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 Dec 2006 14:23:01 -0800 Subject: gtk2 create/maintain icon cache (bug #170335) In-Reply-To: <20061221211456.GA22133@ryvius.pekin.waw.pl> References: <45882D48.7080509@math.unl.edu> <1166556192.15528.6.camel@golem.boston.devel.redhat.com> <4588419C.3070008@math.unl.edu> <1166558763.7685.7.camel@golem.boston.devel.redhat.com> <458A92FC.7020803@math.unl.edu> <20061221211456.GA22133@ryvius.pekin.waw.pl> Message-ID: <1166739781.21769.164.camel@localhost.localdomain> On Thu, 2006-12-21 at 22:14 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 21 December 2006 at 14:58, Rex Dieter wrote: > > 2. My proposed cron job is one way to address this, but many folks seem > > to cringe at that suggestion. Fine, come up with something better. > > I'll admit I know nothing about GTK, but couldn't this be done on-demand? > I assume that when an application needs to display some icon, it calls some > GTK function to do that. Couldn't this function check if the icon cache is > old enough to rebuild it if the icons directory has been updated? Only sort of. The iconcache is owned by root so a normal user running a gtk app can't directly modify it. I don't believe that gtk has a per user cache but even if someone codes that, it would be wasteful (the icons are a system resource so each user would end up with copies of the same cache). -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 jspaleta at gmail.com Thu Dec 21 23:17:01 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 21 Dec 2006 14:17:01 -0900 Subject: Packaging committee report 2006-12-19 In-Reply-To: References: <200612191500.34451.jkeating@redhat.com> Message-ID: <604aa7910612211517q5936fa47i3eaf0834441e5f5f@mail.gmail.com> On 12/19/06, Christopher Stone wrote: > Oh it may work, but the probability of it working 100% correctly > diminishes pretty dramatically I would assume. Personally I think it > is a bad idea and we should always encourage people to upgrade one > distro release at a time. There is a whole spectrum of options inside the word encourage. And surely there are a number of ways to actively encourage people to upgrade on each available release..without actively discouraging people who feel the need to holdback. I only personally encourage people to do fresh installs, but people aren't always prepared for that. Making it possible to skip a release is not necessarily encouraging people do it. People already are waiting to skip a release, for their own reasons, regardless of the current update support policy. Similarly there are nutjobs out there who try to skip two releases or more. I don't think shifting the support lifetimes is going to re-classify who is and who is not a nutjob. Hopefully the leadership in the new fedora-testing initiative will have some bright ideas on how to better organize regression testing for upgrades so that upgrades can be percieved as a more reliable process than it currently is, even from release to release without skipping. -jef From seg at haxxed.com Fri Dec 22 01:11:52 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 21 Dec 2006 19:11:52 -0600 Subject: FC7 plan comments In-Reply-To: <20061221055258.GA19735@nostromo.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <1166642730.6458.8.camel@perun.kabelta.loc> <20061220193525.GB7631@devserv.devel.redhat.com> <20061221011309.GQ3248@redhat.com> <1166670811.10717.68.camel@aglarond.local> <1166671809.4476.1.camel@localhost.localdomain> <1166679909.11691.3.camel@localhost.localdomain> <20061221055258.GA19735@nostromo.devel.redhat.com> Message-ID: <1166749914.2459.10.camel@localhost.localdomain> On Thu, 2006-12-21 at 00:52 -0500, Bill Nottingham wrote: > It's used by the update applet - the applet queries it for available > updates, and by having the daemon resident, it saves bloat and slowness > in the applet. (Basically, the same code would have to be in one > place or the other...) I thought one of the main reasons for dbus to exist is so rootspace can broadcast messages to GUI sessions, rather than having to go the other way. The update agent is run by a cron job, emits a dbus message, and terminates. Or, it just writes to a status file. The applet uses the magic of inotify to be notified of changes. Files are good. Everything is a file. This way also makes the status persist on the filesystem rather than in RAM via a heavyweight daemon. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Sat Dec 23 09:53:09 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 23 Dec 2006 04:53:09 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-23 Message-ID: <20061223095309.D152115212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) andreas.bierfert AT lowlatency.de: wine-docs FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) ryo-dairiki AT users.sourceforge.net: libtomoe-gtk FE6 > FE7 (0:0.4.0-1.fc6 > 0:0.1.0-7.fc6) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) wtogami AT redhat.com: thunderbird FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.9-2.fc6 > 0:1.5.0.7-5.fc7) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) libtomoe-gtk: ryo-dairiki AT users.sourceforge.net FE6 > FE7 (0:0.4.0-1.fc6 > 0:0.1.0-7.fc6) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) thunderbird: wtogami AT redhat.com FC5-updates > FC7 (0:1.5.0.8-1.fc5 > 0:1.5.0.7-5.fc7) FC6-updates > FC7 (0:1.5.0.9-2.fc6 > 0:1.5.0.7-5.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) wine-docs: andreas.bierfert AT lowlatency.de FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From chris.stone at gmail.com Sat Dec 23 18:43:11 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 23 Dec 2006 10:43:11 -0800 Subject: FC7 plan comments In-Reply-To: <20061219213825.GC11828@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061219213825.GC11828@redhat.com> Message-ID: On 12/19/06, John W. Linville wrote: > On Tue, Dec 19, 2006 at 12:41:18PM -0800, Christopher Stone wrote: > > On 12/19/06, Jeff Garzik wrote: > > > > > >Comments on the FC7 draft plan: > > > > > >8. Rock Solid Wireless > > > > > >I would ping John Linville too. He already makes kernel RPMs with > > >enhanced wireless based on his upstream maintainership work. > > > > Indeed. My wireless card actually crashes the kernel. I've been > > meaning to test John's kernel here: > > http://people.redhat.com/linville/kernels/fc6/ which supposedly fixes > > this. > > Hmmmm...well, I hope so. Let me know if that is less than > satisfactory... :-) I installed your kernel and ran modprobe bcm43xx with whatever drivers I had originally installed and this worked, but I could not get my wireless card to work. I then rebooted into the normal kernel and tried modprobe bcm43xx again to see if it still crashed the kernel, but it actually worked. I then tried rmmod bcm43xx, installing a new firmware with fwcutter and then modprobe again but this time it crashed the kernel. I then started noticing that when I rebooted, the kernel is no longer recognizing my usb ports on my monitor. I rebooted into your kernel again and retested the modprobing stuff and it all seemed to work, but I could not get the wireless card to work. I'm afraid I am just not cut out for this kind of testing. I now have four useless usb ports on my monitor that used to work before all this, and that's why I hate testing this kind of stuff. I'm sorry I could not be of more help. About the only thing I can tell you is that I could not get the kernel to crash with your kernel, and I could get the current kernel to crash, and my usb ports on my monitor no longer work because of it. :( -Chris From peter at thecodergeek.com Sat Dec 23 19:51:30 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 23 Dec 2006 11:51:30 -0800 Subject: Offline: 2006-12-23 Through 2007-01-01 In-Reply-To: <1166396534.8636.59.camel@localhost> References: <1166396534.8636.59.camel@localhost> Message-ID: <1166903490.3367.3.camel@localhost> On Sun, 2006-12-17 at 15:02 -0800, I wrote: > * scribes and scribes-templates > This is quiet for now, but development will pickup again soon. Many of > us are experiencing seemingly random errors whereby the .scribesclient > script hangs and causes a processor-intensive zombie task; and work is > underway to triage this (as it is a very big pain in butt). However, it > is very difficult to reproduce; and thus difficult to debug as well > (tracking in upstream SourceForge bug #1617598). This is fixed with the recent BZR snapshot I pushed as an update. Yay! I'm leaving for the airport in a couple of hours and need to finish packing and whatnot, so this will likely be my last post until I return. Happy Holidays and a Joyous New Year to everyone! :] -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Sun Dec 24 18:38:14 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 24 Dec 2006 19:38:14 +0100 Subject: FC7 plan comments In-Reply-To: <1166649818.10717.60.camel@aglarond.local> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> <20061220222017.4a08a4d1@nausicaa.camperquake.de> <1166649818.10717.60.camel@aglarond.local> Message-ID: <20061224193814.6fb18ed3@nausicaa.camperquake.de> Hi. Jeremy Katz wrote: > Encrypting data? Very interesting. > Encrypting the OS bits that anyone can download? Much less interesting, > IMHO Encrypting data. And, just to make sure I did not forget anything important, I encrypt all partitions that are later used to create PVs. -- "Never explain... your friends do not need it and your enemies will not believe you anyway." -- Elbert G. Hubbard From dennis at ausil.us Tue Dec 26 19:16:07 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 26 Dec 2006 13:16:07 -0600 Subject: Extras Buildsys Message-ID: <200612261316.07584.dennis@ausil.us> Hey all, Just a reminder that on Monday January 1 2007 the buildsys will no longer accept jobs for FC-3 and FC-4. at that point repomanage will be run to prune the tree to only the latest package. If you have anything you wish to fix before hand please do so this week as it will be your last opportunity to do so. -- ?,-._|\ ? ?Dennis Gilmore, RHCE / ? ? ?\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From quintela at redhat.com Wed Dec 27 02:43:37 2006 From: quintela at redhat.com (Juan Quintela) Date: Wed, 27 Dec 2006 03:43:37 +0100 Subject: Package EVR problems in FC+FE 2006-12-23 In-Reply-To: <20061223095309.D152115212E@buildsys.fedoraproject.org> References: <20061223095309.D152115212E@buildsys.fedoraproject.org> Message-ID: <1167187417.22076.2.camel@anano.mitica> On Sat, 2006-12-23 at 04:53 -0500, buildsys at fedoraproject.org wrote: > > xen > FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) THere is a 3.0.3-2.fc5 & 3.0.3-1.fc6 on updates candidates. But I have no clue who to convince to let them going to updates. They should have gone with previous kernel update. Later, Juan. PD. Yes, I realized that it was going to be a bad idea to do the update myself. PD2: No, I have no interest in being the owner :) Enough work already. From ville.skytta at iki.fi Wed Dec 27 18:32:00 2006 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 27 Dec 2006 20:32:00 +0200 Subject: Package EVR problems in FC+FE 2006-12-23 In-Reply-To: <1167187417.22076.2.camel@anano.mitica> References: <20061223095309.D152115212E@buildsys.fedoraproject.org> <1167187417.22076.2.camel@anano.mitica> Message-ID: <200612272032.00406.ville.skytta@iki.fi> On Wednesday 27 December 2006 04:43, Juan Quintela wrote: > On Sat, 2006-12-23 at 04:53 -0500, buildsys at fedoraproject.org wrote: > > xen > > FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) > > THere is a 3.0.3-2.fc5 & 3.0.3-1.fc6 on updates candidates. Won't that just shift the problem? Both at 3.0.3 but 2.fc5 > 1.fc6. From buildsys at fedoraproject.org Wed Dec 27 19:09:54 2006 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Dec 2006 14:09:54 -0500 (EST) Subject: Package EVR problems in FC+FE 2006-12-27 Message-ID: <20061227190954.1E0A015212E@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): autofs FC6-updates > FC7 (1:5.0.1-0.rc2.40 > 1:5.0.1-0.rc2.38) dbus FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) iscsi-initiator-utils FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2 FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mozilla FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) nfs-utils FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) xen FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) andreas.bierfert AT lowlatency.de: wine-docs FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) braden AT endoframe.com: openvrml FE6 > FE7 (0:0.16.2-3.fc6 > 0:0.16.2-2.fc7) cgoorah AT yahoo.com.au: ngspice FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) toped FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) chabotc AT xs4all.nl: buoh FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) dwmw2 AT redhat.com: mISDN FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) openpbx FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) enrico.scholz AT informatik.tu-chemnitz.de: clamav FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) xmlrpc-c FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) fedora AT theholbrooks.org: php-json FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) foolish AT guezz.net: muine FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) icon AT fedoraproject.org: yaz FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: gtkmozembedmm FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) petersen AT redhat.com: gtk2hs FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) ryo-dairiki AT users.sourceforge.net: scim-tomoe FE4 > FE5 (0:0.4.0-1.fc4 > 0:0.2.0-6.fc5.1) scott AT perturb.org: dstat FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) skvidal AT phy.duke.edu: seahorse FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) zcerza AT redhat.com: dogtail FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) ---------------------------------------------------------------------- autofs: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:5.0.1-0.rc2.40 > 1:5.0.1-0.rc2.38) buoh: chabotc AT xs4all.nl FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-2) clamav: enrico.scholz AT informatik.tu-chemnitz.de FE3 > FE7 (0:0.88.7-1.fc3 > 0:0.88.6-1.fc7) FE4 > FE7 (0:0.88.7-1.fc4 > 0:0.88.6-1.fc7) FE5 > FE7 (0:0.88.7-1.fc5 > 0:0.88.6-1.fc7) FE6 > FE7 (0:0.88.7-1.fc6 > 0:0.88.6-1.fc7) dbus: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.0.1-8.fc6 > 0:1.0.1-3.fc7) device-mapper: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:1.02.07-2.0 > 0:1.02.02-3.2) dogtail: zcerza AT redhat.com FC6-updates > FC7 (0:0.6.1-1.fc6 > 0:0.6.0-2.fc7) dstat: scott AT perturb.org FE5 > FE7 (0:0.6.4-1.fc5 > 0:0.6.3-5.fc6) FE6 > FE7 (0:0.6.4-1.fc6 > 0:0.6.3-5.fc6) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.2-2.fc5 > 0:0.2.1-3.fc6) gtk2hs: petersen AT redhat.com FE6 > FE7 (0:0.9.10.2-0.1.fc6 > 0:0.9.10-4.fc6) gtkmozembedmm: karlthered AT gmail.com FE6 > FE7 (0:1.4.2.cvs20060817-7.fc6 > 0:1.4.2.cvs20060817-5.fc7) iscsi-initiator-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:6.2.0.747-0.0.fc6 > 0:6.2.0.695-0.7) kdeedu: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:3.5.5-0.1.fc5 > 0:3.5.4-2.fc7) FC6-updates > FC7 (0:3.5.5-0.1.fc6 > 0:3.5.4-2.fc7) lvm2: UNKNOWN OWNER (possibly Core package) FC4-updates > FC5 (0:2.02.06-1.0.fc4 > 0:2.02.01-1.2.1) mISDN: dwmw2 AT redhat.com FE6 > FE7 (0:1.0.3-1.fc6 > 0:1.0.3-1) mozilla: UNKNOWN OWNER (possibly Core package) FL3-updates > FC4-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc4) FL3-updates > FC5-updates (37:1.7.13-1.3.1.legacy > 37:1.7.13-1.1.fc5) muine: foolish AT guezz.net FE5 > FE7 (0:0.8.6-1.fc5 > 0:0.8.5-7.fc6) FE6 > FE7 (0:0.8.6-1.fc6 > 0:0.8.5-7.fc6) nfs-utils: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (1:1.0.10-5.fc6 > 1:1.0.10-4.fc7) ngspice: cgoorah AT yahoo.com.au FE5 > FE7 (0:17-8.fc5 > 0:17-7.fc6) FE6 > FE7 (0:17-8.fc6 > 0:17-7.fc6) openpbx: dwmw2 AT redhat.com FE6 > FE7 (0:1.2-3.rc2.svn2282.fc6 > 0:1.2-3.rc2.svn2135.fc7) openvrml: braden AT endoframe.com FE6 > FE7 (0:0.16.2-3.fc6 > 0:0.16.2-2.fc7) php-json: fedora AT theholbrooks.org FE6 > FE7 (0:1.2.1-5.fc6 > 0:1.2.1-3.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.1-4.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.1-4.fc6 > 0:2.5.1-3.fc7) scim-tomoe: ryo-dairiki AT users.sourceforge.net FE4 > FE5 (0:0.4.0-1.fc4 > 0:0.2.0-6.fc5.1) seahorse: skvidal AT phy.duke.edu FE6 > FE7 (0:0.8.2-1.fc6 > 0:0.8.1-2.fc6) toped: cgoorah AT yahoo.com.au FE6 > FE7 (0:0.8.2-6.fc6 > 0:0.8.2-2.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-1.fc6 > 0:0.30.211-1.fc6) wine-docs: andreas.bierfert AT lowlatency.de FE3 > FE4 (0:0.9.27-1.fc3 > 0:0.9.24-1.fc4) xen: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6 (0:3.0.3-1.fc5 > 0:3.0.3-0.1.rc3) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) xmlrpc-c: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:1.06.06-1.fc5 > 0:1.06.05-3.fc7) FE6 > FE7 (0:1.06.06-1.fc6 > 0:1.06.05-3.fc7) yaz: icon AT fedoraproject.org FE5 > FE7 (0:2.1.40-1.fc5 > 0:2.1.26-1.1.fc6) FE6 > FE7 (0:2.1.40-1.fc6 > 0:2.1.26-1.1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.5-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.5-1.fc6 > 0:2.9.4-2.fc6) From ikent at redhat.com Thu Dec 28 06:33:22 2006 From: ikent at redhat.com (Ian Kent) Date: Thu, 28 Dec 2006 15:33:22 +0900 Subject: Package EVR problems in FC+FE 2006-12-27 In-Reply-To: <20061227190954.1E0A015212E@buildsys.fedoraproject.org> References: <20061227190954.1E0A015212E@buildsys.fedoraproject.org> Message-ID: <1167287602.3560.38.camel@raven.themaw.net> On Wed, 2006-12-27 at 14:09 -0500, buildsys at fedoraproject.org wrote: > UNKNOWN OWNER (possibly Core package): > autofs > FC6-updates > FC7 (1:5.0.1-0.rc2.40 > 1:5.0.1-0.rc2.38) > What is the point of this script? What if I've had some updates in fc7 and now want to merge them into the fc6 package but don't have a need to update fc7 with anything new. I have to tag with a different revision. In any case the report isn't correct. [raven at raven devel]$ brew latest-pkg dist-fc7 autofs Build Tag Built by ---------------------------------------- -------------------- ---------------- autofs-5.0.1-0.rc2.41 dist-fc7 ikent Ian From tibbs at math.uh.edu Thu Dec 28 06:48:52 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Dec 2006 00:48:52 -0600 Subject: Package EVR problems in FC+FE 2006-12-27 In-Reply-To: <1167287602.3560.38.camel@raven.themaw.net> References: <20061227190954.1E0A015212E@buildsys.fedoraproject.org> <1167287602.3560.38.camel@raven.themaw.net> Message-ID: >>>>> "IK" == Ian Kent writes: IK> What is the point of this script? It indicates problems in ordering; if the package in a newer repository has a E-V-R that places it lower in the ordering than the version of that package in an older repository, upgrades from one Fedora release to another will be broken. IK> In any case the report isn't correct. It is certainly correct with what's actually in the repository. autofs-5.0.1-0.rc2.38.src.rpm is what's in rawhide currently. IK> [raven at raven devel]$ brew latest-pkg dist-fc7 autofs I don't think that has any relevance or meaning to anyone outside of Red Hat, unfortunately. Perhaps that version didn't actually get pushed out? - J< From fedora at leemhuis.info Fri Dec 29 14:00:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 29 Dec 2006 15:00:02 +0100 Subject: Summary from yesterdays (mini) FESCo meeting Message-ID: <45951F62.4020302@leemhuis.info> Hi all! Mroe detailed variant of the summary and the full log can be found at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061228 Note: due to the holiday season is was expected that probably only small number of people could participate. FESCo nevertheless choose to run a small and meeting without actually voting on anything. == Summary == === Minimal approve messages === Background: Some packages ( krename: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220210 and pyfribidi: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219071 ) were not branched by our human cvs guards because it was unclear if a full review had beed done for them -- at branch request time there was only a small note "APPROVED" in a comment of thereview bugs without details what things had been checked * dgilmore: the reason i refused to branch those two packages was that the review just said i approve this; [...] i had no way to know if any checking or anything was done * tibbs: I agree that minimal reviews are bad (although they used to be more common) but I'm not sure the two in question were minimal. * thl: I'm wondering if we should add a rule like "the review has to at least mention 8 points he checked when approving a package" The decision went towards a proposed new rule: "the reviewer has to at least mention that he checked the license, if the sources match upstream and 5 other points he checked when approving a package". Dgilmore will post to f-e-l about this whole thing in more detail and start a public discussion before FESCo discusses this further. Site note: the packages will probably get branched now, but the general problem remains. === How to get something realized in Extras === thl wrote http://www.fedoraproject.org/wiki/Extras/Schedule/HowToGetSomethingRealized , tibbs improved it slightly -- FESCO members that were around liked it, Will get posted to f-e-l for further comments. === free discussion around Extras === * there are still so many broken deps -> seems the ones that are left need real work. * XulChris: "is a dist tag of fc#.foo okay for 3rd party repos?" Some disussions around this, the general consensus was "yes". XulChris will probably make a wiki page for guidelines (no rules -- people don't have to follow it, but they can if they want) on setting up a 3rd party repo and what dist-tag to use. EOF CU thl From ville.skytta at iki.fi Fri Dec 29 15:36:11 2006 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 29 Dec 2006 17:36:11 +0200 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <45951F62.4020302@leemhuis.info> References: <45951F62.4020302@leemhuis.info> Message-ID: <200612291736.11510.ville.skytta@iki.fi> On Friday 29 December 2006 16:00, Thorsten Leemhuis wrote: > > The decision went towards a proposed new rule: "the reviewer has to at > least mention that he checked the license, if the sources match upstream > and 5 other points he checked when approving a package". I don't think this makes much sense. How many points does the one then subsequently reviewing that the package was reviewed properly have to add? Who verifies that the reviewer of the review of the package did his job thoroughly enough? Etc. > Site note: the packages will probably get branched now, but the general > problem remains. If the problem is bad reviews, then the bar for reviewers needs to be raised. IMO requiring people to post some amount of (probably copy-pasteable) comments is not the correct fix. From pertusus at free.fr Fri Dec 29 16:05:34 2006 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 29 Dec 2006 17:05:34 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <45951F62.4020302@leemhuis.info> References: <45951F62.4020302@leemhuis.info> Message-ID: <20061229160534.GD2585@free.fr> On Fri, Dec 29, 2006 at 03:00:02PM +0100, Thorsten Leemhuis wrote: > > The decision went towards a proposed new rule: "the reviewer has to at > least mention that he checked the license, if the sources match upstream > and 5 other points he checked when approving a package". Dgilmore will I think that a mention of the license check, and of the upstream source match (with a md5sum if possible or a comment if things are non standard) should be mandatory, but nothing more. For simple review other checks are not really usefull, so mandating them isn't a good idea in my opinion. Adding all the points that were checked should be encouraged, though, it helps in my opinion. -- Pat From bugs.michael at gmx.net Fri Dec 29 16:10:24 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Dec 2006 17:10:24 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <45951F62.4020302@leemhuis.info> References: <45951F62.4020302@leemhuis.info> Message-ID: <20061229171024.ec5430dc.bugs.michael@gmx.net> On Fri, 29 Dec 2006 15:00:02 +0100, Thorsten Leemhuis wrote: > === Minimal approve messages === > > Background: Some packages ( krename: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220210 and > pyfribidi: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219071 > ) were not branched by our human cvs guards because it was unclear if a > full review had beed done for them -- at branch request time there was > only a small note "APPROVED" in a comment of thereview bugs without > details what things had been checked Any more formalism and bureaucracy will drive away reviewers. I think we've agreed on that long ago. I'm surprised this topic has returned. > * dgilmore: the reason i refused to branch those two packages was that > the review just said i approve this; [...] i had no way to know if any > checking or anything was done To which detail would you verify a detailed list of things the reviewer claims he has checked? All that matters is to know who approved a package. Then you know who to talk to if it turns out the packaging is unsatisfactory and the review was half-hearted. From tgl at redhat.com Fri Dec 29 16:14:39 2006 From: tgl at redhat.com (Tom Lane) Date: Fri, 29 Dec 2006 11:14:39 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612291736.11510.ville.skytta@iki.fi> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> Message-ID: <2827.1167408879@sss.pgh.pa.us> Ville =?utf-8?q?Skytt=C3=A4?= writes: > On Friday 29 December 2006 16:00, Thorsten Leemhuis wrote: >> The decision went towards a proposed new rule: "the reviewer has to at >> least mention that he checked the license, if the sources match upstream >> and 5 other points he checked when approving a package". > I don't think this makes much sense. How many points does the one then > subsequently reviewing that the package was reviewed properly have to add? I agree that this sounds like pointless pedantry. It would be reasonable to list all these things in the guidelines for reviewers, if they aren't already. But requiring reviewers to (in effect) copy-and-paste the guidelines in every approval message is a waste of storage space and readers' time. regards, tom lane From jkeating at redhat.com Fri Dec 29 16:19:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Dec 2006 11:19:56 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <45951F62.4020302@leemhuis.info> References: <45951F62.4020302@leemhuis.info> Message-ID: <200612291119.57073.jkeating@redhat.com> On Friday 29 December 2006 09:00, Thorsten Leemhuis wrote: > The decision went towards a proposed new rule: "the reviewer has to at > least mention that he checked the license, if the sources match upstream > and 5 other points he checked when approving a package". Dgilmore will > post to f-e-l about this whole thing in more detail and start a public > discussion before FESCo discusses this further. hrm, you must wear at least 5 pieces of flair... Seriously, a rule like this just encourages folks to check 5 things only and move on. If rules were set in place to make 5 specific things mandatory, that's all that will be checked. Lets not give reviewers a shortcut out. I'd be more in favor of a rule that just says "items checked need to be listed out in the review before building of the package will be allowed". Vague enough as to not give reviewers a shortcut. -- 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 Fri Dec 29 16:32:05 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 29 Dec 2006 11:32:05 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612291119.57073.jkeating@redhat.com> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> Message-ID: <1167409925.31528.17.camel@aglarond.local> On Fri, 2006-12-29 at 11:19 -0500, Jesse Keating wrote: > On Friday 29 December 2006 09:00, Thorsten Leemhuis wrote: > > The decision went towards a proposed new rule: "the reviewer has to at > > least mention that he checked the license, if the sources match upstream > > and 5 other points he checked when approving a package". Dgilmore will > > post to f-e-l about this whole thing in more detail and start a public > > discussion before FESCo discusses this further. > > hrm, you must wear at least 5 pieces of flair... Seriously, a rule like this > just encourages folks to check 5 things only and move on. If rules were set > in place to make 5 specific things mandatory, that's all that will be > checked. Lets not give reviewers a shortcut out. I'd be more in favor of a > rule that just says "items checked need to be listed out in the review before > building of the package will be allowed". Vague enough as to not give > reviewers a shortcut. So, you should just copy and paste all of the guidelines into the review? :-) Because the fact that the package follows the guidelines is what is supposed to be checked, not just some subset. A much better check and balance is exactly what happened in this case; dgilmore saw something suspicious and held off on the branch request. The next step would be either just doing just sort of a quick review or asking someone else to do a quick pass with such a review... such random and spot checks of reviews will go a long way towards verification. Jeremy From jkeating at redhat.com Fri Dec 29 16:32:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Dec 2006 11:32:17 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167409925.31528.17.camel@aglarond.local> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167409925.31528.17.camel@aglarond.local> Message-ID: <200612291132.17176.jkeating@redhat.com> On Friday 29 December 2006 11:32, Jeremy Katz wrote: > So, you should just copy and paste all of the guidelines into the > review? :-) ?Because the fact that the package follows the guidelines is > what is supposed to be checked, not just some subset. > > A much better check and balance is exactly what happened in this case; > dgilmore saw something suspicious and held off on the branch request. > The next step would be either just doing just sort of a quick review or > asking someone else to do a quick pass with such a review... such random > and spot checks of reviews will go a long way towards verification. Sure, that's best of all. I didn't make that clear in my 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 bpepple at fedoraproject.org Fri Dec 29 16:33:44 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 29 Dec 2006 11:33:44 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612291119.57073.jkeating@redhat.com> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> Message-ID: <1167410024.15134.3.camel@Chuck> On Fri, 2006-12-29 at 11:19 -0500, Jesse Keating wrote: > I'd be more in favor of a > rule that just says "items checked need to be listed out in the review before > building of the package will be allowed". Vague enough as to not give > reviewers a shortcut. That sounds fine to me. The problem I had was reviewers just putting 'APPROVED' in reviews, and not giving any information on what was actually checked. /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 katzj at redhat.com Fri Dec 29 16:49:34 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 29 Dec 2006 11:49:34 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167410024.15134.3.camel@Chuck> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167410024.15134.3.camel@Chuck> Message-ID: <1167410974.31528.21.camel@aglarond.local> On Fri, 2006-12-29 at 11:33 -0500, Brian Pepple wrote: > On Fri, 2006-12-29 at 11:19 -0500, Jesse Keating wrote: > > I'd be more in favor of a > > rule that just says "items checked need to be listed out in the review before > > building of the package will be allowed". Vague enough as to not give > > reviewers a shortcut. > > That sounds fine to me. The problem I had was reviewers just putting > 'APPROVED' in reviews, and not giving any information on what was > actually checked. But doing this either means that: a) Every review ends up being a copy of the guidelines and thus impossible to easily find the concerns of the reviewers b) Only some of the things which are checked get listed (at which point, we're right back where we are now... they said they checked foo, does that mean they checked bar?) c) Some bits of the guidelines are skipped in favor of just having a few items checked to "appease" Jeremy From bpepple at fedoraproject.org Fri Dec 29 16:50:14 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 29 Dec 2006 11:50:14 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167409925.31528.17.camel@aglarond.local> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167409925.31528.17.camel@aglarond.local> Message-ID: <1167411014.15325.7.camel@Chuck> On Fri, 2006-12-29 at 11:32 -0500, Jeremy Katz wrote: > On Fri, 2006-12-29 at 11:19 -0500, Jesse Keating wrote: > > So, you should just copy and paste all of the guidelines into the > review? :-) Because the fact that the package follows the guidelines is > what is supposed to be checked, not just some subset. > > A much better check and balance is exactly what happened in this case; > dgilmore saw something suspicious and held off on the branch request. > The next step would be either just doing just sort of a quick review or > asking someone else to do a quick pass with such a review... such random > and spot checks of reviews will go a long way towards verification. Aren't we looking at automating branch creation down the road? I seem to remember dgilmore mentioning something about this yesterday. /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 bugs.michael at gmx.net Fri Dec 29 16:57:42 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Dec 2006 17:57:42 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167410024.15134.3.camel@Chuck> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167410024.15134.3.camel@Chuck> Message-ID: <20061229175742.065a45f5.bugs.michael@gmx.net> On Fri, 29 Dec 2006 11:33:44 -0500, Brian Pepple wrote: > On Fri, 2006-12-29 at 11:19 -0500, Jesse Keating wrote: > > I'd be more in favor of a > > rule that just says "items checked need to be listed out in the review before > > building of the package will be allowed". Vague enough as to not give > > reviewers a shortcut. > > That sounds fine to me. The problem I had was reviewers just putting > 'APPROVED' in reviews, and not giving any information on what was > actually checked. It doesn't make sense to create detailed lists. A single "APPROVED" is fine. I've done that multiple times myself, because everything else is too time-consuming. Even my old-style reviews have been inconsistent and misleading to the silent observer, because they never mentioned everything I had checked. I can catch many packaging bugs and pitfalls with the blink of an eye. And at the same speed it is possible to verify many things one must not find in a spec. You don't want to slow-down the possibly experienced reviever and force him to create detailed lists. From jkeating at redhat.com Fri Dec 29 16:53:33 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Dec 2006 11:53:33 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167411014.15325.7.camel@Chuck> References: <45951F62.4020302@leemhuis.info> <1167409925.31528.17.camel@aglarond.local> <1167411014.15325.7.camel@Chuck> Message-ID: <200612291153.33712.jkeating@redhat.com> On Friday 29 December 2006 11:50, Brian Pepple wrote: > Aren't we looking at automating branch creation down the road? ?I seem > to remember dgilmore mentioning something about this yesterday. With the new buildsystem coming, there will need a step to 'add a package to a collection instance' before the package will be allowed to be built. This prevents the problem of "it's in CVS, it can be built" issues. So while branching may happen automatically, an admin will still need to add the package/set the owner before it can build. -- 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 bpepple at fedoraproject.org Fri Dec 29 17:07:30 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 29 Dec 2006 12:07:30 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229175742.065a45f5.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167410024.15134.3.camel@Chuck> <20061229175742.065a45f5.bugs.michael@gmx.net> Message-ID: <1167412050.15325.19.camel@Chuck> On Fri, 2006-12-29 at 17:57 +0100, Michael Schwendt wrote: > On Fri, 29 Dec 2006 11:33:44 -0500, Brian Pepple wrote: > > > > That sounds fine to me. The problem I had was reviewers just putting > > 'APPROVED' in reviews, and not giving any information on what was > > actually checked. > > It doesn't make sense to create detailed lists. A single "APPROVED" is > fine. I've done that multiple times myself, because everything else is too > time-consuming. Even my old-style reviews have been inconsistent and > misleading to the silent observer, because they never mentioned everything > I had checked. I can catch many packaging bugs and pitfalls with the blink > of an eye. And at the same speed it is possible to verify many things one > must not find in a spec. You don't want to slow-down the possibly > experienced reviever and force him to create detailed lists. I agree this would be extra work for the experienced packagers, but maybe we should have an exemption if they are a sponsor. /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 tibbs at math.uh.edu Fri Dec 29 17:24:19 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Dec 2006 11:24:19 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229171024.ec5430dc.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Any more formalism and bureaucracy will drive away reviewers. I MS> think we've agreed on that long ago. I'm surprised this topic has MS> returned. I as well, and I objected to this when it came up. I prefer a much simpler rule: please just tell us what you checked. As the review is permanently kept as evidence, reviewers should not leave things open to question. If you looked at something and found it OK, please indicate that instead of asking others to assume that you checked something and found it not worth commenting on. When reviewing 30 nearly identical Perl or PHP modules, occasionally you just want to say that the last one is just like the other 29, and I think it's feasible to do so. Additional bizarre rules don't really help much. I try to actually read all of the review traffic and point out places where I think things are deficient, but lately I haven't had the time. - J< From jkeating at redhat.com Fri Dec 29 17:29:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 29 Dec 2006 12:29:41 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> Message-ID: <200612291229.41395.jkeating@redhat.com> On Friday 29 December 2006 12:24, Jason L Tibbitts III wrote: > I prefer a much simpler rule: please just tell us what you checked. > As the review is permanently kept as evidence, reviewers should not > leave things open to question. ?If you looked at something and found > it OK, please indicate that instead of asking others to assume that > you checked something and found it not worth commenting on. As its been stated though, you're supposed to check everything, so should we just copy/paste the guidelines into the review bug? -- 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 Fri Dec 29 18:06:32 2006 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 30 Dec 2006 03:06:32 +0900 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> Message-ID: <45955928.6030803@ioa.s.u-tokyo.ac.jp> Jason L Tibbitts III wrote: >>>>>> "MS" == Michael Schwendt writes: > > MS> Any more formalism and bureaucracy will drive away reviewers. I > MS> think we've agreed on that long ago. I'm surprised this topic has > MS> returned. > > I as well, and I objected to this when it came up. > > I prefer a much simpler rule: please just tell us what you checked. However, the issues to be checked is in fact... quite a lot, isn't it? If I have to list all items I have checked, it means that listing items in ReviewGuidelines is not sufficient. In fact ReviewGuidelines says that "The package must meet the Packaging Guidelines" and Packaging Guildlines also has... many check points!! There are many cases that original spec files do not meet the demand of Packaging Guidelines. And.. even in that case I saw some cases that the review commented "* This package meets the Package Guideines" as if all the items in Package Guidelines are checked (I don't intend to criticize anyone by this statement) and I had to re-review the package quickly. And.. in (not a few) case, do I have to list all items like scriptlets, python issues.... so on? In fact I was rather confused when I received a mail with many check lists and I had to ask "So, what is blocking this bug?" I think only mentioning "these issues are bad. Please fix!!" is enough. Mamoru Tasaka From tibbs at math.uh.edu Fri Dec 29 18:27:09 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Dec 2006 12:27:09 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <45955928.6030803@ioa.s.u-tokyo.ac.jp> References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> <45955928.6030803@ioa.s.u-tokyo.ac.jp> Message-ID: >>>>> "MT" == Mamoru Tasaka writes: MT> However, the issues to be checked is in fact... quite a lot, isn't MT> it? It depends on the package. One of those one-file PHP modules requires significantly less checking than a large graphical application. MT> And.. in (not a few) case, do I have to list all items like MT> scriptlets, Why not? Scriptlets are one of the more critical areas where it's quite possible to screw up systems. They always deserve significant scrutiny, and if you checked them, why not say so? MT> python issues.... so on? Well, if you're reviewing a python module, why wouldn't you? But on the other hand, if you're reviewing, say, a Perl module and it's just the specfile template with the necessary details filled in, then it should be reasonable to just say that it follows the template and that you checked that the filled-in details are correct. MT> In fact I was rather confused when I received a mail with many MT> check lists and I had to ask "So, what is blocking this bug?" I always summarize things up front, and clearly mark the places in the checklist which I believe are problematic. If the reviewer of your package did not do that, what's lost by just asking them to do so? MT> I think only mentioning "these issues are bad. Please fix!!" is MT> enough. Isn't it rather obvious from this discussion and the events surrounding it that such a thing is simply not sufficient? - J< From jgarzik at redhat.com Fri Dec 29 19:25:06 2006 From: jgarzik at redhat.com (Jeff Garzik) Date: Fri, 29 Dec 2006 14:25:06 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <45951F62.4020302@leemhuis.info> References: <45951F62.4020302@leemhuis.info> Message-ID: <20061229192506.GB14930@devserv.devel.redhat.com> On Fri, Dec 29, 2006 at 03:00:02PM +0100, Thorsten Leemhuis wrote: > Hi all! > > Mroe detailed variant of the summary and the full log can be found at: > http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20061228 > > Note: due to the holiday season is was expected that probably only small > number of people could participate. FESCo nevertheless choose to run a > small and meeting without actually voting on anything. An issue to /not/ forget: syslog-ng patent problems need examination and avoidance or clearing. http://bazsi.blogspot.com/2006/07/thoughts-on-patent-system.html From seg at haxxed.com Fri Dec 29 20:14:57 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 29 Dec 2006 14:14:57 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <2827.1167408879@sss.pgh.pa.us> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> Message-ID: <1167423298.3762.13.camel@max.booze> On Fri, 2006-12-29 at 11:14 -0500, Tom Lane wrote: > Ville =?utf-8?q?Skytt=C3=A4?= writes: > > On Friday 29 December 2006 16:00, Thorsten Leemhuis wrote: > >> The decision went towards a proposed new rule: "the reviewer has to at > >> least mention that he checked the license, if the sources match upstream > >> and 5 other points he checked when approving a package". > > > I don't think this makes much sense. How many points does the one then > > subsequently reviewing that the package was reviewed properly have to add? > > I agree that this sounds like pointless pedantry. It would be > reasonable to list all these things in the guidelines for reviewers, > if they aren't already. But requiring reviewers to (in effect) > copy-and-paste the guidelines in every approval message is a waste of > storage space and readers' time. On Fri, 2006-12-29 at 17:10 +0100, Michael Schwendt wrote: >Any more formalism and bureaucracy will drive away reviewers. I think > we've agreed on that long ago. I'm surprised this topic has returned. I... am absolutely astounded by all this. For doing reviews, I keep this template in a Tomboy note: MUST items: - rpmlint: - Package name: - Spec name: - Meets packaging guidelines: - License: - Spec in American English: - Spec legible: - Sources match upstream: - Builds: - BuildRequires: - Locales: - ldconfig: - Relocation: - Directory ownership: - %files: - %clean: - Macros: - Code vs. Content: - Documentation: - devel package: - .desktop file: SHOULD: - Includes license text: - Mock build: - Builds on all archs: - Package functional: - Scriptlets: - Subpackages: Which follows the review guidelines pretty closely. When I finalize a review, I just copy and paste this template into a new note, go down the ReviewGuidelines list, and type in an "Ok" or a "NEEDSWORK" for each one. If the time required to copy and paste and type some OK's would add significantly to your workload, I dare say you aren't putting in adequate time, thought and effort into your reviews. -------------- 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 bugs.michael at gmx.net Fri Dec 29 20:30:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Dec 2006 21:30:25 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> Message-ID: <20061229213025.3a7cff12.bugs.michael@gmx.net> On 29 Dec 2006 11:24:19 -0600, Jason L Tibbitts III wrote: > MS> Any more formalism and bureaucracy will drive away reviewers. I > MS> think we've agreed on that long ago. I'm surprised this topic has > MS> returned. > > I as well, and I objected to this when it came up. > > I prefer a much simpler rule: please just tell us what you checked. It is not feasible. Certainly not for me. It is inefficient. Having to document each and every minor detail I perceive while reviewing a package would require using a completely different work-flow. There are countless things that can raise the reviewer's attention in random order while displaying a spec, while perusing patches, while skimming over a test-build log, while listing the binary rpm contents in verbose mode, while looking into the rpms with Midnight Commander and displaying files of interest, while visiting upstream's web site and reading about stable versus development branches, while test-driving the executables (an increasingly popular check is to enter the Help menu and see whether the documentation or online help system works). Not only would it need a huge check-list (perhaps a tree rather than a list, and a single page in a text editor would not be enough) that grows with every package which requires different things to review. A reviewer would also need to document many things that don't apply. It would not result in better initial packages. Rather than requiring reviewers to be pedantic, better encourage packagers to be more verbose in their spec file comments. Or require them to add comments in some cases: Explicit "Requires"? Let the packager add a comment as why they are necessary and why the automatic deps are insufficient. Snapshot instead of stable release? Let the packager add an explanation. Disabled features, non-default configuration options, or probably overlooked feature options? Require the packager to add a comment. > As the review is permanently kept as evidence, reviewers should not > leave things open to question. If you looked at something and found > it OK, please indicate that instead of asking others to assume that > you checked something and found it not worth commenting on. Why? Silent observers are irrelevant. Only if an observer finds something arguable and points it out, it gets interesting. Either the packaging guidelines cover it or not. If all people involved think the package is okay, then fine. Mission accomplished. What are the goals of doing package reviews? Do you want to aim at perfection? Simply assume that it is in the reviewer's best interest to not approve a package that has flaws. Certainly not a package with serious flaws. At the pace some packagers pipe out updates to their packages every few days, there is enough room to fix subtle packaging bugs after the one-time review+approval. To catch the big fish is the point of doing reviews. From Axel.Thimm at ATrpms.net Fri Dec 29 20:41:21 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 29 Dec 2006 21:41:21 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167423298.3762.13.camel@max.booze> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> Message-ID: <20061229204121.GF28234@neu.nirvana> On Fri, Dec 29, 2006 at 02:14:57PM -0600, Callum Lerwick wrote: > On Fri, 2006-12-29 at 11:14 -0500, Tom Lane wrote: > > Ville =?utf-8?q?Skytt=C3=A4?= writes: > > > On Friday 29 December 2006 16:00, Thorsten Leemhuis wrote: > > >> The decision went towards a proposed new rule: "the reviewer has to at > > >> least mention that he checked the license, if the sources match upstream > > >> and 5 other points he checked when approving a package". > > > > > I don't think this makes much sense. How many points does the one then > > > subsequently reviewing that the package was reviewed properly have to add? > > > > I agree that this sounds like pointless pedantry. It would be > > reasonable to list all these things in the guidelines for reviewers, > > if they aren't already. But requiring reviewers to (in effect) > > copy-and-paste the guidelines in every approval message is a waste of > > storage space and readers' time. > > On Fri, 2006-12-29 at 17:10 +0100, Michael Schwendt wrote: > >Any more formalism and bureaucracy will drive away reviewers. I think > > we've agreed on that long ago. I'm surprised this topic has returned. > > I... am absolutely astounded by all this. For doing reviews, I keep this > template in a Tomboy note: It would be nice if such a template was officially embeded into the review process docs and was maintained to always reflect the latest review/guidelines requirements. > MUST items: > > - rpmlint: > - Package name: > - Spec name: > - Meets packaging guidelines: > - License: > - Spec in American English: > - Spec legible: > - Sources match upstream: > - Builds: > - BuildRequires: > - Locales: > - ldconfig: > - Relocation: > - Directory ownership: > - %files: > - %clean: > - Macros: > - Code vs. Content: > - Documentation: > - devel package: > - .desktop file: > > SHOULD: > > - Includes license text: > - Mock build: > - Builds on all archs: > - Package functional: > - Scriptlets: > - Subpackages: > > Which follows the review guidelines pretty closely. When I finalize a > review, I just copy and paste this template into a new note, go down the > ReviewGuidelines list, and type in an "Ok" or a "NEEDSWORK" for each > one. If the time required to copy and paste and type some OK's would add > significantly to your workload, I dare say you aren't putting in > adequate time, thought and effort into your reviews. -- 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 tibbs at math.uh.edu Fri Dec 29 21:13:45 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Dec 2006 15:13:45 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229213025.3a7cff12.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> <20061229213025.3a7cff12.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> It is not feasible. Certainly not for me. It is MS> inefficient. Having to document each and every minor detail I MS> perceive while reviewing a package would require using a MS> completely different work-flow. So I'm confused; are you saying that you advocate a simple "APPROVED" with no explanation for reviews where you found no issues of note? And if not, then how much do you think is necessary to list? MS> Rather than requiring reviewers to be pedantic, better encourage MS> packagers to be more verbose in their spec file comments. Well, firstly I have not advocated requiring reviewers to be pedantic (just the opposite, in fact), so I'll assume that you're replying to something other than the message which you quoted. But I will certainly agree that it is good to encourage packagers to be more verbose in specfile comments where warranted. I think it's a bit of a non sequitur in this thread, however. >> As the review is permanently kept as evidence, reviewers should not >> leave things open to question. If you looked at something and >> found it OK, please indicate that instead of asking others to >> assume that you checked something and found it not worth commenting >> on. MS> Why? Silent observers are irrelevant. Only if an observer finds MS> something arguable and points it out, it gets interesting. This is patently untrue, to the degree that I have to wonder if you are being disingenuous. Do you not agree that prospective reviewers (i.e. the people who we desperately need once the current overworked crop of volunteers burn out) should have a volume of good reviews to learn from? - J< From bugs.michael at gmx.net Fri Dec 29 21:24:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Dec 2006 22:24:02 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167423298.3762.13.camel@max.booze> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> Message-ID: <20061229222402.8363be60.bugs.michael@gmx.net> On Fri, 29 Dec 2006 14:14:57 -0600, Callum Lerwick wrote: > I... am absolutely astounded by all this. For doing reviews, I keep this > template in a Tomboy note: -snip- > Which follows the review guidelines pretty closely. When I finalize a > review, I just copy and paste this template into a new note, go down the > ReviewGuidelines list, and type in an "Ok" or a "NEEDSWORK" for each > one. > If the time required to copy and paste and type some OK's would add > significantly to your workload, I dare say you aren't putting in > adequate time, thought and effort into your reviews. Wrong way of thinking to begin with. It would be wrong for me to reduce my way of reviewing packages painstakingly to such a short'n'static list of MUST/SHOULD items. My personal list of MUST/SHOULD/HINTS items depends on the package I review. I adapt to what I see and to what seems necessary, and I believe several other contributors do the same. Neither do I want to process items which are irrelevant, because they don't apply to a package, nor do I want to create a list for all things I perceive as "okay". If my other messages in this thread have not been clear enough already, I can't help it. Since I had started contributing reviews long ago, and long before some people invented metrics, I've never reached a point where I no longer found any new/bad things not covered by packaging/reviewing guidelines. I'd like to keep that style of doing reviews. Anyway, the number of Fedora Extras contributors has reached a certain point where I think I won't spend a lot of energy into discussing things like this, especially since I haven't done many reviews for quite some time. From dennis at ausil.us Fri Dec 29 21:44:12 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 29 Dec 2006 15:44:12 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229222402.8363be60.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> Message-ID: <200612291544.12636.dennis@ausil.us> On Friday 29 December 2006 15:24, Michael Schwendt wrote: > On Fri, 29 Dec 2006 14:14:57 -0600, Callum Lerwick wrote: > > I... am absolutely astounded by all this. For doing reviews, I keep this > > template in a Tomboy note: > > -snip- > > > Which follows the review guidelines pretty closely. When I finalize a > > review, I just copy and paste this template into a new note, go down the > > ReviewGuidelines list, and type in an "Ok" or a "NEEDSWORK" for each > > one. > > > > If the time required to copy and paste and type some OK's would add > > significantly to your workload, I dare say you aren't putting in > > adequate time, thought and effort into your reviews. > > Wrong way of thinking to begin with. > > It would be wrong for me to reduce my way of reviewing packages > painstakingly to such a short'n'static list of MUST/SHOULD items. I agree > My personal list of MUST/SHOULD/HINTS items depends on the package I > review. I adapt to what I see and to what seems necessary, and I believe > several other contributors do the same. Neither do I want to process items > which are irrelevant, because they don't apply to a package, nor do I want > to create a list for all things I perceive as "okay". If my other messages > in this thread have not been clear enough already, I can't help it. I think thats really good, if its not relevent skip it > Since I had started contributing reviews long ago, and long before some > people invented metrics, I've never reached a point where I no longer > found any new/bad things not covered by packaging/reviewing guidelines. > I'd like to keep that style of doing reviews. thats a good place to be. > Anyway, the number of Fedora Extras contributors has reached a certain > point where I think I won't spend a lot of energy into discussing things > like this, especially since I haven't done many reviews for quite some > time. What i tried to achieve by starting all of this was something more than Just Approved in bugzilla. for a few reasons. 1) new reviewers look at existing reviews a s a guide on what to do. So while the reviewer may have been through in the review people cant learn from it. 2) if questions crop up later about a package its easy to find answers especially if the reviewer is no longer around. The output in the review needs to be flexible and not cluttered with noise. But it also needs to show that a review indeed took place -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From bugs.michael at gmx.net Fri Dec 29 21:57:21 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Dec 2006 22:57:21 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> <20061229213025.3a7cff12.bugs.michael@gmx.net> Message-ID: <20061229225721.8e4f1693.bugs.michael@gmx.net> On 29 Dec 2006 15:13:45 -0600, Jason L Tibbitts III wrote: > So I'm confused; are you saying that you advocate a simple "APPROVED" > with no explanation for reviews where you found no issues of note? Yes. > Well, firstly I have not advocated requiring reviewers to be pedantic > (just the opposite, in fact), so I'll assume that you're replying to > something other than the message which you quoted. Here is the quote again: | I prefer a much simpler rule: please just tell us what you checked. Plus: | As the review is permanently kept as evidence, reviewers should not | leave things open to question. > >> As the review is permanently kept as evidence, reviewers should not > >> leave things open to question. If you looked at something and > >> found it OK, please indicate that instead of asking others to > >> assume that you checked something and found it not worth commenting > >> on. > > MS> Why? Silent observers are irrelevant. Only if an observer finds > MS> something arguable and points it out, it gets interesting. > > This is patently untrue, to the degree that I have to wonder if you > are being disingenuous. Cannot follow you here. Where you do see disingenuousness? > Do you not agree that prospective reviewers > (i.e. the people who we desperately need once the current overworked > crop of volunteers burn out) should have a volume of good reviews to > learn from? They learn best from submitting packages, from applying the guidelines to their own packages, and from trying to review packages. This is what they do once they maintain their package in CVS on their own without any peer reviewing. They cannot learn from a brief list of YES/NO answers or MUST/SHOULD items. Example: * compiles with $RPM_OPT_FLAGS: yes * unowned directory: %{_datadir}/blubb/bleep/ * blubb-devel is missing "Requires: blip-devel blop-devel" * conflicts with "blop" and "blop-devel" * does ltdlopen *.la files * %{_libdir}/blubb/libbleep.so is not stripped says nothing about how exactly I checked these. The techniques are not explained during a review. From Axel.Thimm at ATrpms.net Fri Dec 29 22:30:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 29 Dec 2006 23:30:09 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229222402.8363be60.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> Message-ID: <20061229223009.GH28234@neu.nirvana> On Fri, Dec 29, 2006 at 10:24:02PM +0100, Michael Schwendt wrote: > On Fri, 29 Dec 2006 14:14:57 -0600, Callum Lerwick wrote: > > > I... am absolutely astounded by all this. For doing reviews, I keep this > > template in a Tomboy note: > > -snip- > > > Which follows the review guidelines pretty closely. When I finalize a > > review, I just copy and paste this template into a new note, go down the > > ReviewGuidelines list, and type in an "Ok" or a "NEEDSWORK" for each > > one. > > > If the time required to copy and paste and type some OK's would add > > significantly to your workload, I dare say you aren't putting in > > adequate time, thought and effort into your reviews. > > Wrong way of thinking to begin with. > > It would be wrong for me to reduce my way of reviewing packages > painstakingly to such a short'n'static list of MUST/SHOULD items. I don't think Callum suggests you to reduce to only these items on the checklist, it should be considered the basic items to check. After all they are called a MUST for a reason, e.g. supposedly *every review* has checked the MUST items, and listing them in the review with a check after them signals that you indeed are following the very basic QA requirements. And speaking of QA - QA is defined by fulfilling a given set of specifications and the MUSTs in guidelines and review process documents are providing these specifications. Sure, these can be better streamlined and perhaps different checklists could emerge for different classes of packages and make life easier. -- 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 jspaleta at gmail.com Fri Dec 29 22:58:09 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 29 Dec 2006 13:58:09 -0900 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229204121.GF28234@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229204121.GF28234@neu.nirvana> Message-ID: <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> On 12/29/06, Axel Thimm wrote: > It would be nice if such a template was officially embeded into the > review process docs and was maintained to always reflect the latest > review/guidelines requirements. As a reviewer and a packager, I'm always concerned that the liste of items I need to check as a matter of policy will shift under my feet. The packaging policy does evolve, and will continue to evolve, and I do my best to adhere to the stated guidance. If I'm not reading over the guidelines as I do any reviews, I'm garunteed to miss a policy change. Boiling down requirements into a template, especially a template that could highlight in some way 'newness' of specific policy items would help notify me of policy shifts over time. I can't reasonably assume that the guidelines I remember from 3 months ago are completely appropriate now. If we had an embedded template that was sorted such with 'newness' of individual policy items could be quickly guaged it would help my efficiency immensely because I could concentrate my time on re-reading the guidance of the specific policy items which have been updated recently. Right now I spend too much time reading over all the guidance looking for changes everytime I do a review. For example if .desktop policy changes again next month, a template could put the desktop related check item at the end of the list, perhaps with a effective-as-of date. This would tell me as a reviewer that I need to go back and make a detailed reading of the desktop policy in the guidelines because it's changed since the last time I ran a review or submitted a package. -jef From bugs.michael at gmx.net Fri Dec 29 23:08:16 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 00:08:16 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229223009.GH28234@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> Message-ID: <20061230000816.552d1189.bugs.michael@gmx.net> On Fri, 29 Dec 2006 23:30:09 +0100, Axel Thimm wrote: > I don't think Callum suggests you to reduce to only these items on the > checklist, it should be considered the basic items to check. After all > they are called a MUST for a reason, e.g. supposedly *every review* > has checked the MUST items, What is the purpose of listing them in the review then? APPROVAL => all MUST items must have passed the check > and listing them in the review with a > check after them signals that you indeed are following the very basic > QA requirements. How do you know whether it's not just a single cut'n'paste job? The only interesting point is when after approval it turns out that the reviewer has NOT checked something and has NOT noticed one or more flaws that should have been noticed when processing the MUST items. Everything else is added bureaucracy from the Fedora playground. Ages ago we've had GPG signed bugzilla comments at fedora.us including the MD5 fingerprint of the reviewed src.rpm, so a review would be tied to a specific src.rpm. From Axel.Thimm at ATrpms.net Fri Dec 29 23:30:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 00:30:17 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230000816.552d1189.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> Message-ID: <20061229233017.GI28234@neu.nirvana> On Sat, Dec 30, 2006 at 12:08:16AM +0100, Michael Schwendt wrote: > On Fri, 29 Dec 2006 23:30:09 +0100, Axel Thimm wrote: > > > I don't think Callum suggests you to reduce to only these items on the > > checklist, it should be considered the basic items to check. After all > > they are called a MUST for a reason, e.g. supposedly *every review* > > has checked the MUST items, > > What is the purpose of listing them in the review then? Ensuring that reviewers get in touch with the checklist instead of ... > APPROVAL => all MUST items must have passed the check ... using the easy way out. > > and listing them in the review with a check after them signals > > that you indeed are following the very basic QA requirements. > > How do you know whether it's not just a single cut'n'paste job? I don't, and I know that even less when there's a one-liner "APPROVED" in the bugzilla entry. > The only interesting point is when after approval it turns out that the > reviewer has NOT checked something and has NOT noticed one or more flaws > that should have been noticed when processing the MUST items. Better be proactive than finding whom to blame afterwards: Forcing the reviewer to interact with the checklist make it less likely for missed items especially when compared to "wild reviews". -- 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 wolfy at nobugconsulting.ro Sat Dec 30 02:30:02 2006 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Sat, 30 Dec 2006 04:30:02 +0200 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167423298.3762.13.camel@max.booze> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> Message-ID: <4595CF2A.6010303@nobugconsulting.ro> On 12/29/2006 10:14 PM, Callum Lerwick wrote: > On Fri, 2006-12-29 at 11:14 -0500, Tom Lane wrote: > >> Ville =?utf-8?q?Skytt=C3=A4?= writes: >> >>> On Friday 29 December 2006 16:00, Thorsten Leemhuis wrote: >>> >>>> The decision went towards a proposed new rule: "the reviewer has to at >>>> least mention that he checked the license, if the sources match upstream >>>> and 5 other points he checked when approving a package". >>>> >>> I don't think this makes much sense. How many points does the one then >>> subsequently reviewing that the package was reviewed properly have to add? >>> >> I agree that this sounds like pointless pedantry. It would be >> reasonable to list all these things in the guidelines for reviewers, >> if they aren't already. But requiring reviewers to (in effect) >> copy-and-paste the guidelines in every approval message is a waste of >> storage space and readers' time. >> > > On Fri, 2006-12-29 at 17:10 +0100, Michael Schwendt wrote: > >> Any more formalism and bureaucracy will drive away reviewers. I think >> we've agreed on that long ago. I'm surprised this topic has returned. >> > > I... am absolutely astounded by all this. For doing reviews, I keep this > template in a Tomboy note: > > MUST items: > > - rpmlint: > - Package name: > - Spec name: > - Meets packaging guidelines: > - License: > - Spec in American English: > - Spec legible: > - Sources match upstream: > - Builds: > - BuildRequires: > - Locales: > - ldconfig: > - Relocation: > - Directory ownership: > - %files: > - %clean: > - Macros: > - Code vs. Content: > - Documentation: > - devel package: > - .desktop file: > > SHOULD: > > - Includes license text: > - Mock build: > - Builds on all archs: > - Package functional: > - Scriptlets: > - Subpackages: > > Which follows the review guidelines pretty closely. When I finalize a > review, I just copy and paste this template into a new note, go down the > ReviewGuidelines list, and type in an "Ok" or a "NEEDSWORK" for each > one. If the time required to copy and paste and type some OK's would add > significantly to your workload, I dare say you aren't putting in > adequate time, thought and effort into your reviews. > > How about Spot's "cheat" sheet ( http://fedoraproject.org/wiki/SpotsReviewCheatSheet?highlight=%28cheat%29 ) ? From bugs.michael at gmx.net Sat Dec 30 09:48:36 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 10:48:36 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229204121.GF28234@neu.nirvana> <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> Message-ID: <20061230104836.7510d93a.bugs.michael@gmx.net> On Fri, 29 Dec 2006 13:58:09 -0900, Jeff Spaleta wrote: > As a reviewer and a packager, I'm always concerned that the liste of > items I need to check as a matter of policy will shift under my feet. That's why we need good communication channels where to announce policy changes and where to reach all package maintainers. > The packaging policy does evolve, and will continue to evolve, and I > do my best to adhere to the stated guidance. If I'm not reading over > the guidelines as I do any reviews, I'm garunteed to miss a policy > change. > Right now I spend too much > time reading over all the guidance looking for changes everytime I do > a review. The scenario you describe is unacceptable. You should only feel the need to revisit the guidelines if they contain things that contradict with your own packaging habits. In that case it'll likely take some time to get used to the guidelines. However, if you read them the first time and find nothing unusual, nothing special, there is no need to revisit them (except when comparing ugly details such as scriptlet sections). > I can't reasonably assume that the guidelines I remember from 3 months > ago are completely appropriate now. Who cares? Three months in the future you should still be able to spot questionable packaging techniques which require a closer look. All that matters is whether a package contains anything nasty prior to approval or after approval (when the packager can reintroduce severe packaging bugs unless this is noticed via commits-list). From bugs.michael at gmx.net Sat Dec 30 09:51:12 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 10:51:12 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229233017.GI28234@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> <20061229233017.GI28234@neu.nirvana> Message-ID: <20061230105112.939a3456.bugs.michael@gmx.net> On Sat, 30 Dec 2006 00:30:17 +0100, Axel Thimm wrote: > On Sat, Dec 30, 2006 at 12:08:16AM +0100, Michael Schwendt wrote: > > On Fri, 29 Dec 2006 23:30:09 +0100, Axel Thimm wrote: > > > > > I don't think Callum suggests you to reduce to only these items on the > > > checklist, it should be considered the basic items to check. After all > > > they are called a MUST for a reason, e.g. supposedly *every review* > > > has checked the MUST items, > > > > What is the purpose of listing them in the review then? > > Ensuring that reviewers get in touch with the checklist instead of ... Ouch. Deadlock. We're in a loop! When the reviewer is forced to include a commented mandatory incomplete checklist, this would require the reviewer to document all additional checks (among them things more important than what's in the checklist), too, for completeness. I hereby refuse to do that and will rather stop doing reviews completely. I do custom reviews and adapt to what is contained within a package, and more often than not that has helped in blocking crap. > > APPROVAL => all MUST items must have passed the check > > ... using the easy way out. No, there is no excuse if the approved package does not pass the checklist actually. > > > and listing them in the review with a check after them signals > > > that you indeed are following the very basic QA requirements. > > > > How do you know whether it's not just a single cut'n'paste job? > > I don't, and I know that even less when there's a one-liner "APPROVED" > in the bugzilla entry. Then it's pointless. > > The only interesting point is when after approval it turns out that the > > reviewer has NOT checked something and has NOT noticed one or more flaws > > that should have been noticed when processing the MUST items. > > Better be proactive than finding whom to blame afterwards: Forcing the > reviewer to interact with the checklist make it less likely for missed > items especially when compared to "wild reviews". No, thank you. This is a big turn-off criterion for me. When I say "APPROVED", all that matters is whether anybody can point me to something I've missed. From Axel.Thimm at ATrpms.net Sat Dec 30 10:44:15 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 11:44:15 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230104836.7510d93a.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229204121.GF28234@neu.nirvana> <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> <20061230104836.7510d93a.bugs.michael@gmx.net> Message-ID: <20061230104415.GB16034@neu.nirvana> On Sat, Dec 30, 2006 at 10:48:36AM +0100, Michael Schwendt wrote: > > The packaging policy does evolve, and will continue to evolve, and > > I do my best to adhere to the stated guidance. If I'm not reading > > over the guidelines as I do any reviews, I'm garunteed to miss a > > policy change. > > > Right now I spend too much time reading over all the guidance > > looking for changes everytime I do a review. > > The scenario you describe is unacceptable. Only because you trimmed the part where Jeff is asking for keeping a checklist up2date with change dates attached to the items :) > You should only feel the need to revisit the guidelines if they contain > things that contradict with your own packaging habits. so how will you know that the guidelines didn't intorduce something against your packaging habits? We can't define quality control of packages based on "packaging habits", can we? > However, if you read them the first time and find nothing unusual, > nothing special, there is no need to revisit them Things change in time ... > > I can't reasonably assume that the guidelines I remember from 3 months > > ago are completely appropriate now. > > Who cares? Three months in the future you should still be able to spot > questionable packaging techniques which require a closer look. All that > matters is whether a package contains anything nasty prior to approval or > after approval (when the packager can reintroduce severe packaging bugs > unless this is noticed via commits-list). So why do we have a packaging committee at all? We should freeze the packaging guidelines for all times if "noone cares that guidleines may change withing 3 months". I think this clearly shows why detailed approvals are needed. If I now see a one-liner "APPROVAL" by for example M. Schwendt, I will not know whether he has checked against any changes in the guidelines or review process the last three months or maybe more. Or better said I will know that he must be missing all changes against his own packaging habits if the above statements are all true. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Dec 30 11:00:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 12:00:43 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230105112.939a3456.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> <20061229233017.GI28234@neu.nirvana> <20061230105112.939a3456.bugs.michael@gmx.net> Message-ID: <20061230110043.GC16034@neu.nirvana> On Sat, Dec 30, 2006 at 10:51:12AM +0100, Michael Schwendt wrote: > On Sat, 30 Dec 2006 00:30:17 +0100, Axel Thimm wrote: > > > On Sat, Dec 30, 2006 at 12:08:16AM +0100, Michael Schwendt wrote: > > > On Fri, 29 Dec 2006 23:30:09 +0100, Axel Thimm wrote: > > > > > > > I don't think Callum suggests you to reduce to only these items on the > > > > checklist, it should be considered the basic items to check. After all > > > > they are called a MUST for a reason, e.g. supposedly *every review* > > > > has checked the MUST items, > > > > > > What is the purpose of listing them in the review then? > > > > Ensuring that reviewers get in touch with the checklist instead of ... > > Ouch. Deadlock. We're in a loop! Then please do find the exit, I'm already standing on the outside looking at you spinning in circles - I'm all dizzy already ;) > When the reviewer is forced to include a commented mandatory > incomplete checklist, this would require the reviewer to document > all additional checks (among them things more important than what's > in the checklist), too, for completeness. Why does it have to be all or nothing? So you either just stamp off a package review with a terse aproval notice or have to write a book on it? Try to find a middle ground, which is posting a checklist and anything else you want to post. Other people have done this successfully, check their reviews. > hereby refuse to do that and will rather stop doing reviews completely. > I do custom reviews and adapt to what is contained within a package, ^^^^^^^^^^^^^^ > and more often than not that has helped in blocking crap. Thanks for putting efforts into allowing good packages to evolve, but any custom or packaging habits controlled reviewes need to be on top of the base checklist. Otherwise the reviews will differ in quality too much. Someone else may think that according to his packaging habits it is enough to build and run the package and stamp it in the same way you do. How will one see the difference in the quality of the review? > > > APPROVAL => all MUST items must have passed the check > > > > ... using the easy way out. > > No, there is no excuse if the approved package does not pass the checklist > actually. And how will one be able to tell? Only by doing himself a complete review ... > > > > and listing them in the review with a check after them signals > > > > that you indeed are following the very basic QA requirements. > > > > > > How do you know whether it's not just a single cut'n'paste job? > > > > I don't, and I know that even less when there's a one-liner "APPROVED" > > in the bugzilla entry. > > Then it's pointless. Well, nothing in bugzilla has been entered under the influence of a truth serum, we don't declare it pointless for that matter. You do tend to exaggerate a bit in the sense of "All or nothing". > > > The only interesting point is when after approval it turns out that the > > > reviewer has NOT checked something and has NOT noticed one or more flaws > > > that should have been noticed when processing the MUST items. > > > > Better be proactive than finding whom to blame afterwards: Forcing the > > reviewer to interact with the checklist make it less likely for missed > > items especially when compared to "wild reviews". > > No, thank you. This is a big turn-off criterion for me. When I say "APPROVED", > all that matters is whether anybody can point me to something I've missed. And "quid custodiet ipsos custodes?". Reviewers aren't gods, they are on the same level as contributors, and when we ask contributors to invest time in packaging and explaining package decisions, we have to ask reviewers to put some visible efforts into the process, too. All I know by now from your responses is o that you never check against changes in the packaging guidelines o neither against changes in the review process o use "custom reviewing" according to your own "packaging habits" So it looks quite certain that you will miss MUSTs from the packaging quideline or the review list, and guess what: One cannot even check whether your reviewes are complete, because there is no trace of them other than a one-liner APPROVAL stamp. Therefore it makes very much sense to maintain a basic checklist for o ensuring that the review really happened with the minimal Fedora standards as given by the review procedure o be able to track bad reviews after the fact o make sure every reviewer has access to a fresh official checklist (with change dates attached as proposed by Jeff) -- 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 bugs.michael at gmx.net Sat Dec 30 14:42:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 15:42:22 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230110043.GC16034@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> <20061229233017.GI28234@neu.nirvana> <20061230105112.939a3456.bugs.michael@gmx.net> <20061230110043.GC16034@neu.nirvana> Message-ID: <20061230154222.1044a963.bugs.michael@gmx.net> On Sat, 30 Dec 2006 12:00:43 +0100, Axel Thimm wrote: > > When the reviewer is forced to include a commented mandatory > > incomplete checklist, this would require the reviewer to document > > all additional checks (among them things more important than what's > > in the checklist), too, for completeness. > > Why does it have to be all or nothing? Why do you ask when I've explained it before? It's in previous messages in this thread. I don't want to transcribe my thoughts during reviewing. But if I'm forced to include a commented checklist, that would not match what I've examined beyond the MUST items, and I would need to extend the list, which would be tiresome. > So you either just stamp off a package review with a terse aproval > notice or have to write a book on it? Strange question. Have you ever before observed a review done by me? The interesting reviews are those where multiple problems are pointed out, not those where no problems are found. > > hereby refuse to do that and will rather stop doing reviews completely. > > I do custom reviews and adapt to what is contained within a package, > ^^^^^^^^^^^^^^ > > and more often than not that has helped in blocking crap. > > Thanks for putting efforts into allowing good packages to evolve, but > any custom or packaging habits controlled reviewes need to be on top > of the base checklist. Another loop. Listen, we've tried to keep the reviewing guidelines short and to the point. Not only because of mixed experience with the shorter "QA Checklist" from fedora.us, which had been described as too complicated to check. And still, over time the new list of MUST/SHOULD items has increased in length. A fundamental problem with such checklists is that you need to find the volunteers who believe they are able to perform all the checks. From the right perspective, however, *every* packager ought to check his own package against the reviewing guidelines prior to submitting it for review. > Otherwise the reviews will differ in quality > too much. Someone else may think that according to his packaging > habits it is enough to build and run the package and stamp it in the > same way you do. How will one see the difference in the quality of the > review? Reviewer X: "I've checked the package in accordance with the reviewing guidelines. All MUST items are fine. APPROVED." Reviewer Y: "The package compiles and links an included libbind." Again, reviews are interesting when something is found, not when nothing is found. > > > > APPROVAL => all MUST items must have passed the check > > > > > > ... using the easy way out. > > > > No, there is no excuse if the approved package does not pass the checklist > > actually. > > And how will one be able to tell? Only by doing himself a complete > review ... Exactly. That's the only way to verify whether all MUST items have been checked. > > > > The only interesting point is when after approval it turns out that the > > > > reviewer has NOT checked something and has NOT noticed one or more flaws > > > > that should have been noticed when processing the MUST items. > > > > > > Better be proactive than finding whom to blame afterwards: Forcing the > > > reviewer to interact with the checklist make it less likely for missed > > > items especially when compared to "wild reviews". > > > > No, thank you. This is a big turn-off criterion for me. When I say "APPROVED", > > all that matters is whether anybody can point me to something I've missed. > > And "quid custodiet ipsos custodes?". I'm not fluent in Latin, so I've had to look this up. Please don't talk in riddles. There really is only one way to verify a review, and that is to do an own review of the same package. Do it! Find sloppy reviews, where serious problems have slipped through, and then give reason to put an eye on reviewers. > Reviewers aren't gods, they are > on the same level as contributors, and when we ask contributors to > invest time in packaging and explaining package decisions, we have to > ask reviewers to put some visible efforts into the process, too. Sigh. A cut'n'pasted list? [ms: The rest of the message ignored deliberately. You've overstepped the mark in there. I've done hundreds of gpg signed reviews, plus more in the new system, and surely don't need your judgement about the quality of my reviewing.] From Axel.Thimm at ATrpms.net Sat Dec 30 15:52:22 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 16:52:22 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230154222.1044a963.bugs.michael@gmx.net> References: <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> <20061229233017.GI28234@neu.nirvana> <20061230105112.939a3456.bugs.michael@gmx.net> <20061230110043.GC16034@neu.nirvana> <20061230154222.1044a963.bugs.michael@gmx.net> Message-ID: <20061230155222.GH16034@neu.nirvana> Michael Schwendt wrote: > You should only feel the need to revisit the guidelines if they > contain things that contradict with your own packaging habits. > However, if you read them the first time and find nothing unusual, > nothing special, there is no need to revisit them > > I can't reasonably assume that the guidelines I remember from 3 > > months ago are completely appropriate now. > > Who cares? Three months in the future you should still be able to > spot questionable packaging techniques which require a closer look. > I do custom reviews > When I say "APPROVED", all that matters is whether anybody can point > me to something I've missed. > On Sat, 30 Dec 2006 12:00:43 +0100, Axel Thimm wrote: > > > > When the reviewer is forced to include a commented mandatory > > > incomplete checklist, this would require the reviewer to document > > > all additional checks (among them things more important than what's > > > in the checklist), too, for completeness. > > > > Why does it have to be all or nothing? > > Why do you ask when I've explained it before? It's in previous messages in > this thread. I don't want to transcribe my thoughts during reviewing. But > if I'm forced to include a commented checklist, that would not match what > I've examined beyond the MUST items, and I would need to extend the list, > which would be tiresome. Again all or nothing. Just do the checklist in the bugzilla, that does not have to be followed up by a book on your methology. You try to bundle that in order to try to demonstrate that check lists are bad, but the bundling is wrong to start with. > > Thanks for putting efforts into allowing good packages to evolve, but > > any custom or packaging habits controlled reviewes need to be on top > > of the base checklist. > > Another loop. Anything that disagrees with your opinion isn't neccessary a loop. > From the right perspective, however, *every* packager ought to check > his own package against the reviewing guidelines prior to submitting > it for review. Indeed, but more to the point, what does that say about reviews? That you as a reviewer don't have to check the guidelines anymore? No, because that's exactly why we need the reviewer - to catch any errors made by the packager. And the reviewer needs to be an example in not being sloppy. > Again, reviews are interesting when something is found, not when nothing > is found. > > > > > > APPROVAL => all MUST items must have passed the check > > > > > > > > ... using the easy way out. > > > > > > No, there is no excuse if the approved package does not pass the checklist > > > actually. > > > > And how will one be able to tell? Only by doing himself a complete > > review ... > > Exactly. That's the only way to verify whether all MUST items have been > checked. So for checking whether your single-worded "APPROVED" is correct or not the whole work needs to be repeated instead of checking that you reviewed the mandatory items. Sorry, but that's nowhere near quality control. > > And "quid custodiet ipsos custodes?". > > I'm not fluent in Latin, so I've had to look this up. Please don't talk in > riddles. Sorry for that, the above is used more often outside of pure Latin and is about self-controlling organizations http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F In our context "Who reviewes the reviewers themselves?" > There really is only one way to verify a review, and that is to do > an own review of the same package. Do it! Find sloppy reviews, where > serious problems have slipped through, and then give reason to put > an eye on reviewers. I can check a review on its validity only if there is one to start with. > > Reviewers aren't gods, they are on the same level as contributors, > > and when we ask contributors to invest time in packaging and > > explaining package decisions, we have to ask reviewers to put some > > visible efforts into the process, too. > > Sigh. A cut'n'pasted list? No, a cut'n'pasted *empty* list, that gets properly filled out. Cut and paste will be its frame, not its content. On the one hand you want us to fully trust reviewers who simply paste in an "APPROVE" stamp and go through loops to verify their "APPROVAL", and on the other hand you assume malicious cut and paste practices by anyone else. > [ms: The rest of the message ignored deliberately. You've overstepped the > mark in there. I've done hundreds of gpg signed reviews, plus more in the > new system, and surely don't need your judgement about the quality of my > reviewing.] I didn't imply anything about the quality of your reviewing, but on the quality of your reviews, which if - as you yourself say - are simple "APPROVED" stamps are no proper reviews at all and are the reason for this thread. If your review efforts are that detailed and effortful, why not document them with a one-liner each? Writing "Built under mock" and "tested create/save under gnome" into the review takes up less than 1% of the time you needed to do these things. Please get back in the row with the rest of us, noone is a review god around here. Are the other reviewers that use proper check lists and frequently check for changes in the review guidelines that much lesser than you are? -- 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 peter at thecodergeek.com Sat Dec 30 16:26:27 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 30 Dec 2006 08:26:27 -0800 Subject: Offline: 2006-12-23 Through 2007-01-01 In-Reply-To: <1166903490.3367.3.camel@localhost> References: <1166396534.8636.59.camel@localhost> <1166903490.3367.3.camel@localhost> Message-ID: <1167495987.3445.1.camel@localhost> Well, it's not the new year yet, but I had written down the wrong returning flight information (oops; sorry!). I'm back. Thanks for watching my stuff while I was away. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat Dec 30 16:36:13 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Dec 2006 11:36:13 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230110043.GC16034@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <20061230105112.939a3456.bugs.michael@gmx.net> <20061230110043.GC16034@neu.nirvana> Message-ID: <200612301136.13360.jkeating@redhat.com> On Saturday 30 December 2006 06:00, Axel Thimm wrote: > Why does it have to be all or nothing? So you either just stamp off a > package review with a terse aproval notice or have to write a book on > it? Try to find a middle ground, which is posting a checklist and > anything else you want to post. Other people have done this > successfully, check their reviews. The checklist is just a condensed version of the guidelines, that will be copied pasted. It is no more valuable than a 'APPROVED'. Anybody could copy/paste the checklist, especially if there are items that don't apply (python checks for a perl package). The only thing it would prove is that they copied the most recent checklist. -- 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 Dec 30 16:39:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Dec 2006 11:39:03 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230155222.GH16034@neu.nirvana> References: <200612291736.11510.ville.skytta@iki.fi> <20061230154222.1044a963.bugs.michael@gmx.net> <20061230155222.GH16034@neu.nirvana> Message-ID: <200612301139.03354.jkeating@redhat.com> On Saturday 30 December 2006 10:52, Axel Thimm wrote: > So for checking whether your single-worded "APPROVED" is correct or > not the whole work needs to be repeated instead of checking that you > reviewed the mandatory items. Sorry, but that's nowhere near quality > control. Just looking to see if the checklist was pasted isn't quality control either. The only way to _actually_ check that things were reviewed is to do the review yourself. A spot check. Anything less is trusting the reviewer did the right thing, and if you're already doing that, what does it matter if they just listed APPROVED or if they copy/pasted a long list of check items? -- 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 bugs.michael at gmx.net Sat Dec 30 17:08:23 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 18:08:23 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230155222.GH16034@neu.nirvana> References: <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> <20061229233017.GI28234@neu.nirvana> <20061230105112.939a3456.bugs.michael@gmx.net> <20061230110043.GC16034@neu.nirvana> <20061230154222.1044a963.bugs.michael@gmx.net> <20061230155222.GH16034@neu.nirvana> Message-ID: <20061230180823.07fabb1f.bugs.michael@gmx.net> On Sat, 30 Dec 2006 16:52:22 +0100, Axel Thimm wrote: > Again all or nothing. Just do the checklist in the bugzilla, that does > not have to be followed up by a book on your methology. You try to > bundle that in order to try to demonstrate that check lists are bad, > but the bundling is wrong to start with. I won't use such checklists anymore. Period. > > > Thanks for putting efforts into allowing good packages to evolve, but > > > any custom or packaging habits controlled reviewes need to be on top > > > of the base checklist. > > > > Another loop. > > Anything that disagrees with your opinion isn't neccessary a loop. You misunderstand so many things and in return try to use smart rhetoric. The loop is that we cannot go back to a full [longer] list of things to check, because as it gets longer, the number of reviewers will be decreasing. Initially we've had 18 items on the list. Considered too much. Trimmed it down to 15 items. Still too much. Nowadays we're back to 31 items plus 8x SHOULD. And I need to cut'n'paste that list into bugzilla to prove what? Nothing. Aha, so you want me to take down detailed notes about all MUST items plus all the things I perceive while performing my own checks? That's extra work *I* do not support. If other reviewers are happy about the bureaucracy, fine. I am not. And this is the feedback. > > From the right perspective, however, *every* packager ought to check > > his own package against the reviewing guidelines prior to submitting > > it for review. > > Indeed, but more to the point, what does that say about reviews? That > you as a reviewer don't have to check the guidelines anymore? Uhm, no. It means that also the packager could be required to include the list of MUST-check items before the reviewer would do an own review. For what benefit? Packagers are expected to become familiar with the guidelines anyway for the life-time of their package(s). > No, because that's exactly why we need the reviewer - to catch any errors > made by the packager. And the reviewer needs to be an example in not > being sloppy. With all due respect, but this is getting ridiculous. We let packagers work on their packages in CVS without any mandatory reviewing. The same packagers can review and approve other packagers' packages. You want to set up an artificial control mechanism in the wrong place. > > There really is only one way to verify a review, and that is to do > > an own review of the same package. Do it! Find sloppy reviews, where > > serious problems have slipped through, and then give reason to put > > an eye on reviewers. > > I can check a review on its validity only if there is one to start with. I feel so sleepy... http://fedoraproject.org/wiki/Packaging/ReviewGuidelines#head-2f03bba0a9f05b2ac0128eb1d70b1e3ce9f9dc40 > > > Reviewers aren't gods, they are on the same level as contributors, > > > and when we ask contributors to invest time in packaging and > > > explaining package decisions, we have to ask reviewers to put some > > > visible efforts into the process, too. > > > > Sigh. A cut'n'pasted list? > > No, a cut'n'pasted *empty* list, that gets properly filled out. I do not want to mess with such lists. I don't know how to document my own judgement in such lists without losing interest in doing reviews completely. > On the one hand you want > us to fully trust reviewers who simply paste in an "APPROVE" stamp and > go through loops to verify their "APPROVAL", and on the other hand you > assume malicious cut and paste practices by anyone else. Not at all. No further comment, since "malicious cut and paste" is nothing I've referred to. > > [ms: The rest of the message ignored deliberately. You've overstepped the > > mark in there. I've done hundreds of gpg signed reviews, plus more in the > > new system, and surely don't need your judgement about the quality of my > > reviewing.] > > I didn't imply anything about the quality of your reviewing, but on > the quality of your reviews, which if - as you yourself say - are > simple "APPROVED" stamps are no proper reviews at all and are the > reason for this thread. I have strong doubts that one of my approvals is the reason for this thread. From bugs.michael at gmx.net Sat Dec 30 17:03:30 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 18:03:30 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230104415.GB16034@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229204121.GF28234@neu.nirvana> <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> <20061230104836.7510d93a.bugs.michael@gmx.net> <20061230104415.GB16034@neu.nirvana> Message-ID: <20061230180330.2fe5ad3f.bugs.michael@gmx.net> On Sat, 30 Dec 2006 11:44:15 +0100, Axel Thimm wrote: > > > The packaging policy does evolve, and will continue to evolve, and > > > I do my best to adhere to the stated guidance. If I'm not reading > > > over the guidelines as I do any reviews, I'm garunteed to miss a > > > policy change. > > > > > Right now I spend too much time reading over all the guidance > > > looking for changes everytime I do a review. > > > > The scenario you describe is unacceptable. > > Only because you trimmed the part where Jeff is asking for keeping a > checklist up2date with change dates attached to the items :) "Unacceptable" = having to revisit the Wiki pages and their changelogs frequently in search of any important updates that have not been announced in proper communication channels. From Axel.Thimm at ATrpms.net Sat Dec 30 17:32:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 18:32:35 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230180330.2fe5ad3f.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229204121.GF28234@neu.nirvana> <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> <20061230104836.7510d93a.bugs.michael@gmx.net> <20061230104415.GB16034@neu.nirvana> <20061230180330.2fe5ad3f.bugs.michael@gmx.net> Message-ID: <20061230173235.GA23064@neu.nirvana> On Sat, Dec 30, 2006 at 06:03:30PM +0100, Michael Schwendt wrote: > On Sat, 30 Dec 2006 11:44:15 +0100, Axel Thimm wrote: > > > > > The packaging policy does evolve, and will continue to evolve, and > > > > I do my best to adhere to the stated guidance. If I'm not reading > > > > over the guidelines as I do any reviews, I'm garunteed to miss a > > > > policy change. > > > > > > > Right now I spend too much time reading over all the guidance > > > > looking for changes everytime I do a review. > > > > > > The scenario you describe is unacceptable. > > > > Only because you trimmed the part where Jeff is asking for keeping a > > checklist up2date with change dates attached to the items :) > > "Unacceptable" = having to revisit the Wiki pages and their > changelogs frequently in search of any important updates that have > not been announced in proper communication channels. Os simply checking the date field in Jeff's proposal ... Please check Jeff's full post again. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Dec 30 17:36:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 18:36:30 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612301136.13360.jkeating@redhat.com> References: <45951F62.4020302@leemhuis.info> <20061230105112.939a3456.bugs.michael@gmx.net> <20061230110043.GC16034@neu.nirvana> <200612301136.13360.jkeating@redhat.com> Message-ID: <20061230173630.GB23064@neu.nirvana> On Sat, Dec 30, 2006 at 11:36:13AM -0500, Jesse Keating wrote: > On Saturday 30 December 2006 06:00, Axel Thimm wrote: > > Why does it have to be all or nothing? So you either just stamp off a > > package review with a terse aproval notice or have to write a book on > > it? Try to find a middle ground, which is posting a checklist and > > anything else you want to post. Other people have done this > > successfully, check their reviews. > > The checklist is just a condensed version of the guidelines, that will be > copied pasted. It is no more valuable than a 'APPROVED'. Anybody could > copy/paste the checklist, especially if there are items that don't apply > (python checks for a perl package). The only thing it would prove is that > they copied the most recent checklist. Don't forget that they have to actively fill the check list with values. It's like a pre-flight check. The pilot and co-pilot could just nod to each other and say "all good". Or they could have a check-mark after a given list of items to check. And that's what quality control is: You get a list of specs to check and return in the checklist with your signature underneath. If the bananas were rotten and you check-marked bananas as OK, you're fired. Whereas now you have the situation "What? pyo files are included now? Why should I know, I read the guidelines 3 months ago ..." -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Dec 30 17:38:24 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 18:38:24 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612301139.03354.jkeating@redhat.com> References: <200612291736.11510.ville.skytta@iki.fi> <20061230154222.1044a963.bugs.michael@gmx.net> <20061230155222.GH16034@neu.nirvana> <200612301139.03354.jkeating@redhat.com> Message-ID: <20061230173824.GC23064@neu.nirvana> On Sat, Dec 30, 2006 at 11:39:03AM -0500, Jesse Keating wrote: > On Saturday 30 December 2006 10:52, Axel Thimm wrote: > > So for checking whether your single-worded "APPROVED" is correct or > > not the whole work needs to be repeated instead of checking that you > > reviewed the mandatory items. Sorry, but that's nowhere near quality > > control. > > Just looking to see if the checklist was pasted isn't quality control either. > The only way to _actually_ check that things were reviewed is to do the > review yourself. A spot check. Anything less is trusting the reviewer did > the right thing, and if you're already doing that, what does it matter if > they just listed APPROVED or if they copy/pasted a long list of check items? If you do find a broken review item and you have a checklist where the reviewer explicitely marked this item as checked, then you know that he was wrong or extremely sloppy. When doing a simple APPROVED you can't tell whether he missed it for thinking he has memorized all guidelines. -- 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 jkeating at redhat.com Sat Dec 30 17:40:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Dec 2006 12:40:00 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230173824.GC23064@neu.nirvana> References: <200612291736.11510.ville.skytta@iki.fi> <200612301139.03354.jkeating@redhat.com> <20061230173824.GC23064@neu.nirvana> Message-ID: <200612301240.00665.jkeating@redhat.com> On Saturday 30 December 2006 12:38, Axel Thimm wrote: > If you do find a broken review item and you have a checklist where the > reviewer explicitely marked this item as checked, then you know that > he was wrong or extremely sloppy. When doing a simple APPROVED you > can't tell whether he missed it for thinking he has memorized all > guidelines. I don't buy this. "Extremely sloppy" could be that he just copied/pasted. It is no more valuable than APPROVED. Either way the reviewer missed something and needs to reeducate themselves. Pasting a checklist adds no value. Only harm. -- 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 Axel.Thimm at ATrpms.net Sat Dec 30 17:42:20 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 18:42:20 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230180823.07fabb1f.bugs.michael@gmx.net> References: <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> <20061229233017.GI28234@neu.nirvana> <20061230105112.939a3456.bugs.michael@gmx.net> <20061230110043.GC16034@neu.nirvana> <20061230154222.1044a963.bugs.michael@gmx.net> <20061230155222.GH16034@neu.nirvana> <20061230180823.07fabb1f.bugs.michael@gmx.net> Message-ID: <20061230174220.GD23064@neu.nirvana> On Sat, Dec 30, 2006 at 06:08:23PM +0100, Michael Schwendt wrote: > On Sat, 30 Dec 2006 16:52:22 +0100, Axel Thimm wrote: > > Again all or nothing. Just do the checklist in the bugzilla, that does > > not have to be followed up by a book on your methology. You try to > > bundle that in order to try to demonstrate that check lists are bad, > > but the bundling is wrong to start with. > > I won't use such checklists anymore. Period. > > > > > Thanks for putting efforts into allowing good packages to > > > > evolve, but any custom or packaging habits controlled reviewes > > > > need to be on top of the base checklist. > > > > > > Another loop. > > > > Anything that disagrees with your opinion isn't neccessary a loop. > > You misunderstand so many things and in return try to use smart > rhetoric And you're losing the etiquette. > > > There really is only one way to verify a review, and that is to do > > > an own review of the same package. Do it! Find sloppy reviews, where > > > serious problems have slipped through, and then give reason to put > > > an eye on reviewers. > > > > I can check a review on its validity only if there is one to start with. > > I feel so sleepy... Have a pleasent sleep then. > Not at all. No further comment, since "malicious cut and paste" is nothing > I've referred to. You imply that the reviewer will just cut'n'paste the list w/o really checking the items, or not? If you don't then what's all the worry about? Do you have a problem if the reviewer pastes in an empty list of requirements he needs to check and ACK or NACK them? -- 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 jkeating at redhat.com Sat Dec 30 17:43:09 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Dec 2006 12:43:09 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230173630.GB23064@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <200612301136.13360.jkeating@redhat.com> <20061230173630.GB23064@neu.nirvana> Message-ID: <200612301243.09268.jkeating@redhat.com> On Saturday 30 December 2006 12:36, Axel Thimm wrote: > Don't forget that they have to actively fill the check list with > values. It's like a pre-flight check. The pilot and co-pilot could > just nod to each other and say "all good". Or they could have a > check-mark after a given list of items to check. > > And that's what quality control is: You get a list of specs to check > and return in the checklist with your signature underneath. If the > bananas were rotten and you check-marked bananas as OK, you're > fired. And whats to stop people from using a pre-filled out checklist to copy/paste? Seriously you're just adding extra paperwork to fix a problem without actually fixing the problem. Whats next? Enforce a datestamp in each "OK" field? > Whereas now you have the situation "What? pyo files are included now? > Why should I know, I read the guidelines 3 months ago ..." And these same people are going to notice one extra line in a checklist, when they're going through doing Yes, yes, yes, yes... I've done the checklist thing, I've tried adding new lines in the checklist (for a QA department, an actual QA department looking at physical things). The only way to get them notices is to announce and discuss them in appropriate channels so that the QA folks knew it was there, otherwise it gets lost in the already too large sea of checks. I've played this game, I don't want to play 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 Axel.Thimm at ATrpms.net Sat Dec 30 17:48:27 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 18:48:27 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612301240.00665.jkeating@redhat.com> References: <200612291736.11510.ville.skytta@iki.fi> <200612301139.03354.jkeating@redhat.com> <20061230173824.GC23064@neu.nirvana> <200612301240.00665.jkeating@redhat.com> Message-ID: <20061230174827.GE23064@neu.nirvana> On Sat, Dec 30, 2006 at 12:40:00PM -0500, Jesse Keating wrote: > On Saturday 30 December 2006 12:38, Axel Thimm wrote: > > If you do find a broken review item and you have a checklist where the > > reviewer explicitely marked this item as checked, then you know that > > he was wrong or extremely sloppy. When doing a simple APPROVED you > > can't tell whether he missed it for thinking he has memorized all > > guidelines. > > I don't buy this. "Extremely sloppy" could be that he just copied/pasted. It > is no more valuable than APPROVED. Either way the reviewer missed something > and needs to reeducate themselves. Pasting a checklist adds no value. Only > harm. Just let me comment that when I explored becoming a contributor to FE one of my most pleasant experiences when I checked the packages submission procedure back then was the high quality of reviewing done and the implied quality of the packages. Until this thread I wasn't aware of monolectical reviews and if this would become a habit it would decrease the quality of packages let through. Which I find a pity as one of the nicest parts of FE was the quality of packages. -- 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 jkeating at redhat.com Sat Dec 30 17:50:26 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Dec 2006 12:50:26 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230174827.GE23064@neu.nirvana> References: <200612291736.11510.ville.skytta@iki.fi> <200612301240.00665.jkeating@redhat.com> <20061230174827.GE23064@neu.nirvana> Message-ID: <200612301250.27003.jkeating@redhat.com> On Saturday 30 December 2006 12:48, Axel Thimm wrote: > Just let me comment that when I explored becoming a contributor to FE > one of my most pleasant experiences when I checked the packages > submission procedure back then was the high quality of reviewing done > and the implied quality of the packages. > > Until this thread I wasn't aware of monolectical reviews and if this > would become a habit it would decrease the quality of packages let > through. Which I find a pity as one of the nicest parts of FE was the > quality of packages. Whether or not the guidelines were regurgitated into the bug report has no bearing on if a valid and quality review was done. None whatsoever. All it does is say "this person copied/pasted some content from a wiki page, and possibly filled in some blanks". It does not prove or disprove that the reviewer actually LOOKED at the package in question. There is no way to tell that, without video proof of the review. You have to trust your reviewers, and spotchecks go a long way toward that. Just pasting content does NOT help the problem. -- 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 Axel.Thimm at ATrpms.net Sat Dec 30 18:15:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Dec 2006 19:15:12 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612301250.27003.jkeating@redhat.com> References: <200612291736.11510.ville.skytta@iki.fi> <200612301240.00665.jkeating@redhat.com> <20061230174827.GE23064@neu.nirvana> <200612301250.27003.jkeating@redhat.com> Message-ID: <20061230181512.GF23064@neu.nirvana> On Sat, Dec 30, 2006 at 12:50:26PM -0500, Jesse Keating wrote: > On Saturday 30 December 2006 12:48, Axel Thimm wrote: > > Just let me comment that when I explored becoming a contributor to FE > > one of my most pleasant experiences when I checked the packages > > submission procedure back then was the high quality of reviewing done > > and the implied quality of the packages. > > > > Until this thread I wasn't aware of monolectical reviews and if this > > would become a habit it would decrease the quality of packages let > > through. Which I find a pity as one of the nicest parts of FE was the > > quality of packages. > > Whether or not the guidelines were regurgitated into the bug report > has no bearing on if a valid and quality review was done. None > whatsoever. All it does is say "this person copied/pasted some > content from a wiki page, and possibly filled in some blanks". It > does not prove or disprove that the reviewer actually LOOKED at the > package in question. There is no way to tell that, without video > proof of the review. You have to trust your reviewers, and > spotchecks go a long way toward that. Just pasting content does NOT > help the problem. Well, in the same hyperbolic nature an "APPROVED" only says that a person hit eight characters on his keyboard in the proper sequence. We should stop assuming the worse from the reviewers and just guide them to do their review properly. And even if you do assume bad reviewer then the checklisting is the way to find what they missed and why. Let's try another approach: Other than the people having written the review guidelines no one has memorized the list (probably the authors didn't either) and will have to check the MUSTs somewhere, be it in the wiki or his personal notes. If he is going to check the items why not publicly in the bugzilla? It's zero effort in addition, unless the reviewer didn't check the MUSTs at all, and that would be bad and worth catching. -- 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 jkeating at redhat.com Sat Dec 30 18:28:10 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 30 Dec 2006 13:28:10 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230181512.GF23064@neu.nirvana> References: <200612291736.11510.ville.skytta@iki.fi> <200612301250.27003.jkeating@redhat.com> <20061230181512.GF23064@neu.nirvana> Message-ID: <200612301328.10916.jkeating@redhat.com> On Saturday 30 December 2006 13:15, Axel Thimm wrote: > Well, in the same hyperbolic nature an "APPROVED" only says that a > person hit eight characters on his keyboard in the proper sequence. > > We should stop assuming the worse from the reviewers and just guide > them to do their review properly. And even if you do assume bad > reviewer then the checklisting is the way to find what they missed and > why. > > Let's try another approach: Other than the people having written the > review guidelines no one has memorized the list (probably the authors > didn't either) and will have to check the MUSTs somewhere, be it in > the wiki or his personal notes. If he is going to check the items why > not publicly in the bugzilla? It's zero effort in addition, unless the > reviewer didn't check the MUSTs at all, and that would be bad and > worth catching. Having a checklist is fine, forcing reviewers to paste it into a review bug purely so that somebody could have a warm and fuzzy feeling that the review was actually done is silly. So sure, maintain a condensed checklist of the musts/shoulds. Review guidelines point to this. Forcing it to be pasted into bugs, not so much. -- 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 tummy.com Sat Dec 30 18:54:54 2006 From: kevin at tummy.com (Kevin Fenzi) Date: Sat, 30 Dec 2006 11:54:54 -0700 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612301328.10916.jkeating@redhat.com> References: <200612291736.11510.ville.skytta@iki.fi> <200612301250.27003.jkeating@redhat.com> <20061230181512.GF23064@neu.nirvana> <200612301328.10916.jkeating@redhat.com> Message-ID: <20061230115454.50dbb932@ningauble.scrye.com> On Sat, 30 Dec 2006 13:28:10 -0500 jkeating at redhat.com (Jesse Keating) wrote: > On Saturday 30 December 2006 13:15, Axel Thimm wrote: > > Well, in the same hyperbolic nature an "APPROVED" only says that a > > person hit eight characters on his keyboard in the proper sequence. > > > > We should stop assuming the worse from the reviewers and just guide > > them to do their review properly. And even if you do assume bad > > reviewer then the checklisting is the way to find what they missed > > and why. > > > > Let's try another approach: Other than the people having written the > > review guidelines no one has memorized the list (probably the > > authors didn't either) and will have to check the MUSTs somewhere, > > be it in the wiki or his personal notes. If he is going to check > > the items why not publicly in the bugzilla? It's zero effort in > > addition, unless the reviewer didn't check the MUSTs at all, and > > that would be bad and worth catching. > > Having a checklist is fine, forcing reviewers to paste it into a > review bug purely so that somebody could have a warm and fuzzy > feeling that the review was actually done is silly. So sure, > maintain a condensed checklist of the musts/shoulds. Review > guidelines point to this. Forcing it to be pasted into bugs, not so > much I would have to agree with Jesse here... I use a checklist, but because it's useful for me to remember to check through everything. If someone is able to check all the must items from memory or notice when they are out of place, more power to them... I don't think one should be required. For folks that don't like the 'APPROVED' type reviews, how about re-reviewing them and looking to see if anything was missed? If it was, point out to the reviewer that they need to make sure and check the item(s) that they missed, and perhaps that would even drive them to start using a checklist moving forward. One other thing to take into account is the history of the person doing the review. If I saw a review done by say mschwent or tibbs that just said 'APPROVED', I would suspect they looked over the package fully. If I saw that from a new first time reviewer, I would want to run a re-review sanity check to make sure they checked over everything they should have. If we had a big pool of reviewers I could even see doing things like random re-reviews of packages (draw a random package out of the hat and re-review it and file bugs for any problems found), or having multiple reviewers per submission (so multiple eyes might find something one pair would miss), or re-review packages that have updates often, and so on. Unfortunately, we don't have a big pool of reviewers, so we do the best we can... If someone in the existing pool of reviewers is doing a poor job, perhaps their fedorabugs membership could be removed? If more poor reviews creep in, perhaps getting fedorabugs membership could be tightened? In any case I don't think a requirement for what a reviewer must say in a package review request ticket is a good idea. Oh well, wasted enough time reading and replying to this thread... off to do some reviews. ;) kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Sat Dec 30 19:59:32 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 20:59:32 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230174220.GD23064@neu.nirvana> References: <1167423298.3762.13.camel@max.booze> <20061229222402.8363be60.bugs.michael@gmx.net> <20061229223009.GH28234@neu.nirvana> <20061230000816.552d1189.bugs.michael@gmx.net> <20061229233017.GI28234@neu.nirvana> <20061230105112.939a3456.bugs.michael@gmx.net> <20061230110043.GC16034@neu.nirvana> <20061230154222.1044a963.bugs.michael@gmx.net> <20061230155222.GH16034@neu.nirvana> <20061230180823.07fabb1f.bugs.michael@gmx.net> <20061230174220.GD23064@neu.nirvana> Message-ID: <20061230205932.f258686c.bugs.michael@gmx.net> On Sat, 30 Dec 2006 18:42:20 +0100, Axel Thimm wrote: > You imply that the reviewer will just cut'n'paste the list w/o really > checking the items, or not? Can you tell that all pasted checkpoints have been checked actually? No. Not even where you want to require the reviewer to fill in something meaningful. Example: * [...] * license: GPL * rpmlint is silent * BR are complete * builds fine for i386 * haven't tried to build for x86_64 * debuginfo package not empty * file ownership/permissions look good * scriptlets look good * installs fine * seems to start fine * removes fine * [...] Ooops. It's a plain copy from the previous approval, where the package was GPL'ed, too, and the rest identical. For a lot of the checks the result is the same for all packages. The wording is ambiguous and not detailed enough. And there is still too much noise. Too much stuff that MUST be satisfied for an approval anyway. Do you have an idea how many reviews like that I've done, gpg signed even? Nobody has any interest in that noise. Packagers don't want to read all that either, especially not if they are familiar with the guidelines and have created their package painstakingly. They wait to be told what they need to fix to get approval. Can you tell what other relevant things have been checked? No, unless another detailed list is included with the review. If it's not included, the visual appearance of the review would be reduced to the well-known check-list. If you wanted to verify and judge about filled-in values, the protocol would need to be *much* more verbose and include the diagnostic output from tools. * file ownership/permissions look good $ rpmls gqview -rwxr-xrwx /usr/bin/gqview -rw-r--r-- /usr/share/applications/gnome-gqview.desktop drwxr-xrwx /usr/share/doc/gqview-2.0.4 -rw-r--r-- /usr/share/doc/gqview-2.0.4/COPYING -rw-r--r-- /usr/share/doc/gqview-2.0.4/ChangeLog -rw-r--r-- /usr/share/doc/gqview-2.0.4/README -rw-r--r-- /usr/share/doc/gqview-2.0.4/TODO drwxr-xrwx /usr/share/doc/gqview-2.0.4/html -rw-r--r-- /usr/share/doc/gqview-2.0.4/html/10_1_general.html Hey, the stuff is world-writable, stupid! ;) > If you don't then what's all the worry about? I want to retain the freedom to keep the s/n ratio high by omitting uninteresting things and being verbose when problems are found or when hints make sense. I don't want to be forced into a specific format for approvals of [trivial] packages. If the relationship between packager and reviewer is fine, it is even possible to do a first brief review of the most important items and continue in CVS. Similarly, I want to avoid pedantry. Like 99% of the spec file appear to be American English, but in Revision 6 the packager added a word with British English spelling. From bugs.michael at gmx.net Sat Dec 30 20:02:10 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 30 Dec 2006 21:02:10 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230173235.GA23064@neu.nirvana> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229204121.GF28234@neu.nirvana> <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> <20061230104836.7510d93a.bugs.michael@gmx.net> <20061230104415.GB16034@neu.nirvana> <20061230180330.2fe5ad3f.bugs.michael@gmx.net> <20061230173235.GA23064@neu.nirvana> Message-ID: <20061230210210.5d600801.bugs.michael@gmx.net> On Sat, 30 Dec 2006 18:32:35 +0100, Axel Thimm wrote: > On Sat, Dec 30, 2006 at 06:03:30PM +0100, Michael Schwendt wrote: > > On Sat, 30 Dec 2006 11:44:15 +0100, Axel Thimm wrote: > > > > > > > The packaging policy does evolve, and will continue to evolve, and > > > > > I do my best to adhere to the stated guidance. If I'm not reading > > > > > over the guidelines as I do any reviews, I'm garunteed to miss a > > > > > policy change. > > > > > > > > > Right now I spend too much time reading over all the guidance > > > > > looking for changes everytime I do a review. > > > > > > > > The scenario you describe is unacceptable. > > > > > > Only because you trimmed the part where Jeff is asking for keeping a > > > checklist up2date with change dates attached to the items :) > > > > "Unacceptable" = having to revisit the Wiki pages and their > > changelogs frequently in search of any important updates that have > > not been announced in proper communication channels. > > Os simply checking the date field in Jeff's proposal ... > > Please check Jeff's full post again. ??? I'm aware of that proposal. Actually, I wholeheartedly agree with his proposal. Please read the quotes again. :) From fedora at leemhuis.info Sat Dec 30 19:58:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 30 Dec 2006 20:58:44 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230115454.50dbb932@ningauble.scrye.com> References: <200612291736.11510.ville.skytta@iki.fi> <200612301250.27003.jkeating@redhat.com> <20061230181512.GF23064@neu.nirvana> <200612301328.10916.jkeating@redhat.com> <20061230115454.50dbb932@ningauble.scrye.com> Message-ID: <4596C4F4.3080305@leemhuis.info> I suspect most people won't read this as the thread probably looks like a flamewar to most of them already, but nevertheless two comments: Kevin Fenzi schrieb: > One other thing to take into account is the history of the person doing > the review. If I saw a review done by say mschwent or tibbs that just > said 'APPROVED', I would suspect they looked over the package fully. Fully agreed. I'm therefor still for what I wrote in the meeting summary and what I proposed during the meeting with a slight modification: The reviewer at least has to mention that he checked the license and if the sources match upstream when approving a package. He further *should* mention what he checked during review, especially if he his not a long term contributor yet. > [...] > If we had a big pool of reviewers ...then we should do re-reviews of the packages that are in the repo. I think you'll find a lot of old cruft in our existing packages that is unneeded (there are probably still packages that probably require "python-abi" manually) or wrong now and nobody noticed it. CU thl From alan at redhat.com Sat Dec 30 22:24:57 2006 From: alan at redhat.com (Alan Cox) Date: Sat, 30 Dec 2006 17:24:57 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229160534.GD2585@free.fr> References: <45951F62.4020302@leemhuis.info> <20061229160534.GD2585@free.fr> Message-ID: <20061230222457.GA31785@devserv.devel.redhat.com> On Fri, Dec 29, 2006 at 05:05:34PM +0100, Patrice Dumas wrote: > I think that a mention of the license check, and of the upstream source match > (with a md5sum if possible or a comment if things are non standard) should SHA not MD5 please (or better yet both). MD5 alone is no longer sufficient for a large archive file you can put lots of zeros into. From alan at redhat.com Sat Dec 30 23:01:11 2006 From: alan at redhat.com (Alan Cox) Date: Sat, 30 Dec 2006 18:01:11 -0500 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: <20061230230111.GB646@devserv.devel.redhat.com> On Tue, Dec 19, 2006 at 02:58:07PM -0500, Jeff Garzik wrote: > 18. Move to using libata for PATA support > > Please keep me and Alan Cox in the loop on this. > > NOTE: You might need some intelligence in mkinitrd to avoid adding > spurious drivers such as pata_generic or ata_generic to the initrd, > after matching more specific pata_* drivers. pata_generic has a real device list it grabs so that one is fine. _legacy is for ISA/VLB only so not needed. > J2) Drop support for any hardware that does not support -march=i686 Just fix the ****ing compiler to generate i686 code for -march=i686. The compiler has been broken for years in using cmov and now on PIV and later cmov is a lose the only excuse they had for not fixing it has gone away. If the compiler stops generating wrong code then i586 goes away and we lose nothing newer than a preventium/MMX From alan at redhat.com Sat Dec 30 23:03:06 2006 From: alan at redhat.com (Alan Cox) Date: Sat, 30 Dec 2006 18:03:06 -0500 Subject: FC7 plan comments In-Reply-To: <20061220184952.GB3248@redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> <20061220184952.GB3248@redhat.com> Message-ID: <20061230230306.GC646@devserv.devel.redhat.com> On Wed, Dec 20, 2006 at 01:49:52PM -0500, Dave Jones wrote: > The only spanner in the works is that some laptops for god knows what reason, > have their sound devices on ISA busses. Not exactly. Someones "xxx ready" for a year said "no ISA bus". Every PC on the planet that year grew an Xbus or LPC bus to replace the ISA bus. There is plenty of ISA bus out there but thankfully no sockets and few odd devices usingit. From jspaleta at gmail.com Sat Dec 30 23:29:47 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 30 Dec 2006 14:29:47 -0900 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061230104836.7510d93a.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <200612291736.11510.ville.skytta@iki.fi> <2827.1167408879@sss.pgh.pa.us> <1167423298.3762.13.camel@max.booze> <20061229204121.GF28234@neu.nirvana> <604aa7910612291458l6dfd47b8i6e71debc9d7ade95@mail.gmail.com> <20061230104836.7510d93a.bugs.michael@gmx.net> Message-ID: <604aa7910612301529jcd2e3flbeb2f4c0099c1a27@mail.gmail.com> On 12/30/06, Michael Schwendt wrote: > Who cares? Three months in the future you should still be able to spot > questionable packaging techniques which require a closer look. Who cares? I care, and I since I've no authority to speak for anyone else, that should suffice. I want to make sure I'm making my best effort that I am watching out for the specific things which the people in the packaging committee have reached a consensus on as best practises. Even the nit-picky details over things like what vendor string to use in a desktop file. I frankly don't give a flying flip personally about details like that, but I value the packaging committees efforts, and I have no desire to de-value the time they spend worrying about the details by simply ignoring the policy guidance amendments they spin up. All I am saying is that there is room for improvement in communicating evolving guidance. A checklist with effective-as-of timestamping is just one implementation mechanism, that would help me keep better track of policy changes. The key idea there isn't checklist per-say, but the timestamping of sections of the guidance at some reasonable level of granularity, so that I can quickly find out what's been updated since the last time I submitted a package or ran a review. If members of the packaging committee would like to see packagers and reviewers, like myself, make submissions and reviews with the most up-to-date guidance in mind, then it would behoove them to find a way to encapsulate granular chronologically sorted effective-as-off timestamping of specific policy sections. > All that matters is whether a package contains anything nasty prior to approval or > after approval (when the packager can reintroduce severe packaging bugs > unless this is noticed via commits-list). If that is all that matters to you, then fine, I'm not mandating or asking you to do more than the minimum requirements. All I am asking is for the people who are writing the more detailed best practises guidance work with me, and anyone else who wants to follow the best practise guidance, so we can more easily keep up with the evolution of the guidance as individual items evolve. -jef From dakingun at gmail.com Sat Dec 30 23:50:54 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Sat, 30 Dec 2006 18:50:54 -0500 Subject: FC7 plan comments In-Reply-To: <20061219195807.GD2417@devserv.devel.redhat.com> References: <20061219195807.GD2417@devserv.devel.redhat.com> Message-ID: On 12/19/06, Jeff Garzik wrote: > > Comments on the FC7 draft plan: > Is gcc-4.2.0 planned for FC7? It should have been released by the time FC7 goes gold. Tons of improvement in gfortran at least in that version would really be welcomed by fortran folks. From Axel.Thimm at ATrpms.net Sun Dec 31 04:33:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 31 Dec 2006 05:33:35 +0100 Subject: Automate parts of review process? Message-ID: <20061231043335.GB396@neu.nirvana> Hi, I think large parts of the review process could be automated or at the very least aided, so that reviewers have less trivial stuff to check and can be reviewing more effectively. In order to allow any kind of automation, the submission process would have to change, e.g. instead of posting a URL a packager would submit the whole src.rpm to some submission mechanism. There the system could test whether the package builds on all non-excluded platforms and on the supported distribution releases (development and any more the submitter choses to add). The system would furthermore be able to run rpmlint and other rpm checking tools on the generated packages and prepare a submission web page for the packager (for example if rpmlint output is not silent the packager would have to comment on it, or if a static lib is found the same and so on). The result would be cast into bugzilla. That would catch most of the trivial packaging issues especially ones made by newbies before any reviewer needs to spend time on it. Perhaps the review process itself could use a helper that for example offers the proper remaining checklists for the package in question. Since the helper has access to the package it would know which items of the review are irrelevant and hide them from the reviewer (e.g. if the package has no python bits mask away python related checks). This part would be optional, e.g. reviewers are free to use the usuall methods of checking a package or could opt to using the helper. Would something like that make sense? -- 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 tcallawa at redhat.com Sun Dec 31 04:53:20 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 30 Dec 2006 22:53:20 -0600 Subject: Automate parts of review process? In-Reply-To: <20061231043335.GB396@neu.nirvana> References: <20061231043335.GB396@neu.nirvana> Message-ID: <1167540800.3328.609.camel@localhost.localdomain> On Sun, 2006-12-31 at 05:33 +0100, Axel Thimm wrote: > Hi, > > I think large parts of the review process could be automated or at the > very least aided, so that reviewers have less trivial stuff to check > and can be reviewing more effectively. > > In order to allow any kind of automation, the submission process would > have to change, e.g. instead of posting a URL a packager would submit > the whole src.rpm to some submission mechanism. There the system could > test whether the package builds on all non-excluded platforms and on > the supported distribution releases (development and any more the > submitter choses to add). The system would furthermore be able to run > rpmlint and other rpm checking tools on the generated packages and > prepare a submission web page for the packager (for example if rpmlint > output is not silent the packager would have to comment on it, or if a > static lib is found the same and so on). The result would be cast into > bugzilla. > > That would catch most of the trivial packaging issues especially ones > made by newbies before any reviewer needs to spend time on it. > > Perhaps the review process itself could use a helper that for example > offers the proper remaining checklists for the package in > question. Since the helper has access to the package it would know > which items of the review are irrelevant and hide them from the > reviewer (e.g. if the package has no python bits mask away python > related checks). This part would be optional, e.g. reviewers are free > to use the usuall methods of checking a package or could opt to using > the helper. > > Would something like that make sense? This has been proposed in the past, I even believe a few people attempted to make some tools to achieve this "pre-review check". To some extent, rpmlint falls into this (every review should have rpmlint run against it). I will repeat what I have said in the past: If someone writes a good, easy to use, open source tool to check for Fedora Packaging Compliance (tm), then I think we would consider having all new packages automatically run through that tool before human-review. The submission process might not even have to change, it could be as simple as having a daemon/script/cron tracking new bugzilla review items, scraping the SRPM path out of it, building it in a plague instance, running the tool, and returning the tool output (or plague build failure) as a comment to the new ticket. Short answer: Show me the tool. :) ~spot From bpepple at fedoraproject.org Sun Dec 31 05:47:28 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 31 Dec 2006 00:47:28 -0500 Subject: Automate parts of review process? In-Reply-To: <1167540800.3328.609.camel@localhost.localdomain> References: <20061231043335.GB396@neu.nirvana> <1167540800.3328.609.camel@localhost.localdomain> Message-ID: <1167544048.7452.2.camel@Chuck> On Sat, 2006-12-30 at 22:53 -0600, Tom 'spot' Callaway wrote: > On Sun, 2006-12-31 at 05:33 +0100, Axel Thimm wrote: > > > > Perhaps the review process itself could use a helper that for example > > offers the proper remaining checklists for the package in > > question. Since the helper has access to the package it would know > > which items of the review are irrelevant and hide them from the > > reviewer (e.g. if the package has no python bits mask away python > > related checks). This part would be optional, e.g. reviewers are free > > to use the usuall methods of checking a package or could opt to using > > the helper. > > > > Would something like that make sense? > > The submission process might not even have to change, it could be as > simple as having a daemon/script/cron tracking new bugzilla review > items, scraping the SRPM path out of it, building it in a plague > instance, running the tool, and returning the tool output (or plague > build failure) as a comment to the new ticket. > > Short answer: Show me the tool. :) Maybe we could look at using or extending Aur?lien Bompard's fedora-qa script? http://gauret.free.fr/fichiers/rpms/fedora/fedora-qa /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 seg at haxxed.com Sun Dec 31 11:26:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 31 Dec 2006 05:26:02 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <20061229225721.8e4f1693.bugs.michael@gmx.net> References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> <20061229213025.3a7cff12.bugs.michael@gmx.net> <20061229225721.8e4f1693.bugs.michael@gmx.net> Message-ID: <1167564362.14707.26.camel@localhost.localdomain> On Fri, 2006-12-29 at 22:57 +0100, Michael Schwendt wrote: > They learn best from submitting packages, from applying the guidelines to > their own packages, and from trying to review packages. This is what they > do once they maintain their package in CVS on their own without any peer > reviewing. They cannot learn from a brief list of YES/NO answers or > MUST/SHOULD items. Example: The problem with this, is in reality this can not scale. Not everyone can submit and maintain packages. And people busy maintaining packages don't tend to be interested or have the time to do reviews. Hell, I'll admit that personally, I signed up to package stuff. Not to do reviews. (I think I squeezed in just before the "must review other people's packages" policy solidified and makes me feel a bit like I got in easy, but hopefully I've made up for that by now.) Doing reviews is of little interest to me, I've reviewed only a handfull of stuff I really wanted/needed and that no one else was in any rush to review. What the project really needs, is people who are primarily interested in spending their time doing reviews, and *not* submitting and maintaining packages. That may or may or may not make any sense, but I think its the only way we can scale. We need free roaming gangs of QA people who are not attached to specific packages, who do reviews and watch the CVS changelogs like hawks. There is only so many packages to go around. As time goes by, there's going to be less and less "low hanging fruit" to package. I myself only maintain a few packages, because most of the stuff I've been packaging either got snagged by someone else first, or aren't acceptable for Fedora. Mostly the latter. (Emulators, stuff that requires mp3, non-free stuff, etc, bleh...) -------------- 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 Sun Dec 31 11:52:10 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 31 Dec 2006 05:52:10 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612291119.57073.jkeating@redhat.com> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> Message-ID: <1167565930.14707.42.camel@localhost.localdomain> On Fri, 2006-12-29 at 11:19 -0500, Jesse Keating wrote: > hrm, you must wear at least 5 pieces of flair... Seriously, a rule like this > just encourages folks to check 5 things only and move on. If rules were set > in place to make 5 specific things mandatory, that's all that will be > checked. Lets not give reviewers a shortcut out. I'd be more in favor of a > rule that just says "items checked need to be listed out in the review before > building of the package will be allowed". Vague enough as to not give > reviewers a shortcut. Which is the whole idea of my checklist. It follows the MUST list basically point-for-point. (Some related stuff gets mushed together into one item, like everything relating to %file lists, and directory/file ownership.) Everything in the MUST list is a MUST, and thus... MUST be checked. And really, the list is primarily for *my* benefit. To make sure *I* don't miss any of them. I don't know how anyone could keep track of all that in their head. And since I'm keeping a checklist anyway, I might as well post it in the review. Like Axel said, professional pilots and NASA astronauts keep pre and post-flight checklists. (And in the case of NASA, a bazillion in between...) I honestly don't understand how a professional packager could be so against keeping a review checklist. Of MUST items. To each their own I guess. -------------- 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 Sun Dec 31 12:11:56 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 31 Dec 2006 06:11:56 -0600 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <200612301139.03354.jkeating@redhat.com> References: <200612291736.11510.ville.skytta@iki.fi> <20061230154222.1044a963.bugs.michael@gmx.net> <20061230155222.GH16034@neu.nirvana> <200612301139.03354.jkeating@redhat.com> Message-ID: <1167567116.14707.53.camel@localhost.localdomain> On Sat, 2006-12-30 at 11:39 -0500, Jesse Keating wrote: > On Saturday 30 December 2006 10:52, Axel Thimm wrote: > > So for checking whether your single-worded "APPROVED" is correct or > > not the whole work needs to be repeated instead of checking that you > > reviewed the mandatory items. Sorry, but that's nowhere near quality > > control. > > Just looking to see if the checklist was pasted isn't quality control either. > The only way to _actually_ check that things were reviewed is to do the > review yourself. A spot check. Anything less is trusting the reviewer did > the right thing, and if you're already doing that, what does it matter if > they just listed APPROVED or if they copy/pasted a long list of check items? I don't see how this is relevant. I don't see how a checklist of MUST items *couldn't* keep an honest person from missing a MUST item. If someone's intent on being actively dishonest, then we have a much greater problem than some half-assed package reviews slipping by. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Sun Dec 31 12:11:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 Dec 2006 17:41:46 +0530 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167565930.14707.42.camel@localhost.localdomain> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167565930.14707.42.camel@localhost.localdomain> Message-ID: <4597A902.2010306@fedoraproject.org> Callum Lerwick wrote: > On Fri, 2006-12-29 at 11:19 -0500, Jesse Keating wrote: >> hrm, you must wear at least 5 pieces of flair... Seriously, a rule like this >> just encourages folks to check 5 things only and move on. If rules were set >> in place to make 5 specific things mandatory, that's all that will be >> checked. Lets not give reviewers a shortcut out. I'd be more in favor of a >> rule that just says "items checked need to be listed out in the review before >> building of the package will be allowed". Vague enough as to not give >> reviewers a shortcut. > > Which is the whole idea of my checklist. It follows the MUST list > basically point-for-point. (Some related stuff gets mushed together into > one item, like everything relating to %file lists, and directory/file > ownership.) Everything in the MUST list is a MUST, and thus... MUST be > checked. > > And really, the list is primarily for *my* benefit. To make sure *I* > don't miss any of them. I don't know how anyone could keep track of all > that in their head. And since I'm keeping a checklist anyway, I might as > well post it in the review. Regardless of whether the checklist is going to be used by everyone, since many people like the idea and use one on their own anyway, it would be better to add one to the review guidelines asap so that there is a common reference point. Rahul From bugs.michael at gmx.net Sun Dec 31 13:42:18 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 31 Dec 2006 14:42:18 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167564362.14707.26.camel@localhost.localdomain> References: <45951F62.4020302@leemhuis.info> <20061229171024.ec5430dc.bugs.michael@gmx.net> <20061229213025.3a7cff12.bugs.michael@gmx.net> <20061229225721.8e4f1693.bugs.michael@gmx.net> <1167564362.14707.26.camel@localhost.localdomain> Message-ID: <20061231144218.de4d655d.bugs.michael@gmx.net> On Sun, 31 Dec 2006 05:26:02 -0600, Callum Lerwick wrote: > > They learn best from submitting packages, from applying the guidelines to > > their own packages, and from trying to review packages. This is what they > > do once they maintain their package in CVS on their own without any peer > > reviewing. They cannot learn from a brief list of YES/NO answers or > > MUST/SHOULD items. Example: > > The problem with this, is in reality this can not scale. Not everyone > can submit and maintain packages. How does that contradict with what I've written above? I talk about how the possibly silent observers of bugzilla traffic can learn from stuff that is talked about during reviews, while you talk about scalability. Packaging needs hands-on experience. Reviewing needs hands-on experience. You cannot learn techniques from skimming over checklists. You need documentation (or guidance) on how to perform the checks yourself plus the creativity to check things beyond predefined checklists. > And people busy maintaining packages > don't tend to be interested or have the time to do reviews. Hell, I'll > admit that personally, I signed up to package stuff. Not to do reviews. > (I think I squeezed in just before the "must review other people's > packages" policy solidified I don't think it's a policy. It's supposed to encourage contributors to exchange reviews and at the same time demonstrate some of their skills. But I've never backed it up, because I don't think it works well. We have "sponsors". We don't need to force new contributors into looking for things they might review before they are permitted to maintain their packages in FE. You can require a new contributors to perform a few reviews reluctantly, then sponsor him, but some months later the contributor orphans his packages because of lack of interest or time, anyway. So, when put up the extra hurdle in front of the new contributors? Sponsor people as soon as they manage to push a new package through the review process, and assist them in case problems turn up. > and makes me feel a bit like I got in easy, > but hopefully I've made up for that by now.) Doing reviews is of little > interest to me, I've reviewed only a handfull of stuff I really > wanted/needed and that no one else was in any rush to review. For me it's different. I don't "own" more than a hand full of packages, because in my point of view it's better if we avoided the 50-packages-per-owner scheme and built many more teams that share the workload. However, interest in doing reviews is lowered due to metrics and systems that aim at quantity instead of quality. From jkeating at redhat.com Sun Dec 31 15:36:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 31 Dec 2006 10:36:25 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167567116.14707.53.camel@localhost.localdomain> References: <200612291736.11510.ville.skytta@iki.fi> <200612301139.03354.jkeating@redhat.com> <1167567116.14707.53.camel@localhost.localdomain> Message-ID: <200612311036.29394.jkeating@redhat.com> On Sunday 31 December 2006 07:11, Callum Lerwick wrote: > I don't see how this is relevant. I don't see how a checklist of MUST > items *couldn't* keep an honest person from missing a MUST item. I don't think arguing that having a condensed one line per rule checklist that could be consulted during review. I think this is a fine idea. What people (including me) are objecting to is forcing the reviewer to paste this list into the review bug. > If someone's intent on being actively dishonest, then we have a much > greater problem than some half-assed package reviews slipping by. Exactly. If there is a problem with somebody just saying "APPROVED" and not actually doing the review right, that same person will most likely just past the checklist and quickly fill it out (or use a pre-filled list) and STILL not actually review. This doesn't do anything to solve the problem it just hides it behind more useless noise. -- 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 Sun Dec 31 15:42:02 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 31 Dec 2006 10:42:02 -0500 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <1167565930.14707.42.camel@localhost.localdomain> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167565930.14707.42.camel@localhost.localdomain> Message-ID: <200612311042.02906.jkeating@redhat.com> On Sunday 31 December 2006 06:52, Callum Lerwick wrote: > Which is the whole idea of my checklist. It follows the MUST list > basically point-for-point. (Some related stuff gets mushed together into > one item, like everything relating to %file lists, and directory/file > ownership.) Everything in the MUST list is a MUST, and thus... MUST be > checked. > > And really, the list is primarily for *my* benefit. To make sure *I* > don't miss any of them. I don't know how anyone could keep track of all > that in their head. And since I'm keeping a checklist anyway, I might as > well post it in the review. > > Like Axel said, professional pilots and NASA astronauts keep pre and > post-flight checklists. (And in the case of NASA, a bazillion in > between...) I honestly don't understand how a professional packager > could be so against keeping a review checklist. Of MUST items. To each > their own I guess. I'm all for having a checklist. What I'm not for is adding more noise to the review that doesn't help. It doesn't solve the fundamental problem of "was this package correctly reviewed or not" and no amount of noise in a bug will help that. Back/forth on items that don't adhere to the guideline DOES help, but in the end, the only way to actually know if the review was done right is to look at the package yourself. And even then its a wash as the lazy reviewer could have just gotten lucky and the package was fine. So, checklist good. Dumping checklist into review bug not so useful. -- 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 Axel.Thimm at ATrpms.net Sun Dec 31 16:07:17 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 31 Dec 2006 17:07:17 +0100 Subject: Summary from yesterdays (mini) FESCo meeting In-Reply-To: <4597A902.2010306@fedoraproject.org> References: <45951F62.4020302@leemhuis.info> <200612291119.57073.jkeating@redhat.com> <1167565930.14707.42.camel@localhost.localdomain> <4597A902.2010306@fedoraproject.org> Message-ID: <20061231160717.GF396@neu.nirvana> On Sun, Dec 31, 2006 at 05:41:46PM +0530, Rahul Sundaram wrote: > Regardless of whether the checklist is going to be used by everyone, > since many people like the idea and use one on their own anyway, it > would be better to add one to the review guidelines asap so that there > is a common reference point. Very true - The checklist would have to be officially adopted for maintenance by the relevant entities, e.g. obviously mostly the packaging group, but there may be parts of the review guidelines that are out of our (the PC's) reach, so everyone entitled to change review and/or packaging guidelines would need to commit to adjust the MUST/SHOULD checklist items as well. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Dec 31 16:10:12 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 31 Dec 2006 17:10:12 +0100 Subject: Automate parts of review process? In-Reply-To: <1167540800.3328.609.camel@localhost.localdomain> References: <20061231043335.GB396@neu.nirvana> <1167540800.3328.609.camel@localhost.localdomain> Message-ID: <20061231161012.GG396@neu.nirvana> On Sat, Dec 30, 2006 at 10:53:20PM -0600, Tom 'spot' Callaway wrote: > On Sun, 2006-12-31 at 05:33 +0100, Axel Thimm wrote: > > I think large parts of the review process could be automated or at > > the very least aided, so that reviewers have less trivial stuff to > > check and can be reviewing more effectively. [...] Perhaps the > > review process itself could use a helper [...] > I will repeat what I have said in the past: If someone writes a good, > easy to use, open source tool to check for Fedora Packaging Compliance > (tm), then I think we would consider having all new packages > automatically run through that tool before human-review. > Short answer: Show me the tool. :) Well, I do feel challenged and I hope to find some time early in the new year to work on such a tool. Speaking of which: Since it's around the corner prepare for a Happy New Year! -- 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: