Re: Non-responsive maintainer check for hubbitus
Hello. I'm here. I catastrophically have no free time to deal with tasks I want like Fedora. But I'm here. And plan to look at provided issues. If you prefer I deal with some particular issue at first - please say. And for urgent issues you can always contact me by Skype or Telegram. 2020-04-30 01:50, David Schwörer wrote: Hi, Does anybody know how to contact Pavel Alexeev (fas: hubbitus) ? https://bugzilla.redhat.com/show_bug.cgi?id=1829117 Last comment on the most recent ticket on bugzilla: #1737349 2019-09-08 pahan #1215344 2016-01-01 pahan #1200038 2015-10-04 pahan #1130101 2014-09-09 pahan List of open bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=pahan%40hubbitus.info_to1=1=substring_id=11024552_format=advanced Kind Regards, David ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, justice as open source. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Installed (but unpackaged) file(s) found on s390x and armv7hl: .s390x.debug.#dwz#
Hello On 07/23/2018 12:36 PM, Dan Horák wrote: On Mon, 23 Jul 2018 10:43:43 +0200 Mark Wielaard wrote: On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote: Hello. I try build new version of perdition package. It build fine (https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416) on all architectures except armv7hl and s390x. On that I got (https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/build.log): error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/sbin/perdition.imap4-2.2-1.fc29.s390x.debug.#dwz#.sWwnyG /usr/lib/debug/usr/sbin/perdition.imap4s-2.2-1.fc29.s390x.debug.#dwz#.eE9BPY /usr/lib/debug/usr/sbin/perdition.imaps-2.2-1.fc29.s390x.debug.#dwz#.WRTN7g /usr/lib/debug/usr/sbin/perdition.managesieve-2.2-1.fc29.s390x.debug.#dwz#.GWCloz /usr/lib/debug/usr/sbin/perdition.pop3-2.2-1.fc29.s390x.debug.#dwz#. 2Sm2W5 /usr/lib/debug/usr/sbin/perdition.pop3s-2.2-1.fc29.s390x.debug.#dwz#.kvArfo Could someone please help me solve that problem? It looks like dwz crashed and left those temporary files behind. Strangely there are no indication in the log files that dwz crashed. But there is an rm -f statement in the log right before the find-debuginfo.sh/dwz invocation that does seem to touch those files. I cannot explain where that comes from. It must be somewhere at the end of the %install phase, but there is nothing in the .spec file that hints at where it is coming from. It might be necessary to run on a real s390x or armv7vhl machine to track down what is going on. so I can reproduce that locally on my rawhide s390x guest Mark, I'll give you the machine info thru other channels. Sorry, but is there some test machine with s390x or armv7vhl and rawhide? I cant find such on https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers and that issue cannot be reproduced in stable Fedora releases. Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6B6PWZKSTDG7KBUONPKFSGCLGUIO5FFF/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4WJVQ75OC66XZTVP4IXXWYD3RGJWVH5V/
Re: Installed (but unpackaged) file(s) found on s390x and armv7hl: .s390x.debug.#dwz#
On 07/23/2018 12:36 PM, Dan Horák wrote: On Mon, 23 Jul 2018 10:43:43 +0200 Mark Wielaard wrote: On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote: Hello. I try build new version of perdition package. It build fine (https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416) on all architectures except armv7hl and s390x. On that I got (https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/build.log): error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/sbin/perdition.imap4-2.2-1.fc29.s390x.debug.#dwz#.sWwnyG /usr/lib/debug/usr/sbin/perdition.imap4s-2.2-1.fc29.s390x.debug.#dwz#.eE9BPY /usr/lib/debug/usr/sbin/perdition.imaps-2.2-1.fc29.s390x.debug.#dwz#.WRTN7g /usr/lib/debug/usr/sbin/perdition.managesieve-2.2-1.fc29.s390x.debug.#dwz#.GWCloz /usr/lib/debug/usr/sbin/perdition.pop3-2.2-1.fc29.s390x.debug.#dwz#. 2Sm2W5 /usr/lib/debug/usr/sbin/perdition.pop3s-2.2-1.fc29.s390x.debug.#dwz#.kvArfo Could someone please help me solve that problem? It looks like dwz crashed and left those temporary files behind. Strangely there are no indication in the log files that dwz crashed. But there is an rm -f statement in the log right before the find-debuginfo.sh/dwz invocation that does seem to touch those files. I cannot explain where that comes from. It must be somewhere at the end of the %install phase, but there is nothing in the .spec file that hints at where it is coming from. It might be necessary to run on a real s390x or armv7vhl machine to track down what is going on. so I can reproduce that locally on my rawhide s390x guest Mark, I'll give you the machine info thru other channels. Sorry, is there any progress? Should I fill bug for that? Against what component? Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6B6PWZKSTDG7KBUONPKFSGCLGUIO5FFF/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JPMBBW2D3AP7CANHVF3BGMNLKHZXJHXI/
Installed (but unpackaged) file(s) found on s390x and armv7hl: .s390x.debug.#dwz#
Hello. I try build new version of perdition package. It build fine (https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416) on all architectures except armv7hl and s390x. On that I got (https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/build.log): error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/sbin/perdition.imap4-2.2-1.fc29.s390x.debug.#dwz#.sWwnyG /usr/lib/debug/usr/sbin/perdition.imap4s-2.2-1.fc29.s390x.debug.#dwz#.eE9BPY /usr/lib/debug/usr/sbin/perdition.imaps-2.2-1.fc29.s390x.debug.#dwz#.WRTN7g /usr/lib/debug/usr/sbin/perdition.managesieve-2.2-1.fc29.s390x.debug.#dwz#.GWCloz /usr/lib/debug/usr/sbin/perdition.pop3-2.2-1.fc29.s390x.debug.#dwz#.2Sm2W5 /usr/lib/debug/usr/sbin/perdition.pop3s-2.2-1.fc29.s390x.debug.#dwz#.kvArfo Could someone please help me solve that problem? -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, justice as open source. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PB6DOPJSPJLDNUVZ3HUSNLMBORWLCXJK/
Re: Accidentally pushed branch to git
03.12.2016 16:03, Josh Boyer пишет: On Sat, Dec 3, 2016 at 5:12 AM, Pavel Alexeev <fo...@hubbitus.com.ru> wrote: Hello. I've just accidentally push into kernel new branch (f25-pf): $ git push originFedora f25-pf WARNING: 'kernel' is an alias for 'rpms/kernel' Counting objects: 2489, done. Delta compression using up to 8 threads. Compressing objects: 100% (1310/1310), done. Writing objects: 100% (2489/2489), 90.97 MiB | 2.11 MiB/s, done. Total 2489 (delta 1559), reused 1820 (delta 1118) remote: Emitting a message to the fedmsg bus. remote: * Publishing information for 1 commits remote: Traceback (most recent call last): remote: File "./hooks/post-receive-chained.d/post-receive-alternativearch", line 196, in remote: run_as_post_receive_hook() remote: File "./hooks/post-receive-chained.d/post-receive-alternativearch", line 157, in run_as_post_receive_hook remote: new_commits_list = get_revs_between(oldrev, newrev, abspath, refname) remote: File "./hooks/post-receive-chained.d/post-receive-alternativearch", line 90, in get_revs_between remote: head = get_default_branch(abspath) remote: NameError: global name 'get_default_branch' is not defined To ssh://pkgs.fedoraproject.org/kernel * [new branch] f25-pf -> f25-pf But can't delete it: [pasha@hubbitus f25-pf]$ git push originFedora --delete f25-pf WARNING: 'kernel' is an alias for 'rpms/kernel' remote: FATAL: + refs/heads/f25-pf rpms/kernel hubbitus DENIED by refs/heads/f[0-9][0-9] remote: error: hook declined to update refs/heads/f25-pf To ssh://pkgs.fedoraproject.org/kernel ! [remote rejected] f25-pf (hook declined) error: failed to push some refs to 'ssh://hubbi...@pkgs.fedoraproject.org/kernel' There is not present any forbidden things but it is not intended to be pushed into Fedora repos. I'm very sorry for the mistake. Could please someone delete it? Only rel-eng can delete it. You'll need to file a ticket with them. josh Ok, thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Accidentally pushed branch to git
Hello. I've just accidentally push into kernel new branch (f25-pf): $ git push originFedora f25-pf WARNING: 'kernel' is an alias for 'rpms/kernel' Counting objects: 2489, done. Delta compression using up to 8 threads. Compressing objects: 100% (1310/1310), done. Writing objects: 100% (2489/2489), 90.97 MiB | 2.11 MiB/s, done. Total 2489 (delta 1559), reused 1820 (delta 1118) remote: Emitting a message to the fedmsg bus. remote: * Publishing information for 1 commits remote: Traceback (most recent call last): remote: File "./hooks/post-receive-chained.d/post-receive-alternativearch", line 196, in remote: run_as_post_receive_hook() remote: File "./hooks/post-receive-chained.d/post-receive-alternativearch", line 157, in run_as_post_receive_hook remote: new_commits_list = get_revs_between(oldrev, newrev, abspath, refname) remote: File "./hooks/post-receive-chained.d/post-receive-alternativearch", line 90, in get_revs_between remote: head = get_default_branch(abspath) remote: NameError: global name 'get_default_branch' is not defined To ssh://pkgs.fedoraproject.org/kernel * [new branch] f25-pf -> f25-pf But can't delete it: [pasha@hubbitus f25-pf]$ git push originFedora --delete f25-pf WARNING: 'kernel' is an alias for 'rpms/kernel' remote: FATAL: + refs/heads/f25-pf rpms/kernel hubbitus DENIED by refs/heads/f[0-9][0-9] remote: error: hook declined to update refs/heads/f25-pf To ssh://pkgs.fedoraproject.org/kernel ! [remote rejected] f25-pf (hook declined) error: failed to push some refs to 'ssh://hubbi...@pkgs.fedoraproject.org/kernel' There is not present any forbidden things but it is not intended to be pushed into Fedora repos. I'm very sorry for the mistake. Could please someone delete it? -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, goodness and justice. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review swaps
Hi! I'll be happy swap reviews for 3 my packages: 1) pgcenter - Top-like PostgreSQL statistics viewer https://bugzilla.redhat.com/show_bug.cgi?id=1302053 It should be quite simple. 2) pgmodeler - PostgreSQL Database Modeler https://bugzilla.redhat.com/show_bug.cgi?id=977116 It old and bigger. But very useful software. Upstream author also very responsive - I believe all known issues resolved now. 3) rigsofrods - Vehicle simulator based on soft-body physics https://bugzilla.redhat.com/show_bug.cgi?id=rigsofrods I wouldn't expect that one will be easy. But my first attempt had been done many-many time ago and I want give it some impulse now. -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, goodness and justice. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Patents question about BPG Image format
Hello. I found very interesting BPG image format - http://bellard.org/bpg/ Under licensing chapter on offsite stated: * The BPG decoding library uses a modified version of FFmpeg released under the LGPL version 2.1 as HEVC decoder. The BPG decoding library excluding the FFmpeg code is released under the BSD license. * The BPG encoder as a whole is released under the GPL version 2 license. The BPG encoder sources excluding x265 are released under the BSD license. Thex265 <https://www.videolan.org/developers/x265.html>library is released under the GPL version 2 license. The optionalJCTVC HEVC reference encoder <https://hevc.hhi.fraunhofer.de/>is released under the BSD license. * Some of the HEVC algorithms may be protected by patents in some countries (read theFFmpeg Patent Mini-FAQ <https://www.ffmpeg.org/legal.html>for more information). Most devices already include or will include hardware HEVC support, so we suggest to use it if patents are an issue. Licenses free. Licensecheck also show mix of BSD, MIT and LGPL code. But what with codec patents? Is it acceptable in Fedora? -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, goodness and justice. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Patents question about BPG Image format
Thank you. 26.01.2016 22:54, Kevin Fenzi wrote: On Tue, 26 Jan 2016 22:32:22 +0300 Pavel Alexeev <fo...@hubbitus.com.ru> wrote: Hello. I found very interesting BPG image format - http://bellard.org/bpg/ Under licensing chapter on offsite stated: * The BPG decoding library uses a modified version of FFmpeg released under the LGPL version 2.1 as HEVC decoder. The BPG decoding library excluding the FFmpeg code is released under the BSD license. * The BPG encoder as a whole is released under the GPL version 2 license. The BPG encoder sources excluding x265 are released under the BSD license. Thex265 <https://www.videolan.org/developers/x265.html>library is released under the GPL version 2 license. The optionalJCTVC HEVC reference encoder <https://hevc.hhi.fraunhofer.de/>is released under the BSD license. * Some of the HEVC algorithms may be protected by patents in some countries (read theFFmpeg Patent Mini-FAQ <https://www.ffmpeg.org/legal.html>for more information). Most devices already include or will include hardware HEVC support, so we suggest to use it if patents are an issue. Licenses free. Licensecheck also show mix of BSD, MIT and LGPL code. But what with codec patents? Is it acceptable in Fedora? Please mail le...@fedoraproject.org or make a review and have it block FE_LEGAL. This list cannot decide if it's acceptable or not, that will take a judgment from fedora legal. kevin -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Freerdp update with bundle in guacamole-server
Good point. At least for Fedora 24 it will be moved forward now. Thank you. 30.11.2015 12:01, Simone Caronni пишет: On Sat, Nov 28, 2015 at 3:55 PM, Pavel Alexeev <fo...@hubbitus.com.ru <mailto:fo...@hubbitus.com.ru>> wrote: And yes, as current version of Remmina has much errors in Fedora 23 I want update it to 1.2.0-rcgit.5 in that branch too. Please make sure that for Fedora 23 you are not breaking Guacamole though. It is ok to leave it disabled/Broken in Fedora 24 until FreeRDP releases the 2.0 snapshot but not in Fedora 23 where this is up and running. Please also note that David Woodhouse backported a lot of patches to the 1.2.0 branch to get the new functionality without breaking the API. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Freerdp update with bundle in guacamole-server
Hi! I'm sorry for too late answer. Simone thank you for the update. As I do not use guacamole and it is ok just drop rdp support there it just most easy way off course. And yes, as current version of Remmina has much errors in Fedora 23 I want update it to 1.2.0-rcgit.5 in that branch too. 24.11.2015 16:54, Simone Caronni пишет: Hello, as you've said, after continuous issues, the Guacamole developers are not willing to update to unreleased versions/tarballs. I've briefly talked with David Woodhouse offlist a few days ago and I've pushed a 15th november 2015 build of both FreeRDP [1] and Remmina [2] at the same time in rawhide (f24). For the moment I've basically ignored guacamole-server at all and I'm waiting on the (promised) 2.0 snapshot of FreeRDP before updating it. @Pavel, I suppose you are refferring to update directly in Fedora 23 and you were not referring to rawhide. I would be more than happy to push an update to Fedora 23 considering the amount of crashes that Remmina has, but I would wait for the tarball and the Guacamole patch. Otherwise disabled RDP support in Guacamole means chunking away a big part of its features; and I would like to avoid it. Regards, --Simone [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=699433 [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=699494 On Sun, Nov 22, 2015 at 7:27 PM, Pavel Alexeev <fo...@hubbitus.com.ru <mailto:fo...@hubbitus.com.ru>> wrote: Thanks Neal. Simone, what you think? I really want move forward and find way. Remmina have many bugs which should be fixed upstream, but I still can't update. 14.11.2015 22:20, Neal Gompa wrote: I am not the maintainer of guacamole-server. That is Simone Caronni (who I cc'd to this email) according to PkgDB[0]. Simone is the one you want to ask, really. [0]: https://admin.fedoraproject.org/pkgdb/package/guacamole-server/ On Sat, Nov 14, 2015 at 2:15 PM, Pavel Alexeev <fo...@hubbitus.com.ru <mailto:fo...@hubbitus.com.ru>> wrote: Hello Neal. If I right understand you are maintainer of guacamole? Do you wish proceed with freerdp-compat package only? 09.11.2015 13 <tel:09.11.2015%2013>:11, Pavel Alexeev пишет: 08.11.2015 23 <tel:08.11.2015%2023>:38, Neal Gompa пишет: On Sun, Nov 8, 2015 at 2:31 PM, Pavel Alexeev <fo...@hubbitus.com.ru <mailto:fo...@hubbitus.com.ru>> wrote: Hello. More than half year in the past freerdp was updated and then reverted version to current present [1], mostly to allow built guacamole-server [2]. As I see it still stick with that version. Meantime freerdp move forward. Remmina, which require fresh versions of freerdp also can't be updated. Recently our bundling policy changed [3]. From freerdp depends: $ dnf repoquery --source --alldeps --whatrequires freerdp-libs ... freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm guacamole-server-0.9.7-1.fc23.src.rpm medusa-2.2-0.rc1.2.fc23.1.src.rpm remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm vinagre-3.18.1-1.fc23.src.rpm vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org <http://rpmfusion.org>) weston-1.9.0-1.fc23.src.rpm $ dnf repoquery --source --alldeps --whatrequires freerdp ... krdc-15.04.2-2.fc23.src.rpm Today I have try build freerdp [4] from master and all dependencies against it. And again, *only* guacamole-server fails to build with: In file included from rdp_stream.h:29:0, from rdp_fs.c:27: rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file or directory compilation terminated. It relied on old svc_plugin which has been rid in 2013 year [5]. Main question. Is it a good reason to bundle copy of current version freerdp into guacamole-server (at least until someone do not willing port it) and update it for rest of Fedora? I have not tried to do such bundle yet, but if no one argue I could try do that with update freerdp and rebuild all other deps too. [1] https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html [2] https://lists.fe
Re: Freerdp update with bundle in guacamole-server
Thanks Neal. Simone, what you think? I really want move forward and find way. Remmina have many bugs which should be fixed upstream, but I still can't update. 14.11.2015 22:20, Neal Gompa wrote: I am not the maintainer of guacamole-server. That is Simone Caronni (who I cc'd to this email) according to PkgDB[0]. Simone is the one you want to ask, really. [0]: https://admin.fedoraproject.org/pkgdb/package/guacamole-server/ On Sat, Nov 14, 2015 at 2:15 PM, Pavel Alexeev <fo...@hubbitus.com.ru> wrote: Hello Neal. If I right understand you are maintainer of guacamole? Do you wish proceed with freerdp-compat package only? 09.11.2015 13:11, Pavel Alexeev пишет: 08.11.2015 23:38, Neal Gompa пишет: On Sun, Nov 8, 2015 at 2:31 PM, Pavel Alexeev <fo...@hubbitus.com.ru> wrote: Hello. More than half year in the past freerdp was updated and then reverted version to current present [1], mostly to allow built guacamole-server [2]. As I see it still stick with that version. Meantime freerdp move forward. Remmina, which require fresh versions of freerdp also can't be updated. Recently our bundling policy changed [3]. From freerdp depends: $ dnf repoquery --source --alldeps --whatrequires freerdp-libs ... freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm guacamole-server-0.9.7-1.fc23.src.rpm medusa-2.2-0.rc1.2.fc23.1.src.rpm remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm vinagre-3.18.1-1.fc23.src.rpm vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org) weston-1.9.0-1.fc23.src.rpm $ dnf repoquery --source --alldeps --whatrequires freerdp ... krdc-15.04.2-2.fc23.src.rpm Today I have try build freerdp [4] from master and all dependencies against it. And again, *only* guacamole-server fails to build with: In file included from rdp_stream.h:29:0, from rdp_fs.c:27: rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file or directory compilation terminated. It relied on old svc_plugin which has been rid in 2013 year [5]. Main question. Is it a good reason to bundle copy of current version freerdp into guacamole-server (at least until someone do not willing port it) and update it for rest of Fedora? I have not tried to do such bundle yet, but if no one argue I could try do that with update freerdp and rebuild all other deps too. [1] https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html [2] https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html [3] https://fedorahosted.org/fpc/ticket/575 [4] https://github.com/FreeRDP/FreeRDP [5] https://github.com/FreeRDP/FreeRDP/pull/1574 -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, goodness and justice. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info Given that the last time someone asked about getting guacamole to work on the latest FreeRDP, they said they won't do it[1], I'm inclined to suggest you should go ahead and try that. Sorry, but I do not very interesting in guacamole and it seams is not very trivial task. I have asked FreeRDP to put out a release before[2], and they've just marked it for "2.0" milestone, whenever that happens... Another option would be to set up the current FreeRDP library as a "compat" package that can be parallel installed with the latest FreeRDP from upstream, which might be possible with some finagling. That may be an option. Do you think it is a better way? It will require new review, but still need only for single package. [1]: https://glyptodon.org/jira/browse/GUAC-1130 [2]: https://github.com/FreeRDP/FreeRDP/issues/2839 -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Freerdp update with bundle in guacamole-server
Hello Neal. If I right understand you are maintainer of guacamole? Do you wish proceed with freerdp-compat package only? 09.11.2015 13:11, Pavel Alexeev пишет: 08.11.2015 23:38, Neal Gompa пишет: On Sun, Nov 8, 2015 at 2:31 PM, Pavel Alexeev <fo...@hubbitus.com.ru>wrote: Hello. More than half year in the past freerdp was updated and then reverted version to current present [1], mostly to allow built guacamole-server [2]. As I see it still stick with that version. Meantime freerdp move forward. Remmina, which require fresh versions of freerdp also can't be updated. Recently our bundling policy changed [3]. From freerdp depends: $ dnf repoquery --source --alldeps --whatrequires freerdp-libs ... freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm guacamole-server-0.9.7-1.fc23.src.rpm medusa-2.2-0.rc1.2.fc23.1.src.rpm remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm vinagre-3.18.1-1.fc23.src.rpm vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org <http://rpmfusion.org>) weston-1.9.0-1.fc23.src.rpm $ dnf repoquery --source --alldeps --whatrequires freerdp ... krdc-15.04.2-2.fc23.src.rpm Today I have try build freerdp [4] from master and all dependencies against it. And again, *only* guacamole-server fails to build with: In file included from rdp_stream.h:29:0, from rdp_fs.c:27: rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file or directory compilation terminated. It relied on old svc_plugin which has been rid in 2013 year [5]. Main question. Is it a good reason to bundle copy of current version freerdp into guacamole-server (at least until someone do not willing port it) and update it for rest of Fedora? I have not tried to do such bundle yet, but if no one argue I could try do that with update freerdp and rebuild all other deps too. [1] https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html [2] https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html [3] https://fedorahosted.org/fpc/ticket/575 [4] https://github.com/FreeRDP/FreeRDP [5] https://github.com/FreeRDP/FreeRDP/pull/1574 -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, goodness and justice. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info Given that the last time someone asked about getting guacamole to work on the latest FreeRDP, they said they won't do it[1], I'm inclined to suggest you should go ahead and try that. Sorry, but I do not very interesting in guacamole and it seams is not very trivial task. I have asked FreeRDP to put out a release before[2], and they've just marked it for "2.0" milestone, whenever that happens... Another option would be to set up the current FreeRDP library as a "compat" package that can be parallel installed with the latest FreeRDP from upstream, which might be possible with some finagling. That may be an option. Do you think it is a better way? It will require new review, but still need only for single package. [1]: https://glyptodon.org/jira/browse/GUAC-1130 [2]: https://github.com/FreeRDP/FreeRDP/issues/2839 -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Freerdp update with bundle in guacamole-server
08.11.2015 23:38, Neal Gompa пишет: On Sun, Nov 8, 2015 at 2:31 PM, Pavel Alexeev <fo...@hubbitus.com.ru <mailto:fo...@hubbitus.com.ru>>wrote: Hello. More than half year in the past freerdp was updated and then reverted version to current present [1], mostly to allow built guacamole-server [2]. As I see it still stick with that version. Meantime freerdp move forward. Remmina, which require fresh versions of freerdp also can't be updated. Recently our bundling policy changed [3]. From freerdp depends: $ dnf repoquery --source --alldeps --whatrequires freerdp-libs ... freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm guacamole-server-0.9.7-1.fc23.src.rpm medusa-2.2-0.rc1.2.fc23.1.src.rpm remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm vinagre-3.18.1-1.fc23.src.rpm vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org <http://rpmfusion.org>) weston-1.9.0-1.fc23.src.rpm $ dnf repoquery --source --alldeps --whatrequires freerdp ... krdc-15.04.2-2.fc23.src.rpm Today I have try build freerdp [4] from master and all dependencies against it. And again, *only* guacamole-server fails to build with: In file included from rdp_stream.h:29:0, from rdp_fs.c:27: rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file or directory compilation terminated. It relied on old svc_plugin which has been rid in 2013 year [5]. Main question. Is it a good reason to bundle copy of current version freerdp into guacamole-server (at least until someone do not willing port it) and update it for rest of Fedora? I have not tried to do such bundle yet, but if no one argue I could try do that with update freerdp and rebuild all other deps too. [1] https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html [2] https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html [3] https://fedorahosted.org/fpc/ticket/575 [4] https://github.com/FreeRDP/FreeRDP [5] https://github.com/FreeRDP/FreeRDP/pull/1574 -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, goodness and justice. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info Given that the last time someone asked about getting guacamole to work on the latest FreeRDP, they said they won't do it[1], I'm inclined to suggest you should go ahead and try that. Sorry, but I do not very interesting in guacamole and it seams is not very trivial task. I have asked FreeRDP to put out a release before[2], and they've just marked it for "2.0" milestone, whenever that happens... Another option would be to set up the current FreeRDP library as a "compat" package that can be parallel installed with the latest FreeRDP from upstream, which might be possible with some finagling. That may be an option. Do you think it is a better way? It will require new review, but still need only for single package. [1]: https://glyptodon.org/jira/browse/GUAC-1130 [2]: https://github.com/FreeRDP/FreeRDP/issues/2839 -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Freerdp update with bundle in guacamole-server
Hello. More than half year in the past freerdp was updated and then reverted version to current present [1], mostly to allow built guacamole-server [2]. As I see it still stick with that version. Meantime freerdp move forward. Remmina, which require fresh versions of freerdp also can't be updated. Recently our bundling policy changed [3]. From freerdp depends: $ dnf repoquery --source --alldeps --whatrequires freerdp-libs ... freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm guacamole-server-0.9.7-1.fc23.src.rpm medusa-2.2-0.rc1.2.fc23.1.src.rpm remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm vinagre-3.18.1-1.fc23.src.rpm vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org) weston-1.9.0-1.fc23.src.rpm $ dnf repoquery --source --alldeps --whatrequires freerdp ... krdc-15.04.2-2.fc23.src.rpm Today I have try build freerdp [4] from master and all dependencies against it. And again, *only* guacamole-server fails to build with: In file included from rdp_stream.h:29:0, from rdp_fs.c:27: rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file or directory compilation terminated. It relied on old svc_plugin which has been rid in 2013 year [5]. Main question. Is it a good reason to bundle copy of current version freerdp into guacamole-server (at least until someone do not willing port it) and update it for rest of Fedora? I have not tried to do such bundle yet, but if no one argue I could try do that with update freerdp and rebuild all other deps too. [1] https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html [2] https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html [3] https://fedorahosted.org/fpc/ticket/575 [4] https://github.com/FreeRDP/FreeRDP [5] https://github.com/FreeRDP/FreeRDP/pull/1574 -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, goodness and justice. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: plowshare is not shipped with modules anymore
17.04.2015 07:41, Ralf Corsepius пишет: On 04/17/2015 01:10 AM, Pavel Alexeev wrote: Hi 14.04.2015 05:20, Ralf Corsepius пишет: On 04/14/2015 03:01 AM, Elder Marco wrote: Ralf, plowshare is a command-line downloader/uploader for some of the most popular file-sharing websites. Each module (written in bash) corresponds to a different sharing site. The modules are downloaded via plowmod, from a oficial repository provided by upstream. Well, as I said before, I do not like packages, which are doing so. I consider them to be a security and data privacy risk, but I am not in a position to change upstreams nor users. My advise to users: Don't use such packages if you are concerned about your data and your installations' security. If package provide some basic modules and also utilities for user to manage update channels or repo in clean way, why not? Why would you trust such update channels and the content they provide? Who tells me their site is trustworthy and not run or having been taken over by a secret service, the Mafia or other criminals? As was mentioned early many software do the same. In Fedora? None that I am aware of, except of Mozilla, whose plugins/addons basically suffer from the same issue. Nothing but Mozilla itself prevents you from installing the Nigerian Mafia or the NSA-Trojan add-ons. Although we do not ship any external yum repos in rpm there clear way for users how to add others. Correct. The rationale not to allow non-fedora repos in Fedora is basically the same. What mean not to allow? You do not understand me. Not ship by default in distribution is not mean not allow. Repo-format well defined, yum-config-manager allow add repos. And it may be much more security breach. Well, instead of relying on Fedora shipping a fixed set of scripts (which should have been reviewed and tested by the package maintainer and protected from forgery with rpm), they want users to download install arbitrary scripts from their site. Do you really think maintainer of any package may review all upstream commits to guarantee anything about upstream software state, quality or mallware presents? Off course we all want and try to do not bring bad things in Fedora, but really it mostly on upstream developer side happened what happened. As pip, rybygems, maven do not forbidden download and install external dependencies I hope plowmod also may do that. IMO, they are implementing a carte-blanche to trojans, malware and espionage. Ralf -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: plowshare is not shipped with modules anymore
Hi 14.04.2015 05:20, Ralf Corsepius пишет: On 04/14/2015 03:01 AM, Elder Marco wrote: Ralf, plowshare is a command-line downloader/uploader for some of the most popular file-sharing websites. Each module (written in bash) corresponds to a different sharing site. The modules are downloaded via plowmod, from a oficial repository provided by upstream. Well, as I said before, I do not like packages, which are doing so. I consider them to be a security and data privacy risk, but I am not in a position to change upstreams nor users. My advise to users: Don't use such packages if you are concerned about your data and your installations' security. If package provide some basic modules and also utilities for user to manage update channels or repo in clean way, why not? As was mentioned early many software do the same. Although we do not ship any external yum repos in rpm there clear way for users how to add others. And it may be much more security breach. So, in my mind plowshare just must clearly state what it doing and provide described way to control such process for user (see and manage repos added, enabled/disabled and so on). Off course that should be installed somewhere under user $HOME... Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
17.03.2015 02:57, Kevin Fenzi wrote: On Mon, 16 Mar 2015 21:02:25 +0300 Pavel Alexeev fo...@hubbitus.com.ru wrote: The main question should it be done in such manner? May be it have worth run at least off-tree (without commits and versions bump) mass rebuild? It allow estimate amount of broken packages and see dependencies. Do we have resources to do so? I was hoping to run a rebuild in copr on our new cloud (which would help this and also help make sure the new cloud is running ok). We will see how long such a rebuild will take and if it's not too long run it. Thank you Kevin. I hope it will be announced shortly. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FreeRDP downgrade in rawhide and f22 updates-testing
Hello. 18.03.2015 14:08, David Woodhouse wrote: After a brief flirtation with a FreeRDP 1.2.1-beta snapshot, we concluded that the API breakage was too much to handle and we've reverted to a slightly earlier snapshot of 1.2.0-beta. The 1.2.1 packages were briefly visible in rawhide and f22 updates-testing. Am I right in thinking that we *don't* need to bump the epoch in order to go back to 1.2.0, and that testers should expect to have to use 'distro-sync' occasionally instead of just 'update'? Why you revert it in rawhide too? I could help with rebuilding dependencies. Is there other known troubles except so-name change? I suppose we can bump the epoch if we have to (it's already non-zero, after all), but my first inclination is always to try to avoid doing so. https://admin.fedoraproject.org/updates/FEDORA-2015-3632 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
15.03.2015 16:57, Michael Schwendt пишет: On Tue, 10 Mar 2015 14:49:28 +0100, Ralf Corsepius wrote: Right now, many issues/problems are interacting and affecting packages simultanously, which occasionally render fixing these issues quite complicated. So far I've hit: - GCC-5.0 - Hardening - boost upgrade - ImageMagick - autotool upgrade. Openly said, the situation on f23 is a mess. Agreed. People run into failed builds, find out that a lib needs a rebuild because of GCC C++ ABI issues. After the rebuild, runtime linking fails for other dependencies, and they need a rebuild, too. This is non-trivial (and dangerous) for larger dep-chains in the distribution. I'm also not sure how many packagers even run Rawhide instead of F22 testing. The main question should it be done in such manner? May be it have worth run at least off-tree (without commits and versions bump) mass rebuild? It allow estimate amount of broken packages and see dependencies. Do we have resources to do so? -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
06.03.2015 19:34, Kevin Fenzi пишет: On Fri, 6 Mar 2015 11:31:45 -0500 Rich Mattes richmat...@gmail.com wrote: There's no planned f22 rebuild for gcc5, as f22 defaults to -D_GLIBCXX_USE_CXX11_ABI=0. These issues are cropping up in f23. There should probably be a mass rebuild for f23, and sooner rather than later as rawhide is currently a big game of whack-a-mole when building c++ packages. As soon as gcc folks say things are settled down enough to do one, we can look at scheduling one. ;) It would be a shame to do it too soon though and have a bug requiring another one. I've been rebuilding things as I run into them being broken. (The other day it was the gobby stack: net6, libxml++, obby, gobby). Is it ok to rebuild all dependencies f.e. for fix build issue with pfstools introduced by that update? Or just fill bugzilla issues for owners? kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
Hello. 06.03.2015 16:51, Tomáš Smetana wrote: On Fri, 6 Mar 2015 14:11:03 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Fri, 06 Mar 2015 12:49:12 +0300, Pavel Alexeev wrote: Hello. ImageMagick itself built in rawhide. just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ It wasn't build with your upgrade, but an older one: https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/root.log DEBUG util.py:388: ImageMagick i686 6.8.8.10-7.fc22 build 159 k DEBUG util.py:388: ImageMagick-c++ i686 6.8.8.10-7.fc22 build 167 k DEBUG util.py:388: ImageMagick-libsi686 6.8.8.10-7.fc22 build 2.0 M You may need to look into using koji wait-repo … to give koji some time to recreate the buildroot repo metadata after including a new build. It may take roughly up to 20 minutes for a build to be included. Meanwhile, the buildroot should be up-to-date, so give it another try. Thanks. Thanks. You were faster... I'm also afraid the example above shows building only the ImageMagick direct dependencies might not be sufficient. Seems that right now there are some packages that have been rebuilt with gcc-5 and some not yet. This may lead to more linker failures when one binary wants to link with several libraries with incompatible ABIs... And how we should deal with it? According to https://fedoraproject.org/wiki/Changes/GCC5 there no planned mass-rebuild for GCC5. I could try rebuild dependencies, but should I use -D_GLIBCXX_USE_CXX11_ABI=0? Do we have some policy about it? Regards, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
Hello. ImageMagick itself built in rawhide. 05.03.2015 15:52, Tomáš Smetana wrote: On Thu, 05 Mar 2015 02:09:00 +0300 Pavel Alexeev fo...@hubbitus.com.ru wrote: Hello. I have long outstanding update of ImageMagick[1] and plan do it in rawhide in 1-3 days. ... Affected packages needs to be rebuild: ... pfstools Package owners in cc. Please let me known if you wish me to rebuild your package. Hi, just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ Thanks and regards, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
Hello. I have long outstanding update of ImageMagick[1] and plan do it in rawhide in 1-3 days. So-name happened libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6 (from ImageMagick-c++ sub-package). Other names did not changed: libMagickCore-6.Q16.so.2, libMagickWand-6.Q16.so.2 Affected packages needs to be rebuild: $ repoquery --repoid=rawhide --whatrequires ImageMagick-c++ --source | sort -u | perl -pe 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' converseen cuneiform drawtiming gtatool inkscape k3d kxstitch perl-Image-SubImageFind pfstools synfig vdr-scraper2vdr Package owners in cc. Please let me known if you wish me to rebuild your package. Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=9139666 [1]https://bugzilla.redhat.com/show_bug.cgi?id=1087263 -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Orphaned packages in epel7
18.10.2014 14:53, opensou...@till.name пишет: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package (co)maintainersStatus Change === SDL_mixer orphan, sdz 2014-05-14 (22 weeks ago) cqrlogorphan, sparks2014-10-14 (0 weeks ago) create-tx-configuration orphan, sparks2014-10-14 (0 weeks ago) golang-github-gorilla-orphan, golang-sig, 2014-06-11 (18 weeks context lsm5, mattdm, vbatts ago) golang-github-gorilla-orphan, golang-sig, 2014-06-11 (18 weeks mux lsm5, mattdm, vbatts ago) golang-github-kr-pty orphan, golang-sig, 2014-06-11 (18 weeks lsm5, mattdm ago) golang-googlecode-net orphan, golang-sig, 2014-06-11 (18 weeks jchaloup, lsm5, mattdm, ago) vbatts golang-googlecode-orphan, golang-sig, 2014-06-11 (18 weeks sqlitelsm5, vbatts ago) mikmodorphan, s4504kr, sdz 2014-05-14 (22 weeks ago) mysql-connector-pythonorphan2014-06-02 (19 weeks ago) pkcs11-helper orphan2014-08-03 (10 weeks ago) python-gunicorn orphan, dcallagh 2014-06-15 (17 weeks ago) python-itsdangerous orphan, branto, 2014-07-10 (14 weeks dcallagh ago) python-paver orphan, lmacken, toshio 2014-08-14 (9 weeks ago) python-requests orphan, sagarun, 2014-08-20 (8 weeks terminalmage ago) python-urllib3orphan, ralph, sagarun2014-07-06 (14 weeks ago) The following packages require above mentioned packages: Depending on: SDL_mixer (1) stellarium (maintained by: s4504kr) stellarium-0.12.4-3.el7.src requires SDL_mixer-devel = 1.2.12-4.el7 Depending on: mysql-connector-python (1) mysql-utilities (maintained by: hubbitus, hhorak) mysql-utilities-1.3.6-1.el7.noarch requires mysql-connector-python = 1.1.6-1.el7 mysql-utilities-1.3.6-1.el7.src requires mysql-connector-python = 1.1.6-1.el7 mysql-utilities taken for Epel7. Depending on: pkcs11-helper (2) openvpn (maintained by: steve, huzaifas, limb) openvpn-2.3.2-4.el7.src requires pkcs11-helper-devel = 1.10-1.el7 openvpn-2.3.2-4.el7.x86_64 requires libpkcs11-helper.so.1()(64bit) NetworkManager-openvpn (maintained by: limb, huzaifas, pavlix) NetworkManager-openvpn-0.9.8.2-4.el7.1.x86_64 requires openvpn = 2.3.2-4.el7 Affected (co)maintainers branto: python-itsdangerous dcallagh: python-gunicorn, python-itsdangerous golang-sig: golang-googlecode-net, golang-github-gorilla-context, golang-googlecode-sqlite, golang-github-kr-pty, golang-github-gorilla-mux hhorak: mysql-connector-python hubbitus: mysql-connector-python huzaifas: pkcs11-helper jchaloup: golang-googlecode-net limb: pkcs11-helper lmacken: python-paver lsm5: golang-googlecode-net, golang-github-gorilla-context, golang-googlecode-sqlite, golang-github-kr-pty, golang-github-gorilla-mux mattdm: golang-googlecode-net, golang-github-gorilla-context, golang-github-kr-pty,
Re: [EPEL-devel] Orphaned packages in epel7
18.10.2014 14:53, opensou...@till.name пишет: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package (co)maintainersStatus Change === SDL_mixer orphan, sdz 2014-05-14 (22 weeks ago) cqrlogorphan, sparks2014-10-14 (0 weeks ago) create-tx-configuration orphan, sparks2014-10-14 (0 weeks ago) golang-github-gorilla-orphan, golang-sig, 2014-06-11 (18 weeks context lsm5, mattdm, vbatts ago) golang-github-gorilla-orphan, golang-sig, 2014-06-11 (18 weeks mux lsm5, mattdm, vbatts ago) golang-github-kr-pty orphan, golang-sig, 2014-06-11 (18 weeks lsm5, mattdm ago) golang-googlecode-net orphan, golang-sig, 2014-06-11 (18 weeks jchaloup, lsm5, mattdm, ago) vbatts golang-googlecode-orphan, golang-sig, 2014-06-11 (18 weeks sqlitelsm5, vbatts ago) mikmodorphan, s4504kr, sdz 2014-05-14 (22 weeks ago) mysql-connector-pythonorphan2014-06-02 (19 weeks ago) pkcs11-helper orphan2014-08-03 (10 weeks ago) python-gunicorn orphan, dcallagh 2014-06-15 (17 weeks ago) python-itsdangerous orphan, branto, 2014-07-10 (14 weeks dcallagh ago) python-paver orphan, lmacken, toshio 2014-08-14 (9 weeks ago) python-requests orphan, sagarun, 2014-08-20 (8 weeks terminalmage ago) python-urllib3orphan, ralph, sagarun2014-07-06 (14 weeks ago) The following packages require above mentioned packages: Depending on: SDL_mixer (1) stellarium (maintained by: s4504kr) stellarium-0.12.4-3.el7.src requires SDL_mixer-devel = 1.2.12-4.el7 Depending on: mysql-connector-python (1) mysql-utilities (maintained by: hubbitus, hhorak) mysql-utilities-1.3.6-1.el7.noarch requires mysql-connector-python = 1.1.6-1.el7 mysql-utilities-1.3.6-1.el7.src requires mysql-connector-python = 1.1.6-1.el7 mysql-utilities taken for Epel7. Depending on: pkcs11-helper (2) openvpn (maintained by: steve, huzaifas, limb) openvpn-2.3.2-4.el7.src requires pkcs11-helper-devel = 1.10-1.el7 openvpn-2.3.2-4.el7.x86_64 requires libpkcs11-helper.so.1()(64bit) NetworkManager-openvpn (maintained by: limb, huzaifas, pavlix) NetworkManager-openvpn-0.9.8.2-4.el7.1.x86_64 requires openvpn = 2.3.2-4.el7 Affected (co)maintainers branto: python-itsdangerous dcallagh: python-gunicorn, python-itsdangerous golang-sig: golang-googlecode-net, golang-github-gorilla-context, golang-googlecode-sqlite, golang-github-kr-pty, golang-github-gorilla-mux hhorak: mysql-connector-python hubbitus: mysql-connector-python huzaifas: pkcs11-helper jchaloup: golang-googlecode-net limb: pkcs11-helper lmacken: python-paver lsm5: golang-googlecode-net, golang-github-gorilla-context, golang-googlecode-sqlite, golang-github-kr-pty, golang-github-gorilla-mux mattdm: golang-googlecode-net, golang-github-gorilla-context, golang-github-kr-pty,
Re: What exactly is a bundled library? (was Re: apitrace, bundled libbacktrace)
13.06.2014 01:42, Adam Williamson пишет: On Tue, 2014-05-13 at 18:56 +0200, Sandro Mani wrote: Hi, apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged. Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request? So in writing a reply to this, I noticed the guidelines around this are actually fairly unclear and subject to interpretation. The section on this topic from https://fedoraproject.org/wiki/Packaging:Guidelines reads: Duplication of system libraries A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed. 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 on another computer is specifically exempted from this but this will likely change in the future. Note that for C and C++ there's only one system in Fedora but for some other languages we have parallel stacks. For instance, python, python3, jython, and pypy are all implementations of the python language but they are separate interpreters with slightly different implementations of the language. Each stack is considered its own system and can each contain its own copy of a library. The thing that is particularly unclear there is the definition of a system (as in a library that exists on a system). The following paragraphs seem to imply that Fedora's stacks for languages/frameworks that implement some kind of shared library functionality are to be understood as systems in that context. This is still not made *entirely* clear, though, really. The page https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries has all sorts of rationale and process stuff, but still no clear definition of precisely what it is that constitutes a bundled library. Even more confusingly, https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries seems to have a rather different definition from that given on Packaging:Guidelines. It reads: (bundled libraries being defined as libraries which exist and are mantained independently, whether or not they are packaged separately for Fedora) to me, that seems fundamentally different from the definition that is somewhat unclearly implied on the Packaging:Guidelines page. Has this been considered before? Is there a superior definition somewhere, or an accepted interpretation which is consistent with both pages? Do we in fact need a section in Packaging:Guidelines and then two separate 'subsidiary' pages all on the topic of bundled libraries? Would it make more sense to combine all the details onto a single subsidiary page and have Packaging:Guidelines just have a very short sort of 'summary' and a link to that one subsidiary page? Would that reduce the likelihood of confusion? Thanks! I've seen several cases in the Real World where 'bundled' libraries that are not a part of the Fedora repositories were considered to be OK under the policy, which is a possible interpretation of the policy as given on Packaging:Guidelines, but doesn't really seem to be a possible interpretation of the policy as given on Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states whether or not they are packaged separately for Fedora). This could have considerable implementations for webapps if it were interpreted strictly, I think. Sorry for the old thread. But it is very interesting question to clearly determine bundled library to which returning happened again and again. Does it hang again now or something indeed changed? -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ORPHAN of mysql and python stuff
02.06.2014 12:15, Remi Collet пишет: Le 28/05/2014 18:32, Pavel Alexeev a écrit : mysql-connector-python (1.1.6 in rawhide, 1.2.1 recently released) Orphaned. mysql-utilities (1.3.6 in rawhide, 1.4.3 recently released) Orphaned Looks interesting. If it is Mariadb compatible I could take it. Yes most commands works with MariaDB server. Thanks. Taken. Do you have current problems with it? No bug reported. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 21
29.05.2014 17:43, Till Maas wrote: Since the mass rebuild will start in a week (2014-06-06) it is a good time to start cleaning up Fedora. After the mass rebuild, packages that fail to build for two releases will be be added to this list. Since this is the first run after adapting the script to pkgdb2, there might be some errors here, please report them. The following packages are orphaned and will be retired when Fedora (F21) is branched, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2015-07-08. The packages will be retired shortly before. Package(co)maintainers === … pmountorphan, agk, Took master, f19, а20. -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What happened to xlwt?
Hi. According to pkgdb - https://admin.fedoraproject.org/pkgdb/package/xlwt/ it has been orphaned. 30.05.2014 15:55, Till Maas wrote: Hi, pkgdb knows a package called xlwt, but there is no repository for it. What happened to it? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ORPHAN of mysql and python stuff
Hello. 28.05.2014 10:52, Remi Collet wrote: Hi, Because of lack of interest, I plan to orphan the following packages (Fedora + EPEL) mysql++ (3.1.0 in rawhide, 3.2.1 available) Used by sems-dsm mysql-connector-python (1.1.6 in rawhide, 1.2.1 recently released) Used by shinken AFAIK, only connector to mysql for python3 mysql-utilities (1.3.6 in rawhide, 1.4.3 recently released) Interesting tools for sysadmin (but too much related to MySQL) Looks interesting. If it is Mariadb compatible I could take it. Do you have current problems with it? If you want to take them, just ask, I will release ownership. Remi. -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide report: 20140523 changes
23.05.2014 14:40, Fedora Rawhide Report wrote: Broken deps for i386 -- [redeclipse] redeclipse-1.4-6.fc20.i686 requires libenet.so.2 redeclipse-server-1.4-6.fc20.i686 requires libenet.so.2 [remmina] remmina-1.0.0-8.fc20.i686 requires libgcrypt.so.11(GCRYPT_1.2) remmina-1.0.0-8.fc20.i686 requires libgcrypt.so.11 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-rail.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-kbd.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-gdi.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-core.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-codec.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-channels.so.1.0 I've recently take remmina ownership and we are working together with Simone Caronni on fixing that and prepare update remmina in rawhide. Infortunately there plenty of bug reports and problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide report: 20140523 changes
23.05.2014 14:40, Fedora Rawhide Report wrote: Broken deps for i386 -- [redeclipse] redeclipse-1.4-6.fc20.i686 requires libenet.so.2 redeclipse-server-1.4-6.fc20.i686 requires libenet.so.2 [remmina] remmina-1.0.0-8.fc20.i686 requires libgcrypt.so.11(GCRYPT_1.2) remmina-1.0.0-8.fc20.i686 requires libgcrypt.so.11 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-rail.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-kbd.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-gdi.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-core.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-codec.so.1.0 remmina-plugins-rdp-1.0.0-8.fc20.i686 requires libfreerdp-channels.so.1.0 I've recently take remmina ownership and we are working together with Simone Caronni on fixing that and prepare update remmina in rawhide. Infortunately there plenty of bug reports and problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Owner-change] Fedora packages ownership change
05.05.2014 14:00, nob...@fedoraproject.org wrote: Change in ownership over the last 168 hours === 4 packages were orphaned transfig [devel,f19,f20] was orphaned by kdudka A utility for converting FIG files (made by xfig) to other formats. https://admin.fedoraproject.org/pkgdb/acls/name/transfig python-openid [EL-5,EL-6,devel,epel7,f19,f20] was orphaned by jcollie Python OpenID libraries https://admin.fedoraproject.org/pkgdb/acls/name/python-openid remmina [devel,f19,f20] was orphaned by cwickert A GTK+ Remote Desktop Client https://admin.fedoraproject.org/pkgdb/acls/name/remmina As I use it for day work I've take it. dnrd [devel] was orphaned by cicku A caching, forwarding DNS proxy server https://admin.fedoraproject.org/pkgdb/acls/name/dnrd 9 packages unorphaned - amigadave unorphaned : gnome-disk-utility [f19] ppisar unorphaned : perl-NOCpulse-Object [devel] mcepl unorphaned : spectrum [f19,f20] ppisar unorphaned : perl-NOCpulse-Debug [devel] ppisar unorphaned : nocpulse-common [devel] jmlich unorphaned : transfig [f19,f20] puiterwijk unorphaned : python-openid [EL-5,EL-6,devel,epel7,f19,f20] toshio unorphaned : qa-assistant [devel] ppisar unorphaned : perl-NOCpulse-CLAC [devel] 14 packages were retired - libmatewnck [devel] was retired by rdieter Window navigator constructor kit for MATE Desktop https://admin.fedoraproject.org/pkgdb/acls/name/libmatewnck xorg-x11-drv-keyboard [devel] was retired by ausil Xorg X11 keyboard input driver https://admin.fedoraproject.org/pkgdb/acls/name/xorg-x11-drv-keyboard mutter-wayland [devel] was retired by fmuellner Mutter window manager with experimental Wayland support https://admin.fedoraproject.org/pkgdb/acls/name/mutter-wayland python-lxml [EL-5] was retired by jcollie ElementTree-like Python bindings for libxml2 and libxslt https://admin.fedoraproject.org/pkgdb/acls/name/python-lxml spectrum [devel,f19,f20] was retired by mcepl XMPP transport/gateway https://admin.fedoraproject.org/pkgdb/acls/name/spectrum perl-NOCpulse-Gritch [devel] was retired by ppisar Perl throttled email notification for Spacewalk https://admin.fedoraproject.org/pkgdb/acls/name/perl-NOCpulse-Gritch async-http-client [devel] was retired by mizdebsk Asynchronous Http Client for Java https://admin.fedoraproject.org/pkgdb/acls/name/async-http-client python-django-sahara [EL-6,epel7] was retired by mimccune Sahara plugin for OpenStack dashboard https://admin.fedoraproject.org/pkgdb/acls/name/python-django-sahara perl-Elasticsearch [devel] was retired by eseyman Official client for Elasticsearch https://admin.fedoraproject.org/pkgdb/acls/name/perl-Elasticsearch mate-doc-utils [devel,f18] was retired by vicodan MATE Desktop doc utils https://admin.fedoraproject.org/pkgdb/acls/name/mate-doc-utils openstack-sahara [EL-6,epel7] was retired by mimccune Apache Hadoop cluster management on OpenStack https://admin.fedoraproject.org/pkgdb/acls/name/openstack-sahara xorg-x11-drv-mouse [devel] was retired by ausil Xorg X11 mouse input driver https://admin.fedoraproject.org/pkgdb/acls/name/xorg-x11-drv-mouse python-saharaclient [EL-6,epel7] was retired by mimccune client library for OpenStack Sahara API https://admin.fedoraproject.org/pkgdb/acls/name/python-saharaclient php-phpunit-PHP-CodeBrowser [devel] was retired by cdamian PHP_CodeBrowser for integration in Hudson and CruiseControl https://admin.fedoraproject.org/pkgdb/acls/name/php-phpunit-PHP-CodeBrowser 7 packages changed owner limbgave to lkundrak : perl-GraphViz [epel7] limbgave to pghmcfc: perl-File-DesktopEntry [EL-6] limbgave to goeran : ttf2pt1 [epel7] limbgave to pghmcfc: perl-File-MimeInfo [EL-6] limbgave to nalimilan : openspecfun [f19,f20] limbgave to goldmann : python-backports-lzma [epel7] limbgave to comzeradd : clipit [EL-6] Sources: https://github.com/pypingou/fedora-owner-change -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick 6.8.8-10 in rawhide. Soname change.
10.04.2014 05:25, Sérgio Basto пишет:
On Qui, 2014-04-10 at 01:40 +0200, Tadej Janež wrote:
Hi!
On Tue, 2014-04-08 at 18:30 +0400, Pavel Alexeev wrote:
Packages for rebuild:
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* |
fgrep -v 'ImageMagick-' | sort -u
As Michael Schwendt already pointed out, your query missed some packages
that need rebuilding (BTW, I noticed this because my package, techne,
was not listed on your list).
Comparing:
repoquery --whatrequires 'libMagick*.so.*' --repoid=rawhide --source
--qf '%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
to:
repoquery --whatrequires 'ImageMagick*' --repoid=rawhide --source --qf
'%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
revealed that the first command catches some packages that the second
command doesn't. These are:
ale
imageinfo
php-magickwand
php-pecl-imagick
psiconv
q
ripright
techne
But it also goes the other way around. The second command catches a lot
more packages that the first one. These are:
a2ps
anyremote
caja-extensions
c-graph
dblatex
epix
fbida
freewrl
fvwm
gallery2
...
Hi, I had study this recently (find dependencies for mass rebuilds ) and
found your bug, query rawhide when ImageMagick is already rebuilt,
query now rawhide we got :
repoquery --repoid=rawhide --requires techne | grep libMag
libMagickCore-6.Q16.so.1()(64bit)
libMagickWand-6.Q16.so.1()(64bit)
repoquery --repoid=rawhide --provides ImageMagick-libs | grep libMag
libMagickCore-6.Q16.so.2
libMagickWand-6.Q16.so.2
libMagickCore-6.Q16.so.2()(64bit)
libMagickWand-6.Q16.so.2()(64bit)
So repoquery is correct techne requires
libMagickWand-6.Q16.so.1()(64bit) and ImageMagick provides
libMagickCore-6.Q16.so.2()(64bit) :D
2nd - about your first command which catches some others packages, the
packages are, the packages that requires only ImageMagick and not
ImageMagick-libs , this packages that just requires ImageMagick binaries
don't need to be rebuild. if a package need to use convert , don't need
to be rebuild.
Conclusion the correct repoquery should be made on a repo that have all
packages without broken deps, on F20 for example.
repoquery --whatrequires ImageMagick-libs --source | perl -pe
's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | sort -u
and you got there your package
Thanks for comments. Each time I have more and more variants :)
Best regards,
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ImageMagick 6.8.8-10 in rawhide. Soname change.
Hello. New version landed in rawhide. Sorry for the late info - incidental soname change happened (fixed in spec now): /usr/lib64/libMagick++-6.Q16.so.1 /usr/lib64/libMagick++-6.Q16.so.1.0.0 /usr/lib64/libMagickCore-6.Q16.so.1 /usr/lib64/libMagickCore-6.Q16.so.1.0.0 /usr/lib64/libMagickWand-6.Q16.so.1 /usr/lib64/libMagickWand-6.Q16.so.1.0.0 Dependency rebuild needed. If you are willing I'll rebuild all after 3 days if you do not answer I should not do it. Packages for rebuild: $ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* | fgrep -v 'ImageMagick-' | sort -u a2ps-0:4.14-24.fc21.i686 a2ps-0:4.14-24.fc21.x86_64 anyremote-0:6.4-1.fc21.x86_64 autotrace-0:0.31.1-38.fc21.i686 autotrace-0:0.31.1-38.fc21.x86_64 autotrace-devel-0:0.31.1-38.fc21.i686 autotrace-devel-0:0.31.1-38.fc21.x86_64 caja-image-converter-0:1.8.0-1.fc21.x86_64 calibre-0:1.30.0-2.fc21.x86_64 c-graph-0:2.0-5.fc20.x86_64 converseen-0:0.6.6.1-2.fc21.x86_64 cuneiform-0:1.1.0-15.fc21.i686 cuneiform-0:1.1.0-15.fc21.x86_64 dblatex-0:0.3.4-8.fc20.noarch drawtiming-0:0.7.1-12.fc21.x86_64 emacs-1:24.3-15.fc21.x86_64 epix-0:1.2.13-3.fc21.i686 epix-0:1.2.13-3.fc21.x86_64 fbida-0:2.09-6.fc20.x86_64 freewrl-0:1.22.13.1-13.fc21.i686 freewrl-0:1.22.13.1-13.fc21.x86_64 fvwm-0:2.6.5-6.fc20.x86_64 gallery2-imagemagick-0:2.3.2-10.fc20.noarch geeqie-0:1.1-17.fc21.x86_64 gnumed-0:1.4.5-1.fc21.noarch gpsdrive-0:2.11-21.fc21.x86_64 gscan2pdf-0:1.2.3-1.fc21.noarch gtatool-imagemagick-0:1.5.2-11.fc21.x86_64 gyachi-0:1.2.11-10.fc21.x86_64 hdrprep-0:0.1.2-12.fc20.noarch html2ps-0:1.0-0.16.b7.fc21.noarch icewm-clearlooks-0:1.3.8-1.fc21.noarch inkscape-0:0.48.4-12.fc21.x86_64 inkscape-view-0:0.48.4-12.fc21.x86_64 k3d-0:0.8.0.2-24.fc21.i686 k3d-0:0.8.0.2-24.fc21.x86_64 kipi-plugins-0:4.0.0-0.6.beta4.fc21.x86_64 kxstitch-0:0.8.4.1-17.fc21.x86_64 latex2rtf-0:2.3.6-1.fc21.x86_64 libdmtx-utils-0:0.7.2-12.fc21.x86_64 libpst-0:0.6.63-1.fc21.x86_64 lyx-0:2.0.7-3.fc21.x86_64 mediawiki-0:1.22.5-1.fc21.noarch mtpaint-0:3.40-14.fc20.x86_64 nautilus-image-converter-0:0.3.1-0.6.git430afce31.fc20.x86_64 nip2-0:7.38.1-2.fc21.x86_64 perl-GD-SecurityImage-0:1.72-4.fc20.noarch perl-Image-Size-0:3.232-3.fc20.noarch perl-Panotools-Script-0:0.28-1.fc20.noarch perl-WebService-Rajce-0:1.13.0930-3.fc20.noarch pfstools-0:1.8.5-16.fc21.x86_64 pfstools-imgmagick-0:1.8.5-16.fc21.x86_64 phatch-cli-0:0.2.7-14.fc21.noarch RabbIT-0:4.11-3.fc21.noarch recoverjpeg-0:2.2.3-2.fc20.x86_64 rss-glx-0:0.9.1.p-20.fc21.x86_64 ruby-RMagick-0:2.13.1-13.fc21.x86_64 shutter-0:0.90.1-1.fc21.noarch synfig-0:0.64.1-3.fc21.i686 synfig-0:0.64.1-3.fc21.x86_64 vips-0:7.38.5-2.fc21.i686 vips-0:7.38.5-2.fc21.x86_64 vips-devel-0:7.38.5-2.fc21.i686 vips-devel-0:7.38.5-2.fc21.x86_64 vips-python-0:7.38.5-2.fc21.x86_64 vips-tools-0:7.38.5-2.fc21.x86_64 w3m-img-0:0.5.3-14.fc21.x86_64 -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick 6.8.8-10 in rawhide. Soname change.
Hi 08.04.2014 20:12, Michael Schwendt wrote: On Tue, 08 Apr 2014 18:30:25 +0400, Pavel Alexeev wrote: Dependency rebuild needed. If you are willing I'll rebuild all after 3 days if you do not answer I should not do it. Packages for rebuild: $ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* | fgrep -v 'ImageMagick-' | sort -u Why --alldeps? 1) That option is the default for repoquery. 2) Packages which are not linked with the ImageMagick libs don't need a rebuild. A query based on repoquery --whatrequires libMagick\*.so\* would be more fruitful. Unfortunately no. At least there ruby-Rmagick which depends on explicit version. It discussed before: http://old.nabble.com/Bug-564123%3A--imagemagick--Dear-other-(than-debian)-imagemagick-maintenair-td27125967.html http://old.nabble.com/Bug-564123%3A--imagemagick--Dear-other-%28than-debian%29-imagemagick-maintenair-td27125967.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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review Swap
Hello, Christopher. I'll review it. 09.02.2014 17:40, Christopher Meng wrote: Hi, This is a program which can check your system based on the open public CVE data, a bit like lynis, is another auditing utility. I hope someone can review it: cvechecker https://bugzilla.redhat.com/show_bug.cgi?id=1062808 Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: orphan/retire gradle
25.11.2013 22:45, Mikolaj Izdebski wrote: W dniu 25.11.2013 18:16, Pavel Alexeev pisze: How groovy will be in Fedora? Is it mean it also will be retired soon? No, there are no plans of retiring groovy. (Groovy can be either with Ant or Gradle. Fedora uses the first option.) Thanks, Mikolaj. But IIRC groovy = 2.0 switched to gradle build only? Have not you either plans to update it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: orphan/retire gradle
26.11.2013 15:06, punto...@libero.it wrote: Il 26/11/2013 11:34, Pavel Alexeev ha scritto: 25.11.2013 22:45, Mikolaj Izdebski wrote: W dniu 25.11.2013 18:16, Pavel Alexeev pisze: How groovy will be in Fedora? Is it mean it also will be retired soon? No, there are no plans of retiring groovy. (Groovy can be either with Ant or Gradle. Fedora uses the first option.) Thanks, Mikolaj. But IIRC groovy = 2.0 switched to gradle build only? yes Have not you either plans to update it? dont forget this problem groovy-all 1.8.x asm3 groovy-all 2.x asm4 gradle use groovy-all 1.8.x ( with asm3) and asm4 Then we have circle? That problem what you discussing before (pointed in mail list previously)? So, no chance update both without exception use binary bundled version or fully maintain alternative build system (bootstrap)? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: orphan/retire gradle
26.11.2013 20:00, punto...@libero.it пишет: Il 26/11/2013 16:42, Pavel Alexeev ha scritto: 26.11.2013 15:06, punto...@libero.it wrote: Il 26/11/2013 11:34, Pavel Alexeev ha scritto: 25.11.2013 22:45, Mikolaj Izdebski wrote: W dniu 25.11.2013 18:16, Pavel Alexeev pisze: How groovy will be in Fedora? Is it mean it also will be retired soon? No, there are no plans of retiring groovy. (Groovy can be either with Ant or Gradle. Fedora uses the first option.) Thanks, Mikolaj. But IIRC groovy = 2.0 switched to gradle build only? yes Have not you either plans to update it? dont forget this problem groovy-all 1.8.x asm3 groovy-all 2.x asm4 gradle use groovy-all 1.8.x ( with asm3) and asm4 Then we have circle? yes That problem what you discussing before (pointed in mail list previously)? yes, but if you do the same type of question the answer is always the same So, no chance update both without exception use binary bundled version or fully maintain alternative build system (bootstrap)? what would change? ... own nothing ... gradle, use at runtime those libraries, and don't work with our ... Ok, sorry for the stupid questions. May be it because I can't believe in it. One more question. Did you see how other distributions handle it? Debian have groovy 2.1.0 ( http://packages.debian.org/experimental/groovy ) and gradle 1.4 ( http://packages.debian.org/search?searchon=nameskeywords=gradle ) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: orphan/retire gradle
Hi. I'm as groovy user want see it in Fedora. And now try build it. Have you tried update to gradle 1.9? Have it same conflicts? 12.11.2013 19:58, punto...@libero.it wrote: hi i decide to remove gradle form Fedora there are too many problems actually for maintain this package incompatible dependencies (gradle may require package versions no longer shipped in Fedora) or for e.g. conflicts with objectweb-asm 3.3.1 and 4.1 libraries https://bugzilla.redhat.com/show_bug.cgi?id=976330 https://bugzilla.redhat.com/show_bug.cgi?id=958008 https://bugzilla.redhat.com/show_bug.cgi?id=985702 regards gil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: orphan/retire gradle
Hi, 25.11.2013 17:31, punto...@libero.it wrote: Il 25/11/2013 13:55, Pavel Alexeev ha scritto: hi Hi. I'm as groovy user want see it in Fedora. And now try build it. Have you tried update to gradle 1.9? no Have it same conflicts? yes, see org.codehaus.groovy:groovy-all:1.8.x (not available, not importable in fedora) ship asm3 classes org.apache.maven:maven-ant-tasks:2.1.3 unusable need to switch to newer eclipse aether-ant-tasks org.sonatype.aether:aether-*:1.13.1 , need to switch to newer eclipse aether regards gil Did you tried contact upstream to resolve such issues? And thanks for the answers. 12.11.2013 19:58, punto...@libero.it wrote: hi i decide to remove gradle form Fedora there are too many problems actually for maintain this package incompatible dependencies (gradle may require package versions no longer shipped in Fedora) or for e.g. conflicts with objectweb-asm 3.3.1 and 4.1 libraries https://bugzilla.redhat.com/show_bug.cgi?id=976330 https://bugzilla.redhat.com/show_bug.cgi?id=958008 https://bugzilla.redhat.com/show_bug.cgi?id=985702 regards gil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: orphan/retire gradle
25.11.2013 20:32, punto...@libero.it пишет: Il 25/11/2013 17:02, Pavel Alexeev ha scritto: Hi, 25.11.2013 17:31, punto...@libero.it wrote: Il 25/11/2013 13:55, Pavel Alexeev ha scritto: hi Hi. I'm as groovy user want see it in Fedora. And now try build it. Have you tried update to gradle 1.9? no Have it same conflicts? yes, see org.codehaus.groovy:groovy-all:1.8.x (not available, not importable in fedora) ship asm3 classes org.apache.maven:maven-ant-tasks:2.1.3 unusable need to switch to newer eclipse aether-ant-tasks org.sonatype.aether:aether-*:1.13.1 , need to switch to newer eclipse aether regards gil Did you tried contact upstream to resolve such issues? And thanks for the answers. yes, but without success Sad tor heard. How groovy will be in Fedora? Is it mean it also will be retired soon? 12.11.2013 19:58, punto...@libero.it wrote: hi i decide to remove gradle form Fedora there are too many problems actually for maintain this package incompatible dependencies (gradle may require package versions no longer shipped in Fedora) or for e.g. conflicts with objectweb-asm 3.3.1 and 4.1 libraries https://bugzilla.redhat.com/show_bug.cgi?id=976330 https://bugzilla.redhat.com/show_bug.cgi?id=958008 https://bugzilla.redhat.com/show_bug.cgi?id=985702 regards gil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
04.10.2013 01:35, Kevin Fenzi пишет:
Here's attached another run of my sources/patches url checker.
Please fix any packages you are responsible for in rawhide, and other
branches as other changes permit.
- There are 3067 lines in this run. Up from 1007 last run.
(Which was 2.5 years ago)
700 sourcecheck-20070826.txt
620 sourcecheck-20070917.txt
561 sourcecheck-20071017.txt
775 sourcecheck-20080206.txt
685 sourcecheck-20080214.txt
674 sourcecheck-20080301.txt
666 sourcecheck-20080401.txt
660 sourcecheck-20080501.txt
642 sourcecheck-20080603.txt
649 sourcecheck-20080705.txt
662 sourcecheck-20080801.txt
912 sourcecheck-20081114.txt
884 sourcecheck-20090215.txt
1060 sourcecheck-20090810.txt
932 sourcecheck-20091101.txt
932 sourcecheck-20091104.txt
1612 sourcecheck-20100105.txt
1391 sourcecheck-20100106.txt
1007 sourcecheck-20100531.txt
3067 sourcecheck-20130930.txt
You can find the results file at:
http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930.txt
$ wget -c
http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930.txt
-q -O- | grep -i Hubbitus
hubbitus:BADURL:ccze-0.2.1.tar.gz:ccze
Upstream site seams down.
Freshmeat page http://freecode.com/projects/ccze refer to debian page.
Should I change URL to it?
hubbitus:BADURL:httpd-2.2.22.tar.bz2:httpd-itk
Not require untill httpd updates to be able build httpd-itk as MPM.
hubbitus:BADURL:ImageMagick-6.8.6-3.tar.xz:ImageMagick
Updated.
hubbitus:BADURL:lde-2.6.1.tar.gz:lde
Updated.
hubbitus:BADURL:qutim-0.3.1.tar.bz2:qutim
Has conditional sources:
%if
0%{?GIT}
Source0:
qutim-0.3.0%{?GIT:.git%{GIT}}.tar.xz
%else
Source0:
http://qutim.org/downloads/%{name}-%{version}.tar.bz2
%endif
Which seams not handled correctly.
hubbitus:BADURL:rabbit4.1-src.tar.gz:RabbIT
Updated.
hubbitus:BADURL:sqlite3-dbf_2011.01.24.tar.gz:sqlite3-dbf
Upstream site seams to be rearranged. Wrote to author.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
Hi 28.08.2013 20:31, Basil Mohamed Gohar wrote: On 08/28/2013 10:41 AM, Solomon Peachy wrote: On Wed, Aug 28, 2013 at 10:13:09AM -0400, Basil Mohamed Gohar wrote: Sorry to come out of left field like this, but would the system profile info we collect on install be useful in determining the weight of the need for some of these drivers? For example, if there is still a bunch of SIS video adapters out there, we might prioritize support for that driver, but then not for others that don't show-up in our hardware surveys. Another way to look at it is the platform capabilities of these graphics devices. For example, Fedora 19's release notes claims a minimum of 1GB RAM is required. Were there any pre-PCIe platforms capable of supporting this much RAM? Plenty! The common limitation in the pre-PCIe era was 2GB or 4GB (e.g., common 32-bit architecture memory limits). I have several that are non-PCIe and have 2GB of RAM. They run Fedora just fine. They do, however, have more modern AGP-based video cards installed, however. I haven't bothered with the embedded video adapter on them, so I cannot speak to their suitability for running Fedora 19. I have old desktop installation with matrox-mga driver used. Is it will only single VESA driver choose which do smaller resolution for that? -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning ne7ssh
Hi. I'll orphan ne7ssh https://admin.fedoraproject.org/pkgdb/acls/name/ne7ssh library. It is FBFS after last botan update. Upstream did not answer on my report (only via web-form). As I also do not use it in my development now I do not want spent time to even try porting it. -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Overall rawhide package testing.
Hi. 26.08.2013 16:19, Alec Leamas wrote: As agreed [1], we have run fedora-review on (almost) all packages in current rawhide. The results are now available at [2]. Here are reports on issues by package and packages by issue. May be it could be possible list it by packager? I want check my packages, but it is slightly troublesome. We have discussed sending email about these results to the package owners. Is this a good idea? In any case, I think it might be good if you check your own packages, chances are that something otherwise unnoticed is discovered. Please don't forget the README. For those interested in the overall distribution, the package by issue reports perhaps also might add something as well as the 'stats' file in the top dir. --alec [1] https://lists.fedoraproject.org/pipermail/devel/2013-August/188133.html [2] http://leamas.fedorapeople.org/fedora-review/tree/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Update uniconvertor to 2.0
Hi. Long awaited release [1][2]. After long time work restarted and on this time without dependency to sk1lib [3]. Just updating. I think only inkskape use it: $ repoquery --whatrequires uniconvertor inkscape-0:0.48.4-4.fc19.x86_64 And through call command-line to convert. So, nothing to rebuild. I also plan update it in Fedora 19 too if no one argue (it have old long outstanding bug, I hope it fixed [4]). Just for the info. [1] - https://bugzilla.redhat.com/show_bug.cgi?id=870642 [2] - https://bugzilla.redhat.com/show_bug.cgi?id=986552 [3] - https://bugzilla.redhat.com/show_bug.cgi?id=759747 [4] - https://bugzilla.redhat.com/show_bug.cgi?id=923581 -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retire pdfbook
That is obsoleted by texlive-pdfjam-3:svn29752.2.02-0.5.fc20.noarch https://bugzilla.redhat.com/show_bug.cgi?id=999211 I'll proceed if no any argue in 1 hour. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: orphaning of packages
16.08.2013 12:12, Robin Lee wrote: On Fri, Aug 16, 2013 at 12:19 PM, Dennis Gilmore den...@ausil.us mailto:den...@ausil.us wrote: Hi all, Jima has not been able to make enough time for Fedora lately and asked me to orphan and announce the packages he maintains. alsa-oss aoetools banner banner taken. bwm-ng clusterssh conserver graphviz libdnet libstatgrab miau ngrep It is not orphaned. If needed I can (co)maintain it/ perl-X11-Protocol rblcheck scanssh vblade feel free to pick them up Dennis -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Release packages ownership
24.08.2013 00:35, Fabien Nicoleau пишет: Hi, due to a lack of time, I released the ownership of most of my packages : cclive https://admin.fedoraproject.org/pkgdb/acls/name/cclive?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Command line video extraction utility clive https://admin.fedoraproject.org/pkgdb/acls/name/clive?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Video extraction tool for user-uploaded video hosts grilo-plugins https://admin.fedoraproject.org/pkgdb/acls/name/grilo-plugins?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Plugins for the Grilo framework libquvi https://admin.fedoraproject.org/pkgdb/acls/name/libquvi?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- A cross-platform library for parsing flash media stream libquvi-scripts https://admin.fedoraproject.org/pkgdb/acls/name/libquvi-scripts?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Embedded lua scripts that libquvi uses for parsing the media details qdevelop https://admin.fedoraproject.org/pkgdb/acls/name/qdevelop?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Development environment dedicated to Qt4 quvi https://admin.fedoraproject.org/pkgdb/acls/name/quvi?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Command line tool for parsing video download links trickle https://admin.fedoraproject.org/pkgdb/acls/name/trickle?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Portable lightweight userspace bandwidth shaper trickle taken umph https://admin.fedoraproject.org/pkgdb/acls/name/umph?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Command line tool for parsing video links from Youtube feeds vbindiff https://admin.fedoraproject.org/pkgdb/acls/name/vbindiff?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- Visual binary diff nomnom https://admin.fedoraproject.org/pkgdb/acls/name/nomnom?_csrf_token=a20dac710fd0964437afa7c441bfb9b72e57b277 -- The graphical video download tool Feel free to take it :) Eponyme -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: httpd-itk broken over release because httpd updated without dependencies caring and maintainer refuse fixing
Thank you. I have done it - https://fedorahosted.org/fesco/ticket/1125. 16.06.2013 18:55, Kalev Lember wrote: 2013-06-16 16:47, Pavel Alexeev skrev: [snip] So, is there any chance to force apply these patches (as provenpackager I can do it itself)? Or I only may wait next apache release or apply again such ugly hacks with sources? Disclaimer: I am not familiar with the issue at hand, and I'm not taking any sides here. The general policy is that provenpackagers do not override primary maintainers. As a provenpackager, I would never commit something to apache knowing that its maintainer doesn't want it. The body that oversees package maintainers is FESCo. File a ticket with the FESCo trac if there are unsolvable issues between maintainers. https://fedorahosted.org/fesco/ Hope this helps, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
httpd-itk broken over release because httpd updated without dependencies caring and maintainer refuse fixing
Hello. I've speak about bug [1] Fix is trivial - just apply 3 svn commits from upstream svn repository (provided revision numbers). Users ask when it will fixed (look at few dependent bugs), but I think it could not. Other way is ugly - build my own Apache and include its sources as it was done before, but Joe Orton (primary httpd maintainer) promise (on refusing my request to provide convenient environment to build MPMs) in 2.4 version module structure for that [2,3]. Update to 2.4 version happened, but dependent httpd-itk still broken. So, is there any chance to force apply these patches (as provenpackager I can do it itself)? Or I only may wait next apache release or apply again such ugly hacks with sources? [1] - https://bugzilla.redhat.com/show_bug.cgi?id=957447 https://bugzilla.redhat.com/show_bug.cgi?id=957447 [2] - https://bugzilla.redhat.com/show_bug.cgi?id=479575 [3] - https://bugzilla.redhat.com/show_bug.cgi?id=597772 -- 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: I'm willing unorphan dead python-chm
31.03.2013 20:45, Kevin Fenzi wrote: On Sun, 31 Mar 2013 20:10:47 +0400 Pavel Alexeev fo...@hubbitus.com.ru wrote: Kevin thank you for the fast answer. No problem. ...snip... In pkgbd devel and Fedora 19 branches marked as Deprecated in status and owned by orphan. https://admin.fedoraproject.org/pkgdb/acls/name/python-chm narasim listed as co-maintainer meantime. Oops. I must have been looking at the wrong package. :( Try now? Yes, now it works. I took it. Thank you very much. And I do not see any available controls to became maintainer of it. I checkout sources and there only dead.package file. By checkout previous git commit I able build package locally. But what should be next? You will need to take ownership, and push a commit that undoes the dead.package, test, build, etc. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130330 changes
30.03.2013 23:02, Kevin Fenzi wrote: So, next week is alpha freeze... perhaps we could get this and the branched report looking a lot nicer before then? python-chm was retired, so these should also be retired or python-chm I'm new python-chm maintainer. I build it soon. -- 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: I'm willing unorphan dead python-chm
Kevin thank you for the fast answer. 30.03.2013 23:07, Kevin Fenzi wrote: On Sat, 30 Mar 2013 21:22:25 +0400 Pavel Alexeev fo...@hubbitus.com.ru wrote: Hello all. It is needed for chm2pdf which maintainer I became. It's also needed by archmage package. It already in Fedora https://admin.fedoraproject.org/pkgdb/acls/name/archmage and owned by lbazan (Luis Enrique Bazán De León). As I see there had not big problem with it. It was orphaned 2013-03-11 according to dead.package file. Around 2 weeks ago and I missed that. So by [1] I hope I can resurrect it without re-review. It doesn't show as depreciated in pgkdb, I also don't see it blocked. Perhaps someone else already took care of it for you? ;) You should just be able to rebuild it now... In pkgbd devel and Fedora 19 branches marked as Deprecated in status and owned by orphan. https://admin.fedoraproject.org/pkgdb/acls/name/python-chm narasim listed as co-maintainer meantime. And I do not see any available controls to became maintainer of it. I checkout sources and there only dead.package file. By checkout previous git commit I able build package locally. But what should be next? kevin -- 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
I'm willing unorphan dead python-chm
Hello all. It is needed for chm2pdf which maintainer I became. As I see there had not big problem with it. It was orphaned 2013-03-11 according to dead.package file. Around 2 weeks ago and I missed that. So by [1] I hope I can resurrect it without re-review. But second step is not so clear to me. Must I fill ticket to Release Engineering team to unblock it? [1] http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
17.03.2013 05:39, Rex Dieter wrote: Orion Poplawski wrote: On 03/16/2013 07:38 AM, Rex Dieter wrote: Orion Poplawski wrote: On 03/14/2013 09:34 AM, Orion Poplawski wrote: Okay, looks like upstream cmake has a patch, I'll get it into rawhide ASAP. Scratch that, it was a hack for Arch Linux's hacked version of ImageMagick sonames that doesn't work for Fedora. Will need to work on a fix... I've a little experience adding pkg-config hints to cmake, I'll help look into it. As noted in http://public.kitware.com/Bug/view.php?id=14012 an issue with pkg-config in cmake is that it isn't always present on all of the platforms that cmake supports. But it is still probably the way to go on Linux. OK, first-draft patch sent upstream and applied to cmake-2.8.11-0.3.rc1.fc20 As far as I could tell, only one package in fedora is affected, converseen, and confirmed it builds ok now. Thank you very much! Then I push ImageMagick into rawhide. Could you please provide upstream bug url for that to monitor status? -- rex -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
17.03.2013 16:40, Rex Dieter пишет: Pavel Alexeev wrote: 17.03.2013 05:39, Rex Dieter wrote: As noted in http://public.kitware.com/Bug/view.php?id=14012 an issue with pkg-config in cmake is that it isn't always present on all of the platforms that cmake supports. But it is still probably the way to go on Linux. OK, first-draft patch sent upstream and applied to cmake-2.8.11-0.3.rc1.fc20 As far as I could tell, only one package in fedora is affected, converseen, and confirmed it builds ok now. Thank you very much! Then I push ImageMagick into rawhide. Could you please provide upstream bug url for that to monitor status? The one orion gave earlier in the thread, http://public.kitware.com/Bug/view.php?id=14012 Sorry. Thank you. Meantime ImageMagick landed in rawhide - http://koji.fedoraproject.org/koji/taskinfo?taskID=5132168 -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
13.03.2013 20:24, Remi Collet wrote: Le 13/03/2013 17:16, Remi Collet a écrit : php-pecl-imagick As you're the owner of this one, if you prefer to update it, see http://svn.php.net/viewvc?view=revisionrevision=329769 Patch incorporated, thanks again. http://koji.fedoraproject.org/koji/taskinfo?taskID=5134433 Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
14.03.2013 12:17, Remi Collet wrote: Le 13/03/2013 17:16, Remi Collet a écrit : php-magickwand Upstream 1.0.9-2 (yes with a -) includes the fix (and the php54 patch) Thanks. It built too - http://koji.fedoraproject.org/koji/taskinfo?taskID=5134893 Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction
Welcome. You could start here http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group 16.03.2013 23:14, Niyo Raoul wrote: Greetings, I am a system engineer at ORINUX BURUNDI. I am not experienced in big development project. But i love programming and design. However, i have been using fedora for years and building personal application in c, c++, java, python and assembly. And also i did some scripting with shell. Therefore, i really want to participe in fedora development while learning and sharing my small experience. Please any guidelines or mentor are the most welcome to help. Regards, Raoul NIYO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
13.03.2013 20:24, Remi Collet wrote: Le 13/03/2013 17:16, Remi Collet a écrit : php-pecl-imagick As you're the owner of this one, if you prefer to update it, see http://svn.php.net/viewvc?view=revisionrevision=329769 Thanks for pointing. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
14.03.2013 20:04, Orion Poplawski пишет: On 03/14/2013 09:34 AM, Orion Poplawski wrote: Okay, looks like upstream cmake has a patch, I'll get it into rawhide ASAP. Scratch that, it was a hack for Arch Linux's hacked version of ImageMagick sonames that doesn't work for Fedora. Will need to work on a fix... Could you do that? I think then I should wait until that happened before IM landed to rawhide, is not? -- 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
ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Good day.
By request https://bugzilla.redhat.com/show_bug.cgi?id=849065 I plan
split off ImageMagick-libs sub-package and update ImageMagick to last
6.8.3-9 version.
There many changes including so-name bump and version scheme change from
upstream:
libMagickCore.so.5 became libMagickCore-6.Q16.so
I plan push it in rawhide 14-17 March if no one will argue.
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5117303
Also changed some directories. Major differences in layout:
%files
- %defattr(-,root,root,-)
- %doc QuickStart.txt ChangeLog Platforms.txt
- %doc README.txt LICENSE NOTICE AUTHORS.txt NEWS.txt
- %{_libdir}/libMagickCore.so.5*
- %{_libdir}/libMagickWand.so.5*
+ %doc README.txt LICENSE NOTICE AUTHORS.txt NEWS.txt ChangeLog
Platforms.txt
%{_bindir}/[a-z]*
- %{_libdir}/%{name}-%{VER}
- %{_datadir}/%{name}-%{VER}
%{_mandir}/man[145]/[a-z]*
%{_mandir}/man1/%{name}.*
+
+ %files libs
+ %defattr(-,root,root,-)
+ %doc LICENSE NOTICE AUTHORS.txt QuickStart.txt
-%{_libdir}/libMagickCore.so.6*
-%{_libdir}/libMagickWand.so.6*
++%{_libdir}/libMagickCore-6.Q16.so.*
++%{_libdir}/libMagickWand-6.Q16.so.*
+ %{_libdir}/%{name}-%{VER}
-%{_datadir}/%{name}-%{VER}
++%{_datadir}/%{name}-6
%exclude %{_libdir}/%{name}-%{VER}/modules-Q16/coders/djvu.*
--%{_sysconfdir}/%{name}
++%{_sysconfdir}/%{name}-6
%files devel
%defattr(-,root,root,-)
@@@ -254,15 -267,15 +269,19 @@@
%{_bindir}/Magick-config
%{_bindir}/MagickWand-config
%{_bindir}/Wand-config
--%{_libdir}/libMagickCore.so
--%{_libdir}/libMagickWand.so
++%{_libdir}/libMagickCore-6.Q16.so
++%{_libdir}/libMagickWand-6.Q16.so
%{_libdir}/pkgconfig/MagickCore.pc
++%{_libdir}/pkgconfig/MagickCore-6.Q16.pc
%{_libdir}/pkgconfig/ImageMagick.pc
++%{_libdir}/pkgconfig/ImageMagick-6.Q16.pc
%{_libdir}/pkgconfig/MagickWand.pc
++%{_libdir}/pkgconfig/MagickWand-6.Q16.pc
%{_libdir}/pkgconfig/Wand.pc
--%dir %{_includedir}/%{name}
--%{_includedir}/%{name}/magick
--%{_includedir}/%{name}/wand
++%{_libdir}/pkgconfig/Wand-6.Q16.pc
++%dir %{_includedir}/%{name}-6
++%{_includedir}/%{name}-6/magick
++%{_includedir}/%{name}-6/wand
%{_mandir}/man1/Magick-config.*
%{_mandir}/man1/MagickCore-config.*
%{_mandir}/man1/Wand-config.*
@@@ -274,6 -287,6 +293,7 @@@
%files doc
%defattr(-,root,root,-)
++%doc %{_datadir}/doc/%{name}-6
%doc %{_datadir}/doc/%{name}-%{VER}
%doc LICENSE
@@@ -281,17 -294,17 +301,19 @@@
%defattr(-,root,root,-)
%doc Magick++/AUTHORS Magick++/ChangeLog Magick++/NEWS Magick++/README
%doc www/Magick++/COPYING
- %{_libdir}/libMagick++.so.5*
-%{_libdir}/libMagick++.so.6*
++%{_libdir}/libMagick++-6.Q16.so.*
%files c++-devel
%defattr(-,root,root,-)
%doc Magick++/examples
%{_bindir}/Magick++-config
--%{_includedir}/%{name}/Magick++
--%{_includedir}/%{name}/Magick++.h
--%{_libdir}/libMagick++.so
++%{_includedir}/%{name}-6/Magick++
++%{_includedir}/%{name}-6/Magick++.h
++%{_libdir}/libMagick++-6.Q16.so
%{_libdir}/pkgconfig/Magick++.pc
++%{_libdir}/pkgconfig/Magick++-6.Q16.pc
%{_libdir}/pkgconfig/ImageMagick++.pc
++%{_libdir}/pkgconfig/ImageMagick++-6.Q16.pc
%{_mandir}/man1/Magick++-config.*
Dependency rebuild required.
List of dependent packages are (maintainers in bcc):
$ repoquery --whatrequires 'libMagickCore.so.*' 'libMagickWand.so.*'
'libMagick++.so.*' --enablerepo=rawhide --source --qf '%{name}' | sed
's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | grep -v ImageMagick | sort -u
ale
autotrace
calibre
converseen
cuneiform
digikam
dmapd
drawtiming
dx
emacs
gdl
imageinfo
inkscape
k3d
kxstitch
libdmtx
nip2
oxine
pfstools
php-magickwand
php-pecl-imagick
psiconv
q
rss-glx
ruby-RMagick
spectrum
techne
transcode
vips
xastir
xine-lib
zbar
--
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: the need of Offline Updates
05.02.2013 19:58, Reindl Harald wrote: Am 05.02.2013 16:49, schrieb Jochen Schmitt: On Tue, Feb 05, 2013 at 10:30:50AM -0500, Colin Walters wrote: 2) Modern Windows updates are safer than RPM, speaking broadly jokingly? show me a upgrade of production machines from F9 to F17 without end in a inconsistent system on windows - you can't, i have been there windows is missing anything like transaction-checks tp prevent one package is overwriting files of a different one, has no package-deps over the complete system tune2fs 1.42.3 (14-May-2012) Filesystem volume name: / Last mounted on: / Filesystem UUID: 918f24a7-bc8e-4da5-8a23-8800d510442 Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file uninit_bg dir_nlink Filesystem created: Mon Aug 18 06:48:05 2008 3.7.3-101.fc17.x86_64 #1 SMP Fri Jan 18 17:40:57 UTC 2013 and as you can see above this was installed with F9 in 2008 I have longer history. On my old desktop at home I have installed now Fedora 16 (plan upgrade) which was always only upgraded, no reinstalls at all. And so history starts from far ~2002. Initially it was ASPLinux [1] (Fedora Core derivation) and then cross-repo upgrade on Fedora Core 2. After that only upgrades. I can't say what all was very smoothly and without problems. I remember 2 times when it does not boot and I had been forced start troubleshoot and resurrect system. But in most cases upgrade was mostly easy. And I awaiting doing it just more easy and more robust, not drop such really great capability from Linux world! [1] http://distrowatch.com/table.php?distribution=asp http://distrowatch.com/table.php?distribution=asp -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
04.02.2013 11:38, Kevin Kofler wrote: David Tardon wrote: Hi, On Sun, Feb 03, 2013 at 11:26:35PM -0600, Chris Adams wrote: Once upon a time, Stephen John Smoogen smo...@gmail.com said: My understanding is that /usr/bin/soffice is a symlink in order to keep backwards maintainability. Personally I say both packages drop it because star office is s 1999. :) There's more than just soffice: $ rpm -ql libreoffice-core | grep bin/ | xargs ls -ld -rwxr-xr-x. 1 root root 362 Dec 6 18:37 /usr/bin/libreoffice -rwxr-xr-x. 1 root root 32 Dec 6 18:37 /usr/bin/ooffice -rwxr-xr-x. 1 root root 39 Dec 6 18:37 /usr/bin/ooviewdoc lrwxrwxrwx. 1 root root 11 Jan 9 12:46 /usr/bin/openoffice.org - libreoffice lrwxrwxrwx. 1 root root 38 Jan 9 12:46 /usr/bin/soffice - /usr/lib64/libreoffice/program/soffice -rwxr-xr-x. 1 root root 360 Dec 6 18:37 /usr/bin/unopkg There is also /usr/bin/oowriter, oocalc, ooimpress, oodraw and oobase that belong to other libreoffice-* subpackages. Ugh. That's just one more reason to not allow the Apache fork to be packaged. May it just use say aoo prefix instead of oo (f.e. aoowriter, aoocalc and so on)? In any case when it gows in .desktop files, and in GUI will properly named as Apache OpenOffice Writer for end users have no sense how really named binary or what symlinks it have. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
04.02.2013 10:47, Kevin Kofler wrote: Jaroslav Reznik wrote: = Features/ApacheOpenOffice = https://fedoraproject.org/wiki/Features/ApacheOpenOffice Feature owner(s): Andrea Pescetti pesce...@apache.org Add Apache OpenOffice, the free productivity suite, to Fedora. A big -1 to this feature, and in fact I'd urge FESCo to veto that package outright (or if it somehow already made it into Fedora, to get it blocked in Koji and Obsoleted by libreoffice ASAP). Rationale: * What benefit does this package have over LibreOffice, to justify carrying 2 packages doing essentially the same thing? * OpenOffice is a huge package and a big strain on our build system (Koji); IMHO, having 2 versions of it would be a gigantic waste of resources. * LibreOffice is clearly the community version to be preferred: - All major distros support it. - Red Hat people work on it. - AFAIK, it has more features. Does anyone have or known real table of differences of futures? I think it may be important see there. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: releasing ownership (maintainers/co-maintainers required)
04.02.2013 13:28, Petr Šabata пишет: On Mon, Feb 04, 2013 at 11:14:48AM +0200, Rakesh Pandit wrote: On 3 February 2013 17:20, Pavel wrote: I would like take dvtm and pstreams-devel. I have released the ownership. You can claim them. Thank you. I've taken dvtm as I've been more or less maintaining it for a while now (I missed it in the original list). I'd welcome Pavel as a comaintainer, of course. Thank you. I had taken pstreams-devel and apply as co-maintainer to dvtm. P -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership
29.01.2013 10:59, lakshminaras2...@gmail.com wrote: I am releasing ownership of the following packages due to lack of time chm2pdf -- A tool to convert CHM files to PDF files I have taken this one. Strange, but can't do it for Fedora 17. emacs-slime -- The superior lisp interaction mode for emacs gnome-guitar -- A small suite of applications for the guitarist griffith -- Media collection manager phatch -- Photo batch processor python-chm -- Python package for CHM files handling stow -- Manage the installation of software packages from source xcftools -- Command-line tools for extracting information from XCF files xcftools not 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
Re: releasing ownership (maintainers/co-maintainers required)
29.01.2013 06:51, Richard Shaw wrote: On Mon, Jan 28, 2013 at 7:37 PM, Rakesh Pandit rakesh.pan...@gmail.com wrote: tinyxml -- A simple, small, C++ XML parser I've requested this one in pkgdb. It is interesting and small library and there I found tends to bundle it in other packages which is not listed as exception: $ repoquery --whatprovides '*/tinyxml.h' | sort -u aqsis-debuginfo-0:1.8.2-1.fc18.x86_64 astromenace-debuginfo-0:1.2-17.fc18.x86_64 cal3d-devel-0:0.11.0-13.fc18.i686 cal3d-devel-0:0.11.0-13.fc18.x86_64 clish-debuginfo-0:0.7.3-4.1.i686 clish-debuginfo-0:0.7.3-4.1.x86_64 clish-devel-0:0.7.3-4.1.i686 clish-devel-0:0.7.3-4.1.x86_64 fife-devel-2:0.3.3r3-3.fc18.i686 fife-devel-2:0.3.3r3-3.fc18.x86_64 gource-debuginfo-0:0.38-1.fc18.x86_64 ldview-debuginfo-0:4.2-34.1.i686 ldview-debuginfo-0:4.2-34.1.x86_64 openclonk-debuginfo-0:5.2.2-14.1.i686 openclonk-debuginfo-0:5.2.2-14.1.x86_64 simspark-debuginfo-0:0.2.3-3.fc18.x86_64 tinyxml-devel-0:2.6.1-4.fc18.i686 tinyxml-devel-0:2.6.1-4.fc18.x86_64 I think you should address it, at least fill appropriate bugs for corresponded maintainers. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: releasing ownership (maintainers/co-maintainers required)
I would like take dvtm and pstreams-devel. 29.01.2013 05:37, Rakesh Pandit wrote: Hi, I haven't been able to keep up maintenance of packages for year plus now and I don't see myself doing that for next 6-7months more. Right now I am too busy with university course work. But I will come back and contribute in free time after summers. My co-maintainers have done wonderful work in taking care of some of important packages. I request existing fedora packagers if they can take up these packages. For packages which already have active co-maintainers already, you can collaborate with them. Some of these packages will need lot of work and few are worth even dropping. As soon as packagers can claim them in this thread I will drop ownership. I will keep myself co-maintain for few packages (will request from new owners). Mayavi -- The Mayavi scientific data 3-dimensional visualizer acheck -- Check common localisation mistakes acheck-rules -- Rules for acheck bunny -- Instrumented C code security fuzzer code2html -- Convert source code to HTML coredumper -- Library to create core dumps cpptest -- A portable and powerful and simple unit testing framework for C++ ctemplate -- A simple but powerful template language for C++ dayplanner -- An easy and clean Day Planner django-mako -- Mako Templates Plugin for Django djvulibre -- DjVu viewers, encoders, and utilities dnrd -- A caching, forwarding DNS proxy server dvtm -- Tiling window management for the console enet -- Thin, simple and robust network layer on top of UDP examiner -- Utility to disassemble and comment foreign executable binaries flickcurl -- C library for the Flickr API freeimage -- Multi-format image decoder library fuse-zip -- Fuse-zip is a fs to navigate, extract, create and modify ZIP archives gedit-plugins -- Plugins for gedit gflags -- Library for commandline flag processing ginac -- C++ library for symbolic calculations gnaural -- A multi-platform programmable binaural-beat generator gnucap -- The Gnu Circuit Analysis Package jed -- Fast, compact editor based on the S-Lang screen library libao -- Cross Platform Audio Output Library libeXosip2 -- A library that hides the complexity of using the SIP protocol libkml -- A KML library written in C++ with bindings to other languagues libogg -- The Ogg bitstream file format library libosip2 -- oSIP is an implementation of SIP linphone -- Phone anywhere in the whole world by using the Internet lynis -- Security and system auditing tool nebula -- Intrusion signature generator ntop -- A network traffic probe similar to the UNIX top command octave -- A high-level language for numerical computations opencv -- Collection of algorithms for computer vision ortp -- A C library implementing the RTP protocol (RFC3550) pdf2djvu -- PDF to DjVu converter perl-Search-Xapian -- Xapian perl bindings php-markdown -- Markdown implementation in PHP php-oauth -- PHP Authentication library for desktop to web applications php-pear-Auth -- Authentication provider for PHP php-xmpphp -- XMPPHP is the successor to Class.Jabber.PHP pstreams-devel -- POSIX Process Control in C++ python-AppTools -- Enthough Tool Suite Application Tools python-EnthoughtBase -- Core package for the Enthought Tool Suite python-EnvisageCore -- Extensible Application Framework python-EnvisagePlugins -- Plug-ins for the Envisage framework python-Traits -- Explicitly typed attributes for Python python-TraitsBackendQt -- PyQt backend for Traits and TraitsGUI python-TraitsGUI -- Traits-capable windowing framework python-durus -- A Python Object Database python-setupdocs -- Setuptools plugin ratproxy -- A passive web application security assessment tool sitecopy -- Tool for easily maintaining remote web sites stardict-dic-hi -- Hindi dictionary for stardict svgalib -- Low-level fullscreen SVGA graphics library taskcoach -- Your friendly task manager tinyxml -- A simple, small, C++ XML parser txt2rss -- Convert from txt to rss unhide -- Tool to find hidden processes and TCP/UDP ports from rootkits up-imapproxy -- University of Pittsburgh IMAP Proxy uriparser -- URI parsing library - RFC 3986 xsel -- Command line clipboard and X selection tool zile -- Zile Is Lossy Emacs Regards, -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
01.02.2013 00:42, James Hogarth wrote: Is it? http://blog.mariadb.org/explanation-on-mariadb-10-0/ and http://blog.mariadb.org/mariadb-10-0-and-mysql-5-6/ seem to suggest that MariaDB will no longer be following Mysql as religiously as the feature suggests I'd still say yes since the context of this discussion is mysql 5.5 to mariadb 5.5 and nothing to do with mysql 5.6 and the time for mariadb 10/11 to become fully compatible to what's brought to the table in that which was the relevant discussion in those blog posts... And if someone is using upstream themselves they are responsible to manage that ... and assuming the versioned obsoletes is used as discussed yesterday then there would be no accidental overwrite and compatibility if mysql-5.6 is on the system and the admin updated without thinking... Is it really hard maintain both? May be it have worth also package and support Percona with XtraDB? James -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using rpms for non-root installs
Hello. Yum also may be used with --installroot=root I have used yum and rpm on that kind with aliases for current user to install software from repositories on shared hosting absolutely without root privileges. In most cases it works, except some cases when particular binaries looks say own config files by fixed path (/etc/appname/default.conf). In such situation you may deep look documentation about config configuration options, environment variables and so. As last alternative before start patching source code you may also just patch elf binary to replace that path by some with the same length (I have done it by compose symlynks appropriately). In any case, it some sort of hacks and depend from you really needs. If it intended for other users and predictable reproducible results you should patch software to bring them configurability in some way. And offer such patches to upstream also will be good idea. 31.01.2013 11:40, Michael Stahnke пишет: You actually may have an option. It's dirty, and here be dragons. I know this from working on RPM on AIX, so again, it's hacky. I did this on a CentOS 6.3 box for my example, should work on Fedora. You can do something like: ls zip-3.0-1.el6.x86_64.rpm mkdir $HOME/.myrpm cp -pr /var/lib/rpm/* $HOME/.myrpm/ chown -R $USER $HOME/.myrpm/ rpm -Uvh --justdb --dbpath $HOME/.myrpm zip-3.0-1.el6.x86_64.rpm rpm2cpio zip-3.0-1.el6.x86_64.rpm | cpio -idmv rpm -q --dbpath $HOME/.myrpm zip Results: [vagrant@localhost ~]$ rpm -q --dbpath /home/vagrant/.myrpm zip zip-3.0-1.el6.x86_64 [vagrant@localhost ~]$ rpm -q zip package zip is not installed You now have zip installed (and rooted) in $HOME. You'd have to add the --dbpath option to rpm any time you used it, and it would get out of sync with the system rpm database unless you wrote some tooling around that. But it's completely do-able. Again, it's ugly and I don't recommend it. stahnma -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
01.02.2013 00:17, drago01 wrote: On Thu, Jan 31, 2013 at 8:10 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2013-01-31 at 14:20 +0100, Robert Mayr wrote: I think that's not the point, one of the two suites will be dominant and you can't provide both of them on a live image for example. LibreOffice was introduced to our live images and we hit target 1GB, do you really think it could be useful having a larger image just because you want to provide both of the office suites? The proposal explicitly says that it doesn't envisage including OO on any images or in any default install configurations, simply adding it as an option in the package repositories. Which doesn't really need a FESCo approval ... just a package review. Meantime there one sentence which optionally require changes in LibreOffice too: The /usr/bin/soffice alias is still a problem since (in the Fedora packages) it would conflict between LibreOffice and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too, at least using the Alternatives system. I think it should be approved first if it really required. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
01.02.2013 17:38, Matej Cepl wrote: On 2013-01-31, 22:07 GMT, Chris Adams wrote: I'm not saying having both is a bad thing, but I would like to think that there's some thought given to does Fedora gain from having both, since there is a cost involved. We don’t (unfortunately?) have policy to stop somebody from packaging whatever they want (if it satisfies Fedora packaging policy). Unfortunately? Isn't it is freedom really? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Releasing ownership
03.02.2013 21:48, Kevin Fenzi wrote: On Sun, 03 Feb 2013 18:32:58 +0400 Pavel Alexeev fo...@hubbitus.com.ru wrote: 29.01.2013 10:59, lakshminaras2...@gmail.com wrote: I am releasing ownership of the following packages due to lack of time chm2pdf -- A tool to convert CHM files to PDF files I have taken this one. Strange, but can't do it for Fedora 17. It somehow got marked depreciated instead of just orphaned. I've fixed it and you should be able to take it now... Thank you. I have taken it too. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
25.01.2013 22:27, Lennart Poettering пишет: On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: On 01/24/2013 06:12 PM, Lennart Poettering wrote: If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? ... Of course, you could tell the user as last step of your script to please reboot now, but if you do that your update isn't online anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... This is a pessimistic view but I think it's not as intractable. There are two separate aspects to it: discovery what needs to be restarted, and the actual process of restarting. The discovery is almost there: we know the resources (libs, files, etc) that were replaced, so it's a matter of walking the list of running processes and checking if they depend on those resources. I can see how transient I/O, including dlopen() could be tricky, but I don't think it's fundamentally impossible---at worst, it'd be implementing some sort of /proc/1234/history-of-opened-fd mechanism. That doesn't work. Let's say my app needs to display a certain icon in some dialog. The next version of that app doesn't need that icon anymore, so on upgrade the icon is deleted. At the same time the user is still running that app, and then enters the dialog. The app now looks for the icon, and doesn't find it. Bang. There is no sane way to determine all these dependencies, because many of them are never explicit, and only temporary in nature. Well written apps load a lot of resources lazily. That has the side effect that you can never know those deps, until they are actually needed. The icon thing is just one example, you can now extrapolate from that... Sorry but how such use case different from simple firefox update in current release when it happened parallel with browsing?? It may also lead to that unpredictable behavior. Off course you will say it shouldn't be major release in stable Fedora. And off course it is true. But anyone can't guaranty what even change or delete 1 file do not lead to unstable app. So for that cases graphical application similar to PackageKit suggests user reboot (and may suggest only reload certain apps) with list of apps, based on maintainers expectation from (suggest reboot in bodhi update system). I hope you do not suggest force reload such apps for user of force always offline update for that thinks. In that point of view online distro update differs only by amount of updated packages which suggest reboot for user. And I may himself plan reboot when I want... -- 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: Fedora Members Absent or present?
20.01.2013 16:14, Emmanuel Seyman wrote: * Frank Murphy [20/01/2013 11:43] : Is there any definitive way to determine if person X has left the Fedoraproject as a whole? The closest thing we have to a definitive way is pingou's fedora_active_user script. https://github.com/pypingou/fedora-active-user Interesting script. Is it planned bring it into Fedora rpm? Say in fedora-packager or standalone package? Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
07.06.2012 12:52, Tadej Janež написал:
On Wed, 2012-06-06 at 21:27 +0400, Pavel Alexeev wrote:
With regard to the packages that depend on ImageMagick that you already
updated: will you revert those commits in git
I'm unsure I known how doing that correctly.
Does it enough do just:
git revert 56e05f..HEAD
or I must do something like:
git reset 56e05f
git reset --soft HEAD@{1}
git commit -m Revert to 56e05fced
git reset --hard
I'm not a git expert but I think you should use:
- git reset --hard HEAD^
- git push -f
to completely nuke the last commit and never see it again.
I tried doing that for my package (techne), however, it didn't work:
$ git push -f
Total 0 (delta 0), reused 0 (delta 0)
remote: error: denying non-fast-forward refs/heads/f16 (you should pull
first)
To ssh://ta...@pkgs.fedoraproject.org/techne
! [remote rejected] f16 - f16 (non-fast-forward)
error: failed to push some refs to
'ssh://ta...@pkgs.fedoraproject.org/techne'
Am I doing something wrong here?
and delete the
corresponding builds in koji?
Do you mean koji untag-pkg or something other? Could you please
provide link on such procedure description?
I couldn't find a procedure description for deleting unwanted builds in
koji. Since this purging issue is clearly above our heads, the
sensible thing would be to ask for help of those who have more
experience handling these issues.
Maybe file a ticket at https://fedorahosted.org/rel-eng/report for the
Release Engineering team and ask them how to handle the issue.
Is it problem just unpush update and leave other tings as is? In case
you need build and update it in the future you just make such changes
(including clear changelog if you are willing) and again bump release.
Do you think there may be problems with it?
As we so speak there it shouldn't happened for most of packages in
stable branch at all.
Regards,
Tadej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
06.06.2012 03:09, Tadej Janež написал:
On Tue, 2012-06-05 at 13:55 +0400, Pavel Alexeev wrote:
I'll plan unpush that update and work on patching ImageMagick to handle
these issues locally. But I'm not security expert and can't guarantee
something except mentioned patch apply (contrary leave it on upstream
authors, as I was want do first).
Even though this means a lot of your work has been waisted, I think it's
the right decision to patch ImageMagick to fix the security issues
instead of doing a large-scale update of Fedora 16.
I'm doubt... But I think it is not have worth start it dispute again.
With regard to the packages that depend on ImageMagick that you already
updated: will you revert those commits in git
I'm unsure I known how doing that correctly.
Does it enough do just:
git revert 56e05f..HEAD
or I must do something like:
|git reset 56e05f
git reset --soft HEAD@{1}
git commit -m Revert to 56e05fced
git reset --hard|
?
and delete the
corresponding builds in koji?
Do you mean koji untag-pkg or something other? Could you please provide
link on such procedure description?
Regards,
Tadej Janež
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
04.06.2012 21:11, Pete Walter написал: Pavel Alexeevforumat hubbitus.com.ru writes: May be in next time? What disadvantages you are seen proceed with that update? Do you try test it? No, I did not test this. And here's a few reasons why I think this shouldn't be pushed: - You are forcing others to do work they otherwise wouldn't need to do. Why do you want me to test ImageMagick functionality in 57 dependant packages? Fix your security bugs and leave other packages alone. F16 is supposed to be stable. - A major ImageMagick update that introduces new features and new code invalidates the QA that has gone into the packages that use ImageMagick. - Needless update churn. We have the Stable Updates Policy for a reason. Do you development on rawhide and let stable Fedora release be stable. - The soname bump breaks third party packages that use ImageMagick libraries. An example is 'transcode' from rpmfusion. http://fedoraproject.org/wiki/Updates_Policy explicitly says that such ABI bumps are left to the discretion of FESCO and the packager. Have you already asked FESCO for their blessing? Note that you should open this dialog _BEFORE_ you build or push updates. Pete Ok. I understand you point. I do not share your point of view, but the respect among others to speak out. But as I mention and thankfully also Johannes Lips (thanks for some positive words) such argue was much more appreciated before all work had been done. For that I announce my intentions for the week ago. I'll plan unpush that update and work on patching ImageMagick to handle these issues locally. But I'm not security expert and can't guarantee something except mentioned patch apply (contrary leave it on upstream authors, as I was want do first). Only one other think before I do that. Is it will be needed then introduce epoch in Fedora 16 IM build to push less version in stable branch? Is it normal introduce epoch tag only in that branch, and not on all others? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
04.06.2012 22:26, Michael Schwendt написал:
On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:
Additionally have worth I try read carefully all docs about
provenpackager and such updates and have not found how deal with such
versions.
It's not provenpackager specific stuff, but found in the basic packaging
guidelines:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag
I had look in my packages and few others and found it was
updated many times in that way.
Just read the page linked above. There is no strict requirement to
apply this release versioning scheme for old branches. If newer branches
would always win RPM Version Comparison because their %version field
is _higher_, you can bump %release in older branches without risk.
In packages were was present subrelease
after %{?dist} - I increase it.
Should or must in next time I add it in any package even it does not
have it??
As the guidelines say: Be careful with this!
Thank you very much Michael. It's helpful.
But what still is not clear to me - if it secure, may it be applied to
all packages on update in stable releases? Or instead I should check if
increasing release do not break version sequence in branches - do that.
And only if it false, introduce subrelease like %{?dist}.1?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
05.06.2012 16:09, Michael Schwendt wrote:
On Tue, 05 Jun 2012 14:05:13 +0400, Pavel Alexeev wrote:
04.06.2012 22:26, Michael Schwendt написал:
On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:
Additionally have worth I try read carefully all docs about
provenpackager and such updates and have not found how deal with such
versions.
It's not provenpackager specific stuff, but found in the basic packaging
guidelines:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag
I had look in my packages and few others and found it was
updated many times in that way.
Just read the page linked above. There is no strict requirement to
apply this release versioning scheme for old branches. If newer branches
would always win RPM Version Comparison because their %version field
is _higher_, you can bump %release in older branches without risk.
In packages were was present subrelease
after %{?dist} - I increase it.
Should or must in next time I add it in any package even it does not
have it??
As the guidelines say: Be careful with this!
Thank you very much Michael. It's helpful.
But what still is not clear to me - if it secure, may it be applied to
all packages on update in stable releases? Or instead I should check if
increasing release do not break version sequence in branches - do that.
And only if it false, introduce subrelease like %{?dist}.1?
Well, if you want to spare yourself the extra check, simply use the
%{?dist}.N scheme for old branches _always_. Then you're on the safe side.
[That means: If you see only a %{?dist} in an old branch, introduce the
%{?dist}.N scheme even if it's not strictly necessary. If you see the
%{?dist}.N scheme is used already, increase N appropriately. Then it's
up to the package owner, or anyone else who touches the package, to
check whether the normal %{?dist} scheme would be fine when preparing
another bug-fix release sometime after you.]
Ok, thank you for the explanation.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
28.05.2012 16:45, Tomáš Smetana wrote: On Sun, 27 May 2012 23:28:03 +0400 Pavel Alexeevfo...@hubbitus.com.ru wrote: Hi. Due to the security issues ([1] for example) and act as newcomer provenpackager I'll plan update ImageMagick in Fedora 16 too (I should had been done it early off course). It seams addressed in rawhide. Hello, may I ask why you prefer bumping the soname instead of just patching the vulnerabilities? The patch is actually ready. Replacing the library with an ABI incompatible version in the stable Fedora release sounds like an overkill in this case. Thanks and regards, Because there several security issues and I think more reliable let it doing to upstream author rather than guaranties all correct in Fedora. In case there one or two sequential bugs I'll try off course handle it separately without so expensive updates off course. Rebuild all dependencies is done now, update submitted for testing: https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16 Testers are welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
03.06.2012 22:57, Tadej Janež wrote:
Pavel,
On Tue, 2012-05-29 at 20:21 +0400, Pavel Alexeev wrote:
It is main reason why I request provenpackager rights. In fedora 17 it
was so painful because I several times asks build dependencies and
then ask help to push updates too.
I think in that turn now I can do all that myself, so it should be
smoother.
As there around 6 security issues, I think update upstream release is
easiest, and furthermore robust way handle it.
I've seen you didn't listen to Tomáš's or Kalev's advice on not bumping
the ImageMagick's soname in a stable release.
Furthermore, you didn't give any warning to the maintainers of the
dependent packages (except for the message on this list).
In my opinion, being a provenpackager is no excuse for not doing that.
Please, use the packagename-ow...@fedoraproject.org addresses to send
out emails to the appropriate package maintainers.
I post message there over week ago. I thought it was sufficient.
Provenpackager rights off course do not excuse that or other mistakes.
On the contrary it only take me possibility make such tasks without make
troubles for others. If I must also write to each maintainer separately
- I promise do it next time. Sorry.
For techne (one of the dependent packages which I maintain) you bumped
the release from 0.2.3-2 to 0.2.3-3, which breaks upgrades to F-17 and
rawhide.
Is there a way to revert the change and make a 0.2.3-2.fc16.1 build?
I do not known unfortunately.
Furthermore I've submitted update to testing ta moment read that
[1].https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16
May be it possible just update in Fedora 17 too?
Additionally have worth I try read carefully all docs about
provenpackager and such updates and have not found how deal with such
versions. I had look in my packages and few others and found it was
updated many times in that way. In packages were was present subrelease
after %{?dist} - I increase it.
Should or must in next time I add it in any package even it does not
have it??
I apologize for the inconvenience. Can I help something now?
If you or other will insist I may unpush that update and try patch IM
for all issues off course... But I really do not want doing it now.
Best regards,
Tadej Janež
[1]
https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16
https://admin.fedoraproject.org/updates/nip2-7.28.4-2.fc16,q-7.11-12.fc16,gdl-0.9.2-4.fc16,dx-4.4.4-21.fc16,dmapd-0.0.47-3.fc16,k3d-0.8.0.2-5.fc16,inkscape-0.48.1-10.fc16,zbar-0.10-9.fc16,xine-lib-1.1.20.1-2.fc16,xastir-2.0.0-4.fc16,techne-0.2.3-3.fc16,ruby-RMagick-2.13.1-6.fc16.4,rss-glx-0.9.1.p-10.fc16,psiconv-0.9.8-9.fc16,php-pecl-imagick-3.0.0-10.fc16,php-magickwand-1.0.9-2.fc16,pfstools-1.8.3-3.fc16,oxine-0.7.1-12.fc16,libdmtx-0.7.2-5.fc16,kxstitch-0.8.4.1-7.fc16,calibre-0.8.33-3.fc16,vips-7.28.2-2.fc16,imageinfo-0.05-14.fc16,drawtiming-0.7.1-5.fc16,converseen-0.4.9-2.fc16,autotrace-0.31.1-26.fc16.2,ale-0.9.0.3-6.fc16,ImageMagick-6.7.7.5-1.fc16
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
04.06.2012 20:10, Pete Walter wrote: Pavel Alexeevforumat hubbitus.com.ru writes: If you or other will insist I may unpush that update and try patch IM for all issues off course... But I really do not want doing it now. In my opinion, the right way to handle this is to backport the security fixes. You even have patches linked to each of the security bugs on bugzilla.redhat.com. And yes, this means unpushing the update with the soname bump. May be in next time? What disadvantages you are seen proceed with that update? Do you try test it? Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Easy way of testing packages?
Something similar already was requested: https://bugzilla.redhat.com/show_bug.cgi?id=563285 Please look there also for some mentioned alternatives in comments. 02.06.2012 17:40, Stefan Schulze Frielinghaus wrote: Hi all, is there an easy way to test packages except of using $ yum --enablerepo=updates-testing updatepackage For example, on May 30 a message reached the devel list that Pidgin needs an update because of a security flaw. A new package was created and needed karma in order to get pushed to stable quickly. Now comes the part I do not like very much: I have to download and install the package and all its sub-packages manually from koji. In case of the mentioned Pidgin update, I have to check if one of the following packages are installed on my system: finch finch-devel libpurple libpurple-devel libpurple-perl libpurple-tcl pidgin pidgin-devel pidgin-docs pidgin-evolution pidgin-perl pidgin-debuginfo Of course, I could wait two or three days (I do not have the exact number in mind) until the package hits updates-testing and is finally deployed to the mirror which I use, but for a package which fixes a security flaw, this is an awful long time. So using yum and enable the updates testing repo is not really a good choice. But manually downloading and checking which packages I should update is bothersome. My question is: Is there an easy/friendly way of testing packages in order to quickly give karma? I only found [1] suggesting yum with the updates-testing repo enabled. Regards, Stefan [1] http://fedoraproject.org/wiki/QA/Updates_Testing -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
28.05.2012 16:23, Kalev Lember wrote: On 05/27/2012 10:28 PM, Pavel Alexeev wrote: Hi. Due to the security issues ([1] for example) and act as newcomer provenpackager I'll plan update ImageMagick in Fedora 16 too (I should had been done it early off course). It seams addressed in rawhide. Hi Pavel, I'm not sure it's a good idea to do ImageMagick soname bump and a large scale rebuild in a stable Fedora release. The last ImageMagick soname bump in F17 was very painful, with broken deps in the repo for about a month. Isn't it possible to backport the individual security patches to F16 and avoid the ImageMagick ABI change? It is main reason why I request provenpackager rights. In fedora 17 it was so painful because I several times asks build dependencies and then ask help to push updates too. I think in that turn now I can do all that myself, so it should be smoother. As there around 6 security issues, I think update upstream release is easiest, and furthermore robust way handle it. How are other distros handling the security issue? I'd also like to quote the Updates Policy for Stable Releases[1]: ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers. [1] http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases There also statement about security updates allowing that ( http://fedoraproject.org/wiki/Updates_Policy#Security_fixes ): If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then a package may be rebased onto a version that upstream supports. The definition of practicality is left to the judgement of FESCO and the packager. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RealHotspot availability
20.05.2012 04:32, Sérgio Basto wrote: On Sex, 2012-05-18 at 21:49 -0400, Gerry Reno wrote: On 05/18/2012 09:42 PM, Dan Williams wrote: On Fri, 2012-05-18 at 18:21 -0400, Gerry Reno wrote: In looking back through some of the meeting minutes I saw that RealHotspot has been approved for Fedora 18. === #fedora-meeting: FESCO (2012-03-19) === Meeting started by limburgher at 18:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-03-19/fesco.2012-03-19-18.00.log.html . Meeting summary --- ... * #823 F18 Feature: Network Manager hotspots - https://fedoraproject.org/wiki/Features/RealHotspot (limburgher, 18:08:10) * AGREED: F18 Network Manager hotspots is passed (+8,-:0,0:0) (limburgher, 18:10:51) ... What are the chances of having RealHotspot backported for F17 and F16 and available as an update? For F17 at least, quite good if your network card supports it. At the moment, that means Intel 6xxx and later, ath5k, ath9k, and perhaps a few others. Try this: iw phy and if under Supported interface modes: you see AP, then your card and driver are capable of real AP mode. Dan None of my devices will connect using adhoc connection in my Fedora 16 installation and having a true AP hotspot would certainly improve things tremendously. . Thanks Dan. # iw list | sed -n '/Supported interface modes/,/AP/p' Supported interface modes: * IBSS * managed * AP Looks like I'm good as far as my card and driver. Just hoping for a backport to F16 since I have one of those nvidia video cards that couldn't run F17. This project is awesome, I need it to connect my android !, and I will try follow it. I don't know what is need but we always can get all packages from 18 and compile in 16. Now I run hostapd which long time in Fedora especially for my wife's Android deviсe which do not allow connect AdHoc without root environment. About nvidia , if you are talking about property driver , rpmfusion just built new drivers , about 6 hours ago. Thanks, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New libtiff version in rawhide, requires dependent packages rebuild
06.05.2012 20:10, Tom Lane wrote: I have pushed libtiff 4.0.1 into rawhide, replacing libtiff 3.9.5. This entails a library soname bump and a few small source-level incompatibilities, as detailed at http://www.remotesensing.org/libtiff/v4.0.0.html By my count there are about a hundred dependent packages (see list below), so to avoid breaking rawhide until everything can be rebuilt, I have put the old 3.9.x library into a temporary subpackage libtiff-compat. (We used the same trick a few months ago for libpng and it seemed to work all right.) I did trial rebuilds of all these packages against libtiff 4.0.1, and found only three that appear to need any source-code changes; though another dozen have pre-existing FTBFS problems which means I can't tell for sure if they would build against the new libtiff. If any of these packages are yours, please rebuild at the soonest opportunity. If you need advice about fixing either libtiff- or libpng-dependent code, contact me off-list and I'll be glad to try to help. regards, tom lane ... hubbitusImageMagick hubbitusfotoxx Done. http://koji.fedoraproject.org/koji/taskinfo?taskID=4070773 http://koji.fedoraproject.org/koji/taskinfo?taskID=4070843 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16-F17 preupgrade (Re: F17 Beta to slip by an additional week.)
29.04.2012 15:00, Ian Malone wrote: On 29 April 2012 01:05, Richard Vickeryrichard.vicker...@gmail.com wrote: On 2012-04-26 10:50 AM, Michał Piotrowskimkkp...@gmail.com wrote: Hi, W dniu 9 kwietnia 2012 17:46 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: Hi, Is it possible to upgrade now from F16 to F17 with preupgrade? Has anyone tried to preupgrade from F16 to F17? Are there any problems related to UsrMove (or anything else)? For those of us who have let our command-line skills wane slightly, what is the command for preupgrade, if this is how it is accomplished? # yum install preupgrade $ preupgrade However, one pre-upgrade bug that may prevent you installing and is not on the blockers list: https://bugzilla.redhat.com/show_bug.cgi?id=813973 Preupgrade fails to build proper squashfs.img URL on boot with small boot partitions Not apparent till you've downloaded all packages and rebooted into the installer. Yes, I also seen it yesterday in update process. Also it does not try other mirrors if current not in sync (and ignore fastestmirror yum plugin option) and what I think more critical it crashes in i18n environment: Bugs filled by me yesterday: https://bugzilla.redhat.com/buglist.cgi?emailreporter2=1emailtype2=exactemailreporter1=1emailtype1=exactquery_format=advancedbug_status=NEWbug_status=ASSIGNEDbug_status=MODIFIEDbug_status=ON_DEVbug_status=ON_QAbug_status=VERIFIEDbug_status=RELEASE_PENDINGbug_status=POSTemail2=pahan%40hubbitus.infoemail1=pahan%40hubbitus.infocomponent=preupgradeproduct=Fedora https://bugzilla.redhat.com/buglist.cgi?emailreporter2=1emailtype2=exactemailreporter1=1emailtype1=exactquery_format=advancedbug_status=NEWbug_status=ASSIGNEDbug_status=MODIFIEDbug_status=ON_DEVbug_status=ON_QAbug_status=VERIFIEDbug_status=RELEASE_PENDINGbug_status=POSTemail2=pahan%40hubbitus.infoemail1=pahan%40hubbitus.infocomponent=preupgradeproduct=Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: node.js rpm and looking for an sponsor
Then delete it in %prep or %setup to be sure. 22.04.2012 18:07, Adrian Alves wrote: check my spec i dont use a bundle, check how i built it On Sun, Apr 22, 2012 at 11:03 AM, Michael Scherer m...@zarb.org mailto:m...@zarb.org wrote: Le dimanche 22 avril 2012 à 10:53 -0300, Adrian Alves a écrit : Hello Guys, Am new on fedora but I built RPMs since 2007 https://fedoraproject.org/wiki/User:Alvesadrian Am looking for an sponsor to push node.js RPM http://alvesadrian.fedorapeople.org/ I already open a ticket in bugzilla Bug 815018 - Review Request: nodejs - javascript fast build framework Hi, there was already 2 attempts : https://bugzilla.redhat.com/show_bug.cgi?id=634911 https://bugzilla.redhat.com/show_bug.cgi?id=732552 basically, the problem is that node.js bundle openssl ( + various patches, of course, or this is not fun ), etc : https://github.com/joyent/node/tree/master/deps and this against the policy : https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel N�n�r)em�h�yhiם�w^�� -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
16.04.2012 09:33, Toshio Kuratomi написал: On Mon, Apr 16, 2012 at 02:02:31AM +0400, Pavel Alexeev wrote: 16.04.2012 00:51, Toshio Kuratomi wrote: On Sun, Apr 15, 2012 at 11:16:58PM +0400, Pavel Alexeev wrote: As I look it for me for first glance. Install or update one package scenario (yum install foo): 1) Client ask last foo package version. 2) Server calculate all dependencies by self algorithms and return in requested form (several may be used from JSON to XML) full list of dependencies for that package. No other overhead provided like dependencies of all packages, filelist etc. 3) Client got it, intercept with current installed packages list, exclude whats already satisfy needs, and then request each other what does not present starting from 1. Update scenario (yum update): 1) Client ask repo-server to get a list of actual versions available packages. 2) Server answer it. 3) Client found which updated and request its as in first scenario for update. I don't think this would be a speedup. Instead of the CPUs of tens of thousands of computers doing the depsolving, you'd be requiring the CPUs of a single site to do it. Yes. And as many clients do the same work, caching will give there good results. So, sequence requests will costs nothing. No. Most requests will be different because they have a different initial state. If you read my suggestion I do not suggest send from client big upload overhead of current installed state. Client ask from server full dependency which package have, and then intercept answer with current installed software. So, answer for each client for package will be the same. Additionally it still allow resolve dependencies with several enabled repositories when some dependencies can't be resolved on one server repo. The server that constructs the subsets of repodata would become single point of failures whereas currently the repodata can be hosted on any mirror. This setup would be much more sensitive to mirrors and repodata going out of sync. There'd likely be times when a new push has gone out where the primary mirror was the only server which could push packages out as every other mirror would be out of sync wrt the repodata server. Yes, as I wrote initially it introduce more requirements to the server, especially some sort of scripting allowed (php, perl, python, ruby or other). But at all it is not exclude mirroring as it is free software and any ma install it, and sync metadata information in traditional way. If you're requiring that mirrors run the script on their systems, then that makes this idea pretty much a non-starter. We've been told by mirrors that they do not want to do this. For that mirror traditional fallback scheme will be available. But if that will be implemented, I think appeared new mirrors also. And client may prefer one or another type depending by they needs. Additional it can be implemented as only solver mirror to serve requests and then point to download on other(s) mirrors. In that case requirements will be small and it may be hosted even on shared hosting. So, I too can provide that mirror. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
14.04.2012 20:44, Reindl Harald wrote: Am 14.04.2012 18:39, schrieb Richard W.M. Jones: On Sat, Apr 14, 2012 at 06:21:15PM +0200, drago01 wrote: On Wed, Apr 11, 2012 at 8:01 PM, Richard W.M. Jonesrjo...@redhat.com wrote: I'm not arguing that's how yum works now, but it doesn't have to work that way! It could incrementally download the RPMs during depsolving, test that they work together, and with that information download further packages as necessary ... Ugh no ... the whole point of the repodata is to avoid having to download the rpms to calculate deps. Well the whole point is to get the best possible software quality, user experience and performance (accepting that we cannot maximize all of these at the same time). It's my personal opinion that yum does not do well on any of these three criteria. and you think performance and user experience will get better by downloading packages for dep-solve? are you aware that many people do not have endless bandwith, traffic-limuts and storage and can you imagine how slow this all would be? yum should not waste ressources which i did even in the recent past by consuming wy too much memory resulting get killed from oom-killer on machines with 512 MB RAM and yes, 512 MB RAM are really enough for many servers and there is no argumentation for a UPDATER eating more ressources as the whole server in normal operations What the point always store it in XML or Sqlite static files instead of provide service on server side to speedup solving? Off course it may require some script running on server side to provide such service and some limit mirroring (there may be fallback to old scheme), but also it may have many benefits: 1) On server side metadata may be any size, optimized for inner use if it will not intended to transfer each time. 2) It may be cached. 3) Clients may ask only small parts of data, which is most cases is what wanted. As I look it for me for first glance. Install or update one package scenario (yum install foo): 1) Client ask last foo package version. 2) Server calculate all dependencies by self algorithms and return in requested form (several may be used from JSON to XML) full list of dependencies for that package. No other overhead provided like dependencies of all packages, filelist etc. 3) Client got it, intercept with current installed packages list, exclude whats already satisfy needs, and then request each other what does not present starting from 1. Update scenario (yum update): 1) Client ask repo-server to get a list of actual versions available packages. 2) Server answer it. 3) Client found which updated and request its as in first scenario for update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
16.04.2012 00:51, Toshio Kuratomi wrote: On Sun, Apr 15, 2012 at 11:16:58PM +0400, Pavel Alexeev wrote: As I look it for me for first glance. Install or update one package scenario (yum install foo): 1) Client ask last foo package version. 2) Server calculate all dependencies by self algorithms and return in requested form (several may be used from JSON to XML) full list of dependencies for that package. No other overhead provided like dependencies of all packages, filelist etc. 3) Client got it, intercept with current installed packages list, exclude whats already satisfy needs, and then request each other what does not present starting from 1. Update scenario (yum update): 1) Client ask repo-server to get a list of actual versions available packages. 2) Server answer it. 3) Client found which updated and request its as in first scenario for update. I don't think this would be a speedup. Instead of the CPUs of tens of thousands of computers doing the depsolving, you'd be requiring the CPUs of a single site to do it. Yes. And as many clients do the same work, caching will give there good results. So, sequence requests will costs nothing. The clients would have to upload, the provides of their installed packages so bandwidth needs might increase. If I was installing a few packages by trial and error/memory I'd likely do yum install tmux followed closely by yum install zsh, which would require separate requests to the server to download separate dependency information as opposed to having the information downloaded once. If you request yum install tmux zsh off course it should be sent and calculated on server in one request. Also caching answers on client side not forbidden. The server that constructs the subsets of repodata would become single point of failures whereas currently the repodata can be hosted on any mirror. This setup would be much more sensitive to mirrors and repodata going out of sync. There'd likely be times when a new push has gone out where the primary mirror was the only server which could push packages out as every other mirror would be out of sync wrt the repodata server. Yes, as I wrote initially it introduce more requirements to the server, especially some sort of scripting allowed (php, perl, python, ruby or other). But at all it is not exclude mirroring as it is free software and any ma install it, and sync metadata information in traditional way. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Update ImageMagick to 6.7.6-5 in rawhide to fix several security issues
Hello. I've plan update ImageMagick in rawhide. No major changes or ABI breakage awaited. Rebuild needed only for packages explicitly depends on IM version (at least ruby-RMagick). Scratch build - http://koji.fedoraproject.org/koji/taskinfo?taskID=3977251 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick - [Fedora Update] [comment] xine-lib-1.1.20.1-3.fc17, emacs-24.0.94-3.fc17, calibre-0.8.42-1.fc17, perl-GD-SecurityImage-1.71-3.fc17, techne-0.2.1-4.fc17, gdl-0.9.2-5.fc17, autotrace
06.04.2012 19:43, Michael Schwendt написал: On Fri, 6 Apr 2012 16:57:14 +0200, CF (Christophe) wrote: On Fri, Apr 06, 2012 at 07:27:31AM -0600, Orion Poplawski wrote: Suggestions? I'm tempted to pushed this to stable so that broken deps emails start going out to get people to do the needed rebuilds. Or perhaps someone in releng can for the needed buildroot overrides? Or perhaps we drop the whole endeavor? I'd lean towards this, why do we need to push a soname bump of ImageMagick so late in the game when f17 is already in beta? If there's a critical bug in the f17 package, isn't it possible to backport the fix instead of forcing these rebuilds? There are several CVEs. As whether the fixes for them could be backported, well, somebody would need to investigate and do it. Yes, indeed. There several security issues found https://bugzilla.redhat.com/show_bug.cgi?id=807994, https://bugzilla.redhat.com/show_bug.cgi?id=807997, https://bugzilla.redhat.com/show_bug.cgi?id=807993, https://bugzilla.redhat.com/show_bug.cgi?id=808159, https://bugzilla.redhat.com/show_bug.cgi?id=804591, https://bugzilla.redhat.com/show_bug.cgi?id=804588, https://bugzilla.redhat.com/show_bug.cgi?id=808159 I have contacted with upstream author to clarify when it will be fixed in main tree. As I'll got answer I'll post update in rawhide asap. Really it have worth have that in stable branches also (but it is not in my rights now, so I must try find someone with at least with provenpackager acl who want help). So have .so.5 in F17 is good idea - in this case may be needed rebuild only dependencies explicitly depends by ImageMagick version (ruby-RMagick for example), and I think I'll can do that with contact of maintainers of that's packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update coming to 6.7.6-5 (.so.5)
28.03.2012 19:23, Orion Poplawski написал: On 03/25/2012 01:20 AM, Pavel Alexeev wrote: 24.03.2012 02:18, Orion Poplawski wrote: On 03/23/2012 02:11 PM, Pavel Alexeev wrote: I want push now builds perl-GD-SecurityImage-1.71-3.fc17 techne-0.2.1-4.fc17 gdl-0.9.2-5.fc17 calibre-0.8.39-1.fc17 autotrace-0.31.1-29.fc17.1 ImageMagick-6.7.5.6-3.fc17 with tat build overrides but got error from bodhi what ImageMagick-6.7.5.6-3.fc17 update already exists. Should I delete it first and unpushing is not enough? You can edit it and adds builds. You may have to be a proven packager or a co-maintainer to submit an update though. Others will have to confirm. No, I still can't edit it because got errors: hubbitus does not have commit access to perl-GD-SecurityImage hubbitus does not have commit access to techne I have not provenpackager rights indeed. I kindly ask FESCO to grant its me, but it not in that moment in any case. If I had them, I could compile all the packages on their own, without asking anyone. Please could you say how I may push such update now? May someone help with it if my rights is not enough? If you delete the update, I can submit a batch update. I have provenpackager rights. It will be very-very helpful and desired. But maybe you could just edit this update? -- 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
