EPEL epel beta report: 20140204 changes
Compose started at Tue Feb 4 08:15:02 UTC 2014 Broken deps for x86_64 -- bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires nagios check-mk-1.2.2p2-2.el7.x86_64 requires mod_python dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::bars) erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst lua-lxc-0.9.0-3.el7.x86_64 requires lua-filesystem lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox nagios-plugins-nrpe-2.15-1.el7.x86_64 requires nagios-plugins nrpe-2.15-1.el7.x86_64 requires nagios-common openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg perl-PDL-2.7.0-2.el7.1.x86_64 requires perl(Prima::MsgBox) python-social-auth-0.1.19-1.el7.noarch requires python-requests-oauthlib = 0:0.3.0 python-social-auth-0.1.19-1.el7.noarch requires python-oauthlib = 0:0.3.8 python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 snmptt-1.4-0.9.beta2.el7.noarch requires perl-Net-SNMP spectrwm-2.4.0-2.el7.x86_64 requires xlockmore spectrwm-2.4.0-2.el7.x86_64 requires dmenu supervisor-3.0-1.el7.noarch requires python-meld3 = 0:0.6.5 w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds Broken deps for ppc64 -- TurboGears-1.1.3-8.el7.noarch requires python-simplejson = 0:1.9.1 bodhi-client-0.9.7-1.el7.noarch requires python-simplejson bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires nagios check-mk-1.2.2p2-2.el7.ppc64 requires mod_python dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::bars) erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript fedmsg-0.7.2-1.el7.noarch requires python-simplejson fedmsg-0.7.2-1.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine httpie-0.8.0-1.el7.noarch requires python-requests imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst lua-lxc-0.9.0-3.el7.ppc64 requires lua-filesystem lxc-templates-0.9.0-3.el7.ppc64 requires dpkg lxc-templates-0.9.0-3.el7.ppc64 requires debootstrap lxc-templates-0.9.0-3.el7.ppc64 requires busybox nagios-plugins-nrpe-2.15-1.el7.ppc64 requires nagios-plugins nrpe-2.15-1.el7.ppc64 requires nagios-common openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(Prima::MsgBox) perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) python-fedora-0.3.33-1.el7.noarch requires python-simplejson python-fedora-0.3.33-1.el7.noarch requires python-requests python-oauth2-1.5.211-4.el7.noarch requires python-simplejson python-requests-kerberos-0.3-2.el7.noarch requires python-requests = 0:1.0 python-social-auth-0.1.19-1.el7.noarch requires python-requests-oauthlib = 0:0.3.0 python-social-auth-0.1.19-1.el7.noarch requires python-requests = 0:1.1.0 python-social-auth-0.1.19-1.el7.noarch
Re: Fedora.NEXT Products and the fate of Spins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/03/2014 11:06 PM, Brendan Jones wrote: On 01/31/2014 12:28 PM, Ian Malone wrote: On 30 January 2014 23:07, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 01/29/2014 07:10 PM, Ian Malone wrote: On 29 January 2014 23:58, Josh Boyer jwbo...@fedoraproject.org wrote: I consider myself squarely in the middle of those two camps. I think they have value to people. I think they fill a niche, however large or small it might be. I also think they can be done by the people wishing to provide them without relying on Fedora resources for hosting and creation (outside of leveraging existing packages and repositories). I don't consider that getting rid of them at all. On the contrary, I think it lets people have more control over their spins, allows them to refresh them as they see fit throughout the release, and allows them to market and promote them beyond a token mention on a Fedora website. Some care is needed, if there are things getting packaged to fill a role in a spin they may disappear from Fedora if the spin in question does. On one hand, I am impressed by many spins as an excellent technology demonstration. On the other hand, what should existing users of a base Fedora do if they find an useful spin with a superior functionality? If its function is not integrated and easily accessible from the base system, they must either dual-boot or re-install from the spin. Therefore I prefer that the spins ultimate goal is to include the functionality into generic Fedora. The same goes for other bundling schemes discussed here. It's not that I object to them per se, but I do think that there's an opportunity cost involved: the person caring about the spin has to chose between working on integrating the spin functionality in generic Fedora, and developing the spin separately. I do recognize that the former is harder, but the opposite tack has a potential to fragment Fedora. Spins should be like branches in a VCS: let's not turn them into forks. I think the strength of Fedora comes from it being an excellent platform for all kinds of FOSS software, and the associated network effect---the better the platform is, the faster it gets better. Spins is a loaded term in Fedora that means exactly what you suggest. An approved Spin, by definition, must only include packages (and functionality) that is contained in the generic Fedora repositories. So the project seems to very much agree with you. Remixes can contain external packages and have the pluses and minuses that you highlight. Some of the discussion to date has been suggesting or implying that Spins become Remixes, but I think that things that are already Spins would likely retain the qualities you desire. The discussion has a lot of tribal knowledge behind it, so if you aren't overly familiar with the history behind these concepts I can see how it would be confusing. Indeed what Przemek Klosowski described (forking fedora) is what making all spins remixes might do. Concrete example: real-time audio. If left to its own devices a music production spin would probably do a realtime kernel and set priorites for jack on its own. However since whatever change was made had to apply to all fedora the result was that the default RT priority for jack was changed in the package (a realtime kernel not being necessarily required http://jackaudio.org/realtime_vs_realtime_kernel), so all Fedora JACK users get a better chosen default (though they still need to make manual changes to groups to benefit from it). I can certainly see the benefits of forking in the domain of audio. However I would also be a little concerned that maintainers of said spins, might just stop bothering to package new audio software in upstream Fedora repositories at all. If they are going to the trouble of of hosting there spins, I can't see why they wouldn't just host there own packages as well (with custom compiler flags and whatever). This is the domain of Fedora Remixes, not Fedora Spins. Downstreams are permitted (naturally) to use Fedora packages for whatever distribution they want to create. The catch is that they have to follow the policies on this page: https://fedoraproject.org/wiki/Remix The primary difference is that Fedora Remixes have to provide their own website and image hosting, as they are Fedora-derived, not Fedora-provided. I'd worry that this is going to result in a poorer quality audio experience in Fedora (for example have those nice arch guys come along and provide patches to audio software that doesn't build). Who's going to do that on 3rd party repos? The sort of person who does that in Fedora in the first place is likely to do so for a Remix if they're using it as well. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment:
Re: Fedora.NEXT Products and the fate of Spins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2014 11:07 PM, Kevin Kofler wrote: Stephen Gallagher wrote: Right now, the vision essentially looks like: Fedora Products: This *is* Fedora. It comes in three flavors. I don't like the hardcoded three there at all, because if KDE is to ever become a full-fledged Product (which IMHO it should have been from the beginning!), it will need to change (unless you're dropping one of your 3 sacred spins). Well, I thought it was clear, since I did include the words Right now, but yes: I do think that other products should be both permitted and planned. One thing I've been discussing as an option with some of the members of the KDE SIG is to promote Fedora Scientific, based on the present-day KDE and Scientific Spins, as a fourth Fedora Product. I think this would be valuable as it would also act as a prototype for what the new-product process will need to be going forward. To address another concern you had elsewhere: One of the stated goals of the Products is to provide a known and reliable setup. I don't view it as reducing Freedom (or Choice) because a clear goal of this effort is to ensure that if you don't want this setup, you don't have to use it. You will be able to either install one of the the Products (and later remove packages you don't want) or you can install individual packages directly from the netinstall.iso just as you have always done. So I really view this as an add-on: if the *choice* a user wants to make is I'd like someone who knows more than I do to make the decision about what I should have installed, that's just as valid a choice as I want to use DNF instead of YUM. It's just taking place at a higher level. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLwsTIACgkQeiVVYja6o6PjhgCgneEHSY6BHKprKxdul+Naw/FN Z2gAoJf2kF1QEq8ixaEs4LvJLn6MROOR =ai3m -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 4, 2014 at 1:03 AM, Stephen Gallagher sgall...@redhat.com wrote: This is the domain of Fedora Remixes, not Fedora Spins. Downstreams are permitted (naturally) to use Fedora packages for whatever distribution they want to create. The catch is that they have to follow the policies on this page: https://fedoraproject.org/wiki/Remix The primary difference is that Fedora Remixes have to provide their own website and image hosting, as they are Fedora-derived, not Fedora-provided. The sort of person who does that in Fedora in the first place is likely to do so for a Remix if they're using it as well. Hi, So where do we currently stand with this? Are we leaning towards spins going away? Are we leaning towards keeping some spins and getting rid of others? What about proposals for new spins? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, Jan 30, 2014 at 12:01:40AM +, Ian Malone wrote: Two thoughts: 1. Is there scope for a spin to be a particular sub-focus of a product? Desktop (all) . desktop gnome . desktop kde . desktop twm (maybe not) Server (all) . server web . server fileserver (or whatever might make sense) The idea being that everything under one product should be a subdivision of what would be included anyway. I realise there's the potential there to snowball again. It looks like the Cloud and Server WGs are both going this way, with Server offering a base plus different roles (like your web and fileserver examples), and Cloud offering a generic image plus several tailored for specific uses (docker, big data, etc.). The Workstation WG is going in a different direction, but I also think the situation is legitimately a bit different, as the intention is for the server roles to have fundamentally the same interface/experience, and it's likely that basic things like cloud-init will remain in the different cloud... uh... spins. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libxnvctrl status?
On 02/04/2014 04:58 AM, Christopher Meng wrote: Hi all, Can someone tell me why this library is still at a very old version packaged in Fedora? I've seen RFEs about updating it to the latest version, but maintainer Adam Jackson hasn't done neither any to this package still so far, nor response to any bugs. Is this library disallowed now because it's from nvidia? Why should a package be disallowed because it's from NVidia? As long as a package's licensing complies to Fedora's requirements a package's origin is irrelevant. Or it should be retired? Why do you think it should be? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libxnvctrl status?
On 02/04/2014 08:54 AM, Simone Caronni wrote: The source code comes from the nvidia-settings tarball; and following the same logic we should allow all the relevant open source components of the Nvidia driver [2] in Fedora, that is: Correct, we could - Similar things are being done at several places in Fedora. Somewhat oversimplified, the basic requirement is all shipped binaries must be built from OSI-compiliant sources-code and no closed-sources be used. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
I'm not fond of keeping spins around when we're focusing on products. That gives the message that they are second-class citizens in Fedora. I'd rather define a process that allows current spins to become either sub-products or full-featured products when they meet a set of requirements (that is to be defined yet). In a contributor-driven community, it shouldn't be a problem to accept new products if it is backed appropriately. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2014 11:11 AM, H. Guémar wrote: I'm not fond of keeping spins around when we're focusing on products. That gives the message that they are second-class citizens in Fedora. To be fair, spins have always been second-class citizens (to a point). They've always been relegated to a secondary page from the standard install media. I'd rather define a process that allows current spins to become either sub-products or full-featured products when they meet a set of requirements (that is to be defined yet). In a contributor-driven community, it shouldn't be a problem to accept new products if it is backed appropriately. This I agree with completely. We need to define a process for how to promote new Products. I *will* say that such a process will probably include a requirement that it must be more than just a technology deliverable (i.e. Just the XFCE Spin renamed). A product will likely need to define a target not currently served by one of the existing products (or the overlap will need to be justified). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLwwyUACgkQeiVVYja6o6NmsQCfTUCY2q3bUKON4vo+J1j9Qnqx OboAnixXUmp0HGNqqwBtjVv1cth05B2d =TxoF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2014 10:34 AM, Dan Mashal wrote: On Tue, Feb 4, 2014 at 1:03 AM, Stephen Gallagher sgall...@redhat.com wrote: This is the domain of Fedora Remixes, not Fedora Spins. Downstreams are permitted (naturally) to use Fedora packages for whatever distribution they want to create. The catch is that they have to follow the policies on this page: https://fedoraproject.org/wiki/Remix The primary difference is that Fedora Remixes have to provide their own website and image hosting, as they are Fedora-derived, not Fedora-provided. The sort of person who does that in Fedora in the first place is likely to do so for a Remix if they're using it as well. Hi, So where do we currently stand with this? Are we leaning towards spins going away? Are we leaning towards keeping some spins and getting rid of others? What about proposals for new spins? I won't speak for all of FESCo, but I'm leaning towards: Spins can continue just as they are, while being aware that they continue to be secondary to our primary deliverables. (Yes, I'm aware of the KDE-as-release-blocker rule and we'll address that individually). So new spins and existing Spins are fine (in my opinion) as long as someone is caring for and feeding them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLww5YACgkQeiVVYja6o6PtYACfUeW9oYycRD7n9b3+kc593KFu gFoAni0WVryNnZp2M7WTioqYXudwFTp2 =GfMO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, Jan 30, 2014 at 12:16:16PM -0800, Adam Williamson wrote: If we decide the alternative desktops are a valuable part of Fedora - which seems to be a popular opinion - how do we fit them into a Product-based conception of Fedora? We can have a KDE Product, and an Xfce Product, and an LXDE Product, but...at that point haven't we just re-invented spins? It doesn't seem to quite work with the Product conception. I would like to see Products defined by the problem space that they are aimed at rather than the technology they're based on. That is, a Fedora Scientific Desktop is a lot more compelling to me than Fedora KDE -- at least as a product. But I don't think there's anything wrong with Fedora KDE as either a spin or something else. For that matter, there could be a Fedora GNOME spin distinct from the Fedora Workstation product, if there were people really keen to work on it, perhap as a showcase of upstream technology without worrying about the concerns of the Fedora Workstation WG's particular area of focus. (With people keen to work on it as the really key phrase.) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
2014-02-04 Stephen Gallagher sgall...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I won't speak for all of FESCo, but I'm leaning towards: Spins can continue just as they are, while being aware that they continue to be secondary to our primary deliverables. [snip] Yes, in my eyes that's the reason why spins should not become a separate product. They can/should be part of a product, such as Workstation, and maybe only Security is worth a discussion apart. How we will call the spins in fedora.ext is not important, but we should have a clear idea soon about them. Personally I wouldn't either keep any of them as release blocking (except GNOME probably), only products should be able to block a release. Just my personal thought about this topic ;) Cheers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 02/04/2014 10:39 AM, Matthew Miller wrote: On Thu, Jan 30, 2014 at 12:16:16PM -0800, Adam Williamson wrote: If we decide the alternative desktops are a valuable part of Fedora - which seems to be a popular opinion - how do we fit them into a Product-based conception of Fedora? We can have a KDE Product, and an Xfce Product, and an LXDE Product, but...at that point haven't we just re-invented spins? It doesn't seem to quite work with the Product conception. I would like to see Products defined by the problem space that they are aimed at rather than the technology they're based on. That is, a Fedora Scientific Desktop is a lot more compelling to me than Fedora KDE -- at least as a product. But I don't think there's anything wrong with Fedora KDE as either a spin or something else. For that matter, there could be a Fedora GNOME spin distinct from the Fedora Workstation product, if there were people really keen to work on it, perhap as a showcase of upstream technology without worrying about the concerns of the Fedora Workstation WG's particular area of focus. (With people keen to work on it as the really key phrase.) But you cannot overlap products as in you cannot have a Gnome workstation and KDE workstation etc you cannot have an Server product outside what is already defined in the ServerWG nor a Cloud product outside what is already defined there. Basically what's happening here is that default is being applied to now three spaces which filled with Red Hat products and elevated above community contribution just like Gnome was put above all community contributions as an Default. Do people truly really want us to move forward with this discrimination between contributions to the project? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, Jan 30, 2014 at 05:51:31AM -0500, Christian Schaller wrote: What I mean to say is that Red Hat has a business motive to support the Fedora community, if supporting Fedora was a pure act of charity then I think organizations like the Red Cross or Unicef would have a much better chance of getting the money. This is certainly true, but the benefits to Red Hat also go far beyond the immediate return on investment. And, many of those benefits simply do not happen for Red Hat if the company does not _genuinely_ invest in community support, including beyond current, obvious product connections. I know you know that, but it doesn't come across clearly in your statements. And, of course, for many Red Hatters, it's deeper than the cold financial calculus. We care about this project and its values, and that's why we're here. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Am 04.02.2014 11:57, schrieb Jóhann B. Guðmundsson: On 02/04/2014 10:39 AM, Matthew Miller wrote: On Thu, Jan 30, 2014 at 12:16:16PM -0800, Adam Williamson wrote: If we decide the alternative desktops are a valuable part of Fedora - which seems to be a popular opinion - how do we fit them into a Product-based conception of Fedora? We can have a KDE Product, and an Xfce Product, and an LXDE Product, but...at that point haven't we just re-invented spins? It doesn't seem to quite work with the Product conception. I would like to see Products defined by the problem space that they are aimed at rather than the technology they're based on. That is, a Fedora Scientific Desktop is a lot more compelling to me than Fedora KDE -- at least as a product. But I don't think there's anything wrong with Fedora KDE as either a spin or something else. For that matter, there could be a Fedora GNOME spin distinct from the Fedora Workstation product, if there were people really keen to work on it, perhap as a showcase of upstream technology without worrying about the concerns of the Fedora Workstation WG's particular area of focus. (With people keen to work on it as the really key phrase.) But you cannot overlap products as in you cannot have a Gnome workstation and KDE workstation etc you cannot have an Server product outside what is already defined in the ServerWG nor a Cloud product outside what is already defined there. Basically what's happening here is that default is being applied to now three spaces which filled with Red Hat products and elevated above community contribution just like Gnome was put above all community contributions as an Default. Do people truly really want us to move forward with this discrimination between contributions to the project? honestly going back to only a install DVD with a sane user-UI and dedicate all the time wasted for the spin/products/discrimination discussions for documentations, screenshots and howtos would have more benefit for Fedora there is nothing you can't setup with the one fits all DVD or even with a slim network install if you only knew what to install and how to configure signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
It's also a negative message to the 1.4 k active contributors in fedora. Or do you assume that most of them are paid by RH which is unlikely. Don't forget that fp.o has been founded with two stakeholders: RH and the community H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 4, 2014 at 2:40 AM, Stephen Gallagher sgall...@redhat.com wrote: I won't speak for all of FESCo, but I'm leaning towards: Spins can continue just as they are, while being aware that they continue to be secondary to our primary deliverables. (Yes, I'm aware of the KDE-as-release-blocker rule and we'll address that individually). So new spins and existing Spins are fine (in my opinion) as long as someone is caring for and feeding them. Thanks, that's good news. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
2014-02-04 Matthew Miller mat...@fedoraproject.org: On Thu, Jan 30, 2014 at 05:51:31AM -0500, Christian Schaller wrote: What I mean to say is that Red Hat has a business motive to support the Fedora community, if supporting Fedora was a pure act of charity then I think organizations like the Red Cross or Unicef would have a much better chance of getting the money. This is certainly true, but the benefits to Red Hat also go far beyond the immediate return on investment. And, many of those benefits simply do not happen for Red Hat if the company does not _genuinely_ invest in community support, including beyond current, obvious product connections. I know you know that, but it doesn't come across clearly in your statements. And, of course, for many Red Hatters, it's deeper than the cold financial calculus. We care about this project and its values, and that's why we're here. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Thank you Matt, I was very concerned about this statement indeed. Haikel, you got the point of my thought too :) -- Robert Mayr (robyduck) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libxnvctrl status?
On 4 February 2014 11:03, Ralf Corsepius rc040...@freenet.de wrote: Correct, we could - Similar things are being done at several places in Fedora. Somewhat oversimplified, the basic requirement is all shipped binaries must be built from OSI-compiliant sources-code and no closed-sources be used. Well, the tools are totally opensource and can be built standalone, libXNVCtrl will interface with the Nvidia X.org driver; but what is the benefit of having them in Fedora if they can't be used without the proprietary blobs? Currently there's a policy that game engines cannot be shipped in Fedora if the content is not free as well; shouldn't the policy be the same (i.e. allow the engines without content or remove the tools as well)? Thanks, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libxnvctrl status?
On 4 February 2014 11:34, Simone Caronni negativ...@gmail.com wrote: but what is the benefit of having them in Fedora if they can't be used without the proprietary blobs? I've always wondered the same thing. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File CPANPLUS-0.9148.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-CPANPLUS: e135aab8af0f16e07ddf1fe096680a00 CPANPLUS-0.9148.tar.gz -- 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
[Bug 1061113] New: perl-Text-Aligner-0.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061113 Bug ID: 1061113 Summary: perl-Text-Aligner-0.10 is available Product: Fedora Version: rawhide Component: perl-Text-Aligner Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-de...@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.10 Current version/release in Fedora Rawhide: 0.08-1.fc21 URL: http://search.cpan.org/dist/Text-Aligner/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RGxqWQMrBWa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061114] New: perl-URI-Find-Simple-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061114 Bug ID: 1061114 Summary: perl-URI-Find-Simple-1.04 is available Product: Fedora Version: rawhide Component: perl-URI-Find-Simple Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.04 Current version/release in Fedora Rawhide: 1.03-7.fc20 URL: http://search.cpan.org/dist/URI-Find-Simple/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=MJVWw4sUqaa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061115] New: perl-URI-Title-1.87 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061115 Bug ID: 1061115 Summary: perl-URI-Title-1.87 is available Product: Fedora Version: rawhide Component: perl-URI-Title Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.87 Current version/release in Fedora Rawhide: 1.86-7.fc21 URL: http://search.cpan.org/dist/URI-Title/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1LSvWndhDna=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPANPLUS] 0.9148 bump
commit fadcaded4d1160b825aade2e7d55677fd2c5185e
Author: Petr Písař ppi...@redhat.com
Date: Tue Feb 4 12:59:09 2014 +0100
0.9148 bump
.gitignore |1 +
perl-CPANPLUS.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8b58c4c..4880ba1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ CPANPLUS-0.84.tar.gz
/CPANPLUS-0.9142.tar.gz
/CPANPLUS-0.9144.tar.gz
/CPANPLUS-0.9146.tar.gz
+/CPANPLUS-0.9148.tar.gz
diff --git a/perl-CPANPLUS.spec b/perl-CPANPLUS.spec
index 2c884bf..e600fea 100644
--- a/perl-CPANPLUS.spec
+++ b/perl-CPANPLUS.spec
@@ -1,4 +1,4 @@
-%global cpan_version 0.9146
+%global cpan_version 0.9148
Name: perl-CPANPLUS
# Keep 2-digit major varion to compete with perl.spec for history
Version:%(echo '%{cpan_version}' | sed 's/\(\...\)/\1./')
@@ -120,6 +120,9 @@ make test %{?_smp_mflags}
%{_mandir}/man3/*
%changelog
+* Tue Feb 04 2014 Petr Pisar ppi...@redhat.com - 0.91.48-1
+- 0.9148 bump
+
* Mon Feb 03 2014 Petr Pisar ppi...@redhat.com - 0.91.46-1
- 0.9146 bump
- Run tests in parallel
diff --git a/sources b/sources
index 270a4c6..edbf833 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-23dc6614318b699b37064b4c4e109e50 CPANPLUS-0.9146.tar.gz
+e135aab8af0f16e07ddf1fe096680a00 CPANPLUS-0.9148.tar.gz
--
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: Meeting minutes Env-and-Stacks WG meeting (2014-01-28)
ACTION: bkabrda will write more about devassistant (mmaslano, 16:44:20) I tried to rewrite the DevAssistant part to be more high-level and to also include information on what we should do with DevAssistant. Hope it's enough. Slavek. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes Env-and-Stacks WG meeting (2014-01-28)
On 4 February 2014 12:02, Bohuslav Kabrda bkab...@redhat.com wrote: I tried to rewrite the DevAssistant part to be more high-level and to also include information on what we should do with DevAssistant. Hope it's enough. Should DevAssistant and gnome software work together? I think there are a lot of overlapping use-cases. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes Env-and-Stacks WG meeting (2014-01-28)
- Original Message - On 4 February 2014 12:02, Bohuslav Kabrda bkab...@redhat.com wrote: I tried to rewrite the DevAssistant part to be more high-level and to also include information on what we should do with DevAssistant. Hope it's enough. Should DevAssistant and gnome software work together? I think there are a lot of overlapping use-cases. It'd certainly be worth looking into. What particular use-cases do you have in mind? Richard -- Regards, Bohuslav Slavek Kabrda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1061103] perl-Compress-Raw-Zlib-2.065 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061103 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Compress-Raw-Zlib-2.06 ||5-1.fc21 Resolution|--- |RAWHIDE Assignee|jples...@redhat.com |p...@city-fan.org Last Closed||2014-02-04 07:10:25 --- Comment #1 from Paul Howarth p...@city-fan.org --- Build done: http://koji.fedoraproject.org/koji/taskinfo?taskID=6489057 -- 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=qVOjOvEiBAa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Introducing myself
Il 03/02/2014 14:09, Christopher Meng ha scritto: Please use your real name for the email address/Bugzilla account. I've just edited the name on bugzilla adding my last name. Thank you for the tip. Hope to find someone interested to my packages. Greetings, Alberto -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 04, 2014 at 10:57:51AM +, Jóhann B. Guðmundsson wrote: For that matter, there could be a Fedora GNOME spin distinct from the Fedora Workstation product, if there were people really keen to work on it, perhap as a showcase of upstream technology without worrying about the concerns of the Fedora Workstation WG's particular area of focus. (With people keen to work on it as the really key phrase.) But you cannot overlap products as in you cannot have a Gnome workstation and KDE workstation etc you cannot have an Server product outside what is already defined in the ServerWG nor a Cloud product outside what is already defined there. I think it's okay for there to be some overlap. The real world doesn't always chop up into neat boxes. If there's a *lot* of overlap between two nominally-different products, then that is less useful and it's probably better for them to either work together or else find a stronger differentiation. But that's talking about products. As long as someone is interested in doing them, spins can overlap like crazy. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Problems running mock with rawhide build root
Hi, I'm having problems running mock with a rawhide buildroot.
I get the following error
ERROR: Command failed. See logs for output.
# /usr/bin/repoquery -c /tmp/tmpQ6Wu7m --installed -a --qf '%{nevra}
%{buildtime} %{size} %{pkgid} %{yumdb_info.from_repo}'
/var/lib/mock/fedora-rawhide-x86_64/result/installed_pkgs
And in the root.log file
DEBUG util.py:281: error: cannot open Packages index using db5 -
Permission denied (13)
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
Which seems highly suspicious. Is something related with RPM broken in
rawhide?
Regards, Sergio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora.NEXT Products and the fate of spins.
It would seem that splitting the products could loose some community support as one product has more support than the other, either way the Fedora 20 product is definately at the cutting edge but after installing it on several machines, it seems IMHO that cracks are starting to appear now that I have not seen before,to the extent that an upgrade via fedup took me 3 hours to sort out on a desktop machine and a laptop install of fedora 20 has failed 3 times for various reason. This is food for thought to ensure that the product fits the community needs as well as Redhats need as one without the other will be a tragety. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libxnvctrl status?
Hi, On 02/04/2014 12:56 PM, Richard Hughes wrote: On 4 February 2014 11:34, Simone Caronni negativ...@gmail.com wrote: but what is the benefit of having them in Fedora if they can't be used without the proprietary blobs? I've always wondered the same thing. IIRC libXNVCtrl was introduced because some desktop sensors applets could use it to show gpu temperature. Specifically the gnome2 sensors applet. repoquery seems to confirm this: # repoquery -q --whatrequires libXNVCtrl hwloc-0:1.7-2.fc20.x86_64 hwloc-libs-0:1.7-2.fc20.i686 hwloc-libs-0:1.7-2.fc20.x86_64 libXNVCtrl-devel-0:169.12-9.fc20.i686 libXNVCtrl-devel-0:169.12-9.fc20.x86_64 mate-sensors-applet-0:1.6.1-1.fc20.i686 mate-sensors-applet-0:1.6.1-1.fc20.x86_64 oyranos-0:0.4.0-12.fc20.x86_64 For cases like this it seems useful to have libXNVCtrl around in Fedora to me, as it enhances existing open packages when used with the nvidia drivers. Otherwise the only way for users to get these features would be to rebuild our packages, which seems undesirable. Things like the nvidia control panel however, which can be in there own package just fine should not be in Fedora IMHO. Note I'm not saying anything about the bit-rottenness of libXNVCtrl, I'm only arguing that it can be useful to have in Fedora. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Meeting canceled for today
- Original Message - Apologies for the late notice everyone, but as i've been head of heels in tons of other work the past week and quite a few folks are either traveling or attending FOSDEM this weekend we're canceling the meeting today. Next week we'll have to see with a lot of people being at DevConf in Brno/CZ whether we can do a meeting or not, but i'll send out an notice on Thursday at the latest. As quite a lot of folks would be at DevConf, we can maybe try f2f even DevConf is pretty busy... Jaroslav Sorry again for the late note today. Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 02/04/2014 12:38 PM, Matthew Miller wrote: On Tue, Feb 04, 2014 at 10:57:51AM +, Jóhann B. Guðmundsson wrote: For that matter, there could be a Fedora GNOME spin distinct from the Fedora Workstation product, if there were people really keen to work on it, perhap as a showcase of upstream technology without worrying about the concerns of the Fedora Workstation WG's particular area of focus. (With people keen to work on it as the really key phrase.) But you cannot overlap products as in you cannot have a Gnome workstation and KDE workstation etc you cannot have an Server product outside what is already defined in the ServerWG nor a Cloud product outside what is already defined there. I think it's okay for there to be some overlap. The real world doesn't always chop up into neat boxes. If there's a *lot* of overlap between two nominally-different products, then that is less useful and it's probably better for them to either work together or else find a stronger differentiation. But that's talking about products. As long as someone is interested in doing them, spins can overlap like crazy. Yes but community products wont be considered primary products which means if things continues in the same manner as default does be ignored by QA/Releng/Marketing/Design since the focus will *only* be on primary products. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 04, 2014 at 01:34:09AM -0800, Dan Mashal wrote: So where do we currently stand with this? So, here's what *I'm* thinking. Spins clearly have enough popularity and importance that we either need to keep them or have some alternative that fills the same space and makes people at least as happy or happier. Since I don't know of any idea for alternatives, we clearly should keep that. Some spins might want to investigate alternative delivery methods. I'm thinking particularly of the non-desktop-environment spins. Some of them could maybe be delivered as groups of applications in Gnome Software (although that's also clearly not appropriate for all), or maybe there's interest in pushing the Fedora Formulas idea futher. I'd also like to see some of the restrictions on spins loosened a little bit. I think the spin/remix distinction (Fedora-only software vs. combined with other things) is good, but, for example, spins, maybe it *would* be okay to change software defaults in a way that isn't currently allowed. I think some spins are completely fine staying as spins forever. Other groups might be interested in becoming a Fedora capital-P Product. *I* don't think we want more than a handful of these, but maybe it turns out that we actually do collectively. So, for spins that are interested in targeting a particular target space, there should be a process to get there. Earlier I had suggested that I was thinking that this would parallel what Fedora does with primary and secondary architectures, and that current spins might all become secondary products. This discussion makes me think that that's not quite right. Stanislav Ochotnický suggested that incubating products might be better, in line with the Apache process: https://incubator.apache.org/incubation/Process_Description.html (Although we're structured somewhat differently from Apache, so we can't just lift that wholesale). Not all spins would be interested in this (again, fine), but the ones that are could have a clear path to follow. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Issue with koji?
On Mon, Feb 3, 2014 at 9:10 PM, Kevin Fenzi ke...@scrye.com wrote: On Mon, 3 Feb 2014 20:56:15 -0700 Dave Johansen davejohan...@gmail.com wrote: I'm trying to do a build on koji and ran into an error during the mock buildroot setup ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038). Is this something wrong with koji? Or with the EL6/EPEL packages? Thanks, Dave This usually happens when a new update has rolled out and you are doing your build in the window between that update being in the repo and koji having run a newrepo task to pick up the new package. So, short answer: wait a bit and try again and it should be fine. Waiting worked ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488197). Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 04, 2014 at 12:56:04PM +, Jóhann B. Guðmundsson wrote: Yes but community products wont be considered primary products No. The initial plan calls for three primary *community* products. And we'll see where it goes from there. which means if things continues in the same manner as default does be ignored by QA/Releng/Marketing/Design since the focus will *only* be on primary products. Focus, yes. Only, no. All of those groups help with existing spins to some degree now, and I don't see any particular change there. As I understand what you've said in earlier messages, I think you're strongly in the camp that thinks Fedora is best as a big bag of building blocks which we hand to users. Other people think that it would be best if we glued the blocks together into predesigned shapes. I think we can do the middle route, where we offer some pre-built structures but also keep the blocks available. Or to switch metaphors to the way Colin Walters put it in a message I read a few minutes ago , we *can* walk and chew gum at the same time. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 4, 2014 at 2:02 PM, Matthew Miller mat...@fedoraproject.orgwrote: I'd also like to see some of the restrictions on spins loosened a little bit. I think the spin/remix distinction (Fedora-only software vs. combined with other things) is good, but, for example, spins, maybe it *would* be okay to change software defaults in a way that isn't currently allowed. Is there a way that isn't currently allowed actually? Spins can put anything into %post, and some do modify configuration. (If nothing else, the desktop spins change the default desktop...) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
- Original Message - On Tue, Feb 4, 2014 at 2:02 PM, Matthew Miller mat...@fedoraproject.org wrote: I'd also like to see some of the restrictions on spins loosened a little bit. I think the spin/remix distinction (Fedora-only software vs. combined with other things) is good, but, for example, spins, maybe it *would* be okay to change software defaults in a way that isn't currently allowed. Is there a way that isn't currently allowed actually? Spins can put anything into %post, and some do modify configuration. (If nothing else, the desktop spins change the default desktop...) And sendmail/rsyslog was one example. So yes, spin already do so. But stating this formally/documented way would be worthy. Jaroslav Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 04, 2014 at 02:38:32PM +0100, Miloslav Trmač wrote: I'd also like to see some of the restrictions on spins loosened a little bit. I think the spin/remix distinction (Fedora-only software vs. combined with other things) is good, but, for example, spins, maybe it *would* be okay to change software defaults in a way that isn't currently allowed. Is there a way that isn't currently allowed actually? Spins can put anything into %post, and some do modify configuration. (If nothing else, the desktop spins change the default desktop...) I don't know to what degree this is enforced, but https://fedoraproject.org/wiki/Spins_Guidelines contains a big warning: Do NOT change the default behavior of applications. An example is to configure Nautilus to use the Browser mode by default. There may be valid reasons to change parts of the application, but you'll need to discuss them with the Spin SIG in your proposal. Although that is only in the Live Spins section. Installation Spins says No notes on Installation Spins yet (as it has for at least the last four years). Not that I'm one to talk -- documenting stuff is hard. :) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
- Original Message - On Tue, Feb 04, 2014 at 02:38:32PM +0100, Miloslav Trmač wrote: I'd also like to see some of the restrictions on spins loosened a little bit. I think the spin/remix distinction (Fedora-only software vs. combined with other things) is good, but, for example, spins, maybe it *would* be okay to change software defaults in a way that isn't currently allowed. Is there a way that isn't currently allowed actually? Spins can put anything into %post, and some do modify configuration. (If nothing else, the desktop spins change the default desktop...) I don't know to what degree this is enforced, but https://fedoraproject.org/wiki/Spins_Guidelines contains a big warning: Do NOT change the default behavior of applications. An example is to configure Nautilus to use the Browser mode by default. There may be valid reasons to change parts of the application, but you'll need to discuss them with the Spin SIG in your proposal. Seems to be pretty outdated (*), we're past many things written there aka Live CD size - for example for desktop and KDE spins. So the CD part could be removed, I know several spins doing changes in defaults and it's really up to SIG standing behind spin than Spins SIG. (*) last edit March 2011 Although that is only in the Live Spins section. Installation Spins says No notes on Installation Spins yet (as it has for at least the last four years). Not that I'm one to talk -- documenting stuff is hard. :) It needs updates :). Any volunteer? Jaroslav -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's Env-and-Stacks WG Meeting (2014-02-04)
#fedora-meeting: Env and Stacks (2014-02-04) Meeting started by bkabrda at 13:03:24 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-02-04/env_and_stacks.2014-02-04-13.03.log.html . Meeting summary --- * DevAssistant PRD section (bkabrda, 13:07:16) * LINK: https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document#DevAssistant (juhp_, 13:09:25) * ACTION: DevAssistant section is overally ok, but tjanez and bkabrda will work on rewording some parts. (bkabrda, 13:29:43) * Define Mission Statement of Env and Stacks WG (bkabrda, 13:30:34) * Define Vision Statement of Env and Stacks WG (bkabrda, 13:32:37) * ACTION: tjanez to propose vision statement on mailing list for discussion: Fedora is the preferred platform for software development and deployment in any language or application stack. (bkabrda, 13:44:24) * ACTION: All woting members of WG should vote on Jens's proposal for irc channel on mailing list: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-January/000157.html (bkabrda, 13:52:11) Meeting ended at 13:55:49 UTC. Action Items * DevAssistant section is overally ok, but tjanez and bkabrda will work on rewording some parts. * tjanez to propose vision statement on mailing list for discussion: Fedora is the preferred platform for software development and deployment in any language or application stack. * All woting members of WG should vote on Jens's proposal for irc channel on mailing list: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-January/000157.html Action Items, by person --- * bkabrda * DevAssistant section is overally ok, but tjanez and bkabrda will work on rewording some parts. * tjanez * DevAssistant section is overally ok, but tjanez and bkabrda will work on rewording some parts. * tjanez to propose vision statement on mailing list for discussion: Fedora is the preferred platform for software development and deployment in any language or application stack. * **UNASSIGNED** * All woting members of WG should vote on Jens's proposal for irc channel on mailing list: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-January/000157.html People Present (lines said) --- * bkabrda (51) * tjanez (47) * juhp_ (36) * hhorak (6) * zodbot (4) * mmaslano (3) * samkottler (1) * abadger1999 (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 04, 2014 at 08:48:12AM -0500, Jaroslav Reznik wrote: I'd also like to see some of the restrictions on spins loosened a little bit. I think the spin/remix distinction (Fedora-only software vs. combined with other things) is good, but, for example, spins, maybe it *would* be okay to change software defaults in a way that isn't currently allowed. Is there a way that isn't currently allowed actually? Spins can put anything into %post, and some do modify configuration. (If nothing else, the desktop spins change the default desktop...) And sendmail/rsyslog was one example. So yes, spin already do so. But stating this formally/documented way would be worthy. That was a particularly gray area because it's simply a matter of installing a package or not. Installing rsyslog but configuring it to log differently than the standard is another level of change (although of course also murky when other applications change their behavior based on the presence or absence of some other package). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FESCo/FAMSCo voting is open
Hi All, I've yet to see an announcement email for this, but the polls for the FESCo and FAMSCo votes are open. Please go vote here: https://admin.fedoraproject.org/voting/ josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCo/FAMSCo voting is open
On Tue, Feb 04, 2014 at 09:25:17AM -0500, Josh Boyer wrote: I've yet to see an announcement email for this, but the polls for the FESCo and FAMSCo votes are open. Please go vote here: https://admin.fedoraproject.org/voting/ Also: more details on Fedora's voting process at http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Fedora_Elections_Guide/index.html -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Mon, Feb 03, 2014 at 08:14:06PM -0800, Andrew Lutomirski wrote: (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) If your hard disc is GPT partition the movement from BIOS to UEFI boot shoot be very easy. You have to install grub2-efi and create the configuration file on /boot/efi/EFI/fedora/grub.cfg. Thy other wy may be harder, because you need 1.) A special BIOS Boot partition (type EF02) with a size of 1 MB. This is required because grub2 can't write the bootstrapping code behind the partition table of a GPT. 2.) A hybrid partition table created with gdisk. The MBR must contains the BIOS Boot partiition as an primary bootable partition. This may affect the usability of other OSs installed on the same disc depeneding of the creation of protected MBR partitions. You may use gptsync to create a hybrid partition table. This is only recommented, if you disk has no more the four partitions 3.) On my MacBoot Pro (late 2013) I required the usage of the linux16/initrd16 commands instead of linux/initrd commands for the BIOS-mode boot. You may see, that I can't advise the installation of a BIOS-mode boot system on a GPT partioned disc, because there are severals pitfalls which you have to considered. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Robert Mayr wrote: Why do you think only about KDE? The other desktops should be considered separate Products, too. It's time to stop treating them as second-class citizens that we won't even wait a few days for with our releases. This topic shouldn't turn into a DE war IMHO. The product for Desktop users should be just one, Workstation. And KDE, as Xfce or LXDE are part of this product and should live under the wing of the Workstation. That way we either do no live images, or bad live images, with a menu filled with lots of applications that do the same thing, unless we start abusing Only/NotShowIn, which would suck for those people who do want to use e.g. Okular under GNOME. I don't think a single image for all desktops is a good idea. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-indirect/epel7] Build for epel7 bootstrap done
Summary of changes: fc93f40... Build for epel7 bootstrap done (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: New UEFI guide on the wiki
On Mon, 3 Feb 2014 20:14:06 -0800 Andrew Lutomirski l...@mit.edu wrote: that in the wiki. (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) Have tried this in the past as an experiment, after 4 or five different flavored change attempts. None were really successful. As AdamW typed, backup and reinstall for bios? if that's what works for you. It'll be quicker and cleaner. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Hi On Tue, Feb 4, 2014 at 8:54 AM, Jaroslav Reznik wrote: - Original Message - It needs updates :). Any volunteer? I have updated it just to remove the obsolete content for now. Ideally, it needs a good rewrite Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retiring/orphaning conglomerate
I intend to orphan conglomerate (http://www.conglomerate.org/). The source code has not been updated for a long time and my interest in the package is gone. If no one is interested in maintaining it I will retire it from the distribuition in the next weeks. Regards, -- José Abílio Matos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, 4 Feb 2014 11:09:15 -0500 Rahul Sundaram methe...@gmail.com wrote: Hi On Tue, Feb 4, 2014 at 8:54 AM, Jaroslav Reznik wrote: - Original Message - It needs updates :). Any volunteer? I have updated it just to remove the obsolete content for now. Ideally, it needs a good rewrite Agreed. Also, mentions of steps involving a 'spins sig' when there's not one thats at all active probibly need to be re-worked. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FESCo announces acceptance of Fedora.next PRDs
Recently, as part of the Fedora.next effort, FESCo has accepted the PRDs from the following Working Groups: - Workstation https://fedoraproject.org/wiki/Workstation/Workstation_PRD - Server https://fedoraproject.org/wiki/Server/Product_Requirements_Document - Cloud https://fedoraproject.org/wiki/Cloud_PRD - Environments and Stacks https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document FESCo would like to thank all the members of these working groups, and all those that have contributed to these documents, for all their time and effort on creating these on short notice, with next to no requirements, while still doing their other Fedora work. Thanks to the all the contributors that worked on this process. We are now ready to move on to concrete technical plans for how the products can be created, tested, distributed and marketed. Help Fedora dream big and we can work with our infrastructure, QA, releng, websites, design, translation and marketing teams to do great things for Fedora 21. We encourage those interested in these areas to check out these links and participate in these communities and discussions, as we work together to make Fedora the best it can be. Bill Nottingham, on behalf of FESCo ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 02/04/2014 06:15 AM, Reindl Harald wrote: honestly going back to only a install DVD with a sane user-UI and dedicate all the time wasted for the spin/products/discrimination discussions for documentations, screenshots and howtos would have more benefit for Fedora there is nothing you can't setup with the one fits all DVD or even with a slim network install if you only knew what to install and how to configure Right! since spins are just a fancy way to install groups, I would like the main install to offer them in a distinct 'I want to customize' installation step of the One True Fedora. That assumes that one can actually mix and match groups, even if they affect the fundamental layers such as the desktop environment. I haven't tried a combined Gnome/KDE installation recently, but I remember that it just offered an option to start a login session in either desktop environment. An example of rampant customization is SUSE studio (http://susestudio.com/browse), and I am not at all impressed by it. I am sure that there are some gems there but the pile of options is just overwhelming, and I think a better approach would be to have a solid base system with multiple customization recipes. This would require careful definition of QA release requirements, to avoid combinatorial explosion in testing---but the current approach of testing the two basic desktop environments is fine and would still work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libxnvctrl status?
On Tue, 2014-02-04 at 12:34 +0100, Simone Caronni wrote: Well, the tools are totally opensource and can be built standalone, libXNVCtrl will interface with the Nvidia X.org driver; but what is the benefit of having them in Fedora if they can't be used without the proprietary blobs? Well, since X is a network protocol, there's no reason the blob you're controlling needs to be running on the same machine as Fedora. Why should Fedora _not_ be able to speak X11 fluently over the network? I don't have time for the package tbh, I'm happy to hand it over if someone wants it. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 04:42:23PM +0100, Jochen Schmitt wrote: On Mon, Feb 03, 2014 at 08:14:06PM -0800, Andrew Lutomirski wrote: (This is a particular pain point for me -- my main development box was originally installed as BIOS, and I switched it to UEFI, and I'm sure I did it wrong because the boot process is impressively finicky.) If your hard disc is GPT partition the movement from BIOS to UEFI boot shoot be very easy. You have to install grub2-efi and create the configuration file on /boot/efi/EFI/fedora/grub.cfg. …and configure the UEFI boot options, which you can't do because you're not running under UEFI and so have no access to UEFI runtime services. The workarounds required for this will tend to be vendor specific, although ensuring that you have the fallback loader supplied by shim may work in many cases. 3.) On my MacBoot Pro (late 2013) I required the usage of the linux16/initrd16 commands instead of linux/initrd commands for the BIOS-mode boot. Yeah it's really a mistake for us to be using the linux/initrd commands under any circumstances. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: …and configure the UEFI boot options, which you can't do because you're not running under UEFI and so have no access to UEFI runtime services. That's probably the biggest flaw in the whole UEFI setup - you can't access it unless you boot using it, and you can't boot from it unless you access it to configure it. It makes switching to UEFI (or the old-time common practice of installing to a drive in one machine and then moving it to another) difficult (at best). I have a friend that worked for a BIOS vendor and now for a CPU vendor that I think helped write some of the UEFI spec - I need to bug him on that one. :) -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What is the usage of an empty RPM ?
Hi, What is the usage of an empty RPM ? What it is for ? For example, on Fedora 20: rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm shows: (contains no files) Regards, Kevin Wilson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is the usage of an empty RPM ?
On Tue, Feb 04, 2014 at 07:30:16PM +0200, Kevin Wilson wrote: Hi, What is the usage of an empty RPM ? What it is for ? For example, on Fedora 20: rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm shows: (contains no files) It pulls in the various dependant packages that are required for a full libvirt install. Previously all the code was in that one package but people wanted the ability to install individual pieces. So those pieces were split off into sub-RPMs, but we still wanted to keep a way to install everything as other people were already used to doing and thus avoid breaking existing dependancies. 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 9:15 AM, Chris Adams li...@cmadams.net wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: …and configure the UEFI boot options, which you can't do because you're not running under UEFI and so have no access to UEFI runtime services. That's probably the biggest flaw in the whole UEFI setup - you can't access it unless you boot using it, and you can't boot from it unless you access it to configure it. It makes switching to UEFI (or the old-time common practice of installing to a drive in one machine and then moving it to another) difficult (at best). There are at least two ways to hack around this. You can boot from a live UEFI image, chroot in, and do the magic incantation to get GRUB to install itself, or you can call your bootloader bootx64.efi (IIRC) and try to convince your firmware to load it. I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) I have a friend that worked for a BIOS vendor and now for a CPU vendor that I think helped write some of the UEFI spec - I need to bug him on that one. :) -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is the usage of an empty RPM ?
On Tue, Feb 4, 2014 at 11:30 AM, Kevin Wilson wkev...@gmail.com wrote: Hi, What is the usage of an empty RPM ? What it is for ? For example, on Fedora 20: rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm shows: (contains no files) It's effectively a meta-package that pulls in dependencies. # yum deplist libvirt package: libvirt.x86_64 1.2.1-2.fc21 dependency: /bin/sh provider: bash.x86_64 4.2.45-6.fc21 dependency: libvirt-client = 1.2.1-2.fc21 provider: libvirt-client.x86_64 1.2.1-2.fc21 provider: libvirt-client.i686 1.2.1-2.fc21 dependency: libvirt-daemon = 1.2.1-2.fc21 provider: libvirt-daemon.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-config-network = 1.2.1-2.fc21 provider: libvirt-daemon-config-network.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-config-nwfilter = 1.2.1-2.fc21 provider: libvirt-daemon-config-nwfilter.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-interface = 1.2.1-2.fc21 provider: libvirt-daemon-driver-interface.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-libxl = 1.2.1-2.fc21 provider: libvirt-daemon-driver-libxl.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-lxc = 1.2.1-2.fc21 provider: libvirt-daemon-driver-lxc.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-network = 1.2.1-2.fc21 provider: libvirt-daemon-driver-network.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-nodedev = 1.2.1-2.fc21 provider: libvirt-daemon-driver-nodedev.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-nwfilter = 1.2.1-2.fc21 provider: libvirt-daemon-driver-nwfilter.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-qemu = 1.2.1-2.fc21 provider: libvirt-daemon-driver-qemu.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-secret = 1.2.1-2.fc21 provider: libvirt-daemon-driver-secret.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-storage = 1.2.1-2.fc21 provider: libvirt-daemon-driver-storage.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-uml = 1.2.1-2.fc21 provider: libvirt-daemon-driver-uml.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-vbox = 1.2.1-2.fc21 provider: libvirt-daemon-driver-vbox.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-xen = 1.2.1-2.fc21 provider: libvirt-daemon-driver-xen.x86_64 1.2.1-2.fc21 -AdamM Regards, Kevin Wilson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is the usage of an empty RPM ?
Hi, Thanks to Adam and Daniel for the quick answer. I am not an expert about RPMs. I just wonder where are these dependencies defined for libvirt (and in general for other RPMs), since the libvirt RPM file itself is an empty file ? Regards, Kevin On Tue, Feb 4, 2014 at 7:37 PM, Adam Miller maxamill...@fedoraproject.org wrote: On Tue, Feb 4, 2014 at 11:30 AM, Kevin Wilson wkev...@gmail.com wrote: Hi, What is the usage of an empty RPM ? What it is for ? For example, on Fedora 20: rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm shows: (contains no files) It's effectively a meta-package that pulls in dependencies. # yum deplist libvirt package: libvirt.x86_64 1.2.1-2.fc21 dependency: /bin/sh provider: bash.x86_64 4.2.45-6.fc21 dependency: libvirt-client = 1.2.1-2.fc21 provider: libvirt-client.x86_64 1.2.1-2.fc21 provider: libvirt-client.i686 1.2.1-2.fc21 dependency: libvirt-daemon = 1.2.1-2.fc21 provider: libvirt-daemon.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-config-network = 1.2.1-2.fc21 provider: libvirt-daemon-config-network.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-config-nwfilter = 1.2.1-2.fc21 provider: libvirt-daemon-config-nwfilter.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-interface = 1.2.1-2.fc21 provider: libvirt-daemon-driver-interface.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-libxl = 1.2.1-2.fc21 provider: libvirt-daemon-driver-libxl.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-lxc = 1.2.1-2.fc21 provider: libvirt-daemon-driver-lxc.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-network = 1.2.1-2.fc21 provider: libvirt-daemon-driver-network.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-nodedev = 1.2.1-2.fc21 provider: libvirt-daemon-driver-nodedev.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-nwfilter = 1.2.1-2.fc21 provider: libvirt-daemon-driver-nwfilter.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-qemu = 1.2.1-2.fc21 provider: libvirt-daemon-driver-qemu.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-secret = 1.2.1-2.fc21 provider: libvirt-daemon-driver-secret.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-storage = 1.2.1-2.fc21 provider: libvirt-daemon-driver-storage.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-uml = 1.2.1-2.fc21 provider: libvirt-daemon-driver-uml.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-vbox = 1.2.1-2.fc21 provider: libvirt-daemon-driver-vbox.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-xen = 1.2.1-2.fc21 provider: libvirt-daemon-driver-xen.x86_64 1.2.1-2.fc21 -AdamM Regards, Kevin Wilson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is the usage of an empty RPM ?
On Tue, Feb 4, 2014 at 11:46 AM, Kevin Wilson wkev...@gmail.com wrote: Hi, Thanks to Adam and Daniel for the quick answer. I am not an expert about RPMs. I just wonder where are these dependencies defined for libvirt (and in general for other RPMs), since the libvirt RPM file itself is an empty file ? Regards, Kevin They are defined in the RPM's spec file used to build the RPM itself. libvirt is a complex package so it's spec file isn't necessarily the best candidate for someone who's not experienced in RPM packaging but if you look at the lines that list out Requires: (not BuildRequires:), it will at least show where the dependencies originate. http://pkgs.fedoraproject.org/cgit/libvirt.git/tree/libvirt.spec -AdamM On Tue, Feb 4, 2014 at 7:37 PM, Adam Miller maxamill...@fedoraproject.org wrote: On Tue, Feb 4, 2014 at 11:30 AM, Kevin Wilson wkev...@gmail.com wrote: Hi, What is the usage of an empty RPM ? What it is for ? For example, on Fedora 20: rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm shows: (contains no files) It's effectively a meta-package that pulls in dependencies. # yum deplist libvirt package: libvirt.x86_64 1.2.1-2.fc21 dependency: /bin/sh provider: bash.x86_64 4.2.45-6.fc21 dependency: libvirt-client = 1.2.1-2.fc21 provider: libvirt-client.x86_64 1.2.1-2.fc21 provider: libvirt-client.i686 1.2.1-2.fc21 dependency: libvirt-daemon = 1.2.1-2.fc21 provider: libvirt-daemon.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-config-network = 1.2.1-2.fc21 provider: libvirt-daemon-config-network.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-config-nwfilter = 1.2.1-2.fc21 provider: libvirt-daemon-config-nwfilter.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-interface = 1.2.1-2.fc21 provider: libvirt-daemon-driver-interface.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-libxl = 1.2.1-2.fc21 provider: libvirt-daemon-driver-libxl.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-lxc = 1.2.1-2.fc21 provider: libvirt-daemon-driver-lxc.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-network = 1.2.1-2.fc21 provider: libvirt-daemon-driver-network.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-nodedev = 1.2.1-2.fc21 provider: libvirt-daemon-driver-nodedev.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-nwfilter = 1.2.1-2.fc21 provider: libvirt-daemon-driver-nwfilter.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-qemu = 1.2.1-2.fc21 provider: libvirt-daemon-driver-qemu.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-secret = 1.2.1-2.fc21 provider: libvirt-daemon-driver-secret.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-storage = 1.2.1-2.fc21 provider: libvirt-daemon-driver-storage.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-uml = 1.2.1-2.fc21 provider: libvirt-daemon-driver-uml.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-vbox = 1.2.1-2.fc21 provider: libvirt-daemon-driver-vbox.x86_64 1.2.1-2.fc21 dependency: libvirt-daemon-driver-xen = 1.2.1-2.fc21 provider: libvirt-daemon-driver-xen.x86_64 1.2.1-2.fc21 -AdamM Regards, Kevin Wilson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is the usage of an empty RPM ?
On 02/04/2014 06:46 PM, Kevin Wilson wrote: Hi, Thanks to Adam and Daniel for the quick answer. I am not an expert about RPMs. I just wonder where are these dependencies defined for libvirt (and in general for other RPMs), since the libvirt RPM file itself is an empty file ? You need to have a look into the spec file. Such dependency there are represented by Require: tags. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
I've done conversions in both directions a few times although not very recently. But having done it, I'd say f it, just reinstall. Or f it, get drunk and sent to the hospital is even a better experience than converting. BIOS-UEFI - BIOS install won't have an EFI System partition, so you have to shrink something. Easiest is pilfering some from the 500MB /boot. Or alternatively from the LVM partition, which is a non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. Yay LVM by default - so this step is easier, by a lot, without LVM. - If there's a spare MBR entry (primary) available, then the ESP type code 0xEF is used. The UEFI spec says firmware should support this configuration but I don't know how well tested it is. - If converting MBR to GPT, the last partition file system needs resizing because otherwise it overlaps with the backup GPT. If the last partition is LVM (which is the default location for default installations, again yay LVM by default) you have to do the non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. UEFI-BIOS - The 200MB FAT ESP can be blown away in favor of a 1+MB BIOS Boot quite easily. Both directions require updating fstab to varying degrees. And both require booting alternate media, such that the system is booting in the mode you are converting to, assembling the file system (easiest with anaconda rescue option at boot time from non-live install media), chrooting the mount point, reinstalling grub, creating a new grub.cfg, and rebuilding the initramfs. However, the reinstalling grub procedure is not the same between the two directions and of course the grub.cfgs go in two different locations *sigh*. For UEFI-BIOS: it's possible to just do grub2-install dev, and grub2-mkconfig -o /boot/grub2/grub.cfg. For BIOS-UEFI I'm pretty sure you're best off resinstalling the grub2-efi package (and installing/reinstalling the shim packages) so that you get the nice shim fallback behavior, the prebaked-signed grub, and therefore instructions work for either Secure Boot on or off. And then grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. Summary: UEFI to BIOS conversion is either very slightly easier if you don't use LVM and don't need conversion to GPT. Otherwise it's a lot easier. Unrelated to conversion, two unfortunates exposed: the difference in grub.cfg locations; the ESP, using one of the most fragile file systems still in use, being persistently mounted rw, and too often being modified due to the grub.cfg on the ESP. Instead the ESP grub.cfg should point via configfile to the maintained grub.cfg at /boot/grub2. Then there'd be no reason at all for /boot/efi being persistently mounted. Note that neither OS X nor Windows keep their ESPs mounted. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is the usage of an empty RPM ?
example of how to build meta packages
some obsoletes/provides are hacks to get rid of useless
dependencies or workarounds for UsrMove-bugs
the really relevant is Requires:
they do not need to privide files
they only ned to provide dependencies
[builduser@buildserver:~]$ cat /rpmbuild/SPECS/lounge-base.spec
Summary: metapackage for thelounge.net default packages
Name: lounge-base
Version: 19.0
Release: 1%{?dist}
BuildArch: noarch
Group: System Environment/Libraries
URL: http://www.thelounge.net/
License: GPL
Obsoletes: php-interbase
Obsoletes: php-pear
Obsoletes: php-pear-Auth-SASL
Obsoletes: php-pear-Mail-Mime
Obsoletes: php-pear-Mail-mimeDecode
Obsoletes: php-pear-Net-IDNA2
Obsoletes: php-pear-Net-SMTP
Obsoletes: php-pear-Net-Socket
Obsoletes: php-php-gettext
Obsoletes: php-snmp
Provides: %{_bindir}/pear
Provides: %{_bindir}/pecl
Provides: %{_bindir}/perl
Provides: php-pear
Provides: php-pear-Auth-SASL
Provides: php-pear-Mail-Mime
Provides: php-pear-Mail-mimeDecode
Provides: php-pear-Net-IDNA2
Provides: php-pear-Net-SMTP
Provides: php-pear-Net-Socket
Provides: php-php-gettext
Provides: %{_sbindir}/ldconfig
Obsoletes: mod_nss
Provides: mod_nss
Obsoletes: mod_fcgid
Provides: mod_fcgid
Requires: attr
Requires: authconfig
Requires: bash-completion
Requires: bzip2
Requires: checksec
Requires: chkrootkit
Requires: dash
Requires: diffutils
Requires: dstat
Requires: ethtool
Requires: file
Requires: grub2
Requires: haveged
Requires: hostname
Requires: htop
Requires: iftop
Requires: iptables-services
Requires: kbd
Requires: less
Requires: logwatch
Requires: lsscsi
Requires: lynis
Requires: mlocate
Requires: nano
Requires: net-tools
Requires: ntp
Requires: openssh-clients
Requires: openssh-server
Requires: pciutils
Requires: php-cli
Requires: php-mysqlnd
Requires: pigz
Requires: postfix
Requires: procmail
Requires: procps-ng
Requires: psmisc
Requires: pyliblzma
Requires: rkhunter
Requires: rootfiles
Requires: rpl
Requires: rsync
Requires: rsyslog
Requires: rsyslog-mysql
Requires: screen
Requires: symlinks
Requires: tar
Requires: unhide
Requires: vim-minimal
Requires: vnstat
Requires: xz
Requires: yum-plugin-protectbase
Requires: yum-plugin-tsflags
Requires: yum-utils
%description
metapackage for thelounge.net default packages
%files
%changelog
* Tue Mar 27 2012 Reindl Harald h.rei...@thelounge.net
- initial build
[builduser@buildserver:~]$
Am 04.02.2014 18:46, schrieb Kevin Wilson:
Thanks to Adam and Daniel for the quick answer.
I am not an expert about RPMs. I just wonder where are these
dependencies defined for libvirt (and in general for other RPMs),
since the libvirt RPM file itself is an empty file ?
Regards,
Kevin
On Tue, Feb 4, 2014 at 7:37 PM, Adam Miller
maxamill...@fedoraproject.org wrote:
On Tue, Feb 4, 2014 at 11:30 AM, Kevin Wilson wkev...@gmail.com wrote:
Hi,
What is the usage of an empty RPM ? What it is for ?
For example, on Fedora 20:
rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm
shows:
(contains no files)
It's effectively a meta-package that pulls in dependencies.
# yum deplist libvirt
package: libvirt.x86_64 1.2.1-2.fc21
dependency: /bin/sh
provider: bash.x86_64 4.2.45-6.fc21
dependency: libvirt-client = 1.2.1-2.fc21
provider: libvirt-client.x86_64 1.2.1-2.fc21
provider: libvirt-client.i686 1.2.1-2.fc21
dependency: libvirt-daemon = 1.2.1-2.fc21
provider: libvirt-daemon.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-config-network = 1.2.1-2.fc21
provider: libvirt-daemon-config-network.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-config-nwfilter = 1.2.1-2.fc21
provider: libvirt-daemon-config-nwfilter.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-interface = 1.2.1-2.fc21
provider: libvirt-daemon-driver-interface.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-libxl = 1.2.1-2.fc21
provider: libvirt-daemon-driver-libxl.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-lxc = 1.2.1-2.fc21
provider: libvirt-daemon-driver-lxc.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-network = 1.2.1-2.fc21
provider: libvirt-daemon-driver-network.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-nodedev = 1.2.1-2.fc21
provider: libvirt-daemon-driver-nodedev.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-nwfilter = 1.2.1-2.fc21
provider: libvirt-daemon-driver-nwfilter.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-qemu = 1.2.1-2.fc21
provider: libvirt-daemon-driver-qemu.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-secret = 1.2.1-2.fc21
provider: libvirt-daemon-driver-secret.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-storage = 1.2.1-2.fc21
provider: libvirt-daemon-driver-storage.x86_64 1.2.1-2.fc21
dependency: libvirt-daemon-driver-uml = 1.2.1-2.fc21
provider: libvirt-daemon-driver-uml.x86_64 1.2.1-2.fc21
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 9:52 AM, Chris Murphy li...@colorremedies.com wrote: I've done conversions in both directions a few times although not very recently. But having done it, I'd say f it, just reinstall. Or f it, get drunk and sent to the hospital is even a better experience than converting. BIOS-UEFI - BIOS install won't have an EFI System partition, so you have to shrink something. Easiest is pilfering some from the 500MB /boot. Or alternatively from the LVM partition, which is a non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. Yay LVM by default - so this step is easier, by a lot, without LVM. - If there's a spare MBR entry (primary) available, then the ESP type code 0xEF is used. The UEFI spec says firmware should support this configuration but I don't know how well tested it is. - If converting MBR to GPT, the last partition file system needs resizing because otherwise it overlaps with the backup GPT. If the last partition is LVM (which is the default location for default installations, again yay LVM by default) you have to do the non-trivial sequence: resize2fs, lvresize, pvmove, pvresize, vgreduce, fdisk, gdisk MBR to GPT conversion. UEFI-BIOS - The 200MB FAT ESP can be blown away in favor of a 1+MB BIOS Boot quite easily. Both directions require updating fstab to varying degrees. And both require booting alternate media, such that the system is booting in the mode you are converting to, assembling the file system (easiest with anaconda rescue option at boot time from non-live install media), chrooting the mount point, reinstalling grub, creating a new grub.cfg, and rebuilding the initramfs. However, the reinstalling grub procedure is not the same between the two directions and of course the grub.cfgs go in two different locations *sigh*. For UEFI-BIOS: it's possible to just do grub2-install dev, and grub2-mkconfig -o /boot/grub2/grub.cfg. For BIOS-UEFI I'm pretty sure you're best off resinstalling the grub2-efi package (and installing/reinstalling the shim packages) so that you get the nice shim fallback behavior, the prebaked-signed grub, and therefore instructions work for either Secure Boot on or off. And then grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. Summary: UEFI to BIOS conversion is either very slightly easier if you don't use LVM and don't need conversion to GPT. Otherwise it's a lot easier. Unrelated to conversion, two unfortunates exposed: the difference in grub.cfg locations; the ESP, using one of the most fragile file systems still in use, being persistently mounted rw, and too often being modified due to the grub.cfg on the ESP. Instead the ESP grub.cfg should point via configfile to the maintained grub.cfg at /boot/grub2. Then there'd be no reason at all for /boot/efi being persistently mounted. Note that neither OS X nor Windows keep their ESPs mounted. This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? /boot is useful regardless of how you boot. The ESP doesn't need to be very large and doesn't cause any harm if booted via BIOS. The BIOS Boot partition only needs to be ~64kB IIRC, and UEFI boot will happily ignore it. You don't even need to have any contents in there. IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. Everyone wins. Especially people who install via UEFI, upgrade their BIOS, and go oh sh*t when the BIOS upgrade conveniently erases their boot entry. (Yes, that's happened to me. I think it's happened several times. The fact that I have two boxes at work, *both* of which have interestingly experimental firmwares [1], is a contributing factor.) [1] One of these interesting firmwares required me to boot, repeatedly, using UEFI, GRUB2 under BIOS, and syslinux to diagnose a bug.The bug turned out to be in GRUB2. At some point I will probably write some more upstreamable drivers for this box, and they'll have to be tested separately under UEFI and BIOS. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:
Re: Packaging question about -Wformat-security on Rawhide
On 02/04/2014 05:31 AM, Dan Mashal wrote: On Mon, Feb 3, 2014 at 8:16 PM, Michael Catanzaro mcatanz...@gnome.org wrote: On Mon, 2014-02-03 at 19:42 -0700, Orion Poplawski wrote: I'm not sure why the default -Wall is being dropped from that line (it is on other tests). It's explicitly dropped on configure.ac:1265 dnl We enable -Wall later. dnl If it's set after the warning CFLAGS in the compiler invocation, it counteracts the -Wno... flags. dnl This leads to warnings we don't want. CFLAGS=`echo $CFLAGS |$sedpath 's/-Wall//'` Second-guessing the user's choice of compiler warnings is certainly unconventional. Anyway, this from the build log looks bad too; hope it's the same issue: checking EXTERN.h usability... no checking EXTERN.h presence... yes configure: WARNING: EXTERN.h: present but cannot be compiled configure: WARNING: EXTERN.h: check for missing prerequisite headers? configure: WARNING: EXTERN.h: see the Autoconf documentation configure: WARNING: EXTERN.h: section Present But Cannot Be Compiled configure: WARNING: EXTERN.h: proceeding with the compiler's result configure: WARNING: ## -- ## configure: WARNING: ## Report this to de...@pidgin.im ## configure: WARNING: ## -- ## checking for EXTERN.h... no I haven't checked this particular case, but these kind of log messages usually mean the configure script fails to compile a header file, because some symbols are missing inside of the header file. This usually means another header file is not being included during the autoconf-check. Typical reasons would be a missing AC_CHECK_HEADERS in configure or a coding-bug inside of the header triggering the compiler warnings. Check out the autoconf list's archive. There are plenty of reports on similar issues. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is the usage of an empty RPM ?
Le Tuesday 04 February 2014 19:30:16 Kevin Wilson a écrit : Hi, What is the usage of an empty RPM ? What it is for ? For example, on Fedora 20: rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm shows: (contains no files) That package does not contain files, but it does contain other things: provides and requirements: $ rpm -q libvirt --requires libvirt-daemon = 1.0.5.9-1.fc19 libvirt-daemon-config-network = 1.0.5.9-1.fc19 libvirt-daemon-config-nwfilter = 1.0.5.9-1.fc19 libvirt-daemon-driver-libxl = 1.0.5.9-1.fc19 libvirt-daemon-driver-lxc = 1.0.5.9-1.fc19 libvirt-daemon-driver-qemu = 1.0.5.9-1.fc19 libvirt-daemon-driver-uml = 1.0.5.9-1.fc19 libvirt-daemon-driver-xen = 1.0.5.9-1.fc19 libvirt-daemon-driver-interface = 1.0.5.9-1.fc19 libvirt-daemon-driver-secret = 1.0.5.9-1.fc19 libvirt-daemon-driver-storage = 1.0.5.9-1.fc19 libvirt-daemon-driver-network = 1.0.5.9-1.fc19 libvirt-daemon-driver-nodedev = 1.0.5.9-1.fc19 libvirt-daemon-driver-nwfilter = 1.0.5.9-1.fc19 libvirt-client = 1.0.5.9-1.fc19 /bin/sh rpmlib(FileDigests) = 4.6.0-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(PayloadIsXz) = 5.2-1 $ rpm -q libvirt --provides bundled(gnulib) libvirt = 1.0.5.9-1.fc19 libvirt(x86-64) = 1.0.5.9-1.fc19 -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. Multiboot, you get to deal with either your firmware's boot manager, or learn a 3rd party replacement (including GRUB, gummiboot, or rEFInd). TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. Care to be more specific? The UX should be basically identical to grub on BIOS. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) It's a continuum. The less interaction the less customizable but the more pleasant. Automatic is great, when it just works. That usually means constraining the options. For gummiboot it means it's presently not supporting boot from anything but FAT32 which I find untenable. Way too much writing is happening on a FAT32 volume in that paradigm for my comfort level. So yes, when it decides what it wants to be when it grows up, then it could be a viable alternative. And like I mentioned in another thread [1], bootloaderspec has regressive boot capabilities also, it effectively says no to snapshotting $BOOT. Since the kernel goes on $BOOT, it means $BOOT contents can be so new they can't boot older snapshots which contain older /lib/modules. So if rootfs is being snapshot, then /boot needs to be snapshot with it. Chris Murphy [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/193857.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. How does firmware find shim.efi? Is it installed as bootx64.efi? IIRC that approach used to be frowned upon. Multiboot, you get to deal with either your firmware's boot manager, or learn a 3rd party replacement (including GRUB, gummiboot, or rEFInd). TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. Care to be more specific? The UX should be basically identical to grub on BIOS. Exactly. The GRUB2 UX is special. :) Somehow anaconda does the right thing. Since I haven't the faintest clue what the right thing is, I can't replicate it. To be fair, UEFI is slightly worse. Disk numbers seem to change on occasion if they're in a bad mood, at least on my box. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) It's a continuum. The less interaction the less customizable but the more pleasant. Automatic is great, when it just works. That usually means constraining the options. For gummiboot it means it's presently not supporting boot from anything but FAT32 which I find untenable. Way too much writing is happening on a FAT32 volume in that paradigm for my comfort level. So yes, when it decides what it wants to be when it grows up, then it could be a viable alternative. And like I mentioned in another thread [1], bootloaderspec has regressive boot capabilities also, it effectively says no to snapshotting $BOOT. Since the kernel goes on $BOOT, it means $BOOT contents can be so new they can't boot older snapshots which contain older /lib/modules. So if rootfs is being snapshot, then /boot needs to be snapshot with it. Fair enough. Some day this will all work well. In the mean time, I actually preferred GRUB 1, the lack of maintenance notwithstanding. --Andy Chris Murphy [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/193857.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? RFE: always create required bootloader partitions in custom partitioning https://bugzilla.redhat.com/show_bug.cgi?id=1022316 I'm not opposed to both ESP and BIOSboot created for every selected disk at install time. But I am opposed to the current behavior of not creating that which is mandatory for operation, while the installer then proceeds to chew me out for not having created it. It knows enough to squawk at me, but it doesn't know enough to just do the thing that needs to be done? Grrr that's not OK. And in fact it's worse in that presently I can't create an ESP per disk because the installer is mountpoint centric not partition centric. So I can only create one ESP on one disk because I can have only one /boot/efi. https://bugzilla.redhat.com/show_bug.cgi?id=1060576 /boot is useful regardless of how you boot. The ESP doesn't need to be very large and doesn't cause any harm if booted via BIOS. The BIOS Boot partition only needs to be ~64kB IIRC, and UEFI boot will happily ignore it. You don't even need to have any contents in there. GRUB devs want 1MB for BIOS Boot. And then it also maintains 1MB alignment. Nevertheless one Kleenex is more valuable than 1MB of drive space, even on an SSD. IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. I'm not opposed to the layout, but I'm personally totally disinterested in the ensuing clusterf|ck experiences I've already had with UEFI+BIOS dual boot OS's. If I could only experience food poisoning instead, my disposition would be no worse for the wear. My opinion: anything that requires BIOS to boot is old, or it's broken. And if it's old, it should be put into a VM. And if it's broken it should be fixed if it isn't a bad idea from the outset. Everyone wins. Especially people who install via UEFI, upgrade their BIOS, and go oh sh*t when the BIOS upgrade conveniently erases their boot entry. Let's agree to not equate UEFI and BIOS. There is nothing basic about UEFI. In any case, this is what BOOT/BOOTarch.EFI is for. Sorry to say but Apple had this exact scenario figured out some 30 years ago, having had so much experience with CMOS/NVRAM corruptions that there is a keyboard shortcut for every Mac since the dawn of time, that clears it. And yet it has a fallback mechanism to still boot the OS via a, probably unnecessarily clever, hint in the file system volume header. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Digest-JHash/f20] Upstream update.
Summary of changes: d09375f... Upstream update. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Digest-JHash/f19] (3 commits) ...Upstream update.
Summary of changes: f640e95... Perl 5.18 rebuild (*) 2b3f8d5... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) d09375f... Upstream update. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 11:30 AM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. How does firmware find shim.efi? Is it installed as bootx64.efi? BOOT/BOOTarch.EFI IIRC that approach used to be frowned upon. UEFI spec This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost. Seems correct to me. Multiboot, you get to deal with either your firmware's boot manager, or learn a 3rd party replacement (including GRUB, gummiboot, or rEFInd). TBH, I've never had much trouble convincing UEFI to load an image -- most of the trouble is convincing GRUB2, once successfully running, to do anything useful. Care to be more specific? The UX should be basically identical to grub on BIOS. Exactly. The GRUB2 UX is special. :) Somehow anaconda does the right thing. Since I haven't the faintest clue what the right thing is, I can't replicate it. To be fair, UEFI is slightly worse. Disk numbers seem to change on occasion if they're in a bad mood, at least on my box. You mean a disk can flip between /dev/sda and /dev/sdb between boots? That's been happening on BIOS also for years, it's not guaranteed assignment which is why UUID is better. (The Debian/Ubuntu approach regenerating grub config all the time is nicer here, but it still sucks. I'm anxiously awaiting BootLoaderSpec and something that isn't GRUB or GRUB2 to make a lot of the unpleasantness go away.) It's a continuum. The less interaction the less customizable but the more pleasant. Automatic is great, when it just works. That usually means constraining the options. For gummiboot it means it's presently not supporting boot from anything but FAT32 which I find untenable. Way too much writing is happening on a FAT32 volume in that paradigm for my comfort level. So yes, when it decides what it wants to be when it grows up, then it could be a viable alternative. And like I mentioned in another thread [1], bootloaderspec has regressive boot capabilities also, it effectively says no to snapshotting $BOOT. Since the kernel goes on $BOOT, it means $BOOT contents can be so new they can't boot older snapshots which contain older /lib/modules. So if rootfs is being snapshot, then /boot needs to be snapshot with it. Fair enough. Some day this will all work well. In the mean time, I actually preferred GRUB 1, the lack of maintenance notwithstanding. That's a long ago sailed, and long lost or sunken ship. It's a choice between two week old left overs in the fridge, will I get food poisoned? Versus a new bottle of Burns Going In and Coming Out Hot Sauce™? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, 2014-02-04 at 10:21 +0100, Stephen Gallagher wrote: On 02/01/2014 11:07 PM, Kevin Kofler wrote: Stephen Gallagher wrote: Right now, the vision essentially looks like: Fedora Products: This *is* Fedora. It comes in three flavors. I don't like the hardcoded three there at all, because if KDE is to ever become a full-fledged Product (which IMHO it should have been from the beginning!), it will need to change (unless you're dropping one of your 3 sacred spins). Well, I thought it was clear, since I did include the words Right now, but yes: I do think that other products should be both permitted and planned. One thing I've been discussing as an option with some of the members of the KDE SIG is to promote Fedora Scientific, based on the present-day KDE and Scientific Spins, as a fourth Fedora Product. I think this would be valuable as it would also act as a prototype for what the new-product process will need to be going forward. To address another concern you had elsewhere: One of the stated goals of the Products is to provide a known and reliable setup. I don't view it as reducing Freedom (or Choice) because a clear goal of this effort is to ensure that if you don't want this setup, you don't have to use it. You will be able to either install one of the the Products (and later remove packages you don't want) or you can install individual packages directly from the netinstall.iso just as you have always done. So I really view this as an add-on: if the *choice* a user wants to make is I'd like someone who knows more than I do to make the decision about what I should have installed, that's just as valid a choice as I want to use DNF instead of YUM. It's just taking place at a higher level. Very well said and I agree. It takes a long time with some packages to ensure that you have all the dependencies, supporting software (such as Gschem, gnetlist, and ngspice, along with models, footprints, and symbols) and useful utilities, such as snapshot, and Gerber viewers. Moreover, while a user often knows what needs to be done, figuring out which utilities work well with the application is something a new user would not be equipped to handle. Regards, Les H -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 10:49 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: /boot is useful regardless of how you boot. The ESP doesn't need to be very large and doesn't cause any harm if booted via BIOS. The BIOS Boot partition only needs to be ~64kB IIRC, and UEFI boot will happily ignore it. You don't even need to have any contents in there. GRUB devs want 1MB for BIOS Boot. And then it also maintains 1MB alignment. Nevertheless one Kleenex is more valuable than 1MB of drive space, even on an SSD. IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. I'm not opposed to the layout, but I'm personally totally disinterested in the ensuing clusterf|ck experiences I've already had with UEFI+BIOS dual boot OS's. If I could only experience food poisoning instead, my disposition would be no worse for the wear. That's okay. I can deal with the clusterfsck all on my own, as long as other things don't get in the way unnecessarily. :) My opinion: anything that requires BIOS to boot is old, or it's broken. And if it's old, it should be put into a VM. And if it's broken it should be fixed if it isn't a bad idea from the outset. Everyone wins. Especially people who install via UEFI, upgrade their BIOS, and go oh sh*t when the BIOS upgrade conveniently erases their boot entry. Let's agree to not equate UEFI and BIOS. There is nothing basic about UEFI. Touché! --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 653 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 83 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 47 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0282/moodle-2.4.8-1.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0378/quassel-0.9.2-1.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0398/socat-1.7.2.3-1.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0395/libpng10-1.0.60-6.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0401/libyaml-0.1.3-4.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0409/zarafa-7.1.8-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0429/mediawiki119-1.19.11-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0426/tpp-1.3.1-17.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing bcfg2-1.3.3-4.el6 knot-1.4.2-1.el6 llvm-3.4-6.el6 mozilla-adblockplus-2.4.1-1.el6 mysql-connector-python-1.1.5-1.el6 perl-No-Worries-1.1-1.el6 php-tcpdf-6.0.059-1.el6 python-ceilometerclient-1.0.8-1.el6 python-django-sorting-0.1-9.el6 Details about builds: bcfg2-1.3.3-4.el6 (FEDORA-EPEL-2014-0444) A configuration management system Update Information: EPEL7 updates; EPEL5 bcfg2-web pkg disabled ChangeLog: * Sat Feb 1 2014 John Morris j...@zultron.com - 1.3.3-4 - Disable bcfg2-web package on EL5; bz #1058427 - Disable %check on EL7; missing EPEL deps - BR: systemd to pick up _unitdir macro * Mon Jan 27 2014 Sol Jerome sol.jer...@gmail.com - 1.3.3-4 - Fix BuildRequires for EPEL7's Django - Remove unnecessary client-side lxml dependency - Add Django dependency for bcfg2-web (the web package *does* require Django for the database) - Fix OS detection for RHEL7 initscripts References: [ 1 ] Bug #1058427 - Add bcfg2 package to EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1058427 knot-1.4.2-1.el6 (FEDORA-EPEL-2014-0449) An authoritative DNS daemon Update Information: Add Knot DNS server into EPEL 6. llvm-3.4-6.el6 (FEDORA-EPEL-2014-0264) The Low Level Virtual Machine Update Information: Updated el6 to 3.4, obseleted pure, and removed --with-c-include-dir. ChangeLog: * Mon Feb 3 2014 Dave Johansen davejohan...@gmail.com 3.4-6 - Removing specification of --with-c-include-dirs * Wed Jan 29 2014 Dave Johansen davejohan...@gmail.com 3.4-5 - Obsoleting pure on EL6 * Sat Jan 18 2014 Dave Johansen davejohan...@gmail.com 3.4-4 - Enable building on EL6 * Fri Jan 17 2014 Dave Airlie airl...@redhat.com 3.4-3 - bump nvr for lldb on ppc disable * Tue Jan 14 2014 Dave Airlie airl...@redhat.com 3.4-2 - add ncurses-devel BR and Requires * Tue Jan 14 2014 Dave Airlie airl...@redhat.com 3.4-1 - update to llvm 3.4 release * Fri Dec 20 2013 Jan Vcelak jvce...@fedoraproject.org 3.3-4 - remove RPATHs - run ldconfig when installing lldb (#1044431) - fix: scan-build manual page is installed into wrong location (#1038829) - fix: requirements for llvm-ocaml-devel packages (#975914) - add LLVM cmake modules into llvm-devel (#914713) * Sat Nov 30 2013 Jan Vcelak jvce...@fedoraproject.org 3.3-3 - properly obsolete clang-doc subpackage (#1035268) - clang-analyzer: fix scan-build search for compiler (#982645) - clang-analyzer: switch package architecture to noarch * Thu Nov 21 2013 Jan Vcelak jvce...@fedoraproject.org 3.3-2 - fix build failure, missing __clear_cache() declaration * Tue Nov 12 2013 Jan Vcelak jvce...@fedoraproject.org 3.3-1 - upgrade to 3.3 release - add compiler-rt, enables address sanitizer (#949489) - add LLDB - debugger from LLVM project (#1009406) - clean up documentation * Thu Oct 17 2013 Jakub Jelinek ja...@redhat.com - 3.3-0.10.rc3 - Rebuild for gcc 4.8.2 * Sat Sep 14 2013 Petr
Re: Problems running mock with rawhide build root
On 02/04/2014 02:44 PM, Sergio Pascual wrote:
Hi, I'm having problems running mock with a rawhide buildroot.
I get the following error
ERROR: Command failed. See logs for output.
# /usr/bin/repoquery -c /tmp/tmpQ6Wu7m --installed -a --qf '%{nevra}
%{buildtime} %{size} %{pkgid} %{yumdb_info.from_repo}'
/var/lib/mock/fedora-rawhide-x86_64/result/installed_pkgs
And in the root.log file
DEBUG util.py:281: error: cannot open Packages index using db5 -
Permission denied (13)
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
Which seems highly suspicious. Is something related with RPM broken in
rawhide?
Not that I know of, nor am I able to reproduce that.
https://bugzilla.redhat.com/show_bug.cgi?id=982043 has similar symptoms
as well, but as to what is causing it... Could be some exotic setup,
also I wouldn't count out SELinux being related one way or another.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: And in fact it's worse in that presently I can't create an ESP per disk because the installer is mountpoint centric not partition centric. So I can only create one ESP on one disk because I can have only one /boot/efi. https://bugzilla.redhat.com/show_bug.cgi?id=1060576 You can create as many ESPs as you like, you just can't mount more than one of them in the same location. I don't see how anaconda can somehow magically fix this. If there is a 'problem' here it's the one you mentioned in another mail, that Fedora's approach to dealing with UEFI is too centred around a magic mount point, but I _really_ am not feeling that supporting fricking RAID-1 boot (which has always been more of a pain in the arse than it's worth, in my opinion) is the most pressing problem we have to deal with when it comes to UEFI. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? RFE: always create required bootloader partitions in custom partitioning https://bugzilla.redhat.com/show_bug.cgi?id=1022316 I'm not opposed to both ESP and BIOSboot created for every selected disk at install time. But I am opposed to the current behavior of not creating that which is mandatory for operation, while the installer then proceeds to chew me out for not having created it. It knows enough to squawk at me, but it doesn't know enough to just do the thing that needs to be done? Grrr that's not OK. One's a lot harder than the other. If you have multiple disks, how do we know which one you want the ESP on? If the layout you created filled the whole disk, what do we shrink to fit the ESP in? You of all people know the consequences of adding more complexity to the installer's partitioning codepaths. ;) I think the improvements for F21 - better error messages, and displaying the errors before you leave custom partitioning - should do the job fine. I think it was the bad error message and the Where's Waldo routine to find it that most confused people/pissed them off in F20 and earlier. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? I'm guessing that userspace improvements since then have mostly fixed this. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (tm). Also, isn't this already sort of necessary on large disks? (I maintain at least ten machines like this, running Fedora and various Ubuntus, some installed graphically and some installed by untarring a system image. I haven't had any problem at all.) --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 11:49 -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? The major thing was we found quite a lot of systems that just don't boot this way. Large numbers of Thinkpads appear to have firmwares that can't boot BIOS-native installs from GPT disks, for instance. We didn't auto-create a BIOS boot partition in custom partitioning, and people were often stumped by the requirement. People hit the same problem with UEFI installs and the ESP, of course, but we're stuck with that: we *have* to support UEFI. We don't have to cause ourselves the pain with BIOS-native installs. Also, people are more likely to accept that things will be different with a completely new firmware standard than they are with the idea that we just arbitrarily changed our default disk format and required them to learn about this 'BIOS boot partition' thing. Your proposal like cmurf's involves us auto-creating the BIOS boot partition, so it doesn't have *that* problem, but it has another problem, the one I pointed out to cmurf - it's not actually all that easy to have custom part just magically do stuff for you, and it certainly makes the code paths more fragile, and we really don't need any more fragility in partitioning. I'm guessing that userspace improvements since then have mostly fixed this. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (tm). You might want to go look back at the F16 release validation process and the anaconda bug list from that period. It was anything but Just Working. :) Also, isn't this already sort of necessary on large disks? Yeah. MBR disks top out at 2.2TB or something like that - you can format a bigger disk with an MBR partition table, but the space beyond whatever the limit is won't be available. These are already special-cased in the installer, if we're reformatting a disk that's above that size, we format it to GPT not MBR (and the BIOS boot partition requirement kicks in). (I maintain at least ten machines like this, running Fedora and various Ubuntus, some installed graphically and some installed by untarring a system image. I haven't had any problem at all.) Ten machines is nice and all, but we have, you know, 10,000 times that many or whatever it is to worry about for a Fedora release :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:02 PM, Andrew Lutomirski l...@mit.edu wrote: IMO in an ideal world, there would be one (or zero!) copy of the bootloader config, and the default configuration of the bootloader would populate the ESP (with the signed shim!), the BIOS Boot partition, and the (fake) MBR in the first sector. That way the disk would *always* be BIOS-bootable and, as long as there's a (working) copy of efibootmgr around, you can make the system UEFI-bootable with a single command that doesn't write to disk. I'm not opposed to the layout, but I'm personally totally disinterested in the ensuing clusterf|ck experiences I've already had with UEFI+BIOS dual boot OS's. If I could only experience food poisoning instead, my disposition would be no worse for the wear. That's okay. I can deal with the clusterfsck all on my own, as long as other things don't get in the way unnecessarily. :) So the problems with this idea you have: https://bugzilla.redhat.com/show_bug.cgi?id=1022316#c3 1. I'm not certain it's simpler code: if EFI, then GPT with ESP and BIOSBoot; if BIOS, then MBR when destination 2TB else GPT with ESP and BIOSBoot. If it is simpler for the anaconda team, fine then I'm neutral. 2. But for users, it's a total edge case to think of switching between BIOS and UEFI without reinstalling, let alone actually doing it. 3. Realize there's no way for anaconda to know if the computer is UEFI booted with the CSM. So a.) it can't use GPT for all BIOS computers, because we know from a circa Fedora 15 release that this causes problems for some BIOS firmware; and b.) using MBR there is no such thing as BIOSBoot, and blivet has no code for creating ESP's with 0xEF on MBR disks which also uses a valuable primary partition in the process, therefore the request only makes it easier to convert EFI to BIOS. It does nothing for BIOS to EFI ease of conversion. And as I argued before, needing to convert from EFI to BIOS implies something is broken and needs to be fixed, not fuck it up worse by converting the install to BIOS. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:34 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: And in fact it's worse in that presently I can't create an ESP per disk because the installer is mountpoint centric not partition centric. So I can only create one ESP on one disk because I can have only one /boot/efi. https://bugzilla.redhat.com/show_bug.cgi?id=1060576 You can create as many ESPs as you like, you just can't mount more than one of them in the same location. Yep you're right. If I had thought of creating bogus mount points first, then I can in fact tediously create ESP's per disk. Then post install I have to fix the f'd up fstab. And then copy boot files from the first ESP to all of the other ESPs. So I'd say it's not really creating ESPs when it's like that compared to the behavior on BIOS/MBR. I don't see how anaconda can somehow magically fix this. Create an ESP for every chosen disk, copy the boot files to each ESP. Just do it automatically, don't tell me, don't complain, don't show me. It's no different than BIOS/MBR. I don't understand how just because the firmware has changed we suddenly need to see required partitions. If there is a 'problem' here it's the one you mentioned in another mail, that Fedora's approach to dealing with UEFI is too centred around a magic mount point, but I _really_ am not feeling that supporting fricking RAID-1 boot (which has always been more of a pain in the arse than it's worth, in my opinion) is the most pressing problem we have to deal with when it comes to UEFI. I didn't say it was most pressing. It is a regression compared to BIOS/MBR: each chosen disk had a boot loader location created, and each boot loader location had a boot loader installed. The user had to do nothing in the installer to make that happen. I don't think I've yet to have /boot on raid1 fail to install or boot, even degraded, in any version of Fedora. So I don't know what's a PITA about it. You check a box for raid1, you put /boot on it. Done. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 12:26 -0800, Adam Williamson wrote: Your proposal like cmurf's involves us auto-creating the BIOS boot partition, so it doesn't have *that* problem, but it has another problem, the one I pointed out to cmurf - it's not actually all that easy to have custom part just magically do stuff for you, and it certainly makes the code paths more fragile, and we really don't need any more fragility in partitioning. Thinking about this a bit more, it probably wouldn't be *too* hard / complex / dangerous to at least pre-populate custom part with the appropriate 'special' partitions for your disk: i.e. run a restricted version of autopart automatically when entering the custom part spoke, which doesn't create the /boot and swap and / partitions, but just any partitions required for booting or other special circumstances. I'll add a comment to cmurf's bug... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, 2014-02-04 at 10:21 +0100, Stephen Gallagher wrote: On 02/01/2014 11:07 PM, Kevin Kofler wrote: Stephen Gallagher wrote: Right now, the vision essentially looks like: Fedora Products: This *is* Fedora. It comes in three flavors. I don't like the hardcoded three there at all, because if KDE is to ever become a full-fledged Product (which IMHO it should have been from the beginning!), it will need to change (unless you're dropping one of your 3 sacred spins). Well, I thought it was clear, since I did include the words Right now, but yes: I do think that other products should be both permitted and planned. One thing I've been discussing as an option with some of the members of the KDE SIG is to promote Fedora Scientific, based on the present-day KDE and Scientific Spins, as a fourth Fedora Product. I think this would be valuable as it would also act as a prototype for what the new-product process will need to be going forward. This still seems kind of bizarre to me. Scientific Workstation is a very niche spin for a particular audience which happens to use the KDE desktop because, I dunno, the person who built the spin had to pick *some* desktop and they liked KDE more than GNOME or something. KDE is our most significant desktop spin after GNOME. If we're expanding the product set, Fedora KDE seems like a reasonable Product candidate, but smooshing it together with Scientific Workstation seems a bit bizarre. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, 2014-02-04 at 11:11 +0100, H. Guémar wrote: I'm not fond of keeping spins around when we're focusing on products. That gives the message that they are second-class citizens in Fedora. We already have about sixteen 'citizen classes' within the spin system, as I pointed out in another mail. Exactly one spin is our default deliverable. Exactly two spins block the release. Exactly six spins are considered 'desktops' and given increased prominence on the download page. Etc etc. There is basically nowhere except https://spins.fedoraproject.org/ , which I don't think is a particularly high traffic page, that actually treats all spins as equal. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:30 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 11:49 -0700, Chris Murphy wrote: On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski l...@mit.edu wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? RFE: always create required bootloader partitions in custom partitioning https://bugzilla.redhat.com/show_bug.cgi?id=1022316 I'm not opposed to both ESP and BIOSboot created for every selected disk at install time. But I am opposed to the current behavior of not creating that which is mandatory for operation, while the installer then proceeds to chew me out for not having created it. It knows enough to squawk at me, but it doesn't know enough to just do the thing that needs to be done? Grrr that's not OK. One's a lot harder than the other. If you have multiple disks, how do we know which one you want the ESP on? All of them should. But at a minimum, each bootable disk needs one or it isn't a bootable disk, is it? So wherever /boot exists and ESP is needed. Two disk /boot on raid1? Both disk. Three disk /boot on raid5? All three disks. Otherwise why even let the user create such a thing when it can't boot upon single disk failure? Honestly… why put in the effort to build the bridge to 90% completion and then let the cars just drop one after another into the abyss? If it's offered it should work. If it's not going to work, don't offer it. If the layout you created filled the whole disk, what do we shrink to fit the ESP in? It's easier if the ESP size is withheld from Available Space for every selected disk, and every selected disk gets an ESP. But if worry warts don't want ESPs on certain drives well then that's more code that I won't oppose but I'll think is totally unnecessary. You of all people know the consequences of adding more complexity to the installer's partitioning codepaths. ;) Yeah what's complex is error checking whether an ESP is needed, and whether it's present, and the not present gripe code, translating into (how many languages are we supporting these days?) and testing all of that. For no good reason. Windows and OS X? It's one size fits all. Your boot disks get an ESP. No options. On OS X actually, all GPT disks get an ESP whether they're intended for booting or not. There is no option, no visible indication at all that the disk has or will get one and no way to specify the ESP size. No complexity and and there are no complaints in millions of users! Do we want an ESP bigger than 200MB? Fine have that conversation if you want. Maybe it ought to be 550MB so that mkdosfs will make our ESP's conform to the UEFI spec by formatting them FAT32 instead of FAT16. And then it'd also be big enough for the fans of the ESP as $BOOT for gummiboot/bootloaderspec. I'm not opposed to it being bigger. But it is precisely this type of hysterically unnecessary customization creep that has made Custom Partitioning the event horizon for QA testing. We will never ever test most let alone all combinations in Custom Partitioning because of shit just like this. I think the improvements for F21 - better error messages, and displaying the errors before you leave custom partitioning - should do the job fine. I think it was the bad error message and the Where's Waldo routine to find it that most confused people/pissed them off in F20 and earlier. *sigh* yes Adam, it's better in that a flower has sprung up from the pile. Somehow I still prefer getting rid of the turds instead of polishing them approach. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 10:30:58AM -0800, Andrew Lutomirski wrote: On Tue, Feb 4, 2014 at 10:19 AM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 10:42 AM, Andrew Lutomirski l...@mit.edu wrote: I think that half the difficulty here is that UEFI is annoying and the other half is that both GRUB2 and efibootmgr are miserable. For single OS installs, you shouldn't have to interact with any of those things. shim.efi, or shim via fallback.efi (?) will even do a fallback boot of Fedora if NVRAM has somehow been vanquished. How does firmware find shim.efi? Is it installed as bootx64.efi? IIRC that approach used to be frowned upon. It installs a fallback loader as bootx64.efi which then creates new boot entries for any installed operating systems it can find. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 4, 2014, at 12:49 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? Firmware face planted. For many it was the lack of an MBR entry with an active bit set, so there is now this PMBRboot flag where the 0xEE has an active bit set. And that pisses off other firmware. So it's no win. I'm guessing that userspace improvements since then have mostly fixed this. It wasn't a user space problem. It was a firmware problem. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (™). None are Lenova computers are they? Also, isn't this already sort of necessary on large disks? Yes but long ago Microsoft's edict was basically GTFO and buy a new computer with UEFI if you want to boot from 2+TB drives. The Windows installer requires MBR for boot disks on BIOS computers. And it requires GPT for boot disks on UEFI computers. Since most firmware testing involves seeing if Windows installs and boots successfully, it essentially means there's a lot of BIOS hardware out there that simply will not support 2+TB drives for booting, ever. (I maintain at least ten machines like this, running Fedora and various Ubuntus, some installed graphically and some installed by untarring a system image. I haven't had any problem at all.) Karma. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 04, 2014 at 11:49:06AM -0800, Andrew Lutomirski wrote: What failed? I'm guessing that userspace improvements since then have mostly fixed this. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (tm). Some firmware sees a GPT label and refuses to even attempt a BIOS boot. We tried this back in F16, tried further by violating the spec as it stood at the time and marking the protective MBR bootable and discovered that there are still systems where this just doesn't work. Also, isn't this already sort of necessary on large disks? There's not really anything else we can do in that case, so we make a best effort and if it doesn't work then, well. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 14:45 -0700, Chris Murphy wrote: You of all people know the consequences of adding more complexity to the installer's partitioning codepaths. ;) Yeah what's complex is error checking whether an ESP is needed, and whether it's present, and the not present gripe code, translating into (how many languages are we supporting these days?) and testing all of that. For no good reason. That code isn't particularly complex, actually, and we've had it for years - that's why the error message used to be so crappy, because it's generic code. There's a generic framework for requirements for stage1 bootloader targets depending on the platform. When creating a new platform you basically fill out a checklist for its requirements for a bootloader stage1 target device. For the BIOS platform that's an MBR or GPT disk. For UEFI platform it's an EFI system partition on a GPT disk. For uboot-y ARM it's a U-Boot partition. Etc etc. All using a solid mechanism that's been in anaconda for years. What you're suggesting is something different and, I think, completely new - I'm not the foremost expert on blivet or anything, but I don't think it has capabilities anything like what you're suggesting at present. Functionally speaking your description makes sense - this is just the place where the bootloader goes and we used to just take care of it for you and now we don't. But that's really not how it looks to the installer or the installer UI. The old bootloader location was not a disk partition, the user interacting with the installer could barely 'see' or 'touch' it at all. It had very limited configurability. None of this is true of the ESP (or similar designs). Windows and OS X? It's one size fits all. Your boot disks get an ESP. No options. On OS X actually, all GPT disks get an ESP whether they're intended for booting or not. There is no option, no visible indication at all that the disk has or will get one and no way to specify the ESP size. No complexity and and there are no complaints in millions of users! Millions of users don't install Windows or OS X; they get it installed for them. And have you looked at what *other* partitioning options Windows gives you? just about zip. zero. none. If we could get away with an installer that simple, we could do a lot more magical whizzy stuff, yes. But it seems fairly clear that we can't (though I'd be all in favour of it - anything for a quiet life). But it is precisely this type of hysterically unnecessary customization creep that has made Custom Partitioning the event horizon for QA testing. We will never ever test most let alone all combinations in Custom Partitioning because of shit just like this. It's not really customization creep: newUI gives you slightly less space than oldUI did. For entirely selfish reasons I'm all for an installer that's a grey box with a green GO button, but I don't think that'd exactly fly with the established Fedora/RHEL user base (remember anaconda is a shared component). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, Feb 4, 2014 at 1:52 PM, Chris Murphy li...@colorremedies.com wrote: On Feb 4, 2014, at 12:49 PM, Andrew Lutomirski l...@mit.edu wrote: On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote: This reminds me: I *always* install with a GPT partition table, an ESP partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4 /boot near the beginning of the disk. All Linuxes seem perfectly happy to install this way (assuming you can figure out how to partition the disk like that in the first place) and booting that way in BIOS or EFI mode. Given that this wastes at most a few MB, should anaconda just partition like that by default? Definitely not. We tried doing BIOS installs to GPT disks by default in Fedora 16, and it was basically a complete disaster. What failed? Firmware face planted. For many it was the lack of an MBR entry with an active bit set, so there is now this PMBRboot flag where the 0xEE has an active bit set. And that pisses off other firmware. So it's no win. I'm guessing that userspace improvements since then have mostly fixed this. It wasn't a user space problem. It was a firmware problem. I've never seen any problem on F18 (IIRC) and up with GPT partition tables being BIOS-booted. It seems to Just Work (™). None are Lenova computers are they? Nope. In fact my only computer that I haven't done this to is Lenovo (and that's only because it has a Windows-on-TrueCrypt dual boot setup, and last time I checked that was fundamentally incompatible with UEFI. Anyway, point taken. My revised RFE is at: https://bugzilla.redhat.com/show_bug.cgi?id=1061478 and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, 2014-02-04 at 11:27 -0500, Przemek Klosowski wrote: On 02/04/2014 06:15 AM, Reindl Harald wrote: honestly going back to only a install DVD with a sane user-UI and dedicate all the time wasted for the spin/products/discrimination discussions for documentations, screenshots and howtos would have more benefit for Fedora there is nothing you can't setup with the one fits all DVD or even with a slim network install if you only knew what to install and how to configure Right! since spins are just a fancy way to install groups, I would like the main install to offer them in a distinct 'I want to customize' installation step of the One True Fedora. That assumes that one can actually mix and match groups, even if they affect the fundamental layers such as the desktop environment. I haven't tried a combined Gnome/KDE installation recently, but I remember that it just offered an option to start a login session in either desktop environment. You can in fact do this at present, though it isn't heavily advertised and I suspect was quietly snuck in by someone on the 'it's easier to apologize than ask permission' principle ;) If you choose the 'Basic Desktop' group on the left-hand side of Software Selection, you'll see the 'subsidiary' group set on the right-hand side includes all the major desktops, and you can pick as many of them as you like. I think you don't get quite the same set of package groups for each environment as you would if you picked its dedicated environment group on the left hand side, but you should get something that works at least. This isn't particularly supported, by which I mean: we don't promote or document it, QA doesn't do planned testing of it, and we wouldn't block a release on it being broken. But AFAIK it usually works OK. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Tue, 2014-02-04 at 14:29 -0800, Andrew Lutomirski wrote: and my suggestion is now to just create both partitions when installing to GPT. Presumably if firmware can handle a GPT disk at all, it won't care whether it happens to contain an ESP unless it's actually trying to boot it using UEFI. You're making a fatal mistake: assuming some kind of sense on the part of firmware authors. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Problems running mock with rawhide build root
Thank you for pointing me the bug report
2014-02-04 Panu Matilainen pmati...@laiskiainen.org:
On 02/04/2014 02:44 PM, Sergio Pascual wrote:
Hi, I'm having problems running mock with a rawhide buildroot.
I get the following error
ERROR: Command failed. See logs for output.
# /usr/bin/repoquery -c /tmp/tmpQ6Wu7m --installed -a --qf '%{nevra}
%{buildtime} %{size} %{pkgid} %{yumdb_info.from_repo}'
/var/lib/mock/fedora-rawhide-x86_64/result/installed_pkgs
And in the root.log file
DEBUG util.py:281: error: cannot open Packages index using db5 -
Permission denied (13)
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
Which seems highly suspicious. Is something related with RPM broken in
rawhide?
Not that I know of, nor am I able to reproduce that.
https://bugzilla.redhat.com/show_bug.cgi?id=982043 has similar symptoms
as well, but as to what is causing it... Could be some exotic setup, also I
wouldn't count out SELinux being related one way or another.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
