EPEL epel beta report: 20140317 changes
Compose started at Mon Mar 17 08:15:02 UTC 2014 Broken deps for x86_64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires mod_python chemtool-1.6.14-1.el7.x86_64 requires openbabel chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine koji-vm-1.8.0-2.el7.noarch requires python-virtinst lnst-2-1.el7.noarch requires python-pyroute2 lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nagios-plugins-nrpe-2.15-1.el7.x86_64 requires nagios-plugins nf3d-0.8-2.el7.noarch requires python-visual openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg php-phpseclib-crypt-aes-0.3.5-2.el7.noarch requires php-pear(phpseclib.sourceforge.net/Crypt_Rijndael) = 0:0.3.0 plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils python-tgcaptcha2-0.2.0-5.el7.noarch requires python-fedora-turbogears qt4pas-2.5-3.el7.x86_64 requires fpc-src rabbitvcs-core-0.16-1.el7.noarch requires python-dulwich rabbitvcs-core-0.16-1.el7.noarch requires pysvn rabbitvcs-nautilus-0.16-1.el7.x86_64 requires nautilus-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunarx-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunar rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 rubygem-mizuho-0.9.20-2.el7.noarch requires rubygem(sqlite3) rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(simplecov-html) = 0:0.7.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(multi_json) = 0:1.0 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) 0:1 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) = 0:0.8 spectrwm-2.5.0-1.el7.x86_64 requires xlockmore spectrwm-2.5.0-1.el7.x86_64 requires dmenu Broken deps for ppc64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires mod_python chemtool-1.6.14-1.el7.ppc64 requires openbabel chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc cloud-init-0.7.2-8.el7.noarch requires python-requests cloud-init-0.7.2-8.el7.noarch requires dmidecode docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma fedmsg-0.7.6-2.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine
EPEL 7 i686 libraries
Hello, maybe I missed this, but I would like to know what's the status of EPEL 7 32 bit (i686) support. I see that in Koji all libraries are x86_64 or ppc64. Shouldn't we have i686 libraries as well, much like in Fedora? Also considering that the system itself has many 32 bit libraries: https://fedoraproject.org/wiki/EPEL/epel7 Thanks regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Java headless bugs
On Sun, Mar 16, 2014 at 8:19 PM, Richard Fearn richardfe...@gmail.com wrote: eclipse-findbugs - https://bugzilla.redhat.com/show_bug.cgi?id=1068044 - Eclipse plugin; continue to depend on java FWIW I'd say the whole java* dependency is pretty much superfluous here, eclipse-jdt should be enough. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf-0.4.18
Hello, we are proudly releasing 0.4.18 today: http://dnf.baseurl.org/2014/03/17/dnf-0-4-18-released/ http://akozumpl.github.io/dnf/release_notes.html#id29 F20 build: https://admin.fedoraproject.org/updates/dnf-0.4.18-1.fc20 Also note that the name disputes have been settled: http://dnf.baseurl.org/2014/03/12/on-the-name/ Cheers, Ales -- 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: [Owfs-developers] Build failure on fedora rawhide (21)
On 03/15/2014 03:49 PM, Tomasz Torcz wrote:
Hi,
My package failed to build on rawhide. Upstream comments point
to Swig as guilty party. Was there any un-announced Swig change?
Hi,
Swig was updated to the version 2.0.12 at Fedora 21.
However, the code which failed was provided by upstream of owfs and it
is part of source tarball.
The upstream used swig for generating of the code. You should asked them
which version
of swig they used.
BTW, new major version 3.0.0 of swig was released. New release is
focused primarily on C++ improvements.
Using the latest Swig for code generating could solve the problem, but I
am not sure with it.
Regards,
Jitka Plesnikova
- Forwarded message from Tomasz Torcz to...@pipebreaker.pl -
Date: Thu, 6 Mar 2014 14:32:31 +0100
From: Tomasz Torcz to...@pipebreaker.pl
To: owfs-develop...@lists.sourceforge.net
Subject: [Owfs-developers] Build failure on fedora rawhide (21)
Hi,
While building latest version for fedora rawhide, I've encountered a build
failure.
I do not see anything obvious in the code, so I was unable to fix it by
myself. Fedora tend to ship quite new build chain, so it is entirely
possible that new GCC started to throw error where older GCC accepted code.
The GCC in question is gcc-4.8.2-14.fc21.x86_64
The first error:
In file included from ../../owlib/src/include/ow.h:220:0,
from ow_wrap.c:2949:
../../owlib/src/include/ow_debug.h:41:35: error: expected '=', ',', ';',
'asm' or '__attribute__' before '{' token
static inline int return_ok(void) { return 0; }
Full buildlog:
http://kojipkgs.fedoraproject.org//work/tasks/2255/6562255/build.log
Build.log contains gcc invocations, of course. Which may be a source
of problem, too. Fedora rawhide started recently to add
Werror=format-security
and similar hardening options to CFLAGS.
- End forwarded message -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2014-03-18)
WG meeting will be at 13:00 UTC, 14:00 Central Europe, 9:00 Boston, 6:00 San Francisco, 22:00 Tokyo in #fedora-meeting on Freenode. == Topic == * work more on Open Questions: https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29 See you, Marcela -- 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: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2014 01:13 AM, Kevin Kofler wrote: Stephen Gallagher wrote: The primary problem is that we need to be able to address the potential for packages that *aren't* part of the default install to handle differing config based on the Product upon which it is being installed. For example, let's say that theoretically, Fedora Cloud doesn't install very many packages at all. Normal operation would be to pick and choose other packages from the repos later. We need a mechanism that says if I yum install this package onto Fedora Cloud, I should get a default that's sensible for Fedora Cloud, which might or might not be the same as is sensible for other Products. If you know about the package at GA release time, you could still drop the required config file from the live kickstart. That really wouldn't scale. While I hope the set of divergent packages would be very small, it could still in theory mean a lot of additional wasted space if we included every possible divergent config on the system. Moreover, we need to account for the possibility that any package could spontaneously decide that it should have a different default for one Product than another. We need to be able to adapt to that post-GA. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMm5l8ACgkQeiVVYja6o6P3xQCfSx2QCLEBI0l3rRPFzq1XzYAo L6kAn2Ko+o/QlLXI2/vLZAqIAzCaSyOV =NZMz -END PGP SIGNATURE- -- 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: F21 Self Contained Change: Security Policy In The Installer
On Sun, 2014-03-16 at 22:05 -0400, Bill Nottingham wrote: Vratislav Podzimek (vpodz...@redhat.com) said: Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 So, having watched the video, I think I'm pretty clearly against this from a interactive install standpoint, given what is presented. Here's what I see in that video. I'm not a UI/UX professional, so additional review from someone more along those lines would be great (and info on where I'm barking up the wrong tree - can always learn more.) INTEGRATION === Current toplevel is localization, software, and system. 'Security policy' doesn't fit as a toplevel along with that. If we wanted it as an additional item under 'System', des that mean it can't be done as an addon? I can be part of the System category. It hasn't been from the beginning because there was no System category when this project was started. INITIAL SCREEN == - You've got three active items: 1 - 'Change content' (button) 2 - 'Apply security policy' (toggle) 3 - 'Select profile' (button) If someone isn't familar with the specific terminology in use here, you're using three separate nouns here which all can be similar in meaning (policy, profile, content). If the user isn't familiar with all three terms, all three of these items could be seen as doing the same thing! That's not good. If I were to whiteboard some proposed improvements of the screen you have (note: not saying this is the way to go vs. a full rework), it would be something like: Apply a security policy [ YES | NO ] (1) Policy 1 | (if we want details on the selected description 1 | policy, they go here on selection) | Policy 2 | description 2 | ... | - [ Choose another policy source ... ] (2) (1) If 'no' is selected, rest of screen is inactive (2) If this is still desired There would be no 'select profile' button - it would be selected by just selecting the profile, similar to other anaconda actions. URL SCREEN == - Why is 'Use SCAP Security Guide' (presumably a predefined URL) a selection, if it is not the normal source of the choices in the initial screen? If we're shipping with predefined content sources, it should be reflected on the initial screen; if we're not using that predefined data, I'm not sure why it's an option here. Choosing SSG doesn't result in using a predefined URL, it results in using content that is a part of the compose, setting various parameters. - 'Enter data stream content or archive URL here'. Again, too jargon-y. Is there a reason 'Enter URL to security policy' isn't good enough? (Or whatever terminology is used in the software spoke.) Good point. However, we would need at least a tooltip on which security policy formats are supported. PROFILE DETAILS === It's best when describing details (if we want to do so) that we don't use different terminology or concepts than what is used in the rest of the installer, if at all possible. In your example, we have: - 'logical volume' This only shows up in custom partitioning, and even then not very foregrounded (unless I'm missing something). - 'mount options' Not used anywhere. - 'package', 'list of installed packages', 'list of excluded packages' Packages are not exposed in the installer UI as user-interactable objects - the only place they show up (outside of error messages) is as part of the installation progress bar. I take all those terms as commonly known or, in case of logical volume, something that can be simply ignored if not understood. Above and beyond that: - We should not be showing things as warnings. If the policy says a password must meet certain parameters, and we let the user later set it up in a way that violates that without additional warnings or automatic remediation, that's a bug. I agree, but before this is fixed (a change in the anaconda installer needed), displaying a warning is better than nothing to me. - The error situation is even worse. It's really bad form to show them an error in spoke A *that they inherently have to know how to fix in spoke B*. Otherwise, you're giving them an easy way to break their system that they won't know how to get out of, with no
Re: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2014 01:16 AM, Kevin Kofler wrote: Stephen Gallagher wrote: - From what I've seen of the planned rich dependencies, I don't think they would provide any mechanism better than this one anyway. Can you explain how you would see this working, with a specific example? foo.spec: Requires: foo-config-default or foo-config-server or foo-config-cloud Requires: not fedora-release-server or foo-config-server Requires: not fedora-release-cloud or foo-config-cloud Ok, so if I'm parsing this right (my boolean logic is always on the fritz), it basically says: If fedora-release-server is installed, then install foo-config-server else if fedora-release-cloud is installed, then install foo-config-cloud else install foo-config-default (And the implication here is that fedora-release-server Conflicts with fedora-release-cloud). That's probably a reasonable approach, assuming those rich dependencies work as advertised and are available in Fedora 21. (I've heard that they're present in RPM itself, but so far the FPC has not approved any such usage. This example is probably worth raising with them.) Thank you for the explanation. The above approach is also fairly future-proof, as if we add a new Product to the line-up, that Product would just pull in foo-config-default until and unless the maintainer decided to add a new, Product-specific config sub-package. As noted above, this makes a couple implications for future usage, however: 1) If we select this route, we make it impossible to have co-tenancy of two Products (e.g. Server and Workstation). This seems to be a statement that the various groups have been circling in on, and I'm coming to see the value in making this assertion. 2) Unless I misunderstand how the dependency-resolution works, it becomes impossible to change from one Product to another (e.g. Cloud's adopt-a-server switch to Server).[1] [1] I could be wrong here; it depends on how RPM and YUM handles 'yum remove fedora-release-cloud; yum install fedora-release-server'. Lets assume that foo has foo-config-cloud installed. I see three possible outcomes to 'yum remove fedora-release-cloud': 1) foo-config-cloud is removed and foo-config-default is installed 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud 3) The transaction aborts because of unsatisfied dependencies. Similar questions are therefore inherent with 'yum install fedora-release-server' after that: do packages get the server default configs or do they remain with the cloud or default configs? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMm6gwACgkQeiVVYja6o6PeYACfeYhu2SIY8/9KRP7sXDrRnr9U 6d8AoImUXiaOZYyHOXQjHnMpjXjpjF79 =9zKP -END PGP SIGNATURE- -- 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: F21 Self Contained Change: Security Policy In The Installer
Thank you for the proposal, Bill. - Original Message - From: Bill Nottingham nott...@splat.cc Vratislav Podzimek (vpodz...@redhat.com) said: Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 So, having watched the video, I think I'm pretty clearly against this from a interactive install standpoint, given what is presented. Here's what I see in that video. I'm not a UI/UX professional, so additional review from someone more along those lines would be great (and info on where I'm barking up the wrong tree - can always learn more.) INTEGRATION === Current toplevel is localization, software, and system. 'Security policy' doesn't fit as a toplevel along with that. If we wanted it as an additional item under 'System', des that mean it can't be done as an addon? Will leave reply to this item to Vratislav (since I am not familiar with Anaconda plug-ins internals). Vratislav, can you clarify if this would be possible to implement by changing the current design? INITIAL SCREEN == - You've got three active items: 1 - 'Change content' (button) 2 - 'Apply security policy' (toggle) 3 - 'Select profile' (button) If someone isn't familar with the specific terminology in use here, you're using three separate nouns here which all can be similar in meaning (policy, profile, content). If the user isn't familiar with all three terms, all three of these items could be seen as doing the same thing! That's not good. Fair enough. To be consistent I would recommend we to stick just with the security policy (and forget about the other possibly confusing terms) [*] If I were to whiteboard some proposed improvements of the screen you have (note: not saying this is the way to go vs. a full rework), it would be something like: rename Choose another policy source... button to read Load external security policy... Let me try to iterate on your proposal. Just a note (small correction) -- within policy we aren't selecting sub-policies, but rather profiles (just question of naming convention). FWICT I like your proposal in general, with small possible enhancements: * have SCAP security guide policy loaded / selected by default, * mention policy name in the middle of Apply ... toggle, * provide description for each profile at the right side (as you proposed) Apply a security policy [ YES | NO ] (1) Policy 1 | (if we want details on the selected description 1 | policy, they go here on selection) | Policy 2 | description 2 | ... | - [ Choose another policy source ... ] (2) (1) If 'no' is selected, rest of screen is inactive Agree with this item. (2) If this is still desired As pointed out by other people in this thread too, having a way to select which policy to apply is good (just for the case the more experienced user might want to supply own modified policy). But agree with that point, that for example on https:// URLs the certificate should be verified for validity (didn't try if it actually is already). There would be no 'select profile' button - it would be selected by just selecting the profile, similar to other anaconda actions. +1. Agree that Select Profile button is redundant (not needed) here. The slight modification of your proposal is listed below: Apply SCAP Security Guide security policy [ YES | NO ] --- | (Maybe description of the whole policy here?) | | | | | --- Choose security profile: [**] --- Common Profile |Longer description of the profile Summary of the profile |shown upon selection --- Server Profile |Longer description -||- Summary of the Server profile | --- .. |.. .. |
Re: Per-Product Config file divergence
On Mon, Mar 17, 2014 at 08:26:52AM -0400, Stephen Gallagher wrote: [1] I could be wrong here; it depends on how RPM and YUM handles 'yum remove fedora-release-cloud; yum install fedora-release-server'. Lets assume that foo has foo-config-cloud installed. I see three possible outcomes to 'yum remove fedora-release-cloud': 1) foo-config-cloud is removed and foo-config-default is installed 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud 3) The transaction aborts because of unsatisfied dependencies. Not sure about with DNF, but with yum we could use yum swap instead of separate remove and install commands. Worst case, we write a plugin to handle this adoption case. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- 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: F21 Self Contained Change: Security Policy In The Installer
Can you be more concrete which term(s) you don't understand? Maybe you are right and the concept needs to be better explained / presented differently prior wider adoption [**]. What is a Data stream? What is a Checklist? How do I know which ones to pick? Datastream is one of the format security policy can be provided in. Checklist is list of rules the features of the system to be installed are to be checked against. But I got your point that we should focus to present this as much easy as possible (possibly removing jargon words / replacing them with their more clear equivalents etc.) Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Per-Product Config file divergence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/2014 09:13 AM, Matthew Miller wrote: On Mon, Mar 17, 2014 at 08:26:52AM -0400, Stephen Gallagher wrote: [1] I could be wrong here; it depends on how RPM and YUM handles 'yum remove fedora-release-cloud; yum install fedora-release-server'. Lets assume that foo has foo-config-cloud installed. I see three possible outcomes to 'yum remove fedora-release-cloud': 1) foo-config-cloud is removed and foo-config-default is installed 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud 3) The transaction aborts because of unsatisfied dependencies. Not sure about with DNF, but with yum we could use yum swap instead of separate remove and install commands. Hmm, you learn something new every day. I didn't know about that one. I assume it handles dependency satisfying properly? So if I did 'yum swap python-django14 python-django' it wouldn't have issues with eclipse-pydev (as a recent example I was grumbling about). Worst case, we write a plugin to handle this adoption case. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMm+scACgkQeiVVYja6o6P4NwCfeGM7x6qRzWad1SRVhIVM/x99 JhEAoIjX7EmuBLn2U6+S4TlLjmSdaiLN =5Qcx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1074959] perl-Task-Kensho-Toolchain-0.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1074959 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Task-Kensho-OOP-0.36-1 ||.fc21 Resolution|--- |RAWHIDE Last Closed||2014-03-17 09:37:12 -- 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=QygbkG6D03a=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: Help understanding Anaconda source - walk through needed.
On Wed, 2014-03-12 at 20:07 +, Aaron Gray wrote: I am looking for someone to walk me through the Anaconda source as I need to understand it and cannot find where its 'main' is and how it launches X Windows as I need to work out why the main installer is not working on my HP D140 G3's with MCA video controllers. Anaconda doesn't really configure X before running it, it just relies on X's autoconfiguration logic to Do The Right Thing. I'm hoping you don't really mean MCA to mean Micro Channel Architecture there, one I didn't think anybody besides IBM was foolish enough to use that and two Fedora's X hasn't supported buses older than PCI for a couple of releases now. Whatever problem you're having with graphics at install time, you will almost certainly also have after installed; it's usually easier to debug by going ahead and installing in text mode and then debugging graphics once installed. - ajax -- 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: F21 Self Contained Change: Security Policy In The Installer
- Original Message - From: Chris Murphy li...@colorremedies.com On Mar 14, 2014, at 1:06 PM, Eric H. Christensen spa...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 14, 2014 at 06:59:18PM +, Matthew Garrett wrote: On Fri, Mar 14, 2014 at 02:57:33PM -0400, Steve Grubb wrote: On Friday, March 14, 2014 06:53:42 PM Matthew Garrett wrote: Having separate server, workstation and cloud products means we can apply separate defaults without requiring user interaction. Beyond that, why would an end user want to choose common criteria during an interactive install? Isn't that something that should be imposed on them by their local admin? Yes, and I believe the kick start would do that. I would also even see a case where an admin takes the base policy and tailors it with site specific settings and puts that into effect instead of the default one we provide. I like the idea of choice. Exactly, this is functionality that makes sense for enterprise and automated deployments. I don't see it making sense for an interactive install. You're making an assumption that I wouldn't want my personal box to be hardened at install or that the enterprise has an automated way of doing a deployments. Why make it harder to use the operating system when a simpler way of configuration has been suggested? I think Matthew is making a reasonable assumption that many (probably even most) other users will become confused to the point of being disturbed by something that seems to require their attention, has a UI with terms they aren't likely familiar with, while suggesting choices, yet at the moment there's only one policy (?) so why is a UI needed for this right now? This is usually what kickstart installs are for. The feature isn't going to be a massive change to the UI and only adds to the awareness that users have a choice on how hardened their system is at install time. Whether you chose to use it is your business. At this point it doesn't appear to need a UI. There's no off or on switch, or opt in or opt out. There's one policy. I'd say even with three policies available I'm much better off with a slider that says Standard Security - More Secure - Most Secure. I mean, that's sufficiently dumbed down I still don't know what those things actually mean in terms of policy or behaviors, but relative to each other I've made a more informed decision than what I'm currently presented with. The problem with this proposal (Standard Security - More - Most within slider) being it's binding the current SCAP security guide content with Anaconda add-on too much (IOW it's not flexible). What if in the future we would like to have five instead of three profiles? Another point is that due to different targeted use of profiles (server vs cloud security etc.) it's not possible to decide which of the profiles is more safer (i.e. use linear scaling from less secure to the most secure). It would be possible if each profile would be implemented as inheriting from his predecessor. But this is not the case always (server vs cloud) - on one hand there would be rules both of them would derive from their parent (common), but on the other hand there would be also usage specific rules (IOW server not having those from cloud and vice versa). I mean honestly how complicated does an OS install need to be? It's like piling on the user. It does need a default, like Timezone spoke, even though sometimes that too is set wrong for a particular user. The default avoids the requirement the user enter the spoke. It should be a minimum recommended security policy. The next question I have is how this spoke can affect other spokes, as well as affect the installation process itself? What I'm looking for is some assessment of impact on QA resources needed to test this feature, if any resources are needed at all. If there's no default but the user must interact with this spoke to proceed with installation, that's definitely a QA impact. Common profile from SCAP security guide would be the default policy (if to apply security policy toggle button was toggled on). Would we know more details about the system from the start (i.e. if it's to be standalone server installation or movable laptop edition we could use even more specific default profile). There's maybe one or two toothbrush wrappers of spare resources in QA (and I'm already imagining Adam feverishly writing a reply, UMMM, I don't think so, where?!) So if it's even remotely possible for a security policy to be chosen that later causes some sort of install, or even a first boot failure to happen - that's too much QA impact right now, short of a recruitment drive. There would be two levels of testing required: * one group to test the functionality of OSCAP Anaconda Addon (i.e. if it works properly). Assuming, this would be done within Fedora Anaconda
Re: F21 System Wide Change: Ruby 2.1
Dne 15.3.2014 15:43, Richard W.M. Jones napsal(a): On Thu, Mar 13, 2014 at 01:52:32PM +0100, Vít Ondruch wrote: Dne 13.3.2014 13:17, Richard W.M. Jones napsal(a): On Thu, Mar 13, 2014 at 05:43:16AM -0400, Jaroslav Reznik wrote: - Original Message - = Proposed System Wide Change: Ruby 2.1 = https://fedoraproject.org/wiki/Changes/Ruby_2.1 Change owner(s): Vít Ondruch vondr...@redhat.com Ruby 2.1 is the latest stable version of Ruby, with major increases in speed, memory efficiency and reliability. With this major update from Ruby 2.0.0 in Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the superior Ruby development platform. This Change was approved by FESCo on yesterdays meeting with a note: this requires a mini-mass rebuild for native ruby extensions so schedule needs to account for that. Is a ruby 2.1 RPM available for us to test build our packages against? (I checked koji, doesn't appear to be any there.) Rich. No, not yet ... I wanted to build in Copr, but it fails due to old Kernel :/ Nevertheless, you can checkout ruby from dist-git and you should be able to scratch-build in Koji for yourself from private-ruby-2.1 branch. The package fails to build with: + mv /home/rjones/rpmbuild/BUILDROOT/ruby-2.1.1-18.fc21.x86_64/usr/share/ruby/gems /home/rjones/rpmbuild/BUILDROOT/ruby-2.1.1-18.fc21.x86_64/usr/share/gems mv: cannot stat '/home/rjones/rpmbuild/BUILDROOT/ruby-2.1.1-18.fc21.x86_64/usr/share/ruby/gems': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.6A9BWu (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.6A9BWu (%install) Could not execute local: Non zero exit Neither /home/rjones/rpmbuild/BUILDROOT/ruby-2.1.1-18.fc21.x86_64/usr/share/ruby/gems nor /home/rjones/rpmbuild/BUILDROOT/ruby-2.1.1-18.fc21.x86_64/usr/share/gems exists. This could be a missing BuildRequires? I have put the full build log up here: http://oirase.annexia.org/tmp/build-2.1.1-18.fc21.log.xz Note I'm building this on an F20-(ish) machine, because I don't want the full Rawhide ExperienceTM on my main dev machine yet. Rich. Please use koji scratch-build/mock to build the Ruby. It is not good idea to build it by plain rpmbuild for various reasons. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
unalz to remove from Fedora
Hello, it has been `discovered' that unalz package bundles bzip2 sources (bug #1076853). In my opinion, it's not possible to unbundle here because the sources are modified at low level to implement ALZip format. Beacuse I was not even able to find any ALZip archive example on the net, I think it's time to remove the package from Fedora (21). If there is an hacker volunteering to fix this issue, I can give him the package. Otherwise I will retire the package in one week. About unzip: unzip is a command line tool for decompressing ALZip archives. The format http://en.wikipedia.org/wiki/ALZip was (is?) popular in South Korea in the end of 1990s. The source code has Korean comments. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-GnuPG-Interface
perl-GnuPG-Interface has broken dependencies in the rawhide tree: On x86_64: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::HandlesVia) On i386: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::HandlesVia) On armhfp: perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::late) perl-GnuPG-Interface-0.50-1.fc21.noarch requires perl(MooX::HandlesVia) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Elasticsearch
perl-Elasticsearch has broken dependencies in the rawhide tree: On x86_64: perl-Elasticsearch-1.05-1.fc21.noarch requires perl(Hijk) = 0:0.12 On i386: perl-Elasticsearch-1.05-1.fc21.noarch requires perl(Hijk) = 0:0.12 On armhfp: perl-Elasticsearch-1.05-1.fc21.noarch requires perl(Hijk) = 0:0.12 Please resolve this as soon as possible. -- 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
Systemd cgroups NWO
What is the status of fedora systemd cgroup integration outlined here: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ Current build is 211-1. The reason for asking is in the document: short-term, medium-term, long-term are not fully defined. We all know Fedora lives on the tip of the spear. -- Cheers, Tim Freedom, Features, Friends, First - Fedora https://fedoraproject.org/wiki/SIGs/bigdata -- 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: F21 Self Contained Change: Security Policy In The Installer
On Mon, 2014-03-17 at 13:10 +0100, Vratislav Podzimek wrote: And to sum it up a bit -- I think this feature doesn't complicate things for users who want to ignore it or who don't understand it. If you think it does, please tell me about it and I'll do my best to fix it. On the other hand, if somebody wants to care about security policies, they have an easy and comfortable choice. Unfortunately, I don't think this is quite right. As I understand it, it's fairly well established that if people see a UI element, they - or, at least, an appreciable amount of them - will want to interact with it, or at least understand it. *Some* people may follow this thought process: Path 1 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, I guess I'll just ignore it and carry on. which is what you're assuming, and would give an okay outcome. However, I think it's fairly well known that quite a lot of people will follow this one: Path 2 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, crap. I'm installing an OS. That's a pretty major operation. I think I'd better understand everything that's going on before I carry on. clickety Huh. content...policy...profile? What is all this stuff about? What does it mean? What should I do? This one goes one of about three ways. If we're really lucky: Well, I guess I'd better go read the docs. reads docs That was a clear, short and cogent explanation! I learned something, an now I can continue! If we're less lucky: I guess I'll go Google around and see if I find something useful. Jeez, why does this have to be so complicated? If we're less lucky: Man, screw this crap, if I have to go read an encyclopaedia just to get it installed, I'll go do something else. And finally, some people will probably follow this one: Path 3 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, what the hell, I'm a smart cookie, I'll just power through. clickety Hum. Content...policy...profile? I don't really know what any of those things are. But reading is hard. I'll just make some sensible-looking guesses! clickety I suspect you can figure out the possible outcomes of path 3. ;) -- 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
Re: Help understanding Anaconda source - walk through needed.
On Mon, 2014-03-17 at 09:39 -0400, Adam Jackson wrote: On Wed, 2014-03-12 at 20:07 +, Aaron Gray wrote: I am looking for someone to walk me through the Anaconda source as I need to understand it and cannot find where its 'main' is and how it launches X Windows as I need to work out why the main installer is not working on my HP D140 G3's with MCA video controllers. Anaconda doesn't really configure X before running it, it just relies on X's autoconfiguration logic to Do The Right Thing. I'm hoping you don't really mean MCA to mean Micro Channel Architecture there, one I didn't think anybody besides IBM was foolish enough to use that and two Fedora's X hasn't supported buses older than PCI for a couple of releases now. Whatever problem you're having with graphics at install time, you will almost certainly also have after installed; it's usually easier to debug by going ahead and installing in text mode and then debugging graphics once installed. I think the system he's referring to is this one: http://reviews.cnet.com/soho-servers/hp-proliant-dl140/4507-3125_7-30620088.html Graphics Controller Type Integrated Interface Type PCI Graphics Processor / Vendor ATI RAGE XL Video Memory 8 MB / 8 MB (max) SDRAM Video Interfaces VGA -- 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
[perl-Fennec/epel7] Update to 2.014
Summary of changes: 7551a9e... Update to 2.014 (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F20: what connects the lid switch to triggering suspend?
On Fri, 2014-03-14 at 17:41 +0100, Tomasz Torcz wrote: On Fri, Mar 14, 2014 at 11:38:31AM -0500, Dan Williams wrote: The lid switch is exposed as input device in Linux. logind opens that device and reacts on it. However it gives DEs the chance to inhibit this if they desire so. Gnome at least doesn't inhibit it perminantly though, but some components might delay suspends, for example Telepathy to log you out of your Jabber server... Normally when you close the lid logind should log something about Lid closed or so... Look around the logs around this to figure out what mightbe going on. I've run into this too, is there a quick command to get the list of offending suspend inhibitors so we can debug further? systemd-inhibit --list Thanks... *drum roll* The offending package was telepathy-mission-control. Not really sure why it cared about suspend/resume, since I didn't have any telepathy services configured, and wasn't using it (or empathy or gnome-accounts-service) for any online accounts. Dan -- 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: Systemd cgroups NWO
On Mon, 17.03.14 17:09, Tim St Clair (tstcl...@redhat.com) wrote: What is the status of fedora systemd cgroup integration outlined here: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ Current build is 211-1. The reason for asking is in the document: short-term, medium-term, long-term are not fully defined. Well, the nebulous choice of words is intended, since we don't want to make specific promises on time-frames... The APIs described (tersely) at the end of the wiki page describe the status quo with systemd 211. The single-writer cgroup tree stuff Tejun has been working on for the kernel is now working on his machine, but it's not pushed upstream and will take a while before it will hit Fedora. At this point in time you hence still may create cgroups directly yourself (but only if you follow the pax cgroup document), however, we strongly encourage you to instead use scopes/slices to create them, as discussed on the wiki page. This way the cgroups transition will be abstracted away from yu. You have control of a number of knobs that systemd will expose for you, such as CPUShares=, BlockIOWeight= and so on, but this is not complete, and primarily so because it's not clear that those other properties will continue to exist the way they are in the kernel. To read statistics data or to write knobs that systemd doesn't cover you need to go directly to the cgroupfs. For that, simply read /proc/self/cgroup to find out your own cgroup, and then operate on that. However, as during the single-writer cgroup transition the kernel interface how we set things up will change, be prepared that things might break... Lennart -- Lennart Poettering, Red Hat -- 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: F20: what connects the lid switch to triggering suspend?
On Mon, 17.03.14 17:18, Dan Williams (d...@redhat.com) wrote: systemd-inhibit --list Thanks... *drum roll* The offending package was telepathy-mission-control. Not really sure why it cared about suspend/resume, since I didn't have any telepathy services configured, and wasn't using it (or empathy or gnome-accounts-service) for any online accounts. They want to set the IM accounts to offline when the machine goes down. BTW, logind versions from Rawhide will actually log the identity of all processes that take delay suspend locks and which don't release them by the time the timeout we put on that elapses. Or with other words, if something like Telepathy delays your suspend you should see logind mentioned that it is responsible for that in the logs. This hopefully puts enough shame on people to not delay suspend unnecessarily... ;-) Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rfc: EFI System partition, FAT32, repair and non-persistent mount
Two feature requests, comments please.
1. EFI System partition is being mounted persistently at /boot/efi, and I'd
like to put an end to that because there's no good reason to do it. None of the
binaries on it are regularly being updated, and if they are, the volume should
be mounted on demand rather than persistently. The grub.cfg on each ESP should
be a simple static grub.cfg like this:
# cat /boot/efi/EFI/fedora/grub.cfg
#
# DO NOT EDIT THIS FILE
# THIS FORWARDS TO THE REAL GRUB.CFG
#
{
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt1
--hint-efi=hd1,gpt1 10044fb4-8f90-4ca6-888c-98a0c88169e2
configfile /boot/grub2/grub.cfg
}
And then we update /boot/grub2/grub.cfg just like on BIOS systems, on a file
system that can tolerate some abuse, unlike FAT. It also means there's some
chance of resiliently bootable raid on UEFI systems which right now isn't
assured because we don't create ESP's on each system disk chosen, let alone
have a way of syncing the grub.cfg's on each of those ESPs. Nor a way to mount
them all at the same time anyway.
Last, Windows and OS X don't keep their ESP or boot volumes persistently
mounted, I don't know what good reason we have for doing this.
2. Right now we aren't doing an fsck on the single ESP we do mount. If we're
going to continue to mount it on every boot despite the arguments against doing
so, shouldn't /etc/fstab fspassno be set to 1 for /boot/efi? I have experienced
ESP file system corruption and /boot/efi wouldn't mount as a result, which
hangs the system and eventually drops it to an obscure emergency shell.
Affected by this change are anaconda to set fspassno to 1; dracut to include
mkfs.msdos initramfs; and possibly to fsck so that it runs mkfs.msdos with -a
which currently it doesn't do, instead it runs it interactively which isn't
suitable for boot time fixing. If we don't have the will to be checking and
fixing a file system critical for booting, maybe we shouldn't be persistently
mounting it rw (back to 1 above)?
3. Currently Fedora anaconda installs result in a FAT16 ESP which also isn't
done on Windows or OS X, except for removable media. My reading of the UEFI
spec says that on system drives (non-removables), it should be FAT32. I don't
know if it's really a problem that we're using FAT16, but figured I'd point it
out here in case someone has two cents to add on this. A bug has been filed
already.
https://bugzilla.redhat.com/show_bug.cgi?id=1046577
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) 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 XML-LibXML-2.0113.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-XML-LibXML: 1948580c28a59928d3fdb892529d7eb0 XML-LibXML-2.0113.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-XML-LibXML] 2.0113 bump
commit 14561579b3702ff6f67e6db8e03185cb2122644a
Author: Jitka Plesnikova jples...@redhat.com
Date: Mon Mar 17 15:36:29 2014 +0100
2.0113 bump
.gitignore |1 +
perl-XML-LibXML.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a77b498..5407b45 100644
--- a/.gitignore
+++ b/.gitignore
@@ -32,3 +32,4 @@ XML-LibXML-1.70.tar.gz
/XML-LibXML-2.0108.tar.gz
/XML-LibXML-2.0110.tar.gz
/XML-LibXML-2.0111.tar.gz
+/XML-LibXML-2.0113.tar.gz
diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index 20e1f81..4903c80 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -3,7 +3,7 @@ Name: perl-XML-LibXML
# https://bugzilla.redhat.com/show_bug.cgi?id=469480
# it might not be needed anymore
# this module is maintained, the other is not
-Version:2.0111
+Version:2.0113
Release:1%{?dist}
Epoch: 1
Summary:Perl interface to the libxml2 library
@@ -114,6 +114,9 @@ fi
%{_mandir}/man3/*.3*
%changelog
+* Mon Mar 17 2014 Jitka Plesnikova jples...@redhat.com - 1:2.0113-1
+- 2.0113 bump
+
* Mon Mar 10 2014 Jitka Plesnikova jples...@redhat.com - 1:2.0111-1
- 2.0111 bump
diff --git a/sources b/sources
index 071cd00..3601f2c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f29842be1b571d98ee7fc82b3f62fdc7 XML-LibXML-2.0111.tar.gz
+1948580c28a59928d3fdb892529d7eb0 XML-LibXML-2.0113.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 1076570] perl-XML-LibXML-2.0113 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1076570 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-XML-LibXML-2.0113-1.fc ||21 Resolution|--- |RAWHIDE Last Closed||2014-03-17 10:55:09 -- 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=6AM0V0U8ika=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 Hijk-0.12.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Hijk: fa4028b0465e083f28a8224ca643560f Hijk-0.12.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-Hijk] Initial import.
commit 4e9c90b7b1341b0b30b18b46047b67e5f86e2132
Author: Emmanuel Seyman emman...@seyman.fr
Date: Mon Mar 17 17:51:04 2014 +0100
Initial import.
.gitignore |1 +
perl-Hijk.spec | 74
sources|1 +
3 files changed, 76 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..e3f024b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Hijk-0.12.tar.gz
diff --git a/perl-Hijk.spec b/perl-Hijk.spec
new file mode 100644
index 000..68d6be8
--- /dev/null
+++ b/perl-Hijk.spec
@@ -0,0 +1,74 @@
+Name: perl-Hijk
+Version:0.12
+Release:3%{?dist}
+Summary:Specialized HTTP client
+License:MIT
+
+URL:http://search.cpan.org/dist/Hijk/
+Source0:http://www.cpan.org/authors/id/A/AV/AVAR/Hijk-%{version}.tar.gz
+
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Config)
+BuildRequires: perl(CPAN::Meta)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Path)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(Plack::Runner)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Socket)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(URI::Escape)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+Hijk is a specialized HTTP Client that does nothing but transport the
+response body back. It does not feature as a user agent, but as a dumb
+client. It is suitable for connecting to data servers transporting via HTTP
+rather then web servers.
+
+%prep
+%setup -q -n Hijk-%{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 {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README.md
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Sat Mar 15 2014 Emmanuel Seyman emman...@seyman.fr - 0.12-3
+- Really add perl as a BuildRequires
+
+* Fri Mar 14 2014 Emmanuel Seyman emman...@seyman.fr - 0.12-2
+- Take into account review (#1074268)
+
+* Sun Mar 09 2014 Emmanuel Seyman emman...@seyman.fr 0.12-1
+- Specfile autogenerated by cpanspec 1.78, with changes.
diff --git a/sources b/sources
index e69de29..ad27109 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+fa4028b0465e083f28a8224ca643560f Hijk-0.12.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-Hijk/f20] Initial import.
commit fe82de5d36a1791dc257ec681f398da7ef417f7b
Author: Emmanuel Seyman emman...@seyman.fr
Date: Mon Mar 17 18:08:06 2014 +0100
Initial import.
.gitignore |1 +
perl-Hijk.spec | 74
sources|1 +
3 files changed, 76 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..e3f024b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Hijk-0.12.tar.gz
diff --git a/perl-Hijk.spec b/perl-Hijk.spec
new file mode 100644
index 000..68d6be8
--- /dev/null
+++ b/perl-Hijk.spec
@@ -0,0 +1,74 @@
+Name: perl-Hijk
+Version:0.12
+Release:3%{?dist}
+Summary:Specialized HTTP client
+License:MIT
+
+URL:http://search.cpan.org/dist/Hijk/
+Source0:http://www.cpan.org/authors/id/A/AV/AVAR/Hijk-%{version}.tar.gz
+
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Config)
+BuildRequires: perl(CPAN::Meta)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Path)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(Plack::Runner)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Socket)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(URI::Escape)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+Hijk is a specialized HTTP Client that does nothing but transport the
+response body back. It does not feature as a user agent, but as a dumb
+client. It is suitable for connecting to data servers transporting via HTTP
+rather then web servers.
+
+%prep
+%setup -q -n Hijk-%{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 {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README.md
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Sat Mar 15 2014 Emmanuel Seyman emman...@seyman.fr - 0.12-3
+- Really add perl as a BuildRequires
+
+* Fri Mar 14 2014 Emmanuel Seyman emman...@seyman.fr - 0.12-2
+- Take into account review (#1074268)
+
+* Sun Mar 09 2014 Emmanuel Seyman emman...@seyman.fr 0.12-1
+- Specfile autogenerated by cpanspec 1.78, with changes.
diff --git a/sources b/sources
index e69de29..ad27109 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+fa4028b0465e083f28a8224ca643560f Hijk-0.12.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 Fennec-2.014.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Fennec: cf015a8aea506d3d93085e47aa7bda35 Fennec-2.014.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-Fennec] Update to 2.014
commit 7551a9ec925db6c31d69acbfd1bcba84680780be
Author: Paul Howarth p...@city-fan.org
Date: Mon Mar 17 21:55:31 2014 +
Update to 2.014
- New upstream release 2.014
- Support FENNEC_PARALLEL=0 environment variable setting
perl-Fennec.spec |6 +-
sources |2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Fennec.spec b/perl-Fennec.spec
index d5888ba..23132cd 100644
--- a/perl-Fennec.spec
+++ b/perl-Fennec.spec
@@ -2,7 +2,7 @@
# guarded by %{?perl_bootstrap} since it requires perl(Fennec) itself
Name: perl-Fennec
-Version: 2.013
+Version: 2.014
Release: 1%{?dist}
Summary: A tester's toolbox, and best friend
License: GPL+ or Artistic
@@ -99,6 +99,10 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/Test::Workflow::Test.3pm*
%changelog
+* Mon Mar 17 2014 Paul Howarth p...@city-fan.org - 2.014-1
+- Update to 2.014
+ - Support FENNEC_PARALLEL=0 environment variable setting
+
* Mon Jan 6 2014 Paul Howarth p...@city-fan.org - 2.013-1
- Update to 2.013
- Add extra debugging for Dreamhost issue
diff --git a/sources b/sources
index 5a0d609..9bead12 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8baf56fee86640e7bf48041f4ac898e8 Fennec-2.013.tar.gz
+cf015a8aea506d3d93085e47aa7bda35 Fennec-2.014.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-Fennec] Created tag perl-Fennec-2.014-1.fc21
The lightweight tag 'perl-Fennec-2.014-1.fc21' was created pointing to: 7551a9e... Update to 2.014 -- 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-Fennec] Created tag perl-Fennec-2.014-1.el7
The lightweight tag 'perl-Fennec-2.014-1.el7' was created pointing to: 7551a9e... Update to 2.014 -- 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 1077413] New: perl-Wx FTBFS because perl-ExtUtils-XSpp introduced epoch
https://bugzilla.redhat.com/show_bug.cgi?id=1077413 Bug ID: 1077413 Summary: perl-Wx FTBFS because perl-ExtUtils-XSpp introduced epoch Product: Fedora Version: rawhide Component: perl-Wx Assignee: tcall...@redhat.com Reporter: mhron...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com Description of problem: In rawhide, perl-ExtUtils-XSpp is now 1:0.18, but perl-Wx BuildRequires perl(ExtUtils::XSpp) = 0.1602 and fails to build. See http://koji.fedoraproject.org/koji/taskinfo?taskID=6643000 While this is not critical yet, it will pops out when a mass (or any) rebuild happens. Version-Release number of selected component (if applicable): 0.9921-3 As a provenpackager, I could fix this, but I guess it's better idea to do it together with packaging the new version (see bz958819). -- 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=4UJUROc7oEa=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 958819] perl-Wx-0.9922 is available
https://bugzilla.redhat.com/show_bug.cgi?id=958819 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added CC||mhron...@redhat.com --- Comment #1 from Miro Hrončok mhron...@redhat.com --- I have it prepared, see https://copr.fedoraproject.org/coprs/churchyard/perl-Wx-09922/ and http://churchyard.fedorapeople.org/SRPMS/perl-Wx-0.9922-1.fc21.src.rpm May I push it to rawhide? -- 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=CWwYmk2obxa=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 958819] perl-Wx-0.9922 is available
https://bugzilla.redhat.com/show_bug.cgi?id=958819 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|tcall...@redhat.com |mhron...@redhat.com --- Comment #2 from Miro Hrončok mhron...@redhat.com --- From spot: My hotel wifi is refusing to open bugzilla for some reason, but go ahead and push the new version. Just note the manual requires generation process. -- 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=VRzJxa0frBa=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 Wx-0.9922.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for perl-Wx: 672a97d618ae64814bfd3572187ab929 Wx-0.9922.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Wx] Update to 0.9922
commit 54c37d16746fe3a0e8eb421eac14e918ff539abb
Author: Miro Hrončok m...@hroncok.cz
Date: Tue Mar 18 02:04:25 2014 +0100
Update to 0.9922
.gitignore |1 +
perl-Wx.spec | 157 +-
sources |2 +-
3 files changed, 92 insertions(+), 68 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 42d3ee5..65cf2fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,3 +16,4 @@ Wx-0.92.tar.gz
/Wx-0.9917.tar.gz
/Wx-0.9918.tar.gz
/Wx-0.9921.tar.gz
+/Wx-0.9922.tar.gz
diff --git a/perl-Wx.spec b/perl-Wx.spec
index f8f826a..8409e6c 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -11,8 +11,8 @@
# cat provides.txt | uniq | sort -n
Name: perl-Wx
-Version:0.9921
-Release:3%{?dist}
+Version:0.9922
+Release:1%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
License:GPL+ or Artistic
@@ -23,8 +23,6 @@ BuildRequires: perl(Alien::wxWidgets) = 0.25
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.21
BuildRequires: perl(ExtUtils::ParseXS) = 2.2203
-# Technically, we need XSpp::Cmd, but there is no versioning in that provide.
-BuildRequires: perl(ExtUtils::XSpp) = 0.1602
BuildRequires: perl(ExtUtils::XSpp::Cmd)
BuildRequires: perl(Fatal)
BuildRequires: perl(Module::Info)
@@ -34,11 +32,12 @@ BuildRequires: perl(YAML) = 0.35
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# Manual provides from XS
+Provides: perl(Wx::ANIHandler)
+Provides: perl(Wx::AUI)
Provides: perl(Wx::AboutDialogInfo)
Provides: perl(Wx::AcceleratorEntry)
Provides: perl(Wx::AcceleratorTable)
Provides: perl(Wx::ActivateEvent)
-Provides: perl(Wx::ANIHandler)
Provides: perl(Wx::Animation)
Provides: perl(Wx::AnimationCtrl)
Provides: perl(Wx::_App)
@@ -46,13 +45,13 @@ Provides: perl(Wx::App)
Provides: perl(Wx::ArchiveFSHandler)
Provides: perl(Wx::ArrayStringProperty)
Provides: perl(Wx::ArtProvider)
-Provides: perl(Wx::AUI)
Provides: perl(Wx::AuiManager)
Provides: perl(Wx::AuiManagerEvent)
Provides: perl(Wx::AuiNotebook)
Provides: perl(Wx::AuiNotebookEvent)
Provides: perl(Wx::AuiPaneInfo)
Provides: perl(Wx::AutoBufferedPaintDC)
+Provides: perl(Wx::BMPHandler)
Provides: perl(Wx::BannerWindow)
Provides: perl(Wx::BestHelpController)
Provides: perl(Wx::Bitmap)
@@ -60,7 +59,6 @@ Provides: perl(Wx::BitmapButton)
Provides: perl(Wx::BitmapComboBox)
Provides: perl(Wx::BitmapDataObject)
Provides: perl(Wx::BitmapToggleButton)
-Provides: perl(Wx::BMPHandler)
Provides: perl(Wx::BookCtrl)
Provides: perl(Wx::BookCtrlEvent)
Provides: perl(Wx::BoolProperty)
@@ -71,6 +69,8 @@ Provides: perl(Wx::BufferedPaintDC)
Provides: perl(Wx::BusyCursor)
Provides: perl(Wx::BusyInfo)
Provides: perl(Wx::Button)
+Provides: perl(Wx::CHMHelpController)
+Provides: perl(Wx::CURHandler)
Provides: perl(Wx::CalendarCtrl)
Provides: perl(Wx::CalendarDateAttr)
Provides: perl(Wx::CalendarEvent)
@@ -79,10 +79,10 @@ Provides: perl(Wx::CaretSuspend)
Provides: perl(Wx::CheckBox)
Provides: perl(Wx::CheckListBox)
Provides: perl(Wx::ChildFocusEvent)
-Provides: perl(Wx::CHMHelpController)
Provides: perl(Wx::Choice)
Provides: perl(Wx::Choicebook)
Provides: perl(Wx::ClassInfo)
+Provides: perl(Wx::ClassInfo)
Provides: perl(Wx::Client)
Provides: perl(Wx::ClientDC)
Provides: perl(Wx::Clipboard)
@@ -103,6 +103,7 @@ Provides: perl(Wx::ComboCtrl)
Provides: perl(Wx::ComboPopup)
Provides: perl(Wx::Command)
Provides: perl(Wx::CommandEvent)
+Provides: perl(Wx::CommandLinkButton)
Provides: perl(Wx::CommandProcessor)
Provides: perl(Wx::ConfigBase)
Provides: perl(Wx::Connection)
@@ -111,11 +112,12 @@ Provides: perl(Wx::ContextHelpButton)
Provides: perl(Wx::ContextMenuEvent)
Provides: perl(Wx::Control)
Provides: perl(Wx::ControlWithItems)
-Provides: perl(Wx::CURHandler)
Provides: perl(Wx::Cursor)
Provides: perl(Wx::CursorProperty)
+Provides: perl(Wx::DC)
+Provides: perl(Wx::DCClipper)
+Provides: perl(Wx::DCOverlay)
Provides: perl(Wx::DataFormat)
-Provides: perl(Wx::DatagramSocket)
Provides: perl(Wx::DataObject)
Provides: perl(Wx::DataObjectComposite)
Provides: perl(Wx::DataObjectSimple)
@@ -143,37 +145,36 @@ Provides: perl(Wx::DataViewToggleRenderer)
Provides: perl(Wx::DataViewTreeCtrl)
Provides: perl(Wx::DataViewTreeStore)
Provides: perl(Wx::DataViewVirtualListModel)
+Provides: perl(Wx::DatagramSocket)
Provides: perl(Wx::DateEvent)
Provides: perl(Wx::DatePickerCtrl)
Provides: perl(Wx::DateProperty)
Provides: perl(Wx::DateSpan)
Provides: perl(Wx::DateTime)
-Provides: perl(Wx::DC)
-Provides: perl(Wx::DCClipper)
-Provides: perl(Wx::DCOverlay)
Provides: perl(Wx::Dialog)
Provides: perl(Wx::DirDialog)
Provides: perl(Wx::DirPickerCtrl)
Provides: perl(Wx::DirProperty)
Provides: perl(Wx::Display)
Provides: perl(Wx::DocChildFrame)
-Provides: perl(Wx::DocManager)
Provides:
[389-devel] Please review ticket 47553: Enhance ACIs to have more control over MODRDN operations
The design for this ticket is http://directory.fedoraproject.org/wiki/Access_control_on_trees_specified_in_MODDN_operation The fix is https://fedorahosted.org/389/attachment/ticket/47553/0001-Ticket-47553-Enhance-ACIs-to-have-more-control-over-.patch The test case is: https://fedorahosted.org/389/attachment/ticket/47553/0001-Ticket-47553-test-case.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Python 3.4.0 final has been released
From Larry's release announcement: == Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a pathlib module providing object-oriented filesystem paths * PEP 435, a standardized enum module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new statistics module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new tracemalloc module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new asyncio module, a new framework for asynchronous I/O To download Python 3.4.0 visit: http://www.python.org/download/releases/3.4.0/ == Direct link to the What's New guide: http://docs.python.org/3/whatsnew/3.4.html Cheers, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/) ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Python 3.4.0 final has been released
On 03/17/2014 05:53 PM, Nick Coghlan wrote: Direct link to the What's New guide: http://docs.python.org/3/whatsnew/3.4.html Rereading that, I remembered there's more to it for Fedora than just hey, here's a shiny new version of Python 3 to be packaged, and I don't mean the stuff Slavek is working on to let ensurepip use the system pip installation as a base. Specifically, there may need to be a security-related change to the Python packaging guidelines, covering the appropriate use of isolated mode: http://docs.python.org/3/whatsnew/3.4.html#whatsnew-isolated-mode There's also a simpler workaround for the issues with the standard streams when running things in the POSIX locale: setting PYTHONIOENCODING=:surrogateescape will deal with it for user mode scripts. Cheers, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/) ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Python 3.4.0 final has been released
- Original Message - On 03/17/2014 05:53 PM, Nick Coghlan wrote: Direct link to the What's New guide: http://docs.python.org/3/whatsnew/3.4.html Thanks, Nick! Rereading that, I remembered there's more to it for Fedora than just hey, here's a shiny new version of Python 3 to be packaged, and I don't mean the stuff Slavek is working on to let ensurepip use the system pip installation as a base. Specifically, there may need to be a security-related change to the Python packaging guidelines, covering the appropriate use of isolated mode: http://docs.python.org/3/whatsnew/3.4.html#whatsnew-isolated-mode What do you have in mind regarding packaging guidelines? There's also a simpler workaround for the issues with the standard streams when running things in the POSIX locale: setting PYTHONIOENCODING=:surrogateescape will deal with it for user mode scripts. Cheers, Nick. Just BTW me and Matej Stuchlik are working on builds of Python 3.4 in Copr [1]. Everything got a bit more complex due to ensurepip: - python3 should have Requires: python3-setuptools python3-pip (this has already been discussed previously on this list, just mentioning) - I've created the rewheel library [2] that has a simple purpose of being able to repack a wheel from system-installed wheels - this means that we need system setuptools and pip packaged as wheels (packaging as wheels has not been standardized yet, so I'm just approaching it from the best angle I could come up with, see patches [3] and [4]) - to package system setuptools and pip as wheels, we first need to package them as normal packages, because we need these packages to be able to create wheels :) - which creates a nice dependency/boostraping cycle: 1) build python3 (no requires on setuptools or pip) 2) build python3-setuptools and python3-pip as normal python packages (not wheels) 3) build python3-wheel (we don't need this to be wheel-in-RPM ATM) 4) build python3-setuptools and python-pip (as wheel-in-RPM) 5) build python3 (add Requires: python3-setuptools, python3-pip) I've got example patches of building setuptools and pip as wheel-in-RPM at [3] and [4] (note that the pip patch also contains some downstream only patches that I've created to achieve what we need; upstream won't probably accept them in this precise format, but the functionality should get upstream in some form). Right now, we're working on integrating rewheel into ensurepip (a patch for that is at [5] - it's for beta4 IIRC). We'll keep this list posted on the progress. When we manage to make this whole process work satisfiably, we'll: 1) formally document the whole process described above 2) start discussing options of accepting rewheel in Python upstream 3) start rebuilding more python3-* packages in the Copr repo to make sure that nothing (or nearly nothing) breaks and we can actually go on with the proposed Fedora Change And then we'd like to concentrate on the Python3-as-a-default switch for a while. Hope this all makes sense, all comments/suggestions are appreciated. Slavek. [1] http://copr.fedoraproject.org/coprs/bkabrda/python-3.4/builds/ [2] https://github.com/bkabrda/rewheel [3] https://github.com/bkabrda/rewheel/blob/master/python-setuptools-spec.patch [4] https://github.com/bkabrda/rewheel/blob/master/python-pip-spec.patch [5] https://github.com/bkabrda/rewheel/blob/master/ensurepip-rewheel.patch ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
