xosd orphaned?
Sorry, I saw it deprecated. Anyone known is there any drop-in alternative? And why it was orphaned? -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Please help do simulation build of two packages (xneur and gxneur)
Hello, All. I'm have two packages: xneur and gxneur. Second is just GUI fronted for first. In major view it act only as GUI to write config for the xneur daemon and just restart it to reload config. As it do not interact via library and just through config file gxneur package depends from xneur with full version dependency. Now I have problem building two packages and pushes into stable branches - to build gxneur I need waiting until xneur go through testing and will be pushed to stable. Sometimes, when karma can't be fast reached it spent 2 weeks. It looks in that period for users what something broken. I see fer ways to resolve it: 1) Each time I want update it request by ticket build-tag from fesco and deal with it. I think it is not easy and best way. 2) Place 2 sources into one src.rpm package and build 2 sub-packages. As for both I have one upstream author I think it is not a problem. The first main question may be I just does not known and now we have some way build override to build two packages serial and then also push it for updates without create separate tag? If so, please drop me a link how it may be accomplished. For second case I also have some questions if I make decision to fusion that packages say into one xneur: 2.1) Must I retire both or only gxneur? 2.2) Must I go through review process again or may just build new package? 2.3) Is there anything policy or guidelines for merging two packages? -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
13.09.2011 09:36, Remi Collet wrote:
Le 07/09/2011 09:14, Pavel Alexeev (aka Pahan-Hubbitus) a écrit :
%if 0%{?php_zend_api:1} if you want to use (guessing php_zend_api
is not defined as 0 even on EPEL)
Just for interest - is there change of minimal buildroot happened since
F15? Why it was worked before? Was it announced and I miss something?
This have been discussed on php-devel mailing list (February 2011)
Probably, as a php package maintainer you should subscribe to this list
(small traffic)
A lot of package are already fixed in rawhide and could be use as example.
Remi
Hello, Remi.
I believe I subscribed to that. But I have not seen such discussion. May
be I just miss id because was very overloaded by work, sorry.
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundle question
12.09.2011 12:37, Matej Cepl wrote: Dne 11.9.2011 00:35, Pavel Alexeev (aka Pahan-Hubbitus) napsal(a): Obviously you have not read my question. It is not jreen. It is about psi and kopete. And there NO system versions of mentioned libs in Fedora yet. I believe the correct answer is that those libraries should be still unbundled from psi/kopete and made into separate packages. Matěj Thank you for the answer, Matěj. Bugreports filled: psi:https://bugzilla.redhat.com/show_bug.cgi?id=737304 kdenetwork:https://bugzilla.redhat.com/show_bug.cgi?id=737305 -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
12.09.2011 19:57, TASAKA Mamoru wrote: 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. Oh, indeed it just my inattention. Thank you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
07.09.2011 18:59, TASAKA Mamoru wrote: If you still see some issue, please write in detail what you see (and post the spec file you are currently using). Yes, apparently I still have it. The long time awhile I have there condition: %if %( php -r echo (version_compare(PHP_VERSION, '5.3.0', '=') ? 1 : 0); ) today it produce parse error. 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 Obviously it because () in construction, but they in quotes!? 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 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 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? 2) Why /dev/null became correct if I escape parenthesis (even if command really not work)? 3) Why initial command work before and not now? Is it bug or expected change? -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundle question
04.09.2011 23:14, Jon Ciesla wrote: Patch jreen to use system versions. See: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries for guidance. Obviously you have not read my question. It is not jreen. It is about psi and kopete. And there NO system versions of mentioned libs in Fedora yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
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.
Just for interest - is there change of minimal buildroot happened since
F15? Why it was worked before? Was it announced and I miss something?
--
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: Review swap request: moonscript, lua-alt-getopt, lua-inotify
I'm ready to swap on any from my packages awaiting review. I going to reviewing now. 24.08.2011 00:58, Michel Alexandre Salim wrote: Dear contributors, Is anyone interested in some review swaps? These packages should be quite straightforward: moonscript -- moonscript is to Lua what coffeescript is to Javascript (improved syntax, lots of convenience features -- from for-comprehensions to OOP) You need to recompile lua-filesystem and lua-lpeg from Rawhide, but that should be straightforward. They'll be built for F-16 as well, but we're probably not going to build them for F-15 unless requested https://bugzilla.redhat.com/show_bug.cgi?id=731003 lua-alt-getopt -- an alternative getopt module, modeled after BSD's getopt_long (needed by moonscript) https://bugzilla.redhat.com/show_bug.cgi?id=731000 lua-inotify -- inotify bindings for Lua (optional requirement for moonscript) https://bugzilla.redhat.com/show_bug.cgi?id=731001 Thanks, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
php-pear package build problem
Hello. I have couple of bugs with FBFS similar to [1]. At first glance it is trivial - php-config doesn't found [2]. But what interesting, it still there as was in Fedora 15: [pasha@vbox temp]$ repoquery --whatprovides '*/php-config' php-devel-0:5.3.6-2.fc15.i686 [pasha@vbox temp]$ repoquery --disablerepo='*' --enablerepo='rawhide' --whatprovides '*/php-config' php-devel-0:5.3.8-1.fc17.i686 And php-devel BR is explicitly mentioned in spec as: BuildRequires: php-devel = 5.1.0 But what very interesting according to root.log [3] it wasn't pulled, and even no error produced? What happened?? 1 - https://bugzilla.redhat.com/show_bug.cgi?id=715709 2 - http://koji.fedoraproject.org/koji/getfile?taskID=3323691name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=3323691name=build.log 3 - http://koji.fedoraproject.org/koji/getfile?taskID=3323691name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=3323691name=root.log -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bundle question
Hello. I'm review jreen library and there found [1] very interesting issue - psi and kdenetwork bundle iris, jdns [2] and simplesasl. For example: $ find kdenetwork-4.6.5 psi-0.14 -iname simplesasl\* kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.h kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.cpp psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.h psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.cpp Should I fill bugs about it against both? iris (simplesasl its part) is psi [3] library, and as I understand released in it. So I think it may contain it. But how deal with kdenetwork? 1 https://bugzilla.redhat.com/show_bug.cgi?id=731456#c8 2 http://delta.affinix.com/jdns/ 3 http://psi-im.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On 07/06/2011 10:43 PM, Casey Dahlin wrote: On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote: I no longer have a need/care for these packages, they are up for grabs: contacts inotail I'll take inotail. --CJD Just for the note - there tailf util in util-linux package does the same. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick
On 07/04/2011 07:52 PM, Nils Philippsen wrote:
On Mon, 2011-07-04 at 16:33 +0200, Nils Philippsen wrote:
On Mon, 2011-07-04 at 18:10 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
Now ImageMagick built against new gcc.
Great, thanks!
Now that I've rebuilt rss-glx against the new ImageMagick version I see
that it has the same library versions, libMagick{Core,Wand}.so.4 -- it
this rebuilding of our packages really necessary?
Nils
If so, it is on your choose.
But in any case ! strongly recommend do that because upstream maintainer
does not carefully handle soname bump -
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg736218.html
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick
Sorry, but it is postponed [1] probably due to the bug in gcc [2] [1] https://bugzilla.redhat.com/show_bug.cgi?id=715834 [2] https://bugzilla.redhat.com/show_bug.cgi?id=715336 On 07/04/2011 02:10 PM, Nils Philippsen wrote: On Tue, 2011-06-21 at 10:39 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Today or in next few days I'll plan update ImageMagick in rawhide to version 6.7.0-8. And we're still waiting... ;-) Nils -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick
Yes, I seen mistake. Now ImageMagick built against new gcc. On 07/04/2011 03:45 PM, Christophe Fergeau wrote: On Mon, Jul 04, 2011 at 03:25:41PM +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Sorry, but it is postponed [1] probably due to the bug in gcc [2] [1] https://bugzilla.redhat.com/show_bug.cgi?id=715834 [2] https://bugzilla.redhat.com/show_bug.cgi?id=715336 The latter is assigned to gcalctool, this does not look like the right component ;) Christophe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Provenpackager help needed to update js
To fix [1] and [2] dependency rebuild required. Scratch build successful [3], if someone can help on it, I'm ready commit and push changes in git. Rebuild for rawhide and f15 required. [1] https://bugzilla.redhat.com/show_bug.cgi?id=710837 [2] https://bugzilla.redhat.com/show_bug.cgi?id=712304 [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=3155367 -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package drops due to FTBFS
23.06.2011 19:09, Matt Domsch wrote: Below are the of packages which have outstanding FTBFS bugs from earlier Fedora releases. I've split them up by their 'dist' tag which shows when they were last successfully built. I recommend and propose to FESCo that all non-building packages with Fedora 12 and 13 dist tags be considered for dropping prior to branching Fedora 16. Since Fedora 14: agave-0.4.7-1.fc14 [u'631411 NEW'] (build/make) bonii gnusim8085-1.3.6-1.fc14 [u'631067 NEW'] (build/make) sherry151,chitlesh kazehakase-0.5.8-9.svn3873_trunk.fc14 [u'631305 NEW'] (build/make) mtasaka link-grammar-4.6.7-3.fc14 [u'599978 NEW'] (build/make) uwog rubygem-rcov-0.9.8-1.fc14 [u'631350 NEW'] (build/make) mmorsi tilda-0.9.6-4.fc14 [u'631372 NEW'] (build/make) laxathom Jiri Skala mailto:jsk...@redhat.com in that bug propose fix. If some help needed I also interesting to help maintain tilda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Update ImageMagick
Today or in next few days I'll plan update ImageMagick in rawhide to version 6.7.0-8. Dependency should be rebuilt: $ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* a2ps-0:4.14-12.fc15.i686 ale-0:0.9.0.3-5.fc15.i686 autotrace-0:0.31.1-26.fc15.1.i686 autotrace-devel-0:0.31.1-26.fc15.1.i686 calibre-0:0.8.4-1.fc16.i686 cuneiform-0:1.1.0-3.fc16.i686 dblatex-0:0.3-3.fc15.noarch drawtiming-0:0.7.1-4.fc15.i686 dx-0:4.4.4-20.fc16.i686 dx-libs-0:4.4.4-20.fc16.i686 fbida-0:2.07-8.fc15.i686 fvwm-0:2.5.30-4.fc16.i686 gallery2-imagemagick-0:2.3.1-3.fc15.noarch gdl-0:0.9.1-3.fc16.i686 gdl-python-0:0.9.1-3.fc16.i686 geeqie-0:1.0-10.fc16.i686 gnome-exe-thumbnailer-0:0.8-2.fc16.noarch gpsdrive-0:2.11-4.fc16.i686 gscan2pdf-0:0.9.32-1.fc16.noarch gyachi-0:1.2.10-5.fc16.i686 hdrprep-0:0.1.2-7.fc15.noarch html2ps-0:1.0-0.7.b7.fc15.noarch icewm-clearlooks-0:1.2.37-7.fc13.i686 imageinfo-0:0.05-13.fc15.i686 inkscape-0:0.48.1-4.fc16.i686 inkscape-view-0:0.48.1-4.fc16.i686 k3d-0:0.8.0.2-3.fc16.i686 kipi-plugins-0:1.9.0-2.fc16.i686 kxstitch-0:0.8.4.1-6.fc15.i686 latex2rtf-0:2.1.0-2.fc15.i686 libdmtx-utils-0:0.7.2-4.fc15.i686 libpst-0:0.6.52-1.fc16.i686 mediawiki-imagemap-0:0-0.4.r37906.fc15.noarch mediawiki-nomath-0:1.16.5-59.fc16.i686 nautilus-image-converter-0:0.3.1-0.1.git430afce31.fc15.i686 nip2-0:7.22.2-4.fc15.i686 oxine-0:0.7.1-11.fc16.i686 perl-GD-SecurityImage-0:1.70-3.fc15.noarch perl-Image-Size-0:3.2-6.fc15.noarch perl-Panotools-Script-0:0.26-1.fc16.noarch pfstools-0:1.8.3-1.fc16.i686 pfstools-imgmagick-0:1.8.3-1.fc16.i686 phatch-cli-0:0.2.7-5.fc16.noarch php-magickwand-0:1.0.8-9.fc15.i686 php-pecl-imagick-0:3.0.0-9.fc15.i686 picturetile-0:0-5.20050314.fc15.noarch plowshare-0:0.9.4-0.6.svn1414.fc16.noarch psiconv-0:0.9.8-8.fc15.i686 publican-0:2.5-2.fc16.noarch q-magick-0:7.11-10.fc16.i686 renrot-0:1.1-2.fc14.noarch rss-glx-0:0.9.1.p-7.fc15.i686 ruby-RMagick-0:2.13.1-6.fc16.2.i686 shutter-0:0.86.4-2.fc15.noarch spectrum-0:1.4.8-1.fc16.i686 techne-0:0.2.1-1.fc16.i686 tetex-tex4ht-0:1.0.2008_09_16_1413-4.fc15.i686 vips-0:7.24.2-1.fc16.i686 vips-devel-0:7.24.2-1.fc16.i686 vips-python-0:7.24.2-1.fc16.i686 vips-tools-0:7.24.2-1.fc16.i686 w3m-img-0:0.5.2-20.fc15.i686 xastir-1:2.0.0-2.fc16.i686 xine-lib-extras-0:1.1.19-6.fc16.i686 zbar-0:0.10-8.fc15.i686 -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
JS ABI breakage update coming
Hello. Few day ago I asked [1] build js without UTF-8 C strings. But before that was opposite request. As acceptable solution found update to recent version, starting from 1.8.0-rc1 [2]. But it have also known bugs and we move to 1.8.5 version from Firefox 4.0 [3] mercurial repository. 1.8 version introduce runtime UTF-8 support [4]. So, to use new version of js with UTF8 C strings support not enough to just rebuild and relink. Instead you need patch (or better ask upstream to do that) you software to add call function JS_SetCStringsAreUTF8. See [4] for more details. I plan build it today (I have still some troubles in it) and push in rawhide in middle of next week. Also in future it is suggested for F15 branch. In CC owners of dependent packages. [1] https://bugzilla.redhat.com/show_bug.cgi?id=676441 [2] https://developer.mozilla.org/En/SpiderMonkey/1.8 [3] https://developer.mozilla.org/en/javascript [4] https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Reference/JS_CStringsAreUTF8 -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
07.02.2011 23:59, Bill Nottingham wrote: Each release, we undergo the effort to track down owners for orphaned packages in the release, and block those orphaned packages where necessary. It's that time again for Fedora 15. The following packages are currently orphaned and exist in F-15. As you can see, there are a lot of dependencies on these packages. Please pick up these packages if you have a need for them. I took pdfbook -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to filter posts on planet.fedoraproject.org?
16.01.2011 16:21, jonathan MERCIER wrote: Le dimanche 16 janvier 2011 à 16:10 +0300, Pavel Alexeev (aka Pahan-Hubbitus) a écrit : Hello. I'm open for himself planet.fedorapeople.org not so long before. Even try add there my own blog. But I'm wondering how I can filter records which I read via RSS by language!? I want read only English and Russian blog posts. Unfortunately I do not known other languages. But quite half of messages come on Indian, Arabian, Spanish and etc. I always just delete it. But it is serious noise. -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru Hi, me i am french and i wrote my record in english and in french. On the fedora planet - english and on fedora-fr planet - french with your cms you can set the language after on fedorapeople set into .planet file the right rss stream with language like: [http://blog.fedora-fr.org/bioinfornatics/feed/en/atom] see en in url stream and for fedora-fr i change en in fr No, I speak about another side - how I as user read only records on particular languages? Is there any rules for bloggers to behave on similar way as you describe? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: want to contribute to fedora project
Hello. http://fedoraproject.org/en/join-fedora 03.01.2011 02:34, rohit bishnoi wrote: i m rohit bishnoi from india. i have knowledge of c, c++ and java languages. i want to contribute to fedora. plz help me how can i help fedora project.. thnks in advance -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
19.12.2010 23:53, Thibault North пишет: On December 19, 2010 02:56:05 pm Pavel Alexeev (aka Pahan-Hubbitus) wrote: Hello, Thibault. I ready swap and took it. Thanks Pavel. Let me know which one I can review for you. Thibault I'm mos interest in review https://bugzilla.redhat.com/show_bug.cgi?id=598860 , but it may be not so easy, so take any from my requests: https://bugzilla.redhat.com/buglist.cgi?emailtype2=substringemailreporter1=1columnlist=assigned_to,bug_status,resolution,short_descquery_based_on=Review%20requests%20(free%20to%20take%20over)emailtype1=substringquery_format=advancedbug_status=NEWemail2=pahan%40hubbitus.infoemail1=pahan%40hubbitus.infocomponent=Package%20Reviewknown_name=Review%20requests%20(free%20to%20take%20over) https://bugzilla.redhat.com/buglist.cgi?emailtype2=substringemailreporter1=1columnlist=assigned_to,bug_status,resolution,short_descquery_based_on=Review%20requests%20%28free%20to%20take%20over%29emailtype1=substringquery_format=advancedbug_status=NEWemail2=pahan%40hubbitus.infoemail1=pahan%40hubbitus.infocomponent=Package%20Reviewknown_name=Review%20requests%20%28free%20to%20take%20over%29 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to push updates in EPEL6?
Hello, All. Please help someone. How push updates in EPEL6? Is it possible already? I got error after build: $ bodhi -n -b 510864 -R testing -t newpackage -c 'Initial import into Fedora/EPEL' -u hubbitus $(fedpkg verrel) Creating a new update for colorize-0.3.4-2.el6 colorize-0.3.4-2.el6 not tagged as an update candidate -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
Hello, Thibault. I ready swap and took it. 19.12.2010 20:59, Thibault North wrote: Hi packagers, I have an easy package to review: https://bugzilla.redhat.com/show_bug.cgi?id=664298 autojump - A fast way to navigate your filesystem from the command line. Anyone interested in a review swap ? Thanks, Thibault -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: RabbIT
15.12.2010 16:07, Paul Howarth пишет: On 15/12/10 12:57, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Hello, guys. I receive quoted message and can't understand doesn't RHEL 6 contain java?? What I should do with it? 14.12.2010 21:16, build...@fedoraproject.org wrote: RabbIT has broken dependencies in the epel-6 tree: On ppc64: RabbIT-4.1-9.el6.noarch requires java= 1:1.6.0 Please resolve this as soon as possible. RHEL 6 does contain java... except on ppc64. Adding a ppc64-only build in EPEL is under consideration on the EPEL list. Paul. Strange, I wasn't seen that. Do you plan post announcements about decision? -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: RabbIT
Hello, guys. I receive quoted message and can't understand doesn't RHEL 6 contain java?? What I should do with it? 14.12.2010 21:16, build...@fedoraproject.org wrote: RabbIT has broken dependencies in the epel-6 tree: On ppc64: RabbIT-4.1-9.el6.noarch requires java= 1:1.6.0 Please resolve this as soon as possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
09.12.2010 17:46, Tom Callaway wrote: Here are the latest set of changes to the Fedora Packaging Guidelines: --- --- Some clarification has been added to the sections dealing with bundled libraries, specifically that: In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser is specifically exempted from this but this will likely change in the future. https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries JavaScript libraries may be bundled in any way? No additional guidelines for that?? Why? --- The guidelines have been updated to indicate that %doc files must not have executable permissions. https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation Irrelevant documentation include build instructions, the omnipresent/INSTALL/file containing generic build instructions, for example, and documentation for non-Linux systems, e.g./README.MSDOS/. sentence also lack some verbose like should (must?) not be included. How you think? -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
26.11.2010 11:38, Ralf Corsepius wrote: On 11/25/2010 11:24 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Furthermore, step to reproduce also is very important, and may be we should enforce users fill it? This doesn't seem a clever idea to me, because at least for me, many abrt alerts originate from breakdowns without any obvious direct user-interaction involved. Demanding a reproducer for this incidents is hardly possible. Ralf Good catch. I did not thin about this case. For that may be provided checkbox like it happened without my interaction, don't known. In conjunction with possibility set by maintainer accept such reports for particular package or not it will be cool. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
04.11.2010 06:10, Orcan Ogetbil wrote: On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote: On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote: On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote: On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote: Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is. I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'. Does it compare to this number? (it takes a while to open) http://tinyurl.com/39yr832 Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :) I am pretty sure a subset of these closed bugs are mass-closing of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say it may be fixed, just update and try. You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY! Orcan I think abrt is mostly useful tool, but it should be more interactive to our users. No, most problem from it (at my experience and by other answers there) because we got many reports dead at begining. Users encountered fill bug report, but if it is new user, it in 90% cases even do not answer on question how it may be reproduced. I assume it is main bad there. Can we add functionality track user bugreports and allow answer on requests (as minimum with 'needinfo' state) directly from abrt?? I think it may serious increase percentage of usefull bug reports from abrt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla bugzappers?
26.11.2010 00:43, Brendan Jones пишет: On 11/25/2010 11:38 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: I think abrt is mostly useful tool, but it should be more interactive to our users. No, most problem from it (at my experience and by other answers there) because we got many reports dead at begining. Users encountered fill bug report, but if it is new user, it in 90% cases even do not answer on question how it may be reproduced. I assume it is main bad there. Can we add functionality track user bugreports and allow answer on requests (as minimum with 'needinfo' state) directly from abrt?? I think it may serious increase percentage of usefull bug reports from abrt. I think I agree with what you are saying - would be nice for bugzappers to be able to filter out [abrt] bugs without debug symbols and steps to reproduce - has anyone done this? If not I could probably have a crack at it using the bugzilla commandline over the weekend. Main suggestion meantime was to continue dialog with user directly via abrt. It fill it via abrt and save credential. If I request something from user - abrt should show it information for user and provide possibility (at least) answer immediately. Furthermore, step to reproduce also is very important, and may be we should enforce users fill it? For example put it in separate required field and check it is not empty (or may be some minimal heuristic against fill it like '123', 'qwerty', 'qaz' like: longer than 10 symbols, contains at least 2 spaces). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphan most of my packages
Thank you. I'll look what I can do with it. Unfortunately I'm not python developer. 17.10.2010 23:44, Andy Shevchenko пишет: In the attachment a few patches which were not included in the Fedora yet. I don't remember for which version they are and what usefulness of them, but just in case I send them to you. On Sun, Oct 10, 2010 at 7:29 PM, Robin Leerobinlee.s...@gmail.com wrote: python-alsa is taken by 'cheeselee' On Sun, Oct 10, 2010 at 10:13 PM, Andy Shevchenko andy.shevche...@gmail.com wrote: Hello, I have no more time to support the following packages in the Fedora. jack-audio-connection-kit -- The Jack Audio Connection Kit klamav -- Clam Anti-Virus on the KDE Desktop man-pages-uk -- Ukrainian man pages from the Linux Documentation Project python-alsa -- Python binding for the ALSA library qstat -- Real-time Game Server Status for FPS game servers uniconvertor -- Universal vector graphics translator -- With Best Regards, Andy Shevchenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
13.10.2010 03:07, Jesse Keating пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/8/10 7:03 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: In most cases I try sync all branches if there no real reasons to make differences. After made some changes in origin/master and commit is I also must do for each available branches something similar: fedpkg switch-branch el5; git pull git merge origin/master git push fedpkg build fedpkg update Off course I can script it with shell, but may be there already possibility to commit in few branches? Something like this: fedpkg commit -F clog -B f12,f13,f14,el5,el6 And will be very cool to start build and push updates (by single template interactively filled one time) also for several branches. I believe there is already a filed RFE for this in fedpkg, and if not it is on my mind for future functionality. I want fill it, but bugzilla even do not contain such component as fedpkg. Why? I have filled it https://fedorahosted.org/fedora-packager/ticket/80 - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky06kcACgkQ4v2HLvE71NXfMACgx4uftMi8pnyYCJSzr7Lt0IJu N1gAnjDA1wn2/qqiSJSjMlNftJXr0kjK =t82w -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Something similar to http://susestudio.com/
15.10.2010 11:00, Rahul Sundaram пишет: On 10/12/2010 11:54 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Subject. Have Fedora/RHEL service similar http://susestudio.com/ ? May be plans to create it? Just for information. https://fedorahosted.org/dorrie/ does some of the basic stuff. Looks cool at first glance. Does Redhat plan do similar service on it? It will be cool if it became available for Fedora also, not just RHEL. I think it requires cloud to function as public service and it very hard to do so in community without sponsorship. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
Unfortunately it is not what I initially ask :( 12.10.2010 19:14, matt_dom...@dell.com wrote: Correct, it's simply a git merge specifying the merge method, to ensure there are no merge conflicts - just make an exact copy of the origin/master branch onto the current branch. You must still 'fedpkg switch-branch' before invoking this. -- Matt Domsch Technology Strategist Dell | Office of the CTO -Original Message- From: Pavel Alexeev (aka Pahan-Hubbitus) [mailto:fo...@hubbitus.com.ru] Sent: Tuesday, October 12, 2010 3:07 AM To: Domsch, Matt Subject: Re: Git commit in all available branches 11.10.2010 05:28, Matt Domsch пишет: On Fri, Oct 08, 2010 at 06:03:04PM +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: In most cases I try sync all branches if there no real reasons to make differences. After made some changes in origin/master and commit is I also must do for each available branches something similar: fedpkg switch-branch el5; git pull git merge origin/master git push fedpkg build fedpkg update I find this works to apply the version from 'master' into the current (say, el5) branch. $ git merge -s recursive -X theirs master Sorry, I think does not understand you. Where I can there provide on what branches I want do that?? On first glance it us mostly equivalent of present before git merge origin/master with additional strategy option only. I've read git-merge man, but still does not understand how it helps. Please describe slightly. There are valid reasons for doing this - e.g. a bug fix release of a package by the upstream, that doesn't break the ABI. Thanks, Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Something similar to http://susestudio.com/
Subject. Have Fedora/RHEL service similar http://susestudio.com/ ? May be plans to create it? Just for information. -- With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact with me you could use Jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphan most of my packages
I took uniconvertor it is needed for ImageMagick. 10.10.2010 18:13, Andy Shevchenko wrote: Hello, I have no more time to support the following packages in the Fedora. jack-audio-connection-kit -- The Jack Audio Connection Kit klamav -- Clam Anti-Virus on the KDE Desktop man-pages-uk -- Ukrainian man pages from the Linux Documentation Project python-alsa -- Python binding for the ALSA library qstat -- Real-time Game Server Status for FPS game servers uniconvertor -- Universal vector graphics translator -- With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact with me you could use Jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Git commit in all available branches
In most cases I try sync all branches if there no real reasons to make differences. After made some changes in origin/master and commit is I also must do for each available branches something similar: fedpkg switch-branch el5; git pull git merge origin/master git push fedpkg build fedpkg update Off course I can script it with shell, but may be there already possibility to commit in few branches? Something like this: fedpkg commit -F clog -B f12,f13,f14,el5,el6 And will be very cool to start build and push updates (by single template interactively filled one time) also for several branches. -- With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact with me you could use Jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
Try verbose variant to figure out what happened: $ fedpkg -v scratch-build 06.10.2010 13:19, Farkas Levente wrote: hi, while try to make a scratch build i always got: - # fedpkg scratch-build Could not log into koji: Opening a SSL connection failed - even if i try to remove .fedora.cert and fedora-packager-setup (so it's not a certificate problem). what else can be the reason? thanks in advance. regards. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora and webserver dependency
04.10.2010 14:49, Jan Kaluza wrote: Hi, there are over 100 packages which Require: httpd and it looks they are preconfigured only for httpd. However, Fedora contains more webservers than apache (httpd) and it's currently impossible (as far as I know) to install for example php (phpMyAdmin, wordpress, ...) if you want to use lighttpd instead of httpd, because yum install php installs also httpd. You then have to disable httpd by chkconfig httpd off, but there's no way to have PHP installed without httpd. I think one solution is to use webserver virtual package instead of Require: httpd. Of course it's OK to use Require: httpd in packages which really needs httpd and can't work with another webserver, but otherwise I think webserver virtual package should be used. It was discussed not so long in past. I agree absolutely. But there also present small problem - many packages includes Apache virtual hosts configuration, .htaccess settings and some similar stuff targeted only for Apache. In most cases it is not so hard to implement similar settings for example for Ngnix and Lighthttpd... But, do we have rights require such implementation for all present webservers from package maintainer? In any case it additional work and requires additional skills. What if new webserver will appear in repos? Another problem is that each webserver in Fedora uses different username/group. If you have application which stores some private data which should be accessible for that application and for webserver, but not for another users, you have to use something like chown your_app_username:webserver_group private_directory. This is not doable when webserver group is different for each webserver, so you have to support *just* one webserver in .spec file or loose the security. Can't we use single username/group for all webserver? Regards, Jan Kaluza -- With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact with me you could use Jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libnotify issue on F14 and rawhide
I have packaged xneur, which on review [1] and its build fine on Fedora
12 and 13. On Fedora 14 it is failed [2] with error:
/usr/include/libnotify/notification.h:28:21: fatal error: gtk/gtk.h: No such
file or directory
I try figure out what happened and go step by step add includes in
CFLAGS like:
make %{?_smp_mflags} CFLAGS=%{optflags} -I%{_includedir}/gtk-2.0
after many attempts and googling I finally arrived to:
make %{?_smp_mflags} CFLAGS=%{optflags} %( pkg-config --cflags --libs
gtk+-2.0 )
which work like a charm.
But I can't understand why I should provide it manually and why it does
not required in previous releases?
I slightly dig more and found it happened on linking with libnotify
library. And finaly result:
On Fedora 13:
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
On Fedora 14 (f14-test.scrye.com):
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
Should I fill bug on libnotify or it is the expected behavior?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=623604
[2]
http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libnotify issue on F14 and rawhide
24.09.2010 13:27, Mamoru Tasaka пишет:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/24/2010 06:11 PM +9:00:
I have packaged xneur, which on review [1] and its build fine on Fedora 12
and 13. On Fedora 14 it is failed [2] with error:
/usr/include/libnotify/notification.h:28:21: fatal error: gtk/gtk.h: No such
file or directory
I try figure out what happened and go step by step add includes in CFLAGS
like:
make %{?_smp_mflags} CFLAGS=%{optflags} -I%{_includedir}/gtk-2.0
after many attempts and googling I finally arrived to:
make %{?_smp_mflags} CFLAGS=%{optflags} %( pkg-config --cflags --libs
gtk+-2.0 )
which work like a charm.
But I can't understand why I should provide it manually
and why it does not required in previous releases?
I slightly dig more and found it happened on linking with libnotify library.
And finaly result:
On Fedora 13:
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
On Fedora 14 (f14-test.scrye.com):
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
Should I fill bug on libnotify or it is the expected behavior?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=623604
[2] http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
This change on libnotify is intentional.
http://git.gnome.org/browse/libnotify/commit/?id=0eb56b2fcf16d5381011e0bae2cf942416dae55c
https://bugzilla.gnome.org/show_bug.cgi?id=622550
How I should deal with it?
Is it normal add such parameters in make or in configure (%configure
LIBNOTIFY_CFLAGS=%( pkg-config --cflags libnotify = 0.4.0 gtk+-2.0
) LIBNOTIFY_LIBS=%( pkg-config --libs libnotify = 0.4.0 gtk+-2.0 ))?
And what is also very strange and interesting. When build failed with
fatal error: gtk/gtk.h: No such file or directory if I go in builddir
and manually invoke last command:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/config -I../../lib/misc
-I../../lib/lib -Wall -Wextra -Werror -g0 -std=gnu99 -fPIC -pthread
-I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -I/usr/include
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c sound.c -fPIC -DPIC -o
.libs/libxnnotify_la-sound.o
compilation fine done without any problem. How it find all includes? And
why it is not happened in rpmbuild process?
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick soname bump for F14
Hello. 16.09.2010 18:35, Orion Poplawski wrote: Do we really want to do this, especially for a FTBS issue presumably against F15? https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14 If we in dialogue in update may be continue in one place is good decision? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick soname bump for F14
17.09.2010 12:56, Mamoru Tasaka wrote:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/17/2010 05:10 PM +9:00:
16.09.2010 18:35, Orion Poplawski wrote:
Do we really want to do this, especially for a FTBS issue presumably
against F15?
https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14
Please excuse me what I did not ask early. Now I call to maintainers of
dependent packages - please rebuild it against new version of ImageMagick.
Well, currently:
$ koji latest-pkg dist-f14-build ImageMagick
Build Tag Built by
ImageMagick-6.6.2.1-11.fc14 dist-f14 mtasaka
So to build against dist-f14-updates-candidate newest
ImageMagick-6.6.4.1-13.fc14, this ImageMagick should be tagged as
override by rel-eng team.
Regards,
Mamoru
Thanks, I fill request https://fedorahosted.org/rel-eng/ticket/4115
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick soname bump for F14
17.09.2010 12:56, Mamoru Tasaka пишет:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/17/2010 05:10 PM +9:00:
16.09.2010 18:35, Orion Poplawski wrote:
Do we really want to do this, especially for a FTBS issue presumably
against F15?
https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14
Please excuse me what I did not ask early. Now I call to maintainers of
dependent packages - please rebuild it against new version of ImageMagick.
Well, currently:
$ koji latest-pkg dist-f14-build ImageMagick
Build Tag Built by
ImageMagick-6.6.2.1-11.fc14 dist-f14 mtasaka
So to build against dist-f14-updates-candidate newest
ImageMagick-6.6.4.1-13.fc14, this ImageMagick should be tagged as
override by rel-eng team.
Regards,
Mamoru
Currently it tagged as override. So, we can continue build dependencies.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick soname bump for F14
16.09.2010 18:35, Orion Poplawski wrote: Do we really want to do this, especially for a FTBS issue presumably against F15? https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14 Please excuse me what I did not ask early. Now I call to maintainers of dependent packages - please rebuild it against new version of ImageMagick. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
26.08.2010 18:34, Chen Lei пишет: I've have several review requests that have been sitting around for a while now. Many of them are new dependencies for existing packages in fedora, anyone want to swap? EmfEngine(new dep for qtiplot 0.9.8.1): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=618480 I'll try review it today. If found more time, may be some others too if no-one take it before. libqmf (dep for qt-mobility): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=626122 contextkit(optional dep for qt-mobility): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=613881 libqttracker(optional dep for qt-mobility): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=614075 Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Question about sane usage of macroses in perl template
$ rpmdev-newspec -t perl
produce template where, inter alia we have such lines:
%{__perl} Makefile.PL INSTALLDIRS=vendor
OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
I'm wonder why there used mix of macros %{__perl} and plain other
commands like make?
Rpm say it is just perl command with path:
$ rpm --eval '%{__perl}'
/usr/bin/perl
Is there any advantage for that?
Many reviewers say what one form should be used if no explicit
requirements for other way.
Also we have Review Guidelins which say usage of macroses should be
consistent -
http://fedoraproject.org/wiki/Packaging:ReviewGuidelines#cite_note-15.
At my point it is example of such inconsistent there.
--
With best wishes, Pavel Alexeev aka Pahan-Hubbitus.
For fast contact with me you could use Jabber: hubbi...@jabber.ru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about sane usage of macroses in perl template
27.08.2010 13:08, Petr Pisar ?:
On 2010-08-27, Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru
wrote:
%{__perl} Makefile.PL INSTALLDIRS=vendor
OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
I'm wonder why there used mix of macros %{__perl} and plain other
commands like make?
Because you cannot have macro for each shell command. (Actually you can,
but it would be silly). Personally, I don't like aliasing macros and
I prefer direct commands as it's simpler and more readable.
Actually macroses present for most used commands and I also now prefer
plain comments in spec. But it is not main question.
Rpm say it is just perl command with path:
$ rpm --eval '%{__perl}'
/usr/bin/perl
Is there any advantage for that?
Probably perl interpreter had been in other location or under diferrent
name before. (E.g. transition between two incompatible perl versions).
This macro could be used to make easy the transition for package
maintainers. Or there had been used some addition perl arguments (like
-w). Or the macro was defined to allow spec file sharing between
distributions with different perl locations.
However this is just speculation. You need to ask the guy how invented
the macro. (It wasn't me :)
Off course. But question inspired by review
https://bugzilla.redhat.com/show_bug.cgi?id=627024#c2 where main
argument of its usage what it is some sort of standard because it used
in template.
https://bugzilla.redhat.com/show_bug.cgi?id=627024#c2
-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question about sane usage of macroses in perl template
27.08.2010 13:58, Ralf Corsepius пишет:
On 08/27/2010 10:28 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
$ rpmdev-newspec -t perl
produce template where, inter alia we have such lines:
%{__perl} Makefile.PL INSTALLDIRS=vendor
OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
I'm wonder why there used mix of macros %{__perl} and plain other
commands like make?
Rpm say it is just perl command with path:
$ rpm --eval '%{__perl}'
/usr/bin/perl
Is there any advantage for that?
You are missing the point:
%__perl is being used to derive a whole zoo of %defines, which required
to keep perl-module packages consistent - make doesn't.
E.g. all perl-module packages something similar to this:
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
...
%{__perl} Makefile.PL INSTALLDIRS=vendor
...
%{perl_vendorlib}
Also we have Review Guidelins which say usage of macroses should be
consistent -
Correct ... when using one macro, it must be used consistently
throughout a *.spec, otherwise your package will not build correctly
should a macro change.
In other words, when using %__perl, you must use it everywhere inside of
your *.spec. As %__perl is being used inside of the default rpm macros,
not using %__perl almost always will be wrong.
Ok, but why not use plain perl?
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
I took csstidy. 04.08.2010 20:32, Bill Nottingham wrote: Each release, we undergo the effort to track down owners for orphaned packages in the release, and block those orphaned packages where necessary. It's that time again for Fedora 14. The following packages are currently orphaned and exist in F-14. As you can see, there are a lot of dependencies on these packages. Please pick up these packages if you have a need for them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all my packages
I add himself as co-maintainer of php-pecl-xdebug. And If you want, can help with some more packages. Please say, if you want. Primarily it may be: php-pear-Structures-DataGrid*. 11.08.2010 21:19, Remi Collet wrote: Le 11/08/2010 18:32, Christopher Stone a écrit : Im no longer maintaining all my packages Do whatever you need to do to orphan them or open them up. Thanks Bye. The Full list: https://admin.fedoraproject.org/pkgdb/users/packages/xulchris I will take all the PHP stuff because I have already update some of them as I was aware of the lack of interest of Chris. co-maintainers welcome. If somebody want to own one of them, just ask. I just want to have no orphan package in the LAMP stack. php-Smarty php-channel-phpunit php-pear-Auth-RADIUS php-pear-Benchmark php-pear-Crypt-CHAP php-pear-DB-DataObject php-pear-DB-DataObject-FormBuilder php-pear-DB-QueryTool php-pear-Date php-pear-Date-Holidays php-pear-Date-Holidays-USA php-pear-File php-pear-File-Passwd php-pear-File-SMBPasswd php-pear-HTML-Common php-pear-HTML-QuickForm HTML forms php-pear-HTML-QuickForm-ElementGrid php-pear-HTML-Table php-pear-HTTP-Client php-pear-HTTP-Request php-pear-HTTP-Upload php-pear-Image-Canvas php-pear-Image-Color php-pear-Image-Graph php-pear-Image-GraphViz php-pear-MDB2 php-pear-MDB2-Driver-mysql php-pear-Math-Stats php-pear-Net-Curl php-pear-Net-POP3 php-pear-Net-URL php-pear-Net-URL-Mapper php-pear-Net-UserAgent-Detect php-pear-Numbers-Roman php-pear-Numbers-Words php-pear-Pager php-pear-Payment-Process php-pear-Structures-DataGrid php-pear-Structures-DataGrid-DataSource-Array php-pear-Structures-DataGrid-DataSource-DataObject php-pear-Structures-DataGrid-DataSource-MDB2 php-pear-Structures-DataGrid-DataSource-RSS php-pear-Structures-DataGrid-Renderer-Pager php-pear-Structures-DataGrid-Renderer-Smarty php-pear-Validate php-pear-Validate-Finance-CreditCard php-pear-XML-Beautifier php-pear-XML-RSS php-pear-XML-Serializer php-pecl-radius -- Radius client library php-pecl-xdebug -- PECL package for debugging PHP scripts Except obsolete ones php-pear-XML-Util (move to php-pear) php-pear-PHPUnit (rename to php-phpunit-PHPUnit) P.S. I discuss with Chris on IRC. He have no password to connect to pkgdb and orphan this package (and no time for...) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedpkg error
I think it because name of package contain plus sign: $ fedpkg -v clone DivFix++ Cloning ssh://hubbi...@pkgs.fedoraproject.org/DivFix++ Running git clone ssh://hubbi...@pkgs.fedoraproject.org/DivFix++ directly on the tty Cloning into DivFix++... bad command: git-upload-pack '/DivFix ' fatal: The remote end hung up unexpectedly Could not clone: Command '['git', 'clone', 'ssh://hubbi...@pkgs.fedoraproject.org/DivFix++']' returned non-zero exit status 128 Should I fill bugreport? Or what I can do with it? -- With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact with me you could use Jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
08.07.2010 00:29, Tom spot Callaway пишет: Hello Fedora! Please take a moment and read this email. There's cake in it for you. Upon the advice of Red Hat Legal, we have slightly amended the Fedora Licensing Guidelines (https://fedoraproject.org/wiki/Packaging:LicensingGuidelines). The following section has been added: Subpackage Licensing [snip] I check dnsjava and it at all have not license file in tarball and main package. In ImageMagick-doc LICENSE file added. Now I can't commit in CVS, I think it because I should use git now. When I understand how use it I'll do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DMitry
19.06.2010 20:34, Ian Baker ?: Hello to all. The subject package is currently orphaned and I'm thinking of taking it over. One problem I can foresee is that, as far as I can tell, there's no longer an upstream maintainer and at least one patch is required to fix compilation issues (warnings) and the code needs a general tidy-up. I could maintain the patches locally, or as a small pet project I could take over upstream maintenance which shouldn't require much work as the codebase is small. Any suggestions and advice would be appreciated and I'm new so please go easy! Thanks. Ian In the similar situation with dead upstream of trafshow I was told became upstream developer for it if I want see it in Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=510651 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inclusion user rpm macros file in spec
30.05.2010 21:19, Pavel Alexeev (aka Pahan-Hubbitus) ?:
21.05.2010 20:58, Panu Matilainen ?:
On Fri, 21 May 2010, Kevin Kofler wrote:
Pavel Alexeev (aka Pahan-Hubbitus) wrote:
I think because macroses should be included before it processed as shell
script.
Is there some variant of %include or similar?
AFAIK, no. E.g. in kde-filesystem, we end up defining things twice, once for
the specfile itself and once for the .macros file:
http://cvs.fedoraproject.org/viewvc/rpms/kde-filesystem/devel/kde-filesystem.spec?revision=1.49view=markup
And neither of you actually thought to try whether %include works? :D
Hint: it does, in spec files.
- Panu -
Thanks for the answers.
Panu, you are sure? I try, and rpmbuild encountered error -
https://bugzilla.redhat.com/show_bug.cgi?id=597835
Sorry for the answer to themselves.
Now, when bug fixed and rpm hit rawhide I can continue test it
suggestion. And it does not work on strange manner - it is not produce
any error, but also does nothing!
So, in minimal spec file was attached in the bug I have now in %prep:
%include %{SOURCE0}
%{testmacros}
exit 102
And at build time no TEST appeared:
$ LANG=C rpmbuild -ba test.spec
+ umask 022
+ cd /home/pasha/SOFT/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ exit 102
error: Bad exit status from
/home/pasha/SOFT/rpmbuild/BUILD/_tmp/rpm-tmp.ECc7qg (%prep)
Bad exit status from
/home/pasha/SOFT/rpmbuild/BUILD/_tmp/rpm-tmp.ECc7qg (%prep)
Please, can you more describe how it should work? What is prerequisites?
May be link on detailed explanation?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ImageMagick update
Hello.
I'm plan update ImageMagick to 6.6.2-0 version in rawhide (
https://bugzilla.redhat.com/show_bug.cgi?id=579458).
Soname bump coming, so, rebuild dependent packages required.
Sorry if it is not interested for you, I sent mail to all from:
repoquery --repoid=rawhide --whatrequires ImageMagick\*
--qf='%{name}-ow...@fedoraproject.org,'
--
With best wishes, Pavel Alexeev aka Pahan-Hubbitus.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: ImageMagick update
22.05.2010 17:28, Hans de Goede пишет:
Hi,
On 05/17/2010 03:13 AM, Chen Lei wrote:
2010/5/16 Pavel Alexeev (aka Pahan-Hubbitus)fo...@hubbitus.com.ru
mailto:fo...@hubbitus.com.ru
About ABI breakage there separate problem in ImageMagick -
http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg736218.html
So, upstream is not carefully there and I never can't guarantee what
there no ABI breakage in any update...
P.S. It seams it does not hit list, i post mail again. It is reason
such big delay...
--
Normally, if the update is a pure bugfix release, it's safe to update
and don't need a rebuild, and you should update them on rawhide as well
as stable branches to fix bugs
If API/ABI is changed, only the following packages need a rebuild.
Packages depends on ImageMagick itself actually don't need a rebuild
even the API is changed.
Wrong, the main ImageMagick provides libs too, on F-13 the full list is:
[h...@localhost anaconda]$ repoquery -q --whatrequires
'libMagickCore.so.2()(64bit)' 'libMagickWand.so.2()(64bit)'
'libMagick++.so.2()(64bit)'
ruby-RMagick-0:2.13.1-1.fc13.1.x86_64
ImageMagick-djvu-0:6.5.8.10-6.fc13.x86_64
vips-tools-0:7.20.7-1.fc13.x86_64
rss-glx-0:0.9.1.p-2.fc13.x86_64
q-magick-0:7.11-6.fc12.x86_64
nip2-0:7.20.7-3.fc13.x86_64
ale-0:0.9.0.3-2.fc12.x86_64
zbar-0:0.10-2.fc13.x86_64
psiconv-0:0.9.8-5.fc12.x86_64
xastir-1:1.9.6-3.fc13.x86_64
ImageMagick-c++-0:6.5.8.10-6.fc13.x86_64
ImageMagick-perl-0:6.5.8.10-6.fc13.x86_64
vips-0:7.20.7-1.fc13.x86_64
autotrace-0:0.31.1-23.fc12.x86_64
inkscape-view-0:0.47-6.fc13.x86_64
k3d-0:0.8.0.1-1.fc13.x86_64
drawtiming-0:0.7.1-1.fc13.x86_64
dx-libs-0:4.4.4-15.fc13.x86_64
dx-0:4.4.4-15.fc13.x86_64
pfstools-0:1.8.1-1.fc13.x86_64
gdl-python-0:0.9-0.10.rc4.fc13.x86_64
oxine-0:0.7.1-6.fc13.x86_64
xine-lib-extras-0:1.1.18.1-1.fc13.x86_64
transcode-0:1.1.5-4.fc13.x86_64
ImageMagick-devel-0:6.5.8.10-6.fc13.x86_64
imageinfo-0:0.05-10.fc12.x86_64
vips-python-0:7.20.7-1.fc13.x86_64
calibre-0:0.6.42-1.fc13.x86_64
pfstools-imgmagick-0:1.8.1-1.fc13.x86_64
php-pecl-imagick-0:2.2.2-4.fc12.x86_64
inkscape-0:0.47-6.fc13.x86_64
php-magickwand-0:1.0.8-4.fc12.x86_64
k3d-0:0.7.11.0-6.fc13.x86_64
gdl-0:0.9-0.10.rc4.fc13.x86_64
zbar-0:0.10-2.fc13.x86_64
transcode-0:1.1.5-4.fc13.x86_64
ImageMagick-devel-0:6.5.8.10-6.fc13.x86_64
vips-python-0:7.20.7-1.fc13.x86_64
calibre-0:0.6.42-1.fc13.x86_64
ImageMagick-c++-0:6.5.8.10-6.fc13.x86_64
vips-tools-0:7.20.7-1.fc13.x86_64
rss-glx-0:0.9.1.p-2.fc13.x86_64
vips-0:7.20.7-1.fc13.x86_64
php-magickwand-0:1.0.8-4.fc12.x86_64
oxine-0:0.7.1-6.fc13.x86_64
nip2-0:7.20.7-3.fc13.x86_64
xine-lib-extras-0:1.1.18.1-1.fc13.x86_64
php-pecl-imagick-0:2.2.2-4.fc12.x86_64
inkscape-0:0.47-6.fc13.x86_64
k3d-0:0.8.0.1-1.fc13.x86_64
ImageMagick-c++-devel-0:6.5.8.10-6.fc13.x86_64
drawtiming-0:0.7.1-1.fc13.x86_64
pfstools-imgmagick-0:1.8.1-1.fc13.x86_64
gdl-python-0:0.9-0.10.rc4.fc13.x86_64
pfstools-0:1.8.1-1.fc13.x86_64
k3d-0:0.7.11.0-6.fc13.x86_64
inkscape-view-0:0.47-6.fc13.x86_64
gdl-0:0.9-0.10.rc4.fc13.x86_64
repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick-c++
ImageMagick-c++-0:6.6.0.2-8.fc14.i686
ImageMagick-c++-0:6.6.0.2-8.fc14.x86_64
inkscape-0:0.48-0.2.20100505bzr.fc14.x86_64
ImageMagick-c++-devel-0:6.6.0.2-8.fc14.x86_64
gdl-0:0.9-0.12.rc4.fc14.x86_64
pfstools-imgmagick-0:1.8.1-1.fc14.x86_64
drawtiming-0:0.7.1-1.1.fc14.x86_64
pfstools-0:1.8.1-1.fc14.x86_64
ImageMagick-c++-devel-0:6.6.0.2-8.fc14.i686
k3d-0:0.8.0.1-1.fc14.x86_64
gdl-python-0:0.9-0.12.rc4.fc14.x86_64
inkscape-view-0:0.48-0.2.20100505bzr.fc14.x86_64
BTW, some subpackages contain .la files, you should remove them in %install.
e.g.
This is not necessarily good advice either:
1) As these la files are for plugins which are located outside of %{_libdir},
they do no harm
2) In the past there have been cases with plugins where the libraries plugins
loading mechanism relies on the .la files being present, that might very well
be the case here.
Regards,
Hans
Very interesting.
Actually spec file contain string to delete in root build directory:
rm $RPM_BUILD_ROOT%{_libdir}/*.la
What can happened bad if I do:
find $RPM_BUILD_ROOT -type f -name *.la -exec rm -f {} \;
as Chen Lei suggested before?
Actually I done that, but update is not pushed yet.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update
30.05.2010 19:22, Mamoru Tasaka пишет:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 05/30/2010 11:59 PM +9:00:
22.05.2010 17:28, Hans de Goede пишет:
This is not necessarily good advice either:
1) As these la files are for plugins which are located outside of
%{_libdir},
they do no harm
2) In the past there have been cases with plugins where the libraries
plugins
loading mechanism relies on the .la files being present, that might very
well
be the case here.
Regards,
Hans
Very interesting.
Actually spec file contain string to delete in root build directory:
rm $RPM_BUILD_ROOT%{_libdir}/*.la
What can happened bad if I do:
find $RPM_BUILD_ROOT -type f -name *.la -exec rm -f {} \;
as Chen Lei suggested before?
Actually I done that, but update is not pushed yet.
At least you have to check if removing libtool files in module directory
won't raise this issue again:
https://bugzilla.redhat.com/show_bug.cgi?id=185237
Awesome!
$ convert -list format | wc -l
7
Mamoru, very thank you! I add comment in spec now with link to that bug
to do not miss it in the future!
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Inclusion user rpm macros file in spec
21.05.2010 20:58, Panu Matilainen ?: On Fri, 21 May 2010, Kevin Kofler wrote: Pavel Alexeev (aka Pahan-Hubbitus) wrote: I think because macroses should be included before it processed as shell script. Is there some variant of %include or similar? AFAIK, no. E.g. in kde-filesystem, we end up defining things twice, once for the specfile itself and once for the .macros file: http://cvs.fedoraproject.org/viewvc/rpms/kde-filesystem/devel/kde-filesystem.spec?revision=1.49view=markup And neither of you actually thought to try whether %include works? :D Hint: it does, in spec files. - Panu - Thanks for the answers. Panu, you are sure? I try, and rpmbuild encountered error - https://bugzilla.redhat.com/show_bug.cgi?id=597835 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update
03.05.2010 03:37, Orcan Ogetbil пишет: On Sun, May 2, 2010 at 7:20 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: 26.04.2010 05:04, Orcan Ogetbil пишет: On Sun, Apr 25, 2010 at 7:13 PM, Kevin Kofler wrote: Christoph Wickert wrote: repoquery --disablerepo=\* --enablerepo=rawhide --whatrequires ImageMagick FYI, repoquery --repoid=rawhide --whatrequires ImageMagick does the trick too. That does not detect packages that require ImageMagick-c++, ImageMagick-perl etc. The wildcard \* seems to work. So it would be good to run a command to include the subpackages of ImageMagick, with the --alldeps flag, e.g. $ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* etc Orcan It produce big list of packages, thank you. What about second part of my questions? How frequently I should (can) update package? There was a huge debate about the updating packages policy in the last months in this list. I don't think there is a unique answer to this question. I would say, it is left to the decision of the maintainer. It all comes down how big the update is. * Suppose there is a big API/ABI change: If you believe that you can deal with rebuilding all the dependent packages, and support them all in stable branches, go ahead and update. Otherwise update only in rawhide and let people know that they need to rebuild their packages, or rebuild them yourself. * Just a bugfix release, with no API/ABI breakage: In this case it should be safe to update. I tried to answer the question as neutral as possible as I don't want to restart the bitchfest. Orcan Thank you, Orcan. And off course I do not want any holly-war. I just wonder about frequently of upstream releases (as I say before around one in week). Is it normal update it in rawhide each time? About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg736218.html So, upstream is not carefully there and I never can't guarantee what there no ABI breakage in any update... P.S. It seams it does not hit list, i post mail again. It is reason such big delay... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Inclusion user rpm macros file in spec
Hello, All!
I'm want share some rpm macros across few packages.
Try add it in separate file as source and install as devel file in package.
For example simple file, say testmacros as Source1 with next content:
%define testmacro() %{expand:%( echo TEST )}
Then, in spec file include it:
source %{SOURCE1}
but get error:
+ source testmacros
testmacros: line 1: syntax error near unexpected token `('
I think because macroses should be included before it processed as shell
script.
Is there some variant of %include or similar?
--
With best wishes, Pavel Alexeev aka Pahan-Hubbitus.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update
16.05.2010 19:35, Orcan Ogetbil пишет: On Sun, May 16, 2010 at 11:14 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: I just wonder about frequently of upstream releases (as I say before around one in week). Is it normal update it in rawhide each time? About ABI breakage there separate problem in ImageMagick - http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg736218.html So, upstream is not carefully there and I never can't guarantee what there no ABI breakage in any update... Hi Pavel, It should be okay to update stuff in rawhide, but you probably need to give time to maintainers to rebuild their packages before branchings (for example, to F-14) or rebuild them yourself. Is the upstream not bumping the soname when they change the ABI? That's not very nice. Is there no way to educate them? You can use Debian's unresolved symbols detection script that is mentioned in the above link. I would say, rebuilding 30(?) packages every other week just for an ImageMagick update would be impractical, even if it is done in rawhide only. If you are not comfortable with detecting the ABI breakage, or if you can't dedicate enough time, I recommend to update every 2-3 months. Let's hear what others will say. Orcan Thank you very much for the answers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 yum in kvm or vmware guests
06.05.2010 01:40, Warren Togami ?: (10/12): samba-3.5.2-60.fc13.x86_64.rpm (71%) 73% [- ] 0.0 B/s | 3.7 MB 3340883129410265958989882401668816722716705737932:48 ETA Anyone else seeing this kind of behavior with F-13 yum within kvm or vmware guests? It seems to happen consistently here in the middle of downloading multiple packages where I need to kill yum and try again. Warren I saw this on real machine and bug was filled: https://bugzilla.redhat.com/show_bug.cgi?id=575743 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update
26.04.2010 05:04, Orcan Ogetbil пишет: On Sun, Apr 25, 2010 at 7:13 PM, Kevin Kofler wrote: Christoph Wickert wrote: repoquery --disablerepo=\* --enablerepo=rawhide --whatrequires ImageMagick FYI, repoquery --repoid=rawhide --whatrequires ImageMagick does the trick too. That does not detect packages that require ImageMagick-c++, ImageMagick-perl etc. The wildcard \* seems to work. So it would be good to run a command to include the subpackages of ImageMagick, with the --alldeps flag, e.g. $ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* etc Orcan It produce big list of packages, thank you. What about second part of my questions? How frequently I should (can) update package? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ImageMagick update
I'll plan update ImageMagick now - https://bugzilla.redhat.com/show_bug.cgi?id=579458 ABI change follow. And according it I have some questions. New minor version of IM made around 1-2 times in week. What policy I should use to handle it? Have it worth update it in rawhide each time when new version arrived (I hope no)? For stable releases I though in action http://fedoraproject.org/wiki/Package_update_guidelines and shortly I should submit updates only for bugfixes. Must I notify someone about coming update? How? Is it enough write here? -- With best wishes, Pavel Alexeev aka Pahan-Hubbitus. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
20.04.2010 03:29, Ryan Rix пишет: On Mon 19 April 2010 3:51:23 pm Slava Zanko wrote: Hi folk, I want to propose new idea about names of command line utilites... For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Is good idea to symlink'ing (shell aliasing) these and much more utilz to another names? Like to: ls - filesystem.list rm - filesystem.remove fsck.* - filesystem.check.* mkfs.* - filesystem.make.* convert - media.convert.image mencoder - media.convert.video oggenc - media.convert.audio.ogg mplayer - media.player.* etc This idea will be easy to realize (need to make at first time one rpm package with lot of symlinks... and then long-time work in all present rpm-packages for respect this technology). But we need for standartization of alias names... in ideal case, standartization must touch all distros (new standard?) P.S. This not my idea. Originally from: http://translate.google.com/translate?js=yprev=_thl=enie=UTF-8layout=2; eotf=1u=http%3A%2F%2Fwww.linux.org.ru%2Fforum%2Ftalks%2F4797323sl=rutl=e n Thanks for attention. I'm against making a mess of PATH with a crapload of symlinks. If this were to happen, it should happen at a bashrc alias level, and even then I'm still against it. I also against making it global by default. But this can be done in separate folder, not to standard /usr/bin, and then added for users who want it just add it into PATH. I not sure what I want it, but sometimes really hard understand by name what do command and from which area it is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: giis-ext4 undelete
It is part of giis or should be packaged separately? Giis is not in Fedora yet. Upstream author ask there who can package it, I volunteered, but when work had be almost done author stop answer on my emails... On 11.02.2010 17:29, lakshmi pathi wrote: Hi all, Here it's http://www.giis.co.in/giis/ http://www.google.com/url?sa=Dq=http://www.giis.co.in/giis/usg=AFQjCNF-HqYzAJyM648v-oepVtmcFeB50A , ext4 undelete tool.giis-ext4 uses ext2fs lib and sqlite,thus provides better/best performance than giis for ext3. giis-ext4 has less than 1000 LOC which is almost 5 times less original than giis and giis-ext4 took just around 6 weekends (approx 15 days , 2hrs / day) thanks to ext2fs library :) Feedback/comments on giis-ext4 are most welcome. -- Cheers, Lakshmipathi.G www.giis.co.in http://www.giis.co.in -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
