Re: yum-builddep (Re: Compiling 32bit on 64bit Fedora)
On Thu, Sep 08, 2011 at 09:27:20AM -0400, Adam Jackson wrote: On Thu, 2011-09-08 at 10:44 +1000, Tony Breeds wrote: Hi All, On a related but different note. How hard would it be to get yum-builddep to take an --arch arg to that we can esily get the 32-bit builddeps on a 64-bit system? Is 'setarch i686 yum-builddep foo' not enough? I swear when I tried that nothing sensible happend. However trying it again today it seems to do the right thing for the 1 or 2 packages I care about. Yours Tony -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in
Hi, yum-langpacks has been working pretty well now for a while in Fedora, but all langpacks are still listed conditionally in comps' language support groups in addition to the langpacks meta-section. So for F17 I'd like to remove them all from comps, this will simplify comps a lot and if we can also remove the resulting empty language support groups it will also reduce the comps translation burden in addition to comps maintenance. A few things I noted while attempting to prune comps-f17: - most of the remaining packages in language support group are fonts and input-methods - perhaps the mandatory/default ones could Provide: fonts(lang) and input-method(lang). - normal anaconda installs support installation of multiple language support groups - I think it would be better to move the list of languages out of comps into anaconda itself (they are already translated in iso-codes, etc) - anaconda could then set langpack_locales to install langpacks for multiple languages - we maybe need to add a new yum install-lang command say to replace yum install @lang-support which could use a more aggressive version of yum-langpacks to pull the required packages. - @base and @office still list aspell-en, hunspell-en, and libreoffice-langpack-en conditionally which I think could be dropped. Anyway the fact that we can remove 1500 basically redundant lines now from comps thanks to Bill's great work on yum-langpacks is good news and would be a big win IMHO. This might well make a good F17 Feature. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum-builddep (Re: Compiling 32bit on 64bit Fedora)
On Thu, Sep 08, 2011 at 10:37:10AM +0300, Panu Matilainen wrote:
On 09/08/2011 03:44 AM, Tony Breeds wrote:
Hi All,
On a related but different note. How hard would it be to get
yum-builddep to take an --arch arg to that we can esily get the 32-bit
builddeps on a 64-bit system?
It's been recently implemented at upstream, see
https://bugzilla.redhat.com/show_bug.cgi?id=734983 for details.
Note that this is only possible when feeding spec-files to yum-builddep,
and even then it requires that spec BuildRequires are using %{_isa}
where relevant.
Thanks I'll test it out when it hits rawhide.
Yours Tony
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in
On 09/09/2011 10:50 AM, Jens Petersen wrote: Hi, yum-langpacks has been working pretty well now for a while in Fedora, but all langpacks are still listed conditionally in comps' language support groups in addition to thelangpacks meta-section. So for F17 I'd like to remove them all from comps, this will simplify comps a lot and if we can also remove the resulting empty language support groups it will also reduce the comps translation burden in addition to comps maintenance. A few things I noted while attempting to prune comps-f17: - most of the remaining packages in language support group are fonts and input-methods - perhaps the mandatory/default ones could Provide: fonts(lang) and input-method(lang). - normal anaconda installs support installation of multiple language support groups - I think it would be better to move the list of languages out of comps into anaconda itself (they are already translated in iso-codes, etc) - anaconda could then set langpack_locales to install langpacks for multiple languages - we maybe need to add a new yum install-lang command say to replace yum install @lang-support which could use a more aggressive version of yum-langpacks to pull the required packages. - @base and @office still list aspell-en, hunspell-en, and libreoffice-langpack-en conditionally which I think could be dropped. Anyway the fact that we can remove 1500 basically redundant lines now from comps thanks to Bill's great work on yum-langpacks is good news and would be a big win IMHO. This might well make a good F17 Feature. Jens Hi, Related note. How about we also change the way we manage translations for packages? This gives more control over translations to translators also translators become independent from package maintainers and can reduce burden from package maintainers taking care of translations! Shouldn't we have translations packaged independently from RPM packages? Anybody knows, how to modify the path of message catalogs (i.e. /usr/share/locale) dynamically while running an application? I would like to use a different mo file rather than the default provided by system. Is it possible? If yes, how? Thanks! -- Regards, Ankit Patel http://www.ankit644.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kudos to Tom Spot Callaway
2011/9/8 Jóhann B. Guðmundsson: On behalf of the systemd convertion team Just wanted to say thanks to Tom Spot Callaway he's been on fire today packaging submitted unit files and shipping them. Your work did not go unoticed! I do agree in particular with respect to his labour to provide cromium packages to the Fedora community. However, there is always some margin to improve: would it be possible to actually sign the chromium builds somehow? ~C -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning maradns
On 08/09/11 12:23, Tomasz Torcz wrote: On Thu, Sep 08, 2011 at 08:52:38PM +1000, Michael Fleming wrote: On 7/09/2011 4:50 PM, Tomasz Torcz wrote: On Tue, Sep 06, 2011 at 02:23:36PM +0100, Khusro Jaleel wrote: On 06/09/11 06:31, Michael Fleming wrote: I've released ownership of the aforementioned package, as I've not used it in any meaningful way in some time and don't have the time to maintain it further. Upstream development seems to have picked up of late (was dormant for a long time) so potential future maintainers will have something interesting to hack on :-) Michael. I'm willing to have a go at maintaining it, I have made a few packages on CentOS in the past for internal company use (BIND 9.8) and a font package for Fedora (tlomt-league-gothic) and I think I should be able to do it. Are there any special gotchas or issues that I need to be aware of? I for one suggest including systemd unit file now: https://bugzilla.redhat.com/show_bug.cgi?id=656891 You won't be able to do it after F16 Beta. That and an update (either 1.4 or the newer 2.0, which now calls the resolver daemon Deadwood) and you're in good shape, as best I can see. Be aware that duende (the process that usually spawns off maradns' recursive and zoneserver authoritative/transfer portions) can be tricky if you're not used to such things. If you've ever worked with djbdns/dnscache before the concept is much clearer, I feel :-) Just drop duende. systemd does everything what duende provides. OK, unfortunately I don't think I'll be able to touch this for a couple of weeks at least. Sorry about that, I'll try to do it sooner if possible. Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
Sorry, you are mixing two things: 1) One is testing environment and it can be probably well defined, clean, etc. 2) The other thing is maintainer mindset. You can try to convince yourself to take a different look but I doubt it will work. It reminds me like if you do patch review of your patches, which doesn't make sense. You, as a developer, are not able to spot weak points. And it is expected that every developer delivers well tested and well behaving code from his side (i.e. automatic +1 karma from his side). If there is not enough karma for his package to bring it into the stable, then there is probably time to ask somebody (probably on fedora-devel), to test this package. Vit BTW no policy can stop some evil maintainer who will create other Fedora accounts and give karma to his packages under different identities. You can even add karma without Fedora identity, but I am not sure if that counts. Dne 9.9.2011 10:13, Nils Philippsen napsal(a): On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote: I don't think a maintainer can realistically replace wide-spread user based testing in a variety of environments. I didn't argue that this would be the case, but rather that persons who are developers/package maintainers can also wear a tester's hat as long as they can keep these roles separate. In light of that, we can either accept a maintainer +1 as I tested this as I would use it and it worked (which should be implied by them submitting the update ^^ already anyway), or we can disallow it as the policy says. ^ No, implicitly assuming that the final package was tested just because a maintainer submitted it is wrong in my eyes. To me, a maintainer submitting an update simply means I've built (a) new package(s) which should fix these problems, now it/they can be tested. It shouldn't make a shred of difference if a person testing an update package is a maintainer or not in this process. I don't think adding more definitions or steps to the existing policy is really going to improve anything. Yet making a special case of testing by a maintainer makes the process more complicated. The policy regarding testing done by maintainers shouldn't be longer than one or two paragraphs and be summed up in keep development and testing separate, ensure that your testing environment isn't negatively affected by your developing. Nils -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New Transifex: TM, QA controls, .desktop, Private projects
Hi all! A quick announcement that we've done a major upgrade on Transifex.net, which brings a few exciting features for Fedora's developers and translators, including a brand-new theme. Some of these were advocated by the Fedora community itself, so thank you for your feedback! http://blog.transifex.net/2011/09/freemium/ http://fedora.transifex.net/ Here are the most interesting features introduced: - Quality control tools for developers - New file formats incl. .desktop XLIFF - Translation Memory Spell-checking - Brand new look-n-feel! - Translation of private proprietary projects ## QA features for developers: - **Pseudo files**: Developers can download special auto-generated files to test their project's internationalization support before translations. This will help catch strigs which were not marked for translation or spot ones which will render badly in certain locales (too tall, wrap around). - **Live developer comments**: Give translation instructions on specific strings straight from the web editor. ## QA features for translators: - **Transation memory**: Transifex now stores your project's past translations in a Translation Memory and offers them in the web editor when a similar string appears. This greatly helps translators save time and increases the quality and consistency of your translations. - **Integrated spell-checker**: The Web Editor now warns on simple and common language mistakes when translating. ## New file formats: .desktop, XLIFF, etc Developers can now submit .desktop files for translation in Transifex. Translators will work with them just like with any other file, watch them for changes, translate online offline etc. Read more information about the changes and background info on our dedicated blog post and our help pages. http://blog.transifex.net/2011/09/freemium/ http://help.transifex.net/ Hope you like these new features use them to improve our translations. =) -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Fri, Sep 9, 2011 at 4:13 AM, Nils Philippsen n...@redhat.com wrote: On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote: I don't think a maintainer can realistically replace wide-spread user based testing in a variety of environments. I didn't argue that this would be the case, but rather that persons who are developers/package maintainers can also wear a tester's hat as long as they can keep these roles separate. In light of that, we can either accept a maintainer +1 as I tested this as I would use it and it worked (which should be implied by them submitting the update ^^ already anyway), or we can disallow it as the policy says. ^ No, implicitly assuming that the final package was tested just because a maintainer submitted it is wrong in my eyes. To me, a maintainer submitting an update simply means I've built (a) new package(s) which should fix these problems, now it/they can be tested. It shouldn't make a shred of difference if a person testing an update package is a maintainer or not in this process. I meant that it should be implied that the package maintainer already did some amount of testing on the package before they submitted it as an update. A basic minimum touch test that it doesn't break things, etc. This is entirely outside the updates process and just common sense good practice. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110909 changes
Compose started at Fri Sep 9 08:15:35 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) airrac-0.1.0-2.fc16.i686 requires libstdair.so.0.36 airrac-0.1.0-2.fc16.i686 requires libstdairuicl.so.0.36 airrac-0.1.0-2.fc16.x86_64 requires libstdairuicl.so.0.36()(64bit) airrac-0.1.0-2.fc16.x86_64 requires libstdair.so.0.36()(64bit) askbot-0.7.17-1.fc16.noarch requires django-recaptcha-works assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-mapi-devel-3.1.90-1.fc16.i686 requires openchange-devel = 0:0.11-2 evolution-mapi-devel-3.1.90-1.fc16.x86_64 requires openchange-devel = 0:0.11-2 evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libcamel-provider-1.2.so.28()(64bit) evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libebook-1.2.so.11()(64bit) evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libcamel-1.2.so.28()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.i686 requires libboost_serialization-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_filesystem-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_system-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_serialization-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) garden-1.0.8-3.fc15.x86_64 requires liballeg.so.4.2()(64bit) giggle-0.5-7.fc16.i686 requires libedataserver-1.2.so.14
rawhide report: 20110909 changes
Compose started at Fri Sep 9 08:15:07 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46 389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46 389-admin-1.1.23-1.fc17.i686 requires libicudata.so.46 389-admin-1.1.23-1.fc17.x86_64 requires libicuuc.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicui18n.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicudata.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.i686 requires libicuuc.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicui18n.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicudata.so.46 389-adminutil-1.1.14-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicudata.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-dsgw-1.1.7-1.fc16.x86_64 requires libicudata.so.46()(64bit) R-core-2.13.1-4.fc17.i686 requires libicuuc.so.46 R-core-2.13.1-4.fc17.i686 requires libicui18n.so.46 R-core-2.13.1-4.fc17.x86_64 requires libicuuc.so.46()(64bit) R-core-2.13.1-4.fc17.x86_64 requires libicui18n.so.46()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicuuc.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicui18n.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) boost-graph-1.47.0-3.fc16.i686 requires libicuuc.so.46 boost-graph-1.47.0-3.fc16.i686 requires libicui18n.so.46 boost-graph-1.47.0-3.fc16.x86_64 requires libicuuc.so.46()(64bit) boost-graph-1.47.0-3.fc16.x86_64 requires libicui18n.so.46()(64bit) boost-regex-1.47.0-3.fc16.i686 requires libicuuc.so.46 boost-regex-1.47.0-3.fc16.i686 requires libicui18n.so.46 boost-regex-1.47.0-3.fc16.x86_64 requires libicuuc.so.46()(64bit) boost-regex-1.47.0-3.fc16.x86_64 requires libicui18n.so.46()(64bit) caribou-0.3.5-2.fc16.i686 requires libgee.so.2 caribou-0.3.5-2.fc16.x86_64 requires libgee.so.2()(64bit) 1:cheese-3.0.2-2.fc16.x86_64 requires libgee.so.2()(64bit) 1:cheese-libs-3.0.2-2.fc16.i686 requires libgee.so.2 1:cheese-libs-3.0.2-2.fc16.x86_64 requires libgee.so.2()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) claws-mail-plugins-geolocation-3.7.9-9.fc17.x86_64 requires libchamplain-0.10.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper dwdiff-1.9-2.fc16.x86_64 requires libicuuc.so.46()(64bit) dwdiff-1.9-2.fc16.x86_64 requires libicui18n.so.46()(64bit) dwdiff-1.9-2.fc16.x86_64 requires libicudata.so.46()(64bit) ease-0.4-7.fc17.i686 requires libgee.so.2 ease-0.4-7.fc17.x86_64 requires libgee.so.2()(64bit) ease-devel-0.4-7.fc17.i686 requires pkgconfig(gee-1.0)
Re: Kudos to Tom Spot Callaway
On Fri, Sep 9, 2011 at 2:16 AM, Christoph Frieben christoph.frie...@googlemail.com wrote: 2011/9/8 Jóhann B. Guðmundsson: On behalf of the systemd convertion team Just wanted to say thanks to Tom Spot Callaway he's been on fire today packaging submitted unit files and shipping them. Your work did not go unoticed! I do agree in particular with respect to his labour to provide cromium packages to the Fedora community. However, there is always some margin to improve: would it be possible to actually sign the chromium builds somehow? ~C What would be more productive (in the long term at least) is figuring out what the blockers are to getting Chromium into Fedora itself and getting those fixed, rather than as an external repo. That way packages would be signed as a part of the normal update process. I've never looked at the source or the packages myself so I can't say anything more - the packages do work fantastically though and I appreciate all the work Tom has done on them! -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kudos to Tom Spot Callaway
On Fri, Sep 9, 2011 at 2:47 PM, Jeffrey Ollie j...@ocjtech.us wrote: On Fri, Sep 9, 2011 at 2:16 AM, Christoph Frieben christoph.frie...@googlemail.com wrote: 2011/9/8 Jóhann B. Guðmundsson: On behalf of the systemd convertion team Just wanted to say thanks to Tom Spot Callaway he's been on fire today packaging submitted unit files and shipping them. Your work did not go unoticed! I do agree in particular with respect to his labour to provide cromium packages to the Fedora community. However, there is always some margin to improve: would it be possible to actually sign the chromium builds somehow? ~C What would be more productive (in the long term at least) is figuring out what the blockers are to getting Chromium into Fedora itself and getting those fixed, rather than as an external repo. That way packages would be signed as a part of the normal update process. If anyone could have worked it out its spot, he's blogged about the problems with it before. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cherokee-1.2.x for EL5 [WAS]: Re: howto build for EL5 on F15 in mock?
Hi, 2011/9/7 Pavel Lisy pavel.l...@gmail.com: Michał Piotrowski píše v Út 06. 09. 2011 v 20:27 +0200: 2011/9/6 Itamar Reis Peixoto ita...@ispbrasil.com.br: 2011/9/6 Michał Piotrowski mkkp...@gmail.com: Hi, I'm trying to build cherokee-1.2.1 for EL5 on my F15 system and I'm getting an error DEBUG util.py:250: cherokee ## DEBUG util.py:250: error: unpacking of archive failed on file /builddir/build/SOURCES/01-drop-privileges.patch;4e664eb5: cpio: MD5 sum mismatch AFAICS I can build this package for F15. I will be grateful for any hint. Hello there is another problem with cherokee and EL5. Cherokee wants to use openssl 1.0 but there is only 0.9.8e version on RHEL5 I've tried create it with openssl built staticly, you can try it. http://ftp-hk.tmapy.cz/tmapy-twist/centos/5/testing/SRPMS/cherokee-1.2.98-1.el5.src.rpm But I don't know if it is working, you can try it on my web https://ftp-hk.tmapy.cz/ it seams it returns nothing when html page is big. I don't know how to debug it. Can you help me? I have not looked at the problem yet. I'll be working on this next week - I need working SSL. Pavel -- Best regards, Michal http://eventhorizon.pl/ download the sources. fedpkg clone cherokee cd cherokee fedpkg local I cloned this tree git://pkgs.fedoraproject.org/cherokee.git with git, I guess that fedpkg clone cherokee does the same. Thanks! -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Warning todays F-16 updates-testing breaks gnome3, both glibc and glib2 are bad!
Hi, This took me some time to figure out, so I hope this mail will save others some grieve. After installing the glib2 update from todays updates-testing: glib2-2.29.90-1.fc16.x86_64 The following happens: [hans@shalem gspca]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 (0x7d3c7000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) /usr/bin/ldd: line 118: 5142 Segmentation fault (core dumped) LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= $@ Nasty! Downgrading glibc yields: [hans@shalem watchdog]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 = (0x7fff2f9ff000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) undefined symbol: g_unix_signal_add_watch_full (/usr/libexec/e-addressbook-factory) Downgrading also glib2 returns the system to working order, maybe only downgrading glib2 is enough, but the seg fault in ldd -r does not look good, so I've downgraded glibc too. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Warning todays F-16 updates-testing breaks gnome3, both glibc and glib2 are bad!
Hi, On 09/09/2011 06:31 PM, Hans de Goede wrote: Hi, This took me some time to figure out, so I hope this mail will save others some grieve. After installing the glib2 update from todays updates-testing: glib2-2.29.90-1.fc16.x86_64 The following happens: [hans@shalem gspca]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 (0x7d3c7000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) /usr/bin/ldd: line 118: 5142 Segmentation fault (core dumped) LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= $@ Nasty! Downgrading glibc yields: [hans@shalem watchdog]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 = (0x7fff2f9ff000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) undefined symbol: g_unix_signal_add_watch_full (/usr/libexec/e-addressbook-factory) Downgrading also glib2 returns the system to working order, maybe only downgrading glib2 is enough, but the seg fault in ldd -r does not look good, so I've downgraded glibc too. Replying to myself: As an alternative to downgrading glib2, one can also get a new evolution-data-server from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=262721 Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gnome-python2-gtkhtml2 and gnome-python2-gtkmozembed removed
Hello, In order to make gnome-python2-extras build in F16+ and to clean up its broken deps, I had to kill two of its subpackages. - gnome-python2-gtkhtml2: needs gtkhtml2 to build, which is already retired in F16+. - gnome-python2-gtkmozembed: needs xulrunner's gtkmozembed support which is disabled in F16+. This will flag up the following packages in the Branched / rawhide broken dep reports (they were broken before, just now showing up): $ repoquery -q --whatrequires gnome-python2-gtkhtml2 gnochm-0:0.9.11-6.fc15.noarch gscribble-0:0.1.2-1.fc16.noarch pida-0:0.5.1-13.fc15.x86_64 solfege-0:3.20.1-1.fc16.x86_64 $ repoquery -q --whatrequires gnome-python2-gtkmozembed awn-extras-applets-0:0.4.2-0.1.bzr1523.fc16.x86_64 awn-extras-applets-0:0.4.2-0.4.bzr1537.fc16.x86_64 pytrainer-0:1.7.2-2.fc15.noarch -- Thanks, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-python2-gtkhtml2 and gnome-python2-gtkmozembed removed
Le ven. 09 sept. 2011 18:40:34 CEST, Kalev Lember a écrit : Hello, In order to make gnome-python2-extras build in F16+ and to clean up its broken deps, I had to kill two of its subpackages. - gnome-python2-gtkhtml2: needs gtkhtml2 to build, which is already retired in F16+. - gnome-python2-gtkmozembed: needs xulrunner's gtkmozembed support which is disabled in F16+. This will flag up the following packages in the Branched / rawhide broken dep reports (they were broken before, just now showing up): $ repoquery -q --whatrequires gnome-python2-gtkhtml2 gnochm-0:0.9.11-6.fc15.noarch gscribble-0:0.1.2-1.fc16.noarch pida-0:0.5.1-13.fc15.x86_64 solfege-0:3.20.1-1.fc16.x86_64 Thank you Kalev for the heads-up. I'm retiring gnochm since there's no reason to keep it around anymore, upstream vanished for a long time. As for gnochm users, i recommend either using xchm or chmsee, kchmviewer-qt (non-kde variant) is also a good alternative. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in
Jens Petersen (peter...@redhat.com) said: yum-langpacks has been working pretty well now for a while in Fedora, but all langpacks are still listed conditionally in comps' language support groups in addition to the langpacks meta-section. So for F17 I'd like to remove them all from comps, this will simplify comps a lot and if we can also remove the resulting empty language support groups it will also reduce the comps translation burden in addition to comps maintenance. Now that I think about it... removing the empty language group will remove anaconda/yum's ability to install that language via kickstart/selection. So we would need to add some of the things you mention later to maintain some sort of feature parity. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: [FESCo] #667: Request to fix CRITPATH update process
I've grown entirely too fed up with the CRITPATH approval process. Here's my Fedora FESCo TRAC ticket requesting that the issue be solved and providing a suggested solution. If you agree, you might want to put your +1 in the ticket. If you disagree because you think you have a better solution, please feel free to update the ticket with your own proposal. But it's well past time that this debacle get fixed. Original Message Subject: [FESCo] #667: Request to fix CRITPATH update process Date: Fri, 09 Sep 2011 17:22:54 - From: FESCo t...@fedorahosted.org Reply-To: nob...@fedoraproject.org CC: fe...@lists.fedoraproject.org, tcall...@redhat.com, l...@jcomserv.net,tos...@fedoraproject.org #667: Request to fix CRITPATH update process -+-- Reporter: dledford | Owner: Type: task | Status: new Priority: blocker | Keywords: -+-- = Proposal topic = I have objected, many times, to the CRITPATH update process on the devel mailing list. This has, obviously, done nothing. I'm now filing this ticket as my last resort to get the issue fixed. = Overview = I object to the CRITPATH process on the basis that it makes it impossible for the maintainer of a package to actually have the power to fix users' problems in a timely manner yet holds the package maintainer accountable for fixing users' problems. It is unethical to make a person accountable for something over which they don't actually have the power to control. I would cite my current f16 mdadm update as an example. It originally had mdadm-3.2.2-8.fc16 as the package in testing with one bug, which was verified to resolve the problem (732818). Before the update was approved, I modified the update with mdadm-3.2.2-9 due to another bug, which has since been verified (and which is a non-boot issue for some people, 729205). All total, the update has now lingered for 43 days. Yesterday, I was assigned bug 736530. In that bug, Adam Williamson made this comment: note that this is a Beta blocker bug through 731177's dependence on it, so please prioritize - thanks! I think it's very appropriate here to point out that when my update that fixes known bugs that prevent proper bootup have lingered for 43 days, to have someone tell me essentially this is important, get on it! is a huge slap in the face. My response to this treatment is a resounding FU. FU and the horse you rode in on. = Problem space = Maintainers need sufficient power to solve users' problems. = Solution Overview = I propose that the CRITPATH update acceptance criteria be modified as such: Any CRITPATH update shall be approved immediately when any one of the three following conditions are met: 1) All bugs listed on the update have been transitioned from ON_QA to VERIFIED indicating that the CRITPATH update solves the issues it is intended to solve. If the update creates new issues after release, then there will be a new CRITPATH update with new bugs to solve those issues. 2) The update receives a total of +3 karma with at least one proven tester +1 karma. 3) The update reaches an age of two weeks and nag mails are now being sent. = Active Ingredients = What groups/systems/things are involved and/or affected by the proposal? Unknown, I don't know the internals of the CRITPATH implementation. = Owners = Who owns this proposal? Whoever created the god awful process we have in place now ought to be responsible for cleaning up their own damn mess. -- Ticket URL: https://fedorahosted.org/fesco/ticket/667 FESCo http://fedoraproject.org/wiki/Development/SteeringCommittee Fedora Engineering Steering Commitee signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Warning todays F-16 updates-testing breaks gnome3, both glibc and glib2 are bad!
On Fri, 2011-09-09 at 18:36 +0200, Hans de Goede wrote: As an alternative to downgrading glib2, one can also get a new evolution-data-server from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=262721 A few more packages are affected (PackageKit, upower,...), but they are all in the big update as of this morning. Thanks to Luke for fixing bodhi ! Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [antlr3] fix build on other arches
On Fri, Sep 9, 2011 at 11:30 AM, Dan Horák shar...@fedoraproject.org wrote:
commit ee88cf13670b752fc9fa94f39b1b2e2fe97849c3
Author: Dan Horák d...@danny.cz
Date: Fri Sep 9 19:30:19 2011 +0200
fix build on other arches
antlr3.spec | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
---
diff --git a/antlr3.spec b/antlr3.spec
index 48daab3..9e86cca 100644
--- a/antlr3.spec
+++ b/antlr3.spec
@@ -9,7 +9,7 @@
Summary: ANother Tool for Language Recognition
Name: antlr3
Version: %{antlr_version}
-Release: 14%{?dist}
+Release: 15%{?dist}
URL: http://www.antlr.org/
Source0:
http://www.antlr.org/download/antlr-%{antlr_version}.tar.gz
Source1:
http://www.antlr.org/download/C/libantlr3c-%{antlr_version}.tar.gz
@@ -203,11 +203,11 @@ popd
# Build the C runtime
pushd libantlr3c-%{antlr_version}
-%ifarch x86_64 ppc64
-%configure --disable-abiflags --enable-debuginfo --enable-64bit
-%endif
-%ifarch %{ix86} ppc
-%configure --disable-abiflags --enable-debuginfo
+%configure --disable-abiflags --enable-debuginfo \
+%ifarch x86_64 ppc64 s390x sparc64
+ --enable-64bit
+%else
+ %{nil}
%endif
[snip]
FWIW, in the couple of packages I maintain where configure isn't smart
enough to figure out 32- vs. 64-bitness on its own (e.g., csdp), I've
done this to be (hopefully) future-architecture-proof:
if [ %{__isa_bits} = 64 ]; then
magic_command_to_enable_64_bit_build
fi
It might be nice to encapsulate that in an RPM macro so that the above
could read something like this:
%configure --disable-abiflags --enable-debuginfo \
%ifarch64
--enable-64bit
%else
%{nil}
%endif
Regards,
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in
On Fri, Sep 9, 2011 at 9:50 AM, Ankitkumar Rameshchandra Patel an...@redhat.com wrote: Related note. How about we also change the way we manage translations for packages? This gives more control over translations to translators also translators become independent from package maintainers and can reduce burden from package maintainers taking care of translations! Shouldn't we have translations packaged independently from RPM packages? This is indeed possible. We did this in MeeGo and worked quite well. Here's the workflow we already implemented with MeeGo: 1. Developer has neither POT or PO files in git. No need to. 2. Developer builds his package. His Makefile produces the POT on-the-fly and includes it in the RPM. 3. Developer pushes his SRPM on build system. His SRPM contains one POT file and no PO files. 4. Transifex Middleware App monitors the build system for updates on packages. It detects a new version of the Anaconda SRPM. It downloads it, extracts the POT file from inside and pushes it to Transifex. 5. Transifex imports the file and notifies all translators if there are new strings available. 6. Translators provide translations either offline or online. 7. Localization packager uses Transifex client to pull all translations for eg. F17 and push a update on the language packs. LPacks are splitted eg. as fedora-langpack-ui-pt_BR etc. 8. User sees an update on yum and installs it. Advantages: - Developer is isolated from the need to host translations -- less clutter in his repo and changelog. - Developer does not need to remember to update his POT and pull translations, often forgotten (eg. the pull fresh translations after deadline). - L10n packager and language teams can push updates to their language any time they want. - CD/DVD can include only a couple of lang packs, so smaller size. Upon selection of the language, yum (or even the installer) can download the lang pack right away. - Process works well with release cycles, since there is a string freeze period. Possible drawbacks: - During Updates cycles (after a release is shipped): Between the time the developer pushes his package and the time the lang packs are updated, the user may see a couple of English strings on his UI. This happens also when the developer hosts his PO files, unless he decides to have small string-freezes every time (don't know anyone who does this). - Need to take extra care to avoid having a new langpack shipped to a user every day, since for some countries this might cause issues). Hope this helps. -d -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yum S3 plugin
(to both cloud@ and devel@) I was interested in a yum plugin to support S3, and discovered [1]this forum post, where Seth and James basically gave their thumbs up. The author (Robert Mela, even though he's not the original author either) made it work and there was some feedback provided, which I incorporated, along with a bunch of small improvements in my [2]github branch. Robert says in the forum post that he'll be happy if someone shepherds this into completion and I'm more than happy to try. Right now the plugin works, is a bit more aligned with the yum plugin architecture I think (I'd really like it to be true :) and also allows you to set the S3 credentials on a global, per-repo or using environment variables. There are 2 things I want to complete/need help with: - Package it as an RPM: I have a half-finished spec for this and I should have no problems finishing as long as I can deal with the item below: - Fix an annoying bug where the plugin creates an empty yum cachedir in the current directory. This is because the way the plugin works, it creates a copy of the original repo with a different grabber based on boto/urllib2 and then copies the rest of the attributes. However when the [3]new repo is created, basecachedir is empty. Can any of you fine people spot a way around that? it's been bugging me for a good week now. thoughts? comments? suggestions? let me know :) Cheers ~kad PS if you're asking yourselves: Why would you need this plugin if you can create websites off an S3 bucket? the answer is: using S3 offers more granularity to share, instead of just opening up the contents of the bucket to the entire world. [1] http://www.bluequartz.us/phpBB2/viewtopic.php?p=568109sid=d3462de3a07fc65561c69f5b940ac6df [2] https://github.com/thekad/yum-s3-plugin/tree/v1.1.x [3] https://github.com/thekad/yum-s3-plugin/blob/v1.1.x/s3.py#L228 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Virtualization Test Day for F16 and Xen
Hi, Virtualization Test day is expected to be on September 15th this year ( https://fedorahosted.org/fedora-qa/ticket/232). We are willing to help test http://fedoraproject.org/wiki/Features/XenPvopsDom0 but find too little information about test methods ( https://fedorahosted.org/fedora-qa/ticket/219). It takes time for us to setup test environment, and would be good to have some info in advance. Regards, Myroslav Opyr -- . Myroslav Opyr ▪ CTO ▪Quintagroup ▪ http://quintagroup.com ˙ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kudos to Tom Spot Callaway
On Fri, Sep 9, 2011 at 14:47, Jeffrey Ollie j...@ocjtech.us wrote: On Fri, Sep 9, 2011 at 2:16 AM, Christoph Frieben christoph.frie...@googlemail.com wrote: 2011/9/8 Jóhann B. Guðmundsson: On behalf of the systemd convertion team Just wanted to say thanks to Tom Spot Callaway he's been on fire today packaging submitted unit files and shipping them. Your work did not go unoticed! I do agree in particular with respect to his labour to provide cromium packages to the Fedora community. However, there is always some margin to improve: would it be possible to actually sign the chromium builds somehow? ~C What would be more productive (in the long term at least) is figuring out what the blockers are to getting Chromium into Fedora itself and getting those fixed, rather than as an external repo. That way packages would be signed as a part of the normal update process. I've never looked at the source or the packages myself so I can't say anything more - the packages do work fantastically though and I appreciate all the work Tom has done on them! This is an old blog post but having seen upstream i am sure it still very much applies: http://spot.livejournal.com/312320.html -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
Al Dunsmuir wrote: I agree, provided you mean not necessarily by each package's maintainer. In some cases, folks working on the common goal do need the assistance of the package maintainer. Alternatively, the package maintainer may be able to make the required changes in a timely manner on their own. Of course, diligent package maintainers should be able to do the changes. We just should not wait forever for the lazy, too busy or simply recalcitrant ones. Package maintainers must not be allowed to emulate King Canute and attempt to hold back the tide of change. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
BackupPC-3.2.1-1.fc14.x86_64 broken? [todays's Fedora 14 update]
Hi, Today's yum update on Fedora 14 resulted in about 10 seconds long 100% CPU load on one of the cores and an error in scriptlet: Running Transaction Updating : farsight2-0.0.22-1.fc14.x86_64 1/26 Updating : libcap-2.22-1.fc14.x86_64 2/26 Updating : 1:cups-libs-1.4.8-2.fc14.x86_64 Updating : 1:cups-1.4.8-2.fc14.x86_64 Updating : farsight2-python-0.0.22-1.fc14.x86_64 Updating : BackupPC-3.2.1-4.fc14.x86_64 Updating : libvpx-0.9.7.1-1.fc14.x86_64 Updating : system-config-firewall-base-1.2.27-2.fc14.noarch Updating : system-config-firewall-tui-1.2.27-2.fc14.noarch Updating : system-config-firewall-1.2.27-2.fc14.noarch Updating : libcap-devel-2.22-1.fc14.x86_64 Updating : rubygems-1.3.7-3.fc14.noarch Updating : 1:cups-libs-1.4.8-2.fc14.i686 Cleanup: 1:cups-1.4.6-1.fc14.x86_64 Cleanup: farsight2-python-0.0.21-2.fc14.x86_64 Cleanup: farsight2-0.0.21-2.fc14.x86_64 Cleanup: 1:cups-libs-1.4.6-1.fc14 Cleanup: BackupPC-3.2.1-1.fc14.x86_64 Non-fatal POSTUN scriptlet failure in rpm package BackupPC Cleanup: libvpx-0.9.6-1.fc14.x86_64 /var/tmp/rpm-tmp.99zFPZ: line 15: syntax error near unexpected token `fi' /var/tmp/rpm-tmp.99zFPZ: line 15: `fi' warning: %postun(BackupPC-3.2.1-1.fc14.x86_64) scriptlet failed, exit status 2 Cleanup: system-config-firewall-1.2.27-1.fc14.noarch Cleanup: system-config-firewall-tui-1.2.27-1.fc14.noarch Cleanup: libcap-devel-2.17-1.fc13.x86_64 Cleanup: libcap-2.17-1.fc13.x86_64 Cleanup: system-config-firewall-base-1.2.27-1.fc14.noarch Cleanup: rubygems-1.3.7-2.fc14.noarch Cleanup: 1:cups-libs-1.4.6-1.fc14 Cheers, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 731907] package in EPEL has bogus version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=731907 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Spreadsheet-ParseExcel ||-0.5900-1.el6 Resolution||ERRATA Last Closed||2011-09-09 03:53:31 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 731907] package in EPEL has bogus version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=731907 Bug 731907 depends on bug 732484, which changed state. Bug 732484 Summary: Review Request: perl-Digest-Perl-MD5 - Perl implementation of Ron Rivest's MD5 Algorithm https://bugzilla.redhat.com/show_bug.cgi?id=732484 What|Old Value |New Value Resolution||NEXTRELEASE Status|MODIFIED|CLOSED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 712694] CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712694 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||ERRATA Last Closed||2011-09-09 04:27:57 Bug 712694 depends on bug 712699, which changed state. Bug 712699 Summary: CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=712699 What|Old Value |New Value Status|NEW |MODIFIED Status|MODIFIED|ON_QA Resolution||ERRATA Status|ON_QA |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Plack-Test-ExternalServer
perl-Plack-Test-ExternalServer has broken dependencies in the F-16 tree: On x86_64: perl-Plack-Test-ExternalServer-0.01-1.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Plack-Test-ExternalServer-0.01-1.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-HTML-FormatText-WithLinks-AndTables
perl-HTML-FormatText-WithLinks-AndTables has broken dependencies in the F-16 tree: On x86_64: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Plack-Middleware-ReverseProxy
perl-Plack-Middleware-ReverseProxy has broken dependencies in the F-16 tree: On x86_64: perl-Plack-Middleware-ReverseProxy-0.10-1.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Plack-Middleware-ReverseProxy-0.10-1.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MooseX-Types-LoadableClass
perl-MooseX-Types-LoadableClass has broken dependencies in the F-16 tree: On x86_64: perl-MooseX-Types-LoadableClass-0.006-1.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-MooseX-Types-LoadableClass-0.006-1.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 736604] CVE-2011-2766 perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=736604 --- Comment #6 from Till Maas opensou...@till.name 2011-09-09 11:40:15 EDT --- Is fcgi-perl from EPEL5 affected by this bug as well? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734253] HTML::Template 2.10 versioning problem
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=734253 --- Comment #10 from Fedora Update System upda...@fedoraproject.org 2011-09-09 13:02:11 EDT --- perl-HTML-Template-2.10-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 736604] CVE-2011-2766 perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=736604 --- Comment #7 from Jan Lieskovsky jlies...@redhat.com 2011-09-09 13:00:11 EDT --- (In reply to comment #6) Is fcgi-perl from EPEL5 affected by this bug as well? No, fcgi in EPEL-5 contains CPAN v0.67 version of the FCGI module (thus is not yet affected by this). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 735062] perl-Date-Manip-6.25 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=735062 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2011-09-09 12:59:27 EDT --- perl-Date-Manip-6.25-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734420] perl-DateTime-TimeZone-1.36 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=734420 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2011-09-09 13:03:05 EDT --- perl-DateTime-TimeZone-1.36-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734420] perl-DateTime-TimeZone-1.36 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=734420 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-DateTime-0.70-2.fc15 |perl-DateTime-TimeZone-1.36 ||-1.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 735062] perl-Date-Manip-6.25 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=735062 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Date-Manip-6.25-1.fc17 |perl-Date-Manip-6.25-1.fc16 Resolution||ERRATA Last Closed||2011-09-09 12:59:32 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734253] HTML::Template 2.10 versioning problem
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=734253 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|2.10-3 |perl-HTML-Template-2.10-3.f ||c16 Resolution||ERRATA Last Closed||2011-09-09 13:02:16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712886 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Gtk2-1.224-2.fc15 |perl-Gtk2-1.224-2.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=712886 --- Comment #11 from Fedora Update System upda...@fedoraproject.org 2011-09-09 13:13:47 EDT --- perl-Gtk2-1.224-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: Bug 590826 - Reloading database from ldif causes changelog to emit data no longer matches errors
https://bugzilla.redhat.com/show_bug.cgi?id=590826 https://bugzilla.redhat.com/attachment.cgi?id=522361action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: Bug 736712 - Modifying ruv entry deadlocks server
https://bugzilla.redhat.com/show_bug.cgi?id=736712 https://bugzilla.redhat.com/attachment.cgi?id=522382action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review 2: Bug 590826 - Reloading database from ldif causes changelog to emit data no longer matches errors
https://bugzilla.redhat.com/show_bug.cgi?id=590826 https://bugzilla.redhat.com/attachment.cgi?id=522385action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
