Re: root-doc subpackage slightly obese
Chen Lei wrote: How about qt-doc? Currently, it bundles src/qch/html docs, the src image files are completely useless and duplicate with files in html directory. The content of the qch and html docs is identical, since assistant_adp is dropped by qt 4.7, I suggest to split html docs into another subpackage or simply drop html docs. Personally, I only use assistant to open qch format docs. Yes, qt-doc should be split per format. Dropping the HTML docs entirely (in favor of the QCH) is also something I'd consider (for all Qt-based libraries). IMHO, showing those docs is what Qt Assistant is for. We'll discuss this in the meeting. (That said, assistant_adp is NOT dropped in Fedora, we ship a qt-assistant- adp compatibility package because some apps need it. But viewing Qt docs in the compatibility Assistant isn't of much use.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package Review Stats for last week ending 8th Aug
Top two FAS account holders who have completed reviewing Package review components on bugzilla for last week ending 8th August were Stanislav Ochotnicky and Mamoru Tasaka. Stanislav Ochotnicky : 5 https://bugzilla.redhat.com/show_bug.cgi?id=615869 felix-shell https://bugzilla.redhat.com/show_bug.cgi?id=616250 geronimo-ejb https://bugzilla.redhat.com/show_bug.cgi?id=617942 geronimo-saaj https://bugzilla.redhat.com/show_bug.cgi?id=617943 geronimo-jaxrpc https://bugzilla.redhat.com/show_bug.cgi?id=612998 PyPAM Mamoru Tasaka : 3 https://bugzilla.redhat.com/show_bug.cgi?id=619257 rubygem-stomp https://bugzilla.redhat.com/show_bug.cgi?id=621242 gyp https://bugzilla.redhat.com/show_bug.cgi?id=619383 gsettings-desktop-schemas Adam Miller : 2 https://bugzilla.redhat.com/show_bug.cgi?id=619518 aajohan-comfortaa-fonts https://bugzilla.redhat.com/show_bug.cgi?id=583531 mozilla-firetray Marcela Mašláňová : 2 https://bugzilla.redhat.com/show_bug.cgi?id=619332 perl-MooseX-Types-VariantTable https://bugzilla.redhat.com/show_bug.cgi?id=620875 wmfrog Miroslav Suchý : 2 https://bugzilla.redhat.com/show_bug.cgi?id=620826 python-icalendar https://bugzilla.redhat.com/show_bug.cgi?id=621194 python-webdav-library Peter Robinson : 2 https://bugzilla.redhat.com/show_bug.cgi?id=467324 mingw32-portablexdr https://bugzilla.redhat.com/show_bug.cgi?id=608069 tango Radek Novacek : 2 https://bugzilla.redhat.com/show_bug.cgi?id=619012 cagibi https://bugzilla.redhat.com/show_bug.cgi?id=620432 laughlin-kde-theme Manuel Wolfshant : 2 https://bugzilla.redhat.com/show_bug.cgi?id=620042 dvdbackup https://bugzilla.redhat.com/show_bug.cgi?id=620166 python-Chaco MERCIER Jonathan : 1 https://bugzilla.redhat.com/show_bug.cgi?id=610794 meego-panel-zones Darryl L. Pierce : 1 https://bugzilla.redhat.com/show_bug.cgi?id=620738 snoopy David Woodhouse : 1 https://bugzilla.redhat.com/show_bug.cgi?id=620752 update-ca-certificates Hicham Haouari : 1 https://bugzilla.redhat.com/show_bug.cgi?id=619462 tyrion Iain Arnell : 1 https://bugzilla.redhat.com/show_bug.cgi?id=620794 perl-PPIx-Utilities Lubomir Rintel : 1 https://bugzilla.redhat.com/show_bug.cgi?id=620168 tigase-utils Martin Gieseking : 1 https://bugzilla.redhat.com/show_bug.cgi?id=566405 nmbscan Howard Ning : 1 https://bugzilla.redhat.com/show_bug.cgi?id=618137 python-TraitsBackendWX Michal Schmidt : 1 https://bugzilla.redhat.com/show_bug.cgi?id=618985 swift Mark Rader : 1 https://bugzilla.redhat.com/show_bug.cgi?id=619831 ltl2ba Parag AN(पराग) : 1 https://bugzilla.redhat.com/show_bug.cgi?id=603245 python-zmq Petr Pisar : 1 https://bugzilla.redhat.com/show_bug.cgi?id=621037 perl-MooseX-MultiMethods Randall Randy Berry : 1 https://bugzilla.redhat.com/show_bug.cgi?id=616177 eazykeyboard Robert Spanton : 1 https://bugzilla.redhat.com/show_bug.cgi?id=610980 mspdebug Ankur Sinha : 1 https://bugzilla.redhat.com/show_bug.cgi?id=612719 recoll Sebastian Dziallas : 1 https://bugzilla.redhat.com/show_bug.cgi?id=620260 mutter-meego Silas Sewell : 1 https://bugzilla.redhat.com/show_bug.cgi?id=609169 chatzilla Steve Traylen : 1 https://bugzilla.redhat.com/show_bug.cgi?id=620862 python-newt_syrup Chen Lei : 1 https://bugzilla.redhat.com/show_bug.cgi?id=607015 python-hcs_utils Tom spot Callaway : 1 https://bugzilla.redhat.com/show_bug.cgi?id=618451 gdb-heap Total reviews modified: 40 Merge Reviews: 0 Review Requests: 40 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some questions about on Fedora
2010/8/8 Remi Collet fed...@famillecollet.com: Le 08/08/2010 10:28, Chen Lei a écrit : I can help to review mysql-connector-c and Silvercity, howerver we may need a approve from FESCo for bundling scintilla in silvercity. I don't plan to package silvercity, but rather keep both (scintilla + silvercity) bundled in MW. + It seems silvercity is packaged in many distributions, e.g. gentoo freebsd mandriva PLD. Is the bundled silvercity heavily changed? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Richard W.M. Jones rjo...@redhat.com writes: I didn't know git could do this, but it sounds useful for other (non-fedpkg) things. Can you explain how, or where to start looking? Look for git-new-workdir, it is in the contrib directory of the git sources. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
Adam Williamson awill...@redhat.com writes: PA uses a more correct but more CPU-intensive resampling method than ALSA by default. On very slow systems it's a good idea to edit /etc/pulse/daemon.conf and change the 'resample-method' parameter. Back when I had a slow enough machine to care (A Sempron 2600+ I believe, about a year ago), it was not the resampling which caused performance problems. Changing resample-method did not appreciably change CPU usage. On even slightly faster systems the CPU usage is very low and then resample-method does make a difference -- but why pick something worse when pulseaudio is already in the low single digits? The Sempron machine is dead now and I do not have anything else slow enough anymore. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100809 changes
Compose started at Mon Aug 9 08:15:09 UTC 2010 Broken deps for x86_64 -- Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6 Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) QuantLib-test-1.0.1-3.fc14.x86_64 requires libboost_unit_test_framework.so.1.41.0()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) clusterssh-3.28-1.fc15.noarch requires xorg-x11-fonts\* cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires libpython2.6.so.1.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) gnomeradio-1.8-6.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 1:libguestfs-1.5.2-4.fc14.x86_64 requires /lib64/libxtables.so.4 libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) libopenvrml-gl-0.18.6-1.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit)
Re: git branch help?
On Sat, Aug 07, 2010 at 04:49:50PM +0100, Richard W.M. Jones wrote: On Tue, Aug 03, 2010 at 12:39:02AM -0700, Matt McCutchen wrote: On Tue, 2010-08-03 at 09:12 +0200, Kevin Kofler wrote: But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( It looks like the current implementation of fedpkg clone -B creates independent repositories that don't share anything except the initially downloaded pack. Changing to multiple working directories hanging off a single repository would solve the problems you mentioned. Someone could file a RFE. I didn't know git could do this, but it sounds useful for other (non-fedpkg) things. Can you explain how, or where to start looking? man git clone, option --shared ? Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On 08/05/2010 10:13 AM, Stanislav Ochotnicky wrote: Excerpts from Chen Lei's message of Thu Aug 05 09:10:25 +0200 2010: It seems a lot of java packages will be orphaned, should we contact JAVA-SIG and maven2/eclipse/intellij-idea maintainers? Unfortunately there is no JAVA-SIG though I was thinking about starting one. There has been some effort ~2 years ago but AFAIK it didn't go anywhere. See http://www.spinics.net/linux/fedora/fedora-devel-java/msg02546.html Ja sem pro, stejne jako PERL SIG I'll be unavailable for two weeks now, but after I get back I plan to look into it more seriously... But for now I am at least letting fedora-java ML know about this (in a few minutes) Oh and taking these (most have co-maintainers, but more would be REALLY REALLY welcome): Unblocked orphan checkstyle Unblocked orphan junit Unblocked orphan maven-doxia Unblocked orphan maven-jxr Unblocked orphan maven-surefire Unblocked orphan velocity -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer: Deji Akingunola
On Sun, Aug 8, 2010 at 3:39 PM, Robert Scheck rob...@fedoraproject.org wrote: Hi, as per non-responsive maintainer policy at https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I have filed: https://bugzilla.redhat.com/show_bug.cgi?id=600992 Does somebody know how to contact Deji Akingunola? I've been unsuccessful via e-mail and Red Hat Bugzilla so far. And it seems he isn't around in the IRC. While the truth is you never contacted me by email, and you went ahead threatening me with AWOL policy and orphaning all my packages just 2 weeks after filing a bug for package upgrade on EPEL 4. I will get to the bug when I have the time. And it seems he isn't around in the IRC. I don't use IRC. Deji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedpkg local redefines %fedora macro
Hello,
while working on `nas' package I found `fedpkg local' redefines
`fedora' macro to value `1'. Dist-cvs `make local' does not do that.
Original source for %fedora is /etc/rpm/macros.dist. See the strace:
$ strace -fqv -eexecve fedpkg local
[...]
execve(/bin/rpm, [rpm, --define, _sourcedir
/home/petr/fedora/nas, --define, _specdir /home/petr/fedora/nas,
--define, _builddir /home/petr/fedora/nas, --define, _srcrpmdir
/home/petr/fedora/nas, --define, _rpmdir /home/petr/fedora/nas,
--define, dist .fc15, --define, fedora 15, --define, fedora
1, -q, --qf, %{VERSION} , --specfile,
/home/petr/fedora/nas/nas.spec],...)
You can check it with this simple spec file:
%if 0%{?fedora} 8
echo TRUE %{?fedora}
%else
echo FALSE %{?fedora}
%endif
-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel 82Q35 / framebuffer problem
On Fri, 2010-08-06 at 23:12 +0200, Jos Vos wrote: On Fri, Aug 06, 2010 at 04:41:33PM -0400, Adam Jackson wrote: This is almost certainly the root of the problem. We don't try to set up SDVO devices if they're not listed in the VBT, but not having a VBT means nothing's gonna be listed. We'll need the output from: # dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1 Should I attach it to the bug? In what format? Preferably as a series of bytes. (To be clear, the output from that command is the resulting /tmp/rom file, not the 1+0 records in/out message on stdout.) - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100809 changes
Compose started at Mon Aug 9 13:15:17 UTC 2010 Broken deps for x86_64 -- CGAL-3.6.1-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 CGAL-3.6.1-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_regex-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_regex-mt.so.1.41.0()(64bit) Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6 Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) QuantLib-test-1.0.1-3.fc14.x86_64 requires libboost_unit_test_framework.so.1.41.0()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 avogadro-1.0.1-2.fc14.x86_64 requires libboost_python-mt.so.1.41.0()(64bit) avogadro-libs-1.0.1-2.fc14.i686 requires libboost_python-mt.so.1.41.0 avogadro-libs-1.0.1-2.fc14.x86_64 requires libboost_python-mt.so.1.41.0()(64bit) bastet-0.43-7.fc13.x86_64 requires libboost_program_options.so.1.41.0()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) easystroke-0.5.3-1.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires libpython2.6.so.1.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) fuse-encfs-1.5-12.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 fuse-encfs-1.5-12.fc14.i686 requires libboost_serialization-mt.so.1.41.0 fuse-encfs-1.5-12.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fuse-encfs-1.5-12.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit)
Upcoming Fedora 14 Tasks
Start End Name Wed 11-Aug Wed 11-Aug Fedora 14 Alpha Go/No-Go Meeting (17:00 EST) Thu 12-Aug Thu 12-Aug Fedora 14 Alpha Release Readiness Meeting Thu 12-Aug Thu 12-Aug Start Stage Sync Alpha to Mirrors Thu 12-Aug Tue 17-Aug Stage Sync Alpha to Mirrors Fri 13-Aug Fri 13-Aug Alpha Export Control Reporting Tue 17-Aug Tue 17-Aug Alpha Public Availability Wed 18-Aug Fri 20-Aug Build F-14 collection packages for all language translators Thu 19-Aug Thu 19-Aug File All Release Engineering Tickets for Fedora 14 Beta Fri 20-Aug Fri 20-Aug Beta Blocker Meeting (f14beta) #1 Fri 20-Aug Fri 20-Aug Compose of image of Software Review UI for Translation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
Petr Pisar (ppi...@redhat.com) said: I suggest that these be just built without NAS support. NAS is basically an older competitor to PulseAudio with fewer features (it focuses on network transparency, which is just one of the things PulseAudio does), it is not compatible with PulseAudio, few to no people use it. I agree NAS is very old audio system, but it has history. It works (or should work) across operating systems (do not think only about Linux). In addition it supports bidirectional sound transmission (from microphone). PulseAudio is interresting project, but it's absolutely unusable on old slow hardware. Last time I checked it out on Pentium TSC (no MMX) running at 200 MHz, it consumed 20 % of CPU just in idle mode. While `playing', it congested CPU, printed some warnings about stream buffer overflow and terminated gracefully complaining about no CPU cycles. NAS or Esound work on the machine fluently. Given that that's not the hardware target we're looking at in Fedora, perhaps some effort could be spent in determining where the performance issues lie in PA in an effort to fix the experience for everyone, rather than maintaining parallel implementations that provide little benefit to the userbase as a whole? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: feature freeze?
Hello, On 08/06/2010 01:42 AM, Kevin Kofler wrote: Peter Czanik wrote: While I guess, it's too late now to make a switch now, here is some good news: http://bazsi.blogs.balabit.com/2010/07/syslog-ng-contributions- redefined.html Dual licensing will be gone with the upcoming syslog-ng v3.2. Nothing has really changed for practical purposes. There's still a non-Free Premium Edition with added features and a crippleware Open Source Edition. The only thing which has changed is the way the non-Free features are delivered (as plugins instead of relicensing the whole thing). This doesn't resolve the complaint that upstream will be unwilling to add features which are specific to the non-Free edition. Crippleware OSEs suck. Fedora should not encourage this practice. OSE is nothing near to being a crippleware. Most features arrive simultaneously to OSE and PE (like support for the new syslog spec, etc.) or appear in PE first and then migrated quickly to OSE (like SSL and database support). Automatic testing of PE also helped to fix more bugs in OSE than the community ever did. So the time and energy spent on PE automagically helps to improve the OSE too. A more detailed blog entry about the OSE vs. PE question is available at http://bazsi.blogs.balabit.com/2010/08/lwn-syslog-ng-rotten-to-open-core.html And for those, who are more interested in technical details than licensing, here is a list of what's new in syslog-ng OSE v3.2 alpha2: http://bazsi.blogs.balabit.com/2010/08/lwn-syslog-ng-rotten-to-open-core.html Bye, CzP / from syslog-ng upstream... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 621928] Unable to enable replica (rdn problem?) on 1.2.6 rc6
https://bugzilla.redhat.com/show_bug.cgi?id=621928 https://bugzilla.redhat.com/attachment.cgi?id=437670action=diff https://bugzilla.redhat.com/attachment.cgi?id=437670action=edit Description: RUV (nsuniqueid=---,suffix) needs to be allowed to add to the DB beforesuffix is added. To allow it, entryrdn prepares the rdn exception list (rdn_exceptions). If the to-be-added entry (in this case RUV; and currently only RUV is in the list) is in the list,suffix is added to the entryrdn index with the temporary entry ID 0 (note: not to the primary db file id2entry.db#). When the suffix is indeed added to the DB, the temporary ID 0 is replaced with the given real ID. Thanks, --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Mon, Aug 9, 2010 at 5:43 PM, Bill Nottingham nott...@redhat.com wrote: Petr Pisar (ppi...@redhat.com) said: I suggest that these be just built without NAS support. NAS is basically an older competitor to PulseAudio with fewer features (it focuses on network transparency, which is just one of the things PulseAudio does), it is not compatible with PulseAudio, few to no people use it. I agree NAS is very old audio system, but it has history. It works (or should work) across operating systems (do not think only about Linux). In addition it supports bidirectional sound transmission (from microphone). PulseAudio is interresting project, but it's absolutely unusable on old slow hardware. Last time I checked it out on Pentium TSC (no MMX) running at 200 MHz, it consumed 20 % of CPU just in idle mode. While `playing', it congested CPU, printed some warnings about stream buffer overflow and terminated gracefully complaining about no CPU cycles. NAS or Esound work on the machine fluently. Given that that's not the hardware target we're looking at in Fedora, perhaps some effort could be spent in determining where the performance issues lie in PA in an effort to fix the experience for everyone, rather than maintaining parallel implementations that provide little benefit to the userbase as a whole? While the XO-1 is a comparitatively relative higher HW spec (433 mhz from memory, so not massive but still double) it might be a worthwhile canditdate as there's quite a few of them around the community for testing, its not overly powerful and sees similar issues as well. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Fri, 2010-08-06 at 11:21 +0100, pbrobin...@gmail.com wrote: On Fri, Aug 6, 2010 at 2:04 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2010-08-05 at 10:46 +, Petr Pisar wrote: PulseAudio is interresting project, but it's absolutely unusable on old slow hardware. Last time I checked it out on Pentium TSC (no MMX) running at 200 MHz, it consumed 20 % of CPU just in idle mode. While `playing', it congested CPU, printed some warnings about stream buffer overflow and terminated gracefully complaining about no CPU cycles. NAS or Esound work on the machine fluently. PA uses a more correct but more CPU-intensive resampling method than ALSA by default. On very slow systems it's a good idea to edit /etc/pulse/daemon.conf and change the 'resample-method' parameter. Is there a recommended value for slow machines or a way to tell PA just to use the HW? Depends how slow is slow :). As Paul said, 'trivial' is the cheapest method (but this will *definitely* lead to quite obvious audible artifacts in certain cases; if you're lucky, you may happen never to play any affected audio). On my Vaio P, which has a very slow Atom CPU, I use speex-float-0 , which doesn't seem to cause any audible problems for me and gets the CPU usage down enough that playing back high def video doesn't max it out. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedpkg cannot talk to koji
I'm getting: $ fedpkg -v build Creating module object from /export/home/orion/fedora/cmake/f13 Initiating a koji session to http://koji.fedoraproject.org/kojihub Could not log into koji: Opening a SSL connection failed fedora-packager-0.5.1.0-1.fc13.noarch I've re-run fedora-packager-setup a couple times. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Sun, 2010-08-08 at 11:34 -0700, Matt McCutchen wrote: On Fri, 2010-08-06 at 11:29 -0500, Steve Bonneville wrote: i.g...@comcast.net wrote: Ideally (from this perspective), the host would validate the response itself. Exactly, if sshd is sufficiently paranoid it should make a query with CD set in the request and do all the validation client-side. If you let your nameserver do the validation, I think it's still possible to MITM this by messing with the communication between the stub resolver and the name server, which isn't secured. Not to mention that one has to trust one's own nameserver, which is a bad idea when using a public wireless access point. In order to achieve I believe that can be simplified to 'using a public wireless access point is a bad idea' =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer: Deji Akingunola
Am Montag, den 09.08.2010, 09:46 -0400 schrieb Deji Akingunola: While the truth is you never contacted me by email, and you went ahead threatening me with AWOL policy and orphaning all my packages just 2 weeks after filing a bug for package upgrade on EPEL 4. The truth is that the bug 600992 was opened June 6th, this is way more than 2 weeks. 2 weeks is just the normal time span from one step of the AWOL policy to the next. I will get to the bug when I have the time. Nobody says that you need to update the package within 2 weeks, but you should at least respond to the bug as you have been doing now. Writing a sentence like this one isn't that hard, is it? Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg cannot talk to koji
On 08/09/2010 01:07 PM, Orion Poplawski wrote: I'm getting: $ fedpkg -v build Creating module object from /export/home/orion/fedora/cmake/f13 Initiating a koji session to http://koji.fedoraproject.org/kojihub Could not log into koji: Opening a SSL connection failed fedora-packager-0.5.1.0-1.fc13.noarch I've re-run fedora-packager-setup a couple times. Had to delete ~/.fedora.cert and then run fedora-packager-setup. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-08-10)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #topic #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 = New business = #topic #448 Disallow packages whose primary owner is group. https://fedorahosted.org/fesco/ticket/448 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-08-10)
On Mon, Aug 9, 2010 at 4:56 PM, Kevin Fenzi wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #topic #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 Hello, could you provide a more detailed status of the above 2 topics after the next meeting? The following report was from last week and it is not very informative: On Tue, Aug 3, 2010 at 4:35 PM, Kevin Fenzi wrote: === #fedora-meeting: FESCO (2010-08-03) === Meeting started by nirik at 19:30:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08-03-19.30.log.html Meeting summary --- * init process (nirik, 19:30:02) * #351 Create a policy for updates - status report on implementation (nirik, 19:32:10) * #382 Implementing Stable Release Vision (nirik, 19:38:07) There has been a very long debate here in this mailing list, and yet we don't know what is going on. We have seen a lot of confusion during the python-2.7 rebuilds. People were thinking they should submit their rebuilds to the testing repo on F-14 instead of the stable repo, although the stable repo contains a useless version of their package with broken dependencies. Some clarification is needed. Thanks, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg local redefines %fedora macro
That would certainly explain all the problems I've been having getting
python3 packages built with fedpkg local. All of my %if
0%{?fedora} 12 lines would blow up.
On Mon, Aug 9, 2010 at 6:54 AM, Petr Pisar ppi...@redhat.com wrote:
Hello,
while working on `nas' package I found `fedpkg local' redefines
`fedora' macro to value `1'. Dist-cvs `make local' does not do that.
Original source for %fedora is /etc/rpm/macros.dist. See the strace:
$ strace -fqv -eexecve fedpkg local
[...]
execve(/bin/rpm, [rpm, --define, _sourcedir
/home/petr/fedora/nas, --define, _specdir /home/petr/fedora/nas,
--define, _builddir /home/petr/fedora/nas, --define, _srcrpmdir
/home/petr/fedora/nas, --define, _rpmdir /home/petr/fedora/nas,
--define, dist .fc15, --define, fedora 15, --define, fedora
1, -q, --qf, %{VERSION} , --specfile,
/home/petr/fedora/nas/nas.spec],...)
You can check it with this simple spec file:
%if 0%{?fedora} 8
echo TRUE %{?fedora}
%else
echo FALSE %{?fedora}
%endif
-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
ky...@kylev.com
Some people have a way with words, while others... erm... thingy.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg local redefines %fedora macro
On Monday, August 09, 2010 04:27:31 pm Kyle VanderBeek wrote:
That would
certainly explain all the problems I've been having getting
python3
packages built with fedpkg local. All of my %if
0%{?fedora} 12
lines would blow up.
On Mon, Aug 9, 2010 at 6:54 AM, Petr Pisar
ppi...@redhat.com wrote:
Hello,
while working on `nas'
package I found `fedpkg local' redefines
`fedora' macro to value `1'.
Dist-cvs `make local' does not do that.
Original source for %fedora is
/etc/rpm/macros.dist. See the strace:
$ strace -fqv -eexecve fedpkg
local
[...]
execve(/bin/rpm, [rpm, --define, _sourcedir
/home/petr/fedora/nas, --define, _specdir /home/petr/fedora/nas,
--define, _builddir /home/petr/fedora/nas, --define, _srcrpmdir
/home/petr/fedora/nas, --define, _rpmdir /home/petr/fedora/nas,
--define, dist .fc15, --define, fedora 15, --define, fedora
1, -q, --qf, %{VERSION} , --specfile,
/home/petr/fedora/nas/nas.spec],...)
You can check it with this
simple spec file:
%if 0%{?fedora} 8
echo TRUE %{?fedora}
%else
echo FALSE %{?fedora}
%endif
-- Petr
The
latest build in koji does the right thing. I need to push it out as an
update
Dennis
signature.asc
Description: This is a digitally signed message part.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
pbrobin...@gmail.com wrote: While the XO-1 is a comparitatively relative higher HW spec (433 mhz from memory, so not massive but still double) it might be a worthwhile canditdate as there's quite a few of them around the community for testing, its not overly powerful and sees similar issues as well. The N900 also uses PulseAudio (though not on Fedora). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Mon, Aug 9, 2010 at 10:56 PM, Kevin Kofler kevin.kof...@chello.at wrote: pbrobin...@gmail.com wrote: While the XO-1 is a comparitatively relative higher HW spec (433 mhz from memory, so not massive but still double) it might be a worthwhile canditdate as there's quite a few of them around the community for testing, its not overly powerful and sees similar issues as well. The N900 also uses PulseAudio (though not on Fedora). Yes, so it seems. It has a lot of config options set in /etc/pulse/daemon.conf but then it seems we don't. Something that I'll add to my list to look at. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: feature freeze?
Peter Czanik wrote: OSE is nothing near to being a crippleware. Most features arrive simultaneously to OSE and PE (like support for the new syslog spec, etc.) or appear in PE first and then migrated quickly to OSE (like SSL and database support). Automatic testing of PE also helped to fix more bugs in OSE than the community ever did. So the time and energy spent on PE automagically helps to improve the OSE too. I completely understand why you want to defend your project and why you think your way of doing it is different. The thing is, most if not all of the people who do Open Core crippleware try to justify themselves that way. (It's always THEIR project which is alleged to be completely different from all the others.) But the facts speak clear: you (the company you work for) sell a proprietary edition which intentionally has more features than the Free one, ergo the Free one is deliberately crippled. Even if the features eventually show up in the Free edition, that still means people are getting them later than they could. The normal way to develop features in established Free Software projects is to develop them in public, in the development tree (which is also Free Software, obviously), using what is often called the Open Source Development Model. In fact, several people in the Open Source camp defend Open Source / Free Software specifically BECAUSE it allows that kind of development model. Compared to such a model, yours means having to wait much longer for the features, and being clearly pressured into buying the proprietary version, giving up the freedoms that come with Free Software. (As you can see, I'm familiar with both the Free Software and the Open Source view of things. Your approach satisfies neither.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
On 08/02/2010 06:06 PM, Kevin Kofler wrote: Jesse Keating wrote: Here is where you should have done a fedpkg or git push [snip] There is nothing to commit, since all the changes are already committed. The joys of DVCSes. People are NOT used to commit and push being different operations. Git is highly confusing to people who aren't git experts. Somebody has changed master since you last touched it, and you had changes on your local master that are out of sync now. First, you should do: git config --add --global push.default tracking This will make git push only attempt to push to the branch you are tracking. Then you can git push your f13 changes. git checkout master to get back to master and do a git pull --rebase to pull in the latest upstream changes and re-play your unpushed changes on top of it. Then git log to see what has happened, push if necessary. Huh? Can it get any more complicated? Ingoring the tone, I had some of the same thoughts. This is a pretty basic operation, in good old broken CVS it was a single command, there must be an easier way to make git do this, or at least as a script in fedpkg that does this operation. I'm not for going back, the list of basic operations that CVS supported were finite, I would be highly surprised if git couldn't support those operations. We just need the bits to get the non-git fedora users over the hump. bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F14 update pushes
Are updates getting pushed for F14? https://admin.fedoraproject.org/updates/lyx-2.0.0-0.6.alpha5.fc14?_csrf_token=3478f09b5daca6a8e92441cd1f8a07e7aed3a668 was submitted on the 5th. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Mon, 2010-08-09 at 12:11 -0700, Adam Williamson wrote: On Sun, 2010-08-08 at 11:34 -0700, Matt McCutchen wrote: On Fri, 2010-08-06 at 11:29 -0500, Steve Bonneville wrote: i.g...@comcast.net wrote: Ideally (from this perspective), the host would validate the response itself. Exactly, if sshd is sufficiently paranoid it should make a query with CD set in the request and do all the validation client-side. If you let your nameserver do the validation, I think it's still possible to MITM this by messing with the communication between the stub resolver and the name server, which isn't secured. Not to mention that one has to trust one's own nameserver, which is a bad idea when using a public wireless access point. In order to achieve I believe that can be simplified to 'using a public wireless access point is a bad idea' =) No, it just means that everything is untrustworthy until proven otherwise. If you use SSL or equivalent, you're fine. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org
On Thu, Aug 5, 2010 at 12:28 PM, Frank Murphy frankl...@gmail.com wrote: send an email to: ad...@fedoraproject.org Subject: BFO The right people will get back to you. Simply because one of the people that tends BFO is in sysadmin-main (the people who receive ad...@fp.o) does not make it a proper support mechanism. You should use ad...@fp.o for things that are security sensitive that should remain confidential to a small group. The proper place to discuss would be infrastruct...@lists.fedoraproject.org. BFO is essentially BKO, and all of the custom stuff is in the infrastructure git repo, which can be found at git://git.fedorahosted.org/fedora-infrastructure. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 update pushes
On Mon, 2010-08-09 at 19:35 -0600, Orion Poplawski wrote: Are updates getting pushed for F14? https://admin.fedoraproject.org/updates/lyx-2.0.0-0.6.alpha5.fc14?_csrf_token=3478f09b5daca6a8e92441cd1f8a07e7aed3a668 was submitted on the 5th. Not while we're trying to spin the Alpha, no. As usual around pre-release dates, only very important updates (mostly release critical) are being pushed to stable. releng have actually not been pushing to -testing either, although for f13 cycle we let -testing pushes happen unimpeded throughout the cycle and we should probably do the same for f14 - jesse has been away, and those who are doing the pushes at present weren't aware until today that we usually keep the -testing pushes going. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-08-10)
On Mon, 9 Aug 2010 17:12:20 -0400 Orcan Ogetbil oget.fed...@gmail.com wrote: Hello, could you provide a more detailed status of the above 2 topics after the next meeting? The following report was from last week and it is not very informative: ...snip... There has been a very long debate here in this mailing list, and yet we don't know what is going on. Sure. Lets take them one at a time: #topic #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 This is checking on the implementation of: https://fedoraproject.org/wiki/Package_update_acceptance_criteria Much of it's in place, but there are still a few parts lacking. Namely: AutoQA, and the 'other updates' section one week in testing part. Also, there still seems to be some work that needs to happen in bodhi in other parts as well. #topic #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 This is tracking the implementation of the Board's: https://fedoraproject.org/wiki/Stable_release_updates_vision We have been using: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas as an ideas container for work on this. There is also an ongoing discussion on the Board list about changing or clarifying this vision statement: http://lists.fedoraproject.org/pipermail/advisory-board/2010-August/008865.html We have seen a lot of confusion during the python-2.7 rebuilds. People were thinking they should submit their rebuilds to the testing repo on F-14 instead of the stable repo, although the stable repo contains a useless version of their package with broken dependencies. Some clarification is needed. For non critical path, you could currently push them to stable, as the one week in stable thing is not implemented. If they are, they need some karma, but it should be easy to confirm that they fix the broken dep and appear to work normally... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some questions about on Fedora
Le 09/08/2010 09:38, Chen Lei a écrit : It seems silvercity is packaged in many distributions, e.g. gentoo freebsd mandriva PLD. It fact, RPM I found only provide the python library. From the upstream README file : Contributions are welcome for a build system for the standalone library on UNIX and for bindings to other languages. Is the bundled silvercity heavily changed? I can't find which version is used (0.9.6 or 0.9.7). And yes there is some changes, mainly namespace So, I think we could keep the bundled version of this very small library. Any FPC member comment ? + -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 update pushes
On Tue, Aug 10, 2010 at 10:40 AM, Adam Williamson wrote: releng have actually not been pushing to -testing either, although for f13 cycle we let -testing pushes happen unimpeded throughout the cycle and we should probably do the same for f14 - jesse has been away, and those who are doing the pushes at present weren't aware until today that we usually keep the -testing pushes going. More documentation of the process, perhaps via a SOP is needed then. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-ORLite-Migrate] Fix requirement
commit 19a14ae3cc18461c33c036a0747876d8e99c987c
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Aug 9 08:42:21 2010 +0200
Fix requirement
perl-ORLite-Migrate-req.patch fix requirement of File::Spec.
Old problem with RPM can't handle CPAN versions (3.2701 3.28).
perl-ORLite-Migrate-req.patch | 17 +
perl-ORLite-Migrate.spec | 10 +++---
2 files changed, 24 insertions(+), 3 deletions(-)
---
diff --git a/perl-ORLite-Migrate-req.patch b/perl-ORLite-Migrate-req.patch
new file mode 100644
index 000..b6071ef
--- /dev/null
+++ b/perl-ORLite-Migrate-req.patch
@@ -0,0 +1,17 @@
+2009-06-10 Stepan Kasal ska...@redhat.com
+
+Require File::Spec 2.28, rpm is not able to grok the crazy
+perl versioning.
+
+
+--- ORLite-Migrate-0.03/lib/ORLite/Migrate.pm.orig 2009-04-19
14:18:00.0 +0200
ORLite-Migrate-0.03/lib/ORLite/Migrate.pm 2009-06-10 14:38:43.0
+0200
+@@ -5,7 +5,7 @@
+ use 5.006;
+ use strict;
+ use Carp ();
+-use File::Spec 3.2701 ();
++use File::Spec 3.28 ();
+ use File::Path 2.04 ();
+ use File::Basename();
+ use Params::Util 0.37 qw{ _STRING _CLASS _HASH };
diff --git a/perl-ORLite-Migrate.spec b/perl-ORLite-Migrate.spec
index af12779..05f10b4 100644
--- a/perl-ORLite-Migrate.spec
+++ b/perl-ORLite-Migrate.spec
@@ -1,11 +1,12 @@
Name: perl-ORLite-Migrate
Version:1.07
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Light weight SQLite-specific schema migration
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/ORLite-Migrate/
Source0:
http://www.cpan.org/authors/id/A/AD/ADAMK/ORLite-Migrate-%{version}.tar.gz
+Patch0: perl-ORLite-Migrate-req.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
# File::Spec = 3.2701, we have 3.30, rpm can't process 3.2701 3.30
@@ -35,6 +36,7 @@ weight single class Database Schema Migration enhancement for
ORLite.
%prep
%setup -q -n ORLite-Migrate-%{version}
+%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -51,8 +53,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-# this is blocked by old File::Spec in perl core package
-#make test
+make test
%clean
rm -rf $RPM_BUILD_ROOT
@@ -64,6 +65,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Aug 9 2010 Marcela Mašláňová mmasl...@redhat.com - 1.07-2
+- fix requirement of this update
+
* Tue May 04 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-6
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ORLite-Migrate] Rewrite patch.
commit c1ce23938da97ce807d8af0d68c52e12ca61de90
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Aug 9 08:55:41 2010 +0200
Rewrite patch.
perl-ORLite-Migrate-req.patch | 15 +--
perl-ORLite-Migrate.spec |2 +-
2 files changed, 6 insertions(+), 11 deletions(-)
---
diff --git a/perl-ORLite-Migrate-req.patch b/perl-ORLite-Migrate-req.patch
index b6071ef..5aac5e2 100644
--- a/perl-ORLite-Migrate-req.patch
+++ b/perl-ORLite-Migrate-req.patch
@@ -1,12 +1,7 @@
-2009-06-10 Stepan Kasal ska...@redhat.com
-
-Require File::Spec 2.28, rpm is not able to grok the crazy
-perl versioning.
-
-
ORLite-Migrate-0.03/lib/ORLite/Migrate.pm.orig 2009-04-19
14:18:00.0 +0200
-+++ ORLite-Migrate-0.03/lib/ORLite/Migrate.pm 2009-06-10 14:38:43.0
+0200
-@@ -5,7 +5,7 @@
+diff -up ORLite-Migrate-1.07/lib/ORLite/Migrate.pm.orig
ORLite-Migrate-1.07/lib/ORLite/Migrate.pm
+--- ORLite-Migrate-1.07/lib/ORLite/Migrate.pm.orig 2010-03-25
11:25:24.0 +0100
ORLite-Migrate-1.07/lib/ORLite/Migrate.pm 2010-08-09 08:55:25.720819126
+0200
+@@ -5,7 +5,7 @@ package ORLite::Migrate;
use 5.006;
use strict;
use Carp ();
@@ -14,4 +9,4 @@ perl versioning.
+use File::Spec 3.28 ();
use File::Path 2.04 ();
use File::Basename();
- use Params::Util 0.37 qw{ _STRING _CLASS _HASH };
+ use Params::Util 0.37 ();
diff --git a/perl-ORLite-Migrate.spec b/perl-ORLite-Migrate.spec
index 05f10b4..d8168af 100644
--- a/perl-ORLite-Migrate.spec
+++ b/perl-ORLite-Migrate.spec
@@ -36,7 +36,7 @@ weight single class Database Schema Migration enhancement for
ORLite.
%prep
%setup -q -n ORLite-Migrate-%{version}
-%patch0 -p1
+##%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ORLite-Migrate] * Mon Aug 9 2010 Marcela Mašlá�ová mmasl...@redhat.com - 1.07-2 - fix requirement of this upd
commit 211433caa8cb3fcdbbf11fe9a58df97a9c91b596
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Aug 9 09:14:27 2010 +0200
* Mon Aug 9 2010 Marcela Mašláňová mmasl...@redhat.com - 1.07-2
- fix requirement of this update
perl-ORLite-Migrate.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-ORLite-Migrate.spec b/perl-ORLite-Migrate.spec
index d8168af..26bd309 100644
--- a/perl-ORLite-Migrate.spec
+++ b/perl-ORLite-Migrate.spec
@@ -19,6 +19,7 @@ BuildRequires: perl(ORLite) = 1.20
BuildRequires: perl(Params::Util) = 0.37
BuildRequires: perl(Probe::Perl)
BuildRequires: perl(Test::More) = 0.47
+BuildRequires: perl(File::Which)
# The following three requires are not detected automatically:
Requires: perl(File::pushd)
Requires: perl(IPC::Run3)
@@ -36,7 +37,7 @@ weight single class Database Schema Migration enhancement for
ORLite.
%prep
%setup -q -n ORLite-Migrate-%{version}
-##%patch0 -p1
+%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Bio-Graphics] * Mon Aug 9 2010 Marcela Maslanova mmasl...@redhat.com - 2.11-2 - remove file which needs missing
commit 6a623d4ecf7e44455b9eb8633b795473ec3bcf10
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Aug 9 09:28:38 2010 +0200
* Mon Aug 9 2010 Marcela Maslanova mmasl...@redhat.com - 2.11-2
- remove file which needs missing Bio::Graphics
perl-Bio-Graphics.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Bio-Graphics.spec b/perl-Bio-Graphics.spec
index f847467..8653135 100644
--- a/perl-Bio-Graphics.spec
+++ b/perl-Bio-Graphics.spec
@@ -1,6 +1,6 @@
Name: perl-Bio-Graphics
Version:2.11
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Generate GD images of Bio::Seq objects
License:GPL+ or Artistic
Group: Development/Libraries
@@ -30,7 +30,7 @@ laid out on the number line
# temporarily remove modules Bio/Graphics/Glyph/trace.pm until the dependency:
# Bio::SCF is packaged
-#rm lib/Bio/Graphics/Glyph/trace.pm
+rm lib/Bio/Graphics/Glyph/trace.pm
%build
%{__perl} Build.PL installdirs=vendor
@@ -60,6 +60,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Aug 9 2010 Marcela Maslanova mmasl...@redhat.com - 2.11-2
+- remove file which needs missing Bio::Graphics
+
* Fri Aug 6 2010 Marcela Maslanova mmasl...@redhat.com - 2.11-1
- update, tests pass fine
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Bio-Graphics] Switch off tests until Bio::Graphics won't be packaged.
commit d6ec909b28da8f78fa4b147be245f350fd59e851
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Mon Aug 9 09:42:04 2010 +0200
Switch off tests until Bio::Graphics won't be packaged.
perl-Bio-Graphics.spec |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/perl-Bio-Graphics.spec b/perl-Bio-Graphics.spec
index 8653135..a05cec8 100644
--- a/perl-Bio-Graphics.spec
+++ b/perl-Bio-Graphics.spec
@@ -46,7 +46,8 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
-./Build test
+# because of removed file in prep
+#./Build test
%clean
rm -rf $RPM_BUILD_ROOT
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Config-Model
perl-Config-Model has broken dependencies in the rawhide tree: On x86_64: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) = 0:0.303 On i386: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) = 0:0.303 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the rawhide tree: On x86_64: perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Config-Model
perl-Config-Model has broken dependencies in the F-14 tree: On x86_64: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) = 0:0.303 On i386: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) = 0:0.303 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the F-14 tree: On x86_64: perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-14 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: #3940: block perl-Data-Alias in F14 and rawhide
#3940: block perl-Data-Alias in F14 and rawhide --+- Reporter: iarnell | Owner: rel-...@lists.fedoraproject.org Type: task | Status: closed Milestone: | Component: koji Resolution: fixed|Keywords: --+- Changes (by notting): * status: new = closed * resolution: = fixed Comment: Blocked. -- Ticket URL: https://fedorahosted.org/rel-eng/ticket/3940#comment:1 Fedora Release Engineering http://fedorahosted.org/rel-eng Release Engineering for the Fedora Project -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Data-Alias] dead package
commit 44b1dc40c43e67fae62f3546cf78bfe8c45122b7 Author: Iain Arnell iarn...@gmail.com Date: Tue Aug 10 05:05:25 2010 +0200 dead package .gitignore |1 - dead.package |1 + filter-requires.sh |3 - perl-Data-Alias.spec | 124 -- sources |1 - 5 files changed, 1 insertions(+), 129 deletions(-) --- diff --git a/dead.package b/dead.package new file mode 100644 index 000..838bb21 --- /dev/null +++ b/dead.package @@ -0,0 +1 @@ +doesn't work under perl 5.12 - see rhbz #611014 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Data-Alias/f14/master] dead package
Summary of changes: 44b1dc4... dead package (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
