Graphics Test Week this week
Sorry for the short notice everyone, but this week is Graphics Test Week again. It's time to make sure the major graphics drivers are in shape for Fedora 16. Tomorrow, 2011-09-06, is Nouveau Test Day [1]. Wednesday, 2011-09-07, is Radeon Test Day [2]. And Thursday, 2011-09-08, is Intel graphics Test Day [3]. All the events take place in #fedora-test-day on Freenode IRC. As always, the more testing we can get, the better. Fedora graphics developers and QA team members will be on hand to help with testing and debugging. If you've been to a graphics Test Day before it would be great to check in and see if any bugs you hit have been resolved, or if things are still working well. If you've never done one before, please come along and add your hardware to the repertoire! The testing is easy and there are full instructions on the wiki pages. You don't need a Fedora account to do the testing or to file the results, but you will need a Bugzilla account to file bugs. If you can't make the day for your graphics card, don't worry - you can come along on either of the other days too, or do the testing later and add your results to the wiki page. Even filed 'late' they will still be useful! To join in, just visit the page for your graphics card and follow the test instructions, then add your results to the table at the bottom of the page - there are instructions on how to do it. You can join #fedora-test-day to chat with the QA team and the developers. Please come along and help us make sure Fedora 16's graphics experience is second to none! [1] https://fedoraproject.org/wiki/Test_Day:2011-09-06_Nouveau [2] https://fedoraproject.org/wiki/Test_Day:2011-09-07_Radeon [3] https://fedoraproject.org/wiki/Test_Day:2011-09-08_Intel -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Hi, 2011/9/6 Jóhann B. Guðmundsson johan...@gmail.com: On 09/06/2011 02:55 AM, Bill Nottingham wrote: Reindl Harald (h.rei...@thelounge.net) said: the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd is at 0% - why will F16 released WITHOUT making the system clean which should have been done for F15 Perhaps the feature owner should update it, as per the policy. I was planning on updating that 0% after beta ( as opposed to having to go through all the components twice or more and incrementally increase that number for no purpose). Once we have released beta you either have native systemd unit for the component or you wont for the F16 whole release cycle and % number on a wiki page aint gonna change that. Live media + default next next install should be covered except for openvpn and wpa_supplicant. I created a service for wpa_supplicant. Is there something wrong with it? That in it self is an acceptable milestone to have reached in my books in one release cycle as in all hands out media + desktop install have been converted and are covered. Excellent job :) Depending on the rest of the components and their maintainers rest might take sometime on converting for variety of reasons. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
05.09.2011 19:17, TASAKA Mamoru wrote:
(Well, as you posted your first mail to fedora devel list, please
keep sending your reply also to devel list. This type of private
mails will be very confusing to many people who are also watching
mailing
list because they cannot know what is currently discussed.
Would you tell me why you replied to my mail privately, although
I posted to devel list? This time I will mail to you privately, however
unless you have some special reason next
time I will want to post my mail also to devel list so that people can
see current discussion)
Mamoru, thank you very much for the answers. And excuse me - it was
mistake. Now I answer in list.
First:
* php-devel is not installed when trying to package srpm from spec and
sources. This is
what koji (build server) always does. i.e. koji tries to package
srpm first, at that time
only minimum buildroot packages are installed. Then after srpm is
successfully packaged,
koji (yum) installs additional packages specified by BuildRequires.
After that koji will
actually try to build binary rpms from the spec file.
No, in this case it was scratch build, so initially srpm was submitted.
So you must ensure that your srpm can successfully packaged even if
none of packages
in BuildRequires are installed (and only minimum buildroot packages
are installed).
* Then looking at your spec file, there are actually two issues which
prevents srpm
from being properly packaged.
1. The line 63
%if %( php -r 'echo version_compare(PHP_VERSION, 5.3.0, =) ? 1
: 0;' )
cannot be parsed when php is not installed (again, when koji first
tries to package
srpm, BuildRequires rpms are not installed yet). The correct line
would be something
like:
%if %( which php /dev/null php -r 'echo
version_compare(PHP_VERSION, 5.3.0, =) ? 1 : 0'|| echo -n 0 )
However please reconsider if you really want this complicated line.
This line needed and I don't see any problems with it:
which php /dev/null php -r 'echo version_compare(PHP_VERSION,
5.3.0, =) ? 1 : 0'|| echo -n 0
always should return with 0 exit status and produce only 0 or 1 as
result, even if php not installed.
2. The line 28
%if %{?php_zend_api}0
cannot be parsed when %php_zend_api is not integer (and this is
actually happening
currently). The correct line would be something like
%if 0%{?php_zend_api?1:0}
however it seems this line is no longer needed on Fedora:
http://fedoraproject.org/wiki/Packaging:PHP#C_extensions_.28PECL_and_others.29
It stil needed for EPEL
http://fedoraproject.org/wiki/Packaging:EPEL#PHP_ABI_Check_Handling and
exactly in this form
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to debug X lockup (advice from gurus wanted)
On 9/1/11 5:05 PM, Roberto Ragusa wrote: Hmmm, turning off SMP is not realistic, as this laptop has a Core 2 Duo. Sure it is. Boot with maxcpus=1 on the kernel command line. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On 09/06/2011 08:39 AM, Michał Piotrowski wrote: I created a service for wpa_supplicant. Is there something wrong with it? Nope Dan had sanctioned it but then another one appear upstream and as you know we try to avoid deviating from upstream. Not sure if Bill spoke with Dan about this ( I assume he did not since there has not been any movement there ) I know that I haven't. With regards to openvpn maintainer has been busy and openvpn might require some path work. ( If I can recall correctly then Suse guys needed to patch their instance ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110906 changes
Compose started at Tue Sep 6 08:15:03 UTC 2011 Broken deps for x86_64 -- FlightGear-2.0.0-6.fc16.x86_64 requires libosgViewer.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgUtil.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgSim.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgGA.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgFX.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) SimGear-2.0.0-6.fc16.i686 requires libosgParticle.so.74 SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74 SimGear-2.0.0-6.fc16.i686 requires libosg.so.74 SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11 SimGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) caribou-0.3.5-1.fc16.i686 requires libgee.so.2 caribou-0.3.5-1.fc16.x86_64 requires libgee.so.2()(64bit) 1:cheese-3.0.2-2.fc16.x86_64 requires libgee.so.2()(64bit) 1:cheese-libs-3.0.2-2.fc16.i686 requires libgee.so.2 1:cheese-libs-3.0.2-2.fc16.x86_64 requires libgee.so.2()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-0.10.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet dh-make-0.55-3.fc15.noarch requires debhelper ease-0.4-7.fc17.i686 requires libgee.so.2 ease-0.4-7.fc17.x86_64 requires libgee.so.2()(64bit) ease-devel-0.4-7.fc17.i686 requires pkgconfig(gee-1.0) ease-devel-0.4-7.fc17.x86_64 requires pkgconfig(gee-1.0) emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libchamplain-0.10.so.0()(64bit) empathy-3.1.90.1-2.fc17.x86_64 requires libgee.so.2()(64bit) empathy-3.1.90.1-2.fc17.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) empathy-3.1.90.1-2.fc17.x86_64 requires libchamplain-0.10.so.0()(64bit) eog-plugins-3.1.2-2.fc16.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) eog-plugins-3.1.2-2.fc16.x86_64 requires
Re: Orphaning maradns
On 06/09/11 06:31, Michael Fleming wrote: I've released ownership of the aforementioned package, as I've not used it in any meaningful way in some time and don't have the time to maintain it further. Upstream development seems to have picked up of late (was dormant for a long time) so potential future maintainers will have something interesting to hack on :-) Michael. I'm willing to have a go at maintaining it, I have made a few packages on CentOS in the past for internal company use (BIND 9.8) and a font package for Fedora (tlomt-league-gothic) and I think I should be able to do it. Are there any special gotchas or issues that I need to be aware of? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Did gtkhtml2 package disappear?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 policycoreutils has broken dependencies in the rawhide tree: On x86_64: policycoreutils-gui-2.1.5-2.fc17.x86_64 requires gtkhtml2 On i386: policycoreutils-gui-2.1.5-2.fc17.i686 requires gtkhtml2 Please resolve this as soon as possible. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5mIWgACgkQrlYvE4MpobPeZgCeOkXSWrLTU1jivQc798oLB2A8 J/kAn2RBAMbzHwAEyK3p2j0nbArvZ2wJ =MO6J -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Did gtkhtml2 package disappear?
On Tue, 06 Sep 2011 09:34:32 -0400, DJW (Daniel) wrote: policycoreutils has broken dependencies in the rawhide tree: On x86_64: policycoreutils-gui-2.1.5-2.fc17.x86_64 requires gtkhtml2 On i386: policycoreutils-gui-2.1.5-2.fc17.i686 requires gtkhtml2 Please resolve this as soon as possible. It has been retired (after it had been orphaned by mbarnes) in favour of gtkhtml3. http://lists.fedoraproject.org/pipermail/devel/2011-July/154154.html https://admin.fedoraproject.org/pkgdb/acls/name/gtkhtml2 -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc4.git0.0.fc16.x86_64 loadavg: 0.30 0.12 0.07 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Best practices for patch management on RPM based packages?
Most of the packages I work with have very few patches so it's not all that difficult, but there are a couple of packages I'm working with that have a lot of patches and one of them has a very active upstream (which is a good thing!) but that also means that the patches need frequent adjustment. I like the idea of quilt but I can't seem to find the magic recipe to get it to integrate with rpmbuild. Any ideas? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
On 09/06/2011 05:16 PM, Richard Shaw wrote:
Most of the packages I work with have very few patches so it's not all
that difficult, but there are a couple of packages I'm working with
that have a lot of patches and one of them has a very active upstream
(which is a good thing!) but that also means that the patches need
frequent adjustment.
I like the idea of quilt but I can't seem to find the magic recipe to
get it to integrate with rpmbuild.
There's a long-standing RFE to integrate quilt/git/etc into rpmbuild to
ease the patch management, I just never seem to get around to it. There
are things that can make it easier already though, for example:
https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/
Also if you're just tired and bored with having to refer to each patch
twice just to get it applied, the %{patches} macro can help there too as
long as all the patches can be applied with the same flags, you can do
something like this:
%setup
for p in %{patches}; do
patch -p1 ${p} || exit 1
done
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
On Tue, 6 Sep 2011, Richard Shaw wrote: Most of the packages I work with have very few patches so it's not all that difficult, but there are a couple of packages I'm working with that have a lot of patches and one of them has a very active upstream (which is a good thing!) but that also means that the patches need frequent adjustment. I like the idea of quilt but I can't seem to find the magic recipe to get it to integrate with rpmbuild. The best is always to convince upstream to take your patch. Did you talk to them? Why are they not merging in the patches? For some packages I maintain, most of the differences are packaging related, and I try to convince upstream to use a packaging/fedora/ directory, so I can give them the updates to sync. (and I do the same for those packages I am actually upstream for, such as openswan and xl2tpd) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Štěpán Kasal
On Tue, Sep 06, 2011 at 04:26:30PM +0200, Nicola Soranzo wrote: I'm following the procedure at: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Does anyone know how to contact Štěpán Kasal (user kasal)? He is not answering e-mails at his listed address (I've written directly to ka...@ucw.cz on 2011/07/27 regarding bug 700405) or the following Bugzilla reports: Last time I had a contact with Stepan, my understanding is that he didn't seem to want to continue maintaining his package. So orphaning them and proposing them here for maintainance should certainly be the way to go. At least adding co-maintainers would be a first needed step. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/06/2011 07:00 PM +9:00:
05.09.2011 19:17, TASAKA Mamoru wrote:
First:
* php-devel is not installed when trying to package srpm from spec and
sources. This is
what koji (build server) always does. i.e. koji tries to package srpm first,
at that time
only minimum buildroot packages are installed. Then after srpm is
successfully packaged,
koji (yum) installs additional packages specified by BuildRequires. After
that koji will
actually try to build binary rpms from the spec file.
No, in this case it was scratch build, so initially srpm was submitted.
Well, it is still true that at the first time only minimum buildroot packages
are installed, because at this time koji does not know what packages are needed
yet.
So koji first unpacks your srpm and parse your spec to check what packages
are listed in BuildRequires. Again this time no packages
listed in BuildRequires are installed yet. So if parsing your spec file fails
when only buildroot packages are installed, still no BuildRequires packages
are installed, even on scratch build.
So you must ensure that your srpm can successfully packaged even if none of
packages
in BuildRequires are installed (and only minimum buildroot packages are
installed).
* Then looking at your spec file, there are actually two issues which
prevents srpm
from being properly packaged.
1. The line 63
%if %( php -r 'echo version_compare(PHP_VERSION, 5.3.0, =) ? 1 : 0;' )
cannot be parsed when php is not installed (again, when koji first tries to
package
srpm, BuildRequires rpms are not installed yet). The correct line would be
something
like:
%if %( which php /dev/null php -r 'echo version_compare(PHP_VERSION,
5.3.0, =) ? 1 : 0'|| echo -n 0 )
However please reconsider if you really want this complicated line.
This line needed and I don't see any problems with it:
which php /dev/null php -r 'echo version_compare(PHP_VERSION, 5.3.0,
=) ? 1 : 0'|| echo -n 0
always should return with 0 exit status and produce only 0 or 1 as result,
even if php not installed.
2. The line 28
%if %{?php_zend_api}0
cannot be parsed when %php_zend_api is not integer (and this is actually
happening
currently). The correct line would be something like
%if 0%{?php_zend_api?1:0}
however it seems this line is no longer needed on Fedora:
http://fedoraproject.org/wiki/Packaging:PHP#C_extensions_.28PECL_and_others.29
It stil needed for EPEL
http://fedoraproject.org/wiki/Packaging:EPEL#PHP_ABI_Check_Handling and
exactly in this form
Then you have to write this only for EPEL build. Again on F-17 parsing
%if %{?php_zend_api}0 actually failed, because php_zend_api is not integer
(actually %php_zend_api is now 20090626-x86-32 on F-17 i686)
This EPEL form is no longer valid on Fedora (at least on F-17).
However %if 0%{?php_zend_api?1:0} is also wrong and this should be
%if 0%{?php_zend_api:1} if you want to use (guessing php_zend_api
is not defined as 0 even on EPEL)
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to debug X lockup (advice from gurus wanted)
Am 06.09.2011 13:10, schrieb Adam Jackson: On 9/1/11 5:05 PM, Roberto Ragusa wrote: Hmmm, turning off SMP is not realistic, as this laptop has a Core 2 Duo. Sure it is. Boot with maxcpus=1 on the kernel command line i would recommend nosmp because it really disables the kernel-smp code signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
On Tue, 2011-09-06 at 09:16 -0500, Richard Shaw wrote: Most of the packages I work with have very few patches so it's not all that difficult, but there are a couple of packages I'm working with that have a lot of patches and one of them has a very active upstream (which is a good thing!) but that also means that the patches need frequent adjustment. I like the idea of quilt but I can't seem to find the magic recipe to get it to integrate with rpmbuild. If your upstream is using git, there's some boilerplate for automating this with git-am in xorg-x11-server.spec. - 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
Re: Best practices for patch management on RPM based packages?
Thanks for the suggestions so far.
I think quilt works ok with Fedora scm (or RPM Fusion cvs) since
everything lives in one directory. I'm trying to get it to place nice
with rpmbuild because not everything I'm working on is in Fedora or
RPM Fusion.
Also, I like to use rpmbuild as kind of a sandbox for me to try things
out without worrying about messing anything up.
It would be nice to add some sort of configuration option to quilt so
it could query rpm to see where everything is located. I'm currently
using the _topdir relocation so that all the pacakages are separated,
i.e.
~/rpmbuild/%{name}/{BUILD,SPECS, etc..}
I've tried running quilt from the SOURCES directory and pointing to
the spec (../SPEC/%{name}.spec) but it still didn't do anything
useful.
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110906 changes
Compose started at Tue Sep 6 13:15:27 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) airrac-0.1.0-2.fc16.i686 requires libstdair.so.0.36 airrac-0.1.0-2.fc16.i686 requires libstdairuicl.so.0.36 airrac-0.1.0-2.fc16.x86_64 requires libstdairuicl.so.0.36()(64bit) airrac-0.1.0-2.fc16.x86_64 requires libstdair.so.0.36()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libecal-1.2.so.9()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.i686 requires libedataserver-1.2.so.14 1:anerley-0.3.0-1.fc16.i686 requires libebook-1.2.so.11 1:anerley-0.3.0-1.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libebook-1.2.so.11()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libebook-1.2.so.11()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires
howto build for EL5 on F15 in mock?
Hi, I'm trying to build cherokee-1.2.1 for EL5 on my F15 system and I'm getting an error DEBUG util.py:250: cherokee ## DEBUG util.py:250: error: unpacking of archive failed on file /builddir/build/SOURCES/01-drop-privileges.patch;4e664eb5: cpio: MD5 sum mismatch AFAICS I can build this package for F15. I will be grateful for any hint. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto build for EL5 on F15 in mock?
Michał Piotrowski píše v Út 06. 09. 2011 v 19:02 +0200: Hi, I'm trying to build cherokee-1.2.1 for EL5 on my F15 system and I'm getting an error DEBUG util.py:250: cherokee ## DEBUG util.py:250: error: unpacking of archive failed on file /builddir/build/SOURCES/01-drop-privileges.patch;4e664eb5: cpio: MD5 sum mismatch AFAICS I can build this package for F15. I will be grateful for any hint. EPEL = 5 (or better RHEL = 5) need source rpms with md5 checksum, you can produce it with rpmbuild-md5 of fedpkg --dist el5 srpm in fedora branch or fedpkg srpm when in the el5 branch of the git checkout Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto build for EL5 on F15 in mock?
2011/9/6 Michał Piotrowski mkkp...@gmail.com: Hi, I'm trying to build cherokee-1.2.1 for EL5 on my F15 system and I'm getting an error DEBUG util.py:250: cherokee ## DEBUG util.py:250: error: unpacking of archive failed on file /builddir/build/SOURCES/01-drop-privileges.patch;4e664eb5: cpio: MD5 sum mismatch AFAICS I can build this package for F15. I will be grateful for any hint. -- Best regards, Michal http://eventhorizon.pl/ download the sources. fedpkg clone cherokee cd cherokee fedpkg local -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Did gtkhtml2 package disappear?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2011 09:41 AM, Michael Schwendt wrote: On Tue, 06 Sep 2011 09:34:32 -0400, DJW (Daniel) wrote: policycoreutils has broken dependencies in the rawhide tree: On x86_64: policycoreutils-gui-2.1.5-2.fc17.x86_64 requires gtkhtml2 On i386: policycoreutils-gui-2.1.5-2.fc17.i686 requires gtkhtml2 Please resolve this as soon as possible. It has been retired (after it had been orphaned by mbarnes) in favour of gtkhtml3. http://lists.fedoraproject.org/pipermail/devel/2011-July/154154.html https://admin.fedoraproject.org/pkgdb/acls/name/gtkhtml2 I guess what I really need is gnome-python2-gtkhtml2, has this been replaced? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5mUaUACgkQrlYvE4MpobNBoQCdEkX+sLsY14xSiKIjDns1tgEL 1I0AniFaJt3Z7XLcwyUYa/cdO/LDXxw9 =8pY7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Did gtkhtml2 package disappear?
On Tue, 06 Sep 2011 13:00:21 -0400, DJW (Daniel) wrote: I guess what I really need is gnome-python2-gtkhtml2, has this been replaced? What I could find is a request to drop it (it's a gnome-python2-extras subpackage): Disable Python bindings for gtkhtml2 (dead package) https://bugzilla.redhat.com/731307 -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc4.git0.0.fc16.x86_64 loadavg: 0.06 0.08 0.12 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (735114) renaming a managed entry does not update mepmanagedby
https://bugzilla.redhat.com/show_bug.cgi?id=735114 https://bugzilla.redhat.com/attachment.cgi?id=521730action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: howto build for EL5 on F15 in mock?
2011/9/6 Dan Horák d...@danny.cz: Michał Piotrowski píše v Út 06. 09. 2011 v 19:02 +0200: Hi, I'm trying to build cherokee-1.2.1 for EL5 on my F15 system and I'm getting an error DEBUG util.py:250: cherokee ## DEBUG util.py:250: error: unpacking of archive failed on file /builddir/build/SOURCES/01-drop-privileges.patch;4e664eb5: cpio: MD5 sum mismatch AFAICS I can build this package for F15. I will be grateful for any hint. EPEL = 5 (or better RHEL = 5) need source rpms with md5 checksum, you can produce it with rpmbuild-md5 of fedpkg --dist el5 srpm Thank you very much, this command solves problem. in fedora branch or fedpkg srpm when in the el5 branch of the git checkout Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: howto build for EL5 on F15 in mock?
2011/9/6 Itamar Reis Peixoto ita...@ispbrasil.com.br: 2011/9/6 Michał Piotrowski mkkp...@gmail.com: Hi, I'm trying to build cherokee-1.2.1 for EL5 on my F15 system and I'm getting an error DEBUG util.py:250: cherokee ## DEBUG util.py:250: error: unpacking of archive failed on file /builddir/build/SOURCES/01-drop-privileges.patch;4e664eb5: cpio: MD5 sum mismatch AFAICS I can build this package for F15. I will be grateful for any hint. -- Best regards, Michal http://eventhorizon.pl/ download the sources. fedpkg clone cherokee cd cherokee fedpkg local I cloned this tree git://pkgs.fedoraproject.org/cherokee.git with git, I guess that fedpkg clone cherokee does the same. Thanks! -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
Dne 6.9.2011 16:29, Panu Matilainen napsal(a): I like the idea of quilt but I can't seem to find the magic recipe to get it to integrate with rpmbuild. What's wrong with quilt setup specname.spec ? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Package-Stash-XS-0.25.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Package-Stash-XS: 52ece18842c46da8fb7a4a14dea910ab Package-Stash-XS-0.25.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Best practices for patch management on RPM based packages?
On 09/06/2011 09:53 PM, Matej Cepl wrote: Dne 6.9.2011 16:29, Panu Matilainen napsal(a): I like the idea of quilt but I can't seem to find the magic recipe to get it to integrate with rpmbuild. Please mind your quotes, I didn't write the above. What's wrong with quilt setup specname.spec Frankly, I don't know. My knowledge of quilt stops at it has to do with patches. This would seem to be the other way around wrt what I have in mind (have rpmbuild setup a temporary git/quilt/whatever repository inside the build directory, such as in the git example I mentioned), but dunno. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Did gtkhtml2 package disappear?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2011 01:49 PM, Michael Schwendt wrote: On Tue, 06 Sep 2011 13:00:21 -0400, DJW (Daniel) wrote: I guess what I really need is gnome-python2-gtkhtml2, has this been replaced? What I could find is a request to drop it (it's a gnome-python2-extras subpackage): Disable Python bindings for gtkhtml2 (dead package) https://bugzilla.redhat.com/731307 Well I will drop the lockdown booleans package from policycoreutils-gui. I don't have time to figure out an alternative and I don't believe many/any people use this gui. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5mdccACgkQrlYvE4MpobPqegCgruwUa/Cv9WRhmISOE5fTTieR dBwAoL1FNOJy8UcKT8q5v7ygEsuUGn08 =/Q6C -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
Richard Shaw hobbes1...@gmail.com writes:
I like the idea of quilt but I can't seem to find the magic recipe to
get it to integrate with rpmbuild.
I use an %apply macro in ways like
| %apply -n4 -p1
which is equivalent to
| %patch4 -p1
on ordinary hosts. But defining this macro as
| %apply(p:n:b:) \
| if test -n $RPM_NO_DEVEL; then\
| %patch%{-n:%{-n*}} %-p %-b \
| else \
|quilt import %-p %{!-p:-p 0} %{P:%{-n*}} \
|quilt push -f; \
| fi \
| %nil
in ~/.rpmmacros allows the management of patches by 'quilt'.
See e.g.
http://pkgs.fedoraproject.org/gitweb/?p=milter-greylist.git;a=blob;f=milter-greylist.spec;hb=HEAD
for the definition of %apply.
Enrico
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Package-Stash] Update to 0.32
commit 1a294d28ce820abeef16899d3dbb70a3cec87b74
Author: Paul Howarth p...@city-fan.org
Date: Tue Sep 6 20:29:32 2011 +0100
Update to 0.32
- New upstream release 0.32
- Bring the behavior of has_symbol for nonexistant scalars into line with
the
XS version
- Invalid package names (for instance, Foo:Bar) are not allowed
- Invalid stash entry names (anything containing ::) are not allowed
- Update patches to apply cleanly
- Bump perl(Package::Stash::XS) version requirement to 0.24
.gitignore |1 +
Package-Stash-0.25-no-Test::LeakTrace.patch| 26
...atch = Package-Stash-0.32-EU::MM-version.patch |4 +-
Package-Stash-0.32-no-Test::LeakTrace.patch| 26
...atch = Package-Stash-0.32-old-Test::More.patch | 156 +++-
perl-Package-Stash.spec| 21 ++-
sources|2 +-
7 files changed, 132 insertions(+), 104 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 83dcea3..abd633f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Package-Stash-[0-9.]*\.tar\.gz
+/Package-Stash-0.32.tar.gz
diff --git a/Package-Stash-0.30-EU::MM-version.patch
b/Package-Stash-0.32-EU::MM-version.patch
similarity index 89%
rename from Package-Stash-0.30-EU::MM-version.patch
rename to Package-Stash-0.32-EU::MM-version.patch
index b34d440..23093c7 100644
--- a/Package-Stash-0.30-EU::MM-version.patch
+++ b/Package-Stash-0.32-EU::MM-version.patch
@@ -18,13 +18,13 @@
},
'DISTNAME' = 'Package-Stash',
'EXE_FILES' = [
-@@ -51,6 +51,9 @@
+@@ -52,6 +52,9 @@
delete $WriteMakefileArgs{CONFIGURE_REQUIRES}
unless eval { ExtUtils::MakeMaker-VERSION(6.52) };
+delete $WriteMakefileArgs{LICENSE}
+ unless eval { ExtUtils::MakeMaker-VERSION(6.30) };
+
- $WriteMakefileArgs{PREREQ_PM}{'Package::Stash::XS'} = 0.22
+ $WriteMakefileArgs{PREREQ_PM}{'Package::Stash::XS'} = 0.24
if can_cc();
diff --git a/Package-Stash-0.32-no-Test::LeakTrace.patch
b/Package-Stash-0.32-no-Test::LeakTrace.patch
new file mode 100644
index 000..a1a32b3
--- /dev/null
+++ b/Package-Stash-0.32-no-Test::LeakTrace.patch
@@ -0,0 +1,26 @@
+diff -up Package-Stash-0.32/t/author-leaks-debug.t.orig
Package-Stash-0.32/t/author-leaks-debug.t
+--- Package-Stash-0.32/t/author-leaks-debug.t.orig 2011-09-06
12:43:32.0 +0100
Package-Stash-0.32/t/author-leaks-debug.t 2011-09-06 12:45:29.866712947
+0100
+@@ -12,7 +12,8 @@ use warnings;
+ use lib 't/lib';
+ use Test::More;
+ use Test::Fatal;
+-use Test::LeakTrace;
++eval use Test::LeakTrace;
++plan skip_all = Test::LeakTrace required for this test if $@;
+
+ plan tests = 29;
+
+diff -up Package-Stash-0.32/t/author-leaks.t.orig
Package-Stash-0.32/t/author-leaks.t
+--- Package-Stash-0.32/t/author-leaks.t.orig 2011-09-06 12:43:32.0
+0100
Package-Stash-0.32/t/author-leaks.t2011-09-06 12:45:58.177640368
+0100
+@@ -12,7 +12,8 @@ use warnings;
+ use lib 't/lib';
+ use Test::More;
+ use Test::Fatal;
+-use Test::LeakTrace;
++eval use Test::LeakTrace;
++plan skip_all = Test::LeakTrace required for this test if $@;
+
+ plan tests = 29;
+
diff --git a/Package-Stash-0.31-old-Test::More.patch
b/Package-Stash-0.32-old-Test::More.patch
similarity index 55%
rename from Package-Stash-0.31-old-Test::More.patch
rename to Package-Stash-0.32-old-Test::More.patch
index bce494a..e33d974 100644
--- a/Package-Stash-0.31-old-Test::More.patch
+++ b/Package-Stash-0.32-old-Test::More.patch
@@ -1,6 +1,6 @@
-diff -up Package-Stash-0.31/t/addsub.t.orig Package-Stash-0.31/t/addsub.t
Package-Stash-0.31/t/addsub.t.orig 2011-08-08 16:43:29.0 +0100
-+++ Package-Stash-0.31/t/addsub.t 2011-08-09 09:41:59.191745893 +0100
+diff -up Package-Stash-0.32/t/addsub.t.orig Package-Stash-0.32/t/addsub.t
+--- Package-Stash-0.32/t/addsub.t.orig 2011-09-06 04:23:06.0 +0100
Package-Stash-0.32/t/addsub.t 2011-09-06 12:32:22.277728975 +0100
@@ -2,7 +2,7 @@
use strict;
use warnings;
@@ -16,19 +16,19 @@ diff -up Package-Stash-0.31/t/addsub.t.orig
Package-Stash-0.31/t/addsub.t
'... got the right %DB::sub value for dunk with specified args';
-
-done_testing;
-diff -up Package-Stash-0.31/t/author-20-leaks.t.orig
Package-Stash-0.31/t/author-20-leaks.t
Package-Stash-0.31/t/author-20-leaks.t.orig2011-08-08
16:43:29.0 +0100
-+++ Package-Stash-0.31/t/author-20-leaks.t 2011-08-09 09:41:59.214745838
+0100
+diff -up Package-Stash-0.32/t/author-leaks-debug.t.orig
Package-Stash-0.32/t/author-leaks-debug.t
+--- Package-Stash-0.32/t/author-leaks-debug.t.orig 2011-09-06
04:23:06.0 +0100
Package-Stash-0.32/t/author-leaks-debug.t 2011-09-06 12:32:22.341728808
+0100
@@ -14,6 +14,8 @@ use Test::More;
use Test::Fatal;
use Test::LeakTrace;
-+plan tests = 25;
++plan tests = 29;
+
- use Package::Stash;
- use Symbol;
Re: Best practices for patch management on RPM based packages?
On Tue, Sep 6, 2011 at 2:23 PM, Panu Matilainen pmati...@laiskiainen.org wrote: On 09/06/2011 09:53 PM, Matej Cepl wrote: Dne 6.9.2011 16:29, Panu Matilainen napsal(a): I like the idea of quilt but I can't seem to find the magic recipe to get it to integrate with rpmbuild. Please mind your quotes, I didn't write the above. My apologies! What's wrong with quilt setup specname.spec Because rpmbuild segregates everything, quilt doesn't seem to know how to handle that. When you create the directory tree for rpmbuild it (at some point) creates: BUILD BUILDROOT RPMS SOURCES SPECS SRPMS Of course the only ones of intrest to quilt is SOURCES and SPECS but that means they are not in the same directory. I've tried changing into the SOURCES directory (so it will find the source archive) at la: quilt -v setup ../SPECS/name.spec which gets me most of the way there. It actually md5sums all the files in the SOURCE directory and runs %prep from the spec file but then it tries to create the 'patches' and 'series' directories in the expanded archive directory from the current directory (SOURCES/name-version) instead of which they are actually expanded (../BUILD/name-version/) And even if it did, that's not a good place to put it because that directory is removed and recreated every time you run rpmbuild (-bp, -bc, -bi, etc). Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
I think I've gotten over the first hurdle. I ended up using the following command: $ quilt setup -d rpmbuild/BUILD --sourcedir rpmbuild/SOURCES/ rpmbuild/SPECS/name.spec Now that doesn't fix the persistence issue since anything in BUILD/ will be deleted on the next run of rpmbuild... In this case 'patches' ends up being a symbolic link to ../SOURCES so that's ok, but the 'series' file will get deleted... Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Package-Stash/f16] Update to 0.32
Summary of changes: 1a294d2... Update to 0.32 (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Package-Stash/el6] (3 commits) ...Update to 0.32
Summary of changes: af968d1... Perl mass rebuild (*) 29b6aed... Update to 0.31 (*) 1a294d2... Update to 0.32 (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Best practices for patch management on RPM based packages?
On Tue, Sep 6, 2011 at 3:17 PM, Richard Shaw hobbes1...@gmail.com wrote: I think I've gotten over the first hurdle. I ended up using the following command: $ quilt setup -d rpmbuild/BUILD --sourcedir rpmbuild/SOURCES/ rpmbuild/SPECS/name.spec Well not so fast... I don't know why, but even though I'm telling it to expand in ~/rpmbuild/BUILD it seems to be expanding the source archive into a temporary directory in /var/tmp... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Package-Stash] Created tag perl-Package-Stash-0.31-1.fc16
The lightweight tag 'perl-Package-Stash-0.31-1.fc16' was created pointing to: 29b6aed... Update to 0.31 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Package-Stash] Created tag perl-Package-Stash-0.31-1.fc17
The lightweight tag 'perl-Package-Stash-0.31-1.fc17' was created pointing to: 29b6aed... Update to 0.31 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Package-Stash] Created tag perl-Package-Stash-0.32-1.el6
The lightweight tag 'perl-Package-Stash-0.32-1.el6' was created pointing to: 1a294d2... Update to 0.32 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Package-Stash] Created tag perl-Package-Stash-0.32-1.fc16
The lightweight tag 'perl-Package-Stash-0.32-1.fc16' was created pointing to: 1a294d2... Update to 0.32 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Package-Stash] Created tag perl-Package-Stash-0.32-1.fc17
The lightweight tag 'perl-Package-Stash-0.32-1.fc17' was created pointing to: 1a294d2... Update to 0.32 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: How to debug X lockup (advice from gurus wanted)
On 09/06/2011 01:18 PM, Reindl Harald wrote: Am 06.09.2011 13:10, schrieb Adam Jackson: On 9/1/11 5:05 PM, Roberto Ragusa wrote: Hmmm, turning off SMP is not realistic, as this laptop has a Core 2 Duo. Sure it is. Boot with maxcpus=1 on the kernel command line i would recommend nosmp because it really disables the kernel-smp code Ahem... what I meant is that it is not realistic for me to sacrifice one of the CPUs just to hope to get more stability. I intended the suggestion was turn off SMP support if you have only one CPU. Thinking about it, the kernel is already no-SMP on systems with one CPU nowadays, right? Anyway, the problem happened again one hour ago, so I just decided to upgrade only the kernel to the one from F15 and hope for the best. If it happens again, I will then upgrade Xorg and Mesa. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Jóhann B. Guðmundsson wrote: There is one thing I have learned ( so far in the conversion process ) and that is that the current model surrounding maintainers and maintainership followed by various policies surrounding that model which we use here in Fedora as in maintainers Own their components ( ownership model ) cannot deal with large scale changes like systemd introduces amongst other things and I will go so far to say that module effectively became outdated when Fedora stopped being hobby distro ( which happened the instance people/corporates started depending on fedora and the components it ships which kinda says it never was ) made up of relatively few components with relatively few maintainers and an hand full of users but that discussion belongs in another thread. That's exactly why I'm saying that global changes should be done globally, not by each package's maintainer. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Sat, 2011-09-03 at 20:56 +0200, Roberto Ragusa wrote: On 09/03/2011 07:31 PM, Adam Williamson wrote: To look at things at a higher level: it's clearly the goal of the guidelines that any interested party (with sufficient basic knowledge) who comes along and checks a Fedora package out of git should be able to _understand it_, and this includes finding out where all the stuff that goes to make up the package actually comes from. glibc spec clearly doesn't achieve this goal; the casual browser is left looking at a gigantic patch and a mystery tarball and wondering where they came from and what they do, as I was. This makes glibc not at all raptor-proof, and not very amenable to outside review or improvements, which is rather against the spirit of an open source, community project. And the mind goes to a recent case of obfuscation by merging patches. http://lwn.net/Articles/432012/ In that case RedHat acknowledged that a single giant patch is more difficult to understand and it confirmed that this was considered a feature (for commercial reasons); someone even started to debate if that could be considered a GPL violation, on the source in preferred form criteria. Well, yes, that parallel came up in my mind too, but really, the two aren't particularly similar. I don't think there's any intent to obfuscate in the case of the glibc spec, it's simply done the way that seemed convenient to its maintainers at the time. Note the Fedora kernel package is a normal source / split out patches set. I'm not sure that whole kerfuffle is particularly relevant to Fedora. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson awill...@redhat.com wrote: Well, yes, that parallel came up in my mind too, but really, the two aren't particularly similar. I don't think there's any intent to obfuscate in the case of the glibc spec, it's simply done the way that seemed convenient to its maintainers at the time. Note the Fedora kernel package is a normal source / split out patches set. I'm not sure that whole kerfuffle is particularly relevant to Fedora. Let me turn that on its head. As more projects become git based over time, the preferred form for code development might actually be a bisectable git checkout and not broken out patchsets for some projects. I'm not sure the distribution and packaging model that we collectively understand now and which grew up in the cvs and svn dominated era fits really well in the git dominated era. I think we are still groping around trying to figure out what the preferred form really is in the git dominated era. I'm not sure the broken out patchset will be it. It might soon be considered a legacy format in some situations. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
X clipboard behaviour/patch verification
Hi. I'd be grateful if someone versed in the finer aspects of X clipboard handling could take a quick look at the patch attached to https://bugzilla.redhat.com/show_bug.cgi?id=667541 and tell me whether it looks sane. Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
submitters +1ing their own packages
I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? sometimes a +1 after weeks in testing is the only or at least easy way to nudge a package into stable. e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 even with my +1 still not there, and this isn't the only package I've done this for. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 6, 2011 at 8:00 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? sometimes a +1 after weeks in testing is the only or at least easy way to nudge a package into stable. e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 even with my +1 still not there, and this isn't the only package I've done this for. Do you mean if you don't want to wait for a week in testing? Or is you're package not aging out for some reason? I own several (new) packages that are not really used yet (building blocks for other packages) and I didn't feel right about +1 my own packages so I just end up leaving them in testing until they can be pushed to stable... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 08:09:03PM -0500, Richard Shaw wrote: On Tue, Sep 6, 2011 at 8:00 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? sometimes a +1 after weeks in testing is the only or at least easy way to nudge a package into stable. e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 even with my +1 still not there, and this isn't the only package I've done this for. Do you mean if you don't want to wait for a week in testing? Or is you're package not aging out for some reason? I do it once the old_testing emails start getting too annoying. With the exception of evtest, I think all the packages I own are critical path so even after that timeout I can't push without proventester ack. in a few cases, I had provenpackager +1 but no other tester and we seem to need both (?) to get it to stable. Cheers, Peter I own several (new) packages that are not really used yet (building blocks for other packages) and I didn't feel right about +1 my own packages so I just end up leaving them in testing until they can be pushed to stable... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
On Tue, 2011-09-06 at 15:04 -0500, Richard Shaw wrote: On 09/06/2011 09:53 PM, Matej Cepl wrote: What's wrong with quilt setup specname.spec Because rpmbuild segregates everything, quilt doesn't seem to know how to handle that. When you create the directory tree for rpmbuild it (at some point) creates: BUILD BUILDROOT RPMS SOURCES SPECS SRPMS Of course the only ones of intrest to quilt is SOURCES and SPECS but that means they are not in the same directory. I have this in my ~/.rpmmacros: %_topdir%(pwd) %_sourcedir %(pwd) %_specdir %(pwd) %_srcrpmdir %(pwd) This way, I simply do: $ fedpkg clone foobar $ cd foobar And I can rpmbuild directly in the git tree. Hope that helps. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 11:00 +1000, Peter Hutterer wrote: On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? sometimes a +1 after weeks in testing is the only or at least easy way to nudge a package into stable. e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 even with my +1 still not there, and this isn't the only package I've done this for. Please don't turn this into another 'I'm not getting enough testing on my old critpath package' thread. We already have about five of those, plus a trac ticket. Whether it has some practical effect or not, it's clearly against the current policy, and what I'm questioning is whether Bodhi should be enforcing that policy automatically. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, 06 Sep 2011 17:02:25 -0700 Adam Williamson awill...@redhat.com wrote: I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? It's not being enforced in bodhi, but it should be: https://fedorahosted.org/bodhi/ticket/277 Hopefully that will be implemented soon. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 07:38:53PM -0700, Adam Williamson wrote: On Wed, 2011-09-07 at 11:00 +1000, Peter Hutterer wrote: On Tue, Sep 06, 2011 at 05:02:25PM -0700, Adam Williamson wrote: I've mentioned before that I actually support this, but I'm in the minority, and AFAIK the current policy is supposed to be that maintainers cannot upkarma updates they submitted themselves. However, this seems to be happening - exhibit a): https://admin.fedoraproject.org/updates/nss-3.12.10-7.fc16 karma is listed as 1, the only positive feedback shown as I write this is from kengert, who submitted the update. Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? sometimes a +1 after weeks in testing is the only or at least easy way to nudge a package into stable. e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 even with my +1 still not there, and this isn't the only package I've done this for. Please don't turn this into another 'I'm not getting enough testing on my old critpath package' thread. We already have about five of those, that wasn't my intent. plus a trac ticket. Whether it has some practical effect or not, it's clearly against the current policy, and what I'm questioning is whether Bodhi should be enforcing that policy automatically. my argument is that even though it's against official policy, it can be useful in some cases. The current voluntary compliance is imo a good solution since it can be circumvented when needed. I'm definitely not advocating doing this for every update. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Best practices for patch management on RPM based packages?
On Sep 6, 2011, at 6:52 PM, Mathieu Bridon wrote: On Tue, 2011-09-06 at 15:04 -0500, Richard Shaw wrote: On 09/06/2011 09:53 PM, Matej Cepl wrote: What's wrong with quilt setup specname.spec Because rpmbuild segregates everything, quilt doesn't seem to know how to handle that. When you create the directory tree for rpmbuild it (at some point) creates: BUILD BUILDROOT RPMS SOURCES SPECS SRPMS Of course the only ones of intrest to quilt is SOURCES and SPECS but that means they are not in the same directory. I have this in my ~/.rpmmacros: %_topdir%(pwd) %_sourcedir %(pwd) %_specdir %(pwd) %_srcrpmdir %(pwd) This way, I simply do: $ fedpkg clone foobar $ cd foobar And I can rpmbuild directly in the git tree. Hope that helps. Don't forget that there is also 'fedpkg local', as well as prep, compile, install. Some of these have --short-circuit options as well to speed up testing. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File threads-1.85.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-threads: 0f9965148fa054cf553d7920c35cdd8e threads-1.85.tar.gz -- 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-threads] 1.85 bump
commit 2a382e16f5e25534942909312304481056bd73b6
Author: Petr Písař ppi...@redhat.com
Date: Tue Sep 6 08:33:53 2011 +0200
1.85 bump
.gitignore|1 +
perl-threads.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 52e0e9b..7e95253 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/threads-1.81.tar.gz
/threads-1.82.tar.gz
/threads-1.83.tar.gz
+/threads-1.85.tar.gz
diff --git a/perl-threads.spec b/perl-threads.spec
index 0aef87e..4d815e7 100644
--- a/perl-threads.spec
+++ b/perl-threads.spec
@@ -1,6 +1,6 @@
Name: perl-threads
-Version:1.83
-Release:4%{?dist}
+Version:1.85
+Release:1%{?dist}
Summary:Perl interpreter-based threads
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,6 +55,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Sep 06 2011 Petr Pisar ppi...@redhat.com - 1.85-1
+- 1.85 bump
+
* Tue Aug 16 2011 Marcela Mašláňová mmasl...@redhat.com - 1.83-4
- change path on vendor, so our debuginfo are not conflicting with
perl core debuginfos
diff --git a/sources b/sources
index 492430b..7403b20 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c087a8ec1eb43f54f257f22312aceb39 threads-1.83.tar.gz
+0f9965148fa054cf553d7920c35cdd8e threads-1.85.tar.gz
--
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-threads-shared] 1.39 bump
commit 85a01a189ac366d190ade67695c885c268db2ade
Author: Petr Písař ppi...@redhat.com
Date: Tue Sep 6 08:43:24 2011 +0200
1.39 bump
.gitignore |1 +
perl-threads-shared.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4524b74..73935d8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/threads-shared-1.34.tar.gz
/threads-shared-1.36.tar.gz
/threads-shared-1.37.tar.gz
+/perl-threads-shared.spec
diff --git a/perl-threads-shared.spec b/perl-threads-shared.spec
index 0007432..d33bb90 100644
--- a/perl-threads-shared.spec
+++ b/perl-threads-shared.spec
@@ -1,6 +1,6 @@
Name: perl-threads-shared
-Version:1.37
-Release:3%{?dist}
+Version:1.39
+Release:1%{?dist}
Summary:Perl extension for sharing data structures between threads
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,6 +55,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Sep 06 2011 Petr Pisar ppi...@redhat.com - 1.39-1
+- 1.39 bump
+
* Wed Aug 17 2011 Marcela Mašláňová mmasl...@redhat.com - 1.37-3
- change path on vendor, so our debuginfo are not conflicting with
perl core debuginfos
diff --git a/sources b/sources
index e11ae62..41ed2ae 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-62260203e96eb20a10b7c3000621a5e6 threads-shared-1.37.tar.gz
+4004f5f67ec76dc2839027202eb38259 perl-threads-shared.spec
--
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
[Bug 735775] perl-threads-shared-1.39 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=735775 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Fixed In Version||perl-threads-1.85-1.fc17 Last Closed||2011-09-06 02:42:41 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 735774] perl-threads-1.85 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=735774 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-threads-1.85-1.fc17 Resolution||RAWHIDE Last Closed||2011-09-06 02:42:58 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 735775] perl-threads-shared-1.39 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=735775 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|CLOSED |ASSIGNED CC|mmasl...@redhat.com,| |ppi...@redhat.com | Fixed In Version|perl-threads-1.85-1.fc17| Resolution|RAWHIDE | Keywords||Reopened -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
File threads-shared-1.39.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-threads-shared: e23c4b3eb6f5a39fed3c0f1761c61c2c threads-shared-1.39.tar.gz -- 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-threads-shared] Use correct source tar ball.
commit b5a3f207e3cca4639b43b4834676738032907d0d Author: Petr Písař ppi...@redhat.com Date: Tue Sep 6 08:49:46 2011 +0200 Use correct source tar ball. .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index 73935d8..63366f0 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,4 @@ /threads-shared-1.36.tar.gz /threads-shared-1.37.tar.gz /perl-threads-shared.spec +/threads-shared-1.39.tar.gz diff --git a/sources b/sources index 41ed2ae..5b3e664 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -4004f5f67ec76dc2839027202eb38259 perl-threads-shared.spec +e23c4b3eb6f5a39fed3c0f1761c61c2c threads-shared-1.39.tar.gz -- 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
[Bug 735775] perl-threads-shared-1.39 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=735775 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-threads-shared-1.39-1. ||fc17 Resolution||RAWHIDE Last Closed|2011-09-06 02:42:41 |2011-09-06 06:48:40 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
File Locale-Maketext-Lexicon-0.91.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Locale-Maketext-Lexicon: ead74d03d40c72cd52d4d70771bbd122 Locale-Maketext-Lexicon-0.91.tar.gz -- 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-Locale-Maketext-Lexicon/f16] Upstream update.
Summary of changes: 4c7bfe3... Upstream update. (*) (*) 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
[perl-Plack/f15] (3 commits) ...Post-merge cleanup.
Summary of changes: 8b58f69... Perl mass rebuild (*) 8ddc36b... Upstream update. (*) b72283c... Post-merge cleanup. (*) 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
[perl-Plack/f14] (4 commits) ...Merge remote-tracking branch 'origin/f15' into f14
Summary of changes: 8b58f69... Perl mass rebuild (*) 8ddc36b... Upstream update. (*) b72283c... Post-merge cleanup. (*) 714fe03... Merge remote-tracking branch 'origin/f15' into f14 (*) 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
[perl-Plack/f14: 4/4] Merge remote-tracking branch 'origin/f15' into f14
commit 714fe03ba97a283431863162ddb8c8e2df2b8f0c Merge: 5dc6978 b72283c Author: Ralf Corsépius corse...@fedoraproject.org Date: Tue Sep 6 16:45:36 2011 +0200 Merge remote-tracking branch 'origin/f15' into f14 .gitignore |2 +- perl-Plack.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 3 deletions(-) --- -- 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-Hash-FieldHash
perl-Hash-FieldHash has broken dependencies in the F-16 tree: On x86_64: perl-Hash-FieldHash-0.10-2.fc15.x86_64 requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Hash-FieldHash-0.10-2.fc15.i686 requires perl(:MODULE_COMPAT_5.12.4) 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-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) 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-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) 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
[perl-Package-Stash-XS] Update to 0.25
commit d408e62f10caf1ea146dc2f4b1fa38aea16b262e
Author: Paul Howarth p...@city-fan.org
Date: Tue Sep 6 20:08:09 2011 +0100
Update to 0.25
- New upstream release 0.25
- Invalid package names (for instance, Foo:Bar) are not allowed
- Invalid stash entry names (anything containing ::) are not allowed
- Update patches to apply cleanly
Package-Stash-XS-0.21-no-Test::LeakTrace.patch | 26
Package-Stash-XS-0.24-no-Test::LeakTrace.patch | 26
...h = Package-Stash-XS-0.24-old-Test::More.patch | 122 +++-
perl-Package-Stash-XS.spec | 12 ++-
sources|2 +-
5 files changed, 106 insertions(+), 82 deletions(-)
---
diff --git a/Package-Stash-XS-0.24-no-Test::LeakTrace.patch
b/Package-Stash-XS-0.24-no-Test::LeakTrace.patch
new file mode 100644
index 000..ae28a20
--- /dev/null
+++ b/Package-Stash-XS-0.24-no-Test::LeakTrace.patch
@@ -0,0 +1,26 @@
+diff -up Package-Stash-XS-0.24/t/author-leaks-debug.t.orig
Package-Stash-XS-0.24/t/author-leaks-debug.t
+--- Package-Stash-XS-0.24/t/author-leaks-debug.t.orig 2011-09-06
09:37:11.754912596 +0100
Package-Stash-XS-0.24/t/author-leaks-debug.t 2011-09-06
09:37:11.762912576 +0100
+@@ -12,7 +12,8 @@ use warnings;
+ use lib 't/lib';
+ use Test::More;
+ use Test::Fatal;
+-use Test::LeakTrace;
++eval use Test::LeakTrace;
++plan skip_all = Test::LeakTrace required for this test if $@;
+
+ BEGIN { $^P |= 0x210 } # PERLDBf_SUBLINE
+
+diff -up Package-Stash-XS-0.24/t/author-leaks.t.orig
Package-Stash-XS-0.24/t/author-leaks.t
+--- Package-Stash-XS-0.24/t/author-leaks.t.orig2011-09-06
09:37:11.754912596 +0100
Package-Stash-XS-0.24/t/author-leaks.t 2011-09-06 09:37:11.762912576
+0100
+@@ -12,7 +12,8 @@ use warnings;
+ use lib 't/lib';
+ use Test::More;
+ use Test::Fatal;
+-use Test::LeakTrace;
++eval use Test::LeakTrace;
++plan skip_all = Test::LeakTrace required for this test if $@;
+
+ use Package::Stash;
+ use Symbol;
diff --git a/Package-Stash-XS-0.23-old-Test::More.patch
b/Package-Stash-XS-0.24-old-Test::More.patch
similarity index 53%
rename from Package-Stash-XS-0.23-old-Test::More.patch
rename to Package-Stash-XS-0.24-old-Test::More.patch
index 05dd63d..9c1bd91 100644
--- a/Package-Stash-XS-0.23-old-Test::More.patch
+++ b/Package-Stash-XS-0.24-old-Test::More.patch
@@ -1,6 +1,6 @@
-diff -up Package-Stash-XS-0.23/t/addsub.t.orig Package-Stash-XS-0.23/t/addsub.t
Package-Stash-XS-0.23/t/addsub.t.orig 2011-08-08 16:43:44.0
+0100
-+++ Package-Stash-XS-0.23/t/addsub.t 2011-08-09 09:21:01.223844899 +0100
+diff -up Package-Stash-XS-0.24/t/addsub.t.orig Package-Stash-XS-0.24/t/addsub.t
+--- Package-Stash-XS-0.24/t/addsub.t.orig 2011-09-06 04:20:20.0
+0100
Package-Stash-XS-0.24/t/addsub.t 2011-09-06 09:33:49.962448819 +0100
@@ -2,7 +2,7 @@
use strict;
use warnings;
@@ -16,19 +16,19 @@ diff -up Package-Stash-XS-0.23/t/addsub.t.orig
Package-Stash-XS-0.23/t/addsub.t
'... got the right %DB::sub value for dunk with specified args';
-
-done_testing;
-diff -up Package-Stash-XS-0.23/t/author-20-leaks.t.orig
Package-Stash-XS-0.23/t/author-20-leaks.t
Package-Stash-XS-0.23/t/author-20-leaks.t.orig 2011-08-08
16:43:44.0 +0100
-+++ Package-Stash-XS-0.23/t/author-20-leaks.t 2011-08-09 09:21:01.309844685
+0100
-@@ -17,6 +17,8 @@ use Test::LeakTrace;
+diff -up Package-Stash-XS-0.24/t/author-leaks-debug.t.orig
Package-Stash-XS-0.24/t/author-leaks-debug.t
+--- Package-Stash-XS-0.24/t/author-leaks-debug.t.orig 2011-09-06
04:20:20.0 +0100
Package-Stash-XS-0.24/t/author-leaks-debug.t 2011-09-06
09:33:49.978448777 +0100
+@@ -19,6 +19,8 @@ BEGIN { $^P |= 0x210 } # PERLDBf_SUBLINE
use Package::Stash;
use Symbol;
-+plan tests = 25;
++plan tests = 29;
+
{
package Bar;
}
-@@ -144,7 +146,10 @@ use Symbol;
+@@ -154,7 +156,10 @@ use Symbol;
ok($foo-has_symbol('@ISA'));
is(ref($foo-get_symbol('@ISA')), 'ARRAY');
is_deeply($foo-get_symbol('@ISA'), ['Exporter']);
@@ -39,25 +39,25 @@ diff -up Package-Stash-XS-0.23/t/author-20-leaks.t.orig
Package-Stash-XS-0.23/t/
}
{
-@@ -198,5 +203,3 @@ use Symbol;
+@@ -208,5 +213,3 @@ use Symbol;
eval { $foo-get_or_add_symbol('blorg') };
} doesn't leak on errors;
}
-
-done_testing;
-diff -up Package-Stash-XS-0.23/t/author-21-leaks-debug.t.orig
Package-Stash-XS-0.23/t/author-21-leaks-debug.t
Package-Stash-XS-0.23/t/author-21-leaks-debug.t.orig 2011-08-08
16:43:44.0 +0100
-+++ Package-Stash-XS-0.23/t/author-21-leaks-debug.t2011-08-09
09:21:01.310844682 +0100
-@@ -19,6 +19,8 @@ BEGIN { $^P |= 0x210 } # PERLDBf_SUBLINE
+diff -up Package-Stash-XS-0.24/t/author-leaks.t.orig
Package-Stash-XS-0.24/t/author-leaks.t
+--- Package-Stash-XS-0.24/t/author-leaks.t.orig2011-09-06
04:20:20.0 +0100
[perl-Package-Stash-XS/f16] Update to 0.25
Summary of changes: d408e62... Update to 0.25 (*) (*) 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
[perl-Package-Stash-XS/el6] (3 commits) ...Update to 0.25
Summary of changes: 69f740c... Perl mass rebuild (*) 06d92df... Update to 0.23 (*) d408e62... Update to 0.25 (*) (*) 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
[perl-Package-Stash-XS] Created tag perl-Package-Stash-XS-0.25-1.el6
The lightweight tag 'perl-Package-Stash-XS-0.25-1.el6' was created pointing to: d408e62... Update to 0.25 -- 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-Package-Stash-XS] Created tag perl-Package-Stash-XS-0.25-1.fc16
The lightweight tag 'perl-Package-Stash-XS-0.25-1.fc16' was created pointing to: d408e62... Update to 0.25 -- 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-Package-Stash-XS] Created tag perl-Package-Stash-XS-0.25-1.fc17
The lightweight tag 'perl-Package-Stash-XS-0.25-1.fc17' was created pointing to: d408e62... Update to 0.25 -- 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
File Class-Load-0.08.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Class-Load: 2b7d7c5faa72e14095f603a6a1e5496b Class-Load-0.08.tar.gz -- 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
[Bug 712699] CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used [fedora-all]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712699 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-09-06 23:41:15 EDT --- perl-Data-FormValidator-4.66-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
[Bug 712699] CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used [fedora-all]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712699 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Data-FormValidator-4.6 ||6-6.fc16 Resolution||ERRATA Last Closed||2011-09-06 23:41:23 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
