Re: Agenda for Env-and-Stacks WG meeting (2014-04-08)
On 04/09/2014 02:07 AM, Toshio Kuratomi wrote: On Tue, Apr 08, 2014 at 04:16:58PM +0200, Marcela Mašláňová wrote: On 04/08/2014 03:02 PM, Toshio Kuratomi wrote: not sure that the ruby scl should have its own change. It needs to have the equivalent filed for the fpc to evaluate, though. https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval_Process Since the guidelines aren't final, probably open an fpc ticket so the fpc sees the request and more that it's needed for the fedora scl change. Although the scl package guidelines aren't final, the guidelines/criteria for approving the scl itself were approved so fpc should be able to evaluate it in parallel to finishing the packaging guidelines. If we remove the ruby scl change we should add more to the main scl change, though, about expectations around the scl approval. For instance, we probably want to touch base with docs/marketing to see if they want to publicize scls in the exact same way as fedora changes or have a slightly different procedure. Also note, in case no one saw it in either fpc or fesco meeting notes, I'm traveling to a week and a half conference now followed by a week and a half of vacation.so I likely won't be around for any fedora meetings until april 27th (and playing catch up with my email for that first week.) -Toshio I'm trying to provide feature needed by Cloud WG, that's all. I can file a new ticket on FPC, but wouldn't it just duplicate communication about General SCL guidelines? Ruby193 could test workflow around SCL in Fedora, that's another good reason to try how far can I get it and what won't work :) I would prefer to keep my changes as is and let FESCo decide. I sense a miscommunication here -- the Draft Guidelines for approving an SCL say that you need to get the FPC to approve new SCLs: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#SCL_Approval_Process I felt that a new FPC ticket would be good because this is the first SCL to be approved and the FPC likely won't become aware of it unless it's called out in a ticket. -Toshio Ok, that's new. It would be great to actually know, which part of guidelines were already approved and which not. I'm following meeting minutes and sometimes looked at logs from FPC, but I probably missed those changes. https://fedorahosted.org/fpc/ticket/419 Also you should probably add category in FPC ticket. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Playground repository
On 04/08/2014 10:46 PM, drago01 wrote: On Tue, Apr 8, 2014 at 6:17 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: Playground repository = https://fedoraproject.org/wiki/Changes/Playground_repository Change owner(s): Marcela Mašláňová mmasl...@redhat.com, Mirek Suchý msu...@redhat.com Responsible WG: Env and Stacks WG The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from there. To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. What's the point of this feature? I mean if we think we are to strict we might want to rethink the guidelines. And how is that different from other coprs repos where poeple already can host that stuff on? It even uses COPR (and thus shares the same problems like lack of multilib and thus dependecy problems). Is this going to be enabled by default? If yes how it is different from just adding the packages in fedora proper if not why is it a feature at all? It is just yet another external repo. No, it won't be enabled by default. All Coprs acceptable by Playground will be on one place with at least some rules. On our yesterday meeting we spoke to tflink about using taskotron at least for some general tests. We have higher standards on packages going into Playground, but not too high. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Playground repository
To chime in here, we have been doing something like this in GStreamer for a long while. There is 'plugins-base' and 'plugins-good' plugins which is comparable to the current core Fedora repository. Any plugin going into base or good need to conform to certain coding standards, licensing standards and documentation standards. Then there is 'plugins-ugly' which is more like rpmfusion. It still has the coding and documentation standards, but licensing can be of a wider variety. (Not just 'non-free' as GStreamer do not accept GPL plugins into the base or good repositories either due to being a LGPL toolkit). Finally there is plugins-bad, which is a bit more like what I think Playground will be. It is a repository with plugins which for a variety of reasons are not ready for any of the other ones yet. This could be that they are not of a high enough coding quality yet or lack documentation, but they still 'work'. And what we found over the years, is that while it is good to have high standards for these plugins to stretch towards in order to get included in one of the other modules, having 'bad' available is crucial as a way to get access to plugins that might be critical to their usecase even if they are not up to our technical standards yet. So while it can be frustrating that some plugins end up lingering in bad for a long time, it is still a much better scenario than people deciding GStreamer is useless for them and move somewhere else. Christian - Original Message - From: Stephen Gallagher sgall...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, April 8, 2014 7:04:54 PM Subject: Re: F21 Self Contained Change: Playground repository -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 12:24 PM, Michael Cronenworth wrote: Jaroslav Reznik wrote: For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and *packages that are never going to make it there.* This sounds like a problem and not a feature. Why would packages never make it to Fedora, yet be available in this new repository? My intent here is to be constructive so my question is genuine. I don't believe Fedora should start down the path of a fragmented repository structure. It makes sense for RHEL and its software channels it can sell support for, but Fedora is different. RPMFusion being an exception as it is a legal necessity. My interpretation here is that there exists plenty of genuinely open-source software out there for which it will likely never be possible to package fully according to Fedora's packaging guidelines due to bundling or similar issues (the obvious example being the oft-requested Chromium). Similarly, there are a great many useful Ruby libraries and applications out there for which unbundling them would be an exercise in futility. Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Also packages that are never going to make it there should probably have been phrased more politically: Even if the reality of the situation is that perfect adherence to the Fedora packaging guidelines is infeasible. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNELDYACgkQeiVVYja6o6MoCACggkj5lqoAtzbDxboz94/bxXma wH4AoI33Q7n/z2W+q6+9baU1ohhR7iXg =IzBI -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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
trimming down Fedora installed size
Hi there, I've been struggling keeping a fedora 20 install on a small SSD, with 6gb / partition (/home is separate). Besides removing packages, I also found this useful: 1. remove /usr/share/docs 2. remove /usr/share/locale/* (all except en and en_US) 3. cleanup /var/log/journal, which seems it's not automatically rotated While this saves space, it also results in package upgrade warnings due to missing files. Are there any other disk space saving tips? What do you think about excluding docs by default in Fedora packages? And for docs either go online, or have a command to install/sync docs for all installed packages? (similar to ruby or npm packages install, not using rpm packages) I think less than 0.1% of users ever look into /usr/share/doc, but I don't have any data to back this up. As more folks switch to SSDs, it would benefit both for disk space saving and wearing to have less space occupied by default. Thanks -- 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: Five Things in Fedora This Week (2014-04-08)
On 8 April 2014 23:01, Corey Sheldon sheldon.co...@gmail.com wrote: I'm glad to supply a mirror site for initial seeding for such actions as needed (GMT-4 (US ES/DT) Also great mailing list but curious do you plan on creating a blog or podcast with such info for those not always near email client ..been forwarding to many friends not tied to pc or devel lists and have had inquiries The email is a convenient repost of the blog: Reposted from http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-08/ Fedora this week: http://fedoramagazine.org/category/general-news/fedora-this-week/ (FWIW, I generally detest podcasts. That's not an objection to them being provided, but this is one person who is unlikely to listen to them.) -- imalone http://ibmalone.blogspot.co.uk -- 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: trimming down Fedora installed size
On Wed, Apr 9, 2014 at 10:33 AM, Marius A marius1...@gmail.com wrote:
1. remove /usr/share/docs
Try this in /etc/rpm/macros.whatever:
%_excludedocs 1
But that'll exclude _all_ files marked as docs in packages such as man
pages, it's not limited to /usr/share/doc. You might also/instead want
to try this:
%_netsharedpath %{_datadir}/doc
2. remove /usr/share/locale/* (all except en and en_US)
Try this in /etc/rpm/macros.whatever:
%_install_langs en
It's possible that these settings break some things such as scriptlets
that do not take missing files into account, but at least they're
cleaner attempts than simply deleting installed files/dirs.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's (today's) FESCo Meeting (2014-04-09)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1221 Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 #topic #1244 F21 System Wide Change: cron to systemd time units .fesco 1244 https://fedorahosted.org/fesco/ticket/1244 #topic #1250 F21 Self Contained Changes .fesco 1250 https://fedorahosted.org/fesco/ticket/1250 #topic #1269 Closing all 'Merge Review' bugs .fesco 1269 https://fedorahosted.org/fesco/ticket/1269 = New business = #topic #1272 Reschedule meeting for DST shift? .fesco 1272 https://fedorahosted.org/fesco/ticket/1272 #topic #1274 F21 System Wide Change: GCC49 - https://fedoraproject.org/wiki/Changes/GCC49 .fesco 1274 https://fedorahosted.org/fesco/ticket/1274 #topic #1275 F21 System Wide Change: GHC 7.8 - https://fedoraproject.org/wiki/Changes/GHC_7.8 .fesco 1275 https://fedorahosted.org/fesco/ticket/1275 #topic #1276 F21 System Wide Change: lbzip2 as default bzip2 implementation - https://fedoraproject.org/wiki/Changes/lbzip2 .fesco 1276 https://fedorahosted.org/fesco/ticket/1276 #topic #1277 F21 System Wide Change: RPM-4.12 - https://fedoraproject.org/wiki/Changes/RPM-4.12 .fesco 1277 https://fedorahosted.org/fesco/ticket/1277 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Framework for Server Role Deployment
On Apr 8, 2014, at 9:48 PM, William Brown will...@firstyear.id.au wrote: == Detailed Description == A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them. Appropriate functionality will also be exposed as a command-line utility. What does it mean to deploy, configure, and manage a server role? Nothing and everything fits this whole description. Installation, setup of mandatory data, running of the necessary services, opening of the necessary ports, easy view of overall health of the services and gathering of backup sets. I'd like a bit more about this, especially the opening of ports (What about ip ranges?) and the gathering of backup sets and what that implies or how it's triggered. What additionally, counts as a server role in this case? Or are these not completely filled out yet? IE a network router is certainly a server role, but does it come under this case? Most of these questions are answered here: https://fedoraproject.org/wiki/Server/Product_Requirements_Document and many of the implementation details have been discussed on the ser...@lists.fp.o, but I certainly agree that we need to gather those details on a wiki page and link that and the PRD from this Change Proposal. I will look into doing this today.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Framework for Server Role Deployment
On Tue, Apr 8, 2014 at 3:08 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 07:22 AM, drago01 wrote: On Tue, Apr 8, 2014 at 12:53 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Framework for Server Role Deployment = https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment Change owner(s): Miloslav Trmač mitr AT volny DOT cz, Fedora Server Working Group server AT lists DOT fedoraproject DOT org Responsible WG: Server A new D-Bus service, and associated command-line tools, to deploy and manage Server Roles. == Detailed Description == A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them. Appropriate functionality will also be exposed as a command-line utility. == Scope == * Proposal owners: Write, document, package and test the D-Bus API. * Other developers: Possibly use the framework for development of new server roles. * Release engineering: Nothing * Policies and guidelines: Nothing Contingency mechanism: Do not ship the Server product with Fedora 21. What? That's not a contingency plan thats a nuke clause .. we could simply not ship any roles and add it in f21 (given that we don't have many roles to begin with). Yes, it's a nuke clause. This Change Proposal is a blocker for shipping the Fedora Server. Without completing this Change, Fedora Server is not meaningful. I am not sure I agree with that ... you can still install the server packages you need which probably is necessary even with this feature because ... Which roles are we going to ship with F21? Database server and ? This feature is not meaningful if common roles are not present. Like file server, web server, application server, could / virt server etc. Also if I enable / install / activate the database server role which database do I get? What if my applications need to talk to another database? Same for application server etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Mono 3.4
On 04/08/2014 01:44 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Mono 3.4 = https://fedoraproject.org/wiki/Changes/Mono_3.4 Change owner(s): Claudio Rodrigo Pereyra Diaz elsupergo...@fedoraproject.org Update the Mono stack in Fedora from 2.10 to 3.4 == Detailed Description == Support for Mono versions 3.0 and 2.10 is been discontinued. No further development of bug fixing is planned for those branches. Mono 3.4 is the active branch an have many improvements . See upstream notes [1] == Scope == * Proposal owners: Update mono spec and build in koji until is ready. * Other developers: Some packages may need to be revised, updated or rebuilt, see Dependencies section * Release engineering: None * Policies and guidelines: None While I very much appreciate the effort to bring the Mono stack up to date, I don't think these kinds of major updates work very well when one person updates the core compiler / libraries, and leaves the rest up to the chance. What else is needed? Does the rest of the mono stack need rebuilds? If yes, the person driving this should be a provenpackager and perform the rebuilds. Does this update drop support for older .NET profiles that apps might rely on? If yes, then other apps need coordinated updates as well. Has this been discussed this with chkr / spot, who have done mono updates previously? Also, I'd like to point out that elsupergomez is not yet a packager nor a provenpackager and getting the latter in particular can take time. I would suggest to reach out to chkr and spot and see if they are interested in helping out with this and new packager guidance. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Mono 3.4
- Original Message - On 04/08/2014 01:44 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Mono 3.4 = https://fedoraproject.org/wiki/Changes/Mono_3.4 Change owner(s): Claudio Rodrigo Pereyra Diaz elsupergo...@fedoraproject.org Update the Mono stack in Fedora from 2.10 to 3.4 == Detailed Description == Support for Mono versions 3.0 and 2.10 is been discontinued. No further development of bug fixing is planned for those branches. Mono 3.4 is the active branch an have many improvements . See upstream notes [1] == Scope == * Proposal owners: Update mono spec and build in koji until is ready. * Other developers: Some packages may need to be revised, updated or rebuilt, see Dependencies section * Release engineering: None * Policies and guidelines: None While I very much appreciate the effort to bring the Mono stack up to date, I don't think these kinds of major updates work very well when one person updates the core compiler / libraries, and leaves the rest up to the chance. What else is needed? Does the rest of the mono stack need rebuilds? If yes, the person driving this should be a provenpackager and perform the rebuilds. Does this update drop support for older .NET profiles that apps might rely on? If yes, then other apps need coordinated updates as well. Has this been discussed this with chkr / spot, who have done mono updates previously? Also, I'd like to point out that elsupergomez is not yet a packager nor a provenpackager and getting the latter in particular can take time. I would suggest to reach out to chkr and spot and see if they are interested in helping out with this and new packager guidance. I raided the same question in a private conversation and he's trying to reach original maintainers. I agree it's a lot of work ahead of him in case the agreement will be made and Change accepted by FESCo. But from my experience, many of people who came to Fedora, proposed change, without any experience in the end were one of the top contributors, proud they were able to contribute etc. So yes, FESCo should take it into consideration but I'd like to avoid situation when this Change will be banned solely on not a maintainer. Jaroslav -- Kalev -- 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: Packager on RHEL5/CentOS5?
On Tue, Apr 08, 2014 at 02:13:32PM +0200, Pierre-Yves Chibon wrote: Hi everyone, As you may know I am working on updating our package database (pkgdb) to a new version named pkgdb2. In this process, pkgdb-cli has got re-writen and now ships a pkgdb2.py python module that can be used as an interface to query the pkgdb2 API. The thing is that fedpkg relies on pkgdb-cli to retire packages and there is a milestone set for F22 to make python3 the default python interpreter [1]. The pkgdb2.py module mentionned above should work fine on EL5 as well as under python3, however that's not the case for pkgdb-cli. My question is thus, is there anyone here that is using RHEL5/CentOS5 to do packaging for Fedora/EPEL? If so, and if you rely on fedpkg/pkgdb-cli for it, please say so :) (here or on [2]). Otherwise, I am considering making the first release of pkgdb-cli for pkgdb2 on el6+ only. My reading of: https://access.redhat.com/site/support/policy/updates/errata/ is that only urgent security and bug fixes should be done now against RHEL 5. No one should be doing general development against RHEL 5 unless they want to support themselves. The question is whether urgent security fixes could include retiring packages. I think unlikely, unless it is discovered that a package has irretrievable security problems that cannot be solved in any way other than immediately removing it from distribution. Would it still be possible to retire a package manually (if that is meaningful)? Or would it not be possible at all? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Packager on RHEL5/CentOS5?
On Tue, Apr 08, 2014 at 02:13:32PM +0200, Pierre-Yves Chibon wrote: My question is thus, is there anyone here that is using RHEL5/CentOS5 to do packaging for Fedora/EPEL? If so, and if you rely on fedpkg/pkgdb-cli for it, please say so :) (here or on [2]). OK I think I read this backwards in my previous answer. No one should be using RHEL 5 to develop/package for Fedora(!) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- 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: trimming down Fedora installed size
On 04/09/2014 09:33 AM, Marius A wrote: 3. cleanup /var/log/journal, which seems it's not automatically rotated It's supposed to be automatic. How big did it become on your system? If the default size limits do not suit you, you can change them in /etc/systemd/journald.conf. Michal -- 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: trimming down Fedora installed size
On 04/09/2014 07:33 AM, Marius A wrote: Are there any other disk space saving tips? Users should not have to result doing disk saving tips. I would say in the long run we should be working towards creating separated locale,doc,man packages 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: trimming down Fedora installed size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 07:23 AM, Jóhann B. Guðmundsson wrote: On 04/09/2014 07:33 AM, Marius A wrote: Are there any other disk space saving tips? Users should not have to result doing disk saving tips. I would say in the long run we should be working towards creating separated locale,doc,man packages Hmm, I wonder if RPM 4.12 would allow us to do this with weak dependencies? Perhaps something like having a metapackage on the system for docs and one for each language. Then we could break up the doc and language packages into sub-packages that are installed conditionally on the presence of that metapackage on the system. Of course, I think there would still be work needed in RPM to support adding a language later, but maybe we could solve that with special tooling or a yum plugin. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNFNA0ACgkQeiVVYja6o6P3SgCfRoJnKbSe/2g6/HIZkzkYAJRc iDcAoKRygNTlNDEIbf8j46e94RowXtis =OpG3 -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: Agenda for Env-and-Stacks WG meeting (2014-04-08)
On Tue, Apr 08, 2014 at 05:14:37PM -0700, Toshio Kuratomi wrote: OTOH, how does the Cloud SIG want to use the SCL? If they want to create things that are outside of the SCL that make use of it, that would seem to be a point of coordination and thus would be Fedora Change worthy... On yet Right now, the primary want is as a consumer. The target is operations building and deploying their own code that utilizes the SCL. That is, end-users. We want to advertise that * there is an alternate Ruby on Rails stack available * it's easy to install and use * and it's done in a way which is consistent across our family of distros, making it easy to migrate back and forth from Fedora, CentOS, and RHEL to meet different needs We also do have some people who have expressed interest in helping maintain and extend the Software Collections used, but not commitment -- maybe I need to do some leaning on people. That's going to be vital long term. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: Packager on RHEL5/CentOS5?
On Wed, Apr 09, 2014 at 12:23:03PM +0100, Richard W.M. Jones wrote: On Tue, Apr 08, 2014 at 02:13:32PM +0200, Pierre-Yves Chibon wrote: My question is thus, is there anyone here that is using RHEL5/CentOS5 to do packaging for Fedora/EPEL? If so, and if you rely on fedpkg/pkgdb-cli for it, please say so :) (here or on [2]). OK I think I read this backwards in my previous answer. No one should be using RHEL 5 to develop/package for Fedora(!) The goal of this email is to confirm it :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: trimming down Fedora installed size
On 04/09/2014 11:50 AM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 07:23 AM, Jóhann B. Guðmundsson wrote: On 04/09/2014 07:33 AM, Marius A wrote: Are there any other disk space saving tips? Users should not have to result doing disk saving tips. I would say in the long run we should be working towards creating separated locale,doc,man packages Hmm, I wonder if RPM 4.12 would allow us to do this with weak dependencies? Perhaps something like having a metapackage on the system for docs and one for each language. Then we could break up the doc and language packages into sub-packages that are installed conditionally on the presence of that metapackage on the system. Of course, I think there would still be work needed in RPM to support adding a language later, but maybe we could solve that with special tooling or a yum plugin. Yeah and we probably have to move the man packages in their own sub-package once the rpm trigger that replaces the cron job lands 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: trimming down Fedora installed size
On Wed, Apr 09, 2014 at 07:50:37AM -0400, Stephen Gallagher wrote: I would say in the long run we should be working towards creating separated locale,doc,man packages Hmm, I wonder if RPM 4.12 would allow us to do this with weak dependencies? Perhaps something like having a metapackage on the system for docs and one for each language. Then we could break up the doc and language packages into sub-packages that are installed conditionally on the presence of that metapackage on the system. Of course, I think there would still be work needed in RPM to support adding a language later, but maybe we could solve that with special tooling or a yum plugin. +1 to all of this. Needs: * rpm macros, possibly other RPM work * packaging guidelines * yum/dnf tooling * a plan for realistically getting from where we are now to where we want to be * executing on that plan Cloud SIG has a lot of interest in this and we may be able to find some contributors to the effort there. https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_packages_in_Cloud_Image could be a model (and is in fact a prerequisite). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: trimming down Fedora installed size
On 04/09/2014 01:50 PM, Stephen Gallagher wrote: On 04/09/2014 07:23 AM, Jóhann B. Guðmundsson wrote: On 04/09/2014 07:33 AM, Marius A wrote: Are there any other disk space saving tips? Users should not have to result doing disk saving tips. I would say in the long run we should be working towards creating separated locale,doc,man packages Hmm, I wonder if RPM 4.12 would allow us to do this with weak dependencies? Perhaps something like having a metapackage on the system for docs and one for each language. Then we could break up the doc and language packages into sub-packages that are installed conditionally on the presence of that metapackage on the system. Of course, I think there would still be work needed in RPM to support adding a language later, but maybe we could solve that with special tooling or a yum plugin. Yes, this is one of the reasons we go for more expressive relations in RPM. You already very closely describe what I have in mind. There are basically two possible ways of making the distribution more flexible in the future: 1) Normal weak dependencies. In a normal install all the docs (and all other bells and whistles) get installed by default. You can remove/deselect packages which are pulled in by weak dependencies. You can even switch off all weak dependencies to only get the core packages. 2) Rich dependencies. Doc and language packages can be build as bridging packages that are only installed if two other packages are present. This can be done by adding e.g. Recommends: foo-langpack-hu if langsupport-hu to package foo or Supplements: foo and langsupport-hu to the foo-langpack-hu package. Similar things can be done for docs or any other set of packages that should be controlled by a single switch package. The nice thing about this is that no additional tooling is needed. Installing foo will automatically install the lang packs for all installed languages and installing a new langsupport package will install the langpacks for all installed packages. The plan is to get all pieces for 1) into F21. So it could already be used for F22. I will try to get 2) ready in this time frame, too, but the bets are still open. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Framework for Server Role Deployment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 06:02 AM, drago01 wrote: On Tue, Apr 8, 2014 at 3:08 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 07:22 AM, drago01 wrote: On Tue, Apr 8, 2014 at 12:53 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Framework for Server Role Deployment = https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment Change owner(s): Miloslav Trmač mitr AT volny DOT cz, Fedora Server Working Group server AT lists DOT fedoraproject DOT org Responsible WG: Server A new D-Bus service, and associated command-line tools, to deploy and manage Server Roles. == Detailed Description == A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them. Appropriate functionality will also be exposed as a command-line utility. == Scope == * Proposal owners: Write, document, package and test the D-Bus API. * Other developers: Possibly use the framework for development of new server roles. * Release engineering: Nothing * Policies and guidelines: Nothing Contingency mechanism: Do not ship the Server product with Fedora 21. What? That's not a contingency plan thats a nuke clause .. we could simply not ship any roles and add it in f21 (given that we don't have many roles to begin with). Yes, it's a nuke clause. This Change Proposal is a blocker for shipping the Fedora Server. Without completing this Change, Fedora Server is not meaningful. I am not sure I agree with that ... you can still install the server packages you need which probably is necessary even with this feature because ... Sorry, you misunderstand (and I wasn't terribly clear). Fedora is still useful as a server, but the Fedora Server *product* has no meaningful differentiation from Fedora with server packages without this. So if we don't deliver this, we may as well not ship specialized install media. Which roles are we going to ship with F21? The two we're working for in F21 are Domain Controller (powered by FreeIPA) and Database Server (powered by PostgreSQL). Database server and ? This feature is not meaningful if common roles are not present. Like file server, web server, application server, could / virt server etc. Well, a complete Domain Controller is certainly meaningful. Also, please understand that the focus of Roles is to provide turn-key *infrastructure*, not abitrary applications. So we looked at what we could provide that would benefit the most potential use-cases. We acknowledged that nearly any application that an end-user would want to build would need access to a database server and that in real-world deployments, databases are generally kept distinctly separate from the server (or VM) providing the application. So it makes sense to provide this as a Serevr Role with easy set-up in order to support all the other things people want to do. Also if I enable / install / activate the database server role which database do I get? We selected PostgreSQL by overwhelming majority vote among the Server WG. A MariaDB Role may come in the future, but we're only building one right now. What if my applications need to talk to another database? Same for application server etc. If your applications cannot use PostgreSQL, then you can always manually set up a different database. You just lose access to the simplicity of doing so via the role mechanism. This is additive; it doesn't replace the traditional way of doing things, but for the common use-cases we support it will make them vastly easier. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNFQQUACgkQeiVVYja6o6ORPQCfZxdBphDLy8650EI+HYpJ6yMH 5LUAoKW0772utqY7SCZE3NFNnEgr+Fuk =Cuht -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: trimming down Fedora installed size
On Wed, Apr 09, 2014 at 10:33:25AM +0300, Marius A wrote: I've been struggling keeping a fedora 20 install on a small SSD, with 6gb / partition (/home is separate). This part of conversation probably belongs on the user list rather than devel. But there are some development-related aspects (see rest of thread) and while we're at it, I have some constructive practical points as well. 2. remove /usr/share/locale/* (all except en and en_US) Also do localedef --delete-from-archive $(localedef --list-archive | grep -v -i ^$LANG | xargs) mv /usr/lib/locale/locale-archive /usr/lib/locale/locale-archive.tmpl build-locale-archive 3. cleanup /var/log/journal, which seems it's not automatically rotated It actually _is_ automatically rotated. See /etc/systemd/journald.conf and `man journald.conf`. Particularly, look at SystemMaxUse, SystemKeepFree, and MaxRetentionSec. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: trimming down Fedora installed size
On 04/09/2014 03:33 AM, Marius A wrote: I think less than 0.1% of users ever look into /usr/share/doc, but I don't have any data to back this up. I think I must fit into this 0.1% (and I am not disputing that that is the correct ratio, either) because I definitely use /usr/share/doc, but mostly because that holds more than just documentation. For example, avahi stores example service definitions for ssh and sftp under /usr/share/doc, and I believe this behavior exists with other packages for non-strictly-documentation data. I don't know what the standard is for defining what, if anything, should be placed under /usr/share/doc, but as it stands now, we should at least know and acknowledge that it's not just READMEs and HTML files when we make the decision to not install it by default or to reduce the chance that it's installed. Having said that, I am all for saving space on a default install and/or making a more minimal install possible. I noticed just now that manpages are compressed, but with gz. I am sure this discussion has already happened, but maybe we can have an alternative man-xz format that will reduce the size of the individual packages for a Fedora Minimal or somesuch (I think manpages should be very, very far down on the list of what to be left out from an install, as they are sometimes the last resort on what to do). My two bits on the idea. -- Libre Video http://librevideo.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
[Bug 1085336] perl-DBIx-Class-0.08250-2.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085336 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-DBIx-Class-0.08250-3.f ||c21 --- Comment #3 from Petr Pisar ppi...@redhat.com --- Upgrade to the latest version is left as an exercise for the package maintainer. -- 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=LRh5zOAnsUa=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: trimming down Fedora installed size
On Wed, Apr 09, 2014 at 09:53:10AM -0400, Basil Mohamed Gohar wrote: I think I must fit into this 0.1% (and I am not disputing that that is the correct ratio, either) because I definitely use /usr/share/doc, but mostly because that holds more than just documentation. For example, avahi stores example service definitions for ssh and sftp under /usr/share/doc, and I believe this behavior exists with other packages for non-strictly-documentation data. This is a packaging bug and should (probably must) be fixed. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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 1085579] perl-Moose compiled for perl API v5.16.0; fedora perl now at v5.18.0
https://bugzilla.redhat.com/show_bug.cgi?id=1085579 --- Comment #3 from simon.gal...@gmail.com --- I can confirm that the issue was local to one system -- our bad! Thanks! -- 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=1cph6PgYMNa=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: trimming down Fedora installed size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 10:01 AM, Matthew Miller wrote: On Wed, Apr 09, 2014 at 09:53:10AM -0400, Basil Mohamed Gohar wrote: I think I must fit into this 0.1% (and I am not disputing that that is the correct ratio, either) because I definitely use /usr/share/doc, but mostly because that holds more than just documentation. For example, avahi stores example service definitions for ssh and sftp under /usr/share/doc, and I believe this behavior exists with other packages for non-strictly-documentation data. This is a packaging bug and should (probably must) be fixed. Why is this a packaging bug? %doc is allowed to contain anything that is not used by the package for runtime execution. It's very common (and appropriate!) to have things like example config files in %doc. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNFVN0ACgkQeiVVYja6o6OBywCgrYgmx8fjMrhIRLHLwPc8g9jv NGQAoKudkM+C7x56tY8bwjXE3ziCUKOT =b7Cg -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: trimming down Fedora installed size
On Wed, Apr 09, 2014 at 10:10:37AM -0400, Stephen Gallagher wrote: I think I must fit into this 0.1% (and I am not disputing that that is the correct ratio, either) because I definitely use /usr/share/doc, but mostly because that holds more than just documentation. For example, avahi stores example service definitions for ssh and sftp under /usr/share/doc, and I believe this behavior exists with other packages for non-strictly-documentation data. This is a packaging bug and should (probably must) be fixed. Why is this a packaging bug? %doc is allowed to contain anything that is not used by the package for runtime execution. It's very common (and appropriate!) to have things like example config files in %doc. Sorry, I missed the word example. Examples _are_ just documentation, pretty much by definition, and shouldn't be required at runtime. So I'm not seeing a problem here. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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-SQL-Abstract] Update to 1.77
commit 99236d52ff15dafb27b0e2b2541de0c65303481f
Author: Paul Howarth p...@city-fan.org
Date: Wed Apr 9 15:15:25 2014 +0100
Update to 1.77
- Update to latest upstream version
- This release by RIBASUSHI - update source URL
- BR: perl(Data::Dumper) and perl(Test::Deep) ≥ 0.101
- Don't need to remove empty directories from the buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
.gitignore |4 +---
perl-SQL-Abstract.spec | 28 ++--
sources|2 +-
3 files changed, 20 insertions(+), 14 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e5b67cd..4814ce9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1 @@
-SQL-Abstract-1.67.tar.gz
-/SQL-Abstract-1.72.tar.gz
-/SQL-Abstract-1.73.tar.gz
+/SQL-Abstract-[0-9.]*.tar.gz
diff --git a/perl-SQL-Abstract.spec b/perl-SQL-Abstract.spec
index 10dcf26..d93b65b 100644
--- a/perl-SQL-Abstract.spec
+++ b/perl-SQL-Abstract.spec
@@ -1,23 +1,25 @@
Name: perl-SQL-Abstract
-Version:1.73
-Release:4%{?dist}
+Version:1.77
+Release:1%{?dist}
Summary:Generate SQL from Perl data structures
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/SQL-Abstract
-Source0:
http://search.cpan.org/CPAN/authors/id/F/FR/FREW/SQL-Abstract-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/SQL-Abstract-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Test::Exception)
-BuildRequires: perl(Test::Warn)
-BuildRequires: perl(Test::More) = 0.92
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(Class::Accessor::Grouped) = 0.10005
BuildRequires: perl(Clone) = 0.31
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(Getopt::Long::Descriptive) = 0.091
BuildRequires: perl(Hash::Merge) = 0.12
-BuildRequires: perl(Scalar::Util)
BuildRequires: perl(List::Util)
+BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::Builder)
+BuildRequires: perl(Test::Deep) = 0.101
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::Warn)
+BuildRequires: perl(Test::More) = 0.92
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Class::Accessor::Grouped) = 0.10005
Requires: perl(Getopt::Long::Descriptive) = 0.091
@@ -44,9 +46,8 @@ PERL5_CPANPLUS_IS_RUNNING=1 %{__perl} Makefile.PL
INSTALLDIRS=vendor
make
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -65,6 +66,13 @@ SQLATEST_TESTER=1 make test
%{_mandir}/man3/DBIx::Class::Storage::Debug::PrettyPrint.3pm*
%changelog
+* Wed Apr 9 2014 Paul Howarth p...@city-fan.org - 1.77-1
+- Update to latest upstream version
+- This release by RIBASUSHI - update source URL
+- BR: perl(Data::Dumper) and perl(Test::Deep) ≥ 0.101
+- Don't need to remove empty directories from the buildroot
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.73-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 3948930..9cd5158 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d72edac94a2bf487fcd19460c4d3a7d3 SQL-Abstract-1.73.tar.gz
+4e7af7304a5e6c89e1e23582c7d6b657 SQL-Abstract-1.77.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: trimming down Fedora installed size
On 04/09/2014 04:01 PM, Matthew Miller wrote: On Wed, Apr 09, 2014 at 09:53:10AM -0400, Basil Mohamed Gohar wrote: I think I must fit into this 0.1% (and I am not disputing that that is the correct ratio, either) because I definitely use /usr/share/doc, but mostly because that holds more than just documentation. For example, avahi stores example service definitions for ssh and sftp under /usr/share/doc, and I believe this behavior exists with other packages for non-strictly-documentation data. This is a packaging bug and should (probably must) be fixed. Pardon, but you're not right: Examples are considered to be documentation. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-SQL-Abstract] Created tag perl-SQL-Abstract-1.77-1.fc21
The lightweight tag 'perl-SQL-Abstract-1.77-1.fc21' was created pointing to: 99236d5... Update to 1.77 -- 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: trimming down Fedora installed size
On 04/09/2014 03:53 PM, Basil Mohamed Gohar wrote: Having said that, I am all for saving space on a default install and/or making a more minimal install possible. I noticed just now that manpages are compressed, but with gz. I am sure this discussion has already happened, but maybe we can have an alternative man-xz format that will reduce the size of the individual packages for a Fedora Minimal or somesuch (I think manpages should be very, very far down on the list of what to be left out from an install, as they are sometimes the last resort on what to do). SUSE once ( 10 years ago) had used *.bz2-compressed manpages, but for a while they also have returned to *.gz. I don't know why they did so, but I'd guess it simply doesn't pay-off size-wise and introduced too much of a penalty speed-wise. So, I'd question the usefulness of not installing man-pages, because their sizes are comparatively small on today's disk-scales, e.g. on my primary system: # du -sh /usr/share/man 89M /usr/share/man That's almost neglibile in comparision to the overall size of the installation. 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
ImageMagick 6.8.8-10 in rawhide. Soname change.
Hello. New version landed in rawhide. Sorry for the late info - incidental soname change happened (fixed in spec now): /usr/lib64/libMagick++-6.Q16.so.1 /usr/lib64/libMagick++-6.Q16.so.1.0.0 /usr/lib64/libMagickCore-6.Q16.so.1 /usr/lib64/libMagickCore-6.Q16.so.1.0.0 /usr/lib64/libMagickWand-6.Q16.so.1 /usr/lib64/libMagickWand-6.Q16.so.1.0.0 Dependency rebuild needed. If you are willing I'll rebuild all after 3 days if you do not answer I should not do it. Packages for rebuild: $ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* | fgrep -v 'ImageMagick-' | sort -u a2ps-0:4.14-24.fc21.i686 a2ps-0:4.14-24.fc21.x86_64 anyremote-0:6.4-1.fc21.x86_64 autotrace-0:0.31.1-38.fc21.i686 autotrace-0:0.31.1-38.fc21.x86_64 autotrace-devel-0:0.31.1-38.fc21.i686 autotrace-devel-0:0.31.1-38.fc21.x86_64 caja-image-converter-0:1.8.0-1.fc21.x86_64 calibre-0:1.30.0-2.fc21.x86_64 c-graph-0:2.0-5.fc20.x86_64 converseen-0:0.6.6.1-2.fc21.x86_64 cuneiform-0:1.1.0-15.fc21.i686 cuneiform-0:1.1.0-15.fc21.x86_64 dblatex-0:0.3.4-8.fc20.noarch drawtiming-0:0.7.1-12.fc21.x86_64 emacs-1:24.3-15.fc21.x86_64 epix-0:1.2.13-3.fc21.i686 epix-0:1.2.13-3.fc21.x86_64 fbida-0:2.09-6.fc20.x86_64 freewrl-0:1.22.13.1-13.fc21.i686 freewrl-0:1.22.13.1-13.fc21.x86_64 fvwm-0:2.6.5-6.fc20.x86_64 gallery2-imagemagick-0:2.3.2-10.fc20.noarch geeqie-0:1.1-17.fc21.x86_64 gnumed-0:1.4.5-1.fc21.noarch gpsdrive-0:2.11-21.fc21.x86_64 gscan2pdf-0:1.2.3-1.fc21.noarch gtatool-imagemagick-0:1.5.2-11.fc21.x86_64 gyachi-0:1.2.11-10.fc21.x86_64 hdrprep-0:0.1.2-12.fc20.noarch html2ps-0:1.0-0.16.b7.fc21.noarch icewm-clearlooks-0:1.3.8-1.fc21.noarch inkscape-0:0.48.4-12.fc21.x86_64 inkscape-view-0:0.48.4-12.fc21.x86_64 k3d-0:0.8.0.2-24.fc21.i686 k3d-0:0.8.0.2-24.fc21.x86_64 kipi-plugins-0:4.0.0-0.6.beta4.fc21.x86_64 kxstitch-0:0.8.4.1-17.fc21.x86_64 latex2rtf-0:2.3.6-1.fc21.x86_64 libdmtx-utils-0:0.7.2-12.fc21.x86_64 libpst-0:0.6.63-1.fc21.x86_64 lyx-0:2.0.7-3.fc21.x86_64 mediawiki-0:1.22.5-1.fc21.noarch mtpaint-0:3.40-14.fc20.x86_64 nautilus-image-converter-0:0.3.1-0.6.git430afce31.fc20.x86_64 nip2-0:7.38.1-2.fc21.x86_64 perl-GD-SecurityImage-0:1.72-4.fc20.noarch perl-Image-Size-0:3.232-3.fc20.noarch perl-Panotools-Script-0:0.28-1.fc20.noarch perl-WebService-Rajce-0:1.13.0930-3.fc20.noarch pfstools-0:1.8.5-16.fc21.x86_64 pfstools-imgmagick-0:1.8.5-16.fc21.x86_64 phatch-cli-0:0.2.7-14.fc21.noarch RabbIT-0:4.11-3.fc21.noarch recoverjpeg-0:2.2.3-2.fc20.x86_64 rss-glx-0:0.9.1.p-20.fc21.x86_64 ruby-RMagick-0:2.13.1-13.fc21.x86_64 shutter-0:0.90.1-1.fc21.noarch synfig-0:0.64.1-3.fc21.i686 synfig-0:0.64.1-3.fc21.x86_64 vips-0:7.38.5-2.fc21.i686 vips-0:7.38.5-2.fc21.x86_64 vips-devel-0:7.38.5-2.fc21.i686 vips-devel-0:7.38.5-2.fc21.x86_64 vips-python-0:7.38.5-2.fc21.x86_64 vips-tools-0:7.38.5-2.fc21.x86_64 w3m-img-0:0.5.3-14.fc21.x86_64 -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- 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: trimming down Fedora installed size
On Wed, 2014-04-09 at 08:39 -0400, Matthew Miller wrote: On Wed, Apr 09, 2014 at 07:50:37AM -0400, Stephen Gallagher wrote: I would say in the long run we should be working towards creating separated locale,doc,man packages Hmm, I wonder if RPM 4.12 would allow us to do this with weak dependencies? Perhaps something like having a metapackage on the system for docs and one for each language. Then we could break up the doc and language packages into sub-packages that are installed conditionally on the presence of that metapackage on the system. Of course, I think there would still be work needed in RPM to support adding a language later, but maybe we could solve that with special tooling or a yum plugin. +1 to all of this. Needs: * rpm macros, possibly other RPM work * packaging guidelines * yum/dnf tooling * a plan for realistically getting from where we are now to where we want to be * executing on that plan From the desktop/workstation perspective, here are a few things I would like to see if we decide to work on this: Support for a new locale is more or less like a 'system extension' for the OS. It would be good to define clear rules for what it means to provide a subpackage that becomes part of this system extension. In an ideal world, this could even be automatic and pattern-based (e.g. if you install anything into /usr/lib64/gstreamer-1.0, you are providing a 'codec' extension, and all the files below that directory belong to it). To present this in the UI, we need to know the available 'extension points' (either a fixed list, or a way to enumerate them), as well as the installed and available extensions for each, including suitable metadata (name+short description at least). -- 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: trimming down Fedora installed size
On 04/09/2014 02:31 PM, Ralf Corsepius wrote: So, I'd question the usefulness of not installing man-page It's more about getting to the point of being able to remove them and or have the option not to install them. Whether they should or should not be installed by default depends on people personal preferences and SIG's uses cases/target audience Embedded + cloud + containers probably want to remove them Server + desktop probably wants to keep them And to you 89m is little, to me it's much so fourth and so on... 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: trimming down Fedora installed size
On Wed, Apr 9, 2014 at 10:31 AM, Ralf Corsepius rc040...@freenet.de wrote: So, I'd question the usefulness of not installing man-pages, because their sizes are comparatively small on today's disk-scales, e.g. on my primary system: # du -sh /usr/share/man 89M /usr/share/man That's almost neglibile in comparision to the overall size of the installation. Disk usage of many small files can be disproportionate. On some platforms -- embedded, lightweight VMs, the savings are sometimes important. They sure were on XO-1 not that long ago, and I'm not sure what I'd do with docs and manages in an on-demand VMs. Having said that, exclude_docs and install_langs have worked well for OLPC and work reasonably well for lightweight VMs too. I am not arguing for big changes here. The plans outlined seem doable, but reworking the whole distro into doc packages to fix something that already works /reasonably well/ seems... not cost effective. There are some limited use cases that aren't ideal now with install_lang and exclude_docs. For example, installing missing docs or langs -- for all or some packages. But that seems like it could be solved by a script that drives rpm to do just that. cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: trimming down Fedora installed size
may be easier to just rewrite the mandb for it rather than create extra confusion of two man pages Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine On Wed, Apr 9, 2014 at 10:49 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 04/09/2014 02:31 PM, Ralf Corsepius wrote: So, I'd question the usefulness of not installing man-page It's more about getting to the point of being able to remove them and or have the option not to install them. Whether they should or should not be installed by default depends on people personal preferences and SIG's uses cases/target audience Embedded + cloud + containers probably want to remove them Server + desktop probably wants to keep them And to you 89m is little, to me it's much so fourth and so on... 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 -- 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: trimming down Fedora installed size
On Wed, Apr 9, 2014 at 10:49 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: It's more about getting to the point of being able to remove them and or have the option not to install them. See my other email on this thread. Following on what I wrote there, instead of reworking all the packages across the distro, a script can be written to achieve the equivalent of exclude_docs. Embedded + cloud + containers probably want to remove them Those already work right with exclude_docs -- I have been a primary user of both use cases (OLPC as embedded, cloud/containers now). cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: trimming down Fedora installed size
On Wed, Apr 09, 2014 at 02:49:56PM +, Jóhann B. Guðmundsson wrote: So, I'd question the usefulness of not installing man-page It's more about getting to the point of being able to remove them and or have the option not to install them. Since man pages are marked as %doc, you can use %_excludedocs macro: $ grep -B2 excludedoc /usr/lib/rpm/macros # Boolean (i.e. 1 == yes, 0 == no) that controls whether files # marked as %doc should be installed. #%_excludedocs And also: $ grep -B3 install_langs /usr/lib/rpm/macros # A colon separated list of desired locales to be installed; # all means install all locale specific files. # %_install_langs all -- Regards,-- Sir Raorn. --- https://plus.google.com/+AlexeyFroloff pgpSHNhRvZ_wA.pgp 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
Re: trimming down Fedora installed size
On 04/09/2014 02:59 PM, Alexey I. Froloff wrote: On Wed, Apr 09, 2014 at 02:49:56PM +, Jóhann B. Guðmundsson wrote: So, I'd question the usefulness of not installing man-page It's more about getting to the point of being able to remove them and or have the option not to install them. Since man pages are marked as %doc, you can use %_excludedocs macro: $ grep -B2 excludedoc /usr/lib/rpm/macros # Boolean (i.e. 1 == yes, 0 == no) that controls whether files # marked as %doc should be installed. #%_excludedocs And also: $ grep -B3 install_langs /usr/lib/rpm/macros # A colon separated list of desired locales to be installed; # all means install all locale specific files. # %_install_langs all Does not solve the problem of dependency like for example if we want to get rid of man-db and it's dependency's so forth and so on. The only way we can move forward is *fixing* our dependency tree. It is a mess to say the least 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: trimming down Fedora installed size
On 04/09/2014 04:53 PM, Matthias Clasen wrote: From the desktop/workstation perspective, here are a few things I would like to see if we decide to work on this: Support for a new locale is more or less like a 'system extension' for the OS. It would be good to define clear rules for what it means to provide a subpackage that becomes part of this system extension. Yes, but my guess this is not very complicated. Natural languages are pretty straight forward. All other 'system extension' will basically come with their own description. We just have to make sure that the description as shown to the user is not completely ignored by the packages using it. In an ideal world, this could even be automatic and pattern-based (e.g. if you install anything into /usr/lib64/gstreamer-1.0, you are providing a 'codec' extension, and all the files below that directory belong to it). *cough* *cough* To present this in the UI, we need to know the available 'extension points' (either a fixed list, or a way to enumerate them), as well as the installed and available extensions for each, including suitable metadata (name+short description at least). We need the rethink the whole packaging UI anyway. Comps still has all its known problems. SoftwareCenter has its own, very special view on the packages, and no one has a clue how to make use of the weak weak dependencies (which are not completely unlike optional packages in comps). So making the number of installed and available packages more manageable is one of the next big things that need to be done after the basic infrastructure is in place. Florian -- 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: trimming down Fedora installed size
On Wed, Apr 09, 2014 at 03:00:24PM +, Jóhann B. Guðmundsson wrote: Does not solve the problem of dependency like for example if we want to get rid of man-db and it's dependency's so forth and so on. Well, it does solve the wasted disk space problem. The only way we can move forward is *fixing* our dependency tree. It is a mess to say the least I second that... -- Regards,-- Sir Raorn. --- https://plus.google.com/+AlexeyFroloff pgp9aIjMXWF1r.pgp 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
Re: trimming down Fedora installed size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 08:42 AM, Florian Festi wrote: On 04/09/2014 01:50 PM, Stephen Gallagher wrote: On 04/09/2014 07:23 AM, Jóhann B. Guðmundsson wrote: On 04/09/2014 07:33 AM, Marius A wrote: Are there any other disk space saving tips? Users should not have to result doing disk saving tips. I would say in the long run we should be working towards creating separated locale,doc,man packages Hmm, I wonder if RPM 4.12 would allow us to do this with weak dependencies? Perhaps something like having a metapackage on the system for docs and one for each language. Then we could break up the doc and language packages into sub-packages that are installed conditionally on the presence of that metapackage on the system. Of course, I think there would still be work needed in RPM to support adding a language later, but maybe we could solve that with special tooling or a yum plugin. Yes, this is one of the reasons we go for more expressive relations in RPM. You already very closely describe what I have in mind. There are basically two possible ways of making the distribution more flexible in the future: 1) Normal weak dependencies. In a normal install all the docs (and all other bells and whistles) get installed by default. You can remove/deselect packages which are pulled in by weak dependencies. You can even switch off all weak dependencies to only get the core packages. 2) Rich dependencies. Doc and language packages can be build as bridging packages that are only installed if two other packages are present. This can be done by adding e.g. Recommends: foo-langpack-hu if langsupport-hu to package foo or Supplements: foo and langsupport-hu This construct would be extremely valuable to the SSSD as well: %package -n client Recommends: sssd-client.i686 if glibc.i686 to the foo-langpack-hu package. Similar things can be done for docs or any other set of packages that should be controlled by a single switch package. The nice thing about this is that no additional tooling is needed. Installing foo will automatically install the lang packs for all installed languages and installing a new langsupport package will install the langpacks for all installed packages. The second half of this statement is the exciting part to me. It's pretty easy to install a language at package-install time, but in order to add the language subpackages for all installed packages on the system if the new langsupport package comes in will mean re-processing all of the dependencies on the installed packages. Probably very slow, but certainly valuable. The plan is to get all pieces for 1) into F21. So it could already be used for F22. I will try to get 2) ready in this time frame, too, but the bets are still open. This would be fantastic, now we just need the FPC to agree. Might be worth filing an FPC bug or two now for them to debate before pushing too hard here. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNFZeQACgkQeiVVYja6o6Nv7ACgom5qypruoq68WLtnFqLydelm ykkAn21vSW53VnMypMNz+amO9AaTfKrl =CKpf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Framework for Server Role Deployment
On Wed, Apr 9, 2014 at 2:45 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 06:02 AM, drago01 wrote: On Tue, Apr 8, 2014 at 3:08 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 07:22 AM, drago01 wrote: On Tue, Apr 8, 2014 at 12:53 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Framework for Server Role Deployment = https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment Change owner(s): Miloslav Trmač mitr AT volny DOT cz, Fedora Server Working Group server AT lists DOT fedoraproject DOT org Responsible WG: Server A new D-Bus service, and associated command-line tools, to deploy and manage Server Roles. == Detailed Description == A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them. Appropriate functionality will also be exposed as a command-line utility. == Scope == * Proposal owners: Write, document, package and test the D-Bus API. * Other developers: Possibly use the framework for development of new server roles. * Release engineering: Nothing * Policies and guidelines: Nothing Contingency mechanism: Do not ship the Server product with Fedora 21. What? That's not a contingency plan thats a nuke clause .. we could simply not ship any roles and add it in f21 (given that we don't have many roles to begin with). Yes, it's a nuke clause. This Change Proposal is a blocker for shipping the Fedora Server. Without completing this Change, Fedora Server is not meaningful. I am not sure I agree with that ... you can still install the server packages you need which probably is necessary even with this feature because ... Sorry, you misunderstand (and I wasn't terribly clear). Fedora is still useful as a server, but the Fedora Server *product* has no meaningful differentiation from Fedora with server packages without this. So if we don't deliver this, we may as well not ship specialized install media. No my point was rather this framework will be only useful for a very limited set of cases (domain controller and database as you stated below), so for anyone having a different type of server he/she will have to install packages by hand anyway. So if this feature its not done it will only affect two specific usecases so there is no need for a nuke clause if its not done just get it into F22 (with hopefully a larger set of roles). Which roles are we going to ship with F21? The two we're working for in F21 are Domain Controller (powered by FreeIPA) and Database Server (powered by PostgreSQL). Database server and ? This feature is not meaningful if common roles are not present. Like file server, web server, application server, could / virt server etc. Well, a complete Domain Controller is certainly meaningful. I didn't say it isn't. Also, please understand that the focus of Roles is to provide turn-key *infrastructure*, not abitrary applications. So we looked at what we could provide that would benefit the most potential use-cases. We acknowledged that nearly any application that an end-user would want to build would need access to a database server and that in real-world deployments, databases are generally kept distinctly separate from the server (or VM) providing the application. So it makes sense to provide this as a Serevr Role with easy set-up in order to support all the other things people want to do. Also if I enable / install / activate the database server role which database do I get? We selected PostgreSQL by overwhelming majority vote among the Server WG. A MariaDB Role may come in the future, but we're only building one right now. Well the times where database means sql database are over (it depends on the application(s) the user is going to use). What if my applications need to talk to another database? Same for application server etc. If your applications cannot use PostgreSQL, then you can always manually set up a different database. You just lose access to the simplicity of doing so via the role mechanism. This is additive; it doesn't replace the traditional way of doing things, but for the common use-cases we support it will make them vastly easier. Sure I am not saying its not useful its just very limited currently (lots of setups will have to use traditional methods anyway) and thus does not warrant to not ship a server product at all if it is not done. -- 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: trimming down Fedora installed size
On 04/09/2014 05:23 PM, Stephen Gallagher wrote: This construct would be extremely valuable to the SSSD as well: %package -n client Recommends: sssd-client.i686 if glibc.i686 That's not exactly by accident... It's pretty easy to install a language at package-install time, but in order to add the language subpackages for all installed packages on the system if the new langsupport package comes in will mean re-processing all of the dependencies on the installed packages. Probably very slow, but certainly valuable. Well, there is a reason why Fedora is moving to a new dependency solver. I am pretty optimistic about performance. The plan is to get all pieces for 1) into F21. So it could already be used for F22. I will try to get 2) ready in this time frame, too, but the bets are still open. This would be fantastic, now we just need the FPC to agree. Might be worth filing an FPC bug or two now for them to debate before pushing too hard here. For now there is just https://fedoraproject.org/wiki/Changes/RPM-4.12 I will talk to the FPC as soon as the parts are all in place. Be aware that it is not enough to just implement the stuff. It needs to be tested and to make its way to the builders. Even with a hurry things need quite some time in RPM land. Florian -- 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 1085905] New: perl-Catalyst-Model-DBIC-Schema-0.61-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085905 Bug ID: 1085905 Summary: perl-Catalyst-Model-DBIC-Schema-0.61-1.fc21 FTBFS Product: Fedora Version: 20 Component: perl-Catalyst-Model-DBIC-Schema Assignee: iarn...@gmail.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, mmasl...@redhat.com, perl-de...@lists.fedoraproject.org perl-Catalyst-Model-DBIC-Schema-0.61-1.fc21 fails to build in F21 and F20 due to tests: t/07connect_info.t .. ok # Failed test 'constraint loader arg as string' # at t/08helper.t line 79. # got: 'qr/^(foo|bar)$/' # expected: 'qr/(?^:^(foo|bar)$)/' # Looks like you failed 1 test of 45. t/08helper.t Dubious, test returned 1 (wstat 256, 0x100) Failed 1/45 subtests -- 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=llRWbwn7Fxa=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: F21 System Wide Change: Framework for Server Role Deployment
On Wed, 2014-04-09 at 08:45 -0400, Stephen Gallagher wrote: On 04/09/2014 06:02 AM, drago01 wrote: On Tue, Apr 8, 2014 at 3:08 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 07:22 AM, drago01 wrote: On Tue, Apr 8, 2014 at 12:53 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Framework for Server Role Deployment = https://fedoraproject.org/wiki/Changes/FrameworkForServerRoleDeployment [snip] Which roles are we going to ship with F21? The two we're working for in F21 are Domain Controller (powered by FreeIPA) and Database Server (powered by PostgreSQL). Thanks. I've added links to the Change pages for those roles to the *discussion* page of the above page, but IMHO the page itself should have such links. I held fire on doing that since I think it merits a more substantial rewrite of the Change page. I think having concrete examples of Roles would make the idea less abstract, and would thus improve the above Change page. BTW, do the roles themselves have pages on the wiki beyond their individual Change pages? [snip] Hope this is helpful 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: trimming down Fedora installed size
On 04/09/2014 04:49 PM, Jóhann B. Guðmundsson wrote: On 04/09/2014 02:31 PM, Ralf Corsepius wrote: So, I'd question the usefulness of not installing man-page It's more about getting to the point of being able to remove them and or have the option not to install them. Well, rpm-wise, all files marked %doc are considered to be optional. I.e. rm -rf /usr/share/doc/* etc. are supposed to work = rpm issuing warnings/errors after %doc-files removals should be considered to be packaging bugs (I don't have a case at hand, but know there are such bugs). Whether they should or should not be installed by default depends on people personal preferences and SIG's uses cases/target audience Embedded + cloud + containers probably want to remove them Server + desktop probably wants to keep them And to you 89m is little, to me it's much so fourth and so on... C'mon, we have packages whose install-sizes are measured in 10ths and 100s of MBs ... and we have other dirs which can easily grow beyond any limits. Same system as before: # du -sh /var/cache /usr 13G /var/cache 8.8G/usr 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
[fedocal] The end of the fedora-meeting* calendars
Dear all, Today, Ralph and I braced ourselves and went onto the fedora-meeting, fedora-meeting-1 and fedora-meeting-2 calendars on fedocal and moved all the meetings in there into other calendars. With the introduction of the meeting location, having a dedicated calendar for the irc chans does not make sense anymore, the calendar should be organized by interest/team and the location field should provide the information about where the meeting is being held. Also please note *not* to use the format `#irc-chan` in the meeting location, otherwise the `#` sign ends-up in the url when displaying the agenda of a location [1] and that leads to weird issue as `#` is a special character for http. I updated all the locations that were using `#fedora-meeting` to use `fedora-meet...@irc.freenode.net` and I will check on this every once in a while. Note that to use the new .nextmeeting command [2] on irc, you will need to have the location set properly on fedocal We have tried to be as careful as possible, so all your meetings should be there, but in case we missed something do not hesitate to let us know, either here or on #fedora-admin. Thanks, Ralph Pierre [1] https://apps.fedoraproject.org/calendar/locations/ and https://apps.fedoraproject.org/calendar/location/fedora-meeting%40irc.freenode.net/ [2] http://threebean.org/blog/new-zodbot-command-nextmeeting/ -- 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: trimming down Fedora installed size
On 04/09/2014 04:14 PM, Ralf Corsepius wrote: C'mon, we have packages whose install-sizes are measured in 10ths and 100s of MBs ... and we have other dirs which can easily grow beyond any limits. I was refering to it being in the eye of the beholder so to speak but as I see it we need to start working towards shrinking the core/base of the distribution to the size of posted stamp compare to the bloat we are now, to keep us agile enough and relevant for the next generation of tinkerers embedded as well as to be able to serve the cloud and container market. In doing so we need to fix dependency and drop or make it optional to add or remove various components ( agile ) as well as the legacy cruff which everybody hold so dear to, in the process. copr presents us with the ability to mapping out and make such drastic changes without having to cause disruption to Fedora in general and people work flows until things have been properly fixed and prepared to do so. Something we did not have when we decide to replace the distribution init system. 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
Schedule for Thursday's FPC Meeting (2014-04-10 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-04-10 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-04-10 09:00 Thu US/Pacific PDT 2014-04-10 12:00 Thu US/Eastern EDT 2014-04-10 16:00 Thu UTC - 2014-04-10 17:00 Thu Europe/London BST 2014-04-10 18:00 Thu Europe/Paris CEST 2014-04-10 18:00 Thu Europe/Berlin CEST 2014-04-10 21:30 Thu Asia/Calcutta IST --new day-- 2014-04-11 00:00 Fri Asia/Singapore SGT 2014-04-11 00:00 Fri Asia/Hong_Kong HKT 2014-04-11 01:00 Fri Asia/Tokyo JST 2014-04-11 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #400 Exception for bundled library FoX in exciting .fpc 400 https://fedorahosted.org/fpc/ticket/400 (remaining votes needed) #topic #407 Bundled lib exception request (copylibs) for sha1 bundled with apt-cacher-ng .fpc 407 https://fedorahosted.org/fpc/ticket/407 (remaining votes needed) #topic #408 Temporary jquery bundling exception for libserialport .fpc 408 https://fedorahosted.org/fpc/ticket/408 = New business = #topic #411 proposal: migrate license files to %license instead of %doc .fpc 411 https://fedorahosted.org/fpc/ticket/411 #topic #413 Bundling exception request for nodejs-shelljs .fpc 413 https://fedorahosted.org/fpc/ticket/413 #topic #414 Please consider requiring AppData for all desktop applications .fpc 414 https://fedorahosted.org/fpc/ticket/414 #topic #415 Temporary Javascript bundling exception for Ambari dependencies .fpc 415 https://fedorahosted.org/fpc/ticket/415 #topic #416 Temporary bundling exception for ipython .fpc 416 https://fedorahosted.org/fpc/ticket/416 #topic #417 sha2 library bundling in clementine .fpc 417 https://fedorahosted.org/fpc/ticket/417 #topic #418 Bundling exception for reaver-wps .fpc 418 https://fedorahosted.org/fpc/ticket/418 #topic #419 ruby193 in SCL .fpc 419 https://fedorahosted.org/fpc/ticket/419 #topic #420 PHP Guidelines change - numeric prefix .fpc 420 https://fedorahosted.org/fpc/ticket/420 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: Schedule for Thursday's FPC Meeting (2014-04-10 16:00 UTC)
James Antill (ja...@fedoraproject.org) said: For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. The systemd timer guideline came up at FESCo today, and we had concerns over the changes from MUST to SHOULD in the proposed guidelines - FESCo would like them to remain as MUST. I'd like to discuss that, and any concerns FPC might have with that, tomorrow with FPC if at all possible. Bill -- 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: trimming down Fedora installed size
Florian Festi (ffe...@redhat.com) said: 1) Normal weak dependencies. In a normal install all the docs (and all other bells and whistles) get installed by default. You can remove/deselect packages which are pulled in by weak dependencies. You can even switch off all weak dependencies to only get the core packages. 2) Rich dependencies. Doc and language packages can be build as bridging packages that are only installed if two other packages are present. This can be done by adding e.g. Recommends: foo-langpack-hu if langsupport-hu to package foo or Supplements: foo and langsupport-hu to the foo-langpack-hu package. Similar things can be done for docs or any other set of packages that should be controlled by a single switch package. Given the number of packages that ship localization, this seems like it would have a pretty dramatic effect on metadata size. Is this a concern? Bill -- 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: Schedule for Thursday's FPC Meeting (2014-04-10 16:00 UTC)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 08:04 PM, James Antill wrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-04-10 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #400 Exception for bundled library FoX in exciting .fpc 400 https://fedorahosted.org/fpc/ticket/400 (remaining votes needed) #topic #407 Bundled lib exception request (copylibs) for sha1 bundled with apt-cacher-ng .fpc 407 https://fedorahosted.org/fpc/ticket/407 (remaining votes needed) #topic #408 Temporary jquery bundling exception for libserialport .fpc 408 https://fedorahosted.org/fpc/ticket/408 = New business = #topic #411 proposal: migrate license files to %license instead of %doc .fpc 411 https://fedorahosted.org/fpc/ticket/411 #topic #413 Bundling exception request for nodejs-shelljs .fpc 413 https://fedorahosted.org/fpc/ticket/413 #topic #414 Please consider requiring AppData for all desktop applications .fpc 414 https://fedorahosted.org/fpc/ticket/414 #topic #415 Temporary Javascript bundling exception for Ambari dependencies .fpc 415 https://fedorahosted.org/fpc/ticket/415 #topic #416 Temporary bundling exception for ipython .fpc 416 https://fedorahosted.org/fpc/ticket/416 #topic #417 sha2 library bundling in clementine .fpc 417 https://fedorahosted.org/fpc/ticket/417 #topic #418 Bundling exception for reaver-wps .fpc 418 https://fedorahosted.org/fpc/ticket/418 #topic #419 ruby193 in SCL .fpc 419 https://fedorahosted.org/fpc/ticket/419 #topic #420 PHP Guidelines change - numeric prefix .fpc 420 https://fedorahosted.org/fpc/ticket/420 I don't see the topic about bundled files in Icecat ( https://fedorahosted.org/fpc/ticket/391). It's still pending. - -- Antonio Trande mailto: sagitterATfedoraproject.org http://www.fedoraos.worpress.com https://fedoraproject.org/wiki/User:Sagitter GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTRZVfAAoJED2vIvfUANbEBRAQAKEbObG6HmZ/Xj5wAyiWj0bQ +KU+sUJgeEyZSc2OZhs9CXUbVjauzeB0eZm8SSfJchbW6pcziHjSna9GxJbqGXQb FWxEta/U0o10h2kXP4rQkb4iMzOOMSnAsKIvqynvpteSrg5lvnU/mUm/wvzCjjow S8Fx9oWog77+vUUCNEIvOws7g3x8Bh6ym4++Q48tjof3eXJR4Z9t2sRnutFPTlhM QhEr55J+wf6gLdgsPAwqWA2LZLK28j3HZ78yaAdxbVNfiCoq07gEgKU84LHZRsyl PqMPTH/xUrvbX+9mulXczFPaliV1lNjOwAzxkb5WHiyLlwUl/R6VqDPHja3gzf5H ba9g+SzWk9Ash5nJdBFC3m6WzXAPUcOVKA0pQyHgBzSES3Aup7y4F3+qmcdvvfHO +YDLL5cIPpJSbuLJqq0D8RmGauRvpvGQBMFrb1+YyFN3Nb2KMerOxIYEEkWC5WOT +9tEq3HvYMA0MHDGv4Nlaevp++tFKEiwUudu+H4T1Mfg0d/55JWol+sbBZnHQ9Pm TEiv/QqBkllotM0Uh3UOWF2QBDj4Foz6ahIXdsl54Uk6PfbBvnTGcH6DpiCf8fQF mW590wlF3KPejPds3AbN2kFLs6W5mNtLzL8/GM8IycgLWm6x3AuLLBMBRzQABejl T5OvlECvQBth0r+Byb8g =1GhI -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: Reinstalling the bootloader
On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy li...@colorremedies.com wrote: You need to install or reinstall grub2-efi and shim packages. Aha, a correct answer! Thanks! Based on this hint, I think I figured it out. I updated the wiki accordingly. Can you take a quick look at: https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_systems I can't fix it because any attempt to change my efi variables results in an OOPS. I can't report the OOPS with abrt because of a correct but inconsequential kernel taint due to #906568, which is probably fixed in 3.14. So I was going to wait for the 3.14 rebase or perhaps boot a custom kernel to see what helps. I haven't had time for that yet. Make sure the firmware is up to date. And if with 3.14 and current firmware you still get an oops when modifying NVRAM entries you'll want to file a bug against the kernel. If it were me I'd file both on kernel.org and redhat.com bugzillas with the proper cross-referencing. It may still end up being a firmware problem that the kernel folks can't do anything about, but to have a chance of it being fixed kernel side requires a bug 2. Do you have a /boot/efi/EFI/fedora/grub.cfg ? No. But I have a /boot/efi/EFI/redhat/grub.conf, attached. /etc/grub.conf is a symlink to it. That's what grub legacy EFI used. I forget if fedup upgrades grub on UEFI systems. It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed. Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg. https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957 or, even better, if anaconda's bootloader installation process were factored out into a command I could run. I don't understand what this means. Being able to do: $ sudo fedora-configure-bootloader would be awesome. It would probably have to take some command line arguments. --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: Schedule for Thursday's FPC Meeting (2014-04-10 16:00 UTC)
On Wed, 2014-04-09 at 20:45 +0200, Antonio Trande wrote: I don't see the topic about bundled files in Icecat ( https://fedorahosted.org/fpc/ticket/391). It's still pending. AFAIK it's not, if you look at the log from the last meeting: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-04-03/fpc.2014-04-03-16.02.log.html ...this happened at the end of the #391 ticket: 17:34:07 abadger1999 Proposal: firefox has a bundling exception since it has an active security team tracking issues in their codebase. icecat has an exception since it is a fork of firefox that closely tracks firefox's changes. 17:34:11 abadger1999 +1 17:34:32 RemiFedora +1 17:34:36 SmootherFrOgZ +1 17:34:43 geppetto +1 17:41:09 limburgher +1 ...it didn't get an #info log, but and writeups will be a little backed up due to PyCon ... but AFAIK it's all dealt with. If you have any other questions etc. feel free to drop by tomorrow. -- 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: trimming down Fedora installed size
On Wed, 2014-04-09 at 12:37 +0300, Ville Skyttä wrote: On Wed, Apr 9, 2014 at 10:33 AM, Marius A marius1...@gmail.com wrote: 1. remove /usr/share/docs Try this in /etc/rpm/macros.whatever: %_excludedocs 1 For recent yum it's significantly better to do: yum fs filter nodocs Try this in /etc/rpm/macros.whatever: %_install_langs en Dito. to get rid of extra languages by: yum fs filter langs en ...then you can yum fs refilter / yum fs refilter-cleanup. It's possible that these settings break some things such as scriptlets that do not take missing files into account, but at least they're cleaner attempts than simply deleting installed files/dirs. This can still be true though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Framework for Server Role Deployment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 05:54 AM, Stephen Gallagher wrote: On Apr 8, 2014, at 9:48 PM, William Brown will...@firstyear.id.au mailto:will...@firstyear.id.au wrote: == Detailed Description == A new D-Bus service will be made available, exposing available server roles, making it possible to deploy, configure and manage them. Appropriate functionality will also be exposed as a command-line utility. What does it mean to deploy, configure, and manage a server role? Nothing and everything fits this whole description. Installation, setup of mandatory data, running of the necessary services, opening of the necessary ports, easy view of overall health of the services and gathering of backup sets. I'd like a bit more about this, especially the opening of ports (What about ip ranges?) and the gathering of backup sets and what that implies or how it's triggered. What additionally, counts as a server role in this case? Or are these not completely filled out yet? IE a network router is certainly a server role, but does it come under this case? Most of these questions are answered here: https://fedoraproject.org/wiki/Server/Product_Requirements_Document and many of the implementation details have been discussed on the ser...@lists.fp.o mailto:ser...@lists.fp.o, but I certainly agree that we need to gather those details on a wiki page and link that and the PRD from this Change Proposal. I will look into doing this today. I've made some changes to the Detailed Description and Documentation sections of the Change proposal to link to relevant information. Some of the detailed pieces (like the API design) are still being worked out and currently have no design page. I hope to have that complete in two weeks. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNFp1YACgkQeiVVYja6o6PSmACgpOha+nKmoali++ZxdxbaBeP0 gCkAoIzU8xc+ZqdvmV+09o7ucCjgXgYn =o7S0 -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: trimming down Fedora installed size
I would like to see logic like this:
manpage files don't get installed unless/until:
1) packagename-manpages is requested to be installed by the user. that
package would require the 'man' package.
OR
2) package is installed AND man is installed.
Don't wan't the manpages taking up disk space? remove the 'man' package
and all manpages disappear.
Don't use en_US and don't want to waste space on that either, remove the
'localization-en_US' package and its corresponding localizations of all
installed packages will dispapear too.
Localization could work the same way. Once a package' localization cruft
is large enough to merit the work, the packager would split it out into
${packagename}-en_US packages for each localization. Distro would maintain
an essentially empty package called localization-en_US, etc for each
localization. Then when you install a localized package, you get
${packagename}-en_US localization-en_us installed, and if you have more
than one localization package installed, you get the corresponding
localized subpackages of ${package}.
On Wed, Apr 9, 2014 at 2:33 AM, Marius A marius1...@gmail.com wrote:
Hi there,
I've been struggling keeping a fedora 20 install on a small SSD, with
6gb / partition (/home is separate).
Besides removing packages, I also found this useful:
1. remove /usr/share/docs
2. remove /usr/share/locale/* (all except en and en_US)
3. cleanup /var/log/journal, which seems it's not automatically rotated
While this saves space, it also results in package upgrade warnings due to
missing files.
Are there any other disk space saving tips?
What do you think about excluding docs by default in Fedora packages?
And for docs either go online, or have a command to install/sync docs for
all installed packages? (similar to ruby or npm packages install, not using
rpm packages)
I think less than 0.1% of users ever look into /usr/share/doc, but I don't
have any data to back this up.
As more folks switch to SSDs, it would benefit both for disk space saving
and wearing to have less space occupied by default.
Thanks
--
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: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 02.04.14 09:12, quickbooks office (quickbooks.off...@gmail.com) wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? This sounds entirely backwards, and I'd instead vote for removing securetty from the PAM stacks we ship altogether. The concept is outdated. It was useful in a time where the primary way to access a server was via physically attached TTY devices. But that time is mostly over... Nowadays the device names exposed by the kernel tend to be dynamically assigned, they should not be assumed stable (with one exeption, classic UART 16650 serial ports). Stable paths for these devices we add in via symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you might know from disk devices. Now, the securetty logic is unable to verify things using these symlinks, hence the entire concept is flawed. It will use an unsteable device name instead, making it mostly useless in hotplug scenarios. securetty is particularly annoying when we use containers. Tools like machinectl login will dynamically spawn a getty for you on a pts device in the container, but since pts is not listed in securetty you cannot log in as root by default. And you cannot event add a wildcard match of pts/* to it, to make this work nicely. Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: trimming down Fedora installed size
On Wed, Apr 09, 2014 at 03:57:27PM -0400, James Antill wrote: For recent yum it's significantly better to do: yum fs filter nodocs Dito. to get rid of extra languages by: yum fs filter langs en ...then you can yum fs refilter / yum fs refilter-cleanup. So -- if the host is originally installed with anaconda's kickstart options for nodocs and language selection, will `yum fs refilter` still work? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: trimming down Fedora installed size
Am 09.04.2014 22:05, schrieb Billy Crook: I would like to see logic like this: manpage files don't get installed unless/until: 1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package. OR 2) package is installed AND man is installed. Don't wan't the manpages taking up disk space? remove the 'man' package and all manpages disappear. Don't use en_US and don't want to waste space on that either, remove the 'localization-en_US' package and its corresponding localizations of all installed packages will dispapear too packages i build at my own have package-manpages for any man/doc parts on all the servers i maintain they are not installed it's enough to have them on *one* central admin server 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: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: trimming down Fedora installed size
On Wed, 2014-04-09 at 10:54 -0400, Martin Langhoff wrote: There are some limited use cases that aren't ideal now with install_lang and exclude_docs. For example, installing missing docs or langs -- for all or some packages. But that seems like it could be solved by a script that drives rpm to do just that. While the recent yum fs refilter stuff tries to help here, the big problem is that the exclude-docs/exclude-langs options are transaction wide ... so you can't do an upgrade and have pkg X with docs and pkg Y without. -- 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: trimming down Fedora installed size
On Wed, Apr 9, 2014 at 3:41 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 09.04.2014 22:05, schrieb Billy Crook: I would like to see logic like this: manpage files don't get installed unless/until: 1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package. OR 2) package is installed AND man is installed. Don't wan't the manpages taking up disk space? remove the 'man' package and all manpages disappear. Don't use en_US and don't want to waste space on that either, remove the 'localization-en_US' package and its corresponding localizations of all installed packages will dispapear too packages i build at my own have package-manpages for any man/doc parts on all the servers i maintain they are not installed it's enough to have them on *one* central admin server heck, on my desktop I might end up just yum installing *-manpages to save time later. -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. Yeah, I think that's a decent way forward. AFAIK the securetty thing right now only affects console terminals and telnet logins. Since consoles are all in there, and hardly anybody runs a telnet server (I ran one on a couple of servers at PPOE to handle specific cases, but I wouldn't have had a problem with adding securetty checks if I needed it), it really is a meaningless check. -- 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
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 9 Apr 2014, Chris Adams wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. Yeah, I think that's a decent way forward. AFAIK the securetty thing right now only affects console terminals As long as it does not lock out root from kvm/uml console/serial logins. Paul -- 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: trimming down Fedora installed size
On 04/09/2014 08:42 PM, Bill Nottingham wrote: Given the number of packages that ship localization, this seems like it would have a pretty dramatic effect on metadata size. Is this a concern? Meta data is a concern. But the major part of the meta data is file data and change logs. Everything else is less than 10%. So doubling or even tripling this part won't hurt. The actual issue we have with meta data is that is is downloaded over and over again (for updates). Should we ever get this fixed the growth of meta data is no longer an issue. Florian -- 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: trimming down Fedora installed size
On 04/09/2014 10:05 PM, Billy Crook wrote: I would like to see logic like this: manpage files don't get installed unless/until: 1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package. OR 2) package is installed AND man is installed. In other words, you want to crippled end-user usability to NULL. 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: trimming down Fedora installed size
Am 09.04.2014 23:01, schrieb Billy Crook: On Wed, Apr 9, 2014 at 3:41 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 09.04.2014 22:05, schrieb Billy Crook: I would like to see logic like this: manpage files don't get installed unless/until: 1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package. OR 2) package is installed AND man is installed. Don't wan't the manpages taking up disk space? remove the 'man' package and all manpages disappear. Don't use en_US and don't want to waste space on that either, remove the 'localization-en_US' package and its corresponding localizations of all installed packages will dispapear too packages i build at my own have package-manpages for any man/doc parts on all the servers i maintain they are not installed it's enough to have them on *one* central admin server heck, on my desktop I might end up just yum installing *-manpages to save time later really? compared how often i reinstall a workstation (never) and how often i need a manpage because command --help don't answer the question that is unlikely how many manpages do you have installed and how many of them you ever viewed in the past let say 5 years? escpecially because the goal is to seperate things which does *not* mean they are not installed in most setups - a meta-package postfix can pull postfix-server and postfix-manuals while you can remove the metapackage and postfix-manuals 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: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, Paul Wouters p...@nohats.ca said: On Wed, 9 Apr 2014, Chris Adams wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. Yeah, I think that's a decent way forward. AFAIK the securetty thing right now only affects console terminals As long as it does not lock out root from kvm/uml console/serial logins. The proposal is to remove the securetty thing, which would remove any TTY check. root would be allowed on any TTY by default. -- 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
Re: F21 System Wide Change: Mono 3.4
On 04/09/2014 12:42 PM, Jaroslav Reznik wrote: So yes, FESCo should take it into consideration but I'd like to avoid situation when this Change will be banned solely on not a maintainer. Yes -- I am hoping that someone who understands the Mono stack and has distro-wide commit access would step up and help elsupergomez push this through. The Scope section of the Change as it is right now, basically says that the proposal owners are going to build a new mono package and that's it. Leaving it up to other maintainers to fix up any resulting breakage never ends well; instead I would expect the people pushing for this drive the changes distro wide. And if nobody steps up, might be worth getting elsupergomez commit access to the whole mono stack. Just don't push this to rawhide and hope that broken dependencies and the whole mono stack somehow magically repairs itself :) -- Kalev -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 09.04.14 22:20, Lennart Poettering (mzerq...@0pointer.de) wrote: This sounds entirely backwards, and I'd instead vote for removing securetty from the PAM stacks we ship altogether. The concept is outdated. It was useful in a time where the primary way to access a server was via physically attached TTY devices. But that time is mostly over... Nowadays the device names exposed by the kernel tend to be dynamically assigned, they should not be assumed stable (with one exeption, classic UART 16650 serial ports). Stable paths for these devices we add in via symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you might know from disk devices. Now, the securetty logic is unable to verify things using these symlinks, hence the entire concept is flawed. It will use an unsteable device name instead, making it mostly useless in hotplug scenarios. securetty is particularly annoying when we use containers. Tools like machinectl login will dynamically spawn a getty for you on a pts device in the container, but since pts is not listed in securetty you cannot log in as root by default. And you cannot event add a wildcard match of pts/* to it, to make this work nicely. Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! To clarify this: while I believe dropping securetty from the default PAM config is the right thing to do, I am not vulunteering to do it. But I'd love to see somebody to pick this up! Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Framework for Server Role Deployment
On Tue, Apr 8, 2014 at 7:25 PM, Rob Kearey r...@ningaui.net wrote: This Change, as written, is *extremely* vague, moreso that most other changes that are filed for Fedora. Is it intended to be updated with more information when that becomes available? +1 - What are 'server roles'? Are we just reinventing Ansible/Puppet/et al here? Yeah, why is someone spending time creating a new Fedora-specific configuration management system rather than just shipping an Ansible playbook or a Salt formula or whatever? -- Jeff Ollie -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, Apr 09, 2014 at 11:39:19PM +0200, Lennart Poettering wrote: To clarify this: while I believe dropping securetty from the default PAM config is the right thing to do, I am not vulunteering to do it. But I'd love to see somebody to pick this up! I looked, and I think this is just a change in util-linux package (not the source even; the pam files are packaged as separate sources) + a note in the release notes. It's not referenced in authconfig or anything. I guess maybe we'd also want to remove /etc/securetty to reduce confusion (since the normal semantics are that missing file = nothing blocked), that's in setup. But otherwise, I think it just comes down to filing an RFE and getting the util-linux maintainer on board. Probably best after this change proposal gets to FESCo — at that point, I'll put this forward as a counter-proposal. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: trimming down Fedora installed size
On 04/09/2014 09:12 PM, Ralf Corsepius wrote: On 04/09/2014 10:05 PM, Billy Crook wrote: I would like to see logic like this: manpage files don't get installed unless/until: 1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package. OR 2) package is installed AND man is installed. In other words, you want to crippled end-user usability to NULL. I would not be dwelling to much on the usability topic since we have bigger issues to fry then end-user usability with minimal installation footprint for cloud/containers/servers which can be easily solve with same concept as is behind command-not-found for man-pages as in man-page-not-found and move cloud/container/server administration into the realm of install on demand ( which arguably we should be moving more towards at on the 21 century rather then rely on plethora of installation commands and package names ) and ofcourse we would remove the silliness of having to confirm the installation since I as an administrators have already made the gesture that I need the command or the man page when I write foo or man foo so I should not have to confirm it to. 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: trimming down Fedora installed size
Am 10.04.2014 00:00, schrieb Jóhann B. Guðmundsson: On 04/09/2014 09:12 PM, Ralf Corsepius wrote: On 04/09/2014 10:05 PM, Billy Crook wrote: I would like to see logic like this: manpage files don't get installed unless/until: 1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package. OR 2) package is installed AND man is installed. In other words, you want to crippled end-user usability to NULL. I would not be dwelling to much on the usability topic since we have bigger issues to fry then end-user usability with minimal installation footprint for cloud/containers/servers which can be easily solve with same concept as is behind command-not-found for man-pages as in man-page-not-found and move cloud/container/server administration into the realm of install on demand ( which arguably we should be moving more towards at on the 21 century rather then rely on plethora of installation commands and package names ) and ofcourse we would remove the silliness of having to confirm the installation since I as an administrators have already made the gesture that I need the command or the man page when I write foo or man foo so I should not have to confirm it to no - if i type man whatever and that starts to pull 10 MB packages i stop and think 5 seconds if there is one of my ,ore than 30 machines which have it already 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: trimming down Fedora installed size
On 04/09/2014 10:06 PM, Reindl Harald wrote: no - if i type man whatever and that starts to pull 10 MB packages i stop and think 5 seconds if there is one of my ,ore than 30 machines which have it already That is you If I was concern with that I would have done the thinking ahead of time and simply would not have installed the man-page-not-found package on those ten,hundred or thousand machines... 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
New Copr release
Hi, I just deployed new version of Copr. https://copr.fedoraproject.org/ Changes: * a lot of small bugfixes * each src.rpm have separate task now - you can still submit bunch of src.rpm, but the list of src.rpm are split and each src.rpm is submitted to builders as one task. This means that Monitor and deleting is more predictable. * you can submit src.rpm only to subset of chroots you selected for your project. * when someone request permission on your project, then copr sends you notification via email now. * repo files now have better URL (which ends with .repo suffix), which should make yours wget happy. * new API calls: * call for fulltext searching (this is first step to dnf copr search) * you add additional repos to project via API call now * when submitting src.rpm, then you get list of ids instead of one id. The last change will probably break old 'copr-cli'. When you submit src.rpm it will be sucesfully sent, but then copr-cli query the status of build and in this phase old clients will throw error. It is not fatal, your packages will be build, but you will have to check the status on WebUI. Or upgrade to newer 'copr-cli' which I just sent to updates-testing. I wish you happy building. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Framework for Server Role Deployment
On 10/04/2014 7:50 AM, Jeffrey Ollie wrote: +1 - What are 'server roles'? Are we just reinventing Ansible/Puppet/et al here? Yeah, why is someone spending time creating a new Fedora-specific configuration management system rather than just shipping an Ansible playbook or a Salt formula or whatever? Pretty much this. The world has enough reinvented wheels as it is. I'd like to see a clear use case and implementation example without handwaving about dbus and so on. -- Rob K -- 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: ImageMagick 6.8.8-10 in rawhide. Soname change.
Hi!
On Tue, 2014-04-08 at 18:30 +0400, Pavel Alexeev wrote:
Packages for rebuild:
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* |
fgrep -v 'ImageMagick-' | sort -u
As Michael Schwendt already pointed out, your query missed some packages
that need rebuilding (BTW, I noticed this because my package, techne,
was not listed on your list).
Comparing:
repoquery --whatrequires 'libMagick*.so.*' --repoid=rawhide --source
--qf '%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
to:
repoquery --whatrequires 'ImageMagick*' --repoid=rawhide --source --qf
'%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
revealed that the first command catches some packages that the second
command doesn't. These are:
ale
imageinfo
php-magickwand
php-pecl-imagick
psiconv
q
ripright
techne
But it also goes the other way around. The second command catches a lot
more packages that the first one. These are:
a2ps
anyremote
caja-extensions
c-graph
dblatex
epix
fbida
freewrl
fvwm
gallery2
...
Best regards,
Tadej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Mono 3.4
I've contacted the current mono maintainer since last autumn, he had been working on it for a while. And I think he is an expert on this rather than the current proposer. Plus it's my first time to see the proposal from an extraneous people outside. We ought not to bring in extraneous people in trying to find a solution for a s Fedora change IMO... Last time I checked showed that it failed to build on ARM hfp. https://bugzilla.xamarin.com/show_bug.cgi?id=7938 -- 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: ImageMagick 6.8.8-10 in rawhide. Soname change.
On Qui, 2014-04-10 at 01:40 +0200, Tadej Janež wrote:
Hi!
On Tue, 2014-04-08 at 18:30 +0400, Pavel Alexeev wrote:
Packages for rebuild:
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* |
fgrep -v 'ImageMagick-' | sort -u
As Michael Schwendt already pointed out, your query missed some packages
that need rebuilding (BTW, I noticed this because my package, techne,
was not listed on your list).
Comparing:
repoquery --whatrequires 'libMagick*.so.*' --repoid=rawhide --source
--qf '%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
to:
repoquery --whatrequires 'ImageMagick*' --repoid=rawhide --source --qf
'%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
revealed that the first command catches some packages that the second
command doesn't. These are:
ale
imageinfo
php-magickwand
php-pecl-imagick
psiconv
q
ripright
techne
But it also goes the other way around. The second command catches a lot
more packages that the first one. These are:
a2ps
anyremote
caja-extensions
c-graph
dblatex
epix
fbida
freewrl
fvwm
gallery2
...
Hi, I had study this recently (find dependencies for mass rebuilds ) and
found your bug, query rawhide when ImageMagick is already rebuilt,
query now rawhide we got :
repoquery --repoid=rawhide --requires techne | grep libMag
libMagickCore-6.Q16.so.1()(64bit)
libMagickWand-6.Q16.so.1()(64bit)
repoquery --repoid=rawhide --provides ImageMagick-libs | grep libMag
libMagickCore-6.Q16.so.2
libMagickWand-6.Q16.so.2
libMagickCore-6.Q16.so.2()(64bit)
libMagickWand-6.Q16.so.2()(64bit)
So repoquery is correct techne requires
libMagickWand-6.Q16.so.1()(64bit) and ImageMagick provides
libMagickCore-6.Q16.so.2()(64bit) :D
2nd - about your first command which catches some others packages, the
packages are, the packages that requires only ImageMagick and not
ImageMagick-libs , this packages that just requires ImageMagick binaries
don't need to be rebuild. if a package need to use convert , don't need
to be rebuild.
Conclusion the correct repoquery should be made on a repo that have all
packages without broken deps, on F20 for example.
repoquery --whatrequires ImageMagick-libs --source | perl -pe
's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | sort -u
and you got there your package
Best regards,
--
Sérgio M. B.
--
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 1085704] New: tests failing on big endians
https://bugzilla.redhat.com/show_bug.cgi?id=1085704 Bug ID: 1085704 Summary: tests failing on big endians Product: Fedora Version: 20 Component: slic3r Assignee: mhron...@redhat.com Reporter: d...@danny.cz QA Contact: extras...@fedoraproject.org CC: mhron...@redhat.com, perl-devel@lists.fedoraproject.org Blocks: 467765 (ZedoraTracker), 1071880 (PPCTracker) A test is failing in big endian arches like s390(x) and ppc/ppc64 from build.log: ... + cd - /builddir/build/BUILD/Slic3r-1.0.0 + SLIC3R_NO_AUTO=1 + perl Build.PL installdirs=vendor t/angles.t ... ok t/arcs.t . skipped: arcs are currently disabled t/clean_polylines.t .. ok t/clipper.t .. ok t/collinear.t ok t/combineinfill.t ok t/cooling.t .. ok t/custom_gcode.t . ok t/dynamic.t .. skipped: variable-width paths are currently disabled # Failed test 'no missing parts in solid shell when fill_density is 0' # at t/fill.t line 252. # got: '12' # expected: '0' # Looks like you failed 1 test of 42. t/fill.t . Dubious, test returned 1 (wstat 256, 0x100) Failed 1/42 subtests t/gcode.t ok t/geometry.t . ok t/layers.t ... ok t/loops.t skipped: temporarily disabled t/multi.t ok t/perimeters.t ... ok t/polyclip.t . ok t/print.t ok t/retraction.t ... ok t/shells.t ... ok t/skirt_brim.t ... ok t/slice.t skipped: temporarily disabled t/support.t .. ok t/svg.t .. ok t/thin.t . ok t/threads.t .. ok t/vibrationlimit.t ... ok Test Summary Report --- t/fill.t (Wstat: 256 Tests: 42 Failed: 1) Failed test: 42 Non-zero exit status: 1 Files=27, Tests=241, 55 wallclock secs ( 0.09 usr 0.03 sys + 55.73 cusr 0.67 csys = 56.52 CPU) Result: FAIL Some tests failed. Please report the failure to the author! error: Bad exit status from /var/tmp/rpm-tmp.4roGD8 (%check) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.4roGD8 (%check) Child return code was: 1 for full logs please see http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1374201 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1767561 Version-Release number of selected component (if applicable): slic3r-1.0.0-0.3.RC2.fc21 is OK slic3r-1.0.0-0.4.RC3.fc21 is BROKEN, newer are broken too Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=467765 [Bug 467765] Fedora for System z (s390): Bug Tracker https://bugzilla.redhat.com/show_bug.cgi?id=1071880 [Bug 1071880] (PPCTracker) Fedora for PowerPC architectures (ppc,ppc64): Bug Tracker -- 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=9rKa2d72oia=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085230] perl-Starlet-0.21-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085230 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Starlet-0.21-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Starlet-0.21-2.fc20 -- 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=PbWJFfn7y1a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085230] perl-Starlet-0.21-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085230 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Starlet-0.21-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Starlet-0.21-2.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ShkE4aBw7za=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085230] perl-Starlet-0.21-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085230 Ralf Corsepius rc040...@freenet.de changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |RAWHIDE Last Closed||2014-04-09 04:01:36 --- Comment #4 from Ralf Corsepius rc040...@freenet.de --- Fixed in *-0.21-2.fc21. -- 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=QmBIDNxy9ea=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085579] perl-Moose compiled for perl API v5.16.0; fedora perl now at v5.18.0
https://bugzilla.redhat.com/show_bug.cgi?id=1085579 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||ppi...@redhat.com Resolution|--- |NOTABUG Last Closed||2014-04-09 04:18:15 --- Comment #1 from Petr Pisar ppi...@redhat.com --- (In reply to simon.galton from comment #0) Description of problem: perl scripts which use the Moose module fail with the following error: Perl API version v5.16.0 of Moose does not match v5.18.0 at /usr/lib64/perl5/DynaLoader.pm line 213. Version-Release number of selected component (if applicable): perl-5.18.2-289.fc20.x86_64 perl-Moose-2.1005-1.fc20.x86_64 How reproducible: install perl and perl-Moose packages then add use Moose; to the top of any perl script I cannot reproduce it: $ rpm -q perl perl-Moose perl-5.18.2-289.fc20.x86_64 perl-Moose-2.1005-1.fc20.x86_64 $ perl -e 'use Moose' $ echo $? 0 The script will abort with the following complaints: Perl API version v5.16.0 of Moose does not match v5.18.0 at /usr/lib64/perl5/DynaLoader.pm line 213. Compilation failed in require at /usr/local/lib64/perl5/Moose/Exporter.pm line 13. BEGIN failed--compilation aborted at /usr/local/lib64/perl5/Moose/Exporter.pm line 13. Compilation failed in require at /usr/local/lib64/perl5/Moose.pm line 18. BEGIN failed--compilation aborted at /usr/local/lib64/perl5/Moose.pm line 18. If you read the error message carefully, you will see the Moose.pm is loaded from /usr/local. This not a file delivered by Fedora. That's your own local installation. You have to remove the files or reinstall them from cpan to get rebuild against current perl. -- 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=bp7RUSrhqFa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085704] tests failing on big endians
https://bugzilla.redhat.com/show_bug.cgi?id=1085704 --- Comment #1 from Miro Hrončok mhron...@redhat.com --- Honestly, I have no idea how to fix this. I will report this upstream, but chances are, the bug is in some of the used Perl module. Looking at [1] it is clear the test was introduced there and that's the reason why it was OK on RC2. [1] https://github.com/alexrj/Slic3r/compare/1.0.0RC2...1.0.0RC3 -- 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=jg2bQku6N7a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085704] tests failing on big endians
https://bugzilla.redhat.com/show_bug.cgi?id=1085704 --- Comment #2 from Miro Hrončok mhron...@redhat.com --- Reported https://github.com/alexrj/Slic3r/issues/1924 -- 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=AhlVAsuGc0a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1082957] perl does not build with GCC 4.9
https://bugzilla.redhat.com/show_bug.cgi?id=1082957 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This has been worked around by adding -fwrapv to ccflags with these two commits: commit 869747506fd0081f6c7eed149ec6f7adbcc4d5b1 Author: H.Merijn Brand h.m.br...@xs4all.nl Date: Wed Apr 9 11:16:55 2014 +0200 gcc 4.9 by default does some optimizations that break perl (#121505) Patch by Tony Cook commit 00051dd553979bd2a1dee100c324b59ee76a49e7 Author: H.Merijn Brand h.m.br...@xs4all.nl Date: Wed Apr 9 12:31:23 2014 +0200 -fwrapv is broken prior to gcc-4.3 (googled and patched by Zefram) The real code fix is demanded for perl-5.22. -- 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=F8NK5oMCnVa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085336] perl-DBIx-Class-0.08250-2.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085336 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Severity|unspecified |high --- Comment #1 from Petr Pisar ppi...@redhat.com --- This bug prevents from building about 30 other packages (mojomojo and some Catalyst and CGI packages). -- 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=7ExSsIQaMha=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 803340] RFE: update to at least 1.40
https://bugzilla.redhat.com/show_bug.cgi?id=803340 Paul Howarth p...@city-fan.org changed: What|Removed |Added Type|--- |Bug -- 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=f0KsjP3t3qa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 803340] RFE: update to at least 1.40
https://bugzilla.redhat.com/show_bug.cgi?id=803340 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed||2014-04-09 09:29:38 --- Comment #1 from Paul Howarth p...@city-fan.org --- Don't need this any more. -- 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=Mx9zXQTR6Ja=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File DBIx-Class-0.08270.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-DBIx-Class: 4c574ad83a6f7456801e234f78c45f10 DBIx-Class-0.08270.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085336] perl-DBIx-Class-0.08250-2.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085336 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|iarn...@gmail.com |ppi...@redhat.com External Bug ID||CPAN 91947 --- Comment #2 from Petr Pisar ppi...@redhat.com --- The problem was in newer sqlite library. Fixed with upstream commit: commit ed5550d36c5771dfb5492b23127f8af9e38254d4 Author: Peter Rabbitson ribasu...@cpan.org Date: Mon Jan 13 12:49:53 2014 +0100 SQLite changed their exception text again -- 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=cu7OECfHuKa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBIx-Class] Adapt to new sqlite-3.8.2 exception messages
commit 14999c3525ac7993a8db3615087d46445fb5bcc0
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 9 15:42:48 2014 +0200
Adapt to new sqlite-3.8.2 exception messages
...SQLite-changed-their-exception-text-again.patch | 67
perl-DBIx-Class.spec |9 +++-
2 files changed, 75 insertions(+), 1 deletions(-)
---
diff --git a/DBIx-Class-0.08250-SQLite-changed-their-exception-text-again.patch
b/DBIx-Class-0.08250-SQLite-changed-their-exception-text-again.patch
new file mode 100644
index 000..61811ba
--- /dev/null
+++ b/DBIx-Class-0.08250-SQLite-changed-their-exception-text-again.patch
@@ -0,0 +1,67 @@
+From ed5550d36c5771dfb5492b23127f8af9e38254d4 Mon Sep 17 00:00:00 2001
+From: Peter Rabbitson ribasu...@cpan.org
+Date: Mon, 13 Jan 2014 12:49:53 +0100
+Subject: [PATCH] SQLite changed their exception text again
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+
+Ported to 0.08250.
+
+diff --git a/t/multi_create/standard.t b/t/multi_create/standard.t
+index 5a02947..6c1efd8 100644
+--- a/t/multi_create/standard.t
b/t/multi_create/standard.t
+@@ -444,7 +444,11 @@ throws_ok ( sub {
+ #$t-cd($t-new_related('cd', { artist = undef } ) );
+ #$t-{_rel_in_storage} = 0;
+ $t-insert;
+-}, qr/cd.artist may not be NULL/, Exception propogated properly);
++}, qr/DBI Exception.+(?x:
++\QNOT NULL constraint failed: cd.artist\E
++ |
++\Qcd.artist may not be NULL\E
++)/s, Exception propogated properly);
+
+ lives_ok ( sub {
+ $schema-resultset('CD')-create ({
+diff --git a/t/relationship/update_or_create_multi.t
b/t/relationship/update_or_create_multi.t
+index 8710048..c7cce7a 100644
+--- a/t/relationship/update_or_create_multi.t
b/t/relationship/update_or_create_multi.t
+@@ -69,7 +69,12 @@ throws_ok {
+ year = 2020,
+ title = 'the best thing since sliced bread',
+ })
+-} qr/\Qcd.artist may not be NULL/, 'ambiguous find + create failed';
++} qr/DBI Exception.+(?x:
++\QNOT NULL constraint failed: cd.artist\E
++ |
++\Qcd.artist may not be NULL\E
++)/s, 'ambiguous find + create failed'
++;
+
+ # expect a create, after a failed search using *only* the
+ # *current* relationship and the unique column constraints
+diff --git a/t/storage/error.t b/t/storage/error.t
+index d5980eb..61d6782 100644
+--- a/t/storage/error.t
b/t/storage/error.t
+@@ -15,7 +15,11 @@ warnings_are ( sub {
+ sub {
+ $schema-resultset('CD')-create({ title = 'vacation in antarctica' })
+ },
+-qr/DBI Exception.+cd\.artist.+NULL/s
++qr/DBI Exception.+(?x:
++ \QNOT NULL constraint failed: cd.artist\E
++|
++ \Qcd.artist may not be NULL\E
++)/s
+ ); # as opposed to some other error
+ }, [], 'No warnings besides exception' );
+
+--
+1.9.0
+
diff --git a/perl-DBIx-Class.spec b/perl-DBIx-Class.spec
index 8238789..a654ffb 100644
--- a/perl-DBIx-Class.spec
+++ b/perl-DBIx-Class.spec
@@ -1,10 +1,13 @@
Name: perl-DBIx-Class
Summary:Extensible and flexible object - relational mapper
Version:0.08250
-Release:2%{?dist}
+Release:3%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/DBIx-Class-%{version}.tar.gz
+# Adapt to new sqlite-3.8.2 exception messages, bug #1085336, CPAN RT#91947,
+# in upstream version 0.08260
+Patch0:
DBIx-Class-0.08250-SQLite-changed-their-exception-text-again.patch
URL:http://search.cpan.org/dist/DBIx-Class/
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
@@ -134,6 +137,7 @@ DISTINCT, GROUP BY and HAVING support.
%prep
%setup -q -n DBIx-Class-%{version}
+%patch0 -p1
find t/ -type f -exec perl -pi -e 's|\r||; s|^#!perl|#!%{__perl}|' {} +
find . -type f -exec chmod -c -x {} +
@@ -181,6 +185,9 @@ make test
%changelog
+* Wed Apr 09 2014 Petr Pisar ppi...@redhat.com - 0.08250-3
+- Adapt to new sqlite-3.8.2 exception messages (bug #1085336)
+
* Wed Aug 14 2013 Jitka Plesnikova jples...@redhat.com - 0.08250-2
- Perl 5.18 re-rebuild of bootstrapped packages
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBIx-Class/f20] Adapt to new sqlite-3.8.2 exception messages
Summary of changes: 14999c3... Adapt to new sqlite-3.8.2 exception messages (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1085579] perl-Moose compiled for perl API v5.16.0; fedora perl now at v5.18.0
https://bugzilla.redhat.com/show_bug.cgi?id=1085579 --- Comment #2 from simon.gal...@gmail.com --- Thanks -- will check on the other systems. -- 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=BBTGyprFMga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
