EPEL epel beta report: 20140710 changes
Compose started at Thu Jul 10 08:15:03 UTC 2014 New package: CharLS-1.0-5.el7 An optimized implementation of the JPEG-LS standard New package: armadillo-4.320.0-1.el7 Fast C++ matrix library with interfaces to LAPACK and ATLAS New package: datagrepper-0.4.1-3.el7 A webapp to query fedmsg history New package: exim-4.82.1-4.el7 The exim mail transfer agent New package: libdap-3.11.3-3.el7 The C++ DAP2 library from OPeNDAP New package: librx-1.5-19.el7 POSIX regexp functions New package: mozilla-adblockplus-2.6.3-1.el7 Adblocking extension for Mozilla Firefox, Thunderbird, and SeaMonkey New package: netcdf4-python-1.1.0-1.el7 Python/numpy interface to netCDF New package: perl-SOCKS-0.03-1.el7 SOCKS Perl module New package: ps2eps-1.68-5.el7 PS-to-EPS converter New package: python-arrow-0.4.2-5.el7 Better dates and times for Python New package: python-chai-0.4.8-2.el7 Easy to use mocking/stub framework New package: python-datanommer-models-0.6.4-2.el7 SQLAlchemy models for datanommer New package: python-flask-openid-1.2-1.el7 OpenID support for Flask New package: python-freezegun-0.1.12-3.el7 Let your Python tests travel through time New package: python-sure-1.1.7-1.el7 Assertion toolbox for python New package: quassel-0.10.0-1.el7 A modern distributed IRC system New package: tcpreplay-4.0.4-2.el7 Replay captured network traffic Updated Packages: knot-1.5.0-1.el7 * Thu Jul 10 2014 Jan Vcelak jvce...@fedoraproject.org 1.5.0-1 - update to 1.5.0 + reimplemented DDNS forwarding + transfer sizes logged in bytes + logging of outgoing/incoming NOTIFY messages + zone flush planning after bootstrap + DDNS signing changes freeing + knotc key handling - update to 1.5.0-rc2 + edns-client-subnet support in kdig + optional asynchronous startup (config 'asynchronous-start') + preempt task queue for faster reload + lazy zone file write after zone transfer (config 'zonefile-sync') + close zone transfer after SERVFAIL response + incremental to full zone transfer fallback, wrong log message + zone events corner cases, reload replanning - update to 1.5.0-rc1 + Pluggable query processing modules + Synthetic IPv4/IPv6 reverse/forward records (optional module) + Dnstap support in both utilities server (optional module) + NOTIFY message support and new TSIG section in kdig + Multi-master support + Query processing and core functionality overhaul + Performance and reduced memory footprint + Faster zone events scheduling + RFC compliant queries/responses in some corner cases + Log messages + New documentation (Sphinx) - enabled dynamic linking - removed info pages ocsinventory-2.1.2-1.el7 * Wed Jul 09 2014 Remi Collet r...@fedoraproject.org - 2.1.2-1 - update to 2.1.2 * Wed Jul 09 2014 Remi Collet r...@fedoraproject.org - 2.1.1-3 - XSS security fix for CVE-2014-4722 php-horde-Horde-Imap-Client-2.23.2-1.el7 * Wed Jul 09 2014 Remi Collet r...@fedoraproject.org - 2.23.2-1 - Update to 2.23.2 php-horde-Horde-Mime-2.4.3-1.el7 * Wed Jul 09 2014 Remi Collet r...@fedoraproject.org - 2.4.3-1 - Update to 2.4.3 qpid-dispatch-0.2-6.el7 --- * Wed Jul 09 2014 Darryl L. Pierce dpie...@redhat.com - 0.2-6 - Removed intro-package comments which can cause POSTUN warnings. - Added dependency on libqpid-dispatch from qpid-dispatch-tools. Summary: Added Packages: 18 Removed Packages: 0 Modified Packages: 5 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
On Thu, Jul 10, 2014 at 05:39:40AM +, Zhiwei Zhu wrote: Hi Toshio, I have just noticed this message after I failed to install TurboGears (v1) on CentOS 7. We really need the TurboGears (v1) support via epel for el7. Migrating away from TurboGears V1 to V2 or to other framework seems impossible for us at the moment, though we know that we will have to migrate in future. Could you help to suggest what we could do to revive these packages and have epel7 will still support TurboGears( v1 )? Sure! Become a package maintainer and maintain the packages that have become orphaned in EPEL7. Note that you won't need to revive all of the packages -- some of those were retired because they depend on TurboGears1 (for instance, bodhi). You'll only need to revive the ones that TurboGears1 depends on (and those that your applications need). -Toshio -- Best Regards Jacky -Original Message- From: epel-devel-boun...@lists.fedoraproject.org [mailto:epel-devel-boun...@lists.fedoraproject.org] On Behalf Of Toshio Kuratomi Sent: Saturday, 21 June 2014 3:02 AM To: epel-devel@lists.fedoraproject.org Subject: Re: EPEL Orphan or retire the TurboGears (v1) stack in 7 On Mon, Jun 16, 2014 at 12:01:26PM -0700, Toshio Kuratomi wrote: If someone steps up to say they'll take ownership of TurboGears1 (one of the comaintainers or someone new), then I'll reassign these packages to them. If no one does, then I'll retire them in epel7 and ask that the packages be removed from the download repos before epel7 leaves beta. Someone can revive them later if they're interested. == Packages to be orphaned retired == * python-cherrypy2 * python-elixir * python-peak-rules * python-turbocheetah * bodhi * python-tgcaptcha2 * python-turboflot * python-turbokid (need to remove a spurious dep on this from TurboGears2) * python-turbojson (need to remove a spurious dep on this from TurboGears2) * python-paste-script (this one has other dependents in Fedora but none in EPEL7. Please speak up or revive this later if you're interested) These have now been retired. If someone is interested in them, feel free to revive. -Toshio [wargaming.net] EgzO3mXGcK This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel pgpe7ewpeSsvv.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
Hi Toshio, Thanks. Understand the situation now. Will discuss with my lead about the possibility to maintain the packages by ourselves. BTW, as we don't have experience of maintaining packages on epel, we have no idea how much effort will be required to do that or how difficult it would be. Could you help to share something about this? I understand that there is some kind of co-maintainer path to take for new maintainers but don't how to start it. -- Best Regards Jacky -Original Message- From: epel-devel-boun...@lists.fedoraproject.org [mailto:epel-devel-boun...@lists.fedoraproject.org] On Behalf Of Toshio Kuratomi Sent: Thursday, 10 July 2014 11:20 PM To: EPEL Development List Subject: Re: EPEL Orphan or retire the TurboGears (v1) stack in 7 On Thu, Jul 10, 2014 at 05:39:40AM +, Zhiwei Zhu wrote: Hi Toshio, I have just noticed this message after I failed to install TurboGears (v1) on CentOS 7. We really need the TurboGears (v1) support via epel for el7. Migrating away from TurboGears V1 to V2 or to other framework seems impossible for us at the moment, though we know that we will have to migrate in future. Could you help to suggest what we could do to revive these packages and have epel7 will still support TurboGears( v1 )? Sure! Become a package maintainer and maintain the packages that have become orphaned in EPEL7. Note that you won't need to revive all of the packages -- some of those were retired because they depend on TurboGears1 (for instance, bodhi). You'll only need to revive the ones that TurboGears1 depends on (and those that your applications need). -Toshio -- Best Regards Jacky -Original Message- From: epel-devel-boun...@lists.fedoraproject.org [mailto:epel-devel-boun...@lists.fedoraproject.org] On Behalf Of Toshio Kuratomi Sent: Saturday, 21 June 2014 3:02 AM To: epel-devel@lists.fedoraproject.org Subject: Re: EPEL Orphan or retire the TurboGears (v1) stack in 7 On Mon, Jun 16, 2014 at 12:01:26PM -0700, Toshio Kuratomi wrote: If someone steps up to say they'll take ownership of TurboGears1 (one of the comaintainers or someone new), then I'll reassign these packages to them. If no one does, then I'll retire them in epel7 and ask that the packages be removed from the download repos before epel7 leaves beta. Someone can revive them later if they're interested. == Packages to be orphaned retired == * python-cherrypy2 * python-elixir * python-peak-rules * python-turbocheetah * bodhi * python-tgcaptcha2 * python-turboflot * python-turbokid (need to remove a spurious dep on this from TurboGears2) * python-turbojson (need to remove a spurious dep on this from TurboGears2) * python-paste-script (this one has other dependents in Fedora but none in EPEL7. Please speak up or revive this later if you're interested) These have now been retired. If someone is interested in them, feel free to revive. -Toshio [wargaming.net] EgzO3mXGcK This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Wargaming.net accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. kgzO3mXGcg ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
Excerpts from Zhiwei Zhu's message of 2014-07-11 09:31:37 +1000: Thanks. Understand the situation now. Will discuss with my lead about the possibility to maintain the packages by ourselves. BTW, as we don't have experience of maintaining packages on epel, we have no idea how much effort will be required to do that or how difficult it would be. Could you help to share something about this? I understand that there is some kind of co-maintainer path to take for new maintainers but don't how to start it. I had hoped we would have Beaker ported off TG1 long before now, and I was going to use the retirement of the EPEL7 TG1 stack as extra motivation to get it done, but realistically we will be depending on it for quite a while still, just like you Zhiwei. So I can maintain the TG1 stack in EPEL7. I will start the un-retiring process for all the packages we need and post the exact list here. Zhiwei, if you would like to co-maintain that would be a great help. I'm not able to sponsor you into the packager group, but I think you can be a co-maintainer without a sponsor (actually I'm not sure about that...) -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
Hi Dan, Thanks for sharing this. It's really a great news for us that you will help to maintain the TG1 stack in EPEL7 and will start the un-retiring process. Hope they will be available again soon. Yes, when talking about real projects, when schedules, requirements, efforts, resources, risks, etc, are involved, the reality is always far away from the theory. We should have planned the migration from TG1 in this release. However, probably because there is no obvious benefit that we can get from it, it's never been given a high priority. I think this show-stopper will push us to really consider the migration seriously in future releases, either to TG2 or to Django. For co-maintaining the TG1 stack, I would like to and will start to look into how to do that, but I hope it could be recovered before I can really offer any help, because our currently release is kind of blocked by this issue. A lot of tasks, plans depend on whether TG1 would be availble on EPEL7. We are going to discuss our platform support stuff early next week and hope there would be some more good news then:) -- Best Regards Jacky -Original Message- From: Dan Callaghan [mailto:dcall...@redhat.com] Sent: Friday, 11 July 2014 10:42 AM To: Zhiwei Zhu Cc: EPEL Development List Subject: Re: EPEL Orphan or retire the TurboGears (v1) stack in 7 Excerpts from Zhiwei Zhu's message of 2014-07-11 09:31:37 +1000: Thanks. Understand the situation now. Will discuss with my lead about the possibility to maintain the packages by ourselves. BTW, as we don't have experience of maintaining packages on epel, we have no idea how much effort will be required to do that or how difficult it would be. Could you help to share something about this? I understand that there is some kind of co-maintainer path to take for new maintainers but don't how to start it. I had hoped we would have Beaker ported off TG1 long before now, and I was going to use the retirement of the EPEL7 TG1 stack as extra motivation to get it done, but realistically we will be depending on it for quite a while still, just like you Zhiwei. So I can maintain the TG1 stack in EPEL7. I will start the un-retiring process for all the packages we need and post the exact list here. Zhiwei, if you would like to co-maintain that would be a great help. I'm not able to sponsor you into the packager group, but I think you can be a co-maintainer without a sponsor (actually I'm not sure about that...) -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
(Rawhide users) Fedora 22 branching: What You Need To Know
Hey folks! As we just hit a branch point, here's a refresher on what this means for folks who've been running Rawhide. If you want to keep running Rawhide, which will now contain packages tracked for Fedora *22*, you don't need to do anything: just keep updating. From tomorrow onwards, you'll start getting '.fc22' packages, tracked for Fedora 22. If you want to follow Fedora 21, you'll want to either remove the 'fedora-repos-rawhide' package (that replaced fedora-release-rawhide today), or disable the Rawhide repository using a graphical repo config manager or 'yum-config-manager' from yum-utils: sudo yum-config-manager --disable rawhide then you'll want to *enable* the regular Fedora repositories: sudo yum-config-manager --enable fedora and, optionally, enable updates-testing: sudo yum-config-manager --enable updates-testing if you miss the branch point and wind up on Rawhide (F22) but you want to switch to F21, you'll want to do all the above, then do this: sudo yum --releasever=21 distro-sync which should get you back to F21. Note that as I write this, it seems that mirrormanager needs an update for F21 - right now when you try to use F21 repos, you'll see an error like this: fedora/21/x86_64/metalink | 28 kB 00:00 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-21arch=x86_64 error was No repomd file I expect that'll get cleaned up pretty soon, so just hang tight. Stay safe out there, intrepid pre-release-nauts! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Wednesday, July 9, 2014, 1:24:12 PM, Reindl Harald wrote: Am 09.07.2014 19:18, schrieb Chris Adams: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: Please, no! As soon as you use disparate systems in a network environment, having differing versions of UID_MIN (where recompilation is required to change) is just wrong. As the message above sys, yes, that is actually used and needed. I see no valid justification for removing that functionality +1 UID_MIN 500 UID_MAX 6 GID_MIN 500 GID_MAX 6 still here in use and that won't change if somebody enforces to change that at compile time he don't care for any production setups not re-installed every year and decides to break things just for fun The boundary between system and user IDs moved from 500 to 1000 relatively recently (F18). Aside from giving more room for system IDs, this had the side effect of hiding IDs from 500 to 999 that were created by older Fedora releases from the GDM logon panel. User IDs had to be moved above 999 to be visible again. It was a bit of a painful transition. Does this mean the system headers were not updated to match? Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
Am 10.07.2014 09:37, schrieb Al Dunsmuir: On Wednesday, July 9, 2014, 1:24:12 PM, Reindl Harald wrote: Am 09.07.2014 19:18, schrieb Chris Adams: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: Please, no! As soon as you use disparate systems in a network environment, having differing versions of UID_MIN (where recompilation is required to change) is just wrong. As the message above sys, yes, that is actually used and needed. I see no valid justification for removing that functionality +1 UID_MIN 500 UID_MAX 6 GID_MIN 500 GID_MAX 6 still here in use and that won't change if somebody enforces to change that at compile time he don't care for any production setups not re-installed every year and decides to break things just for fun The boundary between system and user IDs moved from 500 to 1000 relatively recently (F18). Aside from giving more room for system IDs, this had the side effect of hiding IDs from 500 to 999 that were created by older Fedora releases from the GDM logon panel. User IDs had to be moved above 999 to be visible again. It was a bit of a painful transition and that shows why set that at compile time or hardcode it somewhere is wrong and a bad style KDM respects /etc/login.defs cat /etc/passwd | grep harry harry:x:500:501:Reindl Harald:/home/harry:/usr/bin/bash (written from a graphical KDE session) 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: New Fedora 22 Change proposal: systemd-sysusers
On Thu, 2014-07-10 at 08:17 +0300, Oron Peled wrote: A non-API related question... Generally, I prefer the explicit systemd settings over home directory with magical effects, but I wonder if anyone is aware of existing system users which carry more complex semantics. Perhaps look at the amanda backup system? That uses the home directory location quite deeply in its setup Additionally, This doesn't seem to be hugely clear some of the effects of what you want to achieve. Perhaps the answers to these questions can be put on the wiki to clear up some initial concerns I have as a sysadmin. * Files in systemd's sysusers configuration directory will be used as a data source to create /etc/passwd and /etc/shadow. Under what conditions are these two files created / touched? When I install a package and add a file to this sysuser directory, is only that user added to passwd and shadow? Is there a way to disable or remove a system user from being added to /etc/shadow? Are changes to shadow/passwd made by a user respected / preserved (IE to a user account)? What happens if a human edits the system account generated by systemd, do the changes get lost? -- William will...@firstyear.id.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] The Base Design WG is looking for a new committee member!
Ups, seems i'm living in the future already. :) Meeting is of course on Friday, not Thursday, so hope to see you there tomorrow! Thanks regards, Phil On 07/09/2014 05:23 PM, Phil Knirsch wrote: That sounds great Michal. If you could join us tomorrow at our meeting at 15:00 UTC on #fedora-meeting that would be excellent. Thank you for your interest and see you tomorrow! Regards, Phil On 07/08/2014 02:31 PM, Michal Sekletar wrote: On Fri, Jun 27, 2014 at 06:13:01PM +0200, Phil Knirsch wrote: Hi everyone. Hello everyone, As Bill Nottingham has decided to resign from the committee we now have a free seat that we'd like to fill with another person. In order to fill this seat i'm therefore reaching out here to Fedora development to offer allow any applicant from the community to get in touch with us and let us know you're interested, why you're interested, why you think you'd be a good fit and maybe even the things you'd like to drive or accomplish in the Base Design WG. I am interested in becoming a member of Base Design WG. I'd like help with accomplishing goals of Base WG and make sure that we provide minimal but solid foundation for others to build upon. I believe my previous experience makes me a good fit for this position : * Red Hat employee since 2011, now member of Plumbers group * maintainer and contributor to various networking related projects * systemd maintainer in RHEL I'd like to help with integration of upstream changes in key components to the distribution and making sure they are not disruptive. Another area where I'd like to contribute are container use cases of Fedora Base. Ensuring we provide minimal, but easily extensible platform for sand-boxed/containerized apps. For more background on what the Base WG does, here our Fedora wiki: https://fedoraproject.org/wiki/Base In order to contact us you can either reply directly to me or join us during our regular meetings each Friday at 15:00 UTC on #fedora-meeting. I strongly suspect next weeks meeting will be canceled due to the US holiday, but after that we'll be doing weekly meetings again. Looking forward to see you there! Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Michal -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
cross-gcc is updated to gcc-4.9.0 in updates-testing for F19+
So anyone that is using it to build their own packages, if you could check it in the next three weeks. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, Jul 10, 2014, at 12:46 AM, William wrote: Under what conditions are these two files created / touched? When systemd-sysusers is run. When I install a package and add a file to this sysuser directory, is only that user added to passwd and shadow? The answer to this is pretty simple; systemd-sysusers does nothing if the user already exists. It has built-in idempotency. Contrast with the fact that shadow-utils doesn't, so all of the RPM %pre scripts duplicate it in shell. Is there a way to disable or remove a system user from being added to /etc/shadow? Why? Are changes to shadow/passwd made by a user respected / preserved (IE to a user account)? Yes. What happens if a human edits the system account generated by systemd, do the changes get lost? See above; if you edit the passwd entry post-creation, systemd won't change it. -- 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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4
On Wed, Jul 09, 2014 at 10:19:52PM -0700, Adam Williamson wrote: ddclient seems to have been retired apparently as a part of this process, going by the commit: http://pkgs.fedoraproject.org/cgit/ddclient.git/commit/?id=f741436ca38fd6c36ffbfbb26b3131b278657faa but it wasn't listed in this email. Was that an oversight? Was it listed somewhere else I didn't catch? It does show up as 'orphaned' in pkgdb: https://admin.fedoraproject.org/pkgdb/package/ddclient/ . It was retired as it was shown on the right hand side of the page. It was orphaned after I wrote the final email, therefore it was not additionally announced: https://apps.fedoraproject.org/datagrepper/id?id=2014-e7f2c941-6718-4adf-8e07-849e83368956is_raw=truesize=extra-large I unretired it in pkgdb/koji, so you can restore it in dist-git. However a F21 branch is missing and needs to be requested via an SCM admin request. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20140710 changes
Compose started at Thu Jul 10 07:15:02 UTC 2014 Broken deps for armhfp -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyKDE] PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) = 0:10.0 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [csound] csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [eclipse-jbosstools] eclipse-jbosstools-jst-4.1.1-2.fc21.noarch requires eclipse-wtp-jst-web eclipse-jbosstools-ws-4.1.1-2.fc21.noarch requires osgi(org.eclipse.jst.ws.annotations.core) [edelib] edelib-2.1-4.fc21.armv7hl requires libedelib.so edelib-devel-2.1-4.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [ghc-crypto-api] ghc-crypto-api-devel-0.11-5.fc21.armv7hl requires ghc-devel(entropy-0.2.2.1-ae359458c8f3b4c8838403b8c9a5a50a) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [golang-github-smarterclayton-go-systemd] golang-github-smarterclayton-go-systemd-devel-0-0.5.git5cb9e9e.fc21.noarch requires golang(github.com/guelfey/go.dbus) [grass] grass-6.4.3-5.fc21.armv7hl requires libtk8.5.so grass-6.4.3-5.fc21.armv7hl requires libtcl8.5.so [hfsutils] hfsutils-x11-3.2.6-24.fc20.armv7hl requires libtk8.5.so hfsutils-x11-3.2.6-24.fc20.armv7hl requires libtcl8.5.so [hibernate-search] hibernate-search-4.5.1-4.fc21.noarch requires mvn(org.apache.avro:avro) [ice] ice-php-3.5.1-4.fc21.armv7hl requires php(zend-abi) = 0:20121212-32 ice-php-3.5.1-4.fc21.armv7hl requires php(api) = 0:20121113-32 [jacorb] jacorb-2.3.1-12.fc21.noarch requires UNKNOWN-mvn(org.beanshell:bsh:UNKNOWN) [jboss-integration] jboss-integration-6.0.0-0.3.CR1.fc21.noarch requires mvn(jacorb:jacorb) [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [mapserver] mapserver-java-6.2.1-7.fc21.armv7hl requires java-gcj-compat [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [mingw-tk] mingw32-tk-8.5.13-5.fc21.noarch requires mingw32(tcl85.dll) [naver-nanum-fonts] naver-nanum-barun-gothic-fonts-3.020-10.20131007.fc21.noarch requires naver-nanum-fonts-common = 0:20131007-10.20131007.fc21 naver-nanum-brush-fonts-3.020-10.20131007.fc21.noarch requires naver-nanum-fonts-common = 0:20131007-10.20131007.fc21 naver-nanum-gothic-fonts-3.020-10.20131007.fc21.noarch requires naver-nanum-fonts-common = 0:20131007-10.20131007.fc21 naver-nanum-myeongjo-fonts-3.020-10.20131007.fc21.noarch requires naver-nanum-fonts-common = 0:20131007-10.20131007.fc21 naver-nanum-pen-fonts-3.020-10.20131007.fc21.noarch requires naver-nanum-fonts-common = 0:20131007-10.20131007.fc21 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2014 05:08 PM, Matthew Miller wrote: On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote: I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work. A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed? * dredges up meeting logs -- http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00.html That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: 4. There would be, at least, a net install CD to install a traditional non-productized Fedora system. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO+czUACgkQeiVVYja6o6MglgCgqA5z48SkYRN3Nx8QaTh2da03 4B8An32CWXUbAEOtVMmmY8523MqaDtUP =4qan -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: (Rawhide users) Fedora 22 branching: What You Need To Know
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2014 02:37 AM, Adam Williamson wrote: Hey folks! As we just hit a branch point, here's a refresher on what this means for folks who've been running Rawhide. If you want to keep running Rawhide, which will now contain packages tracked for Fedora *22*, you don't need to do anything: just keep updating. From tomorrow onwards, you'll start getting '.fc22' packages, tracked for Fedora 22. If you want to follow Fedora 21, you'll want to either remove the 'fedora-repos-rawhide' package (that replaced fedora-release-rawhide today), or disable the Rawhide repository using a graphical repo config manager or 'yum-config-manager' from yum-utils: sudo yum-config-manager --disable rawhide then you'll want to *enable* the regular Fedora repositories: sudo yum-config-manager --enable fedora and, optionally, enable updates-testing: sudo yum-config-manager --enable updates-testing if you miss the branch point and wind up on Rawhide (F22) but you want to switch to F21, you'll want to do all the above, then do this: sudo yum --releasever=21 distro-sync which should get you back to F21. Note that as I write this, it seems that mirrormanager needs an update for F21 - right now when you try to use F21 repos, you'll see an error like this: fedora/21/x86_64/metalink | 28 kB 00:00 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-21arch=x86_64 error was No repomd file I expect that'll get cleaned up pretty soon, so just hang tight. Stay safe out there, intrepid pre-release-nauts! One thing I discovered last night. There's a bug with the new fedora-release packages and yum/dnf are kind of arbitrarily picking from fedora-release-[standard|cloud|server|workstation] to install if you just update. (This is in large part because these are just placeholder packages and don't have any content in them yet). To avoid issues going forward, before you do the distro-sync above, you probably want to 'yum install fedora-release-$something' where $something is either 'standard' (for non-productized Fedora) or one of the Products, which your environment will evolve more into the closer we get to Alpha. I'll try to work out what we need to do to make that transition cleaner from F20-F21, but for Rawhide-F21 it's going to be a bit manual for a while. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO+dN0ACgkQeiVVYja6o6P6jgCbBZHPpQj6s6OnNSGxm6hAol8l puoAniWV9dRrSjEehWBXwHakn61lYvLI =dvSE -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: pulseaudio-5.0-6.fc20: fine but not on bodhi
Reindl Harald wrote:
Am 08.07.2014 21:38, schrieb Rex Dieter:
Reindl Harald wrote:
until now https://koji.fedoraproject.org/koji/buildinfo?buildID=542357
for whatever reason did it not make to bodhi -
it was submitted early today,
https://admin.fedoraproject.org/updates/pulseaudio-5.0-6.fc20
thanks for the hint - karma given
because it lists a CVE and even if it raises the major version
to 5 not appear to break anything i would say that update needs
some love to go out
keep in mind a CVE in such a package may affect any Fedora user
FYI, this update has been pulled due to a regression found (probably affects
rawhide too),
https://bugzilla.redhat.com/show_bug.cgi?id=1117683
and pulseaudio upstream,
https://bugs.freedesktop.org/show_bug.cgi?id=81116
and for some reason abrt isn't submitting these crashes for me when I
finally reproduced it :( (see below) This may explain why no bugs were
filed.
abrt always says when I try to report it:
--- Running report_uReport ---
Server responded with an error: 'Validation failed: Element 'stacktrace' is
invalid: List element is invalid: Element 'frames' is invalid: List element
is invalid: Element 'file_name' is missing'
reporter-ureport failed with exit code 1
('report_uReport' exited with 1)
though I can manually use gdb on it's saved coredump fine.
-- Rex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, 10.07.14 08:17, Oron Peled (o...@actcom.co.il) wrote: A non-API related question... On Thursday 10 July 2014 01:49:41 Lennart Poettering wrote: Please understand that we are not duplicating adduser here. Already in the name of the tool we wanted to make clear thtat this is abotu system users, nothing else. The file format we defined has been reduced to the minimum possible, in order to make it difficult for people to use it for anything else than this. There are cases where a home directory of system users carry some semantics. Two examples from the top of my head: * Some tftpd implementations use it as the base path (and chroot into it) * Some anonymous ftpd implementation have similar use (chroot into ~ftp) So I assume *all* of these cases should be replaced by systemd explicit settings -- e.g: WorkingDirectory, RootDirectory in the unit file. Generally, I prefer the explicit systemd settings over home directory with magical effects, but I wonder if anyone is aware of existing system users which carry more complex semantics. The gdm user also kinda needs a home directory. I figure we should add a figth column to sysusers.d fragments, that allows setting the home directory. It's on the TODO list now. 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: pulseaudio-5.0-6.fc20: fine but not on bodhi
Am 10.07.2014 14:30, schrieb Rex Dieter:
Reindl Harald wrote:
Am 08.07.2014 21:38, schrieb Rex Dieter:
Reindl Harald wrote:
until now https://koji.fedoraproject.org/koji/buildinfo?buildID=542357
for whatever reason did it not make to bodhi -
it was submitted early today,
https://admin.fedoraproject.org/updates/pulseaudio-5.0-6.fc20
thanks for the hint - karma given
because it lists a CVE and even if it raises the major version
to 5 not appear to break anything i would say that update needs
some love to go out
keep in mind a CVE in such a package may affect any Fedora user
FYI, this update has been pulled due to a regression found (probably affects
rawhide too),
https://bugzilla.redhat.com/show_bug.cgi?id=1117683
and pulseaudio upstream,
https://bugs.freedesktop.org/show_bug.cgi?id=81116
and for some reason abrt isn't submitting these crashes for me when I
finally reproduced it :( (see below) This may explain why no bugs were
filed.
abrt always says when I try to report it:
--- Running report_uReport ---
Server responded with an error: 'Validation failed: Element 'stacktrace' is
invalid: List element is invalid: Element 'frames' is invalid: List element
is invalid: Element 'file_name' is missing'
reporter-ureport failed with exit code 1
('report_uReport' exited with 1)
though I can manually use gdb on it's saved coredump fine
interesting - until now no single problem here with MPD, Flash
and VLC - the main applications with soundoutput here besides
the new-mail MP3 of thunderbird
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: [Base] The Base Design WG is looking for a new committee member!
On Thu, Jul 10, 2014 at 11:00:12AM +0200, Phil Knirsch wrote: Ups, seems i'm living in the future already. :) Meeting is of course on Friday, not Thursday, so hope to see you there tomorrow! Sure, will be there. Thanks regards, Phil Michal On 07/09/2014 05:23 PM, Phil Knirsch wrote: That sounds great Michal. If you could join us tomorrow at our meeting at 15:00 UTC on #fedora-meeting that would be excellent. Thank you for your interest and see you tomorrow! Regards, Phil On 07/08/2014 02:31 PM, Michal Sekletar wrote: On Fri, Jun 27, 2014 at 06:13:01PM +0200, Phil Knirsch wrote: Hi everyone. Hello everyone, As Bill Nottingham has decided to resign from the committee we now have a free seat that we'd like to fill with another person. In order to fill this seat i'm therefore reaching out here to Fedora development to offer allow any applicant from the community to get in touch with us and let us know you're interested, why you're interested, why you think you'd be a good fit and maybe even the things you'd like to drive or accomplish in the Base Design WG. I am interested in becoming a member of Base Design WG. I'd like help with accomplishing goals of Base WG and make sure that we provide minimal but solid foundation for others to build upon. I believe my previous experience makes me a good fit for this position : * Red Hat employee since 2011, now member of Plumbers group * maintainer and contributor to various networking related projects * systemd maintainer in RHEL I'd like to help with integration of upstream changes in key components to the distribution and making sure they are not disruptive. Another area where I'd like to contribute are container use cases of Fedora Base. Ensuring we provide minimal, but easily extensible platform for sand-boxed/containerized apps. For more background on what the Base WG does, here our Fedora wiki: https://fedoraproject.org/wiki/Base In order to contact us you can either reply directly to me or join us during our regular meetings each Friday at 15:00 UTC on #fedora-meeting. I strongly suspect next weeks meeting will be canceled due to the US holiday, but after that we'll be doing weekly meetings again. Looking forward to see you there! Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Michal -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, 10.07.14 17:16, William (will...@firstyear.id.au) wrote: On Thu, 2014-07-10 at 08:17 +0300, Oron Peled wrote: A non-API related question... Generally, I prefer the explicit systemd settings over home directory with magical effects, but I wonder if anyone is aware of existing system users which carry more complex semantics. Perhaps look at the amanda backup system? That uses the home directory location quite deeply in its setup Additionally, This doesn't seem to be hugely clear some of the effects of what you want to achieve. Perhaps the answers to these questions can be put on the wiki to clear up some initial concerns I have as a sysadmin. * Files in systemd's sysusers configuration directory will be used as a data source to create /etc/passwd and /etc/shadow. Also, /etc/group and /etc/gshadow. Under what conditions are these two files created / touched? Three triggers: 1. When the systemd-sysusers tool is invoked from an RPM scriplet, which I hope can be made the default in Fedora for all packages needing system users. 2. At boot on systems which are set up in a golden master scheme, where a single /usr is used for a number of instances which each have their own /etc and /var. Similar, on stateless systems which boot up with tmpfs on /etc and /var, and hence start from scracth every single time. Note though that Fedora is not set up for this fully yet (though it actually works prettty good already, with the two exceptions in the basic OS being PAM and dbus-1, which react quite allergic to an unpopulated /etc). 3. Similar to 2, but people who instantiate new systems from the same /usr in an offline scheme, where they don't delay user creation to the next reboot. Note however, that sysusers will only do something if any of the specified users is actually missing. We arevery careful in not touching the file system if all users already exist. Also, if the disk is read-only sysusers is automatically skipped at boot. At a later time I will propose fixing Fedora to make the stateless + golden master schemes just work. But I am not ready to discuss this in full now. When I install a package and add a file to this sysuser directory, is only that user added to passwd and shadow? For each user you create with sysusers a matching group will be created too, should it be missing. Is there a way to disable or remove a system user from being added to /etc/shadow? No. What's the usecase? Does this currently exist for the RPM scriptlet case? Are changes to shadow/passwd made by a user respected / preserved (IE to a user account)? Yes. Always. sysuers will never touch existing users, it will only add in missing ones, with secure defaults (i.e. as disabled accounts, with no login possible). For exmple, if you assign a shell or a password to one of those system users, then that's totally OK, sysusers will stay away from that, never reset it, never touch it. What happens if a human edits the system account generated by systemd, do the changes get lost? Nope, what the admin changes will take effect. The only thing that might happen that if you delete a user it might be recreated the next time sysusers runs. 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: kde-4.13.x update for f20
On Sex, 2014-07-04 at 12:12 +0200, Reindl Harald wrote: Am 04.07.2014 12:02, schrieb Sérgio Basto: http://apt.kde-redhat.org/apt/kde-redhat/fedora/kde.repo have 3 repos is to use kde stable ? this will equal to future Fedora 20 , with kde 13 , many years ago I try use kde-redhat and I saw that a quite different filosofy that was in Fedora in the meantime Rex Dieter became the core maintainer of the Fedora packages too - kde-redhat is the playground for Fedora packaging and kde-unstable is the preview of the next major update kde-unstable is not always recommended and should be taken with care, in case of 4.13 it is quite stable kde-testing usually has the same packaging as updates-testing yum --enablerepo=kde-unstable update Obsoleted By: kactivities-libs-4.13.2-1.fc20.x86_64 (kde-unstable) Not found -- 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
Re: kde-4.13.x update for f20
Am 10.07.2014 15:15, schrieb Sérgio Basto: On Sex, 2014-07-04 at 12:12 +0200, Reindl Harald wrote: Am 04.07.2014 12:02, schrieb Sérgio Basto: http://apt.kde-redhat.org/apt/kde-redhat/fedora/kde.repo have 3 repos is to use kde stable ? this will equal to future Fedora 20 , with kde 13 , many years ago I try use kde-redhat and I saw that a quite different filosofy that was in Fedora in the meantime Rex Dieter became the core maintainer of the Fedora packages too - kde-redhat is the playground for Fedora packaging and kde-unstable is the preview of the next major update kde-unstable is not always recommended and should be taken with care, in case of 4.13 it is quite stable kde-testing usually has the same packaging as updates-testing yum --enablerepo=kde-unstable update Obsoleted By: kactivities-libs-4.13.2-1.fc20.x86_64 (kde-unstable) Not found besides 4.13 in the meantime is on kde-testing what about report something useful instead one line out of context and stay at k...@lists.fedoraproject.org? 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: Schedule for Thursday's FPC Meeting (2014-07-10 16:00 UTC)
On Wed, Jul 9, 2014 at 12:31 PM, James Antill ja...@fedoraproject.org wrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-07-10 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. 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. There were a couple other tickets that are needed for Fedora Changes so we'll discuss those first thing: Per-product Config: https://fedorahosted.org/fpc/ticket/446 New java Packaging Guidelines (AFAIK, just making javadocs optional): https://fedorahosted.org/fpc/ticket/445 There were some updated to the mimeinfo scriptlets that we passed last week as well. So we could take a look at that while it's still fresh in our minds: https://fedorahosted.org/fpc/ticket/440 -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting 11 July 2014 15:00 UTC on #fedora-meeting
Agenda: - Introduction of Benedikt Morbach, intern working on buildreq reduction (and potential other stuff if time permits ;)) - Talk with Michal Sekletar as candidate for WG - Vaclav Pavlin presenting minimal Docker image for Fedora (133MB) - Open floor Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: kde-4.13.x update for f20
On Qui, 2014-07-10 at 15:18 +0200, Reindl Harald wrote: Am 10.07.2014 15:15, schrieb Sérgio Basto: On Sex, 2014-07-04 at 12:12 +0200, Reindl Harald wrote: Am 04.07.2014 12:02, schrieb Sérgio Basto: http://apt.kde-redhat.org/apt/kde-redhat/fedora/kde.repo have 3 repos is to use kde stable ? this will equal to future Fedora 20 , with kde 13 , many years ago I try use kde-redhat and I saw that a quite different filosofy that was in Fedora in the meantime Rex Dieter became the core maintainer of the Fedora packages too - kde-redhat is the playground for Fedora packaging and kde-unstable is the preview of the next major update kde-unstable is not always recommended and should be taken with care, in case of 4.13 it is quite stable kde-testing usually has the same packaging as updates-testing yum --enablerepo=kde-unstable update Obsoleted By: kactivities-libs-4.13.2-1.fc20.x86_64 (kde-unstable) Not found besides 4.13 in the meantime is on kde-testing what about report something useful instead one line out of context and stay at k...@lists.fedoraproject.org? OK I will switch to k...@lists.fedoraproject.org in meantime I found the problem was with kde\*.i686 Thanks for you reply , -- 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
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On 10 Jul 2014, at 07:04, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2014 05:08 PM, Matthew Miller wrote: On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote: I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work. A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed? * dredges up meeting logs -- http://meetbot.fedoraproject.org/teams/server-wg/server-wg. 2014-02-25-16.00.html That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: 4. There would be, at least, a net install CD to install a traditional non-productized Fedora system. A minimal netinstall would be ok if there is a simple way to replace the productized fedora-release package with a plain, non- productized fedora-release package. In saying that, I am making an assumption that, once the fedora- release package is switched out, then any product requirements or constraints would disappear and the system would be a traditional, non-productized Fedora system that could then be configured however the system administrator chose. Is that assumption wrong? Thanks. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Upgrade OpenSceneGraph to 3.2.1
Hi, I intend to upgrade OpenSceneGraph to 3.2.1 (Jul 4th) on rawhide. This change will introduce SONAME bumps in OpenSceneGraph-provided libraries and thus is likely to introduce broken package dependencies. I intend to take care about these and to launch rebuilds where necessary. Depending on how well things work out, I am considering to also upgrade on f21, but it's too early to have a strong opinion on this. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2014 09:53 AM, Mike Pinkerton wrote: On 10 Jul 2014, at 07:04, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/09/2014 05:08 PM, Matthew Miller wrote: On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote: I do not know which or if any Spins will be providing the specific net install CD you're asking about. This will not be an *official* (read: tested by QA) method of installing Fedora. However, I see no reason why it wouldn't work. A few months ago* I remember the server WG talking about providing a minimal/netinstall image. Has this changed? * dredges up meeting logs -- http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00.html That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: 4. There would be, at least, a net install CD to install a traditional non-productized Fedora system. A minimal netinstall would be ok if there is a simple way to replace the productized fedora-release package with a plain, non-productized fedora-release package. In saying that, I am making an assumption that, once the fedora-release package is switched out, then any product requirements or constraints would disappear and the system would be a traditional, non-productized Fedora system that could then be configured however the system administrator chose. Is that assumption wrong? Thanks. That is the intent of the design, yes. We're dealing with some real-world issues with that (namely that the way dependency-processing works in yum and dnf has issues with this), so it may require us to code up a special tool to switch from productized to non-productized and vice-versa. Stop reading now if you don't care about minutia: Basically, in order to swap out the productized and non-productized release packages, it's not actually as simple as 'yum swap fedora-release-standard fedora-release-server'. The way the dependency processing works in yum and dnf will generally fall over and fail to properly detect the other packages that would need to be swapped (such as firewalld-config-standard - firewalld-config-server). So what we will probably need to do is write a tool that will examine the RPM database for all product-specific packages and swap them in a single transaction. This is hard to do *generically*, but if everyone sticks with the convention mandated by my proposed Draft, it becomes a pattern-match instead of a deep dependency comparison (which is probably good enough for the first pass). There's also a significant hope that future RPM enhancements (with complex and powerful deps like if foo is installed, then install bar) will allow us to make this a much more simple process. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO+pFkACgkQeiVVYja6o6NlYQCdG8Ht54cjvmL7Gyil0JjJwNTW RLUAn1A7f6Q/t4VzO+9Z5zHHJtQeCqBk =Exps -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: F-21 Branched report: 20140710 changes
Are we going to have empty updates and updates-testing repos for branched this time around? This affects the spin-kickstarts package (and possibly the release packages) as normally we want updates enabled, but if there isn't going to be an updates repo for a while, then we'll need to disable it for now and then do update after the repository becomes available. -- 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: (Rawhide users) Fedora 22 branching: What You Need To Know
On Wed, Jul 09, 2014 at 23:37:39 -0700, Adam Williamson adamw...@fedoraproject.org wrote: sudo yum-config-manager --enable fedora and, optionally, enable updates-testing: sudo yum-config-manager --enable updates-testing The updates-testing repo isn't there yet. I am hoping we get empty repos created for both updates and updates-testing now. (updates-testing will be getting used soon, and having an empty updates repo is useful for avoiding configuration changes between switching to branched and the release.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Wed, Jul 09, 2014 at 10:30:27AM -0400, Miloslav Trmač wrote: - Original Message - Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I wrote up a Change: https://fedoraproject.org/wiki/Changes/SystemdSysusers A move to something more declarative makes sense (whether in systemd or through some kind of long-expected declarative rpm facility doesn’t matter to me much.) The sysusers tool _really_ needs to use an existing API to manage the user database, though. As it is, the implementation * validates names incorrectly * breaks the configurable [UG]ID_MIN logic (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that is actually used and needed) * is likely to break various readers software by not updating the shadow files * doesn’t do any auditing. We are currently already in a bad position by having two major implementations of maintaining the critical databases, we absolutely don’t want any more. At this point this means systemd-sysuers should either run the executables from shadow-utils, or link to libuser. (Or, I suppose, use accountsservice, but that ends up calling shadow-utils.). The plan is to have a single implementation, living around sssd. (Jakub knows more.) Either of two API points above are planned to use the sssd implementation, so can be relied on long-term. Mirek The effort Mirek is talking about (a not-too-detailed design page can be found at [1]) aims at a) using the SSSD database primarily for user accounts and b) providing a rich DBus API. We actually started with b) because that's also usable and useful for remote (LDAP, AD, ..) users which SSSD already handles. The benefit of using the SSSD database would be the ability of use a richer set of attributes that the passwd file has. The API would be usable in a similar fashion accountsservice is now. Even though SSSD would be in the business of managing local users, I think the benefits of using SSSD are mostly for managing non-system accounts. So from this point of view, I don't see what systemd is doing as conflicting with what we plan on doing. One issue to keep in mind is that we planned on reverting the order of the NSS modules to sss files. Given that systemd-sysusers would write to the files directly with the libc API, we need to sync the changes systemd-sysusers to SSSD database, otherwise we risk inconsistencies and there would also be an extra round-trip to nss_sss before reaching to nss_files. We /do/ plan on the syncing anyway, because some admins are still used to vipw their passwd databases and there are legacy scripts around, but still -- could we, when the SSSD interface is available, call out from systemd-sysusers to the SSSD, with some fallback for cases where SSSD is not running? Are there any plans on changing any of the shadow-utils commands to call out to systemd-sysusers when adding system users with either useradd (useradd -r) or libuser? btw I completely agree that even when we switch to using SSSD to manage local accounts, the system must still be usable (sans the extra attributes and the rich API..), if SSSD wasn't able to start for example. [1] https://fedorahosted.org/sssd/wiki/DesignDocs/UsrAccountMgmtConsolidation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Thu, Jul 10, 2014 at 07:04:21AM -0400, Stephen Gallagher wrote: http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00.html That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: 4. There would be, at least, a net install CD to install a traditional non-productized Fedora system. Which totally makes sense from the Server WG pov, of course. Digging further into the logs, I find 16:42:53 nirik mitr: I guess I'd be ok with that... then leave netinstall for base Since I know Base has decided to include anaconda in their circle, I'm going to ask if that group is interested in producing a non-productized minimal netinstall -- possibly as a spin. If they're not, this is probably a help wanted for someone else interested in this existing. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, Jul 10, 2014, at 05:42 AM, Lennart Poettering wrote: Two examples from the top of my head: * Some tftpd implementations use it as the base path (and chroot into it) * Some anonymous ftpd implementation have similar use (chroot into ~ftp) But these aren't really usable without configuration, no? Now many server packages do have default configuration pointing to a default data store (e.g. apache and /var/www/html), but I think there's a reasonable expectation that the majority of sites customize this. Hmm, actually though since sysusers defaults to /, that would presumably mean the default ftp server install would serve up the entire OS, which is probably not desired. Lennart, what about changing the default to /var/empty or so? Interesting, httpd appears to default to /usr/share/httpd for its home directory, not /var/www/ as I would have expected. The gdm user also kinda needs a home directory. This one is special enough that I think alternatively we could have GDM use a compiled-in default of $localstatedir/lib/gdm if the home directory is the default. (Leading to the question of what the default should be). I'm just thinking out loud - maybe it's easiest to add the home directory field. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Comps group for Fedora Audio Spin packages
Hi all, does anyone have any objection to a new comps group containing packages currently present in the Fedora Jam audio spin? We will be discussing names further within the music creation SIG / fedora-music mailing list soon, but Audio Production or Music Creation are two that immediately spring to mind. Suggestions welcome. regards Brendan -- 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: Comps group for Fedora Audio Spin packages
I'd be game Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine On Thu, Jul 10, 2014 at 11:44 AM, Brendan Jones brendan.jones...@gmail.com wrote: Hi all, does anyone have any objection to a new comps group containing packages currently present in the Fedora Jam audio spin? We will be discussing names further within the music creation SIG / fedora-music mailing list soon, but Audio Production or Music Creation are two that immediately spring to mind. Suggestions welcome. regards Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On 07/10/2014 05:22 PM, Matthew Miller wrote: On Thu, Jul 10, 2014 at 07:04:21AM -0400, Stephen Gallagher wrote: http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00.html That's why I said the *specific* netinstall he was asking for. The Fedora Server netinstall wouldn't be producing a non-productized result, which is what he asked for: 4. There would be, at least, a net install CD to install a traditional non-productized Fedora system. Which totally makes sense from the Server WG pov, of course. Digging further into the logs, I find 16:42:53 nirik mitr: I guess I'd be ok with that... then leave netinstall for base Since I know Base has decided to include anaconda in their circle, I'm going to ask if that group is interested in producing a non-productized minimal netinstall -- possibly as a spin. If they're not, this is probably a help wanted for someone else interested in this existing. With my Workstation WG member hat on: if Base is willing to pick up netinstall (both the boot.iso and PXE), we would love that. We originally wanted to ship only the live media for F21 Workstation, but releng convinced us (or forced might be a better word :-) to ship netinstall as well. Releng's reasoning was that we can't leave it out of Workstation because otherwise Fedora would have no working netinstall. Which makes a lot of sense on one hand, but on the other hand a netinstall that can only install Workstation might not be what users expect. If there's an option of producing a generic, non-productized netinstall, that would be best and we would be able to drop this from Workstation. -- Thanks, 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: (Rawhide users) Fedora 22 branching: What You Need To Know
On 10.07.2014 13:11, Stephen Gallagher wrote: One thing I discovered last night. There's a bug with the new fedora-release packages and yum/dnf are kind of arbitrarily picking from fedora-release-[standard|cloud|server|workstation] to install if you just update. (This is in large part because these are just placeholder packages and don't have any content in them yet). To avoid issues going forward, before you do the distro-sync above, you probably want to 'yum install fedora-release-$something' where $something is either 'standard' (for non-productized Fedora) or one of the Products, which your environment will evolve more into the closer we get to Alpha. I'll try to work out what we need to do to make that transition cleaner from F20-F21, but for Rawhide-F21 it's going to be a bit manual for a while. # grep fedora-release /var/log/yum.log ... Updated: fedora-release-21-0.9.noarch ... Erased: fedora-release-rawhide-21-0.7.noarch Is this enough to stay on F21 or I still need e.g. 'fedora-release-standard' for non-product-specific, that is as we use now on Fedora 20? poma -- 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: rawhide report: 20140710 changes
On Thu, Jul 10, 2014 at 4:42 AM, Fedora Rawhide Report rawh...@fedoraproject.org wrote: sssd-1.12.0-1.fc21 -- * Wed Jul 09 2014 Jakub Hrozek jhro...@redhat.com - 1.12.0-1 - New upstream release 1.12.0 - https://fedorahosted.org/sssd/wiki/Releases/Notes-1.12.0 The previous version was 1.12.0-4.fc21.beta2. $ rpmdev-vercmp sssd-1.12.0-4.fc21.beta2 sssd-1.12.0-1.fc21 sssd-1.12.0-4.fc21.beta2 sssd-1.12.0-1.fc21 So yum update will not install the new version for those with the previous version already installed. You'll have to bump the release number to at least 5 to fix this. The real problem is that the proper versioning scheme for beta releases was not followed. See https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages. -- Jerry James http://www.jamezone.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: F-21 Branched report: 20140710 changes
Another thing that seems odd today is that no rpms in this morning's rawhide repo have fc22 in their names. I would have expected this morning's build to have started enough after branching to pick up at least a few fc22 builds. I'll be more worried if this persists in tomorrow's rawhide, but figured I'd ask about it today to get things fixed sooner if something is really broken. -- 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: F-21 Branched report: 20140710 changes
On Thu, 10 Jul 2014 11:18:23 -0500 Bruno Wolff III br...@wolff.to wrote: Another thing that seems odd today is that no rpms in this morning's rawhide repo have fc22 in their names. I would have expected this morning's build to have started enough after branching to pick up at least a few fc22 builds. I'll be more worried if this persists in tomorrow's rawhide, but figured I'd ask about it today to get things fixed sooner if something is really broken. I noticed this a bit ago and just finished tracking it down. We need a mash update to get rawhide to do the right thing. So, today, rawhide was composed from f21. Which means its exactly the same as branched. ;( We will get mash fixed today and tomorrow rawhide should return to normal. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F-21 Branched report: 20140710 changes
On Thu, 10 Jul 2014 10:03:05 -0500 Bruno Wolff III br...@wolff.to wrote: Are we going to have empty updates and updates-testing repos for branched this time around? This affects the spin-kickstarts package (and possibly the release packages) as normally we want updates enabled, but if there isn't going to be an updates repo for a while, then we'll need to disable it for now and then do update after the repository becomes available. Yes, we will get these created soon. Sorry for the trouble. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: (Rawhide users) Fedora 22 branching: What You Need To Know
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2014 11:45 AM, poma wrote: On 10.07.2014 13:11, Stephen Gallagher wrote: One thing I discovered last night. There's a bug with the new fedora-release packages and yum/dnf are kind of arbitrarily picking from fedora-release-[standard|cloud|server|workstation] to install if you just update. (This is in large part because these are just placeholder packages and don't have any content in them yet). To avoid issues going forward, before you do the distro-sync above, you probably want to 'yum install fedora-release-$something' where $something is either 'standard' (for non-productized Fedora) or one of the Products, which your environment will evolve more into the closer we get to Alpha. I'll try to work out what we need to do to make that transition cleaner from F20-F21, but for Rawhide-F21 it's going to be a bit manual for a while. # grep fedora-release /var/log/yum.log ... Updated: fedora-release-21-0.9.noarch ... Erased: fedora-release-rawhide-21-0.7.noarch Is this enough to stay on F21 or I still need e.g. 'fedora-release-standard' for non-product-specific, that is as we use now on Fedora 20? You'll want to install fedora-release-standard manually right now to make sure you have the right version going forward. We're working to figure out how to get that to install by default on upgrades. (Alternately, feel free to use -server or -workstation as well, if you want to move towards that environment going forward). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO+v9EACgkQeiVVYja6o6MljQCfVIJIkDciuOTuF6KpS4oJfeI2 8vgAoKpAYPpJZ91bQ4HqgQy4mfmcheFd =MKnn -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On 07/10/2014 04:34 PM, Stephen Gallagher wrote: Basically, in order to swap out the productized and non-productized release packages, it's not actually as simple as 'yum swap fedora-release-standard fedora-release-server'. The way the dependency processing works in yum and dnf will generally fall over and fail to properly detect the other packages that would need to be swapped (such as firewalld-config-standard - firewalld-config-server). dnf seems able to figure out even the firewalld-config-* swap fine: $ sudo dnf install fedora-release-workstation --allowerasing Dependencies resolved. Package Arch Version Repository Size Installing: fedora-release-workstation noarch21-0.9 rawhide 17 k firewalld-config-workstationnoarch0.3.10-4.fc21 rawhide 40 k Removing: fedora-release-server noarch21-0.9 @System1.0 k firewalld-config-server noarch0.3.10-4.fc21 @System1.0 k Transaction Summary Install 2 Packages Remove 2 Packages Total download size: 57 k Is this ok [y/N]: ... 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: F-21 Branched report: 20140710 changes
On Thu, Jul 10, 2014 at 10:25:48 -0600, Kevin Fenzi ke...@scrye.com wrote: We will get mash fixed today and tomorrow rawhide should return to normal. Thanks for taking care of this and the updates/updates-testing repos. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2014 12:45 PM, Michal Schmidt wrote: On 07/10/2014 04:34 PM, Stephen Gallagher wrote: Basically, in order to swap out the productized and non-productized release packages, it's not actually as simple as 'yum swap fedora-release-standard fedora-release-server'. The way the dependency processing works in yum and dnf will generally fall over and fail to properly detect the other packages that would need to be swapped (such as firewalld-config-standard - firewalld-config-server). dnf seems able to figure out even the firewalld-config-* swap fine: $ sudo dnf install fedora-release-workstation --allowerasing Dependencies resolved. Package Arch Version Repository Size Installing: fedora-release-workstation noarch21-0.9 rawhide 17 k firewalld-config-workstationnoarch 0.3.10-4.fc21 rawhide 40 k Removing: fedora-release-server noarch21-0.9 @System1.0 k firewalld-config-server noarch 0.3.10-4.fc21 @System1.0 k Transaction Summary Install 2 Packages Remove 2 Packages Total download size: 57 k Is this ok [y/N]: ... Michal Ok, that's really good to know. Yum however does not resolve this correctly, and yum is our default package manager. I just tried: [sgallagh@sgallagh540:~]$ sudo yum install fedora-release-server - --disablerepo=fedora --disablerepo=updates --enablerepo=rawhide - --disablerepo=updates-testingLoaded plugins: auto-update-debuginfo, langpacks bluejeans | 2.9 kB 00:00 google-chrome | 951 B 00:00 sgallagh-chrome-compat-libgcrypt| 3.0 kB 00:00 Resolving Dependencies - -- Running transaction check - --- Package fedora-release-server.noarch 0:21-0.9 will be installed - -- Processing Conflict: fedora-release-workstation-21-0.9.noarch conflicts fedora-release-server - -- Processing Conflict: fedora-release-server-21-0.9.noarch conflicts fedora-release-workstation - -- Finished Dependency Resolution Error: fedora-release-workstation conflicts with fedora-release-server-21-0.9.noarch Error: fedora-release-server conflicts with fedora-release-workstation-21-0.9.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest And also: [sgallagh@sgallagh540:~]$ sudo yum swap fedora-release-workstation fedora-release-server --disablerepo=fedora --disablerepo=updates - --enablerepo=rawhide --disablerepo=updates-testing Loaded plugins: auto-update-debuginfo, langpacks (1/2): rawhide/x86_64/primary_db| 17 MB 00:02 (2/2): rawhide-debuginfo/x86_64/primary_db | 1.7 MB 00:06 Resolving Dependencies - -- Running transaction check - --- Package fedora-release-server.noarch 0:21-0.9 will be installed - --- Package fedora-release-workstation.noarch 0:21-0.9 will be erased - -- Processing Dependency: system-release-workstation for package: firewalld-config-workstation-0.3.10-4.fc21.noarch - -- Running transaction check - --- Package firewalld-config-workstation.noarch 0:0.3.10-4.fc21 will be erased - -- Processing Dependency: firewalld-config for package: firewalld-0.3.10-4.fc21.noarch - -- Running transaction check - --- Package firewalld.noarch 0:0.3.10-4.fc21 will be erased - -- Processing Dependency: firewalld = 0.3.10-4.fc21 for package: firewall-config-0.3.10-4.fc21.noarch - -- Running transaction check - --- Package firewall-config.noarch 0:0.3.10-4.fc21 will be erased - -- Finished Dependency Resolution Dependencies Resolved Package Arch Version RepositorySize Installing: fedora-release-server noarch21-0.9rawhide 17 k Removing: fedora-release-workstation noarch21-0.9installed 1.0 k Removing for dependencies: firewall-config noarch0.3.10-4.fc21 installed 778 k firewalld noarch0.3.10-4.fc21 installed 2.1 M firewalld-config-workstationnoarch0.3.10-4.fc21 installed 1.0 k Transaction Summary Install 1 Package Remove 1 Package (+3 Dependent packages) Total download size: 17 k Is this ok [y/d/N]: n Exiting on user command Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2014-07-10.12-49.uQjUpN.yumtx
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, 2014-07-10 at 17:18 +0200, Jakub Hrozek wrote: We /do/ plan on the syncing anyway, because some admins are still used to vipw their passwd databases and there are legacy scripts around, but still -- could we, when the SSSD interface is available, call out from systemd-sysusers to the SSSD, with some fallback for cases where SSSD is not running? Jakub, I think we can use inotify on /etc/passwd and friends and reread if someone modifies the file. The important thing is that people don't try to invent new storage schemes and additional nsswitch modules and files for the system users. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, Jul 10, 2014 at 12:44:29PM -0400, Simo Sorce wrote: On Thu, 2014-07-10 at 17:18 +0200, Jakub Hrozek wrote: We /do/ plan on the syncing anyway, because some admins are still used to vipw their passwd databases and there are legacy scripts around, but still -- could we, when the SSSD interface is available, call out from systemd-sysusers to the SSSD, with some fallback for cases where SSSD is not running? Jakub, I think we can use inotify on /etc/passwd and friends and reread if someone modifies the file. Yeah, but the callback from systemd-sysusers could tell you all the info right away. But as I said earlier, we're going to need to re-read and sync anyway for the vipw case, so it's probably a moot point.. The important thing is that people don't try to invent new storage schemes and additional nsswitch modules and files for the system users. Simo. Right. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, 10.07.14 12:44, Simo Sorce (s...@redhat.com) wrote: On Thu, 2014-07-10 at 17:18 +0200, Jakub Hrozek wrote: We /do/ plan on the syncing anyway, because some admins are still used to vipw their passwd databases and there are legacy scripts around, but still -- could we, when the SSSD interface is available, call out from systemd-sysusers to the SSSD, with some fallback for cases where SSSD is not running? Jakub, I think we can use inotify on /etc/passwd and friends and reread if someone modifies the file. This is not that easy actually as it sounds, because you need to be able to cover the case where the passwd file is replaced by a different one (which is actually the common case, since that's what makes updates to the file atomic). But inotify is not particulraly nice for doing that, especially if you want to cover the state where the file missing is missing entirely... In that case you'd have to watch all of /etc, which of course is something to avoid, since you might get woken up quite a bit too frequently. My suggestion would be to simply check the mtime of /etc/passwd on each query you get (well, but not more often than once per 1s or so), and reread the file if the mtime changed. That way you have to issue one stat() call every 1s if you are busy, and do nothing if you are not. Which sounds like a good deal. Much simpler and safer than inotify. 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: (Rawhide users) Fedora 22 branching: What You Need To Know
On 10.07.2014 18:31, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2014 11:45 AM, poma wrote: On 10.07.2014 13:11, Stephen Gallagher wrote: One thing I discovered last night. There's a bug with the new fedora-release packages and yum/dnf are kind of arbitrarily picking from fedora-release-[standard|cloud|server|workstation] to install if you just update. (This is in large part because these are just placeholder packages and don't have any content in them yet). To avoid issues going forward, before you do the distro-sync above, you probably want to 'yum install fedora-release-$something' where $something is either 'standard' (for non-productized Fedora) or one of the Products, which your environment will evolve more into the closer we get to Alpha. I'll try to work out what we need to do to make that transition cleaner from F20-F21, but for Rawhide-F21 it's going to be a bit manual for a while. # grep fedora-release /var/log/yum.log ... Updated: fedora-release-21-0.9.noarch ... Erased: fedora-release-rawhide-21-0.7.noarch Is this enough to stay on F21 or I still need e.g. 'fedora-release-standard' for non-product-specific, that is as we use now on Fedora 20? You'll want to install fedora-release-standard manually right now to make sure you have the right version going forward. Done deal, thanks. We're working to figure out how to get that to install by default on upgrades. Good luck with that! (Alternately, feel free to use -server or -workstation as well, if you want to move towards that environment going forward). Those two goes camping in virtwood. :) poma -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
empty .bash_history
I've a system that's zeroing out .bash_history at every reboot. Is this happening to everyone? Intended? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4
On Thu, 2014-07-10 at 12:35 +0200, Till Maas wrote: On Wed, Jul 09, 2014 at 10:19:52PM -0700, Adam Williamson wrote: ddclient seems to have been retired apparently as a part of this process, going by the commit: http://pkgs.fedoraproject.org/cgit/ddclient.git/commit/?id=f741436ca38fd6c36ffbfbb26b3131b278657faa but it wasn't listed in this email. Was that an oversight? Was it listed somewhere else I didn't catch? It does show up as 'orphaned' in pkgdb: https://admin.fedoraproject.org/pkgdb/package/ddclient/ . It was retired as it was shown on the right hand side of the page. It was orphaned after I wrote the final email, therefore it was not additionally announced: https://apps.fedoraproject.org/datagrepper/id?id=2014-e7f2c941-6718-4adf-8e07-849e83368956is_raw=truesize=extra-large I unretired it in pkgdb/koji, so you can restore it in dist-git. However a F21 branch is missing and needs to be requested via an SCM admin request. Sorry, I should've been clear - I personally don't want to resurrect it, it's just that someone asked on IRC how they could find out why it was dropped, and as I investigated, I noticed that I couldn't find an announcement for it on devel@. thanks for the info! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rawhide users: ceph packaging issues
I just thought it'd be good to alert Fedora 21 and 22 users to this issue. Some major changes were introduced to the 'ceph' package in the 0.81.0-3 build, and maintained in the 0.81.0-4 build. These builds were done for all current releases, but not submitted as updates to any stable release, so likely only people tracking Rawhide got them. -3 and -4 werre in Rawhide for about a week from July 1 to July 7, so it's pretty likely all Rawhide users wound up with them. The major changes involved a lot of packages being renamed. It seems that the major changes were actually intended only for F22, not for F21 or earlier. So the build 0.81.0-5 was done, which reverts the package to the state of 0.81.0-2 , with the old package organization. However, this really was simply a reversion. No Obsoletes: were introduced to make sure that those who got the -3 or -4 packages would get the new-old -5 packages as updates. For instance, I have three packages from the 0.81.0-4 build installed: [adamw@adam x86_64]$ rpm -qa | grep 0.81.0-4 librados2-0.81.0-4.fc21.x86_64 librbd1-0.81.0-4.fc21.x86_64 libcephfs1-0.81.0-4.fc21.x86_64 my repos have the 0.81.0-5 build: [adamw@adam x86_64]$ sudo yum info ceph ceph-libs Loaded plugins: auto-update-debuginfo, langpacks Available Packages ... Name: ceph Arch: x86_64 Version : 0.81.0 Release : 5.fc21 ... Name: ceph-libs Arch: x86_64 Version : 0.81.0 Release : 5.fc21 , but when I do a yum update, none of those packages is going to be replaced with a 0.81.0-5 build: [adamw@adam x86_64]$ sudo yum update ... No packages marked for update because no Obsoletes are in place to ensure this. Basically, if you got the -3 or -4 builds, you're stuck with them, unless the package gets fixed. This is somewhat important because the -4 build (and I'm presuming the -3 build) has an executable stack violation in librados2, which causes virtual machine launches to fail: https://bugzilla.redhat.com/show_bug.cgi?id=1118504 so, yeah, bit of a mess. You can probably get onto the 0.81.0-5 packages manually with a bit of judicious --nodeps use or 'yum shell' use, but it'd be best if the packages were fixed up, and I figured I'd let folks know about the problem for now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide users: ceph packaging issues
On Thu, 2014-07-10 at 15:34 -0700, Adam Williamson wrote: so, yeah, bit of a mess. You can probably get onto the 0.81.0-5 packages manually with a bit of judicious --nodeps use or 'yum shell' use, but it'd be best if the packages were fixed up, and I figured I'd let folks know about the problem for now. Sigh, just realized I forgot to mention that I have reported this issue as a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1118510 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: (Rawhide users) Fedora 22 branching: What You Need To Know
I'm ready to start my application testing on a Fedora 21 virtual machine. What's the quickest way for me to get one built? Is there a 'net install' ISO file somewhere I can use? On Thu, Jul 10, 2014 at 11:38 AM, poma pomidorabelis...@gmail.com wrote: On 10.07.2014 18:31, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2014 11:45 AM, poma wrote: On 10.07.2014 13:11, Stephen Gallagher wrote: One thing I discovered last night. There's a bug with the new fedora-release packages and yum/dnf are kind of arbitrarily picking from fedora-release-[standard|cloud|server|workstation] to install if you just update. (This is in large part because these are just placeholder packages and don't have any content in them yet). To avoid issues going forward, before you do the distro-sync above, you probably want to 'yum install fedora-release-$something' where $something is either 'standard' (for non-productized Fedora) or one of the Products, which your environment will evolve more into the closer we get to Alpha. I'll try to work out what we need to do to make that transition cleaner from F20-F21, but for Rawhide-F21 it's going to be a bit manual for a while. # grep fedora-release /var/log/yum.log ... Updated: fedora-release-21-0.9.noarch ... Erased: fedora-release-rawhide-21-0.7.noarch Is this enough to stay on F21 or I still need e.g. 'fedora-release-standard' for non-product-specific, that is as we use now on Fedora 20? You'll want to install fedora-release-standard manually right now to make sure you have the right version going forward. Done deal, thanks. We're working to figure out how to get that to install by default on upgrades. Good luck with that! (Alternately, feel free to use -server or -workstation as well, if you want to move towards that environment going forward). Those two goes camping in virtwood. :) poma -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick http://j.mp/CompJournoStickOverview You can catch more flies with a sticky tongue than you can with vinegar. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
Thank you both for your response. It's appreciated. * Files in systemd's sysusers configuration directory will be used as a data source to create /etc/passwd and /etc/shadow. Also, /etc/group and /etc/gshadow. Under what conditions are these two files created / touched? Three triggers: 1. When the systemd-sysusers tool is invoked from an RPM scriplet, which I hope can be made the default in Fedora for all packages needing system users. 2. At boot on systems which are set up in a golden master scheme, where a single /usr is used for a number of instances which each have their own /etc and /var. Similar, on stateless systems which boot up with tmpfs on /etc and /var, and hence start from scracth every single time. Note though that Fedora is not set up for this fully yet (though it actually works prettty good already, with the two exceptions in the basic OS being PAM and dbus-1, which react quite allergic to an unpopulated /etc). 3. Similar to 2, but people who instantiate new systems from the same /usr in an offline scheme, where they don't delay user creation to the next reboot. Note however, that sysusers will only do something if any of the specified users is actually missing. We arevery careful in not touching the file system if all users already exist. Also, if the disk is read-only sysusers is automatically skipped at boot. At a later time I will propose fixing Fedora to make the stateless + golden master schemes just work. But I am not ready to discuss this in full now. When I install a package and add a file to this sysuser directory, is only that user added to passwd and shadow? For each user you create with sysusers a matching group will be created too, should it be missing. Is there a way to disable or remove a system user from being added to /etc/shadow? No. What's the usecase? Does this currently exist for the RPM scriptlet case? ATM there is no use case, but there will surely be one person who will cry out if this is unavailable. I would rather have it clearly stated on a wiki / FAQ, so that when someone in the future asks for this, there is a clear answer stated. I'm a fan of documenting and covering these edge cases is all :) Are changes to shadow/passwd made by a user respected / preserved (IE to a user account)? Yes. Always. sysuers will never touch existing users, it will only add in missing ones, with secure defaults (i.e. as disabled accounts, with no login possible). For exmple, if you assign a shell or a password to one of those system users, then that's totally OK, sysusers will stay away from that, never reset it, never touch it. What happens if a human edits the system account generated by systemd, do the changes get lost? Nope, what the admin changes will take effect. The only thing that might happen that if you delete a user it might be recreated the next time sysusers runs. Thanks for all your answers. Do you mind adding them to an section on https://fedoraproject.org/wiki/Changes/SystemdSysusers So that others can benefit from them? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Thu, 2014-07-10 at 08:35 -0700, Colin Walters wrote: On Thu, Jul 10, 2014, at 05:42 AM, Lennart Poettering wrote: Two examples from the top of my head: * Some tftpd implementations use it as the base path (and chroot into it) * Some anonymous ftpd implementation have similar use (chroot into ~ftp) But these aren't really usable without configuration, no? Now many server packages do have default configuration pointing to a default data store (e.g. apache and /var/www/html), but I think there's a reasonable expectation that the majority of sites customize this. I strongly disagree: Most sites would use these directories else they fall into the SELinux labeling trap. So setting such a home drive is a good thing to assist with SELinux policy creation etc. Hmm, actually though since sysusers defaults to /, that would presumably mean the default ftp server install would serve up the entire OS, which is probably not desired. Lennart, what about changing the default to /var/empty or so? Interesting, httpd appears to default to /usr/share/httpd for its home directory, not /var/www/ as I would have expected. The gdm user also kinda needs a home directory. This one is special enough that I think alternatively we could have GDM use a compiled-in default of $localstatedir/lib/gdm if the home directory is the default. (Leading to the question of what the default should be). I'm just thinking out loud - maybe it's easiest to add the home directory field. I think that Lennart's solution of the home directory configuration option is the way to go given the SELinux labeling above, and that some people do enjoy systems like ftp just working (tm) -- William will...@firstyear.id.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
touchpad event data requested - palm detection
We're currently working on a number of things to improve input devices in libinput - the future input stack for wayland developers. What we need is data to base our assumptions on, so I'm hereby asking the list to provide some. If you don't have a touchpad, please disregard this email. If you're on RHEL or a derivative, F18 or older, please disregard this demail. One focus at the moment is palm detection. If you have a couple of minutes to spare, please run the following command: $ sudo evemu-record /dev/input/event4 palm-data.txt substitute event4 with the kernel device of your touchpad, running evemu-record without arguments will give you a list. While evemu is running, DO NOT use the touchpad. Use your laptop normally otherwise (you can use a mouse where needed, only the touchpad events are recorded). Ideally, use your keyboard because what we're looking for are events generated when you're not actually using the touchpad. Once completed, ctrl+c evemu-record. Again, please DO NOT use the touchpad while the recording is active or the data will be difficult/impossible to analyse. You can re-run evemu-record if you don't think the data set is good enough. Once you're done please go through the following steps: Verify that the txt file contains data: $ grep -q ^E: palm-data.txt echo all clear || echo no data If no data is available, please re-run evemu-record (see the F19/F20 comment below though) Record your kernel version and machine information: $ uname -r device-info.txt $ cat /sys/class/dmi/id/modalias device-info.txt Create a tarball of the data: $ tar jcf palm-data.tar.bz2 palm-data.txt device-info.txt Please use the output of this command for the subject line of your email: $ echo PALMDATA: `cat /sys/class/dmi/id/product_version` This helps identify data sets so we can have good coverage. Emails with a non-matching subject line will be deleted automatically. Attach the tarball and send it to libinputdatacollect...@gmail.com Thanks in advance! == Why do we need this? == While typing on a laptop keyboard, accidental contacts may happen on the touchpad. This can create spurious movements or even tapping/clicking events. To avoid it, we need software-detection for palms. There are a lot of different touchpads out there with different capabilities and sizes. Thus, events look different on those touchpads and we need to figure out how to find common denominators to identify palms. The only way to do this is to look at as many data sets as possible. == A note on Fedora 19 and 20 == On Fedora 19 and Fedora 20, you will not see events on the touchpad device. You need to restart X with the configuration snippet in place below: $ cat /etc/X11/xorg.conf.d/99-synaptics-dontgrab.conf Section InputClass Identifier synaptics don't grab MatchDriver synaptics Option GrabEventDevice off EndSection On F21+ this is the driver default (xorg-x11-drv-synaptics = 1.8) and the snippet is not needed. If you're on RHEL or a derivative, F18 or older, please disregard this email. == A note on security == evemu-record collects events only from the given device and records it in a plain-text format. If you set it to your keyboard, all keys pressed will be visible in the order they were pressed. This can leak passwords, so DO NOT record your keyboard device! If you set it to your touchpad as requested, no key events are recorded. You can verify the data collected by looking at the output file. evemu-record does not send or receive data and requires you actively emailing the data. If you do not want to run evemu-record as root, simply chmod the event file for reading. == A note on privacy == Events from your touchpad cannot usually personally identify you, and neither can the kernel version nor the DMI data. This process is opt-in, you need to actively email the data. Your email can personally identify you, but we won't use the email addresses for anything. The data you send (i.e. the tarball) will be used for analysis and will be made publicly available to others to do analysis. At this point, only I have access to that gmail account but I may extend this to others involved with libinput. If you feel uncomfortable with any of this, simply don't participate. Cheers, Peter pgpWC0wlAWHid.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: New Fedora 22 Change proposal: systemd-sysusers
On Fri, Jul 11, 2014 at 09:05:29AM +0930, William wrote: Thank you both for your response. It's appreciated. * Files in systemd's sysusers configuration directory will be used as a data source to create /etc/passwd and /etc/shadow. Also, /etc/group and /etc/gshadow. Under what conditions are these two files created / touched? Three triggers: 1. When the systemd-sysusers tool is invoked from an RPM scriplet, which I hope can be made the default in Fedora for all packages needing system users. 2. At boot on systems which are set up in a golden master scheme, where a single /usr is used for a number of instances which each have their own /etc and /var. Similar, on stateless systems which boot up with tmpfs on /etc and /var, and hence start from scracth every single time. Note though that Fedora is not set up for this fully yet (though it actually works prettty good already, with the two exceptions in the basic OS being PAM and dbus-1, which react quite allergic to an unpopulated /etc). 3. Similar to 2, but people who instantiate new systems from the same /usr in an offline scheme, where they don't delay user creation to the next reboot. Note however, that sysusers will only do something if any of the specified users is actually missing. We arevery careful in not touching the file system if all users already exist. Also, if the disk is read-only sysusers is automatically skipped at boot. At a later time I will propose fixing Fedora to make the stateless + golden master schemes just work. But I am not ready to discuss this in full now. When I install a package and add a file to this sysuser directory, is only that user added to passwd and shadow? For each user you create with sysusers a matching group will be created too, should it be missing. Is there a way to disable or remove a system user from being added to /etc/shadow? No. What's the usecase? Does this currently exist for the RPM scriptlet case? ATM there is no use case, but there will surely be one person who will cry out if this is unavailable. I would rather have it clearly stated on a wiki / FAQ, so that when someone in the future asks for this, there is a clear answer stated. I'm a fan of documenting and covering these edge cases is all :) http://cgit.freedesktop.org/systemd/systemd/commit/?id=938a560b76 adds the usual semantics of etc-overrides-run-overrides-lib. Are changes to shadow/passwd made by a user respected / preserved (IE to a user account)? Yes. Always. sysuers will never touch existing users, it will only add in missing ones, with secure defaults (i.e. as disabled accounts, with no login possible). For exmple, if you assign a shell or a password to one of those system users, then that's totally OK, sysusers will stay away from that, never reset it, never touch it. What happens if a human edits the system account generated by systemd, do the changes get lost? Nope, what the admin changes will take effect. The only thing that might happen that if you delete a user it might be recreated the next time sysusers runs. Thanks for all your answers. Do you mind adding them to an section on https://fedoraproject.org/wiki/Changes/SystemdSysusers So that others can benefit from them? It is now described in the man page, which is linked from the wiki page. Zbyszek -- 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: (Rawhide users) Fedora 22 branching: What You Need To Know
On Thu, 2014-07-10 at 16:00 -0700, M. Edward (Ed) Borasky wrote: I'm ready to start my application testing on a Fedora 21 virtual machine. What's the quickest way for me to get one built? Is there a 'net install' ISO file somewhere I can use? https://dl.fedoraproject.org/pub/fedora/linux/development/21/x86_64/os/images/boot.iso should be an F21 boot.iso. entirely untested, and you will need to boot the installed system with 'enforcing=0' or do an autorelabel on first boot, due to https://bugzilla.redhat.com/show_bug.cgi?id=1116450 . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide users: ceph packaging issues
On Thu, Jul 10, 2014 at 15:36:41 -0700, Adam Williamson adamw...@fedoraproject.org wrote: On Thu, 2014-07-10 at 15:34 -0700, Adam Williamson wrote: so, yeah, bit of a mess. You can probably get onto the 0.81.0-5 packages manually with a bit of judicious --nodeps use or 'yum shell' use, but it'd be best if the packages were fixed up, and I figured I'd let folks know about the problem for now. Sigh, just realized I forgot to mention that I have reported this issue as a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1118510 I also filed bug, though mine was originally for a file conflict between ceph and python-ceph. I figured out that an obsolete would have fixed things 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
[Bug 1106210] perl-Switch: FTBFS: Not compatible with Filter-1.50
https://bugzilla.redhat.com/show_bug.cgi?id=1106210 Marek mojbor...@yahoo.co.uk changed: What|Removed |Added CC||mojbor...@yahoo.co.uk --- Comment #14 from Marek mojbor...@yahoo.co.uk --- I was hit by this bug in F20 x86_64: $ rpm -q perl-Switch perl-Filter perl-Switch-2.16-8.fc20.noarch perl-Filter-1.50-1.fc20.x86_64 $ perl -e 'use Switch;' Can't call method filter on unblessed reference at -e line 2. $ I applied the perl-Switch-2.17-1.fc20 update from updates-testing and am happy to report that it solved my issue. -- 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=xpRc6EfALOa=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 1118240] New: puic4 is broken: fix provided
https://bugzilla.redhat.com/show_bug.cgi?id=1118240 Bug ID: 1118240 Summary: puic4 is broken: fix provided Product: Fedora Version: 20 Component: perl-Qt Assignee: iarn...@gmail.com Reporter: olivier.laha...@free.fr QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, lti...@redhat.com, perl-devel@lists.fedoraproject.org Created attachment 917029 -- https://bugzilla.redhat.com/attachment.cgi?id=917029action=edit Fixes puic4 code generator. Description of problem: puic4 the UI perl compiler for Qt is completely broken. Here are 2 patches that fixes most problems. The 1st one attached in this comment is mainly (but not exclusively) for the Qt3Support4 fixes. (upstream issue #46) The secondone in next comment will partially fix issue #44. Version-Release number of selected component (if applicable): all perl-Qt-0.96.0* including latest SVN. for rhel-*-* or fedora-*-* How reproducible: puic4 -o Ui_file.pm file.ui where file.ui was generated for Qt3. For exemple: http://svn.oscar.openclustergroup.org/oscar/pkgsrc/netbootmgr/trunk/netbootmgr.ui Steps to Reproduce: 1. wget http://svn.oscar.openclustergroup.org/oscar/pkgsrc/netbootmgr/trunk/netbootmgr.ui 2. puic4 -o Ui_NetBootMgr.pm netbootmgr.ui 3. perl -d NetBootMgr.pl or just look at the syntax for __item and also missing ending semicolons. Actual results: unusable perl syntax. Expected results: valid perl code. Additional info: Upstream AUTHOR is aware of the patch but won't be able to push it before a few weeks. Once dones, he has planed to make a new release. - http://search.cpan.org/dist/Qt/ is a dead repo - git clone https://code.google.com/p/perlqt4/ is the official standalone repo - git clone git://anongit.kde.org/perlqt/ is the active repo from kdebinding project. Note that standalone repo has been resynced back from kdebindings repo to include perl-5.18 fixes Also note thet changes in CMAkelists.txt have an impact: - can't build on rhel6 - need a smokeqt that has smokeqwt lib. IMHO, this shouldn't be required, thus I think that add ing my 2 patches is sufficient for the moment. The Author will give a look at the cmake issues later. https://code.google.com/p/perlqt4/issues/list -- 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=4SAGOsd9Gaa=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 1118240] puic4 is broken: fix provided
https://bugzilla.redhat.com/show_bug.cgi?id=1118240 --- Comment #1 from Olivier LAHAYE olivier.laha...@free.fr --- Created attachment 917030 -- https://bugzilla.redhat.com/attachment.cgi?id=917030action=edit Fixes partially 'puic4 -x' generated code This patch fixes the header generation and the additional code generated by the -x option of puic4. -- 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=B6C1orrPXUa=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 1100158] perl-Server-Starter-0.17 FTBFS sometimes because of races in tests
https://bugzilla.redhat.com/show_bug.cgi?id=1100158 --- Comment #3 from Petr Pisar ppi...@redhat.com --- The t/06-autorestart.t is full of sleeps racing with 4s auto_restart_interval. -- 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=fVcNgyq8sKa=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-Server-Starter] Fix t/06-autorestart.t race
commit eb4c9e9ca7f3d456982ce5195c5fb4ead9f077c1
Author: Petr Písař ppi...@redhat.com
Date: Thu Jul 10 15:45:21 2014 +0200
Fix t/06-autorestart.t race
...-Synchronize-to-PID-in-t-06-autorestart.t.patch | 83
perl-Server-Starter.spec |8 ++-
2 files changed, 90 insertions(+), 1 deletions(-)
---
diff --git a/Server-Starter-0.17-Synchronize-to-PID-in-t-06-autorestart.t.patch
b/Server-Starter-0.17-Synchronize-to-PID-in-t-06-autorestart.t.patch
new file mode 100644
index 000..9b4a713
--- /dev/null
+++ b/Server-Starter-0.17-Synchronize-to-PID-in-t-06-autorestart.t.patch
@@ -0,0 +1,83 @@
+From b2cee396fea96266a95a829b94cdf759d0eae76d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Thu, 10 Jul 2014 15:37:47 +0200
+Subject: [PATCH] Synchronize to PID in t/06-autorestart.t
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+There were races between various sleeps and 4s auto_restart_interval.
+This patch replaces the sleeps by waiting for status with a single PID
+entry.
+
+Similar to CPAN RT#73711.
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ t/06-autorestart.t | 35 +++
+ 1 file changed, 27 insertions(+), 8 deletions(-)
+
+diff --git a/t/06-autorestart.t b/t/06-autorestart.t
+index bab9241..9401500 100644
+--- a/t/06-autorestart.t
b/t/06-autorestart.t
+@@ -3,7 +3,7 @@ use warnings;
+
+ use File::Temp ();
+ use Test::TCP;
+-use Test::More tests = 28;
++use Test::More tests = 26;
+
+ use Server::Starter qw(start_server);
+
+@@ -46,13 +46,19 @@ for my $signal_on_hup ('TERM', 'USR1') {
+ $buf =~ /^(\d+):/;
+ my $worker_pid = $1;
+ # switch to next gen
+-sleep 2;
+-my $status = get_status();
+-like(get_status(), qr/^1:\d+\n$/s, 'status before auto-restart');
+-sleep 5;
+-like(get_status(), qr/^1:\d+\n2:\d+$/s, 'status during transient
state');
+-sleep 4;
+-like(get_status(), qr/^2:\d+\n$/s, 'status after auto-restart');
++my $previous_generation = get_single_generation();
++like($previous_generation, qr/^\d+:\d+\n$/s,
++'status before auto-restart');
++my $current_generation;
++while (($current_generation = get_single_generation()) eq
++$previous_generation) {
++ sleep 1;
++}
++diag Server changed from $previous_generation ,
++to $current_generation\n;
++
++like($current_generation, qr/^\d+:\d+\n$/s,
++'status after auto-restart');
+ is(
+ do {
+ open my $fh, '', $tempdir/signame
+@@ -78,7 +84,20 @@ for my $signal_on_hup ('TERM', 'USR1') {
+ }
+
+ sub get_status {
++while (! -e $tempdir/status) {
++sleep 1;
++}
+ open my $fh, '', $tempdir/status
+ or die failed to open file:$tempdir/status:$!;
+ do { undef $/; $fh };
+ }
++
++sub get_single_generation {
++my $status;
++do {
++sleep 1 if defined $status;
++$status = get_status;
++} until ($status =~ /\A\d+:\d+\n\z/);
++chomp $status;
++$status;
++}
+--
+1.9.3
+
diff --git a/perl-Server-Starter.spec b/perl-Server-Starter.spec
index 3d0cfc4..cb1b22b 100644
--- a/perl-Server-Starter.spec
+++ b/perl-Server-Starter.spec
@@ -1,6 +1,6 @@
Name: perl-Server-Starter
Version:0.17
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Superdaemon for hot-deploying server programs
License:GPL+ or Artistic
Group: Development/Libraries
@@ -10,6 +10,8 @@ Source0:
http://www.cpan.org/authors/id/K/KA/KAZUHO/Server-Starter-%{vers
Patch0: Server-Starter-0.17-Synchronize-to-PID-in-t-07-envdir.t.patch
# Fix loading the environment directory, bug #1100158, CPAN RT#73711
Patch1: Server-Starter-0.17-Fix-loading-envdir.patch
+# Fix t/06-autorestart.t race, bug #1100158, CPAN RT#73711
+Patch2:
Server-Starter-0.17-Synchronize-to-PID-in-t-06-autorestart.t.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
@@ -45,6 +47,7 @@ perl-Server-Starter's start_server script.
%setup -q -n Server-Starter-%{version}
%patch0 -p1
%patch1 -p1
+%patch2 -p1
%build
# --skipdeps causes ExtUtils::AutoInstall not to try auto-installing
@@ -75,6 +78,9 @@ make test
%{_mandir}/man1/start_server.*
%changelog
+* Thu Jul 10 2014 Petr Pisar ppi...@redhat.com - 0.17-4
+- Fix t/06-autorestart.t race (bug #1100158)
+
* Tue Jun 17 2014 Petr Pisar ppi...@redhat.com - 0.17-3
- Fix races in t/07-envdir.t test (bug #1100158)
- Load the environment directory just before restartin a server (bug #1100158)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
[Bug 1100158] perl-Server-Starter-0.17 FTBFS sometimes because of races in tests
https://bugzilla.redhat.com/show_bug.cgi?id=1100158 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version|perl-Server-Starter-0.17-3. |perl-Server-Starter-0.17-4. |fc21|fc22 Resolution|--- |RAWHIDE Last Closed|2014-06-17 06:30:17 |2014-07-10 09:55:34 --- Comment #4 from Petr Pisar ppi...@redhat.com --- I fixed the 5/06-autorestart.t test. -- 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=OR2LDz5J2ia=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 1118362] New: perl-Test-Assert-0.0504-9.fc21 FTBFS due signature test failing if there are network difficulties
https://bugzilla.redhat.com/show_bug.cgi?id=1118362 Bug ID: 1118362 Summary: perl-Test-Assert-0.0504-9.fc21 FTBFS due signature test failing if there are network difficulties Product: Fedora Version: rawhide Component: perl-Test-Assert Assignee: p...@city-fan.org Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, psab...@redhat.com perl-Test-Assert-0.0504-9.fc21 can fail to build from sources due tests sensitive to network: + ./Build test --test_files 'xt/check_changes.t xt/consistent_version_numbers.t xt/distribution.t xt/kwalitee.t xt/minimumversion.t xt/pod.t xt/pod_coverage.t xt/pod_syntax.t xt/signature.t' xt/check_changes.t ... ok xt/consistent_version_numbers.t .. ok xt/distribution.t ok xt/kwalitee.t ok xt/minimumversion.t .. ok xt/pod.t . ok xt/pod_coverage.t ok xt/pod_syntax.t .. ok gpg: new configuration file `/builddir/.gnupg/gpg.conf' created gpg: WARNING: options in `/builddir/.gnupg/gpg.conf' are not yet active during this run gpgkeys: HTTP fetch error 7: Failed to connect to pool.sks-keyservers.net port 11371: Network is unreachable gpg: Signature made Sun Dec 6 23:48:27 2009 CET using DSA key ID C0B10A5B gpg: requesting key C0B10A5B from hkp server pool.sks-keyservers.net gpg: no valid OpenPGP data found. gpg: Can't check signature: public key not found == BAD/TAMPERED signature detected! == # Failed test 'Valid signature' # at xt/signature.t line 9. # Looks like you failed 1 test of 1. xt/signature.t ... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report --- xt/signature.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=9, Tests=40, 11 wallclock secs ( 0.04 usr 0.02 sys + 5.47 cusr 0.13 csys = 5.66 CPU) Result: FAIL -- 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=uLy5xEOHe6a=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 1118362] perl-Test-Assert-0.0504-9.fc21 FTBFS due signature test failing if there are network difficulties
https://bugzilla.redhat.com/show_bug.cgi?id=1118362 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Petr Pisar ppi...@redhat.com --- I will bundle the key. There is a race between checking for key server connectivity and the gpg tool itself. -- 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=xdmiQvf9Xda=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 1118374] New: perl-Test-Assert-0.0504-9.fc21 FTBFS if perl(Perl::Critic::Pulp) is installed
https://bugzilla.redhat.com/show_bug.cgi?id=1118374 Bug ID: 1118374 Summary: perl-Test-Assert-0.0504-9.fc21 FTBFS if perl(Perl::Critic::Pulp) is installed Product: Fedora Version: rawhide Component: perl-Test-Assert Assignee: p...@city-fan.org Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, psab...@redhat.com perl-Test-Assert-0.0504-9.fc21 does not pass perlcritic tests if perl(Perl::Critic::Pulp) is installed: + ./Build test --test_files xt/perlcritic.t # Failed test 'Test::Perl::Critic for blib/lib/Exception/Assertion.pm' # at /usr/share/perl5/vendor_perl/Test/Perl/Critic.pm line 110. # # Perl::Critic found these violations in blib/lib/Exception/Assertion.pm: # Null statement (stray semicolon) at line 131, column 2. (no explanation). (Severity: 3) et cetera. I will add BuildConflicts on this package. -- 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=Qz3o3JkNosa=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 1118374] perl-Test-Assert-0.0504-9.fc21 FTBFS if perl(Perl::Critic::Pulp) is installed
https://bugzilla.redhat.com/show_bug.cgi?id=1118374 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|p...@city-fan.org |ppi...@redhat.com -- 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=KpolnPFBvJa=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-Test-Assert] Build-conflict with Perl::Critic::Pulp due to release tests
commit c8717a8f62187f826462767553bbe1db5776e070 Author: Petr Písař ppi...@redhat.com Date: Thu Jul 10 16:45:41 2014 +0200 Build-conflict with Perl::Critic::Pulp due to release tests perl-Test-Assert.spec |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) --- diff --git a/perl-Test-Assert.spec b/perl-Test-Assert.spec index 3f6cd83..7a44062 100644 --- a/perl-Test-Assert.spec +++ b/perl-Test-Assert.spec @@ -32,6 +32,8 @@ BuildRequires:perl(Test::Pod) BuildRequires: perl(Test::Pod::Coverage) BuildRequires: perl(Test::Signature) BuildRequires: perl(Test::Spelling), hunspell-en +# Release tests does not pass with Perl::Critic::Pulp, bug #1118374 +BuildConflicts: perl(Perl::Critic::Pulp) Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version)) # Avoid doc-file dependencies @@ -124,6 +126,7 @@ cd - %changelog * Thu Jul 10 2014 Petr Pisar ppi...@redhat.com - 0.0504-10 - Bundle upstream signing key (bug #1118362) +- Build-conflict with Perl::Critic::Pulp due to release tests (bug #1118374) * Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.0504-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Assert] Bundle upstream signing key
commit 387a17ac8cb52ad42b5d4fda29107fd7f8fa8d35 Author: Petr Písař ppi...@redhat.com Date: Thu Jul 10 16:34:01 2014 +0200 Bundle upstream signing key C0B10A5B.pub | 305 + perl-Test-Assert.spec | 14 ++- 2 files changed, 318 insertions(+), 1 deletions(-) --- diff --git a/C0B10A5B.pub b/C0B10A5B.pub new file mode 100644 index 000..c0ea179 --- /dev/null +++ b/C0B10A5B.pub @@ -0,0 +1,305 @@ +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v2 + +mQGiBDnZ6D8RBADUNFV5JOmCimkRusWM2HZft4WLvcPkBxsIHlQNSv+D++0dS26n ++BNmldwlFnVF/tgd/OBEiNNdSoAiNosdgfSjP/T57j6jJrzrnddk7ZlgJQSphvR3 +0hP3OMRw9wBIaZ4ZXAJkHhHcK93LT0Uk70hdDUVe4oEINJliNLCahpvT5wCg87jd +osDwmFQ4EwFuTdamLjU7kccD/ivoiY+J/XiGcOqsmLu6GztBHCMZSv2P/IFEHYDV +U2ywWMScP0xPt2sQIAKeBh5N9BGRXYBQOF5z45kyII5olHyJP+sk3iWOKT0CWIvg +eYEiPV7x3cQXo27C/TyGwlnoz4yMIkoo2m11hB/+ibyyUj+n3i2GjJ7Hqo8F6ezH +5KnVA/9PxYi17rGlL42c7ysVHvhi03oHr9QJqwR76b2g1lmbeVVtLBCi5GmZOfUk +hNEQXshMRkz4zbLO52EYN+F74fog8vbBoG7lGFp7Kp7QSdVdUZyfmOSkf6GGYJ6N +MTs9d5cKOg60suB020g9j/lgofj6xomHa2V1jgv0RldgsOOUrrQiUGlvdHIgUm9z +emF0eWNraSA8ZGV4dGVyQGNwYW4ub3JnPohgBBMRAgAgBQJJa2ilAhsjBgsJCAcD +AgQVAggDBBYCAwECHgECF4AACgkQhMHHe8CxClv9OwCdHZYKxlLnq34ni0OnSdF6 +Tiu9GnMAoJAiz1Un263aosx+9mkyGpTCwlDktCRQaW90ciBSb3N6YXR5Y2tpIDxk +ZXh0ZXJAZGViaWFuLm9yZz6IRgQQEQIABgUCOhP03gAKCRBOGHVwnTCcOxLkAJ96 +8eoLiTvL5ZnqtCJT3uBEdPmYEgCaAsMi7DhRPwOjAJKLW5kmX5LJje6IRgQQEQIA +BgUCQxXUxgAKCRAuz4pkrVwI9OrfAKCIm+PEOVSDLKP/ABvYiIxmxQyPgACgnN/Q +Dy44Ctt6qi0nH17uIXiJABOIRgQQEQIABgUCRrC+nwAKCRBeCTvrfz9vWy9mAJ9E +X3c3fxf8pK7/ZzH9tzIiU6iQ5QCdFlFghxoTXJ670BnuyWrciO4sIn6IVgQTEQIA +FgUCOdnoPwQLCgMEAxUDAgMWAgECF4AACgkQhMHHe8CxClsCswCfXhUjJbXL4sGR +sV1095QhUAyQaz8An3Drcz80jtLcryQNrP6YulKD3FM0iFYEExECABYFAjnZ6D8E +CwoDBAMVAwIDFgIBAheAAAoJEITBx3vAsQpbArMAn3Mv4VA+d3mp4xlqPlDgZOSb +rVtSAJ99dpTWgrmSsjjK/2SQjOFN+Y0f54hZBBMRAgAZBAsKAwQDFQMCAxYCAQIX +gAUCQxXaiAIZAQAKCRCEwcd7wLEKWyt2AJ96bW60tspLZvaoWOYpTIlWoRxqfgCg +0jLbQFyJZjx0duKLRzccXlc0IfSIXgQTEQIAFgUCOdnoPwQLCgMEAxUDAgMWAgEC +F4AAEgkQhMHHe8CxClsHZUdQRwABAQKzAJ9eFSMltcviwZGxXXT3lCFQDJBrPwCf +cOtzPzSO0tyvJA2s/pi6UoPcUzSJAJUDBRA52fRWdd1/MXnCsEEBAc4GA/4oDdZX +DKcAIn04jgBunsPaBWETClfp9awM+tRnhz+3pBYEuhzD1lR8uI24wYii5xvuZqkg +tryaG/WFWauTx/5hiV7y6EtznNt8COQUq5SZWPXHhd1b9Ftg4WUvitepSgygan91 +XWPzU51k7BX4DCC7cHqsXubdZKCI4Q6xvhL/EIkCHAQQAQIABgUCRrDvuAAKCRAP +7lW1RjmROAdLD/0V1uI+fPJafxweDPgT9ByKJ/oa6PfsZ7Ux2VVIuRrzh7vfE5Mg +x7PD6lHnHLLuPzvAz+fmIOUDCVivU+WAz9OaTxpb/kHcZay50QSNhS9dLsVEYJhp +gmzKD55MjO8DGe2Oxp3+usFOjQKnX7RxV9R1NMqYyn7FDkkmjlPSfVBzo8JsjdLr +ArRPLvk0bWnIrsXj5uwA1M15xrwKit5do6Naj6W5WRWe2rClgiABotrfNq77w/8I +YpKe832C2LYpIWtFx9piu5Vj9PsitD01goA/UWlscNgD2UZBPMHQp4YBe0oPL/3O +e/enPCyB7iAkfn3lIi2fRqjZUN4g/RPtNsHtmiSatQGE53G+xfPMYSgtKR6Nh7EO +VUXCZZ1nBeKtSzjBQNbXmHFbQ2BNBuG3yJp6Qfpl2nOaA679tMuc/8c8NBWhl1Aw +g8R6E17GTxELKei/r+fEsLeeTxnjJlvIpNeNdm8mFidLyrDLojK30UDq328dO99c +OqlBtMUWcshkGvVk3bZ0gsuuIJ7hOe6h2F2XEgXSRvEm3o1uTYu4H4XEXswqWQbu +LfAVVnLKA8gJ8kcwjEdQllRsb0ePXv3t+59VmfCoEKLd3n1lna/KX59iezjzX8SP +hmJ+b/ywcRfrAdahHegSJJnJr/D/k61Dldm61B6+pEEmifxQhJMkdOVZibQtUGlv +dHIgUm9zemF0eWNraSA8cGlvdHIucm9zemF0eWNraUBnbWFpbC5jb20+iEkEMBEC +AAkFAlIl6ZoCHQAACgkQhMHHe8CxClu0gACfZZuIQtc7GIdnJRHTMVQe1wmX6esA +n0aIO/Q4Ifr7iG0PbTJjaD8sWHPqiGAEExECACAFAkaxq7sCGyMGCwkIBwMCBBUC +CAMEFgIDAQIeAQIXgAAKCRCEwcd7wLEKWyU9AKC5dZEixp15JUPCv/UnF0MJJrQy +/QCdFb4l+NBwLQ6pcRxb6zwO53y3hAa0MFBpb3RyIFJvc3phdHlja2kgPFBpb3Ry +X1Jvc3phdHlja2lAbmV0aWEubmV0LnBsPohJBDARAgAJBQJSv/J4Ah0AAAoJEITB +x3vAsQpboJgAoIBF6LjRq5wluqY0BFvjxmYHFFMxAJ9OVIBg2VczlW49UAiwrlTu +LXVuvYheBBMRAgAeBQJDFdfQAhsjBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEITB +x3vAsQpb91sAnjUcAwphfp3Ex7ysRNDGnNAjEB9MAJ9Ne3h7qORAsjZ+d4vL5XNx +dairvokCHAQQAQIABgUCRrDvwQAKCRAP7lW1RjmROERoD/9l0x0YAryEKtK/CKsC +xNarg+XF1lG9ke5FobNvUEbWKjJl9ixEQAajSXbiccGhHHf++7dtPMYQDj6N9wIX +chWWaMdCL6n4QCWGUMznTjx49CcDumNRIgXcC9HRjSTX/STA8ozvLAvea8UFn9Ih +5kiwJ9KECoM9NVrHq5A+Dkq53jy5KIXHvx0qF2csrbse4u5t4h1w7xhBjLyK9Wgs +Aqf3wTWygKW08SPmOkJ/k7g60yE4+vspQawWArU8CnAGeUouJ9nrHxPIkSIS9M+T +auBoLaE4stessdO1Kpc010nIgPwYFOOZ1dhfVFmWBflDWAvUyrbxZUGhOJZ0EPeG +W0Q7Mble0Ip5X6MO/V9JwySsyZNXKhN+1QbWBYl7e1dgtjkLxCwgpMDlhVgP6idl ++c0bi1hUt23tpqGwLr7T0v3qnSSBVuymNqh4RDp23YZ8V4hLy6OVfo0lYD2k89L+ +/oxeD21x1yyiGaXfObXDXCy9AX8U4aIqGEZ8KGAK/7SlEy1wrF3lTkLHXYr9bZGG +y4zk3iiv4TW4A00TaN4E+bPj4ZmpSkdfi4u024CN813m3p5Zrx2i0hPqEMZleU73 +wNUN+CmE2nIq66F14Yyc1ijDy2PTl1YlZxiDDy42hFhAh4xs5CIfClDdajPZOyGU +uLckV97h2Y8dsq7t2OyWZXCrZtH/AAAoHP8AACgXARAAAQEAAAD/ +2P/gABBKRklGAAEBAQBIAEgAAP/hABZFeGlmAABNTQAqCP/bAEMA +BQMEBAQDBQQEBAUFBQYHDAgHBwcHDwsLCQwRDxISEQ8RERMWHBcTFBoVEREYIRga +HR0fHx8TFyIkIh4kHB4fHv/bAEMBBQUFBwYHDggIDh4UERQeHh4eHh4eHh4eHh4e +Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHv/AABEIASAAxQMB +IgACEQEDEQH/xAAdBwEBAQAAAQIDBAUGBwgJ/8QAQRAAAQMC +BQIEAwUFBgYDAQAAAQACAwQRBQYSITFBUQcTImFxgZEIFDJCoRUjscHRFlJicoLw +M0OSosLhJTRz8f/EABsBAAIDAQEBAAECAAMEBQYH/8QAKxEAAgIC
[Bug 1118362] perl-Test-Assert-0.0504-9.fc21 FTBFS due signature test failing if there are network difficulties
https://bugzilla.redhat.com/show_bug.cgi?id=1118362 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Assert-0.0504-10. ||fc22 Resolution|--- |RAWHIDE Last Closed||2014-07-10 10:59:31 -- 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=sgIGJjsTr0a=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 1118374] perl-Test-Assert-0.0504-9.fc21 FTBFS if perl(Perl::Critic::Pulp) is installed
https://bugzilla.redhat.com/show_bug.cgi?id=1118374 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Assert-0.0504-10. ||fc22 Resolution|--- |RAWHIDE Last Closed||2014-07-10 10:59:29 -- 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=jtSS6LMLzla=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
[PkgDB] ktdreyer:perl-Time-Duration-Parse commit set to Approved
user: ktdreyer set for ktdreyer acl: commit of package: perl-Time-Duration-Parse from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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
[PkgDB] ktdreyer:perl-Time-Duration-Parse watchbugzilla set to Approved
user: ktdreyer set for ktdreyer acl: watchbugzilla of package: perl-Time-Duration-Parse from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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
[PkgDB] ktdreyer:perl-Time-Duration-Parse approveacls set to Approved
user: ktdreyer set for ktdreyer acl: approveacls of package: perl-Time-Duration-Parse from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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
[PkgDB] ktdreyer:perl-Time-Duration-Parse watchcommits set to Approved
user: ktdreyer set for ktdreyer acl: watchcommits of package: perl-Time-Duration-Parse from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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 1117988] [RFE] branch perl-Time-Duration-Parse for EPEL 6
https://bugzilla.redhat.com/show_bug.cgi?id=1117988 Ken Dreyer ktdre...@ktdreyer.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|rc040...@freenet.de |ktdre...@ktdreyer.com Flags||fedora-cvs? --- Comment #2 from Ken Dreyer ktdre...@ktdreyer.com --- (In reply to Ralf Corsepius from comment #1) I do not support EPEL. However feel free to go ahead and maintain it yourself for EPEL. Cool, thanks Ralf for the quick response. I've requested Rawhide ACLs as well in order to be able to keep the package in sync (if necessary). Package Change Request == Package Name: perl-Time-Duration-Parse New Branches: el6 Owners: ktdreyer InitialCC: perl-sig -- 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=o5FsVlnoqna=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 1037242] perl-Proc-ProcessTable FTBFS if -Werror=format-security flag is used
https://bugzilla.redhat.com/show_bug.cgi?id=1037242 --- Comment #2 from Henrique Martins bugzilla-red...@martins.cc --- Can someone make a fc20 version of this? -- 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=oWfkP8fhDOa=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
[PkgDB] ktdreyer:perl-Exporter-Lite commit set to Approved
user: ktdreyer set for ktdreyer acl: commit of package: perl-Exporter-Lite from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Exporter-Lite -- 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 1117989] [RFE] branch perl-Exporter-Lite for EPEL 7
https://bugzilla.redhat.com/show_bug.cgi?id=1117989 Ken Dreyer ktdre...@ktdreyer.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |CURRENTRELEASE Last Closed||2014-07-10 14:06:40 --- Comment #3 from Ken Dreyer ktdre...@ktdreyer.com --- Thanks spot! Built as http://koji.fedoraproject.org/koji/taskinfo?taskID=7125740 . -- 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=6FX4i4n0Mda=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
[PkgDB] limb:perl-Time-Duration-Parse watchcommits set to Approved
user: limb set for ktdreyer acl: watchcommits of package: perl-Time-Duration-Parse from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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
[PkgDB] limb:perl-Time-Duration-Parse watchbugzilla set to Approved
user: limb set for ktdreyer acl: watchbugzilla of package: perl-Time-Duration-Parse from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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
[PkgDB] limb:perl-Time-Duration-Parse approveacls set to Approved
user: limb set for ktdreyer acl: approveacls of package: perl-Time-Duration-Parse from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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 1117988] [RFE] branch perl-Time-Duration-Parse for EPEL 6
https://bugzilla.redhat.com/show_bug.cgi?id=1117988 --- Comment #3 from Jon Ciesla limburg...@gmail.com --- Git done (by process-git-requests). -- 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=5TBMnIbCPma=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
[PkgDB] limb:perl-Time-Duration-Parse commit set to Approved
user: limb set for ktdreyer acl: commit of package: perl-Time-Duration-Parse from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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 1117988] [RFE] branch perl-Time-Duration-Parse for EPEL 6
https://bugzilla.redhat.com/show_bug.cgi?id=1117988 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Flags|fedora-cvs? |fedora-cvs+ -- 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=CAAusfidq5a=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
[PkgDB] limb:perl-Time-Duration-Parse watchbugzilla set to Approved
user: limb set for perl-sig acl: watchbugzilla of package: perl-Time-Duration-Parse from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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
[PkgDB] limb:perl-Time-Duration-Parse watchcommits set to Approved
user: limb set for perl-sig acl: watchcommits of package: perl-Time-Duration-Parse from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Time-Duration-Parse -- 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-Time-Duration-Parse] Correct %description from cpan2dist
commit 8a8db3abe02ac1b73be1d3a40a911e3c4dfaf870
Author: Ken Dreyer ktdre...@ktdreyer.com
Date: Thu Jul 10 14:17:16 2014 -0600
Correct %description from cpan2dist
perl-Time-Duration-Parse.spec | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
---
diff --git a/perl-Time-Duration-Parse.spec b/perl-Time-Duration-Parse.spec
index 3d962e8..fb00172 100644
--- a/perl-Time-Duration-Parse.spec
+++ b/perl-Time-Duration-Parse.spec
@@ -1,6 +1,6 @@
Name: perl-Time-Duration-Parse
Version:0.11
-Release:2%{?dist}
+Release:3%{?dist}
# see lib/Time/Duration/Parse.pm
License:GPL+ or Artistic
Group: Development/Libraries
@@ -22,10 +22,8 @@ BuildRequires: perl(Time::Duration)
%description
Time::Duration::Parse is a module to parse human readable duration strings
-like _2 minutes and 3 seconds_ to seconds.
-
-It does the opposite of duration_exact() in Time::Duration and is roundtrip
-safe. So, the following is always true.
+like 2 minutes and 3 seconds to seconds. It does the opposite of
+duration_exact() in Time::Duration and is roundtrip safe.
%prep
%setup -q -n Time-Duration-Parse-%{version}
@@ -49,6 +47,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Thu Jul 10 2014 Ken Dreyer ktdre...@ktdreyer.com - 0.11-3
+- Correct %%description from cpan2dist
+
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.11-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1117988] [RFE] branch perl-Time-Duration-Parse for EPEL 6
https://bugzilla.redhat.com/show_bug.cgi?id=1117988 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Time-Duration-Parse-0.11-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Time-Duration-Parse-0.11-2.el6 -- 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=GPMyMisMGTa=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-Test-Assert] Created tag perl-Test-Assert-0.0504-11.fc22
The lightweight tag 'perl-Test-Assert-0.0504-11.fc22' was created pointing to: 2ca22cc... Tidy the code to pass the Critic test -- 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 1014054] perl-Net-Patricia license tag is broken.
https://bugzilla.redhat.com/show_bug.cgi?id=1014054 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- Package perl-Net-Patricia-1.22-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Net-Patricia-1.22-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-8243/perl-Net-Patricia-1.22-4.fc20 then log in and leave karma (feedback). -- 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=jg4KWYTgWba=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 1076569] perl-WebService-Linode-0.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1076569 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-WebService-Linode-0.20 |perl-WebService-Linode-0.20 |-1.fc21 |-1.fc20 Resolution|RAWHIDE |ERRATA --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-WebService-Linode-0.20-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- 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=NtuiKrquQVa=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
[389-devel] Please review: Ticket 47846 server crashes deleting a replication agreement
https://fedorahosted.org/389/ticket/47846 https://fedorahosted.org/389/attachment/ticket/47846/0001-Ticket-47846-server-crashes-deleting-a-replication-a.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review ticket 47797: DB deadlock when two threads (on separated backend) try to record changes in retroCL
https://fedorahosted.org/389/ticket/47797 https://fedorahosted.org/389/attachment/ticket/47797/0001-Ticket-47797-DB-deadlock-when-two-threads-on-separat.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] please review: Ticket 47851 - lib389 - Add function to retrieve dirsrvtests data directory
https://fedorahosted.org/389/ticket/47851 https://fedorahosted.org/389/attachment/ticket/47851/0001-Ticket-47851-Add-function-to-retrieve-dirsrvtests-da.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #47852: Updating winsync one-way sync does not affect the behaviour dynamically
https://fedorahosted.org/389/ticket/47852 https://fedorahosted.org/389/attachment/ticket/47852/0001-Ticket-47852-Updating-winsync-one-way-sync-does-not-.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
