EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 581 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 96 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6 56 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11703/chicken-4.8.0.4-4.el6 38 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6 21 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12025/seamonkey-2.22-1.el6 16 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12064/drupal7-context-3.1-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12040/python-djblets-0.7.23-1.el6,ReviewBoard-1.7.18-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12102/moodle-2.4.7-1.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12156/varnish-2.1.5-5.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12154/mediawiki119-1.19.9-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12171/drupal7-7.24-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing bcfg2-1.3.3-1.el6 Details about builds: bcfg2-1.3.3-1.el6 (FEDORA-EPEL-2013-12176) A configuration management system Update Information: This update includes the new upstream 1.3.3 release and the work to reconcile the upstream specfile with the Fedora specfile. The new specfile includes the 'settings.py' module bugfix (commit 7895f095 from July). ChangeLog: * Thu Nov 7 2013 Sol Jerome sol.jer...@gmail.com 1.3.3-1 - New upstream release * Sun Aug 4 2013 John Morris j...@zultron.com - 1.3.2-2 - Reconcile divergences with upstream specfile, as requested by upstream (equally large changes made upstream version to reconcile with Fedora package) - Python macro cleanups - Accommodations for OpenSUSE - Macros for pre and rc releases - Move BRs to top of file - Rearrange lines to match upstream - Change %descriptions to match upstream - Group: tag tweaks - Slim down file tweaks in %prep section; fix apache config paths - Install report collector init file - Separate server-cherrypy package - Rearrange %files sections - Disable two unit tests that break on all RH distros * Wed Jul 3 2013 John Morris j...@zultron.com - 1.3.2-1 - Update to new upstream version 1.3.2 - Move settings.py into server package (fixes bug reported on bcfg2-dev ML) - Use init scripts from redhat/scripts directory - Fix EL5/EL6 sphinx docs - Require python-inotify instead of gamin-python; recommended by upstream - Remove obsolete bcfg2-py27-auth.patch, accepted upstream - Add %check script - Hack test suite to use local copies of XMLSchema.xsd and xml.xsd - Many new BRs to support %check script - Disable %check script on EL5, where there is no python-mock package - Cleanups to _pre/_rc macros - Mark EL5 relics - Other minor formatting * Mon Apr 8 2013 Fabian Affolter m...@fabian-affolter.ch - 1.3.1-1 - Updated to new upstream version 1.3.1 References: [ 1 ] Bug #1003882 - Bcfg2-server requires bcfg2-web https://bugzilla.redhat.com/show_bug.cgi?id=1003882 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Packaging changes for libev in Rawhide
On Sat, 2013-11-23 at 13:47 -0500, Simo Sorce wrote: On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. Libverto builds against both libevent and libev being a event loop abstraction library, if you make libev and libevent conflict libeverto cannot be built anymore. That's why I said I wouldn't make libev-devel conflict with libevent-devel. I said I would put the event.h header from libev into a libev-libevent-devel subpacke, and only this one would conflict with libevent-devel. I presume libverto uses ev.h from libev and event.h from libevent, right? In that case, it would still do that just fine even after I make the changes. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [pkgdb2] call for testers, bug reports and RFE
On Sat, Nov 23, 2013 at 05:34:19PM -0600, Dennis Gilmore wrote: By using github you are also eliminating the possibility of some people to contribute to your project. I personally won't create an account on github. Just because I believe that open projects should be hosted on open platforms. I'd rather us work out a way to have an open patch submission and review process. I accept patches coming in any forms, email, fpaste, pull-request via github, git request-pull from git itself... If an upstream only accepts patches coming from the github pull-request mechanism then I would agree with you, but the fact that you don't want to create an account on github is not a reason to not contribute on a project. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [pkgdb2] call for testers, bug reports and RFE
Pierre-Yves Chibon wrote: You're forgeting, patch/code reviews, Export patch from git, attach to new issue in the bug tracker; as the maintainer, apply it with git am and push it; where's the problem? possibility to close or refer to a ticket from the git commit, Referring just works in Trac (use '#' + ticket number, it will create a link in Trac's display of the commit message). the possibility to easily follow a project and be informed of its changes The Trac timeline has an RSS feed. Anyway, did you see the link in the footer? The one that says 'pkgdb'? But the pkgdb2 code is not in there, is it? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [pkgdb2] call for testers, bug reports and RFE
On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote: Pierre-Yves Chibon wrote: You're forgeting, patch/code reviews, Export patch from git, attach to new issue in the bug tracker; as the maintainer, apply it with git am and push it; where's the problem? It is possible, but I have to agree that github is more convenient/efficient than the workflow you describe. possibility to close or refer to a ticket from the git commit, Referring just works in Trac (use '#' + ticket number, it will create a link in Trac's display of the commit message). Will it add a notification in the issue tracker? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Fri, Nov 22, 2013 at 04:25:00PM +0100, Kevin Kofler wrote: Richard W.M. Jones wrote: Several packages are using git for patch management. eg: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22 http://pkgs.fedoraproject.org/cgit/qemu.git/tree/ http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16 Ewww, we need packaging guidelines banning this bizarre practice. I can see using git-am if you're backporting upstream patches from upstream git (though patch and thus %patchN is usually good enough for that, too), but for Fedora-specific patches, it's really the wrong tool for the job. Some of these packages have invented home-brewed methods to generate the Patch lines in the spec file, eg: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20 Ewww! Yuck! Could you explain why you don't like this? If you had actually used it, I'm sure you would see it is far more sensible than manually managing and rebasing patches. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [pkgdb2] call for testers, bug reports and RFE
On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote: Pierre-Yves Chibon wrote: You're forgeting, patch/code reviews, Export patch from git, attach to new issue in the bug tracker; as the maintainer, apply it with git am and push it; where's the problem? possibility to close or refer to a ticket from the git commit, Referring just works in Trac (use '#' + ticket number, it will create a link in Trac's display of the commit message). the possibility to easily follow a project and be informed of its changes The Trac timeline has an RSS feed. Anyway, did you see the link in the footer? The one that says 'pkgdb'? But the pkgdb2 code is not in there, is it? And pkgdb2 is in prod? And your conclusions of the fact that this link is there are? Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [pkgdb2] call for testers, bug reports and RFE
On Sun, Nov 24, 2013 at 01:48:53PM +0100, Till Maas wrote: On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote: Pierre-Yves Chibon wrote: You're forgeting, patch/code reviews, Export patch from git, attach to new issue in the bug tracker; as the maintainer, apply it with git am and push it; where's the problem? It is possible, but I have to agree that github is more convenient/efficient than the workflow you describe. possibility to close or refer to a ticket from the git commit, Referring just works in Trac (use '#' + ticket number, it will create a link in Trac's display of the commit message). Will it add a notification in the issue tracker? If the proper git hooks and trac settings are enabled, it is in theory possible. I didn't manage to get it to work on the fedocal project when I looked at it. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20131124 changes
Compose started at Sun Nov 24 08:15:02 UTC 2013 Broken deps for i386 -- [OpenEXR_CTL] OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6 [R-RScaLAPACK] R-RScaLAPACK-0.6.1-13.fc20.i686 requires libatlas.so.3 [bcfg2] bcfg2-server-cherrypy-1.3.3-1.fc21.noarch requires python-cherrypy 0:3.3 [blueman] blueman-1.23-7.fc20.i686 requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.i686 requires gvfs-obexftp [converseen] converseen-0.6.2-2.fc20.i686 requires libMagick++-6.Q16.so.1 [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [dragonegg] dragonegg-3.3-11.fc21.i686 requires gcc = 0:4.8.2-1.fc21 [drawtiming] drawtiming-0.7.1-11.fc20.i686 requires libMagick++-6.Q16.so.1 [evolution-rss] 1:evolution-rss-0.3.94-2.fc21.i686 requires libcamel-1.2.so.46 [fatrat] 1:fatrat-1.2.0-0.14.beta2.fc20.i686 requires liblog4cpp.so.4 [firstaidkit] firstaidkit-plugin-openscap-0.3.2-7.fc20.noarch requires openscap-content = 0:0.7.2 [freefem++] freefem++-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-3.19-3.1.fc18.i686 requires libatlas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libatlas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libatlas.so.3 [ghc-happstack-server] ghc-happstack-server-7.1.0-1.fc21.i686 requires libHSthreads-0.5.0.2-ghc7.6.3.so ghc-happstack-server-7.1.0-1.fc21.i686 requires ghc(threads-0.5.0.2-e4dbb933a3190a4bd85aab395a8b346f) ghc-happstack-server-devel-7.1.0-1.fc21.i686 requires ghc-devel(threads-0.5.0.2-e4dbb933a3190a4bd85aab395a8b346f) [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [httpdtap] httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-debuginfo [initial-setup] initial-setup-0.3.11-1.fc21.noarch requires anaconda-tui = 0:21.7 initial-setup-gui-0.3.11-1.fc21.noarch requires anaconda-gui = 0:21.7 [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kscreen] 1:kscreen-1.0.2.1-1.fc21.i686 requires libkscreen(x86-32) = 1:1.0.2.1 [kyua-cli] kyua-cli-0.5-3.fc19.i686 requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.i686 requires liblutok.so.0 [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [maven-doxia] maven-doxia-module-itext-1.4-4.fc21.noarch requires mvn(com.lowagie:itext:2.1.7) [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [netdisco] netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay) [nifti2dicom] nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires
Re: [pkgdb2] call for testers, bug reports and RFE
On Fri, Nov 22, 2013 at 02:34:28PM +0100, Kevin Kofler wrote: I really don't see what is missing there, apart from missing automation for the one-time creation process. Something I just noticed: - Github allows to reply to ticket notifications via email instead of requiring to change to a browser and to re-login there. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
debuginfo packages available in updates later than regular packages.
Hi,
I wondered what the reason is that debuginfo packages seem to enter the
repos only at the successive push compared to the regular packages,
which ultimately means that debuginfo packages are available in updates
ca 1 day after the regular packages. From abrt-reported bugs where
people generate the backtraces locally, it occasionally happens that
they send incomplete backtraces due to mismatching debugsymbols, and it
would certainly help increasing the quality of backtraces if such cases
could be avoided (btw, can this also happen on the retrace server?).
A nice solution to ensure consistency could be to have each debuginfo
package require the exact version of the base package installed. Since
the debuginfo package however cannot know which base (sub)package it
should depend on, I wonder whether it could work if the package and all
subpackages should provide something like: Provides:
debuginfo-requirement(%{name}) = %{version}-%{release}?
Thanks,
Sandro
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: debuginfo packages available in updates later than regular packages.
On Sun, 2013-11-24 at 16:50 +0100, Sandro Mani wrote: From abrt-reported bugs where people generate the backtraces locally, it occasionally happens that they send incomplete backtraces due to mismatching debugsymbols, and it would certainly help increasing the quality of backtraces if such cases could be avoided This does suck, but the bigger problem is that debuginfo packages are not updated at all - not ever - unless you either a) use yum instead of PackageKit b) manually enable the updates-debug repository So requiring the exact version of the base package will only work if that gets fixed first. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: debuginfo packages available in updates later than regular packages.
On 24.11.2013 17:55, Michael Catanzaro wrote: On Sun, 2013-11-24 at 16:50 +0100, Sandro Mani wrote: From abrt-reported bugs where people generate the backtraces locally, it occasionally happens that they send incomplete backtraces due to mismatching debugsymbols, and it would certainly help increasing the quality of backtraces if such cases could be avoided This does suck, but the bigger problem is that debuginfo packages are not updated at all - not ever - unless you either a) use yum instead of PackageKit b) manually enable the updates-debug repository So requiring the exact version of the base package will only work if that gets fixed first. Oh, I never noticed this! I take the reason the debuginfo packages do not live in the normal repos is that one wants to reduce the repodata/filelist size? Could the current situation be improved by an approach similar to: - Move the debuginfo repo definitions to separate files - Have a package fedora-release-debug (or similar) install the repo file in /etc/yum.repos.d. The repos would be enabled by default when installed. - Have all debuginfo packages depend on fedora-release-debug - (ugly) Have debuginfo-install install the repo file before proceeding as before. ? Thanks, Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: debuginfo packages available in updates later than regular packages.
On 11/24/2013 09:13 AM, Sandro Mani wrote: Oh, I never noticed this! I take the reason the debuginfo packages do not live in the normal repos is that one wants to reduce the repodata/filelist size? Could the current situation be improved by an approach similar to: - Move the debuginfo repo definitions to separate files - Have a package fedora-release-debug (or similar) install the repo file in /etc/yum.repos.d. The repos would be enabled by default when installed. - Have all debuginfo packages depend on fedora-release-debug - (ugly) Have debuginfo-install install the repo file before proceeding as before. ? debuginfo-install does install yum-plugin-auto-update-debug-info, which automatically enables $REPO-debuginfo for each $REPO you have enabled. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: debuginfo packages available in updates later than regular packages.
On 11/24/2013 10:51 AM, Josh Stone wrote: On 11/24/2013 09:13 AM, Sandro Mani wrote: Oh, I never noticed this! I take the reason the debuginfo packages do not live in the normal repos is that one wants to reduce the repodata/filelist size? Could the current situation be improved by an approach similar to: - Move the debuginfo repo definitions to separate files - Have a package fedora-release-debug (or similar) install the repo file in /etc/yum.repos.d. The repos would be enabled by default when installed. - Have all debuginfo packages depend on fedora-release-debug - (ugly) Have debuginfo-install install the repo file before proceeding as before. ? debuginfo-install does install yum-plugin-auto-update-debug-info, which automatically enables $REPO-debuginfo for each $REPO you have enabled. ... and now I see you're trying to solve this for !yum, e.g. PackageKit. Sorry for the noise... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: debuginfo packages available in updates later than regular packages.
On Sun, 24 Nov 2013 16:50:51 +0100, Sandro Mani wrote: Hi, I wondered what the reason is that debuginfo packages seem to enter the repos only at the successive push compared to the regular packages, which ultimately means that debuginfo packages are available in updates ca 1 day after the regular packages. Where did you observe this? On a mirror or on the Fedora Project download server? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: debuginfo packages available in updates later than regular packages.
On 24.11.2013 21:52, Michael Schwendt wrote: On Sun, 24 Nov 2013 16:50:51 +0100, Sandro Mani wrote: Hi, I wondered what the reason is that debuginfo packages seem to enter the repos only at the successive push compared to the regular packages, which ultimately means that debuginfo packages are available in updates ca 1 day after the regular packages. Where did you observe this? On a mirror or on the Fedora Project download server? I am running rawhide and it always happens that updates come one day, and the corresponding debuginfo packages the next day. Actually I'm not sure if this is the case also in stable releases, but I though that was why the debuginfo symbols in various abrt bugs were mismatching. However, I didn't realize that the debuginfo packages were only updated via yum and not via PackageKit (as Michael mentioned before in this thread), so that is probably the more likely cause. As far as the mirror is concerned: just using the mirror which yum picks for me, so I guess the answer is: pretty much any mirror. Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Proven packager help requested: Rebuild python-tag
Hi, Python-tag is broken in F19/20/rawhide. It failed to build during the boost 1.54 rebuild for some reason and is therefore in FTBFS for rawhide. I checked out the SCM and rebuilt it in mock, both for F20 and rawhide, quite successfully. No fixes were needed. Could a proven packager please bump the spec and rebuild the package on Koji? It's required by sonata and a few other apps and currently breaks the upgrade path as the bug reports. https://bugzilla.redhat.com/show_bug.cgi?id=1016174 https://bugzilla.redhat.com/show_bug.cgi?id=991882 -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Planned Outage: Server reboots - 2013-11-25 22:00 UTC
Planned Outage: Server reboots - 2013-11-25 22:00 UTC There will be an outage starting at 2013-11-25 22:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2013-11-25 22:00 UTC' Reason for outage: We have another few servers to reboot to bring up to RHEL 6.5 before we go into freeze for Fedora 20 release. This outage should be short and particular services should not be down long during the window. Affected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4127 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Workstation Desktop Environment Concept
Hello list, I'm a computer science major interested in Linux software engineering and just beginning to learn programming so I'm use-case #1 and #2. Currently out of all my peers I'm the only one using Linux as far as I know. Most students and developers even those working on Linux oriented projects either use Mac OS out of personal preference or Windows because it's the default in most organizations and institutions of learning. If users cannot naturally and effortlessly migrate to the Fedora Workstation from Mac or Windows and find a normal environment they're used to, the product will fail. The problem is that the vast majority of Linux desktops don't meet the design standards set by the established commercial leaders. Currently my favorite desktop environment is Gnome Shell and my second favorite is Mate. Gnome Shell is almost there, nearly meets the modern Mac OS level of quality end-users expect, and has an excellent technical foundation, it just needs some simple layout modifications and changes to menu behavior. I've put together a *.pdf document outlining my suggestions and ideas outlining my suggestions in this regard, see the attached link. Hopefully this can be useful to the working group and a provide a starting point for a discussion about the default graphical user interface for the Workstation product. Document Link: http://goo.gl/0IzNgK *this is a Google Documents link Thank you for your time and attention! Regards, Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Best practice for multiple version/OS boot?
Hi, IIRC fedora-review suggested to test packages on all sup- ported Fedora releases. So, with a larger hard disk, I want to install Fedora 19, 20 (soon) and Rawhide and throw in (recent) Debian and Ubuntu as well. As my notebook doesn't support VMs, I'm interested in best practices for partition- ing and multi-boot setups. Currently I use a partition for /boot and another for an en- crypted LVM, so I only need to worry not to put private data in /boot, and I would like to keep such flexibility. I suppose I need to create a /boot partition for each ver- sion/OS. I have had different Fedora versions share the same encrypted LVM without problems; I assume Debian and Ubuntu will do so as well, but I will keep some free space and partitions just in case. More contested seems to be the multi-boot setup. https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a myriad of opinions on how it should be set up; http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide suggests chainloader, and http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html recommends configfile. Of course there is also GRUB's OS prober. So what are Fedora developers /actually/ using? Creating a separate GRUB partition and chainloader/configfile? Running OS prober in the main OS after each installation/ kernel update? Something else? How often do the setups al- low one to shoot oneself in the foot, or are they (more or less) foolproof? Thanks in advance, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best practice for multiple version/OS boot?
On Mon, 2013-11-25 at 06:33 +, Tim Landscheidt wrote: More contested seems to be the multi-boot setup. https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a myriad of opinions on how it should be set up; http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide suggests chainloader, and http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html recommends configfile. Of course there is also GRUB's OS prober. So what are Fedora developers /actually/ using? Creating a I have noticed a fairly strong correlation here: the more you know about how booting works, the more strongly you are inclined to avoid multiboot as far as possible... There really aren't any perfect options. The upstream advice of using 'configfile' as a sort of chainload-lite is probably the best approach for grub2-booted OSes, overall. jlaska's page is outdated; upstream grub2 explicitly discourages doing full chainloading. I'll slap a 'this is obsolete' header on that page, I don't think James would mind. You'll note, though, that the _design_ of both approaches is fairly similar: have a 'master bootloader' not owned by any OS, let each OS own its own boot configuration, and have the master bootloader read each OS's own bootloader configuration when booting that OS. It's just that the old 'chainloading' method actually loaded each OS's bootloader, while the 'configfile' method has the master bootloader read in the config files from the slaves rather than loading a whole bootloader that they control. Personally, I use VMs. separate GRUB partition and chainloader/configfile? Running OS prober in the main OS after each installation/ kernel update? Something else? How often do the setups al- low one to shoot oneself in the foot, or are they (more or less) foolproof? No, none of them are foolproof. I'd expect either the configfile or 'let one OS be in charge and run mkconfig from that OS every time you update any other OS' approach would mostly work most of the time. The configfile approach is less of a pain and, because it involves less manual work, less subject to snafus. If I really had to multiboot, I'd probably go with the configfile approach. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2013-11-25 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-11-25 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! We're into Final validation grind now, so I expect we'll mostly be discussing that. Andre has a topic for updating the validation matrices. I had a look at the blocker list and it doesn't look like we could vote on more than one or two, so it doesn't seem like we need to do a blocker review meeting as well - it can wait till Wednesday. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20131125 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Matrix revisions 3. Fedora 20 Final status 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best practice for multiple version/OS boot?
On 11/25/2013 07:58 AM, Adam Williamson wrote: On Mon, 2013-11-25 at 06:33 +, Tim Landscheidt wrote: More contested seems to be the multi-boot setup. https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a myriad of opinions on how it should be set up; http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide suggests chainloader, and http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html recommends configfile. Of course there is also GRUB's OS prober. So what are Fedora developers /actually/ using? Depends on what you want to test. To check for packaging issues I am just using mock. In cases I really want to/need to test a package, I am using a chainloaded multiboot configuration on an eldery/written-off machine (a dedicated testing machine). Creating a I have noticed a fairly strong correlation here: the more you know about how booting works, the more strongly you are inclined to avoid multiboot as far as possible... There really aren't any perfect options. The upstream advice of using 'configfile' as a sort of chainload-lite is probably the best approach for grub2-booted OSes, overall. jlaska's page is outdated; upstream grub2 explicitly discourages doing full chainloading. I'll slap a 'this is obsolete' header on that page, I don't think James would mind. You'll note, though, that the _design_ of both approaches is fairly similar: have a 'master bootloader' not owned by any OS, let each OS own its own boot configuration, and have the master bootloader read each OS's own bootloader configuration when booting that OS. It's just that the old 'chainloading' method actually loaded each OS's bootloader, while the 'configfile' method has the master bootloader read in the config files from the slaves rather than loading a whole bootloader that they control. Personally, I use VMs. separate GRUB partition and chainloader/configfile? That's what I am using. However, Fedora's installer and grub2 can make this a challenge (It once was easy, but these days it's /self censored. Running OS prober in the main OS after each installation/ kernel update? Something else? How often do the setups al- low one to shoot oneself in the foot, or are they (more or less) foolproof? No, none of them are foolproof. I'd expect either the configfile or 'let one OS be in charge and run mkconfig from that OS every time you update any other OS' approach would mostly work most of the time. I can imagine the works to some extend within the Red Hat family of Linuxes, but is almost non-workable when installing several different Linux distros or different OSes in parallel. The configfile approach is less of a pain and, because it involves less manual work, less subject to snafus. If I really had to multiboot, I'd probably go with the configfile approach. The only approach I found working fairly reliable is using a traditional, strictly separated, cascade of bootloaders with strictly separated physical partitions. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Server-Starter/f20] Upstream update.
Summary of changes: 0eb2cfe... Upstream update. (*) (*) 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
File CGI-Application-Plugin-DBH-4.03.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-CGI-Application-Plugin-DBH: 8ac1f86a239448c5a581e237f0aa29db CGI-Application-Plugin-DBH-4.03.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-CGI-Application-Plugin-DBH] Update to 4.03
commit 9cc5367317e515acb0e5b8ca1e5004ea5f1711fb
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Nov 24 12:24:33 2013 +0100
Update to 4.03
.gitignore |1 +
perl-CGI-Application-Plugin-DBH.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6ce3243..537a680 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
CGI-Application-Plugin-DBH-4.00.tar.gz
/CGI-Application-Plugin-DBH-4.01.tar.gz
/CGI-Application-Plugin-DBH-4.02.tar.gz
+/CGI-Application-Plugin-DBH-4.03.tar.gz
diff --git a/perl-CGI-Application-Plugin-DBH.spec
b/perl-CGI-Application-Plugin-DBH.spec
index bf3b604..afcb7ad 100644
--- a/perl-CGI-Application-Plugin-DBH.spec
+++ b/perl-CGI-Application-Plugin-DBH.spec
@@ -1,5 +1,5 @@
Name: perl-CGI-Application-Plugin-DBH
-Version:4.02
+Version:4.03
Release:1%{?dist}
Summary:Easy DBI access from CGI::Application
License:GPL+ or Artistic
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Nov 24 2013 Emmanuel Seyman emman...@seyman.fr - 4.03-1
+- Update to 4.03
+
* Sun Nov 17 2013 Emmanuel Seyman emman...@seyman.fr - 4.02-1
- Update to 4.02
diff --git a/sources b/sources
index 46c8e45..deaf38f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-926654c530b83869359145a0a2eb3016 CGI-Application-Plugin-DBH-4.02.tar.gz
+8ac1f86a239448c5a581e237f0aa29db CGI-Application-Plugin-DBH-4.03.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Config-Tiny-2.20.tgz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Config-Tiny: d239ea56157fcd61ac796fc13d585dc3 Config-Tiny-2.20.tgz -- 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 Future-0.20.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Future: 9e76cf75a297ffc4136db1d366fc9e06 Future-0.20.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-Config-Tiny] Update to 2.20
commit 85f94aca1b671eea590ac82ed8abf1e07abf81ce
Author: Paul Howarth p...@city-fan.org
Date: Sun Nov 24 11:29:55 2013 +
Update to 2.20
- New upstream release 2.20
- Relax pre-req version requirements
perl-Config-Tiny.spec | 10 +++---
sources |2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/perl-Config-Tiny.spec b/perl-Config-Tiny.spec
index b68401b..b13ce04 100644
--- a/perl-Config-Tiny.spec
+++ b/perl-Config-Tiny.spec
@@ -1,5 +1,5 @@
Name: perl-Config-Tiny
-Version: 2.19
+Version: 2.20
Release: 1%{?dist}
Summary: Perl module for reading and writing .ini style configuration
files
Group: Development/Libraries
@@ -12,8 +12,8 @@ BuildRequires:perl(ExtUtils::MakeMaker)
# Module Runtime
BuildRequires: perl(strict)
# Test Suite
-BuildRequires: perl(File::Spec) = 3.40
-BuildRequires: perl(File::Temp) = 0.19
+BuildRequires: perl(File::Spec) = 3.30
+BuildRequires: perl(File::Temp) = 0.22
BuildRequires: perl(Test::More) = 0.47
BuildRequires: perl(UNIVERSAL)
BuildRequires: perl(utf8)
@@ -54,6 +54,10 @@ make test TEST_FILES=xt/*.t AUTOMATED_TESTING=1
%{_mandir}/man3/Config::Tiny.3pm*
%changelog
+* Sun Nov 24 2013 Paul Howarth p...@city-fan.org - 2.20-1
+- Update to 2.20
+ - Relax pre-req version requirements
+
* Sun Sep 15 2013 Paul Howarth p...@city-fan.org - 2.19-1
- Update to 2.19
- Remove obsolete and wrong version # from Makefile.PL (CPAN RT#88658)
diff --git a/sources b/sources
index b19df6d..d388f48 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4f212792cb988a39872a5413b290b6a8 Config-Tiny-2.19.tgz
+d239ea56157fcd61ac796fc13d585dc3 Config-Tiny-2.20.tgz
--
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-Future] Update to 0.20
commit 073d0438143439f1f98fa810ce94bb9b2a2203a1
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Nov 24 12:33:56 2013 +0100
Update to 0.20
.gitignore |1 +
perl-Future.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a56e5b2..9411b72 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Future-0.17.tar.gz
/Future-0.18.tar.gz
/Future-0.19.tar.gz
+/Future-0.20.tar.gz
diff --git a/perl-Future.spec b/perl-Future.spec
index 9762ab6..a94154b 100644
--- a/perl-Future.spec
+++ b/perl-Future.spec
@@ -1,5 +1,5 @@
Name: perl-Future
-Version:0.19
+Version:0.20
Release:1%{?dist}
Summary:Perl object system to represent an operation awaiting
completion
License:GPL+ or Artistic
@@ -46,6 +46,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Sun Nov 24 2013 Emmanuel Seyman emman...@seyman.fr - 0.20-1
+- Update to 0.20
+
* Sun Sep 29 2013 Emmanuel Seyman emman...@seyman.fr - 0.19-1
- Update to 0.19
diff --git a/sources b/sources
index 40278d8..8b80f9d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-424aa5bf6472bf4e3ab01a20c92763c6 Future-0.19.tar.gz
+9e76cf75a297ffc4136db1d366fc9e06 Future-0.20.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mojolicious-4.58.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Mojolicious: bcd73285601713e0a26949826c6c2d2b Mojolicious-4.58.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-Config-Tiny] Created tag perl-Config-Tiny-2.20-1.fc21
The lightweight tag 'perl-Config-Tiny-2.20-1.fc21' was created pointing to: 85f94ac... Update to 2.20 -- 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-Mojolicious] Update to 4.58
commit d43a313902176b0222ec98886df44878a627bc37
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Nov 24 12:43:07 2013 +0100
Update to 4.58
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4be9a33..eece3a0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -108,3 +108,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-4.53.tar.gz
/Mojolicious-4.56.tar.gz
/Mojolicious-4.57.tar.gz
+/Mojolicious-4.58.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index b33d278..179c66c 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:4.57
+Version:4.58
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -60,6 +60,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Nov 24 2013 Emmanuel Seyman emman...@seyman.fr - 4.58-1
+- Update to 4.58
+
* Sun Nov 17 2013 Emmanuel Seyman emman...@seyman.fr - 4.57-1
- Update to 4.57
diff --git a/sources b/sources
index fe86dac..3ad5e31 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9ed3e4fbee5ad7fa2805d2d27cafe7d9 Mojolicious-4.57.tar.gz
+bcd73285601713e0a26949826c6c2d2b Mojolicious-4.58.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-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) 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-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) 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
[slic3r] Slic3r 1.0.0RC1
commit 00db753a0e6458b2b3e7689fd8e1cc138591dea2
Author: Miro Hrončok m...@hroncok.cz
Date: Sun Nov 24 17:32:54 2013 +0100
Slic3r 1.0.0RC1
slic3r-buildpl.patch | 25 ++
slic3r-datadir.patch | 15
slic3r-english-locale.patch | 35
slic3r-load-config-fix.patch | 39 --
slic3r-nowarn-datadir.patch | 17 +
slic3r.spec | 74 -
6 files changed, 92 insertions(+), 113 deletions(-)
---
diff --git a/slic3r-buildpl.patch b/slic3r-buildpl.patch
new file mode 100644
index 000..0e7c51d
--- /dev/null
+++ b/slic3r-buildpl.patch
@@ -0,0 +1,25 @@
+diff --git a/Build.PL b/Build.PL
+index b501025..1abe9fe 100644
+--- a/Build.PL
b/Build.PL
+@@ -9,7 +9,7 @@ use File::Spec;
+ my %prereqs = qw(
+ Boost::Geometry::Utils 0.15
+ Encode::Locale 0
+-ExtUtils::MakeMaker 6.80
++ExtUtils::MakeMaker 6.70
+ File::Basename 0
+ File::Spec 0
+ Getopt::Long0
+@@ -142,7 +142,10 @@ if (@missing_prereqs) {
+ exit 1;
+ } elsif (!$gui) {
+ eval use App::Prove; 1 or die Failed to load App::Prove;
+-my $res = App::Prove-new-run ? 0 : 1;
++
++my $app = App::Prove-new;
++$app-process_args('-Ixs/blib/lib','-Ixs/blib/arch');
++my $res = $app-run ? 0 : 1;
+ if ($res == 0) {
+ print If you also want to use the GUI you can now run `perl Build.PL
--gui` to install the required modules.\n;
+ } else {
diff --git a/slic3r-nowarn-datadir.patch b/slic3r-nowarn-datadir.patch
new file mode 100644
index 000..a265398
--- /dev/null
+++ b/slic3r-nowarn-datadir.patch
@@ -0,0 +1,17 @@
+diff --git a/lib/Slic3r.pm b/lib/Slic3r.pm
+index d317f2e..3ff1f6d 100644
+--- a/lib/Slic3r.pm
b/lib/Slic3r.pm
+@@ -25,11 +25,7 @@ BEGIN {
+ $have_threads = 0 if $Moo::VERSION == 1.003000;
+ }
+
+-warn Running Slic3r under Perl = 5.16 is not supported nor recommended\n
+-if $^V = v5.16;
+-
+-use FindBin;
+-our $var = $FindBin::Bin/var;
++our $var = /usr/share/slic3r;
+
+ use Encode;
+ use Encode::Locale;
diff --git a/slic3r.spec b/slic3r.spec
index 4b3d811..a8bcf98 100644
--- a/slic3r.spec
+++ b/slic3r.spec
@@ -1,40 +1,43 @@
Name: slic3r
-Version:0.9.10b
-Release:5%{?dist}
+Version:1.0.0
+%global rcrcRC1
+%global verrc %{version}%{rcrc}
+Release:0.1.%{rcrc}%{?dist}
Summary:G-code generator for 3D printers (RepRap, Makerbot, Ultimaker
etc.)
License:AGPLv3 and CC-BY
# Images are CC-BY, code is AGPLv3
Group: Applications/Engineering
URL:http://slic3r.org/
-%global commit d0eac88ff9586b17dcc1766874f69dbd7e8c534f
-%global shortcommit %(c=%{commit}; echo ${c:0:7})
-Source0:
https://github.com/alexrj/Slic3r/archive/%{commit}/%{name}-%{version}-%{shortcommit}.tar.gz
+Source0:https://github.com/alexrj/Slic3r/archive/%{verrc}.tar.gz
-# Use /usr/share to store icons
-Patch0: %{name}-datadir.patch
+# Modify Build.PL so we are able to build this on Fedora
+Patch0: %{name}-buildpl.patch
-# Use English decimal separator for numbers
-# Reasons are a bit complicated and are described in the patch
-Patch1: %{name}-english-locale.patch
-
-# Fix crash when loading a config file
-Patch2: %{name}-load-config-fix.patch
+# Don't warn for Perl = 5.16
+# Use /usr/share/slic3r as datadir
+# Those two are located at the same place at the code, so the patch is merged
+Patch1: %{name}-nowarn-datadir.patch
Source1:%{name}.desktop
-BuildArch: noarch
-BuildRequires: perl(Boost::Geometry::Utils) = 0.12
+BuildRequires: perl(Boost::Geometry::Utils) = 0.15
BuildRequires: perl(Class::XSAccessor)
BuildRequires: perl(Encode::Locale)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::Typemaps::Default) = 1.03
+BuildRequires: perl(ExtUtils::Typemap)
+BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Spec)
+BuildRequires: perl(Getopt::Long)
BuildRequires: perl(Growl::GNTP)
BuildRequires: perl(IO::Scalar)
BuildRequires: perl(List::Util)
BuildRequires: perl(Math::Clipper) = 1.22
BuildRequires: perl(Math::ConvexHull::MonotoneChain)
BuildRequires: perl(Math::ConvexHull) = 1.0.4
-BuildRequires: perl(Math::Geometry::Voronoi)
-BuildRequires: perl(Math::PlanePath)
+BuildRequires: perl(Math::Geometry::Voronoi) = 1.3
+BuildRequires: perl(Math::PlanePath) = 53
BuildRequires: perl(Module::Build)
+BuildRequires: perl(Module::Build::WithXSpp)
%if 0%{?fedora} 19
BuildRequires: perl(Moo) = 1.003001
%else
@@ -42,8 +45,11 @@ BuildRequires: perl(Moo)
%endif
BuildRequires: perl(parent)
BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Storable)
BuildRequires: perl(SVG)
+BuildRequires: perl(Test::Harness)
BuildRequires:
File 1.0.0RC1.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for slic3r: f720fbbaeb15c3048db880dc85955927 1.0.0RC1.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
[slic3r] Sources for previous commit
commit c38570f527b95870acd916070779fd6c57eb59d6 Author: Miro Hrončok m...@hroncok.cz Date: Sun Nov 24 17:38:42 2013 +0100 Sources for previous commit .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index ca72b15..fef49c5 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ /slic3r-0.9.9-01e86c2.tar.gz /slic3r-0.9.10b-f13c611.tar.gz /slic3r-0.9.10b-d0eac88.tar.gz +/1.0.0RC1.tar.gz diff --git a/sources b/sources index f7f1094..adbc0ce 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -5b0ae2b74a93d643f0945e152457b605 slic3r-0.9.10b-d0eac88.tar.gz +f720fbbaeb15c3048db880dc85955927 1.0.0RC1.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 1032056] Slic3r 1.0.0RC1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1032056 --- Comment #5 from Miro Hrončok mhron...@redhat.com --- https://fedorahosted.org/fpc/ticket/368 -- 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=dQ2lkrH85Qa=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 1033994] New: amavisd-new missing dependency on clamav-server-sysvinit
https://bugzilla.redhat.com/show_bug.cgi?id=1033994 Bug ID: 1033994 Summary: amavisd-new missing dependency on clamav-server-sysvinit Product: Fedora Version: 19 Component: amavisd-new Assignee: st...@silug.org Reporter: brad+red...@bradrubenstein.com QA Contact: extras...@fedoraproject.org CC: kana...@kanarip.com, perl-devel@lists.fedoraproject.org, st...@silug.org Amavisd-new installs the file /etc/init.d/clamd.amavisd which references the file /usr/share/clamav/clamd-wrapper which is supplied by clamav-server-sysvinit. This prevents amavisd-new from starting upon installation. Additional Notes: Related to bug 863303. (reported against F17, still an issue in F19) Related to https://issues.kolab.org/show_bug.cgi?id=2581 -- 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=2BbktLZttla=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 SOAP-Lite-1.08.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-SOAP-Lite: d5de2cd5a4415590cfc96d7a41fa811e SOAP-Lite-1.08.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-SOAP-Lite] 1.08 bump, no code changes
commit 8ed6d9aa697f0603f13d8e2a86b8e010449ba4ec
Author: Petr Šabata con...@redhat.com
Date: Mon Nov 25 14:47:08 2013 +0900
1.08 bump, no code changes
.gitignore |1 +
perl-SOAP-Lite.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c3b5957..d04191a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ SOAP-Lite-0.710.10.tar.gz
/SOAP-Lite-0.715.tar.gz
/SOAP-Lite-0.716.tar.gz
/SOAP-Lite-1.06.tar.gz
+/SOAP-Lite-1.08.tar.gz
diff --git a/perl-SOAP-Lite.spec b/perl-SOAP-Lite.spec
index e0e0d13..622cc47 100644
--- a/perl-SOAP-Lite.spec
+++ b/perl-SOAP-Lite.spec
@@ -1,6 +1,6 @@
Name: perl-SOAP-Lite
-Version:1.06
-Release:3%{?dist}
+Version:1.08
+Release:1%{?dist}
Summary:Client and server side SOAP implementation
License:GPL+ or Artistic
Group: Development/Libraries
@@ -79,6 +79,9 @@ make test
%{_mandir}/man1/*
%changelog
+* Mon Nov 25 2013 Petr Šabata con...@redhat.com - 1.08-1
+- 1.08 bump, no code changes
+
* Thu Nov 14 2013 Petr Šabata con...@redhat.com - 1.06-3
- Properly obsolete/provide SOAP-Transport-TCP
diff --git a/sources b/sources
index 3921133..593658f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-29eea1515fa397fdd6723ae73ace11bf SOAP-Lite-1.06.tar.gz
+d5de2cd5a4415590cfc96d7a41fa811e SOAP-Lite-1.08.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 1030917] perl-SOAP-Lite-1.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1030917 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-SOAP-Lite-1.08-1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-11-25 01:00:59 -- 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=5Iiqwwqp3na=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
[perl-DBD-ODBC/f20] (2 commits) ...Modified sources.
Summary of changes: 043e5e6... Initial import (#1028521). (*) 8d529fb... Modified sources. (*) (*) 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
