Re: Multirelease effort: Moving to Python 3
On 07/19/2013 05:44 AM, Toshio Kuratomi wrote: On Jul 18, 2013 5:42 PM, Michael Catanzaro mike.catanz...@gmail.com mailto:mike.catanz...@gmail.com wrote: On Thu, 2013-07-18 at 09:53 -0700, Toshio Kuratomi wrote: /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this But when python2 is no longer installed by default, surely you want to get a python prompt when you type 'python'? Yes, and for a long time, I'm going to want to get a python2 prompt. Which means installing the package for python2, not having python3 start on that case. Why do you want to use old version as default? That's very conservative approach for Fedora ;-) Upstream plans to support it until 2015 (maybe little longer). Fedora needs to be prepared for such step, so it's the right time to start working on it. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
- Original Message - On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote: Hi all, as a new Fedora Python maintainer, I have set myself a goal of moving Fedora to Python 3 as a default. I'm not sure we want to make python3 default depending on what your definition of default is. /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this So, my definition of default is all system tools use Python 3, it is the only Python that gets to minimal buildroot/minimal Fedora installation - that means: - livecd can still ship Python 2 - /usr/bin/python points to Python 3 - Please note, that the pep you're referring to also states that python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions, so this wouldn't really be going against the pep. The python package itself should probably also remain python2 due to dependencies and expectations from other distros and documentation -- I think I'd be -1 to changing this The Fedora live images contain only python3, not python2 -- I'd be heavily in favour of this. +1 This is going to be a multirelease effort that is going to affect lots of Fedora parts. Since we will need to switch default package manager from Yum to DNF (which is supposed to work with Python 3), we will need to wait for that. I've been told that DNF should be default in F22, so that's my target, too. That should also give everyone else plenty of time to work on other essential packages to make this happen. Getting there at the same time as we get to DNF sounds like a good timeline. (But see my note on anaconda below). +1 Here is my analysis/proposal: Before switching, we need to make sure that everything important (*) is Python 3 compatible. There are three steps I see in this transition: 1) Getting rid of Python 2 in mock minimal buildroot. I'm not sure about this one as it will cause a lot of package churn. It might be a necessary pain pointi or it might be a pain point we want to defer until later in our porting efforts. Have to think about it more. If you look at the minimal mock buildroot for rawhide now, the only thing that is drawing in Python is gdb because of it's Python bindings (if I'm not mistaken). So compiling GDB against Python 3, which should work with newest gdb, will accomplish this AFAICS. 2) Porting Anaconda to Python 3. +1 -- unfortunately, this probably depends on DNF So we may need to push DNF in F22 and anaconda compatible with python3 in F23. DNF is a continuous effort. I believe that DNF will provide it's Python 3 bindings sooner than in F22, so Anaconda devels can simultaneously do porting to Python 3 as well as to DNF. IMO this is good thing, since they will just do one big rewrite instead of two smaller. 3) Making all livecd packages depend on Python 3 by default (and eventually getting rid of Python 2 from livecd) - this will also require switching from Yum to DNF as a default, that is supposed to support Python 3. +1 -- this is what I see as the eventual goal (or perhaps, livecd python2 free followed by DVD python2 free followed by distro python2 free). 3.5) Switch tools that could target either python2 or python3 to target python3. Currently the packaging guidelines say to target python2 to control dep proliferation and because that's the most supported by the larger python ecosystem. We should switch the recommendation when our minimal environment must have python3 but does not need to have python2. IMO we should switch this for F21, since livecd ships Python 3 anyway, so the switch doesn't have to happen in one point, but can be continuous. ( 4) Making as much of the remaining packages Python 3 compatible ) We could talk quite a bit on this point -- How active do we want to be with the things that aren't in one of the essential buckets from further up. We could defer thinking about this until after we get the livecd python2-free, though. This is really the last step, that is somehow tied what you mentioned as a reaction to 3) - going through the rest of packages on DVD and then whole distro. This will take few more releases I guess, but it is not that important as sorting out livecd. In past few days, I've been going through packages that are part of the above steps. I have reported numerous bugs asking upstream and/or Fedora maintainers for help with porting to Python 3. We have some spare cycles in our small Python packaging team, that we will try to provide to whoever needs them most, but we're limited and we'll have to rely on the upstreams to do most of the work. I'm attaching a document with list of packages that need porting with some notes/links to opened bugs. Sometime soon, I'll open a tracking bug for this, so that everyone can see where we are quickly. (*) I call
Re: Multirelease effort: Moving to Python 3
On 19. 7. 2013 at 02:41:23, Bohuslav Kabrda wrote: ... snip ... +1 -- unfortunately, this probably depends on DNF So we may need to push DNF in F22 and anaconda compatible with python3 in F23. DNF is a continuous effort. I believe that DNF will provide it's Python 3 bindings sooner than in F22, so Anaconda devels can simultaneously do porting to Python 3 as well as to DNF. IMO this is good thing, since they will just do one big rewrite instead of two smaller. That's right, we are already working on the API stabilization and testing dnf with Anaconda is one part of the entire effort. However there is only so much we can do ourselves. Stronger participation of the Anaconda team is required, as we need to know what parts are they missing and what parts need improving. ... snip ... Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Koji down?
Getting this when connecting to http://koji.fedoraproject.org/koji --- Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, ad...@fedoraproject.org and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.2.15 (Red Hat) Server at koji.fedoraproject.org Port 80 Kind regards Joachim Backes -- Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.9-302.fc19.x86_64 Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji down?
On Fri, 2013-07-19 at 09:03 +0200, Joachim Backes wrote: Getting this when connecting to http://koji.fedoraproject.org/koji --- Internal Server Error It's a planned outage: $ koji --debug moshimoshi [... snip ...] koji.ServerOffline: Planned outage for storage move. See: https://fedorahosted.org/fedora-infrastructure/ticket/3882 -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Koji down?
On 19/07/13 08:03, Joachim Backes wrote: Getting this when connecting to http://koji.fedoraproject.org/koji --- Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, ad...@fedoraproject.org and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.2.15 (Red Hat) Server at koji.fedoraproject.org Port 80 Storage migration http://status.fedoraproject.org/ https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001176.html Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Virtual provides for files in /var/log
On 07/18/2013 11:35 PM, Bill Nottingham wrote: Panu Matilainen (pmati...@laiskiainen.org) said: So... /var/log/messages is not guaranteed to be there even now, because it depends on rsyslog configuration. So any packages which cannot handle missing /var/log/messages are broken already in a non-default (but probably not all that uncommon) config, and nobody is crying out about that. Yes, it's just that if we're moving these packages from being broken in a non-default, administrator-configured configuration to being broken in the out-of-the-box configuration, it might be worthwhile to know that ahead of time, or know if there's a way to have them indicate that they now require the non-default configuration. Yes, I understand the point behind this, its just that a pair of (file) dependencies doesn't really make things just work either. A file provide basically says this package contains file X, but here the presence of the promised file depends on a service configuration *and* that the service is running (and has been so for some time). The file presence could be ensured by doing 'touch /var/log/message' in %post, but that doesn't make the file any more usable in the sense eg hplip and lvm2 seem to expect. Then there's the question (raised by Lennart) of what eg yum will do with virtual file dependencies outside the normal paths, plus some other (perhaps academic in this context) issues wrt virtual file provides vs real files. I guess all I'm saying that if dependencies are going to be used to address the problem, a non-file dependency seems like a better option to me. Perhaps Provides: logfile(messages) or such. That way depsolvers will know full filelists will not be needed to resolve it, its easily distinguishable and the semantics it represents can be clearly documented. I guess it's the equivalent of marking packages that don't work unless SELinux is enabled, or don't work unless the firewall is off. There are likely better ways to fix them. Yeah... Log analyzers are one thing, but I dont know what eg hplip and lvm2 are doing with the info scraped out of /var/log/messages, it seems somewhat suspect at least. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Apache OpenOffice
On Wed, Jul 17, 2013 at 12:54:10PM +0200, Jaroslav Reznik wrote: = Proposed Self Contained Change: Apache OpenOffice = https://fedoraproject.org/wiki/Changes/ApacheOpenOffice Change owner(s): Andrea Pescetti pesce...@apache.org Add Apache OpenOffice [1], the free productivity suite, to Fedora. == Detailed description == Apache OpenOffice (formerly OpenOffice.org) is an extremely popular free and open- source office software suite. Donated by Oracle to the Apache Software Foundation in 2011, it is now developed and supported by a thriving community; it graduated from the Apache Incubator in October 2012 and it is now an Apache Top-Level Project. Apache OpenOffice 4.0, due in the last decade of July 2013, is a major update. The two new versions (3.4.0 and 3.4.1) released in 2012 under the Apache guidance totalled 60 million downloads so far, not counting mirrors. To be clear, this proposal is about merely adding Apache OpenOffice: it doesn't affect existing office suites included in Fedora and it doesn't require that Apache OpenOffice is made the default office suite in Fedora. == Scope == Proposal owners: Packaging is the main issue here. The default OpenOffice build process produces RPM packages, but there are major changes to be done to obtain a set of RPM packages and matching SRPMs suitable for inclusion in Fedora. One of my specific request therew is make sure that they link to the system libraries instead of relying on the embedded version used e.g. for Windows build. Very specifically make sure libxml2 etc... is not provided by static version inside but uses the system one (so we don't have to push Apache OpenOffice too if there is a libxml2 security errata !) Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Vagrant
On Thu, Jul 18, 2013 at 5:30 PM, Matthew Miller mat...@fedoraproject.org wrote: If we're confident that the feature will get into upstream when the unreleased version finally comes out, and if this is really the last blocker, we may be able to get an exception to the bundled libraries policy. (This is one of the listed cases for a possible exception.) Or add the required patch to the package to provide the missing method? It will be removed at the next upstream release anyway. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On 07/18/2013 06:53 PM, Toshio Kuratomi wrote: /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this Quoting from this PEP: python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions I always thought that Fedora (and especially rawhide) is bleading edge distribution :) -- Miroslav Suchy Red Hat, Software Engineer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 08:20:02AM +0200, Marcela Mašláňová wrote: On 07/19/2013 05:44 AM, Toshio Kuratomi wrote: On Jul 18, 2013 5:42 PM, Michael Catanzaro mike.catanz...@gmail.com mailto:mike.catanz...@gmail.com wrote: On Thu, 2013-07-18 at 09:53 -0700, Toshio Kuratomi wrote: /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this But when python2 is no longer installed by default, surely you want to get a python prompt when you type 'python'? Yes, and for a long time, I'm going to want to get a python2 prompt. Which means installing the package for python2, not having python3 start on that case. Why do you want to use old version as default? That's very conservative approach for Fedora ;-) This is not just about porting packages that Fedora is shipping. There are a quadrillion and one random scripts out in the wild with #!/usr/bin/python in them, that only work with python2. If Fedora makes /usr/bin/python be a python3 interpretor, we'll break pretty much all of them. I don't think we want to be doing that for a very long time yet, if ever. Far better to encourage people to explicitly use /usr/bin/python2 and /usr/bin/python3 explicitly and discourage any use of plain /usr/bin/python, but definitely not change the semantics of the latter. Upstream plans to support it until 2015 (maybe little longer). Fedora needs to be prepared for such step, so it's the right time to start working on it. Given the amount of python2 code out there, I wouldn't be at all surprised if someone steps up to maintain python2 beyond the date at which its current maintainer ceases work. Of course such maintainence work would likely be important bug fixes security updates only, not feature work. So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
Hi all,
as a new Fedora Python maintainer, I have set myself a goal of moving Fedora
to Python 3 as a default. This is going to be a multirelease effort that is
going to affect lots of Fedora parts. Since we will need to switch default
package manager from Yum to DNF (which is supposed to work with Python 3), we
will need to wait for that. I've been told that DNF should be default in F22,
so that's my target, too. That should also give everyone else plenty of time
to work on other essential packages to make this happen.
Here is my analysis/proposal:
Before switching, we need to make sure that everything important (*) is
Python 3 compatible. There are three steps I see in this transition:
1) Getting rid of Python 2 in mock minimal buildroot.
2) Porting Anaconda to Python 3.
3) Making all livecd packages depend on Python 3 by default (and eventually
getting rid of Python 2 from livecd) - this will also require switching from
Yum to DNF as a default, that is supposed to support Python 3.
( 4) Making as much of the remaining packages Python 3 compatible )
If we do any work on python3 conversions, it must be done in the context
of respective upstream projects, and not a Fedora custom addon. It will
also quite likely require non-negligable dev resources to make a big dent
in it. It is unlikely to be as simple as just telling upstream to run 2to3,
because a great many upstreams are going to want to provide ongoing support
for both Python2 and Python3 to satisfy non cutting edge distros.
From packaging point of view, this will probably require:
1) Renaming python package to python2
Renaming this is fine, particularly if we also add a Provides: python
2) Renaming python3 package to python
This is a bad idea IMHO. Python3 is not upgrade compatible with functionality
previously provided in the current python package. So such a rename is going
to needlessly cause pain suffering.
3) Switching the %{?with_python3} conditionals in specfiles to
%{?with_python2}
(we will probably create a script to automate this, at least partially)
I don't think we need do any automated conversion of that sort. It is perfectly
reasonable for packages to in fact have both %{with_python3} and %{with_python2}
conditionals present. By all means add %{with_python2} to allow builds without
the legacy python2 stuff, but no need to blanket remove %{with_python3} - leave
it upto the maintainer to decide if they wish to have conditionals for this, or
unconditionally build both.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Application Installer
So, do I understand you correctly that you as Yum/Dnf guys would be ok to have a different backend for GUI and non-GUI use cases as mentioned in this thread and agreed by FESCo previously? I'd be more than happy to see your sign off for this change and state this too there. Well, it's a bit more complicated than that. Obviously there would be a problem with both programs offering different combinations of packages in some cases. But combined with the fact that the use case/target group of users (applications vs. packages) is different for both, I don't think it would be that much of an issue. Wouldn't it be easier to keep gpk-application and gpk-update-viewer installed and set as default applications, and provide AppInstaller as an alternative, experimental program (also installed by default, perhaps)? In F20 conservative users could continue using gpk-* and interested users could start playing with AppInstaller. In F21 AppInstaller can be deemed stable and gpk-* can be removed from the default install. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Le Jeu 18 juillet 2013 16:08, Lennart Poettering a écrit : But anyway, I understand you like ISO, and think it is readable. I don't agree, but we just have to agree to disagree on this one. It might thrill you though to learn that I just commited a patch by Tomasz that adds an ISO output mode to journalctl. journalctl -o short-iso is your friend. Thank you very much (and Tomasz of course), that's awesome turnaround. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Application Installer
On Fri, Jul 19, 2013 at 1:02 PM, Kamil Paral kpa...@redhat.com wrote: So, do I understand you correctly that you as Yum/Dnf guys would be ok to have a different backend for GUI and non-GUI use cases as mentioned in this thread and agreed by FESCo previously? I'd be more than happy to see your sign off for this change and state this too there. Well, it's a bit more complicated than that. Obviously there would be a problem with both programs offering different combinations of packages in some cases. But combined with the fact that the use case/target group of users (applications vs. packages) is different for both, I don't think it would be that much of an issue. Wouldn't it be easier to keep gpk-application and gpk-update-viewer installed and set as default applications, and provide AppInstaller as an alternative, experimental program (also installed by default, perhaps)? In F20 conservative users could continue using gpk-* and interested users could start playing with AppInstaller. In F21 AppInstaller can be deemed stable and gpk-* can be removed from the default install. No .. having two completely different user interfaces / experiences for the same thing does not make much sense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Application Installer
On 15 July 2013 16:07, Jan Zelený jzel...@redhat.com wrote: Another option would be to make the new PK (or just the backend if possible) optional for now and make it default together with dnf replacing yum. However I strongly suspect that neither of these two proposals are acceptable for Richard. Well, although gnome-software works with the yum backend, it performs very badly and the UX is terrible. I'm not sure I'd want gnome-software by default with yum as a backend. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
From: berra...@redhat.com Far better to encourage people to explicitly use /usr/bin/python2 and /usr/bin/python3 explicitly and discourage any use of plain /usr/bin/python, but definitely not change the semantics of the latter. I think this is by far the best thing to do. After all import this says: Explicit is better than implicit. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Virtual provides for files in /var/log
On Fri, Jul 19, 2013 at 10:26:24AM +0300, Panu Matilainen wrote: Yeah... Log analyzers are one thing, but I dont know what eg hplip and lvm2 are doing with the info scraped out of /var/log/messages, it seems somewhat suspect at least. They're just gathering it into a diagnostic report -- not used for normal functioning. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Application Installer
On Fri, 2013-07-19 at 07:02 -0400, Kamil Paral wrote: So, do I understand you correctly that you as Yum/Dnf guys would be ok to have a different backend for GUI and non-GUI use cases as mentioned in this thread and agreed by FESCo previously? I'd be more than happy to see your sign off for this change and state this too there. Well, it's a bit more complicated than that. Obviously there would be a problem with both programs offering different combinations of packages in some cases. But combined with the fact that the use case/target group of users (applications vs. packages) is different for both, I don't think it would be that much of an issue. Wouldn't it be easier to keep gpk-application and gpk-update-viewer installed and set as default applications, and provide AppInstaller as an alternative, experimental program (also installed by default, perhaps)? In F20 conservative users could continue using gpk-* and interested users could start playing with AppInstaller. In F21 AppInstaller can be deemed stable and gpk-* can be removed from the default install. This is the contingency plan. Depending on how far we get with the new application, it may well be enacted - the goals are pretty ambitious... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to create a new mailing list at lists.fedoraproject.org
Hi, I want to create a new mailing list for kexec/kdump related discussions in fedora. How do I go about it. I try to create one here but it asks for List creator's password. I don't have any such password. So who is authorized to create the list and can he/she create one for me? Thanks Vivek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to create a new mailing list at lists.fedoraproject.org
Hi! On Jul 19, 2013 7:12 AM, Vivek Goyal vgo...@redhat.com wrote: Hi, I want to create a new mailing list for kexec/kdump related discussions in fedora. How do I go about it. I try to create one here but it asks for List creator's password. I don't have any such password. So who is authorized to create the list and can he/she create one for me? File a ticket against the Mailing Lists component in Fedora Infrastructure's trac instance: https://fedorahosted.org/fedora-infrastructure/ -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
Le Ven 19 juillet 2013 17:04, Tomas Mraz a écrit : On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. +1 Breaking completely needlessly backwards compatibility this way is really not a good idea. OTOH, it's better to give a heads-up this way (with the option to change shebangs as short-term workaround) than drop users cold at python2 removal time (which *will* eventually come). Some people really need some breakage to notice they're missing a migration. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: On Fri, Jul 19, 2013 at 08:20:02AM +0200, Marcela Mašláňová wrote: On 07/19/2013 05:44 AM, Toshio Kuratomi wrote: On Jul 18, 2013 5:42 PM, Michael Catanzaro mike.catanz...@gmail.com mailto:mike.catanz...@gmail.com wrote: On Thu, 2013-07-18 at 09:53 -0700, Toshio Kuratomi wrote: /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this But when python2 is no longer installed by default, surely you want to get a python prompt when you type 'python'? Yes, and for a long time, I'm going to want to get a python2 prompt. Which means installing the package for python2, not having python3 start on that case. Why do you want to use old version as default? That's very conservative approach for Fedora ;-) This is not just about porting packages that Fedora is shipping. There are a quadrillion and one random scripts out in the wild with #!/usr/bin/python in them, that only work with python2. If Fedora makes /usr/bin/python be a python3 interpretor, we'll break pretty much all of them. I don't think we want to be doing that for a very long time yet, if ever. Far better to encourage people to explicitly use /usr/bin/python2 and /usr/bin/python3 explicitly and discourage any use of plain /usr/bin/python, but definitely not change the semantics of the latter. Upstream plans to support it until 2015 (maybe little longer). Fedora needs to be prepared for such step, so it's the right time to start working on it. Given the amount of python2 code out there, I wouldn't be at all surprised if someone steps up to maintain python2 beyond the date at which its current maintainer ceases work. Of course such maintainence work would likely be important bug fixes security updates only, not feature work. So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. +1 Breaking completely needlessly backwards compatibility this way is really not a good idea. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
From: nicolas.mail...@laposte.net Le Ven 19 juillet 2013 17:04, Tomas Mraz a écrit : On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. +1 Breaking completely needlessly backwards compatibility this way is really not a good idea. OTOH, it's better to give a heads-up this way (with the option to change shebangs as short-term workaround) than drop users cold at python2 removal time (which *will* eventually come). Some people really need some breakage to notice they're missing a migration. Excellent point! If I were caught unaware, I'd much rather have to fix up a bunch shebang lines and learn that I need to get going on my migration pronto than the alternative of finding one day that python2 is just gone where one is left with either a hurried port or downloading python2 from external sources. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AutoQA Testcase Stats
I've been working to revamp the AutoQA infrastructure so that we're not running completely on F17 clients and after building several new client machines in staging, I was curious about how well the tests were running on the new client machines. I've included the numbers below but 2 things jump out at me: - #438 is causing problems for repoclosure - there is a problem with depcheck on f19. the only runs that didn't crash are the ones without any builds in them. The crash looks consistent but I don't know what the root cause is. Note that these numbers reflect execution in staging autotest since I rebuilt the clients (including the queued jobs that weren't run while rebuilding), not pass/fail results and not from production. I was only interested in numbers about execution of the tests (GOOD - executed cleanly, reported results. ERROR - problems in execution, probably didn't report results) Tim Global Stats 2077 Jobs - 535 fc17 - 760 fc18 - 781 fc19 Crashes --- 227 Crashes - 0 fc17 - 80 fc18 - 147 fc19 Passes --- 1849 Passes - 535 fc17 - 680 fc18 - 634 fc19 Test Specific Stats === depcheck 363 runs ( 167 GOOD, 196 ERROR ) - 84 fc17 runs ( 84 GOOD, 0 ERROR ) - 151 fc18 runs ( 75 GOOD, 76 ERROR ) - 128 fc19 runs ( 8 GOOD, 120 ERROR ) repoclosure 48 runs ( 27 GOOD, 21 ERROR ) - 7 fc17 runs ( 7 GOOD, 0 ERROR ) - 20 fc18 runs ( 20 GOOD, 0 ERROR ) - 21 fc19 runs ( 0 GOOD, 21 ERROR ) rpmguard 795 runs ( 790 GOOD, 5 ERROR ) - 202 fc17 runs ( 202 GOOD, 0 ERROR ) - 270 fc18 runs ( 268 GOOD, 2 ERROR ) - 323 fc19 runs ( 320 GOOD, 3 ERROR ) rpmlint 795 runs ( 790 GOOD, 5 ERROR ) - 220 fc17 runs ( 220 GOOD, 0 ERROR ) - 301 fc18 runs ( 299 GOOD, 2 ERROR ) - 274 fc19 runs ( 271 GOOD, 3 ERROR ) upgradepath 75 runs ( 75 GOOD, 0 ERROR ) - 22 fc17 runs ( 22 GOOD, 0 ERROR ) - 18 fc18 runs ( 18 GOOD, 0 ERROR ) - 35 fc19 runs ( 35 GOOD, 0 ERROR ) signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
[AutoQA] #439: depcheck crashes almost every time on fc19
#439: depcheck crashes almost every time on fc19
-+--
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: Depcheck
Component: tests | Keywords:
Blocked By: | Blocking:
-+--
While upgrading clients to fc18 and fc19 in staging, I noticed that there
were a lot of depcheck crashes on the fc19 clients (120/128 runs crashed).
Example job:
http://autoqa-stg.fedoraproject.org/results/238990-autotest/
Traceback:
{{{
Traceback (most recent call last):
File ./depcheck, line 112, in module
profile=opts.profile)
File /usr/share/autotest/tests/depcheck/depcheck_lib.py, line 394,
in depcheck_main
test_dir=temp_dir, accepted_dir=acc_dir)
File /usr/share/autotest/tests/depcheck/depcheck_lib.py, line 338,
in do_depcheck
do_mash(test_dir, mash_arches)
File /usr/share/autotest/tests/depcheck/depcheck_lib.py, line 157,
in do_mash
rc = themash.doMultilib()
File /usr/lib/python2.7/site-packages/mash/__init__.py, line 592, in
doMultilib
pid = self.doDepSolveAndMultilib(arch, repocache)
File /usr/lib/python2.7/site-packages/mash/__init__.py, line 465, in
doDepSolveAndMultilib
self.config.rpm_path % {'arch':arch})
File /usr/lib64/python2.7/posixpath.py, line 75, in join
if b.startswith('/'):
AttributeError: 'NoneType' object has no attribute 'startswith'
Traceback (most recent call last):
File ./depcheck, line 112, in module
profile=opts.profile)
File /usr/share/autotest/tests/depcheck/depcheck_lib.py, line 394,
in depcheck_main
test_dir=temp_dir, accepted_dir=acc_dir)
File /usr/share/autotest/tests/depcheck/depcheck_lib.py, line 341,
in do_depcheck
y.pkgSack # populates all package sacks
File /usr/lib/python2.7/site-packages/yum/__init__.py, line 1050, in
lambda
pkgSack = property(fget=lambda self: self._getSacks(),
File /usr/lib/python2.7/site-packages/yum/__init__.py, line 770, in
_getSacks
self.repos.populateSack(which=repos)
File /usr/lib/python2.7/site-packages/yum/repos.py, line 387, in
populateSack
sack.populate(repo, mdtype, callback, cacheonly)
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 224, in
populate
if self._check_db_version(repo, mydbtype):
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 316, in
_check_db_version
return repo._check_db_version(mdtype)
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1483, in
_check_db_version
repoXML = self.repoXML
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1669, in
lambda
repoXML = property(fget=lambda self: self._getRepoXML(),
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1665, in
_getRepoXML
self._loadRepoXML(text=self.ui_id)
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1656, in
_loadRepoXML
return self._groupLoadRepoXML(text, self._mdpolicy2mdtypes())
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1630, in
_groupLoadRepoXML
if self._commonLoadRepoXML(text):
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1455, in
_commonLoadRepoXML
result = self._getFileRepoXML(local, text)
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1233, in
_getFileRepoXML
size=102400) # setting max size as 100K
File /usr/lib/python2.7/site-packages/yum/yumRepo.py, line 1029, in
_getFile
raise Errors.NoMoreMirrorsRepoError(errstr, errors)
yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from
pending: [Errno 256] No more mirrors to try.
file:///tmp/depcheck.oEfOtO/repodata/repomd.xml: [Errno 14] curl#37 -
Couldn't open file /tmp/depcheck.oEfOtO/repodata/repomd.xml
}}}
--
Ticket URL: https://fedorahosted.org/autoqa/ticket/439
AutoQA http://autoqa.fedorahosted.org
Automated QA project
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 05:16:03PM +0200, Nicolas Mailhot wrote: Le Ven 19 juillet 2013 17:04, Tomas Mraz a écrit : On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. +1 Breaking completely needlessly backwards compatibility this way is really not a good idea. OTOH, it's better to give a heads-up this way (with the option to change shebangs as short-term workaround) than drop users cold at python2 removal time (which *will* eventually come). Some people really need some breakage to notice they're missing a migration. I don't think we're anywhere near the point in time where such an approach is worth the pain it will inflict on people. As above, I'm pretty sceptical that maintainence of Python2 is actually going to stop in 2015, as I think there are too many people and/or organizations who will find they have reasons for wanting to stick on python2 for a long time. Maybe I'll be proved wrong on this in time, but I doubt it, as there's far too many prior examples of people/companies sticking with ancient software versions because the cost of maintaining them is less than the cost of porting them. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, 2013-07-19 at 11:24 -0400, john.flor...@dart.biz wrote: From: nicolas.mail...@laposte.net Le Ven 19 juillet 2013 17:04, Tomas Mraz a écrit : On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. +1 Breaking completely needlessly backwards compatibility this way is really not a good idea. OTOH, it's better to give a heads-up this way (with the option to change shebangs as short-term workaround) than drop users cold at python2 removal time (which *will* eventually come). Some people really need some breakage to notice they're missing a migration. Excellent point! If I were caught unaware, I'd much rather have to fix up a bunch shebang lines and learn that I need to get going on my migration pronto than the alternative of finding one day that python2 is just gone where one is left with either a hurried port or downloading python2 from external sources. The heads-up can be done before the python2 dropping by removing /usr/bin/python from python2 package. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Thu, 2013-07-18 at 21:37 -0400, Ding Yi Chen wrote: Exactly - adding to the minimal install is generally always a supported operation. Removing from the minimal install is always a 'buyer beware' or 'you get both pieces' operation. Didn't Jesse Keating said something like we don't offer minimal install other than uncheck the all boxes? I doubt Jesse would say that, and if he did, he'd be wrong: it's a primary group in the package selection spoke of an equal status with GNOME, KDE etc. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Application Installer
On Fri, 2013-07-19 at 07:02 -0400, Kamil Paral wrote: So, do I understand you correctly that you as Yum/Dnf guys would be ok to have a different backend for GUI and non-GUI use cases as mentioned in this thread and agreed by FESCo previously? I'd be more than happy to see your sign off for this change and state this too there. Well, it's a bit more complicated than that. Obviously there would be a problem with both programs offering different combinations of packages in some cases. But combined with the fact that the use case/target group of users (applications vs. packages) is different for both, I don't think it would be that much of an issue. Wouldn't it be easier to keep gpk-application and gpk-update-viewer installed and set as default applications, and provide AppInstaller as an alternative, experimental program (also installed by default, perhaps)? It might be easier, but it'd probably suck more. gpk-application is pretty crappy, let's face it. It looks pretty bad if you compare it with just about any other distro's graphical package/app manager tools. This is something we are regularly dinged on in reviews. IMHO the sooner we replace it with something better, the...better. (And I'd hate to go another release without resolving https://bugzilla.redhat.com/show_bug.cgi?id=863592 , just to bang that drum again). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Fri, Jul 19, 2013 at 10:37 AM, Adam Williamson awill...@redhat.comwrote: On Thu, 2013-07-18 at 21:37 -0400, Ding Yi Chen wrote: Exactly - adding to the minimal install is generally always a supported operation. Removing from the minimal install is always a 'buyer beware' or 'you get both pieces' operation. Didn't Jesse Keating said something like we don't offer minimal install other than uncheck the all boxes? I doubt Jesse would say that, and if he did, he'd be wrong: it's a primary group in the package selection spoke of an equal status with GNOME, KDE etc. Perhaps there should be a Least Possible Bootable install for situations like this. I would agree Syslog should be missing from such an install. Just not from Default -- Not until journalctl and systemd attain ubiquity.. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 10:17:51AM +0100, Daniel P. Berrange wrote: Far better to encourage people to explicitly use /usr/bin/python2 and /usr/bin/python3 explicitly and discourage any use of plain /usr/bin/python, but definitely not change the semantics of the latter. +1*10^6 Upstream plans to support it until 2015 (maybe little longer). Fedora needs to be prepared for such step, so it's the right time to start working on it. Given the amount of python2 code out there, I wouldn't be at all surprised if someone steps up to maintain python2 beyond the date at which its current maintainer ceases work. Of course such maintainence work would likely be important bug fixes security updates only, not feature work. So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. nod At this time, I'm pretty sure that someone will step up to maintain python2 packages in all major distros after the 2015 date that upstream stops supporting a CPython2. There's several different ways that could shake out -- * Distros independently maintain python2 packages * Distros get together and maintain python2 as a unified project. Possibly even using the CPython upstream revision control system and issue tracker. * Distros switch to alternate implementations of python2 (such as pypy) for their python2 compatible code. It's too early for me to tell which of these is likely to happen. It depends mostly on how important python2 still is when upstream CPython finally decides to stop supporting python2. -Toshio pgpFIEaMi4RuP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
From: tm...@redhat.com On Fri, 2013-07-19 at 11:24 -0400, john.flor...@dart.biz wrote: From: nicolas.mail...@laposte.net Le Ven 19 juillet 2013 17:04, Tomas Mraz a écrit : On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. +1 Breaking completely needlessly backwards compatibility this way is really not a good idea. OTOH, it's better to give a heads-up this way (with the option to change shebangs as short-term workaround) than drop users cold at python2 removal time (which *will* eventually come). Some people really need some breakage to notice they're missing a migration. Excellent point! If I were caught unaware, I'd much rather have to fix up a bunch shebang lines and learn that I need to get going on my migration pronto than the alternative of finding one day that python2 is just gone where one is left with either a hurried port or downloading python2 from external sources. The heads-up can be done before the python2 dropping by removing /usr/bin/python from python2 package. Ah, true indeed. However, I still like the idea of being explicit. If you want py2, say so in the shebang line. Likewise with py3. How can we get the very blunt head's up and be explicit too? I have no idea when py2 will truly go away, but I'm convinced it will eventually and I'd like to create my works in the best possible fashion. Thus far I've relied on the implicit py-py2 and explicit py3 invocations as that's the way I've seen Fedora set examples, but I think this should really be more detailed in the packaging guidelines. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
Le Ven 19 juillet 2013 17:30, Daniel P. Berrange a écrit : On Fri, Jul 19, 2013 at 05:16:03PM +0200, Nicolas Mailhot wrote: Le Ven 19 juillet 2013 17:04, Tomas Mraz a écrit : On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: So while I encourage a Fedora effort to get onto Python3 by default, well before 2015, I don't think we should assume that Python2 support is definitely going to stop in 2015. +1 Breaking completely needlessly backwards compatibility this way is really not a good idea. OTOH, it's better to give a heads-up this way (with the option to change shebangs as short-term workaround) than drop users cold at python2 removal time (which *will* eventually come). Some people really need some breakage to notice they're missing a migration. I don't think we're anywhere near the point in time where such an approach is worth the pain it will inflict on people. As above, I'm pretty sceptical that maintainence of Python2 is actually going to stop in 2015, as I think there are too many people and/or organizations who will find they have reasons for wanting to stick on python2 for a long time. Maybe I'll be proved wrong on this in time, but I doubt it, as there's far too many prior examples of people/companies sticking with ancient software versions because the cost of maintaining them is less than the cost of porting them. Well, in practical terms if you want to do it graciously you need time of python renaming in fedora = fedora python2 removal time - one rhel cycle because some people won't migrate before their stuff is broken in an enterprise distro, so for the heads up to be effective it needs to be advertised a full rhel cycle -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 08:20:02AM +0200, Marcela Mašláňová wrote: On 07/19/2013 05:44 AM, Toshio Kuratomi wrote: On Jul 18, 2013 5:42 PM, Michael Catanzaro mike.catanz...@gmail.com mailto:mike.catanz...@gmail.com wrote: On Thu, 2013-07-18 at 09:53 -0700, Toshio Kuratomi wrote: /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this But when python2 is no longer installed by default, surely you want to get a python prompt when you type 'python'? Yes, and for a long time, I'm going to want to get a python2 prompt. Which means installing the package for python2, not having python3 start on that case. Why do you want to use old version as default? That's very conservative approach for Fedora ;-) This is the wrong mental model of the relationship between python2 and python3. As a comparison this argument is akin to saying, C is the old version of C++. We should be porting all our code to use the C++ compiler in Fedora C is much more compatible to C++ than python2 is to python3 so this would be a less drastic change. python2 and python3 are separate languages. There is a lot of similarity between the two and with recent enough versions of python2 (2.7) and python3 (python3.4) and some external libraries (python-six) and by sticking to some specific coding styles ( http://python3porting.com/noconv.html ) and by sometimes resorting to having separate files for some python2-specific routines vs python3-specific routines you can write code that is valid and runs under either language. That does not mean that they are the same language. Upstream plans to support it until 2015 (maybe little longer). Fedora needs to be prepared for such step, so it's the right time to start working on it. I am wholeheartedly in favor of working on it. But things like switching the default /usr/bin/python are not working on it. Those are backwards incompatible, end user visible, changes of expectations that we do not need to implement now in order to be a leader. When people invoke python, they expect python2. When they want python3, they expect to type python3 to get that. At the moment, causing /usr/bin/python to invoke python3 is just going to cause confusion and end user confusion (arch is the only linux distro that sets /usr/bin/python to point to python3). As an example here, let's suppose that we were to stop shipping firefox by default and started shipping chromium instead. Would we make /usr/bin/firefox invoke /usr/bin/chromium? Would we have a firefox icon that started chromium when clicked? When applied here, it does seem to make more sense for end user's to notice that there isn't a firefox icon and either consciously open up a different web browser or else install firefox to get their preferred browsing experience, right? /usr/bin/python is the same way. People have tons of scripts on their systems with #!/usr/bin/python shebang lines. If we change /usr/bin/python to point to /usr/bin/python3 then we'll force them to deal with either porting, going through all their scripts and replacing them with /usr/bin/python2, or switching to another distribution which doesn't change the meanings of well known interpreter paths for no gain. All this is not to say that there might not be a time in the future when it makes sense to have python3 assume the /usr/bin/python name. However, that time is *after* the collective user consciousness has stopped using /usr/bin/python, not before. When we can go to pycon and talks are assumed to be targeting python3 rather than python2. After people wanting to do a simple calculation on the CLI stop doing /usr/bin/python -c 'print 5 + 6'. This is probably after alternate python implementations like pypy and jython either die off or finally make the switch to implementing python3. My guess is this will be after there's a RHEL release that includes /usr/bin/python3 in the default install since RHEL and CentOS are major parts of our ecosystem and will have to be able to use the python3 syntax on both their RHEL servers and Fedora machines. To some extent, this also depends on what other large distros set as their expectations: Debian and Ubuntu currently point /usr/bin/python to python2. AFAIK, only Arch is pointing to python3. My intuition is this will be at least two years after we stop shipping /usr/bin/python (pointing to python2) by default but this could be wrong -- it's about the expectations of the Fedora community and the Linux and python development communities as a whole. -Toshio pgpGdpRZhxmc2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable kdump on secureboot machines
On 07/11/2013 06:03 PM, Vivek Goyal wrote: It is but it implements stuff which is needed to meet TCB requirements. Current implementation is nowhere near to require secureboot requirements. For example, executables are not locked down in memory. That means after signature verification, if executable gets swapped out, it can be tweaked by root. Ah, okay, so for Trusted Boot, the onus is on the system administrator to make sure that he can provide attestation (by not running any dodgy binaries which would invalidate that), but for Security Boot, we have to prevent the system administrator to run such binaries. Makes sense. The important question is whether we can drop our own patches and switch to whatever upstream does when the time comes. I think we should be able to do that. We are expecting only /sbin/kexec to use this functionality and if things change we can change /sbin/kexec and signing process as we control everything. I think important thing will be to emphasize that other applications should not try to latch on to new keyctl() ioctl option to verify signature of a user space buffer or IMA functionality to put extra data in signature which locks down executable in memory. These are not stable interfaces and might disappear in next fedora release. Okay. There some potential ABI impact from the VM-related changes, but this shouldn't be a problem for Fedora. Is it time to re-visit the decision of locking down kernel on secureboot machine given the fact that upstream does not seem to like the idea. What are other distributions planning to do? Are they carrying additional patches or they have decided to go upstream way of not locking down kernel. I think they don't do any lockdown after boot. CAP_COMPROMISE_KERNEL (or what's it called these days) is a Fedora thing. Ok, I am not aware of details here but if blacklisting does not work already, then this concern is not specific to kdump. Once it starts working and I can blacklisted keys in blacklist keyring, I should be able to check for key in that keyring and disallow sys_kexec(). There are some potential approaches to blacklisting which would be incompatible with certain ways of signing binaries. So it's not immediately clear if an unrelated blacklisting service could be made to work with userspace signatures. So let's skip the blacklisting discussion for now. If we ever have to implement it, it's going to be messy, kexec or no kexec. (See the discussion about post-release media respins.) Like modules, /sbin/kexec will not use PKCS7 format. So it only knows about the key it has been signed with and expects that key to be loaded already. Ah, okay, that's an unfortunate upstream design decision. In this light, what you're planning to do seems fairly unavoidable. Have you considered a non-cryptographic solution, like a physical presence check to (temporarily) disable Secure Boot so that the kexec restriction no longer applies? This could be a fallback option if the original plan turns out to be too brittle/complex. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Enable kdump on secureboot machines
On Thu, Jul 18, 2013 at 08:51:36PM +0200, Miloslav Trmač wrote: On Thu, Jul 11, 2013 at 1:40 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Enable kdump on secureboot machines = https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot == Detailed description == /sbin/kexec prepares a binary blob, called purgatory. This code runs at priviliged level between kernel transition. With secureboot enabled, no unsigned code should run at privilige level 0, hence kexec/kdump is currently disabled if secureboot is enabled. One proposed way to solve the problem is that sign /sbin/kexec utility. And upon successful signature verification, allow it to load kernel, initramfs, and binary blob. /sbin/kexec will verify signatures of kernel being loaded before it asks running kernel to load it. For someone like me unfamiliar with kdump architecture, wouldn't it be possible to generate all relevant blobs (kdump kernel/initrd, ...) at kernel build time and sign them using essentially the existing module signing mechanism, and let the _kernel_ do all signature verification? Then /sbin/kexec wouldn't have to be trusted at all. === Build and ship ima-evm-utils package === /sbin/kexec will be signed by evmctl. This utility will put an xattr security.ima on /sbin/kexec file and kernel will leverage IMA infrastructure in kernel to verify signature of /sbin/kexec upon execution. (My motivation for the above question is that I view IMA (and any approach based on verifying only a pre-specified subset of files) as rather suspect, and that dm-verity makes much more sense to me for enforcing a trusted base OS. IIUC, dm-verity will just ensure that what was loaded from disk matches signature. It does not enforce any restrictions after that. That is make sure once signatures are verified, nothing unsgined can change the address space. So disable ptrace() from unsigned process, run executable run locked in from memory etc. IMA does not enforce this too. But it can possibly be enhanced to put some metadata in signature which says file needs to be executed locked in memory. And IMA will allow me to do it per file and we don't have to sign everything which is on disk. So for this use case where we want to sign only one thing, there is no need to make everything signed. Thanks Vivek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Mon, Jul 15, 2013 at 10:36 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: No Default Sendmail = https://fedoraproject.org/wiki/Changes/NoDefaultSendmail Change owner(s): Lennart Poettering lennart at poettering net, Matthew Miller mattdm at fedoraproject org No longer install an MTA by default. (Specifically let's remove sendmail from @core and @standard comps groups.) == Detailed description == Let's change the default install to no longer install an MTA by default. Specifically, let's remove sendmail from the @standard and @core group. On today's Internet most SMTP hosts do not accept mail from a server which is not configured as a mail exchange for a real domain, hence the default configuration of sendmail is seldom useful. We don't necessarily have to have a MTA always running, or listening on port 25. However, having the /usr/sbin/sendmail API available to applications is valuable - it brings a significant system administration benefit of centralizing the SMTP configuration. Every application[1] can be rewritten to have its own SMTP client and configuration instead of calling /usr/sbin/sendmail, sure, but the system administrators are much better off if the applications call /usr/sbin/sendmail and $whatever implementation handles that. This is not a packaging matter of adding Requires:/usr/sbin/sendmail - we get the benefit of centralization only if applications support /usr/sbin/sendmail , and have it configured as the default. Removing a provider of /usr/sbin/sendmail from the default installation entirely makes both of these application design choices problematic and unlikely. Mirek [1] GUIs and similar things targeted at people who don't want to deal with strings like /etc are probably excluded; think of servers, daemons and the like instead. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: Far better to encourage people to explicitly use /usr/bin/python2 and /usr/bin/python3 explicitly and discourage any use of plain /usr/bin/python Note the GNOME discussion here: https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg5.html One ugly part is that Debian Wheezy does not have python2. That combined with the Arch Linux people who made /usr/bin/python = python3 is a terrible mess for people who just want random portable scripts. For GNOME we decided to just try to ensure python2 always exists: https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00017.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Wed, Jul 17, 2013 at 2:20 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/17/2013 12:05 PM, Richard W.M. Jones wrote: On Wed, Jul 17, 2013 at 09:21:39AM +, Jóhann B. Guðmundsson wrote: On 07/17/2013 12:58 AM, Ding Yi Chen wrote: You still have not addressed the third party programs and scripts that monitor /var/log/messages We honestly cant keep progress and cleanup in the distribution back out of fear of breaking some third party programs. Irrespective of whether journald is good or bad, this is a dumb argument. Dumb I see so you have established a time frame for us how long we should hold back progress in the project and or you have devised an implementation plan on features and cleanups with a rate that a third party can keep up with in the distribution, maybe even chosen which third parties we wait for and which we dont? Progress does not that frequently depend on removing older functionality. Specifically in this case, removing rsyslog does not make journal in any way better. We as a community need to be able to set the pace for ourselves and the fact is unless you are closed source the best thing you can do as a third party is actually participate in the Fedoraproject, packaging you software or application stack and ship it within the distribution so that our existing processes will catch any fallout which our features or cleanups might bring and allow for the community to actually fix it with your or for you. The we have source, we can improve the API, update all users and end up with a cleaner design argument is very rarely true in practice outside of fairly tightly coordinating communities (of which the Linux kernel and its approach to internal interfaces is probably the most visible example). In fact, we as a distribution are getting _worse and worse_ in this regard. There are, instead, more and more subsystems that ship parallel-installable versions with no specific plans about ever fixing all users - sometimes apparently just hoping that both the unported users and older versions of the subsystem will die of neglect at approximately the same time. The argument about updating all users is just not true for proprietary applications, binary-only applications, or cross-platform applications with a release schedule significantly different from Fedora. (Some people think that the Linux ecosystem should be entirely Open Source, so they don't find this relevant. I'd rather not extend this huge thread into a discussion of this particular difference of opinion.) Finally, as a thought experiment - we have a fairly well developed concept of automated testing, and we (so far?) have Moore's law making CPU, storage and the cost of testing exponentially cheaper over time; it just might be the right thing to do to provide essentially infinite backward compatibility, in the same way the newest Windows can run 64-bit applications completely natively, 32-bit applications almost natively, 16-bit applications in a VM or full software emulation, or even fully emulate old 8-bit systems. The same thinking applies to individual sets of APIs and other interfaces: write the new implementation, write a compatibility layer for old users that replaces the old implementation, write a test suite of the compatibility layer (... or just use the test suite of the implementation thing that you should have already), keep the compatibility layer shipped and running and forget about the transition. Writing a compatibility layer is roughly the same kind of work as porting applications, so with any interface that has at least a handful of users a single compatibility layer should in fact be less work. With this approach, it's not at all obvious that one shouldn't aim for a backward compatibility 100 years back[1][2]. Mirek [1] One can't promise the backward compatibility 100 years into the future, though, no more that one can promise that any particular town/nation/language/building will still exist. [2] Don't worry, I'm not at all proposing that Fedora should aim for a backward compatibility 100 years back. I do want to seriously undermine the idea that progress requires removing or breaking things, though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook billycr...@gmail.com wrote: Please voice yourself at meetings in #fedora-devel if this is important to you. (Speaking purely for myself and not for other FESCo members,) I do want to hear from Fedora contributors - but I'd much rather hear on the mailing list (where messages arrive over the course of a week or more) rather than during the FESCo meeting (when we have only a few minutes to agree on a decision, and already frequently have two or three parallel subconversations). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to create a new mailing list at lists.fedoraproject.org
On Fri, Jul 19, 2013 at 07:22:55AM -0700, T.C. Hollingsworth wrote: Hi! On Jul 19, 2013 7:12 AM, Vivek Goyal vgo...@redhat.com wrote: Hi, I want to create a new mailing list for kexec/kdump related discussions in fedora. How do I go about it. I try to create one here but it asks for List creator's password. I don't have any such password. So who is authorized to create the list and can he/she create one for me? File a ticket against the Mailing Lists component in Fedora Infrastructure's trac instance: https://fedorahosted.org/fedora-infrastructure/ Thanks. created one just now. https://fedorahosted.org/fedora-infrastructure/ticket/3900 Vivek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/19/2013 06:12 PM, Miloslav Trmač wrote: Progress does not that frequently depend on removing older functionality. Specifically in this case, removing rsyslog does not make journal in any way better. Perhaps not that' s a matter of opinion but to we should be able to compare it against the discussion and decision that was made when it was declared that rsyslog should become our syslogger over for example syslog-ng to see if it at least meats those standards. In anycase the fact cannot be ignored or denied that it is unnecessary to ship two sysloggers... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote: However, having the /usr/sbin/sendmail API available to applications is valuable - it brings a significant system administration benefit of centralizing the SMTP configuration. What does it mean to have available? Just that. The binary exists and does what it is expected to do. As discussed earlier, I think it's significantly better for applications to get errors (which they can handle) than to think they've sent a message which really gets buried forever. In the case I'm thinking about, application installation instructions just say make sure $sendmail works instead of configure SMTP (and TLS! and SMTP auth!) in this application-specific configuration file. And it's just not possible to automatically configure e-mail. My claim that it is useful to have /usr/sbin/sendmail does not at all depend on having an automatic configuration that works for everyone. I think the way forward is to encourage applications to _log_ rather than to send e-mail, via this or any other API. Application that want to log shoud log. Applications that want to send e-mail should send e-mail. My bank's monthly statement would be rather useless in the bank's splunk archive. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, Jul 19, 2013 at 12:37 PM, Miloslav Trmač m...@volny.cz wrote: On Mon, Jul 15, 2013 at 10:36 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: No Default Sendmail = https://fedoraproject.org/wiki/Changes/NoDefaultSendmail Change owner(s): Lennart Poettering lennart at poettering net, Matthew Miller mattdm at fedoraproject org No longer install an MTA by default. (Specifically let's remove sendmail from @core and @standard comps groups.) == Detailed description == Let's change the default install to no longer install an MTA by default. Specifically, let's remove sendmail from the @standard and @core group. On today's Internet most SMTP hosts do not accept mail from a server which is not configured as a mail exchange for a real domain, hence the default configuration of sendmail is seldom useful. We don't necessarily have to have a MTA always running, or listening on port 25. However, having the /usr/sbin/sendmail API available to applications is valuable - it brings a significant system administration benefit of centralizing the SMTP configuration. Every application[1] can be rewritten to have its own SMTP client and configuration instead of calling /usr/sbin/sendmail, sure, but the system administrators are much better off if the applications call /usr/sbin/sendmail and $whatever implementation handles that. This is not a packaging matter of adding Requires:/usr/sbin/sendmail - we get the benefit of centralization only if applications support /usr/sbin/sendmail , and have it configured as the default. Removing a provider of /usr/sbin/sendmail from the default installation entirely makes both of these application design choices problematic and unlikely. Mirek Agreed. An MTA is an important component of *nix systems. Sendmail stays in Default unless there is compelling reason to switch to postfix, exim, meta1, etc. Those users who wish to remove it are welcome to do so. Nobody is stopping them. The default configuration of sendmail poses no problem to users who are unaware of it. A better option than its removal would be its configuration during install, which is currently not supported in the installer. A during-install installer 'spoke' could be added to support this in the same way root password is handled today. Additionally, on a user's first login, they could be prompted for their preference in how they receive locally originated messages. Please voice yourself at meetings in #fedora-devel if this is important to you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 12:53:20PM -0400, Colin Walters wrote: On Fri, 2013-07-19 at 10:17 +0100, Daniel P. Berrange wrote: Far better to encourage people to explicitly use /usr/bin/python2 and /usr/bin/python3 explicitly and discourage any use of plain /usr/bin/python Note the GNOME discussion here: https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg5.html One ugly part is that Debian Wheezy does not have python2. That combined with the Arch Linux people who made /usr/bin/python = python3 is a terrible mess for people who just want random portable scripts. For GNOME we decided to just try to ensure python2 always exists: https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00017.html nod These two concerns were reasons that PEP394 was written. http://www.python.org/dev/peps/pep-0394/#rationale and CPython2's install was changed to create the python2 symlink: http://www.python.org/dev/peps/pep-0394/#application-to-the-cpython-reference-interpreter which should make it into Debian at some point. -Toshio pgpMMVgPGs6jE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
Daniel P. Berrange (berra...@redhat.com) said: I don't think we're anywhere near the point in time where such an approach is worth the pain it will inflict on people. As above, I'm pretty sceptical that maintainence of Python2 is actually going to stop in 2015, as I think there are too many people and/or organizations who will find they have reasons for wanting to stick on python2 for a long time. Maybe I'll be proved wrong on this in time, but I doubt it, as there's far too many prior examples of people/companies sticking with ancient software versions because the cost of maintaining them is less than the cost of porting them. Especially since I do believe there are large software infrastructures even more tied to python2 than Fedora is with yum/anaconda/etc. (Hellooo, OpenStack!) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Fri, Jul 19, 2013 at 1:28 PM, Jóhann B. Guðmundsson johan...@gmail.com
wrote:
On 07/19/2013 06:12 PM, Miloslav Trmač wrote:
Progress does not that frequently depend on removing older
functionality. Specifically in this case, removing rsyslog does not
make journal in any way better.
Perhaps not that' s a matter of opinion but to we should be able to
compare it against the discussion and decision that was made when it was
declared that rsyslog should become our syslogger over for example
syslog-ng to see if it at least meats those standards.
This is *not the same thing*. In case anyone here is unaware, rsyslog and
syslog-ng are exclusive. ${Syslog} and systemd are not.
In anycase the fact cannot be ignored or denied that it is unnecessary to
ship two sysloggers...
I haven't seen anyone asking to ship two sysloggers.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Mesos Packaging
For folks who are watching, we are assisting the upstream Mesos project(https://issues.apache.org/jira/browse/MESOS-543) and there is interest from multiple parties to get the package and it's dependencies into the Fedora | EPEL channels. If you are interested, please feel free to ping me and we can coordinate, as there is a fair amount to be done. Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Jul 19, 2013 2:11 PM, Steve Clark scl...@netwolves.com wrote: On 07/19/2013 02:56 PM, Jóhann B. Guðmundsson wrote: On 07/19/2013 06:45 PM, Billy Crook wrote: I haven't seen anyone asking to ship two sysloggers. I perhaps should have been clearer and say two logging systems which we currently are doing and one of those cannot be disabled or removed so the logical choice is to remove the one that can and make him as an option to be install later. JBG This might have merit if the one you want to keep could do everything it does plus what the one you want to remove does. Well put. This is exactly why NoSyslog is premature. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/19/2013 07:11 PM, Steve Clark wrote: This might have merit if the one you want to keep could do everything it does plus what the one you want to remove does. And to establish if it does that, we need to know what the deceive factor was of choosing rsyslog in the first place over syslog-ng and other logging systems. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
Miloslav Trmač (m...@volny.cz) said: On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook billycr...@gmail.com wrote: Please voice yourself at meetings in #fedora-devel if this is important to you. (Speaking purely for myself and not for other FESCo members,) I do want to hear from Fedora contributors - but I'd much rather hear on the mailing list (where messages arrive over the course of a week or more) rather than during the FESCo meeting (when we have only a few minutes to agree on a decision, and already frequently have two or three parallel subconversations). I agree with this statement. In terms of this feature as presented, I'm not seeing why having $MTA in the minimal install where you need the installer to have a required configury step for it is a proper use of everyone's time that's installing it. Enterprise administrators are almost certainly pushing out their own configurations directly via puppet/chef/ansible/etc. Desktop users are primarily doing it as part of their MUA setup, or just using webmail. It's not as if the default MTA configuration, as I understand it (no smart host, attempt to send all mail directly with the FQDN) is generally useful OOTB. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Request 36: improve update syncs
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/36/#review47 --- blockerbugs/templates/update_list.html http://reviewboard-tflink.rhcloud.com/r/36/#comment74 got it, thank you - Ilgiz Islamgulov On July 19, 2013, 7:05 p.m., Ilgiz Islamgulov wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/36/ --- (Updated July 19, 2013, 7:05 p.m.) Review request for blockerbugs. Repository: blockerbugs Description --- Add partial updates sync. Display proposed/accepted fe/blocker bugs list associated with update on update list web page. Diffs - testing/testfunc_update_sync.py 69f6bf8a459c71a9325cd633e7e33ce29354d7cd testing/test_updatesync_extract_information.py 1fc701ef79a74e27cf8223b56a04d63025b6509f testing/test_controllers.py f351832ad4350fcff3d67c0137ff62892639e908 blockerbugs/util/update_sync.py d664839ec1c5979dce980e7baad58154f4622e11 blockerbugs/util/bug_sync.py 49cce49740cd6f5b1f430f58c8d1b522e1f0b7e3 blockerbugs/templates/update_list.html a83dd9a422e51ea58e04ae58acd8fefe6eb1f79f blockerbugs/models/update.py 2ee3ca7ee62bd55bbd71555c13fecfab504c4f07 blockerbugs/controllers/main.py 4f23e35558ac3f8ed2ccc5d897b2219e449e7277 blockerbugs/cli.py 694736d098b6285c53db91f91350360d478c4229 Diff: http://reviewboard-tflink.rhcloud.com/r/36/diff/ Testing --- Wrote test suites. I've tested on my develop instance. Thanks, Ilgiz Islamgulov ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Review Request 36: improve update syncs
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/36/ --- (Updated July 19, 2013, 7:05 p.m.) Review request for blockerbugs. Repository: blockerbugs Description --- Add partial updates sync. Display proposed/accepted fe/blocker bugs list associated with update on update list web page. Diffs (updated) - testing/testfunc_update_sync.py 69f6bf8a459c71a9325cd633e7e33ce29354d7cd testing/test_updatesync_extract_information.py 1fc701ef79a74e27cf8223b56a04d63025b6509f testing/test_controllers.py f351832ad4350fcff3d67c0137ff62892639e908 blockerbugs/util/update_sync.py d664839ec1c5979dce980e7baad58154f4622e11 blockerbugs/util/bug_sync.py 49cce49740cd6f5b1f430f58c8d1b522e1f0b7e3 blockerbugs/templates/update_list.html a83dd9a422e51ea58e04ae58acd8fefe6eb1f79f blockerbugs/models/update.py 2ee3ca7ee62bd55bbd71555c13fecfab504c4f07 blockerbugs/controllers/main.py 4f23e35558ac3f8ed2ccc5d897b2219e449e7277 blockerbugs/cli.py 694736d098b6285c53db91f91350360d478c4229 Diff: http://reviewboard-tflink.rhcloud.com/r/36/diff/ Testing --- Wrote test suites. I've tested on my develop instance. Thanks, Ilgiz Islamgulov ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: F20 System Wide Change: No Default Syslog
On 07/19/2013 02:56 PM, Jóhann B. Guðmundsson wrote: On 07/19/2013 06:45 PM, Billy Crook wrote: I haven't seen anyone asking to ship two sysloggers. I perhaps should have been clearer and say two logging systems which we currently are doing and one of those cannot be disabled or removed so the logical choice is to remove the one that can and make him as an option to be install later. JBG This might have merit if the one you want to keep could do everything it does plus what the one you want to remove does. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Jul 19, 2013 2:16 PM, Bill Nottingham nott...@redhat.com wrote: Miloslav Trmač (m...@volny.cz) said: On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook billycr...@gmail.com wrote: Please voice yourself at meetings in #fedora-devel if this is important to you. (Speaking purely for myself and not for other FESCo members,) I do want to hear from Fedora contributors - but I'd much rather hear on the mailing list (where messages arrive over the course of a week or more) rather than during the FESCo meeting (when we have only a few minutes to agree on a decision, and already frequently have two or three parallel subconversations). I agree with this statement. In terms of this feature as presented, I'm not seeing why having $MTA in the minimal install where you need the installer to have a required configury step for it is a proper use of everyone's time that's installing it. Enterprise administrators are almost certainly pushing out their own configurations directly via puppet/chef/ansible/etc. Desktop users are primarily doing it as part of their MUA setup, or just using webmail. It's not as if the default MTA configuration, as I understand it (no smart host, attempt to send all mail directly with the FQDN) is generally useful OOTB. It is to me, and I suspect I am not alone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/19/2013 07:11 PM, Steve Clark wrote: This might have merit if the one you want to keep could do everything it does plus what the one you want to remove does. If the intent was to obsolete rsyslog then yes that would be relevant but since it's not, that's not the case. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
mattdm wrote: [...] What does it mean to have available? As discussed earlier, I think it's significantly better for applications to get errors (which they can handle) than to think they've sent a message which really gets buried forever. There exist /usr/lib/sendmail submission-only imitators (ssmtp, msmtp) that could be trained to block until mail is delivered, and return error return codes upon rejection. And it's just not possible to automatically configure e-mail. [...] As for outgoing SMTP, DHCP packets can identify servers; so can DNS heuristics. I think the way forward is to encourage applications to _log_ rather than to send e-mail, via this or any other API. That can be configured for e-mail alerts if the admin really wants. But without configuration, nothing is going to happen _anyway_. Such a transition should come along with all the tooling needed to emulate the status quo - i.e., scraped-log-to-email scripts. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote: 3) Making all livecd packages depend on Python 3 by default (and eventually getting rid of Python 2 from livecd) - this will also require switching from Yum to DNF as a default, that is supposed to support Python I have a concern about bloating @core and by extension the cloud image. Right now, python is about 5% of the total on-disk usage. I'd hate to see that go to 10%. Therefore, I'd like to see a goal of making the transition for usage in the base cloud image go entirely from python2 to python3 in one release cycle. (Roughly, that's @core + cloud-init, which isn't currently on your list.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Fri, Jul 19, 2013 at 02:16:13PM -0500, Billy Crook wrote: Well put. This is exactly why NoSyslog is premature. And that's exactly why it's NoDefaultSyslog, not NoSyslog. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/19/2013 06:45 PM, Billy Crook wrote: I haven't seen anyone asking to ship two sysloggers. I perhaps should have been clearer and say two logging systems which we currently are doing and one of those cannot be disabled or removed so the logical choice is to remove the one that can and make him as an option to be install later. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd
On Wed, Jul 17, 2013 at 12:43 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd = https://fedoraproject.org/wiki/Changes/ntpdate Given what has been discussed/learned in this thread, it seems that the change proposal needs some changes (and perhaps another round of discussion?). Looking at the rationale, I wonder how the things that have been discussed so far (replacement of ntpd with chrony, and ntpdate with sntp) make a difference with respect to the hardening recommendations - perhaps such changes would help avoid the letter of the recommendations, but what about the substance? For example in http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf, I really doubt the intent was to exclude specifically a daemon named ntpd - rather the intent was most likely to avoid running a daemon at all[1], so just using chrony instead of ntpd wouldn't make a substantial difference. Mirek [1] Leaving aside whether such a recommendation is well justified. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 02:41:23AM -0400, Bohuslav Kabrda wrote: - Original Message - On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote: Hi all, as a new Fedora Python maintainer, I have set myself a goal of moving Fedora to Python 3 as a default. I'm not sure we want to make python3 default depending on what your definition of default is. /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this So, my definition of default is all system tools use Python 3, it is the only Python that gets to minimal buildroot/minimal Fedora installation - that means: I'm okay with this portion of the definition. One note is I would be hesitant about the timing of python3 being the only python that is installed into the minimal buildroot. This should probably happen in rawhide right after a branching. - livecd can still ship Python 2 I would consider this to be the goal that we should shoot for, though. We are constantly fighting for space on the install images and we know that people who install Fedora would like to have the ability to slim down what is installed. Shooting for no-python2 on the livecds and after that, no python2 on the install dvds, and still later, no need for python2 in the packages in the repository seem like milestones that have actual real value for end users. - /usr/bin/python points to Python 3 I am firmly against this. more depth was in my reply to mmaslano although I'll reply to one thing here: - Please note, that the pep you're referring to also states that python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions, so this wouldn't really be going against the pep. This is a misinterpretion of the PEP. (This section is confusing, though: python should refer to the same target as python2 is a recommendation to distributions. but may refer to python3 on some bleeding edge distributions is a statement of fact for end users to watch out for) See the recommendation section: For the time being, it is recommended that python should refer to python2 (however, some distributions have already chosen otherwise; see the Rationale and Migration Notes below). and Future Changes Section: http://www.python.org/dev/peps/pep-0394/#future-changes-to-this-recommendation It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2. This recommendation will be periodically reviewed over the next few years, and updated when the core development team judges it appropriate. The may refer to python3 phrase is an acknowledgment that arch has moved to /usr/bin/python == python3 and isn't going to revert even though upstream thinks it's a... premature time to make that switch. (To be fair to arch, the discussion and PEP happened as a result of arch making that switch so they'd already committed to that before the consensus was formed that this would be a bad thing to do atthis time. We don't have that excuse ;-) If you'd like to read the discussions for yourself, there are three threads linked from the PEP. An even earlier one is at: http://mail.python.org/pipermail/python-dev/2010-November/105252.html The python package itself should probably also remain python2 due to dependencies and expectations from other distros and documentation -- I think I'd be -1 to changing this The Fedora live images contain only python3, not python2 -- I'd be heavily in favour of this. +1 This is going to be a multirelease effort that is going to affect lots of Fedora parts. Since we will need to switch default package manager from Yum to DNF (which is supposed to work with Python 3), we will need to wait for that. I've been told that DNF should be default in F22, so that's my target, too. That should also give everyone else plenty of time to work on other essential packages to make this happen. Getting there at the same time as we get to DNF sounds like a good timeline. (But see my note on anaconda below). +1 Here is my analysis/proposal: Before switching, we need to make sure that everything important (*) is Python 3 compatible. There are three steps I see in this transition: 1) Getting rid of Python 2 in mock minimal buildroot. I'm not sure about this one as it will cause a lot of package churn. It might be a necessary pain pointi or it might be a pain point we want to defer until later in our porting efforts. Have to think about it more. If you look at the minimal mock buildroot for rawhide now, the only thing that is drawing in Python is gdb because of it's Python bindings (if I'm not mistaken). So compiling GDB against Python 3, which should work with newest
Re: F20 System Wide Change: No Default Sendmail
Hi, On Friday 19 July 2013 14:16:57 Matthew Miller wrote: As discussed earlier, I think it's significantly better for applications to get errors (which they can handle) than to think they've sent a message which really gets buried forever. True, but it doesn't have to be buried forever, at least not for the default (desktop) install: * Default delivery as today (no smart host, deliver to local mailbox) * We should add the local inbox to the default configuration of all MUA's that can handle it (kmail, evolution, etc.) * When Anaconda (or would it be first boot? I lost tracking...) is setting the first user, add it to /etc/aliases as a mail alias to root. With this, on every *default* desktop the installing user start getting useful system mails from various packages as they are installed (logwatch, arpwatch, cron-jobs, etc.) IMO, removing sendmail from the *minimal* install is good idea, but we should have an MTA for the default install with local delivery. I think the way forward is to encourage applications to _log_ rather than to send e-mail, via this or any other API. That can be configured for e-mail alerts if the admin really wants. Logging and mail have totally different use-cases. With mail you can send an extensive multi-line report to a human. As explained in the previous section, with very basic default configuration for MUA's and MTA's you get a very high chance that the desktop user who installed the system would actually see these mails (and any user would see the output of their cron-jobs). These same users are very unlikely to know that logs even exist, much less how to read them. [and all non-privileged users cannot see the output of their own cron-jobs...] But without configuration, nothing is going to happen _anyway_. Other use-cases would need configuration anyway. If you install a VM you may really want remote logging (as well as smart-host mails). But then such deployments are usually done by knowledgeable people with appropriate tooling (kickstarts, configuration-management tools, etc.) To summarize: * Remove from minimal install -- so advanced use cases can get rid of MTA. * Leave on default install: - Adding local mailbox to default configuration of MUA's would be an improvement. - Adding the installing user as a root alias to /etc/aliases would be another improvement. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise. - Larry Wall. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Tue, Jul 16, 2013 at 12:54 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Web Assets = https://fedoraproject.org/wiki/Changes/Web_Assets Change owner(s): T.C. Hollingsworth tchollingswo...@gmail.com == Detailed description == A standard directory (/usr/share/assets) for static bits that are intended to be delivered to web browsers, such as CSS Frameworks, UI libraries, etc. will be introduced. HTTP daemons in the distribution should make this directory available publicly as /assets. Minor comment: This copy of the text uses /assets ; the wiki page and the proposed policy uses both /assets and /_assets ; this should be cleared up. More importantly, is it OK to just take over a part of the server's URI namespace like this? If we do so, users won't be able to remap the directory to something else without potentially breaking Fedora-packaged applications. Are we satisfied enough that (presumably) /_assets will not collide with existing applications or installations? (Yes, this is already written in the proposal. I still thought it is worth highlighting to make absolutely sure we have this discussion, because changing the path would be very painful with the current proposal.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 03:29:57PM -0400, Matthew Miller wrote: On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote: 3) Making all livecd packages depend on Python 3 by default (and eventually getting rid of Python 2 from livecd) - this will also require switching from Yum to DNF as a default, that is supposed to support Python I have a concern about bloating @core and by extension the cloud image. Right now, python is about 5% of the total on-disk usage. I'd hate to see that go to 10%. Therefore, I'd like to see a goal of making the transition for usage in the base cloud image go entirely from python2 to python3 in one release cycle. (Roughly, that's @core + cloud-init, which isn't currently on your list.) This seems like a very very worthy goal. I took a brief look at @core (I didn't recurse down the whole dep chain so hopefully I didn't miss an iceberg) and that looks doable. The switch from yum to DNF is the big thing. cloud-init is python so it might need to be ported in and of itself. Some of its dependencies also don't have python3 ports: * configobj -- no upstream python3 port and the third-party port never made it to a release (the code may work but it's unmaintained). If someone is ready to become the upstream for this, indications are that it would be welcomed by both the port's original author and the original ConfigObj maintainer. * policycoreutils-python -- not sure if this interfaces with the C libraries or is about implementing higher level functionality. Nearly anytime you interface with C you have to make choices about bytes vs text and problems with encoding. That could slow up this work. * python-boto -- Looks like there's a badly out-of-date branch in the upstream SCM repository to add python3 support. That may be based on an API incompatible update, though (I see that there's work on boto3...) boto is going to need to talk over the wire to AWS so there's going to be a lot of places where bytes vs text decisions have to be made. All in all, this package feels like it might be the hardest piece of the cloud-init porting. * python-cheetah -- Development slowed way down after they made their last release in 2010 and announced that the next release cheetah-3.0 would include python3 support. Probably need to contact upstream about this and may need to prepare the patch to do the port. -Toshio pgpZdKlcfpejO.pgp Description: PGP signature ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote: However, having the /usr/sbin/sendmail API available to applications is valuable - it brings a significant system administration benefit of centralizing the SMTP configuration. What does it mean to have available? As discussed earlier, I think it's significantly better for applications to get errors (which they can handle) than to think they've sent a message which really gets buried forever. And it's just not possible to automatically configure e-mail. It might have been in 1997, when every system was directly connected to the Internet, every network allowed port 25 out, and everyone accepted mail from everywhere. None of those things are true now -- not just not true in some cases, but not true in the common case. I think the way forward is to encourage applications to _log_ rather than to send e-mail, via this or any other API. That can be configured for e-mail alerts if the admin really wants. But without configuration, nothing is going to happen _anyway_. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Fri, Jul 19, 2013 at 9:51 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: More importantly, is it OK to just take over a part of the server's URI namespace like this? snip But _assets/ does have the potential to clash a lot too. So how about _sysassets/? I'm afraid I don't have enough relevant experience in this area to say whether any particular choice is good. I was just trying to attract attention of other people, more knowledgeable than me. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 11:58:35AM -0400, john.flor...@dart.biz wrote: From: tm...@redhat.com On Fri, 2013-07-19 at 11:24 -0400, john.flor...@dart.biz wrote: Excellent point! If I were caught unaware, I'd much rather have to fix up a bunch shebang lines and learn that I need to get going on my migration pronto than the alternative of finding one day that python2 is just gone where one is left with either a hurried port or downloading python2 from external sources. The heads-up can be done before the python2 dropping by removing /usr/bin/python from python2 package. Ah, true indeed. However, I still like the idea of being explicit. If you want py2, say so in the shebang line. Likewise with py3. How can we get the very blunt head's up and be explicit too? I have no idea when py2 will truly go away, but I'm convinced it will eventually and I'd like to create my works in the best possible fashion. Thus far I've relied on the implicit py-py2 and explicit py3 invocations as that's the way I've seen Fedora set examples, but I think this should really be more detailed in the packaging guidelines. I'm not sure if this is a good idea (or in what time frame it may be a good idea. It's definitely too early now and likely too early for F22) but -- if you want something explicit, we could replace /usr/bin/python with something that prints out an error message to switch shebang lines to use /usr/bin/python2 and exits. (Perhaps a warning message to switch shebang lines could be done now, though). -Toshio pgpcGhpOioqxA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 01:45:41PM -0700, Toshio Kuratomi wrote: * python-cheetah -- Development slowed way down after they made their last release in 2010 and announced that the next release cheetah-3.0 would include python3 support. Probably need to contact upstream about this and may need to prepare the patch to do the port. What I'd _really_ like to do is get cheetah factored out of cloud-init. (https://bugzilla.redhat.com/show_bug.cgi?id=974327). It brings in a whole dependency chain of which python2 vs. python3 is the least of the troubles. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [389 Project] #47435: Very large entryusn values after enabling the USN plugin and the lastusn value is negative.
https://fedorahosted.org/389/ticket/47435 https://fedorahosted.org/389/attachment/ticket/47435/0001-Ticket-47435-Very-large-entryusn-values-after-enabli.patch 1. Bug description: The initial value of lastusn is -1, but since the entryusn has the unsigned long long integer type, the server returns 18446744073709551615 == 0X. Fix description: The initial value -1 is returned as it is. 2. Bug description: Entryusn syntax is defined as an integer in the schema. If negative values are accidentally stored in the entryusn value in the database, it was casted to the unsigned integer in the entryusn initialization code (usn_get_last_usn). Fix description: When an entryusn value is retrieved from the database, it's checked as a singed integer once and if it is negative, it's replaced with the initial value -1. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 10:11 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I'm not sure if this is a good idea (or in what time frame it may be a good idea. It's definitely too early now and likely too early for F22) but -- if you want something explicit, we could replace /usr/bin/python with something that prints out an error message to switch shebang lines to use /usr/bin/python2 and exits. (Perhaps a warning message to switch shebang lines could be done now, though). I personally think it is too early for even that. If one asks me to make necessary changes only to the projects I am upstream, I will have to clone myself many times to do that in any near future. Kushal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, Jul 19, 2013 at 08:22:28PM +0200, Miloslav Trmač wrote: What does it mean to have available? Just that. The binary exists and does what it is expected to do. We can do part 1. Part 2 is impossible. As discussed earlier, I think it's significantly better for applications to get errors (which they can handle) than to think they've sent a message which really gets buried forever. In the case I'm thinking about, application installation instructions just say make sure $sendmail works instead of configure SMTP (and TLS! and SMTP auth!) in this application-specific configuration file. I'm absolutely not suggesting we drop having an MTA. That would be silly. And it's just not possible to automatically configure e-mail. My claim that it is useful to have /usr/sbin/sendmail does not at all depend on having an automatic configuration that works for everyone. Sure. So then it's just down to a matter of whether it's good to have it installed but unconfigured. I think it isn't. I'm _certain_ that it isn't in in @core and in the cloud use case. I can be convinced that there is some better default configuration we can ship in the desktop case, but I'd be surprised -- it's not like Mac users and developers are clamouring for local mail to work. And in the server case, we're not going be able to auto-configure anything, because the local sysadmins will _always_ want the right local thing, which will be different -- so best to leave a blank slate. Application that want to log shoud log. Applications that want to send e-mail should send e-mail. My bank's monthly statement would be rather useless in the bank's splunk archive. Well, sure. But if we're talking about this kind of application, I think it's entirely irrelevant to the change proposal at hand. Unless we're planning to install your bank on eveyone's Fedora system by default. :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Kwalitee] Created tag perl-Test-Kwalitee-1.09-1.fc20
The lightweight tag 'perl-Test-Kwalitee-1.09-1.fc20' was created pointing to: a56d7c4... Update to 1.09 -- 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: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 05:30:36PM -0400, Matthew Miller wrote: On Fri, Jul 19, 2013 at 01:45:41PM -0700, Toshio Kuratomi wrote: * python-cheetah -- Development slowed way down after they made their last release in 2010 and announced that the next release cheetah-3.0 would include python3 support. Probably need to contact upstream about this and may need to prepare the patch to do the port. What I'd _really_ like to do is get cheetah factored out of cloud-init. (https://bugzilla.redhat.com/show_bug.cgi?id=974327). It brings in a whole dependency chain of which python2 vs. python3 is the least of the troubles. If your needs are very minimal, python3-tempita might be a good choice. If you actually do need more features than that, python-mako and python-jinja2 are popular. Note that both of those have a few deps (but hopefully not as bad as cheetah). (Also -- the python3 version of mako has less deps than the python2 version... I think that it just because those deps haven't been ported to python3 yet and the package can operate with reduced functionality without them. the deps fo the python3 version might expand i nthe future). -Toshio pgpAfC3zd2o47.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Jul 19, 2013, at 12:26 PM, Miloslav Trmač m...@volny.cz wrote: On Fri, Jul 19, 2013 at 8:17 PM, Billy Crook billycr...@gmail.com wrote: Please voice yourself at meetings in #fedora-devel if this is important to you. (Speaking purely for myself and not for other FESCo members,) I do want to hear from Fedora contributors - but I'd much rather hear on the mailing list (where messages arrive over the course of a week or more) rather than during the FESCo meeting (when we have only a few minutes to agree on a decision, and already frequently have two or three parallel subconversations). Speaking for myself, I'd like to see sendmail totally dropped from minimal, infrastructure, and desktop packagesets. But at least I'd like to see it disabled (or rather masked, since sendmail somehow manages to be started up even when systemctl is used to disable it) by default. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Sendmail
On Fri, 2013-07-19 at 14:23 -0500, Billy Crook wrote: It's not as if the default MTA configuration, as I understand it (no smart host, attempt to send all mail directly with the FQDN) is generally useful OOTB. It is to me, and I suspect I am not alone. I call bullshit. How is it useful to you? All it can possibly do is deliver mail to root and users in /var/spool . We don't set up any mail reader to read this mail out of the box. No app is very likely to know your user name and send mail to you. The only practical thing you can do with the OOTB sendmail configuration is manually read or configure an agent to read the mail in root's /var/spool directory - and that is not the recommended way to read root's mail _anyway_, the recommended way is to alias root to a user account. Sorry, but I am firmly on the 'this is a mechanism from the 1980s' side of the argument. I run my own mail server, ground up. It makes me feel all old-school geeky. I am one of a minority of about 0.0001% in the world these days, and I don't even use sendmail anyway. It's just ludicrous that we have it in @core. Rip it out, now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Jóhann B. Guðmundsson (johan...@gmail.com) said: On 07/19/2013 07:11 PM, Steve Clark wrote: This might have merit if the one you want to keep could do everything it does plus what the one you want to remove does. And to establish if it does that, we need to know what the deceive factor was of choosing rsyslog in the first place over syslog-ng and other logging systems. rsyslog was chosen over syslog-ng at the time because of better compatibility with sysklogd. I'd have to dig back to check, but I think the config file was part of it. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Hi Lennart, I suppose someone should mention small flash-disk-only computers. There traditionally we fling syslog messages to the serial console or a LRU buffer in RAM (often the dmesg buffer). The point is to avoid I/O on the flash memory. Syslog daemons tend to do a lot of fsync-ed I/O, which just chews up flash write cycles. With some configuration the syslog daemons can be made to not to fsync, and with additional configuration to write to the serial port or to the dmesg ring buffer. These small computers aren't specialised embedded systems anymore -- if you buy a cheap ARM-based laptop then you are buying a such a system. Their increasing popularity is very much the reason ARM is becoming a top-teir architecture in Fedora. These systems are *cheap*, so they don't have the write cycles of an expensive SSD. I'm not across journald at all. But the questions in my mind are: - Is is possible to run journald without writing to disk; that is: to serial as text, or as binary to a ring buffer which can then by used by journalctl? - When writing to disk does journald fsync, and if so can that be disabled by a non-guru laptop user? - Is journalctl available from the dracut shell, so that we can get bug reports for early system failures? There is a lot more variation in small computers, and thus more early system failures. Thank you for making the binary format portable between computers. Allowing a 32b ARM journal file to be displayed on a x86_64 desktop is very useful. Thank you for your time, glen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Sat, Jul 20, 2013 at 08:15:11AM +0930, Glen Turner wrote: Hi Lennart, I suppose someone should mention small flash-disk-only computers. There traditionally we fling syslog messages to the serial console or a LRU buffer in RAM (often the dmesg buffer). The point is to avoid I/O on the flash memory. Syslog daemons tend to do a lot of fsync-ed I/O, which just chews up flash write cycles. With some configuration the syslog daemons can be made to not to fsync, and with additional configuration to write to the serial port or to the dmesg ring buffer. These small computers aren't specialised embedded systems anymore -- if you buy a cheap ARM-based laptop then you are buying a such a system. Their increasing popularity is very much the reason ARM is becoming a top-teir architecture in Fedora. These systems are *cheap*, so they don't have the write cycles of an expensive SSD. I'm not across journald at all. But the questions in my mind are: I'm not Lennart, but I'll try to answer your questions: - Is is possible to run journald without writing to disk; that is: to serial as text, or as binary to a ring buffer which can then by used by journalctl? Yes, it's possible to keep journal completely in /run/ by setting Storage=volatile or not creating /var/log/journal at all. See journald.conf(5). - When writing to disk does journald fsync, and if so can that be disabled by a non-guru laptop user? Yes, see SyncIntervalSec in journald.conf(5). - Is journalctl available from the dracut shell, so that we can get bug reports for early system failures? There is a lot more variation in small computers, and thus more early system failures. Yes, dracut uses systemd and journald too. Thank you for making the binary format portable between computers. Allowing a 32b ARM journal file to be displayed on a x86_64 desktop is very useful. Yes, systemd should be completely portable between architectures. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Billy Crook (billycr...@gmail.com) said: Perhaps there should be a Least Possible Bootable install for situations like this. I would agree Syslog should be missing from such an install. Just not from Default -- Not until journalctl and systemd attain ubiquity.. The installation only has a default because of user requests to not require anaconda to go into that menu. It's still a choice of one of the installation options presented (GNOME, KDE, minimal, infrastructure server, etc.). Minimal is definitely a *subset* of all the others, but that doesn't make it a 'default'. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Sat, Jul 20, 2013 at 01:02:00AM +0200, Zbigniew Jędrzejewski-Szmek wrote: - Is is possible to run journald without writing to disk; that is: to serial as text, or as binary to a ring buffer which can then by used by journalctl? Yes, it's possible to keep journal completely in /run/ by setting Storage=volatile or not creating /var/log/journal at all. See journald.conf(5). Plus add ForwardToConsole=yes and you can have it write to a serial console. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mesos Packaging
Am Freitag, den 19.07.2013, 15:14 -0400 schrieb Tim St Clair: are assisting the upstream Mesos project(https://issues.apache.org/jira/browse/MESOS-543) and there is interest from multiple parties to get the package and it's dependencies into the Fedora | EPEL channels. If you are interested, please feel free to ping me and we can coordinate, as there is a fair amount to be done. Cheers, Tim Hi Tim! You can count on me for doing the reviews and if you need help on the packaging front, too. Cheers, Björn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Fri, Jul 19, 2013 at 11:56 AM, Miloslav Trmač m...@volny.cz wrote: Minor comment: This copy of the text uses /assets ; the wiki page and the proposed policy uses both /assets and /_assets ; this should be cleared up. More importantly, is it OK to just take over a part of the server's URI namespace like this? If we do so, users won't be able to remap the directory to something else without potentially breaking Fedora-packaged applications. Are we satisfied enough that (presumably) /_assets will not collide with existing applications or installations? (Yes, this is already written in the proposal. I still thought it is worth highlighting to make absolutely sure we have this discussion, because changing the path would be very painful with the current proposal.) I added the underscore based on the suggestion of the httpd maintainer (in the discussion on the packaging list), who suggested /.assets/ or /_packaged_assets/ or so. (And sorry, I missed a couple spots when changing it.) I didn't like the latter because I would really prefer to keep it short. One of the things *I* really want from this is the ability to just type /_assets/jquery/jquery.min.js while developing instead of having to wget it every time or use an evil CDN that logs everything. Us programmers are lazy and shouldn't be forced to type gigantic URLs. ;-) But _assets/ does have the potential to clash a lot too. So how about _sysassets/? It reinforces the point of the directory, it's still pretty short, and seems to used nowhere else [1]. Note that most web apps that ship httpd configs already claim a chunk of the URI namespace, so that part isn't anything new, and prior JavaScript proposals actually called for keeping this tradition and giving every JS library it's own directory. -T.C. [1] https://www.google.com/search?q=inurl%3A%22_sysassets%22 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd
On Fri, Jul 19, 2013 at 2:37 PM, Miloslav Trmač m...@volny.cz wrote: On Wed, Jul 17, 2013 at 12:43 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd = https://fedoraproject.org/wiki/Changes/ntpdate Given what has been discussed/learned in this thread, it seems that the change proposal needs some changes (and perhaps another round of discussion?). Probably. Looking at the rationale, I wonder how the things that have been discussed so far (replacement of ntpd with chrony, and ntpdate with sntp) make a difference with respect to the hardening recommendations - perhaps such changes would help avoid the letter of the recommendations, but what about the substance? For example in http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf, I really doubt the intent was to exclude specifically a daemon named ntpd - rather the intent was most likely to avoid running a daemon at all[1], so just using chrony instead of ntpd wouldn't make a substantial difference. Mirek On the other hand the DISA STIG (http://iase.disa.mil/stigs/scap/) content for RHEL 5 and 6 says it must be enabled, or RHEL 5: SV-37402r1_rule The system clock must be synchronized to an authoritative DoD time source. it then goes on to talk about how to make sure ntpd/xntpd is running, or failing that that ntpdate is run from a cronjob. RHEL 6: SV-50421r1_rule The system clock must be synchronized continuously, or at least daily. I also checked the AIX/other UNIX stigs, they all basically say The system clock must be synchronized continuously, or at least daily. with a preference given to ntpd/etc., also NOTE: While it is possible to run ntpdate from a cron script, it is important to mention that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. So I would say DISA STIG REQUIREMENTS (e.g. to CERTIFY a system) outweigh NSA Hardening Tips which AFAIK carry no official weight. Also every other sane security standard/audit list/etc I'm aware of calls out NTP as being required, e.g. from the CSA CAIQ Clock Synchronization SA-12 SA-12.1 Do you utilize a synchronized time-service protocol (ex. NTP) to ensure all systems have a common time reference? So on the one hand we have official DISA STIG REQUIREMENTS, and virtually every security standard I'm aware of saying you must synchronize using NTP, or failing that use ntpdate as a fallback, vs. a Hardening Tips document that carries no official weight. So it looks like the best course of actions would be to enable some sort of clock synchronization daemon by default with an install option (through GUI and kickstart) to turn it off and a post install option to turn it off (e.g. normal systemd tools). All of which conveniently exist already =). [1] Leaving aside whether such a recommendation is well justified. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Kurt Seifried k...@seifried.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mean machinery...
When a shutdown task isn't proceeding as planned on Fedora 19/rawhide, am I the only one that feels like I'm staring down the monocle of a Cylon and should be preparing to die? That or it's the hood from Kit off of Knight Rider... Either way, it's creepy ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 552105] cpanspec treats recommended dependencies to required
https://bugzilla.redhat.com/show_bug.cgi?id=552105
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
CC||ppi...@redhat.com
--- Comment #7 from Petr Pisar ppi...@redhat.com ---
In my opinion, cpanspec should not add recommended modules to dependencies.
However it should put them into the spec file as a comment. Reason is
following:
There are various ways how Perl code can make a dependency optional. Some of
them lead to program crash (if ($foo) { require Bar }). I tend to handle these
cases as a hard dependencies at RPM level because packaged code should not die
due to missing dependency. Only a packager can evaluate this problem properly.
So the recommended modules should be written as a comment to strike the
packager when reviewing the cpanspec output.
--
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=JVdlyWfO58a=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 Crypt-Blowfish-2.12_001.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Crypt-Blowfish: 7789bf6dbe44661efa7fdaf522b9603e Crypt-Blowfish-2.12_001.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-Crypt-Blowfish] 2.12_001 bump
commit 8759b4dda6c488e7c93d1557509acbf7feb2b77e
Author: Petr Písař ppi...@redhat.com
Date: Fri Jul 19 09:23:44 2013 +0200
2.12_001 bump
.gitignore |1 +
perl-Crypt-Blowfish.spec | 21 +++--
sources |2 +-
3 files changed, 17 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d8475b6..3f89a78 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Crypt-Blowfish-2.10.tar.gz
+/Crypt-Blowfish-2.12_001.tar.gz
diff --git a/perl-Crypt-Blowfish.spec b/perl-Crypt-Blowfish.spec
index 6b5c501..5c3c1af 100644
--- a/perl-Crypt-Blowfish.spec
+++ b/perl-Crypt-Blowfish.spec
@@ -1,23 +1,29 @@
+%global cpan_version 2.12_001
+
Summary: XS Blowfish implementation for Perl
Name: perl-Crypt-Blowfish
-Version: 2.10
-Release: 18%{?dist}
+Version: %(echo '%{cpan_version}' | tr _ .)
+Release: 1%{?dist}
License: Copyright only
Group: Development/Libraries
URL: http://search.cpan.org/dist/Crypt-Blowfish/
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DP/DPARIS/Crypt-Blowfish-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DA/DAVIDO/Crypt-Blowfish-%{cpan_version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
-Requires: perl(Carp)
# Recommended:
Requires: perl(Crypt::CBC)
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
# Runt-time:
BuildRequires: perl(Carp)
BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
# Tests:
-BuildRequires: perl(Crypt::CBC)
+BuildRequires: perl(Benchmark)
+# Optional tests:
+BuildRequires: perl(Crypt::CBC) = 1.22
%description
Crypt::Blowfish is an XS-based implementation of the Blowfish
@@ -26,7 +32,7 @@ take full advantage of Crypt::CBC when desired. Blowfish keys
may be
up to 448 bits (56 bytes) long.
%prep
-%setup -q -n Crypt-Blowfish-%{version}
+%setup -q -n Crypt-Blowfish-%{cpan_version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
@@ -54,6 +60,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Fri Jul 19 2013 Petr Pisar ppi...@redhat.com - 2.12.001-1
+- 2.12_001 bump
+
* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 2.10-18
- Perl 5.18 rebuild
diff --git a/sources b/sources
index bf64663..ad3a427 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-15b53308df3b29a62a9f2f718aace19a Crypt-Blowfish-2.10.tar.gz
+7789bf6dbe44661efa7fdaf522b9603e Crypt-Blowfish-2.12_001.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-File-MMagic-XS] Perl 5.18 compatibility
commit de23dbf080d741b5eb3a1e94fb6a49314ed9bd90
Author: Petr Písař ppi...@redhat.com
Date: Fri Jul 19 09:44:04 2013 +0200
Perl 5.18 compatibility
...qw-does-not-produce-array-context-anymore.patch | 31
perl-File-MMagic-XS.spec |4 ++
2 files changed, 35 insertions(+), 0 deletions(-)
---
diff --git
a/File-MMagic-XS-0.09006-qw-does-not-produce-array-context-anymore.patch
b/File-MMagic-XS-0.09006-qw-does-not-produce-array-context-anymore.patch
new file mode 100644
index 000..3a13c95
--- /dev/null
+++ b/File-MMagic-XS-0.09006-qw-does-not-produce-array-context-anymore.patch
@@ -0,0 +1,31 @@
+From 364c8b1b72bef1c77a78d861cdd2637782cdf7f9 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Fri, 19 Jul 2013 09:40:52 +0200
+Subject: [PATCH] qw() does not produce array context anymore
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+https://rt.cpan.org/Public/Bug/Display.html?id=63048
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ inc/Module/Install/XSUtil.pm | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/inc/Module/Install/XSUtil.pm b/inc/Module/Install/XSUtil.pm
+index 8c21436..82b1918 100644
+--- a/inc/Module/Install/XSUtil.pm
b/inc/Module/Install/XSUtil.pm
+@@ -242,7 +242,7 @@ sub cc_assert_lib {
+
+ if ( ! $self-{xsu_loaded_checklib} ) {
+ my $loaded_lib = 0;
+-foreach my $checklib qw(inc::Devel::CheckLib Devel::CheckLib) {
++foreach my $checklib (qw(inc::Devel::CheckLib Devel::CheckLib)) {
+ eval use $checklib 0.4;
+ if (!$@) {
+ $loaded_lib = 1;
+--
+1.8.1.4
+
diff --git a/perl-File-MMagic-XS.spec b/perl-File-MMagic-XS.spec
index ddd6047..13dc0df 100644
--- a/perl-File-MMagic-XS.spec
+++ b/perl-File-MMagic-XS.spec
@@ -6,6 +6,8 @@ Group: Development/Libraries
License:ASL 2.0 and (GPL+ or Artistic)
URL:http://search.cpan.org/dist/File-MMagic-XS
Source0:
http://search.cpan.org/CPAN/authors/id/D/DM/DMAKI/File-MMagic-XS-%{version}.tar.gz
+# Perl 5.18 compatibility, CPAN RT#63048
+Patch0:
File-MMagic-XS-0.09006-qw-does-not-produce-array-context-anymore.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildRequires: gdbm-devel
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -27,6 +29,7 @@ an extended amount of time.
%prep
%setup -q -n File-MMagic-XS-%{version}
+%patch0 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
@@ -54,6 +57,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 0.09006-12
- Perl 5.18 rebuild
+- Perl 5.18 compatibility (CPAN RT#63048)
* Mon Feb 25 2013 Paul Howarth p...@city-fan.org - 0.09006-11
- BR: perl(ExtUtils::MakeMaker) to fix FTBFS (#914283)
--
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-File-HomeDir] Specify all dependencies
commit 64fb553fa0fb87583565cbdad1a83435ae9607d8
Author: Petr Písař ppi...@redhat.com
Date: Fri Jul 19 12:37:10 2013 +0200
Specify all dependencies
perl-File-HomeDir.spec | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
---
diff --git a/perl-File-HomeDir.spec b/perl-File-HomeDir.spec
index d48191d..a26fb4b 100644
--- a/perl-File-HomeDir.spec
+++ b/perl-File-HomeDir.spec
@@ -7,19 +7,27 @@ License:GPL+ or Artistic
URL:http://search.cpan.org/dist/File-HomeDir/
Source0:
http://www.cpan.org/authors/id/A/AD/ADAMK/File-HomeDir-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Carp)
+BuildRequires: perl
+BuildRequires: perl(Config)
BuildRequires: perl(Cwd) = 3.12
-BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(ExtUtils::MM_Unix)
BuildRequires: perl(File::Path) = 2.01
BuildRequires: perl(File::Spec) = 3.12
-BuilDrequires: perl(File::Spec::Functions)
+# POSIX not used on Linux
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(File::Temp) = 0.19
BuildRequires: perl(File::Which) = 0.05
-%if !%{defined perl_bootstrap}
+# Mac::Files not used on Linux
+# Mac::SystemDirectory not used on Linux
+# Not used on Linux
+# Tests:
BuildRequires: perl(Test::More) = 0.47
-%endif
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Cwd) = 3.12
Requires: perl(File::Path) = 2.01
@@ -59,6 +67,7 @@ make test
%changelog
* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 1.00-4
- Perl 5.18 rebuild
+- Specify all dependencies
* Thu Jan 31 2013 Petr Šabata con...@redhat.com - 1.00-3
- Use the Module::Install provided by upstream (#906007)
--
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 Devel-Caller-2.06.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Devel-Caller: af52f47979b3c9358af9e5d8c283f263 Devel-Caller-2.06.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-Caller] 2.06 bump
commit 4be48bbb8e1c1abb2cc1832d771fb1e5ca2cc7fe
Author: Petr Písař ppi...@redhat.com
Date: Fri Jul 19 12:50:25 2013 +0200
2.06 bump
.gitignore |1 +
perl-Devel-Caller.spec | 17 +++--
sources|2 +-
3 files changed, 17 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1f8e609..d3baeff 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Devel-Caller-2.05.tar.gz
+/Devel-Caller-2.06.tar.gz
diff --git a/perl-Devel-Caller.spec b/perl-Devel-Caller.spec
index d2500a8..517a964 100644
--- a/perl-Devel-Caller.spec
+++ b/perl-Devel-Caller.spec
@@ -1,15 +1,25 @@
Name: perl-Devel-Caller
-Version:2.05
-Release:12%{?dist}
+Version:2.06
+Release:1%{?dist}
Summary:Meatier versions of caller
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Devel-Caller/
Source0:
http://www.cpan.org/authors/id/R/RC/RCLAMP/Devel-Caller-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time:
+BuildRequires: perl(B)
+BuildRequires: perl(base)
+BuildRequires: perl(Exporter)
BuildRequires: perl(PadWalker) = 0.08
+BuildRequires: perl(XSLoader)
+# Tests:
BuildRequires: perl(Test::More)
+BuildRequires: perl(vars)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# Don't provide Caller.so or perl(DB)
@@ -56,6 +66,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Devel::Caller.3pm*
%changelog
+* Fri Jul 19 2013 Petr Pisar ppi...@redhat.com - 2.06-1
+- 2.06 bump
+
* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 2.05-12
- Perl 5.18 rebuild
diff --git a/sources b/sources
index ce3cf42..f196867 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2d197318ce8e8d736f23b7f751e8b093 Devel-Caller-2.05.tar.gz
+af52f47979b3c9358af9e5d8c283f263 Devel-Caller-2.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Crypt-DES-2.05_002.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Crypt-DES: e9a55f450730593b7165c58ec3acdbc2 Crypt-DES-2.05_002.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-Crypt-DES] 2.05_002 bump
commit 19b26e18de1dfbaf8c1644f6205da575c38f178d
Author: Petr Písař ppi...@redhat.com
Date: Fri Jul 19 14:16:30 2013 +0200
2.05_002 bump
.gitignore |1 +
perl-Crypt-DES.spec | 20 ++--
sources |2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 31a1ad7..c50e154 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Crypt-DES-2.05.tar.gz
+/Crypt-DES-2.05_002.tar.gz
diff --git a/perl-Crypt-DES.spec b/perl-Crypt-DES.spec
index 3080d09..612cfb1 100644
--- a/perl-Crypt-DES.spec
+++ b/perl-Crypt-DES.spec
@@ -1,21 +1,26 @@
+%global cpan_version 2.05_002
Name: perl-Crypt-DES
-Version:2.05
-Release:20%{?dist}
+Version:%(echo '%{cpan_version}' | tr _ .)
+Release:1%{?dist}
Summary:Perl DES encryption module
License:BSD
Group: Development/Libraries
URL:http://search.cpan.org/dist/Crypt-DES/
-Source0:
http://www.cpan.org/authors/id/D/DP/DPARIS/Crypt-DES-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/D/DA/DAVIDO/Crypt-DES-%{cpan_version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-time:
BuildRequires: perl(Carp)
BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
# Tests:
-BuildRequires: perl(Crypt::CBC) 1.22
BuildRequires: perl(Benchmark)
BuildRequires: perl(Data::Dumper)
+# Optional tests:
+BuildRequires: perl(Crypt::CBC) 1.22
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -24,7 +29,7 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
DES encryption module.
%prep
-%setup -q -n Crypt-DES-%{version}
+%setup -q -n Crypt-DES-%{cpan_version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
@@ -49,12 +54,15 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc COPYRIGHT README
+%doc Changes COPYRIGHT README
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/Crypt*
%{_mandir}/man3/*
%changelog
+* Fri Jul 19 2013 Petr Pisar ppi...@redhat.com - 2.05.002-1
+- 2.05_002 bump
+
* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 2.05-20
- Perl 5.18 rebuild
diff --git a/sources b/sources
index c9093f3..65e00d2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a8a0bea7064e11d2af434f3e468c17bb Crypt-DES-2.05.tar.gz
+e9a55f450730593b7165c58ec3acdbc2 Crypt-DES-2.05_002.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-Gearman-Client-Async] Specify all dependencies
commit fe4fa90c0ef490415b0ca3cc2058401234e56e1a
Author: Petr Písař ppi...@redhat.com
Date: Fri Jul 19 19:22:01 2013 +0200
Specify all dependencies
perl-Gearman-Client-Async.spec | 48 ++--
1 files changed, 36 insertions(+), 12 deletions(-)
---
diff --git a/perl-Gearman-Client-Async.spec b/perl-Gearman-Client-Async.spec
index 132e378..335fa4d 100644
--- a/perl-Gearman-Client-Async.spec
+++ b/perl-Gearman-Client-Async.spec
@@ -9,28 +9,46 @@ Source0:
http://www.cpan.org/authors/id/B/BR/BRADFITZ/Gearman-Client-Asyn
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Test::More)
+# Run-time:
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(constant)
+BuildRequires: perl(Danga::Socket) = 1.52
+BuildRequires: perl(fields)
+BuildRequires: perl(Gearman::JobStatus)
+BuildRequires: perl(Gearman::Objects)
+BuildRequires: perl(Gearman::ResponseParser)
+BuildRequires: perl(Gearman::Task)
+BuildRequires: perl(Gearman::Util)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Socket)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
+# Tests:
+BuildRequires: perl(FindBin)
BuildRequires: perl(Gearman::Server)
-
+BuildRequires: perl(Gearman::Worker)
+BuildRequires: perl(Getopt::Long)
+BuildRequires: perl(IO::Socket::INET)
+BuildRequires: perl(lib)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+# Filter double Requires:
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Danga::Socket\\)$
+
%description
Asynchronous Client for the Gearman distributed job system
%prep
%setup -q -n Gearman-Client-Async-%{version}
-# Filter double Requires:
-cat \EOF %{name}-req
-#!/bin/sh
-%{__perl_requires} $* |\
- sed -e '/^perl(Danga::Socket)$/d'
-EOF
-
-%define __perl_requires
%{_builddir}/Gearman-Client-Async-%{version}/%{name}-req
-chmod +x %{__perl_requires}
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -38,6 +56,10 @@ make %{?_smp_mflags}
mv README.txt README
%check
+# t/err1.t blocks (CPAN RT#73048, 82700)
+rm t/err1.t
+# t/err3.t fails (CPAN RT#87063)
+rm t/err3.t
# this test fails to run on x86_64 (#246356)
rm t/err8.t
make test
@@ -64,6 +86,8 @@ rm -rf %{buildroot}
%changelog
* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 0.94-16
- Perl 5.18 rebuild
+- Specify all dependencies
+- Disable some tests
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.94-15
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 892597] Review Request: glite-lb-types - Build-time component for gLite LB
https://bugzilla.redhat.com/show_bug.cgi?id=892597 --- Comment #16 from Fedora Update System upda...@fedoraproject.org --- glite-lb-types-2.0.7-2.el6 has been pushed to the Fedora EPEL 6 stable repository. -- 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=KEDJnGe4cda=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-NetPacket-SpanningTree] Compatibility with perl 5.18
commit 4cbff5d3e38e363435d2b103d7718d425ac8af03
Author: Petr Písař ppi...@redhat.com
Date: Sat Jul 20 07:26:45 2013 +0200
Compatibility with perl 5.18
01-qw-does-not-imply-parentheses-anymore.patch | 40
perl-NetPacket-SpanningTree.spec |4 ++
2 files changed, 44 insertions(+), 0 deletions(-)
---
diff --git
a/NetPacket-SpanningTree-0.01-qw-does-not-imply-parentheses-anymore.patch
b/NetPacket-SpanningTree-0.01-qw-does-not-imply-parentheses-anymore.patch
new file mode 100644
index 000..41232b1
--- /dev/null
+++ b/NetPacket-SpanningTree-0.01-qw-does-not-imply-parentheses-anymore.patch
@@ -0,0 +1,40 @@
+From bb02037ea3985d53362371272df6c600aa32a15c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Sat, 20 Jul 2013 07:18:53 +0200
+Subject: [PATCH] qw does not imply parentheses anymore
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+https://rt.cpan.org/Public/Bug/Display.html?id=87085
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ SpanningTree.pm | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/SpanningTree.pm b/SpanningTree.pm
+index c03d3a0..95c4c08 100644
+--- a/SpanningTree.pm
b/SpanningTree.pm
+@@ -247,7 +247,7 @@ sub encode {
+ # Invert the message age for encoding.
+ #
+
+-foreach my $name qw(message_age hello_time max_age forward_delay) {
++foreach my $name (qw(message_age hello_time max_age forward_delay)) {
+ $data-{$name} = $data-{$name} * 256;
+ }
+
+@@ -267,7 +267,7 @@ sub encode {
+ #
+ # Put back the message age.
+ #
+-foreach my $name qw(message_age hello_time max_age forward_delay) {
++foreach my $name (qw(message_age hello_time max_age forward_delay)) {
+ $data-{$name} = $data-{$name} / 256;
+ }
+ $data-{bpdu_type} = hex ($data-{bpdu_type});
+--
+1.8.1.4
+
diff --git a/perl-NetPacket-SpanningTree.spec b/perl-NetPacket-SpanningTree.spec
index 0e7dc3b..09ca5e1 100644
--- a/perl-NetPacket-SpanningTree.spec
+++ b/perl-NetPacket-SpanningTree.spec
@@ -8,6 +8,8 @@ URL:
http://search.cpan.org/dist/NetPacket-SpanningTree/
Source0:
http://www.cpan.org/authors/id/C/CG/CGANESAN/NetPacket-SpanningTree-%{version}.tar.gz
# email from author with permissions to relicense sources under Artistic or GPL
Source1:%{name}.email
+# Compatibility with perl 5.18, CPAN RT#87085
+Patch0:
NetPacket-SpanningTree-0.01-qw-does-not-imply-parentheses-anymore.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -25,6 +27,7 @@ specification.
%prep
%setup -q -n NetPacket-SpanningTree-%{version}
+%patch0 -p1
cp %{SOURCE1} .
%build
@@ -56,6 +59,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Thu Jul 18 2013 Petr Pisar ppi...@redhat.com - 0.01-9
- Perl 5.18 rebuild
+- Compatibility with perl 5.18 (CPAN RT#87085)
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.01-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Multirelease effort: Moving to Python 3
On Fri, Jul 19, 2013 at 02:41:23AM -0400, Bohuslav Kabrda wrote: - Original Message - On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote: Hi all, as a new Fedora Python maintainer, I have set myself a goal of moving Fedora to Python 3 as a default. I'm not sure we want to make python3 default depending on what your definition of default is. /usr/bin/python should refer to python2 -- http://www.python.org/dev/peps/pep-0394/ I'd be -1 to changing this So, my definition of default is all system tools use Python 3, it is the only Python that gets to minimal buildroot/minimal Fedora installation - that means: I'm okay with this portion of the definition. One note is I would be hesitant about the timing of python3 being the only python that is installed into the minimal buildroot. This should probably happen in rawhide right after a branching. - livecd can still ship Python 2 I would consider this to be the goal that we should shoot for, though. We are constantly fighting for space on the install images and we know that people who install Fedora would like to have the ability to slim down what is installed. Shooting for no-python2 on the livecds and after that, no python2 on the install dvds, and still later, no need for python2 in the packages in the repository seem like milestones that have actual real value for end users. - /usr/bin/python points to Python 3 I am firmly against this. more depth was in my reply to mmaslano although I'll reply to one thing here: - Please note, that the pep you're referring to also states that python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions, so this wouldn't really be going against the pep. This is a misinterpretion of the PEP. (This section is confusing, though: python should refer to the same target as python2 is a recommendation to distributions. but may refer to python3 on some bleeding edge distributions is a statement of fact for end users to watch out for) See the recommendation section: For the time being, it is recommended that python should refer to python2 (however, some distributions have already chosen otherwise; see the Rationale and Migration Notes below). and Future Changes Section: http://www.python.org/dev/peps/pep-0394/#future-changes-to-this-recommendation It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2. This recommendation will be periodically reviewed over the next few years, and updated when the core development team judges it appropriate. The may refer to python3 phrase is an acknowledgment that arch has moved to /usr/bin/python == python3 and isn't going to revert even though upstream thinks it's a... premature time to make that switch. (To be fair to arch, the discussion and PEP happened as a result of arch making that switch so they'd already committed to that before the consensus was formed that this would be a bad thing to do atthis time. We don't have that excuse ;-) If you'd like to read the discussions for yourself, there are three threads linked from the PEP. An even earlier one is at: http://mail.python.org/pipermail/python-dev/2010-November/105252.html The python package itself should probably also remain python2 due to dependencies and expectations from other distros and documentation -- I think I'd be -1 to changing this The Fedora live images contain only python3, not python2 -- I'd be heavily in favour of this. +1 This is going to be a multirelease effort that is going to affect lots of Fedora parts. Since we will need to switch default package manager from Yum to DNF (which is supposed to work with Python 3), we will need to wait for that. I've been told that DNF should be default in F22, so that's my target, too. That should also give everyone else plenty of time to work on other essential packages to make this happen. Getting there at the same time as we get to DNF sounds like a good timeline. (But see my note on anaconda below). +1 Here is my analysis/proposal: Before switching, we need to make sure that everything important (*) is Python 3 compatible. There are three steps I see in this transition: 1) Getting rid of Python 2 in mock minimal buildroot. I'm not sure about this one as it will cause a lot of package churn. It might be a necessary pain pointi or it might be a pain point we want to defer until later in our porting efforts. Have to think about it more. If you look at the minimal mock buildroot for rawhide now, the only thing that is drawing in Python is gdb because of it's Python bindings (if I'm not mistaken). So compiling GDB against Python 3, which should work with newest
