Re: Autoconf in rawhide broken?
That perl issue was fixed a while back. There's not enough info here for me to help you. I'm really curious what happens here also. Richard, could you specify more info? The 'repoquery -q --requires autoconf' correctly shows 'perl(Carp)' dependency in my rawhide mock instance. So it should be working in koji also. I have a question here, Kevin (or others). What action fixed the dependency hell for this issue? Because I did not rebuild the autoconf package for the #924938 bug. I guess that 'rpm -qR autoconf' is a dynamic question: search whole binary rpm file for e.g. perl files and look what is really needed ... and construct the dependencies. But it is not the case how this is done for 'yum install' because at the time the task 'yum install autoconf' was submitted - we are unable to count dynamically all dependencies.. we still don't have all rpm's. So .. metatdata are somewhere in repo statically stored.. But when this info was fixed for autoconf? Thanks, Pavel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On 9. 4. 2013 at 12:25:56, seth vidal wrote: On Tue, 9 Apr 2013 11:18:54 -0500 Bruno Wolff III br...@wolff.to wrote: On Wed, Apr 10, 2013 at 00:05:45 +0800, Mathieu Bridon boche...@fedoraproject.org wrote: The current behaviour would be obtained by setting it to 1, and setting it to 2 would already be a positive change as it would allow downgrading a package if the update went wrong. I don't think that is really what you want either. The idea is to keep recently obsoleted updates around, not 2 or 3 versions of everything. The change has some other benefits. Reverting bad updates in rawhide would be easier. You can use yum downgrade instead of having to going look at koji and download builds. Dealing with packages dropping out of repos when moving between test and updates. The latter issue is especially bad with branched during freezes. So - this is just an idea - and not necessarily a good one - but what about moving older pkgs which are not in the initial release repo into an updates-archive repo. We could leave the repo disabled by default and only keep 2 copies of any single pkg name in the repo at a time. That way in the best of all possible worlds you'd have at most 4 copies of a pkg in total: 1 - in the base release 'everything' repo 1 - in updates 2 - in updates-archive I'm not sure this solves the initial problem - downloading new metadata every 6 hours or so ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
Hi, I use Fedora rawhide daily as an all-purpose desktop: administrative tasks (budgets, taxes, etc), mail, web browsing (online stores, news, etc). I am pretty agnostic in what I call desktop but over the years I've slowly moved from fat clients to local web clients plugged on local 'server' apps (postfix, amavisd-new, dovecot, squirrelmail…). In part to get the ability to access my desktop remotely and in part due to GNOME's long-term failure in providing apps with stable behaviour, complete feature-sets and robust data handling (I used for example to launch evolution when at home. Now I don't bother and open squirrelmail directly. Both evo and thundermail never bothered with correct handling of shared maildir stores). I don't care about the continuous chrome rewrites and experimentations when basic functionnality does not work (for the same reasons I use the terminal all the time instead of desktop helpers). The web apps have no fancy UI but they get the job done reliably day after day. (OTOH OpenOffice then LibreOffice I continue to use, so I'm not wed to web apps I just want working no-surprise dekstop apps). IMHO there is a severe lack of understanding FLOSS desktop-side that pretty demos win reviews and two-weeks user tests but long-term adoption relies on long-term stability and lack of UI surprises. Once upon a time I wanted to explore adding entertainment media PC functions to the desktop (I have all the required hardware, including video capture card) but I gave up on it for pretty much the same reasons I gave up on GNOME apps (the last straw was the killing of background audio/video tasks by laptop-oriented developpers). Printing robustness is a long-term sore point (when you fill admin documents, invoices, taxes it must work now not the next day after lots of debuging). Due to limited free time my Fedora testing has slowly devolved into filling abrt and selinux reports (there are enough crashes in Fedora apps handling them does not leave any time for more in-depth reporting, which is ignored too often anyway). I've used Fedora and other FLOSS projects in the past to push changes i wanted upstream, and I still use it to get an idea about the changes that will eventually land in distro derivatives that I will see used at work for example (I'm pretty pessimistic about Fedora adoption. RHL then Fedora used to be in the same class than other desktop systems like windows, but other desktop producers made huge stability efforts while Fedora moved the other way for unfathomable reasons. Once upon a time a Linux desktop was the solution if you wanted to avoid data loss (at the cost of being a bit bare) now it's even more bare but completely outclassed by the competition on the stability front. Lately I've noticed the Games SIG packaged some interesting bits in Fedora, and so far those bits to not fail in strange and misterious ways and I can continue months-old games after multiple updates without strange and mysterious time-consuming behaviour changes. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autoconf in rawhide broken?
On 2013-04-10, Pavel Raiskup prais...@redhat.com wrote: I have a question here, Kevin (or others). What action fixed the dependency hell for this issue? http://pkgs.fedoraproject.org/cgit/perl.git/commit/?id=8bb72978405d9fbb30cf160f18cd789f7b4062ab We excluded some scripts delivered in binary `perl' package from scanning by automatic Provides-generator. The scripts defines `Carp' perl module internally what fools the generator to export it as `perl(Carp)' dependency symbol. Without the fix, `perl' package declared it provides Carp module on RPM level, which was not true on Perl code level, so while yum got satisfied with `perl' package, none Carp module was installed into the system and that made other Perl code using the Carp module, like autconf, unhappy. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kernel functionality which replaced cpuspeed daemon thermal limits ?
Back in Fedora 16, the cpuspeed daemon RPM was removed from the repositories. To quote [1] Fedora 16 kernel cpufreq stack now fully replaces CPUSpeed, effectively making the package obsolete. There seems to be little clear documentation though on how to make use of the cpufreq stack to do what cpuspeed was able todo. In particular I have this setup: cpuspeed -i 10 -T 3 -t /sys/devices/virtual/thermal/thermal_zone1/temp 75000 Which lets the CPUs run at full speed when load demands, but if the temperature exceeds 75C then cpuspeed throttles back regardless of load to allow cooling. AFAICT, none of the built-in kernel governors are able to express such a policy. In particular the default ondemand governor is useless because it will happily keep the CPU at full speed if there is load, even when the temperature goes up to beyond the critical thermal shutdown point. Pretty much any parallel compile job will cause an emergency shutdown in this way. Of course this is ultimately the fault of shitty Thinkpad bios and/or cooling, but cpuspeed lets me cope with the hardware flaws. Can anyone point out the kernel cpufreq config that I might have missed to make it take into account thermal sensors when controlling CPU freq ? If there is none, then I intend to re-submit cpuspeed for review and inclusion in Fedora repos. Regards, Daniel [1] https://fedoraproject.org/wiki/Fedora_16_Alpha_release_notes#What.27s_New_in_Fedora_16_Alpha -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: [Fedora Update] [comment] wallaby-0.16.0-3.fc19
Why is it 7 days? It used to by 3 days in this period of release cycle, if I remember correctly. Was there some change? Vít Původní zpráva Předmět:[Fedora Update] [comment] wallaby-0.16.0-3.fc19 Datum: Tue, 09 Apr 2013 22:04:11 + Od: upda...@fedoraproject.org Komu: vondr...@fedoraproject.org bodhi - 2013-04-09 22:04:10 (karma: 0) This update has reached 7 days in testing and can be pushed to stable now if the maintainer wishes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Dne 9.4.2013 18:14, Simo Sorce napsal(a): On Tue, 2013-04-09 at 17:16 +0200, Hans de Goede wrote: Hi, Am 09.04.2013 14:27, schrieb Matthew Miller: On Tue, Apr 09, 2013 at 10:10:26AM +0100, Richard Hughes wrote: I'm wondering what the interest would be in keeping packages referenced in metadata on the mirrors for say a month? We'd probably need a separate fedora-security repo too that's designed to be kept small enough so that metadata checks every day would be not costly in terms of bandwidth and time. If anyone is interested in doing this, you'd be awesome. Thanks. I've heard of a plan in development about batching non-critical updates into monthly sets. It seems like these two things could go together I'm sorry, but that is a very bad idea. When users report bugs, and I mean real bugs here, like crashes or non working functionality. I always do my best to get them a fixed package asap, and AFAIK they really appreciate this. Moreover this is just a very non Fedora thing to do, one of the things Fedora is, is about being First. A lot of out users expect us to quickly give them new packages after upstream bug-fix releases. Lumping these all together in a single day in the month just does not feel like a Fedora thing to do. Also many packages in Fedora are maintained by volunteers lumping all the updates together will mean a flag day where all of the packages maintained by someone will get pushed at once, leading to a peak in work load, since despite testing, etc. There will be regressions as well as new packages sometimes leading to questions. And there also will be a peak workload a few days before the flag day to try and get things in now, instead of needing to wait a month. Having such peak workloads is not a good idea in general, and esp. not with volunteers. Can't they get them from updates-testing if they need a fix right now ? Simo. Actually, if update gets enough karma, it could be released immediately. The karma signals that somebody cares to give a karma. If there is no karma, it can be release in one month batch, since it is probably just minor, non-interesting fix. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130410 changes
Compose started at Wed Apr 10 08:15:14 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eclipse] 1:eclipse-tests-4.3.0-0.30.fc20.x86_64 requires osgi(org.eclipse.releng.tools) [eg] eg-1.7.5.2-1.fc20.noarch requires perl(one) eg-1.7.5.2-1.fc20.noarch requires perl(it) eg-1.7.5.2-1.fc20.noarch requires perl(an) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [mapserver] php-mapserver-6.0.3-9.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapserver-6.0.3-9.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) [mygui] mygui-3.2.0-4.fc20.i686 requires libCommon.so mygui-3.2.0-4.fc20.x86_64 requires libCommon.so()(64bit) mygui-demos-3.2.0-4.fc20.x86_64 requires libCommon.so()(64bit) mygui-tools-3.2.0-4.fc20.x86_64 requires
Recommended memory size for F19?
Dear developers, I was running F18 on an old notebook with 512 MB memory (not extendable). Now, I upgraded this box to F19 with yum. The upgrade was done, but now, the box is no more operable because it is continuously swapping. Question: which minimal memory size is recommended for F19? Kind regards Joachim Backes -- Fedora release 18 (Spherical Cow): Kernel-3.8.6-203.fc18.x86_64 Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 for F19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu 04 Apr 2013 11:04:44 AM EDT, Matthias Runge wrote: Hi, recently, we introduced python-django14 for F19, to provide a compatibility package for those packages not working with Django-1.5 and requiring an older Django-1.4. If you know, your django-package does not work with Django-1.5 or are in doubt, please change in your spec-file Requires: python-django to Requires: python-django14 In a week, I will upgrade python-django to Django-1.5.1, in the mean time, I'll file bugs against packages including patches. Actually, I just realized that this is NOT going to provide a clean upgrade path. If you change the Requires: to python-django14, it means that when upgrading an app, yum is going to attempt to install python-django14 on systems that already have python-django, which will result in an implicit conflict. There are two things that should probably be done to solve this: 1) All applications should change Requires: python-django to Requires: python-django = 1.4 Conflicts: python-django = 1.5 Since the python-django14 package Provides: python-django = 1.4.5, this will cleanly move upgrades along to the python-django14 package if needed. 2) The python-django14 package should add: Obsoletes: python-django 1.5 Conflicts: python-django = 1.5 This way, anyone who is currently running python-django = 1.4.x will continue along the 1.4.x upgrade path until they explicitly switch to 1.5. Also, since the packages are not mutually-compatible, they really need to have the explicit Conflicts. It should be safe to use Obsoletes $current_version because we will only ever be supporting in Fedora the two versions supported by upstream. It gets a little hazy with EPEL, but given that upstream has abandoned the older releases, they should probably get retired eventually. Adding Toshio to the CC list explicitly to check my logic :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlUrgACgkQeiVVYja6o6PshgCePEKhRM7kmkeGbyYIVDLDImIW NnIAoKbAi7RZ8FFl3EpYyneFc+8yxci0 =sjyA -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130410 changes
Compose started at Wed Apr 10 09:15:13 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [alexandria] alexandria-0.6.9-4.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [denemo] denemo-0.9.4-0.fc18.x86_64 requires libgtksourceview-3.0.so.0()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eruby] eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) = 0:1.9.0 eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9 eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) = 0:1.9.0 eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) [fawkes] fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8(LIBJPEG_8.0) fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8 fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8(LIBJPEG_8.0)(64bit) fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8()(64bit) fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gearbox] gearbox-10.11-3.fc19.i686 requires libIceUtil.so.35b gearbox-10.11-3.fc19.x86_64 requires libIceUtil.so.35b()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [gorm] gorm-1.2.18-1.fc19.i686 requires libgnustep-gui.so.0.22 gorm-1.2.18-1.fc19.x86_64 requires libgnustep-gui.so.0.22()(64bit) [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686
Re: MySQL and MariaDB in Fedora
- hho...@redhat.com wrote: On 04/05/2013 08:06 PM, Norvald Ryeng wrote: - hho...@redhat.com wrote: On 03/21/2013 08:36 PM, Norvald Ryeng wrote: What is the deadline for fixing the remaining issues with MySQL and MariaDB in Fedora? We would like to find a solution and get 5.6 in soon. Hi Norvald, I've just asked for creating component community-mysql, as discussed on fedora-devel above, the review is done already. As soon as it is built in koji I'm going to EOL MySQL component. So I'm expecting to be done in the beginning of the next week. I see you've bumped the epoch of the MariaDB packages to force MariaDB as default when both MySQL and MariaDB provide mysql-server. We've tested it, and it seems to do the trick. Could you rename the MySQL packages to mysql-community-* instead of community-mysql-*? That way the prefix aligns with the product name and OpenSuSE's prefix. I wanted to use that, but then found out that it wouldn't work. The problem is that it has the same prefix as virtual name mysql, that is used as requirement in other packages. As a result, when somebody asked for mysql -- mysql-community would be preferred before mariadb, because according [1] rule #9 (check the prefix of the pkg to the requiring pkg prefix (perl-foo and perl-lib) for each common character in the prefix add 2 points to the provider's score) would be applied. When we use the name community-mysql we don't have any same prefix, so the rule #10 is applied (if, at this point, we have pkgs with an equal score - look at the version of the provide), which means mariadb with higher epoch will be chosen. We've tested and found that if the MariaDB packages have a higher epoch number, they will be chosen even if the MySQL packages have a mysql-community prefix. Generally, I don't like either, that packages in openSUSE an Fedora won't have the same name, but openSUSE has a bit more powerful RPM spec to handle such things. [1] http://yum.baseurl.org/wiki/CompareProviders How do we get push access to the git repo? It would be great to get 5.6 in before the test day on April 30. To get involved, just follow standard process as described on Fedora wiki: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers However, I'd rather wait with 5.6 until F20 because of the following reasons: * we are almost a month after feature freeze * I believe users will have enough concerns with switching to MariaDB and MySQL-5.6 would bring others * better wait a bit longer to stabilize the new release than bring a quite important package too soon Introduction of MariaDB should not interfere with upgrading MySQL. If anything, choosing MariaDB as the default makes upgrading MySQL easier since it will only be installed when users explicitly ask for it. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 for F19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed 10 Apr 2013 07:53:28 AM EDT, Stephen Gallagher wrote: There are two things that should probably be done to solve this: 1) All applications should change Requires: python-django to Requires: python-django = 1.4 Conflicts: python-django = 1.5 Since the python-django14 package Provides: python-django = 1.4.5, this will cleanly move upgrades along to the python-django14 package if needed. I need to amend this piece. You *do* need to add an explicit BuildRequires: python-django14 to your application and rebuild it as well, otherwise if there are any dependencies in the chain that have an unversioned Requires: python-django, they will force 1.5 into the build and break things. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlXjoACgkQeiVVYja6o6PEHQCcCCIzbGhXgqMgHcoSjxRmdLlD yvkAn1PX8EkBiE31JyzrrlTQai8XuezH =aFCo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Revisiting non-rawhide chain-builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot. However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch. It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches. I've opened an RFE on the upstream fedpkg project here: https://fedorahosted.org/fedpkg/ticket/6 This might make an excellent and highly-useful GSoC project. I've added it to the Summer Coding Ideas Page[1]. I'm not the best person to act as mentor, since I don't know the code, but I'd be okay acting as a backup mentor. [1] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2013#Fedpkg:_Chain-builds_for_non-Rawhide_branches -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlZGsACgkQeiVVYja6o6NWxgCgh7mBGR4X8ME3sTrH+m9R/tBu kxsAmgIFRwdCq6Ke20ndrp/LE5gFrWG2 =Yty8 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Each Fedora release I do series of blog on New Security Feature coming in the next Fedora.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I need ideas for what to write about in Fedora 19. Could people send some to me. If you google security features site:danwalsh.livejournal.com you will see a lot of the past blogs. Things I have covered in the past in addition to SELinux advances, systemd improvements, journald, kerberos moving the cache, FreeIPA integration with ActiveDirectory, audit improvement, libvirt/containers ... Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlZQYACgkQrlYvE4MpobOokACeMB4ZAkU+/g7T4+YkGh9gq3/Q Jm8AoJ3vs2qdymMWa4RBeGg3J9iQHdSK =vwFC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Each Fedora release I do series of blog on New Security Feature coming in the next Fedora.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2013 09:11 AM, Daniel J Walsh wrote: I need ideas for what to write about in Fedora 19. Could people send some to me. If you google security features site:danwalsh.livejournal.com you will see a lot of the past blogs. Things I have covered in the past in addition to SELinux advances, systemd improvements, journald, kerberos moving the cache, FreeIPA integration with ActiveDirectory, audit improvement, libvirt/containers ... The new Shared System Certificates features sounds like a good candidate: https://fedoraproject.org/wiki/Features/SharedSystemCertificates -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlZ24ACgkQeiVVYja6o6PHnwCfSMWdwGB/OyWNchIP+f33LHja 8zgAn29k44DWqJ1SVH3TavlcjUWror/J =DcR0 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, Apr 10, 2013 at 09:24:49 +0200, Jan Zelený jzel...@redhat.com wrote: I'm not sure this solves the initial problem - downloading new metadata every 6 hours or so ... Does the metadata really need to be downloaded or just checked to see if it is current? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
Hello all, the discussion has somewhat died down... If you have a specific proposal for a change in policy, please add it to https://fedorahosted.org/fesco/ticket/1104 ; hard data that demonstrate the impact, if any, in a situation relevant to Fedora (in particular, taking into account prelink as it is deployed by default) would be very welcome but is not a strict requirement. (This is not intended to cut off the discussion on the mailing list, only to make it clear to FESCo whether there is any proposal for change or whether we are happy enough with the current status.) Thank you, Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review ticket 512: improve performance of vattr code
https://fedorahosted.org/389/ticket/512 https://fedorahosted.org/389/attachment/ticket/512/0001-Ticket-512-improve-performance-of-vattr-code.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Each Fedora release I do series of blog on New Security Feature coming in the next Fedora.
On 04/10/2013 01:11 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I need ideas for what to write about in Fedora 19. Could people send some to me. If you google security features site:danwalsh.livejournal.com you will see a lot of the past blogs. Things I have covered in the past in addition to SELinux advances, systemd improvements, journald, kerberos moving the cache, FreeIPA integration with ActiveDirectory, audit improvement, libvirt/containers ... ( systemd ) container awesomeness JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-04-10 @ 16:00 UTC - F19 Alpha Blocker Bug Review #6
# F19 Alpha Blocker Review meeting #6 # Date: 2013-04-10 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net Apologies on the late notice but it's time for another exciting blocker review meeting! We'll be running through the alpha blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the alpha release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ 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: Keeping old versions of packages
Am 10.04.2013 15:47, schrieb Bruno Wolff III: On Wed, Apr 10, 2013 at 09:24:49 +0200, Jan Zelený jzel...@redhat.com wrote: I'm not sure this solves the initial problem - downloading new metadata every 6 hours or so ... Does the metadata really need to be downloaded or just checked to see if it is current? normally not if proper implemented in the client to check last creation time FTP: no problem to check timestamp HTTP: HEAD-request and E-Tags signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
Being in the middle of a career change, I use Fedora as a basic desktop with MATE. As productivity I do a lot of photo editing with GIMP and the occasional tools like custom-made ImageMagick scripts, illustration with Inkscape, DTP with a GIMP and Inkscape combo and web development with Pluma. On the server side, I run only an Apache instance on the same machine for testing the web stuff. All the other services are externally hosted. The machine is shared with my life partner, who also do photo editing, but as she refuses to even try Linux alternatives, is set-up for dual boot with Window 7. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 09:24:49 +0200 Jan Zelený jzel...@redhat.com wrote: On 9. 4. 2013 at 12:25:56, seth vidal wrote: On Tue, 9 Apr 2013 11:18:54 -0500 Bruno Wolff III br...@wolff.to wrote: On Wed, Apr 10, 2013 at 00:05:45 +0800, Mathieu Bridon boche...@fedoraproject.org wrote: The current behaviour would be obtained by setting it to 1, and setting it to 2 would already be a positive change as it would allow downgrading a package if the update went wrong. I don't think that is really what you want either. The idea is to keep recently obsoleted updates around, not 2 or 3 versions of everything. The change has some other benefits. Reverting bad updates in rawhide would be easier. You can use yum downgrade instead of having to going look at koji and download builds. Dealing with packages dropping out of repos when moving between test and updates. The latter issue is especially bad with branched during freezes. So - this is just an idea - and not necessarily a good one - but what about moving older pkgs which are not in the initial release repo into an updates-archive repo. We could leave the repo disabled by default and only keep 2 copies of any single pkg name in the repo at a time. That way in the best of all possible worlds you'd have at most 4 copies of a pkg in total: 1 - in the base release 'everything' repo 1 - in updates 2 - in updates-archive I'm not sure this solves the initial problem - downloading new metadata every 6 hours or so ... I wasn't trying to solve that problem. The problem I did solve was the updates repodata growing forever if we keep more than one version of the pkgs in there. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 08:47:38 -0500 Bruno Wolff III br...@wolff.to wrote: On Wed, Apr 10, 2013 at 09:24:49 +0200, Jan Zelený jzel...@redhat.com wrote: I'm not sure this solves the initial problem - downloading new metadata every 6 hours or so ... Does the metadata really need to be downloaded or just checked to see if it is current? The metadata doesn't get downloaded if it hasn't changed - the problem though is that the metadata DOES change often. Normally everyday. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autoconf in rawhide broken?
On Wed, Apr 10, 2013 at 2:20 AM, Pavel Raiskup prais...@redhat.com wrote: That perl issue was fixed a while back. There's not enough info here for me to help you. I'm really curious what happens here also. Richard, could you specify more info? Well it appears to be fixed now. I was pretty sure my mock chroot was new since I hadn't run a local mock rawhide build since a fresh install of f18 (after a failed f17-f18 upgrade with fedup). Sorry for the noise! Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
From: seth vidal skvi...@fedoraproject.org The metadata doesn't get downloaded if it hasn't changed - the problem though is that the metadata DOES change often. Normally everyday. Is there anything that could be done to make it unnecessary to pull the complete metadata for every update? For example, IIRC this is all sqlite data, but what if this was in a plain-text data dump form where something like rsync could be used to efficiently transfer only those bits that have changed. Client CPU time to reconstruct the DB is probably cheaper than the bandwidth. Maybe such a mode would only be used if the DB size exceeded some threshold. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revisiting non-rawhide chain-builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2013 09:08 AM, Stephen Gallagher wrote: Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot. However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch. It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches. My only concern with this is that on non-Rawhide branches, these overrides are temporary. I'd hate for this to result in incomplete update pushes. ~tom == Fedora Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlfjcACgkQPF6ZrZMFQmDyhgCgkOvMC1LVq9BpUXPZymaqebSJ cj0AnR1Ao6ncKCi4Wk/ner0UxiKgFJw0 =HtQI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 10:53:25 -0400 john.flor...@dart.biz wrote: From: seth vidal skvi...@fedoraproject.org The metadata doesn't get downloaded if it hasn't changed - the problem though is that the metadata DOES change often. Normally everyday. Is there anything that could be done to make it unnecessary to pull the complete metadata for every update? For example, IIRC this is all sqlite data, but what if this was in a plain-text data dump form where something like rsync could be used to efficiently transfer only those bits that have changed. Client CPU time to reconstruct the DB is probably cheaper than the bandwidth. Maybe such a mode would only be used if the DB size exceeded some threshold. You'll have to talk to those folks who are trying to work on a delta metadata format. And rsync is not efficient from a bunch of clients to a mirror server. It would cripple a mirror server in a moment. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revisiting non-rawhide chain-builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed 10 Apr 2013 10:59:03 AM EDT, Tom Callaway wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2013 09:08 AM, Stephen Gallagher wrote: Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot. However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch. It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches. My only concern with this is that on non-Rawhide branches, these overrides are temporary. I'd hate for this to result in incomplete update pushes. I don't really see how that would be any worse than the current situation where updates sometimes land in stable before their dependencies do (because Bodhi doesn't yet support listing other updates as dependencies). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlfg0ACgkQeiVVYja6o6Mc0gCfQIVDl1boB0G+PTTxhcsuDOvU 80IAnR4MzwrKTcTVC7N7wO9LMTuj4XPW =txYo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Mathieu Bridon (boche...@fedoraproject.org) said: On Tuesday, April 09, 2013 11:52 PM, Bill Nottingham wrote: If you wanted to keep more versions on the mirrors, you have the following options: 1) Have mash create everything, and then run a script that prunes versions older than X, and re-runs createrepo. [... snip ...] 2) Have mash try and implement a date-based expiry itself from what it requests from koji. [... snip ...] 3) Have mash sort through the packages retrieved by koji, and pull some subset less than 'all' (the last 2/3/4 versions). This is probably doable - it requires requesting all tagged packages from koji and then doing some postprocessing on the list before you download them. It's merely a matter of code. It seems to me that all of these solutions focus on making mash do more stuff, without ever changing Koji. It's the (somewhat) more agile component in that it can be changed with less downstream dependencies, fewer worries about deployment on infrastructure, etc. But couldn't the Koji API grow a new parameter, which would be used for specifying how many versions of each package to get at most? It certainly could. However, Koji's concept of 'newer' is (IIRC) entirely tied to build time/tag time in the repo, not NVR. So it may not be what we want. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 19 Alpha Release Candidate 1 (RC1) Available Now!
2013/4/9 Adam Williamson awill...@redhat.com On 09/04/13 10:41 AM, Andreas Tunek wrote: I tried the live image on two computers and could not get into GDM. Is this a known bug or should I report it? It's hard to tell with no more details than that, but there are no known general showstopper bugs in the GDM/GNOME path of RC1, no. there's known to be a showstopper for KDE: https://bugzilla.redhat.com/** show_bug.cgi?id=949831https://bugzilla.redhat.com/show_bug.cgi?id=949831(a snafu in the build process). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel I added bug 950653 (https://bugzilla.redhat.com/show_bug.cgi?id=950653). /Andreas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On 10. 4. 2013 at 10:53:25, john.flor...@dart.biz wrote: From: seth vidal skvi...@fedoraproject.org The metadata doesn't get downloaded if it hasn't changed - the problem though is that the metadata DOES change often. Normally everyday. Is there anything that could be done to make it unnecessary to pull the complete metadata for every update? For example, IIRC this is all sqlite data, but what if this was in a plain-text data dump form where something like rsync could be used to efficiently transfer only those bits that have changed. Client CPU time to reconstruct the DB is probably cheaper than the bandwidth. Maybe such a mode would only be used if the DB size exceeded some threshold. Adding Zdenek to CC, as he is already working on a proposal to reduce metadata download size. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl] Fix leaking tied hashes
commit c367bfcf005b8eba873800a0a3a8c7e983a1bc30
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 10 14:55:00 2013 +0200
Fix leaking tied hashes
...n-t-leak-deleted-iterator-when-tying-hash.patch | 60 +++
perl-5.16.3-Don-t-leak-if-hh-copying-dies.patch| 109
...16.3-Free-iterator-when-freeing-tied-hash.patch | 78 ++
perl.spec | 16 +++-
4 files changed, 262 insertions(+), 1 deletions(-)
---
diff --git a/perl-5.16.3-Don-t-leak-deleted-iterator-when-tying-hash.patch
b/perl-5.16.3-Don-t-leak-deleted-iterator-when-tying-hash.patch
new file mode 100644
index 000..7280612
--- /dev/null
+++ b/perl-5.16.3-Don-t-leak-deleted-iterator-when-tying-hash.patch
@@ -0,0 +1,60 @@
+From 677ffc8fe97148750054b11e7fbd21c98f860ee1 Mon Sep 17 00:00:00 2001
+From: Father Chrysostomos spr...@cpan.org
+Date: Fri, 21 Sep 2012 18:23:20 -0700
+Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20leak=20deleted=20iterator=20whe?=
+ =?UTF-8?q?n=20tying=20hash?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Petr Pisar: ported to 5.16.3
+---
+ pp_sys.c | 7 +++
+ t/op/tie.t | 13 +
+ 2 files changed, 20 insertions(+)
+
+diff --git a/pp_sys.c b/pp_sys.c
+index 034a2d0..0e35d59 100644
+--- a/pp_sys.c
b/pp_sys.c
+@@ -852,9 +852,16 @@ PP(pp_tie)
+
+ switch(SvTYPE(varsv)) {
+ case SVt_PVHV:
++ {
++ HE *entry;
+ methname = TIEHASH;
++ if (HvLAZYDEL(varsv) (entry = HvEITER((HV *)varsv))) {
++ HvLAZYDEL_off(varsv);
++ hv_free_ent((HV *)varsv, entry);
++ }
+ HvEITER_set(MUTABLE_HV(varsv), 0);
+ break;
++ }
+ case SVt_PVAV:
+ methname = TIEARRAY;
+ if (!AvREAL(varsv)) {
+diff --git a/t/op/tie.t b/t/op/tie.t
+index 9301bb3..5a536b8 100644
+--- a/t/op/tie.t
b/t/op/tie.t
+@@ -1259,3 +1259,16 @@ $h{i}{j} = 'k';
+ print $h{i}{j}, \n;
+ EXPECT
+ k
++
++
++# NAME Test that tying a hash does not leak a deleted iterator
++# This produced unbalanced string table warnings under
++# PERL_DESTRUCT_LEVEL=2.
++package l {
++sub TIEHASH{bless[]}
++}
++$h = {foo=0};
++each %$h;
++delete $$h{foo};
++tie %$h, 'l';
++EXPECT
+--
+1.8.1.4
+
diff --git a/perl-5.16.3-Don-t-leak-if-hh-copying-dies.patch
b/perl-5.16.3-Don-t-leak-if-hh-copying-dies.patch
new file mode 100644
index 000..eb350b6
--- /dev/null
+++ b/perl-5.16.3-Don-t-leak-if-hh-copying-dies.patch
@@ -0,0 +1,109 @@
+From f5488561bdaab57380bf07e8e66778503a41aca3 Mon Sep 17 00:00:00 2001
+From: Father Chrysostomos spr...@cpan.org
+Date: Sun, 23 Sep 2012 12:42:15 -0700
+Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20leak=20if=20hh=20copying=20dies?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When %^H is copied on entering a new scope, if it happens to have been
+tied it can die. This was resulting in leaks, because no protections
+were added to handle that case.
+
+The two things that were leaking were the new hash in hv_copy_hints_hv
+and the new value (for an element) in newSVsv.
+
+By fixing newSVsv itself, this also fixes any potential leaks when
+other pieces of code call newSVsv on explosive values.
+
+Petr Pisar: Ported to 5.16.3
+---
+ hv.c | 6 ++
+ sv.c | 7 ---
+ t/op/svleak.t | 22 +-
+ 3 files changed, 31 insertions(+), 4 deletions(-)
+
+diff --git a/hv.c b/hv.c
+index 3c35341..29d6352 100644
+--- a/hv.c
b/hv.c
+@@ -1440,6 +1440,9 @@ Perl_hv_copy_hints_hv(pTHX_ HV *const ohv)
+ const I32 riter = HvRITER_get(ohv);
+ HE * const eiter = HvEITER_get(ohv);
+
++ ENTER;
++ SAVEFREESV(hv);
++
+ while (hv_max hv_max + 1 = hv_fill * 2)
+ hv_max = hv_max / 2;
+ HvMAX(hv) = hv_max;
+@@ -1461,6 +1464,9 @@ Perl_hv_copy_hints_hv(pTHX_ HV *const ohv)
+ }
+ HvRITER_set(ohv, riter);
+ HvEITER_set(ohv, eiter);
++
++ SvREFCNT_inc_simple_void_NN(hv);
++ LEAVE;
+ }
+ hv_magic(hv, NULL, PERL_MAGIC_hints);
+ return hv;
+diff --git a/sv.c b/sv.c
+index a43feac..597d71b 100644
+--- a/sv.c
b/sv.c
+@@ -8764,11 +8764,12 @@ Perl_newSVsv(pTHX_ register SV *const old)
+ Perl_ck_warner_d(aTHX_ packWARN(WARN_INTERNAL), semi-panic: attempt to
dup freed string);
+ return NULL;
+ }
++/* Do this here, otherwise we leak the new SV if this croaks. */
++SvGETMAGIC(old);
+ new_SV(sv);
+-/* SV_GMAGIC is the default for sv_setv()
+- SV_NOSTEAL prevents TEMP buffers being, well, stolen, and saves games
++/* SV_NOSTEAL prevents TEMP buffers being, well, stolen, and saves games
+with SvTEMP_off and SvTEMP_on round a call to sv_setsv. */
+-sv_setsv_flags(sv, old, SV_GMAGIC | SV_NOSTEAL);
++sv_setsv_flags(sv, old, SV_NOSTEAL);
+ return sv;
+ }
+
+diff --git a/t/op/svleak.t
[perl] Fix dead lock in PerlIO after fork from thread
commit a381049bf683de48ae2db810af33a088e020cc7d
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 10 15:37:36 2013 +0200
Fix dead lock in PerlIO after fork from thread
...106212-Add-PL_perlio_mutex-to-atfork_lock.patch | 48
perl.spec |6 +++
2 files changed, 54 insertions(+), 0 deletions(-)
---
diff --git a/perl-5.17.9-106212-Add-PL_perlio_mutex-to-atfork_lock.patch
b/perl-5.17.9-106212-Add-PL_perlio_mutex-to-atfork_lock.patch
new file mode 100644
index 000..9e3fa34
--- /dev/null
+++ b/perl-5.17.9-106212-Add-PL_perlio_mutex-to-atfork_lock.patch
@@ -0,0 +1,48 @@
+From 4da80956418bbe1fdc23cad0b1cbb24cd7b87609 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Patrik=20H=C3=A4gglund?= patrik.h.haggl...@ericsson.com
+Date: Sat, 2 Feb 2013 20:21:05 +0100
+Subject: [PATCH] PATCH [perl #106212] Add PL_perlio_mutex to
+ atfork_lock/unlock
+
+Using threads + fork() on Linux, and IO operations in the threads, the
+PL_perlio_mutex may be left in a locked state at the call of fork(),
+potentially leading to deadlock in the child process at subsequent IO
+operations. (Threads are pre-empted and not continued in the child
+process after the fork.)
+
+Therefore, ensure that the PL_perlio_mutex is unlocked in the child
+process, right after fork(), by using atfork_lock/unlock.
+
+(The RT text gives ways to reproduce the problem, but are not easily
+added to Perl's test suite)
+---
+ util.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/util.c b/util.c
+index 5c695b8..75381f1 100644
+--- a/util.c
b/util.c
+@@ -2798,6 +2798,9 @@ Perl_atfork_lock(void)
+dVAR;
+ #if defined(USE_ITHREADS)
+ /* locks must be held in locking order (if any) */
++# ifdef USE_PERLIO
++MUTEX_LOCK(PL_perlio_mutex);
++# endif
+ # ifdef MYMALLOC
+ MUTEX_LOCK(PL_malloc_mutex);
+ # endif
+@@ -2812,6 +2815,9 @@ Perl_atfork_unlock(void)
+ dVAR;
+ #if defined(USE_ITHREADS)
+ /* locks must be released in same order as in atfork_lock() */
++# ifdef USE_PERLIO
++MUTEX_UNLOCK(PL_perlio_mutex);
++# endif
+ # ifdef MYMALLOC
+ MUTEX_UNLOCK(PL_malloc_mutex);
+ # endif
+--
+1.8.1.4
+
diff --git a/perl.spec b/perl.spec
index 4c22355..92f6c64 100644
--- a/perl.spec
+++ b/perl.spec
@@ -119,6 +119,9 @@ Patch22:
perl-5.16.3-Don-t-leak-deleted-iterator-when-tying-hash.patch
Patch23:perl-5.16.3-Free-iterator-when-freeing-tied-hash.patch
Patch24:perl-5.16.3-Don-t-leak-if-hh-copying-dies.patch
+# Fix dead lock in PerlIO after fork from thread, rhbz#947444, RT#106212
+Patch25:perl-5.17.9-106212-Add-PL_perlio_mutex-to-atfork_lock.patch
+
# Update some of the bundled modules
# see http://fedoraproject.org/wiki/Perl/perl.spec for instructions
@@ -1830,6 +1833,7 @@ tarball from perl.org.
%patch22 -p1
%patch23 -p1
%patch24 -p1
+%patch25 -p1
#copy the example script
cp -a %{SOURCE5} .
@@ -2044,6 +2048,7 @@ pushd %{build_archlib}/CORE/
'Fedora Patch22: Fix leaking tied hashes (RT#107000) [1]' \
'Fedora Patch23: Fix leaking tied hashes (RT#107000) [2]' \
'Fedora Patch24: Fix leaking tied hashes (RT#107000) [3]' \
+'Fedora Patch25: Fix dead lock in PerlIO after fork from thread
(RT106212)' \
%{nil}
rm patchlevel.bak
@@ -3485,6 +3490,7 @@ sed \
%changelog
* Wed Apr 10 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-270
- Fix leaking tied hashes (bug #859910)
+- Fix dead lock in PerlIO after fork from thread (bug #947444)
* Tue Apr 09 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-269
- Sub-package Sys-Syslog (bug #950057)
--
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] Add proper conflicts to perl-Getopt-Long, perl-Locale-Maketext, and perl-Sys-Syslog
commit 06d9b0d83923748fc560bd37d2ddeb223ddc2b6f Author: Petr Písař ppi...@redhat.com Date: Wed Apr 10 17:21:41 2013 +0200 Add proper conflicts to perl-Getopt-Long, perl-Locale-Maketext, and perl-Sys-Syslog perl.spec |5 + 1 files changed, 5 insertions(+), 0 deletions(-) --- diff --git a/perl.spec b/perl.spec index 92f6c64..695d70d 100644 --- a/perl.spec +++ b/perl.spec @@ -902,6 +902,7 @@ Requires: perl(Text::ParseWords) # Recommended: Requires: perl(Pod::Usage) = 1.14 BuildArch: noarch +Conflicts: perl 4:5.16.3-268 %description Getopt-Long The Getopt::Long module implements an extended getopt function called @@ -1036,6 +1037,7 @@ Epoch: 0 Version:1.22 Requires: %perl_compat BuildArch: noarch +Conflicts: perl 4:5.16.3-268 %description Locale-Maketext It is a common feature of applications (whether run directly, or via the Web) @@ -1492,6 +1494,7 @@ Epoch: 0 Version:0.29 Requires: %perl_compat Requires: perl(XSLoader) +Conflicts: perl 4:5.16.3-269 %description Sys-Syslog Sys::Syslog is an interface to the UNIX syslog(3) function. Call syslog() with @@ -3491,6 +3494,8 @@ sed \ * Wed Apr 10 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-270 - Fix leaking tied hashes (bug #859910) - Fix dead lock in PerlIO after fork from thread (bug #947444) +- Add proper conflicts to perl-Getopt-Long, perl-Locale-Maketext, and + perl-Sys-Syslog * Tue Apr 09 2013 Petr Pisar ppi...@redhat.com - 4:5.16.3-269 - Sub-package Sys-Syslog (bug #950057) -- 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: Keeping old versions of packages
Once upon a time, john.flor...@dart.biz john.flor...@dart.biz said: Is there anything that could be done to make it unnecessary to pull the complete metadata for every update? For example, IIRC this is all sqlite data, but what if this was in a plain-text data dump form where something like rsync could be used to efficiently transfer only those bits that have changed. Client CPU time to reconstruct the DB is probably cheaper than the bandwidth. Maybe such a mode would only be used if the DB size exceeded some threshold. The metadata starts in XML before being loaded into an SQLite DB file, and the XML is in the repodata directory with the DB. However, both are compressed, as they are large. For example, the current updates/18/x86_64 XML is over 34M (5M gzip compressed), and the DB is 41M (9M bzip2 compressed). I'm guessing there are historical reasons why different compression is used; both could be made noticeably smaller with xz (XML to just over 3M, DB to 7M), but that's still a lot of data to download (and there are also other metadata files that have to be downloaded sometimes, especially the filelists.xml.gz, which is 10M gzip compressed). I'm not sure when the XML is downloaded instead of (or in addition to) the DB, but it does appear to happen (I see one example in my mirror server web logs this morning for example). All the metadata changes with every push (usually once per day for the updates repo), so it has to be downloaded constantly. Your only practical choice for distribution is HTTP; rsync has much higher server overhead and only available on some mirrors. If you want anything other than the full download, it'll have to be in the form of additional repodata files generated as part of the push. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Guidelines Change] Changes to the Packaging Guidelines
Another round of changes to the Fedora Packaging Guidelines have been made:
---
A new section on packaging cron jobs has been added:
https://fedoraproject.org/wiki/Packaging/CronFiles
---
The guidelines for migrating from sysv init scripts to systemd were
clarified to state that the migration triggers only need to be kept for
two releases (to cover the range of supported upgrades). For example, if
the package converted to systemd unit files in F18, the migration
support could be dropped in the F21. It is not mandatory that they drop
them, this is just to clarify that they have the option of dropping them
at that point.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript
---
If an update to your package resolves a known security concern (at the
time of the update) with a Common Vulnerabilities and Exposures (CVE)
number assigned to it, you should mention the CVE number in the RPM
changelog entry.
https://fedoraproject.org/wiki/Packaging:Guidelines#Security_Updates_To_Resolve_Known_CVE_Issues
---
The Java Guidelines have been updated with macros that simplify
packaging on F19+, a specific circumstance where JAR files can be now
installed to %{_javadir}/%{name}/ under its usual name, and other
cleanups proposed by the Java SIG.
https://fedoraproject.org/wiki/Packaging:Java
---
The ruby gems guidelines have been updated to make use of the
%gem_install macro that is available in Fedora 19 and beyond.
https://fedoraproject.org/wiki/Packaging:Ruby
---
The packaging guidelines have been clarified to specify that RPM Macro
files stored in /etc/rpm/ are not to be marked %config.
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Additional_RPM_Macros
---
A Bundling exception for nodejs-should to include the forked code
fragment from the Node.js assert module was approved.
---
These guideline changes were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Jóhann B. Guðmundsson, Przemek Klosowski, David Malcolm,
Jamie Nguyen, Vit Ondruch, Michal Srb, 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: Recommended memory size for F19?
On Wed, 10 Apr 2013 13:26:48 +0200 Joachim Backes joachim.bac...@rhrk.uni-kl.de wrote: Dear developers, I was running F18 on an old notebook with 512 MB memory (not extendable). Now, I upgraded this box to F19 with yum. The upgrade was done, but now, the box is no more operable because it is continuously swapping. Question: which minimal memory size is recommended for F19? We don't know yet, as f19 hasn't been released. ;) There's still debugging options enabled on the kernel, but I wouldn't think that would cause 'continuously swapping'. Can you use top/ps/etc to identify which thing is using up memory? You could also try booting with 'slub_debug=-' or using a rawhide no debug kernel: http://fedoraproject.org/wiki/RawhideKernelNodebug kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fedora Update] [comment] wallaby-0.16.0-3.fc19
On Wed, 10 Apr 2013 12:44:22 +0200 Vít Ondruch vondr...@redhat.com wrote: Why is it 7 days? It used to by 3 days in this period of release cycle, if I remember correctly. Was there some change? Nope. Just a mistake. ;) The pre-beta status wasn't updated everywhere, and the job that does the nagging had old config. ;( it should be corrected now. Thanks for noting it! Vít kevin -- Původní zpráva Předmět: [Fedora Update] [comment] wallaby-0.16.0-3.fc19 Datum:Tue, 09 Apr 2013 22:04:11 + Od: upda...@fedoraproject.org Komu: vondr...@fedoraproject.org bodhi - 2013-04-09 22:04:10 (karma: 0) This update has reached 7 days in testing and can be pushed to stable now if the maintainer wishes signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recommended memory size for F19?
I was running F18 on an old notebook ... Question: which minimal memory size is recommended for F19? For graphical desktop, the installer currently warns if less than 768MB. Many users probably will be uncomfortable with less than 1GB. Things you can try: Append cgroup_disable=memory to the kernel boot command line. This saves somewhere around 1% (10MB out of 1GB), but every MB counts. Append selinux=0 to the kernel boot command line. This saved me 140MB (difference in grep MemFree /proc/meminfo after booting to single user), which is gigantic. When I decided to restore SELinux, the next boot took about 4 minutes to relabel all files. Stop and disable unwanted services. For example: systemctl stop sendmail.service systemctl disable sendmail.service -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
From: Chris Adams cmad...@hiwaay.net The metadata starts in XML before being loaded into an SQLite DB file, and the XML is in the repodata directory with the DB. However, both are compressed, as they are large. For example, the current updates/18/x86_64 XML is over 34M (5M gzip compressed), and the DB is 41M (9M bzip2 compressed). I'm guessing there are historical reasons why different compression is used; both could be made noticeably smaller with xz (XML to just over 3M, DB to 7M), but that's still a lot of data to download (and there are also other metadata files that have to be downloaded sometimes, especially the filelists.xml.gz, which is 10M gzip compressed). I was thinking there had been some xz integration recently. Maybe that was with the delta rpm support. I don't follow that though since we have a local mirror, there's not much point in rsycing, storing, etc. the deltas. I'm not sure when the XML is downloaded instead of (or in addition to) the DB, but it does appear to happen (I see one example in my mirror server web logs this morning for example). I've wondered about that too. I sure hope we didn't add the efficient method on top of the inefficient method, rather than replace it. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 12:24:58 -0400 john.flor...@dart.biz wrote: I was thinking there had been some xz integration recently. Maybe that was with the delta rpm support. I don't follow that though since we have a local mirror, there's not much point in rsycing, storing, etc. the deltas. There's a rel-eng ticket to enable xz compressed repodata: https://fedorahosted.org/rel-eng/ticket/5362 Basically yum and friends should be able to handle it fine, but createrepo doesn't default to it, so out repos would be different from most everyone elses. This didn't happen for f19, but perhaps we could enable it for rawhide... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 10:33:43 -0500 Chris Adams cmad...@hiwaay.net wrote: The metadata starts in XML before being loaded into an SQLite DB file, and the XML is in the repodata directory with the DB. However, both are compressed, as they are large. For example, the current updates/18/x86_64 XML is over 34M (5M gzip compressed), and the DB is 41M (9M bzip2 compressed). I'm guessing there are historical reasons why different compression is used; both could be made noticeably smaller with xz (XML to just over 3M, DB to 7M), but that's still a lot of data to download (and there are also other metadata files that have to be downloaded sometimes, especially the filelists.xml.gz, which is 10M gzip compressed). I'm not sure when the XML is downloaded instead of (or in addition to) the DB, but it does appear to happen (I see one example in my mirror server web logs this morning for example). Here's how it works. the xml metadata put together over a decade ago. It is the canonical representation of the metadata. The sqlite was added maybe 8ish years ago as a way of more quickly reading the same data and not eating up so much memory. At the time bzip2 was the new hotness so we used it instead of gz. the primary, filelists and other xml should not ever be downloaded at this point unless you hit a mirror which is out of sync, badly. the only xml files that should be getting downloaded: 1. repomd.xml - it's fairly small and the index for everything else 2. comps.xml (or groups.xml) - which is where comps is stored per-repo 3. updatemd.xml which is just the security/update info for describing updates yum will grab repomd.xml and look to see if it is newer than what it has already. Then go from there about updating the rest of the metadata. Hope that helps explain it a bit more. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 12:24:58 -0400 john.flor...@dart.biz wrote: I was thinking there had been some xz integration recently. Maybe that was with the delta rpm support. I don't follow that though since we have a local mirror, there's not much point in rsycing, storing, etc. the deltas. yum and createrepo both support xz now - we can really only do it from f18-f19 iirc - just ot make sure everyone has the required version of yum and friends. I'm not sure when the XML is downloaded instead of (or in addition to) the DB, but it does appear to happen (I see one example in my mirror server web logs this morning for example). I've wondered about that too. I sure hope we didn't add the efficient method on top of the inefficient method, rather than replace it. See my earlier email explaining how that works. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Each Fedora release I do series of blog on New Security Feature coming in the next Fedora.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2013 10:10 AM, Jóhann B. Guðmundsson wrote: On 04/10/2013 01:11 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I need ideas for what to write about in Fedora 19. Could people send some to me. If you google security features site:danwalsh.livejournal.com you will see a lot of the past blogs. Things I have covered in the past in addition to SELinux advances, systemd improvements, journald, kerberos moving the cache, FreeIPA integration with ActiveDirectory, audit improvement, libvirt/containers ... ( systemd ) container awesomeness JBG Be more specific. What has changed in Fedora 19? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlmJ0ACgkQrlYvE4MpobN+0wCfXCtmskuaUa1GZk665l2ETS9N Fn0Aniq6zbjS22SOhUnym5I+or1iWgJG =X3tj -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recommended memory size for F19?
On 04/10/2013 06:23 PM, John Reiser wrote: I was running F18 on an old notebook ... Question: which minimal memory size is recommended for F19? For graphical desktop, the installer currently warns if less than 768MB. Are these the installation memory requirements or the run-time requirements? I am asking because running F18 seems perfectly possible on with 512MB, but running the installer wasn't. Many users probably will be uncomfortable with less than 1GB. Things you can try: Append cgroup_disable=memory to the kernel boot command line. This saves somewhere around 1% (10MB out of 1GB), but every MB counts. Append selinux=0 to the kernel boot command line. This saved me 140MB (difference in grep MemFree /proc/meminfo after booting to single user), which is gigantic. When I decided to restore SELinux, the next boot took about 4 minutes to relabel all files. Stop and disable unwanted services. For example: systemctl stop sendmail.service systemctl disable sendmail.service Disable /tmp on tmpfs? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recommended memory size for F19?
And obviously, you *must* have some swap space if you are trying to run with low RAM. Even as small as 100MB of swap space will help. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
UEFI testing of F19 Alpha RC2 requested
Hi, folks. This is a special testing request for F19 Alpha. There are known to be a couple of bugs that can cause UEFI installation to fail because there isn't enough space in the firmware NVRAM; as a fix for that somewhat-infamous bricking bug on some laptops, the current F19 kernel refuses to write to the NVRAM if it's 50% or more full. As Josh put it: https://bugzilla.redhat.com/show_bug.cgi?id=947142 The kernel now limits efivars from using more than 50% of the available firmware space. This has some known deficiencies if the firmware on the machine doesn't do garbage collection to free up space. This is being worked on upstream. Unfortunately we really don't know how many systems are likely to have problems with this mechanism, and so we're finding it hard to decide if we need to block the Alpha on the kernel improvements. So we're asking that anyone who has a machine with a UEFI firmware on which they can safely do a disposable test install - to a spare disk or partition or whatever - try and do a *native UEFI* install of F19 Alpha RC2 (if writing to a USB stick with livecd-iso-to-disk, remember to pass --efi to make a UEFI bootable stick): https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC2/ and see if you get a successful install. Bear in mind that there are obviously other bugs you might run into as this is an Alpha build - if you run into anything else by all means report it separately, but what we're principally interested in is, if you make it to bootloader installation (one of the last things done in the install process), does it succeed, or do you get an error? And if it succeeds, does the installed system boot - at least as far as grub? If as many people as possible could test and send their feedback to this thread or as a comment on the bug report, that'd be great. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revisiting non-rawhide chain-builds
On Wednesday, April 10, 2013 09:08 PM, Stephen Gallagher wrote: Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot. However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch. It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches. I've opened an RFE on the upstream fedpkg project here: https://fedorahosted.org/fedpkg/ticket/6 This might make an excellent and highly-useful GSoC project. I've added it to the Summer Coding Ideas Page[1]. I'm not the best person to act as mentor, since I don't know the code, but I'd be okay acting as a backup mentor. I know the code quite well, as I implemented a fedpkg-like tool (also based on pyrpkg) for $dayjob, and I had sent a few patches to Jesse. (which reminds me I still have a couple that I never sent back!) I also know the Bodhi code intimately, again because I deployed it at $dayjob (and that implied quite extensive patching to remove hardcoded Fedora assumptions). However, I don't have commit permissions to fedpkg (but I do have them for Bodhi), and as such I wouldn't be able to ensure the changes actually get merged. So I probably wouldn't be the best person to mentor either, but if a student is interested and nobody else wants to, I could eventually act as one. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revisiting non-rawhide chain-builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed 10 Apr 2013 01:19:49 PM EDT, Mathieu Bridon wrote: On Wednesday, April 10, 2013 09:08 PM, Stephen Gallagher wrote: Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot. However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch. It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches. I've opened an RFE on the upstream fedpkg project here: https://fedorahosted.org/fedpkg/ticket/6 This might make an excellent and highly-useful GSoC project. I've added it to the Summer Coding Ideas Page[1]. I'm not the best person to act as mentor, since I don't know the code, but I'd be okay acting as a backup mentor. I know the code quite well, as I implemented a fedpkg-like tool (also based on pyrpkg) for $dayjob, and I had sent a few patches to Jesse. (which reminds me I still have a couple that I never sent back!) I also know the Bodhi code intimately, again because I deployed it at $dayjob (and that implied quite extensive patching to remove hardcoded Fedora assumptions). However, I don't have commit permissions to fedpkg (but I do have them for Bodhi), and as such I wouldn't be able to ensure the changes actually get merged. So I probably wouldn't be the best person to mentor either, but if a student is interested and nobody else wants to, I could eventually act as one. Frankly, you sound like the perfect person to be the primary mentor for this effort, if you're willing. Can I add you to the proposal page? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFln+QACgkQeiVVYja6o6MToQCghmPURVUNjpVWq0LJEYHRSrpf 4QAAoKw2ryBhDxsRJqa61lkEw+ph4/j/ =rkFE -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autoconf in rawhide broken?
Without the fix, `perl' package declared it provides Carp module on RPM level, which was not true on Perl code level, so while yum got satisfied with `perl' package, none Carp module was installed into the system and that made other Perl code using the Carp module, like autconf, unhappy. Well - I probably missed something before. What confused me: after changes in *your* package, the 'perl(Carp)' dependency appeared in *my* package? ... I would bet before that the first thing I was trying in rawhide mock was: `rpm -qR autoconf` and it did not list the 'perl(Carp)'. That convinced me that adding the 'perl(Carp)' to Requires could help. ... But the 'perl(Carp)' auto-dependency was probably always there (and I was blind) - and it just wasn't satisfied by 'perl'. Thanks Petr for leading me to this result, Pavel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM Weekly Status Meeting 2013-04-10
Good day all, Please join us today (Wednesday, April 10th) at 4PM EDT (8PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 0) Status of ACTION items from our previous meeting 1) Problem packages 2) Aarch64 patching - minimal install package set 3) Testing F19 Alpha install tree candidate 4) Your topic here If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
On 04/10/2013 02:34 PM, Norvald Ryeng wrote: - hho...@redhat.com wrote: On 04/05/2013 08:06 PM, Norvald Ryeng wrote: - hho...@redhat.com wrote: On 03/21/2013 08:36 PM, Norvald Ryeng wrote: What is the deadline for fixing the remaining issues with MySQL and MariaDB in Fedora? We would like to find a solution and get 5.6 in soon. Hi Norvald, I've just asked for creating component community-mysql, as discussed on fedora-devel above, the review is done already. As soon as it is built in koji I'm going to EOL MySQL component. So I'm expecting to be done in the beginning of the next week. I see you've bumped the epoch of the MariaDB packages to force MariaDB as default when both MySQL and MariaDB provide mysql-server. We've tested it, and it seems to do the trick. Could you rename the MySQL packages to mysql-community-* instead of community-mysql-*? That way the prefix aligns with the product name and OpenSuSE's prefix. I wanted to use that, but then found out that it wouldn't work. The problem is that it has the same prefix as virtual name mysql, that is used as requirement in other packages. As a result, when somebody asked for mysql -- mysql-community would be preferred before mariadb, because according [1] rule #9 (check the prefix of the pkg to the requiring pkg prefix (perl-foo and perl-lib) for each common character in the prefix add 2 points to the provider's score) would be applied. When we use the name community-mysql we don't have any same prefix, so the rule #10 is applied (if, at this point, we have pkgs with an equal score - look at the version of the provide), which means mariadb with higher epoch will be chosen. We've tested and found that if the MariaDB packages have a higher epoch number, they will be chosen even if the MySQL packages have a mysql-community prefix. According to what I read in [1], mysql-community would be preferred before mariadb because of common prefix, in case both packages will have the same score from the previous rules. I've tested that with a potential package mysqlfoo, which has the same prefix as mysql-community, so if I ran: $ yum update mysqlfoo then mysql-community got higher score and was preferred before mariadb. Maybe there are even more cases like that, so I'd rather stick with community-mysql. [1] http://yum.baseurl.org/wiki/CompareProviders Generally, I don't like either, that packages in openSUSE an Fedora won't have the same name, but openSUSE has a bit more powerful RPM spec to handle such things. [1] http://yum.baseurl.org/wiki/CompareProviders How do we get push access to the git repo? It would be great to get 5.6 in before the test day on April 30. To get involved, just follow standard process as described on Fedora wiki: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers However, I'd rather wait with 5.6 until F20 because of the following reasons: * we are almost a month after feature freeze * I believe users will have enough concerns with switching to MariaDB and MySQL-5.6 would bring others * better wait a bit longer to stabilize the new release than bring a quite important package too soon Introduction of MariaDB should not interfere with upgrading MySQL. If anything, choosing MariaDB as the default makes upgrading MySQL easier since it will only be installed when users explicitly ask for it. Upgrades like this are usually considered as a Feature, which also corresponds with Feature description at [2]. Therefore I'd rather wait for F20. [2] https://fedoraproject.org/wiki/Features/Policy/Definitions Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UEFI testing of F19 Alpha RC2 requested
Once upon a time, Adam Williamson awill...@redhat.com said: https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC2/ I'll give this a test (I've got one older UEFI system that wouldn't work with F18 anyway). One question: can I just download the netinst and point it at a local development/19 mirror, or do I need to download the full DVD? Alternately: is it sufficient to just boot from the images in my local development/19 mirror (so I don't have to download anything new)? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Looking for reasons why mod_security pkg was orphaned/retired
Hi, I'm (co-/) maintainer of mod_security, I noticed that the owner orphaned it and then retired it, obviously I can't take it over. [1] I'm kindly asking for the reasons ? I'm maintaining this package (on fedora and epel) lately so it safe to assign to me if it's possible. CCing the former and new owners. [1] https://admin.fedoraproject.org/pkgdb/acls/name/mod_security Thanks. -- Athmane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UEFI testing of F19 Alpha RC2 requested
On Wed, Apr 10, 2013 at 10:08:31AM -0700, Adam Williamson wrote: process), does it succeed, or do you get an error? And if it succeeds, does the installed system boot - at least as far as grub? I tried RC1 yesterday and it installs, but it gets stuck at the Welcome to GRUB! text. It doesn't even get to the grub prompt. https://bugzilla.redhat.com/show_bug.cgi?id=949761 It looks like grub2 is the same version -- 2.00-16.fc19 -- in both RC1 and RC2. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM Weekly Status Meeting Minutes 2013-04-10
Thanks to those that were able to join for the status meeting today, for those unable the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-10/fedora-meeting-1.2013-04-10-20.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-10/fedora-meeting-1.2013-04-10-20.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-10/fedora-meeting-1.2013-04-10-20.00.log.html -Paul === #fedora-meeting-1: Fedora ARM weekly status meeting === Meeting started by pwhalen at 20:00:17 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-10/fedora-meeting-1.2013-04-10-20.00.log.html . Meeting summary --- * 0) Status of ACTION items from our previous meeting (pwhalen, 20:02:34) * pwhalen to work with pbrobinson to publish weekly problem package reports (pwhalen, 20:02:48) * INPROGRESS - list composed, narrowing down list of most relevant packages. (pwhalen, 20:02:48) * masta, j_dulaney, oatley to try upstream kernel on a10 devices (pwhalen, 20:03:19) * ACTION: masta, j_dulaney, oatley to try upstream kernel on a10 devices (pwhalen, 20:05:35) * bconoboy to draft message to devel-announce requesting aarch64 config.guess/sub support go into f19 (pwhalen, 20:06:15) * bconoboy off this week, follow-up next week. (pwhalen, 20:06:15) * pbrobinson reviewed vboot-utils for masta, awaiting git creation (pwhalen, 20:08:10) * 1) Problem packages (pwhalen, 20:08:29) * looking pretty darn good with the packages (pwhalen, 20:09:27) * tog-pegasus continues to block (pwhalen, 20:09:51) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=922770 (pbrobinson, 20:14:04) * LINK: tog-pegasus BZ - https://bugzilla.redhat.com/show_bug.cgi?id=922770 (pwhalen, 20:15:03) * 2) Aarch64 patching status - minimal install package set (pwhalen, 20:17:32) * ACTION: bconoboy to work out remaining minimal F19 package set requiring aarch64 autotools patching (jonmasters, 20:22:39) * 3) Testing F19 Alpha install tree candidate (pwhalen, 20:23:04) * LINK: http://armpkgs.fedoraproject.org/mash/stage/19-Alpha-RC2/Fedora/ (pwhalen, 20:23:11) * 4) Kernel status update (pwhalen, 20:27:57) * 5) Your topic here (pwhalen, 20:40:02) Meeting ended at 20:42:41 UTC. Action Items * masta, j_dulaney, oatley to try upstream kernel on a10 devices * bconoboy to work out remaining minimal F19 package set requiring aarch64 autotools patching Action Items, by person --- * bconoboy * bconoboy to work out remaining minimal F19 package set requiring aarch64 autotools patching * masta * masta, j_dulaney, oatley to try upstream kernel on a10 devices * **UNASSIGNED** * (none) People Present (lines said) --- * pbrobinson (53) * pwhalen (46) * jonmasters (34) * masta (24) * dgilmore (16) * zodbot (9) * nirik (7) * ahs3 (3) * kalev (2) * whenry (1) * jcapik (1) * jonmasters_ (1) * bconoboy (0) * ctyler (0) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recommended memory size for F19?
On Wed, Apr 10, 2013 at 06:55:59PM +0200, Ralf Corsepius wrote: Disable /tmp on tmpfs? I have suggested this should be done automatically in RAM-limited situations (primarily for VMs): https://bugzilla.redhat.com/show_bug.cgi?id=858265 Well, ideally it would never have been done in the first place, but we are where we are. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 828238] perl-MIME-Charset-1.010 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=828238 Xavier Bachelot xav...@bachelot.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2013-04-10 16:55:17 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7OXD9HdysBa=cc_unsubscribe -- 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: Each Fedora release I do series of blog on New Security Feature coming in the next Fedora.
Le mercredi 10 avril 2013 à 09:11 -0400, Daniel J Walsh a écrit : I need ideas for what to write about in Fedora 19. Could people send some to me. If you google security features site:danwalsh.livejournal.com you will see a lot of the past blogs. Things I have covered in the past in addition to SELinux advances, systemd improvements, journald, kerberos moving the cache, FreeIPA integration with ActiveDirectory, audit improvement, libvirt/containers ... Privacy in gnome 3.8 ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revisiting non-rawhide chain-builds
On 10/04/13 07:58 AM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed 10 Apr 2013 10:59:03 AM EDT, Tom Callaway wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2013 09:08 AM, Stephen Gallagher wrote: Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot. However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch. It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches. My only concern with this is that on non-Rawhide branches, these overrides are temporary. I'd hate for this to result in incomplete update pushes. I don't really see how that would be any worse than the current situation where updates sometimes land in stable before their dependencies do (because Bodhi doesn't yet support listing other updates as dependencies). We've probably been round this roundabout before, but updates are supposed to be internally consistent. If an update to Package A also requires Package B to be updated, both packages should be submitted as a single update. You should not submit one update for A and one for B. When I catch these cases, I file negative feedback until the updates are corrected. I think it might be possible for a sufficiently sophisticated version of the proposed mechanism to help the packager out with doing this, in fact: it could help you do a chain build and then submit an update containing the full chain/set of packages. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recommended memory size for F19?
On 10/04/13 08:53 AM, Kevin Fenzi wrote: On Wed, 10 Apr 2013 13:26:48 +0200 Joachim Backes joachim.bac...@rhrk.uni-kl.de wrote: Dear developers, I was running F18 on an old notebook with 512 MB memory (not extendable). Now, I upgraded this box to F19 with yum. The upgrade was done, but now, the box is no more operable because it is continuously swapping. Question: which minimal memory size is recommended for F19? We don't know yet, as f19 hasn't been released. ;) There's still debugging options enabled on the kernel, but I wouldn't think that would cause 'continuously swapping'. I think debug kernels actually do result in substantially increased memory usage, for some reason. Certainly, Alphas always seem to need more RAM for a successful install than Betas and Finals. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 19 Alpha RC2 UEFI Fail
Fails at Grub. Missing file. En.mo.gz Brian Fagioli linuxtes...@yandex.com -- Sent from Yandex.Mail for mobile: http://m.ya.ru/ymail -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Alpha RC2 UEFI Fail
Fails at Grub. Missing file. En.mo.gz That message probably is just informative, and not the cause of failing to boot. The same message occurs in many successful boots of current release Fedora 18. Right now the suspected culprit of failing to boot Fedora 19 is somewhere in passing control of the active video graphics from one stage to the next. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Alpha RC2 UEFI Fail
When I installed it on the same machine without UEFI, it booted fine. Running it now. 10.04.13, 20:47, John Reiser jrei...@bitwagon.com: Fails at Grub. Missing file. En.mo.gz That message probably is just informative, and not the cause of failing to boot. The same message occurs in many successful boots of current release Fedora 18. Right now the suspected culprit of failing to boot Fedora 19 is somewhere in passing control of the active video graphics from one stage to the next. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Sent from Yandex.Mail for mobile: http://m.ya.ru/ymail -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
Am 09.04.2013 17:02, schrieb Richard Hughes: On 9 April 2013 13:48, Reindl Harald h.rei...@thelounge.net wrote: if i want monthly pacthdays i use Microsoft or Oracle Not at all. Patchdays make perfect sense for planning reboots/downtime/maintenance and that kind of thing. there where i need this test-machines and internal repos exists but i do NOT need anybody to hold back updates for me you can hardly classify which bug is for which user critical! Sure you can, Red Hat does it for updates in RHEL, and you just have to define what the terms mean. 90% of the updates I'm looking at right now for F18 are really not important at all. Spec file fixups, new versions without bugfixes, updated artwork; that can all wait until a certain point in the month but Fedora IS NOT RHEL if you want the RHEL way use it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 for F19
On Wed, Apr 10, 2013 at 07:53:28AM -0400, Stephen Gallagher wrote: Actually, I just realized that this is NOT going to provide a clean upgrade path. If you change the Requires: to python-django14, it means that when upgrading an app, yum is going to attempt to install python-django14 on systems that already have python-django, which will result in an implicit conflict. There are two things that should probably be done to solve this: 1) All applications should change Requires: python-django to Requires: python-django = 1.4 Conflicts: python-django = 1.5 Since the python-django14 package Provides: python-django = 1.4.5, this will cleanly move upgrades along to the python-django14 package if needed. 2) The python-django14 package should add: Obsoletes: python-django 1.5 Conflicts: python-django = 1.5 This way, anyone who is currently running python-django = 1.4.x will continue along the 1.4.x upgrade path until they explicitly switch to 1.5. Also, since the packages are not mutually-compatible, they really need to have the explicit Conflicts. It should be safe to use Obsoletes $current_version because we will only ever be supporting in Fedora the two versions supported by upstream. It gets a little hazy with EPEL, but given that upstream has abandoned the older releases, they should probably get retired eventually. Adding Toshio to the CC list explicitly to check my logic :) Conflicts will run afoul of the guidelines. I thought these were parallel installable? -Toshio pgpG3lY48OPuC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Alpha RC2 UEFI Fail
On 10/04/13 05:50 PM, Brian Fagioli wrote: When I installed it on the same machine without UEFI, it booted fine. Running it now. 10.04.13, 20:47, John Reiser jrei...@bitwagon.com: Fails at Grub. Missing file. En.mo.gz That message probably is just informative, and not the cause of failing to boot. The same message occurs in many successful boots of current release Fedora 18. Right now the suspected culprit of failing to boot Fedora 19 is somewhere in passing control of the active video graphics from one stage to the next. It seems that every tester who doesn't hit the 'ENOSPC' issue and gets a successful install hits this issue where grub fails to display instead. So far the only bootable UEFI install I've heard of is one tflink did where he set grub up to use a serial console. The bug report for this problem is https://bugzilla.redhat.com/show_bug.cgi?id=949761 , we're poking at it there. One thing the devs would like people to try is: pjones: adamw: get them to try putting GRUB_TERMINAL_OUTPUT=console in /etc/default/grub and re-running grub2-mkconfig you could do that from ctrl-alt-f2 after install is complete but before rebooting, or you could do it from rescue mode or a live image on the installed system. The theory is that by disabling grub's graphical mode we'll work around whatever the problem is, and hence prove that the problem is with the graphical mode. If anyone actually got an entirely successful UEFI install with Alpha RC1 or RC2 - it installed without errors, and the installed system boots, showing you a graphical grub screen - that would be useful info to add to the bug; right now I'm working on the assumption that this is a complete showstopper for all UEFI installs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why does _hardened_build use -z,relro and not -z,relro,-z,now ?
Hi, Why does the _hardened_build macro for the spec file use -z,relro and not -z,relro,-z,now ? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Swaping packages review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, I have a package waiting for the review needed for Design spin (for release 20) https://bugzilla.redhat.com/show_bug.cgi?id=913367 In return, I will do the same for the taker waiting to review own package too. Regards, - -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) iQEcBAEBAgAGBQJRZkAEAAoJEF5SgXTYomCaPYcH/0SV3WmbpcCY2uTAXn9lyBpN mVnEW2fhoHNcTzndyzEuUk6GJlIFIq2B49VYcAPVSF03OtQXhz5v4qnd6CMUfA1t 5QvTkecQqkxmlfKfOiWZnorIoEEMv67YY61z7bZm6+cRmZVWT83CFoF/lymt9kGw 5jDk/UtNPBqmxv8mrbV/PgMcp1SCeL7N8KOlX0Y3gpikI2Jdzs7WmuVKLNwV6et1 waC/JVUXSAJFh8gPeMhO2lFjy2iw930srbmOuRQwkObYVPGA+igr6sMrJI5D2hsO i32Au4ZmLROoCHa2ewZN936rNrZ/oEii9+uuXuVC+w1Ci8sds0tJFIoDZ/onBuo= =Lkr1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Locale-Maketext-1.23.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Locale-Maketext: 3d6c7808522292fc2c49e36a04f01968 Locale-Maketext-1.23.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-Locale-Maketext] Import
commit a4652efd9f945bd122910a593366c6d76c76e8fb
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 10 08:29:26 2013 +0200
Import
.gitignore|1 +
perl-Locale-Maketext.spec | 67 +
sources |1 +
3 files changed, 69 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..5166d1b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Locale-Maketext-1.23.tar.gz
diff --git a/perl-Locale-Maketext.spec b/perl-Locale-Maketext.spec
new file mode 100644
index 000..1dc93f1
--- /dev/null
+++ b/perl-Locale-Maketext.spec
@@ -0,0 +1,67 @@
+Name: perl-Locale-Maketext
+Version:1.23
+Release:1%{?dist}
+Summary:Framework for localization
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Locale-Maketext/
+Source0:
http://www.cpan.org/authors/id/T/TO/TODDR/Locale-Maketext-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(strict)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(I18N::LangTags) = 0.31
+BuildRequires: perl(I18N::LangTags::Detect)
+BuildRequires: perl(integer)
+# utf8 is optional
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
+# Tests:
+BuildRequires: perl(base)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(utf8)
+# Optional tests:
+%if !%{defined perl_bootstrap}
+BuildRequires: perl(Test::Pod) = 1.14
+%endif
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(I18N::LangTags) = 0.31
+
+# Filter under-specified dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(I18N::LangTags\\)$
+
+%description
+It is a common feature of applications (whether run directly, or via the Web)
+for them to be localized -- i.e., for them to present an English interface
+to an English-speaker, a German interface to a German-speaker, and so on for
+all languages it's programmed with. Locale::Maketext is a framework for
+software localization; it provides you with the tools for organizing and
+accessing the bits of text and text-processing code that you need for
+producing localized applications.
+
+%prep
+%setup -q -n Locale-Maketext-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc ChangeLog README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Apr 05 2013 Petr Pisar ppi...@redhat.com 1.23-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..a397342 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+3d6c7808522292fc2c49e36a04f01968 Locale-Maketext-1.23.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
[Bug 950017] Unable to use LOG_EMERG level in Sys::Syslog
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=950017 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Depends On||950057 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=x5Ak3wbFUKa=cc_unsubscribe -- 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 950375] New: perl-DBD-Multi-0.18 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=950375 Bug ID: 950375 Summary: perl-DBD-Multi-0.18 is available Product: Fedora Version: rawhide Component: perl-DBD-Multi Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Category: --- Latest upstream release: 0.18 Current version in Fedora Rawhide: 0.16 URL: http://search.cpan.org/dist/DBD-Multi/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=sgi7WYIQn1a=cc_unsubscribe -- 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 828238] perl-MIME-Charset-1.010 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=828238 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-MIME-Charset-1.009.3 |perl-MIME-Charset-1.010 is |is available|available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 1.010 Current version in Fedora Rawhide: 1.009.2 URL: http://search.cpan.org/dist/MIME-Charset/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YiwHadBiEQa=cc_unsubscribe -- 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 950375] perl-DBD-Multi-0.18 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=950375 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mmasl...@redhat.com |psab...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6rV34SDiERa=cc_unsubscribe -- 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 DBD-Multi-0.18.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DBD-Multi: 736a967a9e416c531b8f5a7dd8416d68 DBD-Multi-0.18.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-DBD-Multi] 0.18 bump
commit 2371c11cdc9a9ac355fa2349147e05b633c3fd7e
Author: Petr Šabata con...@redhat.com
Date: Wed Apr 10 10:13:42 2013 +0200
0.18 bump
.gitignore |1 +
perl-DBD-Multi.spec | 73 +++---
sources |2 +-
3 files changed, 41 insertions(+), 35 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0cf00e4..4db6da7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
DBD-Multi-0.14.tar.gz
/DBD-Multi-0.16.tar.gz
+/DBD-Multi-0.18.tar.gz
diff --git a/perl-DBD-Multi.spec b/perl-DBD-Multi.spec
index a5469b7..a10881a 100644
--- a/perl-DBD-Multi.spec
+++ b/perl-DBD-Multi.spec
@@ -1,30 +1,41 @@
-Name: perl-DBD-Multi
-Version:0.16
-Release:8%{?dist}
+Name: perl-DBD-Multi
+Version:0.18
+Release:1%{?dist}
# see Makefile.PL
-License:GPL+ or Artistic
+License:GPL+ or Artistic
Group: Development/Libraries
-Summary:DB Proxy with fail-over and load balancing
-Source:
http://search.cpan.org/CPAN/authors/id/D/DW/DWRIGHT/DBD-Multi-%{version}.tar.gz
+Summary:DB Proxy with fail-over and load balancing
+Source:
http://search.cpan.org/CPAN/authors/id/D/DW/DWRIGHT/DBD-Multi-%{version}.tar.gz
Url:http://search.cpan.org/dist/DBD-Multi
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
BuildArch: noarch
-
-BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Class::Accessor::Fast) = 0.19
-BuildRequires: perl(DBD::SQLite) = 1.09
+# Build
+BuildRequires: perl
+BuildRequires: perl(Config)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MM_Unix)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Path)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+# Runtime
+BuildRequires: perl(base)
+BuildRequires: perl(Class::Accessor::Fast)
+BuildRequires: perl(DBD::File)
BuildRequires: perl(DBI)
-BuildRequires: perl(List::Util) = 1.18
-BuildRequires: perl(Pod::Simple)
-BuildRequires: perl(Sys::SigAction) = 0.1
-BuildRequires: perl(Test::Exception) = 0.21
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Sys::SigAction)
+# Test-only
+BuildRequires: perl(DBD::SQLite)
+BuildRequires: perl(DBI::Const::GetInfoType)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod) = 1.14
-BuildRequires: perl(Test::Pod::Coverage) = 1.04
-
-# not picked up due to 'use base'
-Requires: perl(Class::Accessor::Fast) = 0.19
+# not picked up automatically
+Requires: perl(Class::Accessor::Fast)
%description
This software manages multiple database connections for fail-overs and also
@@ -35,34 +46,28 @@ based on your preferences and present availability of the
DB server.
%prep
%setup -q -n DBD-Multi-%{version}
-%{__perl} -pi -e 's|^#!perl|#!%{__perl}|' t/*.t
-
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-rm -rf %{buildroot}
-
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
-
%{_fixperms} %{buildroot}/*
%check
make test
-%clean
-rm -rf %{buildroot}
-
%files
-%defattr(-,root,root,-)
-%doc Changes README t/
+%doc Changes README TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
+* Wed Apr 10 2013 Petr Šabata con...@redhat.com - 0.18-1
+- 0.18 bump; testsuite enhancement and get_info implementation
+- Spec cleanup
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.16-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 9f20498..4077728 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-82b248645e7799c938201cf0b3ef86da DBD-Multi-0.16.tar.gz
+736a967a9e416c531b8f5a7dd8416d68 DBD-Multi-0.18.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-DBD-Multi/f19] 0.18 bump
Summary of changes: 2371c11... 0.18 bump (*) (*) 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 950375] perl-DBD-Multi-0.18 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=950375 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-DBD-Multi-0.18-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-DBD-Multi-0.18-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=LB58K5gguNa=cc_unsubscribe -- 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-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) 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
File Sys-Syslog-0.32.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Sys-Syslog: 8a7b1f4414d7cfd2421cba7fae1bd602 Sys-Syslog-0.32.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-Sys-Syslog] Import
commit 69cc6e8c9dd84c3bd0e3f8c46ca4709a62bd9861
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 10 13:40:35 2013 +0200
Import
.gitignore |1 +
perl-Sys-Syslog.spec | 86 ++
sources |1 +
3 files changed, 88 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..d390a26 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Sys-Syslog-0.32.tar.gz
diff --git a/perl-Sys-Syslog.spec b/perl-Sys-Syslog.spec
new file mode 100644
index 000..46d1135
--- /dev/null
+++ b/perl-Sys-Syslog.spec
@@ -0,0 +1,86 @@
+Name: perl-Sys-Syslog
+Version:0.32
+Release:1%{?dist}
+Summary:Perl interface to the UNIX syslog(3) calls
+# Unused sources fallback/* are covered with BSD license.
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Sys-Syslog/
+Source0:
http://www.cpan.org/authors/id/S/SA/SAPER/Sys-Syslog-%{version}.tar.gz
+BuildRequires: perl
+BuildRequires: perl(strict)
+BuildRequires: perl(ExtUtils::Constant)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(File::Spec)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Socket)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
+BuildRequires: perl(warnings::register)
+BuildRequires: perl(XSLoader)
+# DynaLoader not used
+# Tests:
+BuildRequires: perl(Config)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Test::More)
+# Optional tests:
+%if !%{defined perl_bootstrap}
+%if !0%{?rhel}
+BuildRequires: perl(Test::Distribution)
+%endif
+BuildRequires: perl(Test::NoWarnings)
+BuildRequires: perl(Test::Pod) = 1.14
+BuildRequires: perl(Test::Pod::Coverage) = 1.06
+BuildRequires: perl(Test::Portability::Files)
+# POE::Component::Server::Syslog is not packaged yet
+%endif
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(XSLoader)
+
+%{?perl_default_filter}
+
+%description
+Sys::Syslog is an interface to the UNIX syslog(3) function. Call syslog() with
+a string priority and a list of printf() arguments just like at syslog(3).
+
+%prep
+%setup -q -n Sys-Syslog-%{version}
+chmod -x eg/*
+# Inhibit bundled syslog.h
+rm -rf fallback
+sed -i -e '/^fallback\//d' MANIFEST
+# Recode files
+for F in Changes; do
+iconv -f ISO-8859-1 -t UTF-8 $F ${F}.utf8
+touch -r $F ${F}.utf8
+mv ${F}.utf8 $F
+done
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes eg README
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/Sys*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Apr 09 2013 Petr Pisar ppi...@redhat.com 0.32-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..d6d7b74 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+8a7b1f4414d7cfd2421cba7fae1bd602 Sys-Syslog-0.32.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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the F-19 tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 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 950017] Unable to use LOG_EMERG level in Sys::Syslog
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=950017 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-5.16.3-269.fc20 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Fixed with perl-5.16.3-269.fc20 and perl-Sys-Syslog-0.32-1.fc20 in F20. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=jlp9lXeLSKa=cc_unsubscribe -- 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 947444] PerlIO dead-locks with threaded fork
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947444 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Assignee|mmasl...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CbdsZbxYnia=cc_unsubscribe -- 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 MIME-Charset-1.010.tar.gz uploaded to lookaside cache by xavierb
A file has been added to the lookaside cache for perl-MIME-Charset: f0cc0af0566033dac5c9ecddf26004be MIME-Charset-1.010.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-MIME-Charset] 1.010
commit 9d74b8a8765471e41fa3fcc441eb768ed5989d57
Author: Xavier Bachelot xav...@bachelot.org
Date: Wed Apr 10 22:34:42 2013 +0200
1.010
.gitignore |1 +
perl-MIME-Charset.spec |9 ++---
sources|2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 63baa51..988dff8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ MIME-Charset-1.006.2.tar.gz
/MIME-Charset-1.008.2.tar.gz
/MIME-Charset-1.009.1.tar.gz
/MIME-Charset-1.009.2.tar.gz
+/MIME-Charset-1.010.tar.gz
diff --git a/perl-MIME-Charset.spec b/perl-MIME-Charset.spec
index c038125..39d88ae 100644
--- a/perl-MIME-Charset.spec
+++ b/perl-MIME-Charset.spec
@@ -1,6 +1,6 @@
Name: perl-MIME-Charset
-Version:1.009.2
-Release:4%{?dist}
+Version:1.010
+Release:1%{?dist}
Summary:Charset Informations for MIME
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,11 +57,14 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc ARTISTIC Changes GPL README
+%doc ARTISTIC Changes COPYING README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Wed Apr 10 2013 Xavier Bachelot xav...@bachelot.org 1.010-1
+- Update to 1.010.
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.009.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 781c4ec..06ea4d7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5e08a317206a84f3bf2e9e40a6bb2bb1 MIME-Charset-1.009.2.tar.gz
+f0cc0af0566033dac5c9ecddf26004be MIME-Charset-1.010.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
[Guidelines Change] Changes to the Packaging Guidelines
Another round of changes to the Fedora Packaging Guidelines have been made:
---
A new section on packaging cron jobs has been added:
https://fedoraproject.org/wiki/Packaging/CronFiles
---
The guidelines for migrating from sysv init scripts to systemd were
clarified to state that the migration triggers only need to be kept for
two releases (to cover the range of supported upgrades). For example, if
the package converted to systemd unit files in F18, the migration
support could be dropped in the F21. It is not mandatory that they drop
them, this is just to clarify that they have the option of dropping them
at that point.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript
---
If an update to your package resolves a known security concern (at the
time of the update) with a Common Vulnerabilities and Exposures (CVE)
number assigned to it, you should mention the CVE number in the RPM
changelog entry.
https://fedoraproject.org/wiki/Packaging:Guidelines#Security_Updates_To_Resolve_Known_CVE_Issues
---
The Java Guidelines have been updated with macros that simplify
packaging on F19+, a specific circumstance where JAR files can be now
installed to %{_javadir}/%{name}/ under its usual name, and other
cleanups proposed by the Java SIG.
https://fedoraproject.org/wiki/Packaging:Java
---
The ruby gems guidelines have been updated to make use of the
%gem_install macro that is available in Fedora 19 and beyond.
https://fedoraproject.org/wiki/Packaging:Ruby
---
The packaging guidelines have been clarified to specify that RPM Macro
files stored in /etc/rpm/ are not to be marked %config.
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Additional_RPM_Macros
---
A Bundling exception for nodejs-should to include the forked code
fragment from the Node.js assert module was approved.
---
These guideline changes were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Jóhann B. Guðmundsson, Przemek Klosowski, David Malcolm,
Jamie Nguyen, Vit Ondruch, Michal Srb, 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
