Re: [mate-screensaver] Initial import
Hello, mate-screensaver maintainer:
leigh123linux wrote, at 10/23/2012 04:13 PM +9:00:
commit e8b3798a18387d3e05675f40c4ee5998e94d0dfd
Author: leigh123linux leigh123li...@googlemail.com
Date: Tue Oct 23 08:13:31 2012 +0100
Initial import
.gitignore|1 +
mate-screensaver.spec | 131 +
sources |1 +
3 files changed, 133 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..ea3919d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/mate-screensaver-1.4.0.tar.xz
diff --git a/mate-screensaver.spec b/mate-screensaver.spec
new file mode 100644
index 000..b4c2afd
--- /dev/null
+++ b/mate-screensaver.spec
@@ -0,0 +1,131 @@
skip
+%build
+%configure \
+--disable-static \
+--disable-schemas-install \
+--with-xscreensaverdir=%{_datadir}/xscreensaver/config \
+--with-xscreensaverhackdir=%{_libexecdir}/xscreensaver \
+--enable-locking \
+--enable-pam
+
Maybe mate-screensaver will use xscreensaver-foo.desktop under
%{_datadir}/applications/screensavers (in xscreensaver-extras-gss
and xscreensaver-gl-extras-gss) like gnome-screensaver 2.x?
If so, it may be better that I drop Requires: gnome-screensaver on
xscreensaver-extras-gss and xscreensaver-gl-extras-gss because
if gnome-screensaver user wants to use these desktop files he/she
will install gnome-screensaver beforehand anyway, and if mate-screensaver
user wants to use these desktop files he/she does not want to install
gnome-screensaver (and he/she will install mate-screensaver beforehand).
How do you think? I will appreciate your opinion
Regards,
Mamoru Tasaka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120825 changes
Hi, Parag: Parag N(पराग़) wrote, at 08/26/2012 03:41 PM +9:00: Hi Mamoru, On Sat, Aug 25, 2012 at 7:31 PM, TASAKA Mamoru mtas...@fedoraproject.org wrote: Fedora Rawhide Report wrote, at 08/25/2012 09:34 PM +9:00: Compose started at Sat Aug 25 08:15:10 UTC 2012 Broken deps for x86_64 -- [OpenSceneGraph] OpenSceneGraph-examples-gtk-3.0.1-12.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [beldi] beldi-0.9.26-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [celestia] celestia-1.6.1-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [coot] coot-0.6.2-14.20110715svn3566.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) snip pango maintainer, would you explain what has happened? Also would you explain how we should cope with this? And I would appreciate it if you would announce this kind of change beforehand, thank you. (Well, it seems that this change happened 3 days ago, however it seems that I missed this). I am not a pango maintainer but I did rebuild a failed pango-1.31.0-1.fc18 build to pango-1.31.0-2.fc18 build and also rebuilt the same pango build in master branch. About libpangox library its not now provided by upstream pango tarball. Also, I see upstream changelog mentioned like this Remove pangoX been overdue I never thought this library be still in use by other packages. So, didn't informed this to devel list. Parag. Thanks. Then I will wait from reply from pango maintainer. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120825 changes
Fedora Rawhide Report wrote, at 08/25/2012 09:34 PM +9:00: Compose started at Sat Aug 25 08:15:10 UTC 2012 Broken deps for x86_64 -- [OpenSceneGraph] OpenSceneGraph-examples-gtk-3.0.1-12.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [beldi] beldi-0.9.26-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [celestia] celestia-1.6.1-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [coot] coot-0.6.2-14.20110715svn3566.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ebview] ebview-0.3.6.2-6.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gabedit] gabedit-2.4.0-3.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gauche-gtk] 1:gauche-gtk-0.6-0.6.20120403gitf7d3f802f3750.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ghemical] ghemical-2.99.2-22.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gliv] gliv-1.9.7-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gnash] 1:python-gnash-0.8.10-4.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gnubg] 1:gnubg-0.9.0.1-15.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gnubik] gnubik-2.4-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gspiceui] gspiceui-0.9.98-7.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gtkglext] gtkglext-devel-1.2.0-18.fc18.i686 requires pkgconfig(pangox) gtkglext-devel-1.2.0-18.fc18.x86_64 requires pkgconfig(pangox) gtkglext-libs-1.2.0-18.fc18.i686 requires libpangox-1.0.so.0 gtkglext-libs-1.2.0-18.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gtkglextmm] gtkglextmm-1.2.0-15.fc18.i686 requires libpangox-1.0.so.0 gtkglextmm-1.2.0-15.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [gtkmathview] gtkmathview-0.8.0-10.fc18.i686 requires libpangox-1.0.so.0 gtkmathview-0.8.0-10.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ibus-handwrite] ibus-handwrite-2.1.4-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [k3d] k3d-0.8.0.2-11.fc19.i686 requires libpangox-1.0.so.0 k3d-0.8.0.2-11.fc19.x86_64 requires libpangox-1.0.so.0()(64bit) [pcb] pcb-0.20110918-5.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [pygtkglext] pygtkglext-1.1.0-13.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) [ruby-gnome2] ruby-gtkglext-0.90.4-1.9.fc18.1.x86_64 requires libpangox-1.0.so.0()(64bit) [sawfish] sawfish-1.9.0-2.fc18.x86_64 requires libpangox-1.0.so.0()(64bit) pango maintainer, would you explain what has happened? Also would you explain how we should cope with this? And I would appreciate it if you would announce this kind of change beforehand, thank you. (Well, it seems that this change happened 3 days ago, however it seems that I missed this). Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Bill Nottingham wrote, at 08/01/2012 02:11 AM +9:00: Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. We will block these packages on Monday, August 06. Note that if you're receiving this mail directly, it's because you are a co-maintainer of one of these packages. Please work with your comaintainers to take up maintenance. Package ragel (fails to build) Package xaos (fails to build) Package xdrawchem (fails to build) Fixed these. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-rpm-config and rpm-build (fwd)
Paul Wouters wrote, at 06/17/2012 09:46 AM +9:00: On Fri, 15 Jun 2012, Ralf Corsepius wrote: On 06/15/2012 05:03 AM, Jens Petersen wrote: yum install rpm-build should install an rpmbuild version that works as expected for fedora. Currently, it does not because it is missing the dependancy on redhat-rpm-config. Well I tend to agree: it would be the least surprising behaviour for most fedora packagers. I think it's a silly idea. rpm-build is a generic tool and redhat-rpm-config is a redhat specific/proprietary add-on/plugin to it. Then add redhat-rpm-config as a buildrequire for all fedora packages. (though that might be a catch22) I guess you know this: https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 Though I understand the point about keeping rpmbuild generic - I don't see how pulling in redhat-rpm-config would break generic rpms? Though I don't have a current example of current redhat-rpm-config breaking generic rpms, history is full of such cases. Someone building non-fedora/non-epel rpms should be expected to create their own version of foo-rpm-config that satisfies/obsoletes the same dependancy as redhat-rpm-config. Surely most people have it installed anyway. Well, fedora packagers will have it installed, because fedora-packager pulls it in. group names are no replacements for proper dependancies. People who build rpms need to be able to yum install rpmbuild and get a working setup. They should not need to spend an hour googling on why their debuginfo packages don't get build. Same as above. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ruby review swap
Darryl L. Pierce wrote, at 12/21/2011 11:23 PM +9:00: I have a package [1] I'd like to get through the review process, and am willing to trade reviews with someone else with a Ruby package to get reviewed. [1] https://bugzilla.redhat.com/show_bug.cgi?id=752089 If you would review my review request [2], I would appreciate it. [2] https://bugzilla.redhat.com/show_bug.cgi?id=678674 Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji rawhide broken
Iain Arnell wrote, at 10/22/2011 09:30 PM +9:00: Is anyone able to fix koji rawhide buildroot? DEBUG util.py:247: Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 (build) DEBUG util.py:247: Requires: grubby= 8.3-1 DEBUG util.py:247: Installing: grubby-8.2-1.fc17.i686 (build) DEBUG util.py:247: grubby = 8.2-1.fc17 DEBUG util.py:247: You could try using --skip-broken to work around the problem DEBUG util.py:247: You could try running: rpm -Va --nofiles --nodigest DEBUG util.py:247: Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 (build) DEBUG util.py:247: Requires: grubby= 8.3-1 DEBUG util.py:247: Available: grubby-8.2-1.fc17.i686 (build) DEBUG util.py:247: grubby = 8.2-1.fc17 It looks like kernel-3.1.0-0.rc10.git1.1.fc17 needs to be untagged until grubby-8.3-1.fc17 is built and available. Untagged. Regards, Mamoru -- 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/11/2011 01:01 AM +9:00: Now I change it on: %if %( php -r echo (version_compare(PHP_VERSION, '5.3.0', '=') ? 1 : 0); /dev/null || echo 0 ) but on make srpm got error: error: /home/pasha/SOFT/git/php-pecl-runkit/master/php-pecl-runkit.spec:74: parseExpressionBoolean returns -1 error: query of specfile /home/pasha/SOFT/git/php-pecl-runkit/master/php-pecl-runkit.spec failed, can't parse Could not make an srpm: Could not parse the spec, exited 1 Because this php command succeeds (perhaps) and return status (of php) is 0. Then php -r prints the result 1 to stdout but this is redirected to /dev/null. The latter || echo 0 is not evaluated because php -r succeeds. So (with php installed) this is %if (empty) , and rpmbuild cannot parse it. Obviously it because () in construction, but they in quotes!? See above Changing it to: %if %( php -r echo \(version_compare\(PHP_VERSION, '5.3.0', '='\) ? 1 : 0\); /dev/null || echo 0 ) give me chance build package. See http://koji.fedoraproject.org/koji/taskinfo?taskID=3341569 but it also doesn't work as intended, patches doesn't applied: http://koji.fedoraproject.org/koji/getfile?taskID=3341573name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=3341573name=build.log Because with this php command fails to understand the part \(\) (perhaps) and return status is non-zero (perhaps), so the latter || echo 0 is evaluated. So this is %if 0, and patches are not applied. If I redirecting to null only stderr and remove parenthesis escaping: %if %( php -r echo (version_compare(PHP_VERSION, '5.3.0', '=') ? 1 : 0); 2/dev/null || echo 0 ) package also built: http://koji.fedoraproject.org/koji/taskinfo?taskID=3341605 and rpm do what I want: http://koji.fedoraproject.org/koji/getfile?taskID=3341605name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=3341605name=build.log See the first case you wrote, This time the output of php -r command 1 printed out to stdout is used so this is actually %if 1, so the result is as expected. So, it seams I completely don't understand rpm expression parsing logic: 1) Why /dev/null is incorrect? Independent on shell were it intended to be parsed, macros just should pass content of macros %() to shell and return string value. Or not? See above 2) Why /dev/null became correct if I escape parenthesis (even if command really not work)? I don't see the corresponding example you tried for this case. 3) Why initial command work before and not now? Is it bug or expected change? I think the current behavior is expected. Regards, Mamoru -- 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/07/2011 04:14 PM +9:00:
06.09.2011 18:47, TASAKA Mamoru wrote:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/06/2011 07:00 PM +9:00:
05.09.2011 19:17, TASAKA Mamoru wrote:
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)
It wasn't sole issue, but I understand your idea. Thank you again.
It also was in php command below what I also make silent fail if command
not found.
If you still see some issue, please write in detail what you see (and post
the spec file you are currently using).
Just for interest - is there change of minimal buildroot happened since
F15? Why it was worked before? Was it announced and I miss something?
F-15+ is using rpm 4.9.x. F-14 uses 4.8.1. At least this changed (note
that your initial spec file does not work even on F-15). Perhaps this
is related, although I have not examined further.
Regards,
Mamoru
--
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: Need help to build gimp-2.7.3
Luya Tshimbalanga wrote, at 08/24/2011 09:45 AM +9:00: Attempting to build rpm version of gimp 2.7.3 ended with failure from http://koji.fedoraproject.org/koji/taskinfo?taskID=3297263 For some reasons, I am puzzled about gimp-remote not built with this version while it did with 2.7.2. Can anyone check and suggest fix on the spec. Regards, Luya http://developer.gimp.org/NEWS says Changes in GIMP 2.7.3 = Source and build system: - Remove gimp-remote for good, it has been disabled for years Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange rpath behavior
Jorge Gallegos wrote, at 08/14/2011 09:22 AM +9:00: Hi, I am looking for a sponsor for uwsgi server in this ticket https://bugzilla.redhat.com/show_bug.cgi?id=682704 however I am trying to fix the rpath issues I commented there because otherwise i think it simply won't pass. I am faced with some... weird behavior. The software does not use the standard configure/makefile approach, instead it is built using a python program (uwsiconfig.py) to decide what flags it should use, then simply calls them (os.system(bla)) to build it. When I build the package using the python program I get warnings about rpath being present (sure enough I inspect the binaries and I can see /usr/lib64 in there) but, when I basically pipe the output of the program to another shell file (sans comments) and execute that shell file, I get no warning whatsoever and /usr/lib64 is nowhere to be found in the binaries. Now, I could cheat and patch uwsgiconfig.py to write the shell script instead of calling os.system (actually I have a patch/spec I just tested and works just fine) but that sounds like bad form. Can any of you veterans tell me why this is happening? My initial thought would be: python _has_ rpath issues, which the binaries inherit because they are compiled under python's scope Thoughts? Only commenting about rpath issue here (fixing packaging issues is also needed). Try finding LD_RUN_PATH string in uwsgi source. This string is actually there and this causes rpath to be embedded in built binaries. Note that there seems some API change in jansson and your srpm won't build in F-16 currently. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
Bill Nottingham wrote, at 07/13/2011 06:10 AM +9:00: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. Orphan kazehakase I am the current (orignal) owner of kazehakase and now I fixed the build (FTBFS issue). Any other action needed? Thank you in advance. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji: filter by dist-release
Reindl Harald wrote, at 06/22/2011 02:56 AM +9:00: http://koji.fedoraproject.org/koji/builds is there any way to get this filtered only for F15 or whatever is used? Click Build Targets and choose build targets. For example latest builds for dist-f15-updates-candidate tag are seen on: http://koji.fedoraproject.org/koji/builds?tagID=154inherited=0order=-completion_time Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rubygems 1.8.5 hits rawhide with license change
Hello, all: Now rawhide buildtree sees rubygems 1.8.5. The license changed from (Ruby or GPL+) to (Ruby or MIT). If you see any issues with new rubygems please feel free to report them, thank you. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: critpath approval process seems rather broken
Tomasz Torcz wrote, at 04/09/2011 07:57 PM +9:00: On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote: Will Woods wrote: In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first. The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks. No, security updates are not _that_ special. For example, there's an avahi update in pipeline. It has broken dependencies. Pushing this would broke some systems. I'm talking about: https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14 So as a result we are just leaving this security issue unresolved more than one month? Okay, it is all very well that we try to explain why the new updates request is not yet pushed, however then people would ask, so why can't Fedora try to fix such issue like broken dependency ASAP? Short of man power? Is Fedora just making light of security issues? Who is responsible for this issue? Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
