From ml at deadbabylon.de Thu Feb 1 10:49:08 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 1 Feb 2007 11:49:08 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <20070125134557.4055c232@localhost.localdomain> References: <20070125134557.4055c232@localhost.localdomain> Message-ID: <20070201114908.302d987b@localhost.localdomain> (One week later:) It seems that Hugo did not respond to the bug report [1] or this thread. What's next? 1) Wait another week? On his fotolog I've also discovered a msn account but I do not use msn for myself. (eitchugo at hotmail.com) 2) Reassign the packages [2] to other maintainers? If so I could take kerry. Sebastian [1] http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222184 [2] https://www.redhat.com/archives/fedora-extras-list/2007-January/msg00544.html (without ode) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Thu Feb 1 14:51:46 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 1 Feb 2007 09:51:46 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-01 Message-ID: <20070201145146.814EA15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 18 CCfits-1.6-2.fc7 aiccu-2007.01.15-1.fc7 bugzilla-2.22.1-5.fc7 cal3d-0.11.0-4.fc7 catfish-0.2d-1.fc7 chkrootkit-0.47-5.fc7 chmlib-0.39-1.fc7 comix-3.6.2-2.fc7 gnu-smalltalk-2.3.2-4.fc7 mpc-0.12.0-2.fc7 python-mutagen-1.10.1-1.fc7 NEW smashteroid-1.11-2.fc7 smolt-0.6.2-1.fc7 sysprof-kmod-1.0.8-1.2.6.19_1.2916.fc7 viaideinfo-0.5-1.fc7 wordpress-2.1-0.fc7 xine-lib-1.1.4-1.fc7 xmlstarlet-1.0.1-4.fc7 Packages built and released for Fedora Extras 6: 12 CCfits-1.6-2.fc6 aiccu-2007.01.15-1.fc6 bugzilla-2.22-11.fc6 catfish-0.2d-1.fc6 chkrootkit-0.47-2.fc6 chmlib-0.39-1.fc6 comix-3.6.2-2.fc6 gnu-smalltalk-2.3.2-4.fc6 python-mutagen-1.10.1-1.fc6 smolt-0.6.2-1.fc6 viaideinfo-0.5-1.fc6 wordpress-2.1-0.fc6 Packages built and released for Fedora Extras 5: 11 CCfits-1.6-2.fc5 aiccu-2007.01.15-1.fc5 bugzilla-2.22-10.fc5 catfish-0.2d-1.fc5 chkrootkit-0.47-2.fc5 chmlib-0.39-1.fc5 comix-3.6.2-2.fc5 gnu-smalltalk-2.3.2-4.fc5 python-mutagen-1.10.1-1.fc5 viaideinfo-0.5-1.fc5 wordpress-2.1-0.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Feb 1 15:49:50 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 01 Feb 2007 15:49:50 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-01 Message-ID: <20070201154950.5705.39631@extras64.linux.duke.edu> New report for: Jochen AT herr-schmitt.de package: gnu-smalltalk - 2.3.2-4.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so libtcl8.4.so package: gnu-smalltalk - 2.3.2-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: gnu-smalltalk - 2.3.2-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so libtcl8.4.so package: gnu-smalltalk - 2.3.2-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) ====================================================================== New report for: cgoorah AT yahoo.com.au package: xcircuit - 3.4.26-17.fc6.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: xcircuit - 3.4.26-17.fc6.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so libtcl8.4.so package: xcircuit - 3.4.26-17.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) ====================================================================== New report for: rdieter AT math.unl.edu package: geomview - 1.8.2-0.25.rc9.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so libtcl8.4.so package: geomview - 1.8.2-0.25.rc9.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: geomview - 1.8.2-0.25.rc9.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so libtcl8.4.so package: geomview - 1.8.2-0.25.rc9.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) ====================================================================== New report for: spr AT astrax.fis.ucm.es package: xpa - 2.1.6-7.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so package: xpa - 2.1.6-7.fc6.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so package: xpa - 2.1.6-7.fc6.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so package: xpa - 2.1.6-7.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) ====================================================================== New report for: jima AT beer.tclug.org package: graphviz-tcl - 2.12-3.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so package: graphviz-tcl - 2.12-3.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so package: graphviz-tcl - 2.12-3.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so()(64bit) ====================================================================== New report for: imlinux AT gmail.com package: sqlite2-tcl - 2.8.17-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so package: sqlite2-tcl - 2.8.17-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so package: sqlite2-tcl - 2.8.17-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) ====================================================================== New report for: garrick AT usc.edu package: torque-client - 2.1.6-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so libtk8.4.so package: torque-client - 2.1.6-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so libtk8.4.so package: torque-client - 2.1.6-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so()(64bit) libtcl8.4.so()(64bit) package: torque-gui - 2.1.6-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so libtk8.4.so /usr/bin/wish8.4 package: torque-gui - 2.1.6-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so libtk8.4.so /usr/bin/wish8.4 package: torque-gui - 2.1.6-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so()(64bit) libtcl8.4.so()(64bit) /usr/bin/wish8.4 ====================================================================== New report for: tcallawa AT redhat.com package: R - 2.4.1-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so libtk8.4.so package: R - 2.4.1-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so libtk8.4.so package: R - 2.4.1-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so libtk8.4.so package: R - 2.4.1-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) ====================================================================== New report for: green AT redhat.com package: vkeybd - 0.1.17a-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: tk < 0:8.5 libtk8.4.so libtcl8.4.so package: vkeybd - 0.1.17a-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: tk < 0:8.5 libtcl8.4.so libtk8.4.so package: vkeybd - 0.1.17a-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: tk < 0:8.5 libtk8.4.so()(64bit) libtcl8.4.so()(64bit) ====================================================================== New report for: gemi AT bluewin.ch package: gcl - 2.6.7-14.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: gcl - 2.6.7-14.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) package: labltk - 3.09.3-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so libtk8.4.so package: labltk - 3.09.3-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so libtk8.4.so package: labltk - 3.09.3-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so()(64bit) libtcl8.4.so()(64bit) package: q - 7.6-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so libtk8.4.so package: q - 7.6-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so libtk8.4.so package: skencil - 0.6.17-8.fc6.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: skencil - 0.6.17-8.fc6.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so libtcl8.4.so package: skencil - 0.6.17-8.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) ====================================================================== New report for: paul AT xelerance.com package: hping3 - 0.0.20051105-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so package: hping3 - 0.0.20051105-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so package: hping3 - 0.0.20051105-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) ====================================================================== New report for: nphilipp AT redhat.com package: ppracer - 0.3.1-8.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so package: ppracer - 0.3.1-8.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so package: ppracer - 0.3.1-8.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) ====================================================================== New report for: adrian AT lisas.de package: uudeview - 0.5.20-9.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so libtk8.4.so package: uudeview - 0.5.20-9.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so libtk8.4.so package: uudeview - 0.5.20-9.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so()(64bit) libtcl8.4.so()(64bit) ====================================================================== New report for: orion AT cora.nwra.com package: environment-modules - 3.2.3-3.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so package: environment-modules - 3.2.3-3.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so package: environment-modules - 3.2.3-3.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) package: plplot - 5.7.2-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so libtk8.4.so package: plplot - 5.7.2-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so libtk8.4.so package: plplot - 5.7.2-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so libtk8.4.so package: plplot - 5.7.2-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) package: plplot-tk - 5.7.2-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so libtcl8.4.so package: plplot-tk - 5.7.2-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: plplot-tk - 5.7.2-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so libtcl8.4.so package: plplot-tk - 5.7.2-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) libtk8.4.so()(64bit) package: python-matplotlib-tk - 0.87.7-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: python-matplotlib-tk - 0.87.7-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so libtcl8.4.so package: python-matplotlib-tk - 0.87.7-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so()(64bit) libtcl8.4.so()(64bit) ====================================================================== New report for: redhat-bugzilla AT linuxnetz.de package: eggdrop - 1.6.18-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.4.so package: eggdrop - 1.6.18-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.4.so package: eggdrop - 1.6.18-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.4.so()(64bit) ====================================================================== New report for: jamatos AT fc.up.pt package: python-imaging - 1.1.5-7.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so libtcl8.4.so package: python-imaging - 1.1.5-7.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.4.so libtcl8.4.so package: python-imaging - 1.1.5-7.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.4.so libtcl8.4.so package: python-imaging - 1.1.5-7.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.4.so()(64bit) libtcl8.4.so()(64bit) ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de gnu-smalltalk - 2.3.2-4.fc7.i386 gnu-smalltalk - 2.3.2-4.fc7.i386 gnu-smalltalk - 2.3.2-4.fc7.ppc gnu-smalltalk - 2.3.2-4.fc7.x86_64 adrian AT lisas.de uudeview - 0.5.20-9.i386 uudeview - 0.5.20-9.ppc uudeview - 0.5.20-9.x86_64 cgoorah AT yahoo.com.au toped - 0.8.2-2.fc6.i386 (48 days) toped - 0.8.2-2.fc6.ppc (48 days) toped - 0.8.2-2.fc6.x86_64 (48 days) xcircuit - 3.4.26-17.fc6.i386 xcircuit - 3.4.26-17.fc6.ppc xcircuit - 3.4.26-17.fc6.x86_64 dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (55 days) csound - 5.03.0-9.fc7.i386 (55 days) csound - 5.03.0-9.fc7.ppc (55 days) csound - 5.03.0-9.fc7.x86_64 (55 days) csound-python - 5.03.0-9.fc7.i386 (55 days) csound-python - 5.03.0-9.fc7.ppc (55 days) csound-python - 5.03.0-9.fc7.x86_64 (55 days) csound-tk - 5.03.0-9.fc7.i386 (55 days) csound-tk - 5.03.0-9.fc7.ppc (55 days) csound-tk - 5.03.0-9.fc7.x86_64 (55 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (57 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (57 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (57 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (57 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (57 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (57 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (57 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (55 days) garrick AT usc.edu torque-client - 2.1.6-1.fc7.i386 torque-client - 2.1.6-1.fc7.ppc torque-client - 2.1.6-1.fc7.x86_64 torque-gui - 2.1.6-1.fc7.i386 torque-gui - 2.1.6-1.fc7.ppc torque-gui - 2.1.6-1.fc7.x86_64 gauret AT free.fr amarok - 1.4.4-5.fc7.i386 (15 days) amarok - 1.4.4-5.fc7.i386 (15 days) amarok - 1.4.4-5.fc7.ppc (15 days) amarok - 1.4.4-5.fc7.x86_64 (15 days) gemi AT bluewin.ch gcl - 2.6.7-14.fc7.i386 gcl - 2.6.7-14.fc7.x86_64 labltk - 3.09.3-1.fc7.i386 labltk - 3.09.3-1.fc7.ppc labltk - 3.09.3-1.fc7.x86_64 q - 7.6-1.fc7.i386 q - 7.6-1.fc7.ppc skencil - 0.6.17-8.fc6.i386 skencil - 0.6.17-8.fc6.ppc skencil - 0.6.17-8.fc6.x86_64 giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.19_1.2916.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.19_1.2916.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.19_1.2916.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.19_1.2916.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.19_1.2916.fc7.x86_64 green AT redhat.com vkeybd - 0.1.17a-1.fc6.i386 vkeybd - 0.1.17a-1.fc6.ppc vkeybd - 0.1.17a-1.fc6.x86_64 ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (52 days) libreadline-java - 0.8.0-13.fc6.i386 (52 days) libreadline-java - 0.8.0-13.fc6.ppc (52 days) libreadline-java - 0.8.0-13.fc6.x86_64 (52 days) imlinux AT gmail.com sqlite2-tcl - 2.8.17-1.fc6.i386 sqlite2-tcl - 2.8.17-1.fc6.ppc sqlite2-tcl - 2.8.17-1.fc6.x86_64 jamatos AT fc.up.pt python-amara - 1.1.7-2.fc6.noarch (55 days) python-amara - 1.1.7-2.fc6.noarch (55 days) python-amara - 1.1.7-2.fc6.noarch (55 days) python-imaging - 1.1.5-7.fc7.i386 python-imaging - 1.1.5-7.fc7.i386 python-imaging - 1.1.5-7.fc7.ppc python-imaging - 1.1.5-7.fc7.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (115 days) linphone - 1.2.0-4.fc5.ppc (115 days) linphone - 1.2.0-4.fc5.x86_64 (115 days) jima AT beer.tclug.org graphviz-tcl - 2.12-3.fc7.i386 graphviz-tcl - 2.12-3.fc7.ppc graphviz-tcl - 2.12-3.fc7.x86_64 lmacken AT redhat.com python-cherrypy - 2.2.1-3.fc6.noarch (55 days) python-cherrypy - 2.2.1-3.fc6.noarch (55 days) python-cherrypy - 2.2.1-3.fc6.noarch (55 days) nphilipp AT redhat.com ppracer - 0.3.1-8.fc7.i386 ppracer - 0.3.1-8.fc7.ppc ppracer - 0.3.1-8.fc7.x86_64 orion AT cora.nwra.com environment-modules - 3.2.3-3.fc7.i386 environment-modules - 3.2.3-3.fc7.ppc environment-modules - 3.2.3-3.fc7.x86_64 paraview - 2.4.4-3.fc6.i386 (55 days) paraview - 2.4.4-3.fc6.ppc (55 days) paraview - 2.4.4-3.fc6.x86_64 (55 days) paraview-mpi - 2.4.4-3.fc6.i386 (55 days) paraview-mpi - 2.4.4-3.fc6.ppc (55 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (55 days) plplot - 5.7.2-1.fc7.i386 plplot - 5.7.2-1.fc7.i386 plplot - 5.7.2-1.fc7.ppc plplot - 5.7.2-1.fc7.x86_64 plplot-tk - 5.7.2-1.fc7.i386 plplot-tk - 5.7.2-1.fc7.i386 plplot-tk - 5.7.2-1.fc7.ppc plplot-tk - 5.7.2-1.fc7.x86_64 python-matplotlib-tk - 0.87.7-4.fc7.i386 python-matplotlib-tk - 0.87.7-4.fc7.ppc python-matplotlib-tk - 0.87.7-4.fc7.x86_64 paul AT xelerance.com hping3 - 0.0.20051105-5.fc7.i386 hping3 - 0.0.20051105-5.fc7.ppc hping3 - 0.0.20051105-5.fc7.x86_64 petersen AT redhat.com ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.i386 (10 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.ppc (10 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.x86_64 (10 days) rdieter AT math.unl.edu PyKDE - 3.16.0-5.fc7.i386 (55 days) PyKDE - 3.16.0-5.fc7.i386 (55 days) PyKDE - 3.16.0-5.fc7.ppc (55 days) PyKDE - 3.16.0-5.fc7.x86_64 (55 days) geomview - 1.8.2-0.25.rc9.fc7.i386 geomview - 1.8.2-0.25.rc9.fc7.i386 geomview - 1.8.2-0.25.rc9.fc7.ppc geomview - 1.8.2-0.25.rc9.fc7.x86_64 kdemultimedia-extras - 6:3.5.5-0.3.fc7.i386 (18 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.ppc (18 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.x86_64 (18 days) redhat-bugzilla AT linuxnetz.de eggdrop - 1.6.18-4.fc7.i386 eggdrop - 1.6.18-4.fc7.ppc eggdrop - 1.6.18-4.fc7.x86_64 shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (55 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-7.fc6.i386 xpa - 2.1.6-7.fc6.i386 xpa - 2.1.6-7.fc6.ppc xpa - 2.1.6-7.fc6.x86_64 stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (55 days) xmldiff - 0.6.7-12.fc6.ppc (55 days) xmldiff - 0.6.7-12.fc6.x86_64 (55 days) tcallawa AT redhat.com R - 2.4.1-1.fc7.i386 R - 2.4.1-1.fc7.i386 R - 2.4.1-1.fc7.ppc R - 2.4.1-1.fc7.x86_64 ville.skytta AT iki.fi em8300 - 0.16.0-3.fc7.i386 (36 days) em8300 - 0.16.0-3.fc7.ppc (36 days) em8300 - 0.16.0-3.fc7.x86_64 (36 days) ====================================================================== Broken packages in fedora-extras-5-i386: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.i386 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.ppc requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.x86_64 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 R-2.4.1-1.fc7.i386 requires libtcl8.4.so R-2.4.1-1.fc7.i386 requires libtk8.4.so amarok-1.4.4-5.fc7.i386 requires libmtp.so.4 amarok-1.4.4-5.fc7.i386 requires libgpod.so.0 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.i386 requires libtk8.4.so csound-tk-5.03.0-9.fc7.i386 requires libtcl8.4.so eggdrop-1.6.18-4.fc7.i386 requires libtcl8.4.so em8300-0.16.0-3.fc7.i386 requires em8300-kmod >= 0:0.16.0 environment-modules-3.2.3-3.fc7.i386 requires libtcl8.4.so gcl-2.6.7-14.fc7.i386 requires libtk8.4.so gcl-2.6.7-14.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so graphviz-tcl-2.12-3.fc7.i386 requires libtk8.4.so hping3-0.0.20051105-5.fc7.i386 requires libtcl8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.i386 requires libgstreamer-0.8.so.1 kmod-sysprof-1.0.8-1.2.6.19_1.2916.fc7.i586 requires kernel-i586 = 0:2.6.19-1.2916.fc7 kmod-sysprof-1.0.8-1.2.6.19_1.2916.fc7.i686 requires kernel-i686 = 0:2.6.19-1.2916.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.19_1.2916.fc7.i686 requires kernel-i686 = 0:2.6.19-1.2916.fc7PAE labltk-3.09.3-1.fc7.i386 requires libtcl8.4.so labltk-3.09.3-1.fc7.i386 requires libtk8.4.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 paraview-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-2.4.4-3.fc6.i386 requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so ppracer-0.3.1-8.fc7.i386 requires libtcl8.4.so python-amara-1.1.7-2.fc6.noarch requires python(abi) = 0:2.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.5-7.fc7.i386 requires libtk8.4.so python-imaging-1.1.5-7.fc7.i386 requires libtcl8.4.so python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtcl8.4.so python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 q-7.6-1.fc7.i386 requires libtcl8.4.so q-7.6-1.fc7.i386 requires libtk8.4.so skencil-0.6.17-8.fc6.i386 requires libtk8.4.so skencil-0.6.17-8.fc6.i386 requires libtcl8.4.so sqlite2-tcl-2.8.17-1.fc6.i386 requires libtcl8.4.so toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 torque-client-2.1.6-1.fc7.i386 requires libtcl8.4.so torque-client-2.1.6-1.fc7.i386 requires libtk8.4.so torque-gui-2.1.6-1.fc7.i386 requires libtcl8.4.so torque-gui-2.1.6-1.fc7.i386 requires libtk8.4.so torque-gui-2.1.6-1.fc7.i386 requires /usr/bin/wish8.4 uudeview-0.5.20-9.i386 requires libtcl8.4.so uudeview-0.5.20-9.i386 requires libtk8.4.so vkeybd-0.1.17a-1.fc6.i386 requires tk < 0:8.5 vkeybd-0.1.17a-1.fc6.i386 requires libtk8.4.so vkeybd-0.1.17a-1.fc6.i386 requires libtcl8.4.so xcircuit-3.4.26-17.fc6.i386 requires libtk8.4.so xcircuit-3.4.26-17.fc6.i386 requires libtcl8.4.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xpa-2.1.6-7.fc6.i386 requires libtcl8.4.so ====================================================================== Broken packages in fedora-extras-development-ppc: PyKDE-3.16.0-5.fc7.ppc requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.ppc requires python-abi = 0:2.4 R-2.4.1-1.fc7.ppc requires libtcl8.4.so R-2.4.1-1.fc7.ppc requires libtk8.4.so amarok-1.4.4-5.fc7.ppc requires libmtp.so.4 amarok-1.4.4-5.fc7.ppc requires libgpod.so.0 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.ppc requires libtcl8.4.so csound-tk-5.03.0-9.fc7.ppc requires libtk8.4.so eggdrop-1.6.18-4.fc7.ppc requires libtcl8.4.so em8300-0.16.0-3.fc7.ppc requires em8300-kmod >= 0:0.16.0 environment-modules-3.2.3-3.fc7.ppc requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtcl8.4.so graphviz-tcl-2.12-3.fc7.ppc requires libtk8.4.so hping3-0.0.20051105-5.fc7.ppc requires libtcl8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.ppc requires libgstreamer-0.8.so.1 labltk-3.09.3-1.fc7.ppc requires libtcl8.4.so labltk-3.09.3-1.fc7.ppc requires libtk8.4.so libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 paraview-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-2.4.4-3.fc6.ppc requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtcl8.4.so ppracer-0.3.1-8.fc7.ppc requires libtcl8.4.so python-amara-1.1.7-2.fc6.noarch requires python(abi) = 0:2.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.5-7.fc7.ppc requires libtk8.4.so python-imaging-1.1.5-7.fc7.ppc requires libtcl8.4.so python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtk8.4.so skencil-0.6.17-8.fc6.ppc requires libtk8.4.so skencil-0.6.17-8.fc6.ppc requires libtcl8.4.so sqlite2-tcl-2.8.17-1.fc6.ppc requires libtcl8.4.so toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 torque-client-2.1.6-1.fc7.ppc requires libtcl8.4.so torque-client-2.1.6-1.fc7.ppc requires libtk8.4.so torque-gui-2.1.6-1.fc7.ppc requires libtcl8.4.so torque-gui-2.1.6-1.fc7.ppc requires libtk8.4.so torque-gui-2.1.6-1.fc7.ppc requires /usr/bin/wish8.4 uudeview-0.5.20-9.ppc requires libtcl8.4.so uudeview-0.5.20-9.ppc requires libtk8.4.so vkeybd-0.1.17a-1.fc6.ppc requires tk < 0:8.5 vkeybd-0.1.17a-1.fc6.ppc requires libtcl8.4.so vkeybd-0.1.17a-1.fc6.ppc requires libtk8.4.so xcircuit-3.4.26-17.fc6.ppc requires libtk8.4.so xcircuit-3.4.26-17.fc6.ppc requires libtcl8.4.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xpa-2.1.6-7.fc6.ppc requires libtcl8.4.so ====================================================================== Broken packages in fedora-extras-development-x86_64: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python-abi = 0:2.4 R-2.4.1-1.fc7.i386 requires libtcl8.4.so R-2.4.1-1.fc7.i386 requires libtk8.4.so R-2.4.1-1.fc7.x86_64 requires libtcl8.4.so()(64bit) R-2.4.1-1.fc7.x86_64 requires libtk8.4.so()(64bit) amarok-1.4.4-5.fc7.i386 requires libmtp.so.4 amarok-1.4.4-5.fc7.i386 requires libgpod.so.0 amarok-1.4.4-5.fc7.x86_64 requires libmtp.so.4()(64bit) amarok-1.4.4-5.fc7.x86_64 requires libgpod.so.0()(64bit) csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtcl8.4.so()(64bit) eggdrop-1.6.18-4.fc7.x86_64 requires libtcl8.4.so()(64bit) em8300-0.16.0-3.fc7.x86_64 requires em8300-kmod >= 0:0.16.0 environment-modules-3.2.3-3.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtk8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtcl8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtk8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtcl8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtk8.4.so()(64bit) graphviz-tcl-2.12-3.fc7.x86_64 requires libtk8.4.so()(64bit) hping3-0.0.20051105-5.fc7.x86_64 requires libtcl8.4.so()(64bit) kdemultimedia-extras-6:3.5.5-0.3.fc7.x86_64 requires libgstreamer-0.8.so.1()(64bit) kmod-sysprof-1.0.8-1.2.6.19_1.2916.fc7.x86_64 requires kernel-x86_64 = 0:2.6.19-1.2916.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.19_1.2916.fc7.x86_64 requires kernel-x86_64 = 0:2.6.19-1.2916.fc7kdump labltk-3.09.3-1.fc7.x86_64 requires libtk8.4.so()(64bit) labltk-3.09.3-1.fc7.x86_64 requires libtcl8.4.so()(64bit) libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-tk-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) ppracer-0.3.1-8.fc7.x86_64 requires libtcl8.4.so()(64bit) python-amara-1.1.7-2.fc6.noarch requires python(abi) = 0:2.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.5-7.fc7.i386 requires libtk8.4.so python-imaging-1.1.5-7.fc7.i386 requires libtcl8.4.so python-imaging-1.1.5-7.fc7.x86_64 requires libtk8.4.so()(64bit) python-imaging-1.1.5-7.fc7.x86_64 requires libtcl8.4.so()(64bit) python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtk8.4.so()(64bit) python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtcl8.4.so()(64bit) skencil-0.6.17-8.fc6.x86_64 requires libtcl8.4.so()(64bit) skencil-0.6.17-8.fc6.x86_64 requires libtk8.4.so()(64bit) sqlite2-tcl-2.8.17-1.fc6.x86_64 requires libtcl8.4.so()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) torque-client-2.1.6-1.fc7.x86_64 requires libtk8.4.so()(64bit) torque-client-2.1.6-1.fc7.x86_64 requires libtcl8.4.so()(64bit) torque-gui-2.1.6-1.fc7.x86_64 requires libtk8.4.so()(64bit) torque-gui-2.1.6-1.fc7.x86_64 requires libtcl8.4.so()(64bit) torque-gui-2.1.6-1.fc7.x86_64 requires /usr/bin/wish8.4 uudeview-0.5.20-9.x86_64 requires libtk8.4.so()(64bit) uudeview-0.5.20-9.x86_64 requires libtcl8.4.so()(64bit) vkeybd-0.1.17a-1.fc6.x86_64 requires tk < 0:8.5 vkeybd-0.1.17a-1.fc6.x86_64 requires libtk8.4.so()(64bit) vkeybd-0.1.17a-1.fc6.x86_64 requires libtcl8.4.so()(64bit) xcircuit-3.4.26-17.fc6.x86_64 requires libtcl8.4.so()(64bit) xcircuit-3.4.26-17.fc6.x86_64 requires libtk8.4.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-7.fc6.i386 requires libtcl8.4.so xpa-2.1.6-7.fc6.x86_64 requires libtcl8.4.so()(64bit) From johan-fedora at deds.nl Thu Feb 1 17:15:34 2007 From: johan-fedora at deds.nl (Johan Kok) Date: Thu, 1 Feb 2007 18:15:34 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <20070201114908.302d987b@localhost.localdomain> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> Message-ID: <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> On 1-feb-2007, at 11:49, Sebastian Vahl wrote: > (One week later:) > It seems that Hugo did not respond to the bug report > [1] or this thread. What's next? > > 1) Wait another week? On his fotolog I've also discovered a msn > account > but I do not use msn for myself. (eitchugo at hotmail.com) Added that account and just spoke to him. He's not very available to work on FE packages at the moment. He will respond in this thread soon. Johan From bugzilla at redhat.com Fri Feb 2 05:43:14 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 2 Feb 2007 00:43:14 -0500 Subject: [Bug 169919] Review Request: m17n-db - multilingualization datafiles In-Reply-To: Message-ID: <200702020543.l125hEt6010407@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: m17n-db - multilingualization datafiles Alias: m17n-db-review https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169919 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com majain at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |majain at redhat.com Alias| |m17n-db-review -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Feb 2 05:43:20 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 2 Feb 2007 00:43:20 -0500 Subject: [Bug 169922] Review Request: m17n-lib - multilingual text library In-Reply-To: Message-ID: <200702020543.l125hKUQ010427@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: m17n-lib - multilingual text library Alias: m17n-lib-review https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169922 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com majain at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |majain at redhat.com Alias| |m17n-lib-review -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugs.michael at gmx.net Fri Feb 2 14:07:00 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 2 Feb 2007 15:07:00 +0100 Subject: Traceback during commit Message-ID: <20070202150700.69f03b0a.bugs.michael@gmx.net> I see this during commit to cvs/extras/rpms: [...] new revision: 1.4; previous revision: 1.3 done Traceback (most recent call last): File "/cvs/extras/CVSROOT/getnotifylist", line 34, in ? list = owners.getAclEmails(package, branch) File "/cvs/extras/CVSROOT/owners.py", line 240, in getAclEmails for o in self.packages_dict[package].owners: AttributeError: Package instance has no attribute 'owners' Running syncmail... [...] From notting at redhat.com Fri Feb 2 15:35:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Feb 2007 10:35:22 -0500 Subject: Traceback during commit In-Reply-To: <20070202150700.69f03b0a.bugs.michael@gmx.net> References: <20070202150700.69f03b0a.bugs.michael@gmx.net> Message-ID: <20070202153522.GB6613@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > I see this during commit to cvs/extras/rpms: > > [...] > new revision: 1.4; previous revision: 1.3 > done > Traceback (most recent call last): > File "/cvs/extras/CVSROOT/getnotifylist", line 34, in ? > list = owners.getAclEmails(package, branch) > File "/cvs/extras/CVSROOT/owners.py", line 240, in getAclEmails > for o in self.packages_dict[package].owners: > AttributeError: Package instance has no attribute 'owners' > Running syncmail... > [...] What package? Bill From bugs.michael at gmx.net Fri Feb 2 15:53:27 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 2 Feb 2007 16:53:27 +0100 Subject: Traceback during commit In-Reply-To: <20070202153522.GB6613@nostromo.devel.redhat.com> References: <20070202150700.69f03b0a.bugs.michael@gmx.net> <20070202153522.GB6613@nostromo.devel.redhat.com> Message-ID: <20070202165327.04b5652d.bugs.michael@gmx.net> On Fri, 2 Feb 2007 10:35:22 -0500, Bill Nottingham wrote: > > I see this during commit to cvs/extras/rpms: > > > > [...] > > new revision: 1.4; previous revision: 1.3 > > done > > Traceback (most recent call last): > > File "/cvs/extras/CVSROOT/getnotifylist", line 34, in ? > > list = owners.getAclEmails(package, branch) > > File "/cvs/extras/CVSROOT/owners.py", line 240, in getAclEmails > > for o in self.packages_dict[package].owners: > > AttributeError: Package instance has no attribute 'owners' > > Running syncmail... > > [...] > > What package? Four orphans: gdome2 perl-String-Ediff python-htmltmpl python-id3 From paul at xelerance.com Fri Feb 2 16:25:05 2007 From: paul at xelerance.com (Paul Wouters) Date: Fri, 2 Feb 2007 17:25:05 +0100 (CET) Subject: Manual Requires: behaviour changed? was :Broken dependencies in Fedora Extras - 2007-02-01 (fwd) Message-ID: I received an email with: > package: hping3 - 0.0.20051105-5.fc7.i386 from fedora-extras-development-i386 > unresolved deps: > libtcl8.4.so This has never before been an issue. In fact, according to the guidelines at http://fedoraproject.org/wiki/Packaging/Guidelines#Requires I am not supposed to manually add libraries, as rpm should pick them up per default. Hence, my package only includes a BuildRequires: tcl-devel and not a Requires: tcl. Did this behaviour change, or is the above script hit a false positive? Paul From wart at kobold.org Fri Feb 2 16:28:45 2007 From: wart at kobold.org (Wart) Date: Fri, 02 Feb 2007 08:28:45 -0800 Subject: Manual Requires: behaviour changed? was :Broken dependencies in Fedora Extras - 2007-02-01 (fwd) In-Reply-To: References: Message-ID: <45C366BD.6020708@kobold.org> Paul Wouters wrote: > I received an email with: > >> package: hping3 - 0.0.20051105-5.fc7.i386 from fedora-extras-development-i386 >> unresolved deps: >> libtcl8.4.so > > This has never before been an issue. In fact, according to the guidelines at > > http://fedoraproject.org/wiki/Packaging/Guidelines#Requires > > I am not supposed to manually add libraries, as rpm should pick them up per default. > Hence, my package only includes a BuildRequires: tcl-devel and not a Requires: tcl. > > Did this behaviour change, or is the above script hit a false positive? No, the behavior did not change, and the above script did not hit a false positive. Recently the version of Tcl was upgraded from 8.4 to 8.5. This came with a corresponding name change for the .so: libtcl8.4.so is no longer available, but libtcl8.5.so is. To fix, you just need to bump the release and rebuild your package. The rebuild will find the new libtcl8.5.so and set the requirement appropriately. --Wart From jamatos at fc.up.pt Fri Feb 2 16:31:16 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 2 Feb 2007 16:31:16 +0000 Subject: Manual Requires: behaviour changed? was :Broken dependencies in Fedora Extras - 2007-02-01 (fwd) In-Reply-To: References: Message-ID: <200702021631.16679.jamatos@fc.up.pt> On Friday 02 February 2007 4:25:05 pm Paul Wouters wrote: > > This has never before been an issue. In fact, according to the guidelines > at > > http://fedoraproject.org/wiki/Packaging/Guidelines#Requires > > I am not supposed to manually add libraries, as rpm should pick them up per > default. Hence, my package only includes a BuildRequires: tcl-devel and not > a Requires: tcl. > > Did this behaviour change, or is the above script hit a false positive? Nope. There is a new tcl version (8.5), usually in these cases you only need to rebuild your package against the new version and that is it. So a simple rebuild should be enough. :-) > Paul -- Jos? Ab?lio From ville.skytta at iki.fi Fri Feb 2 16:33:47 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 2 Feb 2007 18:33:47 +0200 Subject: Possibly unorphaning lirc-kmod(-common) In-Reply-To: <20070128152610.GA12091@ryvius.pekin.waw.pl> References: <20070128152610.GA12091@ryvius.pekin.waw.pl> Message-ID: <200702021833.47979.ville.skytta@iki.fi> On Sunday 28 January 2007 17:26, Dominik 'Rathann' Mierzejewski wrote: > Hello. > > I'm potentially interested in maintaining this for FC6+, provided I can > make it work with my TV card's IR control. My friend has a serial IR > adapter, so if all goes well, I'll have two devices to test it on. > > Is it acceptable to patch in a couple of kernel headers to make the gpio > module compile? So some headers required by gpio are not being shipped in kernel-devel? If that's correct, IMHO the answer is no unless it's for a short transition period only, eg. gpio heading towards upstream kernel, or movement towards having the required headers shipped in the kernel-devel packages. From paul at xelerance.com Fri Feb 2 16:38:09 2007 From: paul at xelerance.com (Paul Wouters) Date: Fri, 2 Feb 2007 17:38:09 +0100 (CET) Subject: Manual Requires: behaviour changed? was :Broken dependencies in Fedora Extras - 2007-02-01 (fwd) In-Reply-To: <45C366BD.6020708@kobold.org> References: <45C366BD.6020708@kobold.org> Message-ID: On Fri, 2 Feb 2007, Wart wrote: > Recently the version of Tcl was upgraded from 8.4 to 8.5. This came with a > corresponding name change for the .so: libtcl8.4.so is no longer available, > but libtcl8.5.so is. > > To fix, you just need to bump the release and rebuild your package. The > rebuild will find the new libtcl8.5.so and set the requirement appropriately. Ahh got it. Fired of rebuild request. thanks! Paul From buildsys at fedoraproject.org Fri Feb 2 22:14:57 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 2 Feb 2007 17:14:57 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-02 Message-ID: <20070202221457.F33C715212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 32 R-2.4.1-2.fc7 abiword-2.4.6-2.fc7 amsn-0.96-5.fc7 clips-6.24-22.fc7 NEW cycle-0.3.1-3.fc7 NEW dbus-qt-0.70-1.fc7 directfb-1.0.0-0.1.rc3.fc7 exaile-0.2.8-2.fc7 fatsort-0.9.7-1.fc7 ghdl-0.25-0.89svn.2.fc7 grads-1.9b4-20.fc7 hackedbox-0.8.5-1.fc7 hping3-0.0.20051105-6.fc7 jd-1.8.5-1.fc7 js-1.60-1.fc7 NEW kazehakase-0.4.4.1-1.fc7 lash-0.5.1-11.fc7 NEW libscigraphica-2.1.1-6.fc7 lighttpd-1.4.13-5.fc7 mhash-0.9.7.1-4 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.7-1.fc7 ppracer-0.3.1-9.fc7 rpmlint-0.79-1.fc7 NEW scigraphica-2.1.0-4.fc7 sysprof-kmod-1.0.8-1.2.6.19_1.2917.fc7 tcllib-1.9-2.fc7 tclxml-3.1-10.fc7 viruskiller-1.0-3.fc7 vkeybd-0.1.17a-2.fc7 xpa-2.1.6-8.fc7 xtide-2.9-0.3.RC1.fc7 zabbix-1.1.5-1.fc7 Packages built and released for Fedora Extras 6: 19 clips-6.24-22.fc6 NEW dbus-qt-0.70-1.fc6 exaile-0.2.8-2.fc6 fatsort-0.9.7-1.fc6 NEW greylistd-0.8.3.2-8.fc6 NEW gtk-rezlooks-engine-0.6-4.fc6 jd-1.8.5-1.fc6 knetworkmanager-0.1-0.6.svn20061113.fc6 NEW libscigraphica-2.1.1-6.fc6 NEW libsieve-2.2.4-2.fc6 NEW mailgraph-1.12-4.fc6 openvrml-0.16.3-2.fc6 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.7-1.fc6 rpmlint-0.79-1.fc6 NEW scigraphica-2.1.0-4.fc6 xine-lib-1.1.4-1.fc6 xtide-2.9-0.3.RC1.fc6 yafc-1.1.1-6.fc6 zabbix-1.1.5-1.fc6 Packages built and released for Fedora Extras 5: 8 clips-6.24-22.fc5 fatsort-0.9.7-1.fc5 NEW greylistd-0.8.3.2-8.fc5 jd-1.8.5-1.fc5 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.7-1.fc5 rpmlint-0.79-1.fc5 xtide-2.9-0.3.RC1.fc5 zabbix-1.1.5-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From garrick at usc.edu Sat Feb 3 08:29:59 2007 From: garrick at usc.edu (garrick) Date: Sat, 3 Feb 2007 00:29:59 -0800 Subject: [buildsys@fedoraproject.org: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras] Message-ID: <20070203082959.GX7558@polop.usc.edu> Any TCL experts around? I've never seen this error message before, and google doesn't find much. I'm just doing a rebuild because of tcl8.5 with no other changes. It builds fine under mock with fedora-devel-i386, but fails all 3 arches in plague. I even confirmed my fake root was using the same nvr tcl/tk packages as plague. http://buildsys.fedoraproject.org/logs/fedora-development-extras/26895-torque-2.1.6-2.fc7/ -- Garrick Staples, Linux/HPCC Administrator University of Southern California -------------- next part -------------- An embedded message was scrubbed... From: buildsys at fedoraproject.org Subject: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras Date: Sat, 03 Feb 2007 03:16:34 -0500 (EST) Size: 3105 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Sat Feb 3 14:10:30 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 3 Feb 2007 08:10:30 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-03 Message-ID: <20070203081030.A1216@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Sat Feb 3 07:41:25 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2568 Number failed to build: 82 Number expected to fail due to ExclusiveArch or ExcludeArch: 19 Leaving: 63 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 63 ---------------------------------- PyKDE-3.16.0-5.fc7 rdieter at math.unl.edu R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de amarok-1.4.4-5.fc7 gauret at free.fr atitvout-0.4-6 andreas.bierfert at lowlatency.de banshee-0.10.12-4.fc6 caillon at redhat.com comix-3.6.2-2.fc7 mtasaka at ioa.s.u-tokyo.ac.jp compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com daap-sharp-0.3.3-4.fc6 bdpepple at ameritech.net darcs-1.0.8-4.fc7 petersen at redhat.com djvulibre-3.5.17-2.fc6 matthias at rpmforge.net em8300-kmod-0.16.0-5.2.6.18_1.2869.fc6 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gforth-0.6.2-7.fc6 gemi at bluewin.ch gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnucap-0.34-3.fc6 j.w.r.degoede at hhs.nl gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gpgme-1.1.2-6.fc6.1 rdieter at math.unl.edu gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kdemultimedia-extras-3.5.5-0.3.fc7 rdieter at math.unl.edu kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kpolynome-0.1.2-7.fc6 cgoorah at yahoo.com.au kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libreadline-java-0.8.0-13.fc6 ifoox at redhat.com mlton-20061107-2.fc7 adam at spicenitz.org monodevelop-0.12-7.fc7 paul at all-the-johnsons.co.uk nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.1.6-1.fc6 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org powerman-1.0.24-3.fc6 jwilson at redhat.com prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.7-2.fc6 jamatos at fc.up.pt python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com python-reportlab-2.0-2.fc7 bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com rawstudio-0.4.1-2.fc6 giallu at gmail.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de tellico-1.2.6-1.fc7 jamatos at fc.up.pt toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Sat Feb 3 14:11:00 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 3 Feb 2007 08:11:00 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-02-03 Message-ID: <20070203081100.A1236@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Sat Feb 3 07:46:52 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2568 Number failed to build: 58 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 56 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 56 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de amarok-1.4.4-5.fc7 gauret at free.fr banshee-0.10.12-4.fc6 caillon at redhat.com comix-3.6.2-2.fc7 mtasaka at ioa.s.u-tokyo.ac.jp compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com darcs-1.0.8-4.fc7 petersen at redhat.com djvulibre-3.5.17-2.fc6 matthias at rpmforge.net em8300-kmod-0.16.0-5.2.6.18_1.2869.fc6 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gforth-0.6.2-7.fc6 gemi at bluewin.ch gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnucap-0.34-3.fc6 j.w.r.degoede at hhs.nl gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gpgme-1.1.2-6.fc6.1 rdieter at math.unl.edu gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kdemultimedia-extras-3.5.5-0.3.fc7 rdieter at math.unl.edu kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kpolynome-0.1.2-7.fc6 cgoorah at yahoo.com.au kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libreadline-java-0.8.0-13.fc6 ifoox at redhat.com lighttpd-1.4.13-5.fc7 matthias at rpmforge.net nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.1.6-1.fc6 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org powerman-1.0.24-3.fc6 jwilson at redhat.com python-amara-1.1.7-2.fc6 jamatos at fc.up.pt python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com rawstudio-0.4.1-2.fc6 giallu at gmail.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.19_1.2917.fc7 giallu at gmail.com tellico-1.2.6-1.fc7 jamatos at fc.up.pt toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From chris.stone at gmail.com Sat Feb 3 16:20:47 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 3 Feb 2007 08:20:47 -0800 Subject: Extras i386 rawhide rebuild in mock status 2007-02-03 In-Reply-To: <20070203081100.A1236@humbolt.us.dell.com> References: <20070203081100.A1236@humbolt.us.dell.com> Message-ID: On 2/3/07, Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for i386 Sat Feb 3 07:46:52 CST 2007 Any chance to sort these by owner e-mail rather than package name? From notting at redhat.com Sat Feb 3 16:50:44 2007 From: notting at redhat.com (Bill Nottingham) Date: Sat, 3 Feb 2007 11:50:44 -0500 Subject: Traceback during commit In-Reply-To: <20070202165327.04b5652d.bugs.michael@gmx.net> References: <20070202150700.69f03b0a.bugs.michael@gmx.net> <20070202153522.GB6613@nostromo.devel.redhat.com> <20070202165327.04b5652d.bugs.michael@gmx.net> Message-ID: <20070203165044.GA4753@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > > What package? > > Four orphans: gdome2 perl-String-Ediff python-htmltmpl python-id3 Fixed. Bill From buildsys at fedoraproject.org Sat Feb 3 18:04:48 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 3 Feb 2007 13:04:48 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-03 Message-ID: <20070203180448.0923715212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 17 banshee-0.11.5-1.fc7 clamav-0.90-0.2.rc3.fc7 eggdrop-1.6.18-5.fc7 ejabberd-1.1.3-1.fc7 emacs-vm-7.19-5.fc7 gforth-0.6.2-10.fc7 gnupg2-2.0.2-1.fc7 kazehakase-0.4.4.1-2.fc7 kshutdown-0.9.1beta-2.fc7 libextractor-0.5.17a-1.fc7 libtasn1-0.3.8-1.fc7 mimetic-0.9.2-1.fc7 openvrml-0.16.3-3.fc7 smart-0.50-44.fc7 tclsoap-1.6.7-3.fc7 xcircuit-3.4.26-18.fc7 xscreensaver-5.01-6.fc7 Packages built and released for Fedora Extras 6: 20 NEW csync2-1.33-4.fc6 eggdrop-1.6.18-5.fc6 ejabberd-1.1.3-1.fc6 emacs-vm-7.19-5.fc6 NEW fuse-smb-0.8.5-5.fc6 genius-0.7.7-1.fc6 NEW incron-0.5.0-1.fc6 kshutdown-0.9.1beta-2.fc6 libextractor-0.5.17a-1.fc6 libtasn1-0.3.8-1.fc6 mimetic-0.9.2-1.fc6 moomps-5.8-2.fc6 NEW pdns-recursor-3.1.4-4.fc6 NEW python-libtorrent-0.4.0-2.fc6 NEW rb_libtorrent-0.11-5.fc6 NEW seedit-2.1.0-0.15.beta6.7.fc6 skencil-0.6.17-10.fc6 NEW tango-icon-theme-extras-0.1.0-1.fc6 xcircuit-3.4.26-18.fc6 xscreensaver-5.01-6.fc6 Packages built and released for Fedora Extras 5: 17 NEW csync2-1.33-4.fc5 eggdrop-1.6.18-5.fc5 ejabberd-1.1.3-1.fc5 emacs-vm-7.19-5.fc5 NEW fuse-smb-0.8.5-5.fc5 genius-0.7.7-1.fc5 NEW incron-0.5.0-1.fc5 kshutdown-0.9.1beta-2.fc5 libextractor-0.5.17a-1.fc5 libtasn1-0.3.8-1.fc5 mimetic-0.9.2-1.fc5 moomps-5.8-2.fc5 NEW pdns-recursor-3.1.4-4.fc5 NEW python-libtorrent-0.4.0-2.fc5 NEW rb_libtorrent-0.11-5.fc5 NEW tango-icon-theme-extras-0.1.0-1.fc5 xcircuit-3.4.26-18.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From wart at kobold.org Sat Feb 3 23:04:11 2007 From: wart at kobold.org (Wart) Date: Sat, 03 Feb 2007 15:04:11 -0800 Subject: [buildsys@fedoraproject.org: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras] In-Reply-To: <20070203082959.GX7558@polop.usc.edu> References: <20070203082959.GX7558@polop.usc.edu> Message-ID: <45C514EB.1090601@kobold.org> garrick wrote: > Any TCL experts around? I've never seen this error message before, and > google doesn't find much. > > I'm just doing a rebuild because of tcl8.5 with no other changes. It > builds fine under mock with fedora-devel-i386, but fails all 3 arches in > plague. I even confirmed my fake root was using the same nvr tcl/tk > packages as plague. > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/26895-torque-2.1.6-2.fc7/ I've been able to reproduce this in a local mock build. It seems to only occur when I run tclsh from the Makefile, but not when run by hand. I'm still trying to find a solution or workaround... --Wart From garrick at usc.edu Sun Feb 4 02:19:06 2007 From: garrick at usc.edu (Garrick Staples) Date: Sat, 3 Feb 2007 18:19:06 -0800 Subject: [buildsys@fedoraproject.org: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras] In-Reply-To: <45C514EB.1090601@kobold.org> References: <20070203082959.GX7558@polop.usc.edu> <45C514EB.1090601@kobold.org> Message-ID: <20070204021906.GZ7558@polop.usc.edu> On Sat, Feb 03, 2007 at 03:04:11PM -0800, Wart alleged: > garrick wrote: > >Any TCL experts around? I've never seen this error message before, and > >google doesn't find much. > > > >I'm just doing a rebuild because of tcl8.5 with no other changes. It > >builds fine under mock with fedora-devel-i386, but fails all 3 arches in > >plague. I even confirmed my fake root was using the same nvr tcl/tk > >packages as plague. > > > >http://buildsys.fedoraproject.org/logs/fedora-development-extras/26895-torque-2.1.6-2.fc7/ > > I've been able to reproduce this in a local mock build. It seems to > only occur when I run tclsh from the Makefile, but not when run by hand. > I'm still trying to find a solution or workaround... Thanks for checking. I'm glad that at least someone else can trigger the problem. -- 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 seg at haxxed.com Sun Feb 4 09:56:56 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 04 Feb 2007 03:56:56 -0600 Subject: Mock, x86_64 and i386 Builds In-Reply-To: <45AFFB79.8040709@fedoraunity.org> References: <45AFFB79.8040709@fedoraunity.org> Message-ID: <1170583016.24387.8.camel@goat.booze> On Thu, 2007-01-18 at 15:58 -0700, Jonathan Steffan wrote: > Using mock, what needs to be done when a package needs both i386 and > x86_64 libs? > > http://gwenole.beauchesne.info/projects/nspluginwrapper/ > > http://www.damaestro.us/Members/jon/nspluginwrapper-0.9.91.2-2.src.rpm I attempted to package nspluginwrapper a while back: http://www.haxxed.com/rpms/nspluginwrapper-0.9.90.1-0.src.rpm Originally based on the upstream spec, but it got mostly rewrote as its approach was crackrock. Basically you build it for i386, it pops out an i386 subpackage that virtual provides nspluginwrapper-runtime-i386, then you build it for x86_64, and it pops out a package that depends on nspluginwrapper-runtime-i386. Put the two together in a repo and ta-da! However, I could not get the thing to actually work, it just segfaulted on start up, so I didn't go any farther. Maybe newer versions actually work. From buildsys at fedoraproject.org Sun Feb 4 11:31:30 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 4 Feb 2007 06:31:30 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-04 Message-ID: <20070204113130.D70BF15212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 8 cups-pdf-2.4.4-1.fc7 gpgme-1.1.3-1.fc7 katapult-0.3.1.4-4.fc7 kismet-0.0.2007.01.R1b-6.fc7 kpolynome-0.1.2-9.fc7 nqc-3.1.4-6.fc7 opencdk-0.5.13-1.fc7 xmlrpc-c-1.06.09-1.fc7 Packages built and released for Fedora Extras 6: 8 cups-pdf-2.4.4-1.fc6 katapult-0.3.1.4-4.fc6 kdmtheme-1.1.2-5.fc6 kpolynome-0.1.2-8.fc6 nqc-3.1.4-6.fc6 opencdk-0.5.13-1.fc6 puppet-0.22.1-1.fc6 xmlrpc-c-1.06.09-1.fc6 Packages built and released for Fedora Extras 5: 8 cups-pdf-2.4.4-1.fc5 katapult-0.3.1.4-4.fc5 kdmtheme-1.1.2-5.fc5 kpolynome-0.1.2-8.fc5 nqc-3.1.4-6.fc5 opencdk-0.5.13-1.fc5 puppet-0.22.1-1.fc5 xmlrpc-c-1.06.09-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dwmw2 at infradead.org Sun Feb 4 15:24:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 04 Feb 2007 15:24:03 +0000 Subject: Mock, x86_64 and i386 Builds In-Reply-To: <1170583016.24387.8.camel@goat.booze> References: <45AFFB79.8040709@fedoraunity.org> <1170583016.24387.8.camel@goat.booze> Message-ID: <1170602643.29759.688.camel@pmac.infradead.org> On Sun, 2007-02-04 at 03:56 -0600, Callum Lerwick wrote: > Basically you build it for i386, it pops out an i386 subpackage that > virtual provides nspluginwrapper-runtime-i386, then you build it for > x86_64, and it pops out a package that depends on > nspluginwrapper-runtime-i386. Put the two together in a repo and ta-da! > However, I could not get the thing to actually work, it just segfaulted > on start up, so I didn't go any farther. Maybe newer versions actually > work. I've had it working on PowerPC. Obviously I took the same approach of building the ppc and i386 parts on separate machines. qemu rocks :) -- dwmw2 From jwilson at redhat.com Sun Feb 4 17:47:21 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 04 Feb 2007 12:47:21 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-03 In-Reply-To: <20070203081030.A1216@humbolt.us.dell.com> References: <20070203081030.A1216@humbolt.us.dell.com> Message-ID: <45C61C29.3040000@redhat.com> Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for x86_64 Sat Feb 3 07:41:25 CST 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 2568 > Number failed to build: 82 > Number expected to fail due to ExclusiveArch or ExcludeArch: 19 > Leaving: 63 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 63 > ---------------------------------- [...] > powerman-1.0.24-3.fc6 jwilson at redhat.com [...] Easy fix, just need to tweak BR. This one is failing due to libwrap being split out into tcp_wrappers-libs now. -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Sun Feb 4 17:55:43 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 04 Feb 2007 12:55:43 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-03 In-Reply-To: <45C61C29.3040000@redhat.com> References: <20070203081030.A1216@humbolt.us.dell.com> <45C61C29.3040000@redhat.com> Message-ID: <45C61E1F.3000503@redhat.com> Jarod Wilson wrote: > Matt Domsch wrote: >> Extras Rawhide-in-Mock Build Results for x86_64 Sat Feb 3 07:41:25 >> CST 2007 >> >> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ >> >> Total packages: 2568 >> Number failed to build: 82 >> Number expected to fail due to ExclusiveArch or ExcludeArch: 19 >> Leaving: 63 >> (there may be some duplicates if rawhide has 2 versions of a package) >> >> Of those expected to have worked... >> Without a bug filed: 63 >> ---------------------------------- > [...] > > powerman-1.0.24-3.fc6 jwilson at redhat.com > [...] > > Easy fix, just need to tweak BR. This one is failing due to libwrap > being split out into tcp_wrappers-libs now. Er, rather, tcp_wrappers being split up to have a proper -devel package now (as well as a -libs package). -- Jarod Wilson jwilson at redhat.com From wart at kobold.org Sun Feb 4 19:22:30 2007 From: wart at kobold.org (Wart) Date: Sun, 04 Feb 2007 11:22:30 -0800 Subject: [buildsys@fedoraproject.org: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras] In-Reply-To: <20070204021906.GZ7558@polop.usc.edu> References: <20070203082959.GX7558@polop.usc.edu> <45C514EB.1090601@kobold.org> <20070204021906.GZ7558@polop.usc.edu> Message-ID: <45C63276.4030300@kobold.org> Garrick Staples wrote: > On Sat, Feb 03, 2007 at 03:04:11PM -0800, Wart alleged: >> garrick wrote: >>> Any TCL experts around? I've never seen this error message before, and >>> google doesn't find much. >>> >>> I'm just doing a rebuild because of tcl8.5 with no other changes. It >>> builds fine under mock with fedora-devel-i386, but fails all 3 arches in >>> plague. I even confirmed my fake root was using the same nvr tcl/tk >>> packages as plague. >>> >>> http://buildsys.fedoraproject.org/logs/fedora-development-extras/26895-torque-2.1.6-2.fc7/ >> I've been able to reproduce this in a local mock build. It seems to >> only occur when I run tclsh from the Makefile, but not when run by hand. >> I'm still trying to find a solution or workaround... > > Thanks for checking. I'm glad that at least someone else can trigger > the problem. One more data point, but no solution: A FC7-i386 mock build fails on a FC6-x86_64 build host, but succeeds on a FC7-i386 build host. I haven't been able to get gdb to work in the FC7 mock chroot on the FC6-x86_64 build host (is this even possible?), so it's been a little tricky to track this down. --Wart From buildsys at fedoraproject.org Sun Feb 4 20:48:58 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 4 Feb 2007 15:48:58 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-04 Message-ID: <20070204204858.ABA2815212F@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 12 clamav-0.90-0.3.rc3.fc7 NEW dolphin-0.8.1-1.fc7 incron-0.5.1-1.fc7 initng-0.6.9-3.fc7 initng-ifiles-0.0.7-1.fc7 jd-1.8.5-2.cvs070204.fc7 kismet-0.0.2007.01.R1b-7.fc7 NEW kpowersave-0.7.1-2.fc7 NEW liborigin-20070115-3.fc7 nmh-1.2-20070115cvs.3.fc7 pan-0.122-1.fc7 perl-Module-ScanDeps-0.72-1.fc7 Packages built and released for Fedora Extras 6: 5 NEW dolphin-0.8.1-1.fc6 NEW kazehakase-0.4.4.1-2.fc6.1 NEW kpowersave-0.7.1-2.fc6 NEW liborigin-20070115-3.fc6 pan-0.122-1.fc6 Packages built and released for Fedora Extras 5: 3 NEW dolphin-0.8.1-1.fc5 NEW kazehakase-0.4.4.1-2.fc5 NEW liborigin-20070115-3.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From mitr at volny.cz Sun Feb 4 20:54:53 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Sun, 04 Feb 2007 21:54:53 +0100 Subject: [buildsys@fedoraproject.org: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras] In-Reply-To: <45C63276.4030300@kobold.org> References: <20070203082959.GX7558@polop.usc.edu> <45C514EB.1090601@kobold.org> <20070204021906.GZ7558@polop.usc.edu> <45C63276.4030300@kobold.org> Message-ID: <45C6481D.8050106@volny.cz> Hi, Wart napsal(a): > One more data point, but no solution: A FC7-i386 mock build fails on a > FC6-x86_64 build host, but succeeds on a FC7-i386 build host. I haven't > been able to get gdb to work in the FC7 mock chroot on the FC6-x86_64 > build host (is this even possible?), so it's been a little tricky to > track this down. Jakub Jelinek has found and fixed the tcl bug, so try building it again as soon as tcl-8.5a5-7.fc7 appears in rawhide. Mirek From giallu at gmail.com Sun Feb 4 22:55:07 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 4 Feb 2007 23:55:07 +0100 Subject: Extras i386 rawhide rebuild in mock status 2007-02-03 In-Reply-To: <20070203081100.A1236@humbolt.us.dell.com> References: <20070203081100.A1236@humbolt.us.dell.com> Message-ID: On 2/3/07, Matt Domsch wrote: > rawstudio-0.4.1-2.fc6 giallu at gmail.com Do I have to add an "aclocal" call as suggested by the log: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-extras/i386/rawstudio-0.4.1-2.fc6.src.rpm/result/build.log or is there anything else needed? btw, thanks Matt for running this effort From garrick at usc.edu Sun Feb 4 23:00:07 2007 From: garrick at usc.edu (Garrick Staples) Date: Sun, 4 Feb 2007 15:00:07 -0800 Subject: [buildsys@fedoraproject.org: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras] In-Reply-To: <45C6481D.8050106@volny.cz> References: <20070203082959.GX7558@polop.usc.edu> <45C514EB.1090601@kobold.org> <20070204021906.GZ7558@polop.usc.edu> <45C63276.4030300@kobold.org> <45C6481D.8050106@volny.cz> Message-ID: <20070204230007.GB7558@polop.usc.edu> On Sun, Feb 04, 2007 at 09:54:53PM +0100, Miloslav Trmac alleged: > Hi, > Wart napsal(a): > > One more data point, but no solution: A FC7-i386 mock build fails on a > > FC6-x86_64 build host, but succeeds on a FC7-i386 build host. I haven't > > been able to get gdb to work in the FC7 mock chroot on the FC6-x86_64 > > build host (is this even possible?), so it's been a little tricky to > > track this down. > Jakub Jelinek has found and fixed the tcl bug, so try building it again > as soon as tcl-8.5a5-7.fc7 appears in rawhide. > Mirek Terrific! I'll check tomorrow or so. -- 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 giallu at gmail.com Mon Feb 5 08:54:13 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 5 Feb 2007 09:54:13 +0100 Subject: Fwd: Build Error (Job 26995): sysprof-kmod-1_0_8-1_kernel_2_6_19_1_2919_fc7 on fedora-development-extras In-Reply-To: <20070205082629.9134D15212F@buildsys.fedoraproject.org> References: <20070205082629.9134D15212F@buildsys.fedoraproject.org> Message-ID: ---------- Forwarded message ---------- From: buildsys at fedoraproject.org Date: Feb 5, 2007 9:26 AM Subject: Build Error (Job 26995): sysprof-kmod-1_0_8-1_kernel_2_6_19_1_2919_fc7 on fedora-development-extras To: giallu at gmail.com Job failed on arch i586 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/26995-sysprof-kmod-1.0.8-1.kernel_2.6.19_1.2919.fc7/ [...snip...] /var/lib/mock/fedora-development-i386-core-7b9db580f5a9b48ab77e70233cdead6fa0c590a9/root resolvedep 'kernel-devel-i586 = kernel-2.6.19-1.2919.fc7' No Package Found for kernel-devel-i586 = kernel-2.6.19-1.2919.fc7 Cleaning up... Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-7b9db580f5a9b48ab77e70233cdead6fa0c590a9/root/proc Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-7b9db580f5a9b48ab77e70233cdead6fa0c590a9/root/dev/pts Done. I'm not sure what is going on. I can see the kernel-devel package in the development repo... Any hint? From jamatos at fc.up.pt Mon Feb 5 13:07:53 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Mon, 5 Feb 2007 13:07:53 +0000 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-03 In-Reply-To: <45C61E1F.3000503@redhat.com> References: <20070203081030.A1216@humbolt.us.dell.com> <45C61C29.3040000@redhat.com> <45C61E1F.3000503@redhat.com> Message-ID: <200702051307.53991.jamatos@fc.up.pt> On Sunday 04 February 2007 5:55:43 pm Jarod Wilson wrote: > Er, rather, tcp_wrappers being split up to have a proper -devel package > now (as well as a -libs package). > > -- > Jarod Wilson > jwilson at redhat.com Thank you, I had the same problem with tellico. :-) -- Jos? Ab?lio From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 5 13:49:03 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 5 Feb 2007 14:49:03 +0100 Subject: Orphaning udftools In-Reply-To: <20061115111812.5fc921a6@python3.es.egwn.lan> References: <20061115111812.5fc921a6@python3.es.egwn.lan> Message-ID: <20070205144903.58542ecf@python3.es.egwn.lan> Matthias Saou wrote : > The udftools package seems to have been broken for a while : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168111 > > I'm not interested in maintaining a package from a dead upstream > project (last release is from 2004 and open bugs have been piling up > ever since), so I would like to offer it to someone else, or if no one > is interested... have it removed entirely from Extras for now. > > Project page : http://sourceforge.net/projects/linux-udf/ > > Possible start point to get it back into shape : > http://packages.debian.org/testing/source/udftools > (as you can see, the Debian patch is larger than the original > sources...) Not a single answer in nearly 3 months, so I'll orphan the package. To any CVS admin : Please orphan "udftools" in owners.list, thanks. I'll be closing the only open bug report against it as WONTFIX : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168111 As for the review it should have undergone... I guess it could be removed from the list : http://fedoraproject.org/wiki/ChristianIseli/PackageReviewStatus I've just added it to the Wiki OrphanedPackages page. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.46 0.39 0.46 From j.w.r.degoede at hhs.nl Mon Feb 5 16:19:20 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 Feb 2007 17:19:20 +0100 Subject: New new package process SUCKS! (read please) Message-ID: <45C75908.8040003@hhs.nl> Hi all, I just went through my first new package under the new process (aka package no 100, so I'm experienced in this). The mail below may seem flamebate but it is mean't very seriously, so please take it seriously. And the new process SUCKS! First of all as discussed earlier the new review with flags is both unclear / not very well documented and much more work then it used to be, without any clear arguments why we needed a new process in the first place -> SUCKS Then I wanted todo an import an it failed as I first needed to be in owners.list and that requires manual intervention by an CVS admin, so now I have the feeling that I need a CVS admin for any fart I want todo -> SUCKS The new ACL design is broken, the ACL's shouldn't work by owners.list, but instead by putting the owner in the acl in the initial import and then owners.list would "just" be used for bugzilla and not for CVS access / ACL, which in turn means that then anyone could be given rights to owners.list as things were -> problem solved. I know things are probably not that easy. But the current solution is not a solution its a cure worse then the disease! IOW it SUCKS! Regards, Hans From michel.salim at gmail.com Mon Feb 5 16:21:48 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 5 Feb 2007 11:21:48 -0500 Subject: [buildsys@fedoraproject.org: Build Error (Job 26895): torque-2_1_6-2_fc7 on fedora-development-extras] In-Reply-To: <45C514EB.1090601@kobold.org> References: <20070203082959.GX7558@polop.usc.edu> <45C514EB.1090601@kobold.org> Message-ID: <883cfe6d0702050821ra6ee4f1s547a87bdd7dd3a6f@mail.gmail.com> 2007/2/3, Wart : > garrick wrote: > > Any TCL experts around? I've never seen this error message before, and > > google doesn't find much. > > > > I'm just doing a rebuild because of tcl8.5 with no other changes. It > > builds fine under mock with fedora-devel-i386, but fails all 3 arches in > > plague. I even confirmed my fake root was using the same nvr tcl/tk > > packages as plague. > > > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/26895-torque-2.1.6-2.fc7/ > > I've been able to reproduce this in a local mock build. It seems to > only occur when I run tclsh from the Makefile, but not when run by hand. > I'm still trying to find a solution or workaround... > Does tclsh expect to find an attached display? I had a similar problem with a Python setup script that tried to verify that pygtk is installed by importing it and trapping exceptions. pygtk would fail to load without X. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From chris.stone at gmail.com Mon Feb 5 16:40:49 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 5 Feb 2007 08:40:49 -0800 Subject: New new package process SUCKS! (read please) In-Reply-To: <45C75908.8040003@hhs.nl> References: <45C75908.8040003@hhs.nl> Message-ID: On 2/5/07, Hans de Goede wrote: > First of all as discussed earlier the new review with flags is both > unclear / not very well documented and much more work then it used to > be, without any clear arguments why we needed a new process in the first > place -> SUCKS Actually here is the reasoning behind the change[1]: "After mulling this over a bit, I have decided that using tracking bugs with this review would be too confusing, as well as too slow to be usable in a work-flow, and would generate too much extraneous mail spam." Ironically, the new process is too confusing, too slow to be usable in a work-flow and it generates too much extranious mail spam. [1] https://www.redhat.com/archives/fedora-maintainers/2007-January/msg00340.html Regards, Chris From buildsys at fedoraproject.org Mon Feb 5 17:58:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 5 Feb 2007 12:58:35 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-05 Message-ID: <20070205175835.84B0F15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 29 beryl-core-0.1.9999.1-2.fc7 beryl-manager-0.1.9999.1-1.fc7 beryl-plugins-0.1.9999.1-1.fc7 beryl-settings-0.1.9999.1-2.fc7 bibletime-1.6.3b-2.fc7 deltarpm-3.3-6.fc7 djvulibre-3.5.18-1.fc7 emerald-0.1.9999.1-1.fc7 emerald-themes-0.1.9999.1-1.fc7 espeak-1.19-1.fc7 geda-gattrib-20061020-3.fc7 geda-gschem-20061020-3.fc7 gnonlin-0.10.7-1.fc7 gpsim-0.22.0-2.fc7 gtkwave-3.0.21-1.fc7 heliodor-0.1.9999.1-1.fc7 initng-ifiles-0.0.7-2.fc7 jd-1.8.5-2.cvs070205.fc7 mediawiki-1.9.2-33.fc7 ncftp-3.2.0-3.fc7 openalpp-20060714-3.fc7 osgal-20060903-3.fc7 pcb-0.20060822-9.fc7 php-extras-5.2.0-1.fc7 rlwrap-0.28-2.fc7 smart-0.50-45.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2922.fc7 tclxml-3.1-11.fc7 ucarp-1.2-7.fc7 Packages built and released for Fedora Extras 6: 11 deltarpm-3.3-6.fc6 espeak-1.19-1.fc6 geda-gattrib-20061020-3.fc6 geda-gschem-20061020-3.fc6 NEW gstreamer-plugins-pulse-0.9.4-4.fc6 gtkwave-3.0.21-1.fc6 openalpp-20060714-3.fc6 osgal-20060903-3.fc6 pcb-0.20060822-9.fc6 perl-Module-ScanDeps-0.72-1.fc6 smart-0.50-45.fc6 Packages built and released for Fedora Extras 5: 9 espeak-1.19-1.fc5 geda-gattrib-20061020-3.fc5 NEW gstreamer-plugins-pulse-0.9.4-4.fc5 gtkwave-3.0.21-1.fc5 openalpp-20060714-3.fc5 osgal-20060903-3.fc5 pcb-0.20060822-9.fc5 perl-Module-ScanDeps-0.72-1.fc5 smart-0.50-45.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Mon Feb 5 18:51:33 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 05 Feb 2007 18:51:33 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-05 Message-ID: <20070205185133.17043.12312@extras64.linux.duke.edu> New report for: jwilson AT redhat.com package: beryl - 0.1.9999.1-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: bdock >= 0:0.1.9999.1 package: beryl - 0.1.9999.1-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: bdock >= 0:0.1.9999.1 package: beryl - 0.1.9999.1-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: bdock >= 0:0.1.9999.1 package: beryl-kde - 0.1.9999.1-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: aquamarine >= 0:0.1.9999.1 package: beryl-kde - 0.1.9999.1-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: aquamarine >= 0:0.1.9999.1 package: beryl-kde - 0.1.9999.1-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: aquamarine >= 0:0.1.9999.1 ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de gnu-smalltalk - 2.3.2-4.fc7.i386 (4 days) gnu-smalltalk - 2.3.2-4.fc7.i386 (4 days) gnu-smalltalk - 2.3.2-4.fc7.ppc (4 days) gnu-smalltalk - 2.3.2-4.fc7.x86_64 (4 days) adrian AT lisas.de uudeview - 0.5.20-9.i386 (4 days) uudeview - 0.5.20-9.ppc (4 days) uudeview - 0.5.20-9.x86_64 (4 days) cgoorah AT yahoo.com.au toped - 0.8.2-2.fc6.i386 (52 days) toped - 0.8.2-2.fc6.ppc (52 days) toped - 0.8.2-2.fc6.x86_64 (52 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (59 days) csound - 5.03.0-9.fc7.i386 (59 days) csound - 5.03.0-9.fc7.ppc (59 days) csound - 5.03.0-9.fc7.x86_64 (59 days) csound-python - 5.03.0-9.fc7.i386 (59 days) csound-python - 5.03.0-9.fc7.ppc (59 days) csound-python - 5.03.0-9.fc7.x86_64 (59 days) csound-tk - 5.03.0-9.fc7.i386 (59 days) csound-tk - 5.03.0-9.fc7.ppc (59 days) csound-tk - 5.03.0-9.fc7.x86_64 (59 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (61 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (61 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (61 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (61 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (61 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (61 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (61 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (59 days) garrick AT usc.edu torque-client - 2.1.6-1.fc7.i386 (4 days) torque-client - 2.1.6-1.fc7.ppc (4 days) torque-client - 2.1.6-1.fc7.x86_64 (4 days) torque-gui - 2.1.6-1.fc7.i386 (4 days) torque-gui - 2.1.6-1.fc7.ppc (4 days) torque-gui - 2.1.6-1.fc7.x86_64 (4 days) gauret AT free.fr amarok - 1.4.4-5.fc7.i386 (19 days) amarok - 1.4.4-5.fc7.i386 (19 days) amarok - 1.4.4-5.fc7.ppc (19 days) amarok - 1.4.4-5.fc7.x86_64 (19 days) gemi AT bluewin.ch gcl - 2.6.7-14.fc7.i386 (4 days) gcl - 2.6.7-14.fc7.x86_64 (4 days) labltk - 3.09.3-1.fc7.i386 (4 days) labltk - 3.09.3-1.fc7.ppc (4 days) labltk - 3.09.3-1.fc7.x86_64 (4 days) q - 7.6-1.fc7.i386 (4 days) q - 7.6-1.fc7.ppc (4 days) skencil - 0.6.17-8.fc6.i386 (4 days) skencil - 0.6.17-8.fc6.ppc (4 days) skencil - 0.6.17-8.fc6.x86_64 (4 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (56 days) libreadline-java - 0.8.0-13.fc6.i386 (56 days) libreadline-java - 0.8.0-13.fc6.ppc (56 days) libreadline-java - 0.8.0-13.fc6.x86_64 (56 days) imlinux AT gmail.com sqlite2-tcl - 2.8.17-1.fc6.i386 (4 days) sqlite2-tcl - 2.8.17-1.fc6.ppc (4 days) sqlite2-tcl - 2.8.17-1.fc6.x86_64 (4 days) jamatos AT fc.up.pt python-amara - 1.1.7-2.fc6.noarch (59 days) python-amara - 1.1.7-2.fc6.noarch (59 days) python-amara - 1.1.7-2.fc6.noarch (59 days) python-imaging - 1.1.5-7.fc7.i386 (4 days) python-imaging - 1.1.5-7.fc7.i386 (4 days) python-imaging - 1.1.5-7.fc7.ppc (4 days) python-imaging - 1.1.5-7.fc7.x86_64 (4 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (119 days) linphone - 1.2.0-4.fc5.ppc (119 days) linphone - 1.2.0-4.fc5.x86_64 (119 days) jima AT beer.tclug.org graphviz-tcl - 2.12-3.fc7.i386 (4 days) graphviz-tcl - 2.12-3.fc7.ppc (4 days) graphviz-tcl - 2.12-3.fc7.x86_64 (4 days) jwilson AT redhat.com beryl - 0.1.9999.1-2.fc7.i386 beryl - 0.1.9999.1-2.fc7.ppc beryl - 0.1.9999.1-2.fc7.x86_64 beryl-kde - 0.1.9999.1-2.fc7.i386 beryl-kde - 0.1.9999.1-2.fc7.ppc beryl-kde - 0.1.9999.1-2.fc7.x86_64 lmacken AT redhat.com python-cherrypy - 2.2.1-3.fc6.noarch (59 days) python-cherrypy - 2.2.1-3.fc6.noarch (59 days) python-cherrypy - 2.2.1-3.fc6.noarch (59 days) orion AT cora.nwra.com environment-modules - 3.2.3-3.fc7.i386 (4 days) environment-modules - 3.2.3-3.fc7.ppc (4 days) environment-modules - 3.2.3-3.fc7.x86_64 (4 days) paraview - 2.4.4-3.fc6.i386 (59 days) paraview - 2.4.4-3.fc6.ppc (59 days) paraview - 2.4.4-3.fc6.x86_64 (59 days) paraview-mpi - 2.4.4-3.fc6.i386 (59 days) paraview-mpi - 2.4.4-3.fc6.ppc (59 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (59 days) plplot - 5.7.2-1.fc7.i386 (4 days) plplot - 5.7.2-1.fc7.i386 (4 days) plplot - 5.7.2-1.fc7.ppc (4 days) plplot - 5.7.2-1.fc7.x86_64 (4 days) plplot-tk - 5.7.2-1.fc7.i386 (4 days) plplot-tk - 5.7.2-1.fc7.i386 (4 days) plplot-tk - 5.7.2-1.fc7.ppc (4 days) plplot-tk - 5.7.2-1.fc7.x86_64 (4 days) python-matplotlib-tk - 0.87.7-4.fc7.i386 (4 days) python-matplotlib-tk - 0.87.7-4.fc7.ppc (4 days) python-matplotlib-tk - 0.87.7-4.fc7.x86_64 (4 days) petersen AT redhat.com ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.i386 (14 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.ppc (14 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.x86_64 (14 days) rdieter AT math.unl.edu PyKDE - 3.16.0-5.fc7.i386 (59 days) PyKDE - 3.16.0-5.fc7.i386 (59 days) PyKDE - 3.16.0-5.fc7.ppc (59 days) PyKDE - 3.16.0-5.fc7.x86_64 (59 days) geomview - 1.8.2-0.25.rc9.fc7.i386 (4 days) geomview - 1.8.2-0.25.rc9.fc7.i386 (4 days) geomview - 1.8.2-0.25.rc9.fc7.ppc (4 days) geomview - 1.8.2-0.25.rc9.fc7.x86_64 (4 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.i386 (22 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.ppc (22 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.x86_64 (22 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (59 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (59 days) xmldiff - 0.6.7-12.fc6.ppc (59 days) xmldiff - 0.6.7-12.fc6.x86_64 (59 days) ville.skytta AT iki.fi em8300 - 0.16.0-3.fc7.i386 (40 days) em8300 - 0.16.0-3.fc7.ppc (40 days) em8300 - 0.16.0-3.fc7.x86_64 (40 days) ====================================================================== Broken packages in fedora-extras-5-i386: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.i386 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.ppc requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.x86_64 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 amarok-1.4.4-5.fc7.i386 requires libmtp.so.4 amarok-1.4.4-5.fc7.i386 requires libgpod.so.0 beryl-0.1.9999.1-2.fc7.i386 requires bdock >= 0:0.1.9999.1 beryl-kde-0.1.9999.1-2.fc7.i386 requires aquamarine >= 0:0.1.9999.1 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.i386 requires libtk8.4.so csound-tk-5.03.0-9.fc7.i386 requires libtcl8.4.so em8300-0.16.0-3.fc7.i386 requires em8300-kmod >= 0:0.16.0 environment-modules-3.2.3-3.fc7.i386 requires libtcl8.4.so gcl-2.6.7-14.fc7.i386 requires libtk8.4.so gcl-2.6.7-14.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so graphviz-tcl-2.12-3.fc7.i386 requires libtk8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.i386 requires libgstreamer-0.8.so.1 labltk-3.09.3-1.fc7.i386 requires libtcl8.4.so labltk-3.09.3-1.fc7.i386 requires libtk8.4.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 paraview-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-2.4.4-3.fc6.i386 requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so python-amara-1.1.7-2.fc6.noarch requires python(abi) = 0:2.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.5-7.fc7.i386 requires libtk8.4.so python-imaging-1.1.5-7.fc7.i386 requires libtcl8.4.so python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtcl8.4.so python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 q-7.6-1.fc7.i386 requires libtcl8.4.so q-7.6-1.fc7.i386 requires libtk8.4.so skencil-0.6.17-8.fc6.i386 requires libtk8.4.so skencil-0.6.17-8.fc6.i386 requires libtcl8.4.so sqlite2-tcl-2.8.17-1.fc6.i386 requires libtcl8.4.so toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 torque-client-2.1.6-1.fc7.i386 requires libtcl8.4.so torque-client-2.1.6-1.fc7.i386 requires libtk8.4.so torque-gui-2.1.6-1.fc7.i386 requires libtcl8.4.so torque-gui-2.1.6-1.fc7.i386 requires libtk8.4.so torque-gui-2.1.6-1.fc7.i386 requires /usr/bin/wish8.4 uudeview-0.5.20-9.i386 requires libtcl8.4.so uudeview-0.5.20-9.i386 requires libtk8.4.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-ppc: PyKDE-3.16.0-5.fc7.ppc requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.ppc requires python-abi = 0:2.4 amarok-1.4.4-5.fc7.ppc requires libmtp.so.4 amarok-1.4.4-5.fc7.ppc requires libgpod.so.0 beryl-0.1.9999.1-2.fc7.ppc requires bdock >= 0:0.1.9999.1 beryl-kde-0.1.9999.1-2.fc7.ppc requires aquamarine >= 0:0.1.9999.1 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.ppc requires libtcl8.4.so csound-tk-5.03.0-9.fc7.ppc requires libtk8.4.so em8300-0.16.0-3.fc7.ppc requires em8300-kmod >= 0:0.16.0 environment-modules-3.2.3-3.fc7.ppc requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtcl8.4.so graphviz-tcl-2.12-3.fc7.ppc requires libtk8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.ppc requires libgstreamer-0.8.so.1 labltk-3.09.3-1.fc7.ppc requires libtcl8.4.so labltk-3.09.3-1.fc7.ppc requires libtk8.4.so libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 paraview-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-2.4.4-3.fc6.ppc requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtcl8.4.so python-amara-1.1.7-2.fc6.noarch requires python(abi) = 0:2.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.5-7.fc7.ppc requires libtk8.4.so python-imaging-1.1.5-7.fc7.ppc requires libtcl8.4.so python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtk8.4.so skencil-0.6.17-8.fc6.ppc requires libtk8.4.so skencil-0.6.17-8.fc6.ppc requires libtcl8.4.so sqlite2-tcl-2.8.17-1.fc6.ppc requires libtcl8.4.so toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 torque-client-2.1.6-1.fc7.ppc requires libtcl8.4.so torque-client-2.1.6-1.fc7.ppc requires libtk8.4.so torque-gui-2.1.6-1.fc7.ppc requires libtcl8.4.so torque-gui-2.1.6-1.fc7.ppc requires libtk8.4.so torque-gui-2.1.6-1.fc7.ppc requires /usr/bin/wish8.4 uudeview-0.5.20-9.ppc requires libtcl8.4.so uudeview-0.5.20-9.ppc requires libtk8.4.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python-abi = 0:2.4 amarok-1.4.4-5.fc7.i386 requires libmtp.so.4 amarok-1.4.4-5.fc7.i386 requires libgpod.so.0 amarok-1.4.4-5.fc7.x86_64 requires libmtp.so.4()(64bit) amarok-1.4.4-5.fc7.x86_64 requires libgpod.so.0()(64bit) beryl-0.1.9999.1-2.fc7.x86_64 requires bdock >= 0:0.1.9999.1 beryl-kde-0.1.9999.1-2.fc7.x86_64 requires aquamarine >= 0:0.1.9999.1 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtcl8.4.so()(64bit) em8300-0.16.0-3.fc7.x86_64 requires em8300-kmod >= 0:0.16.0 environment-modules-3.2.3-3.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtk8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtcl8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtk8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtcl8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtk8.4.so()(64bit) graphviz-tcl-2.12-3.fc7.x86_64 requires libtk8.4.so()(64bit) kdemultimedia-extras-6:3.5.5-0.3.fc7.x86_64 requires libgstreamer-0.8.so.1()(64bit) labltk-3.09.3-1.fc7.x86_64 requires libtk8.4.so()(64bit) labltk-3.09.3-1.fc7.x86_64 requires libtcl8.4.so()(64bit) libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-tk-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) python-amara-1.1.7-2.fc6.noarch requires python(abi) = 0:2.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.5-7.fc7.i386 requires libtk8.4.so python-imaging-1.1.5-7.fc7.i386 requires libtcl8.4.so python-imaging-1.1.5-7.fc7.x86_64 requires libtk8.4.so()(64bit) python-imaging-1.1.5-7.fc7.x86_64 requires libtcl8.4.so()(64bit) python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtk8.4.so()(64bit) python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtcl8.4.so()(64bit) skencil-0.6.17-8.fc6.x86_64 requires libtcl8.4.so()(64bit) skencil-0.6.17-8.fc6.x86_64 requires libtk8.4.so()(64bit) sqlite2-tcl-2.8.17-1.fc6.x86_64 requires libtcl8.4.so()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) torque-client-2.1.6-1.fc7.x86_64 requires libtk8.4.so()(64bit) torque-client-2.1.6-1.fc7.x86_64 requires libtcl8.4.so()(64bit) torque-gui-2.1.6-1.fc7.x86_64 requires libtk8.4.so()(64bit) torque-gui-2.1.6-1.fc7.x86_64 requires libtcl8.4.so()(64bit) torque-gui-2.1.6-1.fc7.x86_64 requires /usr/bin/wish8.4 uudeview-0.5.20-9.x86_64 requires libtk8.4.so()(64bit) uudeview-0.5.20-9.x86_64 requires libtcl8.4.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 From notting at redhat.com Mon Feb 5 21:02:34 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Feb 2007 16:02:34 -0500 Subject: New new package process SUCKS! (read please) In-Reply-To: <45C75908.8040003@hhs.nl> References: <45C75908.8040003@hhs.nl> Message-ID: <20070205210234.GH4858@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Then I wanted todo an import an it failed as I first needed to be in > owners.list and that requires manual intervention by an CVS admin, so > now I have the feeling that I need a CVS admin for any fart I want todo > -> SUCKS Mmm, hyperbole. Right now, the initial set up of a package needs done by the admin; currently this is adding an entry to the owners.list/ making the directory in CVS. In future it might be 'adding the entry to the package database and setting it up in the build system'. The step will still be needed, even though parts of it may change. Heck, I'd love to get it where the CVS branching stuff isn't a separate step. But that takes time and infrastructure, and there seems to be a dearth of people who want to touch the CVS stuff. > The new ACL design is broken, the ACL's shouldn't work by owners.list, > but instead by putting the owner in the acl in the initial import and > then owners.list would "just" be used for bugzilla and not for CVS > access / ACL, which in turn means that then anyone could be given rights > to owners.list as things were -> problem solved. I know things are > probably not that easy. But the current solution is not a solution its a > cure worse then the disease! IOW it SUCKS! owner in acl == anyone in acl can remove all the other owners. Bill From notting at redhat.com Mon Feb 5 21:56:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 5 Feb 2007 16:56:56 -0500 Subject: Orphaning udftools In-Reply-To: <20070205144903.58542ecf@python3.es.egwn.lan> References: <20061115111812.5fc921a6@python3.es.egwn.lan> <20070205144903.58542ecf@python3.es.egwn.lan> Message-ID: <20070205215656.GJ4858@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > To any CVS admin : Please orphan "udftools" in owners.list, thanks. Orphaned. Please send any repository removal requests, as necessary. Bill From ville.skytta at iki.fi Mon Feb 5 22:02:36 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 6 Feb 2007 00:02:36 +0200 Subject: Fwd: Build Error (Job 26995): sysprof-kmod-1_0_8-1_kernel_2_6_19_1_2919_fc7 on fedora-development-extras In-Reply-To: References: <20070205082629.9134D15212F@buildsys.fedoraproject.org> Message-ID: <200702060002.36916.ville.skytta@iki.fi> On Monday 05 February 2007 10:54, Gianluca Sforna wrote: > No Package Found for kernel-devel-i586 = kernel-2.6.19-1.2919.fc7 ^^^^^^^ > I'm not sure what is going on. I can see the kernel-devel package in > the development repo... > Any hint? See ^'s above :) From giallu at gmail.com Mon Feb 5 22:32:04 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 5 Feb 2007 23:32:04 +0100 Subject: Fwd: Build Error (Job 26995): sysprof-kmod-1_0_8-1_kernel_2_6_19_1_2919_fc7 on fedora-development-extras In-Reply-To: <200702060002.36916.ville.skytta@iki.fi> References: <20070205082629.9134D15212F@buildsys.fedoraproject.org> <200702060002.36916.ville.skytta@iki.fi> Message-ID: On 2/5/07, Ville Skytt? wrote: > On Monday 05 February 2007 10:54, Gianluca Sforna wrote: > > > No Package Found for kernel-devel-i586 = kernel-2.6.19-1.2919.fc7 > ^^^^^^^ > > > I'm not sure what is going on. I can see the kernel-devel package in > > the development repo... > > Any hint? > > See ^'s above :) today I did a rebuild against the new 2.6.20 and it went good... /me still confused From ville.skytta at iki.fi Mon Feb 5 23:03:41 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 6 Feb 2007 01:03:41 +0200 Subject: Fwd: Build Error (Job 26995): sysprof-kmod-1_0_8-1_kernel_2_6_19_1_2919_fc7 on fedora-development-extras In-Reply-To: References: <20070205082629.9134D15212F@buildsys.fedoraproject.org> <200702060002.36916.ville.skytta@iki.fi> Message-ID: <200702060103.42122.ville.skytta@iki.fi> On Tuesday 06 February 2007 00:32, Gianluca Sforna wrote: > On 2/5/07, Ville Skytt? wrote: > > On Monday 05 February 2007 10:54, Gianluca Sforna wrote: > > > No Package Found for kernel-devel-i586 = kernel-2.6.19-1.2919.fc7 > > > > ^^^^^^^ > > > > > I'm not sure what is going on. I can see the kernel-devel package in > > > the development repo... > > > Any hint? > > > > See ^'s above :) > > today I did a rebuild against the new 2.6.20 and it went good... > > /me still confused Looks at the ^'s above again, then :). Or this: http://cvs.fedora.redhat.com/viewcvs/devel/sysprof-kmod/sysprof-kmod.spec?root=extras&r1=1.32&r2=1.31&makepatch=1&diff_format=u Your earlier try had an extra "kernel-" at the start of the target kernel %{version}-%{release}. From giallu at gmail.com Mon Feb 5 23:08:54 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 6 Feb 2007 00:08:54 +0100 Subject: Fwd: Build Error (Job 26995): sysprof-kmod-1_0_8-1_kernel_2_6_19_1_2919_fc7 on fedora-development-extras In-Reply-To: <200702060103.42122.ville.skytta@iki.fi> References: <20070205082629.9134D15212F@buildsys.fedoraproject.org> <200702060002.36916.ville.skytta@iki.fi> <200702060103.42122.ville.skytta@iki.fi> Message-ID: On 2/6/07, Ville Skytt? wrote: > On Tuesday 06 February 2007 00:32, Gianluca Sforna wrote: > > On 2/5/07, Ville Skytt? wrote: > > > On Monday 05 February 2007 10:54, Gianluca Sforna wrote: > > > > No Package Found for kernel-devel-i586 = kernel-2.6.19-1.2919.fc7 > > > > > > ^^^^^^^ > > > > > > > I'm not sure what is going on. I can see the kernel-devel package in > > > > the development repo... > > > > Any hint? > > > > > > See ^'s above :) > > > > today I did a rebuild against the new 2.6.20 and it went good... > > > > /me still confused > > Looks at the ^'s above again, then :). Or this: > http://cvs.fedora.redhat.com/viewcvs/devel/sysprof-kmod/sysprof-kmod.spec?root=extras&r1=1.32&r2=1.31&makepatch=1&diff_format=u > > Your earlier try had an extra "kernel-" at the start of the target > kernel %{version}-%{release}. Ok. sorry for the dumbness. gmail's font positioned the ^^^^ chars under kernel-devel... however, that's the second time I hit the same prob :( hope it won't happend a third one /me going to refine the autorebuild script... From rc040203 at freenet.de Tue Feb 6 03:02:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Feb 2007 04:02:33 +0100 Subject: New new package process SUCKS! (read please) In-Reply-To: <20070205210234.GH4858@nostromo.devel.redhat.com> References: <45C75908.8040003@hhs.nl> <20070205210234.GH4858@nostromo.devel.redhat.com> Message-ID: <1170730953.1254.172.camel@mccallum.corsepiu.local> On Mon, 2007-02-05 at 16:02 -0500, Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > The new ACL design is broken, the ACL's shouldn't work by owners.list, > > but instead by putting the owner in the acl in the initial import and > > then owners.list would "just" be used for bugzilla and not for CVS > > access / ACL, which in turn means that then anyone could be given rights > > to owners.list as things were -> problem solved. I know things are > > probably not that easy. But the current solution is not a solution its a > > cure worse then the disease! IOW it SUCKS! > > owner in acl == anyone in acl can remove all the other owners. And where is the problem? Spell: Trust Spell: VCS Ralf From buildsys at fedoraproject.org Tue Feb 6 12:12:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 6 Feb 2007 07:12:45 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-06 Message-ID: <20070206121245.8D85415212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 15 audacity-1.3.2-7.20070106cvs.fc7 bdock-0.1.9999.1-1.fc7 csmash-0.6.6-14.fc7 NEW dxpc-3.9.1-0.2.b1.fc7 NEW irsim-9.7.41-5.fc7 NEW kalgebra-0.5-3.fc7 ktorrent-2.1-4.fc7 libsieve-2.2.5-1.fc7 liferea-1.2.5-1.fc7 proftpd-1.3.0a-3.fc7 python-amara-1.1.9-7.fc7 python-imaging-1.1.6-1.fc7 skencil-0.6.17-12.fc7 uudeview-0.5.20-10 yum-utils-1.0.2-1 Packages built and released for Fedora Extras 6: 19 aquamarine-0.1.9999.1-1.fc6 audacity-1.3.2-4.fc6 bdock-0.1.9999.1-1.fc6 beryl-core-0.1.9999.1-2.fc6 beryl-manager-0.1.9999.1-1.fc6 beryl-plugins-0.1.9999.1-1.fc6 beryl-settings-0.1.9999.1-2.fc6 NEW dxpc-3.9.1-0.2.b1.fc6 emerald-0.1.9999.1-1.fc6 emerald-themes-0.1.9999.1-1.fc6 heliodor-0.1.9999.1-1.fc6 NEW irsim-9.7.41-5.fc6 NEW kalgebra-0.5-3.fc6 ktorrent-2.1-4.fc6 libsieve-2.2.5-1.fc6 NEW netcdf-decoders-4.1.4-1.fc6 proftpd-1.3.0a-3.fc6 python-amara-1.1.9-7.fc6 python-imaging-1.1.6-1.fc6 Packages built and released for Fedora Extras 5: 5 ktorrent-2.1-4.fc5 NEW netcdf-decoders-4.1.4-1.fc5 proftpd-1.3.0a-3.fc5 python-amara-1.1.9-7.fc5 python-imaging-1.1.6-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From chitlesh at fedoraproject.org Tue Feb 6 12:22:55 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 6 Feb 2007 13:22:55 +0100 Subject: rpms/yum-utils/devel yum-utils.spec,1.15,1.16 In-Reply-To: <200702061118.l16BISHP016800@cvs-int.fedora.redhat.com> References: <200702061118.l16BISHP016800@cvs-int.fedora.redhat.com> Message-ID: <13dbfe4f0702060422v2f5efeddye59166e5a4a78251@mail.gmail.com> Hello Tim or seth, can you take a look at this RFE please https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218550 Chitlesh On 2/6/07, timlau Tim Lauridsen wrote: > Author: timlau > > Update of /cvs/extras/rpms/yum-utils/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16765/devel > > Modified Files: > yum-utils.spec > Log Message: > Added dist tag and bumped release -- http://clunixchit.blogspot.com From tla at rasmil.dk Tue Feb 6 18:05:44 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Tue, 06 Feb 2007 19:05:44 +0100 Subject: rpms/yum-utils/devel yum-utils.spec,1.15,1.16 In-Reply-To: <13dbfe4f0702060422v2f5efeddye59166e5a4a78251@mail.gmail.com> References: <200702061118.l16BISHP016800@cvs-int.fedora.redhat.com> <13dbfe4f0702060422v2f5efeddye59166e5a4a78251@mail.gmail.com> Message-ID: <45C8C378.4050100@rasmil.dk> Chitlesh GOORAH wrote: > Hello Tim or seth, > can you take a look at this RFE please > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218550 > > Chitlesh > > On 2/6/07, timlau Tim Lauridsen wrote: >> Author: timlau >> >> Update of /cvs/extras/rpms/yum-utils/devel >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16765/devel >> >> Modified Files: >> yum-utils.spec >> Log Message: >> Added dist tag and bumped release > I will take a look Tim From wtogami at redhat.com Tue Feb 6 18:55:21 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 13:55:21 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? Message-ID: <45C8CF19.30100@redhat.com> In automating processes needed for the Fedora VCS <-> Package Database <-> Bugzilla, we frequently hit an extreme annoyance that is slowing us down. The e-mail address registered in Fedora Account System (FAS) accounts do not always match those of Bugzilla accounts. It would *greatly* simplify our ability to move forward with needed infrastructure improvements if the two were unified. Proposal: All FAS accounts must match Bugzilla account addresses ================================================================ Implementation ============== 1) Most users are already fine. 2) Those users who do not yet match, they have the option of either: a) Change their FAS e-mail address. b) Change their Bugzilla address. (this requires a one-time change by dkl in the Bugzilla database) Benefits ======== - owners.list contains FAS account names instead of arbitrary e-mail addresses. - Those account names can be directly used by the VCS ACL - Simplified view in Package Database Key question ============ Is this an unreasonable requirement? Please comment. Warren Togami wtogami at redhat.com From notting at redhat.com Tue Feb 6 19:02:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 14:02:33 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <45C8CF19.30100@redhat.com> References: <45C8CF19.30100@redhat.com> Message-ID: <20070206190233.GG29861@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Implementation > ============== > 1) Most users are already fine. > 2) Those users who do not yet match, they have the option of either: > a) Change their FAS e-mail address. > b) Change their Bugzilla address. (this requires a one-time change > by dkl in the Bugzilla database) > > Benefits > ======== > - owners.list contains FAS account names instead of arbitrary e-mail > addresses. > - Those account names can be directly used by the VCS ACL > - Simplified view in Package Database > > Key question > ============ > Is this an unreasonable requirement? Please comment. The public availability of bugzilla e-mails has caused people to use specific e-mail addresses for that (presumably for spamtrapping); they may not want to use this for general Fedora mail. FWIW, the account<->bugzilla discrepancy applies to all of 8 users, at the moment. So I'm not sure how critical it is. Bill From Christian.Iseli at licr.org Tue Feb 6 19:08:15 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 6 Feb 2007 20:08:15 +0100 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <45C8CF19.30100@redhat.com> References: <45C8CF19.30100@redhat.com> Message-ID: <20070206200815.7abd8476@ludwig-alpha.unil.ch> On Tue, 06 Feb 2007 13:55:21 -0500, Warren Togami wrote: > Is this an unreasonable requirement? Please comment. No, sounds pretty sane to me. C From wtogami at redhat.com Tue Feb 6 19:11:03 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 14:11:03 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <20070206190233.GG29861@nostromo.devel.redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> Message-ID: <45C8D2C7.2070101@redhat.com> Bill Nottingham wrote: >> Key question >> ============ >> Is this an unreasonable requirement? Please comment. > > The public availability of bugzilla e-mails has caused people to > use specific e-mail addresses for that (presumably for spamtrapping); > they may not want to use this for general Fedora mail. > > FWIW, the account<->bugzilla discrepancy applies to all of 8 users, > at the moment. So I'm not sure how critical it is. > > Bill > Would there be any drawback to using FAS names directly now in owners.list, instead of Bugzilla addresses? Warren Togami wtogami at redhat.com From notting at redhat.com Tue Feb 6 19:12:15 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 14:12:15 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <45C8D2C7.2070101@redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <45C8D2C7.2070101@redhat.com> Message-ID: <20070206191215.GH29861@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Would there be any drawback to using FAS names directly now in > owners.list, instead of Bugzilla addresses? owners.list is used to manipulate the bugzilla info (that was its first use.) So, that script would need heavy modification. Bill From wtogami at redhat.com Tue Feb 6 19:53:24 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 14:53:24 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <20070206191215.GH29861@nostromo.devel.redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <45C8D2C7.2070101@redhat.com> <20070206191215.GH29861@nostromo.devel.redhat.com> Message-ID: <45C8DCB4.3040602@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >> Would there be any drawback to using FAS names directly now in >> owners.list, instead of Bugzilla addresses? > > owners.list is used to manipulate the bugzilla info (that was its > first use.) So, that script would need heavy modification. > > Bill > True, however it needs to also handle the ACL's now. Warren From Axel.Thimm at ATrpms.net Tue Feb 6 21:22:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 6 Feb 2007 22:22:44 +0100 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <20070206190233.GG29861@nostromo.devel.redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> Message-ID: <20070206212244.GC31898@neu.nirvana> On Tue, Feb 06, 2007 at 02:02:33PM -0500, Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: > > Implementation > > ============== > > 1) Most users are already fine. > > 2) Those users who do not yet match, they have the option of either: > > a) Change their FAS e-mail address. > > b) Change their Bugzilla address. (this requires a one-time change > > by dkl in the Bugzilla database) > > > > Benefits > > ======== > > - owners.list contains FAS account names instead of arbitrary e-mail > > addresses. > > - Those account names can be directly used by the VCS ACL > > - Simplified view in Package Database > > > > Key question > > ============ > > Is this an unreasonable requirement? Please comment. > > The public availability of bugzilla e-mails has caused people to > use specific e-mail addresses for that (presumably for spamtrapping); > they may not want to use this for general Fedora mail. But the mail is only exposed to other bugzilla registered users, so email scraping by spam bots is already prohibited to a large extend. > FWIW, the account<->bugzilla discrepancy applies to all of 8 users, > at the moment. So I'm not sure how critical it is. It makes sense to ask those 8 to use the FAS-account in bugzilla and close the matter :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Feb 6 22:31:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 17:31:32 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <45C8DCB4.3040602@redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <45C8D2C7.2070101@redhat.com> <20070206191215.GH29861@nostromo.devel.redhat.com> <45C8DCB4.3040602@redhat.com> Message-ID: <20070206223132.GA331@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > True, however it needs to also handle the ACL's now. The bugzilla script? Not really. Bill From notting at redhat.com Tue Feb 6 22:32:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 17:32:04 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <20070206212244.GC31898@neu.nirvana> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <20070206212244.GC31898@neu.nirvana> Message-ID: <20070206223204.GB331@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > It makes sense to ask those 8 to use the FAS-account in bugzilla and > close the matter :) I did. They said they didn't want to. Bill From wtogami at redhat.com Tue Feb 6 23:07:30 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Feb 2007 18:07:30 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <20070206223132.GA331@nostromo.devel.redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <45C8D2C7.2070101@redhat.com> <20070206191215.GH29861@nostromo.devel.redhat.com> <45C8DCB4.3040602@redhat.com> <20070206223132.GA331@nostromo.devel.redhat.com> Message-ID: <45C90A32.4090109@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >> True, however it needs to also handle the ACL's now. > > The bugzilla script? Not really. > > Bill > I mean, is it not logical to generate ACL's based on owners.list? Warren From notting at redhat.com Wed Feb 7 01:56:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Feb 2007 20:56:09 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <45C90A32.4090109@redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <45C8D2C7.2070101@redhat.com> <20070206191215.GH29861@nostromo.devel.redhat.com> <45C8DCB4.3040602@redhat.com> <20070206223132.GA331@nostromo.devel.redhat.com> <45C90A32.4090109@redhat.com> Message-ID: <20070207015609.GA3162@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > I mean, is it not logical to generate ACL's based on owners.list? Sorry, you've completely lost me. Bill From vonbrand at inf.utfsm.cl Wed Feb 7 02:34:02 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 06 Feb 2007 23:34:02 -0300 Subject: Getting upstream to include license files In-Reply-To: <20070125224050.GA9092@ryvius.pekin.waw.pl> References: <45B8F503.4000601@timj.co.uk> <20070125224050.GA9092@ryvius.pekin.waw.pl> Message-ID: <200702070234.l172Y2vS026665@laptop13.inf.utfsm.cl> Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 25 January 2007 at 19:20, Tim Jackson wrote: > > I have created the following suggested sample text to save people some > > time when asking upstream authors to include full license text in their > > packages: > > > > http://fedoraproject.org/wiki/PackagingDrafts/LicenseInclusionUpstreamRequest > > > > Any comments/changes welcome. I'm not trying to mandate that anyone > > should use this, just suggest that having a prewritten polite bit of > > boilerplate might save some time. > > > > If people like it generally then perhaps spot would consider including a > > link to it on the PackageReviewGuidelines under the relevant point about > > requesting upstream to include license text? > > Looks good to me. Some nits: > > s/This package/This software/ Nope. "Software" is a generic term, like "people". [Yes, a favorite nit of mine.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From Axel.Thimm at ATrpms.net Wed Feb 7 07:42:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 7 Feb 2007 08:42:47 +0100 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <20070206223204.GB331@nostromo.devel.redhat.com> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <20070206212244.GC31898@neu.nirvana> <20070206223204.GB331@nostromo.devel.redhat.com> Message-ID: <20070207074247.GB9462@neu.nirvana> On Tue, Feb 06, 2007 at 05:32:04PM -0500, Bill Nottingham wrote: > > > On Tue, Feb 06, 2007 at 01:55:21PM -0500, Warren Togami wrote: > > > > It would *greatly* simplify our ability to move forward with needed > > > > infrastructure improvements if the two were unified. > > > FWIW, the account<->bugzilla discrepancy applies to all of 8 users, > > > at the moment. So I'm not sure how critical it is. > > It makes sense to ask those 8 to use the FAS-account in bugzilla > > and close the matter :) > I did. They said they didn't want to. It seems unfair to generate more load on infrastructure's shoulders for these 8 people. As said the reason can't be that of fear of spam scraping as bugzilla (at least the implemenation currently used) protects the email from anonymous access. Can't these 8 users be brought to reason? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Feb 7 07:58:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 07 Feb 2007 08:58:42 +0100 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <20070207074247.GB9462@neu.nirvana> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <20070206212244.GC31898@neu.nirvana> <20070206223204.GB331@nostromo.devel.redhat.com> <20070207074247.GB9462@neu.nirvana> Message-ID: <45C986B2.7030907@leemhuis.info> On 07.02.2007 08:42, Axel Thimm wrote: > > It seems unfair to generate more load on infrastructure's shoulders > for these 8 people. While I agree to this... > As said the reason can't be that of fear of spam > scraping as bugzilla (at least the implemenation currently used) > protects the email from anonymous access. ...I have to disagree to this one, as the owners.list file in CVS is currently accessible to everyone, and thus the email used for bugzilla is not protected everywhere. But that might change with the PackageDB soon. > [...] CU thl From triad at df.lth.se Wed Feb 7 09:51:00 2007 From: triad at df.lth.se (Linus Walleij) Date: Wed, 7 Feb 2007 10:51:00 +0100 (CET) Subject: New new package process SUCKS! (read please) In-Reply-To: <20070205210234.GH4858@nostromo.devel.redhat.com> References: <45C75908.8040003@hhs.nl> <20070205210234.GH4858@nostromo.devel.redhat.com> Message-ID: On Mon, 5 Feb 2007, Bill Nottingham wrote: >> then owners.list would "just" be used for bugzilla and not for CVS >> access / ACL, > > owner in acl == anyone in acl can remove all the other owners. And who would do that? The entire Fedora project relies on good intentions, responsibility and trusted members. The only valid point is if there is a risk that someone does that by mistake, which is highly unlikely IMHO. Linus From buildsys at fedoraproject.org Wed Feb 7 11:48:34 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 7 Feb 2007 06:48:34 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-07 Message-ID: <20070207114834.3E6E115212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 29 amarok-1.4.5-1.fc7 aquamarine-0.1.9999.1-1.fc7 aterm-1.0.0-7.fc7 beryl-manager-0.1.9999.1-2.fc7 beryl-settings-0.1.9999.1-3.fc7 claws-mail-2.7.2-1.fc7 claws-mail-plugins-2.7.1-2.fc7 dnsmasq-2.37-1.fc7 NEW duel3-0.1-0.2.20060225.fc7 em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 exim-4.66-1.fc7 exim-doc-4.66-1.fc7 fcron-3.0.2-1.fc7 fuse-2.6.3-1.fc7 highlight-2.4.8-2.fc7 ladspa-swh-plugins-0.4.15-8.fc7 mew-5.2-1.fc7 nagios-2.7-2.fc7 optipng-0.5.5-1.fc7 pungi-0.2.3-1.fc7 qemu-0.9.0-1.fc7 scim-tomoe-0.5.0-3.fc7 seamonkey-1.1-2.fc7 shorewall-3.2.8-1.fc7 sweep-0.9.2-1.fc7 syslog-ng-1.6.12-1.fc7 torque-2.1.6-4.fc7 wine-docs-0.9.30-1.fc7 yum-utils-1.0.2-2.fc7 Packages built and released for Fedora Extras 6: 21 aterm-1.0.0-7.fc6 beryl-manager-0.1.9999.1-2.fc6 beryl-settings-0.1.9999.1-3.fc6 claws-mail-2.7.2-1.fc6 claws-mail-plugins-2.7.1-2.fc6 NEW duel3-0.1-0.2.20060225.fc6 fcron-3.0.2-1.fc6.1 fuse-2.6.3-1.fc6 highlight-2.4.8-2.fc6 ladspa-swh-plugins-0.4.15-8.fc6 libmtp-0.1.3-1.fc6 nagios-2.7-2.fc6 optipng-0.5.5-1.fc6 seamonkey-1.0.7-0.6.1.fc6 shorewall-3.2.8-1.fc6 NEW smashteroid-1.11-2.fc6 sweep-0.9.2-1.fc6 syslog-ng-1.6.12-1.fc6 tellico-1.2.8-1.fc6 wine-docs-0.9.30-1.fc6 yum-utils-1.0.2-2.fc6 Packages built and released for Fedora Extras 5: 13 PyRTF-0.45-2.fc5 claws-mail-2.7.2-1.fc5 claws-mail-plugins-2.7.1-2.fc5 fcron-3.0.2-1.fc5 fuse-2.6.3-1.fc5 highlight-2.4.8-2.fc5 libmtp-0.1.3-1.fc5 nagios-2.7-2.fc5 shorewall-3.2.8-1.fc5 sweep-0.9.2-1.fc5 syslog-ng-1.6.12-1.fc5 tellico-1.2.8-1.fc5 wine-docs-0.9.30-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 7 12:38:38 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 07 Feb 2007 12:38:38 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-07 Message-ID: <20070207123838.14958.37348@extras64.linux.duke.edu> New report for: gauret AT free.fr package: amarok - 1.4.4-1.fc5.i386 from fedora-extras-5-i386 unresolved deps: libmtp.so.2 package: amarok - 1.4.4-1.fc5.ppc from fedora-extras-5-ppc unresolved deps: libmtp.so.2 package: amarok - 1.4.4-1.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libmtp.so.2()(64bit) package: amarok - 1.4.4-7.fc6.i386 from fedora-extras-6-i386 unresolved deps: libmtp.so.2 package: amarok - 1.4.4-7.fc6.ppc from fedora-extras-6-ppc unresolved deps: libmtp.so.2 package: amarok - 1.4.4-7.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libmtp.so.2()(64bit) ====================================================================== New report for: triad AT df.lth.se package: gnomad2 - 2.8.9-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: libmtp.so.2 package: gnomad2 - 2.8.9-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: libmtp.so.2 package: gnomad2 - 2.8.9-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: libmtp.so.2()(64bit) package: gnomad2 - 2.8.9-2.fc6.i386 from fedora-extras-6-i386 unresolved deps: libmtp.so.2 package: gnomad2 - 2.8.9-2.fc6.ppc from fedora-extras-6-ppc unresolved deps: libmtp.so.2 package: gnomad2 - 2.8.9-2.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libmtp.so.2()(64bit) ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de gnu-smalltalk - 2.3.2-4.fc7.i386 (6 days) gnu-smalltalk - 2.3.2-4.fc7.i386 (6 days) gnu-smalltalk - 2.3.2-4.fc7.ppc (6 days) gnu-smalltalk - 2.3.2-4.fc7.x86_64 (6 days) cgoorah AT yahoo.com.au toped - 0.8.2-2.fc6.i386 (54 days) toped - 0.8.2-2.fc6.ppc (54 days) toped - 0.8.2-2.fc6.x86_64 (54 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (61 days) csound - 5.03.0-9.fc7.i386 (61 days) csound - 5.03.0-9.fc7.ppc (61 days) csound - 5.03.0-9.fc7.x86_64 (61 days) csound-python - 5.03.0-9.fc7.i386 (61 days) csound-python - 5.03.0-9.fc7.ppc (61 days) csound-python - 5.03.0-9.fc7.x86_64 (61 days) csound-tk - 5.03.0-9.fc7.i386 (61 days) csound-tk - 5.03.0-9.fc7.ppc (61 days) csound-tk - 5.03.0-9.fc7.x86_64 (61 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (63 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (63 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (63 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (63 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (63 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (63 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (63 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (61 days) gauret AT free.fr amarok - 1.4.4-1.fc5.i386 amarok - 1.4.4-1.fc5.ppc amarok - 1.4.4-1.fc5.x86_64 amarok - 1.4.4-7.fc6.i386 amarok - 1.4.4-7.fc6.ppc amarok - 1.4.4-7.fc6.x86_64 gemi AT bluewin.ch gcl - 2.6.7-14.fc7.i386 (6 days) gcl - 2.6.7-14.fc7.x86_64 (6 days) labltk - 3.09.3-1.fc7.i386 (6 days) labltk - 3.09.3-1.fc7.ppc (6 days) labltk - 3.09.3-1.fc7.x86_64 (6 days) q - 7.6-1.fc7.i386 (6 days) q - 7.6-1.fc7.ppc (6 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (58 days) libreadline-java - 0.8.0-13.fc6.i386 (58 days) libreadline-java - 0.8.0-13.fc6.ppc (58 days) libreadline-java - 0.8.0-13.fc6.x86_64 (58 days) imlinux AT gmail.com sqlite2-tcl - 2.8.17-1.fc6.i386 (6 days) sqlite2-tcl - 2.8.17-1.fc6.ppc (6 days) sqlite2-tcl - 2.8.17-1.fc6.x86_64 (6 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (121 days) linphone - 1.2.0-4.fc5.ppc (121 days) linphone - 1.2.0-4.fc5.x86_64 (121 days) jima AT beer.tclug.org graphviz-tcl - 2.12-3.fc7.i386 (6 days) graphviz-tcl - 2.12-3.fc7.ppc (6 days) graphviz-tcl - 2.12-3.fc7.x86_64 (6 days) lmacken AT redhat.com python-cherrypy - 2.2.1-3.fc6.noarch (61 days) python-cherrypy - 2.2.1-3.fc6.noarch (61 days) python-cherrypy - 2.2.1-3.fc6.noarch (61 days) orion AT cora.nwra.com environment-modules - 3.2.3-3.fc7.i386 (6 days) environment-modules - 3.2.3-3.fc7.ppc (6 days) environment-modules - 3.2.3-3.fc7.x86_64 (6 days) paraview - 2.4.4-3.fc6.i386 (61 days) paraview - 2.4.4-3.fc6.ppc (61 days) paraview - 2.4.4-3.fc6.x86_64 (61 days) paraview-mpi - 2.4.4-3.fc6.i386 (61 days) paraview-mpi - 2.4.4-3.fc6.ppc (61 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (61 days) plplot - 5.7.2-1.fc7.i386 (6 days) plplot - 5.7.2-1.fc7.i386 (6 days) plplot - 5.7.2-1.fc7.ppc (6 days) plplot - 5.7.2-1.fc7.x86_64 (6 days) plplot-tk - 5.7.2-1.fc7.i386 (6 days) plplot-tk - 5.7.2-1.fc7.i386 (6 days) plplot-tk - 5.7.2-1.fc7.ppc (6 days) plplot-tk - 5.7.2-1.fc7.x86_64 (6 days) python-matplotlib-tk - 0.87.7-4.fc7.i386 (6 days) python-matplotlib-tk - 0.87.7-4.fc7.ppc (6 days) python-matplotlib-tk - 0.87.7-4.fc7.x86_64 (6 days) petersen AT redhat.com ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.i386 (16 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.ppc (16 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.x86_64 (16 days) rdieter AT math.unl.edu PyKDE - 3.16.0-5.fc7.i386 (61 days) PyKDE - 3.16.0-5.fc7.i386 (61 days) PyKDE - 3.16.0-5.fc7.ppc (61 days) PyKDE - 3.16.0-5.fc7.x86_64 (61 days) geomview - 1.8.2-0.25.rc9.fc7.i386 (6 days) geomview - 1.8.2-0.25.rc9.fc7.i386 (6 days) geomview - 1.8.2-0.25.rc9.fc7.ppc (6 days) geomview - 1.8.2-0.25.rc9.fc7.x86_64 (6 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.i386 (24 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.ppc (24 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.x86_64 (24 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (61 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (61 days) xmldiff - 0.6.7-12.fc6.ppc (61 days) xmldiff - 0.6.7-12.fc6.x86_64 (61 days) triad AT df.lth.se gnomad2 - 2.8.9-2.fc5.i386 gnomad2 - 2.8.9-2.fc5.ppc gnomad2 - 2.8.9-2.fc5.x86_64 gnomad2 - 2.8.9-2.fc6.i386 gnomad2 - 2.8.9-2.fc6.ppc gnomad2 - 2.8.9-2.fc6.x86_64 ====================================================================== Broken packages in fedora-extras-5-i386: amarok-1.4.4-1.fc5.i386 requires libmtp.so.2 ghc642-gtk2hs-mozembed-0.9.10-2.fc5.i386 requires mozilla-devel = 37:1.7.13 gnomad2-2.8.9-2.fc5.i386 requires libmtp.so.2 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: amarok-1.4.4-1.fc5.ppc requires libmtp.so.2 ghc642-gtk2hs-mozembed-0.9.10-2.fc5.ppc requires mozilla-devel = 37:1.7.13 gnomad2-2.8.9-2.fc5.ppc requires libmtp.so.2 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: amarok-1.4.4-1.fc5.x86_64 requires libmtp.so.2()(64bit) ghc642-gtk2hs-mozembed-0.9.10-2.fc5.x86_64 requires mozilla-devel = 37:1.7.13 gnomad2-2.8.9-2.fc5.x86_64 requires libmtp.so.2()(64bit) linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-6-i386: amarok-1.4.4-7.fc6.i386 requires libmtp.so.2 gnomad2-2.8.9-2.fc6.i386 requires libmtp.so.2 ====================================================================== Broken packages in fedora-extras-6-ppc: amarok-1.4.4-7.fc6.ppc requires libmtp.so.2 gnomad2-2.8.9-2.fc6.ppc requires libmtp.so.2 ====================================================================== Broken packages in fedora-extras-6-x86_64: amarok-1.4.4-7.fc6.x86_64 requires libmtp.so.2()(64bit) gnomad2-2.8.9-2.fc6.x86_64 requires libmtp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.i386 requires libtk8.4.so csound-tk-5.03.0-9.fc7.i386 requires libtcl8.4.so environment-modules-3.2.3-3.fc7.i386 requires libtcl8.4.so gcl-2.6.7-14.fc7.i386 requires libtk8.4.so gcl-2.6.7-14.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so graphviz-tcl-2.12-3.fc7.i386 requires libtk8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.i386 requires libgstreamer-0.8.so.1 labltk-3.09.3-1.fc7.i386 requires libtcl8.4.so labltk-3.09.3-1.fc7.i386 requires libtk8.4.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 paraview-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-2.4.4-3.fc6.i386 requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtcl8.4.so python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 q-7.6-1.fc7.i386 requires libtcl8.4.so q-7.6-1.fc7.i386 requires libtk8.4.so sqlite2-tcl-2.8.17-1.fc6.i386 requires libtcl8.4.so toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-ppc: PyKDE-3.16.0-5.fc7.ppc requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.ppc requires python-abi = 0:2.4 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.ppc requires libtcl8.4.so csound-tk-5.03.0-9.fc7.ppc requires libtk8.4.so environment-modules-3.2.3-3.fc7.ppc requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtcl8.4.so graphviz-tcl-2.12-3.fc7.ppc requires libtk8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.ppc requires libgstreamer-0.8.so.1 labltk-3.09.3-1.fc7.ppc requires libtcl8.4.so labltk-3.09.3-1.fc7.ppc requires libtk8.4.so libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 paraview-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-2.4.4-3.fc6.ppc requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtcl8.4.so python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtk8.4.so sqlite2-tcl-2.8.17-1.fc6.ppc requires libtcl8.4.so toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python-abi = 0:2.4 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtcl8.4.so()(64bit) environment-modules-3.2.3-3.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtk8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtcl8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtk8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtcl8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtk8.4.so()(64bit) graphviz-tcl-2.12-3.fc7.x86_64 requires libtk8.4.so()(64bit) kdemultimedia-extras-6:3.5.5-0.3.fc7.x86_64 requires libgstreamer-0.8.so.1()(64bit) labltk-3.09.3-1.fc7.x86_64 requires libtk8.4.so()(64bit) labltk-3.09.3-1.fc7.x86_64 requires libtcl8.4.so()(64bit) libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-tk-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtk8.4.so()(64bit) python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtcl8.4.so()(64bit) sqlite2-tcl-2.8.17-1.fc6.x86_64 requires libtcl8.4.so()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 From paul at xelerance.com Wed Feb 7 14:26:23 2007 From: paul at xelerance.com (Paul Wouters) Date: Wed, 7 Feb 2007 15:26:23 +0100 (CET) Subject: New new package process SUCKS! (read please) In-Reply-To: References: <45C75908.8040003@hhs.nl> <20070205210234.GH4858@nostromo.devel.redhat.com> Message-ID: On Wed, 7 Feb 2007, Linus Walleij wrote: > And who would do that? The entire Fedora project relies on good intentions, > responsibility and trusted members. That's a bug, not a feature. Paul From ville.skytta at iki.fi Wed Feb 7 16:45:29 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 7 Feb 2007 18:45:29 +0200 Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) In-Reply-To: <20070207123838.14958.37348@extras64.linux.duke.edu> References: <20070207123838.14958.37348@extras64.linux.duke.edu> Message-ID: <200702071845.29559.ville.skytta@iki.fi> On Wednesday 07 February 2007 14:38, Fedora Extras repoclosure wrote: > package: amarok - 1.4.4-1.fc5.i386 from fedora-extras-5-i386 > unresolved deps: > libmtp.so.2 Ditto: > package: amarok - 1.4.4-1.fc5.ppc from fedora-extras-5-ppc > package: amarok - 1.4.4-1.fc5.x86_64 from fedora-extras-5-x86_64 > package: amarok - 1.4.4-7.fc6.i386 from fedora-extras-6-i386 > package: amarok - 1.4.4-7.fc6.ppc from fedora-extras-6-ppc > package: amarok - 1.4.4-7.fc6.x86_64 from fedora-extras-6-x86_64 > package: gnomad2 - 2.8.9-2.fc5.i386 from fedora-extras-5-i386 > package: gnomad2 - 2.8.9-2.fc5.ppc from fedora-extras-5-ppc > package: gnomad2 - 2.8.9-2.fc5.x86_64 from fedora-extras-5-x86_64 > package: gnomad2 - 2.8.9-2.fc6.i386 from fedora-extras-6-i386 > package: gnomad2 - 2.8.9-2.fc6.ppc from fedora-extras-6-ppc > package: gnomad2 - 2.8.9-2.fc6.x86_64 from fedora-extras-6-x86_64 Linus, was the soname change of libmtp announced somewhere in public beforehand? Why was it necessary push the update to non-devel distros? Apologies if I missed the announcement, but based on the above list of breakage I'm not alone even within Fedora maintainers, let alone elsewhere. In case you're not aware of it, yum (more or less by design AFAIK) bumps the severity of a single dependency problem among a batch of updates into the *sum* of all other problems fixed in the batch, including security ones and across all repos, by refusing to install any of them unless the user manually cherry picks the packages not affected by the dependency issue separately. This is what users of amarok and/or gnomad2 on FC-5 and FC-6 have to deal with right now, and maintainers need to take it extra carefully into account at all times as long as yum has anywhere near the significant role it currently has or is fixed. FESCO, what's the status of the incompatible package upgrade policy? I didn't find it in Wiki nor the FESCO schedule. At the very least, instructions how packagers must communicate (where, how long beforehand, rationale of the update) incoming incompatible upgrades needs to be put somewhere and people made aware of it. From igor.zubkov at gmail.com Wed Feb 7 17:22:17 2007 From: igor.zubkov at gmail.com (Igor Zubkov) Date: Wed, 07 Feb 2007 19:22:17 +0200 Subject: Q: howto contribute to Fedora Extras new package? Message-ID: <1170868937.3230.14.camel@localhost.localdomain> Hello, All! I am newbie here and i want to contrib package to fedora. So, what i am must read before this? (wiki etc?) From limb at jcomserv.net Wed Feb 7 17:23:44 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 7 Feb 2007 11:23:44 -0600 (CST) Subject: Q: howto contribute to Fedora Extras new package? In-Reply-To: <1170868937.3230.14.camel@localhost.localdomain> References: <1170868937.3230.14.camel@localhost.localdomain> Message-ID: <35195.65.192.24.190.1170869024.squirrel@mail.jcomserv.net> http://fedoraproject.org/wiki/Extras/Contributors This should help. > Hello, All! > > I am newbie here and i want to contrib package to fedora. So, what i am > must read before this? (wiki etc?) > > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From wtogami at redhat.com Wed Feb 7 21:05:40 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Feb 2007 16:05:40 -0500 Subject: RFC: FAS E-mail == Bugzilla E-mail? In-Reply-To: <45C986B2.7030907@leemhuis.info> References: <45C8CF19.30100@redhat.com> <20070206190233.GG29861@nostromo.devel.redhat.com> <20070206212244.GC31898@neu.nirvana> <20070206223204.GB331@nostromo.devel.redhat.com> <20070207074247.GB9462@neu.nirvana> <45C986B2.7030907@leemhuis.info> Message-ID: <45CA3F24.8020402@redhat.com> Thorsten Leemhuis wrote: > > But that might change with the PackageDB soon. > Ideally we want to use FAS account name everywhere, and FAS just knows what your e-mail address is and deals with it. I think it is stupid that we are using bugzilla addresses in owners.list. We should fix this after we stabilize the package review process. BTW, *PLEASE* comment on my posts from today on fedora-maintainers list regarding changes to the review and CVS admin process. If you are not yet subscribed to fedora-maintainers and you think you should be based upon your contributions to Fedora, talk to me directly. Warren Toogami wtogami at redhat.com From bugs.michael at gmx.net Thu Feb 8 08:21:45 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 8 Feb 2007 09:21:45 +0100 Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) In-Reply-To: <200702071845.29559.ville.skytta@iki.fi> References: <20070207123838.14958.37348@extras64.linux.duke.edu> <200702071845.29559.ville.skytta@iki.fi> Message-ID: <20070208092145.aa679260.bugs.michael@gmx.net> On Wed, 7 Feb 2007 18:45:29 +0200, Ville Skytt? wrote: > On Wednesday 07 February 2007 14:38, Fedora Extras repoclosure wrote: > > > package: amarok - 1.4.4-1.fc5.i386 from fedora-extras-5-i386 > > unresolved deps: > > libmtp.so.2 > Linus, was the soname change of libmtp announced somewhere in public > beforehand? Why was it necessary push the update to non-devel distros? > Apologies if I missed the announcement, but based on the above list of > breakage I'm not alone even within Fedora maintainers, let alone elsewhere. I've investigated a bit and have found #221114, where this was planned, albeit half-hearted. ABI breakage in stable branches ought to be announced on maintainers-list. And it should be possible to prepare all packages in CVS and let one maintainer submit all build jobs. Further, notifying the extras signers about builds that are expected to break deps, if not pushed as a complete set, is highly encouraged. It would not be much work to enhance the pushscript with a bit of code that excludes build results based on src.rpm names. From triad at df.lth.se Thu Feb 8 08:23:22 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 8 Feb 2007 09:23:22 +0100 (CET) Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) In-Reply-To: <200702071845.29559.ville.skytta@iki.fi> References: <20070207123838.14958.37348@extras64.linux.duke.edu> <200702071845.29559.ville.skytta@iki.fi> Message-ID: On Wed, 7 Feb 2007, Ville Skytt? wrote: > Linus, was the soname change of libmtp announced somewhere in public > beforehand? If Bugzilla counts as public, yes: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221114 Aurelien Bompard (Amarok maintainer) triggered libmtp upgrade here by explicit request at 2007-02-06 16:19 EST. However this reminds me about the Hitchhikers Guide to the Galaxy where intergalactic highway constructions claim the destruction of the earth was announced in obscucre places before taking place, so "noone should be upset about it". I do understand that not every living person reads all bugzilla tickets, so looking back we should have brought this to the devel list too, since Amarok is such a popular package :-/ I'm sorry it ended up like this, even though we discussed it for two months... :-( (The other dependency, gnomad2, is indeed obscure so doesn't cause much trouble I guess.) Next time we will bring it more public, so someone can say "no" for us or find a better way. > Why was it necessary push the update to non-devel distros? The 0.1.3 supports very many devices not supported by the previous version, so users consider it a bug. > Apologies if I missed the announcement, but based on the above list of > breakage I'm not alone even within Fedora maintainers, let alone elsewhere. The packages were intended to be pushed out alongside each other, I built libmtp and I instructed gauret (Amarok maintainer) to rebuild and built gnomad2 immediately afterwards, however the build of libmtp was pushed before our builds were done. The actual question here is how do we coordinate package builds with pushing of builds in a good way? What we want to do is group three packages (libmtp, gnomad2, amarok) and not push any one of them until all three are built. This would totally solve this kind of nasty problems. Linus From triad at df.lth.se Thu Feb 8 08:29:38 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 8 Feb 2007 09:29:38 +0100 (CET) Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) In-Reply-To: <20070208092145.aa679260.bugs.michael@gmx.net> References: <20070207123838.14958.37348@extras64.linux.duke.edu> <200702071845.29559.ville.skytta@iki.fi> <20070208092145.aa679260.bugs.michael@gmx.net> Message-ID: On Thu, 8 Feb 2007, Michael Schwendt wrote: > I've investigated a bit and have found #221114, where this was planned, > albeit half-hearted. ABI breakage in stable branches ought to be announced > on maintainers-list. I don't think we're half-hearted, just amateurs... We need a policy on how to handle this, saying something like "announce it on maintainer-list" etc. > And it should be possible to prepare all packages in CVS and let one > maintainer submit all build jobs. > > Further, notifying the extras signers about builds that are expected > to break deps, if not pushed as a complete set, is highly encouraged. > It would not be much work to enhance the pushscript with a bit of code > that excludes build results based on src.rpm names. Yes, this is exactly what is needed. Linus From rc040203 at freenet.de Thu Feb 8 08:33:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 08 Feb 2007 09:33:22 +0100 Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) In-Reply-To: References: <20070207123838.14958.37348@extras64.linux.duke.edu> <200702071845.29559.ville.skytta@iki.fi> Message-ID: <1170923603.21576.237.camel@mccallum.corsepiu.local> On Thu, 2007-02-08 at 09:23 +0100, Linus Walleij wrote: > On Wed, 7 Feb 2007, Ville Skytt? wrote: > > Apologies if I missed the announcement, but based on the above list of > > breakage I'm not alone even within Fedora maintainers, let alone elsewhere. > > The packages were intended to be pushed out alongside each other, I built > libmtp and I instructed gauret (Amarok maintainer) to rebuild and built > gnomad2 immediately afterwards, however the build of libmtp was pushed > before our builds were done. > > The actual question here is how do we coordinate package builds with > pushing of builds in a good way? Communication - Direct email, bugzilla. If necessary introduce compat-packages. > What we want to do is group three > packages (libmtp, gnomad2, amarok) and not push any one of them until all > three are built. This would totally solve this kind of nasty problems. co-maintain them, give other maintainers privileges to rebuild the packages when all agree upon such step? Having a build-system which requires maintainers to "give explicit clearance before a package is being pushed to the public"? Ralf From triad at df.lth.se Thu Feb 8 08:38:47 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 8 Feb 2007 09:38:47 +0100 (CET) Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) In-Reply-To: <200702071845.29559.ville.skytta@iki.fi> References: <20070207123838.14958.37348@extras64.linux.duke.edu> <200702071845.29559.ville.skytta@iki.fi> Message-ID: On Wed, 7 Feb 2007, Ville Skytt? wrote: > In case you're not aware of it, yum (more or less by design AFAIK) bumps the > severity of a single dependency problem among a batch of updates into the > *sum* of all other problems fixed in the batch, including security ones and > across all repos, by refusing to install any of them unless the user manually > cherry picks the packages not affected by the dependency issue separately. I've noticed this too, on several occasions. I wonder what the reasoning is behind this construction, i.e. why not just hold back libmtp-0.1.3 in this case informing the users that it'll break, and the only thing I can think of is that is designed for consistent repositories, so this is supposed to break thusly as an indication of the problem. But with no policies and tools for keeping the repositories consistent, yum design and the FC repositories are at odds. Linus From buildsys at fedoraproject.org Thu Feb 8 10:49:42 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 8 Feb 2007 05:49:42 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-08 Message-ID: <20070208104942.07A6E15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 18 beryl-settings-0.1.9999.1-4.fc7 dumpasn1-20060622-2.fc7 exim-4.66-2.fc7 graphviz-2.12-5.fc7 inkscape-0.45-1.fc7 ktorrent-2.1-7.fc7 mock-0.6.11-1.fc7 perl-Crypt-CBC-2.22-1.fc7 perl-Mozilla-LDAP-1.5-9.fc7 powerman-1.0.25-2.fc7 pulseaudio-0.9.5-3.fc7 sage-0.2.0-1.fc7 smolt-0.7-1.fc7 tellico-1.2.8-1.fc7 ufraw-0.10-1.fc7 wfut-1.1.0-1.fc7 wine-0.9.30-1.fc7 zabbix-1.1.6-1.fc7 Packages built and released for Fedora Extras 6: 15 amarok-1.4.5-1.fc6 beryl-settings-0.1.9999.1-4.fc6 gnomad2-2.8.11-1.fc6 NEW ingo-1.1.2-3.fc6 ktorrent-2.1-7.fc6 mew-5.2-1.fc6 mock-0.6.11-1.fc6 perl-Crypt-CBC-2.22-1.fc6 perl-Mozilla-LDAP-1.5-9.fc6 powerman-1.0.25-2.fc6 sage-0.2.0-1.fc6 smolt-0.7-1.fc6 wfut-1.1.0-1.fc6 wine-0.9.30-1.fc6 zabbix-1.1.6-1.fc6 Packages built and released for Fedora Extras 5: 9 amarok-1.4.5-1.fc5.1 gnomad2-2.8.11-1.fc5 NEW ingo-1.1.2-3.fc5 ktorrent-2.1-7.fc5 perl-Crypt-CBC-2.22-1.fc5 perl-Mozilla-LDAP-1.5-9.fc5 powerman-1.0.25-1.fc5 wine-0.9.30-1.fc5 zabbix-1.1.6-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From caolanm at redhat.com Thu Feb 8 12:50:31 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 08 Feb 2007 12:50:31 +0000 Subject: hunspell dictionaries, do I have to make 28 review request ? Message-ID: <1170939032.29307.11.camel@soulcrusher.caolan.org> So, what I want to do is split out the hunspell dictionaries from openoffice.org into separate packages for each dictionary so we don't have to re-build them for each OOo respin, or re-download them for that matter, etc etc. To that end https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227811 is the Afrikaans dict. The question is, can I avoid having to making 27 extra review requests for the remaining dictionaries that I want to split out of OOo (http://people.redhat.com/caolanm/hunspell/) and get a sort of blanket approval based off the Afrikaans dict review ? C. From triad at df.lth.se Thu Feb 8 13:40:30 2007 From: triad at df.lth.se (Linus Walleij) Date: Thu, 8 Feb 2007 14:40:30 +0100 (CET) Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) In-Reply-To: <1170923603.21576.237.camel@mccallum.corsepiu.local> References: <20070207123838.14958.37348@extras64.linux.duke.edu> <200702071845.29559.ville.skytta@iki.fi> <1170923603.21576.237.camel@mccallum.corsepiu.local> Message-ID: On Thu, 8 Feb 2007, Ralf Corsepius wrote: > co-maintain them, give other maintainers privileges to rebuild the > packages when all agree upon such step? Yes if I was to do this today I'd say we both make everything up to "make tag", then I shouldv'e waited for the next release mail and after that build first the lib then both dependencies as soon as that build is confirmed. > Having a build-system which requires maintainers to "give explicit > clearance before a package is being pushed to the public"? Yep, the programming equivalent is a "race condition"... I we had e.g. a webpage where you can confirm your (and others) builds to be pushed, we could have spent a week building this lib and its dependent apps, then pushed all of them in batch, breaking nothing. I believe this is what e.g. Debian use the "unstable" and "testing" repos for... Hm, and I was against that at one point, now I will reconsider that stance. Linus From kevin.kofler at chello.at Thu Feb 8 17:08:54 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 8 Feb 2007 17:08:54 +0000 (UTC) Subject: libmtp soname change breakage (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-07) References: <20070207123838.14958.37348@extras64.linux.duke.edu> <200702071845.29559.ville.skytta@iki.fi> Message-ID: The breakage has been solved 23 hours later with the next push. There were cases of broken dependencies which stayed unfixed for weeks (I once filed bugs against each of them when there were 3 or 4 packages broken for several days, with moderate success), this one was relatively harmless in comparison. Kevin Kofler From notting at redhat.com Thu Feb 8 17:24:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Feb 2007 12:24:18 -0500 Subject: hunspell dictionaries, do I have to make 28 review request ? In-Reply-To: <1170939032.29307.11.camel@soulcrusher.caolan.org> References: <1170939032.29307.11.camel@soulcrusher.caolan.org> Message-ID: <20070208172418.GC8342@nostromo.devel.redhat.com> Caolan McNamara (caolanm at redhat.com) said: > To that end https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227811 > is the Afrikaans dict. The question is, can I avoid having to making 27 > extra review requests for the remaining dictionaries that I want to > split out of OOo (http://people.redhat.com/caolanm/hunspell/) and get a > sort of blanket approval based off the Afrikaans dict review ? Is it essentially templated? Bill From fedora at leemhuis.info Thu Feb 8 17:43:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 08 Feb 2007 18:43:00 +0100 Subject: hunspell dictionaries, do I have to make 28 review request ? In-Reply-To: <1170939032.29307.11.camel@soulcrusher.caolan.org> References: <1170939032.29307.11.camel@soulcrusher.caolan.org> Message-ID: <45CB6124.1010802@leemhuis.info> Caolan McNamara schrieb: > So, what I want to do is split out the hunspell dictionaries from > openoffice.org into separate packages for each dictionary so we don't > have to re-build them for each OOo respin, or re-download them for that > matter, etc etc. > > To that end https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227811 > is the Afrikaans dict. The question is, can I avoid having to making 27 > extra review requests for the remaining dictionaries that I want to > split out of OOo (http://people.redhat.com/caolanm/hunspell/) and get a > sort of blanket approval based off the Afrikaans dict review ? My 2 cent: - search a reviewer of the Afrikaans dict review that is willig to work on you on the other dicts, too - finish the Afrikaans dict review - open review bugs for all the others, too -- at least the license IMHO should be checked by the reviewer, and that way proper tracking is possible later, too; reviewing should be not much more then running a diff (and looking at the differences), checking the license and the md5sum for the initial reviewer -> should be easy to do CU thl From caolanm at redhat.com Thu Feb 8 18:34:28 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 08 Feb 2007 18:34:28 +0000 Subject: hunspell dictionaries, do I have to make 28 review request ? In-Reply-To: <20070208172418.GC8342@nostromo.devel.redhat.com> References: <1170939032.29307.11.camel@soulcrusher.caolan.org> <20070208172418.GC8342@nostromo.devel.redhat.com> Message-ID: <1170959669.29307.24.camel@soulcrusher.caolan.org> On Thu, 2007-02-08 at 12:24 -0500, Bill Nottingham wrote: > Caolan McNamara (caolanm at redhat.com) said: > > To that end https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227811 > > is the Afrikaans dict. The question is, can I avoid having to making 27 > > extra review requests for the remaining dictionaries that I want to > > split out of OOo (http://people.redhat.com/caolanm/hunspell/) and get a > > sort of blanket approval based off the Afrikaans dict review ? > > Is it essentially templated? Yeah, they're all essentially the same, except the license differs as LGPL/GPL/BSD from case to case. rpmdiff is silent on all of them. I mean, I don't *really* mind making 27 separate package reviews, but we've got a lot of package reviews outstanding already and it just seems a little time-consuming to rinse and repeat so many times rather than handle them all as one single request. C. From tibbs at math.uh.edu Thu Feb 8 18:43:03 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Feb 2007 12:43:03 -0600 Subject: hunspell dictionaries, do I have to make 28 review request ? In-Reply-To: <1170959669.29307.24.camel@soulcrusher.caolan.org> References: <1170939032.29307.11.camel@soulcrusher.caolan.org> <20070208172418.GC8342@nostromo.devel.redhat.com> <1170959669.29307.24.camel@soulcrusher.caolan.org> Message-ID: >>>>> "CM" == Caolan McNamara writes: CM> I mean, I don't *really* mind making 27 separate package reviews, CM> but we've got a lot of package reviews outstanding already and it CM> just seems a little time-consuming to rinse and repeat so many CM> times rather than handle them all as one single request. We really want to have a review URL to put in the package database, and I don't know that we've ever allowed multiple packages to be reviewed in a single ticket. So rather than having to go through a bunch of discussion to make new policy, it might just be simpler for someone to review the first one, then waste ten minutes in front of bugzilla entering "This is packaged identically to the first one; see (URL). APPROVED". (Of course, they should be checking to make sure that's actually the case.) - J< From wolfy at nobugconsulting.ro Thu Feb 8 18:51:20 2007 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Thu, 08 Feb 2007 20:51:20 +0200 Subject: hunspell dictionaries, do I have to make 28 review request ? In-Reply-To: References: <1170939032.29307.11.camel@soulcrusher.caolan.org> <20070208172418.GC8342@nostromo.devel.redhat.com> <1170959669.29307.24.camel@soulcrusher.caolan.org> Message-ID: <45CB7128.8000601@nobugconsulting.ro> On 02/08/2007 08:43 PM, Jason L Tibbitts III wrote: >>>>>> "CM" == Caolan McNamara writes: >>>>>> > > CM> I mean, I don't *really* mind making 27 separate package reviews, > CM> but we've got a lot of package reviews outstanding already and it > CM> just seems a little time-consuming to rinse and repeat so many > CM> times rather than handle them all as one single request. > > We really want to have a review URL to put in the package database, > and I don't know that we've ever allowed multiple packages to be > reviewed in a single ticket. > > So rather than having to go through a bunch of discussion to make new > policy, it might just be simpler for someone to review the first one, > then waste ten minutes in front of bugzilla entering "This is packaged > identically to the first one; see (URL). APPROVED". (Of course, they > should be checking to make sure that's actually the case.) > > - J< > > I'll do that. From caolanm at redhat.com Thu Feb 8 20:07:15 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 08 Feb 2007 20:07:15 +0000 Subject: hunspell dictionaries, do I have to make 28 review request ? In-Reply-To: References: <1170939032.29307.11.camel@soulcrusher.caolan.org> <20070208172418.GC8342@nostromo.devel.redhat.com> <1170959669.29307.24.camel@soulcrusher.caolan.org> Message-ID: <1170965316.29307.27.camel@soulcrusher.caolan.org> On Thu, 2007-02-08 at 12:43 -0600, Jason L Tibbitts III wrote: > >>>>> "CM" == Caolan McNamara writes: > > CM> I mean, I don't *really* mind making 27 separate package reviews, > CM> but we've got a lot of package reviews outstanding already and it > CM> just seems a little time-consuming to rinse and repeat so many > CM> times rather than handle them all as one single request. > > We really want to have a review URL to put in the package database, > and I don't know that we've ever allowed multiple packages to be > reviewed in a single ticket. > > So rather than having to go through a bunch of discussion to make new > policy, it might just be simpler for someone to review the first one, > then waste ten minutes in front of bugzilla entering "This is packaged > identically to the first one; see (URL). APPROVED". (Of course, they > should be checking to make sure that's actually the case.) sure. not a problem. I'll pause on the first dict, and mirror any required changed into the other and pile them on afterwards. C. From mmcgrath at fedoraproject.org Thu Feb 8 20:27:58 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 8 Feb 2007 14:27:58 -0600 Subject: Wiki upgrade Message-ID: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> There's been a strong push to get the wiki upgraded sooner than later. Unfortunately we're running into stability issues (among other things) in its current state and platform. Sometime in the next couple of weeks we'll probably request a 12-24 hour wiki change lock so we can do the upgrade. We're going to try to make this as painless as possible but please be patient. Is there any time that is better / worse than any other time for anyone out there? Does anyone care as long as enough advanced notice is given? -Mike From tibbs at math.uh.edu Thu Feb 8 20:32:17 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Feb 2007 14:32:17 -0600 Subject: Wiki upgrade In-Reply-To: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> References: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> Message-ID: >>>>> "MM" == Mike McGrath writes: MM> Is there any time that is better / worse than any other time for MM> anyone out there? Does anyone care as long as enough advanced MM> notice is given? Any chance we could get the package import switched over from editing CVSSyncNeeded to flags before the wiki is taken offline? - J< From mmcgrath at fedoraproject.org Thu Feb 8 21:44:03 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 8 Feb 2007 15:44:03 -0600 Subject: Wiki upgrade In-Reply-To: References: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> Message-ID: <3237e4410702081344q1a5fc46bnf63f7869b3891244@mail.gmail.com> On 08 Feb 2007 14:32:17 -0600, Jason L Tibbitts III wrote: > >>>>> "MM" == Mike McGrath writes: > > MM> Is there any time that is better / worse than any other time for > MM> anyone out there? Does anyone care as long as enough advanced > MM> notice is given? > > Any chance we could get the package import switched over from editing > CVSSyncNeeded to flags before the wiki is taken offline? > Sorry, i crossposted the hell out of this. The wiki won't be taken offline just made un-editible for most of that time. I haven't been working with the CVSSync changes so I can't speak with any authority on what will happen when with it. -Mike From mattdm at mattdm.org Thu Feb 8 21:47:37 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Feb 2007 16:47:37 -0500 Subject: using non-standard optflags (-O3, in particular) Message-ID: <20070208214737.GA20150@jadzia.bu.edu> I'm working on building calc, a math package, for Extras. Upstream says: There is a slight performance advantage with -O3. We have some users who run very long calc computations (on the order of months of CPU time). So even slight advantages are useful. Between your EMail message and this one, we received a plea from one of those massive computation calc users to keep -O3. Given the nature of the package, this seems reasonable. Is there a standard mechanism for overriding part of optflags like this? Upstream also would prefer -g3 -- is there a problem with that? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wolfy at nobugconsulting.ro Thu Feb 8 21:54:31 2007 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Thu, 08 Feb 2007 23:54:31 +0200 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070208214737.GA20150@jadzia.bu.edu> References: <20070208214737.GA20150@jadzia.bu.edu> Message-ID: <45CB9C17.5040906@nobugconsulting.ro> On 02/08/2007 11:47 PM, Matthew Miller wrote: > I'm working on building calc, a math package, for Extras. Upstream says: > > There is a slight performance advantage with -O3. We have some > users who run very long calc computations (on the order of months of > CPU time). So even slight advantages are useful. Between your EMail > message and this one, we received a plea from one of those massive > computation calc users to keep -O3. > > > Given the nature of the package, this seems reasonable. Is there a > standard mechanism for overriding part of optflags like this? > > > Upstream also would prefer -g3 -- is there a problem with that? > > Take a look at http://fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlag . Maybe this method can help. From mattdm at mattdm.org Thu Feb 8 22:05:51 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Feb 2007 17:05:51 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <45CB9C17.5040906@nobugconsulting.ro> References: <20070208214737.GA20150@jadzia.bu.edu> <45CB9C17.5040906@nobugconsulting.ro> Message-ID: <20070208220551.GA22090@jadzia.bu.edu> On Thu, Feb 08, 2007 at 11:54:31PM +0200, lonely wolf wrote: > http://fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlag . http://fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlags actually. Thanks. Although I think I probably actually want it to break if -O2 isn't found, so I'll do it a little differently from that. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From seg at haxxed.com Thu Feb 8 22:16:58 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 08 Feb 2007 16:16:58 -0600 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070208214737.GA20150@jadzia.bu.edu> References: <20070208214737.GA20150@jadzia.bu.edu> Message-ID: <1170973018.13307.47.camel@localhost.localdomain> On Thu, 2007-02-08 at 16:47 -0500, Matthew Miller wrote: > I'm working on building calc, a math package, for Extras. Upstream says: > > There is a slight performance advantage with -O3. With what GCC version? And with what other flags? Optimization is an incredibly finicky thing, that can wildly vary depending on the version of GCC, and different opt flags can interact in strange ways. Unless you can show a conclusive benchmark showing -O3 is better with *our* GCC and all the rest of *our* opt flags, this shouldn't be allowed IMHO. -------------- 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 nomis80 at nomis80.org Thu Feb 8 22:43:27 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Thu, 8 Feb 2007 17:43:27 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <1170973018.13307.47.camel@localhost.localdomain> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> Message-ID: <200702081743.27764.nomis80@nomis80.org> On Thursday February 8 2007 17:16, Callum Lerwick wrote: > Unless you can show a conclusive benchmark showing -O3 is better with > *our* GCC and all the rest of *our* opt flags, this shouldn't be allowed > IMHO. I think what you're proposing is red tape and we should trust the packager's common sense. From pertusus at free.fr Fri Feb 9 00:25:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Feb 2007 01:25:38 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <1170973018.13307.47.camel@localhost.localdomain> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> Message-ID: <20070209001402.GE2821@free.fr> On Thu, Feb 08, 2007 at 04:16:58PM -0600, Callum Lerwick wrote: > > With what GCC version? And with what other flags? Optimization is an > incredibly finicky thing, that can wildly vary depending on the version > of GCC, and different opt flags can interact in strange ways. > > Unless you can show a conclusive benchmark showing -O3 is better with > *our* GCC and all the rest of *our* opt flags, this shouldn't be allowed > IMHO. Why not trust upstream? And if a benchmark shows that it is untrue, come back to -O2. If i recall well -O3 make debuging harder, so there is a choice to do, but the packager should certainly be trusted in those cases. -- Pat From bjohnson-dated-1169703224.9d1a0c at symetrix.com Fri Feb 9 01:49:13 2007 From: bjohnson-dated-1169703224.9d1a0c at symetrix.com (Bernard Johnson) Date: Thu, 08 Feb 2007 18:49:13 -0700 Subject: gdome2 orphan Message-ID: I am interested in taking over the ownership of gdome2. I need it it as a requirement for a package submission (ntop: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219025). If there are no objections or others wishing to take ownership, I'll claim ownership and assign it to myself middle of next week. From giallu at gmail.com Fri Feb 9 09:24:37 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 9 Feb 2007 10:24:37 +0100 Subject: Wiki upgrade In-Reply-To: <3237e4410702081344q1a5fc46bnf63f7869b3891244@mail.gmail.com> References: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> <3237e4410702081344q1a5fc46bnf63f7869b3891244@mail.gmail.com> Message-ID: On 2/8/07, Mike McGrath wrote: > > Sorry, i crossposted the hell out of this. The wiki won't be taken > offline just made un-editible for most of that time. Is there any simple way to do that? (/me running a internal wiki with need to upgrade) From paul at city-fan.org Fri Feb 9 09:56:28 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 09 Feb 2007 09:56:28 +0000 Subject: Wiki upgrade In-Reply-To: References: <3237e4410702081227i2699af5fr13f9b075bf23ea2@mail.gmail.com> <3237e4410702081344q1a5fc46bnf63f7869b3891244@mail.gmail.com> Message-ID: <45CC454C.3040903@city-fan.org> Gianluca Sforna wrote: > On 2/8/07, Mike McGrath wrote: >> >> Sorry, i crossposted the hell out of this. The wiki won't be taken >> offline just made un-editible for most of that time. > > Is there any simple way to do that? (/me running a internal wiki with > need to upgrade) I'd have thought: acl_rights_before = u"All:read" in wikiconfig.py would have that effect (as long as you didn't have any pages with restrictions on who could read them, which would be overridden by this). Paul. From joost.soeterbroek at gmail.com Fri Feb 9 11:30:22 2007 From: joost.soeterbroek at gmail.com (Joost Soeterbroek) Date: Fri, 9 Feb 2007 12:30:22 +0100 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread Message-ID: I am orphaning the following packages: - clearsilver - glunarclock - gnubg - heartbeat - ltsp-utils - trac - xmms-cdread Joost From sundaram at fedoraproject.org Fri Feb 9 11:34:31 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 09 Feb 2007 17:04:31 +0530 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: References: Message-ID: <45CC5C47.1040801@fedoraproject.org> Joost Soeterbroek wrote: > I am orphaning the following packages: > > - clearsilver > - glunarclock > - gnubg > - heartbeat > - ltsp-utils > - trac > - xmms-cdread > > Joost That is the entire list of packages you maintain. Are you leaving Fedora? Rahul From joost.soeterbroek at gmail.com Fri Feb 9 11:44:55 2007 From: joost.soeterbroek at gmail.com (Joost Soeterbroek) Date: Fri, 9 Feb 2007 12:44:55 +0100 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: <45CC5C47.1040801@fedoraproject.org> References: <45CC5C47.1040801@fedoraproject.org> Message-ID: On 2/9/07, Rahul Sundaram wrote: > Joost Soeterbroek wrote: > > I am orphaning the following packages: > > > > - clearsilver > > - glunarclock > > - gnubg > > - heartbeat > > - ltsp-utils > > - trac > > - xmms-cdread > > > > Joost > > That is the entire list of packages you maintain. Are you leaving Fedora? For the time being, yes. I want to spend more of my spare time on other projects and interests. Joost > > Rahul > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From buildsys at fedoraproject.org Fri Feb 9 12:11:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 9 Feb 2007 07:11:21 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-09 Message-ID: <20070209121121.6158015212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 24 alsa-oss-1.0.12-4.fc7 NEW bcfg2-0.9.1-1.d.fc7 beryl-core-0.1.9999.1-3.fc7 bibletime-1.6.3b-3.fc7 espeak-1.20-1.fc7 exim-4.66-3.fc7 exo-0.3.2-2.fc7 gtklp-1.2.3-1.fc7 itcl-3.3-0.8.RC1.fc7 itk-3.3-0.5.RC1.fc7 jd-1.8.5-2.cvs070208.fc7 jrtplib-3.7.0-1.fc7 kicad-2007.01.15-1.fc7 libnfnetlink-0.0.25-1.fc7 liferea-1.2.6-1.fc7 mew-5.2-2.fc7 nas-1.8-13.fc7 prelude-manager-0.9.7.1-4.fc7 puppet-0.22.1-1.fc7 rawstudio-0.5-1.fc7 revelation-0.4.11-2.fc7 seedit-2.1.0-2.fc7 tcldom-3.1-8.fc7 xlockmore-5.23-1.fc7 Packages built and released for Fedora Extras 6: 12 beryl-core-0.1.9999.1-3.fc6 bibletime-1.6.3b-3.fc6 espeak-1.20-1.fc6 gtklp-1.2.3-1.fc6 inkscape-0.45-1.fc6 jrtplib-3.7.0-1.fc6 kicad-2007.01.15-1.fc6 mew-5.2-2.fc6 nas-1.8-11.fc6 prelude-manager-0.9.7.1-4.fc6 seedit-2.1.0-3.fc6 xlockmore-5.23-1.fc6 Packages built and released for Fedora Extras 5: 8 bibletime-1.6.3b-3.fc5 espeak-1.20-1.fc5 gtklp-1.2.3-1.fc5 kicad-2007.01.15-1.fc5 mew-5.2-2.fc5 nas-1.8-11.fc5 prelude-manager-0.9.7.1-4.fc5 xlockmore-5.23-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 9 12:17:16 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 9 Feb 2007 13:17:16 +0100 Subject: What is the current way to import a new package? Message-ID: <20070209131716.34e0bd24@python3.es.egwn.lan> Hi, I know things have changed regarding owners.list, and CVS ACLs, but... the wiki page doesn't seem to reflect any of those changes : http://fedoraproject.org/wiki/Extras/NewPackageProcess What should I do? I tried the "normal" cvs-import.sh way, but got : [dude at python3 common]$ ./cvs-import.sh /tmp/RPMS/libmp4v2-1.5.0.1-3.src.rpm Checking out the modules file... Creating new module: libmp4v2 cvs diff: [12:11:55] waiting for thias's lock in /cvs/extras/CVSROOT cvs diff: [12:12:25] obtained lock in /cvs/extras/CVSROOT Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. cvs commit: Pre-commit check failed cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! Entry for module 'libmp4v2' created. Checking out module: 'libmp4v2' Unpacking source package: libmp4v2-1.5.0.1-3.src.rpm... L libmp4v2-1.5.0.1.tar.bz2 A libmp4v2.spec L mklibmp4v2-r51.tar.bz2 Checking : libmp4v2-1.5.0.1.tar.bz2 on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... Uploading: libmp4v2-1.5.0.1.tar.bz2 to https://cvs.fedora.redhat.com/repo/extras/upload.cgi... File libmp4v2-1.5.0.1.tar.bz2 size 375541 MD5 90eb2b0940ebe02ef81b7a60530beaee stored OK Checking : mklibmp4v2-r51.tar.bz2 on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... Uploading: mklibmp4v2-r51.tar.bz2 to https://cvs.fedora.redhat.com/repo/extras/upload.cgi... File mklibmp4v2-r51.tar.bz2 size 14885 MD5 4b4abb862b079a7e296c891d96faebc9 stored OK Source upload succeeded. Don't forget to commit the new ./sources file A sources cvs update: use `cvs add' to create an entry for .cvsignore ? import.log ? devel/.cvsignore cvs commit... cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! [dude at python3 common]$ (sorry for the ugly line wrapping...) So it ended up aborting, but it said it created the CVS module, sent emails... I'm afraid I did something I possibly shouldn't have :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 3.68 3.37 2.86 From frank-buettner at gmx.net Fri Feb 9 12:58:16 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Fri, 09 Feb 2007 13:58:16 +0100 Subject: Build system hang Message-ID: <45CC6FE8.2040601@gmx.net> Hello, the build system is broken. make build will result in an plague-client error: no job ID was provided in the time required From buildsys at fedoraproject.org Fri Feb 9 13:01:55 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 09 Feb 2007 13:01:55 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-09 Message-ID: <20070209130155.16336.8290@extras64.linux.duke.edu> New report for: tagoh AT redhat.com package: mew-xemacs - 5.2-2.fc5.i386 from fedora-extras-5-i386 unresolved deps: xemacs-packages-extra package: mew-xemacs - 5.2-2.fc5.ppc from fedora-extras-5-ppc unresolved deps: xemacs-packages-extra package: mew-xemacs - 5.2-2.fc5.x86_64 from fedora-extras-5-x86_64 unresolved deps: xemacs-packages-extra ====================================================================== New report for: i AT stingr.net package: libnetfilter_conntrack - 0.0.31-3.fc6.i386 from fedora-extras-development-x86_64 unresolved deps: libnfnetlink.so.1 package: libnetfilter_conntrack - 0.0.31-3.fc6.i386 from fedora-extras-development-i386 unresolved deps: libnfnetlink.so.1 package: libnetfilter_conntrack - 0.0.31-3.fc6.ppc from fedora-extras-development-ppc unresolved deps: libnfnetlink.so.1 package: libnetfilter_conntrack - 0.0.31-3.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libnfnetlink.so.1()(64bit) ====================================================================== New report for: andreas.bierfert AT lowlatency.de package: claws-mail - 2.7.2-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libdb-4.3.so package: libetpan - 0.49-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libdb-4.3.so ====================================================================== New report for: bojan AT rexursive.com package: libapreq2 - 2.09-0.rc2.1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libdb-4.3.so ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de gnu-smalltalk - 2.3.2-4.fc7.i386 (8 days) gnu-smalltalk - 2.3.2-4.fc7.i386 (8 days) gnu-smalltalk - 2.3.2-4.fc7.ppc (8 days) gnu-smalltalk - 2.3.2-4.fc7.x86_64 (8 days) andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 libetpan - 0.49-1.fc7.i386 bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 cgoorah AT yahoo.com.au toped - 0.8.2-2.fc6.i386 (56 days) toped - 0.8.2-2.fc6.ppc (56 days) toped - 0.8.2-2.fc6.x86_64 (56 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (63 days) csound - 5.03.0-9.fc7.i386 (63 days) csound - 5.03.0-9.fc7.ppc (63 days) csound - 5.03.0-9.fc7.x86_64 (63 days) csound-python - 5.03.0-9.fc7.i386 (63 days) csound-python - 5.03.0-9.fc7.ppc (63 days) csound-python - 5.03.0-9.fc7.x86_64 (63 days) csound-tk - 5.03.0-9.fc7.i386 (63 days) csound-tk - 5.03.0-9.fc7.ppc (63 days) csound-tk - 5.03.0-9.fc7.x86_64 (63 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (65 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (65 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (65 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (65 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (65 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (65 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (65 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (63 days) gemi AT bluewin.ch gcl - 2.6.7-14.fc7.i386 (8 days) gcl - 2.6.7-14.fc7.x86_64 (8 days) labltk - 3.09.3-1.fc7.i386 (8 days) labltk - 3.09.3-1.fc7.ppc (8 days) labltk - 3.09.3-1.fc7.x86_64 (8 days) q - 7.6-1.fc7.i386 (8 days) q - 7.6-1.fc7.ppc (8 days) i AT stingr.net libnetfilter_conntrack - 0.0.31-3.fc6.i386 libnetfilter_conntrack - 0.0.31-3.fc6.i386 libnetfilter_conntrack - 0.0.31-3.fc6.ppc libnetfilter_conntrack - 0.0.31-3.fc6.x86_64 ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (60 days) libreadline-java - 0.8.0-13.fc6.i386 (60 days) libreadline-java - 0.8.0-13.fc6.ppc (60 days) libreadline-java - 0.8.0-13.fc6.x86_64 (60 days) imlinux AT gmail.com sqlite2-tcl - 2.8.17-1.fc6.i386 (8 days) sqlite2-tcl - 2.8.17-1.fc6.ppc (8 days) sqlite2-tcl - 2.8.17-1.fc6.x86_64 (8 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (123 days) linphone - 1.2.0-4.fc5.ppc (123 days) linphone - 1.2.0-4.fc5.x86_64 (123 days) lmacken AT redhat.com python-cherrypy - 2.2.1-3.fc6.noarch (63 days) python-cherrypy - 2.2.1-3.fc6.noarch (63 days) python-cherrypy - 2.2.1-3.fc6.noarch (63 days) orion AT cora.nwra.com environment-modules - 3.2.3-3.fc7.i386 (8 days) environment-modules - 3.2.3-3.fc7.ppc (8 days) environment-modules - 3.2.3-3.fc7.x86_64 (8 days) paraview - 2.4.4-3.fc6.i386 (63 days) paraview - 2.4.4-3.fc6.ppc (63 days) paraview - 2.4.4-3.fc6.x86_64 (63 days) paraview-mpi - 2.4.4-3.fc6.i386 (63 days) paraview-mpi - 2.4.4-3.fc6.ppc (63 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (63 days) plplot - 5.7.2-1.fc7.i386 (8 days) plplot - 5.7.2-1.fc7.i386 (8 days) plplot - 5.7.2-1.fc7.ppc (8 days) plplot - 5.7.2-1.fc7.x86_64 (8 days) plplot-tk - 5.7.2-1.fc7.i386 (8 days) plplot-tk - 5.7.2-1.fc7.i386 (8 days) plplot-tk - 5.7.2-1.fc7.ppc (8 days) plplot-tk - 5.7.2-1.fc7.x86_64 (8 days) python-matplotlib-tk - 0.87.7-4.fc7.i386 (8 days) python-matplotlib-tk - 0.87.7-4.fc7.ppc (8 days) python-matplotlib-tk - 0.87.7-4.fc7.x86_64 (8 days) petersen AT redhat.com ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.i386 (18 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.ppc (18 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.x86_64 (18 days) rdieter AT math.unl.edu PyKDE - 3.16.0-5.fc7.i386 (63 days) PyKDE - 3.16.0-5.fc7.i386 (63 days) PyKDE - 3.16.0-5.fc7.ppc (63 days) PyKDE - 3.16.0-5.fc7.x86_64 (63 days) geomview - 1.8.2-0.25.rc9.fc7.i386 (8 days) geomview - 1.8.2-0.25.rc9.fc7.i386 (8 days) geomview - 1.8.2-0.25.rc9.fc7.ppc (8 days) geomview - 1.8.2-0.25.rc9.fc7.x86_64 (8 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.i386 (26 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.ppc (26 days) kdemultimedia-extras - 6:3.5.5-0.3.fc7.x86_64 (26 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (63 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (63 days) xmldiff - 0.6.7-12.fc6.ppc (63 days) xmldiff - 0.6.7-12.fc6.x86_64 (63 days) tagoh AT redhat.com mew-xemacs - 5.2-2.fc5.i386 mew-xemacs - 5.2-2.fc5.ppc mew-xemacs - 5.2-2.fc5.x86_64 ====================================================================== Broken packages in fedora-extras-5-i386: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.i386 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 mew-xemacs-5.2-2.fc5.i386 requires xemacs-packages-extra ====================================================================== Broken packages in fedora-extras-5-ppc: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.ppc requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 mew-xemacs-5.2-2.fc5.ppc requires xemacs-packages-extra ====================================================================== Broken packages in fedora-extras-5-x86_64: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.x86_64 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) mew-xemacs-5.2-2.fc5.x86_64 requires xemacs-packages-extra ====================================================================== Broken packages in fedora-extras-development-i386: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.i386 requires libtk8.4.so csound-tk-5.03.0-9.fc7.i386 requires libtcl8.4.so environment-modules-3.2.3-3.fc7.i386 requires libtcl8.4.so gcl-2.6.7-14.fc7.i386 requires libtk8.4.so gcl-2.6.7-14.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.i386 requires libgstreamer-0.8.so.1 labltk-3.09.3-1.fc7.i386 requires libtcl8.4.so labltk-3.09.3-1.fc7.i386 requires libtk8.4.so libnetfilter_conntrack-0.0.31-3.fc6.i386 requires libnfnetlink.so.1 libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 paraview-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-2.4.4-3.fc6.i386 requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.i386 requires libtcl8.4.so python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 q-7.6-1.fc7.i386 requires libtcl8.4.so q-7.6-1.fc7.i386 requires libtk8.4.so sqlite2-tcl-2.8.17-1.fc6.i386 requires libtcl8.4.so toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-ppc: PyKDE-3.16.0-5.fc7.ppc requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.ppc requires python-abi = 0:2.4 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-tk-5.03.0-9.fc7.ppc requires libtcl8.4.so csound-tk-5.03.0-9.fc7.ppc requires libtk8.4.so environment-modules-3.2.3-3.fc7.ppc requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.ppc requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.ppc requires libtcl8.4.so kdemultimedia-extras-6:3.5.5-0.3.fc7.ppc requires libgstreamer-0.8.so.1 labltk-3.09.3-1.fc7.ppc requires libtcl8.4.so labltk-3.09.3-1.fc7.ppc requires libtk8.4.so libnetfilter_conntrack-0.0.31-3.fc6.ppc requires libnfnetlink.so.1 libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 paraview-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-2.4.4-3.fc6.ppc requires libtcl8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtk8.4.so paraview-mpi-2.4.4-3.fc6.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtcl8.4.so plplot-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtk8.4.so plplot-tk-5.7.2-1.fc7.ppc requires libtcl8.4.so python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtk8.4.so python-matplotlib-tk-0.87.7-4.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtcl8.4.so q-7.6-1.fc7.ppc requires libtk8.4.so sqlite2-tcl-2.8.17-1.fc6.ppc requires libtcl8.4.so toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python-abi = 0:2.4 claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk-5.03.0-9.fc7.x86_64 requires libtcl8.4.so()(64bit) environment-modules-3.2.3-3.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtcl8.4.so()(64bit) gcl-2.6.7-14.fc7.x86_64 requires libtk8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.i386 requires libtk8.4.so geomview-1.8.2-0.25.rc9.fc7.i386 requires libtcl8.4.so geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtcl8.4.so()(64bit) geomview-1.8.2-0.25.rc9.fc7.x86_64 requires libtk8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.i386 requires libtk8.4.so gnu-smalltalk-2.3.2-4.fc7.i386 requires libtcl8.4.so gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtcl8.4.so()(64bit) gnu-smalltalk-2.3.2-4.fc7.x86_64 requires libtk8.4.so()(64bit) kdemultimedia-extras-6:3.5.5-0.3.fc7.x86_64 requires libgstreamer-0.8.so.1()(64bit) labltk-3.09.3-1.fc7.x86_64 requires libtk8.4.so()(64bit) labltk-3.09.3-1.fc7.x86_64 requires libtcl8.4.so()(64bit) libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libnetfilter_conntrack-0.0.31-3.fc6.i386 requires libnfnetlink.so.1 libnetfilter_conntrack-0.0.31-3.fc6.x86_64 requires libnfnetlink.so.1()(64bit) libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtk8.4.so()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.i386 requires libtk8.4.so plplot-tk-5.7.2-1.fc7.i386 requires libtcl8.4.so plplot-tk-5.7.2-1.fc7.x86_64 requires libtcl8.4.so()(64bit) plplot-tk-5.7.2-1.fc7.x86_64 requires libtk8.4.so()(64bit) python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtk8.4.so()(64bit) python-matplotlib-tk-0.87.7-4.fc7.x86_64 requires libtcl8.4.so()(64bit) sqlite2-tcl-2.8.17-1.fc6.x86_64 requires libtcl8.4.so()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 From kevin.kofler at chello.at Fri Feb 9 13:05:43 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 9 Feb 2007 13:05:43 +0000 (UTC) Subject: using non-standard optflags (-O3, in particular) References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> Message-ID: Patrice Dumas writes: > Why not trust upstream? And if a benchmark shows that it is untrue, > come back to -O2. If i recall well -O3 make debuging harder, so there is > a choice to do, but the packager should certainly be trusted in those > cases. -O3 also hurts code size. Kevin Kofler From dcbw at redhat.com Fri Feb 9 13:11:18 2007 From: dcbw at redhat.com (Dan Williams) Date: Fri, 09 Feb 2007 08:11:18 -0500 Subject: Build system hang In-Reply-To: <45CC6FE8.2040601@gmx.net> References: <45CC6FE8.2040601@gmx.net> Message-ID: <1171026678.2902.42.camel@localhost.localdomain> On Fri, 2007-02-09 at 13:58 +0100, Frank B?ttner wrote: > Hello, the build system is broken. > make build will result in an plague-client error: no job ID was provided > in the time required Kicked. Postgres got told to quit: DatabaseError: error 'FATAL: terminating connection due to administrator command server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The following users probably want to requeue: nphilipp at redhat dot com - ufraw-0_9_1-1_fc5 frank-buettner at gmx dot net - nas-1_8-13_fc5 joost dot soeterbroek at gmail dot com - heartbeat-2_0_8-2_fc7 - heartbeat-2_0_8-2_fc6 - heartbeat-2_0_8-2_fc5 Dan From limb at jcomserv.net Fri Feb 9 13:31:50 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 9 Feb 2007 07:31:50 -0600 (CST) Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: References: Message-ID: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> I'll take gnubg, and trac if no one wants it. > I am orphaning the following packages: > > - clearsilver > - glunarclock > - gnubg > - heartbeat > - ltsp-utils > - trac > - xmms-cdread > > Joost > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From limb at jcomserv.net Fri Feb 9 13:36:01 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 9 Feb 2007 07:36:01 -0600 (CST) Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> References: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> Message-ID: <14838.65.192.24.190.1171028161.squirrel@mail.jcomserv.net> And, I suppose naturally, if(trac){clearsilver as well};. > I'll take gnubg, and trac if no one wants it. > >> I am orphaning the following packages: >> >> - clearsilver >> - glunarclock >> - gnubg >> - heartbeat >> - ltsp-utils >> - trac >> - xmms-cdread >> >> Joost >> >> -- >> fedora-extras-list mailing list >> fedora-extras-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-extras-list >> > > > -- > novus ordo absurdum > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From jeff at ocjtech.us Fri Feb 9 13:42:54 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 09 Feb 2007 07:42:54 -0600 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> References: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> Message-ID: <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> On Fri, 2007-02-09 at 07:31 -0600, Jon Ciesla wrote: > I'll take gnubg, and trac if no one wants it. > > > I am orphaning the following packages: > > > > - clearsilver > > - glunarclock > > - gnubg > > - heartbeat > > - ltsp-utils > > - trac > > - xmms-cdread I'll take clearsilver and trac if Jon doesn't want it... Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Fri Feb 9 13:47:25 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 9 Feb 2007 07:47:25 -0600 (CST) Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> References: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> Message-ID: <15599.65.192.24.190.1171028845.squirrel@mail.jcomserv.net> Be my guest. I'll just take gnubg. > On Fri, 2007-02-09 at 07:31 -0600, Jon Ciesla wrote: >> I'll take gnubg, and trac if no one wants it. >> >> > I am orphaning the following packages: >> > >> > - clearsilver >> > - glunarclock >> > - gnubg >> > - heartbeat >> > - ltsp-utils >> > - trac >> > - xmms-cdread > > I'll take clearsilver and trac if Jon doesn't want it... > > Jeff > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From thomas at apestaart.org Fri Feb 9 14:19:18 2007 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 09 Feb 2007 15:19:18 +0100 Subject: Twisted 2.x for FC5 Message-ID: <1171030758.19734.427.camel@level.fluendo.lan> I would like to put Twisted 2.x in FC5 as well. It is currently living out a happy live in FC6 and devel without any serious issues so far. Anyone against this ? Thomas From limb at jcomserv.net Fri Feb 9 14:20:12 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 9 Feb 2007 08:20:12 -0600 (CST) Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: <15599.65.192.24.190.1171028845.squirrel@mail.jcomserv.net> References: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> <15599.65.192.24.190.1171028845.squirrel@mail.jcomserv.net> Message-ID: <17936.65.192.24.190.1171030812.squirrel@mail.jcomserv.net> I'll take glunarclock, too. > Be my guest. I'll just take gnubg. > >> On Fri, 2007-02-09 at 07:31 -0600, Jon Ciesla wrote: >>> I'll take gnubg, and trac if no one wants it. >>> >>> > I am orphaning the following packages: >>> > >>> > - clearsilver >>> > - glunarclock >>> > - gnubg >>> > - heartbeat >>> > - ltsp-utils >>> > - trac >>> > - xmms-cdread >> >> I'll take clearsilver and trac if Jon doesn't want it... >> >> Jeff >> >> -- >> fedora-extras-list mailing list >> fedora-extras-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-extras-list >> > > > -- > novus ordo absurdum > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From gauret at free.fr Fri Feb 9 14:27:13 2007 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 09 Feb 2007 15:27:13 +0100 Subject: rpms/heartbeat/devel heartbeat.spec,1.13,1.14 References: <200702090951.l199pUqI019993@cvs-int.fedora.redhat.com> Message-ID: Joost Soeterbroek (jsoeterb) wrote: > Author: jsoeterb > > Update of /cvs/extras/rpms/heartbeat/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv19976 > > Modified Files: > heartbeat.spec > Log Message: > * Fri Feb 9 2007 Joost Soeterbroek > - 2.0.8-2 - > change condrestart -> restart (bz #223949) Careful, "service heartbeat restart" will *start* the heartbeat service if it wasn't running previously. Condrestart is supposed to check if the service is running and only restart it in this case. If the init script does not support condrestart, you have two options : - patch it to support it, and send your patch upstream (preferred) - inside the scriptlet, check if heartbeat is running and restart heartbeat only in this case. You could use service heartbeat status to do that. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours ; and this we should do freely and generously." -- Benjamin Franklin From rc040203 at freenet.de Fri Feb 9 15:46:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 16:46:33 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070209001402.GE2821@free.fr> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> Message-ID: <1171035994.31485.155.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 01:25 +0100, Patrice Dumas wrote: > On Thu, Feb 08, 2007 at 04:16:58PM -0600, Callum Lerwick wrote: > > > > With what GCC version? And with what other flags? Optimization is an > > incredibly finicky thing, that can wildly vary depending on the version > > of GCC, and different opt flags can interact in strange ways. > > > > Unless you can show a conclusive benchmark showing -O3 is better with > > *our* GCC and all the rest of *our* opt flags, this shouldn't be allowed > > IMHO. > > Why not trust upstream? If you mean those people who implement RPM_OPT_FLAGS, then I'd agree. If you mean a packages upstream: Yes, -O3 might have improved speed on this upstream's test systems, but ... only on very rare occasions, these "upstreams" will be able to prove generality of their claims. > And if a benchmark shows that it is untrue, > come back to -O2. If i recall well -O3 make debuging harder, so there is > a choice to do, but the packager should certainly be trusted in those > cases. Your answer clearly shows you don't know what -O3 really does (I don't know either), which details it all affects and which bugs it suffers from. This is no surprise, because -O3 (like any other -Ox flags) comprises a set of optimizations which silently changes over time, can have different effect on different architectures, particular cpus and will vary between distributions (The fedora GCC is not a vanilla FSF gcc), etc. So, the only results of recommendations to trust when it comes to packaging binaries for a distro is those who are deeply familiar with the guts of the OS, in case of Fedora, RH's GCC, glibc and kernel developers. They recommend those flags in RPM_OPT_FLAGS. Ralf From nomis80 at nomis80.org Fri Feb 9 15:59:06 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Fri, 09 Feb 2007 10:59:06 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <1171035994.31485.155.camel@mccallum.corsepiu.local> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> Message-ID: <45CC9A4A.1090106@nomis80.org> Ralf Corsepius wrote: > So, the only results of recommendations to trust when it comes to > packaging binaries for a distro is those who are deeply familiar with > the guts of the OS, in case of Fedora, RH's GCC, glibc and kernel > developers. This is BS. Sure, people have thought about the defaults, but it doesn't mean that the packager doesn't know what he's doing either. Some software, particularly numerical computation stuff, is built for being optimized properly. There are some extreme cases where using -O2 instead of -O3 simply makes a piece of software useless (take Blitz++ for example). Using -O3 in specific cases isn't that big of a deal. In any case, if there's something the packager hasn't thought about, he'll be quickly reminded by way of the Bugzilla. From kevin at scrye.com Fri Feb 9 16:05:34 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 9 Feb 2007 09:05:34 -0700 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: References: Message-ID: <20070209090534.5e64fb24@ningauble.scrye.com> On Fri, 9 Feb 2007 12:30:22 +0100 joost.soeterbroek at gmail.com ("Joost Soeterbroek") wrote: > I am orphaning the following packages: > > - clearsilver > - glunarclock > - gnubg > - heartbeat I'll take heartbeat if no one else wants it... > - ltsp-utils > - trac > - xmms-cdread > > Joost > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at scrye.com Fri Feb 9 16:09:08 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 9 Feb 2007 09:09:08 -0700 Subject: What is the current way to import a new package? In-Reply-To: <20070209131716.34e0bd24@python3.es.egwn.lan> References: <20070209131716.34e0bd24@python3.es.egwn.lan> Message-ID: <20070209090908.389a86f7@ningauble.scrye.com> On Fri, 9 Feb 2007 13:17:16 +0100 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) wrote: > Hi, > > I know things have changed regarding owners.list, and CVS ACLs, but... > the wiki page doesn't seem to reflect any of those changes : > http://fedoraproject.org/wiki/Extras/NewPackageProcess > > What should I do? I tried the "normal" cvs-import.sh way, but got : Yeah, things are not very documented/stable right now. Hopefully we can get things cleared up before too long. My understanding is currently you need to use the CVSSyncNeeded wiki page: http://www.fedoraproject.org/wiki/Extras/CVSSyncNeeded An admin will prep things, add you to owners, and then you can import. Can you try that? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at scrye.com Fri Feb 9 16:12:05 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 9 Feb 2007 09:12:05 -0700 Subject: Twisted 2.x for FC5 In-Reply-To: <1171030758.19734.427.camel@level.fluendo.lan> References: <1171030758.19734.427.camel@level.fluendo.lan> Message-ID: <20070209091205.2647ff91@ningauble.scrye.com> On Fri, 09 Feb 2007 15:19:18 +0100 thomas at apestaart.org (Thomas Vander Stichele) wrote: > I would like to put Twisted 2.x in FC5 as well. It is currently > living out a happy live in FC6 and devel without any serious issues > so far. > > Anyone against this ? I'm not against it per se, however, what else depends on it there? Can you make sure and coordinate with all the maintainers of those packages and make sure that their stuff works with 2.x? Also, try and make sure to push it all out at the same time to avoid broken dependencies. What are the advantages of pushing a major version update there instead of just leaving it with the previous stable? > Thomas kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Feb 9 16:16:16 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 9 Feb 2007 17:16:16 +0100 Subject: What is the current way to import a new package? In-Reply-To: <20070209090908.389a86f7@ningauble.scrye.com> References: <20070209131716.34e0bd24@python3.es.egwn.lan> <20070209090908.389a86f7@ningauble.scrye.com> Message-ID: <20070209171616.4ee386bb@python3.es.egwn.lan> Kevin Fenzi wrote : > On Fri, 9 Feb 2007 13:17:16 +0100 > thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net > (Matthias Saou) wrote: > > > Hi, > > > > I know things have changed regarding owners.list, and CVS ACLs, but... > > the wiki page doesn't seem to reflect any of those changes : > > http://fedoraproject.org/wiki/Extras/NewPackageProcess > > > > What should I do? I tried the "normal" cvs-import.sh way, but got : > > Yeah, things are not very documented/stable right now. > Hopefully we can get things cleared up before too long. > > My understanding is currently you need to use the CVSSyncNeeded wiki > page: > > http://www.fedoraproject.org/wiki/Extras/CVSSyncNeeded > > An admin will prep things, add you to owners, and then you can import. > > Can you try that? Sure, but what scares me is that the "libmp4v2" CVS module was created with a messed up content : It has a "common" directory inside it with the same content as the "common" directory one level below, from where I ran the import script. I really thought I only needed help from a CVS admin in order to get added to the owners.list file... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 2.34 2.92 3.42 From rc040203 at freenet.de Fri Feb 9 16:17:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 17:17:11 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <45CC9A4A.1090106@nomis80.org> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> Message-ID: <1171037831.31485.164.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 10:59 -0500, Simon Perreault wrote: > Ralf Corsepius wrote: > > So, the only results of recommendations to trust when it comes to > > packaging binaries for a distro is those who are deeply familiar with > > the guts of the OS, in case of Fedora, RH's GCC, glibc and kernel > > developers. > > This is BS. Beg your pardon? > Sure, people have thought about the defaults, but it doesn't > mean that the packager doesn't know what he's doing either. Rest assured: In 99% of all cases they don't know. They test on their "Pentium IV" and claim something - They can't have any clues about what happens on a sparc, an i586 and AMD X2 , or a ppc something. > Some > software, particularly numerical computation stuff, is built for being > optimized properly. There are some extreme cases where using -O2 instead > of -O3 simply makes a piece of software useless (take Blitz++ for example). In other words: Crappy non-portable SW, > Using -O3 in specific cases isn't that big of a deal. It is - It renders debugging impossible on many systems, strict-aliasing silently kills SW on some targets, it might trigger exotic target-specific bugs etc. etc. As part of the distro you can't to compromise between different trade-offs. Ralf From tibbs at math.uh.edu Fri Feb 9 16:37:54 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Feb 2007 10:37:54 -0600 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> References: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> Message-ID: >>>>> "JCO" == Jeffrey C Ollie writes: JCO> I'll take clearsilver and trac if Jon doesn't want it... Why don't you both take them? It would be better for all involved to have more than one maintainer for trac in any case. - J< From nomis80 at nomis80.org Fri Feb 9 16:41:39 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Fri, 09 Feb 2007 11:41:39 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <1171037831.31485.164.camel@mccallum.corsepiu.local> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> Message-ID: <45CCA443.2010804@nomis80.org> Ralf Corsepius wrote: > On Fri, 2007-02-09 at 10:59 -0500, Simon Perreault wrote: >> Ralf Corsepius wrote: >>> So, the only results of recommendations to trust when it comes to >>> packaging binaries for a distro is those who are deeply familiar with >>> the guts of the OS, in case of Fedora, RH's GCC, glibc and kernel >>> developers. >> This is BS. > Beg your pardon? You don't need that level of familiarity to make good recommendations. You make it sound like Red Hat has some kind of old wise man and only he knows enough, and he only speaks once a year on summer solstice. >> Sure, people have thought about the defaults, but it doesn't >> mean that the packager doesn't know what he's doing either. > Rest assured: In 99% of all cases they don't know. Ok now, you say 99% of packagers can't package? BS. > They test on their "Pentium IV" and claim something - They can't have > any clues about what happens on a sparc, an i586 and > AMD X2 , or a ppc something. You sound very condescending. >> Some >> software, particularly numerical computation stuff, is built for being >> optimized properly. There are some extreme cases where using -O2 instead >> of -O3 simply makes a piece of software useless (take Blitz++ for example). > In other words: Crappy non-portable SW, The particular example I gave is a marvel of software engineering, useful to many scientists working with big arrays. What about ATLAS? It's currently in Extras, and the packager has done many unorthodox things to ensure maximum efficiency. Compiling it with -O2 would be stupid. > It is - It renders debugging impossible on many systems, Not much worse than -O2 already is. > strict-aliasing > silently kills SW on some targets You know this is enabled at -O2 right? > it might trigger exotic > target-specific bugs etc. etc. BS, and you know it. > As part of the distro you can't to compromise between different > trade-offs. WTF? You think Fedora isn't about compromise? It's full of it! People here compromise every single day. And that's a good thing! People who don't want the compromise a distro imposes on them run Linux from Scratch. From pertusus at free.fr Fri Feb 9 16:47:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Feb 2007 17:47:18 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <1171037831.31485.164.camel@mccallum.corsepiu.local> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> Message-ID: <20070209164718.GC2979@free.fr> On Fri, Feb 09, 2007 at 05:17:11PM +0100, Ralf Corsepius wrote: > > Sure, people have thought about the defaults, but it doesn't > > mean that the packager doesn't know what he's doing either. > Rest assured: In 99% of all cases they don't know. > > They test on their "Pentium IV" and claim something - They can't have > any clues about what happens on a sparc, an i586 and > AMD X2 , or a ppc something. That's a good point. It should indeed be verified/benchmarked on the most common arches supported. It is theoretically possible that contributors share their benchmarks on the different platforms to validate the results, but it is clearly not commonly happening in fedora... > > Using -O3 in specific cases isn't that big of a deal. > It is - It renders debugging impossible on many systems, strict-aliasing > silently kills SW on some targets, it might trigger exotic > target-specific bugs etc. etc. I admit that I am not familiar with this issue, but what you describe don't seem to be very reproducible. Besides it seems that for some of the issues you describe the issue is in the compiler, so it shouldn't prevent from using it, but instead it should be fixed in the compiler. -- Pat From rc040203 at freenet.de Fri Feb 9 17:24:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Feb 2007 18:24:20 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <45CCA443.2010804@nomis80.org> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <45CCA443.2010804@nomis80.org> Message-ID: <1171041860.31485.191.camel@mccallum.corsepiu.local> On Fri, 2007-02-09 at 11:41 -0500, Simon Perreault wrote: > Ralf Corsepius wrote: > > On Fri, 2007-02-09 at 10:59 -0500, Simon Perreault wrote: > >> Ralf Corsepius wrote: > >>> So, the only results of recommendations to trust when it comes to > >>> packaging binaries for a distro is those who are deeply familiar with > >>> the guts of the OS, in case of Fedora, RH's GCC, glibc and kernel > >>> developers. > >> This is BS. > > Beg your pardon? > > You don't need that level of familiarity to make good recommendations. > You make it sound like Red Hat has some kind of old wise man and only he > knows enough, and he only speaks once a year on summer solstice. I am not affiliated with RH. > >> Sure, people have thought about the defaults, but it doesn't > >> mean that the packager doesn't know what he's doing either. > > Rest assured: In 99% of all cases they don't know. > > Ok now, you say 99% of packagers can't package? BS. Well, this sentence was ill formulated, I meant 99% of all maintainers who want their packages to use -O3 don't know what they are doing. > >> Some > >> software, particularly numerical computation stuff, is built for being > >> optimized properly. There are some extreme cases where using -O2 instead > >> of -O3 simply makes a piece of software useless (take Blitz++ for example). > > In other words: Crappy non-portable SW, > > The particular example I gave is a marvel of software engineering, > useful to many scientists working with big arrays. I am well aware what Blitz++ is. This doesn't change anything about the fact that a package which needs "-O3 to be useful", is plain broken - period. A package that is reported to "gain a 10% performance boost" on a particular HW environment is something completely different. > > It is - It renders debugging impossible on many systems, > > Not much worse than -O2 already is. There are reasons why certain optimizations are in -O3 and why they are not in -O2, e.g. because some of them do not provide sufficient performance gains, some of them because they are too architecture specific, some of them because they are unsafe, some of them because they are considered unstable/experimental. > > strict-aliasing > > silently kills SW on some targets > > You know this is enabled at -O2 right? I know, but there is more to it. > > it might trigger exotic > > target-specific bugs etc. etc. > > BS, and you know it. Great, then you must be using a different GCC than I am. I have seen -O3 triggering target specific bugs on many occasions. > > As part of the distro you can't to compromise between different > > trade-offs. > > WTF? You think Fedora isn't about compromise? On a distro you must compromise: Exactly why using -O3 is a bad thing for a distro. Ralf From mattdm at mattdm.org Fri Feb 9 19:00:51 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Feb 2007 14:00:51 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070209164718.GC2979@free.fr> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <20070209164718.GC2979@free.fr> Message-ID: <20070209190051.GA13895@jadzia.bu.edu> On Fri, Feb 09, 2007 at 05:47:18PM +0100, Patrice Dumas wrote: > That's a good point. It should indeed be verified/benchmarked on the > most common arches supported. It is theoretically possible that > contributors share their benchmarks on the different platforms to > validate the results, but it is clearly not commonly happening in > fedora... How about I include a specific benchmark test in build section that runs for, say, a minute, and then use that to auto-select between O2 and O3 on a per-build basis? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From limb at jcomserv.net Fri Feb 9 19:24:11 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 9 Feb 2007 13:24:11 -0600 (CST) Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: References: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> Message-ID: <45864.65.192.24.190.1171049051.squirrel@mail.jcomserv.net> That's fine with me. Co-Maintaining into the Brave New Future. :) >>>>>> "JCO" == Jeffrey C Ollie writes: > > JCO> I'll take clearsilver and trac if Jon doesn't want it... > > Why don't you both take them? It would be better for all involved to > have more than one maintainer for trac in any case. > > - J< > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From pertusus at free.fr Fri Feb 9 19:41:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Feb 2007 20:41:50 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070209190051.GA13895@jadzia.bu.edu> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <20070209164718.GC2979@free.fr> <20070209190051.GA13895@jadzia.bu.edu> Message-ID: <20070209194150.GE2979@free.fr> On Fri, Feb 09, 2007 at 02:00:51PM -0500, Matthew Miller wrote: > On Fri, Feb 09, 2007 at 05:47:18PM +0100, Patrice Dumas wrote: > > That's a good point. It should indeed be verified/benchmarked on the > > most common arches supported. It is theoretically possible that > > contributors share their benchmarks on the different platforms to > > validate the results, but it is clearly not commonly happening in > > fedora... > > How about I include a specific benchmark test in build section that runs > for, say, a minute, and then use that to auto-select between O2 and O3 on a > per-build basis? :) I would be personally happy with that. If there are other issues beside speed I think that they should be handled at the level of gcc. -- Pat From ville.skytta at iki.fi Fri Feb 9 20:38:38 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 9 Feb 2007 22:38:38 +0200 Subject: rpms/mew/FC-5 mew.spec,1.6,1.7 In-Reply-To: <200702091317.l19DHk5p002365@cvs-int.fedora.redhat.com> References: <200702091317.l19DHk5p002365@cvs-int.fedora.redhat.com> Message-ID: <200702092238.39029.ville.skytta@iki.fi> On Friday 09 February 2007 15:17, Akira Tagoh wrote: > %changelog > -* Fri Feb 9 2007 Akira TAGOH - 5.2-2 > +* Fri Feb 9 2007 Akira TAGOH - 5.2-3 > - Remove all MIME handler definitions in mew-init.el so that it's no > longer needed. +- Remove xemacs-packages-extra deps. That's right, there's no xemacs-packages-extra on FC-5, but I suppose you'll want a dependency on xemacs-sumo there. Also, this commit has made the FC-5 branch newer than FC-6 and devel (5.2-3.* > 5.2-2.*) and thus FC-6 and devel will now require another bump too. See naming for how to push fixes like this for old branches only in the future: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#DistBump From nomis80 at nomis80.org Fri Feb 9 20:49:49 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Fri, 09 Feb 2007 15:49:49 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070209190051.GA13895@jadzia.bu.edu> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <20070209164718.GC2979@free.fr> <20070209190051.GA13895@jadzia.bu.edu> Message-ID: <45CCDE6D.1030408@nomis80.org> Matthew Miller wrote: > How about I include a specific benchmark test in build section that runs > for, say, a minute, and then use that to auto-select between O2 and O3 on a > per-build basis? :) This is not acceptable because it would make the build nondeterministic. From pertusus at free.fr Fri Feb 9 21:22:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Feb 2007 22:22:39 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <45CCDE6D.1030408@nomis80.org> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <20070209164718.GC2979@free.fr> <20070209190051.GA13895@jadzia.bu.edu> <45CCDE6D.1030408@nomis80.org> Message-ID: <20070209212239.GG2979@free.fr> On Fri, Feb 09, 2007 at 03:49:49PM -0500, Simon Perreault wrote: > Matthew Miller wrote: > >How about I include a specific benchmark test in build section that runs > >for, say, a minute, and then use that to auto-select between O2 and O3 on a > >per-build basis? :) > > This is not acceptable because it would make the build nondeterministic. Yes, but isn't the gain worth this issue? And it shouldn't be that nondeterministic or it means that the gain in execution time isn't that big. -- Pat From mattdm at mattdm.org Fri Feb 9 21:28:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 9 Feb 2007 16:28:48 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <45CCDE6D.1030408@nomis80.org> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <20070209164718.GC2979@free.fr> <20070209190051.GA13895@jadzia.bu.edu> <45CCDE6D.1030408@nomis80.org> Message-ID: <20070209212848.GA27000@jadzia.bu.edu> On Fri, Feb 09, 2007 at 03:49:49PM -0500, Simon Perreault wrote: > >How about I include a specific benchmark test in build section that runs > >for, say, a minute, and then use that to auto-select between O2 and O3 on a > >per-build basis? :) > This is not acceptable because it would make the build nondeterministic. Also it wouldn't really work depending on the other loads on the build system. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From cr33dog at gmail.com Fri Feb 9 23:35:52 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Fri, 9 Feb 2007 17:35:52 -0600 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: <45864.65.192.24.190.1171049051.squirrel@mail.jcomserv.net> References: <14572.65.192.24.190.1171027910.squirrel@mail.jcomserv.net> <1171028574.8283.25.camel@lt21223.campus.dmacc.edu> <45864.65.192.24.190.1171049051.squirrel@mail.jcomserv.net> Message-ID: I'll take ltsp-utils if no one wants it. I haven't packaged much for Fedora - co-mantainer(s) welcome. Chris From bpepple at fedoraproject.org Sat Feb 10 00:56:17 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 09 Feb 2007 19:56:17 -0500 Subject: FESCo Meeting Summary for 2007-02-08 Message-ID: <1171068977.28153.9.camel@Chuck> Members Present * Brian Pepple (bpepple) * Thorsten Leemhuis (thl) * Warren Togami (warren) * Jeremy Katz (jeremy) * Christian Iseli (ch4chris) * Toshio Kuratomi (abadger1999) * Jason Tibbitts (tibbs) * Tom Callaway (spot) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Rex Dieter (rdieter) * Josh Boyer (jwb) * Kevin Fenzi (nirik) * Jesse Keating (f13) Absent * Andreas Bierfert (awjb) == Summary == THL Leaving * thl is leaving FESCo due to possible conflicts with his day job. FESCo would like to thank Thorsten for all his hard work while he was on FESCo. Thanks! BTW: here's a link to his blog entry about leaving FESCo: http://thorstenl.blogspot.com/2007/02/leaving-fesco.html Core/Extras Merge * FESCo will wait a week before making a decision regarding the Core Review process, to get further feedback from the community. * Currently waiting for the new build system (Koji), which is still going through legal in regard to it's licensing. Co-Maintainership * thl worked on the proposal and adjusted the wording. He'll send it to FESCo members for review, and then to the public mailing lists. cvs-import * The plan is to modify cvs-import to 1) give a warning 2) provide a diff 3) make a cvs comment mandatory. Incompatible package upgrade policy * Maintainers should be aware of the effects that changes to their packages may have, and should alert other maintainers on the mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages. This is covered in the Maintainer Responsibilities policy proposal. http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy * In the future, the new updates system will not let repo breakage occur. Packaging Committee Report * FESCo didn't have any objections to the Packaging Committee's guidelines regarding: 1. non-pear PHP extension paths 2. desktop files - http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles 3. makeinstall clarification - http://fedoraproject.org/wiki/PackagingDrafts/MakeInstall 4. Making the suggested buildroot mandatory 5. All binaries must be built from source - http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement 6. buildrequires clarification - http://fedoraproject.org/wiki/PackagingDrafts/BuildRequires MISC * There was a discussion whether to have acl's enabled by default on new packages. * notting discussed that FAB had recently talked about firmware which would require: 1. make up a license tag for non-modifiable firmware for easy finding for users 2. modify the EULA to add an exception clause for firmware (similar to the one currently for trademarked logos) 3. release note the eula change 4. start poking vendors * jeremy mentioned that the bugzilla update script from owners.list should be running every 4 hours now. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070208 Thanks, /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 nomis80 at nomis80.org Sat Feb 10 02:59:37 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Fri, 9 Feb 2007 21:59:37 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070209212239.GG2979@free.fr> References: <20070208214737.GA20150@jadzia.bu.edu> <45CCDE6D.1030408@nomis80.org> <20070209212239.GG2979@free.fr> Message-ID: <200702092159.37365.nomis80@nomis80.org> On Friday February 9 2007 16:22, Patrice Dumas wrote: > Yes, but isn't the gain worth this issue? No, because a build *absolutely* needs to be deterministic, for security reasons among others. > And it shouldn't be that > nondeterministic or it means that the gain in execution time isn't > that big. You're right, but it is or it isn't. This isn't an analog thing. See the ATLAS package for ways to deal with this kind of thing. You have to "record" the execution on a host and be able to replay it deterministically. From wolfy at nobugconsulting.ro Sat Feb 10 04:34:57 2007 From: wolfy at nobugconsulting.ro (lonely wolf) Date: Sat, 10 Feb 2007 06:34:57 +0200 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070209212239.GG2979@free.fr> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <20070209164718.GC2979@free.fr> <20070209190051.GA13895@jadzia.bu.edu> <45CCDE6D.1030408@nomis80.org> <20070209212239.GG2979@free.fr> Message-ID: <45CD4B71.3000805@nobugconsulting.ro> On 02/09/2007 11:22 PM, Patrice Dumas wrote: > On Fri, Feb 09, 2007 at 03:49:49PM -0500, Simon Perreault wrote: > >> Matthew Miller wrote: >> >>> How about I include a specific benchmark test in build section that runs >>> for, say, a minute, and then use that to auto-select between O2 and O3 on a >>> per-build basis? :) >>> >> This is not acceptable because it would make the build nondeterministic. >> > > Yes, but isn't the gain worth this issue? And it shouldn't be that > nondeterministic or it means that the gain in execution time isn't > that big. The test would mean exactly zero for the end user who might have a completely different architecture. Optimizations which would work great on a dual-core-with-large cache-machine would probably mean zero or worse for a standard P4. What I - as end user - would find useful if I wanted to squeeze the last bit of performance is a table with benchmarks obtained on different architectures with different compilation options. But we cannot ship different packages with N architectures * M compilation options. Or can we? I think that a valid approach for such an option would be the application having the same code compiled in with different optimizations and doing a runtime check to select the fastest one. From opensource at till.name Sat Feb 10 08:29:55 2007 From: opensource at till.name (Till Maas) Date: Sat, 10 Feb 2007 09:29:55 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <1171041860.31485.191.camel@mccallum.corsepiu.local> References: <20070208214737.GA20150@jadzia.bu.edu> <45CCA443.2010804@nomis80.org> <1171041860.31485.191.camel@mccallum.corsepiu.local> Message-ID: <200702100930.05289.opensource@till.name> On Friday 09 February 2007 18:24, Ralf Corsepius wrote: > There are reasons why certain optimizations are in -O3 and why they are > not in -O2, e.g. because some of them do not provide sufficient > performance gains, some of them because they are too architecture > specific, some of them because they are unsafe, some of them because > they are considered unstable/experimental. According to the gcc manpage -O3 enables only three more optimizationes than -O3 does: -finline-functions -funswitch-loops -fgcse-after-reload Are all of them bad or is there more optimization done than is described there? 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 bugs.michael at gmx.net Sat Feb 10 10:55:11 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 10 Feb 2007 11:55:11 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171068977.28153.9.camel@Chuck> References: <1171068977.28153.9.camel@Chuck> Message-ID: <20070210115511.dc946f84.bugs.michael@gmx.net> On Fri, 09 Feb 2007 19:56:17 -0500, Brian Pepple wrote: > * In the future, the new updates system will not let repo breakage > occur. But the code that makes that possible is not available yet, is it? In the meantime, we can exclude build-job results from being published until a complete set of build-jobs is finished. All that's needed is a mail to the extras signers, which contains the list of src.rpm %{name}s to exclude. I committed rudimentary blacklist support to the pushscript yesterday. From seg at haxxed.com Sat Feb 10 11:16:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 10 Feb 2007 05:16:39 -0600 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <200702100930.05289.opensource@till.name> References: <20070208214737.GA20150@jadzia.bu.edu> <45CCA443.2010804@nomis80.org> <1171041860.31485.191.camel@mccallum.corsepiu.local> <200702100930.05289.opensource@till.name> Message-ID: <1171106199.27095.8.camel@localhost.localdomain> On Sat, 2007-02-10 at 09:29 +0100, Till Maas wrote: > According to the gcc manpage -O3 enables only three more optimizationes > than -O3 does: > > -finline-functions > -funswitch-loops > -fgcse-after-reload > > Are all of them bad or is there more optimization done than is described > there? From my CentOS 4 box: (gcc-3.4.6) `-O3' Optimize yet more. `-O3' turns on all optimizations specified by `-O2' and also turns on the `-finline-functions', `-fweb', `-frename-registers' and `-funswitch-loops' options. [...] `-frename-registers' Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. It can, however, make debugging impossible, since variables will no longer stay in a "home register". `-fweb' Constructs webs as commonly used for register allocation purposes and assign each web individual pseudo register. This allows the register allocation pass to operate on pseudos directly, but also strengthens several other optimization passes, such as CSE, loop optimizer and trivial dead code remover. It can, however, make debugging impossible, since variables will no longer stay in a "home register". Enabled at levels `-O3'. gcc versions can vary widely, like I said before, did upstream perform their performance tests on our compiler? Or at least a similar version? Or are they still using gcc 3.4 or something even older? This is key. -------------- 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 mattdm at mattdm.org Sat Feb 10 12:41:27 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 10 Feb 2007 07:41:27 -0500 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <1171106199.27095.8.camel@localhost.localdomain> References: <20070208214737.GA20150@jadzia.bu.edu> <45CCA443.2010804@nomis80.org> <1171041860.31485.191.camel@mccallum.corsepiu.local> <200702100930.05289.opensource@till.name> <1171106199.27095.8.camel@localhost.localdomain> Message-ID: <20070210124127.GA20389@jadzia.bu.edu> On Sat, Feb 10, 2007 at 05:16:39AM -0600, Callum Lerwick wrote: > gcc versions can vary widely, like I said before, did upstream perform > their performance tests on our compiler? Or at least a similar version? > Or are they still using gcc 3.4 or something even older? This is key. No idea; likely older stuff. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at fedoraproject.org Sat Feb 10 14:04:42 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 10 Feb 2007 09:04:42 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-10 Message-ID: <20070210140442.56DDA15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 8 centericq-4.21.0-11.fc7 environment-modules-3.2.4-1.fc7 gutenprint-5.0.0-5.fc7 moin-1.5.7-1.fc7 ncarg-4.4.1-8.fc7 php-Smarty-2.6.16-1.fc7 python-matplotlib-0.90.0-1.fc7 vnc-reflector-1.2.4-3.fc7 Packages built and released for Fedora Extras 6: 6 centericq-4.21.0-9.fc6 dnsmasq-2.37-1.fc6 environment-modules-3.2.4-1.fc6 nas-1.8-13.fc6 ncarg-4.4.1-8.fc6 vnc-reflector-1.2.4-3.fc6 Packages built and released for Fedora Extras 5: 7 centericq-4.21.0-8.fc5 dnsmasq-2.37-1.fc5 environment-modules-3.2.4-1.fc5 mew-5.2-3.fc5 nas-1.8-13.fc5 ufraw-0.9.1-1.fc5 vnc-reflector-1.2.4-3.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jkeating at redhat.com Sat Feb 10 14:33:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 10 Feb 2007 09:33:04 -0500 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070210115511.dc946f84.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <20070210115511.dc946f84.bugs.michael@gmx.net> Message-ID: <200702100933.05070.jkeating@redhat.com> On Saturday 10 February 2007 05:55, Michael Schwendt wrote: > But the code that makes that possible is not available yet, is it? I think it is somewhat manual. It copies over the proposed updates to a temp dir, creates a repo, and then does repoclosure. If there are broken deps, I can uncheck specific things for updates and try the depcheck again before I push. -- 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 Sat Feb 10 15:02:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 10 Feb 2007 16:02:08 +0100 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <200702100930.05289.opensource@till.name> References: <20070208214737.GA20150@jadzia.bu.edu> <45CCA443.2010804@nomis80.org> <1171041860.31485.191.camel@mccallum.corsepiu.local> <200702100930.05289.opensource@till.name> Message-ID: <1171119728.31485.244.camel@mccallum.corsepiu.local> On Sat, 2007-02-10 at 09:29 +0100, Till Maas wrote: > On Friday 09 February 2007 18:24, Ralf Corsepius wrote: > > > There are reasons why certain optimizations are in -O3 and why they are > > not in -O2, e.g. because some of them do not provide sufficient > > performance gains, some of them because they are too architecture > > specific, some of them because they are unsafe, some of them because > > they are considered unstable/experimental. > > According to the gcc manpage -O3 enables only three more optimizationes > than -O3 does: "Paper has patience" ("Papier ist geduldig"), as we say in German ;) > -finline-functions > -funswitch-loops > -fgcse-after-reload > > Are all of them bad or is there more optimization done than is described > there? No idea, one would have to have a look into the source code. -OX change widely between GCC releases and also can differ between different vendors. Ralf From jspaleta at gmail.com Sun Feb 11 06:35:31 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 Feb 2007 21:35:31 -0900 Subject: For your dining pleasure.. i give you experimental packages of usbsink Message-ID: <604aa7910702102235q4fd3331eude71c3e40e850897@mail.gmail.com> Good Alaskan Evening! I have produced a set of packages and a package review request for usbsink. I thought I'd let everyone on the list know about it.. because I think this is actually pretty super keen, and I think a lot of people might want to try it out and see how well it works. If a lot of people find it useful, perhaps it will be useful enough to think about as an f7 or later desktop 'feature' for a default desktop install. I make no such claim yet...but I see this application's..potential.. since its one of the rare applications I ask my wife about which illicts a response like 'oooooh that would be handy.' -jef"Because my wife has a far better feel for the pulse of mainstream desktop users than I..she keeps her desktop effects turned on..and I cringe at the sight of the wasted gpu cycles"spaleta References: http://usbsink.sourceforge.net/ USBSink is a GNOME program for automatic file synchronization over USB. It is designed for users of removable drives, such as flash drives or external hard disks. In USBSink you define a task associated to a particular USB drive, and then have a complete automation of data trasfers. With file monitoring and hardware detection features, USBSink is able to respond and act according to relevant events on the desktop. Experimental Package Location: http://jspaleta.thecodergeek.com/Fedora%20SRPMS/usbsink/ binaries for fe6 and fe-development are available Review Request Ticket: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228188 From buildsys at fedoraproject.org Sun Feb 11 22:57:17 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 11 Feb 2007 17:57:17 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-11 Message-ID: <20070211225717.C9D7115212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 32 Pound-2.2.4-1.fc7 TeXmacs-1.0.6.8-2.fc7 boo-0.7.6.2237-12.fc7 chkrootkit-0.47-6.fc7 NEW cronolog-1.6.2-4.fc7 deskbar-applet-2.17.90-3.fc7 emacs-common-muse-3.02.93-5.fc7 emacs-vm-7.19-8.fc7 eventlog-0.2.5-3.fc7 genius-0.7.7-2.fc7 gnu-smalltalk-2.3.2-5.fc7 gpodder-0.8.9-1.fc7 graveman-0.3.12.5-3.fc7 hspell-1.0-6.fc7 hugs98-2006.09-3.fc7 jd-1.8.5-2.cvs070211.1.fc7 libnetfilter_conntrack-0.0.50-1.fc7 liferea-1.2.6b-1.fc7 listen-0.5-12.svn657.fc7.2 manedit-0.8.1-1.fc7 moomps-5.8-2.fc7 pan-0.123-1.fc7 perl-Email-MIME-1.858-1.fc7 perl-Email-Simple-1.998-1.fc7 perl-File-HomeDir-0.64-1.fc7 perl-Geo-Ellipsoids-0.14-1.fc7 perl-Glib-1.143-1.fc7 perl-Log-Log4perl-1.09-1.fc7 python-matplotlib-0.90.0-2.fc7 syslog-ng-2.0.2-1.fc7 ucblogo-5.5-6.fc7 yap-5.1.1-3.fc7 Packages built and released for Fedora Extras 6: 12 TeXmacs-1.0.6.8-2.fc6 NEW cronolog-1.6.2-4.fc6 emacs-common-muse-3.02.93-5.fc6 emacs-vm-7.19-7.fc6 eventlog-0.2.5-3.fc6 graveman-0.3.12.5-3.fc6 manedit-0.8.1-1.fc6 pan-0.123-1.fc6 perl-Email-MIME-1.858-1.fc6 perl-Geo-Ellipsoids-0.14-1.fc6 perl-Glib-1.143-1.fc6 perl-Log-Log4perl-1.09-1.fc6 Packages built and released for Fedora Extras 5: 11 NEW cronolog-1.6.2-4.fc5 emacs-common-muse-3.02.93-5.fc5 emacs-vm-7.19-7.fc5 eventlog-0.2.5-3.fc5 graveman-0.3.12.5-3.fc5 inkscape-0.45-1.fc5 manedit-0.8.1-1.fc5 perl-Email-MIME-1.858-1.fc5 perl-Geo-Ellipsoids-0.14-1.fc5 perl-Glib-1.143-1.fc5 perl-Log-Log4perl-1.09-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lsof at nodata.co.uk Sun Feb 11 22:57:31 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 11 Feb 2007 23:57:31 +0100 Subject: For your dining pleasure.. i give you experimental packages of usbsink In-Reply-To: <604aa7910702102235q4fd3331eude71c3e40e850897@mail.gmail.com> References: <604aa7910702102235q4fd3331eude71c3e40e850897@mail.gmail.com> Message-ID: <1171234651.3193.13.camel@localhost.localdomain> Am Samstag, den 10.02.2007, 21:35 -0900 schrieb Jeff Spaleta: > Good Alaskan Evening! > > I have produced a set of packages and a package review request for > usbsink. I thought I'd let everyone on the list know about it.. > because I think this is actually pretty super keen, and I think a lot > of people might want to try it out and see how well it works. If a > lot of people find it useful, perhaps it will be useful enough to > think about as an f7 or later desktop 'feature' for a default desktop > install. I make no such claim yet...but I see this > application's..potential.. since its one of the rare applications I > ask my wife about which illicts a response like 'oooooh that would be > handy.' > > -jef"Because my wife has a far better feel for the pulse of mainstream > desktop users than I..she keeps her desktop effects turned on..and I > cringe at the sight of the wasted gpu cycles"spaleta > > References: > http://usbsink.sourceforge.net/ > USBSink is a GNOME program for automatic file synchronization over > USB. It is designed for users of removable drives, such as flash > drives or external hard disks. In USBSink you define a task associated > to a particular USB drive, and then have a complete automation of data > trasfers. With file monitoring and hardware detection features, > USBSink is able to respond and act according to relevant events on the > desktop. > > Experimental Package Location: > http://jspaleta.thecodergeek.com/Fedora%20SRPMS/usbsink/ > binaries for fe6 and fe-development are available > > Review Request Ticket: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228188 > Interesting. Does it use librsync under the hood? From jspaleta at gmail.com Mon Feb 12 02:56:56 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 11 Feb 2007 17:56:56 -0900 Subject: For your dining pleasure.. i give you experimental packages of usbsink In-Reply-To: <1171234651.3193.13.camel@localhost.localdomain> References: <604aa7910702102235q4fd3331eude71c3e40e850897@mail.gmail.com> <1171234651.3193.13.camel@localhost.localdomain> Message-ID: <604aa7910702111856i3bccd05fle76b45d88816c280@mail.gmail.com> On 2/11/07, nodata wrote: > Interesting. Does it use librsync under the hood? not at the moment... something to bring up with the upstream developer. from the website's stated plans using libsync in future versions isnt out of the question. What is super-keen about it is it basically provides a digestable enduser solution for backing up personal data. Something the desktop experience really needs, I think. usbsink may not be the right solution long term..but it may very well be the best solution right now. Its worth a serious kick of its tires. I was sort of hoping the hal/dbus-guruish people would look at it and comment. Hell even the oh-so-very-cute WD MyBook usb/firewire drives come with software to let windows users to do exactly this sort of thing using the mybook drive. -jef"totally wants a way to push the button on his WD Mybook drive casing and have it start a personal data backup process as part of his Gnome Session. I wonder does linux even 'see' the button press action...where the hell would i look to see if linux sees me press the button?"spaleta From giallu at gmail.com Mon Feb 12 07:50:00 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 12 Feb 2007 08:50:00 +0100 Subject: For your dining pleasure.. i give you experimental packages of usbsink In-Reply-To: <604aa7910702111856i3bccd05fle76b45d88816c280@mail.gmail.com> References: <604aa7910702102235q4fd3331eude71c3e40e850897@mail.gmail.com> <1171234651.3193.13.camel@localhost.localdomain> <604aa7910702111856i3bccd05fle76b45d88816c280@mail.gmail.com> Message-ID: On 2/12/07, Jeff Spaleta wrote: > > -jef"totally wants a way to push the button on his WD Mybook drive > casing and have it start a personal data backup process as part of his > Gnome Session. I wonder does linux even 'see' the button press > action...where the hell would i look to see if linux sees me press the > button?"spaleta > This would be extra cool... I think the windows counterpart has a small program polling the USB link for such events; you may want to start from a USB snooping session in Windows to see what is transmitted on the wire. I'd also wonder what the results would be trying to contact WD about giving developers some specs... From buildsys at fedoraproject.org Mon Feb 12 18:44:17 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 12 Feb 2007 13:44:17 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-12 Message-ID: <20070212184417.08B2915212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 10 GeoIP-1.4.2-1.fc7 akode-2.0.1-5.fc7 gnomad2-2.8.11-2.fc7 gnome-applet-music-2.1.0-1.fc7 incron-0.5.4-1.fc7 jd-1.8.5-2.cvs070212.fc7 piklab-0.13.3-1.fc7 postgresql-pgpool-3.2-1.fc7 puppet-0.22.1-2.fc7 python-simpy-1.8-1.fc7 Packages built and released for Fedora Extras 6: 7 djvulibre-3.5.18-1.fc6 gnomad2-2.8.11-2.fc6 incron-0.5.4-1.fc6 moin-1.5.7-1.fc6 piklab-0.13.3-1.fc6 postgresql-pgpool-3.2-1.fc6 puppet-0.22.1-2.fc6 Packages built and released for Fedora Extras 5: 7 djvulibre-3.5.18-1.fc5 gnomad2-2.8.11-2.fc5 incron-0.5.4-1.fc5 moin-1.5.7-1.fc5 piklab-0.13.3-1.fc5 postgresql-pgpool-3.2-1.fc5 puppet-0.22.1-2.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tagoh at redhat.com Tue Feb 13 03:05:02 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Tue, 13 Feb 2007 12:05:02 +0900 (JST) Subject: rpms/mew/FC-5 mew.spec,1.6,1.7 In-Reply-To: <200702092238.39029.ville.skytta@iki.fi> References: <200702091317.l19DHk5p002365@cvs-int.fedora.redhat.com> <200702092238.39029.ville.skytta@iki.fi> Message-ID: <20070213.120502.232920279.tagoh@redhat.com> >>>>> On Fri, 9 Feb 2007 22:38:38 +0200, >>>>> "VS" == Ville Skytt? wrote: VS> That's right, there's no xemacs-packages-extra on FC-5, but I suppose you'll VS> want a dependency on xemacs-sumo there. Maybe. VS> Also, this commit has made the FC-5 branch newer than FC-6 and devel (5.2-3.* >> 5.2-2.*) and thus FC-6 and devel will now require another bump too. See VS> naming for how to push fixes like this for old branches only in the future: VS> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#DistBump Thank you for the tip. I forgot that issue :) will rebuild them then. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Tue Feb 13 12:57:29 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 13 Feb 2007 13:57:29 +0100 Subject: libInventor.so.0.0.0: bug or feature? Message-ID: [giallu at molzilla ~]$ rpm -q Inventor Inventor-2.1.5-24.fc5 [giallu at molzilla ~]$ rpm -ql Inventor [snip] /usr/lib/libInventor.so.0 /usr/lib/libInventor.so.0.0.0 [snip] is this made intentionally? Cheers Gianluca From rc040203 at freenet.de Tue Feb 13 13:20:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 14:20:57 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: References: Message-ID: <1171372857.3622.127.camel@mccallum.corsepiu.local> On Tue, 2007-02-13 at 13:57 +0100, Gianluca Sforna wrote: > [giallu at molzilla ~]$ rpm -q Inventor > Inventor-2.1.5-24.fc5 > [giallu at molzilla ~]$ rpm -ql Inventor > [snip] > /usr/lib/libInventor.so.0 > /usr/lib/libInventor.so.0.0.0 > [snip] > > is this made intentionally? I don't understand - Could you elaborate? Ralf From rc040203 at freenet.de Tue Feb 13 14:10:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 15:10:46 +0100 Subject: FE CVS: missing %dist %fedora? Message-ID: <1171375847.3622.135.camel@mccallum.corsepiu.local> Hi, Seems to me as if building rpms in checked out copies of FE-CVS now seems broken: After a "cvs up" make started to produce rpms without %dist and breaks building rpm-specs which apply %fedora. Is this just me (and having screwed up locally)? Ralf From giallu at gmail.com Tue Feb 13 14:46:36 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 13 Feb 2007 15:46:36 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: <1171372857.3622.127.camel@mccallum.corsepiu.local> References: <1171372857.3622.127.camel@mccallum.corsepiu.local> Message-ID: On 2/13/07, Ralf Corsepius wrote: > On Tue, 2007-02-13 at 13:57 +0100, Gianluca Sforna wrote: > > [giallu at molzilla ~]$ rpm -q Inventor > > Inventor-2.1.5-24.fc5 > > [giallu at molzilla ~]$ rpm -ql Inventor > > [snip] > > /usr/lib/libInventor.so.0 > > /usr/lib/libInventor.so.0.0.0 > > [snip] > > > > is this made intentionally? > > I don't understand - Could you elaborate? > I meant the 0.0.0 triplet used as version. Is that right/usual to have? In the meanwhile, I spotted a problem in the spec file: around line 220 there are 4 install commands like: install -d m755 instead of install -d -m755 From rc040203 at freenet.de Tue Feb 13 15:01:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 16:01:16 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: References: <1171372857.3622.127.camel@mccallum.corsepiu.local> Message-ID: <1171378876.3622.146.camel@mccallum.corsepiu.local> On Tue, 2007-02-13 at 15:46 +0100, Gianluca Sforna wrote: > On 2/13/07, Ralf Corsepius wrote: > > On Tue, 2007-02-13 at 13:57 +0100, Gianluca Sforna wrote: > > > [giallu at molzilla ~]$ rpm -q Inventor > > > Inventor-2.1.5-24.fc5 > > > [giallu at molzilla ~]$ rpm -ql Inventor > > > [snip] > > > /usr/lib/libInventor.so.0 > > > /usr/lib/libInventor.so.0.0.0 > > > [snip] > > > > > > is this made intentionally? > > > > I don't understand - Could you elaborate? > > > > I meant the 0.0.0 triplet used as version. Is that right/usual to have? There is nothing wrong in using "libXXX.so.0.0.0" for a library using an SONAME of "libXXX.so.0", accompanied by a symlink "libXXX.so.0" pointing to "libXXX.so.0.0.0". > In the meanwhile, I spotted a problem in the spec file: around line > 220 there are 4 install commands like: > > install -d m755 > > instead of > > install -d -m755 Thanks, will fix in CVS. Ralf From rc040203 at freenet.de Tue Feb 13 15:24:40 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 16:24:40 +0100 Subject: FC6: Upgrading opencv? (SONAME breakage) Message-ID: <1171380280.3622.159.camel@mccallum.corsepiu.local> Hi, I received a request to upgrade opencv (currently at version 0.9.9, a prerelease of 1.0.0) to version 1.0.0 for FE6 (in FE7 since December). Unfortunately, between version 0.9.9 and version 1.0.0, upstream has changed SONAMEs from libXX.so.0 to libXX.so.1, i.e. such an upgrade would break package deps on Fedora 6. Theoretically, I could provide a compat-package, but given the fact that there doesn't seem to be a package in Fedora which depends on opencv, the risks of upgrading are rather low. Therefore, QUESTION: Is there anybody out there who is opposed to me upgrading opencv for FE6 to opencv-1.0.0? Please speak up now or comment to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228510 Ralf From giallu at gmail.com Tue Feb 13 15:26:59 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 13 Feb 2007 16:26:59 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: <1171378876.3622.146.camel@mccallum.corsepiu.local> References: <1171372857.3622.127.camel@mccallum.corsepiu.local> <1171378876.3622.146.camel@mccallum.corsepiu.local> Message-ID: On 2/13/07, Ralf Corsepius wrote: > > I meant the 0.0.0 triplet used as version. Is that right/usual to have? > > There is nothing wrong in using "libXXX.so.0.0.0" for a library using an > SONAME of "libXXX.so.0", accompanied by a symlink "libXXX.so.0" pointing > to "libXXX.so.0.0.0". OK. thanks for the clarification From rc040203 at freenet.de Tue Feb 13 15:36:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 16:36:53 +0100 Subject: FE CVS: missing %dist %fedora? In-Reply-To: <1171375847.3622.135.camel@mccallum.corsepiu.local> References: <1171375847.3622.135.camel@mccallum.corsepiu.local> Message-ID: <1171381013.3622.163.camel@mccallum.corsepiu.local> On Tue, 2007-02-13 at 15:10 +0100, Ralf Corsepius wrote: > Hi, > > Seems to me as if building rpms in checked out copies of FE-CVS now > seems broken: > > After a "cvs up" > make > started to produce rpms without %dist and breaks building rpm-specs > which apply %fedora. > > Is this just me (and having screwed up locally)? No, it's not just me, even a fresh anonymous checkout exposes this issue. # cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/extras co Inventor # cd Inventor/devel # make i386 Ralf From jeff at ocjtech.us Tue Feb 13 16:17:31 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 13 Feb 2007 10:17:31 -0600 Subject: FE CVS: missing %dist %fedora? In-Reply-To: <1171381013.3622.163.camel@mccallum.corsepiu.local> References: <1171375847.3622.135.camel@mccallum.corsepiu.local> <1171381013.3622.163.camel@mccallum.corsepiu.local> Message-ID: <1171383451.3877.9.camel@lt21223.campus.dmacc.edu> On Tue, 2007-02-13 at 16:36 +0100, Ralf Corsepius wrote: > On Tue, 2007-02-13 at 15:10 +0100, Ralf Corsepius wrote: > > Hi, > > > > Seems to me as if building rpms in checked out copies of FE-CVS now > > seems broken: > > > > After a "cvs up" > > make > > started to produce rpms without %dist and breaks building rpm-specs > > which apply %fedora. > > > > Is this just me (and having screwed up locally)? > > No, it's not just me, even a fresh anonymous checkout exposes this > issue. > > # cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/extras co Inventor > # cd Inventor/devel > # make i386 > AFAIK, "make i386" has never defined %dist and %fedora, because "make i386" is just running plain ol' rpmbuild with a few macros on the command line to get everything in the right directory. %dist and % fedora are only defined in the build environment set up by mock. FWIW you can run "make mockbuild" to run a local mock build. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Feb 13 16:36:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Feb 2007 17:36:58 +0100 Subject: FE CVS: missing %dist %fedora? In-Reply-To: <1171383451.3877.9.camel@lt21223.campus.dmacc.edu> References: <1171375847.3622.135.camel@mccallum.corsepiu.local> <1171381013.3622.163.camel@mccallum.corsepiu.local> <1171383451.3877.9.camel@lt21223.campus.dmacc.edu> Message-ID: <1171384618.3622.186.camel@mccallum.corsepiu.local> On Tue, 2007-02-13 at 10:17 -0600, Jeffrey C. Ollie wrote: > On Tue, 2007-02-13 at 16:36 +0100, Ralf Corsepius wrote: > > On Tue, 2007-02-13 at 15:10 +0100, Ralf Corsepius wrote: > > > Hi, > > > > > > Seems to me as if building rpms in checked out copies of FE-CVS now > > > seems broken: > > > > > > After a "cvs up" > > > make > > > started to produce rpms without %dist and breaks building rpm-specs > > > which apply %fedora. > > > > > > Is this just me (and having screwed up locally)? > > > > No, it's not just me, even a fresh anonymous checkout exposes this > > issue. > > > > # cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/extras co Inventor > > # cd Inventor/devel > > # make i386 > > > > AFAIK, "make i386" has never defined %dist and %fedora, because "make > i386" is just running plain ol' rpmbuild with a few macros on the > command line to get everything in the right directory. You could be right ... the last change to Makefile.common is 1/2 year old ;) Except for very few packages (Inventor is one them) I don't actively use %fedora and %dist inside of my specs, and am normally using mock for building. So this might have escaped me :-o > %dist and % > fedora are only defined in the build environment set up by mock. "make srpm" supports them ;) Ralf From jkeating at redhat.com Tue Feb 13 16:51:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Feb 2007 11:51:24 -0500 Subject: FE CVS: missing %dist %fedora? In-Reply-To: <1171384618.3622.186.camel@mccallum.corsepiu.local> References: <1171375847.3622.135.camel@mccallum.corsepiu.local> <1171383451.3877.9.camel@lt21223.campus.dmacc.edu> <1171384618.3622.186.camel@mccallum.corsepiu.local> Message-ID: <200702131151.24868.jkeating@redhat.com> On Tuesday 13 February 2007 11:36, Ralf Corsepius wrote: > > AFAIK, "make i386" has never defined %dist and %fedora, because "make > > i386" is just running plain ol' rpmbuild with a few macros on the > > command line to get everything in the right directory. > > You could be right ... the last change to Makefile.common is 1/2 year > old ;) > > Except for very few packages (Inventor is one them) I don't actively use > %fedora and %dist inside of my specs, and am normally using mock for > building. So this might have escaped me :-o > > > ? %dist and % > > fedora are only defined in the build environment set up by mock. > > "make srpm" supports them ;) One might think this is a bug in Makefile.common. Any cases where rpm is called the dist and fedora should be defined based on what branch it is being called from. I would fix it, but I'm busy preparing koji for release (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tdiehl at rogueind.com Tue Feb 13 17:16:24 2007 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 13 Feb 2007 12:16:24 -0500 (EST) Subject: rpmlint question Message-ID: Hi, I am trying to learn how to make rpms. When I run rpmlint against the package I am trying to make I get the following output: (bullwinkle pts31) $ rpmlint dspam-3.6.8-1.fc5.mtd.1.i386.rpm W: dspam devel-file-in-non-devel-package /usr/lib/libdspam.so E: dspam setgid-binary /usr/bin/dspam root 02510 E: dspam non-standard-executable-perm /usr/bin/dspam 02510 E: dspam non-standard-executable-perm /usr/bin/dspam 02510 (bullwinkle pts31) $ I understand the permissions entries but what I do not understand is why is rpmlint complaining about libdspam.so. It is installed as follows: (bullwinkle pts35) $ ll /var/tmp/dspam-3.6.8-1.fc5.mtd.1-root-tdiehl/usr/lib total 392 lrwxrwxrwx 1 tdiehl tdiehl 17 Feb 13 12:09 libdspam.so -> libdspam.so.7.0.0 lrwxrwxrwx 1 tdiehl tdiehl 17 Feb 13 12:09 libdspam.so.7 -> libdspam.so.7.0.0 -rwxr-xr-x 1 tdiehl tdiehl 88320 Feb 13 12:09 libdspam.so.7.0.0 (bullwinkle pts35) $ Is this really incorrect or is rpmlint confused? Please go easy on me, as I am not a programmer but I am trying to learn. Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From notting at redhat.com Tue Feb 13 17:17:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Feb 2007 12:17:32 -0500 Subject: rpmlint question In-Reply-To: References: Message-ID: <20070213171732.GB1373@nostromo.devel.redhat.com> Tom Diehl (tdiehl at rogueind.com) said: > I am trying to learn how to make rpms. When I run rpmlint against the > package > I am trying to make I get the following output: > > (bullwinkle pts31) $ rpmlint dspam-3.6.8-1.fc5.mtd.1.i386.rpm > W: dspam devel-file-in-non-devel-package /usr/lib/libdspam.so Generally, lib.so is used for development purposes. It's what the linker looks at when you link against that library with -l. So it's classified as a development file. The only other use of lib.so would be if it's a dynamically loaded module or plugin, loaded with dlopen() or similar code. (However, in that case, it's probably better to specify a particular ABI version, so programs don't get a version that's different from the API/ABI they compiled against.) If libdspam.so isn't a plugin used by other programs, just remove libdspam.so from your file list. Bill From tmz at pobox.com Tue Feb 13 17:49:57 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 13 Feb 2007 12:49:57 -0500 Subject: rpmlint question In-Reply-To: <20070213171732.GB1373@nostromo.devel.redhat.com> References: <20070213171732.GB1373@nostromo.devel.redhat.com> Message-ID: <20070213174957.GF23466@psilocybe.teonanacatl.org> Bill Nottingham wrote: > If libdspam.so isn't a plugin used by other programs, just remove > libdspam.so from your file list. And to possibly save you from another error, you'll either want to rm the file from the buildroot in %install section or use %exclude in %files. %install [...] rm -f %{buildroot}/%{_libdir}/libdspam.so Or: %files [...] %exclude %{_libdir}/libdspam.so If you just remove it from the file list and it is found in the buildroot, rpm will complain about unpackaged files. HTH -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== If God had meant for us to be naked, we would have been born that way. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rcritten at redhat.com Tue Feb 13 22:27:07 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Feb 2007 17:27:07 -0500 Subject: signing a JAR file Message-ID: <45D23B3B.9020007@redhat.com> I'm looking into adding Java Security Services (JSS). This is a Java JNI interface to Network Security Services (NSS) for crypto. According to http://www.mozilla.org/projects/security/pki/jss/provider_notes.html it won't work unless the jar file is signed (using jarsigner). So I'm not sure how to proceed. Has this come up with any other packages? thanks rob -- Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From laurent.rineau__fedora_extras at normalesup.org Tue Feb 13 23:46:07 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Wed, 14 Feb 2007 00:46:07 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: <1171378876.3622.146.camel@mccallum.corsepiu.local> References: <1171378876.3622.146.camel@mccallum.corsepiu.local> Message-ID: <200702140046.07550@rineau.tsetse> On Tuesday 13 February 2007 16:01:16 Ralf Corsepius wrote: > There is nothing wrong in using "libXXX.so.0.0.0" for a library using an > SONAME of "libXXX.so.0", accompanied by a symlink "libXXX.so.0" pointing > to "libXXX.so.0.0.0". Having libXXX.so.0.0.0 as soversion probably means that the somajor and soversion are not set by the upstream developers (GNU/autotools defaults the soversion to 0.0.0). It probably means that next release of the library will have the same set of somajor/soversion, whatever is the binary compatibility of that release with the previous one. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From triad at df.lth.se Wed Feb 14 06:35:21 2007 From: triad at df.lth.se (Linus Walleij) Date: Wed, 14 Feb 2007 07:35:21 +0100 (CET) Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: <200702140046.07550@rineau.tsetse> References: <1171378876.3622.146.camel@mccallum.corsepiu.local> <200702140046.07550@rineau.tsetse> Message-ID: On Wed, 14 Feb 2007, Laurent Rineau wrote: > Having libXXX.so.0.0.0 as soversion probably means that the somajor and > soversion are not set by the upstream developers (GNU/autotools defaults the > soversion to 0.0.0). It probably means that next release of the library will > have the same set of somajor/soversion, whatever is the binary compatibility > of that release with the previous one. The typical way to use this during early development is to release libfoo-1.0.so.0, then libfoo-1.1.so.0 etc, as a marker that the package is pre-alpha. However it should be noticed that library versioning is so hairy and unproperly undocumented that 90% of developers invariably get it wrong the first time and also later. So they often need education. I have myself needed much education on this and I still do mistakes... So give advice and patches to upstream. Linus From ville.skytta at iki.fi Wed Feb 14 07:12:22 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 14 Feb 2007 09:12:22 +0200 Subject: signing a JAR file In-Reply-To: <45D23B3B.9020007@redhat.com> References: <45D23B3B.9020007@redhat.com> Message-ID: <200702140912.22971.ville.skytta@iki.fi> On Wednesday 14 February 2007, Rob Crittenden wrote: > I'm looking into adding Java Security Services (JSS). This is a Java JNI > interface to Network Security Services (NSS) for crypto. > > According to > http://www.mozilla.org/projects/security/pki/jss/provider_notes.html it > won't work unless the jar file is signed (using jarsigner). It won't work with Sun's (nor with BEA's, IBM's etc I think) Java unless signed, but I guess GCJ doesn't care. But that's just guesswork, haven't verified it. From rc040203 at freenet.de Wed Feb 14 07:41:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Feb 2007 08:41:28 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: References: <1171378876.3622.146.camel@mccallum.corsepiu.local> <200702140046.07550@rineau.tsetse> Message-ID: <1171438888.3622.216.camel@mccallum.corsepiu.local> On Wed, 2007-02-14 at 07:35 +0100, Linus Walleij wrote: > On Wed, 14 Feb 2007, Laurent Rineau wrote: > > > Having libXXX.so.0.0.0 as soversion probably means that the somajor and > > soversion are not set by the upstream developers (GNU/autotools defaults the > > soversion to 0.0.0). It probably means that next release of the library will > > have the same set of somajor/soversion, whatever is the binary compatibility > > of that release with the previous one. > > The typical way to use this during early development is to release > libfoo-1.0.so.0, then libfoo-1.1.so.0 etc, as a marker that the package is > pre-alpha. There exist different ways of naming share libraries. What you describe above is one way of doing so. I prefer using the "libtool way" (cf. info libtool versioning), i.e. libXXX.so -> libXXX.so.X (SONAME) -> libXXX.so.X.Y.Z This is the way the vast majority of shared libs are versioned on Linux. > However it should be noticed that library versioning is so hairy and > unproperly undocumented that 90% of developers invariably get it wrong the > first time and also later. The reason is simple: There is no "nominal standard". There exist several ways of versioning shared libraries, all with pros and cons. There exist different personal preferences, mostly stemming from a person's and a package's history. > So they often need education. I have myself > needed much education on this and I still do mistakes... So give advice > and patches to upstream. ROTFL - Inventor is an elderly, former "monster package" SGI had sold for $$$$ during the 1990's and had released LGPL'ed ca. in 2000. They had been responsive to patches/fixes in subsequent years, but since ca. 2003 their responsiveness has stalled. In other words, this is "dead-stable" code without an active upstream nor development. De facto, everything is in "keep-alive" maintenance by Linux distros keeping their packages going and them occasionally mutually harvesting/exchanging their patches and modifications. I.e. the de facto upstream are Debian and Fedora (i.e. me). The 0.0.0 in this particular case originates from Debian, because the original sources from SGI did not apply any SONAME. Ralf From giallu at gmail.com Wed Feb 14 08:06:26 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 14 Feb 2007 09:06:26 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: <1171438888.3622.216.camel@mccallum.corsepiu.local> References: <1171378876.3622.146.camel@mccallum.corsepiu.local> <200702140046.07550@rineau.tsetse> <1171438888.3622.216.camel@mccallum.corsepiu.local> Message-ID: On 2/14/07, Ralf Corsepius wrote: > > So they often need education. I have myself > > needed much education on this and I still do mistakes... So give advice > > and patches to upstream. > > ROTFL - Inventor is an elderly, former "monster package" SGI had sold > for $$$$ during the 1990's and had released LGPL'ed ca. in 2000. > They had been responsive to patches/fixes in subsequent years, but since > ca. 2003 their responsiveness has stalled. And given they just re-emerged from bankrupt, I seriously doubt it will ever improve... > > In other words, this is "dead-stable" code without an active upstream > nor development. De facto, everything is in "keep-alive" maintenance by > Linux distros keeping their packages going and them occasionally > mutually harvesting/exchanging their patches and modifications. > I.e. the de facto upstream are Debian and Fedora (i.e. me). And I thank you both for that... I was actaully pretty impressed by the 219Kb (bzipped) applied "monster patch" :) From rc040203 at freenet.de Wed Feb 14 08:49:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Feb 2007 09:49:53 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: References: <1171378876.3622.146.camel@mccallum.corsepiu.local> <200702140046.07550@rineau.tsetse> <1171438888.3622.216.camel@mccallum.corsepiu.local> Message-ID: <1171442994.3622.235.camel@mccallum.corsepiu.local> On Wed, 2007-02-14 at 09:06 +0100, Gianluca Sforna wrote: > De facto, everything is in "keep-alive" maintenance by > > Linux distros keeping their packages going and them occasionally > > mutually harvesting/exchanging their patches and modifications. > > I.e. the de facto upstream are Debian and Fedora (i.e. me). Before somebody feels insulted: Ubuntu also has Inventor, but their modifications are largely identical to Debian. > And I thank you both for that... > I was actaully pretty impressed by the 219Kb (bzipped) applied > "monster patch" :) The patch looks bigger than it actually is (Uncompressed size: 1.6MB), because it contains _one_ 1.5MB ascii data file ;) Ralf From bugzilla at redhat.com Wed Feb 14 10:26:51 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Feb 2007 05:26:51 -0500 Subject: [Bug 176452] Review Request: oddjob - a D-BUS service which runs odd jobs on behalf of client applications In-Reply-To: Message-ID: <200702141026.l1EAQpha021710@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: oddjob - a D-BUS service which runs odd jobs on behalf of client applications https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176452 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com ------- Additional Comments From bugs.michael at gmx.net 2007-02-14 05:26 EST ------- The circular dependency between the main package and the -libs package is odd. The main package has an implicit dependency on the library SONAME in the -libs package. The -libs package has an explicit dependency on the main package. The initial import (tagged oddjob-0_23-1) has an indirect dependency from the -devel package to the main package and from there to the -libs package via the automatic SONAME dep. Instead, it should have been just -devel requires -libs, not -devel requires main package and not -libs requires main package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From dominik at greysector.net Wed Feb 14 11:36:50 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 14 Feb 2007 12:36:50 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: <1171442994.3622.235.camel@mccallum.corsepiu.local> References: <1171378876.3622.146.camel@mccallum.corsepiu.local> <200702140046.07550@rineau.tsetse> <1171438888.3622.216.camel@mccallum.corsepiu.local> <1171442994.3622.235.camel@mccallum.corsepiu.local> Message-ID: <20070214113650.GB3176@ryvius.pekin.waw.pl> On Wednesday, 14 February 2007 at 09:49, Ralf Corsepius wrote: > On Wed, 2007-02-14 at 09:06 +0100, Gianluca Sforna wrote: > > > De facto, everything is in "keep-alive" maintenance by > > > Linux distros keeping their packages going and them occasionally > > > mutually harvesting/exchanging their patches and modifications. > > > I.e. the de facto upstream are Debian and Fedora (i.e. me). > Before somebody feels insulted: Ubuntu also has Inventor, but their > modifications are largely identical to Debian. > > > And I thank you both for that... > > I was actaully pretty impressed by the 219Kb (bzipped) applied > > "monster patch" :) > The patch looks bigger than it actually is (Uncompressed size: 1.6MB), > because it contains _one_ 1.5MB ascii data file ;) Have you thought of splitting that off from the patch and including as SourceN: ? 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 buildsys at fedoraproject.org Wed Feb 14 12:16:28 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 14 Feb 2007 07:16:28 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-14 Message-ID: <20070214121628.2D06E15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 63 Canna-3.7p3-17.fc7 Inventor-2.1.5-25.fc7 NetworkManager-vpnc-0.6.4-1.fc7 ScientificPython-2.6-7.fc7 TeXmacs-1.0.6.9-1.fc7 NEW ack-1.56-4.fc7 apcupsd-3.14.0-0.fc7 aplus-fsf-4.20.2-13.fc7 basket-1.0-1.fc7 catfish-0.2stable-1.fc7 chemical-mime-data-0.1.94-2.fc7 codeblocks-1.0-0.23.20070211svn3592.fc7 deltarpm-3.3-7.fc7 dnsmasq-2.38-1.fc7 NEW eb-4.3-2.fc7 NEW etherape-0.9.7-4.fc7 freeciv-2.0.9-1.fc7 NEW fuse-convmvfs-0.2.3-2.fc7 NEW gemdropx-0.9-2.fc7 NEW gimmie-0.2.3-2.fc7 gnome-libs-1.4.2-4.fc7 NEW gpixpod-0.6.2-1.fc7 gpsim-0.22.0-3.fc7 gstreamer-python-0.10.7-1.fc7 gtranslator-1.1.7-2.fc7 NEW hunspell-af-0.20060117-1.fc7 NEW hunspell-bg-0.20040405-1.fc7 NEW hunspell-ca-0.20021015-1.fc7 NEW hunspell-cy-0.20040425-1.fc7 NEW hunspell-da-0.20070106-1.fc7 NEW hunspell-de-0.20051213-1.fc7 NEW hunspell-ee-0.20030602-1.fc7 NEW hunspell-el-0.20041220-1.fc7 NEW hunspell-es-0.20050510-1.fc7 NEW hunspell-ga-0.20060731-1.fc7 NEW hunspell-gl-0.20061002-1.fc7 initng-ifiles-0.0.8-1.fc7 jd-1.8.5-2.cvs070213.fc7 kdemultimedia-extras-3.5.6-3.fc7 kinput2-v3.1-31.fc7 NEW libmp4v2-1.5.0.1-3.fc7 libsyncml-0.4.3-1.fc7 NEW methane-1.4.7-1.fc7 ncarg-4.4.1-9.fc7 openbox-3.3.1-5.fc7 optipng-0.5.5-2.fc7 NEW perl-App-CLI-0.07-2.fc7 NEW perl-File-Next-0.38-2.fc7 NEW perl-Module-Depends-0.10-2.fc7 NEW perl-Path-Class-0.16-1.fc7 NEW perl-Proc-Daemon-0.03-1.fc7.1 perl-RRD-Simple-1.41-1.fc7 php-pear-Log-1.9.10-1.fc7 php-pear-PHP-CompatInfo-1.4.1-1.fc7 poker-engine-1.0.23-2.fc7 NEW postgrey-1.27-4.fc7 seedit-2.1.0-3.fc7 smolt-0.8-1.fc7 NEW spampd-2.30-3.fc7 supertux-0.3.0-1.fc7 NEW tilda-0.9.4-6.fc7 tracker-0.5.4-5.fc7 xtide-2.9-0.3.RC2.fc7 Packages built and released for Fedora Extras 6: 43 Canna-3.7p3-17.fc6 NetworkManager-vpnc-0.6.4-1.fc6 ScientificPython-2.6-7.fc6 TeXmacs-1.0.6.9-1.fc6 akode-2.0.1-5.fc6 aplus-fsf-4.20.2-13.fc6 basket-1.0-1.fc6 NEW bcfg2-0.9.1-1.d.fc6 catfish-0.2stable-1.fc6 codeblocks-1.0-0.23.20070211svn3592.fc6 dnsmasq-2.38-1.fc6 NEW eb-4.3-1.fc6 em8300-kmod-0.16.0-5.2.6.19_1.2911.fc6 NEW etherape-0.9.7-4.fc6 NEW fuse-convmvfs-0.2.3-2.fc6 NEW gemdropx-0.9-2.fc6 NEW gimmie-0.2.3-2.fc6 NEW gpixpod-0.6.2-1.fc6 gpsim-0.22.0-2.fc6 gstreamer-python-0.10.7-1.fc6 initng-0.6.9-3.fc6 initng-ifiles-0.0.8-1.fc6 kinput2-v3.1-31.fc6 NEW libmp4v2-1.5.0.1-3.fc6 mail-notification-4.0-1.fc6 NEW methane-1.4.7-1.fc6 ncarg-4.4.1-9.fc6 openbox-3.3.1-4.fc6 NEW perl-App-CLI-0.07-2.fc6 NEW perl-File-Next-0.38-2.fc6 NEW perl-Module-Depends-0.10-2.fc6 NEW perl-Path-Class-0.16-1.fc6 NEW perl-Proc-Daemon-0.03-1.fc6 perl-RRD-Simple-1.41-1.fc6 php-pear-Log-1.9.10-1.fc6 php-pear-PHP-CompatInfo-1.4.1-1.fc6 poker-engine-1.0.23-2.fc6 NEW postgrey-1.27-4.fc6 python-simpy-1.8-1.fc6 smolt-0.8-1.fc6 NEW spampd-2.30-3.fc6 tracker-0.5.4-4.fc6 xtide-2.9-0.3.RC2.fc6 Packages built and released for Fedora Extras 5: 25 aplus-fsf-4.20.2-13.fc5 catfish-0.2stable-1.fc5 codeblocks-1.0-0.23.20070211svn3592.fc5 dnsmasq-2.38-1.fc5 NEW fuse-convmvfs-0.2.3-2.fc5 gpredict-0.7.1-1.fc5 gpsim-0.22.0-2.fc5 initng-0.6.9-3.fc5 initng-ifiles-0.0.8-1.fc5 NEW libmp4v2-1.5.0.1-3.fc5 openbox-3.3.1-3.fc5 NEW perl-App-CLI-0.07-2.fc5 NEW perl-File-Next-0.38-2.fc5 NEW perl-Module-Depends-0.10-2.fc5 NEW perl-Path-Class-0.16-1.fc5 NEW perl-Proc-Daemon-0.03-1.fc5.1 perl-RRD-Simple-1.41-1.fc5 php-pear-Log-1.9.10-1.fc5 php-pear-PHP-CompatInfo-1.4.1-1.fc5 poker-engine-1.0.23-2.fc5 NEW postgrey-1.27-4.fc5 python-simpy-1.8-1.fc5 NEW smolt-0.8-1.fc5 NEW spampd-2.30-3.fc5 xtide-2.9-0.3.RC2.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rc040203 at freenet.de Wed Feb 14 12:46:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Feb 2007 13:46:57 +0100 Subject: libInventor.so.0.0.0: bug or feature? In-Reply-To: <20070214113650.GB3176@ryvius.pekin.waw.pl> References: <1171378876.3622.146.camel@mccallum.corsepiu.local> <200702140046.07550@rineau.tsetse> <1171438888.3622.216.camel@mccallum.corsepiu.local> <1171442994.3622.235.camel@mccallum.corsepiu.local> <20070214113650.GB3176@ryvius.pekin.waw.pl> Message-ID: <1171457217.3622.259.camel@mccallum.corsepiu.local> On Wed, 2007-02-14 at 12:36 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 14 February 2007 at 09:49, Ralf Corsepius wrote: > > On Wed, 2007-02-14 at 09:06 +0100, Gianluca Sforna wrote: > > > > > De facto, everything is in "keep-alive" maintenance by > > > > Linux distros keeping their packages going and them occasionally > > > > mutually harvesting/exchanging their patches and modifications. > > > > I.e. the de facto upstream are Debian and Fedora (i.e. me). > > Before somebody feels insulted: Ubuntu also has Inventor, but their > > modifications are largely identical to Debian. > > > > > And I thank you both for that... > > > I was actaully pretty impressed by the 219Kb (bzipped) applied > > > "monster patch" :) > > The patch looks bigger than it actually is (Uncompressed size: 1.6MB), > > because it contains _one_ 1.5MB ascii data file ;) > > Have you thought of splitting that off from the patch and including as > SourceN: ? Yes, but a diff is simpler for me, because I cut the diffs from a local cvs and have all mods in my local (non-public) cvs. I should consider starting a public project based on this code base :-) Ralf From buildsys at fedoraproject.org Wed Feb 14 13:09:52 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 14 Feb 2007 13:09:52 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 Message-ID: <20070214130952.7545.22068@extras64.linux.duke.edu> New report for: jima AT beer.tclug.org package: graphviz-tcl - 2.12-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so package: graphviz-tcl - 2.12-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so package: graphviz-tcl - 2.12-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) ====================================================================== New report for: paul AT xelerance.com package: hping3 - 0.0.20051105-6.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.5.so package: hping3 - 0.0.20051105-6.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.5.so package: hping3 - 0.0.20051105-6.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so()(64bit) ====================================================================== New report for: orion AT cora.nwra.com package: environment-modules - 3.2.4-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.5.so package: environment-modules - 3.2.4-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.5.so package: environment-modules - 3.2.4-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so()(64bit) package: python-matplotlib-tk - 0.90.0-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: python-matplotlib-tk - 0.90.0-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: python-matplotlib-tk - 0.90.0-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) libtcl8.5.so()(64bit) ====================================================================== New report for: nphilipp AT redhat.com package: ppracer - 0.3.1-9.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.5.so package: ppracer - 0.3.1-9.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.5.so package: ppracer - 0.3.1-9.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so()(64bit) ====================================================================== New report for: garrick AT usc.edu package: torque-client - 2.1.6-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: torque-client - 2.1.6-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: torque-client - 2.1.6-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) libtcl8.5.so()(64bit) package: torque-gui - 2.1.6-4.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so /usr/bin/wish8.5 libtcl8.5.so package: torque-gui - 2.1.6-4.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so /usr/bin/wish8.5 libtcl8.5.so package: torque-gui - 2.1.6-4.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: /usr/bin/wish8.5 libtk8.5.so()(64bit) libtcl8.5.so()(64bit) ====================================================================== New report for: Jochen AT herr-schmitt.de package: gnu-smalltalk - 2.3.2-5.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so libtk8.5.so package: gnu-smalltalk - 2.3.2-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.5.so libtk8.5.so package: gnu-smalltalk - 2.3.2-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.5.so libtk8.5.so package: gnu-smalltalk - 2.3.2-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) libtcl8.5.so()(64bit) ====================================================================== New report for: redhat-bugzilla AT linuxnetz.de package: eggdrop - 1.6.18-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.5.so package: eggdrop - 1.6.18-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.5.so package: eggdrop - 1.6.18-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so()(64bit) ====================================================================== New report for: cgoorah AT yahoo.com.au package: irsim - 9.7.41-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: irsim - 9.7.41-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: xcircuit - 3.4.26-18.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: xcircuit - 3.4.26-18.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: xcircuit - 3.4.26-18.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) libtcl8.5.so()(64bit) ====================================================================== New report for: tcallawa AT redhat.com package: R - 2.4.1-2.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so libtcl8.5.so package: R - 2.4.1-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: R - 2.4.1-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: R - 2.4.1-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so()(64bit) libtk8.5.so()(64bit) ====================================================================== New report for: green AT redhat.com package: vkeybd - 0.1.17a-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.5.so tk < 0:8.6 libtk8.5.so package: vkeybd - 0.1.17a-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so tk < 0:8.6 package: vkeybd - 0.1.17a-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) libtcl8.5.so()(64bit) tk < 0:8.6 ====================================================================== New report for: spr AT astrax.fis.ucm.es package: xpa - 2.1.6-8.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so package: xpa - 2.1.6-8.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtcl8.5.so package: xpa - 2.1.6-8.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtcl8.5.so package: xpa - 2.1.6-8.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so()(64bit) ====================================================================== New report for: jamatos AT fc.up.pt package: python-imaging - 1.1.6-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so libtcl8.5.so package: python-imaging - 1.1.6-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: python-imaging - 1.1.6-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: python-imaging - 1.1.6-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtcl8.5.so()(64bit) libtk8.5.so()(64bit) ====================================================================== New report for: gemi AT bluewin.ch package: skencil - 0.6.17-12.fc7.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: skencil - 0.6.17-12.fc7.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: skencil - 0.6.17-12.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) libtcl8.5.so()(64bit) ====================================================================== New report for: adrian AT lisas.de package: uudeview - 0.5.20-10.i386 from fedora-extras-development-i386 unresolved deps: libtk8.5.so libtcl8.5.so package: uudeview - 0.5.20-10.ppc from fedora-extras-development-ppc unresolved deps: libtk8.5.so libtcl8.5.so package: uudeview - 0.5.20-10.x86_64 from fedora-extras-development-x86_64 unresolved deps: libtk8.5.so()(64bit) libtcl8.5.so()(64bit) ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de gnu-smalltalk - 2.3.2-5.fc7.i386 gnu-smalltalk - 2.3.2-5.fc7.i386 gnu-smalltalk - 2.3.2-5.fc7.ppc gnu-smalltalk - 2.3.2-5.fc7.x86_64 adrian AT lisas.de uudeview - 0.5.20-10.i386 uudeview - 0.5.20-10.ppc uudeview - 0.5.20-10.x86_64 andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (5 days) libetpan - 0.49-1.fc7.i386 (5 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (5 days) cgoorah AT yahoo.com.au irsim - 9.7.41-5.fc7.i386 irsim - 9.7.41-5.fc7.ppc toped - 0.8.2-2.fc6.i386 (61 days) toped - 0.8.2-2.fc6.ppc (61 days) toped - 0.8.2-2.fc6.x86_64 (61 days) xcircuit - 3.4.26-18.fc7.i386 xcircuit - 3.4.26-18.fc7.ppc xcircuit - 3.4.26-18.fc7.x86_64 dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (68 days) csound - 5.03.0-9.fc7.i386 (68 days) csound - 5.03.0-9.fc7.ppc (68 days) csound - 5.03.0-9.fc7.x86_64 (68 days) csound-python - 5.03.0-9.fc7.i386 (68 days) csound-python - 5.03.0-9.fc7.ppc (68 days) csound-python - 5.03.0-9.fc7.x86_64 (68 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (70 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (70 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (70 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (70 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (70 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (70 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (70 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (68 days) garrick AT usc.edu torque-client - 2.1.6-4.fc7.i386 torque-client - 2.1.6-4.fc7.ppc torque-client - 2.1.6-4.fc7.x86_64 torque-gui - 2.1.6-4.fc7.i386 torque-gui - 2.1.6-4.fc7.ppc torque-gui - 2.1.6-4.fc7.x86_64 gemi AT bluewin.ch skencil - 0.6.17-12.fc7.i386 skencil - 0.6.17-12.fc7.ppc skencil - 0.6.17-12.fc7.x86_64 giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.20_1.2922.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.20_1.2922.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.20_1.2922.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.20_1.2922.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.20_1.2922.fc7.x86_64 green AT redhat.com vkeybd - 0.1.17a-2.fc7.i386 vkeybd - 0.1.17a-2.fc7.ppc vkeybd - 0.1.17a-2.fc7.x86_64 ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (65 days) libreadline-java - 0.8.0-13.fc6.i386 (65 days) libreadline-java - 0.8.0-13.fc6.ppc (65 days) libreadline-java - 0.8.0-13.fc6.x86_64 (65 days) jamatos AT fc.up.pt python-imaging - 1.1.6-1.fc7.i386 python-imaging - 1.1.6-1.fc7.i386 python-imaging - 1.1.6-1.fc7.ppc python-imaging - 1.1.6-1.fc7.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (128 days) linphone - 1.2.0-4.fc5.ppc (128 days) linphone - 1.2.0-4.fc5.x86_64 (128 days) jima AT beer.tclug.org graphviz-tcl - 2.12-5.fc7.i386 graphviz-tcl - 2.12-5.fc7.ppc graphviz-tcl - 2.12-5.fc7.x86_64 lmacken AT redhat.com python-cherrypy - 2.2.1-3.fc6.noarch (68 days) python-cherrypy - 2.2.1-3.fc6.noarch (68 days) python-cherrypy - 2.2.1-3.fc6.noarch (68 days) nphilipp AT redhat.com ppracer - 0.3.1-9.fc7.i386 ppracer - 0.3.1-9.fc7.ppc ppracer - 0.3.1-9.fc7.x86_64 orion AT cora.nwra.com environment-modules - 3.2.4-1.fc7.i386 environment-modules - 3.2.4-1.fc7.ppc environment-modules - 3.2.4-1.fc7.x86_64 paraview - 2.4.4-3.fc6.x86_64 (68 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (68 days) python-matplotlib-tk - 0.90.0-2.fc7.i386 python-matplotlib-tk - 0.90.0-2.fc7.ppc python-matplotlib-tk - 0.90.0-2.fc7.x86_64 paul AT xelerance.com hping3 - 0.0.20051105-6.fc7.i386 hping3 - 0.0.20051105-6.fc7.ppc hping3 - 0.0.20051105-6.fc7.x86_64 petersen AT redhat.com ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.i386 (23 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.ppc (23 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.x86_64 (23 days) rdieter AT math.unl.edu PyKDE - 3.16.0-5.fc7.i386 (68 days) PyKDE - 3.16.0-5.fc7.i386 (68 days) PyKDE - 3.16.0-5.fc7.ppc (68 days) PyKDE - 3.16.0-5.fc7.x86_64 (68 days) redhat-bugzilla AT linuxnetz.de eggdrop - 1.6.18-5.fc7.i386 eggdrop - 1.6.18-5.fc7.ppc eggdrop - 1.6.18-5.fc7.x86_64 shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (68 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 xpa - 2.1.6-8.fc7.i386 xpa - 2.1.6-8.fc7.ppc xpa - 2.1.6-8.fc7.x86_64 stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (68 days) xmldiff - 0.6.7-12.fc6.ppc (68 days) xmldiff - 0.6.7-12.fc6.x86_64 (68 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 R - 2.4.1-2.fc7.i386 R - 2.4.1-2.fc7.ppc R - 2.4.1-2.fc7.x86_64 ville.skytta AT iki.fi kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc ====================================================================== Broken packages in fedora-extras-5-i386: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.i386 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.ppc requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.x86_64 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 eggdrop-1.6.18-5.fc7.i386 requires libtcl8.5.so environment-modules-3.2.4-1.fc7.i386 requires libtcl8.5.so gnu-smalltalk-2.3.2-5.fc7.i386 requires libtcl8.5.so gnu-smalltalk-2.3.2-5.fc7.i386 requires libtk8.5.so graphviz-tcl-2.12-5.fc7.i386 requires libtk8.5.so hping3-0.0.20051105-6.fc7.i386 requires libtcl8.5.so irsim-9.7.41-5.fc7.i386 requires libtk8.5.so irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE kmod-sysprof-1.0.8-1.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-sysprof-1.0.8-1.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 ppracer-0.3.1-9.fc7.i386 requires libtcl8.5.so python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.6-1.fc7.i386 requires libtk8.5.so python-imaging-1.1.6-1.fc7.i386 requires libtcl8.5.so python-matplotlib-tk-0.90.0-2.fc7.i386 requires libtk8.5.so python-matplotlib-tk-0.90.0-2.fc7.i386 requires libtcl8.5.so python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 skencil-0.6.17-12.fc7.i386 requires libtk8.5.so skencil-0.6.17-12.fc7.i386 requires libtcl8.5.so toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 torque-client-2.1.6-4.fc7.i386 requires libtk8.5.so torque-client-2.1.6-4.fc7.i386 requires libtcl8.5.so torque-gui-2.1.6-4.fc7.i386 requires libtk8.5.so torque-gui-2.1.6-4.fc7.i386 requires /usr/bin/wish8.5 torque-gui-2.1.6-4.fc7.i386 requires libtcl8.5.so uudeview-0.5.20-10.i386 requires libtk8.5.so uudeview-0.5.20-10.i386 requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.i386 requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.i386 requires tk < 0:8.6 vkeybd-0.1.17a-2.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-ppc: PyKDE-3.16.0-5.fc7.ppc requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.ppc requires python-abi = 0:2.4 R-2.4.1-2.fc7.ppc requires libtk8.5.so R-2.4.1-2.fc7.ppc requires libtcl8.5.so csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 eggdrop-1.6.18-5.fc7.ppc requires libtcl8.5.so environment-modules-3.2.4-1.fc7.ppc requires libtcl8.5.so gnu-smalltalk-2.3.2-5.fc7.ppc requires libtcl8.5.so gnu-smalltalk-2.3.2-5.fc7.ppc requires libtk8.5.so graphviz-tcl-2.12-5.fc7.ppc requires libtk8.5.so hping3-0.0.20051105-6.fc7.ppc requires libtcl8.5.so irsim-9.7.41-5.fc7.ppc requires libtk8.5.so irsim-9.7.41-5.fc7.ppc requires libtcl8.5.so kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 ppracer-0.3.1-9.fc7.ppc requires libtcl8.5.so python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.6-1.fc7.ppc requires libtk8.5.so python-imaging-1.1.6-1.fc7.ppc requires libtcl8.5.so python-matplotlib-tk-0.90.0-2.fc7.ppc requires libtk8.5.so python-matplotlib-tk-0.90.0-2.fc7.ppc requires libtcl8.5.so skencil-0.6.17-12.fc7.ppc requires libtk8.5.so skencil-0.6.17-12.fc7.ppc requires libtcl8.5.so toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 torque-client-2.1.6-4.fc7.ppc requires libtk8.5.so torque-client-2.1.6-4.fc7.ppc requires libtcl8.5.so torque-gui-2.1.6-4.fc7.ppc requires libtk8.5.so torque-gui-2.1.6-4.fc7.ppc requires /usr/bin/wish8.5 torque-gui-2.1.6-4.fc7.ppc requires libtcl8.5.so uudeview-0.5.20-10.ppc requires libtk8.5.so uudeview-0.5.20-10.ppc requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.ppc requires libtk8.5.so vkeybd-0.1.17a-2.fc7.ppc requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.ppc requires tk < 0:8.6 xcircuit-3.4.26-18.fc7.ppc requires libtk8.5.so xcircuit-3.4.26-18.fc7.ppc requires libtcl8.5.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.ppc requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-x86_64: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python-abi = 0:2.4 R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so R-2.4.1-2.fc7.x86_64 requires libtcl8.5.so()(64bit) R-2.4.1-2.fc7.x86_64 requires libtk8.5.so()(64bit) claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) eggdrop-1.6.18-5.fc7.x86_64 requires libtcl8.5.so()(64bit) environment-modules-3.2.4-1.fc7.x86_64 requires libtcl8.5.so()(64bit) gnu-smalltalk-2.3.2-5.fc7.i386 requires libtcl8.5.so gnu-smalltalk-2.3.2-5.fc7.i386 requires libtk8.5.so gnu-smalltalk-2.3.2-5.fc7.x86_64 requires libtk8.5.so()(64bit) gnu-smalltalk-2.3.2-5.fc7.x86_64 requires libtcl8.5.so()(64bit) graphviz-tcl-2.12-5.fc7.x86_64 requires libtk8.5.so()(64bit) hping3-0.0.20051105-6.fc7.x86_64 requires libtcl8.5.so()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump kmod-sysprof-1.0.8-1.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) ppracer-0.3.1-9.fc7.x86_64 requires libtcl8.5.so()(64bit) python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-imaging-1.1.6-1.fc7.i386 requires libtk8.5.so python-imaging-1.1.6-1.fc7.i386 requires libtcl8.5.so python-imaging-1.1.6-1.fc7.x86_64 requires libtcl8.5.so()(64bit) python-imaging-1.1.6-1.fc7.x86_64 requires libtk8.5.so()(64bit) python-matplotlib-tk-0.90.0-2.fc7.x86_64 requires libtk8.5.so()(64bit) python-matplotlib-tk-0.90.0-2.fc7.x86_64 requires libtcl8.5.so()(64bit) skencil-0.6.17-12.fc7.x86_64 requires libtk8.5.so()(64bit) skencil-0.6.17-12.fc7.x86_64 requires libtcl8.5.so()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) torque-client-2.1.6-4.fc7.x86_64 requires libtk8.5.so()(64bit) torque-client-2.1.6-4.fc7.x86_64 requires libtcl8.5.so()(64bit) torque-gui-2.1.6-4.fc7.x86_64 requires /usr/bin/wish8.5 torque-gui-2.1.6-4.fc7.x86_64 requires libtk8.5.so()(64bit) torque-gui-2.1.6-4.fc7.x86_64 requires libtcl8.5.so()(64bit) uudeview-0.5.20-10.x86_64 requires libtk8.5.so()(64bit) uudeview-0.5.20-10.x86_64 requires libtcl8.5.so()(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires libtk8.5.so()(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires libtcl8.5.so()(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires tk < 0:8.6 xcircuit-3.4.26-18.fc7.x86_64 requires libtk8.5.so()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtcl8.5.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so xpa-2.1.6-8.fc7.x86_64 requires libtcl8.5.so()(64bit) From j.w.r.degoede at hhs.nl Wed Feb 14 16:08:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 14 Feb 2007 17:08:25 +0100 Subject: Headsup: new ode 0.8 coming to devel Message-ID: <45D333F9.5060003@hhs.nl> Hi all, I'm about to commit and build ode-0.8 for devel. This is API and ABI compatible with 0.7, yet I'm still issuing a warning as it contains a couple of checks (asserts) for wrong use which may break applications. I had to fix sturmbahnfahrer for one. Hence this is only going into devel for now. Regards, Hans From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 14 16:56:35 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 14 Feb 2007 17:56:35 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171068977.28153.9.camel@Chuck> References: <1171068977.28153.9.camel@Chuck> Message-ID: <20070214175635.0c70075c@python3.es.egwn.lan> Brian Pepple wrote : > Packaging Committee Report > * FESCo didn't have any objections to the Packaging Committee's > guidelines regarding: [...] > 4. Making the suggested buildroot mandatory [...] What's the rationale behind this? I fail to see the purpose, since this is something that needs to be addressed better than it is currently, and ideally from inside rpm itself (and apparently it's being done, thanks Bill). It's even being subject to current discussions, like using mktemp for it... As far as I'm concerned, any directory inside %_tmppath with a name which is package _and_ version specific is fine. And before adding "user specific too", I'd definitely add "arch specific" as I find it more important, so this is a never ending and useless debate... I'm asking because the usual "you should use this buildroot" I usually get from people reviewing my packages has become "you must", which does annoy me because I fail to see the point for such a change : https://bugzilla.redhat.com/228294 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.62 0.64 0.66 From tibbs at math.uh.edu Wed Feb 14 17:06:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Feb 2007 11:06:07 -0600 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070214175635.0c70075c@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <20070214175635.0c70075c@python3.es.egwn.lan> Message-ID: >>>>> "MS" == Matthias Saou writes: MS> What's the rationale behind this? Picking a single value that meets the technical requirements so that package reviewers can be spared unending confusion over whether a particular buildroot is sufficient and unending argument between packagers and reviewers which wastes everyone's time. It takes all of two seconds to fix it. - J< From jkeating at redhat.com Wed Feb 14 17:30:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Feb 2007 12:30:16 -0500 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070214175635.0c70075c@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <20070214175635.0c70075c@python3.es.egwn.lan> Message-ID: <200702141230.16529.jkeating@redhat.com> On Wednesday 14 February 2007 11:56, Matthias Saou wrote: > What's the rationale behind this? I fail to see the purpose, since this > is something that needs to be addressed better than it is currently, > and ideally from inside rpm itself (and apparently it's being done, > thanks Bill). It's even being subject to current discussions, like > using mktemp for it... > > As far as I'm concerned, any directory inside %_tmppath with a name > which is package _and_ version specific is fine. And before adding "user > specific too", I'd definitely add "arch specific" as I find it more > important, so this is a never ending and useless debate... > > I'm asking because the usual "you should use this buildroot" I usually > get from people reviewing my packages has become "you must", which does > annoy me because I fail to see the point for such a change : > https://bugzilla.redhat.com/228294 Because without using a mktemp style buildroot, there are technical risks of overlapping directories from either multiple users or multiple arches building on the same system. Since all arguments around what BuildRoot should be are centered around this, we need to pick _one_ that is safe, and is the same as what the patches sent to rpm would use, once / if they get integrated. As stated, it is a simple one line change. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 14 17:30:33 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 14 Feb 2007 18:30:33 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: References: <1171068977.28153.9.camel@Chuck> <20070214175635.0c70075c@python3.es.egwn.lan> Message-ID: <20070214183033.60a2c443@python3.es.egwn.lan> Jason L Tibbitts III wrote : > >>>>> "MS" == Matthias Saou writes: > > MS> What's the rationale behind this? > > Picking a single value that meets the technical requirements so that > package reviewers can be spared unending confusion over whether a > particular buildroot is sufficient and unending argument between > packagers and reviewers which wastes everyone's time. > > It takes all of two seconds to fix it. Changing it doesn't "fix" anything. If we have to pick something for the short term, then I'd suggest this : * Mandatory : The BuildRoot must start with %{_tmppath}/%{name}-%{version}-%{release}. The preferred value is %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n). And that's it for now. Let the real fix come in later. Right now we have a _mandatory_ value which has been approved last week, but already a new possible value to be ratified : http://fedoraproject.org/wiki/Packaging/GuidelinesTodo It makes really little sense to me to have changed this now. Can I politely ask the packaging committee to reconsider this point? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.21 1.02 0.76 From rc040203 at freenet.de Wed Feb 14 17:36:55 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Feb 2007 18:36:55 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070214183033.60a2c443@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <20070214175635.0c70075c@python3.es.egwn.lan> <20070214183033.60a2c443@python3.es.egwn.lan> Message-ID: <1171474615.3622.309.camel@mccallum.corsepiu.local> On Wed, 2007-02-14 at 18:30 +0100, Matthias Saou wrote: > Jason L Tibbitts III wrote : > > > >>>>> "MS" == Matthias Saou writes: > > > > MS> What's the rationale behind this? > > > > Picking a single value that meets the technical requirements so that > > package reviewers can be spared unending confusion over whether a > > particular buildroot is sufficient and unending argument between > > packagers and reviewers which wastes everyone's time. > > > > It takes all of two seconds to fix it. > > Changing it doesn't "fix" anything. If we have to pick something for the > short term, then I'd suggest this : We have picked one for short term, namely that which had been used for most packages in FE. > * Mandatory : The BuildRoot must start with > %{_tmppath}/%{name}-%{version}-%{release}. The preferred value is > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n). ^^^^^^^ This ^^^^^^ > And that's it for now. Let the real fix come in later. Right, yesterday we (FPC) tried to come up with a better proposal, but this "ad-hoq" approach meanwhile went up in smoke, because it has shown to be broken. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Feb 14 17:55:27 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 14 Feb 2007 18:55:27 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <200702141230.16529.jkeating@redhat.com> References: <1171068977.28153.9.camel@Chuck> <20070214175635.0c70075c@python3.es.egwn.lan> <200702141230.16529.jkeating@redhat.com> Message-ID: <20070214185527.75e510cb@python3.es.egwn.lan> Jesse Keating wrote : > On Wednesday 14 February 2007 11:56, Matthias Saou wrote: > > What's the rationale behind this? I fail to see the purpose, since this > > is something that needs to be addressed better than it is currently, > > and ideally from inside rpm itself (and apparently it's being done, > > thanks Bill). It's even being subject to current discussions, like > > using mktemp for it... > > > > As far as I'm concerned, any directory inside %_tmppath with a name > > which is package _and_ version specific is fine. And before adding "user > > specific too", I'd definitely add "arch specific" as I find it more > > important, so this is a never ending and useless debate... > > > > I'm asking because the usual "you should use this buildroot" I usually > > get from people reviewing my packages has become "you must", which does > > annoy me because I fail to see the point for such a change : > > https://bugzilla.redhat.com/228294 > > Because without using a mktemp style buildroot, there are technical risks of > overlapping directories from either multiple users or multiple arches > building on the same system. Since all arguments around what BuildRoot > should be are centered around this, we need to pick _one_ that is safe, and > is the same as what the patches sent to rpm would use, once / if they get > integrated. As stated, it is a simple one line change. Why pick _one_ when it's trivial to evaluate the level of safety a given buildroot has for the Fedora build system? That extra "id" execution is totally useless with mock, and I simply dislike adding useless stuff. Any useless stuff, anywhere. %{_tmppath}/%{name}-%{version}-%{release}-root Is shorter than what is now _mandatory_, just as safe/unsafe with mock, which is what we encourage all users to use for builds anyway. And it saves that useless "id" execution. Which again is why I'd like to propose this for the short term, until we can rip out all BuildRoot: lines for good : > * Mandatory : The BuildRoot must start with > %{_tmppath}/%{name}-%{version}-%{release}. The preferred value is > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n). I like sane "guide" lines, not arbitrary "fixed" lines that make little to no sense. If a mktemp based buildroot which actually fixes real issues is found, I'll have absolutely no problem switching to that! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.25 1.29 1.17 From jkeating at redhat.com Wed Feb 14 19:08:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Feb 2007 14:08:41 -0500 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070214185527.75e510cb@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> Message-ID: <200702141408.44834.jkeating@redhat.com> On Wednesday 14 February 2007 12:55, Matthias Saou wrote: > Why pick _one_ when it's trivial to evaluate the level of safety a given > buildroot has for the Fedora build system? That extra "id" execution is > totally useless with mock, and I simply dislike adding useless stuff. > Any useless stuff, anywhere. > > %{_tmppath}/%{name}-%{version}-%{release}-root > > Is shorter than what is now _mandatory_, just as safe/unsafe with mock, > which is what we encourage all users to use for builds anyway. And it > saves that useless "id" execution. Given that mock is a clean root each time, just %{_tmppath}/%{name} is enough. However this rule isn't for use in mock, this rule was brought up and contested for uses outside of mock, particularly by Ralf Corsepius. > Which again is why I'd like to propose this for the short term, until > > we can rip out all BuildRoot: lines for good : > > * Mandatory : The BuildRoot must start with > > %{_tmppath}/%{name}-%{version}-%{release}. The preferred value is > > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n). > > I like sane "guide" lines, not arbitrary "fixed" lines that make little > to no sense. These are not enough to fix Ralf's issues. > If a mktemp based buildroot which actually fixes real issues is found, > I'll have absolutely no problem switching to that! Ralf should be able to point out these problems which a mktemp based solution would fix. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Wed Feb 14 19:26:09 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 14 Feb 2007 13:26:09 -0600 Subject: License tag for Fedora Directory Server Message-ID: <1171481169.3851.2.camel@lt21223.campus.dmacc.edu> I'm in the middle of reviewing the Fedora Directory Server package and a question has come up regarding the License tag. The package has "GPL with exceptions" as the license tag, which rpmlint flags as invaild. Is "GPL with exceptions" acceptable as a license tag? The review request is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228555 Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Wed Feb 14 19:32:36 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 14 Feb 2007 13:32:36 -0600 Subject: License tag for Fedora Directory Server In-Reply-To: <1171481169.3851.2.camel@lt21223.campus.dmacc.edu> References: <1171481169.3851.2.camel@lt21223.campus.dmacc.edu> Message-ID: <200702141332.36526.dennis@ausil.us> On Wednesday 14 February 2007 13:26, Jeffrey C. Ollie wrote: > I'm in the middle of reviewing the Fedora Directory Server package and a > question has come up regarding the License tag. The package has "GPL > with exceptions" as the license tag, which rpmlint flags as invaild. Is > "GPL with exceptions" acceptable as a license tag? > > The review request is here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228555 When i spoke to spot about it at fudcon he said it was fine -- Dennis Gilmore, RHCE From rcritten at redhat.com Wed Feb 14 20:28:11 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Feb 2007 15:28:11 -0500 Subject: signing a JAR file In-Reply-To: <200702140912.22971.ville.skytta@iki.fi> References: <45D23B3B.9020007@redhat.com> <200702140912.22971.ville.skytta@iki.fi> Message-ID: <45D370DB.4060309@redhat.com> Ville Skytt? wrote: > On Wednesday 14 February 2007, Rob Crittenden wrote: >> I'm looking into adding Java Security Services (JSS). This is a Java JNI >> interface to Network Security Services (NSS) for crypto. >> >> According to >> http://www.mozilla.org/projects/security/pki/jss/provider_notes.html it >> won't work unless the jar file is signed (using jarsigner). > > It won't work with Sun's (nor with BEA's, IBM's etc I think) Java unless > signed, but I guess GCJ doesn't care. But that's just guesswork, haven't > verified it. > Can I package up the mozilla.org jar pre-signed jar file? I think that would qualify it as a "binary distribution" though which is frowned upon. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From tdiehl at rogueind.com Wed Feb 14 21:03:12 2007 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 14 Feb 2007 16:03:12 -0500 (EST) Subject: rpmlint question In-Reply-To: <20070213171732.GB1373@nostromo.devel.redhat.com> References: <20070213171732.GB1373@nostromo.devel.redhat.com> Message-ID: On Tue, 13 Feb 2007, Bill Nottingham wrote: > Tom Diehl (tdiehl at rogueind.com) said: >> I am trying to learn how to make rpms. When I run rpmlint against the >> package >> I am trying to make I get the following output: >> >> (bullwinkle pts31) $ rpmlint dspam-3.6.8-1.fc5.mtd.1.i386.rpm >> W: dspam devel-file-in-non-devel-package /usr/lib/libdspam.so > > Generally, lib.so is used for development purposes. It's what > the linker looks at when you link against that library with > -l. So it's classified as a development file. > > The only other use of lib.so would be if it's a dynamically > loaded module or plugin, loaded with dlopen() or similar code. > (However, in that case, it's probably better to specify a particular > ABI version, so programs don't get a version that's different from > the API/ABI they compiled against.) > > If libdspam.so isn't a plugin used by other programs, just remove > libdspam.so from your file list. It turns out that libdspam.so is not needed but there are subpackages that contain drivers for mysql and postgresql. If I pull the .so symlinks, I get the following error: [bullwinkle pts33]# dspam --daemon --debug 1312: [02/14/2007 15:46:54] dlopen() failed: /usr/lib/libmysql_drv.so: /usr/lib/libmysql_drv.so: cannot open shared object file: No such file or directory 1312: [02/14/2007 15:46:54] Unable to initialize storage driver [bullwinkle pts33]# Having said the above, there is a config file in dspam, that calls /usr/lib/libmysql_drv.so. If I change the config to /usr/lib/libmysql_drv.so.7 or /usr/lib/libmysql_drv.so.7.0.0 then the program runs and the driver loads. What is the correct way to handle this type of thing? In addition, if the right answer is to drop the *.so libs, am I really supposed to drop them or do they belong in the -devel package? Is there a doc for this somewhere? So far, I have not been able to find one. Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From guthrie at counterexample.org Wed Feb 14 21:49:31 2007 From: guthrie at counterexample.org (John T. Guthrie) Date: Wed, 14 Feb 2007 16:49:31 -0500 Subject: rpmlint question In-Reply-To: <20070213171732.GB1373@nostromo.devel.redhat.com> References: <20070213171732.GB1373@nostromo.devel.redhat.com> Message-ID: <1171489771.18976.9.camel@euler.counterexample.org> On Tue, 2007-02-13 at 12:17 -0500, Bill Nottingham wrote: > Tom Diehl (tdiehl at rogueind.com) said: > > I am trying to learn how to make rpms. When I run rpmlint against the > > package > > I am trying to make I get the following output: > > > > (bullwinkle pts31) $ rpmlint dspam-3.6.8-1.fc5.mtd.1.i386.rpm > > W: dspam devel-file-in-non-devel-package /usr/lib/libdspam.so > > Generally, lib.so is used for development purposes. It's what > the linker looks at when you link against that library with > -l. So it's classified as a development file. > > The only other use of lib.so would be if it's a dynamically > loaded module or plugin, loaded with dlopen() or similar code. > (However, in that case, it's probably better to specify a particular > ABI version, so programs don't get a version that's different from > the API/ABI they compiled against.) > > If libdspam.so isn't a plugin used by other programs, just remove > libdspam.so from your file list. One alternative, if it is a development file, would be to put libdspam.so into a devel subpackage. This would remove libdspam.so from the main package list, but would give other people the option of being able to write applications against it if they so chose. Of course you would need to move the file listing of libdspam.so from the main package file list to the devel subpackage file list. If you are new to RPMs in general, I have found the Maximum RPM web page to be invaluable. You can find it here: http://www.rpm.org/max-rpm/ That page will provide info on how to create subpackages, among other things, if you aren't familiar with that. HTH > Bill -- John Guthrie guthrie at counterexample.org From garrick at usc.edu Wed Feb 14 22:10:09 2007 From: garrick at usc.edu (Garrick Staples) Date: Wed, 14 Feb 2007 14:10:09 -0800 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: <20070214130952.7545.22068@extras64.linux.duke.edu> References: <20070214130952.7545.22068@extras64.linux.duke.edu> Message-ID: <20070214221009.GD2378@polop.usc.edu> > ====================================================================== > Broken packages in fedora-extras-development-i386: > > R-2.4.1-2.fc7.i386 requires libtk8.5.so > R-2.4.1-2.fc7.i386 requires libtcl8.5.so > eggdrop-1.6.18-5.fc7.i386 requires libtcl8.5.so > environment-modules-3.2.4-1.fc7.i386 requires libtcl8.5.so > gnu-smalltalk-2.3.2-5.fc7.i386 requires libtcl8.5.so > gnu-smalltalk-2.3.2-5.fc7.i386 requires libtk8.5.so > graphviz-tcl-2.12-5.fc7.i386 requires libtk8.5.so > hping3-0.0.20051105-6.fc7.i386 requires libtcl8.5.so > irsim-9.7.41-5.fc7.i386 requires libtk8.5.so > irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so > ppracer-0.3.1-9.fc7.i386 requires libtcl8.5.so > python-imaging-1.1.6-1.fc7.i386 requires libtk8.5.so > python-imaging-1.1.6-1.fc7.i386 requires libtcl8.5.so > python-matplotlib-tk-0.90.0-2.fc7.i386 requires libtk8.5.so > python-matplotlib-tk-0.90.0-2.fc7.i386 requires libtcl8.5.so > skencil-0.6.17-12.fc7.i386 requires libtk8.5.so > skencil-0.6.17-12.fc7.i386 requires libtcl8.5.so > torque-client-2.1.6-4.fc7.i386 requires libtk8.5.so > torque-client-2.1.6-4.fc7.i386 requires libtcl8.5.so > torque-gui-2.1.6-4.fc7.i386 requires libtk8.5.so > torque-gui-2.1.6-4.fc7.i386 requires /usr/bin/wish8.5 > torque-gui-2.1.6-4.fc7.i386 requires libtcl8.5.so > uudeview-0.5.20-10.i386 requires libtk8.5.so > uudeview-0.5.20-10.i386 requires libtcl8.5.so > vkeybd-0.1.17a-2.fc7.i386 requires libtcl8.5.so > vkeybd-0.1.17a-2.fc7.i386 requires tk < 0:8.6 > vkeybd-0.1.17a-2.fc7.i386 requires libtk8.5.so > xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so > xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so > xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so What happened here? Presumably buildsys couldn't find the new TCL packages for some reason and produced a false report? -------------- 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 xelerance.com Wed Feb 14 22:24:46 2007 From: paul at xelerance.com (Paul Wouters) Date: Wed, 14 Feb 2007 23:24:46 +0100 (CET) Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: <20070214221009.GD2378@polop.usc.edu> References: <20070214130952.7545.22068@extras64.linux.duke.edu> <20070214221009.GD2378@polop.usc.edu> Message-ID: On Wed, 14 Feb 2007, Garrick Staples wrote: > > xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so > > What happened here? Presumably buildsys couldn't find the new TCL > packages for some reason and produced a false report? I wondered the same, as I had fixed my package to deal with this. A 'make build' builds it fine for me, so this script definitely creates false positives. Paul From dennis at ausil.us Wed Feb 14 22:28:14 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 14 Feb 2007 16:28:14 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: References: <20070214130952.7545.22068@extras64.linux.duke.edu> <20070214221009.GD2378@polop.usc.edu> Message-ID: <200702141628.14777.dennis@ausil.us> On Wednesday 14 February 2007 16:24, Paul Wouters wrote: > On Wed, 14 Feb 2007, Garrick Staples wrote: > > > xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so > > > > What happened here? Presumably buildsys couldn't find the new TCL > > packages for some reason and produced a false report? > > I wondered the same, as I had fixed my package to deal with this. > A 'make build' builds it fine for me, so this script definitely creates > false positives. umm no if you look at todays rawhide report the tcl maintainer dropped tcl back to 8.4 so all the tcl stuff needs rebuilt tcl-1:8.4.13-9.fc7 ------------------ * Tue Feb 13 2007 Marcela Maslanova - 1:8.4.13-9 - review again * Fri Feb 09 2007 David Cantrell - 1:8.4.13-8 - rebuild * Thu Feb 08 2007 Marcela Maslanova - 1:8.4.13-7 - downgrade back to 8.4.13 - rhbz #226479 review -- Dennis Gilmore, RHCE From denis at poolshark.org Wed Feb 14 22:36:09 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 14 Feb 2007 23:36:09 +0100 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: <200702141628.14777.dennis@ausil.us> References: <20070214130952.7545.22068@extras64.linux.duke.edu> <20070214221009.GD2378@polop.usc.edu> <200702141628.14777.dennis@ausil.us> Message-ID: <45D38ED9.40808@poolshark.org> Dennis Gilmore wrote: > On Wednesday 14 February 2007 16:24, Paul Wouters wrote: >> On Wed, 14 Feb 2007, Garrick Staples wrote: >>>> xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so >>> What happened here? Presumably buildsys couldn't find the new TCL >>> packages for some reason and produced a false report? >> I wondered the same, as I had fixed my package to deal with this. >> A 'make build' builds it fine for me, so this script definitely creates >> false positives. > > umm no if you look at todays rawhide report the tcl maintainer dropped tcl > back to 8.4 so all the tcl stuff needs rebuilt > > * Thu Feb 08 2007 Marcela Maslanova - 1:8.4.13-7 > - downgrade back to 8.4.13 > - rhbz #226479 review > This could have been communicated better, to say the least. From dennis at ausil.us Wed Feb 14 22:41:25 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 14 Feb 2007 16:41:25 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: <45D38ED9.40808@poolshark.org> References: <20070214130952.7545.22068@extras64.linux.duke.edu> <200702141628.14777.dennis@ausil.us> <45D38ED9.40808@poolshark.org> Message-ID: <200702141641.25997.dennis@ausil.us> On Wednesday 14 February 2007 16:36, Denis Leroy wrote: > Dennis Gilmore wrote: > > > > umm no if you look at todays rawhide report the tcl maintainer dropped > > tcl back to 8.4 so all the tcl stuff needs rebuilt > > > > * Thu Feb 08 2007 Marcela Maslanova - 1:8.4.13-7 > > - downgrade back to 8.4.13 > > - rhbz #226479 review > > This could have been communicated better, to say the least. I dont disagree. the maintainer of tcl really needs to be spoken to by his manager -- Dennis Gilmore, RHCE From tibbs at math.uh.edu Thu Feb 15 00:03:48 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Feb 2007 18:03:48 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: <45D38ED9.40808@poolshark.org> References: <20070214130952.7545.22068@extras64.linux.duke.edu> <20070214221009.GD2378@polop.usc.edu> <200702141628.14777.dennis@ausil.us> <45D38ED9.40808@poolshark.org> Message-ID: >>>>> "DL" == Denis Leroy writes: DL> This could have been communicated better, to say the least. There was a thread about on fedora-devel-list; the end result of that thread was that tcl was being backed off. There was even discussion about whether epoch had been bumped properly. (It was.) This certainly should have been announced on fedora-maintainers, but at least it was discussed with the community in some sense. http://www.redhat.com/archives/fedora-devel-list/2007-February/msg00506.html - J< From wart at kobold.org Thu Feb 15 00:09:56 2007 From: wart at kobold.org (Michael Thomas) Date: Wed, 14 Feb 2007 16:09:56 -0800 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: References: <20070214130952.7545.22068@extras64.linux.duke.edu> <20070214221009.GD2378@polop.usc.edu> <200702141628.14777.dennis@ausil.us> <45D38ED9.40808@poolshark.org> Message-ID: <45D3A4D4.90102@kobold.org> Jason L Tibbitts III wrote: >>>>>> "DL" == Denis Leroy writes: > > DL> This could have been communicated better, to say the least. > > There was a thread about on fedora-devel-list; the end result of that > thread was that tcl was being backed off. There was even discussion > about whether epoch had been bumped properly. (It was.) > > This certainly should have been announced on fedora-maintainers, but > at least it was discussed with the community in some sense. > > http://www.redhat.com/archives/fedora-devel-list/2007-February/msg00506.html Where would be the right place to announce this sort of thing? It seems like we have 3 redundant lists where it could be posted: fedora-extras-list, fedora-maintainers-list, fedora-devel-list --Wart From tibbs at math.uh.edu Thu Feb 15 00:23:47 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Feb 2007 18:23:47 -0600 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: <45D3A4D4.90102@kobold.org> References: <20070214130952.7545.22068@extras64.linux.duke.edu> <20070214221009.GD2378@polop.usc.edu> <200702141628.14777.dennis@ausil.us> <45D38ED9.40808@poolshark.org> <45D3A4D4.90102@kobold.org> Message-ID: >>>>> "MT" == Michael Thomas writes: MT> Where would be the right place to announce this sort of thing? fedora-maintainers seems to be the best place since all package maintainers are supposed to be subscribed there. See the draft maintainer responsibility policy: http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy Hopefully this will get finished up and ratified in the near future. - J< From rc040203 at freenet.de Thu Feb 15 04:30:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 05:30:57 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <200702141408.44834.jkeating@redhat.com> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> Message-ID: <1171513857.3622.342.camel@mccallum.corsepiu.local> On Wed, 2007-02-14 at 14:08 -0500, Jesse Keating wrote: > On Wednesday 14 February 2007 12:55, Matthias Saou wrote: > > Why pick _one_ when it's trivial to evaluate the level of safety a given > > buildroot has for the Fedora build system? That extra "id" execution is > > totally useless with mock, and I simply dislike adding useless stuff. > > Any useless stuff, anywhere. > > > > %{_tmppath}/%{name}-%{version}-%{release}-root > > > > Is shorter than what is now _mandatory_, just as safe/unsafe with mock, > > which is what we encourage all users to use for builds anyway. And it > > saves that useless "id" execution. > > Given that mock is a clean root each time, just %{_tmppath}/%{name} is > enough. However this rule isn't for use in mock, this rule was brought up > and contested for uses outside of mock, particularly by Ralf Corsepius. For the record: My issue is: IMO, the default settings rpmbuild uses, must be safe against arbitrary users running rpmbuild in a multi user environment. %{_tmppath}/%{name}-%{version}-%{release} does not suffice this criterion. It fails in a multiuser environment when rpmbuild leave behind %rpmbuild, e.g.: su -l user1 rpmbuild -ba xxxx.spec ... su -l user2 rpmbuild -ba xxxx.spec This situation typically happens in situations, when co-workers share a machine but work on the same project or a user is using several accounts on the same machine. %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) suffices this criterion. > > If a mktemp based buildroot which actually fixes real issues is found, > > I'll have absolutely no problem switching to that! > > Ralf should be able to point out these problems which a mktemp based solution > would fix. c.f. above. Unfortunately, AFAICT, certain types of rpmbuild invocations seem to invoke executables contained in %buildroot several times. i.e. any command returning different values in subsequent invocations durning rpmbuild-runs will not be applicable (mktemp, timestamps etc.) Ralf From paul at xelerance.com Thu Feb 15 04:47:01 2007 From: paul at xelerance.com (Paul Wouters) Date: Thu, 15 Feb 2007 05:47:01 +0100 (CET) Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-14 In-Reply-To: References: <20070214130952.7545.22068@extras64.linux.duke.edu> <20070214221009.GD2378@polop.usc.edu> <200702141628.14777.dennis@ausil.us> <45D38ED9.40808@poolshark.org> <45D3A4D4.90102@kobold.org> Message-ID: On Thu, 14 Feb 2007, Jason L Tibbitts III wrote: > MT> Where would be the right place to announce this sort of thing? > > fedora-maintainers seems to be the best place since all package > maintainers are supposed to be subscribed there. Yes. Also, I think in this case, it should be perfectly fine for some automated script to up the release numbers/changelog and fire off build requests. There isnt much point on waiting on the individual maintainers for this one. I guess perhaps a tcl84 compat package and tcl-8.5 package construct, like openssl uses, should have been used here? Paul From guthrie at counterexample.org Thu Feb 15 06:06:10 2007 From: guthrie at counterexample.org (John T. Guthrie) Date: Thu, 15 Feb 2007 01:06:10 -0500 Subject: orphaning clearsilver glunarclock gnubg heartbeat ltsp-utils trac xmms-cdread In-Reply-To: References: Message-ID: <1171519570.18976.11.camel@euler.counterexample.org> On Fri, 2007-02-09 at 12:30 +0100, Joost Soeterbroek wrote: > I am orphaning the following packages: > > - clearsilver > - glunarclock > - gnubg > - heartbeat > - ltsp-utils > - trac > - xmms-cdread I'll take xmms-cdread if no one else wants it. > Joost -- John Guthrie guthrie at counterexample.org -------------- 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 Thu Feb 15 09:20:29 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 10:20:29 +0100 Subject: rpmlint question In-Reply-To: References: <20070213171732.GB1373@nostromo.devel.redhat.com> Message-ID: <20070215102029.4b318648.bugs.michael@gmx.net> On Wed, 14 Feb 2007 16:03:12 -0500 (EST), Tom Diehl wrote: > It turns out that libdspam.so is not needed but there are subpackages > that contain drivers for mysql and postgresql. If I pull the .so symlinks, > I get the following error: > > [bullwinkle pts33]# dspam --daemon --debug > 1312: [02/14/2007 15:46:54] dlopen() failed: /usr/lib/libmysql_drv.so: /usr/lib/libmysql_drv.so: cannot open shared object file: No such file or directory > 1312: [02/14/2007 15:46:54] Unable to initialize storage driver > [bullwinkle pts33]# > > Having said the above, there is a config file in dspam, that calls > /usr/lib/libmysql_drv.so. If I change the config to /usr/lib/libmysql_drv.so.7 > or /usr/lib/libmysql_drv.so.7.0.0 then the program runs and the driver loads. > > What is the correct way to handle this type of thing? Rule of thumb: don't touch it unless you know what you are doing. > In addition, if the right answer is to drop the *.so libs, am I really supposed > to drop them or do they belong in the -devel package? > > Is there a doc for this somewhere? So far, I have not been able to find one. There used to be a paragraph somewhere in the Wiki, merged from fedora.us, but I think it got obsoleted/dropped because it would be too confusing for packaging newbies. The decision on what to do with *.so files is difficult. Basically, you only need to know which libraries are needed at run-time and which are needed at build-time only. Then you can include them in the right packages. For ordinary libraries, which are correctly named, only the *.so.* files are needed at run-time and the *.so symlink is only needed during development. libfoo.so is what is needed for the linker option -lfoo to succeed. In your example, however. the developers use dlopen() to load shared libraries at run-time. The libraries are used like plugins. Is there an API (in header files) for those plugin libraries? The developers ought to move their plugins to a private directory and not pollute /usr/lib. The chosen file names are very generic, too, since the libraries can conflict with any other package, which would also include a libmysql_drv.so.* Further, the developers ought to dlopen the versioned libs rather than the non-versioned *.so and that is especially useful when loading external libs (e.g. system libs). From bugs.michael at gmx.net Thu Feb 15 09:20:35 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 10:20:35 +0100 Subject: rpmlint question In-Reply-To: <1171489771.18976.9.camel@euler.counterexample.org> References: <20070213171732.GB1373@nostromo.devel.redhat.com> <1171489771.18976.9.camel@euler.counterexample.org> Message-ID: <20070215102035.dbf8cdca.bugs.michael@gmx.net> On Wed, 14 Feb 2007 16:49:31 -0500, John T. Guthrie wrote: > If you are new to RPMs in general, I have found the Maximum RPM web page > to be invaluable. You can find it here: http://www.rpm.org/max-rpm/ > That page will provide info on how to create subpackages, among other > things, if you aren't familiar with that. Newer, enhanced: http://www.rpm.org/max-rpm-snapshot/ From roozbeh at farsiweb.info Thu Feb 15 10:14:21 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Thu, 15 Feb 2007 13:44:21 +0330 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171513857.3622.342.camel@mccallum.corsepiu.local> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> Message-ID: <1171534461.3324.7.camel@shalil.farsiweb.info> On Thu, 2007-02-15 at 05:30 +0100, Ralf Corsepius wrote: > For the record: > > > My issue is: IMO, the default settings rpmbuild uses, must be safe > against arbitrary users running rpmbuild in a multi user environment. > [...] Just to also mention that (for the record) that the scenario you mention here has happened in real life for me and a colleague. Without knowing, we were building the same SRPM on a test-build machine separately, and things got really weird. My colleague spent quite a while trying to fix the problem from her side, because she didn't know the possible problem with the build root. It was a core package. Roozbeh From bugs.michael at gmx.net Thu Feb 15 10:48:08 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 11:48:08 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171534461.3324.7.camel@shalil.farsiweb.info> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> Message-ID: <20070215114808.8797f9f3.bugs.michael@gmx.net> On Thu, 15 Feb 2007 13:44:21 +0330, Roozbeh Pournader wrote: > On Thu, 2007-02-15 at 05:30 +0100, Ralf Corsepius wrote: > > For the record: > > > > > > My issue is: IMO, the default settings rpmbuild uses, must be safe > > against arbitrary users running rpmbuild in a multi user environment. > > [...] > > Just to also mention that (for the record) that the scenario you mention > here has happened in real life for me and a colleague. Without knowing, > we were building the same SRPM on a test-build machine separately, and > things got really weird. My colleague spent quite a while trying to fix > the problem from her side, because she didn't know the possible problem > with the build root. It was a core package. Funny. Because by default you can only build as superuser, since it needs write-access to /usr/src/redhat/. As soon as you set up a local ~/.rpmmacros, you can define %_buildroot and point it to a private location. Problem solved. For example: %_topdir %(echo $HOME)/tmp/rpm %_tmppath %{_topdir}/tmp %_buildroot %{_tmppath}/%{name}-%{version}-root From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 15 11:01:42 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 15 Feb 2007 12:01:42 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <200702141408.44834.jkeating@redhat.com> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> Message-ID: <20070215120142.1a97aa07@python3.es.egwn.lan> Jesse Keating wrote : > > we can rip out all BuildRoot: lines for good : > > > * Mandatory : The BuildRoot must start with > > > %{_tmppath}/%{name}-%{version}-%{release}. The preferred value is > > > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n). > > > > I like sane "guide" lines, not arbitrary "fixed" lines that make little > > to no sense. > > These are not enough to fix Ralf's issues. > > > If a mktemp based buildroot which actually fixes real issues is found, > > I'll have absolutely no problem switching to that! > > Ralf should be able to point out these problems which a mktemp based solution > would fix. I've read Ralf's issues. Sure, there are issues, and I get his point. Here's another, which IIRC Axel has already exposed a few times : - Try to rebuild an x86_64 package on an x86_64 machine... let's say it takes a long time for some reason. - Fire up the i386 rebuild for the same package on the same x86_64 machine... boom, you end up with installed files overwriting each others! (I've never tested this myself) Which brings me back to my initial points : 1) There are issues, we all know that. 2) There are issues which the current _mandatory_ BuildRoot doesn't fix! 3) We have barely made a fixed setting mandatory, and are already in the process of finding it a replacement. I'm not arguing against using the BuildRoot value which was _suggested_ until now. I'm just annoyed that it has been made _mandatory_ for (what I find to be) no obvious reasons, and knowing we want to change it ASAP. Oh, and co-workers should be using mock. People using plain rpmbuild nowadays should be prepared to see about just as many side-effects as people using rpmbuild as root a few years ago... My packages under review are currently blocked because of this useless guideline change :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.33 0.49 0.47 From laroche at redhat.com Thu Feb 15 11:06:37 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 15 Feb 2007 12:06:37 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215120142.1a97aa07@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> Message-ID: <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> > My packages under review are currently blocked because of this useless > guideline change :-( I don't think it makes sense to block reviews for the BuildRoot settings. We have enough other things to look at... regards, Florian La Roche From rc040203 at freenet.de Thu Feb 15 11:17:29 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 12:17:29 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215114808.8797f9f3.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> <20070215114808.8797f9f3.bugs.michael@gmx.net> Message-ID: <1171538249.3622.542.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 11:48 +0100, Michael Schwendt wrote: > On Thu, 15 Feb 2007 13:44:21 +0330, Roozbeh Pournader wrote: > > > On Thu, 2007-02-15 at 05:30 +0100, Ralf Corsepius wrote: > > > For the record: > > > > > > > > > My issue is: IMO, the default settings rpmbuild uses, must be safe > > > against arbitrary users running rpmbuild in a multi user environment. > > > [...] > > > > Just to also mention that (for the record) that the scenario you mention > > here has happened in real life for me and a colleague. Without knowing, > > we were building the same SRPM on a test-build machine separately, and > > things got really weird. My colleague spent quite a while trying to fix > > the problem from her side, because she didn't know the possible problem > > with the build root. It was a core package. > > Funny. Not funny - Limitations/defects/bugs in rpm. We actually are playing with symptoms, because nobody wants to fix the cause. > Because by default you can only build as superuser, since it > needs write-access to /usr/src/redhat/. As soon as you set up a > local ~/.rpmmacros, you can define %_buildroot and point it to > a private location. Problem solved. For example: > > %_topdir %(echo $HOME)/tmp/rpm > %_tmppath %{_topdir}/tmp > %_buildroot %{_tmppath}/%{name}-%{version}-root Yes, this is the traditional argument against using a fixed buildroot. (IIRC, Thias or Axel came up with it, when this topic came up ca 1/2 a year ago). Ralf From jamatos at fc.up.pt Thu Feb 15 11:18:49 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 15 Feb 2007 11:18:49 +0000 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> References: <1171068977.28153.9.camel@Chuck> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> Message-ID: <200702151118.49691.jamatos@fc.up.pt> On Thursday 15 February 2007 11:06:37 am Florian La Roche wrote: > > My packages under review are currently blocked because of this useless > > guideline change :-( > > I don't think it makes sense to block reviews for the BuildRoot > settings. We have enough other things to look at... Agreed. I think that the whole point is moot, building rpms as root is like playing the with a gun directed to the head. > regards, > > Florian La Roche -- Jos? Ab?lio From roozbeh at farsiweb.info Thu Feb 15 11:21:16 2007 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Thu, 15 Feb 2007 14:51:16 +0330 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215114808.8797f9f3.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> <20070215114808.8797f9f3.bugs.michael@gmx.net> Message-ID: <1171538476.3324.12.camel@shalil.farsiweb.info> On Thu, 2007-02-15 at 11:48 +0100, Michael Schwendt wrote: > As soon as you set up a > local ~/.rpmmacros, you can define %_buildroot and point it to > a private location. Problem solved. Sure you can, but we had kept to the rpmdev-setuptree (used to be called fedora-something then) defaults, which doesn't define a buildroot, but only the very basics. Roozbeh From rc040203 at freenet.de Thu Feb 15 11:24:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 12:24:25 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> Message-ID: <1171538666.20765.1.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 12:06 +0100, Florian La Roche wrote: > > My packages under review are currently blocked because of this useless > > guideline change :-( > > I don't think it makes sense to block reviews for the BuildRoot > settings. We have enough other things to look at... Why isn't anybody at redhat able to run a sed script over all *.spec and thereby closing this case for all packages at once? Ralf From Axel.Thimm at ATrpms.net Thu Feb 15 11:25:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Feb 2007 12:25:18 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070214175635.0c70075c@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <20070214175635.0c70075c@python3.es.egwn.lan> Message-ID: <20070215112518.GA32562@neu.nirvana> On Wed, Feb 14, 2007 at 05:56:35PM +0100, Matthias Saou wrote: > Brian Pepple wrote : > > > Packaging Committee Report > > * FESCo didn't have any objections to the Packaging Committee's > > guidelines regarding: > [...] > > 4. Making the suggested buildroot mandatory > [...] > > What's the rationale behind this? I fail to see the purpose, since this > is something that needs to be addressed better than it is currently, > and ideally from inside rpm itself (and apparently it's being done, > thanks Bill). It's even being subject to current discussions, like > using mktemp for it... > > As far as I'm concerned, any directory inside %_tmppath with a name > which is package _and_ version specific is fine. And before adding "user > specific too", I'd definitely add "arch specific" as I find it more > important, so this is a never ending and useless debate... > > I'm asking because the usual "you should use this buildroot" I usually > get from people reviewing my packages has become "you must", which does > annoy me because I fail to see the point for such a change : > https://bugzilla.redhat.com/228294 We rediscussed this on the FPC meeting on the 13th, especially because the circumstances under which the voting happened where questionable to say the least (the opposition to this, e.g. me, was absent and the party in favour heavily misquoted the arguments of you and me drifting the voters to his cause ...) [1]. During the discussion on IRC we came up with a new buildroot to make more people happy BuildRoot: %(mktemp -d %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) This was positively voted upon. Later Ville found an issue with rpm -q/-bs leaving dead buildroots around and suggested BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) This still isn't perfect, but if one does want to fullfil goals like multiarch, multiuser, security etc it's the better choice. Personally I still prefer a simply EVR buildroot like you do, and I wished the "mandatory" of any buildroot suggestion would be dropped. [1] http://www.redhat.com/archives/fedora-packaging/2007-February/msg00089.html [2] http://www.redhat.com/archives/fedora-packaging/2007-February/msg00138.html -- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Feb 15 11:34:10 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 15 Feb 2007 12:34:10 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171538666.20765.1.camel@mccallum.corsepiu.local> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> <1171538666.20765.1.camel@mccallum.corsepiu.local> Message-ID: <20070215123410.7c040b02@python3.es.egwn.lan> Ralf Corsepius wrote : > On Thu, 2007-02-15 at 12:06 +0100, Florian La Roche wrote: > > > My packages under review are currently blocked because of this useless > > > guideline change :-( > > > > I don't think it makes sense to block reviews for the BuildRoot > > settings. We have enough other things to look at... > > Why isn't anybody at redhat able to run a sed script over all *.spec > and thereby closing this case for all packages at once? Because we might want to do that only once, if/when we find a better Buildroot value? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 3.44 3.58 2.79 From rc040203 at freenet.de Thu Feb 15 11:51:26 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 12:51:26 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215123410.7c040b02@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> <1171538666.20765.1.camel@mccallum.corsepiu.local> <20070215123410.7c040b02@python3.es.egwn.lan> Message-ID: <1171540287.20765.20.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 12:34 +0100, Matthias Saou wrote: > Ralf Corsepius wrote : > > > On Thu, 2007-02-15 at 12:06 +0100, Florian La Roche wrote: > > > > My packages under review are currently blocked because of this useless > > > > guideline change :-( > > > > > > I don't think it makes sense to block reviews for the BuildRoot > > > settings. We have enough other things to look at... > > > > Why isn't anybody at redhat able to run a sed script over all *.spec > > and thereby closing this case for all packages at once? > > Because we might want to do that only once, if/when we find a better > Buildroot value? Why should this be a requirement? Florian's remark was aiming at "ease of work". Helping him would be a matter of very few hours to for a central admin. As a side-effect, all the arguments on Bugzilla would be closed, still existing broken buildroots would be fixed ... And FPC could try to develop a long term solution in peace and silence, which would help avoiding such semi-cooked/semi-functional proposals as we came up the last time. Ralf From bugs.michael at gmx.net Thu Feb 15 12:00:42 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 13:00:42 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171538476.3324.12.camel@shalil.farsiweb.info> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> <20070215114808.8797f9f3.bugs.michael@gmx.net> <1171538476.3324.12.camel@shalil.farsiweb.info> Message-ID: <20070215130042.919c0bab.bugs.michael@gmx.net> On Thu, 15 Feb 2007 14:51:16 +0330, Roozbeh Pournader wrote: > On Thu, 2007-02-15 at 11:48 +0100, Michael Schwendt wrote: > > As soon as you set up a > > local ~/.rpmmacros, you can define %_buildroot and point it to > > a private location. Problem solved. > > Sure you can, but we had kept to the rpmdev-setuptree (used to be called > fedora-something then) defaults, which doesn't define a buildroot, but > only the very basics. It doesn't define a buildroot at all, and that is a problem in the script. From buildsys at fedoraproject.org Thu Feb 15 12:34:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 15 Feb 2007 07:34:50 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-15 Message-ID: <20070215123450.1979615212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 33 arrows-0.6-3.fc7 bugzilla-2.22.1-6.fc7 eggdrop-1.6.18-6.fc7 NEW emacs-nxml-mode-0.20041004-5.fc7 environment-modules-3.2.4-2.fc7 NEW fedora-ds-1.1.0-0.1.20070213.fc7 gnu-smalltalk-2.3.3-3.fc7 gnubg-20061119-7.fc7 gnucap-0.35-1.fc7 graphviz-2.12-6.fc7 (!) hping3-0.0.20051105-6.fc7 : INVALID rebuild, not published! NEW hunspell-he-0.20050112-1.fc7 NEW hunspell-hr-0.20060607-1.fc7 NEW hunspell-th-0.20061212-1.fc7 kicad-2007.01.15-2.fc7 kid3-0.8.1-2.fc7 libtomoe-gtk-0.5.1-1.fc7 libtunepimp-0.5.3-3.fc7 mimedefang-2.61-1.fc7 ode-0.8-1.fc7 ppracer-0.3.1-10.fc7 python-imaging-1.1.6-2.fc7 python-matplotlib-0.90.0-3.fc7 qt4-qsa-1.2.2-2.fc7 seedit-2.1.0-5.fc7 sturmbahnfahrer-1.2-2.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2925.fc7 tinyfugue-5.0-0.6.b8.fc7 tomoe-0.5.1-1.fc7 torque-2.1.6-5.fc7 uudeview-0.5.20-11 xine-lib-1.1.4-2.fc7 (!) xpa-2.1.6-8.fc7 : INVALID rebuild, not published! Packages built and released for Fedora Extras 6: 10 NEW ack-1.56-4.fc6 amarok-1.4.5-3.fc6 bugzilla-2.22-12.fc6 gnubg-20061119-7.fc6 NEW gtranslator-1.1.7-2.fc6 kicad-2007.01.15-2.fc6 mimedefang-2.61-1.fc6 qt4-qsa-1.2.2-2.fc6 sysprof-kmod-1.0.8-1.2.6.19_1.2911.fc6 tinyfugue-5.0-0.6.b8.fc6 Packages built and released for Fedora Extras 5: 13 MagicPoint-1.11b-4.fc5 NEW ack-1.56-4.fc5 amarok-1.4.5-3.fc5 bugzilla-2.22-11.fc5 em8300-kmod-0.16.0-1.2.6.19_1.2288.fc5 NEW fedora-ds-1.1.0-0.1.20070213.fc5 gnu-smalltalk-2.3.3-2.fc5 gnubg-20061119-8.fc5.2 kicad-2007.01.15-2.fc5 mimedefang-2.61-1.fc5 qt4-qsa-1.2.2-2.fc5 sysprof-kmod-1.0.8-1.2.6.19_1.2288.fc5 tinyfugue-5.0-0.4.b8.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From bugs.michael at gmx.net Thu Feb 15 12:59:26 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 13:59:26 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171538249.3622.542.camel@mccallum.corsepiu.local> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> <20070215114808.8797f9f3.bugs.michael@gmx.net> <1171538249.3622.542.camel@mccallum.corsepiu.local> Message-ID: <20070215135926.09613c69.bugs.michael@gmx.net> On Thu, 15 Feb 2007 12:17:29 +0100, Ralf Corsepius wrote: > > > > My issue is: IMO, the default settings rpmbuild uses, must be safe > > > > against arbitrary users running rpmbuild in a multi user environment. > > > > [...] > > > > > > Just to also mention that (for the record) that the scenario you mention > > > here has happened in real life for me and a colleague. Without knowing, > > > we were building the same SRPM on a test-build machine separately, and > > > things got really weird. My colleague spent quite a while trying to fix > > > the problem from her side, because she didn't know the possible problem > > > with the build root. It was a core package. > > > > Funny. > > Not funny - Limitations/defects/bugs in rpm. > > We actually are playing with symptoms, because nobody wants to fix the > cause. So what? It cannot be fixed at the spec-file level. But it can be fixed with global defaults, with per user rpmbuild trees. The /usr/src/redhat tree is crap. It is beyond my comprehension why it still exists and why it encourages users to run rpmbuild as root. > > Because by default you can only build as superuser, since it > > needs write-access to /usr/src/redhat/. As soon as you set up a > > local ~/.rpmmacros, you can define %_buildroot and point it to > > a private location. Problem solved. For example: > > > > %_topdir %(echo $HOME)/tmp/rpm > > %_tmppath %{_topdir}/tmp > > %_buildroot %{_tmppath}/%{name}-%{version}-root > > Yes, this is the traditional argument against using a fixed buildroot. > (IIRC, Thias or Axel came up with it, when this topic came up ca 1/2 a > year ago). It predates that discussion *by far*. As why changes to global configuration defaults have never found their way into RPM, I can only guess. Perhaps it is in bugzilla as one of the many WONTFIX tickets. For a long period of time, bug reports and feature requests have not been taken seriously, users and packagers have been burnt and have learnt to work around deficiencies. "mktemp" in the spec file BuildRoot tag is getting far too annoying, especially since I do not like anything in my spec file which is not used during my local test-builds, and because failure conditions are not dealt with. I don't know yet what's necessary to block it from becoming mandatory, but it's ridiculous, giving the fact that it will return a fresh tmp dir with every invocation of rpmbuild. From Axel.Thimm at ATrpms.net Thu Feb 15 13:14:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 15 Feb 2007 14:14:40 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215135926.09613c69.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> <20070215114808.8797f9f3.bugs.michael@gmx.net> <1171538249.3622.542.camel@mccallum.corsepiu.local> <20070215135926.09613c69.bugs.michael@gmx.net> Message-ID: <20070215131440.GB6038@neu.nirvana> On Thu, Feb 15, 2007 at 01:59:26PM +0100, Michael Schwendt wrote: > "mktemp" in the spec file BuildRoot tag is getting far too annoying, > especially since I do not like anything in my spec file which is not used > during my local test-builds, and because failure conditions are not dealt > with. I don't know yet what's necessary to block it from becoming > mandatory, but it's ridiculous, giving the fact that it will return a > fresh tmp dir with every invocation of rpmbuild. Check Ville's posting on fedora-packaging on correcting this. And FWIW I personally think this is the lesser evil. The real "solution" would be to leave buildroots w/o any mandatory clause. If a packager isn't able to construct a sane buildroot, then I don't need to check on the rest of the specfile ... -- 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 Thu Feb 15 13:23:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 14:23:10 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215131440.GB6038@neu.nirvana> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> <20070215114808.8797f9f3.bugs.michael@gmx.net> <1171538249.3622.542.camel@mccallum.corsepiu.local> <20070215135926.09613c69.bugs.michael@gmx.net> <20070215131440.GB6038@neu.nirvana> Message-ID: <1171545790.20765.42.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 14:14 +0100, Axel Thimm wrote: > On Thu, Feb 15, 2007 at 01:59:26PM +0100, Michael Schwendt wrote: > > "mktemp" in the spec file BuildRoot tag is getting far too annoying, > > especially since I do not like anything in my spec file which is not used > > during my local test-builds, and because failure conditions are not dealt > > with. I don't know yet what's necessary to block it from becoming > > mandatory, but it's ridiculous, giving the fact that it will return a > > fresh tmp dir with every invocation of rpmbuild. > > Check Ville's posting on fedora-packaging on correcting this. It's not correcting this, it's hack making the symptoms of the mktemp approach less visible. > And FWIW > I personally think this is the lesser evil. The real "solution" would > be to leave buildroots w/o any mandatory clause. => non deterministic builds Ralf From buildsys at fedoraproject.org Thu Feb 15 13:28:55 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 15 Feb 2007 13:28:55 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-15 Message-ID: <20070215132855.13466.51842@extras64.linux.duke.edu> New report for: rpm AT greysector.net package: mkvtoolnix - 1.8.1-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 package: mkvtoolnix - 1.8.1-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 package: mkvtoolnix - 1.8.1-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7()(64bit) ====================================================================== New report for: j.w.r.degoede AT hhs.nl package: scummvm - 0.9.1-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 package: scummvm - 0.9.1-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 package: scummvm - 0.9.1-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7()(64bit) ====================================================================== New report for: rdieter AT math.unl.edu package: akode - 2.0.1-5.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7 libOggFLAC.so.3 package: akode - 2.0.1-5.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 libOggFLAC.so.3 package: akode - 2.0.1-5.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 libOggFLAC.so.3 package: akode - 2.0.1-5.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libOggFLAC.so.3()(64bit) libFLAC.so.7()(64bit) ====================================================================== New report for: foolish AT guezz.net package: flac123 - 0.0.9-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 package: flac123 - 0.0.9-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 package: flac123 - 0.0.9-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7()(64bit) package: muine - 0.8.7-1.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7 package: muine - 0.8.7-1.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 package: muine - 0.8.7-1.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 package: muine - 0.8.7-1.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7()(64bit) ====================================================================== New report for: redhat-bugzilla AT camperquake.de package: audacious-plugins - 1.2.5-3.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7 package: audacious-plugins - 1.2.5-3.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 package: audacious-plugins - 1.2.5-3.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 package: audacious-plugins - 1.2.5-3.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7()(64bit) ====================================================================== New report for: gemi AT bluewin.ch package: audacity - 1.3.2-7.20070106cvs.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 libFLAC++.so.5 package: audacity - 1.3.2-7.20070106cvs.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 libFLAC++.so.5 package: audacity - 1.3.2-7.20070106cvs.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libFLAC++.so.5()(64bit) libFLAC.so.7()(64bit) package: graveman - 0.3.12.5-3.fc7.i386 from fedora-extras-development-i386 unresolved deps: libFLAC.so.7 package: graveman - 0.3.12.5-3.fc7.ppc from fedora-extras-development-ppc unresolved deps: libFLAC.so.7 package: graveman - 0.3.12.5-3.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libFLAC.so.7()(64bit) ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (6 days) libetpan - 0.49-1.fc7.i386 (6 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (6 days) cgoorah AT yahoo.com.au irsim - 9.7.41-5.fc7.i386 irsim - 9.7.41-5.fc7.ppc toped - 0.8.2-2.fc6.i386 (62 days) toped - 0.8.2-2.fc6.ppc (62 days) toped - 0.8.2-2.fc6.x86_64 (62 days) xcircuit - 3.4.26-18.fc7.i386 xcircuit - 3.4.26-18.fc7.ppc xcircuit - 3.4.26-18.fc7.x86_64 dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (69 days) csound - 5.03.0-9.fc7.i386 (69 days) csound - 5.03.0-9.fc7.ppc (69 days) csound - 5.03.0-9.fc7.x86_64 (69 days) csound-python - 5.03.0-9.fc7.i386 (69 days) csound-python - 5.03.0-9.fc7.ppc (69 days) csound-python - 5.03.0-9.fc7.x86_64 (69 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (71 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (71 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (71 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (71 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (71 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (71 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (71 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (69 days) foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 flac123 - 0.0.9-1.fc7.ppc flac123 - 0.0.9-1.fc7.x86_64 muine - 0.8.7-1.fc7.i386 muine - 0.8.7-1.fc7.i386 muine - 0.8.7-1.fc7.ppc muine - 0.8.7-1.fc7.x86_64 gemi AT bluewin.ch audacity - 1.3.2-7.20070106cvs.fc7.i386 audacity - 1.3.2-7.20070106cvs.fc7.ppc audacity - 1.3.2-7.20070106cvs.fc7.x86_64 graveman - 0.3.12.5-3.fc7.i386 graveman - 0.3.12.5-3.fc7.ppc graveman - 0.3.12.5-3.fc7.x86_64 skencil - 0.6.17-12.fc7.i386 skencil - 0.6.17-12.fc7.ppc skencil - 0.6.17-12.fc7.x86_64 green AT redhat.com vkeybd - 0.1.17a-2.fc7.i386 vkeybd - 0.1.17a-2.fc7.ppc vkeybd - 0.1.17a-2.fc7.x86_64 ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (66 days) libreadline-java - 0.8.0-13.fc6.i386 (66 days) libreadline-java - 0.8.0-13.fc6.ppc (66 days) libreadline-java - 0.8.0-13.fc6.x86_64 (66 days) j.w.r.degoede AT hhs.nl scummvm - 0.9.1-2.fc7.i386 scummvm - 0.9.1-2.fc7.ppc scummvm - 0.9.1-2.fc7.x86_64 jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (129 days) linphone - 1.2.0-4.fc5.ppc (129 days) linphone - 1.2.0-4.fc5.x86_64 (129 days) lmacken AT redhat.com python-cherrypy - 2.2.1-3.fc6.noarch (69 days) python-cherrypy - 2.2.1-3.fc6.noarch (69 days) python-cherrypy - 2.2.1-3.fc6.noarch (69 days) matthias AT rpmforge.net easytag - 1.99.13-1.fc7.i386 easytag - 1.99.13-1.fc7.ppc easytag - 1.99.13-1.fc7.x86_64 xmms-flac - 1.1.2-27.fc6.i386 xmms-flac - 1.1.2-27.fc6.ppc xmms-flac - 1.1.2-27.fc6.x86_64 orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (69 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (69 days) paul AT xelerance.com hping3 - 0.0.20051105-6.fc7.i386 hping3 - 0.0.20051105-6.fc7.ppc hping3 - 0.0.20051105-6.fc7.x86_64 petersen AT redhat.com ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.i386 (24 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.ppc (24 days) ghc642-gtk2hs-mozembed - 0.9.10-2.fc5.x86_64 (24 days) rdieter AT math.unl.edu PyKDE - 3.16.0-5.fc7.i386 (69 days) PyKDE - 3.16.0-5.fc7.i386 (69 days) PyKDE - 3.16.0-5.fc7.ppc (69 days) PyKDE - 3.16.0-5.fc7.x86_64 (69 days) akode - 2.0.1-5.fc7.i386 akode - 2.0.1-5.fc7.i386 akode - 2.0.1-5.fc7.ppc akode - 2.0.1-5.fc7.x86_64 redhat-bugzilla AT camperquake.de audacious-plugins - 1.2.5-3.fc7.i386 audacious-plugins - 1.2.5-3.fc7.i386 audacious-plugins - 1.2.5-3.fc7.ppc audacious-plugins - 1.2.5-3.fc7.x86_64 rpm AT greysector.net mkvtoolnix - 1.8.1-2.fc7.i386 mkvtoolnix - 1.8.1-2.fc7.ppc mkvtoolnix - 1.8.1-2.fc7.x86_64 shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (69 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 xpa - 2.1.6-8.fc7.i386 xpa - 2.1.6-8.fc7.ppc xpa - 2.1.6-8.fc7.x86_64 stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (69 days) xmldiff - 0.6.7-12.fc6.ppc (69 days) xmldiff - 0.6.7-12.fc6.x86_64 (69 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 R - 2.4.1-2.fc7.i386 R - 2.4.1-2.fc7.ppc R - 2.4.1-2.fc7.x86_64 ville.skytta AT iki.fi kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc ====================================================================== Broken packages in fedora-extras-5-i386: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.i386 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.ppc requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: ghc642-gtk2hs-mozembed-0.9.10-2.fc5.x86_64 requires mozilla-devel = 37:1.7.13 linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so akode-2.0.1-5.fc7.i386 requires libFLAC.so.7 akode-2.0.1-5.fc7.i386 requires libOggFLAC.so.3 audacious-plugins-1.2.5-3.fc7.i386 requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC++.so.5 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 easytag-1.99.13-1.fc7.i386 requires libFLAC.so.7 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 graveman-0.3.12.5-3.fc7.i386 requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.i386 requires libtcl8.5.so irsim-9.7.41-5.fc7.i386 requires libtk8.5.so irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 mkvtoolnix-1.8.1-2.fc7.i386 requires libFLAC.so.7 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 scummvm-0.9.1-2.fc7.i386 requires libFLAC.so.7 skencil-0.6.17-12.fc7.i386 requires libtk8.5.so skencil-0.6.17-12.fc7.i386 requires libtcl8.5.so toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 vkeybd-0.1.17a-2.fc7.i386 requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.i386 requires tk < 0:8.6 vkeybd-0.1.17a-2.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xmms-flac-1.1.2-27.fc6.i386 requires libFLAC.so.7 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-ppc: PyKDE-3.16.0-5.fc7.ppc requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.ppc requires python-abi = 0:2.4 R-2.4.1-2.fc7.ppc requires libtk8.5.so R-2.4.1-2.fc7.ppc requires libtcl8.5.so akode-2.0.1-5.fc7.ppc requires libFLAC.so.7 akode-2.0.1-5.fc7.ppc requires libOggFLAC.so.3 audacious-plugins-1.2.5-3.fc7.ppc requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC++.so.5 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 easytag-1.99.13-1.fc7.ppc requires libFLAC.so.7 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 graveman-0.3.12.5-3.fc7.ppc requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.ppc requires libtcl8.5.so irsim-9.7.41-5.fc7.ppc requires libtk8.5.so irsim-9.7.41-5.fc7.ppc requires libtcl8.5.so kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 mkvtoolnix-1.8.1-2.fc7.ppc requires libFLAC.so.7 muine-0.8.7-1.fc7.ppc requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 scummvm-0.9.1-2.fc7.ppc requires libFLAC.so.7 skencil-0.6.17-12.fc7.ppc requires libtk8.5.so skencil-0.6.17-12.fc7.ppc requires libtcl8.5.so toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 vkeybd-0.1.17a-2.fc7.ppc requires libtk8.5.so vkeybd-0.1.17a-2.fc7.ppc requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.ppc requires tk < 0:8.6 xcircuit-3.4.26-18.fc7.ppc requires libtk8.5.so xcircuit-3.4.26-18.fc7.ppc requires libtcl8.5.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xmms-flac-1.1.2-27.fc6.ppc requires libFLAC.so.7 xpa-2.1.6-8.fc7.ppc requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-x86_64: PyKDE-3.16.0-5.fc7.i386 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.i386 requires python-abi = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python(abi) = 0:2.4 PyKDE-3.16.0-5.fc7.x86_64 requires python-abi = 0:2.4 R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so R-2.4.1-2.fc7.x86_64 requires libtcl8.5.so()(64bit) R-2.4.1-2.fc7.x86_64 requires libtk8.5.so()(64bit) akode-2.0.1-5.fc7.i386 requires libFLAC.so.7 akode-2.0.1-5.fc7.i386 requires libOggFLAC.so.3 akode-2.0.1-5.fc7.x86_64 requires libOggFLAC.so.3()(64bit) akode-2.0.1-5.fc7.x86_64 requires libFLAC.so.7()(64bit) audacious-plugins-1.2.5-3.fc7.i386 requires libFLAC.so.7 audacious-plugins-1.2.5-3.fc7.x86_64 requires libFLAC.so.7()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC++.so.5()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC.so.7()(64bit) claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) easytag-1.99.13-1.fc7.x86_64 requires libFLAC.so.7()(64bit) flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) graveman-0.3.12.5-3.fc7.x86_64 requires libFLAC.so.7()(64bit) hping3-0.0.20051105-6.fc7.x86_64 requires libtcl8.5.so()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 mkvtoolnix-1.8.1-2.fc7.x86_64 requires libFLAC.so.7()(64bit) muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 muine-0.8.7-1.fc7.x86_64 requires libFLAC.so.7()(64bit) openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 scummvm-0.9.1-2.fc7.x86_64 requires libFLAC.so.7()(64bit) skencil-0.6.17-12.fc7.x86_64 requires libtk8.5.so()(64bit) skencil-0.6.17-12.fc7.x86_64 requires libtcl8.5.so()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires libtk8.5.so()(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires libtcl8.5.so()(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires tk < 0:8.6 xcircuit-3.4.26-18.fc7.x86_64 requires libtk8.5.so()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtcl8.5.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xmms-flac-1.1.2-27.fc6.x86_64 requires libFLAC.so.7()(64bit) xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so xpa-2.1.6-8.fc7.x86_64 requires libtcl8.5.so()(64bit) From gilboad at gmail.com Thu Feb 15 13:38:55 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 15 Feb 2007 15:38:55 +0200 Subject: Make tags fails? Help? Message-ID: <1171546735.9384.25.camel@gilboa-work-dev.localdomain> Hello all, I'm trying to import two new packages into -extras and make tag fails. $ rm -rf gmrun icewm common $ cvs co gmrun icewm cvs checkout: Updating gmrun U gmrun/Makefile U gmrun/import.log U gmrun/pkg.acl cvs checkout: Updating gmrun/FC-5 U gmrun/FC-5/.cvsignore U gmrun/FC-5/Makefile U gmrun/FC-5/branch U gmrun/FC-5/sources cvs checkout: Updating gmrun/FC-6 U gmrun/FC-6/.cvsignore U gmrun/FC-6/Makefile U gmrun/FC-6/branch U gmrun/FC-6/sources cvs checkout: Updating gmrun/devel U gmrun/devel/.cvsignore U gmrun/devel/Makefile U gmrun/devel/gmrun-gmrunrc.patch U gmrun/devel/gmrun.spec U gmrun/devel/sources cvs checkout: Updating common U common/Makefile U common/Makefile.common U common/branches U common/cvs-import.sh cvs checkout: Updating icewm U icewm/Makefile U icewm/import.log U icewm/pkg.acl cvs checkout: Updating icewm/FC-5 U icewm/FC-5/.cvsignore U icewm/FC-5/Makefile U icewm/FC-5/branch U icewm/FC-5/sources cvs checkout: Updating icewm/FC-6 U icewm/FC-6/.cvsignore U icewm/FC-6/Makefile U icewm/FC-6/branch U icewm/FC-6/sources cvs checkout: Updating icewm/devel U icewm/devel/.cvsignore U icewm/devel/Makefile U icewm/devel/icewm-configure.patch U icewm/devel/icewm-keys.patch U icewm/devel/icewm-menu.patch U icewm/devel/icewm-startup U icewm/devel/icewm-toolbar.patch U icewm/devel/icewm-xdg-menu U icewm/devel/icewm.desktop U icewm/devel/icewm.spec U icewm/devel/sources cvs checkout: Updating common U common/Makefile U common/Makefile.common U common/branches U common/cvs-import.sh $ cd icewm/devel/ $ make tag cvs tag -c icewm-1_2_30-12_fc7 cvs [server aborted]: "tag" requires write access to the repository make: *** [tag] Error 1 ACL problems? - Gilboa From bugs.michael at gmx.net Thu Feb 15 13:54:24 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 14:54:24 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215131440.GB6038@neu.nirvana> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <1171513857.3622.342.camel@mccallum.corsepiu.local> <1171534461.3324.7.camel@shalil.farsiweb.info> <20070215114808.8797f9f3.bugs.michael@gmx.net> <1171538249.3622.542.camel@mccallum.corsepiu.local> <20070215135926.09613c69.bugs.michael@gmx.net> <20070215131440.GB6038@neu.nirvana> Message-ID: <20070215145424.b2e373eb.bugs.michael@gmx.net> On Thu, 15 Feb 2007 14:14:40 +0100, Axel Thimm wrote: > > "mktemp" in the spec file BuildRoot tag is getting far too annoying, > > especially since I do not like anything in my spec file which is not used > > during my local test-builds, and because failure conditions are not dealt > > with. I don't know yet what's necessary to block it from becoming > > mandatory, but it's ridiculous, giving the fact that it will return a > > fresh tmp dir with every invocation of rpmbuild. > > Check Ville's posting on fedora-packaging on correcting this. And FWIW > I personally think this is the lesser evil. The real "solution" would > be to leave buildroots w/o any mandatory clause. mktemp -ud also returns a new path with every invocation. A buildroot that becomes a moving target (even when overriding %_tmppath) is impractical for --short-circuit builds or anything where you would want to examine the buildroot contents. From jkeating at redhat.com Thu Feb 15 14:00:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 09:00:19 -0500 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215145424.b2e373eb.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <20070215131440.GB6038@neu.nirvana> <20070215145424.b2e373eb.bugs.michael@gmx.net> Message-ID: <200702150900.19913.jkeating@redhat.com> On Thursday 15 February 2007 08:54, Michael Schwendt wrote: > mktemp -ud also returns a new path with every invocation. A buildroot that > becomes a moving target (even when overriding %_tmppath) is impractical for > --short-circuit builds or anything where you would want to examine the > buildroot contents. Without a unique buildroot for each build, you're back to the problem of overwriting or picking something up that you didn't put there in the first place. I do believe the patches that were sent upstream to do BuildRoot internally within RPM make use of unique directories per 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 bugs.michael at gmx.net Thu Feb 15 14:17:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 15:17:57 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <200702150900.19913.jkeating@redhat.com> References: <1171068977.28153.9.camel@Chuck> <20070215131440.GB6038@neu.nirvana> <20070215145424.b2e373eb.bugs.michael@gmx.net> <200702150900.19913.jkeating@redhat.com> Message-ID: <20070215151757.bc6e4685.bugs.michael@gmx.net> On Thu, 15 Feb 2007 09:00:19 -0500, Jesse Keating wrote: > > mktemp -ud also returns a new path with every invocation. A buildroot that > > becomes a moving target (even when overriding %_tmppath) is impractical for > > --short-circuit builds or anything where you would want to examine the > > buildroot contents. > > Without a unique buildroot for each build, you're back to the problem of > overwriting or picking something up that you didn't put there in the first > place. No, because every spec file does "rm -rf $RPM_BUILD_ROOT" at the beginning of %install. All that is needed is making %_tmppath point to the user's private space. And that is highly recommended for many years. > I do believe the patches that were sent upstream to do BuildRoot > internally within RPM make use of unique directories per build. Raises the question why there is a draft on making a specific BuildRoot mandatory? From laroche at redhat.com Thu Feb 15 14:21:36 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 15 Feb 2007 15:21:36 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <1171540287.20765.20.camel@mccallum.corsepiu.local> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> <1171538666.20765.1.camel@mccallum.corsepiu.local> <20070215123410.7c040b02@python3.es.egwn.lan> <1171540287.20765.20.camel@mccallum.corsepiu.local> Message-ID: <20070215142136.GA25930@dudweiler.stuttgart.redhat.com> > Florian's remark was aiming at "ease of work". Helping him would be a > matter of very few hours to for a central admin. The cvs commit would be easy todo, question is if we then wait for new package builds to happen or if also a central person should kick of and monitor package rebuilds. > And FPC could try to develop a long term solution in peace and silence, > which would help avoiding such semi-cooked/semi-functional proposals as > we came up the last time. Yepp, not all tools are ready for this. And no final and fully tunable BuildRoots setting found yet. regards, Florian La Roche From bugs.michael at gmx.net Thu Feb 15 14:32:16 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 15:32:16 +0100 Subject: claws-mail, libetpan (was: Re: Summary - Broken dependencies in Fedora Extras - 2007-02-15) In-Reply-To: <20070215132855.13466.51842@extras64.linux.duke.edu> References: <20070215132855.13466.51842@extras64.linux.duke.edu> Message-ID: <20070215153216.54e08398.bugs.michael@gmx.net> On Thu, 15 Feb 2007 13:28:55 -0000, Fedora Extras repoclosure wrote: > claws-mail - 2.7.2-1.fc7.i386 (6 days) > libetpan - 0.49-1.fc7.i386 (6 days) > ====================================================================== > Broken packages in fedora-extras-development-x86_64: > > claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so > libetpan-0.49-1.fc7.i386 requires libdb-4.3.so This is odd. First of all, libdb-4.5.so seems to be available since Dec 4th. And claws-mail need not link against libdb at all, since it is libetpan that links against it and BuildRequires db4-devel. It's libetpan-config which returns the libraries it is linked against, $ ./libetpan-config --libs -L/usr/lib -letpan -pthread -lssl -lcrypto -ldb-4.3 -lsasl2 and which causes apps to link against them, too. From jkeating at redhat.com Thu Feb 15 14:30:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 09:30:10 -0500 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215151757.bc6e4685.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <200702150900.19913.jkeating@redhat.com> <20070215151757.bc6e4685.bugs.michael@gmx.net> Message-ID: <200702150930.10903.jkeating@redhat.com> On Thursday 15 February 2007 09:17, Michael Schwendt wrote: > Raises the question why there is a draft on making a specific BuildRoot > mandatory? Because of the lag between a patch being submitted and a build made with patch or a release made with patch. -- 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 faucamp at csir.co.za Thu Feb 15 14:29:57 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Thu, 15 Feb 2007 16:29:57 +0200 Subject: Packaging KDE window decorations, etc Message-ID: <45D48A860200006A0000FE81@cs-emo.csir.co.za> Hi, I want to package/import a few window decorations and styles for KDE, and would like to know the following: How should these types of packages be named? After a quick scan of the extras repo, I came across "crystal", with the description "KDE window decoration". This works fine for crystal, but I've packaged a window decoration called "alphacube" which is based on a Gnome theme with the same name, so in my case this might cause a package naming clash in the future. And besides, the name "alphacube" does not intuitively tell you that it is a KDE window decoration, vs some 3d virtual reality Rubik's cube simulation. Searching for a window decoration/theme with this naming scheme is also a bit troublesome. Also, the wiki does not provide information on the proper naming of themes, etc (I may have missed it, though); the closest thing I could find was the "Addon Packages (General)" section; if treated like this, what should it be named? Something like kdebase-alphacube doesn't really make sense, and kde-theme-alphacube or kde-decoration-alphacube, while nice, does not really follow any of the current packaging naming guidelines... Please advise? -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rdieter at math.unl.edu Thu Feb 15 14:37:19 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Feb 2007 08:37:19 -0600 Subject: Packaging KDE window decorations, etc References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> Message-ID: Francois Aucamp wrote: > I want to package/import a few window decorations and styles for KDE, > and would like to know the following: > > How should these types of packages be named? ... > Please advise? Please simply upstream name, for now, at least until we come up with something better. -- Rex From mr.ecik at gmail.com Thu Feb 15 14:44:58 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Thu, 15 Feb 2007 15:44:58 +0100 Subject: Odd cvs-import.sh and make tag error Message-ID: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> Hi! Today I tried to import my package to repo. Cvs-import.sh returns some odd errors, but it finished its job successfully so I wasn't concerned about that. However, `make tag` gives me identical errors i.e.: [ecik at ecik ~/cvs/sonata/devel]$ LANG=C make tag build error: Unable to open emacs-nxml-mode: No such file or directory error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: Group field must be present in package: (main package) error: License field must be present in package: (main package) error: query of specfile emacs-nxml-mode failed, can't parse error: Unable to open emacs-nxml-mode: No such file or directory error: Name field must be present in package: (main package) error: Version field must be present in package: (main package) error: Release field must be present in package: (main package) error: Summary field must be present in package: (main package) error: Group field must be present in package: (main package) error: License field must be present in package: (main package) error: query of specfile emacs-nxml-mode failed, can't parse make: *** No rule to make target `emacs-nxml-mode', needed by `tag'. Stop. I've never had such a problem before, what can I do with it? -- Micha? Bentkowski mr.ecik at gmail.com From bugs.michael at gmx.net Thu Feb 15 14:49:19 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 15:49:19 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <200702150930.10903.jkeating@redhat.com> References: <1171068977.28153.9.camel@Chuck> <200702150900.19913.jkeating@redhat.com> <20070215151757.bc6e4685.bugs.michael@gmx.net> <200702150930.10903.jkeating@redhat.com> Message-ID: <20070215154919.84bd7c43.bugs.michael@gmx.net> On Thu, 15 Feb 2007 09:30:10 -0500, Jesse Keating wrote: > > Raises the question why there is a draft on making a specific BuildRoot > > mandatory? > > Because of the lag between a patch being submitted and a build made with patch > or a release made with patch. So, the "upstream" rule here is violated. Instead, you want to change thousands of spec files because of a theoretical problem that can only affect users who don't set up a per user build environment on a multi-user system? Loyalty finds an end here. The mktemp buildroot in spec files would be really disappointing decision. $ rpm -qf /usr/lib/rpm/redhat/macros redhat-rpm-config-8.0.45-6 $ rpm --eval %_tmppath /var/tmp could be modified more quickly than applying a bigger buildroot patch to the code. From bugs.michael at gmx.net Thu Feb 15 14:52:12 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 15:52:12 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215142136.GA25930@dudweiler.stuttgart.redhat.com> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> <1171538666.20765.1.camel@mccallum.corsepiu.local> <20070215123410.7c040b02@python3.es.egwn.lan> <1171540287.20765.20.camel@mccallum.corsepiu.local> <20070215142136.GA25930@dudweiler.stuttgart.redhat.com> Message-ID: <20070215155212.51c14f30.bugs.michael@gmx.net> On Thu, 15 Feb 2007 15:21:36 +0100, Florian La Roche wrote: > > Florian's remark was aiming at "ease of work". Helping him would be a > > matter of very few hours to for a central admin. > > The cvs commit would be easy todo, question is if we then wait for new > package builds to happen or if also a central person should kick of and > monitor package rebuilds. Please do not add such mktemp madness to everybody's spec files. There are enough packaging issues, broken deps and bugs in Extras, do you really think it would be highly important to submit unnecessary rebuilds of thousands of packages just for a changed BuildRoot? From jkeating at redhat.com Thu Feb 15 14:51:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 09:51:40 -0500 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215154919.84bd7c43.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <200702150930.10903.jkeating@redhat.com> <20070215154919.84bd7c43.bugs.michael@gmx.net> Message-ID: <200702150951.40990.jkeating@redhat.com> On Thursday 15 February 2007 09:49, Michael Schwendt wrote: > So, the "upstream" rule here is violated. Instead, you want to change > thousands of spec files because of a theoretical problem that can only > affect users who don't set up a per user build environment on a multi-user > system? Loyalty finds an end here. The mktemp buildroot in spec files > would be really disappointing decision. > > $ rpm -qf /usr/lib/rpm/redhat/macros > redhat-rpm-config-8.0.45-6 > $ rpm --eval %_tmppath > /var/tmp > > could be modified more quickly than applying a bigger buildroot patch > to the code. Sure, that's an option. I think the mktemp based approach found some problems. We haven't ratified anything, we're open for discussion. I was perfectly happy with a rule of "Is there a BuildRoot defined, and it isn't /? Yes? PASS" however others within the Packaging Committee wanted to protect users against the scenarios you described. -- 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 caolanm at redhat.com Thu Feb 15 15:02:41 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 15 Feb 2007 15:02:41 +0000 Subject: Odd cvs-import.sh and make tag error In-Reply-To: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> References: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> Message-ID: <1171551761.4727.10.camel@soulcrusher.caolan.org> On Thu, 2007-02-15 at 15:44 +0100, Micha? Bentkowski wrote: > Hi! > Today I tried to import my package to repo. Cvs-import.sh returns some > odd errors, but it finished its job successfully so I wasn't concerned > about that. > However, `make tag` gives me identical errors i.e.: > > [ecik at ecik ~/cvs/sonata/devel]$ LANG=C make tag build > error: Unable to open emacs-nxml-mode: No such file or directory examine the devel/Makefile and see if the SPECFILE = foo is incorrect. C. From rc040203 at freenet.de Thu Feb 15 15:14:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Feb 2007 16:14:20 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215155212.51c14f30.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> <1171538666.20765.1.camel@mccallum.corsepiu.local> <20070215123410.7c040b02@python3.es.egwn.lan> <1171540287.20765.20.camel@mccallum.corsepiu.local> <20070215142136.GA25930@dudweiler.stuttgart.redhat.com> <20070215155212.51c14f30.bugs.michael@gmx.net> Message-ID: <1171552460.20765.112.camel@mccallum.corsepiu.local> On Thu, 2007-02-15 at 15:52 +0100, Michael Schwendt wrote: > On Thu, 15 Feb 2007 15:21:36 +0100, Florian La Roche wrote: > > > > Florian's remark was aiming at "ease of work". Helping him would be a > > > matter of very few hours to for a central admin. > > > > The cvs commit would be easy todo, question is if we then wait for new > > package builds to happen or if also a central person should kick of and > > monitor package rebuilds. > There are enough packaging issues, broken deps and bugs in Extras, do you > really think it would be highly important to submit unnecessary rebuilds You don't have to rebuild upon such a change. Simply commit a change to cvs. It would then be picked up during the next regular build spin Ralf From bugs.michael at gmx.net Thu Feb 15 15:18:32 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 16:18:32 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <200702150951.40990.jkeating@redhat.com> References: <1171068977.28153.9.camel@Chuck> <200702150930.10903.jkeating@redhat.com> <20070215154919.84bd7c43.bugs.michael@gmx.net> <200702150951.40990.jkeating@redhat.com> Message-ID: <20070215161832.2b40268c.bugs.michael@gmx.net> On Thu, 15 Feb 2007 09:51:40 -0500, Jesse Keating wrote: > I was perfectly happy with a rule of "Is there a BuildRoot defined, and it > isn't /? Yes? PASS" The RPM maintainer(s) can probably tell you since how long it has been impossible to build with BuildRoot='/' -- just try it with --buildroot=/ or a modified spec file. It is a fatal error. It is no theoretical threat anymore. Maybe somewhere on this world there really is somebody who has ever before done something stupid with such a buildroot definition. But it is terribly difficult to find such victims or even bug reports about it. During review, using --buildroot (or mock) is recommended anyway, since the default path may point to a place that is low on free space. /tmp versus /var/tmp versus %_tmppath. From bugs.michael at gmx.net Thu Feb 15 15:21:23 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 16:21:23 +0100 Subject: Odd cvs-import.sh and make tag error In-Reply-To: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> References: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> Message-ID: <20070215162123.56b01564.bugs.michael@gmx.net> On Thu, 15 Feb 2007 15:44:58 +0100, Micha? Bentkowski wrote: > Hi! > Today I tried to import my package to repo. Cvs-import.sh returns some > odd errors, but it finished its job successfully so I wasn't concerned > about that. > However, `make tag` gives me identical errors i.e.: > > [ecik at ecik ~/cvs/sonata/devel]$ LANG=C make tag build > error: Unable to open emacs-nxml-mode: No such file or directory Get Dennis Gilmore (ausil) to fix your devel/Makefile. From jkeating at redhat.com Thu Feb 15 15:22:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Feb 2007 10:22:59 -0500 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215161832.2b40268c.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <200702150951.40990.jkeating@redhat.com> <20070215161832.2b40268c.bugs.michael@gmx.net> Message-ID: <200702151022.59642.jkeating@redhat.com> On Thursday 15 February 2007 10:18, Michael Schwendt wrote: > The RPM maintainer(s) can probably tell you since how long it has been > impossible to build with BuildRoot='/' -- just try it with --buildroot=/ > or a modified spec file. It is a fatal error. It is no theoretical threat > anymore. Maybe somewhere on this world there really is somebody who has > ever before done something stupid with such a buildroot definition. But it > is terribly difficult to find such victims or even bug reports about it. I didn't state I looked for / as a protection item, I looked for / because I know rpm would never let that work, and the package would not build. > During review, using --buildroot (or mock) is recommended anyway, since > the default path may point to a place that is low on free space. /tmp > versus /var/tmp versus %_tmppath. yes, this is known. Again, the issue that was brought up to us was NOT the typical useage case of using mock or whatnot. -- 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 Thu Feb 15 15:30:32 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 16:30:32 +0100 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <200702151022.59642.jkeating@redhat.com> References: <1171068977.28153.9.camel@Chuck> <200702150951.40990.jkeating@redhat.com> <20070215161832.2b40268c.bugs.michael@gmx.net> <200702151022.59642.jkeating@redhat.com> Message-ID: <20070215163032.12ab5c2f.bugs.michael@gmx.net> On Thu, 15 Feb 2007 10:22:59 -0500, Jesse Keating wrote: > > The RPM maintainer(s) can probably tell you since how long it has been > > impossible to build with BuildRoot='/' -- just try it with --buildroot=/ > > or a modified spec file. It is a fatal error. It is no theoretical threat > > anymore. Maybe somewhere on this world there really is somebody who has > > ever before done something stupid with such a buildroot definition. But it > > is terribly difficult to find such victims or even bug reports about it. > > I didn't state I looked for / as a protection item, I looked for / because I > know rpm would never let that work, and the package would not build. The spec file would fail to build the src.rpm beforehand. ;o) Unless the packager used --buildroot to build it. Back to the drawing board... From dennis at ausil.us Thu Feb 15 15:32:54 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Feb 2007 09:32:54 -0600 Subject: Odd cvs-import.sh and make tag error In-Reply-To: <20070215162123.56b01564.bugs.michael@gmx.net> References: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> <20070215162123.56b01564.bugs.michael@gmx.net> Message-ID: <200702150932.54954.dennis@ausil.us> On Thursday 15 February 2007 09:21, Michael Schwendt wrote: > On Thu, 15 Feb 2007 15:44:58 +0100, Micha? Bentkowski wrote: > > Hi! > > Today I tried to import my package to repo. Cvs-import.sh returns some > > odd errors, but it finished its job successfully so I wasn't concerned > > about that. > > However, `make tag` gives me identical errors i.e.: > > > > [ecik at ecik ~/cvs/sonata/devel]$ LANG=C make tag build > > error: Unable to open emacs-nxml-mode: No such file or directory > > Get Dennis Gilmore (ausil) to fix your devel/Makefile. Fixed -- Dennis Gilmore, RHCE From mr.ecik at gmail.com Thu Feb 15 15:48:40 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Thu, 15 Feb 2007 16:48:40 +0100 Subject: Odd cvs-import.sh and make tag error In-Reply-To: <200702150932.54954.dennis@ausil.us> References: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> <20070215162123.56b01564.bugs.michael@gmx.net> <200702150932.54954.dennis@ausil.us> Message-ID: <668bb39a0702150748m7526aa97j6980e88fad047f3c@mail.gmail.com> FC-6 is still broken: [ecik at ecik ~/cvs/sonata/FC-6]$ LANG=C make tag rpmq: no arguments given for query rpmq: no arguments given for query cvs tag -c sonata-- -- Micha? Bentkowski mr.ecik at gmail.com From mr.ecik at gmail.com Thu Feb 15 15:53:25 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Thu, 15 Feb 2007 16:53:25 +0100 Subject: Odd cvs-import.sh and make tag error In-Reply-To: <668bb39a0702150748m7526aa97j6980e88fad047f3c@mail.gmail.com> References: <668bb39a0702150644h3f70fd6bu72cdb7d953f77f94@mail.gmail.com> <20070215162123.56b01564.bugs.michael@gmx.net> <200702150932.54954.dennis@ausil.us> <668bb39a0702150748m7526aa97j6980e88fad047f3c@mail.gmail.com> Message-ID: <668bb39a0702150753qf6275d2r75e8625042f4f8ae@mail.gmail.com> Oh, it looks like sonata.spec was absent in FC-6 directory. I added that and now it seems to work. 2007/2/15, Micha? Bentkowski : > FC-6 is still broken: > [ecik at ecik ~/cvs/sonata/FC-6]$ LANG=C make tag > rpmq: no arguments given for query > rpmq: no arguments given for query > cvs tag -c sonata-- > > -- > Micha? Bentkowski > mr.ecik at gmail.com > -- Micha? Bentkowski mr.ecik at gmail.com From tdiehl at rogueind.com Thu Feb 15 17:14:22 2007 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 15 Feb 2007 12:14:22 -0500 (EST) Subject: rpmlint question In-Reply-To: <20070215102029.4b318648.bugs.michael@gmx.net> References: <20070213171732.GB1373@nostromo.devel.redhat.com> <20070215102029.4b318648.bugs.michael@gmx.net> Message-ID: On Thu, 15 Feb 2007, Michael Schwendt wrote: > On Wed, 14 Feb 2007 16:03:12 -0500 (EST), Tom Diehl wrote: > >> It turns out that libdspam.so is not needed but there are subpackages >> that contain drivers for mysql and postgresql. If I pull the .so symlinks, >> I get the following error: >> >> [bullwinkle pts33]# dspam --daemon --debug >> 1312: [02/14/2007 15:46:54] dlopen() failed: /usr/lib/libmysql_drv.so: /usr/lib/libmysql_drv.so: cannot open shared object file: No such file or directory >> 1312: [02/14/2007 15:46:54] Unable to initialize storage driver >> [bullwinkle pts33]# >> >> Having said the above, there is a config file in dspam, that calls >> /usr/lib/libmysql_drv.so. If I change the config to /usr/lib/libmysql_drv.so.7 >> or /usr/lib/libmysql_drv.so.7.0.0 then the program runs and the driver loads. >> >> What is the correct way to handle this type of thing? > > Rule of thumb: don't touch it unless you know what you are doing. > >> In addition, if the right answer is to drop the *.so libs, am I really supposed >> to drop them or do they belong in the -devel package? >> >> Is there a doc for this somewhere? So far, I have not been able to find one. > > There used to be a paragraph somewhere in the Wiki, merged from fedora.us, > but I think it got obsoleted/dropped because it would be too confusing for > packaging newbies. The decision on what to do with *.so files is difficult. Like me!! :-) > Basically, you only need to know which libraries are needed at run-time > and which are needed at build-time only. Then you can include them in the > right packages. For ordinary libraries, which are correctly named, only > the *.so.* files are needed at run-time and the *.so symlink is only > needed during development. libfoo.so is what is needed for the linker > option -lfoo to succeed. > > In your example, however. the developers use dlopen() to load shared > libraries at run-time. The libraries are used like plugins. Is there an > API (in header files) for those plugin libraries? I do not think so. > The developers ought to move their plugins to a private directory and not > pollute /usr/lib. The chosen file names are very generic, too, since the > libraries can conflict with any other package, which would also include a > libmysql_drv.so.* Further, the developers ought to dlopen the versioned > libs rather than the non-versioned *.so and that is especially useful when > loading external libs (e.g. system libs). AAH!! This helps a lot. I think I am finally starting to understand this magic. So, if I understand you correctly, the right thing to do in this case, would be to get upstream to use /usr/lib/libmysql_drv.so.7 and put the *.so files in the -devel package. Is this correct? Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From chitlesh at fedoraproject.org Thu Feb 15 17:14:28 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 15 Feb 2007 18:14:28 +0100 Subject: Packaging KDE window decorations, etc In-Reply-To: References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> Message-ID: <13dbfe4f0702150914u25f2bd13o7385bf92a5d7059f@mail.gmail.com> On 2/15/07, Rex Dieter wrote: > Please simply upstream name, for now, at least until we come up with > something better. > > -- Rex +1 However there are 2 different situations - we can have lets say kwin-DECORATOR - otherwise, let it be as is, since people are using the "search" button just as you did Fran?ois. Hence we have to make sure that in the summary there is at least "KDE window decoration" Chitlesh -- http://clunixchit.blogspot.com From bugs.michael at gmx.net Thu Feb 15 19:15:59 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Feb 2007 20:15:59 +0100 Subject: rpmlint question In-Reply-To: References: <20070213171732.GB1373@nostromo.devel.redhat.com> <20070215102029.4b318648.bugs.michael@gmx.net> Message-ID: <20070215201559.db734281.bugs.michael@gmx.net> On Thu, 15 Feb 2007 12:14:22 -0500 (EST), Tom Diehl wrote: > > The developers ought to move their plugins to a private directory and not > > pollute /usr/lib. The chosen file names are very generic, too, since the > > libraries can conflict with any other package, which would also include a > > libmysql_drv.so.* Further, the developers ought to dlopen the versioned > > libs rather than the non-versioned *.so and that is especially useful when > > loading external libs (e.g. system libs). > > AAH!! This helps a lot. I think I am finally starting to understand this magic. > > So, if I understand you correctly, the right thing to do in this case, would > be to get upstream to use /usr/lib/libmysql_drv.so.7 and put the *.so files in > the -devel package. > > Is this correct? More like: * if these libraries are supposed to be plugins, the developers should move them to /usr/lib/dspam/ and dlopen them from there via *.so.* or *.so (they have all the freedom, the private plugin directory can contain all files - if the plugins are built together with the main application, dlopening *.so from a private directory would be fine) * if they want to keep them in /usr/lib as plugin libs to coexist with system libraries, the developers are strongly encouraged to give them names in an own namespace, which is less likely to conflict with other packages or libs, e.g. /usr/lib/libdspam_mysql_drv.so* or /usr/lib/libdspam_mysql.so* * if these libs can be linked with (or dlopenend from) other programs through a public API (with corresponding include files) just like system libraries, the developers ought to separate what is needed at run-time for dynamic linking (versioned *.so.* libs) and what is needed at build-time only (the *.so symlinks) - that would make it possible to split off the development files (headers and *.so symlink e.g.) into the separate -devel package and possible even the libs into a separate -libs package - external programs, which would link against these libs, would have automatic RPM dependencies on the exact library names, e.g. an implicit "Requires: libdspam_mysql_drv.so.7" - the developers, if they continue loading the libs as plugins, should prefer the versioned *.so.* names, too, because changing the library name and version would break dependencies and because the *.so symlink of system libraries is only to be used during development From opensource at till.name Thu Feb 15 19:15:18 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 20:15:18 +0100 Subject: Using mock with gpgcheck=1 Message-ID: <200702152015.32399.opensource@till.name> Hiyas, how can I use mock with gpgcheck enabled to build packages. When I enable it, mock exits with these lines in root.log: warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Public key for glibc-devel-2.4-11.i386.rpm is not installed So somehow I need to install the gpgkeys in the rpm database that is used inside the buildroot, but how? 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 skvidal at linux.duke.edu Thu Feb 15 19:30:14 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 14:30:14 -0500 Subject: Using mock with gpgcheck=1 In-Reply-To: <200702152015.32399.opensource@till.name> References: <200702152015.32399.opensource@till.name> Message-ID: <1171567814.25527.16.camel@cutter> On Thu, 2007-02-15 at 20:15 +0100, Till Maas wrote: > Hiyas, > > how can I use mock with gpgcheck enabled to build packages. When I enable it, > mock exits with these lines in root.log: > > warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 > Public key for glibc-devel-2.4-11.i386.rpm is not installed > > So somehow I need to install the gpgkeys in the rpm database that is used > inside the buildroot, but how? set gpgkey=url:/to/key in the mock.cfg for each repo stanza -sv From opensource at till.name Thu Feb 15 19:36:07 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 20:36:07 +0100 Subject: Using mock with gpgcheck=1 In-Reply-To: <1171567814.25527.16.camel@cutter> References: <200702152015.32399.opensource@till.name> <1171567814.25527.16.camel@cutter> Message-ID: <200702152036.20707.opensource@till.name> On Donnerstag 15 Februar 2007, seth vidal wrote: > set gpgkey=url:/to/key in the mock.cfg for each repo stanza Thank you very muck, do they need to be ftp/http URLs or work file:// URLs that point outside of /var/lib/mock/ there, 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 skvidal at linux.duke.edu Thu Feb 15 19:43:34 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 15 Feb 2007 14:43:34 -0500 Subject: Using mock with gpgcheck=1 In-Reply-To: <200702152036.20707.opensource@till.name> References: <200702152015.32399.opensource@till.name> <1171567814.25527.16.camel@cutter> <200702152036.20707.opensource@till.name> Message-ID: <1171568614.25527.18.camel@cutter> On Thu, 2007-02-15 at 20:36 +0100, Till Maas wrote: > On Donnerstag 15 Februar 2007, seth vidal wrote: > > > set gpgkey=url:/to/key in the mock.cfg for each repo stanza > > Thank you very muck, do they need to be ftp/http URLs or work file:// URLs > that point outside of /var/lib/mock/ there, too? > file urls should work, iirc. though I don't know if I've actually tested that recently. -sv From ville.skytta at iki.fi Thu Feb 15 20:55:56 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 15 Feb 2007 22:55:56 +0200 Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215130042.919c0bab.bugs.michael@gmx.net> References: <1171068977.28153.9.camel@Chuck> <1171538476.3324.12.camel@shalil.farsiweb.info> <20070215130042.919c0bab.bugs.michael@gmx.net> Message-ID: <200702152255.56639.ville.skytta@iki.fi> On Thursday 15 February 2007, Michael Schwendt wrote: > On Thu, 15 Feb 2007 14:51:16 +0330, Roozbeh Pournader wrote: > > On Thu, 2007-02-15 at 11:48 +0100, Michael Schwendt wrote: > > > As soon as you set up a > > > local ~/.rpmmacros, you can define %_buildroot and point it to > > > a private location. Problem solved. > > > > Sure you can, but we had kept to the rpmdev-setuptree (used to be called > > fedora-something then) defaults, which doesn't define a buildroot, but > > only the very basics. > > It doesn't define a buildroot at all, and that is a problem in the script. Disagreed. In fact, I think it's the opposite. As long as there's no sane buildroot in the vanilla system rpmbuild setup, any tool, for example mock, that defines it is potentially brushing problems under the carpet. If the macros file emitted by that script or mock defines a buildroot and the vanilla system rpmbuild does not, it will make it easier for packages without any buildroot set to slip into the repositories. And on systems that don't have a default buildroot set, that will result in either failing builds as non-root users (even if otherwise properly set up for those users), or that plus a mess if someone is crazy/unlucky enough to try building such packages as root. From opensource at till.name Thu Feb 15 22:30:22 2007 From: opensource at till.name (Till Maas) Date: Thu, 15 Feb 2007 23:30:22 +0100 Subject: Using mock with gpgcheck=1 In-Reply-To: <1171568614.25527.18.camel@cutter> References: <200702152015.32399.opensource@till.name> <200702152036.20707.opensource@till.name> <1171568614.25527.18.camel@cutter> Message-ID: <200702152330.36777.opensource@till.name> On Donnerstag 15 Februar 2007, seth vidal wrote: > file urls should work, iirc. though I don't know if I've actually tested > that recently. It seems to work, but the packages from http://buildsys.fedoraproject.org/buildgroups/5/i386/ are not signed. I opened an infrastructure ticket for this, I hope that is the correct place to ask. 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 jeff at ocjtech.us Thu Feb 15 23:38:27 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 15 Feb 2007 17:38:27 -0600 Subject: Using mock with gpgcheck=1 In-Reply-To: <200702152330.36777.opensource@till.name> References: <200702152015.32399.opensource@till.name> <200702152036.20707.opensource@till.name> <1171568614.25527.18.camel@cutter> <200702152330.36777.opensource@till.name> Message-ID: <1171582707.3638.4.camel@lt21223.campus.dmacc.edu> On Thu, 2007-02-15 at 23:30 +0100, Till Maas wrote: > On Donnerstag 15 Februar 2007, seth vidal wrote: > > > file urls should work, iirc. though I don't know if I've actually tested > > that recently. > > It seems to work, but the packages from > http://buildsys.fedoraproject.org/buildgroups/5/i386/ are not signed. I > opened an infrastructure ticket for this, I hope that is the correct place to > ask. You should be able to set gpgcheck on individual repositories - seting gpgcheck=0 on the 'groups' repo should bypass the GPG check for that repo. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Thu Feb 15 23:43:18 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 15 Feb 2007 17:43:18 -0600 Subject: Packaging KDE window decorations, etc In-Reply-To: References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> Message-ID: <16de708d0702151543u820a2dcqb88636cc98a054d3@mail.gmail.com> On 2/15/07, Rex Dieter wrote: > Francois Aucamp wrote: > > > I want to package/import a few window decorations and styles for KDE, > > and would like to know the following: > > > > How should these types of packages be named? > ... > > Please advise? > > Please simply upstream name, for now, at least until we come up with > something better. > > -- Rex I too would like to do something similar (as soon as I find a way to extend 24hours). Might I suggest the following format? kde-- I would suggest using the categories used by KDE-look.org. This will make a `yum list` more useful. -- Fedora Core 6 and proud From opensource at till.name Fri Feb 16 00:22:58 2007 From: opensource at till.name (Till Maas) Date: Fri, 16 Feb 2007 01:22:58 +0100 Subject: Using mock with gpgcheck=1 In-Reply-To: <1171582707.3638.4.camel@lt21223.campus.dmacc.edu> References: <200702152015.32399.opensource@till.name> <200702152330.36777.opensource@till.name> <1171582707.3638.4.camel@lt21223.campus.dmacc.edu> Message-ID: <200702160123.05743.opensource@till.name> On Freitag 16 Februar 2007, Jeffrey C. Ollie wrote: > You should be able to set gpgcheck on individual repositories - seting > gpgcheck=0 on the 'groups' repo should bypass the GPG check for that > repo. Thanks, but I want to enable gpgcheck=1 for all repositories because I do not want to test only, whether or not the package builds but also want to install/run the desired package. Using gpgcheck=0 for an external repository is therefore not an option. The reason I need to use mock to build a package is, that I want to test the package on a FC5 machine, but my development machine runs FC6. 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 faucamp at csir.co.za Fri Feb 16 07:14:47 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Fri, 16 Feb 2007 09:14:47 +0200 Subject: Packaging KDE window decorations, etc In-Reply-To: <45D576070200006A0000FF06@cs-emo.csir.co.za> References: <45D4B14B020000D200007E0D@cs-emo.csir.co.za> <45D576070200006A0000FF06@cs-emo.csir.co.za> Message-ID: <45D576070200006A0000FF06@cs-emo.csir.co.za> On Thu, 2007-02-15 at 18:14 +0100, Chitlesh GOORAH wrote: > However there are 2 different situations > - we can have lets say kwin-DECORATOR > - otherwise, let it be as is, since people are using the "search" > button just as you did Fran?ois. Hence we have to make sure that in > the summary there is at least "KDE window decoration" Using an appropriate summary is fine, but my concern is that it still doesn't solve potential package naming clashes (where the KDE theme/deco is a port of a Gnome one, or the other way around). Also, searching for something like "decoration" turns up quite a lot more than just themes, and "KDE decoration" is much worse; I actually found the crystal theme by filtering the "User Interface/Desktops" RPM group entries (something that is frowned upon by yum, it seems ;-) )... On Thu, 2007-02-15 at 17:43 -0600, Arthur Pemberton wrote: > I would suggest using the categories used by KDE-look.org. This will > make a `yum list` more useful. I agree 100% with the "yum list" part, but KDE-look's default category names are maybe a bit long..? For now, I will follow the advice of Rex and Chitlesh, though. Thanks for the help, guys! Cheers, -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From pmatilai at laiskiainen.org Fri Feb 16 07:49:16 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 16 Feb 2007 09:49:16 +0200 (EET) Subject: FESCo Meeting Summary for 2007-02-08 In-Reply-To: <20070215123410.7c040b02@python3.es.egwn.lan> References: <1171068977.28153.9.camel@Chuck> <200702141230.16529.jkeating@redhat.com> <20070214185527.75e510cb@python3.es.egwn.lan> <200702141408.44834.jkeating@redhat.com> <20070215120142.1a97aa07@python3.es.egwn.lan> <20070215110637.GB23277@dudweiler.stuttgart.redhat.com> <1171538666.20765.1.camel@mccallum.corsepiu.local> <20070215123410.7c040b02@python3.es.egwn.lan> Message-ID: On Thu, 15 Feb 2007, Matthias Saou wrote: > Ralf Corsepius wrote : > >> On Thu, 2007-02-15 at 12:06 +0100, Florian La Roche wrote: >>>> My packages under review are currently blocked because of this useless >>>> guideline change :-( >>> >>> I don't think it makes sense to block reviews for the BuildRoot >>> settings. We have enough other things to look at... >> >> Why isn't anybody at redhat able to run a sed script over all *.spec >> and thereby closing this case for all packages at once? > > Because we might want to do that only once, if/when we find a better > Buildroot value? Somebody suggested doing something like this in specs: BuildRoot: %{rpmbuildroot} ..and make that mandatory. Put out a new version of redhat-rpm-config with that defined to use whatever uid-arch-mktempd-junk people see necessary. If I want to have consistent buildroots, I redefine that macro locally, otherwise it'll just work. And it's a single sed-job that only needs to be done once. I'd still prefer being able ditch this useless junk from every spec (Matthias had various other items on the hitlist) completely, but the above is far better than this endless arguing (and for heavens sake, blocking packages) based on something that's completely irrelevant to the buildsystem. - Panu - From pemboa at gmail.com Fri Feb 16 08:20:33 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 17 Feb 2007 02:20:33 +1800 Subject: Packaging KDE window decorations, etc In-Reply-To: <45D576070200006A0000FF06@cs-emo.csir.co.za> References: <45D4B14B020000D200007E0D@cs-emo.csir.co.za> <45D576070200006A0000FF06@cs-emo.csir.co.za> <45D576070200006A0000FF06@cs-emo.csir.co.za> Message-ID: <16de708d0702160020w198fda64kc3997a7e03662894@mail.gmail.com> On 2/17/07, Francois Aucamp wrote: > On Thu, 2007-02-15 at 18:14 +0100, Chitlesh GOORAH wrote: > > However there are 2 different situations > > - we can have lets say kwin-DECORATOR > > - otherwise, let it be as is, since people are using the "search" > > button just as you did Fran?ois. Hence we have to make sure that in > > the summary there is at least "KDE window decoration" > > Using an appropriate summary is fine, but my concern is that it still > doesn't solve potential package naming clashes (where the KDE theme/deco > is a port of a Gnome one, or the other way around). Also, searching for > something like "decoration" turns up quite a lot more than just themes, > and "KDE decoration" is much worse; I actually found the crystal theme > by filtering the "User Interface/Desktops" RPM group entries (something > that is frowned upon by yum, it seems ;-) )... > > On Thu, 2007-02-15 at 17:43 -0600, Arthur Pemberton wrote: > > I would suggest using the categories used by KDE-look.org. This will > > make a `yum list` more useful. > > I agree 100% with the "yum list" part, but KDE-look's default category > names are maybe a bit long..? > > For now, I will follow the advice of Rex and Chitlesh, though. Thanks > for the help, guys! > > Cheers, > -Francois > I agree with following their advice. I disagree that those names are too long. Descriptiveness is more important than length. > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Fedora Core 6 and proud From seg at haxxed.com Fri Feb 16 09:35:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 16 Feb 2007 03:35:31 -0600 Subject: Second Life client packaged for Fedora Message-ID: <1171618531.2953.14.camel@localhost.localdomain> Okay, after much pain, sorrow and apparently duplicated effort[*] I finally managed to get a vaguely usable Second Life package + deps: http://www.haxxed.com/rpms/secondlife/ * spot has some packages too: http://www.auroralinux.org/people/spot/SecondLife/ Don't expect his and mine to be interchangeable just yet. I guess we have some merging to do... -------------- 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 Fri Feb 16 11:57:06 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 16 Feb 2007 06:57:06 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-16 Message-ID: <20070216115706.953BB15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 39 PyKDE-3.16.0-6.fc7 akode-2.0.1-6.fc7 amarok-1.4.5-3.fc7 autogen-5.8.9-1.fc7 easytag-1.99.13-2.fc7 NEW gmrun-0.9.2-7.fc7 graveman-0.3.12.5-4.fc7 NEW hunspell-lt-1.1-1.20061127cvs.fc7 NEW hunspell-nb-0.20060508-1.fc7 NEW hunspell-nl-0.20050720-1.fc7 NEW hunspell-nn-0.20060508-1.fc7 NEW hunspell-pl-0.20070214-1.fc7 NEW hunspell-pt-0.20061026-2.fc7 NEW hunspell-ru-0.20040406-1.fc7 NEW hunspell-sk-0.20050911-1.fc7 NEW hunspell-sl-0.20070127-1.fc7 NEW hunspell-sv-1.3.8.6-1.fc7 NEW hunspell-zu-0.20060120-1.fc7 NEW icewm-1.2.30-12.fc7 jd-1.8.5-2.cvs070215.fc7 kdemultimedia-extras-3.5.6-4.fc7 libdnet-1.12-1.fc7 libsx-2.05-12.fc7 lilypond-2.10.17-1.fc7 lyx-1.4.4-2.fc7 mkvtoolnix-2.0.0-1.fc7 mono-debugger-0.31-1.fc7 monodoc-1.2.3-1.fc7 perl-B-Keywords-1.06-1.fc7 perl-Locale-Maketext-Lexicon-0.62-1.fc7 perl-Perl-Critic-1.03-1.fc7 perl-Test-ClassAPI-1.03-1.fc7 perl-Text-Quoted-1.10-1.fc7 pungi-0.2.4-1.fc7 scummvm-0.9.1-3.fc7 NEW sonata-1.0.1-2.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2930.fc7 wings-0.98.32b-11.fc7 xmms-flac-1.1.4-1.fc7 Packages built and released for Fedora Extras 6: 14 audacity-1.3.2-6.fc6 NEW fedora-ds-1.1.0-0.1.20070213.fc6 NEW gmrun-0.9.2-7.fc6 gnu-smalltalk-2.3.3-3.fc6 NEW icewm-1.2.30-12.fc6 lilypond-2.10.17-1.fc6 perl-B-Keywords-1.06-1.fc6 perl-Locale-Maketext-Lexicon-0.62-1.fc6 perl-Perl-Critic-1.03-1.fc6 perl-Test-ClassAPI-1.03-1.fc6 perl-Text-Quoted-1.10-1.fc6 seedit-2.1.0-5.fc6 NEW tilda-0.9.4-6.fc6 wings-0.98.32b-11.fc6 Packages built and released for Fedora Extras 5: 9 NEW etherape-0.9.7-4.1.fc5 NEW gmrun-0.9.2-7.fc5 gtk2hs-0.9.10-3.fc5 NEW icewm-1.2.30-12.fc5 perl-B-Keywords-1.06-1.fc5 perl-Locale-Maketext-Lexicon-0.62-1.fc5 perl-Perl-Critic-1.03-1.fc5 perl-Test-ClassAPI-1.03-1.fc5 perl-Text-Quoted-1.10-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Fri Feb 16 13:02:34 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Feb 2007 07:02:34 -0600 Subject: Packaging KDE window decorations, etc References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> <16de708d0702151543u820a2dcqb88636cc98a054d3@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > I too would like to do something similar (as soon as I find a way to > extend 24hours). > > Might I suggest the following format? > kde-- > > I would suggest using the categories used by KDE-look.org. This will > make a `yum list` more useful. Willing to writup a proposal and stuff it in the wiki under http://fedoraproject.org/wiki/PackagingDrafts/ somewhere? (: -- Rex From rdieter at math.unl.edu Fri Feb 16 13:05:09 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Feb 2007 07:05:09 -0600 Subject: Packaging KDE window decorations, etc References: <45D4B14B020000D200007E0D@cs-emo.csir.co.za> <45D576070200006A0000FF06@cs-emo.csir.co.za> Message-ID: Francois Aucamp wrote: > On Thu, 2007-02-15 at 18:14 +0100, Chitlesh GOORAH wrote: >> However there are 2 different situations >> - we can have lets say kwin-DECORATOR >> - otherwise, let it be as is, since people are using the "search" >> button just as you did Fran?ois. Hence we have to make sure that in >> the summary there is at least "KDE window decoration" > > Using an appropriate summary is fine, but my concern is that it still > doesn't solve potential package naming clashes (where the KDE theme/deco > is a port of a Gnome one, or the other way around). How about not inventing problems that don't actually exist yet? (: I think I like Arthur's suggestion of using kde-look categories, but such a proposal will take time to flesh out, and you need not wait on that to start packaging stuff now, imo. -- Rex From j.w.r.degoede at hhs.nl Fri Feb 16 13:13:11 2007 From: j.w.r.degoede at hhs.nl (Goede, J.W.R. de) Date: Fri, 16 Feb 2007 14:13:11 +0100 Subject: Ogre update breaking soname headsup Message-ID: Hi All, I've just requested the build of ogre-1.2.5, as usual with a new ogre upstream release this release breaks then ABI so all ogre using packages must be rebuild. AFAIK only chess uses ogre and I'll take care of that myself. Because of the ABI breaking nature of this update I'm only building this for devel. Regards, Hans From pemboa at gmail.com Fri Feb 16 14:10:52 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 17 Feb 2007 08:10:52 +1800 Subject: Packaging KDE window decorations, etc In-Reply-To: References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> <16de708d0702151543u820a2dcqb88636cc98a054d3@mail.gmail.com> Message-ID: <16de708d0702160610o1c40f4b9j84ba9d0ddb183cc1@mail.gmail.com> On 2/17/07, Rex Dieter wrote: > Arthur Pemberton wrote: > > > I too would like to do something similar (as soon as I find a way to > > extend 24hours). > > > > Might I suggest the following format? > > kde-- > > > > I would suggest using the categories used by KDE-look.org. This will > > make a `yum list` more useful. > > Willing to writup a proposal and stuff it in the wiki under > http://fedoraproject.org/wiki/PackagingDrafts/ > somewhere? (: > > -- Rex Is there a proposal skeleton, or recommended examoke? I believe I still have wiki priviledges and can attempt to write up a proposal - it is the least I can do having opened my big mouth, Arthur Pemberton -- Fedora Core 6 and proud From rdieter at math.unl.edu Fri Feb 16 14:23:26 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Feb 2007 08:23:26 -0600 Subject: Packaging KDE window decorations, etc References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> <16de708d0702151543u820a2dcqb88636cc98a054d3@mail.gmail.com> <16de708d0702160610o1c40f4b9j84ba9d0ddb183cc1@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > On 2/17/07, Rex Dieter > wrote: >> Arthur Pemberton wrote: >> > Might I suggest the following format? >> > kde-- >> > >> > I would suggest using the categories used by KDE-look.org. This will >> > make a `yum list` more useful. >> >> Willing to writup a proposal and stuff it in the wiki under >> http://fedoraproject.org/wiki/PackagingDrafts/ >> somewhere? (: > Is there a proposal skeleton, or recommended examoke? Not that I'm aware of. > I believe I > still have wiki priviledges and can attempt to write up a proposal - > it is the least I can do having opened my big mouth, That's the spirit! (: ll make sure give it more love after you have an initial proposal done. -- Rex From faucamp at csir.co.za Fri Feb 16 15:36:16 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Fri, 16 Feb 2007 17:36:16 +0200 Subject: Packaging KDE window decorations, etc In-Reply-To: <45D5EB900200006A000100B2@cs-emo.csir.co.za> References: <45D5C96C020000F70000872B@cs-emo.csir.co.za> <45D5EB900200006A000100B2@cs-emo.csir.co.za> Message-ID: <45D5EB900200006A000100B2@cs-emo.csir.co.za> On Fri, 2007-02-16 at 07:05 -0600, Rex Dieter wrote: > How about not inventing problems that don't actually exist yet? (: :-) Fair enough, my intention was not to complain about as-yet nonexistent problems... but prevention is always better than a cure, its a simple management principle, even - look at the discussion on the RPM buildroot problem as an example of the type of thing that *could* happen. > I think I like Arthur's suggestion of using kde-look categories, but such a > proposal will take time to flesh out, and you need not wait on that to > start packaging stuff now, imo. Thanks, I won't. I'm also more than willing (and keen) to help Arthur out on the proposal, so please let me know if I can help you! Cheers and thanks for the feedback, -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dan at danny.cz Fri Feb 16 23:15:34 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 17 Feb 2007 00:15:34 +0100 Subject: UltimateStunts packaged but problems with sound Message-ID: <1171667734.332.21.camel@eagle.danny.cz> Hello, I have prepared a package with UltimateStunts - a remake of famous DOS game called Stunts (http://www.ultimatestunts.nl/index.php?page=0&lang=en). Only the spec file is available at http://fedora.danny.cz/ultimatestunts.spec , srpm will be uploaded later due some problems with my Internet connection. Everything looks good - it is under GPL, it compiles on FC6/x86_64 and in mock for Development/i386, tools can be run etc. But the game itself has some problem with loading sounds in wav files via the OpenAL/ALUT libraries. If there is anybody familiar with these sound libraries, please take a look. The errors are here: ---Sound data Loading file cars/generic/engine.wav Failed to load /home/dan/devel/share/ultimatestunts/cars/generic/engine.wav ALUT error was: There was already an AL error on entry to an ALUT function Loading file cars/generic/skid.wav Failed to load /home/dan/devel/share/ultimatestunts/cars/generic/skid.wav ALUT error was: There was already an AL error on entry to an ALUT function Loading file cars/generic/crash_nonfatal.wav Failed to load /home/dan/devel/share/ultimatestunts/cars/generic/crash_nonfatal.wav ALUT error was: There was already an AL error on entry to an ALUT function Errror in CDataManager::getObject (shared/datamanager.cpp): Object requested with ID 0, but there are only 0 objects of type 9 (Sample) Neopr?vn?n? p??stup do pam?ti (SIGSEGV) After reading forums, googling etc. my opinion is that there is some incompatibility with the CVS snapshot version of OpenAL from Fedora (Extras) and some previous version which is used by upstream. Thanks, Dan From pertusus at free.fr Sat Feb 17 09:30:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 17 Feb 2007 10:30:55 +0100 Subject: UltimateStunts packaged but problems with sound In-Reply-To: <1171667734.332.21.camel@eagle.danny.cz> References: <1171667734.332.21.camel@eagle.danny.cz> Message-ID: <20070217093055.GA2806@free.fr> On Sat, Feb 17, 2007 at 12:15:34AM +0100, Dan Hor?k wrote: > Hello, > > I have prepared a package with UltimateStunts - a remake of famous DOS > game called Stunts There is a potential trademark issue since the game use in its name part of a game that was published. I don't know if it is a real issue, though. -- Pat From buildsys at fedoraproject.org Sat Feb 17 12:10:52 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 17 Feb 2007 07:10:52 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-17 Message-ID: <20070217121052.ECF7815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 18 basket-1.0-2.fc7 chess-1.0-5.fc7 dvdisaster-0.70.4-1.fc7 environment-modules-3.2.5-1.fc7 gcstar-1.1.1-1.fc7 gossip-0.22-2.fc7 jd-1.8.5-2.cvs070216.fc7 kchmviewer-2.7-2.fc7 libupnp-1.4.2-1.fc7 mod_fcgid-2.1-1.fc7 mono-debugger-0.31-2.fc7 ogre-1.2.5-1.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 tcldom-3.1-9.fc7 tcllib-1.9-3.fc7 tclsoap-1.6.7-4.fc7 wine-docs-0.9.31-1.fc7 yumex-1.9.3-1.0.fc7 Packages built and released for Fedora Extras 6: 9 basket-1.0-2.fc6 dvdisaster-0.70.4-1.fc6 gcstar-1.1.1-1.fc6 kchmviewer-2.7-2.fc6 libupnp-1.4.2-1.fc6 lyx-1.4.4-2.fc6 mod_fcgid-2.1-1.fc6 (!) mono-debugger-0.30-7.fc7 : INVALID rebuild, not published! wine-docs-0.9.31-1.fc6 Packages built and released for Fedora Extras 5: 7 dvdisaster-0.70.4-1.fc5 gcstar-1.1.1-1.fc5 libupnp-1.4.2-1.fc5 lilypond-2.10.17-2.fc5 lyx-1.4.4-2.fc5 mod_fcgid-2.1-1.fc5 wine-docs-0.9.31-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 17 13:06:48 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 17 Feb 2007 13:06:48 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-17 Message-ID: <20070217130648.20104.7196@extras64.linux.duke.edu> New report for: oliver AT linux-kernel.at package: syck-php - 0.55-13.fc7.i386 from fedora-extras-development-i386 unresolved deps: php = 0:5.2.0 package: syck-php - 0.55-13.fc7.ppc from fedora-extras-development-ppc unresolved deps: php = 0:5.2.0 package: syck-php - 0.55-13.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: php = 0:5.2.0 ====================================================================== New report for: rdieter AT math.unl.edu package: k3b-extras - 0.12.17-1.fc6.i386 from fedora-extras-development-i386 unresolved deps: libk3bdevice.so.2 libk3b.so.2 package: k3b-extras - 0.12.17-1.fc6.ppc from fedora-extras-development-ppc unresolved deps: libk3b.so.2 libk3bdevice.so.2 package: k3b-extras - 0.12.17-1.fc6.x86_64 from fedora-extras-development-x86_64 unresolved deps: libk3b.so.2()(64bit) libk3bdevice.so.2()(64bit) ====================================================================== New report for: matthias AT rpmforge.net package: php-eaccelerator - 5.2.0_0.9.5-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: php-common = 0:5.2.0 package: php-eaccelerator - 5.2.0_0.9.5-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: php-common = 0:5.2.0 package: php-eaccelerator - 5.2.0_0.9.5-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: php-common = 0:5.2.0 ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (8 days) libetpan - 0.49-1.fc7.i386 (8 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (8 days) cgoorah AT yahoo.com.au irsim - 9.7.41-5.fc7.i386 (3 days) irsim - 9.7.41-5.fc7.ppc (3 days) toped - 0.8.2-2.fc6.i386 (64 days) toped - 0.8.2-2.fc6.ppc (64 days) toped - 0.8.2-2.fc6.x86_64 (64 days) xcircuit - 3.4.26-18.fc7.i386 (3 days) xcircuit - 3.4.26-18.fc7.ppc (3 days) xcircuit - 3.4.26-18.fc7.x86_64 (3 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (71 days) csound - 5.03.0-9.fc7.i386 (71 days) csound - 5.03.0-9.fc7.ppc (71 days) csound - 5.03.0-9.fc7.x86_64 (71 days) csound-python - 5.03.0-9.fc7.i386 (71 days) csound-python - 5.03.0-9.fc7.ppc (71 days) csound-python - 5.03.0-9.fc7.x86_64 (71 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (73 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (73 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (73 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (73 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (73 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (73 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (73 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (71 days) foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (2 days) flac123 - 0.0.9-1.fc7.ppc (2 days) flac123 - 0.0.9-1.fc7.x86_64 (2 days) muine - 0.8.7-1.fc7.i386 (2 days) muine - 0.8.7-1.fc7.i386 (2 days) muine - 0.8.7-1.fc7.ppc (2 days) muine - 0.8.7-1.fc7.x86_64 (2 days) gemi AT bluewin.ch audacity - 1.3.2-7.20070106cvs.fc7.i386 (2 days) audacity - 1.3.2-7.20070106cvs.fc7.ppc (2 days) audacity - 1.3.2-7.20070106cvs.fc7.x86_64 (2 days) skencil - 0.6.17-12.fc7.i386 (3 days) skencil - 0.6.17-12.fc7.ppc (3 days) skencil - 0.6.17-12.fc7.x86_64 (3 days) green AT redhat.com vkeybd - 0.1.17a-2.fc7.i386 (3 days) vkeybd - 0.1.17a-2.fc7.ppc (3 days) vkeybd - 0.1.17a-2.fc7.x86_64 (3 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (68 days) libreadline-java - 0.8.0-13.fc6.i386 (68 days) libreadline-java - 0.8.0-13.fc6.ppc (68 days) libreadline-java - 0.8.0-13.fc6.x86_64 (68 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (131 days) linphone - 1.2.0-4.fc5.ppc (131 days) linphone - 1.2.0-4.fc5.x86_64 (131 days) lmacken AT redhat.com python-cherrypy - 2.2.1-3.fc6.noarch (71 days) python-cherrypy - 2.2.1-3.fc6.noarch (71 days) python-cherrypy - 2.2.1-3.fc6.noarch (71 days) matthias AT rpmforge.net php-eaccelerator - 5.2.0_0.9.5-2.fc7.i386 php-eaccelerator - 5.2.0_0.9.5-2.fc7.ppc php-eaccelerator - 5.2.0_0.9.5-2.fc7.x86_64 oliver AT linux-kernel.at syck-php - 0.55-13.fc7.i386 syck-php - 0.55-13.fc7.ppc syck-php - 0.55-13.fc7.x86_64 orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (71 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (71 days) paul AT xelerance.com hping3 - 0.0.20051105-6.fc7.i386 (3 days) hping3 - 0.0.20051105-6.fc7.ppc (3 days) hping3 - 0.0.20051105-6.fc7.x86_64 (3 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 k3b-extras - 0.12.17-1.fc6.ppc k3b-extras - 0.12.17-1.fc6.x86_64 redhat-bugzilla AT camperquake.de audacious-plugins - 1.2.5-3.fc7.i386 (2 days) audacious-plugins - 1.2.5-3.fc7.i386 (2 days) audacious-plugins - 1.2.5-3.fc7.ppc (2 days) audacious-plugins - 1.2.5-3.fc7.x86_64 (2 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (71 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 (3 days) xpa - 2.1.6-8.fc7.i386 (3 days) xpa - 2.1.6-8.fc7.ppc (3 days) xpa - 2.1.6-8.fc7.x86_64 (3 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (71 days) xmldiff - 0.6.7-12.fc6.ppc (71 days) xmldiff - 0.6.7-12.fc6.x86_64 (71 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 (3 days) R - 2.4.1-2.fc7.i386 (3 days) R - 2.4.1-2.fc7.ppc (3 days) R - 2.4.1-2.fc7.x86_64 (3 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 (3 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 (3 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc (3 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (3 days) kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 (3 days) kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (3 days) kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc (3 days) ====================================================================== Broken packages in fedora-extras-5-i386: linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so audacious-plugins-1.2.5-3.fc7.i386 requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC++.so.5 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.i386 requires libtcl8.5.so irsim-9.7.41-5.fc7.i386 requires libtk8.5.so irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 php-eaccelerator-5.2.0_0.9.5-2.fc7.i386 requires php-common = 0:5.2.0 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 skencil-0.6.17-12.fc7.i386 requires libtk8.5.so skencil-0.6.17-12.fc7.i386 requires libtcl8.5.so syck-php-0.55-13.fc7.i386 requires php = 0:5.2.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 vkeybd-0.1.17a-2.fc7.i386 requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.i386 requires tk < 0:8.6 vkeybd-0.1.17a-2.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-ppc: R-2.4.1-2.fc7.ppc requires libtk8.5.so R-2.4.1-2.fc7.ppc requires libtcl8.5.so audacious-plugins-1.2.5-3.fc7.ppc requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC++.so.5 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.ppc requires libtcl8.5.so irsim-9.7.41-5.fc7.ppc requires libtk8.5.so irsim-9.7.41-5.fc7.ppc requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 muine-0.8.7-1.fc7.ppc requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 php-eaccelerator-5.2.0_0.9.5-2.fc7.ppc requires php-common = 0:5.2.0 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 skencil-0.6.17-12.fc7.ppc requires libtk8.5.so skencil-0.6.17-12.fc7.ppc requires libtcl8.5.so syck-php-0.55-13.fc7.ppc requires php = 0:5.2.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 vkeybd-0.1.17a-2.fc7.ppc requires libtk8.5.so vkeybd-0.1.17a-2.fc7.ppc requires libtcl8.5.so vkeybd-0.1.17a-2.fc7.ppc requires tk < 0:8.6 xcircuit-3.4.26-18.fc7.ppc requires libtk8.5.so xcircuit-3.4.26-18.fc7.ppc requires libtcl8.5.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.ppc requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-x86_64: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so R-2.4.1-2.fc7.x86_64 requires libtcl8.5.so()(64bit) R-2.4.1-2.fc7.x86_64 requires libtk8.5.so()(64bit) audacious-plugins-1.2.5-3.fc7.i386 requires libFLAC.so.7 audacious-plugins-1.2.5-3.fc7.x86_64 requires libFLAC.so.7()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC++.so.5()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC.so.7()(64bit) claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) hping3-0.0.20051105-6.fc7.x86_64 requires libtcl8.5.so()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 muine-0.8.7-1.fc7.x86_64 requires libFLAC.so.7()(64bit) openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) php-eaccelerator-5.2.0_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.0 python-cherrypy-2.2.1-3.fc6.noarch requires python(abi) = 0:2.4 skencil-0.6.17-12.fc7.x86_64 requires libtk8.5.so()(64bit) skencil-0.6.17-12.fc7.x86_64 requires libtcl8.5.so()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) syck-php-0.55-13.fc7.x86_64 requires php = 0:5.2.0 toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires libtk8.5.so()(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires libtcl8.5.so()(64bit) vkeybd-0.1.17a-2.fc7.x86_64 requires tk < 0:8.6 xcircuit-3.4.26-18.fc7.x86_64 requires libtk8.5.so()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtcl8.5.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so xpa-2.1.6-8.fc7.x86_64 requires libtcl8.5.so()(64bit) From tibbs at math.uh.edu Sat Feb 17 16:28:37 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 17 Feb 2007 10:28:37 -0600 Subject: syck (Was: Summary - Broken dependencies in Fedora Extras - 2007-02-17) In-Reply-To: <20070217130648.20104.7196@extras64.linux.duke.edu> References: <20070217130648.20104.7196@extras64.linux.duke.edu> Message-ID: >>>>> "FEr" == Fedora Extras repoclosure writes: FEr> syck-php - 0.55-13.fc7.i386 from fedora-extras-development-i386 FEr> unresolved deps: php = 0:5.2.0 Joy, this again. I've fixed it the last three times on general principles, but I think it's time to consider syck orphaned and either find a real maintainer or drop it from the repo. In accordance with the AWOL maintainer policy, I've opened https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229122 - J< From dan at danny.cz Sat Feb 17 19:22:02 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 17 Feb 2007 20:22:02 +0100 Subject: UltimateStunts packaged but problems with sound In-Reply-To: <20070217093055.GA2806@free.fr> References: <1171667734.332.21.camel@eagle.danny.cz> <20070217093055.GA2806@free.fr> Message-ID: <1171740122.3675.13.camel@eagle.danny.cz> Patrice Dumas p??e v So 17. 02. 2007 v 10:30 +0100: > On Sat, Feb 17, 2007 at 12:15:34AM +0100, Dan Hor?k wrote: > > Hello, > > > > I have prepared a package with UltimateStunts - a remake of famous DOS > > game called Stunts > > There is a potential trademark issue since the game use in its name part > of a game that was published. I don't know if it is a real issue, > though. Yes, it is possible. So it could be a candidate for a 3rd party repo. I have finally found a workaround for the wav file loading problem. It is really simple - when the call to alutCreateBufferFromFile(filename) fails, just call it second time (http://echelog.matzon.dk/logs/browse/openal/1152825197) And it works. Dan From bugzilla at redhat.com Sun Feb 18 05:35:31 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 18 Feb 2007 00:35:31 -0500 Subject: [Bug 169106] Review Request: fwrestart, safe firewall restarting script In-Reply-To: Message-ID: <200702180535.l1I5ZVGQ009566@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: fwrestart, safe firewall restarting script https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169106 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs? ------- Additional Comments From kevin at tummy.com 2007-02-18 00:35 EST ------- Setting fedora-cvs flag here to request EL-4 and EL-5 branches for this package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From eric.tanguy at univ-nantes.fr Sun Feb 18 10:29:50 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 18 Feb 2007 11:29:50 +0100 Subject: Pb with buildsys Message-ID: <1171794591.12027.2.camel@bureau.maison> Building a package i have this error : http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9.8-2.fc6/i386/job.log This package build fine for devel and FC-5 and have pbs with FC-6 but i can't understand why the system find 64 bits missing dependencies for a i386 build ... Help needed. Eric From bugs.michael at gmx.net Sun Feb 18 12:42:36 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 18 Feb 2007 13:42:36 +0100 Subject: Pb with buildsys In-Reply-To: <1171794591.12027.2.camel@bureau.maison> References: <1171794591.12027.2.camel@bureau.maison> Message-ID: <20070218134236.7ba63ba5.bugs.michael@gmx.net> On Sun, 18 Feb 2007 11:29:50 +0100, Tanguy Eric wrote: > Building a package i have this error : > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9.8-2.fc6/i386/job.log > > This package build fine for devel and FC-5 and have pbs with FC-6 but i > can't understand why the system find 64 bits missing dependencies for a > i386 build ... > > Help needed. Is it still the same when you requeue the build with plague-client? According to the root.log at http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9.8-2.fc6/i386/root.log the builder used the x86_64 libupnp-devel to resolve your BuildRequires: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-6-i386-core-4354da6237bd729d5c49901ce64c4b2f7efc8a96/root resolvedep 'libupnp-devel' 'pkgconfig' 0:libupnp-devel-1.4.2-1.fc6.x86_64 1:pkgconfig-0.21-1.fc6.i386 Perhaps the needsign repository, which is a multi-arch repo (it contains packages for i386, x86_64 and ppc) exposes temporary problems in the dependency resolvers. From eric.tanguy at univ-nantes.fr Sun Feb 18 13:52:22 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 18 Feb 2007 14:52:22 +0100 Subject: Pb with buildsys In-Reply-To: <20070218134236.7ba63ba5.bugs.michael@gmx.net> References: <1171794591.12027.2.camel@bureau.maison> <20070218134236.7ba63ba5.bugs.michael@gmx.net> Message-ID: <1171806743.13870.0.camel@bureau.maison> Le dimanche 18 f?vrier 2007 ? 13:42 +0100, Michael Schwendt a ?crit : > On Sun, 18 Feb 2007 11:29:50 +0100, Tanguy Eric wrote: > > > Building a package i have this error : > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9.8-2.fc6/i386/job.log > > > > This package build fine for devel and FC-5 and have pbs with FC-6 but i > > can't understand why the system find 64 bits missing dependencies for a > > i386 build ... > > > > Help needed. > > Is it still the same when you requeue the build with plague-client? Yes i tried it 3 times > > According to the root.log at > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9.8-2.fc6/i386/root.log > > the builder used the x86_64 libupnp-devel to resolve your BuildRequires: > > Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-6-i386-core-4354da6237bd729d5c49901ce64c4b2f7efc8a96/root resolvedep 'libupnp-devel' 'pkgconfig' > 0:libupnp-devel-1.4.2-1.fc6.x86_64 > 1:pkgconfig-0.21-1.fc6.i386 > > Perhaps the needsign repository, which is a multi-arch repo (it contains > packages for i386, x86_64 and ppc) exposes temporary problems in the > dependency resolvers. > May be but i can't understand why the problem is just for FC-6 and there is no problem with devel and FC-5 ... From dennis at ausil.us Sun Feb 18 17:32:04 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 18 Feb 2007 11:32:04 -0600 Subject: Pb with buildsys In-Reply-To: <1171806743.13870.0.camel@bureau.maison> References: <1171794591.12027.2.camel@bureau.maison> <20070218134236.7ba63ba5.bugs.michael@gmx.net> <1171806743.13870.0.camel@bureau.maison> Message-ID: <200702181132.04505.dennis@ausil.us> Once upon a time Sunday 18 February 2007, Tanguy Eric wrote: > Le dimanche 18 f?vrier 2007 ? 13:42 +0100, Michael Schwendt a ?crit : > > On Sun, 18 Feb 2007 11:29:50 +0100, Tanguy Eric wrote: > > > Building a package i have this error : > > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9 > > >.8-2.fc6/i386/job.log > > > > > > This package build fine for devel and FC-5 and have pbs with FC-6 but i > > > can't understand why the system find 64 bits missing dependencies for a > > > i386 build ... > > > > > > Help needed. > > > > Is it still the same when you requeue the build with plague-client? > > Yes i tried it 3 times > > > According to the root.log at > > > > > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9.8 > >-2.fc6/i386/root.log > > > > the builder used the x86_64 libupnp-devel to resolve your BuildRequires: > > > > Executing /usr/sbin/mock-helper yum --installroot > > /var/lib/mock/fedora-6-i386-core-4354da6237bd729d5c49901ce64c4b2f7efc8a96 > >/root resolvedep 'libupnp-devel' 'pkgconfig' > > 0:libupnp-devel-1.4.2-1.fc6.x86_64 > > 1:pkgconfig-0.21-1.fc6.i386 > > > > Perhaps the needsign repository, which is a multi-arch repo (it contains > > packages for i386, x86_64 and ppc) exposes temporary problems in the > > dependency resolvers. > > May be but i can't understand why the problem is just for FC-6 and there > is no problem with devel and FC-5 .. the problem is that i forgot to remove /etc/rpm/platform from the new builder i put in Friday. Its now removed and ive requeued the build. Dennis From eric.tanguy at univ-nantes.fr Sun Feb 18 17:39:36 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 18 Feb 2007 18:39:36 +0100 Subject: Pb with buildsys In-Reply-To: <200702181132.04505.dennis@ausil.us> References: <1171794591.12027.2.camel@bureau.maison> <20070218134236.7ba63ba5.bugs.michael@gmx.net> <1171806743.13870.0.camel@bureau.maison> <200702181132.04505.dennis@ausil.us> Message-ID: <1171820376.3823.0.camel@bureau.maison> Le dimanche 18 f?vrier 2007 ? 11:32 -0600, Dennis Gilmore a ?crit : > Once upon a time Sunday 18 February 2007, Tanguy Eric wrote: > > Le dimanche 18 f?vrier 2007 ? 13:42 +0100, Michael Schwendt a ?crit : > > > On Sun, 18 Feb 2007 11:29:50 +0100, Tanguy Eric wrote: > > > > Building a package i have this error : > > > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9 > > > >.8-2.fc6/i386/job.log > > > > > > > > This package build fine for devel and FC-5 and have pbs with FC-6 but i > > > > can't understand why the system find 64 bits missing dependencies for a > > > > i386 build ... > > > > > > > > Help needed. > > > > > > Is it still the same when you requeue the build with plague-client? > > > > Yes i tried it 3 times > > > > > According to the root.log at > > > > > > > > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/27763-ushare-0.9.8 > > >-2.fc6/i386/root.log > > > > > > the builder used the x86_64 libupnp-devel to resolve your BuildRequires: > > > > > > Executing /usr/sbin/mock-helper yum --installroot > > > /var/lib/mock/fedora-6-i386-core-4354da6237bd729d5c49901ce64c4b2f7efc8a96 > > >/root resolvedep 'libupnp-devel' 'pkgconfig' > > > 0:libupnp-devel-1.4.2-1.fc6.x86_64 > > > 1:pkgconfig-0.21-1.fc6.i386 > > > > > > Perhaps the needsign repository, which is a multi-arch repo (it contains > > > packages for i386, x86_64 and ppc) exposes temporary problems in the > > > dependency resolvers. > > > > May be but i can't understand why the problem is just for FC-6 and there > > is no problem with devel and FC-5 .. > > the problem is that i forgot to remove /etc/rpm/platform from the new builder > i put in Friday. Its now removed and ive requeued the build. > > > Dennis > Ok thanks, it builds fine now. Eric From eric.tanguy at univ-nantes.fr Sun Feb 18 19:17:02 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 18 Feb 2007 20:17:02 +0100 Subject: Tremulous problem Message-ID: <1171826222.3056.2.camel@bureau.maison> I just tried to install tremulous via yum and when i run it i obtain a black screen. Here is what i can see in a console : $ tremulous tremulous 1.1.0 linux-x86 Sep 6 2006 ----- FS_Startup ----- Current search path: /home/tanguy/.tremulous/base /usr/share/tremulous/base/vms-1.1.0.pk3 (4 files) /usr/share/tremulous/base/map-uncreation-1.1.0.pk3 (110 files) /usr/share/tremulous/base/map-tremor-1.1.0.pk3 (45 files) /usr/share/tremulous/base/map-transit-1.1.0.pk3 (135 files) /usr/share/tremulous/base/map-niveus-1.1.0.pk3 (134 files) /usr/share/tremulous/base/map-nexus6-1.1.0.pk3 (151 files) /usr/share/tremulous/base/map-karith-1.1.0.pk3 (118 files) /usr/share/tremulous/base/map-atcs-1.1.0.pk3 (87 files) /usr/share/tremulous/base/map-arachnid2-1.1.0.pk3 (67 files) /usr/share/tremulous/base/data-1.1.0.pk3 (1229 files) /usr/share/tremulous/base /usr/bin/base ---------------------- 2080 files in pk3 files execing default.cfg execing autogen.cfg couldn't exec autoexec.cfg Hunk_Clear: reset the hunk ok ----- Client Initialization ----- ----- Initializing Renderer ---- ------------------------------- ----- Client Initialization Complete ----- ----- R_Init ----- ------- Input Initialization ------- Joystick is not active. ------------------------------------ ...loading libGL.so.1: Calling SDL_Init(SDL_INIT_VIDEO)... SDL_Init(SDL_INIT_VIDEO) passed. Initializing OpenGL display ...setting mode 3: 640 480 Using 8/8/8 Color bits, 24 depth, 8 stencil display. GL_RENDERER: GeForce4 MX Integrated GPU/PCI/SSE/3DNOW! Initializing OpenGL extensions ...ignoring GL_S3_s3tc ...ignoring GL_EXT_texture_env_add ...using GL_ARB_multitexture ...using GL_EXT_compiled_vertex_array GL_VENDOR: NVIDIA Corporation GL_RENDERER: GeForce4 MX Integrated GPU/PCI/SSE/3DNOW! GL_VERSION: 1.5.8 NVIDIA 96.31 GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shared_texture_palette GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_fence GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_register_combiners GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_SGIS_texture_lod GL_SUN_slice_accum GL_MAX_TEXTURE_SIZE: 2048 GL_MAX_ACTIVE_TEXTURES_ARB: 2 PIXELFORMAT: color(24-bits) Z(24-bit) stencil(8-bits) MODE: 3, 640 x 480 fullscreen hz:N/A GAMMA: hardware w/ 0 overbright bits CPU: rendering primitives: single glDrawElements texturemode: GL_LINEAR_MIPMAP_LINEAR picmip: 0 texture bits: 0 multitexture: enabled compiled vertex arrays: enabled texenv add: disabled compressed textures: disabled Initializing Shaders ...loading 'scripts/uncreation.shader' ...loading 'scripts/q3map2_tremor.shader' ...loading 'scripts/tremor.shader' ...loading 'scripts/transit.shader' ...loading 'scripts/niveus.shader' ...loading 'scripts/nexus6.shader' ...loading 'scripts/karith.shader' ...loading 'scripts/atcs.shader' ...loading 'scripts/arachnid2.shader' ...loading 'scripts/jetpack.shader' ...loading 'scripts/core.shader' ...loading 'scripts/flame.shader' ...loading 'scripts/misc.shader' ...loading 'scripts/common-trem.shader' ...loading 'scripts/titan.shader' ...loading 'scripts/water.shader' ...loading 'scripts/displays.shader' ...loading 'scripts/plant_life.shader' ...loading 'scripts/stasis.shader' ...loading 'scripts/booster.shader' ...loading 'scripts/eggpod.shader' ...loading 'scripts/medistat.shader' ...loading 'scripts/mgturret.shader' ...loading 'scripts/reactor.shader' ...loading 'scripts/telenode.shader' ...loading 'scripts/trapper.shader' ...loading 'scripts/overmind.shader' ...loading 'scripts/tesla.shader' ...loading 'scripts/dcc.shader' ...loading 'scripts/hive.shader' ...loading 'scripts/level2.shader' ...loading 'scripts/human.shader' ...loading 'scripts/null.shader' ...loading 'scripts/weapons.shader' ...loading 'scripts/conkit.shader' ...loading 'scripts/advckit.shader' ...loading 'scripts/psaw.shader' ...loading 'scripts/mdriver.shader' ...loading 'scripts/flamer.shader' ...loading 'scripts/crosshairs.shader' ...loading 'scripts/grenade.shader' ...loading 'scripts/splash.shader' ...loading 'scripts/marks.shader' ...loading 'scripts/sprites.shader' ...loading 'scripts/muzzleflashes.shader' ----- finished R_Init ----- ------ Initializing Sound ------ Initializing SDL audio driver... SDL audio driver is "alsa". SDL_AudioSpec: Format: AUDIO_S16LSB Freq: 22050 Samples: 470 Channels: 2 Starting SDL audio callback... SDL audio initialized. ----- Sound Info ----- 1 stereo 16384 samples 16 samplebits 1 submission_chunk 22050 speed 0xa878b38 dma buffer No background file. ---------------------- Sound intialization successful. -------------------------------- Sound memory manager started Loading vm file vm/ui.qvm... ...which has vmMagic VM_MAGIC_VER2 Loading 1075 jump table targets VM file ui compiled to 786313 bytes of code ui loaded in 4596672 bytes on the hunk UI menu load time = 554 milli seconds UI menu load time = 81 milli seconds UI menu load time = 83 milli seconds --- Common Initialization Complete --- Opening IP socket: localhost:30720 Hostname: bureau.maison Alias: bureau Alias: localhost.localdomain Alias: localhost IP: 127.0.0.1 Started tty console (use +set ttycon 0 to disable) Received signal 15, exiting... ----- CL_Shutdown ----- Closing SDL audio device... SDL audio device shut down. RE_Shutdown( 1 ) X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 137 (XFree86-VidModeExtension) Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) Value in failed request: 0x460000e Serial number of failed request: 177 Current serial number in output stream: 179 From buildsys at fedoraproject.org Mon Feb 19 00:38:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 18 Feb 2007 19:38:07 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-18 Message-ID: <20070219003807.85C4315212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 15 NetworkManager-vpnc-0.6.4-2.fc7 audacious-plugins-1.2.5-6.fc7 catfish-0.2.1-1.fc7 cfitsio-3.030-2.fc7 clamav-0.90-1.fc7 jd-1.8.8-0.1.beta070218.fc7 q-7.6-2.fc7 skencil-0.6.17-13.fc7 sonata-1.0.1-3.fc7 testdisk-6.6-1.fc7 ushare-0.9.8-2.fc7 wine-0.9.31-1.fc7 wormux-0.7.9-1.fc7 xtide-2.9-0.3.RC3.fc7 yafc-1.1.1-7.fc7 Packages built and released for Fedora Extras 6: 12 NetworkManager-vpnc-0.6.4-2.fc6 audacity-1.3.2-7.fc6 catfish-0.2.1-1.fc6 cfitsio-3.030-2.fc6 jd-1.8.8-0.1.beta070218.fc6 mod_mono-1.2.1-1.fc6 NEW sonata-1.0.1-3.fc6 testdisk-6.6-1.fc6 ushare-0.9.8-2.fc6 wine-0.9.31-1.fc6 wormux-0.7.9-1.fc6 xtide-2.9-0.3.RC3.fc6 Packages built and released for Fedora Extras 5: 7 catfish-0.2.1-1.fc5 cfitsio-3.030-2.fc5 jd-1.8.8-0.1.beta070218.fc5.1 testdisk-6.6-1.fc5 ushare-0.9.8-2.fc5 wine-0.9.31-1.fc5 xtide-2.9-0.3.RC3.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Matt_Domsch at dell.com Mon Feb 19 04:31:38 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Feb 2007 22:31:38 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-18 Message-ID: <20070218223138.A18516@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Sun Feb 18 21:10:50 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2641 Number failed to build: 75 Number expected to fail due to ExclusiveArch or ExcludeArch: 19 Leaving: 56 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 56 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de atitvout-0.4-6 andreas.bierfert at lowlatency.de audacity-1.3.2-7.20070106cvs.fc7 gemi at bluewin.ch banshee-0.11.5-1.fc7 caillon at redhat.com boo-0.7.6.2237-12.fc7 paul at all-the-johnsons.co.uk compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com darcs-1.0.8-4.fc7 petersen at redhat.com em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libreadline-java-0.8.0-13.fc6 ifoox at redhat.com mlton-20061107-2.fc7 adam at spicenitz.org nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com perl-Log-Log4perl-1.09-1.fc7 jpo at di.uminho.pt php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.9-7.fc7 jamatos at fc.up.pt python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com python-reportlab-2.0-2.fc7 bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu skencil-0.6.17-12.fc7 gemi at bluewin.ch socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 giallu at gmail.com toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Mon Feb 19 04:32:01 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 18 Feb 2007 22:32:01 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-02-18 Message-ID: <20070218223201.A18534@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Sun Feb 18 21:15:52 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2641 Number failed to build: 49 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 47 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 46 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de banshee-0.11.5-1.fc7 caillon at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com darcs-1.0.8-4.fc7 petersen at redhat.com em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gkrellm-wifi-0.9.12-3.fc6 j.w.r.degoede at hhs.nl gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gnumeric-1.6.3-5.fc6 j.w.r.degoede at hhs.nl gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libreadline-java-0.8.0-13.fc6 ifoox at redhat.com nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org python-basemap-data-0.9-1.fc6 orion at cora.nwra.com python-cherrypy-2.2.1-3.fc6 lmacken at redhat.com qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu skencil-0.6.17-12.fc7 gemi at bluewin.ch socat-1.5.0.0-3.fc6 paul at xelerance.com soundtouch-1.3.1-6.fc6 j.w.r.degoede at hhs.nl steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 giallu at gmail.com toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xmms-speex-0.9.1-8.fc6 matthias at rpmforge.net xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From gauret at free.fr Mon Feb 19 07:07:37 2007 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 19 Feb 2007 08:07:37 +0100 Subject: Taking over libvisual-plugins Message-ID: Hi *, I'm taking over libvisual-plugins, which has been orphaned since 2006-09-19. I'll be requesting an owners.list change through the bugzilla flag. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr It is by caffeine alone that I set my mind in motion. It is by the beans of java that the thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone that I set my mind in motion. From j.w.r.degoede at hhs.nl Mon Feb 19 08:43:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 19 Feb 2007 09:43:58 +0100 Subject: Tremulous problem In-Reply-To: <1171826222.3056.2.camel@bureau.maison> References: <1171826222.3056.2.camel@bureau.maison> Message-ID: <45D9634E.8010705@hhs.nl> Tanguy Eric wrote: > I just tried to install tremulous via yum and when i run it i obtain a > black screen. Next time please don't send a mail like this to both the list and my private mail, I first read my private mail, thus you got a private response, now here is the same response again for those reading the list. Even better would be to use bugzilla for things like this. --- original reply --- > Here is what i can see in a console : > Thats useless as the problem seen here is caused by you running it from a console instead of from X. Could you try the official tremulous binaries from the tremulous homepage, and if those give a black screen too try contacting the tremulous developers directly? Regards, Hans From j.w.r.degoede at hhs.nl Mon Feb 19 10:59:17 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 19 Feb 2007 11:59:17 +0100 Subject: libmatroska update Message-ID: <45D98305.7020401@hhs.nl> Hi all, I've just updated libmatroska to 0.8.1, AFAIK its ABI and API compatible, still it could use some more testing then I've done. Let me know if you encounter any problems. Also because of this I'm pushing this only to devel, unless requested otherwise. Regards, Hans From eric.tanguy at univ-nantes.fr Mon Feb 19 14:32:28 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 19 Feb 2007 15:32:28 +0100 Subject: Tremulous problem In-Reply-To: <45D9634E.8010705@hhs.nl> References: <1171826222.3056.2.camel@bureau.maison> <45D9634E.8010705@hhs.nl> Message-ID: <1171895548.6328.7.camel@bureau.maison> Le lundi 19 f?vrier 2007 ? 09:43 +0100, Hans de Goede a ?crit : > Tanguy Eric wrote: > > I just tried to install tremulous via yum and when i run it i obtain a > > black screen. > > Next time please don't send a mail like this to both the list and my > private mail, I first read my private mail, thus you got a private > response, now here is the same response again for those reading the > list. Even better would be to use bugzilla for things like this. Sorry. > > --- original reply --- > > > Here is what i can see in a console : > > > > Thats useless as the problem seen here is caused by you running it from > a console instead of from X. I don't understand why you find this useless. I have a problem : when i run the game from X, i obtain a black screen. I can hear the sound. So i guess the game plays fine except i have nothing at screen. I kill the game from a console and i see my desktop in very low resolution. So i tried to launch it from a console to see the messages ... > > Could you try the official tremulous binaries from the tremulous > homepage, and if those give a black screen too try contacting the > tremulous developers directly? I tried the official package without any success. I have the same problem with similar games (alienarena, cube, ...) but i can play with doom and freedoom without any problem. > > Regards, Regards Eric > > Hans > From j.w.r.degoede at hhs.nl Mon Feb 19 14:47:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 19 Feb 2007 15:47:27 +0100 Subject: Tremulous problem In-Reply-To: <1171895548.6328.7.camel@bureau.maison> References: <1171826222.3056.2.camel@bureau.maison> <45D9634E.8010705@hhs.nl> <1171895548.6328.7.camel@bureau.maison> Message-ID: <45D9B87F.905@hhs.nl> Tanguy Eric wrote: > Le lundi 19 f?vrier 2007 ? 09:43 +0100, Hans de Goede a ?crit : >> Tanguy Eric wrote: >>> I just tried to install tremulous via yum and when i run it i obtain a >>> black screen. >> Next time please don't send a mail like this to both the list and my >> private mail, I first read my private mail, thus you got a private >> response, now here is the same response again for those reading the >> list. Even better would be to use bugzilla for things like this. > > Sorry. > >> --- original reply --- >> >> > Here is what i can see in a console : >> > >> >> Thats useless as the problem seen here is caused by you running it from >> a console instead of from X. > > I don't understand why you find this useless. I have a problem : when i > run the game from X, i obtain a black screen. I can hear the sound. So i > guess the game plays fine except i have nothing at screen. I kill the > game from a console and i see my desktop in very low resolution. So i > tried to launch it from a console to see the messages ... > The X error you are seeing is xvidmode related, and that message is given because tremulous is making an xvidmode call to change the resolution, while X is not visible / on the foreground. Thus the output is useless. >> Could you try the official tremulous binaries from the tremulous >> homepage, and if those give a black screen too try contacting the >> tremulous developers directly? > > I tried the official package without any success. I have the same > problem with similar games (alienarena, cube, ...) but i can play with > doom and freedoom without any problem. > Sounds like a video-driver / or monitor configuration problem. Since you're using the binary nvidea drivers there is no-on who can help you here. Regards, Hans From Christian.Iseli at licr.org Mon Feb 19 15:05:41 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 19 Feb 2007 16:05:41 +0100 Subject: FE Package Status of Feb 19, 2007 Message-ID: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Hi folks, I cross-post this to fel and fml. I suppose this should later only go to fml. What do you think ? The name should also become Fedora Package Status... I made a long overdue update to the PackageStatus page. I changed the script to deal with the new reviewing process and hope I didn't make too many mistakes. Have a good look, and report funnies... The mass review makes it a bit complicated to determine who is the submitter and who is the reviewer in some cases. We'll see how things look when the dust settles a bit on the big "merge review" thing. Looks like the owners.list file is still missing a couple entries, and is not fully sorted... Someone who has access: please fix it (or give me access to fix it). Sorting problem in owners.list: hunspell-bg lt hunspell-ca Sorting problem in owners.list: ices lt icewm Sorting problem in owners.list: kakasi lt kalgebra Cheers, C ---- FE Package Status of Feb 19, 2007 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 2868 packages - 4175 binary rpms in devel - 102 orphans - 21 packages not available in extras devel or release andreas at bawue dot net ddrescue bdpepple at ameritech dot net galago-filesystem caolanm at redhat dot com hunspell-hu caolanm at redhat dot com hunspell-ms caolanm at redhat dot com hunspell-it cweyl at alumni dot drew dot edu perl-GStreamer dbhole at redhat dot com objectweb-anttask fitzsim at redhat dot com classpathx-jaxp gauret at free dot fr pdftohtml gauret at free dot fr libvisual-plugins guillaume dot thouvenin at bull dot net elsa jhrozek at redhat dot com dwdiff matt at rudeserver dot com rudeconfig mcepl at redhat dot com gstreamer-plugins-pulseaudio overholt at redhat dot com jython paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net paul at all-the-johnsons dot co dot uk gconvert paul at xelerance dot com l2tpd pertusus at free dot fr ivman rmeggins at redhat dot com fedora-ds - 7 packages not available in extras devel but present in release andreas dot bierfert at lowlatency dot de sylpheed-claws-plugins andreas dot bierfert at lowlatency dot de sylpheed-claws bjohnson at symetrix dot com gdome2 cweyl at alumni dot drew dot edu 915resolution cweyl at alumni dot drew dot edu perl-File-ExtAttr jmp at safe dot ca clement lmacken at redhat dot com python-TurboMail - 26 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=226002 libevent nobody at fedoraproject.org https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=196837,221084,225755,225808,225896,225995,226036,226240,226264,226265,226266,226272,226279,226280,226291,226340,226345,226390,226395,226396,226399,226403,226429,226490,226497 php-pear-PHPUnit chris.stone at gmail.com dkms Matt_Domsch at dell.com firefox nobody at fedoraproject.org gmime nobody at fedoraproject.org icu nobody at fedoraproject.org libdaemon nobody at fedoraproject.org liboil nobody at fedoraproject.org perl-Archive-Zip nobody at fedoraproject.org perl-IO-Socket-SSL nobody at fedoraproject.org perl-IO-String nobody at fedoraproject.org perl-IO-Zlib nobody at fedoraproject.org perl-Net-SSLeay nobody at fedoraproject.org perl-Socket6 nobody at fedoraproject.org perl-String-CRC32 nobody at fedoraproject.org perl-XML-Simple nobody at fedoraproject.org pyspi nobody at fedoraproject.org python-numeric nobody at fedoraproject.org scim-anthy nobody at fedoraproject.org scim nobody at fedoraproject.org scim-pinyin nobody at fedoraproject.org scim-tables nobody at fedoraproject.org seamonkey nobody at fedoraproject.org sqlite nobody at fedoraproject.org thunderbird nobody at fedoraproject.org tog-pegasus nobody at fedoraproject.org - 2 packages present in the development repo which have no owners entry cycle gstreamer-plugins-pulse - 2 orphaned packages, yet available in extras devel luks-tools udftools - 43 packages that moved to core FE-ACCEPT packages stats: - 1945 accepted, closed package reviews - 25 accepted, closed package reviews not in repo - 2 accepted, closed package reviews not in owners - 13 accepted, open package reviews older than 4 weeks; - 80 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 213 open tickets - 23 tickets with no activity in eight weeks - 13 tickets with no activity in four weeks - 3 closed tickets FE-NEW packages stats: - 1175 open tickets - 38 tickets with no activity in eight weeks - 33 tickets with no activity in four weeks - 1 closed tickets FE-NEEDSPONSOR packages stats: - 49 open tickets - 7 tickets with no activity in eight weeks - 6 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - 2 open tickets - 2 tickets with no activity in eight weeks OPEN-BUGS packages stats: - 257 open tickets - 102 tickets with no activity in eight weeks - 36 tickets with no activity in four weeks CVS stats: - 2864 packages with a devel directory - 7 packages with no owners entry EL4 EL5 cycle gstreamer-plugins-pulse php-pear-PHP-CodeSniffer postgis postgresql-dbi-link - 1 packages in CVS devel *and* Core libnl - 193 packages were dropped from extras Maintainers stats: - 258 maintainers - 11 inactive maintainers with open bugs - 33 inactive maintainers Dropped FC packages: - 290 packages were dropped from core since FC 1 Comps.xml files stats: - 938 packages in comps-fe7 file - 546 packages missing from comps-fe7 file - 12 packages in comps-fe7 but not in repo - 935 packages in comps-fe6 file - 553 packages missing from comps-fe6 file - 5 packages in comps-fe6 but not in repo From rc040203 at freenet.de Mon Feb 19 17:43:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Feb 2007 18:43:12 +0100 Subject: buildsys error Message-ID: <1171906992.3280.10.camel@mccallum.corsepiu.local> A bizarre buildsys error: Error Downloading Packages: buildsys-macros - 7-3.fc7.noarch: failure: buildsys-macros-7-3.fc7.noarch.rpm from groups: [Errno 256] No more mirrors to try. http://buildsys.fedoraproject.org/logs/fedora-development-extras/27809-Coin2-2.4.5-4.fc7/ppc/root.log Ralf From martin.sourada at seznam.cz Mon Feb 19 19:56:41 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Mon, 19 Feb 2007 20:56:41 +0100 Subject: Listen 0.5 update to stable? Message-ID: <45DA00F9.90704@seznam.cz> I noticed a stable release of listen 0.5 was released just few days after listen update in extras (to svn657). Is there any particular reason why not to update to the stable release? From giallu at gmail.com Mon Feb 19 21:33:49 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 19 Feb 2007 22:33:49 +0100 Subject: buildsys error In-Reply-To: <1171906992.3280.10.camel@mccallum.corsepiu.local> References: <1171906992.3280.10.camel@mccallum.corsepiu.local> Message-ID: On 2/19/07, Ralf Corsepius wrote: > A bizarre buildsys error: > > Error Downloading Packages: > buildsys-macros - 7-3.fc7.noarch: failure: buildsys-macros-7-3.fc7.noarch.rpm from groups: [Errno 256] No more mirrors to try. > > http://buildsys.fedoraproject.org/logs/fedora-development-extras/27809-Coin2-2.4.5-4.fc7/ppc/root.log > Happened to me few days ago with sysprof-kmod x86_64. I just waited and requeued From buildsys at fedoraproject.org Mon Feb 19 23:01:27 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 19 Feb 2007 18:01:27 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-19 Message-ID: <20070219230127.0BD6915212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 31 NEW 915resolution-0.5.2-4.fc7 SIMVoleon-2.0.1-5.fc7 SoQt-1.4.1-4.fc7 amarok-1.4.5-4.fc7 bcfg2-0.9.2-1.fc7 bin2iso-1.9-5.b.fc7 cobbler-0.4.0-2.fc7 darcs-1.0.9-0.1.rc2.fc7 easytag-1.99.13-3.fc7 NEW gdome2-0.8.1-5.2.fc7 gkrellm-wifi-0.9.12-4.fc7 glyph-keeper-0.32-1.fc7 gnumeric-1.6.3-6.fc7 NEW hunspell-ms-0.20050117-1.fc7 jd-1.8.8-0.1.cvs070219.fc7 kvm-12-3 libmatroska-0.8.1-1.fc7 NEW libvisual-plugins-0.4.0-2.fc7 mhash-0.9.8-1 mock-0.6.12-1.fc7 perl-Class-InsideOut-1.06-1.fc7 perl-Data-Alias-1.02-1.fc7 php-eaccelerator-5.2.1_0.9.5-1.fc7 python-basemap-data-0.9-2.fc7 python-cherrypy-2.2.1-6.fc7 python-telepathy-0.13.8-1.fc7 soundtouch-1.3.1-7.fc7 ufraw-0.10-2.fc7 vkeybd-0.1.17a-3.fc7 xmms-speex-0.9.1-9.fc7 yum-utils-1.1.0-1.fc7 Packages built and released for Fedora Extras 6: 8 amarok-1.4.5-4.fc6 bcfg2-0.9.2-1.fc6 cobbler-0.4.0-2.fc6 easytag-1.99.13-3.fc6 NEW libvisual-plugins-0.4.0-2.fc6 perl-Class-InsideOut-1.06-1.fc6 perl-Data-Alias-1.02-1.fc6 yum-utils-1.0.3-1.fc6 Packages built and released for Fedora Extras 5: 3 cobbler-0.4.0-2.fc5 perl-Class-InsideOut-1.06-1.fc5 perl-Data-Alias-1.02-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lxtnow at gmail.com Tue Feb 20 00:26:40 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Mon, 19 Feb 2007 20:26:40 -0400 Subject: Openjpeg Message-ID: <62bc09df0702191626y73482dc7x485236e8a033a436@mail.gmail.com> Hi, I started review this bug #229098and asking about the license of this one. As for mp3 or NTFS from where the code can be GPL but not the format and by this way not added in extras, even if its license is BSD for openjpeg. Do you have a good link where i can find out more explaination about lisences accepted on extras. -- Xavier.t Lamien -- French Fedora Ambassador GPG-Key ID: F3903DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at xelerance.com Tue Feb 20 05:14:54 2007 From: paul at xelerance.com (Paul Wouters) Date: Tue, 20 Feb 2007 06:14:54 +0100 (CET) Subject: FE Package Status of Feb 19, 2007 In-Reply-To: <20070219160541.539bce2d@ludwig-alpha.unil.ch> References: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Message-ID: On Mon, 19 Feb 2007, Christian Iseli wrote: > FE Package Status of Feb 19, 2007 > - 21 packages not available in extras devel or release [...] > paul at xelerance dot com l2tpd Package was obsoleted for xl2tpd. was I supposed to remove it from the owners file? I no longer have access to modify that file. Paul From giallu at gmail.com Tue Feb 20 08:05:37 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 20 Feb 2007 09:05:37 +0100 Subject: Openjpeg In-Reply-To: <62bc09df0702191626y73482dc7x485236e8a033a436@mail.gmail.com> References: <62bc09df0702191626y73482dc7x485236e8a033a436@mail.gmail.com> Message-ID: On 2/20/07, SmootherFrOgZ wrote: > Hi, > > I started review this bug #229098 and asking about the license of this one. > As for mp3 or NTFS from where the code can be GPL but not the format and by > this way not added in extras, even if its license is BSD for openjpeg. > Do you have a good link where i can find out more explaination about > lisences accepted on extras. http://fedoraproject.org/wiki/Packaging/Guidelines#Legal From giallu at gmail.com Tue Feb 20 08:11:39 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 20 Feb 2007 09:11:39 +0100 Subject: Unorphaning buildbot Message-ID: Hi all, I am interested in unorphaning buildbot, a nice cross platform build automation tool; co-maintainers are welcome. Since I'm pretty confused by all the recent changes in the guidelines, who is in charge for editing the owners.list and how should I request the modification? Cheers Gianluca From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 20 08:21:21 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 20 Feb 2007 17:21:21 +0900 Subject: Unorphaning buildbot In-Reply-To: References: Message-ID: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> Gianluca Sforna wrote: > Hi all, > I am interested in unorphaning buildbot, a nice cross platform build > automation tool; co-maintainers are welcome. > > Since I'm pretty confused by all the recent changes in the guidelines, > who is in charge for editing the owners.list and how should I request > the modification? > Well, according to the explanation by Warren Togami on fedora-maintainers list: ------------------------------------------------------- Change Owner or Add Co-Maintainers ================================== 1) Use existing review ticket, even if it is CLOSED, this is fine. 2) Write in a comment the change request and justification if appropriate. 3) Set fedora-cvs? ------------------------------------------------------- So, you have to search what is the original review request for buildbot and write something and set fedora-cvs flags properly. For this case, the original buildbot review request is _perhaps_ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197565 From giallu at gmail.com Tue Feb 20 08:34:07 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 20 Feb 2007 09:34:07 +0100 Subject: Unorphaning buildbot In-Reply-To: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> References: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> Message-ID: On 2/20/07, Mamoru Tasaka wrote: > Gianluca Sforna wrote: > > Hi all, > > I am interested in unorphaning buildbot, a nice cross platform build > > automation tool; co-maintainers are welcome. > > > > Since I'm pretty confused by all the recent changes in the guidelines, > > who is in charge for editing the owners.list and how should I request > > the modification? > > > > Well, according to the explanation by Warren Togami on > fedora-maintainers list: > ------------------------------------------------------- > Change Owner or Add Co-Maintainers > ================================== > 1) Use existing review ticket, even if it is CLOSED, this is fine. > 2) Write in a comment the change request and justification if appropriate. > 3) Set fedora-cvs? > ------------------------------------------------------- > > So, you have to search what is the original review request for > buildbot and write something and set fedora-cvs flags properly. > For this case, the original buildbot review request is _perhaps_ > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197565 that's it. thanks a lot /me going to note on all his spec files the review BZ... From fedora at leemhuis.info Tue Feb 20 08:40:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Feb 2007 09:40:05 +0100 Subject: co-maintainers wanted and how to update owners.list for packages that have no review ticket (was Re: Unorphaning buildbot) In-Reply-To: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> References: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> Message-ID: <45DAB3E5.3000205@leemhuis.info> On 20.02.2007 09:21, Mamoru Tasaka wrote: > Gianluca Sforna wrote: >> I am interested in unorphaning buildbot, a nice cross platform build >> automation tool; co-maintainers are welcome. >> Since I'm pretty confused by all the recent changes in the guidelines, >> who is in charge for editing the owners.list and how should I request >> the modification? > Well, according to the explanation by Warren Togami on > fedora-maintainers list: > ------------------------------------------------------- > Change Owner or Add Co-Maintainers > ================================== > 1) Use existing review ticket, even if it is CLOSED, this is fine. > 2) Write in a comment the change request and justification if appropriate. > 3) Set fedora-cvs? > ------------------------------------------------------- And how to realize it for all those early Extras packages that got reviewed on the mailing lists or got imported from freshrpms and fedora.us directly? Those have no review ticket in bugzilla. BTW, I'm searching co-maintainers for these packages: > Fedora Extras|atomix|Little mind game where you have to build molecules out of atoms lying around|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|enigma|Clone of the ATARI game Oxyd|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|ghex|A binary editor for GNOME|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|gsynaptics|Settings tool for Synaptics touchpad driver|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|gweled|Swapping gem game|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|mail-notification|Mail Notification is a status icon that informs you if you have new mail|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|mail-notification|Mail Notification is a status icon that informs you if you have new mail|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|revelation|Password manager for GNOME 2|fedora at leemhuis.info|extras-qa at fedoraproject.org| > Fedora Extras|tiobench|Threaded I/O benchmark|fedora at leemhuis.info|extras-qa at fedoraproject.org| In case anybody is interested in co-maintaining them please send me a private mail! tia! CU thl From giallu at gmail.com Tue Feb 20 08:48:23 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 20 Feb 2007 09:48:23 +0100 Subject: co-maintainers wanted and how to update owners.list for packages that have no review ticket (was Re: Unorphaning buildbot) In-Reply-To: <45DAB3E5.3000205@leemhuis.info> References: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> <45DAB3E5.3000205@leemhuis.info> Message-ID: On 2/20/07, Thorsten Leemhuis wrote: > On 20.02.2007 09:21, Mamoru Tasaka wrote: > > Gianluca Sforna wrote: > >> I am interested in unorphaning buildbot, a nice cross platform build > >> automation tool; co-maintainers are welcome. > >> Since I'm pretty confused by all the recent changes in the guidelines, > >> who is in charge for editing the owners.list and how should I request > >> the modification? > > Well, according to the explanation by Warren Togami on > > fedora-maintainers list: > > ------------------------------------------------------- > > Change Owner or Add Co-Maintainers > > ================================== > > 1) Use existing review ticket, even if it is CLOSED, this is fine. > > 2) Write in a comment the change request and justification if appropriate. > > 3) Set fedora-cvs? > > ------------------------------------------------------- > > And how to realize it for all those early Extras packages that got > reviewed on the mailing lists or got imported from freshrpms and > fedora.us directly? Those have no review ticket in bugzilla. IIRC someone collected that kind of info lately (for the package DB?) but I'm not sure if the results are available somewhere. From mtasaka at ioa.s.u-tokyo.ac.jp Tue Feb 20 08:55:04 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 20 Feb 2007 17:55:04 +0900 Subject: co-maintainers wanted and how to update owners.list for packages that have no review ticket (was Re: Unorphaning buildbot) In-Reply-To: <45DAB3E5.3000205@leemhuis.info> References: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> <45DAB3E5.3000205@leemhuis.info> Message-ID: <45DAB768.1060307@ioa.s.u-tokyo.ac.jp> Thorsten Leemhuis wrote: > On 20.02.2007 09:21, Mamoru Tasaka wrote: >> Gianluca Sforna wrote: >>> I am interested in unorphaning buildbot, a nice cross platform build >>> automation tool; co-maintainers are welcome. >>> Since I'm pretty confused by all the recent changes in the guidelines, >>> who is in charge for editing the owners.list and how should I request >>> the modification? >> Well, according to the explanation by Warren Togami on >> fedora-maintainers list: >> ------------------------------------------------------- >> Change Owner or Add Co-Maintainers >> ================================== >> 1) Use existing review ticket, even if it is CLOSED, this is fine. >> 2) Write in a comment the change request and justification if >> appropriate. >> 3) Set fedora-cvs? >> ------------------------------------------------------- > > And how to realize it for all those early Extras packages that got > reviewed on the mailing lists or got imported from freshrpms and > fedora.us directly? Those have no review ticket in bugzilla. I threw similar questions on fedora-maintainers list twice, actually... Yes, in these cases the new process (candidate?) is questionable. Mamoru From giallu at gmail.com Tue Feb 20 09:04:05 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 20 Feb 2007 10:04:05 +0100 Subject: Help with desktop-file-install Message-ID: In the latest rawstudio buildlog I see the following warnings: + desktop-file-install --vendor fedora --dir /var/tmp/rawstudio-0.5-1.fc7-root-mockbuild/usr/share/applications --add-category X-Fedora --delete-original /var/tmp/rawstudio-0.5-1.fc7-root-mockbuild/usr/share/applications/rawstudio.desktop /var/tmp/rawstudio-0.5-1.fc7-root-mockbuild/usr/share/applications/rawstudio.desktop: missing encoding (guessed UTF-8) /var/tmp/rawstudio-0.5-1.fc7-root-mockbuild/usr/share/applications/fedora-rawstudio.desktop: warning: The 'Application' category is not defined by the desktop entry specification. Please use one of "AudioVideo", "Audio", "Video", "Development", "Education", "Game", "Graphics", "Network", "Office", "Settings", "System", "Utility" instead Questions: 1. is the --add-category X-Fedora not required anymore? 2. how to fix the encoding ? 3. is --remove-category Application enough to fix the last one? TIA Gianluca From rdieter at math.unl.edu Tue Feb 20 12:19:17 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Feb 2007 06:19:17 -0600 Subject: Help with desktop-file-install In-Reply-To: References: Message-ID: Gianluca Sforna wrote: > Questions: > 1. is the --add-category X-Fedora not required anymore? no. > 2. how to fix the encoding ? Add Encoding=UTF-8 (or other as appropriate) to the .desktop file. > 3. is --remove-category Application enough to fix the last one? should be. -- Rex From Christian.Iseli at licr.org Tue Feb 20 13:41:03 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 20 Feb 2007 14:41:03 +0100 Subject: co-maintainers wanted and how to update owners.list for packages that have no review ticket (was Re: Unorphaning buildbot) In-Reply-To: References: <45DAAF81.10504@ioa.s.u-tokyo.ac.jp> <45DAB3E5.3000205@leemhuis.info> Message-ID: <20070220144103.6e6194f1@ludwig-alpha.unil.ch> On Tue, 20 Feb 2007 09:48:23 +0100, Gianluca Sforna wrote: > IIRC someone collected that kind of info lately (for the package DB?) > but I'm not sure if the results are available somewhere. That would be me... :-) The status of my knowledge is here: http://fedoraproject.org/wiki/ChristianIseli/PackageReviewStatus C From Christian.Iseli at licr.org Tue Feb 20 13:43:32 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 20 Feb 2007 14:43:32 +0100 Subject: FE Package Status of Feb 19, 2007 In-Reply-To: References: <20070219160541.539bce2d@ludwig-alpha.unil.ch> Message-ID: <20070220144332.043de4ce@ludwig-alpha.unil.ch> On Tue, 20 Feb 2007 06:14:54 +0100 (CET), Paul Wouters wrote: > Package was obsoleted for xl2tpd. was I supposed to remove it from the > owners file? I no longer have access to modify that file. No. Please have a look at http://fedoraproject.org/wiki/Extras/PackageEndOfLife (you should "cvs rm" the files in l2tpd/devel and "cvs add" a dead.package file in there) Cheers, C From ville.skytta at iki.fi Tue Feb 20 16:29:54 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 20 Feb 2007 18:29:54 +0200 Subject: Help with desktop-file-install In-Reply-To: References: Message-ID: <200702201829.54634.ville.skytta@iki.fi> On Tuesday 20 February 2007, Rex Dieter wrote: > Add > Encoding=UTF-8 > (or other as appropriate) to the .desktop file. Note that even though desktop-file-{install,validate} currently whines if the Encoding key is not present, it's deprecated in Desktop Entry Specification 1.0. The spec isn't very clear about exactly how should one specify the encodings [0], but I gather in 1.0 compliant desktop files it's using the .ENCODING part of keys that can take a localestring as a value and omit the Encoding=... key altogether, for example: Comment[fi_FI.UTF-8]=... More info: http://standards.freedesktop.org/desktop-entry-spec/1.0/ (Localized values for keys, Deprecated items, The Legacy-Mixed Encoding). [0] Well at least it's not clear to me. If someone understands/knows better, clarifications welcome. From paul at xelerance.com Tue Feb 20 16:30:52 2007 From: paul at xelerance.com (Paul Wouters) Date: Tue, 20 Feb 2007 17:30:52 +0100 (CET) Subject: FE Package Status of Feb 19, 2007 In-Reply-To: <20070220144332.043de4ce@ludwig-alpha.unil.ch> References: <20070219160541.539bce2d@ludwig-alpha.unil.ch> <20070220144332.043de4ce@ludwig-alpha.unil.ch> Message-ID: On Tue, 20 Feb 2007, Christian Iseli wrote: > No. Please have a look at > http://fedoraproject.org/wiki/Extras/PackageEndOfLife > > (you should "cvs rm" the files in l2tpd/devel and "cvs add" a > dead.package file in there) Ah thanks! I've done this now. Paul From bugs.michael at gmx.net Tue Feb 20 20:23:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 20 Feb 2007 21:23:22 +0100 Subject: Orphanizing the OrphanedPackages Wiki page Message-ID: <20070220212322.add7edba.bugs.michael@gmx.net> After sending this message, I won't keep an eye on the OrphanedPackages Wiki page and on orphaned packages anymore. I will also discontinue with monitoring the orphan owner in bugzilla. With the locks on owners.list and CVS it makes no sense to continue with such activities. From jerone at gmail.com Tue Feb 20 20:33:51 2007 From: jerone at gmail.com (Jerone Young) Date: Tue, 20 Feb 2007 14:33:51 -0600 Subject: Review of grub2 packages, anyone going to review them? Message-ID: <9f50a7a00702201233k1471b70ctabe122ae22088f04@mail.gmail.com> Hi I submitted grub2 packages for review sometime ago. The bugzilla can be found here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228255 Any idea if anyone will get to it ? From lxtnow at gmail.com Tue Feb 20 20:43:28 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Tue, 20 Feb 2007 16:43:28 -0400 Subject: Review of grub2 packages, anyone going to review them? In-Reply-To: <9f50a7a00702201233k1471b70ctabe122ae22088f04@mail.gmail.com> References: <9f50a7a00702201233k1471b70ctabe122ae22088f04@mail.gmail.com> Message-ID: <62bc09df0702201243xcfea8ccqe9dea14a55cd4936@mail.gmail.com> i'll have a look 2007/2/20, Jerone Young : > > Hi I submitted grub2 packages for review sometime ago. The bugzilla > can be found here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228255 > > Any idea if anyone will get to it ? > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Xavier -- French Fedora Ambassador GPG-Key ID: F3903DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Tue Feb 20 21:10:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 16:10:01 -0500 Subject: Orphanizing the OrphanedPackages Wiki page In-Reply-To: <20070220212322.add7edba.bugs.michael@gmx.net> References: <20070220212322.add7edba.bugs.michael@gmx.net> Message-ID: <45DB63A9.1020109@redhat.com> Michael Schwendt wrote: > After sending this message, I won't keep an eye on the OrphanedPackages > Wiki page and on orphaned packages anymore. I will also discontinue with > monitoring the orphan owner in bugzilla. With the locks on owners.list > and CVS it makes no sense to continue with such activities. I believe maintaining this in two places is too much manual work in the long-term. Perhaps we should have a script that reads owners.list and to auto-generates a static page that displays the orphans? This could be written independently of anything else. http://rubenkerkhof.com/review Something like this... except generated with links to the CVS of each orphaned package. Any volunteers to write this? Pretty easy project. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Feb 20 21:37:45 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Feb 2007 16:37:45 -0500 Subject: signing a JAR file In-Reply-To: <45D370DB.4060309@redhat.com> References: <45D23B3B.9020007@redhat.com> <200702140912.22971.ville.skytta@iki.fi> <45D370DB.4060309@redhat.com> Message-ID: <45DB6A29.2080407@redhat.com> Rob Crittenden wrote: > > Can I package up the mozilla.org jar pre-signed jar file? I think that > would qualify it as a "binary distribution" though which is frowned upon. > > rob > This is an interesting question possibly for our packaging guidelines committee. It is obvious that you cannot make a reproducible signed binary as needed in this case using our current guidelines. Perhaps a scheme like this would be acceptable: 1) Spec file builds the JAR from sources. 2) Uses some kind of intelligent compare algorithm to be sure that the Java bytecode is truly identical to the signed JAR. 3) ONLY IF THEY MATCH, then throw away the built copy and ship the signed JAR. Now there are possible problems with this... 1) How error-prone or even possible is it to make reproducible JAR files that can compare in this way? 2) Does this run afoul of any licenses, like the proposed GPLv3 anti-DRM provisions? Other question... *Who* must sign the JAR file for it to be valid? Warren Togami wtogami at redhat.com From jerone at gmail.com Tue Feb 20 21:39:20 2007 From: jerone at gmail.com (Jerone Young) Date: Tue, 20 Feb 2007 15:39:20 -0600 Subject: Review of grub2 packages, anyone going to review them? In-Reply-To: <62bc09df0702201243xcfea8ccqe9dea14a55cd4936@mail.gmail.com> References: <9f50a7a00702201233k1471b70ctabe122ae22088f04@mail.gmail.com> <62bc09df0702201243xcfea8ccqe9dea14a55cd4936@mail.gmail.com> Message-ID: <9f50a7a00702201339q5f6fd4bdp8d7c91995fd496ae@mail.gmail.com> Thanks! Trying to get the ball rolling on this :-) On 2/20/07, SmootherFrOgZ wrote: > i'll have a look > > 2007/2/20, Jerone Young : > > > > Hi I submitted grub2 packages for review sometime ago. The bugzilla > > can be found here: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228255 > > > > Any idea if anyone will get to it ? > > > > -- > > fedora-extras-list mailing list > > fedora-extras-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > > > -- > Xavier > -- > French Fedora Ambassador > GPG-Key ID: F3903DEB > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > From ville.skytta at iki.fi Tue Feb 20 22:17:20 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 21 Feb 2007 00:17:20 +0200 Subject: signing a JAR file In-Reply-To: <45DB6A29.2080407@redhat.com> References: <45D23B3B.9020007@redhat.com> <45D370DB.4060309@redhat.com> <45DB6A29.2080407@redhat.com> Message-ID: <200702210017.21003.ville.skytta@iki.fi> On Tuesday 20 February 2007, Warren Togami wrote: > > Perhaps a scheme like this would be acceptable: > 1) Spec file builds the JAR from sources. > 2) Uses some kind of intelligent compare algorithm to be sure that the > Java bytecode is truly identical to the signed JAR. > 3) ONLY IF THEY MATCH, then throw away the built copy and ship the > signed JAR. Interesting idea. > Now there are possible problems with this... > 1) How error-prone or even possible is it to make reproducible JAR files > that can compare in this way? Different compilers generate at least somewhat different bytecode, and chances that the compilers used by upstream and Fedora are different are very high. Perhaps decompiling the bytecode in both the upstream jar and the built jar and comparing those would yield better results, OTOH the compiler differences might be reflected in the decompiled code too. Hm, is there a Java decompiler included in Fedora? > Other question... > *Who* must sign the JAR file for it to be valid? For JCE providers for use with Sun's Java, and applies probably to BEA as well, dunno about others, one needs to have a code signing certificate issued by Sun's JCE code signing CA. http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/HowToImplAJCEProvider.html#Step%205a From buildsys at fedoraproject.org Tue Feb 20 22:39:54 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 20 Feb 2007 17:39:54 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-20 Message-ID: <20070220223954.6645215212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 45 Coin2-2.4.5-5.fc7 SIMVoleon-2.0.1-6.fc7 SoQt-1.4.1-5.fc7 abiword-2.4.6-3.fc7 NEW amarokFS-0.4.2-4.fc7 aquamarine-0.1.9999.2-2.fc7 aria2-0.10.1-1.fc7 bdock-0.1.9999.2-1.fc7 beryl-core-0.1.9999.2-1.fc7 beryl-manager-0.1.9999.2-1.fc7 beryl-plugins-0.1.9999.2-1.fc7 beryl-settings-0.1.9999.2-1.fc7 bugzilla-2.22.2-1.fc7 cobbler-0.4.2-0.fc7 NEW eblook-1.6.1-2.fc7 emerald-0.1.9999.2-1.fc7 emerald-themes-0.1.9999.2-1.fc7 heliodor-0.1.9999.2-1.fc7 NEW hunspell-fr-0.20060915-1.fc7 NEW hunspell-hu-0.20061105-2.fc7 NEW hunspell-it-2.3-0.1.20060723.fc7 libprelude-0.9.13-1.fc7 libtelepathy-0.0.42-1.fc7 lilypond-2.10.19-1.fc7 loudmouth-1.2.0-2.fc7 NEW mosml-2.01-9.fc7 multican-0.0.5-1.fc7 NEW ntfs-config-0.5.4-4.fc7 octave-2.9.9-2.fc7 octave-forge-2006.07.09-9.fc7 NEW perl-Acme-Damn-0.03-3.fc7 NEW perl-File-ExtAttr-1.01-3.fc7 NEW perl-GStreamer-0.09-3.fc7 NEW php-pear-PHP-CodeSniffer-0.4.0-1.fc7 NEW poker-network-1.0.35-2.fc7 NEW poker2d-1.0.35-3.fc7 NEW rudeconfig-5.0.5-1.fc7 NEW sear-0.6.3-2.fc7 smolt-0.9-1.fc7 snort-2.6.1.3-1.fc7 socat-1.5.0.0-5.fc7 NEW tmda-1.1.10-4.2.fc7 xl2tpd-1.1.07-2.fc7 NEW yum-arch-2.2.2-2.fc7 yum-utils-1.1.1-1.fc7 Packages built and released for Fedora Extras 6: 20 NEW amarokFS-0.4.2-4.fc6 bugzilla-2.22.2-1.fc6 clamav-0.88.7-2.fc6 cobbler-0.4.2-0.fc6 eb-4.3-2.fc6 NEW eblook-1.6.1-2.fc6 NEW emacs-nxml-mode-0.20041004-5.fc6 libprelude-0.9.13-1.fc6 NEW mosml-2.01-9.fc6 opencv-1.0.0-1.fc6 NEW perl-Acme-Damn-0.03-3.fc6 NEW perl-GStreamer-0.09-3.fc6 NEW php-pear-PHP-CodeSniffer-0.4.0-1.fc6 NEW poker-network-1.0.35-2.fc6 NEW poker2d-1.0.35-3.fc6 NEW sear-0.6.3-2.fc6 smolt-0.9-1.fc6 socat-1.5.0.0-5.fc6 NEW tmda-1.1.10-4.2.fc6 NEW yum-arch-2.2.2-2.fc6 Packages built and released for Fedora Extras 5: 14 NEW amarokFS-0.4.2-4.fc5 bugzilla-2.22.2-1.fc5 clamav-0.88.7-2.fc5 cobbler-0.4.2-0.fc5 NEW eb-4.3-2.fc5 NEW eblook-1.6.1-2.fc5 libprelude-0.9.13-1.fc5 NEW perl-Acme-Damn-0.03-3.fc5 NEW perl-GStreamer-0.09-3.fc5 NEW poker-network-1.0.35-2.fc5.1 NEW poker2d-1.0.35-3.fc5.1 smolt-0.9-1.fc5 NEW socat-1.5.0.0-2.fc5 NEW tmda-1.1.10-4.2.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From orion at cora.nwra.com Tue Feb 20 22:46:36 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 20 Feb 2007 15:46:36 -0700 Subject: Where is Fedora Directory Server? Message-ID: <45DB7A4C.1040202@cora.nwra.com> Appears to be checked in and built for FC5+, but I don't see it in http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From dennis at ausil.us Tue Feb 20 22:54:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 20 Feb 2007 16:54:00 -0600 Subject: Where is Fedora Directory Server? In-Reply-To: <45DB7A4C.1040202@cora.nwra.com> References: <45DB7A4C.1040202@cora.nwra.com> Message-ID: <200702201654.00910.dennis@ausil.us> On Tuesday 20 February 2007 04:46:36 pm Orion Poplawski wrote: > Appears to be checked in and built for FC5+, but I don't see it in > http://download.fedora.redhat.com/pub/fedora/linux/extras/5/i386/. > Its about to get renamed to fedora-ds-base it provides only some of the functionality of the old fedora-ds package provided by the ds guys the admin tools are not yet packaged in their own bits. the problem is that it upgrades prior installs but does not provide the same functionality. once all the pieces are in place a fedora-ds meta package will be submitted that requires all the admin tools -- Dennis Gilmore, RHCE From lxtnow at gmail.com Tue Feb 20 23:54:02 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Tue, 20 Feb 2007 19:54:02 -0400 Subject: CVSTAG Message-ID: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> Hi, Is there someone can know how to untag a branch to "make build" for another one. i "make tag" for Devel branch to build. Now i'm unable to tag another branch such as FC-6 here is the following error: ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a different branch ERROR: You can not forcibly move tags between branches cheers, -- Xavier.t Lamien -- French Fedora Ambassador GPG-Key ID: F3903DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at poolshark.org Wed Feb 21 07:53:53 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 21 Feb 2007 08:53:53 +0100 Subject: CVSTAG In-Reply-To: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> References: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> Message-ID: <45DBFA91.40309@poolshark.org> SmootherFrOgZ wrote: > Hi, > > Is there someone can know how to untag a branch to "make build" for > another one. > > i "make tag" for Devel branch to build. > Now i'm unable to tag another branch such as FC-6 > here is the following error: > > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a different > branch > ERROR: You can not forcibly move tags between branches Looks like something went haywire. Make sure to always do a 'cvs update' before working on things, including the common directory. In your case, you need to use the force tag option, like this: make tag TAG_OPTS=-F -denis From chris.stone at gmail.com Wed Feb 21 07:59:47 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 20 Feb 2007 23:59:47 -0800 Subject: CVSTAG In-Reply-To: <45DBFA91.40309@poolshark.org> References: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> <45DBFA91.40309@poolshark.org> Message-ID: On 2/20/07, Denis Leroy wrote: > SmootherFrOgZ wrote: > > Hi, > > > > Is there someone can know how to untag a branch to "make build" for > > another one. > > > > i "make tag" for Devel branch to build. > > Now i'm unable to tag another branch such as FC-6 > > here is the following error: > > > > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a different > > branch > > ERROR: You can not forcibly move tags between branches > > Looks like something went haywire. Make sure to always do a 'cvs update' > before working on things, including the common directory. > > In your case, you need to use the force tag option, like this: > > make tag TAG_OPTS=-F This error also occurs when using cvs-import.sh --branch From paul at city-fan.org Wed Feb 21 09:01:27 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 21 Feb 2007 09:01:27 +0000 Subject: Orphanizing the OrphanedPackages Wiki page In-Reply-To: <45DB63A9.1020109@redhat.com> References: <20070220212322.add7edba.bugs.michael@gmx.net> <45DB63A9.1020109@redhat.com> Message-ID: <1172048487.4239.4.camel@metropolis.intra.city-fan.org> On Tue, 2007-02-20 at 16:10 -0500, Warren Togami wrote: > Michael Schwendt wrote: > > After sending this message, I won't keep an eye on the OrphanedPackages > > Wiki page and on orphaned packages anymore. I will also discontinue with > > monitoring the orphan owner in bugzilla. With the locks on owners.list > > and CVS it makes no sense to continue with such activities. > > I believe maintaining this in two places is too much manual work in the > long-term. > > Perhaps we should have a script that reads owners.list and to > auto-generates a static page that displays the orphans? This could be > written independently of anything else. > > http://rubenkerkhof.com/review > Something like this... except generated with links to the CVS of each > orphaned package. > > Any volunteers to write this? Pretty easy project. It's not just a list of orphaned packages though. Some of the packages have associated information about people volunteering to maintain them for instance, or historical details. Paul. From paul at city-fan.org Wed Feb 21 09:06:07 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 21 Feb 2007 09:06:07 +0000 Subject: CVSTAG In-Reply-To: References: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> <45DBFA91.40309@poolshark.org> Message-ID: <1172048767.4239.8.camel@metropolis.intra.city-fan.org> On Tue, 2007-02-20 at 23:59 -0800, Christopher Stone wrote: > On 2/20/07, Denis Leroy wrote: > > SmootherFrOgZ wrote: > > > Hi, > > > > > > Is there someone can know how to untag a branch to "make build" for > > > another one. > > > > > > i "make tag" for Devel branch to build. > > > Now i'm unable to tag another branch such as FC-6 > > > here is the following error: > > > > > > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a different > > > branch > > > ERROR: You can not forcibly move tags between branches > > > > Looks like something went haywire. Make sure to always do a 'cvs update' > > before working on things, including the common directory. > > > > In your case, you need to use the force tag option, like this: > > > > make tag TAG_OPTS=-F > > This error also occurs when using cvs-import.sh --branch It also occurs if you import an SRPM into devel that was built with %{dist} set to the appropriate tag for another branch, e.g. an SRPM built using mock in an FC6 buildroot. Paul. From belegdol at gmail.com Wed Feb 21 13:29:12 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 21 Feb 2007 13:29:12 +0000 Subject: Packaging kernel modules Message-ID: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> Hi. Although my laptop is not yet (blame Toshiba) supported by it, I've been thinking about packaging the omnibook kernel module [1]. Is there any template I could start with, or shall I just take one of the kmod-foo specs and edit it accordingly? And are there any other things I should know about? From jkeating at redhat.com Wed Feb 21 14:37:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 09:37:44 -0500 Subject: Packaging kernel modules In-Reply-To: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> References: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> Message-ID: <200702210937.44400.jkeating@redhat.com> On Wednesday 21 February 2007 08:29, Julian Sikorski wrote: > Hi. Although my laptop is not yet (blame Toshiba) supported by it, > I've been thinking about packaging the omnibook kernel module [1]. Is > there any template I could start with, or shall I just take one of the > kmod-foo specs and edit it accordingly? And are there any other things > I should know about? Why is the omnibook kernel module not upstream yet? -- 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 belegdol at gmail.com Wed Feb 21 14:41:40 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 21 Feb 2007 14:41:40 +0000 Subject: Packaging kernel modules In-Reply-To: <200702210937.44400.jkeating@redhat.com> References: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> <200702210937.44400.jkeating@redhat.com> Message-ID: <9b1b20e70702210641i3af912c7lcd99c5a7efeb9d12@mail.gmail.com> I guess that's because it is regarded as experimental by its author. 2007/2/21, Jesse Keating : > On Wednesday 21 February 2007 08:29, Julian Sikorski wrote: > > Hi. Although my laptop is not yet (blame Toshiba) supported by it, > > I've been thinking about packaging the omnibook kernel module [1]. Is > > there any template I could start with, or shall I just take one of the > > kmod-foo specs and edit it accordingly? And are there any other things > > I should know about? > > > Why is the omnibook kernel module not upstream yet? > > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > From mr.ecik at gmail.com Wed Feb 21 13:36:20 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Wed, 21 Feb 2007 14:36:20 +0100 Subject: Packaging kernel modules In-Reply-To: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> References: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> Message-ID: <668bb39a0702210536l7ac2b1dub6adfff7aca6c17b@mail.gmail.com> This should be useful: http://fedoraproject.org/wiki/Packaging/KernelModules 2007/2/21, Julian Sikorski : > Hi. Although my laptop is not yet (blame Toshiba) supported by it, > I've been thinking about packaging the omnibook kernel module [1]. Is > there any template I could start with, or shall I just take one of the > kmod-foo specs and edit it accordingly? And are there any other things > I should know about? > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Micha? Bentkowski mr.ecik at gmail.com From fedora at leemhuis.info Wed Feb 21 14:51:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Feb 2007 15:51:35 +0100 Subject: Packaging kernel modules In-Reply-To: <9b1b20e70702210641i3af912c7lcd99c5a7efeb9d12@mail.gmail.com> References: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> <200702210937.44400.jkeating@redhat.com> <9b1b20e70702210641i3af912c7lcd99c5a7efeb9d12@mail.gmail.com> Message-ID: <45DC5C77.5010103@leemhuis.info> On 21.02.2007 15:41, Julian Sikorski wrote: > I guess that's because it is regarded as experimental by its author. That's why CONFIG_EXPERIMENTAL exists ;-) CU thl > 2007/2/21, Jesse Keating : >> On Wednesday 21 February 2007 08:29, Julian Sikorski wrote: >>> Hi. Although my laptop is not yet (blame Toshiba) supported by it, >>> I've been thinking about packaging the omnibook kernel module [1]. Is >>> there any template I could start with, or shall I just take one of the >>> kmod-foo specs and edit it accordingly? And are there any other things >>> I should know about? >> >> Why is the omnibook kernel module not upstream yet? >> >> >> -- >> Jesse Keating >> Release Engineer: Fedora >> >> -- >> fedora-extras-list mailing list >> fedora-extras-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-extras-list >> >> >> > From jkeating at redhat.com Wed Feb 21 14:55:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 09:55:45 -0500 Subject: Fwd: Build Result: 27977 - pungi on fedora-development-extras Message-ID: <200702210955.45779.jkeating@redhat.com> Although we're in a freeze, it would be good for this to get pushed out, so that everybody at home can play along with the same pungi I'm using for composing Test2. There may be more updates if I find bugs/improvements during the test2 compose trials. ---------- Forwarded Message ---------- Subject: Build Result: 27977 - pungi on fedora-development-extras Date: Wednesday 21 February 2007 09:49 From: buildsys at fedoraproject.org To: jkeating at redhat.com 27977 (pungi): Build on target fedora-development-extras succeeded. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/27977-pungi -0.2.5-1.fc7/ ------------------------------------------------------- -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed Feb 21 14:55:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Feb 2007 08:55:54 -0600 Subject: Packaging kernel modules In-Reply-To: <9b1b20e70702210641i3af912c7lcd99c5a7efeb9d12@mail.gmail.com> References: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> <200702210937.44400.jkeating@redhat.com> <9b1b20e70702210641i3af912c7lcd99c5a7efeb9d12@mail.gmail.com> Message-ID: <1172069754.24204.161.camel@zod.rchland.ibm.com> On Wed, 2007-02-21 at 14:41 +0000, Julian Sikorski wrote: > I guess that's because it is regarded as experimental by its author. The driver hasn't been touched in over a year. The last release was Jan of 2006. Are you sure it's even active still? josh From j.w.r.degoede at hhs.nl Wed Feb 21 15:26:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 21 Feb 2007 16:26:36 +0100 Subject: Proposal: cross-compiling / development packaging guidelines Message-ID: <45DC64AC.2050804@hhs.nl> Hi All, As you all know by now I'm working as a computer science teacher on a Dutch university. In a few our lab exercises we use Atmel AVR microcontroller kits and I'm working on a lab using the gp2x handheld console (ARM linux machine). Currently the AVR labs are given using winavr, running on that other OS. I and a couple other teachers are interested in also having a toolchain for AVR available under Linux and I also would like to see a toochain for the gp2x under Linux. Thus we have given a group of 3 students the assignment to create high quality rpm packages of binutils gcc and the needed libs for Fedora to allow crosscompiling to Atmel AVR / ARM Linux on Fedora. I'm personally coaching these students and unless they want to go through the sponsor process themsleves, I will submit the resulting packages for review myself and maintain them in the future. Now that the setting of all this is clear on to the more interesting stuff how should cross-devel packages for Fedora look? Proposal: 1) binutils, gcc, glibc and other libraries for avr / arm-linux will use the exact same upstream version as the native versions where-ever possible 2) All package names will be prefixed with the same prefix as binutils and gcc use, examples: avr-binutils, avr-gcc, arm-linux-binutils, arm-linux-gcc, arm-linux-glibc 3) The as,ld and gcc binaries: * will be named avr-as, avr-ld and avr-gcc resp arm-linux-as, arm-linux-ld arm-linux-gcc * will be installed under /usr/bin * will have links called as, ld and gcc installed under /usr/avr/bin resp /usr/arm-linux/bin. More on these dirs below 4) libraries respectively headers will be installed under /usr/avr/lib resp /usr/avr/include for avr and under /usr/arm-linux/lib resp /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS compliant, still I believe this is the right way, rationale: * These path's are advised in the cross-compiler guidelines in gcc's INSTALL document * All cross-compile setup howto's / docs on the internet I could find use path's like this. IOW: "The compiling environments are well defined already, established in the standards, there is absolutely no compelling reason to move it to something Fedora specific." * We (Fedora/RH) have done this before with the libc5-compat stuff under /usr/i386-linux-libc5/{lib,include} * Quoting the FHS on this: "No large package (such as TeX and GNU Emacs) should use a direct subdirectory of /usr. Instead, there should be a subdirectory within /usr/lib (or /usr/local/lib if it was installed completely locally) for the purpose. An exception is made for the X Window System because of considerable precedent and widely-accepted practice.". I think using /usr/avr / /usr/arm-linux is ok with this paragraph as: 1) a cross-compile setup is not a single large package 2) Just like the X Window System (which we've moved out of its own dir BTW), there is "considerable precedent and widely-accepted practice." * Doing things like this is also where Debian ended up after ample discussion see: http://lists.debian.org/debian-policy/1999/04/msg00015.html Notice that today (7 years later) Debian is still doing things this way! 5) Docs (manpages, info and docs under %doc) will not be installed as they will be identical to the native version docs, instead a readme.fedora will be installed through %doc redirecting people to the native docs, and informing them what native package to install to get the docs if not installed already. So for example when people look under /use/share/doc/arm-linux-SDL-devel-%{version} they will find a readme.fedora redirecting them to /usr/share/doc/SDL-devel-%{version} and be told that if that dir does not exist that they then should install SDL-devel. Problems: 7) With the arm-linux target some libraries may have target specific compile options, for example the gp2x handheld uses a special version of SDL with patches to support the gp2x input buttons and video. Proposed solution: a) install headers and libs for special platforms/targets under their own dir, for gp2x that would be /usr/arm-linux-gp2x/{lib,include} b) and then create binutils and gcc wrappers called special-prefix-binname, for example arm-linux-gp2x-gcc, these wrappers add /usr/arm-linux-gp2x/{lib,include} to the beginning of the lib / /include search paths and add flags for the cpu-type and other hardware specifics. These wrappers would be put in a package called gp2x-devel, which besides containing these wrappers would also Requires: all the necesarry bits, so that someone who wants todo gp2x development can just do a "yum install gp2x-devel" and get started. 8) The SRPMS for all these packages will most of the time contain the exact same tarbals as the native binutils / gcc / libs Possible solutions: a) Live with the extra diskspace / bandwidth cost this induces upon our mirrors b) *** Warning dirty hack *** Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep and if it isn't there bail with a message howto get the tarbal from the srpms for the native packages. We can use the sources file and the look-aside cache to make the test for the tarbal succeed on the buildsys. Advantages: saves tons of diskspace. Disadvantage: slight inconvienience for people trying to rebuild the srpm's manually. Large inconvienience for people doing automated rebuilds (aurora for example) I honestly don't know what todo here. I kinda like solution b), except for the pain it causes to aurora and possible others. Well thats it (for know) I'm sure when we start actually building these packages new issues will arive but first lets all agree on howto handle the issues discussed above. Talking about all agreeing on this, if there are enough people interested I would like to start an embedded / cross-compiling Fedora SIG, any takers? Regards, Hans From rc040203 at freenet.de Wed Feb 21 16:10:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Feb 2007 17:10:28 +0100 Subject: Proposal: cross-compiling / development packaging guidelines In-Reply-To: <45DC64AC.2050804@hhs.nl> References: <45DC64AC.2050804@hhs.nl> Message-ID: <1172074229.23237.157.camel@mccallum.corsepiu.local> On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote: > Hi All, Comments interspersed ... > Now that the setting of all this is clear on to the more interesting stuff > how should cross-devel packages for Fedora look? Proposal: > > 1) binutils, gcc, glibc and other libraries for avr / arm-linux will use the > exact same upstream version as the native versions where-ever possible > > 2) All package names will be prefixed with the same prefix as binutils and > gcc use, examples: > avr-binutils, avr-gcc, arm-linux-binutils, arm-linux-gcc, arm-linux-glibc Fine with me - It's the same approach am I am using for my cross-rpms. > 3) The as,ld and gcc binaries: > * will be named avr-as, avr-ld and avr-gcc resp arm-linux-as, arm-linux-ld > arm-linux-gcc > * will be installed under /usr/bin > * will have links called as, ld and gcc installed under /usr/avr/bin resp > /usr/arm-linux/bin. More on these dirs below This is the default with GCC. > 4) libraries respectively headers will be installed under /usr/avr/lib resp > /usr/avr/include for avr and under /usr/arm-linux/lib resp > /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS > compliant, still I believe this is the right way, The default for GCC is ${prefix}/$(target)/{lib|include}. This default is almost impossible to change. > 5) Docs (manpages, info and docs under %doc) will not be installed as they > will be identical to the native version docs, What you say only partially applies to gcc/binutils/gdb. Their section 3 man-pages are canonicalized (they install as -manpage), hence are free of conflicts with a native gcc. section-7 man-pages and infos however conflict. > Problems: > > 7) With the arm-linux target some libraries may have target specific compile > options, for example the gp2x handheld uses a special version of SDL with > patches to support the gp2x input buttons and video. > > Proposed solution: > a) install headers and libs for special platforms/targets under their own > dir, for gp2x that would be /usr/arm-linux-gp2x/{lib,include} That's the standard GCC approach for cross-toolchains. > b) and then create binutils and gcc wrappers called special-prefix-binname, > for example arm-linux-gp2x-gcc, these wrappers add > /usr/arm-linux-gp2x/{lib,include} to the beginning of the lib / > /include search paths and add flags for the cpu-type and other > hardware specifics. These wrappers would be put in a package called > gp2x-devel, which besides containing these wrappers would also Requires: > all the necesarry bits, so that someone who wants todo gp2x development > can just do a "yum install gp2x-devel" and get started. This is the classical standard GCC wrapper approach for non-multilib'ed cross-toolchains. > 8) The SRPMS for all these packages will most of the time contain the exact > same tarbals as the native binutils / gcc / libs > > Possible solutions: > a) Live with the extra diskspace / bandwidth cost this induces upon > our mirrors That's what I'd do. An alternative would be to build different versions inside of the same SRPMS at one time. Ralf From orion at cora.nwra.com Wed Feb 21 16:44:52 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 21 Feb 2007 09:44:52 -0700 Subject: php-Smarty Message-ID: <45DC7704.7020402@cora.nwra.com> I'm currently the maintainer of php-Smarty. Two items: - Could someone who is running php-Smarty on FC6 please try out the following update: http://www.cora.nwra.com/~orion/fedora/php-Smarty-2.6.16-1.fc6.noarch.rpm * Wed Feb 21 2007 Orion Poplawski 2.6.16-1 - Update to 2.6.16 - Install in /usr/share/php/Smarty - Update php version requirement I'd be interested in knowing if moving the install location causes any problems, or if with the changes to php supporting /usr/share/php everything is smooth. - I no longer run php-Smarty, so I'd be happy if someone else who does volunteered to maintain it. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From belegdol at gmail.com Wed Feb 21 17:27:54 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 21 Feb 2007 17:27:54 +0000 Subject: Packaging kernel modules In-Reply-To: <1172069754.24204.161.camel@zod.rchland.ibm.com> References: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> <200702210937.44400.jkeating@redhat.com> <9b1b20e70702210641i3af912c7lcd99c5a7efeb9d12@mail.gmail.com> <1172069754.24204.161.camel@zod.rchland.ibm.com> Message-ID: <9b1b20e70702210927sef69404qe56d2a6fe12aba6@mail.gmail.com> Last release is 2.20070211. Are you checking the right homepage? http://omnibook.sourceforge.net 2007/2/21, Josh Boyer : > On Wed, 2007-02-21 at 14:41 +0000, Julian Sikorski wrote: > > I guess that's because it is regarded as experimental by its author. > > The driver hasn't been touched in over a year. The last release was Jan > of 2006. Are you sure it's even active still? > > josh > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > From kwizart at gmail.com Wed Feb 21 17:34:17 2007 From: kwizart at gmail.com (kwizart) Date: Wed, 21 Feb 2007 18:34:17 +0100 Subject: Review Request: elektra - /etc/profiles.d question and .csh needed... Message-ID: <45DC8299.8060403@gmail.com> Hello I have few questions about packaging elektra: See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209906 Summary: A key/value pair database to store software configurations By default the file installed in /etc/profile.d have executable bit set and own a shebang. Then it lead to the rpmlint error: E: elektra sourced-script-with-shebang /etc/profile.d/elektra-elektraenv.sh E: elektra executable-sourced-script /etc/profile.d/elektra-elektraenv.sh 0755 Fixing this at install step would lead to do this : (as petrus have done). # file in profile.d is sourced, remove shebang and execute bits sed -i -e 's;#!/bin/sh;;' $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/elektra-elektraenv.sh chmod a-x $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/elektra-elektraenv.sh and files section will have: %config(noreplace) %{_sysconfdir}/profile.d/*.sh Then rpmlint remain quiet: So my question is what is the current state of art about this question? Most of the packages i have found in /etc/profiles.d (fc6) own the shebang and have executable bit set... The second part is: i need a csh version of that script to be included to satisfied csh users... Can anyone can check for changes needed to this conversion? Here is the file : http://kwizart.free.fr/fedora/6/testing/elektra/elektraenv.sh I plan to package oyranos that will need elektra (oyranos is needed by cinepaint which is currently reviewed here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225522 ) Third part would be to sort all packages that need elektra or could enable elektra options I wonder if a bugzilla entry would be created to list packages for this when the elektra package will be stabilized Nicolas (kwizart) From sailer at sailer.dynip.lugs.ch Wed Feb 21 17:44:39 2007 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Wed, 21 Feb 2007 18:44:39 +0100 Subject: Proposal: cross-compiling / development packaging guidelines Message-ID: <1172079879.3139.83.camel@playstation2.hb9jnx.ampr.org> On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote: > Thus we have given a group of 3 students the assignment to create > high quality rpm packages of binutils gcc and the needed libs for Fedora to > allow crosscompiling to Atmel AVR / ARM Linux on Fedora. I'm personally Great! I'm very much looking forward to these packages. > 4) libraries respectively headers will be installed under /usr/avr/lib resp > /usr/avr/include for avr and under /usr/arm-linux/lib resp > /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS > compliant, still I believe this is the right way, rationale: Why not /usr/share/avr/include, /usr/share/arm-linux/lib etc.? From the view of the host, this is shareable data, i.e. I can use the same data with an i386 avr-gcc or a ppc avr-gcc, no? Tom From rc040203 at freenet.de Wed Feb 21 17:51:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Feb 2007 18:51:53 +0100 Subject: Proposal: cross-compiling / development packaging guidelines In-Reply-To: <1172079879.3139.83.camel@playstation2.hb9jnx.ampr.org> References: <1172079879.3139.83.camel@playstation2.hb9jnx.ampr.org> Message-ID: <1172080314.23237.170.camel@mccallum.corsepiu.local> On Wed, 2007-02-21 at 18:44 +0100, Thomas Sailer wrote: > On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote: > > > Thus we have given a group of 3 students the assignment to create > > high quality rpm packages of binutils gcc and the needed libs for Fedora to > > allow crosscompiling to Atmel AVR / ARM Linux on Fedora. I'm personally > > Great! I'm very much looking forward to these packages. > > > 4) libraries respectively headers will be installed under /usr/avr/lib resp > > /usr/avr/include for avr and under /usr/arm-linux/lib resp > > /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS > > compliant, still I believe this is the right way, rationale: > > Why not /usr/share/avr/include, /usr/share/arm-linux/lib etc.? As I previously wrote, because this would be very hard to implement into GCC. > From the > view of the host, this is shareable data, i.e. I can use the same data > with an i386 avr-gcc or a ppc avr-gcc, no? Yes, this would be shareable data. With one exception: Its location is hard-coded into GCC. Ralf From ch.nolte at noltec.org Wed Feb 21 17:56:33 2007 From: ch.nolte at noltec.org (Christian Nolte) Date: Wed, 21 Feb 2007 18:56:33 +0100 Subject: Second Life client packaged for Fedora In-Reply-To: <1171618531.2953.14.camel@localhost.localdomain> References: <1171618531.2953.14.camel@localhost.localdomain> Message-ID: <45DC87D1.9060505@noltec.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Callum! Callum Lerwick schrieb: > Okay, after much pain, sorrow and apparently duplicated effort[*] I > finally managed to get a vaguely usable Second Life package + deps: > > http://www.haxxed.com/rpms/secondlife/ > > * spot has some packages too: > > http://www.auroralinux.org/people/spot/SecondLife/ > > Don't expect his and mine to be interchangeable just yet. I guess we > have some merging to do... > Thanks for your time and effort with this! The only problem I've encountered was that it is explicitly necessary to define ARCH=i686 before the secondlife-firstlook SRPM can be built. This is a problem of the linden/indra/Scons script which only accepts i686 as valid arch. Best regards! Christian - -- Christian Nolte key : http://www.noltec.org/christian-nolte.asc or : www.keyserver.net GPG-fingerprint: 1088 6C2D 1496 0A34 D159 1108 08D8 C0D2 77E1 5BBC - ---------------------------------------------------------------- For more than 4 generations the IT Professionals were the guardians of quality and stability in software. Before the dark times. Before Microsoft... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF3IfRCNjA0nfhW7wRAjF5AJ4wBqLGlDXobHwTh1MdlqP/7d7tywCfR5nl ppn7qW4tkfnGj70aaVdB8+Q= =7S4U -----END PGP SIGNATURE----- From lsof at nodata.co.uk Wed Feb 21 18:34:07 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 21 Feb 2007 19:34:07 +0100 Subject: Second Life client packaged for Fedora In-Reply-To: <45DC87D1.9060505@noltec.org> References: <1171618531.2953.14.camel@localhost.localdomain> <45DC87D1.9060505@noltec.org> Message-ID: <1172082847.19442.3.camel@sb-home.lan> Am Mittwoch, den 21.02.2007, 18:56 +0100 schrieb Christian Nolte: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Callum! > > Callum Lerwick schrieb: > > Okay, after much pain, sorrow and apparently duplicated effort[*] I > > finally managed to get a vaguely usable Second Life package + deps: > > > > http://www.haxxed.com/rpms/secondlife/ > > > > * spot has some packages too: > > > > http://www.auroralinux.org/people/spot/SecondLife/ > > > > Don't expect his and mine to be interchangeable just yet. I guess we > > have some merging to do... > > > > Thanks for your time and effort with this! > > The only problem I've encountered was that it is explicitly necessary to > define ARCH=i686 before the secondlife-firstlook SRPM can be built. This > is a problem of the linden/indra/Scons script which only accepts i686 as > valid arch. > > Best regards! > Christian > > - -- > Christian Nolte > > key : http://www.noltec.org/christian-nolte.asc > or : www.keyserver.net > > GPG-fingerprint: > 1088 6C2D 1496 0A34 D159 1108 08D8 C0D2 77E1 5BBC > - ---------------------------------------------------------------- > For more than 4 generations the IT Professionals were the > guardians of quality and stability in software. Before the > dark times. Before Microsoft... > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFF3IfRCNjA0nfhW7wRAjF5AJ4wBqLGlDXobHwTh1MdlqP/7d7tywCfR5nl > ppn7qW4tkfnGj70aaVdB8+Q= > =7S4U > -----END PGP SIGNATURE----- > Does second life obey http_proxy? From ville.skytta at iki.fi Wed Feb 21 18:44:45 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 21 Feb 2007 20:44:45 +0200 Subject: Review Request: elektra - /etc/profiles.d question and .csh needed... In-Reply-To: <45DC8299.8060403@gmail.com> References: <45DC8299.8060403@gmail.com> Message-ID: <200702212044.45875.ville.skytta@iki.fi> On Wednesday 21 February 2007, kwizart wrote: > Most of the packages i have found in > /etc/profiles.d (fc6) own the shebang and have executable bit set... It's likely that all those are minor packaging bugs/oversights. Executing profile scripts isn't generally useful because the invoking shell's environment is not affected by whatever variables the profile script sets, and there's no need for scripts to be executable in order to be sourced. Some more background info: https://bugzilla.redhat.com/225983#c5 From fedora at leemhuis.info Wed Feb 21 18:47:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Feb 2007 19:47:15 +0100 Subject: Small heads up: Discussion around EPEL now on fedora-devel Message-ID: <45DC93B3.9080004@leemhuis.info> Hi, just a heads up on this lists (?) -- I posted some thoughts about EPEL and the way forward to fedora-devel list; see https://www.redhat.com/archives/fedora-devel-list/2007-February/msg01085.html for details. Please participate in that discussion there if you are interested. tia! CU thl (?) -- ohh boy, this mailing list mess really needs to be sorted out soon -- it gets more and more annoying. I'm still waiting for feedback from some redhat guys how we actually want to move on regarding the serer side for mailman (own server? seperate domain for fedora? leave everything as it is and just kleen up the lists) before we can move on... From chris.stone at gmail.com Wed Feb 21 19:07:02 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 21 Feb 2007 11:07:02 -0800 Subject: php-Smarty In-Reply-To: <45DC7704.7020402@cora.nwra.com> References: <45DC7704.7020402@cora.nwra.com> Message-ID: On 2/21/07, Orion Poplawski wrote: > I'm currently the maintainer of php-Smarty. Two items: > > - Could someone who is running php-Smarty on FC6 please try out the > following update: > > http://www.cora.nwra.com/~orion/fedora/php-Smarty-2.6.16-1.fc6.noarch.rpm > > * Wed Feb 21 2007 Orion Poplawski 2.6.16-1 > - Update to 2.6.16 > - Install in /usr/share/php/Smarty > - Update php version requirement > > I'd be interested in knowing if moving the install location causes any > problems, or if with the changes to php supporting /usr/share/php > everything is smooth. Works like a charm. > > - I no longer run php-Smarty, so I'd be happy if someone else who does > volunteered to maintain it. I can maintain it, not sure how the new process to fix owners.list works though. From lxtnow at gmail.com Wed Feb 21 19:08:49 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Wed, 21 Feb 2007 15:08:49 -0400 Subject: CVSTAG In-Reply-To: References: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> <45DBFA91.40309@poolshark.org> Message-ID: <62bc09df0702211108m49ba5a16u59e4fa6a4e8d1412@mail.gmail.com> 2007/2/21, Christopher Stone : > > On 2/20/07, Denis Leroy wrote: > > SmootherFrOgZ wrote: > > > Hi, > > > > > > Is there someone can know how to untag a branch to "make build" for > > > another one. > > > > > > i "make tag" for Devel branch to build. > > > Now i'm unable to tag another branch such as FC-6 > > > here is the following error: > > > > > > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a > different > > > branch > > > ERROR: You can not forcibly move tags between branches > > > > Looks like something went haywire. Make sure to always do a 'cvs update' > > before working on things, including the common directory. > > > > In your case, you need to use the force tag option, like this: > > > > make tag TAG_OPTS=-F > > This error also occurs when using cvs-import.sh --branch > > tried with your command, same thing: cvs tag -F -c ntfs-config-0_5_4-4_fc6 Enter passphrase for key '/home/lxtnow/.ssh/id_dsa': ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a different branch ERROR: You can not forcibly move tags between branches cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 i'm working to resolve this error. -- Xavier -- French Fedora Ambassador GPG-Key ID: F3903DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Wed Feb 21 20:14:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Feb 2007 14:14:14 -0600 Subject: Packaging kernel modules In-Reply-To: <9b1b20e70702210927sef69404qe56d2a6fe12aba6@mail.gmail.com> References: <9b1b20e70702210529l777084a6gafa1d1e87207f05@mail.gmail.com> <200702210937.44400.jkeating@redhat.com> <9b1b20e70702210641i3af912c7lcd99c5a7efeb9d12@mail.gmail.com> <1172069754.24204.161.camel@zod.rchland.ibm.com> <9b1b20e70702210927sef69404qe56d2a6fe12aba6@mail.gmail.com> Message-ID: <1172088854.24204.192.camel@zod.rchland.ibm.com> On Wed, 2007-02-21 at 17:27 +0000, Julian Sikorski wrote: > Last release is 2.20070211. Are you checking the right homepage? > http://omnibook.sourceforge.net Nope, sorry. I was looking here: http://sourceforge.net/project/showfiles.php?group_id=48623&package_id=47019 josh From tibbs at math.uh.edu Wed Feb 21 20:40:51 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Feb 2007 14:40:51 -0600 Subject: php-Smarty In-Reply-To: References: <45DC7704.7020402@cora.nwra.com> Message-ID: >>>>> "CS" == Christopher Stone writes: CS> I can maintain it, not sure how the new process to fix owners.list CS> works though. Find the review ticket, set fedora-cvs? and add a comment saying that you want to change the ownership of the package. If there's no review ticket, just open a new ticket, set fedora-cvs?, explain what's happening and ask for the ownership change. - J< From bugzilla at redhat.com Wed Feb 21 21:13:07 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 21 Feb 2007 16:13:07 -0500 Subject: [Bug 170701] Review Request: php-Smarty - Template/Presentation Framework for PHP In-Reply-To: Message-ID: <200702212113.l1LLD71l031490@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: php-Smarty - Template/Presentation Framework for PHP https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170701 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-extras- | |list at redhat.com | CC| |fedora-package- | |review at redhat.com CC|fedora-package- | |review at redhat.com | CC| |fedora-extras- | |list at redhat.com chris.stone at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs? ------- Additional Comments From chris.stone at gmail.com 2007-02-21 16:12 EST ------- Ownership change request, see: https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00331.html New owner should be: chris.stone at gmail.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From giallu at gmail.com Wed Feb 21 21:16:06 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Feb 2007 22:16:06 +0100 Subject: php-Smarty In-Reply-To: References: <45DC7704.7020402@cora.nwra.com> Message-ID: On 21 Feb 2007 14:40:51 -0600, Jason L Tibbitts III wrote: > >>>>> "CS" == Christopher Stone writes: > > CS> I can maintain it, not sure how the new process to fix owners.list > CS> works though. > > Find the review ticket, set fedora-cvs? and add a comment saying that > you want to change the ownership of the package. > > If there's no review ticket, just open a new ticket, set fedora-cvs?, > explain what's happening and ask for the ownership change. > Tried yesterday here but as of now it did not worked... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197565 From orion at cora.nwra.com Wed Feb 21 21:17:01 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 21 Feb 2007 14:17:01 -0700 Subject: php-Smarty In-Reply-To: References: <45DC7704.7020402@cora.nwra.com> Message-ID: <45DCB6CD.40106@cora.nwra.com> Christopher Stone wrote: > On 2/21/07, Orion Poplawski wrote: >> I'd be interested in knowing if moving the install location causes any >> problems, or if with the changes to php supporting /usr/share/php >> everything is smooth. > > Works like a charm. > >> >> - I no longer run php-Smarty, so I'd be happy if someone else who does >> volunteered to maintain it. > > I can maintain it, not sure how the new process to fix owners.list works > though. > Great. I've checked in my changes, but have not requested a build. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jkeating at redhat.com Wed Feb 21 22:12:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Feb 2007 17:12:55 -0500 Subject: Fwd: Build Result: 27977 - pungi on fedora-development-extras In-Reply-To: <200702210955.45779.jkeating@redhat.com> References: <200702210955.45779.jkeating@redhat.com> Message-ID: <200702211712.55735.jkeating@redhat.com> On Wednesday 21 February 2007 09:55, Jesse Keating wrote: > Although we're in a freeze, it would be good for this to get pushed out, so > that everybody at home can play along with the same pungi I'm using for > composing Test2. ?There may be more updates if I find bugs/improvements > during the test2 compose trials. I found a bad bug and built another pungi to fix this. Please make sure that this new pungi sees the light of day. -- 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 buildsys at fedoraproject.org Wed Feb 21 22:27:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Feb 2007 17:27:45 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-21 Message-ID: <20070221222745.285C315212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 16 Pound-2.2.5-1.fc7 NEW dbmail-2.2.2-9.fc7 dia-0.95-8.fc7 gossip-0.22-3.fc7 gstreamer-python-0.10.7-2.fc7 loudmouth-1.2.0-3.fc7 NEW moto4lin-0.3-6.fc7 nazghul-0.5.6-1.fc7 ntfs-3g-1.0-1.fc7 perl-Image-ExifTool-6.77-1.fc7 perl-Template-Toolkit-2.18-1.fc7 perl-Test-LongString-0.11-1.fc7 pungi-0.2.5-1.fc7 rawstudio-0.5.1-1.fc7 rssowl-1.2.3-2.fc7 telepathy-gabble-0.5.1-2.fc7 Packages built and released for Fedora Extras 6: 12 Coin2-2.4.5-5.fc6 SIMVoleon-2.0.1-6.fc6 SoQt-1.4.1-5.fc6 NEW dbmail-2.2.2-9.fc6 dia-0.95-8.fc6 gstreamer-python-0.10.7-2.fc6 NEW moto4lin-0.3-6.fc6 ntfs-3g-1.0-1.fc6 perl-Image-ExifTool-6.77-1.fc6 perl-Template-Toolkit-2.18-1.fc6 perl-Test-LongString-0.11-1.fc6 rawstudio-0.5.1-1.fc6 Packages built and released for Fedora Extras 5: 9 Coin2-2.4.5-5.fc5 SIMVoleon-2.0.1-6.fc5 SoQt-1.4.1-5.fc5 dia-0.95-8.fc5 ntfs-3g-1.0-1.fc5 perl-Image-ExifTool-6.77-1.fc5 perl-Template-Toolkit-2.18-1.fc5 perl-Test-LongString-0.11-1.fc5 rawstudio-0.5.1-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Wed Feb 21 23:26:10 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Feb 2007 18:26:10 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-21 Message-ID: <20070221232610.CF64015212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 1 pungi-0.2.6-1.fc7 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tibbs at math.uh.edu Thu Feb 22 02:49:25 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Feb 2007 20:49:25 -0600 Subject: php-Smarty In-Reply-To: References: <45DC7704.7020402@cora.nwra.com> Message-ID: >>>>> "GS" == Gianluca Sforna writes: GS> Tried yesterday here but as of now it did not worked... It's still done by humans, you know. It certainly looks to me as if you're the owner of buildbot at the moment. - J< From j.w.r.degoede at hhs.nl Thu Feb 22 07:42:49 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Feb 2007 08:42:49 +0100 Subject: Proposal: cross-compiling / development packaging guidelines In-Reply-To: <1172079879.3139.83.camel@playstation2.hb9jnx.ampr.org> References: <1172079879.3139.83.camel@playstation2.hb9jnx.ampr.org> Message-ID: <45DD4979.4050305@hhs.nl> Thomas Sailer wrote: > On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote: > >> Thus we have given a group of 3 students the assignment to create >> high quality rpm packages of binutils gcc and the needed libs for Fedora to >> allow crosscompiling to Atmel AVR / ARM Linux on Fedora. I'm personally > > Great! I'm very much looking forward to these packages. > >> 4) libraries respectively headers will be installed under /usr/avr/lib resp >> /usr/avr/include for avr and under /usr/arm-linux/lib resp >> /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS >> compliant, still I believe this is the right way, rationale: > > Why not /usr/share/avr/include, /usr/share/arm-linux/lib etc.? From the > view of the host, this is shareable data, i.e. I can use the same data > with an i386 avr-gcc or a ppc avr-gcc, no? > Because all the cross-compile makefiles, binutils/gcc/glibc configure script etc, expect it to be under $prefix/$target. Moving away from this will become a HUGE patchfest and then people will start complaining that app XXYZ doesn't work with our cross-compile toolchain because we did things different. Besides that there are binaries installed under /usr/avr/bin, moving things to under /usr/share thus is not an option. Also see the long list of rationale I gave in the original post, but you didn't bother to go into. Regards, Hans From j.w.r.degoede at hhs.nl Thu Feb 22 07:49:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Feb 2007 08:49:27 +0100 Subject: Proposal: cross-compiling / development packaging guidelines In-Reply-To: <1172074229.23237.157.camel@mccallum.corsepiu.local> References: <45DC64AC.2050804@hhs.nl> <1172074229.23237.157.camel@mccallum.corsepiu.local> Message-ID: <45DD4B07.6040007@hhs.nl> Ralf Corsepius wrote: > On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote: > > The default for GCC is ${prefix}/$(target)/{lib|include}. > This default is almost impossible to change. > I'm glad the things I "came up" with, closely match how you do things, thats good to hear and for me a confirment that I'm on the right track. >> 5) Docs (manpages, info and docs under %doc) will not be installed as they >> will be identical to the native version docs, > > What you say only partially applies to gcc/binutils/gdb. Their section 3 > man-pages are canonicalized (they install as -manpage), hence > are free of conflicts with a native gcc. section-7 man-pages and infos > however conflict. > Okay, so since the are installed as -manpage, they won't conflict, but will they contain any different content? I see no difference between "man arm-linux-as" and "man as", since there is no difference is it worth installing the same manpage twice, I know that one might only install the cross-toolchain and not the native one, but then we will be missing the section 7 manpages, info files etc already, and what are the changes of someone actually objecting to installing the native toolchain (even if just to get the docs)? > This is the classical standard GCC wrapper approach for non-multilib'ed cross-toolchains. > So even more agreement good to hear :) >> 8) The SRPMS for all these packages will most of the time contain the exact >> same tarbals as the native binutils / gcc / libs >> >> Possible solutions: >> a) Live with the extra diskspace / bandwidth cost this induces upon >> our mirrors > That's what I'd do. > > An alternative would be to build different versions inside of the same > SRPMS at one time. > That would require coordination between the cross-compile stuff maintainer and the native maintainer, also that would force a rebuild of both native and cross compile stuff if one of the 2 changes. I thought of this too but I don't see this as a very realistic option. Regards, Hans From rc040203 at freenet.de Thu Feb 22 07:52:44 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Feb 2007 08:52:44 +0100 Subject: Proposal: cross-compiling / development packaging guidelines In-Reply-To: <45DD4979.4050305@hhs.nl> References: <1172079879.3139.83.camel@playstation2.hb9jnx.ampr.org> <45DD4979.4050305@hhs.nl> Message-ID: <1172130764.23237.181.camel@mccallum.corsepiu.local> On Thu, 2007-02-22 at 08:42 +0100, Hans de Goede wrote: > Thomas Sailer wrote: > > On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote: > > > >> Thus we have given a group of 3 students the assignment to create > >> high quality rpm packages of binutils gcc and the needed libs for Fedora to > >> allow crosscompiling to Atmel AVR / ARM Linux on Fedora. I'm personally > > > > Great! I'm very much looking forward to these packages. > > > >> 4) libraries respectively headers will be installed under /usr/avr/lib resp > >> /usr/avr/include for avr and under /usr/arm-linux/lib resp > >> /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS > >> compliant, still I believe this is the right way, rationale: > > > > Why not /usr/share/avr/include, /usr/share/arm-linux/lib etc.? From the > > view of the host, this is shareable data, i.e. I can use the same data > > with an i386 avr-gcc or a ppc avr-gcc, no? > > > > Because all the cross-compile makefiles, binutils/gcc/glibc configure script > etc, expect it to be under $prefix/$target. Moving away from this will become a > HUGE patchfest and then people will start complaining that app XXYZ doesn't > work with our cross-compile toolchain because we did things different. > > Besides that there are binaries installed under /usr/avr/bin, moving things to > under /usr/share thus is not an option. Note: These are native binaries - Not target binaries. $prefix/$target/{lib|include} are target files Ralf From rc040203 at freenet.de Thu Feb 22 08:03:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Feb 2007 09:03:25 +0100 Subject: Proposal: cross-compiling / development packaging guidelines In-Reply-To: <45DD4B07.6040007@hhs.nl> References: <45DC64AC.2050804@hhs.nl> <1172074229.23237.157.camel@mccallum.corsepiu.local> <45DD4B07.6040007@hhs.nl> Message-ID: <1172131405.23237.193.camel@mccallum.corsepiu.local> On Thu, 2007-02-22 at 08:49 +0100, Hans de Goede wrote: > Ralf Corsepius wrote: > > On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote: > > > > > > The default for GCC is ${prefix}/$(target)/{lib|include}. > > This default is almost impossible to change. > > > > I'm glad the things I "came up" with, closely match how you do things, thats > good to hear and for me a confirment that I'm on the right track. > > >> 5) Docs (manpages, info and docs under %doc) will not be installed as they > >> will be identical to the native version docs, > > > > What you say only partially applies to gcc/binutils/gdb. Their section 3 > > man-pages are canonicalized (they install as -manpage), hence > > are free of conflicts with a native gcc. section-7 man-pages and infos > > however conflict. > > > > Okay, so since the are installed as -manpage, they won't conflict, but > will they contain any different content? Yes - The contents depends on the version of tools being used. As Fedora's binutils/GCC/gdb doesn't necessarily match the sources a cross-toolchain uses, they can diverge. > I see no difference between "man > arm-linux-as" and "man as", since there is no difference is it worth installing This is a random coincidence wrt. the binutils, because the binutils only change very slowly. In case the versions drift apart, their contents also will differ. This case is the "nominal case" for cross-toolchains, because different OSes and different architectures normally require different toolchains. > >> 8) The SRPMS for all these packages will most of the time contain the exact > >> same tarbals as the native binutils / gcc / libs > >> > >> Possible solutions: > >> a) Live with the extra diskspace / bandwidth cost this induces upon > >> our mirrors > > That's what I'd do. > > > > An alternative would be to build different versions inside of the same > > SRPMS at one time. > > > > That would require coordination between the cross-compile stuff maintainer and > the native maintainer, also that would force a rebuild of both native and cross > compile stuff if one of the 2 changes. I thought of this too but I don't see > this as a very realistic option. I don't understand. The only point (besides infos) where a native toolchain and cross-toolchains are tightly connected, is i18n/nls. Getting i18n/nls working for cross-toolchains would require a cross-toolchain to be using identical versions as the native toolchain, or to tweak locale's paths. For my cross-toolchain rpms I resorted to switching off i18n/nls. Ralf From giallu at gmail.com Thu Feb 22 08:33:59 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 22 Feb 2007 09:33:59 +0100 Subject: php-Smarty In-Reply-To: References: <45DC7704.7020402@cora.nwra.com> Message-ID: On 21 Feb 2007 20:49:25 -0600, Jason L Tibbitts III wrote: > >>>>> "GS" == Gianluca Sforna writes: > > GS> Tried yesterday here but as of now it did not worked... > > It's still done by humans, you know. It certainly looks to me as if > you're the owner of buildbot at the moment. > Yap thanks. Warren took care of my request shortly after my post :) From enrico.scholz at informatik.tu-chemnitz.de Thu Feb 22 11:20:40 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 22 Feb 2007 12:20:40 +0100 Subject: Review Request: elektra - /etc/profiles.d question and .csh needed... In-Reply-To: <45DC8299.8060403@gmail.com> (kwizart@gmail.com's message of "Wed, 21 Feb 2007 18:34:17 +0100") References: <45DC8299.8060403@gmail.com> Message-ID: <878xeq8mlz.fsf@kosh.bigo.ensc.de> kwizart at gmail.com (kwizart) writes: > By default the file installed in /etc/profile.d have executable bit set > and own a shebang. > Then it lead to the rpmlint error: > > E: elektra sourced-script-with-shebang /etc/profile.d/elektra-elektraenv.sh > E: elektra executable-sourced-script /etc/profile.d/elektra-elektraenv.sh 0755 Perhaps an upstream trick to enforce syntax highlighting in vim ('# -*- sh -*-' does not seem to work there)? I would say: make script non-executable, package it as-is (with the shebang) and ignore the rpmlint message. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From paul at city-fan.org Thu Feb 22 12:18:18 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 22 Feb 2007 12:18:18 +0000 Subject: CVSTAG In-Reply-To: <62bc09df0702211108m49ba5a16u59e4fa6a4e8d1412@mail.gmail.com> References: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> <45DBFA91.40309@poolshark.org> <62bc09df0702211108m49ba5a16u59e4fa6a4e8d1412@mail.gmail.com> Message-ID: <45DD8A0A.7050102@city-fan.org> SmootherFrOgZ wrote: > 2007/2/21, Christopher Stone : >> >> On 2/20/07, Denis Leroy wrote: >> > SmootherFrOgZ wrote: >> > > Hi, >> > > >> > > Is there someone can know how to untag a branch to "make build" for >> > > another one. >> > > >> > > i "make tag" for Devel branch to build. >> > > Now i'm unable to tag another branch such as FC-6 >> > > here is the following error: >> > > >> > > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a >> different >> > > branch >> > > ERROR: You can not forcibly move tags between branches >> > >> > Looks like something went haywire. Make sure to always do a 'cvs >> update' >> > before working on things, including the common directory. >> > >> > In your case, you need to use the force tag option, like this: >> > >> > make tag TAG_OPTS=-F >> >> This error also occurs when using cvs-import.sh --branch >> >> tried with your command, same thing: > > cvs tag -F -c ntfs-config-0_5_4-4_fc6 > Enter passphrase for key '/home/lxtnow/.ssh/id_dsa': > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a different > branch > ERROR: You can not forcibly move tags between branches > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 > > i'm working to resolve this error. Just bump the release number in the spec up, commit and re-tag. Repeat for all later Fedora releases to avoid having a later version in FC6 than Rawhide for instance. Paul. From lxtnow at gmail.com Thu Feb 22 13:29:00 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Thu, 22 Feb 2007 14:29:00 +0100 Subject: CVSTAG In-Reply-To: <45DD8A0A.7050102@city-fan.org> References: <62bc09df0702201554u5f140d6y7185d318110cc33e@mail.gmail.com> <45DBFA91.40309@poolshark.org> <62bc09df0702211108m49ba5a16u59e4fa6a4e8d1412@mail.gmail.com> <45DD8A0A.7050102@city-fan.org> Message-ID: <62bc09df0702220529j58573306v11dfd2d48bdad8bc@mail.gmail.com> 2007/2/22, Paul Howarth : > > SmootherFrOgZ wrote: > > 2007/2/21, Christopher Stone : > >> > >> On 2/20/07, Denis Leroy wrote: > >> > SmootherFrOgZ wrote: > >> > > Hi, > >> > > > >> > > Is there someone can know how to untag a branch to "make build" for > >> > > another one. > >> > > > >> > > i "make tag" for Devel branch to build. > >> > > Now i'm unable to tag another branch such as FC-6 > >> > > here is the following error: > >> > > > >> > > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a > >> different > >> > > branch > >> > > ERROR: You can not forcibly move tags between branches > >> > > >> > Looks like something went haywire. Make sure to always do a 'cvs > >> update' > >> > before working on things, including the common directory. > >> > > >> > In your case, you need to use the force tag option, like this: > >> > > >> > make tag TAG_OPTS=-F > >> > >> This error also occurs when using cvs-import.sh --branch > >> > >> tried with your command, same thing: > > > > cvs tag -F -c ntfs-config-0_5_4-4_fc6 > > Enter passphrase for key '/home/lxtnow/.ssh/id_dsa': > > ERROR: The tag ntfs-config-0_5_4-4_fc6 is already applied on a different > > branch > > ERROR: You can not forcibly move tags between branches > > cvs tag: Pre-tag check failed > > cvs [tag aborted]: correct the above errors first! > > make: *** [tag] Error 1 > > > > i'm working to resolve this error. > > Just bump the release number in the spec up, commit and re-tag. Repeat > for all later Fedora releases to avoid having a later version in FC6 > than Rawhide for instance. > > Paul. Ok, i will try -- Xavier.t Lamien -- French Fedora Ambassador Fedora Extras Contributor GPG-Key ID: F3903DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at deadbabylon.de Thu Feb 22 14:32:32 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 22 Feb 2007 15:32:32 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> Message-ID: <20070222153232.226706de@localhost.localdomain> Am Thu, 1 Feb 2007 18:15:34 +0100 schrieb Johan Kok : > > On 1-feb-2007, at 11:49, Sebastian Vahl wrote: > > > (One week later:) > > It seems that Hugo did not respond to the bug report > > [1] or this thread. What's next? > > > > 1) Wait another week? On his fotolog I've also discovered a msn > > account > > but I do not use msn for myself. (eitchugo at hotmail.com) > > Added that account and just spoke to him. He's not very available to > work on FE packages at the moment. He will respond in this thread > soon. Have you heard a lifesign from Hugo? Or did I just missed the mail? Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From limb at jcomserv.net Thu Feb 22 15:44:35 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 22 Feb 2007 09:44:35 -0600 (CST) Subject: Repoview links broken? Message-ID: <36008.65.192.24.190.1172159075.squirrel@mail.jcomserv.net> http://fedoraproject.org/extras/6/i386/repodata/ and its ilk don't seem to work. Jon -- novus ordo absurdum From mmcgrath at redhat.com Thu Feb 22 16:18:17 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 22 Feb 2007 10:18:17 -0600 Subject: Repoview links broken? In-Reply-To: <36008.65.192.24.190.1172159075.squirrel@mail.jcomserv.net> References: <36008.65.192.24.190.1172159075.squirrel@mail.jcomserv.net> Message-ID: <45DDC249.1040506@redhat.com> Jon Ciesla wrote: > http://fedoraproject.org/extras/6/i386/repodata/ and its ilk don't seem to > work. > > Jon Left over from yesterday, working on it now. -Mike From bpepple at fedoraproject.org Thu Feb 22 16:04:46 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 22 Feb 2007 11:04:46 -0500 Subject: FESCo Meeting Summary for 2007-02-15 Message-ID: <1172160286.12386.5.camel@Chuck> Sorry for the delay in getting this out, I've been buried with work the last week. :( Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Tom Callaway (spot) * Warren Togami (warren) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Jesse Keating (f13) * Jeremy Katz (jeremy) Absent * Andreas Bierfert (awjb) * Josh Boyer (jwb) == Summary == Core/Extras Merge * FESCo ratified the CVS administration with flags proposal. * warren is going to continue working on the core package review procedures, and the plan is for FESCo to vote on it at the 2007-02-22 meeting. * notting brought up a proposed change to owners.list, which would list multiple owners in the owners section. FESCo approved this change. Sponsor Nominations * rvolkal was nominated and accepted. Packaging Committee Report * FESCo didn't have any objections to the Packaging Committee's guidelines regarding: * Jpackage naming policy * spec file naming clarification For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070215 Thanks, /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 mmcgrath at redhat.com Thu Feb 22 19:19:00 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 22 Feb 2007 13:19:00 -0600 Subject: Repoview links broken? In-Reply-To: <45DDC249.1040506@redhat.com> References: <36008.65.192.24.190.1172159075.squirrel@mail.jcomserv.net> <45DDC249.1040506@redhat.com> Message-ID: <45DDECA4.3080909@redhat.com> Mike McGrath wrote: > Jon Ciesla wrote: >> http://fedoraproject.org/extras/6/i386/repodata/ and its ilk don't >> seem to >> work. >> >> Jon > Left over from yesterday, working on it now. > Fixed -Mike From buildsys at fedoraproject.org Thu Feb 22 19:22:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Feb 2007 14:22:02 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-22 Message-ID: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 0 Packages built and released for Fedora Extras 6: 21 aquamarine-0.1.9999.2-2.fc6 bdock-0.1.9999.2-1.fc6 beryl-core-0.1.9999.2-1.fc6 beryl-manager-0.1.9999.2-1.fc6 beryl-plugins-0.1.9999.2-1.fc6 beryl-settings-0.1.9999.2-1.fc6 chemical-mime-data-0.1.94-2.fc6 NEW elph-1.0.1-1.fc6 emerald-0.1.9999.2-1.fc6 emerald-themes-0.1.9999.2-1.fc6 fuse-2.6.3-2.fc6 gauche-gl-0.4.3-2.fc6 gauche-gtk-0.4.1-11.fc6 NEW glimmer-3.02-1.fc6 heliodor-0.1.9999.2-1.fc6 leafnode-1.11.5-4.fc6 mediawiki-1.8.4-8.fc6 NEW rudeconfig-5.0.5-1.fc6 NEW sear-media-0.6-3 NEW thinkfinger-0.2.2-4.fc6 vigra-1.5.0-2.fc6 Packages built and released for Fedora Extras 5: 9 NEW dbmail-2.2.2-9.fc5 NEW elph-1.0.1-1.fc5 fuse-2.6.3-2.fc5 NEW glimmer-3.02-1.fc5 leafnode-1.11.5-3.fc5 NEW libsieve-2.2.5-1.fc5 mediawiki-1.8.4-8.fc5 NEW rudeconfig-5.0.5-1.fc5 vigra-1.5.0-2.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From pemboa at gmail.com Thu Feb 22 19:37:56 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Feb 2007 13:37:56 -0600 Subject: Packaging KDE window decorations, etc In-Reply-To: <45D5EB900200006A000100B2@cs-emo.csir.co.za> References: <45D5C96C020000F70000872B@cs-emo.csir.co.za> <45D5EB900200006A000100B2@cs-emo.csir.co.za> <45D5EB900200006A000100B2@cs-emo.csir.co.za> Message-ID: <16de708d0702221137y3e357d16ue3f7f398a1aeb144@mail.gmail.com> On 2/16/07, Francois Aucamp wrote: > On Fri, 2007-02-16 at 07:05 -0600, Rex Dieter wrote: > > How about not inventing problems that don't actually exist yet? (: > > :-) Fair enough, my intention was not to complain about as-yet > nonexistent problems... but prevention is always better than a cure, its > a simple management principle, even - look at the discussion on the RPM > buildroot problem as an example of the type of thing that *could* > happen. > > > I think I like Arthur's suggestion of using kde-look categories, but > such a > > proposal will take time to flesh out, and you need not wait on that to > > start packaging stuff now, imo. > > Thanks, I won't. I'm also more than willing (and keen) to help Arthur > out on the proposal, so please let me know if I can help you! > > Cheers and thanks for the feedback, > -Francois Francois, sorry for my apparent lack of manners, I seemed to have missed this last message. Here is a very basic (bare-bones) proposal I wrote up : http://fedoraproject.org/wiki/PackagingDrafts/KDELooks Be sure to critique so that I do much better next time on the first try. Thank you. Arthur Pemberton -- Fedora Core 6 and proud From rc040203 at freenet.de Thu Feb 22 19:42:45 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Feb 2007 20:42:45 +0100 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> Message-ID: <1172173365.23237.270.camel@mccallum.corsepiu.local> On Thu, 2007-02-22 at 14:22 -0500, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 0 > > > > Packages built and released for Fedora Extras 6: 21 Seems as if all packages having been built ca. 24hrs - ca. 48hrs ago have not been pushed. Ralf From dennis at ausil.us Thu Feb 22 19:51:05 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 22 Feb 2007 13:51:05 -0600 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <1172173365.23237.270.camel@mccallum.corsepiu.local> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <1172173365.23237.270.camel@mccallum.corsepiu.local> Message-ID: <200702221351.05353.dennis@ausil.us> On Thursday 22 February 2007 01:42:45 pm Ralf Corsepius wrote: > On Thu, 2007-02-22 at 14:22 -0500, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 0 > > > > > > > > Packages built and released for Fedora Extras 6: 21 > > Seems as if all packages having been built ca. 24hrs - ca. 48hrs ago > have not been pushed. Development is frozen you need to put in a special request to get a package released -- Dennis Gilmore, RHCE From rc040203 at freenet.de Thu Feb 22 20:08:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Feb 2007 21:08:32 +0100 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <200702221351.05353.dennis@ausil.us> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <1172173365.23237.270.camel@mccallum.corsepiu.local> <200702221351.05353.dennis@ausil.us> Message-ID: <1172174912.23237.280.camel@mccallum.corsepiu.local> On Thu, 2007-02-22 at 13:51 -0600, Dennis Gilmore wrote: > On Thursday 22 February 2007 01:42:45 pm Ralf Corsepius wrote: > > On Thu, 2007-02-22 at 14:22 -0500, buildsys at fedoraproject.org wrote: > > > Packages built and released for Fedora Extras development: 0 > > > > > > > > > > > > Packages built and released for Fedora Extras 6: 21 > > > > Seems as if all packages having been built ca. 24hrs - ca. 48hrs ago > > have not been pushed. > Development is frozen 1. We are talking about updates to FC6 and FC5- These have nothing to do with devel nor with the freeze. If they do - then something is very broken with Fedora's release management. > you need to put in a special request to get a package > released 2. Which special requests? Ralf From buildsys at fedoraproject.org Thu Feb 22 20:22:42 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Thu, 22 Feb 2007 20:22:42 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-22 Message-ID: <20070222202242.27025.21978@extras64.linux.duke.edu> New report for: enrico.scholz AT informatik.tu-chemnitz.de package: tor-core - 0.1.1.26-2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libevent-1.1a.so.1 package: tor-core - 0.1.1.26-2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libevent-1.1a.so.1 package: tor-core - 0.1.1.26-2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libevent-1.1a.so.1()(64bit) ====================================================================== New report for: jima AT beer.tclug.org package: scanssh - 2.1-10.fc7.i386 from fedora-extras-development-i386 unresolved deps: libevent-1.1a.so.1 package: scanssh - 2.1-10.fc7.ppc from fedora-extras-development-ppc unresolved deps: libevent-1.1a.so.1 package: scanssh - 2.1-10.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libevent-1.1a.so.1()(64bit) ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (13 days) libetpan - 0.49-1.fc7.i386 (13 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (13 days) cgoorah AT yahoo.com.au irsim - 9.7.41-5.fc7.i386 (8 days) irsim - 9.7.41-5.fc7.ppc (8 days) toped - 0.8.2-2.fc6.i386 (69 days) toped - 0.8.2-2.fc6.ppc (69 days) toped - 0.8.2-2.fc6.x86_64 (69 days) xcircuit - 3.4.26-18.fc7.i386 (8 days) xcircuit - 3.4.26-18.fc7.ppc (8 days) xcircuit - 3.4.26-18.fc7.x86_64 (8 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (76 days) csound - 5.03.0-9.fc7.i386 (76 days) csound - 5.03.0-9.fc7.ppc (76 days) csound - 5.03.0-9.fc7.x86_64 (76 days) csound-python - 5.03.0-9.fc7.i386 (76 days) csound-python - 5.03.0-9.fc7.ppc (76 days) csound-python - 5.03.0-9.fc7.x86_64 (76 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (78 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (78 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (78 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (78 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (78 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (78 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (78 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (76 days) enrico.scholz AT informatik.tu-chemnitz.de tor-core - 0.1.1.26-2.fc7.i386 tor-core - 0.1.1.26-2.fc7.ppc tor-core - 0.1.1.26-2.fc7.x86_64 foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (7 days) flac123 - 0.0.9-1.fc7.ppc (7 days) flac123 - 0.0.9-1.fc7.x86_64 (7 days) muine - 0.8.7-1.fc7.i386 (7 days) muine - 0.8.7-1.fc7.i386 (7 days) muine - 0.8.7-1.fc7.ppc (7 days) muine - 0.8.7-1.fc7.x86_64 (7 days) gemi AT bluewin.ch audacity - 1.3.2-7.20070106cvs.fc7.i386 (7 days) audacity - 1.3.2-7.20070106cvs.fc7.ppc (7 days) audacity - 1.3.2-7.20070106cvs.fc7.x86_64 (7 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.20_1.2932.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (73 days) libreadline-java - 0.8.0-13.fc6.i386 (73 days) libreadline-java - 0.8.0-13.fc6.ppc (73 days) libreadline-java - 0.8.0-13.fc6.x86_64 (73 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (136 days) linphone - 1.2.0-4.fc5.ppc (136 days) linphone - 1.2.0-4.fc5.x86_64 (136 days) jima AT beer.tclug.org scanssh - 2.1-10.fc7.i386 scanssh - 2.1-10.fc7.ppc scanssh - 2.1-10.fc7.x86_64 oliver AT linux-kernel.at syck-php - 0.55-13.fc7.i386 (5 days) syck-php - 0.55-13.fc7.ppc (5 days) syck-php - 0.55-13.fc7.x86_64 (5 days) orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (76 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (76 days) paul AT xelerance.com hping3 - 0.0.20051105-6.fc7.i386 (8 days) hping3 - 0.0.20051105-6.fc7.ppc (8 days) hping3 - 0.0.20051105-6.fc7.x86_64 (8 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (5 days) k3b-extras - 0.12.17-1.fc6.ppc (5 days) k3b-extras - 0.12.17-1.fc6.x86_64 (5 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (76 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 (8 days) xpa - 2.1.6-8.fc7.i386 (8 days) xpa - 2.1.6-8.fc7.ppc (8 days) xpa - 2.1.6-8.fc7.x86_64 (8 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (76 days) xmldiff - 0.6.7-12.fc6.ppc (76 days) xmldiff - 0.6.7-12.fc6.x86_64 (76 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 (8 days) R - 2.4.1-2.fc7.i386 (8 days) R - 2.4.1-2.fc7.ppc (8 days) R - 2.4.1-2.fc7.x86_64 (8 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 (8 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 (8 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc (8 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (8 days) kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 (8 days) kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (8 days) kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc (8 days) ====================================================================== Broken packages in fedora-extras-5-i386: linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-development-i386: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC++.so.5 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.i386 requires libtcl8.5.so irsim-9.7.41-5.fc7.i386 requires libtk8.5.so irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2932.fc7 kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 scanssh-2.1-10.fc7.i386 requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.i386 requires php = 0:5.2.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 tor-core-0.1.1.26-2.fc7.i386 requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-ppc: R-2.4.1-2.fc7.ppc requires libtk8.5.so R-2.4.1-2.fc7.ppc requires libtcl8.5.so audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC++.so.5 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.ppc requires libtcl8.5.so irsim-9.7.41-5.fc7.ppc requires libtk8.5.so irsim-9.7.41-5.fc7.ppc requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 muine-0.8.7-1.fc7.ppc requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 scanssh-2.1-10.fc7.ppc requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.ppc requires php = 0:5.2.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 tor-core-0.1.1.26-2.fc7.ppc requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.ppc requires libtk8.5.so xcircuit-3.4.26-18.fc7.ppc requires libtcl8.5.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.ppc requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-x86_64: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so R-2.4.1-2.fc7.x86_64 requires libtcl8.5.so()(64bit) R-2.4.1-2.fc7.x86_64 requires libtk8.5.so()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC++.so.5()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC.so.7()(64bit) claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) hping3-0.0.20051105-6.fc7.x86_64 requires libtcl8.5.so()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 muine-0.8.7-1.fc7.x86_64 requires libFLAC.so.7()(64bit) openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) scanssh-2.1-10.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) syck-php-0.55-13.fc7.x86_64 requires php = 0:5.2.0 toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) tor-core-0.1.1.26-2.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtk8.5.so()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtcl8.5.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so xpa-2.1.6-8.fc7.x86_64 requires libtcl8.5.so()(64bit) From bugs.michael at gmx.net Thu Feb 22 20:31:24 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Feb 2007 21:31:24 +0100 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <1172174912.23237.280.camel@mccallum.corsepiu.local> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <1172173365.23237.270.camel@mccallum.corsepiu.local> <200702221351.05353.dennis@ausil.us> <1172174912.23237.280.camel@mccallum.corsepiu.local> Message-ID: <20070222213124.e56a0a0d.bugs.michael@gmx.net> On Thu, 22 Feb 2007 21:08:32 +0100, Ralf Corsepius wrote: > On Thu, 2007-02-22 at 13:51 -0600, Dennis Gilmore wrote: > > On Thursday 22 February 2007 01:42:45 pm Ralf Corsepius wrote: > > > On Thu, 2007-02-22 at 14:22 -0500, buildsys wrote: > > > > Packages built and released for Fedora Extras development: 0 > > > > > > > > > > > > > > > > Packages built and released for Fedora Extras 6: 21 > > > > > > Seems as if all packages having been built ca. 24hrs - ca. 48hrs ago > > > have not been pushed. > > Development is frozen > > 1. We are talking about updates to FC6 and FC5- These have nothing to > do with devel nor with the freeze. Point me to at least one example please. Give the build job number or plague-results directory. From dennis at ausil.us Thu Feb 22 20:35:42 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 22 Feb 2007 14:35:42 -0600 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <1172174912.23237.280.camel@mccallum.corsepiu.local> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <200702221351.05353.dennis@ausil.us> <1172174912.23237.280.camel@mccallum.corsepiu.local> Message-ID: <200702221435.43181.dennis@ausil.us> On Thursday 22 February 2007 02:08:32 pm Ralf Corsepius wrote: > On Thu, 2007-02-22 at 13:51 -0600, Dennis Gilmore wrote: > > On Thursday 22 February 2007 01:42:45 pm Ralf Corsepius wrote: > > > On Thu, 2007-02-22 at 14:22 -0500, buildsys at fedoraproject.org wrote: > > > > Packages built and released for Fedora Extras development: 0 > > > > > > > > > > > > > > > > Packages built and released for Fedora Extras 6: 21 > > > > > > Seems as if all packages having been built ca. 24hrs - ca. 48hrs ago > > > have not been pushed. > > > > Development is frozen > > 1. We are talking about updates to FC6 and FC5- These have nothing to > do with devel nor with the freeze. > > If they do - then something is very broken with Fedora's release > management. Indeed the sync between duke and Red Hat seems to be down yesterdays dia build http://buildsys.fedoraproject.org/build-status/job.psp?uid=27975 is not on the master mirror. but is in the pushed tree -- Dennis Gilmore, RHCE From dennis at ausil.us Thu Feb 22 20:42:12 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 22 Feb 2007 14:42:12 -0600 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <200702221435.43181.dennis@ausil.us> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <1172174912.23237.280.camel@mccallum.corsepiu.local> <200702221435.43181.dennis@ausil.us> Message-ID: <200702221442.13010.dennis@ausil.us> On Thursday 22 February 2007 02:35:42 pm Dennis Gilmore wrote: > On Thursday 22 February 2007 02:08:32 pm Ralf Corsepius wrote: > > On Thu, 2007-02-22 at 13:51 -0600, Dennis Gilmore wrote: > > > On Thursday 22 February 2007 01:42:45 pm Ralf Corsepius wrote: > > > > On Thu, 2007-02-22 at 14:22 -0500, buildsys at fedoraproject.org wrote: > > > > > Packages built and released for Fedora Extras development: 0 > > > > > > > > > > > > > > > > > > > > Packages built and released for Fedora Extras 6: 21 > > > > > > > > Seems as if all packages having been built ca. 24hrs - ca. 48hrs ago > > > > have not been pushed. > > > > > > Development is frozen > > > > 1. We are talking about updates to FC6 and FC5- These have nothing to > > do with devel nor with the freeze. > > > > If they do - then something is very broken with Fedora's release > > management. > > Indeed the sync between duke and Red Hat seems to be down yesterdays dia > build http://buildsys.fedoraproject.org/build-status/job.psp?uid=27975 is > not on the master mirror. but is in the pushed tree problem found being fixed now -- Dennis Gilmore, RHCE From chitlesh at fedoraproject.org Thu Feb 22 20:43:38 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 22 Feb 2007 21:43:38 +0100 Subject: Packaging KDE window decorations, etc In-Reply-To: <16de708d0702221137y3e357d16ue3f7f398a1aeb144@mail.gmail.com> References: <45D5C96C020000F70000872B@cs-emo.csir.co.za> <45D5EB900200006A000100B2@cs-emo.csir.co.za> <16de708d0702221137y3e357d16ue3f7f398a1aeb144@mail.gmail.com> Message-ID: <13dbfe4f0702221243n4c270d13j73fd0e51b7d41e58@mail.gmail.com> On 2/22/07, Arthur Pemberton wrote: > Be sure to critique so that I do much better next time on the first try. > Wouldn't it be better with kwin-%{packagename}-%{version}-%{release}.%{arch}.rpm. instead of kde-decoration-%{type}-%{packagename}-%{version}-%{release}.%{arch}.rpm. regards, Chitlesh -- http://clunixchit.blogspot.com From rc040203 at freenet.de Thu Feb 22 20:51:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Feb 2007 21:51:59 +0100 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <20070222213124.e56a0a0d.bugs.michael@gmx.net> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <1172173365.23237.270.camel@mccallum.corsepiu.local> <200702221351.05353.dennis@ausil.us> <1172174912.23237.280.camel@mccallum.corsepiu.local> <20070222213124.e56a0a0d.bugs.michael@gmx.net> Message-ID: <1172177519.23237.309.camel@mccallum.corsepiu.local> On Thu, 2007-02-22 at 21:31 +0100, Michael Schwendt wrote: > On Thu, 22 Feb 2007 21:08:32 +0100, Ralf Corsepius wrote: > > > On Thu, 2007-02-22 at 13:51 -0600, Dennis Gilmore wrote: > > > On Thursday 22 February 2007 01:42:45 pm Ralf Corsepius wrote: > > > > On Thu, 2007-02-22 at 14:22 -0500, buildsys wrote: > > > > > Packages built and released for Fedora Extras development: 0 > > > > > > > > > > > > > > > > > > > > Packages built and released for Fedora Extras 6: 21 > > > > > > > > Seems as if all packages having been built ca. 24hrs - ca. 48hrs ago > > > > have not been pushed. > > > Development is frozen > > > > 1. We are talking about updates to FC6 and FC5- These have nothing to > > do with devel nor with the freeze. > > Point me to at least one example please. Give the build job number > or plague-results directory. All of my yesterday's buildjobs have not been pushed - To be found on the successful build jobs page. Ralf From bugs.michael at gmx.net Thu Feb 22 20:54:35 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Feb 2007 21:54:35 +0100 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <200702221435.43181.dennis@ausil.us> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <200702221351.05353.dennis@ausil.us> <1172174912.23237.280.camel@mccallum.corsepiu.local> <200702221435.43181.dennis@ausil.us> Message-ID: <20070222215435.ac8e74d7.bugs.michael@gmx.net> On Thu, 22 Feb 2007 14:35:42 -0600, Dennis Gilmore wrote: > Indeed the sync between duke and Red Hat seems to be down yesterdays dia build > http://buildsys.fedoraproject.org/build-status/job.psp?uid=27975 is not on > the master mirror. but is in the pushed tree Most likely related to the breakage Mike McGrath has been pointed to earlier today, when the fedoraproject.org repo was missing. fedora-infrastructure-list doesn't say anything about the changes in the background. Probably shuffling around fp.org host names via DNS or so. From bugs.michael at gmx.net Thu Feb 22 21:01:21 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 22 Feb 2007 22:01:21 +0100 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <1172177519.23237.309.camel@mccallum.corsepiu.local> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <1172173365.23237.270.camel@mccallum.corsepiu.local> <200702221351.05353.dennis@ausil.us> <1172174912.23237.280.camel@mccallum.corsepiu.local> <20070222213124.e56a0a0d.bugs.michael@gmx.net> <1172177519.23237.309.camel@mccallum.corsepiu.local> Message-ID: <20070222220121.74170f49.bugs.michael@gmx.net> On Thu, 22 Feb 2007 21:51:59 +0100, Ralf Corsepius wrote: > All of my yesterday's buildjobs have not been pushed - To be found on > the successful build jobs page. Build report is here: https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00348.html cf. http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/Coin2/2.4.5-5.fc6/PUSHED They have been pushed, but something has failed to mirror them from RDU to Red Hat. I am completely in the dark as what changes have been applied to the fedoraproject.org host and/or its IP. Seems fedoraproject.org now is at redhat.com. From dennis at ausil.us Thu Feb 22 21:25:36 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 22 Feb 2007 15:25:36 -0600 Subject: Fedora Extras Package Build Report 2007-02-22 In-Reply-To: <20070222215435.ac8e74d7.bugs.michael@gmx.net> References: <20070222192202.44E4B15212E@buildsys.fedoraproject.org> <200702221435.43181.dennis@ausil.us> <20070222215435.ac8e74d7.bugs.michael@gmx.net> Message-ID: <200702221525.37043.dennis@ausil.us> On Thursday 22 February 2007 02:54:35 pm Michael Schwendt wrote: > On Thu, 22 Feb 2007 14:35:42 -0600, Dennis Gilmore wrote: > > Indeed the sync between duke and Red Hat seems to be down yesterdays dia > > build http://buildsys.fedoraproject.org/build-status/job.psp?uid=27975 is > > not on the master mirror. but is in the pushed tree > > Most likely related to the breakage Mike McGrath has been pointed to > earlier today, when the fedoraproject.org repo was missing. > fedora-infrastructure-list doesn't say anything about the changes > in the background. Probably shuffling around fp.org host names via > DNS or so. The wiki was moved from a single host at duke to multiple hosts in the Pheonix colo. the script that pulls the updates has been pointed to the full name of the host instead of fedoraproject.org the sync is in progress as we speak -- Dennis Gilmore, RHCE From pemboa at gmail.com Thu Feb 22 22:22:43 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Feb 2007 16:22:43 -0600 Subject: Packaging KDE window decorations, etc In-Reply-To: <13dbfe4f0702221243n4c270d13j73fd0e51b7d41e58@mail.gmail.com> References: <45D5C96C020000F70000872B@cs-emo.csir.co.za> <45D5EB900200006A000100B2@cs-emo.csir.co.za> <16de708d0702221137y3e357d16ue3f7f398a1aeb144@mail.gmail.com> <13dbfe4f0702221243n4c270d13j73fd0e51b7d41e58@mail.gmail.com> Message-ID: <16de708d0702221422o7e6aaccai42419264b5e51b4e@mail.gmail.com> On 2/22/07, Chitlesh GOORAH wrote: > On 2/22/07, Arthur Pemberton wrote: > > > Be sure to critique so that I do much better next time on the first try. > > > > > Wouldn't it be better with > kwin-%{packagename}-%{version}-%{release}.%{arch}.rpm. > instead of > kde-decoration-%{type}-%{packagename}-%{version}-%{release}.%{arch}.rpm. > > > regards, > Chitlesh > -- It would definetly be shorter, but I'm thinking of being able to write a PyQt app that can simply display apps from `yum list "kde-*"` -- Fedora Core 6 and proud From buildsys at fedoraproject.org Thu Feb 22 22:47:20 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Feb 2007 17:47:20 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-22 Message-ID: <20070222224720.31C2D15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 0 Packages built and released for Fedora Extras 6: 1 sear-0.6.3-3.fc6 Packages built and released for Fedora Extras 5: 0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From wtogami at redhat.com Thu Feb 22 22:47:13 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 22 Feb 2007 17:47:13 -0500 Subject: RATIFIED: Review with Flags (Version 6) Message-ID: <45DE1D71.7020300@redhat.com> Thursday, February 22nd, 2007 FESCO ratified this as the new package review process for *ALL* reviews. This includes both Merge Reviews and New Package Reviews. Next I need to find all places in the Wiki that need updating... STOP USING THE TRACKER BUGS. Just leave them as-is. FESCO is thinking about what to do about them during next week's meeting. Changes since Version 5: ======================== - fedora-review- is equivalent to FE-DEADPACKAGE. Only set to - if the package cannot be fixed and thus is no longer in consideration for reviews. Possible reasons may include: - license or other legal problems - other reasons that cannot be solved soon - fedora-review? is equivalent to FE-REVIEW. Use this for any review in process. If you ask the owner to make changes, keep it set to ?, and use NEEDINFO on the owner. - fedora-review+ is equivalent to FE-ACCEPT Fedora Review Flag States ========================= fedora-review BLANK I want a review, or a past reviewer gave up. fedora-review? Under Review, ASSIGNED to reviewer fedora-review- This review cannot proceed, dropped for legal or other issues. fedora-review+ APPROVED, ASSIGNED to reviewer Assigned Pointer ================ - Assigned pointer to nobody at fedoraproject.org if no reviewer yet. - Assigned pointer to reviewer, during and after the review. Bugzilla States =============== In practice a bug sitting in these states matter less than the state of the fedora-review flag. Participants are to follow these states as suggested guidelines, but the fedora-review flag has the hard requirements of behavior. NEW ASSIGNED REOPENED - There is no real distinction between these states, they all generally mean "open". NEEDINFO - To owner or other person who needs to fix something or provide needed information in order for the review to proceed. MODIFIED - Owner seems to have fixed it, but it requires testing. - OPTIONAL: you don't need to use this state. It could sit in ASSIGNED where you do the same thing. This might seem confusing, but we can't stop people from using this state. Yet another thing to simplify away in the future ideal process. I'm sorry if you're upset about this. - *Special Case: During the Mass Review, the fix may go into rawhide and the reviewer can verify both the CVS contents and package before giving fedora-review+. CLOSED RAWHIDE - fedora-review+ is APPROVED, CVS procedure is done, and package is built and confirmed to be done. - *Special Case*: During the Mass Review, it is fine to set to CLOSED RAWHIDE if it is confirmed to be fixed there. Please consider using MODIFIED prior to CLOSED RAWHIDE to allow for a verification step. Review Process ============== 1. Review Request is filed fedora-review is BLANK Assigned to nobody 2. Reviewer Takes a Request fedora-review is ? Assigned to reviewer 3a. If review denied and needs work Comment NEEDINFO to whoever needs to fix it. 3b. NEEDINFO, owner provides fix Undo NEEDINFO status 4. If APPROVED fedora-review+ 5. After fedora-review+ initiate the fedora-cvs request procedure http://fedoraproject.org/wiki/CVSAdminProcedure 6. After fedora-cvs procedure (empty directories are in CVS) checkin build verify buids set to CLOSED RAWHIDE Other Possibilities =================== fedora-review? could also be used on any other Fedora bug when a horrible mess is found in an existing package, and attention for a re-review would be desired to fix it. Warren Togami wtogami at redhat.com From christoph.wickert at nurfuerspam.de Fri Feb 23 00:29:21 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 23 Feb 2007 01:29:21 +0100 Subject: requires_kbase_article?? Message-ID: <1172190561.7222.40.camel@hal9000.oberschlesier.lan> Hi, can anybody tell me what the "requires_kbase_article"-flag is for and how to use it? I did a full text search on my fedora-extras-list folder with no results. Same for full text search on the wiki. To be honest, the recent changes are very confusing and frustrating for me as a contributor. Not the changes itself but the lack of information about them. ATM I have stopped doing new reviews, because I feel I have not completely understood the new rules. For example I didn't know what to do with the existing tracker bugs. Correct me if I'm wrong: When Warren sent out the "Review with flags V. 6" mail two hours ago, it was the first time somebody clarified this not to use trackers any more. I think we need more info and clearer advice from FeSCo. We need better communication. And we need that _before_ changes are done. I don't want to search through a thousand mails every time for some piece of information that should be written down clearly in the wiki. IIRC maintainers-list was meant to be a "low traffic list" mainly for important announcements, but by now we have an average of 150-300 mails a week. This is very hard to follow, especially for non-native speakers with poor English like me. I have a lot of work to do ATM and only little spare time for fedora. I will do more work if I have more time again, but I think it must be possible to follow the fedora project even for a maintainer with limited time. So I would like to be able to get _all_ important changes on maintainers-list while the _whole_ decisions are discussed on fedora-extras-list (or whatever this list will be called after the merge). Please FeSCo, show us your guiding hand! Christoph From josef at toxicpanda.com Fri Feb 23 00:44:08 2007 From: josef at toxicpanda.com (Josef Whiter) Date: Thu, 22 Feb 2007 19:44:08 -0500 Subject: requires_kbase_article?? In-Reply-To: <1172190561.7222.40.camel@hal9000.oberschlesier.lan> References: <1172190561.7222.40.camel@hal9000.oberschlesier.lan> Message-ID: <45DE38D8.5060003@toxicpanda.com> Christoph Wickert wrote: > Hi, > > can anybody tell me what the "requires_kbase_article"-flag is for and > how to use it? I did a full text search on my fedora-extras-list folder > with no results. Same for full text search on the wiki. > This is something for use for internal RH stuff, it doesn't affect anything Fedora related so you can safely ignore it. Josef From christoph.wickert at nurfuerspam.de Fri Feb 23 01:07:05 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 23 Feb 2007 02:07:05 +0100 Subject: requires_kbase_article?? In-Reply-To: <45DE38D8.5060003@toxicpanda.com> References: <1172190561.7222.40.camel@hal9000.oberschlesier.lan> <45DE38D8.5060003@toxicpanda.com> Message-ID: <1172192825.7222.43.camel@hal9000.oberschlesier.lan> Am Donnerstag, den 22.02.2007, 19:44 -0500 schrieb Josef Whiter: > Christoph Wickert wrote: > > Hi, > > > > can anybody tell me what the "requires_kbase_article"-flag is for and > > how to use it? I did a full text search on my fedora-extras-list folder > > with no results. Same for full text search on the wiki. > > > This is something for use for internal RH stuff, it doesn't affect > anything Fedora related so you can safely ignore it. Thanks a lot Josef. requires_kbase_article was just _one_ example of recent changes that IMHO weren't announced as they should have been. Christoph From notting at redhat.com Fri Feb 23 02:39:05 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Feb 2007 21:39:05 -0500 Subject: requires_kbase_article?? In-Reply-To: <1172192825.7222.43.camel@hal9000.oberschlesier.lan> References: <1172190561.7222.40.camel@hal9000.oberschlesier.lan> <45DE38D8.5060003@toxicpanda.com> <1172192825.7222.43.camel@hal9000.oberschlesier.lan> Message-ID: <20070223023905.GB18943@nostromo.devel.redhat.com> Christoph Wickert (christoph.wickert at nurfuerspam.de) said: > requires_kbase_article was just _one_ example of recent changes that > IMHO weren't announced as they should have been. I suspect it was only added for Fedora bugs by accident. Bill From faucamp at csir.co.za Fri Feb 23 09:37:42 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Fri, 23 Feb 2007 11:37:42 +0200 Subject: Packaging KDE window decorations, etc In-Reply-To: <45DED2060200006A00010A8F@cs-emo.csir.co.za> References: <45DE33F4020000ED00006697@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> Message-ID: <45DED2060200006A00010A8F@cs-emo.csir.co.za> Good work so far! I just have a few suggestions: from wiki: 1. Themes for Amarok should be named kde-themes-amarok-%{packagename}-%{version}-%{release}.%{arch}.rpm. - I don't think this is necessary, especially since lots of Gnome users also use amarok - IMO it could be something like: amarok-theme-%{packagename}-%{version}-%{release}.%{arch}.rpm. The same goes for k3b, as I also know of a few people that use k3b in Gnome. Actually, I think most (all?) "application-level" themes should _not_ have a prefix such as "kde-themes-"; imo they are not strictly part of the "KDE-naming scheme", and it over-complicates things a bit. :-) As for the kde-decoration-%{type}-%{packagename}/{kwin-%{packagename} debate, I'm happy with both. However, if we are going to use something like kde-style-* and kde-icon-* for widget styles and icons, it might be better to stick to kde-decoration-* so that everything looks similar. We could even do something like: kde-kwin-(%{type}-)%{packagename} where %{type} is optional, depending on whether or not something like deKorator is required. Your PyQt app sounds interesting; some kind of "find KDE stuff" yum-frontend? I would find that _very_ useful - let me know if I can help you out with that... :-) Cheers, -Francois On Thu, 2007-02-22 at 16:22 -0600, Arthur Pemberton wrote: > On 2/22/07, Chitlesh GOORAH wrote: > > On 2/22/07, Arthur Pemberton wrote: > > > > > Be sure to critique so that I do much better next time on the first try. > > > > > > > > > Wouldn't it be better with > > kwin-%{packagename}-%{version}-%{release}.%{arch}.rpm. > > instead of > > kde-decoration-%{type}-%{packagename}-%{version}-%{release}.%{arch}.rpm. > > > > > > regards, > > Chitlesh > > -- > > It would definetly be shorter, but I'm thinking of being able to write > a PyQt app that can simply display apps from `yum list "kde-*"` > > -- > Fedora Core 6 and proud > -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From paul at city-fan.org Fri Feb 23 09:55:01 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 23 Feb 2007 09:55:01 +0000 Subject: php-Smarty In-Reply-To: References: <45DC7704.7020402@cora.nwra.com> Message-ID: <45DEB9F5.8010609@city-fan.org> Christopher Stone wrote: > On 2/21/07, Orion Poplawski wrote: >> I'm currently the maintainer of php-Smarty. Two items: >> >> - Could someone who is running php-Smarty on FC6 please try out the >> following update: >> >> http://www.cora.nwra.com/~orion/fedora/php-Smarty-2.6.16-1.fc6.noarch.rpm >> >> * Wed Feb 21 2007 Orion Poplawski 2.6.16-1 >> - Update to 2.6.16 >> - Install in /usr/share/php/Smarty >> - Update php version requirement >> >> I'd be interested in knowing if moving the install location causes any >> problems, or if with the changes to php supporting /usr/share/php >> everything is smooth. > > Works like a charm. > >> >> - I no longer run php-Smarty, so I'd be happy if someone else who does >> volunteered to maintain it. > > I can maintain it, not sure how the new process to fix owners.list works > though. Are you going to push this FC6 version as an update? If so, when? Paul. From johan-fedora at deds.nl Fri Feb 23 10:09:06 2007 From: johan-fedora at deds.nl (Johan Kok) Date: Fri, 23 Feb 2007 11:09:06 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <20070222153232.226706de@localhost.localdomain> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> <20070222153232.226706de@localhost.localdomain> Message-ID: <6E49FA91-4FC8-4A12-BE27-4A86C1027FE9@deds.nl> On 22-feb-2007, at 15:32, Sebastian Vahl wrote: > Am Thu, 1 Feb 2007 18:15:34 +0100 > schrieb Johan Kok : >> Added that account and just spoke to him. He's not very available to >> work on FE packages at the moment. He will respond in this thread >> soon. > > Have you heard a lifesign from Hugo? Or did I just missed the mail? Hm, I haven't heard anything from Hugo since that chat. I suppose he never wrote that mail we talked about. In the conversation he said that he was occupied at the moment and that he did not have time for Fedora. He suggested that anyone who would like to maintain or co- maintain one of his packages (with him) should do so and said that he would write that in a message to this list. Johan From chris.stone at gmail.com Fri Feb 23 15:32:34 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 23 Feb 2007 07:32:34 -0800 Subject: php-Smarty In-Reply-To: <45DEB9F5.8010609@city-fan.org> References: <45DC7704.7020402@cora.nwra.com> <45DEB9F5.8010609@city-fan.org> Message-ID: On 2/23/07, Paul Howarth wrote: > Are you going to push this FC6 version as an update? If so, when? When bug #225434 is closed. From wtogami at redhat.com Fri Feb 23 19:14:59 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Feb 2007 14:14:59 -0500 Subject: sdcc - Cross Compiler, Needs Packaging Standards? Message-ID: <45DF3D33.3030207@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 It appears that a few folks want sdcc, but do the packaging standards for cross compilers and the concern about names being dropped into /usr/bin should be solved first? Warren Togami wtogami at redhat.com From buildsys at fedoraproject.org Fri Feb 23 19:24:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 23 Feb 2007 14:24:18 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-23 Message-ID: <20070223192418.6AD4D15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 1 kvm-14-1 Packages built and released for Fedora Extras 6: 10 NEW Democracy-0.9.5.1-1.fc6 NEW KoboDeluxe-0.4-0.3.pre10.fc6 NEW hyperestraier-1.4.9-2.fc6 kazehakase-0.4.4.1-3.fc6 NEW kbilliards-0.8.7b-2.fc6 lat-1.2.2-1.fc6 liblo-0.23-12.fc6 pl-5.6.28-1.fc6 NEW qdbm-1.8.74-2.fc6 xpilot-ng-4.7.2-11.fc6 Packages built and released for Fedora Extras 5: 4 NEW hyperestraier-1.4.9-2.fc5.1 kazehakase-0.4.4.1-3.fc5 lat-1.2.2-1.fc5 NEW qdbm-1.8.74-2.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Fri Feb 23 20:18:48 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 23 Feb 2007 20:18:48 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-23 Message-ID: <20070223201848.5050.37588@extras64.linux.duke.edu> New report for: tscherf AT redhat.com package: Democracy - 0.9.5.1-1.fc6.i386 from fedora-extras-6-i386 unresolved deps: libfame package: Democracy - 0.9.5.1-1.fc6.ppc from fedora-extras-6-ppc unresolved deps: libfame package: Democracy - 0.9.5.1-1.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: libfame ====================================================================== New report for: overholt AT redhat.com package: eclipse-emf - 2.2.1-9.fc6.i386 from fedora-extras-6-i386 unresolved deps: eclipse-platform < 1:3.2.2 package: eclipse-emf - 2.2.1-9.fc6.ppc from fedora-extras-6-ppc unresolved deps: eclipse-platform < 1:3.2.2 package: eclipse-emf - 2.2.1-9.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: eclipse-platform < 1:3.2.2 ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (14 days) libetpan - 0.49-1.fc7.i386 (14 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (14 days) cgoorah AT yahoo.com.au irsim - 9.7.41-5.fc7.i386 (9 days) irsim - 9.7.41-5.fc7.ppc (9 days) toped - 0.8.2-2.fc6.i386 (70 days) toped - 0.8.2-2.fc6.ppc (70 days) toped - 0.8.2-2.fc6.x86_64 (70 days) xcircuit - 3.4.26-18.fc7.i386 (9 days) xcircuit - 3.4.26-18.fc7.ppc (9 days) xcircuit - 3.4.26-18.fc7.x86_64 (9 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (77 days) csound - 5.03.0-9.fc7.i386 (77 days) csound - 5.03.0-9.fc7.ppc (77 days) csound - 5.03.0-9.fc7.x86_64 (77 days) csound-python - 5.03.0-9.fc7.i386 (77 days) csound-python - 5.03.0-9.fc7.ppc (77 days) csound-python - 5.03.0-9.fc7.x86_64 (77 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (79 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (79 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (79 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (79 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (79 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (79 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (79 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (77 days) enrico.scholz AT informatik.tu-chemnitz.de tor-core - 0.1.1.26-2.fc7.i386 tor-core - 0.1.1.26-2.fc7.ppc tor-core - 0.1.1.26-2.fc7.x86_64 foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (8 days) flac123 - 0.0.9-1.fc7.ppc (8 days) flac123 - 0.0.9-1.fc7.x86_64 (8 days) muine - 0.8.7-1.fc7.i386 (8 days) muine - 0.8.7-1.fc7.i386 (8 days) muine - 0.8.7-1.fc7.ppc (8 days) muine - 0.8.7-1.fc7.x86_64 (8 days) gemi AT bluewin.ch audacity - 1.3.2-7.20070106cvs.fc7.i386 (8 days) audacity - 1.3.2-7.20070106cvs.fc7.ppc (8 days) audacity - 1.3.2-7.20070106cvs.fc7.x86_64 (8 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.20_1.2932.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (74 days) libreadline-java - 0.8.0-13.fc6.i386 (74 days) libreadline-java - 0.8.0-13.fc6.ppc (74 days) libreadline-java - 0.8.0-13.fc6.x86_64 (74 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (137 days) linphone - 1.2.0-4.fc5.ppc (137 days) linphone - 1.2.0-4.fc5.x86_64 (137 days) jima AT beer.tclug.org scanssh - 2.1-10.fc7.i386 scanssh - 2.1-10.fc7.ppc scanssh - 2.1-10.fc7.x86_64 oliver AT linux-kernel.at syck-php - 0.55-13.fc7.i386 (6 days) syck-php - 0.55-13.fc7.ppc (6 days) syck-php - 0.55-13.fc7.x86_64 (6 days) orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (77 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (77 days) overholt AT redhat.com eclipse-emf - 2.2.1-9.fc6.i386 eclipse-emf - 2.2.1-9.fc6.ppc eclipse-emf - 2.2.1-9.fc6.x86_64 paul AT xelerance.com hping3 - 0.0.20051105-6.fc7.i386 (9 days) hping3 - 0.0.20051105-6.fc7.ppc (9 days) hping3 - 0.0.20051105-6.fc7.x86_64 (9 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (6 days) k3b-extras - 0.12.17-1.fc6.ppc (6 days) k3b-extras - 0.12.17-1.fc6.x86_64 (6 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (77 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 (9 days) xpa - 2.1.6-8.fc7.i386 (9 days) xpa - 2.1.6-8.fc7.ppc (9 days) xpa - 2.1.6-8.fc7.x86_64 (9 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (77 days) xmldiff - 0.6.7-12.fc6.ppc (77 days) xmldiff - 0.6.7-12.fc6.x86_64 (77 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 (9 days) R - 2.4.1-2.fc7.i386 (9 days) R - 2.4.1-2.fc7.ppc (9 days) R - 2.4.1-2.fc7.x86_64 (9 days) tscherf AT redhat.com Democracy - 0.9.5.1-1.fc6.i386 Democracy - 0.9.5.1-1.fc6.ppc Democracy - 0.9.5.1-1.fc6.x86_64 ville.skytta AT iki.fi kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 (9 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 (9 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc (9 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (9 days) kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 (9 days) kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (9 days) kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc (9 days) ====================================================================== Broken packages in fedora-extras-5-i386: linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-6-i386: Democracy-0.9.5.1-1.fc6.i386 requires libfame eclipse-emf-2.2.1-9.fc6.i386 requires eclipse-platform < 1:3.2.2 ====================================================================== Broken packages in fedora-extras-6-ppc: Democracy-0.9.5.1-1.fc6.ppc requires libfame eclipse-emf-2.2.1-9.fc6.ppc requires eclipse-platform < 1:3.2.2 ====================================================================== Broken packages in fedora-extras-6-x86_64: Democracy-0.9.5.1-1.fc6.x86_64 requires libfame eclipse-emf-2.2.1-9.fc6.x86_64 requires eclipse-platform < 1:3.2.2 ====================================================================== Broken packages in fedora-extras-development-i386: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC++.so.5 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.i386 requires libtcl8.5.so irsim-9.7.41-5.fc7.i386 requires libtk8.5.so irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2932.fc7 kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 scanssh-2.1-10.fc7.i386 requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.i386 requires php = 0:5.2.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 tor-core-0.1.1.26-2.fc7.i386 requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-ppc: R-2.4.1-2.fc7.ppc requires libtk8.5.so R-2.4.1-2.fc7.ppc requires libtcl8.5.so audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC++.so.5 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.ppc requires libtcl8.5.so irsim-9.7.41-5.fc7.ppc requires libtk8.5.so irsim-9.7.41-5.fc7.ppc requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 muine-0.8.7-1.fc7.ppc requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 scanssh-2.1-10.fc7.ppc requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.ppc requires php = 0:5.2.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 tor-core-0.1.1.26-2.fc7.ppc requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.ppc requires libtk8.5.so xcircuit-3.4.26-18.fc7.ppc requires libtcl8.5.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.ppc requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-x86_64: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so R-2.4.1-2.fc7.x86_64 requires libtcl8.5.so()(64bit) R-2.4.1-2.fc7.x86_64 requires libtk8.5.so()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC++.so.5()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC.so.7()(64bit) claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) hping3-0.0.20051105-6.fc7.x86_64 requires libtcl8.5.so()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 muine-0.8.7-1.fc7.x86_64 requires libFLAC.so.7()(64bit) openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) scanssh-2.1-10.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) syck-php-0.55-13.fc7.x86_64 requires php = 0:5.2.0 toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) tor-core-0.1.1.26-2.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtk8.5.so()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtcl8.5.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so xpa-2.1.6-8.fc7.x86_64 requires libtcl8.5.so()(64bit) From j.w.r.degoede at hhs.nl Fri Feb 23 20:38:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 23 Feb 2007 21:38:23 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45DF3D33.3030207@redhat.com> References: <45DF3D33.3030207@redhat.com> Message-ID: <45DF50BF.5090705@hhs.nl> Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > It appears that a few folks want sdcc, but do the packaging standards > for cross compilers and the concern about names being dropped into > /usr/bin should be solved first? > 1) The cross compile stuff being discussed so far was about a cross compiling binutils + gcc + libs, sdcc is a whole different compiler, which comes with its own libc (I think) etc. packaging sdcc sure would be interesting, and could/should try to follow the guidelines being developed for cross-gcc where possible 2) About the cross compiling gcc guidelines I've been having both on and off-list discussions on this topic with Ralf Corsepius, mostly we agree on what I proposed in my initial mail about this from this week: https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00329.html Besides my post we also have: http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers?highlight=%28Packaging%29 Which was created by Tibbs over a year ago in response to a package review request for cross-compile stuff by Ralf. This is mostly compatible with my proposal, but less complete. The only difference is that both Ralf and I don't like the proposed prefixing of cross- in front of the packages, if one installs arm-linux-gcc on a x86_64, its obvious that its a cross compiler and the names will get long enough with just prefixing the canonical target. Other then from Ralf I have had 0 replies. Ralf had the same experience when submitting 2 packages as a first try for review, that was over a year ago and noone has responded, except for Tibbs setting up the wiki page, which also has bitrotted since then.since Ralf and I seem to be the only ones seriously enough interested in this to actually invest time, I suggest that we (Ralf and I) form a cross-compile / embedded SIG and work out a set of guidelines for cross stuff within this SIG, much like the Games SIG has some additional Guidelines for games. Since Ralf and I agree for 99.9% on my proposal, this really is almost done. The only thing which I want discussed in a wider audience / need more input in is the SRPM issue, quoting from my original mail: "The SRPMS for all these packages will most of the time contain the exact same tarbals as the native binutils / gcc / libs Possible solutions: a) Live with the extra diskspace / bandwidth cost this induces upon our mirrors b) *** Warning dirty hack *** Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep and if it isn't there bail with a message howto get the tarbal from the srpms for the native packages. We can use the sources file and the look-aside cache to make the test for the tarbal succeed on the buildsys. Advantages: saves tons of diskspace. Disadvantage: slight inconvienience for people trying to rebuild the srpm's manually. Large inconvienience for people doing automated rebuilds (aurora for example) I honestly don't know what todo here. I kinda like solution b), except for the pain it causes to aurora and possible others." So what do you think / any advice on the SRPM issue Warren? Regards, Hans From trond.danielsen at gmail.com Fri Feb 23 20:31:42 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Fri, 23 Feb 2007 21:31:42 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45DF50BF.5090705@hhs.nl> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> Message-ID: <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> 2007/2/23, Hans de Goede : > > > Warren Togami wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > > > It appears that a few folks want sdcc, but do the packaging standards > > for cross compilers and the concern about names being dropped into > > /usr/bin should be solved first? > > > > 1) The cross compile stuff being discussed so far was about a cross > compiling binutils + gcc + libs, sdcc is a whole different compiler, > which comes with its own libc (I think) etc. packaging sdcc sure > would be interesting, and could/should try to follow the guidelines > being developed for cross-gcc where possible > Even though sdcc comes with its own libc, and are different from gcc in many ways, I do think it makes sense to follow the same guidelines as other cross compilers. This makes everything more consitent. The spec file for sdcc is almost complete, but I wanted to clarify some of the questions I had regarding "best practice" with regards to cross compilers. > 2) About the cross compiling gcc guidelines I've been having both on and > off-list discussions on this topic with Ralf Corsepius, mostly we > agree on what I proposed in my initial mail about this from this > week: > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00329.html > > Besides my post we also have: > http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers?highlight=%28Packaging%29 > Which was created by Tibbs over a year ago in response to a package > review request for cross-compile stuff by Ralf. This is mostly > compatible with my proposal, but less complete. The only difference > is that both Ralf and I don't like the proposed prefixing of cross- > in front of the packages, if one installs arm-linux-gcc on a x86_64, > its obvious that its a cross compiler and the names will get long > enough with just prefixing the canonical target. > > Other then from Ralf I have had 0 replies. Ralf had the same > experience when submitting 2 packages as a first try for review, that > was over a year ago and noone has responded, except for Tibbs setting > up the wiki page, which also has bitrotted since then.since Ralf and > I seem to be the only ones seriously enough interested in this to > actually invest time, I suggest that we (Ralf and I) form a > cross-compile / embedded SIG and work out a set of guidelines for > cross stuff within this SIG, much like the Games SIG has some > additional Guidelines for games. > > Since Ralf and I agree for 99.9% on my proposal, this really is > almost done. The only thing which I want discussed in a wider > audience / need more input in is the SRPM issue, quoting from my > original mail: > "The SRPMS for all these packages will most of the time contain the > exact same tarbals as the native binutils / gcc / libs > > Possible solutions: > a) Live with the extra diskspace / bandwidth cost this induces upon > our mirrors > b) *** Warning dirty hack *** > Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep > and if it isn't there bail with a message howto get the tarbal > from the srpms for the native packages. We can use the sources > file and the look-aside cache to make the test for the tarbal > succeed on the buildsys. Advantages: saves tons of diskspace. > Disadvantage: slight inconvienience for people trying to rebuild > the srpm's manually. Large inconvienience for people doing > automated rebuilds (aurora for example) > > I honestly don't know what todo here. I kinda like solution b), > except for the pain it causes to aurora and possible others." > > So what do you think / any advice on the SRPM issue Warren? > > Regards, > > Hans > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > I would very much like to contribute to make this happend. I have both a personal and professional interest in seeing as many tools for embedded system development available in the Fedora repositories. There are a number of tools that are missing, that would make Fedora a more attractive target for engineers. A quick summary: - Tools for Atmels AVR and AVR32 processors. Both are supported by free software tools. - Tools for Analog Devices Blackfin. This DSP runs uclinux, and compilers and other related tools are available. Once the guidelines are completed, I will get down to packing up as many of these as possible. -- Trond Danielsen From wtogami at redhat.com Fri Feb 23 21:34:47 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Feb 2007 16:34:47 -0500 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45DF50BF.5090705@hhs.nl> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> Message-ID: <45DF5DF7.5040302@redhat.com> glibc.src.rpm 15.6MB gcc.src.rpm 39MB Hans de Goede wrote: > b) *** Warning dirty hack *** > Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep > and if it isn't there bail with a message howto get the tarbal > from the srpms for the native packages. We can use the sources http://cvs.fedora.redhat.com//repo/dist/glibc/glibc-2.5-fedora-20061008T1257.tar.bz2/ 6aa114e3cde495c267ff8a6e55b90bec/glibc-2.5-fedora-20061008T1257.tar.bz2 The files are available if you know the exact URL, which is possible to figure out from the CVS module of the original SRPM and hash. > file and the look-aside cache to make the test for the tarbal > succeed on the buildsys. Advantages: saves tons of diskspace. Right, this is not problematic at all to our own buildsys. This might be a useful optimization for other cases. For example, where plugins need the original source tarball to build. > Disadvantage: slight inconvienience for people trying to rebuild > the srpm's manually. Large inconvienience for people doing > automated rebuilds (aurora for example) > This need not be inconvenient for manual builders and other automated rebuilds. We only need an evil auto-downloader, but make it disabled by default. Then manual or automated rebuilders can choose to enable evil by setting an environment variable $AUTO_GRAB_SOURCE if they want to automate it. Otherwise it tells the user exactly what to do. BuildRequires: auto-grab-source %prep %setup -q GRAB_SOURCENAME=glibc-2.5-fedora-20061008T1257.tar.bz2 GRAB_HASH=6aa114e3cde495c267ff8a6e55b90bec GRAB_NAME=glibc auto-grab-source $GRAB_NAME $GRAB_SOURCENAME $GRAB_HASH The pseudocode of this tool =========================== if file exists and matches hash return 0 else if $AUTO_GRAB_SOURCE == true attempt to grab verify else display instructive error message about what to do fi fi Is this too evil and ugly? Is this evilness worth avoiding 50MB+ of extra .src.rpm for all mirrors to throw around? I don't have any opinion either way. This does not effect our own buildsys, or anybody else building packages directly from CVS. Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Feb 23 21:43:45 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Feb 2007 16:43:45 -0500 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45DF5DF7.5040302@redhat.com> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <45DF5DF7.5040302@redhat.com> Message-ID: <45DF6011.9050208@redhat.com> Warren Togami wrote: > > BuildRequires: auto-grab-source > > %prep > %setup -q > GRAB_SOURCENAME=glibc-2.5-fedora-20061008T1257.tar.bz2 > GRAB_HASH=6aa114e3cde495c267ff8a6e55b90bec > GRAB_NAME=glibc > auto-grab-source $GRAB_NAME $GRAB_SOURCENAME $GRAB_HASH It could be even simpler than this. BuildRequires: auto-grab-source Source#: sources %prep auto-grab-source glibc auto-grab-source gcc auto-grab-source binutils # auto-grab-source reads the sources file for filenames and hashes # needs %%{name} parameter because that isn't specified in sources %setup -q Warren Togami wtogami at redhat.com From kevin.kofler at chello.at Fri Feb 23 22:59:26 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Feb 2007 22:59:26 +0000 (UTC) Subject: sdcc - Cross Compiler, Needs Packaging Standards? References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> Message-ID: Trond Danielsen writes: > There are a number of tools that are missing, that would make Fedora a > more attractive target for engineers. A quick summary: > > - Tools for Atmels AVR and AVR32 processors. Both are supported by > free software tools. > - Tools for Analog Devices Blackfin. This DSP runs uclinux, and > compilers and other related tools are available. Add TIGCC to the list. http://tigcc.ticalc.org It's a (heavily-patched) GCC + a (heavily patched) GNU as + a custom linker (ld-tigcc) + a custom C library (TIGCCLIB) + other tools targeting the TI calculators with a Motorola 68000 CPU, namely the TI-89, the TI-89 Titanium, the TI-92, the TI-92 Plus and the Voyage 200. The legacy A68k assembler is non-Free, so that can't go into Fedora, however you get a fully-functional toolchain without it (with only the GNU assembler, which is what GCC uses anyway), you just can't build legacy assembly programs written for A68k. Everything else in TIGCC is Free Software under the GPL or compatible licenses (e.g. the libgcc exception for the runtime). WARNING: My current RPM is a horrible kludge, so please don't try taking my current specfile and submitting it for review, it will never pass. ;-) (Copying installed binaries into the buildroot definitely isn't going to build in Mock...) If I have anything acceptable, I'll probably submit it for review myself. As for the prefix problem: my RPM currently installs to /usr/local/tigcc, which is a blatant guideline and FHS violation. But if I'm going to change it, it'd better be to the correct location. ;-) So, is /usr/tigcc a good prefix to pick? Or would /usr/m68k-tigcc be better? (Our patched GCC doesn't care about what I pick, I can use pretty much any directory as the prefix provided it's not used by anything else.) We also have: * an IDE (KTIGCC, based on the KDE libs) * an emulator (TiEmu) with an integrated (patched) GDB and Insight port and with a GPLed replacement OS called PedroM (so the emulator can be used out of the box without TI's non-Free OS; it can also load the non-Free OS of course): http://lpg.ticalc.org/prj_tiemu/ * linking software (TiLP): http://lpg.ticalc.org/prj_tilp/ Kevin Kofler From j.w.r.degoede at hhs.nl Sat Feb 24 11:35:59 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 Feb 2007 12:35:59 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> Message-ID: <45E0231F.1040701@hhs.nl> Kevin Kofler wrote: > Trond Danielsen writes: >> There are a number of tools that are missing, that would make Fedora a >> more attractive target for engineers. A quick summary: >> >> - Tools for Atmels AVR and AVR32 processors. Both are supported by >> free software tools. >> - Tools for Analog Devices Blackfin. This DSP runs uclinux, and >> compilers and other related tools are available. > > Add TIGCC to the list. http://tigcc.ticalc.org > It's a (heavily-patched) GCC + a (heavily patched) GNU as + a custom linker > (ld-tigcc) + a custom C library (TIGCCLIB) + other tools targeting the TI > calculators with a Motorola 68000 CPU, namely the TI-89, the TI-89 Titanium, > the TI-92, the TI-92 Plus and the Voyage 200. > > The legacy A68k assembler is non-Free, so that can't go into Fedora, however > you get a fully-functional toolchain without it (with only the GNU assembler, > which is what GCC uses anyway), you just can't build legacy assembly programs > written for A68k. Everything else in TIGCC is Free Software under the GPL or > compatible licenses (e.g. the libgcc exception for the runtime). > > WARNING: My current RPM is a horrible kludge, so please don't try taking my > current specfile and submitting it for review, it will never pass. ;-) (Copying > installed binaries into the buildroot definitely isn't going to build in > Mock...) If I have anything acceptable, I'll probably submit it for review > myself. > > As for the prefix problem: my RPM currently installs to /usr/local/tigcc, which > is a blatant guideline and FHS violation. But if I'm going to change it, it'd > better be to the correct location. ;-) So, is /usr/tigcc a good prefix to pick? > Or would /usr/m68k-tigcc be better? (Our patched GCC doesn't care about what I > pick, I can use pretty much any directory as the prefix provided it's not used > by anything else.) > > We also have: > * an IDE (KTIGCC, based on the KDE libs) > * an emulator (TiEmu) with an integrated (patched) GDB and Insight port and > with a GPLed replacement OS called PedroM (so the emulator can be used out of > the box without TI's non-Free OS; it can also load the non-Free OS of course): > http://lpg.ticalc.org/prj_tiemu/ > * linking software (TiLP): http://lpg.ticalc.org/prj_tilp/ > > Kevin Kofler > This all sound specific, as also mentioned in another mail in this thread I would like to start a cross-compile SIG to get all this organised and to help each other with open issues and reviews. So far I know of the following people being interested: Hans de Goede (avr-gcc, arm-linux-gp2x-gcc) Kevin Kofler (tigcc) Ralf Corsepius (rtems) Trond Danielsen (sdcc, avr-gcc, avr32-gcc, Analog Devices Blackfin) So assuming all named people are reading this, who's in? I'am in myself ofcourse and (see below) I believe Trond is in too. I think tigcc would be a great addition, so any chance you could start posting somewhat cleaned up specs for review, starting with the most basic components first? If you encounter any problems you cannot solve yourself, please contant me / us, I've got lots of packaging experience, perhaps I can help. Regards, Hans From j.w.r.degoede at hhs.nl Sat Feb 24 11:36:03 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 Feb 2007 12:36:03 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> Message-ID: <45E02323.2080200@hhs.nl> Hi All, Trond Danielsen wrote: > 2007/2/23, Hans de Goede : >> >> >> 1) The cross compile stuff being discussed so far was about a cross >> compiling binutils + gcc + libs, sdcc is a whole different compiler, >> which comes with its own libc (I think) etc. packaging sdcc sure >> would be interesting, and could/should try to follow the guidelines >> being developed for cross-gcc where possible >> > > Even though sdcc comes with its own libc, and are different from gcc > in many ways, I do think it makes sense to follow the same guidelines > as other cross compilers. This makes everything more consitent. > I'm not sure I've just taken a look at the spec-file for sdcc from your review request: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 And I like what I see, I think that there are 3 distinct issues we need to look at when packaging cross-compilers / cross-development tools: 1) What does upstream's makefile / configure do by default, deviating from this will cause troubles, cause many makefiles for projects intended te be build with this tools will break if we put things in other places. This is especially important when the build-chain consists of multiple parts as it does with binutils/gcc/xxxlibcxxx because if we decide todo things different there the spec files will turn into huge patch fests to get things further down the chain to build (and we will be inflicting similar pain on people trying to build existing stuff with our tools. 2) Try to be as FHS compatible as possible, except where this breaks 1 3) Files most not conflict, so sdcc installing a /usr/bin/cc is a BAD idea (_fictional_ example). In the case were upstream doesn't do this themselves all files under /usr/bin must be prefixed with a common prefix. Likewise header files for cross development must not go under /usr/include, but in their own private dir. The same for libs. This leads to the conclusion that partially this will be a case by case job. For cross-compiling gcc(chain) rpms we can make guidelines, but I do not believe that we should force packages for other cross-compilers to follow these guidelines. On the contrary, I believe we should stay as close to upstream as possible, to minimize the element of surprise for end users. This is why I plea for a cross-compiler SIG, so far I know of the following people being interested: Hans de Goede (avr-gcc, arm-linux-gp2x-gcc) Kevin Kofler (tigcc) Ralf Corsepius (rtems) Trond Danielsen (sdcc, avr-gcc, avr32-gcc, Analog Devices Blackfin) So assuming all named people are reading this, who's in? I'am in myself ofcourse and (see below) I believe Trond is in too. Then within this SIG we can try to create general cross compiling guidelines and where this makes sense because there is a whole family with a common pattern, per compiler-family guidelines. The document which I posted earlier: https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00329.html Is in me eyes a reasonable start for guidelines for the gcc-family of cross compilers. > The spec file for sdcc is almost complete, but I wanted to clarify > some of the questions I had regarding "best practice" with regards to > cross compilers. > As said I've taken a quick peek and I like it, what questions do you have? > I would very much like to contribute to make this happend. I have both > a personal and professional interest in seeing as many tools for > embedded system development available in the Fedora repositories. > There are a number of tools that are missing, that would make Fedora a > more attractive target for engineers. A quick summary: > > - Tools for Atmels AVR and AVR32 processors. Both are supported by > free software tools. > - Tools for Analog Devices Blackfin. This DSP runs uclinux, and > compilers and other related tools are available. > > Once the guidelines are completed, I will get down to packing up as > many of these as possible. > Welcome aboard, notice that I've got a couple of last-year CS students working on packaging avr-gcc, so please contact me before things get done twice. Regards, Hans From j.w.r.degoede at hhs.nl Sat Feb 24 11:40:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 Feb 2007 12:40:23 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45DF6011.9050208@redhat.com> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <45DF5DF7.5040302@redhat.com> <45DF6011.9050208@redhat.com> Message-ID: <45E02427.705@hhs.nl> Warren Togami wrote: > Warren Togami wrote: >> >> BuildRequires: auto-grab-source >> >> %prep >> %setup -q >> GRAB_SOURCENAME=glibc-2.5-fedora-20061008T1257.tar.bz2 >> GRAB_HASH=6aa114e3cde495c267ff8a6e55b90bec >> GRAB_NAME=glibc >> auto-grab-source $GRAB_NAME $GRAB_SOURCENAME $GRAB_HASH > > It could be even simpler than this. > > BuildRequires: auto-grab-source > Source#: sources > > %prep > auto-grab-source glibc > auto-grab-source gcc > auto-grab-source binutils > # auto-grab-source reads the sources file for filenames and hashes > # needs %%{name} parameter because that isn't specified in sources > %setup -q > I kinda like this, except that I think auto-grab-source might just as well be an rpm macro, currently its too small IMHO to be in its own package. That still leaves the question is this too evil for the many MB's it will safe? Just like you Warren I honestly don't know. Do you know anyone we could ask? Maybe we should ask the FPC to rule on this? Regards, Hans From j.w.r.degoede at hhs.nl Sat Feb 24 11:42:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 Feb 2007 12:42:55 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <6E49FA91-4FC8-4A12-BE27-4A86C1027FE9@deds.nl> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> <20070222153232.226706de@localhost.localdomain> <6E49FA91-4FC8-4A12-BE27-4A86C1027FE9@deds.nl> Message-ID: <45E024BF.3020606@hhs.nl> Johan Kok wrote: > > On 22-feb-2007, at 15:32, Sebastian Vahl wrote: >> Am Thu, 1 Feb 2007 18:15:34 +0100 >> schrieb Johan Kok : >>> Added that account and just spoke to him. He's not very available to >>> work on FE packages at the moment. He will respond in this thread >>> soon. >> >> Have you heard a lifesign from Hugo? Or did I just missed the mail? > > Hm, I haven't heard anything from Hugo since that chat. I suppose he > never wrote that mail we talked about. In the conversation he said that > he was occupied at the moment and that he did not have time for Fedora. > He suggested that anyone who would like to maintain or co-maintain one > of his packages (with him) should do so and said that he would write > that in a message to this list. > I say that he truely is AWOL then, so lets orphan his packages. Can someone make the list of his packages (again) and post that to the list, then give people a couple of days to pick up some of his packages. Once its clear which ones get a new owner and which ones will get orphaned we can send a list with this info to a CVS admin to make the necessary changes. Regards, Hans From trond.danielsen at gmail.com Sat Feb 24 14:18:22 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Sat, 24 Feb 2007 15:18:22 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45E02323.2080200@hhs.nl> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> <45E02323.2080200@hhs.nl> Message-ID: <409676c70702240618w44a8cb0tc6f3dab048a9322d@mail.gmail.com> 2007/2/24, Hans de Goede : > Hi All, > > Trond Danielsen wrote: > > 2007/2/23, Hans de Goede : > >> > >> > >> 1) The cross compile stuff being discussed so far was about a cross > >> compiling binutils + gcc + libs, sdcc is a whole different compiler, > >> which comes with its own libc (I think) etc. packaging sdcc sure > >> would be interesting, and could/should try to follow the guidelines > >> being developed for cross-gcc where possible > >> > > > > Even though sdcc comes with its own libc, and are different from gcc > > in many ways, I do think it makes sense to follow the same guidelines > > as other cross compilers. This makes everything more consitent. > > > > I'm not sure I've just taken a look at the spec-file for sdcc from your > review request: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > And I like what I see, I think that there are 3 distinct issues we need > to look at when packaging cross-compilers / cross-development tools: > 1) What does upstream's makefile / configure do by default, deviating > from this will cause troubles, cause many makefiles for projects > intended te be build with this tools will break if we put things in > other places. This is especially important when the build-chain > consists of multiple parts as it does with binutils/gcc/xxxlibcxxx > because if we decide todo things different there the spec files > will turn into huge patch fests to get things further down the chain > to build (and we will be inflicting similar pain on people trying to > build existing stuff with our tools. > > 2) Try to be as FHS compatible as possible, except where this breaks 1 > > 3) Files most not conflict, so sdcc installing a /usr/bin/cc is a BAD > idea (_fictional_ example). In the case were upstream doesn't do this > themselves all files under /usr/bin must be prefixed with a common > prefix. Likewise header files for cross development must not go under > /usr/include, but in their own private dir. The same for libs. > > This leads to the conclusion that partially this will be a case by case > job. For cross-compiling gcc(chain) rpms we can make guidelines, but I > do not believe that we should force packages for other cross-compilers > to follow these guidelines. On the contrary, I believe we should stay as > close to upstream as possible, to minimize the element of surprise for > end users. > > This is why I plea for a cross-compiler SIG, so far I know of the > following people being interested: > > Hans de Goede (avr-gcc, arm-linux-gp2x-gcc) > Kevin Kofler (tigcc) > Ralf Corsepius (rtems) > Trond Danielsen (sdcc, avr-gcc, avr32-gcc, Analog Devices Blackfin) > > So assuming all named people are reading this, who's in? I'am in myself > ofcourse and (see below) I believe Trond is in too. Confirmed. Count me in. > > Then within this SIG we can try to create general cross compiling > guidelines and where this makes sense because there is a whole family > with a common pattern, per compiler-family guidelines. The document > which I posted earlier: > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00329.html > > Is in me eyes a reasonable start for guidelines for the gcc-family of > cross compilers. > I think this is a very good starting point for a complete set of guide lines. What remains is to create a wiki page, so that we can start > > The spec file for sdcc is almost complete, but I wanted to clarify > > some of the questions I had regarding "best practice" with regards to > > cross compilers. > > > > As said I've taken a quick peek and I like it, what questions do you have? > The main issue is the install path. avr-gcc installs everything into $prefix/avr, which I think is a good solution. Somebody commented in bugzilla that some of the names of the binaries from sdcc where to generic, and I therefore moved the binaries to /usr/libexec/sdcc, and created symlinks to /usr/bin. But I wonder if this is a good solution...? > > I would very much like to contribute to make this happend. I have both > > a personal and professional interest in seeing as many tools for > > embedded system development available in the Fedora repositories. > > There are a number of tools that are missing, that would make Fedora a > > more attractive target for engineers. A quick summary: > > > > - Tools for Atmels AVR and AVR32 processors. Both are supported by > > free software tools. > > - Tools for Analog Devices Blackfin. This DSP runs uclinux, and > > compilers and other related tools are available. > > > > Once the guidelines are completed, I will get down to packing up as > > many of these as possible. > > > > Welcome aboard, notice that I've got a couple of last-year CS students > working on packaging avr-gcc, so please contact me before things get > done twice. > -- Trond Danielsen From johan-fedora at deds.nl Sat Feb 24 14:41:49 2007 From: johan-fedora at deds.nl (Johan Kok) Date: Sat, 24 Feb 2007 15:41:49 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <45E024BF.3020606@hhs.nl> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> <20070222153232.226706de@localhost.localdomain> <6E49FA91-4FC8-4A12-BE27-4A86C1027FE9@deds.nl> <45E024BF.3020606@hhs.nl> Message-ID: <1CE6B0FC-9095-4BEF-916C-70DEE07139CA@deds.nl> On 24-feb-2007, at 12:42, Hans de Goede wrote: > Johan Kok wrote: >> >> Hm, I haven't heard anything from Hugo since that chat. I suppose he >> never wrote that mail we talked about. > > I say that he truely is AWOL then, so lets orphan his packages. Can > someone make the list of his packages (again) and post that to the > list, > then give people a couple of days to pick up some of his packages. guichan kerry knemo metamonitor netpanzer netpanzer-data ode pengupop python-ogg python-vorbis tuxpuck xmoto -- Johan From buildsys at fedoraproject.org Sat Feb 24 15:42:52 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 24 Feb 2007 10:42:52 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-24 Message-ID: <20070224154252.29C9815212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 0 Packages built and released for Fedora Extras 6: 18 Democracy-0.9.5.1-3.fc6 audacity-1.3.2-8.fc6 beryl-core-0.1.9999.2-2.fc6 beryl-plugins-0.1.9999.2-2.fc6 NEW deluge-0.4.1-6.fc6 NEW fedora-ds-base-1.1.0-0.1.20070223.fc6 gajim-0.11.1-1.fc6 gweled-0.7-7.fc6 initng-ifiles-0.0.8.1-1.fc6 nagios-plugins-1.4.6-1.fc6 nrpe-2.7-3.fc6 numpy-1.0.1-3.fc6 php-pecl-zip-1.8.5-1.fc6 rssowl-1.2.3-3.fc6 vdr-sudoku-0.1.3-1.fc6 wxMaxima-0.7.1-2.fc6 xl2tpd-1.1.08-2.fc6 xpilot-ng-4.7.2-12.fc6 Packages built and released for Fedora Extras 5: 9 NEW deluge-0.4.1-6.fc5 NEW fedora-ds-base-1.1.0-0.1.20070223.fc5 initng-ifiles-0.0.8.1-1.fc5 nagios-plugins-1.4.6-1.fc5 nrpe-2.7-3.fc5 numpy-1.0.1-3.fc5 php-pecl-zip-1.8.5-1.fc5 wxMaxima-0.7.1-2.fc5 xl2tpd-1.1.08-2.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Feb 24 16:49:04 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sat, 24 Feb 2007 16:49:04 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-02-24 Message-ID: <20070224164904.3973.82226@extras64.linux.duke.edu> New report for: tscherf AT redhat.com package: Democracy - 0.9.5.1-3.fc6.i386 from fedora-extras-6-i386 unresolved deps: dbus-pythoni package: Democracy - 0.9.5.1-3.fc6.ppc from fedora-extras-6-ppc unresolved deps: dbus-pythoni package: Democracy - 0.9.5.1-3.fc6.x86_64 from fedora-extras-6-x86_64 unresolved deps: dbus-pythoni ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (15 days) libetpan - 0.49-1.fc7.i386 (15 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (15 days) cgoorah AT yahoo.com.au irsim - 9.7.41-5.fc7.i386 (10 days) irsim - 9.7.41-5.fc7.ppc (10 days) toped - 0.8.2-2.fc6.i386 (71 days) toped - 0.8.2-2.fc6.ppc (71 days) toped - 0.8.2-2.fc6.x86_64 (71 days) xcircuit - 3.4.26-18.fc7.i386 (10 days) xcircuit - 3.4.26-18.fc7.ppc (10 days) xcircuit - 3.4.26-18.fc7.x86_64 (10 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (78 days) csound - 5.03.0-9.fc7.i386 (78 days) csound - 5.03.0-9.fc7.ppc (78 days) csound - 5.03.0-9.fc7.x86_64 (78 days) csound-python - 5.03.0-9.fc7.i386 (78 days) csound-python - 5.03.0-9.fc7.ppc (78 days) csound-python - 5.03.0-9.fc7.x86_64 (78 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (80 days) openpbx - 1.2-3.rc2.svn2135.fc7.i386 (80 days) openpbx - 1.2-3.rc2.svn2135.fc7.ppc (80 days) openpbx - 1.2-3.rc2.svn2135.fc7.x86_64 (80 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.i386 (80 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.ppc (80 days) openpbx-postgresql - 1.2-3.rc2.svn2135.fc7.x86_64 (80 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (78 days) enrico.scholz AT informatik.tu-chemnitz.de tor-core - 0.1.1.26-2.fc7.i386 (2 days) tor-core - 0.1.1.26-2.fc7.ppc (2 days) tor-core - 0.1.1.26-2.fc7.x86_64 (2 days) foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (9 days) flac123 - 0.0.9-1.fc7.ppc (9 days) flac123 - 0.0.9-1.fc7.x86_64 (9 days) muine - 0.8.7-1.fc7.i386 (9 days) muine - 0.8.7-1.fc7.i386 (9 days) muine - 0.8.7-1.fc7.ppc (9 days) muine - 0.8.7-1.fc7.x86_64 (9 days) gemi AT bluewin.ch audacity - 1.3.2-7.20070106cvs.fc7.i386 (9 days) audacity - 1.3.2-7.20070106cvs.fc7.ppc (9 days) audacity - 1.3.2-7.20070106cvs.fc7.x86_64 (9 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i586 (2 days) kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i686 (2 days) kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 (2 days) kmod-sysprof-PAE - 1.0.8-1.2.6.20_1.2932.fc7.i686 (2 days) kmod-sysprof-kdump - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 (2 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (75 days) libreadline-java - 0.8.0-13.fc6.i386 (75 days) libreadline-java - 0.8.0-13.fc6.ppc (75 days) libreadline-java - 0.8.0-13.fc6.x86_64 (75 days) jeff AT ocjtech.us linphone - 1.2.0-4.fc5.i386 (138 days) linphone - 1.2.0-4.fc5.ppc (138 days) linphone - 1.2.0-4.fc5.x86_64 (138 days) jima AT beer.tclug.org scanssh - 2.1-10.fc7.i386 (2 days) scanssh - 2.1-10.fc7.ppc (2 days) scanssh - 2.1-10.fc7.x86_64 (2 days) oliver AT linux-kernel.at syck-php - 0.55-13.fc7.i386 (7 days) syck-php - 0.55-13.fc7.ppc (7 days) syck-php - 0.55-13.fc7.x86_64 (7 days) orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (78 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (78 days) overholt AT redhat.com eclipse-emf - 2.2.1-9.fc6.i386 eclipse-emf - 2.2.1-9.fc6.ppc eclipse-emf - 2.2.1-9.fc6.x86_64 paul AT xelerance.com hping3 - 0.0.20051105-6.fc7.i386 (10 days) hping3 - 0.0.20051105-6.fc7.ppc (10 days) hping3 - 0.0.20051105-6.fc7.x86_64 (10 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (7 days) k3b-extras - 0.12.17-1.fc6.ppc (7 days) k3b-extras - 0.12.17-1.fc6.x86_64 (7 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (78 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 (10 days) xpa - 2.1.6-8.fc7.i386 (10 days) xpa - 2.1.6-8.fc7.ppc (10 days) xpa - 2.1.6-8.fc7.x86_64 (10 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (78 days) xmldiff - 0.6.7-12.fc6.ppc (78 days) xmldiff - 0.6.7-12.fc6.x86_64 (78 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 (10 days) R - 2.4.1-2.fc7.i386 (10 days) R - 2.4.1-2.fc7.ppc (10 days) R - 2.4.1-2.fc7.x86_64 (10 days) tscherf AT redhat.com Democracy - 0.9.5.1-3.fc6.i386 Democracy - 0.9.5.1-3.fc6.ppc Democracy - 0.9.5.1-3.fc6.x86_64 ville.skytta AT iki.fi kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 (10 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 (10 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc (10 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (10 days) kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 (10 days) kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (10 days) kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc (10 days) ====================================================================== Broken packages in fedora-extras-5-i386: linphone-1.2.0-4.fc5.i386 requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-ppc: linphone-1.2.0-4.fc5.ppc requires libortp.so.2 ====================================================================== Broken packages in fedora-extras-5-x86_64: linphone-1.2.0-4.fc5.x86_64 requires libortp.so.2()(64bit) ====================================================================== Broken packages in fedora-extras-6-i386: Democracy-0.9.5.1-3.fc6.i386 requires dbus-pythoni eclipse-emf-2.2.1-9.fc6.i386 requires eclipse-platform < 1:3.2.2 ====================================================================== Broken packages in fedora-extras-6-ppc: Democracy-0.9.5.1-3.fc6.ppc requires dbus-pythoni eclipse-emf-2.2.1-9.fc6.ppc requires eclipse-platform < 1:3.2.2 ====================================================================== Broken packages in fedora-extras-6-x86_64: Democracy-0.9.5.1-3.fc6.x86_64 requires dbus-pythoni eclipse-emf-2.2.1-9.fc6.x86_64 requires eclipse-platform < 1:3.2.2 ====================================================================== Broken packages in fedora-extras-development-i386: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.i386 requires libFLAC++.so.5 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.i386 requires libtcl8.5.so irsim-9.7.41-5.fc7.i386 requires libtk8.5.so irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2932.fc7 kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.i386 requires libpq.so.4 python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 scanssh-2.1-10.fc7.i386 requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.i386 requires php = 0:5.2.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.i386 requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.i386 requires libwx_gtk2u_adv-2.6.so.0 tor-core-0.1.1.26-2.fc7.i386 requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-ppc: R-2.4.1-2.fc7.ppc requires libtk8.5.so R-2.4.1-2.fc7.ppc requires libtcl8.5.so audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC.so.7 audacity-1.3.2-7.20070106cvs.fc7.ppc requires libFLAC++.so.5 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 hping3-0.0.20051105-6.fc7.ppc requires libtcl8.5.so irsim-9.7.41-5.fc7.ppc requires libtk8.5.so irsim-9.7.41-5.fc7.ppc requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 muine-0.8.7-1.fc7.ppc requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.ppc requires libedit.so.0 openpbx-postgresql-1.2-3.rc2.svn2135.fc7.ppc requires libpq.so.4 scanssh-2.1-10.fc7.ppc requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.ppc requires php = 0:5.2.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3) toped-0.8.2-2.fc6.ppc requires libwx_baseu_xml-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_qa-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_baseu_net-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_xrc-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_html-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_baseu-2.6.so.0 toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6) toped-0.8.2-2.fc6.ppc requires libwx_gtk2u_adv-2.6.so.0 tor-core-0.1.1.26-2.fc7.ppc requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.ppc requires libtk8.5.so xcircuit-3.4.26-18.fc7.ppc requires libtcl8.5.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.ppc requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-x86_64: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so R-2.4.1-2.fc7.x86_64 requires libtcl8.5.so()(64bit) R-2.4.1-2.fc7.x86_64 requires libtk8.5.so()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC++.so.5()(64bit) audacity-1.3.2-7.20070106cvs.fc7.x86_64 requires libFLAC.so.7()(64bit) claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) hping3-0.0.20051105-6.fc7.x86_64 requires libtcl8.5.so()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 muine-0.8.7-1.fc7.x86_64 requires libFLAC.so.7()(64bit) openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 openpbx-1.2-3.rc2.svn2135.fc7.x86_64 requires libedit.so.0()(64bit) openpbx-postgresql-1.2-3.rc2.svn2135.fc7.x86_64 requires libpq.so.4()(64bit) paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) scanssh-2.1-10.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) syck-php-0.55-13.fc7.x86_64 requires php = 0:5.2.0 toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_xrc-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_qa-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_xml-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_html-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_baseu_net-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_gl-2.6.so.0()(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) toped-0.8.2-2.fc6.x86_64 requires libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) tor-core-0.1.1.26-2.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtk8.5.so()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtcl8.5.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so xpa-2.1.6-8.fc7.x86_64 requires libtcl8.5.so()(64bit) From wart at kobold.org Sat Feb 24 16:55:16 2007 From: wart at kobold.org (Wart) Date: Sat, 24 Feb 2007 08:55:16 -0800 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <1CE6B0FC-9095-4BEF-916C-70DEE07139CA@deds.nl> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> <20070222153232.226706de@localhost.localdomain> <6E49FA91-4FC8-4A12-BE27-4A86C1027FE9@deds.nl> <45E024BF.3020606@hhs.nl> <1CE6B0FC-9095-4BEF-916C-70DEE07139CA@deds.nl> Message-ID: <45E06DF4.2080307@kobold.org> Johan Kok wrote: > > On 24-feb-2007, at 12:42, Hans de Goede wrote: >> Johan Kok wrote: >>> >>> Hm, I haven't heard anything from Hugo since that chat. I suppose he >>> never wrote that mail we talked about. >> >> I say that he truely is AWOL then, so lets orphan his packages. Can >> someone make the list of his packages (again) and post that to the list, >> then give people a couple of days to pick up some of his packages. > > guichan I can pick up guichan. afaik, it's a dependecy for only two packages, sear and manaworld, both of which are mine. --Wart From rc040203 at freenet.de Sat Feb 24 18:18:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Feb 2007 19:18:49 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <409676c70702240618w44a8cb0tc6f3dab048a9322d@mail.gmail.com> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> <45E02323.2080200@hhs.nl> <409676c70702240618w44a8cb0tc6f3dab048a9322d@mail.gmail.com> Message-ID: <1172341130.23237.526.camel@mccallum.corsepiu.local> On Sat, 2007-02-24 at 15:18 +0100, Trond Danielsen wrote: > 2007/2/24, Hans de Goede : > > Hi All, > > > > Trond Danielsen wrote: > > > 2007/2/23, Hans de Goede : > > >> > > >> > > >> 1) The cross compile stuff being discussed so far was about a cross > > >> compiling binutils + gcc + libs, sdcc is a whole different compiler, > > >> which comes with its own libc (I think) etc. packaging sdcc sure > > >> would be interesting, and could/should try to follow the guidelines > > >> being developed for cross-gcc where possible > > >> > > > > > > Even though sdcc comes with its own libc, and are different from gcc > > > in many ways, I do think it makes sense to follow the same guidelines > > > as other cross compilers. This makes everything more consitent. > > > > > > > I'm not sure I've just taken a look at the spec-file for sdcc from your > > review request: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > > > And I like what I see, I think that there are 3 distinct issues we need > > to look at when packaging cross-compilers / cross-development tools: > > 1) What does upstream's makefile / configure do by default, deviating > > from this will cause troubles, cause many makefiles for projects > > intended te be build with this tools will break if we put things in > > other places. This is especially important when the build-chain > > consists of multiple parts as it does with binutils/gcc/xxxlibcxxx > > because if we decide todo things different there the spec files > > will turn into huge patch fests to get things further down the chain > > to build (and we will be inflicting similar pain on people trying to > > build existing stuff with our tools. > > > > 2) Try to be as FHS compatible as possible, except where this breaks 1 > > > > 3) Files most not conflict, so sdcc installing a /usr/bin/cc is a BAD > > idea (_fictional_ example). In the case were upstream doesn't do this > > themselves all files under /usr/bin must be prefixed with a common > > prefix. Likewise header files for cross development must not go under > > /usr/include, but in their own private dir. The same for libs. > > > > This leads to the conclusion that partially this will be a case by case > > job. For cross-compiling gcc(chain) rpms we can make guidelines, but I > > do not believe that we should force packages for other cross-compilers > > to follow these guidelines. On the contrary, I believe we should stay as > > close to upstream as possible, to minimize the element of surprise for > > end users. > > > > This is why I plea for a cross-compiler SIG, so far I know of the > > following people being interested: > > > > Hans de Goede (avr-gcc, arm-linux-gp2x-gcc) > > Kevin Kofler (tigcc) > > Ralf Corsepius (rtems) .. freebsd, cygwin, mingw ... > > Trond Danielsen (sdcc, avr-gcc, avr32-gcc, Analog Devices Blackfin) > > > > So assuming all named people are reading this, who's in? I'am in myself > > ofcourse and (see below) I believe Trond is in too. > > Confirmed. Count me in. > > > > > Then within this SIG we can try to create general cross compiling > > guidelines and where this makes sense because there is a whole family > > with a common pattern, per compiler-family guidelines. The document > > which I posted earlier: > > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00329.html > > > > Is in me eyes a reasonable start for guidelines for the gcc-family of > > cross compilers. > > > > I think this is a very good starting point for a complete set of guide > lines. What remains is to create a wiki page, so that we can start > > > > The spec file for sdcc is almost complete, but I wanted to clarify > > > some of the questions I had regarding "best practice" with regards to > > > cross compilers. > > > > > > > As said I've taken a quick peek and I like it, what questions do you have? > > > > The main issue is the install path. avr-gcc installs everything into > $prefix/avr, which I think is a good solution. Somebody commented in > bugzilla This person was me ;) > that some of the names of the binaries from sdcc where to > generic, and I therefore moved the binaries to /usr/libexec/sdcc, and > created symlinks to /usr/bin. But I wonder if this is a good > solution...? Do you see any problem with it? I don't. To the contrary, you automatically get $bindir/- as surplus, which is what the GNU toolchain applies and which is what modern autotools automatically support for cross-toolchains. > > > I would very much like to contribute to make this happend. I have both > > > a personal and professional interest in seeing as many tools for > > > embedded system development available in the Fedora repositories. > > > There are a number of tools that are missing, that would make Fedora a > > > more attractive target for engineers. A quick summary: > > > > > > - Tools for Atmels AVR and AVR32 processors. Both are supported by > > > free software tools. > > > - Tools for Analog Devices Blackfin. This DSP runs uclinux, and > > > compilers and other related tools are available. Toolchains for both targets also are available for RTEMS (avr-rtems*, bfin-rtems). > > > Once the guidelines are completed, I will get down to packing up as > > > many of these as possible. > > > > > > > Welcome aboard, notice that I've got a couple of last-year CS students > > working on packaging avr-gcc, so please contact me before things get > > done twice. Do me a favor, don't name cross tools "cpu", use a more specific name, such as avr-elf. "avr" is too unspecific to specify a particular toolchain, which, gnerally speaking, will always consists of more than just a "target" compiler. Ralf From rc040203 at freenet.de Sat Feb 24 18:24:37 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Feb 2007 19:24:37 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45E02427.705@hhs.nl> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <45DF5DF7.5040302@redhat.com> <45DF6011.9050208@redhat.com> <45E02427.705@hhs.nl> Message-ID: <1172341477.23237.533.camel@mccallum.corsepiu.local> On Sat, 2007-02-24 at 12:40 +0100, Hans de Goede wrote: > > Warren Togami wrote: > > Warren Togami wrote: > >> > >> BuildRequires: auto-grab-source > >> > >> %prep > >> %setup -q > >> GRAB_SOURCENAME=glibc-2.5-fedora-20061008T1257.tar.bz2 > >> GRAB_HASH=6aa114e3cde495c267ff8a6e55b90bec > >> GRAB_NAME=glibc > >> auto-grab-source $GRAB_NAME $GRAB_SOURCENAME $GRAB_HASH > > > > It could be even simpler than this. > > > > BuildRequires: auto-grab-source > > Source#: sources > > > > %prep > > auto-grab-source glibc > > auto-grab-source gcc > > auto-grab-source binutils > > # auto-grab-source reads the sources file for filenames and hashes > > # needs %%{name} parameter because that isn't specified in sources > > %setup -q > > > > I kinda like this, except that I think auto-grab-source might just as > well be an rpm macro, currently its too small IMHO to be in its own package. > > That still leaves the question is this too evil for the many MB's it > will safe? Given the "look-aside cache" is clever, this doesn't safe many bytes on the build server. For the GNU toolchain's it's arguable, if this approach is applicable at all due to the restrictions of the GPL. It mandates you to make the sources corresponding the binaries you are shipping to be available. I know of at least one concrete case, RMS in person had been enforcing this, actively. Ralf From j.w.r.degoede at hhs.nl Sat Feb 24 19:05:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 Feb 2007 20:05:36 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <1172341477.23237.533.camel@mccallum.corsepiu.local> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <45DF5DF7.5040302@redhat.com> <45DF6011.9050208@redhat.com> <45E02427.705@hhs.nl> <1172341477.23237.533.camel@mccallum.corsepiu.local> Message-ID: <45E08C80.7050202@hhs.nl> Ralf Corsepius wrote: > On Sat, 2007-02-24 at 12:40 +0100, Hans de Goede wrote: >> Warren Togami wrote: >>> Warren Togami wrote: >>>> BuildRequires: auto-grab-source >>>> >>>> %prep >>>> %setup -q >>>> GRAB_SOURCENAME=glibc-2.5-fedora-20061008T1257.tar.bz2 >>>> GRAB_HASH=6aa114e3cde495c267ff8a6e55b90bec >>>> GRAB_NAME=glibc >>>> auto-grab-source $GRAB_NAME $GRAB_SOURCENAME $GRAB_HASH >>> It could be even simpler than this. >>> >>> BuildRequires: auto-grab-source >>> Source#: sources >>> >>> %prep >>> auto-grab-source glibc >>> auto-grab-source gcc >>> auto-grab-source binutils >>> # auto-grab-source reads the sources file for filenames and hashes >>> # needs %%{name} parameter because that isn't specified in sources >>> %setup -q >>> >> I kinda like this, except that I think auto-grab-source might just as >> well be an rpm macro, currently its too small IMHO to be in its own package. >> >> That still leaves the question is this too evil for the many MB's it >> will safe? > Given the "look-aside cache" is clever, this doesn't safe many bytes on > the build server. > > For the GNU toolchain's it's arguable, if this approach is applicable at > all due to the restrictions of the GPL. It mandates you to make the > sources corresponding the binaries you are shipping to be available. > And we are, in the srpms of the native binutils / gcc / whatever. The idea is to only do this for cases where we can use the same version as the native tools, otherwise we would just use a plain srpm, for the reasons given by you about the GPL and other reasons too. Regards, Hans From j.w.r.degoede at hhs.nl Sat Feb 24 19:09:35 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 Feb 2007 20:09:35 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <1172341130.23237.526.camel@mccallum.corsepiu.local> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> <45E02323.2080200@hhs.nl> <409676c70702240618w44a8cb0tc6f3dab048a9322d@mail.gmail.com> <1172341130.23237.526.camel@mccallum.corsepiu.local> Message-ID: <45E08D6F.8090409@hhs.nl> Ralf Corsepius wrote: >>> This is why I plea for a cross-compiler SIG, so far I know of the >>> following people being interested: >>> >>> Hans de Goede (avr-gcc, arm-linux-gp2x-gcc) >>> Kevin Kofler (tigcc) >>> Ralf Corsepius (rtems) > .. freebsd, cygwin, mingw ... > So does this mean we can count you in? (I think we can, but you never explicitly said yes). >> that some of the names of the binaries from sdcc where to >> generic, and I therefore moved the binaries to /usr/libexec/sdcc, and >> created symlinks to /usr/bin. But I wonder if this is a good >> solution...? > Do you see any problem with it? I don't. > > To the contrary, you automatically get $bindir/- as > surplus, which is what the GNU toolchain applies and which is what > modern autotools automatically support for cross-toolchains. > +1 >>> Welcome aboard, notice that I've got a couple of last-year CS students >>> working on packaging avr-gcc, so please contact me before things get >>> done twice. > > Do me a favor, don't name cross tools "cpu", use a more specific name, > such as avr-elf. "avr" is too unspecific to specify a particular > toolchain, which, gnerally speaking, will always consists of more than > just a "target" compiler. > The avr is a 8 bit OS less mcu, the avr-gcc chain generates code to run directly on the bare hardware. There is no "executuble" format, no OS, no nothing. Also notice that every makefile for AVR software under the sun (that I know of) refers to avr-gcc as avr-gcc and nothing else. Thus for exact the same reasons why we want /usr//{bin,lib,include} and not seperate dirs under bin lib include, we want avr-gcc to be just plain avr-gcc. The only alternative I can come up with would be avr-nothing-gcc or avr-NA-gcc, which both are bogus. Regards, Hans From wolters.liste at gmx.net Sun Feb 25 02:18:09 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Sun, 25 Feb 2007 03:18:09 +0100 Subject: "make tag" in new branches? Message-ID: <200702250318.15319.wolters.liste@gmx.net> Hi, after my speedcrunch review I was now able to checkout the speedcrunch module and upload the srpm as described in step 10 in /wiki/Extras/NewPackageProcess. The build went as usual. After that I wanted to create packages for the other branches as well. The mentioned howto says in step 11 that I have to copy the 'sources' file, the *.spec file and all patches (one *.destkop file in that case) to the branch directory. The .spec file and the patches are supposed to be "cvs add"ed, and cvs commit does the rest. However, when you follow that rules you can't tag or build a branch because there is no Makefile. I tried to simply copy the Makefile but then the build log gives me "Error: could not make srpm for speedcrunch-0_7-0_4_beta2_fc5 - output was: make: *** No rule to make target `srpm'. Stop." What do I have to do now? Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Sun Feb 25 06:19:07 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 25 Feb 2007 07:19:07 +0100 Subject: "make tag" in new branches? In-Reply-To: <200702250318.15319.wolters.liste@gmx.net> References: <200702250318.15319.wolters.liste@gmx.net> Message-ID: <45E12A5B.9090705@hhs.nl> Roland Wolters wrote: > Hi, > > after my speedcrunch review I was now able to checkout the speedcrunch module > and upload the srpm as described in step 10 > in /wiki/Extras/NewPackageProcess. > The build went as usual. After that I wanted to create packages for the other > branches as well. The mentioned howto says in step 11 that I have to copy > the 'sources' file, the *.spec file and all patches (one *.destkop file in > that case) to the branch directory. The .spec file and the patches are > supposed to be "cvs add"ed, and cvs commit does the rest. > > However, when you follow that rules you can't tag or build a branch because > there is no Makefile. I tried to simply copy the Makefile but then the build > log gives me > "Error: could not make srpm for speedcrunch-0_7-0_4_beta2_fc5 - output was: > make: *** No rule to make target `srpm'. Stop." > > What do I have to do now? > > Roland > Strange, it looks like the CVs-admin made some kinda error as normally the Makefile is there. I think you now need to cvs add, commit and tag the makefile regards, Hans From rc040203 at freenet.de Sun Feb 25 06:01:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 25 Feb 2007 07:01:57 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45E08D6F.8090409@hhs.nl> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> <45E02323.2080200@hhs.nl> <409676c70702240618w44a8cb0tc6f3dab048a9322d@mail.gmail.com> <1172341130.23237.526.camel@mccallum.corsepiu.local> <45E08D6F.8090409@hhs.nl> Message-ID: <1172383317.23237.551.camel@mccallum.corsepiu.local> On Sat, 2007-02-24 at 20:09 +0100, Hans de Goede wrote: > > Ralf Corsepius wrote: > >>> This is why I plea for a cross-compiler SIG, so far I know of the > >>> following people being interested: > >>> > >>> Hans de Goede (avr-gcc, arm-linux-gp2x-gcc) > >>> Kevin Kofler (tigcc) > >>> Ralf Corsepius (rtems) > > .. freebsd, cygwin, mingw ... > > > > So does this mean we can count you in? (I think we can, but you never > explicitly said yes). For the moment, yes. But given the feedback, toolchains I had submitted for FE more than a year ago had received, my expectations hardly could be lower. > >>> Welcome aboard, notice that I've got a couple of last-year CS students > >>> working on packaging avr-gcc, so please contact me before things get > >>> done twice. > > > > Do me a favor, don't name cross tools "cpu", use a more specific name, > > such as avr-elf. "avr" is too unspecific to specify a particular > > toolchain, which, gnerally speaking, will always consists of more than > > just a "target" compiler. > > > > The avr is a 8 bit OS less mcu, the avr-gcc chain generates code to run > directly on the bare hardware. There is no "executuble" format, elf > no OS, avr-libc > no nothing. elf/avr-libc alone cause this toolchain to contain hardcoded characteristics, which make it unusable for other avr-targets environments (e.g. avr-rtems uses newlib instead of avr-libc). > Also notice that every makefile for AVR software under the > sun (that I know of) refers to avr-gcc as avr-gcc and nothing else. Sorry, to me these packages are simply bugged. > Thus for exact the same reasons why we want > /usr//{bin,lib,include} and not seperate dirs under bin > lib include, we want avr-gcc to be just plain avr-gcc. This is a common fault, "bare" target toolchain implementors tend to commit. They think a "cpu" is sufficient to describe a target-toolchains characteristic. They miss that "cpu" alone means nothing and will break when something changes, e.g. the object format, or the libc they are using. E.g. "i386" means nothing, a i386-pc-coff toolchains is something completely different than a today's i386-pc-linux toolchain (currently implies i386/glibc2/elf.), a i386-cygwin toolchain, a i386-mingw toolchain, i386-rtems or a "bare/freestanding i386" toolchain. Ralf From ville.skytta at iki.fi Sun Feb 25 11:12:05 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 25 Feb 2007 13:12:05 +0200 Subject: EPEL owners (was: Re: owners owners.epel.list,1.42,1.43) In-Reply-To: <200702242324.l1ONOB31008670@cvs-int.fedora.redhat.com> References: <200702242324.l1ONOB31008670@cvs-int.fedora.redhat.com> Message-ID: <200702251312.05640.ville.skytta@iki.fi> On Sunday 25 February 2007, Dennis Gilmore wrote: > Author: ausil > > Update of /cvs/extras/owners > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8651 > > Modified Files: > owners.epel.list > Log Message: > add missing items from EPEL list Looks like this was done without asking the respective package owners whether they're interested in maintaining those packages in EPEL. I know I wasn't asked, yet rpmlint and rpmdevtools were imported by someone else but assigned to me. Please don't do that - in worst cases that may mean the packages are effectively unmaintained as the reports go to people who have no plans to do anything about them. There were also some "branched for infrastructure" commits lately; were the newly added EPEL owners asked in those cases? As a side note, I most likely will be interested in maintaining some EPEL5 packages later, but probably not EPEL4. From fedora at leemhuis.info Sun Feb 25 11:36:08 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 25 Feb 2007 12:36:08 +0100 Subject: EPEL owners In-Reply-To: <200702251312.05640.ville.skytta@iki.fi> References: <200702242324.l1ONOB31008670@cvs-int.fedora.redhat.com> <200702251312.05640.ville.skytta@iki.fi> Message-ID: <45E174A8.8060709@leemhuis.info> Ville Skytt? schrieb: > On Sunday 25 February 2007, Dennis Gilmore wrote: >> Author: ausil >> Update of /cvs/extras/owners >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8651 >> >> Modified Files: >> owners.epel.list >> Log Message: >> add missing items from EPEL list > Looks like this was done without asking the respective package owners whether > they're interested in maintaining those packages in EPEL. I know I wasn't > asked, yet rpmlint and rpmdevtools were imported by someone else but assigned > to me. [...] I suppose this was an error, and I suppose this error is limited to those two packages. Those two are quite crucial to because most of us use them to (test-) build package builds on EL. So those were in the first bunch of test-packages that got build in the testing phase. All the other packages should afaik have been build only when the Fedora maintainer asked for a EPEL branch. I'm willing to take the two if you don't want them and if that's okay for you. CU thl From ville.skytta at iki.fi Sun Feb 25 12:16:01 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 25 Feb 2007 14:16:01 +0200 Subject: EPEL owners In-Reply-To: <45E174A8.8060709@leemhuis.info> References: <200702242324.l1ONOB31008670@cvs-int.fedora.redhat.com> <200702251312.05640.ville.skytta@iki.fi> <45E174A8.8060709@leemhuis.info> Message-ID: <200702251416.01251.ville.skytta@iki.fi> On Sunday 25 February 2007, Thorsten Leemhuis wrote: > Ville Skytt? schrieb: > > On Sunday 25 February 2007, Dennis Gilmore wrote: > > > > Looks like this was done without asking the respective package owners > > whether they're interested in maintaining those packages in EPEL. I know > > I wasn't asked, yet rpmlint and rpmdevtools were imported by someone else > > but assigned to me. [...] > > I suppose this was an error, and I suppose this error is limited to > those two packages. Those two are quite crucial to because most of us > use them to (test-) build package builds on EL. So those were in the > first bunch of test-packages that got build in the testing phase. All > the other packages should afaik have been build only when the Fedora > maintainer asked for a EPEL branch. > > I'm willing to take the two if you don't want them and if that's okay > for you. Thanks, go ahead, and feel free to include me in initial Cc list; as said I may be interested in chiming in more actively later. And see also https://bugzilla.redhat.com/229975 https://bugzilla.redhat.com/229976 https://bugzilla.redhat.com/227284 From wolters.liste at gmx.net Sun Feb 25 15:04:58 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Sun, 25 Feb 2007 16:04:58 +0100 Subject: "make tag" in new branches? In-Reply-To: <45E12A5B.9090705@hhs.nl> References: <200702250318.15319.wolters.liste@gmx.net> <45E12A5B.9090705@hhs.nl> Message-ID: <200702251605.04272.wolters.liste@gmx.net> Once upon a time Hans de Goede wrote: > Roland Wolters wrote: > > However, when you follow that rules you can't tag or build a branch > > because there is no Makefile. I tried to simply copy the Makefile but > > then the build log gives me > > "Error: could not make srpm for speedcrunch-0_7-0_4_beta2_fc5 - output > > was: make: *** No rule to make target `srpm'. Stop." > > > > Strange, it looks like the CVs-admin made some kinda error as normally > the Makefile is there. I think you now need to cvs add, commit and tag > the makefile > Worked, thanks. Was this a single error only with my package, or should I add something to the web page? Roland -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wolters.liste at gmx.net Sun Feb 25 15:15:56 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Sun, 25 Feb 2007 16:15:56 +0100 Subject: "make tag" in new branches? In-Reply-To: <200702251605.04272.wolters.liste@gmx.net> References: <200702250318.15319.wolters.liste@gmx.net> <45E12A5B.9090705@hhs.nl> <200702251605.04272.wolters.liste@gmx.net> Message-ID: <200702251616.41723.wolters.liste@gmx.net> Once upon a time Roland Wolters wrote: > Once upon a time Hans de Goede wrote: > > Roland Wolters wrote: > > > However, when you follow that rules you can't tag or build a branch > > > because there is no Makefile. I tried to simply copy the Makefile but > > > then the build log gives me > > > "Error: could not make srpm for speedcrunch-0_7-0_4_beta2_fc5 - output > > > was: make: *** No rule to make target `srpm'. Stop." > > > > Strange, it looks like the CVs-admin made some kinda error as normally > > the Makefile is there. I think you now need to cvs add, commit and tag > > the makefile > > Worked, thanks. Was this a single error only with my package, or should I > add something to the web page? > Argh, I was to quick - it didn't work out: Error: could not make srpm for speedcrunch-0_7-0_5_beta2_fc5 - output was: rpmbuild --define "_sourcedir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "_builddir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "_srcrpmdir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "_rpmdir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "dist .fc5" --define "fedora 5" --define "dist .fc5" --define "fedora 5" --nodeps -bs speedcrunch.spec error: File /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5/speedcrunch-0.7-beta2.tar.gz: No such file or directory make: *** [srpm] Error 1 What should I do now? And am I really the only one having such problems? Roland -- Thank you for not discussing the outside world. -- Simpsons -------------- 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 Sun Feb 25 15:22:44 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 25 Feb 2007 16:22:44 +0100 Subject: "make tag" in new branches? In-Reply-To: <200702251616.41723.wolters.liste@gmx.net> References: <200702250318.15319.wolters.liste@gmx.net> <45E12A5B.9090705@hhs.nl> <200702251605.04272.wolters.liste@gmx.net> <200702251616.41723.wolters.liste@gmx.net> Message-ID: <20070225162244.f355cd4b.bugs.michael@gmx.net> On Sun, 25 Feb 2007 16:15:56 +0100, Roland Wolters wrote: > Argh, I was to quick - it didn't work out: > Error: could not make srpm for speedcrunch-0_7-0_5_beta2_fc5 - output was: > rpmbuild --define "_sourcedir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "_builddir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "_srcrpmdir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "_rpmdir /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5" --define "dist .fc5" --define "fedora > 5" --define "dist .fc5" --define "fedora 5" --nodeps -bs speedcrunch.spec > error: > File /tmp/28234-speedcrunch-0_7-0_5_beta2_fc5-1172416243/speedcrunch/FC-5/speedcrunch-0.7-beta2.tar.gz: > No such file or directory > make: *** [srpm] Error 1 > > What should I do now? And am I really the only one having such problems? In a fresh "cvs co speedcrunch && cd speedcrunch/FC-5" there is no "sources" files. Add and commit it. Also applies to FC-6 branch. From dennis at ausil.us Sun Feb 25 15:39:43 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 25 Feb 2007 09:39:43 -0600 Subject: EPEL owners In-Reply-To: <45E174A8.8060709@leemhuis.info> References: <200702242324.l1ONOB31008670@cvs-int.fedora.redhat.com> <200702251312.05640.ville.skytta@iki.fi> <45E174A8.8060709@leemhuis.info> Message-ID: <200702250939.48819.dennis@ausil.us> Once upon a time Sunday 25 February 2007, Thorsten Leemhuis wrote: > Ville Skytt? schrieb: > > On Sunday 25 February 2007, Dennis Gilmore wrote: > >> Author: ausil > >> Update of /cvs/extras/owners > >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8651 > >> > >> Modified Files: > >> owners.epel.list > >> Log Message: > >> add missing items from EPEL list > > > > Looks like this was done without asking the respective package owners > > whether they're interested in maintaining those packages in EPEL. I know > > I wasn't asked, yet rpmlint and rpmdevtools were imported by someone else > > but assigned to me. [...] > > I suppose this was an error, and I suppose this error is limited to > those two packages. Those two are quite crucial to because most of us > use them to (test-) build package builds on EL. So those were in the > first bunch of test-packages that got build in the testing phase. All > the other packages should afaik have been build only when the Fedora > maintainer asked for a EPEL branch. > > I'm willing to take the two if you don't want them and if that's okay > for you. I'm also willing to help, rpmdevtools is used in every single EPEL build root the same as for Fedora. there was alot of things branched with no entry in owners.epel.list so i sripted inserting them from owners.list. Im sorry that it happened this way. There should be nothing else thats been branched like this. Dennis -------------- 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 Sun Feb 25 16:40:28 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 25 Feb 2007 17:40:28 +0100 Subject: rpms/Democracy/FC-6 Democracy.spec,1.3,1.4 In-Reply-To: <200702241727.l1OHRISa010608@cvs-int.fedora.redhat.com> References: <200702241727.l1OHRISa010608@cvs-int.fedora.redhat.com> Message-ID: <20070225174028.fff2a200.bugs.michael@gmx.net> On Sat, 24 Feb 2007 12:27:18 -0500, Thorsten Scherf (tscherf) wrote: > Author: tscherf > > Update of /cvs/extras/rpms/Democracy/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10590 > > Modified Files: > Democracy.spec > Log Message: > changed typo > > > Index: Democracy.spec > =================================================================== > RCS file: /cvs/extras/rpms/Democracy/FC-6/Democracy.spec,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- Democracy.spec 24 Feb 2007 10:32:45 -0000 1.3 > +++ Democracy.spec 24 Feb 2007 17:26:45 -0000 1.4 > @@ -14,7 +14,7 @@ > BuildRequires: boost-devel qt-devel pygtk2-devel libXcursor-devel > BuildRequires: firefox-devel gettext libXfixes-devel gtk2-devel > Requires: firefox xine-lib gnome-python2-gtkmozembed > -Requires: gnome-python2-gconf dbus-pythoni > +Requires: gnome-python2-gconf dbus-python > > %description > Democracy player is a free application that turns your computer into an Please do increase "Release" and also create a new build-tag with "make tag" before submitting a build job for the fixed package. Your resubmission of Democracy-0_9_5_1-3_fc6 does not include the fix, because it's the old tag on the old files. From buildsys at fedoraproject.org Sun Feb 25 16:45:58 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 25 Feb 2007 16:45:58 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-02-25 Message-ID: <20070225164558.27948.75767@extras64.linux.duke.edu> New report for: tscherf AT redhat.com package: Democracy - 0.9.5.1-3.fc7.i386 from fedora-extras-needsign-development-i386 unresolved deps: dbus-pythoni package: Democracy - 0.9.5.1-3.fc7.ppc from fedora-extras-needsign-development-ppc unresolved deps: dbus-pythoni package: Democracy - 0.9.5.1-3.fc7.x86_64 from fedora-extras-needsign-development-x86_64 unresolved deps: dbus-pythoni ====================================================================== New report for: ville.skytta AT iki.fi package: em8300 - 0.16.1-0.1.rc2.fc7.i386 from fedora-extras-needsign-development-i386 unresolved deps: em8300-kmod >= 0:0.16.1 package: em8300 - 0.16.1-0.1.rc2.fc7.ppc from fedora-extras-needsign-development-ppc unresolved deps: em8300-kmod >= 0:0.16.1 package: em8300 - 0.16.1-0.1.rc2.fc7.x86_64 from fedora-extras-needsign-development-x86_64 unresolved deps: em8300-kmod >= 0:0.16.1 ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (16 days) libetpan - 0.49-1.fc7.i386 (16 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (16 days) cgoorah AT yahoo.com.au irsim - 9.7.41-5.fc7.i386 (11 days) irsim - 9.7.41-5.fc7.ppc (11 days) xcircuit - 3.4.26-18.fc7.i386 (11 days) xcircuit - 3.4.26-18.fc7.ppc (11 days) xcircuit - 3.4.26-18.fc7.x86_64 (11 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (79 days) csound - 5.03.0-9.fc7.i386 (79 days) csound - 5.03.0-9.fc7.ppc (79 days) csound - 5.03.0-9.fc7.x86_64 (79 days) csound-python - 5.03.0-9.fc7.i386 (79 days) csound-python - 5.03.0-9.fc7.ppc (79 days) csound-python - 5.03.0-9.fc7.x86_64 (79 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (81 days) endur AT bennewitz.com streamtuner - 0.99.99-15.fc7.x86_64 (79 days) enrico.scholz AT informatik.tu-chemnitz.de tor-core - 0.1.1.26-2.fc7.i386 (3 days) tor-core - 0.1.1.26-2.fc7.ppc (3 days) tor-core - 0.1.1.26-2.fc7.x86_64 (3 days) foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (10 days) flac123 - 0.0.9-1.fc7.ppc (10 days) flac123 - 0.0.9-1.fc7.x86_64 (10 days) muine - 0.8.7-1.fc7.i386 (10 days) muine - 0.8.7-1.fc7.i386 (10 days) muine - 0.8.7-1.fc7.ppc (10 days) muine - 0.8.7-1.fc7.x86_64 (10 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i586 (3 days) kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i686 (3 days) kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 (3 days) kmod-sysprof-PAE - 1.0.8-1.2.6.20_1.2932.fc7.i686 (3 days) kmod-sysprof-kdump - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 (3 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (76 days) libreadline-java - 0.8.0-13.fc6.i386 (76 days) libreadline-java - 0.8.0-13.fc6.ppc (76 days) libreadline-java - 0.8.0-13.fc6.x86_64 (76 days) jima AT beer.tclug.org scanssh - 2.1-10.fc7.i386 (3 days) scanssh - 2.1-10.fc7.ppc (3 days) scanssh - 2.1-10.fc7.x86_64 (3 days) oliver AT linux-kernel.at syck-php - 0.55-13.fc7.i386 (8 days) syck-php - 0.55-13.fc7.ppc (8 days) syck-php - 0.55-13.fc7.x86_64 (8 days) orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (79 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (79 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (8 days) k3b-extras - 0.12.17-1.fc6.ppc (8 days) k3b-extras - 0.12.17-1.fc6.x86_64 (8 days) shahms AT shahms.com python-psyco - 1.5.1-4.fc6.i386 (79 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 (11 days) xpa - 2.1.6-8.fc7.i386 (11 days) xpa - 2.1.6-8.fc7.ppc (11 days) xpa - 2.1.6-8.fc7.x86_64 (11 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (79 days) xmldiff - 0.6.7-12.fc6.ppc (79 days) xmldiff - 0.6.7-12.fc6.x86_64 (79 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 (11 days) R - 2.4.1-2.fc7.i386 (11 days) R - 2.4.1-2.fc7.ppc (11 days) R - 2.4.1-2.fc7.x86_64 (11 days) tscherf AT redhat.com Democracy - 0.9.5.1-3.fc7.i386 Democracy - 0.9.5.1-3.fc7.ppc Democracy - 0.9.5.1-3.fc7.x86_64 ville.skytta AT iki.fi em8300 - 0.16.1-0.1.rc2.fc7.i386 em8300 - 0.16.1-0.1.rc2.fc7.ppc em8300 - 0.16.1-0.1.rc2.fc7.x86_64 kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 (11 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 (11 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc (11 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (11 days) kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 (11 days) kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (11 days) kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc (11 days) ====================================================================== Broken packages in fedora-extras-development-i386: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 irsim-9.7.41-5.fc7.i386 requires libtk8.5.so irsim-9.7.41-5.fc7.i386 requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2932.fc7 kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 python-psyco-1.5.1-4.fc6.i386 requires python-abi = 0:2.4 python-psyco-1.5.1-4.fc6.i386 requires python(abi) = 0:2.4 scanssh-2.1-10.fc7.i386 requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.i386 requires php = 0:5.2.0 tor-core-0.1.1.26-2.fc7.i386 requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.i386 requires libtk8.5.so xcircuit-3.4.26-18.fc7.i386 requires libtcl8.5.so xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-ppc: R-2.4.1-2.fc7.ppc requires libtk8.5.so R-2.4.1-2.fc7.ppc requires libtcl8.5.so csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 irsim-9.7.41-5.fc7.ppc requires libtk8.5.so irsim-9.7.41-5.fc7.ppc requires libtcl8.5.so k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 muine-0.8.7-1.fc7.ppc requires libFLAC.so.7 scanssh-2.1-10.fc7.ppc requires libevent-1.1a.so.1 syck-php-0.55-13.fc7.ppc requires php = 0:5.2.0 tor-core-0.1.1.26-2.fc7.ppc requires libevent-1.1a.so.1 xcircuit-3.4.26-18.fc7.ppc requires libtk8.5.so xcircuit-3.4.26-18.fc7.ppc requires libtcl8.5.so xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.ppc requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-development-x86_64: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so R-2.4.1-2.fc7.x86_64 requires libtcl8.5.so()(64bit) R-2.4.1-2.fc7.x86_64 requires libtk8.5.so()(64bit) claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 muine-0.8.7-1.fc7.x86_64 requires libFLAC.so.7()(64bit) openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) scanssh-2.1-10.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) streamtuner-0.99.99-15.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) syck-php-0.55-13.fc7.x86_64 requires php = 0:5.2.0 tor-core-0.1.1.26-2.fc7.x86_64 requires libevent-1.1a.so.1()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtk8.5.so()(64bit) xcircuit-3.4.26-18.fc7.x86_64 requires libtcl8.5.so()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so xpa-2.1.6-8.fc7.x86_64 requires libtcl8.5.so()(64bit) ====================================================================== Broken packages in fedora-extras-needsign-development-i386: Democracy-0.9.5.1-3.fc7.i386 requires dbus-pythoni em8300-0.16.1-0.1.rc2.fc7.i386 requires em8300-kmod >= 0:0.16.1 ====================================================================== Broken packages in fedora-extras-needsign-development-ppc: Democracy-0.9.5.1-3.fc7.ppc requires dbus-pythoni em8300-0.16.1-0.1.rc2.fc7.ppc requires em8300-kmod >= 0:0.16.1 ====================================================================== Broken packages in fedora-extras-needsign-development-x86_64: Democracy-0.9.5.1-3.fc7.x86_64 requires dbus-pythoni em8300-0.16.1-0.1.rc2.fc7.x86_64 requires em8300-kmod >= 0:0.16.1 From wolters.liste at gmx.net Sun Feb 25 17:11:57 2007 From: wolters.liste at gmx.net (Roland Wolters) Date: Sun, 25 Feb 2007 18:11:57 +0100 Subject: "make tag" in new branches? In-Reply-To: <20070225162244.f355cd4b.bugs.michael@gmx.net> References: <200702250318.15319.wolters.liste@gmx.net> <200702251616.41723.wolters.liste@gmx.net> <20070225162244.f355cd4b.bugs.michael@gmx.net> Message-ID: <200702251812.03943.wolters.liste@gmx.net> Once upon a time Michael Schwendt wrote: > On Sun, 25 Feb 2007 16:15:56 +0100, Roland Wolters wrote: > > What should I do now? And am I really the only one having such problems? > > In a fresh "cvs co speedcrunch && cd speedcrunch/FC-5" there is no > "sources" files. Add and commit it. Also applies to FC-6 branch. Thanks for the answer, builds now. However, the howto explicitly said to only cvs-add and commit the *.spec file and the patches. Looks to me that the howto is more in a draft state, at least in this regard... Roland -- Every revolution begins as an idea in someone's mind. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Sun Feb 25 19:28:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 25 Feb 2007 19:28:18 +0000 (UTC) Subject: sdcc - Cross Compiler, Needs Packaging Standards? References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> <45E02323.2080200@hhs.nl> <409676c70702240618w44a8cb0tc6f3dab048a9322d@mail.gmail.com> <1172341130.23237.526.camel@mccallum.corsepiu.local> <45E08D6F.8090409@hhs.nl> <1172383317.23237.551.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > > Also notice that every makefile for AVR software under the > > sun (that I know of) refers to avr-gcc as avr-gcc and nothing else. > Sorry, to me these packages are simply bugged. IMHO, this discussion should be taken up with upstream avr-gcc, it's not the distributor's job to rename the cross compiler to a name of their liking, breaking all the makefiles made for the unmodified upstream cross-toolchain. Kevin Kofler From trond.danielsen at gmail.com Sun Feb 25 20:38:25 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Sun, 25 Feb 2007 21:38:25 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <409676c70702231231j6f141ba2l87c60c1979215254@mail.gmail.com> <45E02323.2080200@hhs.nl> <409676c70702240618w44a8cb0tc6f3dab048a9322d@mail.gmail.com> <1172341130.23237.526.camel@mccallum.corsepiu.local> <45E08D6F.8090409@hhs.nl> <1172383317.23237.551.camel@mccallum.corsepiu.local> Message-ID: <409676c70702251238l1f0141cal2c730455eac0fdf7@mail.gmail.com> 2007/2/25, Kevin Kofler : > Ralf Corsepius writes: > > > Also notice that every makefile for AVR software under the > > > sun (that I know of) refers to avr-gcc as avr-gcc and nothing else. > > Sorry, to me these packages are simply bugged. > > IMHO, this discussion should be taken up with upstream avr-gcc, it's not the > distributor's job to rename the cross compiler to a name of their liking, > breaking all the makefiles made for the unmodified upstream cross-toolchain. > I agree on this one, and it also complies with the inital guidelines proposed by Hans de Goede on not to derive too much from upstream. -- Trond Danielsen From paul at xelerance.com Sun Feb 25 20:59:12 2007 From: paul at xelerance.com (Paul Wouters) Date: Sun, 25 Feb 2007 21:59:12 +0100 (CET) Subject: libgcrypt's global variable issues - statically linking it in application or not? Message-ID: Hi, There is a serious (long lived) bug in libgcrypt that can cause any program to fail when two clients within the same program (eg plugins) are trying to use libgcrypt. This is because it uses global variables that the two clients both need to use in the same address space in (potentially) different ways. Gaim-otr is suffering from this, because it uses libgcrypt. If another module in gaim uses libgcrypt, for example when LDAP is enabled and a TLS connection is initiated through another plugin, or when using another encryption plugin within gaim that uses libgcrypt directly, or indirectly via another package or plugin using gnutls which uses libgcrypt, this bug pops up. For various discussions of this bug, see: http://lists.gnupg.org/pipermail/gcrypt-devel/2006-January/000889.html http://www.mail-archive.com/debian-bugs-dist at lists.debian.org/msg304755.html Having said this, I do not think Fedora's ldap packages depend on libgcrypt, so enabling any kind of DNS functionality through ldap, as the original Debian bug experiences, should not cause any problems on Fedora (AFAIK!). I also see no gaim plugin packages in core or extras apart from gaim-otr that uses libgcrypt, so from a practical point of view, we have no issues *yet*. I personally have never been bitten by this bug in all my years of using gaim-otr on Fedora. The real question is, what should be done? A staticly linked libgcrypt protecting those users who install non-fedora packaged software that might trigger this bug, or postpone this issue until we actually see the libgcrypt problem in fedora packaged software (while hoping the libgcrypt people fix their global variable usage before we're bitten)? If it was decided to statically link libgcrypt into gaim-otr, I would want to use a Requires: that only points to the latest version of libgcrypt, so that a rebuild of gaim-otr is forced when a new version of libgcrypt is packaged. I would like to hear what others are thinking about this issue. Paul From ml at deadbabylon.de Sun Feb 25 22:36:51 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 25 Feb 2007 23:36:51 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <1CE6B0FC-9095-4BEF-916C-70DEE07139CA@deds.nl> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> <20070222153232.226706de@localhost.localdomain> <6E49FA91-4FC8-4A12-BE27-4A86C1027FE9@deds.nl> <45E024BF.3020606@hhs.nl> <1CE6B0FC-9095-4BEF-916C-70DEE07139CA@deds.nl> Message-ID: <20070225233651.364f9d96@localhost.localdomain> Am Sat, 24 Feb 2007 15:41:49 +0100 schrieb Johan Kok : > > On 24-feb-2007, at 12:42, Hans de Goede wrote: > > Johan Kok wrote: > >> > >> Hm, I haven't heard anything from Hugo since that chat. I suppose > >> he never wrote that mail we talked about. > > > > I say that he truely is AWOL then, so lets orphan his packages. Can > > someone make the list of his packages (again) and post that to the > > list, > > then give people a couple of days to pick up some of his packages. > > guichan > kerry > knemo > metamonitor > netpanzer > netpanzer-data > ode > pengupop > python-ogg > python-vorbis > tuxpuck > xmoto > > > -- > Johan > Also said this in the bug report: I could take kerry. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliver at linux-kernel.at Mon Feb 26 08:37:24 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 26 Feb 2007 09:37:24 +0100 Subject: owners.list Message-ID: <45E29C44.5090701@linux-kernel.at> Can someone with write permissions please change the following: RCS file: /cvs/extras/owners/owners.list,v retrieving revision 1.2380 diff -r1.2380 owners.list 2551c2551 < Fedora Extras|syck|YAML for C, Python, and PHP|oliver at linux-kernel.at|extras-qa at fedoraproject.org| --- > Fedora Extras|syck|YAML for C, Python, and PHP|tibbs at math.uh.edu|extras-qa at fedoraproject.org|oliver at linux-kernel.at Thanks, Oliver From jpo at di.uminho.pt Mon Feb 26 10:39:13 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 26 Feb 2007 10:39:13 +0000 Subject: x86_64 builds are failing due to disk space shortage Message-ID: <45E2B8D1.6070004@di.uminho.pt> Job failed on arch x86_64 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/28283-perl-Cairo-1.023-1.fc7/ ------------------------------------------------- installing package make-3.81-3.fc7 needs 516MB on the / filesystem installing package rpmdevtools-5.3-1.fc6 needs 516MB on the / filesystem installing package net-tools-1.60-78.fc7 needs 517MB on the / filesystem installing package coreutils-6.7-8.fc7 needs 527MB on the / filesystem installing package glibc-headers-2.5.90-17 needs 530MB on the / filesystem ... -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4616 bytes Desc: S/MIME Cryptographic Signature URL: From dennis at ausil.us Mon Feb 26 11:35:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 26 Feb 2007 05:35:00 -0600 Subject: x86_64 builds are failing due to disk space shortage In-Reply-To: <45E2B8D1.6070004@di.uminho.pt> References: <45E2B8D1.6070004@di.uminho.pt> Message-ID: <200702260535.06750.dennis@ausil.us> Once upon a time Monday 26 February 2007, Jose Pedro Oliveira wrote: > Job failed on arch x86_64 > > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-development-extras/28283-perl >-Cairo-1.023-1.fc7/ > > ------------------------------------------------- > > installing package make-3.81-3.fc7 needs 516MB on the / filesystem > installing package rpmdevtools-5.3-1.fc6 needs 516MB on the / filesystem > installing package net-tools-1.60-78.fc7 needs 517MB on the / filesystem > installing package coreutils-6.7-8.fc7 needs 527MB on the / filesystem > installing package glibc-headers-2.5.90-17 needs 530MB on the / > filesystem ... plague does not clean up after a failed build. one of the builder was running short of space i am cleaning it up right now. please requeue your builds. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Mon Feb 26 12:36:33 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 26 Feb 2007 07:36:33 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-26 Message-ID: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 0 Packages built and released for Fedora Extras 6: 29 Democracy-0.9.5.1-4.fc6 abcm2ps-5.3.0-1.fc6 cyphesis-0.5.11-2.fc6 deluge-0.4.90.2-2.fc6 dvdauthor-0.6.14-1.fc6 eclipse-emf-2.2.2-1.fc6 emelfm2-0.3.2-2.fc6 eventlog-0.2.5-4.fc6 global-5.4-1.fc6 gnomesword-2.2.2.1-1.fc6.1 gpodder-0.8.9-1.fc6 perl-Cairo-1.023-1.fc6 perl-Config-General-2.32-1.fc6 perl-Image-Info-1.24-1.fc6 NEW perl-Math-Random-MT-Auto-5.04-3.fc6 python-eyed3-0.6.12-1.fc6 qgit-1.5.5-1.fc6 regexxer-0.9-1.fc6 scipy-0.5.2-1.fc6 NEW speedcrunch-0.7-0.9.beta2.fc6 tclabc-1.0.9-1.fc6 tmda-1.1.11-1.fc6 NEW usbsink-0.3.1-1.fc6 vdr-1.4.5-4.fc6 xarchiver-0.4.9-0.1.20070128svn24772.fc6 xfce4-datetime-plugin-0.5.0-1.fc6 xfce4-genmon-plugin-3.1-1.fc6 xfce4-wavelan-plugin-0.5.4-1.fc6 xfce4-xmms-plugin-0.5.1-1.fc6 Packages built and released for Fedora Extras 5: 9 deluge-0.4.90.2-2.fc5 emelfm2-0.3.2-2.fc5 gnomesword-2.2.2.1-1.fc5 perl-Image-Info-1.24-1.fc5 NEW perl-Math-Random-MT-Auto-5.04-3.fc5 qgit-1.5.5-1.fc5 regexxer-0.9-1.fc5 NEW speedcrunch-0.7-0.9.beta2.fc5 tmda-1.1.11-1.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From david at lovesunix.net Mon Feb 26 13:41:17 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 26 Feb 2007 14:41:17 +0100 Subject: Fedora Extras Package Build Report 2007-02-26 In-Reply-To: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> References: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> Message-ID: <1172497277.17419.28.camel@dawkins> man, 26 02 2007 kl. 07:36 -0500, skrev buildsys at fedoraproject.org: > Packages built and released for Fedora Extras 6: 29 > > deluge-0.4.90.2-2.fc6 But Mr. Gordon.. this is madness, a known unstable beta pushed for FC6. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From tibbs at math.uh.edu Mon Feb 26 14:55:36 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Feb 2007 08:55:36 -0600 Subject: owners.list In-Reply-To: <45E29C44.5090701@linux-kernel.at> References: <45E29C44.5090701@linux-kernel.at> Message-ID: >>>>> "OF" == Oliver Falk writes: >> Fedora Extras|syck|YAML for C, Python, and PHP> tibbs at math.uh.edu|extras-qa at fedoraproject.org|oliver at linux-kernel.at Umm, no. I am not in any way the maintainer of syck, nor have I ever wished to be. The only reason my name appears in the changelog is because I did mass rebuilds of many packages due to core python and PHP updates. Since this package needs rebuilding when either changes, I show up a lot. - J< From oliver at linux-kernel.at Mon Feb 26 15:22:53 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 26 Feb 2007 16:22:53 +0100 Subject: owners.list In-Reply-To: References: <45E29C44.5090701@linux-kernel.at> Message-ID: <45E2FB4D.30605@linux-kernel.at> Am 2007-02-26 15:55, Jason L Tibbitts III schrieb: >>>>>> "OF" == Oliver Falk writes: > >>> Fedora Extras|syck|YAML for C, Python, and > PHP> tibbs at math.uh.edu|extras-qa at fedoraproject.org|oliver at linux-kernel.at > > Umm, no. I am not in any way the maintainer of syck, nor have I ever > wished to be. The only reason my name appears in the changelog is > because I did mass rebuilds of many packages due to core python and > PHP updates. Since this package needs rebuilding when either changes, > I show up a lot. k! Havn't thought about this :-) Maybe jima is the one who should be informed then... Jima? You take syck also? Or Steven? As you maintain the perl part also!? Thanks, Oliver From vonbrand at inf.utfsm.cl Mon Feb 26 16:53:56 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 26 Feb 2007 13:53:56 -0300 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <45DF50BF.5090705@hhs.nl> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> Message-ID: <4806.1172508836@laptop13.inf.utfsm.cl> Hans de Goede wrote: > Warren Togami wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > > > It appears that a few folks want sdcc, but do the packaging standards > > for cross compilers and the concern about names being dropped into > > /usr/bin should be solved first? > > [...] > Since Ralf and I agree for 99.9% on my proposal, this really is > almost done. The only thing which I want discussed in a wider > audience / need more input in is the SRPM issue, quoting from my > original mail: > "The SRPMS for all these packages will most of the time contain the > exact same tarbals as the native binutils / gcc / libs > > Possible solutions: > a) Live with the extra diskspace / bandwidth cost this induces upon > our mirrors > b) *** Warning dirty hack *** > Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep > and if it isn't there bail with a message howto get the tarbal > from the srpms for the native packages. We can use the sources > file and the look-aside cache to make the test for the tarbal > succeed on the buildsys. Advantages: saves tons of diskspace. > Disadvantage: slight inconvienience for people trying to rebuild > the srpm's manually. Large inconvienience for people doing > automated rebuilds (aurora for example) > > I honestly don't know what todo here. I kinda like solution b), > except for the pain it causes to aurora and possible others." You can build nosrc.rpms, by just stating in the .spec, e.g.: Source0: some-nice-file.tar.bz2 ... NoSource: 0 The NoSource directive says that Source0 (in this case) is not to be included in the SRPM. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From rc040203 at freenet.de Mon Feb 26 17:01:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 26 Feb 2007 18:01:19 +0100 Subject: sdcc - Cross Compiler, Needs Packaging Standards? In-Reply-To: <4806.1172508836@laptop13.inf.utfsm.cl> References: <45DF3D33.3030207@redhat.com> <45DF50BF.5090705@hhs.nl> <4806.1172508836@laptop13.inf.utfsm.cl> Message-ID: <1172509279.23237.625.camel@mccallum.corsepiu.local> On Mon, 2007-02-26 at 13:53 -0300, Horst H. von Brand wrote: > Hans de Goede wrote: > > Warren Togami wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > > > > > It appears that a few folks want sdcc, but do the packaging standards > > > for cross compilers and the concern about names being dropped into > > > /usr/bin should be solved first? > > > > > [...] > > > Since Ralf and I agree for 99.9% on my proposal, this really is > > almost done. The only thing which I want discussed in a wider > > audience / need more input in is the SRPM issue, quoting from my > > original mail: > > "The SRPMS for all these packages will most of the time contain the > > exact same tarbals as the native binutils / gcc / libs > > > > Possible solutions: > > a) Live with the extra diskspace / bandwidth cost this induces upon > > our mirrors > > b) *** Warning dirty hack *** > > Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep > > and if it isn't there bail with a message howto get the tarbal > > from the srpms for the native packages. We can use the sources > > file and the look-aside cache to make the test for the tarbal > > succeed on the buildsys. Advantages: saves tons of diskspace. > > Disadvantage: slight inconvienience for people trying to rebuild > > the srpm's manually. Large inconvienience for people doing > > automated rebuilds (aurora for example) > > > > I honestly don't know what todo here. I kinda like solution b), > > except for the pain it causes to aurora and possible others." > > You can build nosrc.rpms, by just stating in the .spec, e.g.: We've been using this approach for the rtems toolchains for years. In practice, this was more hassle than it had helped. The real show stopper which finally broke it was mock. It doesn't support nosrc.rpm. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 26 17:17:34 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 26 Feb 2007 18:17:34 +0100 Subject: EPEL owners In-Reply-To: <200702251312.05640.ville.skytta@iki.fi> References: <200702242324.l1ONOB31008670@cvs-int.fedora.redhat.com> <200702251312.05640.ville.skytta@iki.fi> Message-ID: <20070226181734.63b58fae@python3.es.egwn.lan> Ville Skytt? wrote : > As a side note, I most likely will be interested in maintaining some EPEL5 > packages later, but probably not EPEL4. This shows up a problem with the current situation : Some people could be wanting to maintain some of your packagers for the older RHEL releases which you won't be interested in, but this can't be perfectly handled (i.e. have a complete different owners, like for Fedora vs. RHEL), and _could_ be fixed by co-maintainership... yet if someone it interested in, say, EL2.1 in general, it would be quite difficult and wouldn't make much sense to have him co-maintaining hundreds of packages... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.31 0.38 0.29 From andy at smile.org.ua Mon Feb 26 18:23:18 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 26 Feb 2007 20:23:18 +0200 Subject: rpms/licq/devel .cvsignore, 1.4, 1.5 licq.spec, 1.14, 1.15 sources, 1.4, 1.5 In-Reply-To: <200702261754.l1QHsEDi030295@cvs-int.fedora.redhat.com> References: <200702261754.l1QHsEDi030295@cvs-int.fedora.redhat.com> Message-ID: <20070226182318.GC27186@serv.smile.org.ua> Hi Peter Vrabec! On Mon, Feb 26, 2007 at 12:54:14PM -0500, Peter Vrabec wrote next: > %prep > %setup -q > +tar -C plugins -xjf %{SOURCE1} What about following variant: %setup -q -a1 ln -sf icqnb... plugins/icqnb... ? My 2 cents is just for using setup macro as much as possible. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Feb 26 18:46:54 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 26 Feb 2007 19:46:54 +0100 Subject: AWOL-Maintainer: Hugo Cisneiros In-Reply-To: <1CE6B0FC-9095-4BEF-916C-70DEE07139CA@deds.nl> References: <20070125134557.4055c232@localhost.localdomain> <20070201114908.302d987b@localhost.localdomain> <2A480D8C-4531-4A37-B738-A7AB7943CC3C@deds.nl> <20070222153232.226706de@localhost.localdomain> <6E49FA91-4FC8-4A12-BE27-4A86C1027FE9@deds.nl> <45E024BF.3020606@hhs.nl> <1CE6B0FC-9095-4BEF-916C-70DEE07139CA@deds.nl> Message-ID: <20070226194654.466699d8@python3.es.egwn.lan> Johan Kok wrote : > > On 24-feb-2007, at 12:42, Hans de Goede wrote: > > Johan Kok wrote: > >> > >> Hm, I haven't heard anything from Hugo since that chat. I suppose he > >> never wrote that mail we talked about. > > > > I say that he truely is AWOL then, so lets orphan his packages. Can > > someone make the list of his packages (again) and post that to the > > list, > > then give people a couple of days to pick up some of his packages. > > guichan > kerry > knemo > metamonitor > netpanzer > netpanzer-data > ode > pengupop > python-ogg > python-vorbis > tuxpuck > xmoto I could definitely pick up python-ogg and python-vorbis. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.26 0.23 0.17 From j.w.r.degoede at hhs.nl Mon Feb 26 19:14:15 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Feb 2007 20:14:15 +0100 Subject: AWOL maintainer, packages looking for new owner Message-ID: <45E33187.7000708@hhs.nl> Hi all, As also discussed in another thread, but probably not followed by everyone there, hence a new post in this: Hugo Cisneiros is official AWOL, contact has been made and he would respond about his Fedora contributer status on the list, but he hasn't. This means that the following packages are looking for a new owner, some packages already have volunteers who I've added in brackets: guichan (Michael Thomas aka Wart) kerry (Sebastian Vahl) knemo metamonitor netpanzer netpanzer-data pengupop python-ogg (Matthias Saou) python-vorbis (Matthias Saou) tuxpuck xmoto Regards, Hans From j.w.r.degoede at hhs.nl Mon Feb 26 19:17:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Feb 2007 20:17:47 +0100 Subject: AWOL maintainer, Games looking for new owner Message-ID: <45E3325B.6020703@hhs.nl> Hi all, As also discussed in another thread, but probably not followed by everyone here, hence a new post on this: Hugo Cisneiros is official AWOL, contact has been made and he would respond about his Fedora contributer status on the list, but he hasn't. This means that the following Games are looking for a new owner, some packages already have volunteers who I've added in brackets: guichan (Michael Thomas aka Wart) netpanzer netpanzer-data pengupop tuxpuck xmoto Regards, Hans From chitlesh at fedoraproject.org Mon Feb 26 19:06:07 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 26 Feb 2007 20:06:07 +0100 Subject: Packaging KDE window decorations, etc In-Reply-To: <45DED2060200006A00010A8F@cs-emo.csir.co.za> References: <45DE33F4020000ED00006697@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> Message-ID: <13dbfe4f0702261106i918a13co14938ce538a13a87@mail.gmail.com> Hello there, I have dekorator which is ready for approval https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229319 But now with this new packaging draft for kde stuffs, what could be the final decision ? Should i stick with - dekorator or - kde-decoration-dekorator ? Secondly, moodin is also paving into the approval status. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221015 Right now, it's ksplash-engine-moodin, should it be kde-ksplash-engine-moodin ?? Arthur, you missed ksplash in your drafts. Well as you can see, this draft is the only blocker for these 2 packages. The only question left is whether I should follow it or not. Can anyone shed light on this ? Chitlesh -- http://clunixchit.blogspot.com From limb at jcomserv.net Mon Feb 26 19:05:31 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 26 Feb 2007 13:05:31 -0600 (CST) Subject: AWOL maintainer, packages looking for new owner In-Reply-To: <45E33187.7000708@hhs.nl> References: <45E33187.7000708@hhs.nl> Message-ID: <62060.65.192.24.190.1172516731.squirrel@mail.jcomserv.net> I could take tuxpuck and xmoto. > Hi all, > > As also discussed in another thread, but probably not followed by > everyone there, hence a new post in this: Hugo Cisneiros is official > AWOL, contact has been made and he would respond about his Fedora > contributer status on the list, but he hasn't. > > This means that the following packages are looking for a new owner, > some packages already have volunteers who I've added in brackets: > > guichan (Michael Thomas aka Wart) > kerry (Sebastian Vahl) > knemo > metamonitor > netpanzer > netpanzer-data > pengupop > python-ogg (Matthias Saou) > python-vorbis (Matthias Saou) > tuxpuck > xmoto > > Regards, > > Hans > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From wtogami at redhat.com Mon Feb 26 19:48:04 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 26 Feb 2007 14:48:04 -0500 Subject: Good Review Examples? Message-ID: <45E33974.2020606@redhat.com> http://fedoraproject.org/wiki/Extras/Contributors Under the "Read Other Submissions" section, I think we should have a few links to exemplary examples of how a package review should look like. What are the elements of a good review example? * Well formed submission as suggested by the template. * Constructive comments describing how the package can be improved. * Possibly some back and forth. * APPROVED * Properly formed fedora-cvs request * done Any good examples from recent review tickets? Warren Togami wtogami at redhat.com From alcapcom at gmail.com Mon Feb 26 19:45:18 2007 From: alcapcom at gmail.com (alcapcom) Date: Mon, 26 Feb 2007 20:45:18 +0100 Subject: Add text to an existing file Message-ID: <1172519119.3458.13.camel@xp2000.planet-cameleon.org> Hi Folk, This problem concern this review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192436 For the moment we add the Xgl definition in GDM via this %post script: %post GDM_CONF_FILE=/etc/gdm/custom.conf GDM_CONF_EXSIST=$(fgrep -i \[server-xgl\] $GDM_CONF_FILE) if ! [ -n "$GDM_CONF_EXSIST" ] ; then cp -f $GDM_CONF_FILE $GDM_CONF_FILE.rpmsave cat >> $GDM_CONF_FILE \ << EOF # Experimental build of Xgl [server-xgl] name=Xgl server command=%{_bindir}/Xgl -accel glx:pbuffer -accel xv:pbuffer -audit 0 flexible=false EOF fi Thorsten signal me that it is not a good way of making, but I do not see how to add text to an existing file without a %post script. Any idea? In advance, Thanks -- Regards, Alphonse -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From limb at jcomserv.net Mon Feb 26 20:10:13 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 26 Feb 2007 14:10:13 -0600 (CST) Subject: Good Review Examples? In-Reply-To: <45E33974.2020606@redhat.com> References: <45E33974.2020606@redhat.com> Message-ID: <5052.65.192.24.190.1172520613.squirrel@mail.jcomserv.net> This one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214830 Terribly helpful. > http://fedoraproject.org/wiki/Extras/Contributors > Under the "Read Other Submissions" section, I think we should have a few > links to exemplary examples of how a package review should look like. > > What are the elements of a good review example? > > * Well formed submission as suggested by the template. > * Constructive comments describing how the package can be improved. > * Possibly some back and forth. > * APPROVED > * Properly formed fedora-cvs request > * done > > Any good examples from recent review tickets? > > Warren Togami > wtogami at redhat.com > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From pemboa at gmail.com Mon Feb 26 20:42:43 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 26 Feb 2007 14:42:43 -0600 Subject: Packaging KDE window decorations, etc In-Reply-To: <13dbfe4f0702261106i918a13co14938ce538a13a87@mail.gmail.com> References: <45DE33F4020000ED00006697@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> <13dbfe4f0702261106i918a13co14938ce538a13a87@mail.gmail.com> Message-ID: <16de708d0702261242q12ed318l20e5ee4d0147b827@mail.gmail.com> On 2/26/07, Chitlesh GOORAH wrote: > Hello there, > > I have dekorator which is ready for approval > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229319 > > But now with this new packaging draft for kde stuffs, what could be > the final decision ? > > Should i stick with > - dekorator or > - kde-decoration-dekorator ? I (without any power to do so) suggest that you stick with dekorator. > > Secondly, moodin is also paving into the approval status. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221015 > Right now, it's ksplash-engine-moodin, should it be kde-ksplash-engine-moodin ?? I'll put in a category for splash screens into the draft. I would again suggest leaving things as is till some consensus has been reached on a standard. > Arthur, you missed ksplash in your drafts. Will add. Thanks for pointing that out > > Well as you can see, this draft is the only blocker for these 2 > packages. The only question left is whether I should follow it or not. I vote for not following it yet until it has been peer reviewed and ratified. > Can anyone shed light on this ? > > Chitlesh > -- > http://clunixchit.blogspot.com > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Fedora Core 6 and proud From peter at thecodergeek.com Mon Feb 26 20:40:48 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Feb 2007 12:40:48 -0800 (PST) Subject: Fedora Extras Package Build Report 2007-02-26 In-Reply-To: <1172497277.17419.28.camel@dawkins> References: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> <1172497277.17419.28.camel@dawkins> Message-ID: <22233.65.223.36.19.1172522448.squirrel@webmail.thecodergeek.com> David Nielsen wrote: > But Mr. Gordon.. this is madness, a known unstable beta pushed for FC6. My sincere apologies. :[ This should only have been pushed as an update to FE-Devel; and *not* FC-5/FC-6 as I did. I've put a repository removal request on the wiki's Extras/RepoRequests page for these. Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From peter at thecodergeek.com Mon Feb 26 20:42:14 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Feb 2007 12:42:14 -0800 (PST) Subject: Fedora Extras Package Build Report 2007-02-26 In-Reply-To: <1172497277.17419.28.camel@dawkins> References: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> <1172497277.17419.28.camel@dawkins> Message-ID: <22488.65.223.36.19.1172522534.squirrel@webmail.thecodergeek.com> David Nielsen wrote: > But Mr. Gordon.. this is madness, a known unstable beta pushed for FC6. My sincere apologies. :[ This should only have been pushed as an update to FE-Devel; and *not* FC-5/FC-6 as I did. I've put a repository removal request on the wiki's Extras/RepoRequests page for these. Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From peter at thecodergeek.com Mon Feb 26 20:43:38 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Feb 2007 12:43:38 -0800 (PST) Subject: Fedora Extras Package Build Report 2007-02-26 In-Reply-To: <1172497277.17419.28.camel@dawkins> References: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> <1172497277.17419.28.camel@dawkins> Message-ID: <22799.65.223.36.19.1172522618.squirrel@webmail.thecodergeek.com> David Nielsen wrote: > But Mr. Gordon.. this is madness, a known unstable beta pushed for FC6. My sincere apologies. :[ This should only have been pushed as an update to FE-Devel; and *not* FC-5/FC-6 as I did. I've put a repository removal request on the wiki's Extras/RepoRequests page for these. Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From chitlesh at fedoraproject.org Mon Feb 26 20:48:14 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 26 Feb 2007 21:48:14 +0100 Subject: Packaging KDE window decorations, etc In-Reply-To: <16de708d0702261242q12ed318l20e5ee4d0147b827@mail.gmail.com> References: <45DE33F4020000ED00006697@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> <13dbfe4f0702261106i918a13co14938ce538a13a87@mail.gmail.com> <16de708d0702261242q12ed318l20e5ee4d0147b827@mail.gmail.com> Message-ID: <13dbfe4f0702261248m51bb9446j901556537615fbc7@mail.gmail.com> On 2/26/07, Arthur Pemberton wrote: > > Arthur, you missed ksplash in your drafts. > > Will add. Thanks for pointing that out It would be nice to have : kde-splash instead of kde-splashscreens Chitlesh -- http://clunixchit.blogspot.com From buildsys at fedoraproject.org Mon Feb 26 20:49:40 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 26 Feb 2007 20:49:40 -0000 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-02-26 Message-ID: <20070226204940.11448.68390@extras64.linux.duke.edu> New report for: wart AT kobold.org package: sear - 0.6.3-3.fc7.i386 from fedora-extras-needsign-development-i386 unresolved deps: sear-media package: sear - 0.6.3-3.fc7.ppc from fedora-extras-needsign-development-ppc unresolved deps: sear-media package: sear - 0.6.3-3.fc7.x86_64 from fedora-extras-needsign-development-x86_64 unresolved deps: sear-media ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de claws-mail - 2.7.2-1.fc7.i386 (17 days) libetpan - 0.49-1.fc7.i386 (17 days) bojan AT rexursive.com libapreq2 - 2.09-0.rc2.1.fc7.i386 (17 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (80 days) csound - 5.03.0-9.fc7.i386 (80 days) csound - 5.03.0-9.fc7.ppc (80 days) csound - 5.03.0-9.fc7.x86_64 (80 days) csound-python - 5.03.0-9.fc7.i386 (80 days) csound-python - 5.03.0-9.fc7.ppc (80 days) csound-python - 5.03.0-9.fc7.x86_64 (80 days) dwmw2 AT redhat.com openpbx - 1.2-3.rc2.svn2135.fc7.i386 (82 days) foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (11 days) flac123 - 0.0.9-1.fc7.ppc (11 days) flac123 - 0.0.9-1.fc7.x86_64 (11 days) muine - 0.8.7-1.fc7.i386 (11 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i586 (4 days) kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.i686 (4 days) kmod-sysprof - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 (4 days) kmod-sysprof-PAE - 1.0.8-1.2.6.20_1.2932.fc7.i686 (4 days) kmod-sysprof-kdump - 1.0.8-1.2.6.20_1.2932.fc7.x86_64 (4 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (77 days) libreadline-java - 0.8.0-13.fc6.i386 (77 days) libreadline-java - 0.8.0-13.fc6.ppc (77 days) libreadline-java - 0.8.0-13.fc6.x86_64 (77 days) orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (80 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (80 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (9 days) k3b-extras - 0.12.17-1.fc6.ppc (9 days) k3b-extras - 0.12.17-1.fc6.x86_64 (9 days) spr AT astrax.fis.ucm.es xpa - 2.1.6-8.fc7.i386 (12 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (80 days) xmldiff - 0.6.7-12.fc6.ppc (80 days) xmldiff - 0.6.7-12.fc6.x86_64 (80 days) tcallawa AT redhat.com R - 2.4.1-2.fc7.i386 (12 days) ville.skytta AT iki.fi em8300 - 0.16.1-0.1.rc2.fc7.i386 em8300 - 0.16.1-0.1.rc2.fc7.ppc em8300 - 0.16.1-0.1.rc2.fc7.x86_64 kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i586 (12 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.i686 (12 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.ppc (12 days) kmod-em8300 - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (12 days) kmod-em8300-PAE - 0.16.0-10.2.6.20_1.2922.fc7.i686 (12 days) kmod-em8300-kdump - 0.16.0-10.2.6.20_1.2922.fc7.x86_64 (12 days) kmod-em8300-smp - 0.16.0-10.2.6.20_1.2922.fc7.ppc (12 days) wart AT kobold.org sear - 0.6.3-3.fc7.i386 sear - 0.6.3-3.fc7.ppc sear - 0.6.3-3.fc7.x86_64 ====================================================================== Broken packages in fedora-extras-development-i386: csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2922.fc7 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7 kmod-em8300-PAE-0.16.0-10.2.6.20_1.2922.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2922.fc7PAE kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2932.fc7 kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.20_1.2932.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2932.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-ppc: csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7 kmod-em8300-smp-0.16.0-10.2.6.20_1.2922.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2922.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: R-2.4.1-2.fc7.i386 requires libtk8.5.so R-2.4.1-2.fc7.i386 requires libtcl8.5.so claws-mail-2.7.2-1.fc7.i386 requires libdb-4.3.so csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) kmod-em8300-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7 kmod-em8300-kdump-0.16.0-10.2.6.20_1.2922.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2922.fc7kdump kmod-sysprof-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.20_1.2932.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2932.fc7kdump libapreq2-2.09-0.rc2.1.fc7.i386 requires libdb-4.3.so libetpan-0.49-1.fc7.i386 requires libdb-4.3.so libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 muine-0.8.7-1.fc7.i386 requires libFLAC.so.7 openpbx-1.2-3.rc2.svn2135.fc7.i386 requires libedit.so.0 paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 xpa-2.1.6-8.fc7.i386 requires libtcl8.5.so ====================================================================== Broken packages in fedora-extras-needsign-development-i386: em8300-0.16.1-0.1.rc2.fc7.i386 requires em8300-kmod >= 0:0.16.1 sear-0.6.3-3.fc7.i386 requires sear-media ====================================================================== Broken packages in fedora-extras-needsign-development-ppc: em8300-0.16.1-0.1.rc2.fc7.ppc requires em8300-kmod >= 0:0.16.1 sear-0.6.3-3.fc7.ppc requires sear-media ====================================================================== Broken packages in fedora-extras-needsign-development-x86_64: em8300-0.16.1-0.1.rc2.fc7.x86_64 requires em8300-kmod >= 0:0.16.1 sear-0.6.3-3.fc7.x86_64 requires sear-media From bugs.michael at gmx.net Mon Feb 26 21:08:13 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 26 Feb 2007 22:08:13 +0100 Subject: Summary - Broken dependencies in Fedora Extras development - 2007-02-26 In-Reply-To: <20070226204940.11448.68390@extras64.linux.duke.edu> References: <20070226204940.11448.68390@extras64.linux.duke.edu> Message-ID: <20070226220813.3d1bf2f8.bugs.michael@gmx.net> On Mon, 26 Feb 2007 20:49:40 -0000, Fedora Extras repoclosure wrote: > New report for: wart AT kobold.org > > package: sear - 0.6.3-3.fc7.i386 from fedora-extras-needsign-development-i386 > unresolved deps: > sear-media > > package: sear - 0.6.3-3.fc7.ppc from fedora-extras-needsign-development-ppc > unresolved deps: > sear-media > > package: sear - 0.6.3-3.fc7.x86_64 from fedora-extras-needsign-development-x86_64 > unresolved deps: > sear-media This is okay. Please ignore. A copy request is in the Wiki. I've just been playing with repoclosure checks on temporary repos created from the needsign queue. I will also try to disable the summary mail for those checks. From pemboa at gmail.com Mon Feb 26 21:19:49 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 26 Feb 2007 15:19:49 -0600 Subject: Packaging KDE window decorations, etc In-Reply-To: <13dbfe4f0702261248m51bb9446j901556537615fbc7@mail.gmail.com> References: <45DE33F4020000ED00006697@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> <13dbfe4f0702261106i918a13co14938ce538a13a87@mail.gmail.com> <16de708d0702261242q12ed318l20e5ee4d0147b827@mail.gmail.com> <13dbfe4f0702261248m51bb9446j901556537615fbc7@mail.gmail.com> Message-ID: <16de708d0702261319jab20c54hd913691dd8e9aac6@mail.gmail.com> On 2/26/07, Chitlesh GOORAH wrote: > On 2/26/07, Arthur Pemberton wrote: > > > Arthur, you missed ksplash in your drafts. > > > > Will add. Thanks for pointing that out > > It would be nice to have : kde-splash instead of kde-splashscreens Noted, check wiki. -- Fedora Core 6 and proud From pemboa at gmail.com Mon Feb 26 21:13:16 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 26 Feb 2007 15:13:16 -0600 Subject: Packaging KDE window decorations, etc In-Reply-To: <45DED2060200006A00010A8F@cs-emo.csir.co.za> References: <45DE33F4020000ED00006697@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> <45DED2060200006A00010A8F@cs-emo.csir.co.za> Message-ID: <16de708d0702261313t49ddfb0dt4fc1f30ca5f52812@mail.gmail.com> On 2/23/07, Francois Aucamp wrote: > Good work so far! > > I just have a few suggestions: > > from wiki: > 1. Themes for Amarok should be named > kde-themes-amarok-%{packagename}-%{version}-%{release}.%{arch}.rpm. > > - I don't think this is necessary, especially since lots of Gnome users > also use amarok - IMO it could be something like: > amarok-theme-%{packagename}-%{version}-%{release}.%{arch}.rpm. > > The same goes for k3b, as I also know of a few people that use k3b in > Gnome. > > Actually, I think most (all?) "application-level" themes should _not_ > have a prefix such as "kde-themes-"; imo they are not strictly part of > the "KDE-naming scheme", and it over-complicates things a bit. :-) > > As for the kde-decoration-%{type}-%{packagename}/{kwin-%{packagename} > debate, I'm happy with both. However, if we are going to use something > like kde-style-* and kde-icon-* for widget styles and icons, it might be > better to stick to kde-decoration-* so that everything looks similar. > We could even do something like: > kde-kwin-(%{type}-)%{packagename} > where %{type} is optional, depending on whether or not something like > deKorator is required. > > Your PyQt app sounds interesting; some kind of "find KDE stuff" > yum-frontend? I would find that _very_ useful - let me know if I can > help you out with that... :-) Still very much in the idea (all in my head stage), but I will try to materialize it as soon as possible. > Cheers, > -Francois > > On Thu, 2007-02-22 at 16:22 -0600, Arthur Pemberton wrote: > > On 2/22/07, Chitlesh GOORAH wrote: > > > On 2/22/07, Arthur Pemberton wrote: > > > > > > > Be sure to critique so that I do much better next time on the > first try. > > > > > > > > > > > > > Wouldn't it be better with > > > kwin-%{packagename}-%{version}-%{release}.%{arch}.rpm. > > > instead of > > > > kde-decoration-%{type}-%{packagename}-%{version}-%{release}.%{arch}.rpm. > > > > > > > > > regards, > > > Chitlesh > > > -- > > > > It would definetly be shorter, but I'm thinking of being able to write > > a PyQt app that can simply display apps from `yum list "kde-*"` > > > > -- > > Fedora Core 6 and proud > > > > > -- > This message is subject to the CSIR's copyright, terms and conditions and > e-mail legal notice. Views expressed herein do not necessarily represent the > views of the CSIR. > > CSIR E-mail Legal Notice > http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html > > CSIR Copyright, Terms and Conditions > http://mail.csir.co.za/CSIR_Copyright.html > > For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR > Legal Notice send a blank message with REQUEST LEGAL in the subject line to > CallCentre at csir.co.za. > > > This message has been scanned for viruses and dangerous content by MailScanner, > and is believed to be clean. > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Fedora Core 6 and proud From peter at thecodergeek.com Mon Feb 26 21:19:45 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Feb 2007 13:19:45 -0800 (PST) Subject: Fedora Extras Package Build Report 2007-02-26 In-Reply-To: <1172497277.17419.28.camel@dawkins> References: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> <1172497277.17419.28.camel@dawkins> Message-ID: <32017.65.223.36.19.1172524785.squirrel@webmail.thecodergeek.com> David Nielsen wrote: > But Mr. Gordon.. this is madness, a known unstable beta pushed for FC6. My sincere apologies. :[ This should only have been pushed as an update to FE-Devel; and *not* FC-5/FC-6 as I did. I've put a repository removal request on the wiki's Extras/RepoRequests page for these. Thanks. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From pemboa at gmail.com Mon Feb 26 21:14:40 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 26 Feb 2007 15:14:40 -0600 Subject: Packaging KDE window decorations, etc In-Reply-To: References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> <16de708d0702151543u820a2dcqb88636cc98a054d3@mail.gmail.com> Message-ID: <16de708d0702261314j6585dc91q6e47b12969bda4f2@mail.gmail.com> On 2/16/07, Rex Dieter wrote: > Arthur Pemberton wrote: > > > I too would like to do something similar (as soon as I find a way to > > extend 24hours). > > > > Might I suggest the following format? > > kde-- > > > > I would suggest using the categories used by KDE-look.org. This will > > make a `yum list` more useful. > > Willing to writup a proposal and stuff it in the wiki under > http://fedoraproject.org/wiki/PackagingDrafts/ > somewhere? (: > > -- Rex Gentlemen, I have taken some time to revise my proposal based on comments and suggestions given. Please comment and critique accordingly: http://fedoraproject.org/wiki/PackagingDrafts/KDELooks Arthur Pemberton -- Fedora Core 6 and proud From peter at thecodergeek.com Mon Feb 26 21:28:59 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Feb 2007 13:28:59 -0800 (PST) Subject: Fedora Extras Package Build Report 2007-02-26 In-Reply-To: <32017.65.223.36.19.1172524785.squirrel@webmail.thecodergeek.com> References: <20070226123633.7A10F15212E@buildsys.fedoraproject.org> <1172497277.17419.28.camel@dawkins> <32017.65.223.36.19.1172524785.squirrel@webmail.thecodergeek.com> Message-ID: <34161.65.223.36.19.1172525339.squirrel@webmail.thecodergeek.com> Gaah I think DreamHost's mail servers I just sent that multiple times by accident. Sorry about that, too! :< (I *SO* hate Mondays...) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From devrim at CommandPrompt.com Mon Feb 26 21:33:09 2007 From: devrim at CommandPrompt.com (Devrim GUNDUZ) Date: Mon, 26 Feb 2007 23:33:09 +0200 Subject: AWOL maintainer, packages looking for new owner In-Reply-To: <45E33187.7000708@hhs.nl> References: <45E33187.7000708@hhs.nl> Message-ID: <1172525589.3285.0.camel@laptop.gunduz.org> Hi, On Mon, 2007-02-26 at 20:14 +0100, Hans de Goede wrote: > xmoto I can take this one, if noone beats me. /me loves playing xmoto. -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- 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 bpepple at fedoraproject.org Mon Feb 26 21:53:45 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 26 Feb 2007 16:53:45 -0500 Subject: FESCo Meeting Summary for 2007-02-22 Message-ID: <1172526825.16039.5.camel@Chuck> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Tom Callaway (spot) * Warren Togami (warren) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Jesse Keating (f13) * Jeremy Katz (jeremy) Members Absent * Andreas Bierfert (awjb) * Josh Boyer (jwb) == Summary == awjb * Andreas has decided to step down from FESCo due to time constraints with his university work. Core/Extras Merge * FESCo ratified the new Package Review process. For more details refer to https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00380.html Co-Maintainers * FESCo ratified the co-maintainers guidelines. http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership Sponsor Nominations * Parag Ashok Nemade, Andrew Overholt, Thomas Fitzsimmons, and Chitlesh Goorahwas were nominated and accepted as new sponsors. Packaging Committee Report * FESCo didn't have any objections to the Packaging Committee's guidelines regarding: SourceURL: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070222 Thanks, /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 Matt_Domsch at dell.com Mon Feb 26 21:58:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 26 Feb 2007 15:58:45 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-02-26 Message-ID: <20070226155845.A5641@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Mon Feb 26 15:37:09 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2646 Number failed to build: 66 Number expected to fail due to ExclusiveArch or ExcludeArch: 20 Leaving: 46 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 46 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com SIMVoleon-2.0.1-6.fc7 rc040203 at freenet.de SoQt-1.4.1-5.fc7 rc040203 at freenet.de airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de atitvout-0.4-6 andreas.bierfert at lowlatency.de audacity-1.3.2-7.20070106cvs.fc7 gemi at bluewin.ch,bugs.michael at gmx.net banshee-0.11.5-1.fc7 caillon at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libreadline-java-0.8.0-13.fc6 ifoox at redhat.com mlton-20061107-2.fc7 adam at spicenitz.org nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.9-7.fc7 jamatos at fc.up.pt python-reportlab-2.0-2.fc7 bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Mon Feb 26 21:59:06 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 26 Feb 2007 15:59:06 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-02-26 Message-ID: <20070226155906.A5660@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Mon Feb 26 15:41:50 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2646 Number failed to build: 43 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 41 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 41 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com SIMVoleon-2.0.1-6.fc7 rc040203 at freenet.de SoQt-1.4.1-5.fc7 rc040203 at freenet.de airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de banshee-0.11.5-1.fc7 caillon at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.0-10.2.6.20_1.2922.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk itcl-3.3-0.8.RC1.fc7 wart at kobold.org itk-3.3-0.5.RC1.fc7 wart at kobold.org jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libapreq2-2.09-0.rc2.1.fc7 bojan at rexursive.com libpaper-1.1.20-5.fc6 tcallawa at redhat.com libreadline-java-0.8.0-13.fc6 ifoox at redhat.com nomadsync-0.4.2-13.fc6 triad at df.lth.se octave-2.9.9-2.fc7 qspencer at ieee.org openpbx-1.2-3.rc2.svn2135.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-extras-5.2.0-1.fc7 dmitry at butskoy.name php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com seahorse-0.8.1-2.fc6 skvidal at linux.duke.edu steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 giallu at gmail.com toped-0.8.2-2.fc6 cgoorah at yahoo.com.au wine-0.9.31-1.fc7 andreas.bierfert at lowlatency.de xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xfce4-wavelan-plugin-0.5.3-3.fc6 fedora at christoph-wickert.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xosd-2.2.14-8.fc6 kevin at tummy.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From packages at amiga-hardware.com Mon Feb 26 23:41:12 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 26 Feb 2007 23:41:12 +0000 Subject: using non-standard optflags (-O3, in particular) In-Reply-To: <20070209190051.GA13895@jadzia.bu.edu> References: <20070208214737.GA20150@jadzia.bu.edu> <1170973018.13307.47.camel@localhost.localdomain> <20070209001402.GE2821@free.fr> <1171035994.31485.155.camel@mccallum.corsepiu.local> <45CC9A4A.1090106@nomis80.org> <1171037831.31485.164.camel@mccallum.corsepiu.local> <20070209164718.GC2979@free.fr> <20070209190051.GA13895@jadzia.bu.edu> Message-ID: <45E37018.3010302@amiga-hardware.com> Matthew Miller wrote: > > How about I include a specific benchmark test in build section that runs > for, say, a minute, and then use that to auto-select between O2 and O3 on a > per-build basis? :) > As a compromise, you could supply both in the same RPM, or even split off the -O3 version into a subrpm with some sort of suffix to distinguish it from the 'default' -O2 version. eg: /usr/bin/someprogram (-O2) /usr/bin/someprogram_O3 (-O3) IIRC i've seen similar things done in the past, for example where it might be advantageous to supply both an OpenGL version and a non-OpenGL version. Coincidentally I had to deal with a package for another repo where upstream used -O3 by default and the resultant binary was horribly unstable but -O2 was fine. -- Ian Chapman. From j.w.r.degoede at hhs.nl Tue Feb 27 06:51:11 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Feb 2007 07:51:11 +0100 Subject: AWOL maintainer, packages looking for new owner In-Reply-To: <1172525589.3285.0.camel@laptop.gunduz.org> References: <45E33187.7000708@hhs.nl> <1172525589.3285.0.camel@laptop.gunduz.org> Message-ID: <45E3D4DF.8000308@hhs.nl> Devrim GUNDUZ wrote: > Hi, > > On Mon, 2007-02-26 at 20:14 +0100, Hans de Goede wrote: >> xmoto > > I can take this one, if noone beats me. > > /me loves playing xmoto. > I'm afraid that Jon Ciesla has already beaten you to it. Feel free to take one of the others though :) Regards, Hans From j.w.r.degoede at hhs.nl Tue Feb 27 06:54:56 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Feb 2007 07:54:56 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <1172526825.16039.5.camel@Chuck> References: <1172526825.16039.5.camel@Chuck> Message-ID: <45E3D5C0.5090002@hhs.nl> Brian Pepple wrote: > Packaging Committee Report > * FESCo didn't have any objections to the Packaging Committee's > guidelines regarding: > SourceURL: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl > Hmm, I added a comment a couple of days ago to the page about the sourceforge section not being correct and that is still there. How can this be approved without that comment being addressed? Regsrds, Hans From ville.skytta at iki.fi Tue Feb 27 07:14:08 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 27 Feb 2007 09:14:08 +0200 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <45E3D5C0.5090002@hhs.nl> References: <1172526825.16039.5.camel@Chuck> <45E3D5C0.5090002@hhs.nl> Message-ID: <200702270914.09086.ville.skytta@iki.fi> On Tuesday 27 February 2007, Hans de Goede wrote: > Brian Pepple wrote: > > Packaging Committee Report > > * FESCo didn't have any objections to the Packaging Committee's > > guidelines regarding: > > SourceURL: http://www.fedoraproject.org/wiki/PackagingDrafts/SourceUrl > > Hmm, I added a comment a couple of days ago to the page about the > sourceforge section not being correct and that is still there. How can > this be approved without that comment being addressed? The FESCO meeting which approved it was on 22th, you added a comment on 24th? Besides, that comment has been addressed over and over again, at least most of it. downloads.sourceforge.net (with the "s" in "downloads", and "sourceforge" spelled as is, not "sf") is a different system from download.sourceforge.net and dl.sf.net and dl.sourceforge.net which are all the same. And downloads.sf.net is yet something different. See what DNS has to say about those. It is not a coincidence that the draft says "use downloads.sourceforge.net". SourceForge uses http://downloads.sourceforge.net/foo/bar-1.0.tar.gz links themselves, see the file releases view (appended with ?use_mirror=... though). Have you actually witnessed downloads.sourceforge.net (again, the one with "s" in "downloads", and "sourceforge" spelled as is, not "sf") failing the way you describe? I haven't, nor I remember seeing anyone saying that it would have. I have seen it happen several times with dl.sf.net/download.sourceforge.net. From faucamp at csir.co.za Tue Feb 27 10:01:11 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Tue, 27 Feb 2007 12:01:11 +0200 Subject: Packaging KDE window decorations, etc In-Reply-To: <45E41D870200006A00010DF5@cs-emo.csir.co.za> References: <45E36B6B020000C5000071AD@cs-emo.csir.co.za> <45E41D870200006A00010DF5@cs-emo.csir.co.za> Message-ID: <45E41D870200006A00010DF5@cs-emo.csir.co.za> On Mon, 2007-02-26 at 15:14 -0600, Arthur Pemberton wrote: > Gentlemen, > > I have taken some time to revise my proposal based on comments and > suggestions given. > > Please comment and critique accordingly: > http://fedoraproject.org/wiki/PackagingDrafts/KDELooks >From wiki: "Problems: Current Purpose may be too broad." Current: "Purpose: To develop a standard package naming scheme for all packages in The Fedora-KDE universe." Suggestion: Purpose: To develop a standard package naming scheme for add-on packages (such as themes) of other applications/system elements in the Fedora-KDE universe. Someone with more creativity can rephrase that to be sound better, of course :-) -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Feb 27 11:13:01 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Feb 2007 12:13:01 +0100 Subject: Good Review Examples? In-Reply-To: <45E33974.2020606@redhat.com> References: <45E33974.2020606@redhat.com> Message-ID: <20070227121301.583376a8@python3.es.egwn.lan> Warren Togami wrote : > http://fedoraproject.org/wiki/Extras/Contributors > Under the "Read Other Submissions" section, I think we should have a few > links to exemplary examples of how a package review should look like. > > What are the elements of a good review example? > > * Well formed submission as suggested by the template. > * Constructive comments describing how the package can be improved. > * Possibly some back and forth. > * APPROVED > * Properly formed fedora-cvs request > * done > > Any good examples from recent review tickets? Are you interested in counter-examples too? It's not a formal review, but IMHO definitely highlights some of the possible misunderstandings people can have from the guidelines : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230096 - No constructive comments, just "MUST" (some wrong) and "SHOULD" - No indication of it's formal or just some preliminary comments Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.62 0.43 0.22 From pertusus at free.fr Tue Feb 27 11:50:22 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Feb 2007 12:50:22 +0100 Subject: Good Review Examples? In-Reply-To: <20070227121301.583376a8@python3.es.egwn.lan> References: <45E33974.2020606@redhat.com> <20070227121301.583376a8@python3.es.egwn.lan> Message-ID: <20070227115022.GA16894@free.fr> On Tue, Feb 27, 2007 at 12:13:01PM +0100, Matthias Saou wrote: > > Are you interested in counter-examples too? It's not a formal review, > but IMHO definitely highlights some of the possible misunderstandings > people can have from the guidelines : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230096 > > - No constructive comments, just "MUST" (some wrong) and "SHOULD" > - No indication of it's formal or just some preliminary comments I don't think this is a good example. I can guess that Xavier isn't very experienced, so doing review that may be ameliorated is something normal, and I think that one of the role, of (very) experienced packagers is to point out out in a pedagogical manner his errors. I don't disagree that there are mistakes in the review, but in my opinion learning by doing (mistakes) should be encouraged, so I think that in some sense this review is perfectly right since it shows an inexperienced reviewer who does his best to comment on a review. -- Pat From rdieter at math.unl.edu Tue Feb 27 14:01:26 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Feb 2007 08:01:26 -0600 Subject: Packaging KDE window decorations, etc References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> <16de708d0702151543u820a2dcqb88636cc98a054d3@mail.gmail.com> <16de708d0702261314j6585dc91q6e47b12969bda4f2@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > Gentlemen, > > I have taken some time to revise my proposal based on comments and > suggestions given. > > Please comment and critique accordingly: > http://fedoraproject.org/wiki/PackagingDrafts/KDELooks Thanks, very good work. My first suggestion would be that since this is a *Naming scheme* guideline, all references to -%{version}-%{release}.%{arch}.rpm should be omitted. -- Rex From rc040203 at freenet.de Tue Feb 27 14:15:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 27 Feb 2007 15:15:57 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <1172526825.16039.5.camel@Chuck> References: <1172526825.16039.5.camel@Chuck> Message-ID: <1172585758.15418.9.camel@mccallum.corsepiu.local> [Resent, initial attempt to send to the accounts list seems to have failed] On Mon, 2007-02-26 at 16:53 -0500, Brian Pepple wrote: > Members Present > * Brian Pepple (bpepple) > * Jason Tibbitts (tibbs) > * Christian Iseli (ch4chris) > * Tom Callaway (spot) > * Warren Togami (warren) > * Rex Dieter (rdieter) > * Toshio Kuratomi (abadger1999) > * Kevin Fenzi (nirik) > * Dennis Gilmore (dgilmore) > * Bill Nottingham (notting) > * Jesse Keating (f13) > * Jeremy Katz (jeremy) > Sponsor Nominations > * Parag Ashok Nemade, Andrew Overholt, Thomas Fitzsimmons, and Chitlesh > Goorahwas were nominated and accepted as new sponsors. How comes varekova has been made sponsor? I received a mail dated today with her application for for extras access, now, she out of a sudden seems to have been made sponsor. Ralf From tibbs at math.uh.edu Tue Feb 27 15:19:35 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Feb 2007 09:19:35 -0600 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <1172585758.15418.9.camel@mccallum.corsepiu.local> References: <1172526825.16039.5.camel@Chuck> <1172585758.15418.9.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: >> Sponsor Nominations Parag Ashok Nemade, Andrew Overholt, Thomas >> Fitzsimmons, and Chitlesh Goorahwas were nominated and accepted as >> new sponsors. RC> How comes varekova has been made sponsor? varekova doesn't appear in the list you quoted; are you talking about some separate event? If she has indeed been made a sponsor, it was done without FESCo input. - J< From bpepple at fedoraproject.org Tue Feb 27 15:27:42 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 27 Feb 2007 10:27:42 -0500 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <1172585758.15418.9.camel@mccallum.corsepiu.local> References: <1172526825.16039.5.camel@Chuck> <1172585758.15418.9.camel@mccallum.corsepiu.local> Message-ID: <1172590062.29673.7.camel@Chuck> On Tue, 2007-02-27 at 15:15 +0100, Ralf Corsepius wrote: > > > Sponsor Nominations > > * Parag Ashok Nemade, Andrew Overholt, Thomas Fitzsimmons, and Chitlesh > > Goorahwas were nominated and accepted as new sponsors. > How comes varekova has been made sponsor? > > I received a mail dated today with her application for for extras > access, now, she out of a sudden seems to have been made sponsor. I believe someone has jumped the gun on making her a sponsor, since FESCo hasn't had a chance to vote on this. Later, /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 rc040203 at freenet.de Tue Feb 27 15:36:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 27 Feb 2007 16:36:07 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: References: <1172526825.16039.5.camel@Chuck> <1172585758.15418.9.camel@mccallum.corsepiu.local> Message-ID: <1172590567.15418.18.camel@mccallum.corsepiu.local> On Tue, 2007-02-27 at 09:19 -0600, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > >> Sponsor Nominations Parag Ashok Nemade, Andrew Overholt, Thomas > >> Fitzsimmons, and Chitlesh Goorahwas were nominated and accepted as > >> new sponsors. > > RC> How comes varekova has been made sponsor? > > varekova doesn't appear in the list you quoted; are you talking about > some separate event? If I interpret https://admin.fedora.redhat.com/accounts/groupbox.cgi correctly, she is being shown as sponsor. cvsextras varekova sponsor approved rvokal cvsextras varekova rvokal user approved rvokal > If she has indeed been made a sponsor, it was done without FESCo > input. That's what I am wondering about. Ralf From tibbs at math.uh.edu Tue Feb 27 15:45:54 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Feb 2007 09:45:54 -0600 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <1172590567.15418.18.camel@mccallum.corsepiu.local> References: <1172526825.16039.5.camel@Chuck> <1172585758.15418.9.camel@mccallum.corsepiu.local> <1172590567.15418.18.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> If I interpret RC> https://admin.fedora.redhat.com/accounts/groupbox.cgi correctly, RC> she is being shown as sponsor. Something is obviously screwed up anyway; varekova appears twice in the list, and the role domain of the second appearance is "rvokal" which is pretty odd. Note that there's also duplication for "wilmer". Something's obviously gone wrong somewhere. - J< From bpepple at fedoraproject.org Tue Feb 27 16:10:00 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 27 Feb 2007 11:10:00 -0500 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: References: <1172526825.16039.5.camel@Chuck> <1172585758.15418.9.camel@mccallum.corsepiu.local> <1172590567.15418.18.camel@mccallum.corsepiu.local> Message-ID: <1172592600.31658.9.camel@Chuck> On Tue, 2007-02-27 at 09:45 -0600, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> If I interpret > RC> https://admin.fedora.redhat.com/accounts/groupbox.cgi correctly, > RC> she is being shown as sponsor. > > Something is obviously screwed up anyway; varekova appears twice in > the list, and the role domain of the second appearance is "rvokal" > which is pretty odd. This looks like it was rvokal's first time sponsoring someone, and obviously he had some problems with it. I've removed varekova's 2nd account (which was the one she was made a sponsor with). I'm not sure how to remove the role domain that was added in error, but maybe someone more familiar with the accounts system can fix 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 pemboa at gmail.com Tue Feb 27 16:13:25 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 28 Feb 2007 10:13:25 +1800 Subject: Packaging KDE window decorations, etc In-Reply-To: References: <45D48A860200006A0000FE81@cs-emo.csir.co.za> <16de708d0702151543u820a2dcqb88636cc98a054d3@mail.gmail.com> <16de708d0702261314j6585dc91q6e47b12969bda4f2@mail.gmail.com> Message-ID: <16de708d0702270813h1b56b0dal874a44c47a6e4e25@mail.gmail.com> On 2/28/07, Rex Dieter wrote: > Arthur Pemberton wrote: > > > > Gentlemen, > > > > I have taken some time to revise my proposal based on comments and > > suggestions given. > > > > Please comment and critique accordingly: > > http://fedoraproject.org/wiki/PackagingDrafts/KDELooks > > Thanks, very good work. My first suggestion would be that since this is a > *Naming scheme* guideline, all references to > -%{version}-%{release}.%{arch}.rpm > should be omitted. > > -- Rex Fixed. -- Fedora Core 6 and proud From pemboa at gmail.com Tue Feb 27 16:13:49 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 28 Feb 2007 10:13:49 +1800 Subject: Packaging KDE window decorations, etc In-Reply-To: <45E41D870200006A00010DF5@cs-emo.csir.co.za> References: <45E36B6B020000C5000071AD@cs-emo.csir.co.za> <45E41D870200006A00010DF5@cs-emo.csir.co.za> <45E41D870200006A00010DF5@cs-emo.csir.co.za> Message-ID: <16de708d0702270813k6f31e722rd5fcc126096d767e@mail.gmail.com> On 2/28/07, Francois Aucamp wrote: > On Mon, 2007-02-26 at 15:14 -0600, Arthur Pemberton wrote: > > Gentlemen, > > > > I have taken some time to revise my proposal based on comments and > > suggestions given. > > > > Please comment and critique accordingly: > > http://fedoraproject.org/wiki/PackagingDrafts/KDELooks > > >From wiki: > > "Problems: Current Purpose may be too broad." > > Current: > "Purpose: To develop a standard package naming scheme for all packages > in The Fedora-KDE universe." > > Suggestion: > Purpose: To develop a standard package naming scheme for add-on packages > (such as themes) of other applications/system elements in the Fedora-KDE > universe. > > Someone with more creativity can rephrase that to be sound better, of > course :-) > > -Francois > Thanks, added. -- Fedora Core 6 and proud From radekvokal at gmail.com Tue Feb 27 16:15:08 2007 From: radekvokal at gmail.com (Radek Vokal) Date: Tue, 27 Feb 2007 17:15:08 +0100 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: References: <1172526825.16039.5.camel@Chuck> <1172585758.15418.9.camel@mccallum.corsepiu.local> Message-ID: <76ac05530702270815q2ecc8775gec58881537e2f16e@mail.gmail.com> my fault, shame on me. She is not a sponsor and won't be one. From bpepple at fedoraproject.org Tue Feb 27 16:20:58 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 27 Feb 2007 11:20:58 -0500 Subject: FESCo Meeting Summary for 2007-02-22 In-Reply-To: <76ac05530702270815q2ecc8775gec58881537e2f16e@mail.gmail.com> References: <1172526825.16039.5.camel@Chuck> <1172585758.15418.9.camel@mccallum.corsepiu.local> <76ac05530702270815q2ecc8775gec58881537e2f16e@mail.gmail.com> Message-ID: <1172593258.32051.0.camel@Chuck> On Tue, 2007-02-27 at 17:15 +0100, Radek Vokal wrote: > my fault, shame on me. She is not a sponsor and won't be one. No problem, I removed her account which was made 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 buc at odusz.so-cdu.ru Tue Feb 27 17:42:09 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 27 Feb 2007 20:42:09 +0300 Subject: xawtv: legal question Message-ID: <45E46D71.5050409@odu.neva.ru> I'm going to package "xawtv" (A TV application for v4l compliant devices, was in Fedora until FC2, http://linux.bytesex.org/xawtv ) Xawtv can record TV into raw or avi file, including formats: > raw - single file, raw video data > video formats: > rgb 24 bit TrueColor (BE: rgb) [raw] > gray 8 bit StaticGray [raw] > 422 16 bit YUV 4:2:2 (packed, YUYV) [raw] > 422p 16 bit YUV 4:2:2 (planar) [raw] > 4mpeg yuv4mpeg (mpeg2enc >= 1.6) [yuv] > 4mpeg-o yuv4mpeg (old mpeg2enc) [yuv] > audio formats: > mono8 8bit mono [wav] > mono16 16bit mono (LE) [wav] > stereo 16bit stereo (LE) [wav] > > avi - Microsoft AVI (RIFF) format > video formats: > rgb15 15 bit TrueColor (LE) [avi] > rgb24 24 bit TrueColor (LE: bgr) [avi] > mjpeg MJPEG (AVI) [avi] > jpeg JPEG (JFIF) [avi] > audio formats: > mono8 8bit mono [avi] > mono16 16bit mono (LE) [avi] > stereo 16bit stereo (LE) [avi] It seems that "yuv4mpeg" is some kind of raw formats, but what about "mjpeg" (motion jpeg) in avi files? I've found that only ffmpeg-based plugins can play it then... Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From j.w.r.degoede at hhs.nl Tue Feb 27 18:19:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Feb 2007 19:19:25 +0100 Subject: xawtv: legal question In-Reply-To: <45E46D71.5050409@odu.neva.ru> References: <45E46D71.5050409@odu.neva.ru> Message-ID: <45E4762D.90109@hhs.nl> Dmitry Butskoy wrote: > I'm going to package "xawtv" > (A TV application for v4l compliant devices, was in Fedora until FC2, > http://linux.bytesex.org/xawtv ) > > Xawtv can record TV into raw or avi file, including formats: >> raw - single file, raw video data >> video formats: >> rgb 24 bit TrueColor (BE: rgb) [raw] >> gray 8 bit StaticGray [raw] >> 422 16 bit YUV 4:2:2 (packed, YUYV) [raw] >> 422p 16 bit YUV 4:2:2 (planar) [raw] >> 4mpeg yuv4mpeg (mpeg2enc >= 1.6) [yuv] >> 4mpeg-o yuv4mpeg (old mpeg2enc) [yuv] >> audio formats: >> mono8 8bit mono [wav] >> mono16 16bit mono (LE) [wav] >> stereo 16bit stereo (LE) [wav] >> >> avi - Microsoft AVI (RIFF) format >> video formats: >> rgb15 15 bit TrueColor (LE) [avi] >> rgb24 24 bit TrueColor (LE: bgr) [avi] >> mjpeg MJPEG (AVI) [avi] >> jpeg JPEG (JFIF) [avi] >> audio formats: >> mono8 8bit mono [avi] >> mono16 16bit mono (LE) [avi] >> stereo 16bit stereo (LE) [avi] > > It seems that "yuv4mpeg" is some kind of raw formats, but what about > "mjpeg" (motion jpeg) in avi files? I've found that only ffmpeg-based > plugins can play it then... > the 2 4mpeg formats definetely are a patent problem, mjpeg OTOH is fine. I don't know what the status as a container format is. Regards, Hans From buildsys at fedoraproject.org Tue Feb 27 22:17:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 27 Feb 2007 17:17:21 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-27 Message-ID: <20070227221721.A133715212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 0 Packages built and released for Fedora Extras 6: 22 brasero-0.5.2-1.fc6 crossvc-1.5.1-1.fc6 freedroidrpg-0.10.1-1.fc6 git-1.5.0.2-1.fc6 grepmail-5.3032-5.fc6 gtkwave-3.0.22-1.fc6 irsim-9.7.45-1.fc6 kazehakase-0.4.4.1-3.fc6.1 kpowersave-0.7.2-1.fc6 licq-1.3.4-3.fc6 liferea-1.0.26-3.fc6 NEW magic-7.4.33-6.fc6 NEW mecab-0.94-0.4.pre2.fc6 pdftk-1.41-3.fc6 perl-Mail-Mbox-MessageParser-1.5000-1.fc6 php-pecl-zip-1.8.6-1.fc6 piklab-0.13.3-2.fc6.1 raptor-1.4.14-3.fc6 ushare-0.9.10-1.fc6 wcstools-3.6.7-1.fc6 wesnoth-1.2.2-2.fc6 wordpress-2.1.1-0.fc6 Packages built and released for Fedora Extras 5: 15 crossvc-1.5.1-1.fc5 galeon-2.0.3-3.fc5 grepmail-5.3032-5.fc5 gtkwave-3.0.22-1.fc5 kazehakase-0.4.4.1-3.fc5.1 NEW mecab-0.94-0.4.pre2.fc5 pdftk-1.41-3.fc5 perl-Mail-Mbox-MessageParser-1.5000-1.fc5 php-pecl-zip-1.8.6-1.fc5 piklab-0.13.3-2.fc5 raptor-1.4.14-3.fc5 ushare-0.9.10-1.fc5 wcstools-3.6.7-1.fc5 wesnoth-1.2.2-2.fc5 wordpress-2.1.1-0.fc5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From chris.stone at gmail.com Tue Feb 27 22:56:32 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 27 Feb 2007 14:56:32 -0800 Subject: Fedora Extras Package Build Report 2007-02-27 In-Reply-To: <20070227221721.A133715212E@buildsys.fedoraproject.org> References: <20070227221721.A133715212E@buildsys.fedoraproject.org> Message-ID: On 2/27/07, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora Extras development: 0 Build report no longer working for devel? From matt at truch.net Tue Feb 27 23:03:20 2007 From: matt at truch.net (Matthew D Truch) Date: Tue, 27 Feb 2007 18:03:20 -0500 Subject: Fedora Extras Package Build Report 2007-02-27 In-Reply-To: References: <20070227221721.A133715212E@buildsys.fedoraproject.org> Message-ID: <20070227230320.GJ9723@truch.net> > >Packages built and released for Fedora Extras development: 0 > > Build report no longer working for devel? It's build and *release* report. Wasn't the freeze on devel (for Fedora 7 test 2) just lifted? -- "Party on Wayne; Party on Garth. -- Wayne's World" -------------------------- Matthew Truch Department of Physics Brown University matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Feb 27 23:15:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Feb 2007 04:45:00 +0530 Subject: Xara LX forked to replace rendering engine Message-ID: <45E4BB74.8000607@fedoraproject.org> Hi Thought this might interesting news since Xara LX got kicked out of Fedora for the proprietary cdraw rending engine. http://www.linux.com/article.pl?sid=07/02/26/1726257 Rahul From buildsys at fedoraproject.org Wed Feb 28 00:09:04 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 27 Feb 2007 19:09:04 -0500 (EST) Subject: Fedora Extras Package Build Report 2007-02-27 Message-ID: <20070228000904.BE9A915212E@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 137 NEW Democracy-0.9.5.1-4.fc7 NEW KoboDeluxe-0.4-0.3.pre10.fc7 R-2.4.1-3.fc7 abcm2ps-5.3.0-1.fc7 amavisd-new-2.4.5-1.fc7 NEW aqbanking-2.1.0-14 audacity-1.3.2-14.fc7 bash-completion-20060301-3.fc7 beryl-core-0.1.9999.2-2.fc7 beryl-plugins-0.1.9999.2-2.fc7 bittorrent-4.4.0-4.fc7 brasero-0.5.2-1.fc7 claws-mail-2.7.2-2.fc7 NEW compat-wxGTK26-2.6.3-2 crossvc-1.5.1-1.fc7 cyphesis-0.5.11-2.fc7 NEW deluge-0.4.90.2-2.fc7 deskbar-applet-2.17.91-1.fc7 dkms-2.0.15-1.fc7 dvdauthor-0.6.14-1.fc7 NEW elph-1.0.1-1.fc7 em8300-0.16.1-0.1.rc2.fc7 emelfm2-0.3.2-2.fc7 eventlog-0.2.5-4.fc7 NEW fedora-ds-base-1.1.0-0.1.20070223.fc7 freedroidrpg-0.10.1-1.fc7 fuse-2.6.3-2.fc7 gajim-0.11.1-1.fc7 gauche-gl-0.4.3-2.fc7 gauche-gtk-0.4.1-11.fc7 gcstar-1.1.1-2.fc7 geany-0.10.1-1.fc7 git-1.5.0.2-1.fc7 NEW glimmer-3.02-1.fc7 global-5.4-1.fc7 gnome-python2-gda-2.14.3-1.fc7 gnomesword-2.2.2.1-2.fc7 gpa-0.7.5-1.fc7 grepmail-5.3032-5.fc7 gsynaptics-0.9.11-1.fc7 NEW gtkpod-0.99.8-3.fc7 gtkwave-3.0.22-1.fc7 gweled-0.7-7.fc7 NEW gwenhywfar-2.3.0-7 hping3-0.0.20051105-7.fc7 NEW hyperestraier-1.4.9-2.fc7 initng-ifiles-0.0.8.1-1.fc7 irsim-9.7.45-1.fc7 jd-1.8.8-0.1.cvs070227.fc7 john-1.7.0.2-3.fc7 kazehakase-0.4.4.1-3.fc7 NEW kbilliards-0.8.7b-2.fc7 kdeartwork-extras-3.5.6-2.fc7 kdmtheme-1.1.2-5.fc7 klamav-0.41-1.fc7 koffice-1.6.2-3.fc7 kpowersave-0.7.2-1.fc7 kvm-14-2 lat-1.2.2-1.fc7 leafnode-1.11.5-4.fc7 libetpan-0.49-2.fc7 liblo-0.23-12.fc7 NEW libofx-0.8.3-3 NEW libsmbios-0.13.2-1.fc7 libstroke-0.5.1-13.fc7 licq-1.3.4-6.fc7 liferea-1.2.7-1.fc7 loudmouth-1.2.1-2.fc7 mISDN-1.1.0-1 NEW magic-7.4.33-6.fc7 NEW mecab-0.94-0.4.pre2.fc7 monodevelop-0.13-1.fc7 muine-0.8.7-2.fc7 nagios-plugins-1.4.6-1.fc7 nrpe-2.7-3.fc7 numpy-1.0.1-3.fc7 openpbx-1.2-3.rc3.svn2540.fc7 otrs-2.1.5-1.fc7 pan-0.125-1.fc7 pdftk-1.41-3.fc7 perl-Apache-Session-1.82-1.fc7 perl-Cairo-1.023-1.fc7 perl-Config-General-2.32-1.fc7 NEW perl-Crypt-PasswdMD5-1.3-2.fc7 perl-Data-Compare-0.15-1.fc7 perl-GSSAPI-0.24-1.fc7 perl-Glib-1.144-1.fc7 perl-Gtk2-1.143-1.fc7 perl-Image-Info-1.24-1.fc7 perl-Mail-Mbox-MessageParser-1.5000-1.fc7 NEW perl-Math-Random-MT-Auto-5.04-3.fc7 perl-Test-Manifest-1.17-1.fc7 php-Smarty-2.6.16-2.fc7 piklab-0.13.3-2.fc7 pl-5.6.28-1.fc7 python-4Suite-XML-1.0.2-1 python-eyed3-0.6.12-1.fc7 python-psyco-1.5.1-5.fc7 NEW qdbm-1.8.74-2.fc7 qgit-1.5.5-1.fc7 qt4-4.2.2-3.fc7 raptor-1.4.14-3.fc7 regexxer-0.9-1.fc7 scanssh-2.1-11.fc7 scipy-0.5.2-1.fc7 seahorse-0.8.2-2.fc7 sear-0.6.3-3.fc7 NEW speedcrunch-0.7-0.9.beta2.fc7 streamtuner-0.99.99-16.fc7 syck-0.55-14.fc7 syslog-ng-2.0.2-2.fc7 tclabc-1.0.9-1.fc7 NEW thinkfinger-0.2.2-4.fc7 tmda-1.1.11-1.fc7 tor-0.1.1.26-3.fc7 ucblogo-5.5-9.fc7 NEW usbsink-0.3.1-1.fc7 ushare-0.9.10-1.fc7 vdr-1.4.5-4.fc7 vdr-sudoku-0.1.3-1.fc7 vigra-1.5.0-2.fc7 vnstat-1.4-9.fc7 vpnc-0.4.0-1.fc7 wcstools-3.6.7-1.fc7 wesnoth-1.2.2-2.fc7 wordpress-2.1.1-0.fc7 wxMaxima-0.7.1-2.fc7 xcircuit-3.4.26-20.fc7 xfce4-datetime-plugin-0.5.0-1.fc7 xfce4-genmon-plugin-3.1-1.fc7 xfce4-wavelan-plugin-0.5.4-1.fc7 xfce4-xmms-plugin-0.5.1-1.fc7 xl2tpd-1.1.08-2.fc7 xosd-2.2.14-9.fc7 xpa-2.1.6-9.fc7 xpilot-ng-4.7.2-12.fc7 yasm-0.6.0-1.fc7 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From daniil.ivanov at gmail.com Wed Feb 28 08:26:49 2007 From: daniil.ivanov at gmail.com (Daniil Ivanov) Date: Wed, 28 Feb 2007 10:26:49 +0200 Subject: rpms/kazehakase/FC-6 kazehakase.spec,1.4,1.5 In-Reply-To: <200702271747.l1RHlS0L030153@cvs-int.fedora.redhat.com> References: <200702271747.l1RHlS0L030153@cvs-int.fedora.redhat.com> Message-ID: On 27/02/07, mtasaka Mamoru Tasaka wrote: > Author: mtasaka > > --- kazehakase.spec 23 Feb 2007 13:35:59 -0000 1.4 > +++ kazehakase.spec 27 Feb 2007 17:46:55 -0000 1.5 > @@ -1,16 +1,18 @@ > %if 0%{?fedora} == 7 > -%define FFver 2.0.0.1 > +%define FFver 2.0.0.2 > %endif > %if 0%{?fedora} == 6 > -%define FFver 1.5.0.9 > +%define FFver 1.5.0.10 > %endif > %if 0%{?fedora} == 5 > -%define SMver 1.0.7 > +%define SMver 1.0.8 > %endif > This tie of kazehakase version to firefox version and Fedora distribution really hurts. Thanks, Daniil. From mtasaka at ioa.s.u-tokyo.ac.jp Wed Feb 28 08:50:52 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 28 Feb 2007 17:50:52 +0900 Subject: rpms/kazehakase/FC-6 kazehakase.spec,1.4,1.5 In-Reply-To: References: <200702271747.l1RHlS0L030153@cvs-int.fedora.redhat.com> Message-ID: <45E5426C.703@ioa.s.u-tokyo.ac.jp> Daniil Ivanov wrote: > On 27/02/07, mtasaka Mamoru Tasaka > wrote: >> Author: mtasaka >> >> --- kazehakase.spec 23 Feb 2007 13:35:59 -0000 1.4 >> +++ kazehakase.spec 27 Feb 2007 17:46:55 -0000 1.5 >> @@ -1,16 +1,18 @@ >> %if 0%{?fedora} == 7 >> -%define FFver 2.0.0.1 >> +%define FFver 2.0.0.2 >> %endif >> %if 0%{?fedora} == 6 >> -%define FFver 1.5.0.9 >> +%define FFver 1.5.0.10 >> %endif >> %if 0%{?fedora} == 5 >> -%define SMver 1.0.7 >> +%define SMver 1.0.8 >> %endif >> > > This tie of kazehakase version to firefox version and Fedora > distribution really hurts. > > Thanks, Daniil. > Please explain verbosely (in bugzilla report), thanks. Mamoru From limb at jcomserv.net Wed Feb 28 12:31:46 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 28 Feb 2007 06:31:46 -0600 (CST) Subject: AWOL maintainer, packages looking for new owner In-Reply-To: <45E3D4DF.8000308@hhs.nl> References: <45E33187.7000708@hhs.nl> <1172525589.3285.0.camel@laptop.gunduz.org> <45E3D4DF.8000308@hhs.nl> Message-ID: <37444.65.192.24.190.1172665906.squirrel@mail.jcomserv.net> Well, I did call "dibs", and as we all know, that's legally binding. :) To make it up to you, I'll try to bump to the current version ASAP. > > > Devrim GUNDUZ wrote: >> Hi, >> >> On Mon, 2007-02-26 at 20:14 +0100, Hans de Goede wrote: >>> xmoto >> >> I can take this one, if noone beats me. >> >> /me loves playing xmoto. >> > > I'm afraid that Jon Ciesla has already beaten you to it. Feel free to > take one of the others though :) > > Regards, > > Hans > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From j.w.r.degoede at hhs.nl Wed Feb 28 13:42:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 28 Feb 2007 14:42:06 +0100 Subject: Anyone interested in pickung up netpanzer Message-ID: <45E586AE.6020802@hhs.nl> Hi all, Sadly Hugo Cisneiros has left us (AWOL) thus netpanzer currently is looking for a new loving maintainers. As this is a popular game it would be a shame to let it get orphaned, So any takers? Notice that pengupop also is still looking for a loving maintainer. Regards, Hans From limb at jcomserv.net Wed Feb 28 13:32:16 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 28 Feb 2007 07:32:16 -0600 (CST) Subject: Anyone interested in pickung up netpanzer In-Reply-To: <45E586AE.6020802@hhs.nl> References: <45E586AE.6020802@hhs.nl> Message-ID: <40743.65.192.24.190.1172669536.squirrel@mail.jcomserv.net> I can take both. I just wanted to give others a chance. :) > Hi all, > > Sadly Hugo Cisneiros has left us (AWOL) thus netpanzer currently is > looking for a new loving maintainers. As this is a popular game it would > be a shame to let it get orphaned, > > So any takers? > > Notice that pengupop also is still looking for a loving maintainer. > > Regards, > > Hans > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- novus ordo absurdum From lxtnow at gmail.com Wed Feb 28 14:03:07 2007 From: lxtnow at gmail.com (SmootherFrOgZ) Date: Wed, 28 Feb 2007 10:03:07 -0400 Subject: Anyone interested in pickung up netpanzer In-Reply-To: <40743.65.192.24.190.1172669536.squirrel@mail.jcomserv.net> References: <45E586AE.6020802@hhs.nl> <40743.65.192.24.190.1172669536.squirrel@mail.jcomserv.net> Message-ID: <62bc09df0702280603g4d48dcc4g97e5126dcbd417f@mail.gmail.com> 2007/2/28, Jon Ciesla : > > I can take both. I just wanted to give others a chance. :) > > > Hi all, > > > > Sadly Hugo Cisneiros has left us (AWOL) thus netpanzer currently is > > looking for a new loving maintainers. As this is a popular game it would > > be a shame to let it get orphaned, > > > > So any takers? > > > > Notice that pengupop also is still looking for a loving maintainer. > > you give me one... :P ? > Regards, > > > > Hans > > > > -- > > fedora-extras-list mailing list > > fedora-extras-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-extras-list > > > > > -- > novus ordo absurdum > > -- > fedora-extras-list mailing list > fedora-extras-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-extras-list > -- Xavier.t Lamien -- GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From limb at jcomserv.net Wed Feb 28 14:08:12 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 28 Feb 2007 08:08:12 -0600 (CST) Subject: Anyone interested in pickung up netpanzer In-Reply-To: <62bc09df0702280603g4d48dcc4g97e5126dcbd417f@mail.gmail.com> References: <45E586AE.6020802@hhs.nl> <40743.65.192.24.190.1172669536.squirrel@mail.jcomserv.net> <62bc09df0702280603g4d48dcc4g97e5126dcbd417f@mail.gmail.com> Message-ID: <45139.65.192.24.190.1172671692.squirrel@mail.jcomserv.net> Which would you like? I've already submitted the cvs flag request, but I can do another. > 2007/2/28, Jon Ciesla : >> >> I can take both. I just wanted to give others a chance. :) >> >> > Hi all, >> > >> > Sadly Hugo Cisneiros has left us (AWOL) thus netpanzer currently is >> > looking for a new loving maintainers. As this is a popular game it >> would >> > be a shame to let it get orphaned, >> > >> > So any takers? >> > >> > Notice that pengupop also is still looking for a loving maintainer. >> > > > > you give me one... :P ? > >> Regards, >> > >> > Hans >> > >> > -- >> > fedora-extras-list mailing list >> > fedora-extras-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-extras-list >> > >> >> >> -- >> novus ordo absurdum >> >> -- >> fedora-extras-list mailing list >> fedora-extras-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-extras-list >> > > > > -- > Xavier.t Lamien > -- > GPG-Key ID: F3903DEB > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > -- novus ordo absurdum From buc at odusz.so-cdu.ru Wed Feb 28 15:48:25 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 28 Feb 2007 18:48:25 +0300 Subject: xawtv: legal question Message-ID: <45E5A449.3030903@odu.neva.ru> Hans de Goede wrote: > Dmitry Butskoy wrote: > > > I'm going to package "xawtv" > > > (A TV application for v4l compliant devices, was in Fedora until > FC2, http://linux.bytesex.org/xawtv ) > > Xawtv can record TV into raw or avi file, including formats: > > > raw - single file, raw video data > video formats: > rgb 24 bit TrueColor (BE: rgb) [raw] > gray 8 bit StaticGray [raw] > 422 16 bit YUV 4:2:2 (packed, YUYV) [raw] > 422p 16 bit YUV 4:2:2 (planar) [raw] > 4mpeg yuv4mpeg (mpeg2enc >= 1.6) [yuv] > 4mpeg-o yuv4mpeg (old mpeg2enc) [yuv] > audio formats: > mono8 8bit mono [wav] > mono16 16bit mono (LE) [wav] > stereo 16bit stereo (LE) [wav] > > avi - Microsoft AVI (RIFF) format > video formats: > rgb15 15 bit TrueColor (LE) [avi] > rgb24 24 bit TrueColor (LE: bgr) [avi] > mjpeg MJPEG (AVI) [avi] > jpeg JPEG (JFIF) [avi] > audio formats: > mono8 8bit mono [avi] > mono16 16bit mono (LE) [avi] > stereo 16bit stereo (LE) [avi] > > > It seems that "yuv4mpeg" is some kind of raw formats, but what > about "mjpeg" (motion jpeg) in avi files? I've found that only > ffmpeg-based plugins can play it then... > > the 2 4mpeg formats definetely are a patent problem, Note, that "yuv4mpeg" is not "mpeg" itself, it is "for mpeg" (4mpeg). It is really a sequence of uncompressed YUV 4:2:0 images... IMHO it was designed to "prepare raw stream for mjpegtools". > mjpeg OTOH is fine. Since it is just a sequence of jpeg images? > I don't know what the status as a container format is. avi seems to be OK (already used in Core's dvgrab and Extras' xine-lib ) But to be sure, could anyone confirm these my assumptions? :) ~buc From bugs.michael at gmx.net Wed Feb 28 15:54:00 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 28 Feb 2007 16:54:00 +0100 Subject: rpms/claws-mail-plugins/FC-5 .cvsignore, 1.3, 1.4 claws-mail-plugins.spec, 1.4, 1.5 sources, 1.3, 1.4 In-Reply-To: <200702281320.l1SDKMnU015153@cvs-int.fedora.redhat.com> References: <200702281320.l1SDKMnU015153@cvs-int.fedora.redhat.com> Message-ID: <20070228165400.750f3fc0.bugs.michael@gmx.net> On Wed, 28 Feb 2007 08:20:22 -0500, Andreas Bierfert (awjb) wrote: > Author: awjb > > Update of /cvs/extras/rpms/claws-mail-plugins/FC-5 > %clean > rm -rf $RPM_BUILD_ROOT > @@ -425,11 +445,14 @@ > %doc acpi_notifier-%{acpinotifier}/AUTHORS > %doc acpi_notifier-%{acpinotifier}/README > %{_libdir}/claws-mail/plugins/acpi_notifier* > +%lang(ca) %{_datadir}/locale/ca/LC_MESSAGES/acpi_notifier.mo > %lang(de) %{_datadir}/locale/de/LC_MESSAGES/acpi_notifier.mo > %lang(es) %{_datadir}/locale/es/LC_MESSAGES/acpi_notifier.mo > %lang(fi) %{_datadir}/locale/fi/LC_MESSAGES/acpi_notifier.mo > %lang(fr) %{_datadir}/locale/fr/LC_MESSAGES/acpi_notifier.mo > +%lang(hu) %{_datadir}/locale/hu/LC_MESSAGES/acpi_notifier.mo > %lang(it) %{_datadir}/locale/it/LC_MESSAGES/acpi_notifier.mo > +%lang(pl) %{_datadir}/locale/pl/LC_MESSAGES/acpi_notifier.mo > %lang(pt_BR) %{_datadir}/locale/pt_BR/LC_MESSAGES/acpi_notifier.mo > %lang(sk) %{_datadir}/locale/sk/LC_MESSAGES/acpi_notifier.mo > %lang(sr) %{_datadir}/locale/sr/LC_MESSAGES/acpi_notifier.mo Does %find_lang acpi_notifier not work? (similar question about the other pkgs)