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 : > 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" 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 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) libvirt-qpid-0.2.18-1.fc14.x86_64
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 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 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) fusecompress-2.6-6.
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 "OSE"s 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=437670&action=diff https://bugzilla.redhat.com/attachment.cgi?id=437670&action=edit Description: RUV (nsuniqueid=---,) needs to be allowed to add to the DB before 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, 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 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 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 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
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: Non-responsive maintainer: Deji Akingunola
Hello Deji, On Mon, 09 Aug 2010, Deji Akingunola wrote: > 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. thank you very much for your reply. In fact, I sent you an e-mail - and I'm really sorry for starting AWOL policy, if my e-mail wasn't received by you. > I will get to the bug when I have the time. Thanks. If you should need a co-maintainer for CLucene, just let me know. Greetings, Robert pgpvUwMGRLn0m.pgp Description: PGP signature -- 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 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 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 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
Re: feature freeze?
On Tue, Aug 10, 2010 at 3:38 AM, Kevin Kofler wrote: > 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. > --- They used to have a proprietary edition and demanded copyright control but now they have moved to a model of proprietary plugins without copyright control. Ideally, we will get everything as Free software but this is a significant improvement over what was before. I don't think syslog-ng even without the proprietary plugins is crippleware. It is quite useful on its own but ultimately this debate is obsolete now that all mainstream distributions led by Fedora have picked up rsyslog as default. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Evolution - bits missing?
Hi, Post the disaster on my hard drive, I've restarted evolution, but have found that the menu bar (File, Edit, etc) at the top has vanished. Is this a known problem and if it isn't, is there a way to get it back there? TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org
On Tue, Aug 10, 2010 at 8:16 AM, Jon Stanley wrote: > . > > 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. > Would be useful to have a trac or bugzilla component to report bugs to. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
