[Test-Announce] 2012-10-08 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-10-08 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again tomorrow. An important day again, as we should check freeze-ability for F18 Beta once more: in particular, whether anaconda 18.13 implements all the partitioning requirements, and whether the new upgrade tool shows any signs of appearing. We also have quite a few blockers to look at. This weekend is Canadian Thanksgiving, so I'm not scheduled to be at work tomorrow. I'm hoping someone else will be able to run the meeting. If no-one wants to and I'm awake, though, I'll do it, but please, someone just go ahead and take it =) This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20121008 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 18 Beta status / mini blocker review 3. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request: remove gd.tuwien.ac.at from mirror-lists
On Wed, Oct 03, 2012 at 10:23:48AM -0400, Zdenek Pavlas wrote: On Wed Sep 26 08:02:05, Reindl Harald wrote: yes, and that is why statistics of mirrors are meaningsless because of this fact my idea to give us a config-option dear yum, if the selected mirror provides lower than 500 KB/sek try another one because my line can 12 MB/sec FWIW, we've increased the low speed limit in urlgrabber from 1 to 1000 B/sec. This should fix the most pathological cases. When speed falls below this limit for 30s, download is aborted as if it timed out, and next mirror is used. Each timeout also halves the mirror's estimated speed so it will very likely be avoided next time. https://admin.fedoraproject.org/updates/FEDORA-2012-14928/python-urlgrabber-3.9.1-21.fc18 Cool, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
tim.laurid...@gmail.com píše v Ne 07. 10. 2012 v 18:51 +0200: On Fri, Oct 5, 2012 at 5:19 PM, Jiri Eischmann eischm...@redhat.com wrote: Hi, the possibility of Software Center in Fedora has already been discussed several times, last time a few month ago. I read an article about a successful Google Summer of Code project [1] whose goal was to make Software Center a distribution independent program using PackageKit. Matthias even made an Ubuntu-independent infrastructure for AppStream (additional data about packages/apps). I wonder if there are still any efforts to get it to Fedora and what it would require from our infrastructure. If I understand it correctly, there are currently three options: 1) Software Center based on PackageKit by Matthias 2) Light Software Center - a new app based on PackageKit from the beginning 3) Apper already supports AppStream [2] I'm asking because I hear from many (not only) beginners that they would appreciate something like Ubuntu Software Center in Fedora. I guess it's one of the main reasons why many users rather go for Ubuntu than Fedora. Jiri [1] http://blog.tenstral.net/2012/08/gsoc-appstream-final-report.html [2] http://blog.tenstral.net/2012/08/appstream-for-apper.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel The ultimate software center is a web application, like Google playstore. All the rating and commenting and other info, need to be centrally maintained and it is not a good idea to try to distribute this kind of metadata. There shall just be a local installer to install the packages triggered by the web app. Another thing is what the users of Fedora and most other linux'es is not my old mother and most of these users, don't care about a big fancy software shop. I strongly disagree. Believe me, as a community manager in Red Hat I communicate with community members and normal users on daily basis. And the question When is Fedora going to have something like Software Center is one of the most frequent ones. And I also disagree it's about our mums and dads. We went to a local university last week to introduce Fedora to new computer science students. Those are users we're highly interested in. But for most of them, it's the first contact with Linux and questions and opinions like Where can I search only for app or Looking for apps among packages is not very convenient were very frequent. So nobody is going to do this great amount of work it takes to make a great webstore, Ubuntu need it for the same ways as Apple, they want to earn some money.) As someone already wrote, this is not about money, this is about user experience. Software Center only with free software would be a big improvement over what we have now. It is an illusion that if we just have a fancy webstore, every body will start using Fedora IMHO. Nobody simplifies it like this. Software Center is just one of pieces in the puzzle. It will be nice if more people uses Fedora, but it not the main target, the greatness of Fedora is not measured but how many user it have, compared to other Linuxes or other os'es. Yeah, the number of users might not be the main goal for Fedora, but without users, we won't achieve our actual goals. Less users leads in long term to less contributors, for example. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
Reindl Harald píše v Ne 07. 10. 2012 v 20:02 +0200: Am 07.10.2012 19:55, schrieb drago01: Maybe maybe not. The point is that a fancy software shop would result into this old mother type of user consider to use fedora. A user ultimately don't care about packages but about applications. Other distritors are moving in this direction while we fall behind. We should lead here like we do in other areas. why do we need to lead everywehre for every price? It will be nice if more people uses Fedora, but it not the main target, the greatness of Fedora is not measured but how many user it have, compared to other Linuxes or other os'es. Well without users (and growth) it will become irrelevant and thus it will become harder to achieve anything else. nobody says without users but do we really need every noob as user? Why does some of us imply it's about noobs? I know about many experienced Fedora users and contributors who would appreciate it, too. And why are noobs something unwanted? As I said above, most new computer science students at our local technical university are Linux noobs who would appreciate something like this. They have potential to be good contributors in a few years if Fedora hooks them up now. Unfortunately, our competition is more successful at this and it will have an impact on our contributor base in long term. why have we different operating systems and distributions if all satisfies the same user-base for every price? there is also a need for a clean and straight forwarded linux without compromises only to fetch users better satisfied with OSX or windows How would Software Center hold you from enjoying clean and straight forwarded Linux? It's just an app. Anyone who'd like to would be able to use YUM, YUMEX, Add/Remove, Apper,... Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Confusing tracker bug naming
On 10/06/2012 08:42 PM, Christoph Wickert wrote: Questions, feedback, thoughts or rants anybody? This is something you should be asking on the -test list where the QA community resides JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Sun, Oct 07, 2012 at 09:32:33PM +0300, Nikos Roussos wrote: I still haven't understand what it takes to get this started. Besides of course from having some people dedicating some time on that. Convincing infrastructure team is the first step? Does this need to get through FESCO first? Writing up a specific plan is the first step. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 863785] perl-Dancer-1.3110 is available
https://bugzilla.redhat.com/show_bug.cgi?id=863785 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|mmasl...@redhat.com |psab...@redhat.com -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F-18 Branched report: 20121008 changes
Compose started at Mon Oct 8 09:15:23 UTC 2012 Broken deps for x86_64 -- [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [dhcp-forwarder] dhcp-forwarder-upstart-0.10-1801.fc18.noarch requires /sbin/initctl [dogtag-pki] dogtag-pki-10.0.0-0.8.a1.fc18.noarch requires pki-util-javadoc = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc18.noarch requires pki-java-tools-javadoc = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc18.noarch requires pki-common-javadoc = 0:10.0.0 [dragonegg] dragonegg-3.1-7.fc18.x86_64 requires gcc = 0:4.7.1-5.fc18 [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [fontik] fontik-0.6.1-3.20120305git5dbbc513.fc18.x86_64 requires libgee-0.8.so.1()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit) [gwibber] 1:gwibber-3.4.2-3.fc18.i686 requires libgee-0.8.so.0 1:gwibber-3.4.2-3.fc18.x86_64 requires libgee-0.8.so.0()(64bit) [ip-sentinel] ip-sentinel-upstart-0.12-1303.fc18.noarch requires /sbin/initctl [kismon] kismon-0.6-2.fc18.noarch requires pyclutter [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [maniadrive] raydium-1.2-47.fc18.x86_64 requires libode.so.1()(64bit) [mapserver] mapserver-perl-6.0.1-5.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [milter-greylist] milter-greylist-upstart-4.2.7-1701.fc18.noarch requires /sbin/initctl [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [openvrml] libopenvrml-0.18.9-3.fc18.i686 requires libboost_thread-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_system-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.i686 requires libboost_filesystem-mt.so.1.48.0 libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) libopenvrml-0.18.9-3.fc18.x86_64 requires
rawhide report: 20121008 changes
Compose started at Mon Oct 8 08:15:10 UTC 2012 Broken deps for x86_64 -- [PyKDE] PyKDE-3.16.6-10.fc18.x86_64 requires sip-api(8) = 0:8.1 [PyQt] PyQt-3.18.1-12.fc18.x86_64 requires sip-api(8) = 0:8.1 [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [dogtag-pki] dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-util-javadoc = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-java-tools-javadoc = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-common-javadoc = 0:10.0.0 [dragonegg] dragonegg-3.1-11.fc19.x86_64 requires gcc = 0:4.7.2-2.fc19 [dustmite] dustmite-1-5.20120304gitcde46e0.fc17.x86_64 requires libphobos-ldc.so.59()(64bit) [dvipdfm] dvipdfm-0.13.2d-44.fc18.x86_64 requires libkpathsea.so.4()(64bit) [dvipdfmx] dvipdfmx-0-0.35.20090708cvs.fc18.x86_64 requires libkpathsea.so.4()(64bit) [dvipng] dvipng-1.14-4.fc18.x86_64 requires libkpathsea.so.4()(64bit) [dvisvgm] dvisvgm-1.0.12-1.fc19.x86_64 requires libkpathsea.so.4()(64bit) [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [fontik] fontik-0.6.1-3.20120305git5dbbc513.fc19.x86_64 requires libgee-0.8.so.1()(64bit) [func] func-0.28-1.fc17.noarch requires smolt [gcc-python-plugin] gcc-python2-debug-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python2-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python3-debug-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python3-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 [gcstar] gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Table) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::HBox) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Frame) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::EventBox) [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit) [gnome-shell-theme-selene] gnome-shell-theme-selene-3.4.0-5.fc19.noarch requires gnome-shell-extensions-user-theme [gnuplot] gnuplot-latex-4.6.0-2.fc18.noarch requires texlive-texmf-xetex [gtkd] gtkd-2.0.0-28.20120603gitcb35d25.fc18.i686 requires libphobos-ldc.so.59 gtkd-2.0.0-28.20120603gitcb35d25.fc18.x86_64 requires libphobos-ldc.so.59()(64bit) [gwibber] 1:gwibber-3.4.2-3.fc18.i686 requires libgee-0.8.so.0 1:gwibber-3.4.2-3.fc18.x86_64 requires libgee-0.8.so.0()(64bit) [kamoso] kamoso-2.0.2-6.fc18.x86_64 requires libkipi.so.9()(64bit) [kphotoalbum] kphotoalbum-4.2-4.fc18.x86_64 requires libkipi.so.9()(64bit) [ktp-call-ui] ktp-call-ui-0.5.0-1.fc19.x86_64 requires libtelepathy-farstream.so.2()(64bit) [libsyncml] 1:libsyncml-0.4.6-4.fc17.i686 requires libsoup-2.2.so.8 1:libsyncml-0.4.6-4.fc17.x86_64 requires libsoup-2.2.so.8()(64bit) [llvm] clang-3.1-9.fc19.i686 requires libstdc++-devel = 0:4.7.1 clang-3.1-9.fc19.x86_64 requires libstdc++-devel = 0:4.7.1 [mapserver]
Re: Any progress in Software Center in Fedora effort?
Am 08.10.2012 10:49, schrieb Jiri Eischmann: Reindl Harald píše v Ne 07. 10. 2012 v 20:02 +0200: why have we different operating systems and distributions if all satisfies the same user-base for every price? there is also a need for a clean and straight forwarded linux without compromises only to fetch users better satisfied with OSX or windows How would Software Center hold you from enjoying clean and straight forwarded Linux? It's just an app. Anyone who'd like to would be able to use YUM, YUMEX, Add/Remove, Apper,... hopefully this will be true there are many environments with no need for packagekit/software center and if dependencies will still be careful to not pull many packages as cross-deps all are satisfied signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd requires HTTP server and serves QR codes
Am I the only one who raised his eyebrow when today's systemd update to systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs? -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On 10/08/2012 10:49 AM, Jiri Eischmann wrote: Reindl Harald píše v Ne 07. 10. 2012 v 20:02 +0200: Am 07.10.2012 19:55, schrieb drago01: Maybe maybe not. The point is that a fancy software shop would result into this old mother type of user consider to use fedora. A user ultimately don't care about packages but about applications. Other distritors are moving in this direction while we fall behind. We should lead here like we do in other areas. why do we need to lead everywehre for every price? It will be nice if more people uses Fedora, but it not the main target, the greatness of Fedora is not measured but how many user it have, compared to other Linuxes or other os'es. Well without users (and growth) it will become irrelevant and thus it will become harder to achieve anything else. nobody says without users but do we really need every noob as user? Why does some of us imply it's about noobs? Because hardly any of the non-noobs misses this Software Center and because non-noobs know that the term apps is an Apple/Google marketing hype? Anyone who'd like to would be able to use YUM, YUMEX, Add/Remove, Apper,... Pardon, I do not understand what's your problem is. If it's just a yet another frontend/GUI program, why not package it? If it requires some server side infrastructure you will have to talk to FESCO. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
From: Petr Pisar ppi...@redhat.com Am I the only one who raised his eyebrow when today's systemd update to systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs? I suspect it has to do with this feature: http://www.h-online.com/open/news/item/Systemd-to-secure-system-log-information-against-attacks-1671165.html -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, 2012-10-08 at 16:49 +0200, Ralf Corsepius wrote: On 10/08/2012 10:49 AM, Jiri Eischmann wrote: Reindl Harald píše v Ne 07. 10. 2012 v 20:02 +0200: Am 07.10.2012 19:55, schrieb drago01: Maybe maybe not. The point is that a fancy software shop would result into this old mother type of user consider to use fedora. A user ultimately don't care about packages but about applications. Other distritors are moving in this direction while we fall behind. We should lead here like we do in other areas. why do we need to lead everywehre for every price? It will be nice if more people uses Fedora, but it not the main target, the greatness of Fedora is not measured but how many user it have, compared to other Linuxes or other os'es. Well without users (and growth) it will become irrelevant and thus it will become harder to achieve anything else. nobody says without users but do we really need every noob as user? Why does some of us imply it's about noobs? Because hardly any of the non-noobs misses this Software Center and because non-noobs know that the term apps is an Apple/Google marketing hype? User experience is important for everyone. Not just noobs. And currently Fedora is certainly not first when it comes on Applications installation user experience. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 863991] perl-Coro-6.09 does not build on S390
https://bugzilla.redhat.com/show_bug.cgi?id=863991 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Coro-6.09-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Coro-6.09-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15627/perl-Coro-6.09-2.fc18 then log in and leave karma (feedback). -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd requires HTTP server and serves QR codes
On Mon, 08.10.12 14:50, Petr Pisar (ppi...@redhat.com) wrote: Am I the only one who raised his eyebrow when today's systemd update to systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs? The live-syncing logging logic that is available in 184 as a preview is based on JSON and HTTP (in order to build as much on existing standards as possible, and get best integration with other systems). In order to keep the footprint low we decided to use an existing embeddable minimal HTTP engine for that, rather than writing our own. Correspondingly the microhttpd library is only pulled in by the journal gateway daemon, which is responsible for the HTTP iface to the journal. We thought about splitting this off into an individual package (and it would be really easy to still do that), but as the code of libmicrohttpd is minimal, and it doesn't pull in any deps beyond what is already in the minimal installation set we didn't bother so far. Note that the code is not enabled unless people do systemctl enable systemd-journal-gatewayd.service. The QR code stuff is for showing a scannable QR code for the FSS sealing key. It's a gimmick. In order to minimize footprint we actually made sure that the qrencode pacakge got split up in order not to pull in any additional packages into the basic set. It too is a really minimal dep, pulling nothing else in that wasn't in the minimal installation set already. Here too, was the option to implement our own thing, our own QR encoding code or just use the existing solution whose code is quite OK, whose deps are minimal, and which is quite well tested already. With the qrencode package split-up we were quite happy with having a dep on it. Hopes this makes sense, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Mon, Oct 08, 2012 at 02:50:23PM +, Petr Pisar wrote: Am I the only one who raised his eyebrow when today's systemd update to systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs? In terms of _size_, there's not much concern, as these are both very small libraries. In terms of *policy*, it does seem like this may be headed towards the path of an eventual realization that putting all this functionality into one monolithic package has some drawbacks. I believe that both of these are for the journal (ie, logging). If the systemd-journal-gatewayd service is running, one can connect via http on localhost and get a file in /var/log/messages-like format or JSON. This is kind of nifty, but raises a few questions. Traditionally, messages data is world-readable, but for a few years we've been shipping it readable only by root. What policy do we want for this, and what's the mechanism for enforcing it? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, Oct 8, 2012 at 4:17 PM, Nikos Roussos comzer...@fedoraproject.orgwrote: ** On Mon, 2012-10-08 at 16:49 +0200, Ralf Corsepius wrote: On 10/08/2012 10:49 AM, Jiri Eischmann wrote: Reindl Harald píše v Ne 07. 10. 2012 v 20:02 +0200: Am 07.10.2012 19:55, schrieb drago01: Maybe maybe not. The point is that a fancy software shop would result into this old mother type of user consider to use fedora. A user ultimately don't care about packages but about applications. Other distritors are moving in this direction while we fall behind. We should lead here like we do in other areas. why do we need to lead everywehre for every price? It will be nice if more people uses Fedora, but it not the main target, the greatness of Fedora is not measured but how many user it have, compared to other Linuxes or other os'es. Well without users (and growth) it will become irrelevant and thus it will become harder to achieve anything else. nobody says without users but do we really need every noob as user? Why does some of us imply it's about noobs? Because hardly any of the non-noobs misses this Software Center and because non-noobs know that the term apps is an Apple/Google marketing hype? User experience is important for everyone. Not just noobs. And currently Fedora is certainly not first when it comes on Applications installation user experience. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Advantages: - Do not depend on one or more managers to install something. - More easy admin packages for end-users - In desktops or window managers is more practical to use a software center on another environment managers and many bookstores such as Openbox, wmii, Fluxbox NOTE: openSUSE has got YaST (good!) withouth remove to Ark. Is no excuse to not create it if you follow the upstream projects like GNOME or KDE. Disadvantages - Much time and effort - Search people interested in doing it -- Álvaro Castillo http://fedoraproject.org/wiki/User:Netsys Linux user #547784 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Mon, Oct 08, 2012 at 11:49:47AM -0400, Matthew Miller wrote: In terms of *policy*, it does seem like this may be headed towards the path of an eventual realization that putting all this functionality into one monolithic package has some drawbacks. (A concern Lennart addresses in his message parallel to this one. As long as it remains easy to split up if that later becomes important, I'm not too concerned.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Mon, 08.10.12 11:49, Matthew Miller (mat...@fedoraproject.org) wrote: On Mon, Oct 08, 2012 at 02:50:23PM +, Petr Pisar wrote: Am I the only one who raised his eyebrow when today's systemd update to systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs? In terms of _size_, there's not much concern, as these are both very small libraries. In terms of *policy*, it does seem like this may be headed towards the path of an eventual realization that putting all this functionality into one monolithic package has some drawbacks. Well, sure it has drawbacks. But it also has benefits. Right now I believe the benefits outweigh the drawbacks, and splitting this off one day is easy. Hence I'd like to leave it as it is right now in F18. I believe that both of these are for the journal (ie, logging). If the systemd-journal-gatewayd service is running, one can connect via http on localhost and get a file in /var/log/messages-like format or JSON. Correct. Note that this is not accessible at all, by default, and mostly a preview for now. Later on we will add http digest auth and proper TLS support (including client certs) if people want to control access. (thankfully, libmicrohttpd already implements auth+tls, so this is easy for us to provide). This is kind of nifty, but raises a few questions. Traditionally, messages data is world-readable, but for a few years we've been shipping it readable only by root. What policy do we want for this, and what's the mechanism for enforcing it? Well, the idea is certainly here to provide read access to all messages, if this is enabled. The default will always be to grant no access at all via HTTP. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Mon, Oct 8, 2012 at 5:31 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 08.10.12 14:50, Petr Pisar (ppi...@redhat.com) wrote: Am I the only one who raised his eyebrow when today's systemd update to systemd-194-1.fc18 pulled in libmicrohttpd and qrencode-libs? The live-syncing logging logic that is available in 184 as a preview is based on JSON and HTTP (in order to build as much on existing standards as possible, and get best integration with other systems). In order to keep the footprint low we decided to use an existing embeddable minimal HTTP engine for that, rather than writing our own. Correspondingly the microhttpd library is only pulled in by the journal gateway daemon, which is responsible for the HTTP iface to the journal. We thought about splitting this off into an individual package (and it would be really easy to still do that), but as the code of libmicrohttpd is minimal, and it doesn't pull in any deps beyond what is already in the minimal installation set we didn't bother so far. We support a minimal installation target (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this really doesn't seem like something that should be included, for the same reason we don't ship a disabled-by-default ident or httpd in the minimal installation. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Guidelines Change] Change to the Packaging Guidelines
A few minor changes to the Fedora Packaging Guidelines have been made: --- The Ruby Packaging guidelines were updated to reflect the fact that rubygem packages must have a Requires: rubygems, because that package (rubygems) owns the RubyGems? directory structure. https://fedoraproject.org/wiki/Packaging:Ruby#RubyGems --- The systemd Scriptlets for Fedora 18+ have had their corresponding scriptlet Requires adjusted from systemd-units to systemd, since systemd-units is provided by the systemd package in Fedora 18+. There is still a separation in previous releases of Fedora (16/17), so packagers can choose to continue using the old Requires (systemd-units) if they are targeting multiple versions of Fedora with a single spec file. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29 --- This guideline change was approved by the Fedora Packaging Committee (FPC). Many thanks to Vit Ondruch, Lennart Poettering, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~tom ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Mon, Oct 08, 2012 at 07:37:42PM +0200, Miloslav Trmač wrote: We support a minimal installation target (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this really doesn't seem like something that should be included, for the same reason we don't ship a disabled-by-default ident or httpd in the minimal installation. I'm for a minimal installation. Let's be clear: what's the reason? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Mon, Oct 8, 2012 at 7:59 PM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Oct 08, 2012 at 07:37:42PM +0200, Miloslav Trmač wrote: We support a minimal installation target (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this really doesn't seem like something that should be included, for the same reason we don't ship a disabled-by-default ident or httpd in the minimal installation. I'm for a minimal installation. Let's be clear: what's the reason? 1) Ability to review - it much easier to verify security/sanity of files that are not there at all than of files that are present but supposedly unused. 2) Risk of enabling the service by mistake (which, given that journal-gatewayd will happily serve private log data to the whole internet AFAICS, is has a pretty bad impact in this particular case). 3) Overhead/downtime associated with upgrades of unused components (which wouldn't apply for a systemd subpackage here, but would apply to libmicrohttpd). 4) Disk space Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-Load-XS] Created tag perl-Class-Load-XS-0.06-1.fc18
The lightweight tag 'perl-Class-Load-XS-0.06-1.fc18' was created pointing to: 917540e... Update to 0.06 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Class-Load-XS] Created tag perl-Class-Load-XS-0.06-1.fc19
The lightweight tag 'perl-Class-Load-XS-0.06-1.fc19' was created pointing to: 917540e... Update to 0.06 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd requires HTTP server and serves QR codes
On Mon, Oct 8, 2012 at 7:39 PM, Miloslav Trmač m...@volny.cz wrote: On Mon, Oct 8, 2012 at 7:59 PM, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Oct 08, 2012 at 07:37:42PM +0200, Miloslav Trmač wrote: We support a minimal installation target (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this really doesn't seem like something that should be included, for the same reason we don't ship a disabled-by-default ident or httpd in the minimal installation. I'm for a minimal installation. Let's be clear: what's the reason? 1) Ability to review - it much easier to verify security/sanity of files that are not there at all than of files that are present but supposedly unused. 2) Risk of enabling the service by mistake (which, given that journal-gatewayd will happily serve private log data to the whole internet AFAICS, is has a pretty bad impact in this particular case). 3) Overhead/downtime associated with upgrades of unused components (which wouldn't apply for a systemd subpackage here, but would apply to libmicrohttpd). 4) Disk space And if it's only listening on localhost by default there's not much point of it running on a server where there's no easy means of doing so. I would like to see it split into a sub package even if the subpackage is installed by default. I think for people like this there should be the ability to easily completely opt out (ie remove it) to completely remove any option of compromise if they wish to do so. There's a lot of platforms and auditors that wouldn't want this installed at all (whether it be Fedora or RHEL) due to security risks whether it be a valid opinion or not (ever had to deal with PCI-DSS auditors?). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
On 10/05/2012 04:43 PM, Troy Dawson wrote: Hello, I have updated mongodb from 2.0.7 to 2.2.0. It is currently going through the normal channels for rawhide and Fedora 18. 10gen has a very good track record for being backwards compatible. According to their documentation When upgrading a standalone mongod, 2.2 is a drop-in replacement. and MongoDB 2.0 data files are compatible with 2.2-series binaries without any special migration process. If upgrading replica sets and sharded cluster, you should follow the procedures from their release notes. http://docs.mongodb.org/manual/release-notes/2.2/#upgrading What are people's thoughts on bringing it into Fedora 16, Fedora 17, EPEL6 and EPEL5? Troy Dawson I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 and 5. I am going to build for those tomorrow and let things sit in testing for at least a week (2 weeks for EPEL). The only concern I have received thus far is whether packages will need to be rebuilt against the new mongodb 2.2. From everything I have looked at, the answer is no. The API's should be backward compatible. The libraries provided are the same name, there is no increase in number. $ rpm -qp --provides libmongodb-2.0.7-2.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.0.7-2.fc18 libmongodb(x86-64) = 2.0.7-2.fc18 $ rpm -qp --provides libmongodb-2.2.0-6.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.2.0-6.fc18 libmongodb(x86-64) = 2.2.0-6.fc18 Thank You Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On 5 October 2012 15:42, Richard Hughes hughsi...@gmail.com wrote: On 5 October 2012 16:19, Jiri Eischmann eischm...@redhat.com wrote: 1) Software Center based on PackageKit by Matthias 2) Light Software Center - a new app based on PackageKit from the beginning 3) Apper already supports AppStream [2] Basically, Fedora needs to ship Appstream metadata and then we can just include any one of the two existing projects. To that, we need someone who's got an interest in working with the infrastructure guys in Fedora. I tried, but failed. It is not just infrastructure, but I understand we are a major blocker. Getting past the legal blockers is possible but infrastructure wants a plan, a continuing budget and a bodies that are dedicated to the project. Fedora has a huge history of Hey this is a great idea! and getting a 30% solution put out with the idea that it will become a 80% solution if people just wish hard enough... instead the people who started it go off to new stuff that interests them and the people who come after either throw away what was done before or find that real life has other plans for them. And then infrastructure gets handed the reigns of the nearly dead website, phone service, etc. And when we say we can't support it.. we have to spend a year proving that we can't get anyone to step up while everyone says Geez infrastructure can't do anything right. Look we have a lot of great ideas that we all would love to have happen. However just because we have them doesn't mean we have the resources to make them happen. There needs to be web design, web application coding, processes for getting applications in and approved, servers and disk space for this. Those are the hardest part and it is a blocker because if no one is around to keep a service going and growing it quickly becomes run by cargo cult. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
Hi, 2012/10/8 Troy Dawson tdaw...@redhat.com: On 10/05/2012 04:43 PM, Troy Dawson wrote: Hello, I have updated mongodb from 2.0.7 to 2.2.0. It is currently going through the normal channels for rawhide and Fedora 18. 10gen has a very good track record for being backwards compatible. According to their documentation When upgrading a standalone mongod, 2.2 is a drop-in replacement. and MongoDB 2.0 data files are compatible with 2.2-series binaries without any special migration process. If upgrading replica sets and sharded cluster, you should follow the procedures from their release notes. http://docs.mongodb.org/manual/release-notes/2.2/#upgrading What are people's thoughts on bringing it into Fedora 16, Fedora 17, EPEL6 and EPEL5? Troy Dawson I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 and 5. I am going to build for those tomorrow and let things sit in testing for at least a week (2 weeks for EPEL). I'll test on Fedora 17 and I'll let you know if I will have problems. The only concern I have received thus far is whether packages will need to be rebuilt against the new mongodb 2.2. From everything I have looked at, the answer is no. The API's should be backward compatible. The libraries provided are the same name, there is no increase in number. $ rpm -qp --provides libmongodb-2.0.7-2.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.0.7-2.fc18 libmongodb(x86-64) = 2.0.7-2.fc18 $ rpm -qp --provides libmongodb-2.2.0-6.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.2.0-6.fc18 libmongodb(x86-64) = 2.2.0-6.fc18 Thank You Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ https://getactive.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers
On Wed, Oct 3, 2012 at 8:23 PM, Jon Ciesla limburg...@gmail.com wrote: swing-layout -- Natural layout for Swing panels I'll take this since is a dep of Omegat. FAS name: olea -- Ismael Olea http://olea.org/diario/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
Troy Dawson píše v Po 08. 10. 2012 v 14:48 -0500: On 10/05/2012 04:43 PM, Troy Dawson wrote: Hello, I have updated mongodb from 2.0.7 to 2.2.0. It is currently going through the normal channels for rawhide and Fedora 18. 10gen has a very good track record for being backwards compatible. According to their documentation When upgrading a standalone mongod, 2.2 is a drop-in replacement. and MongoDB 2.0 data files are compatible with 2.2-series binaries without any special migration process. If upgrading replica sets and sharded cluster, you should follow the procedures from their release notes. http://docs.mongodb.org/manual/release-notes/2.2/#upgrading What are people's thoughts on bringing it into Fedora 16, Fedora 17, EPEL6 and EPEL5? Troy Dawson I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 and 5. I am going to build for those tomorrow and let things sit in testing for at least a week (2 weeks for EPEL). The only concern I have received thus far is whether packages will need to be rebuilt against the new mongodb 2.2. From everything I have looked at, the answer is no. The API's should be backward compatible. The libraries provided are the same name, there is no increase in number. you can use the abi-compliance-checker tool to confirm that Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 863734] perl-Template-Toolkit package is missing dependency on perl(AppConfig).
https://bugzilla.redhat.com/show_bug.cgi?id=863734 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Template-Toolkit-2.24-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Template-Toolkit-2.24-1.fc17 -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Any progress in Software Center in Fedora effort?
On Mon, Oct 8, 2012 at 9:49 PM, Stephen John Smoogen smo...@gmail.com wrote: [...] There needs to be web design, web application coding, processes for getting applications in and approved, servers and disk space for this. Those are the hardest part and it is a blocker because if no one is around to keep a service going and growing it quickly becomes run by cargo cult. No one but Tim asked for a web based solution. We don't need an application submission process either, just present the applications we have in a more usable manner (i.e applications not packages). The code for a native application support is mostly there. People that want to maintain this code are also present. What is missing is generating the required metadata (which requires support from the infrastructure team). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, Oct 08, 2012 at 10:39:21PM +0200, drago01 wrote: No one but Tim asked for a web based solution. We don't need an application submission process either, just present the applications we have in a more usable manner (i.e applications not packages). The code for a native application support is mostly there. People that want to maintain this code are also present. What is missing is generating the required metadata (which requires support from the infrastructure team). Let me check my understanding for this metadata, we need to, at repository compose time: 1. look in each rpm for a desktop file 2. pull the desktop file out of the rpm 3. put that info into a data structure 4. write that out as xml Is there more? So, in addition to putting forth an overall plan -- which is still an important step! -- it looks like an obvious thing to do is work on adding this functionality to createrepo. Then it's just a matter of asking the release engineering team to turn it on, right? (And helping deal with any performance costs -- it's unfortunate that the file has to be pulled out of the RPM. If this is very successful, a future version of RPM could add metadata from the desktop file at build time.) Alternately, this could be done asynchronously, since the metadata doesn't care about specific package version and release, just the name, so if they get a little out of sync it's probably okay. So it _could_ be a separate tool. Here, there's no reason someone couldn't stand this up separately as a proof of concept. And, a yum plugin could be written that would search on and install these applications, just as yum currently handles groupinstall. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, 8 Oct 2012 22:39:21 +0200 drago01 drag...@gmail.com wrote: On Mon, Oct 8, 2012 at 9:49 PM, Stephen John Smoogen smo...@gmail.com wrote: [...] There needs to be web design, web application coding, processes for getting applications in and approved, servers and disk space for this. Those are the hardest part and it is a blocker because if no one is around to keep a service going and growing it quickly becomes run by cargo cult. No one but Tim asked for a web based solution. We don't need an application submission process either, just present the applications we have in a more usable manner (i.e applications not packages). The code for a native application support is mostly there. People that want to maintain this code are also present. What is missing is generating the required metadata (which requires support from the infrastructure team). I'd like to see a concrete plan for generating that metadata, and sign off from the folks who know our current metadata generation process. That would be: rel-eng folks, bodhi maintainers, yum and rpm developers. Once everyone has reached a consensus on the plan, we would need folks willing to work on/maintain the needed changes. Last time this came up, there was no good census on the metadata needed or how to generate it, IIRC. (Happy to be proven wrong) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
* Matthew Miller [08/10/2012 23:04] : Is there more? You'll need icons, licenses, ratings, reviews and a (much) more detailed description than the one in the .desktop file. Bonus points if you include screenshots as well. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, Oct 8, 2012 at 11:09 PM, Stephen John Smoogen smo...@gmail.com wrote: On 8 October 2012 14:39, drago01 drag...@gmail.com wrote: On Mon, Oct 8, 2012 at 9:49 PM, Stephen John Smoogen smo...@gmail.com wrote: [...] There needs to be web design, web application coding, processes for getting applications in and approved, servers and disk space for this. Those are the hardest part and it is a blocker because if no one is around to keep a service going and growing it quickly becomes run by cargo cult. No one but Tim asked for a web based solution. We don't need an application submission process either, just present the applications we have in a more usable manner (i.e applications not packages). The code for a native application support is mostly there. People that want to maintain this code are also present. What is missing is generating the required metadata (which requires support from the infrastructure team). Dude.. ... metadata has to be served from something. I did not claim otherwise. It has to be updated from somewhere.. it has to have some sort of way to get to the client. Yes that's what I was taling about (create it at compose time). It gets to the client the same way the packages get to the client (downloaded from the mirrors via HTTP or FTP). That is a web application. No it isn't. The software has to be stored somewhere to be gotten from.. and that requires disk space, front end servers, and other infrastructure. This is not about a webportal just some files on the mirrors in addition to the existing metadata. And applications which go into a store need some way to be sorted and viewed by people outside of the application.. tada another web application. No this will be done using a native frontend ... did you even read the mail you are replying to? And yes there will need to be a submission process because the first time we end up serving someone who put Oracle DB or someone elses software in it.. we in infrastructure will know about it and be told to get rid of it immediately plus deal with whatever other legal issues involved. Or when MP3 or other Fedora forbidden items show up, we in infrastructure will have to deal with the cleanup there too. You entirely missed the point. So I will try again one more time the applications == rpms currently in the repo. There is no submission process other then the usual package review which we always had. So please take some time to read other peoples mails before replying and base your answers on that, thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers UPDATED LIST
On Fri, Oct 5, 2012 at 1:32 PM, Jon Ciesla limburg...@gmail.com wrote: -- Forwarded message -- From: Przemek Klosowski przemek.klosow...@nist.gov Date: Fri, Oct 5, 2012 at 12:06 PM Subject: Re: Packages in need of new maintainers To: devel@lists.fedoraproject.org On 10/03/2012 02:23 PM, Jon Ciesla wrote: As a result of FESCO ticket 952*, Lubomir Rintel's 200+ packages are in need of new maintainers. Under normal circumstances we'd simply orphan them all, but given the large number we want to handle this in a more orderly fashion. Please reply to the list with any requests for ownership changes, and I'll complete them on a first-come, first-served basis Could you do an updated list of packages that are still looking for owners? I'll take these java packages: derby -- Relational database implemented entirely in java ezmorph -- Object transformation library for Java jcommon -- JFree Java utility classes jfreechart -- Java chart library joda-time -- Java date and time API json-lib -- JSON library for Java rhino -- JavaScript for Java tagsoup -- A SAX-compliant HTML parser written in Java testng -- Java-based testing framework xom -- XML Pull Parser xpp3 -- XML Pull Parser -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Questions about the new comps
Christoph Wickert (christoph.wick...@gmail.com) said:
In order to reduce the size of the F18 Xfce spin, I wanted to edit comps
- but decided to not do so until I fully understand what is going on. I
seem to have missed a lot since since last our discussion at Blacksburg,
so have a lot of questions.
Here we go:
1. How can a package maintainer define a default, but not mandatory
package? Example: The Xfce SIG decided to no longer install
xfce4-icon-theme by default. It just takes space and we don't
use it. Nevertheless we want to enable users to install it
easily. How would we do that? Define an extra group with only
xfce4-icon-theme and make it an option of the Xfce environment?
That's the simplest way, yes. Under what circumstances would you expect
that a user would want to install it? If it's something where they would
only ever install it if they already know what the package name is, having
it categorized via a group seems like overkill.
2. Even if I cannot do it in anacoda any longer, how would I do it
in PackageKit? How can I make something show up in a group there
without making it mandatory?
3. How do the new groups translate into PackageKit groups? Will all
options be listed in the side pane of gpk-applications? Will
they dynamically change? Will all packages of a group be
selected?
Tackling these together:
This is sort of a two-part question - what is the available data, and what
do the tools do with it?
= The data =
Right now, nearly all 'building block' groups (part of environments, or
add-ons to those environments) are marked with:
uservisiblefalse/uservisible
to prevent them showing up in the installer UI where they shouldn't. We
could add some code to change this, but this is how it's currently done.
We have the environment sections in comps that define the installation
choices, and the options to them.
We have the category section in comps as well, which is a little
less defined.
= The tools =
1. anaconda
anaconda uses the 'environment' sections to determine what to offer.
The left pane is populated with the list of environments. After selecting
one, the right pane is populated with:
- all add-ons for that environment
- any groups that both:
1. are marked uservisibletrue/uservisible
2. have default/mandatory packages
This is for compatibility for add-on/third-party repos - if you add on, say,
a Chromium repo that has a group there, it will show up as an option for
whatever you decide to install.
anaconda ignores optional packages, unless you pass --optional in a
kickstart file.
anaconda no longer uses the category section.
2. apper
apper organizes groups via the category section. It appears to show them
whether or not the group is marked as user-visible. You can individually
select packages in these groups, but do not appear to be able to (easily)
select the group to get its default offerings. apper does not specifically
denote a package's status (mandatory/default/optional) in the UI, AFAICT.
apper does not read environments.
3. yumex
yumex organizes groups via the category section. It also appears to show
them whether or not the group is marked as user-visible. You can
individually select packages in these groups, or select the group to get
its default offerings. yumex does not specifically denote a package's status
(mandatory/default/optional) in the UI, AFAICT.
yumex does not read environments.
yumex has a 'categories' option that appears to have nothing to do with
comps categories, as well.
4. gnome-packagekit
gpk-application offers groups via two mechanisms:
- An uncategorized list of groups ('package collections')
This shows all groups listed in the category sections, in a flat list
instead of a tree. While you can select a group in this interface to get
its default offerings, you can not individually select packages from them
(as far as I can easily tell.)
- A filtered list of groups
PackageKit has its own concept of featured groups that it lists as separate
items. This list is assembled from comps groups via a mapping in
PacakgeKit's yum backend. You can individuallly select packages in groups
offered in this manner, but you can not select a group to get its default
offerings.
I did not check synaptic - people using that, frankly, are beyond my
immediate concern, but I'll answer questions on the data if they have them.
...
So, taking this into account, I think the simplest fix that ensures a
semi-coherent interface in post-install package tools while we work towards
something better would be to edit the category definitions in the comps file
so that there are categories for each installation option that lists the
add-ons for that option.
This would have the benefit of giving easy access to the options presented
in the anaconda interface in a post-install environment without having to
modify the code in those tools, at the
Re: Questions about the new comps
Christoph Wickert (christoph.wick...@gmail.com) said: one more question: How can one install something that is neither an 'environment' nor a minimal install install? Say I want openbox as window manager, how would I do that? openbox is in the group 'window-managers', but that group is not shown in anaconda. I guess we need to creae a group for each and every window manager and then make these groups options of either 'window-managers' or 'basic-x-windows' (the latter is shown in anaconda). If you really want every window manager to be an installation option for network installs, yes, you'd create groups and make them options of the basic-x-windows environment. Go nuts - Jens has already done so for xmonad. Note that in this scenario you either add the appropriate ancillary bits (display manager, firstboot, any additional applets, what have you) either into your window-manager option, or in another group that users would have to select as well. It's not really the target audience of the anaconda installation at the moment - the idea is to provide a meaningful list of vetted and tested installation options. (It's why they mirror the spins + a couple of server options). Supporting an X by Y by Z matrix of window managers, display managers, and input methods/font groups/pick-your-poison doesn't fit into that. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, Oct 08, 2012 at 11:09:17PM +0200, Emmanuel Seyman wrote: Is there more? You'll need icons, licenses, ratings, reviews and a (much) more detailed description than the one in the .desktop file. Bonus points if you include screenshots as well. Oh; yes -- that's an Open Collaboration Server on the Freedesktop spec: http://www.freedesktop.org/wiki/Specifications/open-collaboration-services So there's that. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, Oct 08, 2012 at 03:09:38PM -0600, Stephen John Smoogen wrote: Dude.. metadata has to be served from something. It has to be updated from somewhere.. it has to have some sort of way to get to the client. That is a web application. The software has to be stored somewhere to Well, looks like in the plan, at least _some_ of it is repo metadata. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On 8 October 2012 15:09, Stephen John Smoogen smo...@gmail.com wrote: On 8 October 2012 14:39, drago01 drag...@gmail.com wrote: On Mon, Oct 8, 2012 at 9:49 PM, Stephen John Smoogen smo...@gmail.com wrote: [...] There needs to be web design, web application coding, processes for getting applications in and approved, servers and disk space for this. Those are the hardest part and it is a blocker because if no one is around to keep a service going and growing it quickly becomes run by cargo cult. No one but Tim asked for a web based solution. We don't need an application submission process either, just present the applications we have in a more usable manner (i.e applications not packages). The code for a native application support is mostly there. People that want to maintain this code are also present. What is missing is generating the required metadata (which requires support from the infrastructure team). Dude.. metadata has to be served from something. It has to be updated from somewhere.. it has to have some sort of way to get to the client. My unreserved apologies to drago and others. My tone was not constructive and very condescending. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Mon, 08.10.12 19:37, Miloslav Trmač (m...@volny.cz) wrote: The live-syncing logging logic that is available in 184 as a preview is based on JSON and HTTP (in order to build as much on existing standards as possible, and get best integration with other systems). In order to keep the footprint low we decided to use an existing embeddable minimal HTTP engine for that, rather than writing our own. Correspondingly the microhttpd library is only pulled in by the journal gateway daemon, which is responsible for the HTTP iface to the journal. We thought about splitting this off into an individual package (and it would be really easy to still do that), but as the code of libmicrohttpd is minimal, and it doesn't pull in any deps beyond what is already in the minimal installation set we didn't bother so far. We support a minimal installation target (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this really doesn't seem like something that should be included, for the same reason we don't ship a disabled-by-default ident or httpd in the minimal installation. Well, I am all for minimizing the minimal installation set, and can applaud attempts to continiusly make data avilable where we stand with this and which packages are the worst dependency and size hogs. However, afaics the feature you mentioned is kinda dead? is any current data available about how our minimal footprint got worse/better over time in both terms of packages and disk space, and which packages are to blame for it? If the libmicrohttpd dep really is problematic I am happy to split it off, but I'd really like some hard data first whether doing this would help more than a trivial bit to achieve a smaller minimal installation set. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers UPDATED LIST
Please add these two to the list: * meld (EPEL 5, EPEL 6) * opengl-games-utils (EPEL 6) Thanks. -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, Oct 08, 2012 at 11:18:33PM +0200, drago01 wrote: That is a web application. No it isn't. The software has to be stored somewhere to be gotten from.. and that requires disk space, front end servers, and other infrastructure. This is not about a webportal just some files on the mirrors in addition to the existing metadata. This is why we need a clear plan, because right now everyone is talking about a different imagined thing. I *think* you're just talking about getting the appdata.xml metadata from desktop files into the mirrors: http://distributions.freedesktop.org/wiki/AppStream/Implementation#Mirror (I see also that I missed the icons tar.gz that needs to go alongside that.) But the whole Freedesktop plan has a whole bunch of other parts. Is that what we're talking about implementing in general? http://distributions.freedesktop.org/wiki/AppStream/Implementation Is this the best architecture for Fedora? Does it provide the user experience we want? If so (or if not, but we want to do something else instead), what does the non-abstract version of that diagram look like for our implementation? Who will do what parts, where will they run, and who will keep those parts running? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
On Mon, 8 Oct 2012 18:16:28 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Mon, Oct 08, 2012 at 11:18:33PM +0200, drago01 wrote: That is a web application. No it isn't. The software has to be stored somewhere to be gotten from.. and that requires disk space, front end servers, and other infrastructure. This is not about a webportal just some files on the mirrors in addition to the existing metadata. This is why we need a clear plan, because right now everyone is talking about a different imagined thing. I *think* you're just talking about getting the appdata.xml metadata from desktop files into the mirrors: http://distributions.freedesktop.org/wiki/AppStream/Implementation#Mirror (I see also that I missed the icons tar.gz that needs to go alongside that.) The last time this came up, some folks wanted to put all the icons and app desktop file data into a package and ship it and install it by default. Others found this a bad idea and wanted to generate the data on the server side and serve it to folks. The folks wishing to push the package are stalled in legal (because shipping a package with all icons in it means that each icon is under the license of whatever package it came from, making the resulting rpm license... very silly). The folks who wanted to generate the data as far as I know didn't get to far toward doing so, AFAIK. So, yes, this would need a clear plan. ;) But the whole Freedesktop plan has a whole bunch of other parts. Is that what we're talking about implementing in general? http://distributions.freedesktop.org/wiki/AppStream/Implementation Is this the best architecture for Fedora? Does it provide the user experience we want? If so (or if not, but we want to do something else instead), what does the non-abstract version of that diagram look like for our implementation? Who will do what parts, where will they run, and who will keep those parts running? If we decide this is the way we want to go, any such work would need to use the Infrastructure Request for Resources process: http://fedoraproject.org/wiki/Request_For_Resources kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, Oct 9, 2012 at 12:14 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 08.10.12 19:37, Miloslav Trmač (m...@volny.cz) wrote: We support a minimal installation target (https://fedoraproject.org/wiki/Features/MinimalPlatform ), and this really doesn't seem like something that should be included, for the same reason we don't ship a disabled-by-default ident or httpd in the minimal installation. Well, I am all for minimizing the minimal installation set, and can applaud attempts to continiusly make data avilable where we stand with this and which packages are the worst dependency and size hogs. However, afaics the feature you mentioned is kinda dead? It's not dead: anaconda offers that option, and we aim to look at new problems at least once per release. Milan Brož has been recently examining the F18 status. Looking at bugzllla, Fedora QA uses it (#862238), and you have personally responded to a minimal install-related bug less then a month ago (#852828). is any current data available about how our minimal footprint got worse/better over time in both terms of packages and disk space, and which packages are to blame for it? If the libmicrohttpd dep really is problematic I am happy to split it off, but I'd really like some hard data first whether doing this would help more than a trivial bit to achieve a smaller minimal installation set. One more network-listening service, let alone an unauthenticated one, is way more than a trivial bit IMHO. The disk space aspect is by far the most negligible of the four reasons for a minimal installation I have mentioned earlier today. (The cost of a megabyte of storage is practically indistinguishable from zero, and even multiplied by the number of Fedora users it is not a number that would inspire much work.) If you are curious about specific data, I don't have it available; I'll ask around. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Feature Suggestion] UsrMove continued
Hello. Modern Fedora had 14 non-empty root directories: /boot /bin /dev /etc /home /lib /proc /root /run /sbin /sys /tmp /usr /var Original UsrMove had fixed just 3 of them. But the rest are still there. What do you think about fixing them all? Instead of all these directories we can have it as simple as: /os-- OS, kernel-space /usr -- user-space, shareable, possibly read-only, /var -- variable system data, read-write, non-shareable /home -- variable user data, read-write, shareable And nothing else. Changes in depth: /os: /os/boot /os/dev /os/proc /os/sys /usr: /usr/etc /usr/bin /usr/lib /usr/root /usr/sbin /var: /var/run /var/tmp /home remains unchanged Details === * /dev, /proc and /sys are used for talking to kernel, they go to /os. * /boot contains the kernel itself, so /os is also a good place for it. * /root was initially on a root partition because 'root' user should be able to login even when all other FS (including /usr) are not mounted. Since now it can't do anything without /usr anyway, /root dir don't have to be in /. * /etc contains data and configs for userspace programs, it's useless without them, and don't have to be separated. After all GNU autotools have never been aware of such split in the first place. * /tmp is not really needed any more. Single /var/tmp temporary directory is enough, it can be automatically cleaned by tmpwatch as usual (this also solves the problem of large files not fitting in small /tmp) * As long as initramfs is able to mount /usr it can certainly mount /var. There's no need for a separate /run in that case, it just pollutes root directory, so it can be moved back to /var, it's a variable data directory after all. User Experience === * fewer toplevel directories Benefits to Fedora == * Simpler and cleaner overall file system layout, with full compatibility. * Clear separation of kernel-space, user-space and files of regular users. * Improved compatibility with build systems such as GNU autotools who never have been aware of the /usr split in the first place * Minimize difference to other *nix systems, such as Android and Solaris, which already use similar approach * Isolate the vendor-supplied mostly read-only operating system resources from the rest, thus allow snapshotting of the OS, and easy lightweight container OS duplication This is not a new feature. It has same reasons and same benefits as original UsrMove. But there're more: * Dedicated root partition is not necessary any more * which gives unique ability for NFS-booted diskless stations: initramfs only mounts /home (rw, shared), /usr (ro, shared) and /var (rw, dedicated) directly to the initramfs layout. * In some distant future it may be possible to have multiple operating systems installed in subdirectories of a single partition. I.e. user would have /F21, /F22 and /F23 dirs, and initramfs just binds /usr, /var and /home to /F2*/subdirs. No more partitioning, resizing and moving disks around. If you're an Ubuntu user and want to try Fedora you just install it on top of the same partition. If you don't like it, you only need to remove the /Fedora dir. * Compat-symlinks would still remain there for a long time, but they can probably be hidden from non-root users (UID!=0) with some eyecandy kernel module. Alternatively (probably not, but still) they can be completely replaced with a special redirecting compat-kernel module. Obviously this won't go in F18. But it mostly works, you can test it: 0. Get Fedora17 LiveCD 1. Boot it with additional kernel params: selinux=0 systemd.log_level=debug systemd.log_target=console init=/bin/bash 2. When you get the shell: # mkdir /os /os/proc /os/sys /os/dev # mount --move /proc /os/proc; rm -rf /proc; ln -s os/proc / # mount --move /sys /os/sys; rm -rf /sys; ln -s os/sys / # mount --move /dev /os/dev; rm -rf /dev; ln -s os/dev / # mv /boot /os/; ln -s os/boot / # rm -f /var/run; mkdir /var/run # mount -n --move /run /var/run; rm -rf /run; ln -s var/run / # mv -f /root /etc /usr/; ln -s usr/root usr/etc / # mount --bind /var/tmp /tmp # exec /sbin/init and it should work as usual. PS: Actually only selinux=0 init=/bin/bash is needed in kernel params. The systemd.log... part is there just as a workaround. F17 Live can be booted without it. F18 works fine for me without it in QEMU, but freezes on real hardware. Not sure why, it happens with regular F18Alpha too. Some race condition systemd bug? -- Serge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Hi, On Mon, Oct 8, 2012 at 1:07 PM, Lennart Poettering mzerq...@0pointer.de wrote: Correct. Note that this is not accessible at all, by default, and mostly a preview for now. Later on we will add http digest auth and proper TLS support (including client certs) if people want to control access. (thankfully, libmicrohttpd already implements auth+tls, so this is easy for us to provide). I think negotiate-auth would be a really good feature here, since many enterprise deployments use kerberos based SSO in their intranets. --Ray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers UPDATED LIST
On Fri, Oct 5, 2012 at 10:32 AM, Jon Ciesla limburg...@gmail.com wrote: On 10/03/2012 02:23 PM, Jon Ciesla wrote: As a result of FESCO ticket 952*, Lubomir Rintel's 200+ packages are in need of new maintainers. Under normal circumstances we'd simply orphan them all, but given the large number we want to handle this in a more orderly fashion. Please reply to the list with any requests for ownership changes, and I'll complete them on a first-come, first-served basis Could you do an updated list of packages that are still looking for owners? Because I haven't entirely run kicking and screaming from attempting to package nodejs, I (FAS: patches) will take: http-parser -- HTTP request/response parser for C libeio -- Event-based fully asynchronous I/O library And the EPEL branches for: v8 -- JavaScript Engine if the Fedora V8 maintainers and uninterested in them. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
Miloslav Trmač (m...@volny.cz) said: is any current data available about how our minimal footprint got worse/better over time in both terms of packages and disk space, and which packages are to blame for it? If the libmicrohttpd dep really is problematic I am happy to split it off, but I'd really like some hard data first whether doing this would help more than a trivial bit to achieve a smaller minimal installation set. One more network-listening service, let alone an unauthenticated one, is way more than a trivial bit IMHO. Well, it *is* off by default. Checking the minimal install of the moment: Install 38 Packages (+160 Dependent packages) Total download size: 129 M Installed size: 505 M In that minimal install, the following disabled services exist: NetworkManager-wait-online.service autovt@.service console-getty.service console-shell.service debug-shell.service dnsmasq.service ip6tables.service iptables.service rdisc.service saslauthd.service wpa_supplicant.service systemd-journal-gatewayd.socket The follwing 'traditional' services are enabled: auditd.service sshd.service sm-client.service sendmail.service NetworkManager.service crond.service rsyslog.service Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam/el5] fix missing require
commit 4ed621f6881a007e1ac2cebb92e1d613d9f56a35
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Mon Oct 8 00:14:58 2012 -0600
fix missing require
dspam.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/dspam.spec b/dspam.spec
index 93ae57d..428a5ed 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:1%{?dist}
+Release:2%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -40,6 +40,7 @@ Requires: dspam-libs = %{version}-%{release}
Requires(post): chkconfig
Requires(preun):chkconfig
Requires(preun):initscripts
+Requires: perl(Mail::MboxParser)
%description
The DSPAM agent masquerades as the email server's local delivery agent
@@ -375,6 +376,9 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Sun Oct 7 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-2
+- require perl(Mail::MboxParser)
+
* Wed May 2 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-1
- new upstream release
--
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
[dspam/el6] fix missing require
commit c2dd3d1ca4c14f4117414b4f3f3f5d0cf177c6cb
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Mon Oct 8 00:13:34 2012 -0600
fix missing require
dspam.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/dspam.spec b/dspam.spec
index c1d345c..db60f70 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:1%{?dist}
+Release:2%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -40,6 +40,7 @@ Requires: dspam-libs = %{version}-%{release}
Requires(post): chkconfig
Requires(preun):chkconfig
Requires(preun):initscripts
+Requires: perl(Mail::MboxParser)
%description
The DSPAM agent masquerades as the email server's local delivery agent
@@ -375,6 +376,9 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Sun Oct 7 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-2
+- require perl(Mail::MboxParser)
+
* Wed May 2 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-1
- new upstream release
--
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
[dspam/f16] add exim patch, fix requires
commit 2c3ba6487512d928b1ee6a05bfc27a527c3d9f5e
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Mon Oct 8 00:08:22 2012 -0600
add exim patch, fix requires
.gitignore |1 +
dspam-3.10.2.exim.patch | 35 +++
dspam.spec | 12 +---
3 files changed, 45 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3916ccd..fa1c4e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ dspam-3.9.0.tar.gz
dspam-3.10.0.tar.gz
/dspam-3.10.1.tar.gz
/dspam-3.10.2.tar.gz
+/.project
diff --git a/dspam-3.10.2.exim.patch b/dspam-3.10.2.exim.patch
new file mode 100644
index 000..f3031c2
--- /dev/null
+++ b/dspam-3.10.2.exim.patch
@@ -0,0 +1,35 @@
+--- doc/exim.txt 2011-08-16 17:38:30.0 -0500
doc/exim.txt_NEW 2012-08-02 10:06:19.405528304 -0500
+@@ -40,11 +40,17 @@
+
+ command = /usr/local/bin/dspam --deliver=innocent --user
$local_part@$domain -- %u
+
+-Finally, you will need to configure and compile DSPAM. DSPAM will most likely
+-end up calling exim again for delivery, using the spam-scanned protocol to
+-identify scanned messages. The most common example is:
+-
+- ./configure --with-delivery-agent=/usr/sbin/exim -oMr spam-scanned
++Finally, you will need to configure and compile DSPAM. You can configure
++DSPAM with the appropriate LDA using --with-delivery-agent= at configure
++time or by specifying TrustedDeliveryAgent in dspam.conf. DSPAM will most
++likely end up calling exim again for delivery, using the spam-scanned
++protocol to identify scanned messages. The most common example is:
++
++ ./configure --with-delivery-agent=/usr/sbin/exim -oMr spam-scanned -oi
++
++Note: DSPAM expects the LDA to NOT provide the line with a single dot (.)
++processing to indicate the end of data that a MTA must provide to meet the
++SMTP RFC, hence the -oi option to exim above.
+
+ RUNNING WITHOUT PRIVILEGED EXIM USERS
+
+--- src/dspam.conf.in 2012-04-11 13:48:33.0 -0500
src/dspam.conf.in_NEW 2012-08-02 10:09:38.235559835 -0500
+@@ -43,7 +43,7 @@
+ # Other popular configurations:
+ #TrustedDeliveryAgent /usr/cyrus/bin/deliver# Cyrus
+ #TrustedDeliveryAgent /bin/maildrop # Maildrop
+-#TrustedDeliveryAgent /usr/local/sbin/exim -oMr spam-scanned # Exim
++#TrustedDeliveryAgent /usr/local/sbin/exim -oMr spam-scanned -oi # Exim
+ #
+ TrustedDeliveryAgent @delivery_agent@
diff --git a/dspam.spec b/dspam.spec
index 88c5335..723455c 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:1%{?dist}
+Release:2%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -35,10 +35,11 @@ BuildRequires: mysql-devel
BuildRequires: postgresql-devel
BuildRequires: sqlite-devel
BuildRequires: openldap-devel
-BuildRequires: systemd-units
+BuildRequires: systemd-units
Requires: dspam-libs = %{version}-%{release}
-Requires(post):systemd-sysv
+Requires(post): systemd-sysv
+Requires: perl(Mail::MboxParser)
%description
The DSPAM agent masquerades as the email server's local delivery agent
@@ -135,6 +136,7 @@ Web-based interface for DSPAM's powerful Anti-Spam engine.
%patch1 -p0
%patch2 -p0
%patch3 -p0
+%patch4 -p0
%build
@@ -375,6 +377,10 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Sun Oct 7 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-2
+- Add exim patch
+- Require perl(Mail::MboxParser) fixes bug #622502
+
* Wed May 2 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-1
- New upstream release
--
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
[dspam/f17] add exim patch, fix requires
commit 32a021d2b73e470ab65b4422822909e99a96186e
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Sun Oct 7 23:58:53 2012 -0600
add exim patch, fix requires
.gitignore |1 +
dspam-3.10.2.exim.patch | 35 +++
dspam.spec | 16
3 files changed, 48 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3916ccd..fa1c4e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ dspam-3.9.0.tar.gz
dspam-3.10.0.tar.gz
/dspam-3.10.1.tar.gz
/dspam-3.10.2.tar.gz
+/.project
diff --git a/dspam-3.10.2.exim.patch b/dspam-3.10.2.exim.patch
new file mode 100644
index 000..f3031c2
--- /dev/null
+++ b/dspam-3.10.2.exim.patch
@@ -0,0 +1,35 @@
+--- doc/exim.txt 2011-08-16 17:38:30.0 -0500
doc/exim.txt_NEW 2012-08-02 10:06:19.405528304 -0500
+@@ -40,11 +40,17 @@
+
+ command = /usr/local/bin/dspam --deliver=innocent --user
$local_part@$domain -- %u
+
+-Finally, you will need to configure and compile DSPAM. DSPAM will most likely
+-end up calling exim again for delivery, using the spam-scanned protocol to
+-identify scanned messages. The most common example is:
+-
+- ./configure --with-delivery-agent=/usr/sbin/exim -oMr spam-scanned
++Finally, you will need to configure and compile DSPAM. You can configure
++DSPAM with the appropriate LDA using --with-delivery-agent= at configure
++time or by specifying TrustedDeliveryAgent in dspam.conf. DSPAM will most
++likely end up calling exim again for delivery, using the spam-scanned
++protocol to identify scanned messages. The most common example is:
++
++ ./configure --with-delivery-agent=/usr/sbin/exim -oMr spam-scanned -oi
++
++Note: DSPAM expects the LDA to NOT provide the line with a single dot (.)
++processing to indicate the end of data that a MTA must provide to meet the
++SMTP RFC, hence the -oi option to exim above.
+
+ RUNNING WITHOUT PRIVILEGED EXIM USERS
+
+--- src/dspam.conf.in 2012-04-11 13:48:33.0 -0500
src/dspam.conf.in_NEW 2012-08-02 10:09:38.235559835 -0500
+@@ -43,7 +43,7 @@
+ # Other popular configurations:
+ #TrustedDeliveryAgent /usr/cyrus/bin/deliver# Cyrus
+ #TrustedDeliveryAgent /bin/maildrop # Maildrop
+-#TrustedDeliveryAgent /usr/local/sbin/exim -oMr spam-scanned # Exim
++#TrustedDeliveryAgent /usr/local/sbin/exim -oMr spam-scanned -oi # Exim
+ #
+ TrustedDeliveryAgent @delivery_agent@
diff --git a/dspam.spec b/dspam.spec
index f745697..6cace29 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:1%{?dist}
+Release:2%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -24,7 +24,9 @@ Source8:dspam-systemd
Source99: dspam-filter-requires.sh
Patch1: dspam-3.9.0-docs.patch
Patch2: dspam-3.9.0-dspamsock.patch
-Patch3:dspam-default-server-port.patch
+Patch3: dspam-default-server-port.patch
+Patch4: dspam-3.10.2.exim.patch
+
URL:http://www.nuclearelephant.com/
# kept to be able to build EPEL versions
Buildroot: %(mktemp -ud
%{_tmppath}/%{name}-%{version}-%{release}-XX)
@@ -35,10 +37,11 @@ BuildRequires: mysql-devel
BuildRequires: postgresql-devel
BuildRequires: sqlite-devel
BuildRequires: openldap-devel
-BuildRequires: systemd-units
+BuildRequires: systemd-units
Requires: dspam-libs = %{version}-%{release}
-Requires(post):systemd-sysv
+Requires(post): systemd-sysv
+Requires: perl(Mail::MboxParser)
%description
The DSPAM agent masquerades as the email server's local delivery agent
@@ -135,6 +138,7 @@ Web-based interface for DSPAM's powerful Anti-Spam engine.
%patch1 -p0
%patch2 -p0
%patch3 -p0
+%patch4 -p0
%build
@@ -376,6 +380,10 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Sun Oct 7 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-2
+- Add exim patch
+- Require perl(Mail::MboxParser) fixes bug #622502
+
* Wed May 2 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-1
- New upstream release
--
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
[dspam/f18] (3 commits) ...add exim patch and fix bug 622502
Summary of changes: dd99fa3... ignore eclipse project files d41e9df... Merge branch 'master' of ssh://g...@pkgs.fedoraproject.org/ be45028... add exim patch and fix bug 622502 -- 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
[dspam/f18: 1/3] ignore eclipse project files
commit dd99fa310620c957ff861aa173554e4a208ced31 Author: Nathanael D. Noblet nathan...@gnat.ca Date: Thu Aug 2 13:04:01 2012 -0600 ignore eclipse project files .gitignore |1 + 1 files changed, 1 insertions(+), 0 deletions(-) --- diff --git a/.gitignore b/.gitignore index 3916ccd..7e03bca 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ dspam-3.9.0.tar.gz dspam-3.10.0.tar.gz /dspam-3.10.1.tar.gz /dspam-3.10.2.tar.gz +.project -- 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
[dspam/f18: 2/3] Merge branch 'master' of ssh://g...@pkgs.fedoraproject.org/dspam.git
commit d41e9df204a8fea5082275cafcc691cc86426136 Merge: dd99fa3 4189c8b Author: Nathanael D. Noblet nathan...@gnat.ca Date: Sun Oct 7 23:26:35 2012 -0600 Merge branch 'master' of ssh://g...@pkgs.fedoraproject.org/dspam.git dspam.spec |5 - 1 files changed, 4 insertions(+), 1 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[dspam/f18: 3/3] add exim patch and fix bug 622502
commit be45028815d8b485ee71151d9677ff4a621af086
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Sun Oct 7 23:44:53 2012 -0600
add exim patch and fix bug 622502
dspam-3.10.2.exim.patch | 35 +++
dspam.spec | 11 +--
2 files changed, 44 insertions(+), 2 deletions(-)
---
diff --git a/dspam-3.10.2.exim.patch b/dspam-3.10.2.exim.patch
new file mode 100644
index 000..f3031c2
--- /dev/null
+++ b/dspam-3.10.2.exim.patch
@@ -0,0 +1,35 @@
+--- doc/exim.txt 2011-08-16 17:38:30.0 -0500
doc/exim.txt_NEW 2012-08-02 10:06:19.405528304 -0500
+@@ -40,11 +40,17 @@
+
+ command = /usr/local/bin/dspam --deliver=innocent --user
$local_part@$domain -- %u
+
+-Finally, you will need to configure and compile DSPAM. DSPAM will most likely
+-end up calling exim again for delivery, using the spam-scanned protocol to
+-identify scanned messages. The most common example is:
+-
+- ./configure --with-delivery-agent=/usr/sbin/exim -oMr spam-scanned
++Finally, you will need to configure and compile DSPAM. You can configure
++DSPAM with the appropriate LDA using --with-delivery-agent= at configure
++time or by specifying TrustedDeliveryAgent in dspam.conf. DSPAM will most
++likely end up calling exim again for delivery, using the spam-scanned
++protocol to identify scanned messages. The most common example is:
++
++ ./configure --with-delivery-agent=/usr/sbin/exim -oMr spam-scanned -oi
++
++Note: DSPAM expects the LDA to NOT provide the line with a single dot (.)
++processing to indicate the end of data that a MTA must provide to meet the
++SMTP RFC, hence the -oi option to exim above.
+
+ RUNNING WITHOUT PRIVILEGED EXIM USERS
+
+--- src/dspam.conf.in 2012-04-11 13:48:33.0 -0500
src/dspam.conf.in_NEW 2012-08-02 10:09:38.235559835 -0500
+@@ -43,7 +43,7 @@
+ # Other popular configurations:
+ #TrustedDeliveryAgent /usr/cyrus/bin/deliver# Cyrus
+ #TrustedDeliveryAgent /bin/maildrop # Maildrop
+-#TrustedDeliveryAgent /usr/local/sbin/exim -oMr spam-scanned # Exim
++#TrustedDeliveryAgent /usr/local/sbin/exim -oMr spam-scanned -oi # Exim
+ #
+ TrustedDeliveryAgent @delivery_agent@
diff --git a/dspam.spec b/dspam.spec
index e7103bf..c79f9e1 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:2%{?dist}
+Release:3%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -24,7 +24,8 @@ Source8:dspam-systemd
Source99: dspam-filter-requires.sh
Patch1: dspam-3.9.0-docs.patch
Patch2: dspam-3.9.0-dspamsock.patch
-Patch3:dspam-default-server-port.patch
+Patch3: dspam-default-server-port.patch
+Patch4: dspam-3.10.2.exim.patch
URL:http://www.nuclearelephant.com/
# kept to be able to build EPEL versions
Buildroot: %(mktemp -ud
%{_tmppath}/%{name}-%{version}-%{release}-XX)
@@ -39,6 +40,7 @@ BuildRequires:systemd-units
Requires: dspam-libs = %{version}-%{release}
Requires(post):systemd-sysv
+Requires: perl(Mail::MboxParser)
%description
The DSPAM agent masquerades as the email server's local delivery agent
@@ -135,6 +137,7 @@ Web-based interface for DSPAM's powerful Anti-Spam engine.
%patch1 -p0
%patch2 -p0
%patch3 -p0
+%patch4 -p0
%build
@@ -376,6 +379,10 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Sun Oct 7 2012 Nathanael Noblet nathan...@gnat.ca - 3.10.2-3
+- Add exim patch
+- Require perl(Mail::MboxParser) fixes bug #622502
+
* Wed Jul 18 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 3.10.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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
[dspam] (3 commits) ...add exim patch and fix bug 622502
Summary of changes: dd99fa3... ignore eclipse project files (*) d41e9df... Merge branch 'master' of ssh://g...@pkgs.fedoraproject.org/ (*) be45028... add exim patch and fix bug 622502 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[dspam/f16] add the patch to the spec
commit ab705f123d0311b0fe4527b66cabedcaf5694988
Author: Nathanael D. Noblet nathan...@gnat.ca
Date: Mon Oct 8 00:32:16 2012 -0600
add the patch to the spec
dspam.spec |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
---
diff --git a/dspam.spec b/dspam.spec
index 723455c..b2bf889 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -24,7 +24,9 @@ Source8:dspam-systemd
Source99: dspam-filter-requires.sh
Patch1: dspam-3.9.0-docs.patch
Patch2: dspam-3.9.0-dspamsock.patch
-Patch3:dspam-default-server-port.patch
+Patch3: dspam-default-server-port.patch
+Patch4: dspam-3.10.2.exim.patch
+
URL:http://www.nuclearelephant.com/
# kept to be able to build EPEL versions
Buildroot: %(mktemp -ud
%{_tmppath}/%{name}-%{version}-%{release}-XX)
--
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 863784] perl-Coro-6.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=863784 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Fixed In Version||perl-Coro-6.09-1.fc19 -- 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 758866] CVE-2011-4363 perl-Proc-ProcessTable: unsafe temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=758866 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added CC||jlies...@redhat.com External Bug ID||Debian BTS 650500 --- Comment #4 from Jan Lieskovsky jlies...@redhat.com --- Upstream ticket: https://rt.cpan.org/Public/Bug/Display.html?id=72862 Other references: http://www.securityfocus.com/bid/50868 http://www.osvdb.org/77428 http://secunia.com/advisories/47015 -- 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 863988] New: perl-Coro-6.09 bundles libecb
https://bugzilla.redhat.com/show_bug.cgi?id=863988 Bug ID: 863988 QA Contact: extras...@fedoraproject.org Severity: unspecified URL: http://software.schmorp.de/pkg/libecb Version: rawhide Priority: unspecified CC: boche...@fedoraproject.org, kwiz...@gmail.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Assignee: ppi...@redhat.com Summary: perl-Coro-6.09 bundles libecb Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: ppi...@redhat.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: ASSIGNED Component: perl-Coro Product: Fedora Coro-6.09 sources bundles ecb.h file from libecb project http://software.schmorp.de/pkg/libecb. -- 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 863991] New: perl-Coro-6.09 does not build on S390
https://bugzilla.redhat.com/show_bug.cgi?id=863991 Bug ID: 863991 QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: boche...@fedoraproject.org, kwiz...@gmail.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Assignee: ppi...@redhat.com Summary: perl-Coro-6.09 does not build on S390 Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: ppi...@redhat.com Type: Bug Documentation: --- Hardware: s390 Mount Type: --- Status: ASSIGNED Component: perl-Coro Product: Fedora Coro 6.09 fails to build on big endian machine because of typo in bundled Coro/ecb.h file: $ gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m31 -march=z9-109 -mtune=z10 -DVERSION=\6.09\ -DXS_VERSION=\6.09\ -fPIC -I/usr/lib/perl5/CORE -DHAVE_MMAP -DCORO_UCONTEXT -DCORO_STACKSIZE=16384 -DCORO_STACKGUARD=4 -DCORO_JIT=1 State.c In file included from State.xs:17:0: ecb.h: In function 'ecb_byteorder_helper': ecb.h:497:3: error: 'retrurn' undeclared (first use in this function) -- 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 863991] perl-Coro-6.09 does not build on S390
https://bugzilla.redhat.com/show_bug.cgi?id=863991 Petr Pisar ppi...@redhat.com changed: What|Removed |Added External Bug ID||CPAN 80056 -- 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
[perl-Coro] Fix building on big endian system
commit 7a02ec12a1ba623a662f5b624712bbe5e0a08cb2
Author: Petr Písař ppi...@redhat.com
Date: Mon Oct 8 13:39:00 2012 +0200
Fix building on big endian system
Coro-6.09-Fix-a-typo-in-ecb.h.patch | 27 +++
perl-Coro.spec |8 +++-
2 files changed, 34 insertions(+), 1 deletions(-)
---
diff --git a/Coro-6.09-Fix-a-typo-in-ecb.h.patch
b/Coro-6.09-Fix-a-typo-in-ecb.h.patch
new file mode 100644
index 000..ea6bcb2
--- /dev/null
+++ b/Coro-6.09-Fix-a-typo-in-ecb.h.patch
@@ -0,0 +1,27 @@
+From de7220dcac464425fc2667706100901d0fc7f444 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Mon, 8 Oct 2012 13:25:37 +0200
+Subject: [PATCH] Fix a typo in ecb.h
+
+A code for big endian system has a mistyped return word.
+https://rt.cpan.org/Public/Bug/Display.html?id=80056
+---
+ Coro/ecb.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Coro/ecb.h b/Coro/ecb.h
+index 1162bc6..5a88f60 100644
+--- a/Coro/ecb.h
b/Coro/ecb.h
+@@ -494,7 +494,7 @@ ecb_byteorder_helper (void)
+ #elif __BYTE_ORDER__ __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ return 0x44;
+ #elif __BYTE_ORDER__ __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+- retrurn 0x11;
++ return 0x11;
+ #else
+ union
+ {
+--
+1.7.11.7
+
diff --git a/perl-Coro.spec b/perl-Coro.spec
index e41f97a..9363870 100644
--- a/perl-Coro.spec
+++ b/perl-Coro.spec
@@ -1,12 +1,14 @@
Name: perl-Coro
Version:6.09
-Release:1%{?dist}
+Release:2%{?dist}
Summary:The only real threads in perl
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Coro/
Source0:
http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/Coro-%{version}.tar.gz
Patch0: %{name}-5.25-ucontext-default.patch
+# Bug #863991, CPAN RT #80056
+Patch1: Coro-6.09-Fix-a-typo-in-ecb.h.patch
BuildRequires: perl(AnyEvent) = 5
BuildRequires: perl(base)
BuildRequires: perl(Carp)
@@ -82,6 +84,7 @@ programming much safer and easier than using other thread
models.
%ifnarch %{ix86} x86_64 %{arm}
%patch0 -p1 -b .ucontext-default
%endif
+%patch1 -p1
for F in Coro/jit-*.pl; do
sed -i -e '/^#!/d' $F
@@ -127,6 +130,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Oct 08 2012 Petr Pisar ppi...@redhat.com - 6.09-2
+- Fix building on big endian system (bug #863991)
+
* Sun Oct 07 2012 Nicolas Chauvet kwiz...@gmail.com - 6.09-1
- Update to 4.09
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Coro/f18] Fix building on big endian system
Summary of changes: 7a02ec1... Fix building on big endian system (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 863991] perl-Coro-6.09 does not build on S390
https://bugzilla.redhat.com/show_bug.cgi?id=863991 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Coro-6.09-2.fc19 -- 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 863991] perl-Coro-6.09 does not build on S390
https://bugzilla.redhat.com/show_bug.cgi?id=863991 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Coro-6.09-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Coro-6.09-2.fc18 -- 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-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the F-18 tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so 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 863988] perl-Coro-6.09 bundles libecb
https://bugzilla.redhat.com/show_bug.cgi?id=863988 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Blocks||504493 ||(DuplicSysLibsTracker) -- 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 863785] perl-Dancer-1.3110 is available
https://bugzilla.redhat.com/show_bug.cgi?id=863785 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Dancer-1.3110-1.fc19 Resolution|--- |RAWHIDE Last Closed||2012-10-08 08:26:56 -- 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 863988] perl-Coro-6.09 bundles libecb
https://bugzilla.redhat.com/show_bug.cgi?id=863988 Petr Pisar ppi...@redhat.com changed: What|Removed |Added URL|http://software.schmorp.de/ |https://fedorahosted.org/fp |pkg/libecb |c/ticket/220 --- Comment #1 from Petr Pisar ppi...@redhat.com --- FPC request for bundling exception https://fedorahosted.org/fpc/ticket/220. -- 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-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the rawhide tree: On x86_64: perl-OpenOffice-UNO-0.07-3.fc17.x86_64 requires perl(:MODULE_COMPAT_5.14.2) On i386: perl-OpenOffice-UNO-0.07-3.fc17.i686 requires perl(:MODULE_COMPAT_5.14.2) perl-OpenOffice-UNO-0.07-3.fc17.i686 requires libsal_textenc.so 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 863988] perl-Coro-6.09 bundles libecb
https://bugzilla.redhat.com/show_bug.cgi?id=863988 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Depends On||864066 -- 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 864102] New: Bad precedence in library version check
https://bugzilla.redhat.com/show_bug.cgi?id=864102 Bug ID: 864102 QA Contact: extras...@fedoraproject.org Severity: unspecified Version: el6 Priority: unspecified CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com Assignee: psab...@redhat.com Summary: Bad precedence in library version check Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: li...@cmadams.net Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Net-SSH2 Product: Fedora EPEL Created attachment 623492 -- https://bugzilla.redhat.com/attachment.cgi?id=623492action=edit Fix operator precedence in auth agent check The perl module checks the libssh2 version to decide if agent authenticaion support should be used, but there is a bad operator precedence in the check (= has higher precedence than ||). While the bug is upstream, the situation (running newer Net::SSH2 with older libssh2) is pretty specific to RHEL 6. This bug makes -auth calls fail unless an explicit auth rank is set. The attached patch fixes the problem. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Wx-0.9914.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Wx: b2cb65b0a51c547cb07442f02a61be6b Wx-0.9914.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Wx/f18] 0.9914
commit 37bb5038662854b9627c6fc95694456c0073b8d9
Author: Tom Callaway s...@fedoraproject.org
Date: Mon Oct 8 13:14:57 2012 -0400
0.9914
perl-Wx.spec | 11 ++-
sources |2 +-
2 files changed, 11 insertions(+), 2 deletions(-)
---
diff --git a/perl-Wx.spec b/perl-Wx.spec
index 99b043f..f6845ab 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -9,7 +9,7 @@
# for i in `grep -r PACKAGE= * | cut -d -f 2 | sed 's|PACKAGE=|perl(|g'
| grep Wx:: | sort -n |uniq`; do printf Provides: $i)\\n; done
Name: perl-Wx
-Version:0.9911
+Version:0.9914
Release:1%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
@@ -184,9 +184,11 @@ Provides: perl(Wx::ListView)
Provides: perl(Wx::Locale)
Provides: perl(Wx::Log)
Provides: perl(Wx::LogChain)
+Provides: perl(Wx::LogFormatter)
Provides: perl(Wx::LogGui)
Provides: perl(Wx::LogNull)
Provides: perl(Wx::LogPassThrough)
+Provides: perl(Wx::LogRecordInfo)
Provides: perl(Wx::LogStderr)
Provides: perl(Wx::LogTextCtrl)
Provides: perl(Wx::LogWindow)
@@ -232,6 +234,7 @@ Provides: perl(Wx::PlFileSystemHandler)
Provides: perl(Wx::PlGridCellEditor)
Provides: perl(Wx::PlGridCellRenderer)
Provides: perl(Wx::PlLog)
+Provides: perl(Wx::PlLogFormatter)
Provides: perl(Wx::PlLogPassThrough)
Provides: perl(Wx::PlSizer)
Provides: perl(Wx::PlThreadEvent)
@@ -389,6 +392,12 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%{_mandir}/man3/*.3pm*
%changelog
+* Mon Oct 8 2012 Tom Callaway s...@fedoraproject.org - 0.9914-1
+- update to 0.9914
+
+* Mon Oct 1 2012 Tom Callaway s...@fedoraproject.org - 0.9913-1
+- update to 0.9913
+
* Fri Aug 24 2012 Tom Callaway s...@fedoraproject.org - 0.9911-1
- update to 0.9911
diff --git a/sources b/sources
index 409b6e5..da7fa5b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-528fe939dca2e50b050d78abf6866e3f Wx-0.9911.tar.gz
+b2cb65b0a51c547cb07442f02a61be6b Wx-0.9914.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Wx] 0.9914
commit 748b1f40095b53b365290e339d6ed77446f8d436
Author: Tom Callaway s...@fedoraproject.org
Date: Mon Oct 8 13:21:42 2012 -0400
0.9914
.gitignore |1 +
perl-Wx.spec |8 +++-
sources |2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f4e7dc4..272dfa6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Wx-0.92.tar.gz
/Wx-0.9907.tar.gz
/Wx-0.9911.tar.gz
/Wx-0.9913.tar.gz
+/Wx-0.9914.tar.gz
diff --git a/perl-Wx.spec b/perl-Wx.spec
index b9b2f0f..f6845ab 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -9,7 +9,7 @@
# for i in `grep -r PACKAGE= * | cut -d -f 2 | sed 's|PACKAGE=|perl(|g'
| grep Wx:: | sort -n |uniq`; do printf Provides: $i)\\n; done
Name: perl-Wx
-Version:0.9913
+Version:0.9914
Release:1%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
@@ -184,9 +184,11 @@ Provides: perl(Wx::ListView)
Provides: perl(Wx::Locale)
Provides: perl(Wx::Log)
Provides: perl(Wx::LogChain)
+Provides: perl(Wx::LogFormatter)
Provides: perl(Wx::LogGui)
Provides: perl(Wx::LogNull)
Provides: perl(Wx::LogPassThrough)
+Provides: perl(Wx::LogRecordInfo)
Provides: perl(Wx::LogStderr)
Provides: perl(Wx::LogTextCtrl)
Provides: perl(Wx::LogWindow)
@@ -232,6 +234,7 @@ Provides: perl(Wx::PlFileSystemHandler)
Provides: perl(Wx::PlGridCellEditor)
Provides: perl(Wx::PlGridCellRenderer)
Provides: perl(Wx::PlLog)
+Provides: perl(Wx::PlLogFormatter)
Provides: perl(Wx::PlLogPassThrough)
Provides: perl(Wx::PlSizer)
Provides: perl(Wx::PlThreadEvent)
@@ -389,6 +392,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%{_mandir}/man3/*.3pm*
%changelog
+* Mon Oct 8 2012 Tom Callaway s...@fedoraproject.org - 0.9914-1
+- update to 0.9914
+
* Mon Oct 1 2012 Tom Callaway s...@fedoraproject.org - 0.9913-1
- update to 0.9913
diff --git a/sources b/sources
index 46b45d6..da7fa5b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-eab115ad98737eb6a02305e1b9e79c48 Wx-0.9913.tar.gz
+b2cb65b0a51c547cb07442f02a61be6b Wx-0.9914.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Class-Load-XS-0.06.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Class-Load-XS: a3e73647f84eb8bd26847c3dda78f0d3 Class-Load-XS-0.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Class-Load-XS] Update to 0.06
commit 917540e2fcb44225998f3fb1795ba790e355b39e
Author: Paul Howarth p...@city-fan.org
Date: Mon Oct 8 19:10:31 2012 +0100
Update to 0.06
- New upstream release 0.06:
- Require Class::Load 0.20 in the code, not just the distro metadata
(CPAN RT#80002)
- Weird classes with either an ISA or VERSION constant would cause the XS
to
blow up badly (CPAN RT#79998)
- Fixed some broken logic that lead to a segfault from the
014-weird-constants.t test on some Perls (CPAN RT#80059)
- Bump perl(Class::Load) version requirement to 0.20
- Drop explicit requirement for perl(Class::Load), no longer needed
perl-Class-Load-XS.spec | 18 ++
sources |2 +-
2 files changed, 15 insertions(+), 5 deletions(-)
---
diff --git a/perl-Class-Load-XS.spec b/perl-Class-Load-XS.spec
index 6156daa..dbd3ac8 100644
--- a/perl-Class-Load-XS.spec
+++ b/perl-Class-Load-XS.spec
@@ -2,8 +2,8 @@
#TODO: BR: Test::Pod::LinkCheck when available
Name: perl-Class-Load-XS
-Version: 0.04
-Release: 3%{?dist}
+Version: 0.06
+Release: 1%{?dist}
Summary: XS implementation of parts of Class::Load
Group: Development/Libraries
License: Artistic 2.0
@@ -16,7 +16,7 @@ BuildRequires:perl(Module::Build)
# ===
# Module requirements
# ===
-BuildRequires: perl(Class::Load) = 0.15
+BuildRequires: perl(Class::Load) = 0.20
# ===
# Regular test suite requirements
# ===
@@ -38,7 +38,6 @@ BuildRequires:perl(Test::Pod)
# Runtime requirements
# ===
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(Class::Load) = 0.15
%{?perl_default_filter}
@@ -69,6 +68,17 @@ RELEASE_TESTING=1 ./Build test
%{_mandir}/man3/Class::Load::XS.3pm*
%changelog
+* Mon Oct 8 2012 Paul Howarth p...@city-fan.org - 0.06-1
+- Update to 0.06:
+ - Require Class::Load 0.20 in the code, not just the distro metadata
+(CPAN RT#80002)
+ - Weird classes with either an ISA or VERSION constant would cause the XS to
+blow up badly (CPAN RT#79998)
+ - Fixed some broken logic that lead to a segfault from the
+014-weird-constants.t test on some Perls (CPAN RT#80059)
+- Bump perl(Class::Load) version requirement to 0.20
+- Drop explicit requirement for perl(Class::Load), no longer needed
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.04-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index 2774d37..db49c4c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f805304cb330591651c443397c23e60a Class-Load-XS-0.04.tar.gz
+a3e73647f84eb8bd26847c3dda78f0d3 Class-Load-XS-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Class-Load-XS/f18] Update to 0.06
Summary of changes: 917540e... Update to 0.06 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Template-Toolkit/f17] 2.24, fix deps
commit 308c37dea4d997726b59b63636dca9db34ed4d19
Author: Tom Callaway s...@fedoraproject.org
Date: Mon Oct 8 16:25:51 2012 -0400
2.24, fix deps
perl-Template-Toolkit.spec | 54 ---
sources|4 +-
2 files changed, 47 insertions(+), 11 deletions(-)
---
diff --git a/perl-Template-Toolkit.spec b/perl-Template-Toolkit.spec
index 42a65b6..753be83 100644
--- a/perl-Template-Toolkit.spec
+++ b/perl-Template-Toolkit.spec
@@ -1,19 +1,43 @@
Name: perl-Template-Toolkit
-Version:2.22
-Release:11%{?dist}
+Version:2.24
+Release:1%{?dist}
Summary:Template processing system
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://www.template-toolkit.org/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AB/ABW/Template-Toolkit-%{version}.tar.gz
-Source1:http://tt2.org/download/TT_v222_html_docs.tar.gz
+Source1:http://tt2.org/download/TT_v224_html_docs.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRequires: perl(AppConfig)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(lib)
+# Run-time:
+BuildRequires: perl(base)
+BuildRequires: perl(CGI)
+BuildRequires: perl(constant)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Encode)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(File::Path)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Temp)
+# Prefer Image::Info over Image::Size
+BuildRequires: perl(Image::Info)
+BuildRequires: perl(Pod::POM)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Text::Wrap)
+# Tests:
+BuildRequires: perl(Carp)
BuildRequires: perl(Test::More)
-BuildRequires: perl(AppConfig), perl(Text::Autoformat), perl(GD::Graph3d),
perl(GD::Graph)
-BuildRequires: perl(GD::Text), perl(Image::Info), perl(Image::Size),
perl(Pod::POM)
-BuildRequires: perl(XML::DOM), perl(XML::RSS), perl(XML::XPath)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(AppConfig)
+Requires: perl(Encode)
+Requires: perl(File::Temp)
+# Prefer Image::Info over Image::Size
+Requires: perl(Image::Info)
Provides: perl-Template-Toolkit-examples = %{version}-%{release}
Obsoletes: perl-Template-Toolkit-examples 2.22-1
@@ -54,8 +78,8 @@ make install \
INSTALLARCHLIB=$RPM_BUILD_ROOT%{perl_archlib} \
TT_PREFIX=$RPM_BUILD_ROOT%{_datadir}/tt2
find $RPM_BUILD_ROOT -type f \( -name perllocal.pod -o \
- -name .packlist -o -name '*.bs' -size 0 \) -exec rm {} ';'
-find $RPM_BUILD_ROOT -depth -type d -empty -exec rmdir {} ';'
+ -name .packlist -o -name '*.bs' -size 0 \) -exec rm -f {} ';'
+find $RPM_BUILD_ROOT -depth -type d -empty -exec rmdir -f {} ';'
chmod -R u+w $RPM_BUILD_ROOT/*
# Nuke buildroot where it hides
sed -i s|$RPM_BUILD_ROOT||g
$RPM_BUILD_ROOT%{perl_vendorarch}/Template/Config.pm
@@ -78,6 +102,18 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Thu Aug 23 2012 Tom Callaway s...@fedoraproject.org - 2.24-1
+- update to 2.24
+
+* Tue Aug 21 2012 Petr Pisar ppi...@redhat.com - 2.22-14
+- Correct dependencies
+
+* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.22-13
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
+
+* Wed Jun 20 2012 Petr Pisar ppi...@redhat.com - 2.22-12
+- Perl 5.16 rebuild
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.22-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 9dfe444..c3ea2d0 100644
--- a/sources
+++ b/sources
@@ -1,2 +1,2 @@
-d98277f6420e5da6b93d99a8db2b3934 Template-Toolkit-2.22.tar.gz
-587d909170fd7dcbe8a51485c49fa3e0 TT_v222_html_docs.tar.gz
+c25fdab1beebf8818c2e624bc9f9d212 Template-Toolkit-2.24.tar.gz
+434a70bb50915e5c2baf5c3fd6ce673e TT_v224_html_docs.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Reminder: Fedora 18 Beta freeze readiness meeting 2012-10-08 @ 17:00 UTC
Hi! This is a reminder for special FESCo/FPGM/Fedora QA meeting to decide if Fedora 18 is ready to freeze (based on Fedora 18 Beta criteria [1]). The goal is to avoid the long freeze period if we know, we are not yet ready to fulfil Beta criteria. Join us on FreeNode.org #fedora-meeting-1 channel today (2012-10-08) @ 17:00 UTC. For more info see FESCo ticket #946 [2] - Fedora 18 Beta freeze readiness: is major functionality in place? Where major functionality is - new upgrade tool - beta partitioning requirements - other areas Jaroslav [1] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria [2] https://fedorahosted.org/fesco/ticket/946 ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
[Guidelines Change] Change to the Packaging Guidelines
A few minor changes to the Fedora Packaging Guidelines have been made: --- The Ruby Packaging guidelines were updated to reflect the fact that rubygem packages must have a Requires: rubygems, because that package (rubygems) owns the RubyGems? directory structure. https://fedoraproject.org/wiki/Packaging:Ruby#RubyGems --- The systemd Scriptlets for Fedora 18+ have had their corresponding scriptlet Requires adjusted from systemd-units to systemd, since systemd-units is provided by the systemd package in Fedora 18+. There is still a separation in previous releases of Fedora (16/17), so packagers can choose to continue using the old Requires (systemd-units) if they are targeting multiple versions of Fedora with a single spec file. https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29 --- This guideline change was approved by the Fedora Packaging Committee (FPC). Many thanks to Vit Ondruch, Lennart Poettering, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~tom ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
