Re: [EPEL-devel] epel-release: consider adding %epel macro ?
On Mon, Oct 20, 2014 at 08:56:35PM -0500, Rex Dieter wrote:
Jeff Sheltren wrote:
On Mon, Oct 20, 2014 at 3:11 PM, Rex Dieter
rdie...@math.unl.edu wrote:
ping, any comment or objection?
I'll work on a patch for epel-release to implement a %{epel} macro, in
case anyone was waiting for implementation details.
Seems like it can't hurt much to have such a macro defined by the
epel-release package. Could you give an example of the kind of logic
you'd use this for?
Sure. My primary motivation is that I'd like be able keep fedora/rhel kde
packaging merged in fedora's git repos. *Normally*, rhel kde packaging
disables some features ( based on %rhel macro), but I'd like to be able
(re)enable those via some extras macro, like %epel. This is one approach
redhat's kde maintainers agreed would be acceptable.
How would enabling features at build-time contional on the presence of
epel-release and this macro help? Will you be building in two
environments and creating two repositories--one for RHEL binaries and
one for RHEL+EPEL binaries?
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 912 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 244 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 131 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2719/nodejs-0.10.32-1.el6,v8-3.14.5.10-14.el6 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2811/nodejs-qs-0.6.6-3.el6 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2821/nodejs-send-0.3.0-4.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3202/python-oauth2-1.5.211-8.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2850/nginx-1.0.15-8.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3264/getmail-4.46.0-2.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3279/php-ZendFramework-1.12.9-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3286/facter-1.6.18-5.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3297/catdoc-0.94.2-10.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3427/rubygem-httpclient-2.4.0-2.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3421/drupal7-7.32-1.el6 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3434/pylint-1.3.1-1.el6,python-astroid-1.2.1-2.el6,python-logilab-common-0.62.1-2.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing grib_api-1.12.3-5.el6 ioprocess-0.14.0-1.el6 pyhoca-cli-0.5.0.0-1.el6 pyhoca-gui-0.5.0.0-1.el6 python-catkin_pkg-0.2.5-1.el6 python-rosdep-0.10.32-1.el6 python-x2go-0.5.0.0-1.el6 supervisor-2.1-9.el6 Details about builds: grib_api-1.12.3-5.el6 (FEDORA-EPEL-2014-3509) WMO FM-92 GRIB (v1,v2) interface accessible from C and FORTRAN programs Update Information: - Add BR libpng-devel - Add png support (bug #1154192) - Fix python install location (bug #1098516) - Add png support (bug #1154192) - Add png support (bug #1154192) - Add png support (bug #1154192) ChangeLog: * Mon Oct 20 2014 Orion Poplawski or...@cora.nwra.com - 1.12.3-5 - Add BR libpng-devel * Fri Oct 17 2014 Orion Poplawski or...@cora.nwra.com - 1.12.3-4 - Add png support (bug #1154192) * Thu Aug 7 2014 Orion Poplawski or...@cora.nwra.com - 1.12.3-2 - Fix python install location (bug #1098516) References: [ 1 ] Bug #1154192 - Request for recompile grib_api with PNG support https://bugzilla.redhat.com/show_bug.cgi?id=1154192 ioprocess-0.14.0-1.el6 (FEDORA-EPEL-2014-3516) Slave process to perform risky IO Update Information: Fix poll timeout ChangeLog: * Mon Oct 20 2014 Saggi Mizrahi smizr...@redhat.com 0.14.0-2 - Fix poll timeout - Add support for zombiereaper where available - Fix IOProcesses being referenced by commincation thread - build: update INSTALL - specfile: Add missing dependency to glib2 pyhoca-cli-0.5.0.0-1.el6 (FEDORA-EPEL-2014-3506) Command line X2Go client written in Python Update Information: Update to 0.5.0.0: o HTTP X2Go Session Broker support o Telekinesis / mTelePlayer support (requires X2Go Server = 4.1.0.0) o Selection of clipboard mode (bidirectional, server-client, client-server) o More exception catching when some error occurs during a running session / connected session o Great improvements concerning session cleanup o Require that X2Go Server commands are in $PATH o Handle duplicate session profile names gracefully o Deepen the undetstanding of SSH forwarding tunnels o Various other fixes around stability ChangeLog: * Mon Oct 20 2014 Orion Poplawski or...@cora.nwra.com - 0.5.0.0-1 - Update to 0.5.0.0 * Fri Aug 22 2014 Orion Poplawski or...@cora.nwra.com - 0.4.0.2-3 - Drop notify-python requires * Sat Jun 7 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.4.0.2-2 - Rebuilt for
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2748/nodejs-0.10.32-1.el7,v8-3.14.5.10-14.el7 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2825/nginx-1.6.2-1.el7 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2861/nodejs-qs-0.6.6-3.el7 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2870/nodejs-send-0.3.0-4.el7 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3236/python-oauth2-1.5.211-8.el7 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3283/php-ZendFramework2-2.3.3-1.el7 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3292/davfs2-1.4.7-6.el7 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3454/rubygem-httpclient-2.4.0-2.el7 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3432/drupal7-7.32-1.el7 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3328/zarafa-7.1.11-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing amiri-fonts-0.107-2.el7 ast-7.3.4-1.el7 canl-java-2.1.1-1.el7 gnulib-0-12.20141021git.el7 goldendict-1.5-0.4.RC1.el7 grib_api-1.12.3-5.el7 gtk-unico-engine-1.0.3-0.6.20140109bzr152.el7 islamic-menus-1.0.6-4.el7 libsrtp-1.4.4-13.20101004cvs.el7 pyhoca-cli-0.5.0.0-1.el7 pyhoca-gui-0.5.0.0-1.el7 python-catkin_pkg-0.2.5-1.el7 python-pyarabic-0.4-3.el7 python-qalsadi-0.1-2.el7 python-rosdep-0.10.32-1.el7 python-tashaphyne-0.2-3.el7 python-x2go-0.5.0.0-1.el7 rsnapshot-1.3.1-13.el7 sigil-0.8.1-1.el7 tuxcut-5.1-2.el7 wondershaper-1.2.1-3.el7 Details about builds: amiri-fonts-0.107-2.el7 (FEDORA-EPEL-2014-3513) A classical Arabic font in Naskh style Update Information: To EPEL7. ast-7.3.4-1.el7 (FEDORA-EPEL-2014-3523) A Library for Handling World Coordinate Systems in Astronomy Update Information: Update to 7.3.4, change: - By default, the simplification of Polygons no longer checks that the edges are not bent by the simplification. A new attribute, SimpVertices, can be set to zero in order to re-instate this check. - The Polygon class has a new mathod, astConvex, that returns a Polygon representing the shortest polygon (i.e. convex hull) enclosing a specified set of pixel values within a supplied array. ChangeLog: * Fri Mar 7 2014 Orion Poplawski or...@cora.nwra.com 7.3.4-1 - Update to 7.3.4 canl-java-2.1.1-1.el7 (FEDORA-EPEL-2014-3514) EMI Common Authentication library - bindings for Java Update Information: Update to latest upstream release. This update contains two fixes of the OCSP handling: caching of failing OCSP responders and limited memory usage footprint of the overall OCSP cache. ChangeLog: * Mon Oct 13 2014 Mattias Ellert mattias.ell...@fysast.uu.se - 2.1.1-1 - New upstream version gnulib-0-12.20141021git.el7 (FEDORA-EPEL-2014-3508) GNU Portability Library Update Information: Update on 20141021. ChangeLog: * Tue Oct 21 2014 Mosaab Alzoubi moc...@hotmail.com - 0-12.20141021git - Update on 20141021. goldendict-1.5-0.4.RC1.el7 (FEDORA-EPEL-2014-3515) A feature-rich dictionary lookup program Update Information: To EPEL7. grib_api-1.12.3-5.el7 (FEDORA-EPEL-2014-3519) WMO FM-92 GRIB (v1,v2) interface accessible from C and FORTRAN programs
Re: [EPEL-devel] epel-release: consider adding %epel macro ?
Chuck Anderson wrote:
On Mon, Oct 20, 2014 at 08:56:35PM -0500, Rex Dieter wrote:
Jeff Sheltren wrote:
On Mon, Oct 20, 2014 at 3:11 PM, Rex Dieter
rdie...@math.unl.edu wrote:
ping, any comment or objection?
I'll work on a patch for epel-release to implement a %{epel} macro, in
case anyone was waiting for implementation details.
Seems like it can't hurt much to have such a macro defined by the
epel-release package. Could you give an example of the kind of logic
you'd use this for?
Sure. My primary motivation is that I'd like be able keep fedora/rhel
kde
packaging merged in fedora's git repos. *Normally*, rhel kde packaging
disables some features ( based on %rhel macro), but I'd like to be able
(re)enable those via some extras macro, like %epel. This is one
approach redhat's kde maintainers agreed would be acceptable.
How would enabling features at build-time contional on the presence of
epel-release and this macro help? Will you be building in two
environments and creating two repositories--one for RHEL binaries and
one for RHEL+EPEL binaries?
Yes, yes, respectively. See my first post in this thread, regarding a KDE
for RHEL7 COPR.
My primary motivation is to simplify the task of doing something like:
https://copr.fedoraproject.org/coprs/rdieter/kde4/
where I currently end up patching various .spec files (mostly to enable
features due to having epel available), and I'd like to be able to minimize
having to do that.
-- Rex
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Request new package
2014-10-20 15:04 GMT+02:00 Richard Shaw hobbes1...@gmail.com: On a side note, I played around building a package and noticed that only a sysvinit file is provided. Upstream should develop a systemd service file. Hi Richard, thank you very much for this note that I reported in the developer mailing list. I'll write back as soon as I know if somebody takes care of systemd service file. Valerio. -- 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: Request new package
2014-10-21 8:49 GMT+02:00 Valerio Pachera siri...@gmail.com: 2014-10-20 15:04 GMT+02:00 Richard Shaw hobbes1...@gmail.com: On a side note, I played around building a package and noticed that only a sysvinit file is provided. Upstream should develop a systemd service file. Hi Richard, thank you very much for this note that I reported in the developer mailing list. I'll write back as soon as I know if somebody takes care of systemd service file. if you know how to start it by hand, it's very easy to write a basic service file. man systemd.service for more informations H. Valerio. -- 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: LLVM 3.5 rebase
2014-10-20 16:19 GMT+02:00 Adam Jackson a...@redhat.com: On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote: 2014-10-17 16:00 GMT+02:00 Peter Robinson pbrobin...@gmail.com: So I'm OK with retiring python-llvmpy if a patch doesn't appear soon. I would be too, but I'm going to want 3.5 in F21, and we have this whole thing about not retiring packages in a live release. So I will retire the package before the window for F21 closes. Just a question. If I retire the package in F21, will it affect the F20 F21 upgrade path for those who have python-llvmpy installed? I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy that requires llvm 3.4 and... fedup will probably ignore python-llvpmy and will go ahead, but those that use yum will need to uninstall python-llvmpy by hand. Is this correct? -- 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: LLVM 3.5 rebase
On 10/21/2014 10:37 AM, Sergio Pascual wrote: Just a question. If I retire the package in F21, will it affect the F20 F21 upgrade path for those who have python-llvmpy installed? I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy that requires llvm 3.4 and... fedup will probably ignore python-llvpmy and will go ahead, but those that use yum will need to uninstall python-llvmpy by hand. Is this correct? The usual fix for this is to have something remove the retired package on upgrades. llvm should be a good candidate for doing the removal since all python-llvmpy installations already have llvm installed. Something like this in llvm spec file: Obsoletes: python-llvmpy 0.12.7-2 Obsoletes: python3-llvmpy 0.12.7-2 -- Hope this helps, 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
Fedora 21 Beta Go/No-Go Meeting, Thursday, October 23 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 21 Beta. Thursday, October 23, 2014 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. Release Candidate (RC) availability and good QA coverage are prerequisites for the Go/No-Go decision but meeting itself is held in any case. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 21 Beta Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist Fedora 21 Beta blocker bug status report by adamw https://lists.fedoraproject.org/pipermail/devel/2014-October/203591.html We have very tight schedule this time to make Fedora 21 release this year, please help us with blocker bugs, testing and other tasks needed for successful release. So far, many reviews says F21 Alpha is the best Fedora ever! Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can you help with making fonts awesome in Fedora 21?
On 17 October 2014 10:22, pravin@gmail.com pravin@gmail.com wrote: Will be very helpful if you can add how to test information as well. i.e. after local install package will appear in gnome-software something in bit detail. You can't actually preview metainfo files in the same way as AppData files; they have to be run through appstream-builder before they are useful. If you're technically savvy, you can install appstream-builder, generate some metadata, and then look at the logs, but the easier way is just to look at my daily rebuilds of rawhide: https://github.com/hughsie/createrepo_as_logs/ For instance, this is Lato: https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/l/lato-fonts.log Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LLVM 3.5 rebase
2014-10-21 12:32 GMT+02:00 Kalev Lember kalevlem...@gmail.com: On 10/21/2014 10:37 AM, Sergio Pascual wrote: Just a question. If I retire the package in F21, will it affect the F20 F21 upgrade path for those who have python-llvmpy installed? I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy that requires llvm 3.4 and... fedup will probably ignore python-llvpmy and will go ahead, but those that use yum will need to uninstall python-llvmpy by hand. Is this correct? The usual fix for this is to have something remove the retired package on upgrades. llvm should be a good candidate for doing the removal since all python-llvmpy installations already have llvm installed. Something like this in llvm spec file: Obsoletes: python-llvmpy 0.12.7-2 Obsoletes: python3-llvmpy 0.12.7-2 I have retired python-llvmpy in Rawhide and F21. Now if the owner of llvm does the Obsoletes trick then the rebase can go ahead, is it right? -- Hope this helps, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141021 changes
Compose started at Tue Oct 21 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.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 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [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 [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 [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 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [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 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires
Re: Can you help with making fonts awesome in Fedora 21?
On Tue, Oct 21, 2014 at 1:24 PM, Richard Hughes hughsi...@gmail.com wrote: On 17 October 2014 10:22, pravin@gmail.com pravin@gmail.com wrote: Will be very helpful if you can add how to test information as well. i.e. after local install package will appear in gnome-software something in bit detail. You can't actually preview metainfo files in the same way as AppData files; they have to be run through appstream-builder before they are useful. If you're technically savvy, you can install appstream-builder, generate some metadata, and then look at the logs, but the easier way is just to look at my daily rebuilds of rawhide: https://github.com/hughsie/createrepo_as_logs/ For instance, this is Lato: https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/l/lato-fonts.log smc-fonts failed to process with 'unrecognized contents' message https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/s/smc-fonts-common.log What could be the issue? Richard -- -- Rajeesh -- 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 report: 20141021 changes
Compose started at Tue Oct 21 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [gorm] gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23 [hadoop] hadoop-common-2.4.1-5.fc22.noarch requires commons-httpclient [hledger] ghc-hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-hledger-devel-0.19.3-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) hledger-0.19.3-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so hledger-0.19.3-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) hledger-0.19.3-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [idris] idris-0.9.9.1-3.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so idris-0.9.9.1-3.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so idris-0.9.9.1-3.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) idris-0.9.9.1-3.fc22.i686 requires
Re: Can you help with making fonts awesome in Fedora 21?
On 21 October 2014 12:55, Rajeesh K Nambiar rajeeshknamb...@gmail.com wrote: smc-fonts failed to process with 'unrecognized contents' message https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/s/smc-fonts-common.log What could be the issue? Two things look to be the problem: ?xml version=1.0 encoding=UTF-8 needs to be: ?xml version=1.0 encoding=UTF-8? value key=FontSampleTextമനുഷ്യരെല്ലാവരും/key needs to be: value key=FontSampleTextമനുഷ്യരെല്ലാവരും/value Also, if you're making changes upstream (yay! upstream! thanks!) could you please fix this: appstream-util validate /home/hughsie/smc.metainfo.xml /home/hughsie/smc.metainfo.xml: FAILED: • style-invalid : p does not end in '.|:|!' • style-invalid : Not enough p tags for a good description Basically, the description has to end with a dot, and if possible be a little longer. Thanks. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 Beta blocker bug status report
On Mon, Oct 20, 2014 at 07:10:01PM -0700, Adam Williamson wrote: * https://bugzilla.redhat.com/show_bug.cgi?id=1099299 - systemd - fedup fails to upgrade F20 to F21 or later - infinite loop when starting udev - the expected fix for this has been written, but testing is difficult without it being included in a compose. QA/releng are asking systemd devs to provide a koji build and Bodhi update with the fix, and we will pull it into the next compose for testing. Hi Adam, I amended the updates that was in updates-testing with a build that carries four additional patches for #1099299. 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
Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Hello folks, I raised a question with the Board a couple weeks ago[1] as to how we should be branding the different releases. It's been clear that different groups have different opinions on whether we should call something Fedora Server 21 vs. Fedora 21 Server (and Workstation and Cloud, of course). I was asked by the Board to get input from each of the working groups as well as marketing and branding folks. I'm sending this to each of these lists, but PLEASE keep all replies on the devel@lists.fedoraproject.org list or it will be impossible to keep track of the replies. (I've set the reply-to header on this email; please try not to lose it). A few specific comments that have been made on the Board ticket (to avoid rehashing them). * Fedora Server 21 sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? Anyway, we need to have a consistent branding decision made for the release (and for the Ambassadors). So please come prepared to find a consensus (not to win a fight). [1] https://fedorahosted.org/board/ticket/11 signature.asc Description: This is a digitally signed message part -- 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: Can you help with making fonts awesome in Fedora 21?
On Tue, Oct 21, 2014 at 2:09 PM, Richard Hughes hughsi...@gmail.com wrote: On 21 October 2014 12:55, Rajeesh K Nambiar rajeeshknamb...@gmail.com wrote: smc-fonts failed to process with 'unrecognized contents' message https://raw.githubusercontent.com/hughsie/createrepo_as_logs/master/s/smc-fonts-common.log What could be the issue? Two things look to be the problem: ?xml version=1.0 encoding=UTF-8 needs to be: ?xml version=1.0 encoding=UTF-8? value key=FontSampleTextമനുഷ്യരെല്ലാവരും/key needs to be: value key=FontSampleTextമനുഷ്യരെല്ലാവരും/value Also, if you're making changes upstream (yay! upstream! thanks!) could you please fix this: appstream-util validate /home/hughsie/smc.metainfo.xml /home/hughsie/smc.metainfo.xml: FAILED: • style-invalid : p does not end in '.|:|!' • style-invalid : Not enough p tags for a good description Basically, the description has to end with a dot, and if possible be a little longer. Thanks. Okay, will fix it upstream and make a new build. Thanks for the quick resolution! Richard -- -- Rajeesh -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Hi, On 10/21/2014 08:28 AM, Stephen Gallagher wrote: * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? Is there any intention to release the products on different schedules? ~m -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
- Original Message - Hi, On 10/21/2014 08:28 AM, Stephen Gallagher wrote: * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? Is there any intention to release the products on different schedules? Definitely not now or in the near future. Jaroslav ~m -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On 10/21/2014 08:42 AM, Jaroslav Reznik wrote: - Original Message - Hi, On 10/21/2014 08:28 AM, Stephen Gallagher wrote: * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? Is there any intention to release the products on different schedules? Definitely not now or in the near future. Does any group want to eventually release on a different cycle than the others? I mean I think this is the critical question. Because if the products are always going to be in sync, having separate version numbers for Fedora and each of them is going to confuse way more than it clarifies. ~m -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, 2014-10-21 at 08:47 -0400, Máirín Duffy wrote: On 10/21/2014 08:42 AM, Jaroslav Reznik wrote: - Original Message - Hi, On 10/21/2014 08:28 AM, Stephen Gallagher wrote: * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? Is there any intention to release the products on different schedules? Definitely not now or in the near future. Does any group want to eventually release on a different cycle than the others? I mean I think this is the critical question. Because if the products are always going to be in sync, having separate version numbers for Fedora and each of them is going to confuse way more than it clarifies. I cannot speak for the entirety of the Server Working Group, but I've been advocating for Fedora Server to eventually move to a different major release cadence (doing minor releases aligned with the Fedora base though).[1] That being said, the Server WG agreed unanimously that this was not going to be a near-term goal. I suspect at that point we will end up having to re-brand Server in some way (possibly by re-starting the numbering at 1) [1] https://fedoraserver-wgblog.rhcloud.com/proposal-announcement-fedora-server-lifecycle-stable-and-development/ signature.asc Description: This is a digitally signed message part -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Stephen Gallagher wrote: Hello folks, I raised a question with the Board a couple weeks ago[1] as to how we should be branding the different releases. It's been clear that different groups have different opinions on whether we should call something Fedora Server 21 vs. Fedora 21 Server (and Workstation and Cloud, of course). At least until release schedules and/or branding diverge, I personally think it more important to continue to emphasize the version over the product (ie, version should come first), e.g. go with the Fedora 21 $PRODUCT variant -- 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
top in Rawhide
Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? The default consumes huge amounts of whitespace with a useless display of per-CPU stats, and [not shown] is completely static until you press 'P'. Rich. top - 14:20:04 up 3:46, 3 users, load average: 1.65, 1.18, 1.06 Tasks: 169 total, 1 running, 167 sleeping, 1 stopped, 0 zombie %Cpu0 : 2.0/13.2 15[ ] %Cpu1 : 0.6/60.4 61[ ] %Cpu2 : 0.0/0.7 1[ ] %Cpu3 : 0.0/1.3 1[|] %Cpu4 : 0.7/1.3 2[|] %Cpu5 : 0.0/3.4 3[|| ] %Cpu6 : 0.0/1.3 1[|] %Cpu7 : 9.1/7.116[|] GiB Mem : 2.8/15.726 [ ] GiB Swap: 0.0/16.000 [ ] PID USER PR NIVIRTRES %CPU %MEM TIME+ S COMMAND 6540 root 20 0 204.7m 86.5m 6.5 0.5 2:35.27 D yum 465 root 20 0 37.8m 21.4m 2.6 0.1 0:11.91 S systemd-journal 9 root 20 00.0m 0.0m 2.0 0.0 0:38.04 S rcuos/1 7274 root 20 00.0m 0.0m 2.0 0.0 0:01.24 S kworker/5:0 16102 rjones20 0 108.1m 3.6m 1.3 0.0 0:00.18 R top 1 root 20 0 10.8m 7.8m 0.7 0.0 0:09.63 S systemd [etc] -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, Oct 21, 2014 at 08:25:55AM -0500, Rex Dieter wrote: Stephen Gallagher wrote: Hello folks, I raised a question with the Board a couple weeks ago[1] as to how we should be branding the different releases. It's been clear that different groups have different opinions on whether we should call something Fedora Server 21 vs. Fedora 21 Server (and Workstation and Cloud, of course). At least until release schedules and/or branding diverge, I personally think it more important to continue to emphasize the version over the product (ie, version should come first), e.g. go with the Fedora 21 $PRODUCT variant +1 The difference between Fedora versions is so far much bigger than the difference between products within one version, so this ordering of distribution.version.product seems right. 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: A few specific comments that have been made on the Board ticket (to avoid rehashing them). * Fedora Server 21 sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? My opinion is that since we've decided on a unified lifecycle and release process for now, we should reflect that in the names, so: Fedora 21 Cloud Fedora 21 Server Fedora 21 Workstation but that we should also allow unversioned naming: Fedora Cloud Fedora Server Fedora Workstation In the future, if we have separated release cycles, I think separate numbering might make sense, with the Built on the Fedora 21 platform wording or similar. Possibily date-based schemes for the products — but I don't want to get the cart too far ahead of the horse on that. Anyway, we need to have a consistent branding decision made for the release (and for the Ambassadors). So please come prepared to find a consensus (not to win a fight). [1] https://fedorahosted.org/board/ticket/11 -- desktop mailing list desk...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop -- 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: top in Rawhide
Am 21.10.2014 um 15:33 schrieb Richard W.M. Jones: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? The default consumes huge amounts of whitespace with a useless display of per-CPU stats, and [not shown] is completely static until you press 'P'. after the first time faced htop 8 years ago never started top again htop is highly configureable in case what you want to see, where and how ordered 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: top in Rawhide
On Tue, Oct 21, 2014 at 02:33:39PM +0100, Richard W.M. Jones wrote: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? The default consumes huge amounts of whitespace with a useless display of per-CPU stats, and [not shown] is completely static until you press 'P'. It doesn't seem to be static for me. (Consider using -d1 or -d0.5 if you like it to update more frequently.) In any case, you can get the old display back by pressing 't' several times to cycle through the options for cpu stats (mnemonic: task, I guess) and the same with 'm' for memory info, and then W (for write) to save the config when you like it. You an also edit the ~/.toprc manually, but... it's a horrible format not meant to be consumed by humans. -- 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: top in Rawhide
On Tue, Oct 21, 2014 at 09:42:30AM -0400, Matthew Miller wrote: On Tue, Oct 21, 2014 at 02:33:39PM +0100, Richard W.M. Jones wrote: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? The default consumes huge amounts of whitespace with a useless display of per-CPU stats, and [not shown] is completely static until you press 'P'. It doesn't seem to be static for me. (Consider using -d1 or -d0.5 if you like it to update more frequently.) In any case, you can get the old display back by pressing 't' several times to cycle through the options for cpu stats (mnemonic: task, I guess) and the same with 'm' for memory info, and then W (for write) to save the config when you like it. That works, thanks. You an also edit the ~/.toprc manually, but... it's a horrible format not meant to be consumed by humans. I see what you mean. Not even in ASCII by the looks of it?! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- 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: top in Rawhide
On Tue, 2014-10-21 at 14:33 +0100, Richard W.M. Jones wrote: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? The default consumes huge amounts of whitespace with a useless display of per-CPU stats, and [not shown] is completely static until you press 'P'. Rich. top - 14:20:04 up 3:46, 3 users, load average: 1.65, 1.18, 1.06 Tasks: 169 total, 1 running, 167 sleeping, 1 stopped, 0 zombie %Cpu0 : 2.0/13.2 15[ ] %Cpu1 : 0.6/60.4 61[ ] %Cpu2 : 0.0/0.7 1[ ] %Cpu3 : 0.0/1.3 1[| ] %Cpu4 : 0.7/1.3 2[| ] %Cpu5 : 0.0/3.4 3[|| ] %Cpu6 : 0.0/1.3 1[| ] %Cpu7 : 9.1/7.116[| ] GiB Mem : 2.8/15.726 [ ] GiB Swap: 0.0/16.000 [ ] PID USER PR NIVIRTRES %CPU %MEM TIME+ S COMMAND 6540 root 20 0 204.7m 86.5m 6.5 0.5 2:35.27 D yum 465 root 20 0 37.8m 21.4m 2.6 0.1 0:11.91 S systemd-journal 9 root 20 00.0m 0.0m 2.0 0.0 0:38.04 S rcuos/1 7274 root 20 00.0m 0.0m 2.0 0.0 0:01.24 S kworker/5:0 16102 rjones20 0 108.1m 3.6m 1.3 0.0 0:00.18 R top 1 root 20 0 10.8m 7.8m 0.7 0.0 0:09.63 S systemd [etc] FWIW, if you press 1 (numeral one), it collapses all the CPUs to a single line covering all of them. I find that quite helpful. signature.asc Description: This is a digitally signed message part -- 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: top in Rawhide
On Tue, Oct 21, 2014 at 09:47:45AM -0400, Stephen Gallagher wrote: FWIW, if you press 1 (numeral one), it collapses all the CPUs to a single line covering all of them. I find that quite helpful. What I really want is one line showing the collapsed view, and a second line showing me if any of the CPUs are pegged at 100% because of some crazy runaway process. Actually, is there a crazy runaway process or processes making my CPU fan go full blast, and if so, what are they? is 95% of what I want when I look at top. -- 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: LLVM 3.5 rebase
On Tue, 2014-10-21 at 13:33 +0200, Sergio Pascual wrote: I have retired python-llvmpy in Rawhide and F21. Now if the owner of llvm does the Obsoletes trick then the rebase can go ahead, is it right? Hopefully! I still need to get dragonegg building, but that at least does have an active upstream. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On 10/21/2014 09:36 AM, Matthew Miller wrote: On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: A few specific comments that have been made on the Board ticket (to avoid rehashing them). * Fedora Server 21 sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? My opinion is that since we've decided on a unified lifecycle and release process for now, we should reflect that in the names, so: Fedora 21 Cloud Fedora 21 Server Fedora 21 Workstation but that we should also allow unversioned naming: Fedora Cloud Fedora Server Fedora Workstation In the future, if we have separated release cycles, I think separate numbering might make sense, with the Built on the Fedora 21 platform wording or similar. Possibily date-based schemes for the products — but I don't want to get the cart too far ahead of the horse on that. ^^^ This From my POV (the designer / branding person,) this is exactly the plan I support. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes for Env-and-Stacks WG meeting (2014-10-21)
#fedora-meeting: Env and Stacks (2014-10-21) Meeting started by hhorak at 13:02:31 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-21/env-and-stacks.2014-10-21-13.02.log.html . Meeting summary --- * init process (hhorak, 13:02:48) * Follow-up -- Docker docs (hhorak, 13:04:46) * ACTION: hhorak will sum up what we agreed the last time on Docker doc and will write it on the wiki for someone who picks it (hhorak, 13:12:02) * Integration tests for packages alias Per-component integration tests in Fedora (hhorak, 13:13:33) * IDEA: we can divide the complex issue into smaller pieces delivered independently -- first have method/rules to keep tests somewhere and write them somehow and later solve how to run them automatically in proper environment (hhorak, 13:29:48) * IDEA: we might consider not to support only one way to define tests, since different use cases need something different and one size does not fit all (hhorak, 13:38:52) * various Fedora maintainers use different approaches right now for components -- some maintainers keep specs in different branches the same and include '%if %fedora' stuff and some prefer different content in different branches and rather have clean spec files (hhorak, 13:47:09) * IDEA: it might be fine if we are able to stay flexible in that regard as well with tests and just are able to provide some sane recommendation (hhorak, 13:47:09) * IDEA: for software collections -- the tests would just be part of the collection (hhorak, 13:49:20) * ACTION: hhorak will send proposal about integration tests to the devel list (hhorak, 13:51:23) * IDEA: if we are able to provide the integration tests as real upstream projects that other distros could benefit from as well, we can start some nice collaboration and benefit all from that (pretty challenging idea, but might be worth keep in mind) (hhorak, 14:07:29) * Picking chairman for the next meeting (hhorak, 14:15:13) * hhorak is actually not available the next week.. (hhorak, 14:15:34) * let's skip the next week's meeting, since many of use won't be here (hhorak, 14:19:40) * let's leave picking a new time to ML discussion and try a new whenisgood (hhorak, 14:40:18) * ACTION: hhorak will chair the meeting in two weeks.. (hhorak, 14:41:23) Meeting ended at 14:43:35 UTC. Action Items * hhorak will sum up what we agreed the last time on Docker doc and will write it on the wiki for someone who picks it * hhorak will send proposal about integration tests to the devel list * hhorak will chair the meeting in two weeks.. Action Items, by person --- * hhorak * hhorak will sum up what we agreed the last time on Docker doc and will write it on the wiki for someone who picks it * hhorak will send proposal about integration tests to the devel list * hhorak will chair the meeting in two weeks.. * **UNASSIGNED** * (none) People Present (lines said) --- * hhorak (62) * juhp (60) * nphilipp (33) * sicampbell (19) * bkabrda (9) * zodbot (4) * ncoghlan (3) * Southern_Gentlem (1) * samkottler (0) * vpavlin (0) * tjanez (0) * pkovar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request new package
There's a guy that created a script for he's own purposes.
So, just to have an idea:
[Unit]
Description=Sheepdog QEMU/KVM Block Storage
After=syslog.target
[Service]
EnvironmentFile=/etc/conf.d/
sheep.conf
ExecStart=/usr/sbin/sheep --pidfile /var/run/sheep.pid ${SHEEP_OPTS}
${SHEEP_PATH}
PIDFile=/var/run/sheep.pid
Type=forking
[Install]
WantedBy=multi-user.target
sheep.conf have this for example:
SHEEP_OPTS=-c local -D -u
SHEEP_PATH=/var/lib/sheepdog
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-10-22)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-10-22 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1355 Please select Engineering Representiatve for the new Fedora Council .fesco 1355 https://fedorahosted.org/fesco/ticket/1355 See also https://lists.fedoraproject.org/pipermail/devel/2014-October/203391.html #topic #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline .fesco 1322 https://fedorahosted.org/fesco/ticket/1322 = New business = #topic #1357 please consider django-1.7 as late feature for f21 .fesco 1357 https://fedorahosted.org/fesco/ticket/1357 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Oct 21, 2014, at 9:36 AM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: A few specific comments that have been made on the Board ticket (to avoid rehashing them). * Fedora Server 21 sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? My opinion is that since we've decided on a unified lifecycle and release process for now, we should reflect that in the names, so: Fedora 21 Cloud Fedora 21 Server Fedora 21 Workstation Yes. Since people have a tendency to shorten, I think we'll see F21C, F21S, F21W as a result. That's probably better than FC21 for cloud where it's confused with .fc21 in all of our RPMS, and even vernacular people still interchange F20 and FC20 calling back to Fedora Core days. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What are the ELF shared lib symbol versioning best practices?
Is there a good description of ELF shared library symbol versioning best practices somewhere? In particular, under what conditions do you need to create a new section in the versioning file given to the linker's --version-script option when new symbols are added? And what do you do if you've done it wrong? For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when I should perhaps have created KEYUTILS_1.5 and added them there: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 I have been given a patch to move these symbols to KEYUTILS_1.5, but checking the keyctl program with readelf -s, I see: 47: 0 FUNCGLOBAL DEFAULT UND recursive_session_key_sca@KEYUTILS_1.4 (7) so I would guess applying this patch would break anything that uses this. I assumed that adding them to KEYUTILS_1.4 would be okay because nothing would've tried to use them previously because they didn't exist in any version. 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Should be Fedora 21 $PRODUCT because the Fedora version is underneath the product, and one product can usually convert into another on an installed system. -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
2014-10-21 16:39 GMT+02:00 Máirín Duffy du...@fedoraproject.org: On 10/21/2014 09:36 AM, Matthew Miller wrote: On Tue, Oct 21, 2014 at 08:28:16AM -0400, Stephen Gallagher wrote: A few specific comments that have been made on the Board ticket (to avoid rehashing them). * Fedora Server 21 sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? My opinion is that since we've decided on a unified lifecycle and release process for now, we should reflect that in the names, so: Fedora 21 Cloud Fedora 21 Server Fedora 21 Workstation but that we should also allow unversioned naming: Fedora Cloud Fedora Server Fedora Workstation In the future, if we have separated release cycles, I think separate numbering might make sense, with the Built on the Fedora 21 platform wording or similar. Possibily date-based schemes for the products — but I don't want to get the cart too far ahead of the horse on that. ^^^ This From my POV (the designer / branding person,) this is exactly the plan I support. Amen This is a fair compromise between having a consistent numbering and a strong product branding. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request new package
See, that's easy ! :) H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
2014-10-21 17:06 GMT+02:00 David Timothy Strauss da...@davidstrauss.net: Should be Fedora 21 $PRODUCT because the Fedora version is underneath the product, and one product can usually convert into another on an installed system. Caution, there is no guarantee that it will always be supported. As far as the Cloud Product is concerned, only conversion to Server Product (aka adopting a cattle) scenario will be supported. And we haven't ruled out yet, different lifecycles for products in the long term. As long as it makes sense and that our infrastructure could cope with it, off course H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote: Is there a good description of ELF shared library symbol versioning best practices somewhere? In particular, under what conditions do you need to create a new section in the versioning file given to the linker's --version-script option when new symbols are added? For libvirt, we create a new version section for each new upstream release. ie so all new APIs in a release get tagged with the version number of the release they first appeared in. And what do you do if you've done it wrong? Cry, and then live with it forever, unless you want to break ABI and force all downstream apps to re-link :-( For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when I should perhaps have created KEYUTILS_1.5 and added them there: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 I have been given a patch to move these symbols to KEYUTILS_1.5, but checking the keyctl program with readelf -s, I see: 47: 0 FUNCGLOBAL DEFAULT UND recursive_session_key_sca@KEYUTILS_1.4 (7) so I would guess applying this patch would break anything that uses this. Yes, unfortunately anything which has already linked against your library *and* used these original symbols will have the 1.4 version encoded in their ELF section. So if you change the version to 1.5 you will cause linker loading failures which can only be fixed by rebuilding the downstream apps. I assumed that adding them to KEYUTILS_1.4 would be okay because nothing would've tried to use them previously because they didn't exist in any version. One thing to bear in mind with symbol versioning is that it also interacts with RPM versioning. ie, if an application links to a symbol foo@MYLIB_X.Y then the RPM will automatically get a Requires: mylib.so(MYLIB_X.Y) added to it. This ensures that when you install the application, it pulls in a version of the library that is new enough to have all the symbols the application needs. Note that RPM only depends on the version, not the full symbol name. So by adding new symbols to the existing KEYUTILS_1.4 version section, no new RPM dependancies will be introduced. So an RPM install of an application that uses the new symbols, will still be (mistakenly) satisfied by the an old version of the library that lacks the symbols. This is the primary reason why for libvirt, we take the approach of always introducing a new version block for each new release that includes new APIs. BTW, there is one tricky thing to be aware of if you ever backport new APIs to old stable branches. You likely want to avoid adding a linker version section for the stable branch, since if an app links against the stable branch version of the library, you want a clean upgrade path to the next major version of the library (assuming preserved ABI). I've never found any particularly good docs on symbol versioning when I've looked previously. In case it helps though, here's how we deal with it in libvirt: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/ In summary, I'd probably suggest you just live with the symbols as part of the KEYUTILS_1_4 version block. It isn't a particularly serious hardship that those were added to an old version block, so not worth the pain of changing them (unless you plan to break ABI and change soname version anyway). Then for future API additions just define a new version section for each new release that adds APIs. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, 2014-10-21 at 15:59 +0100, David Howells wrote: Is there a good description of ELF shared library symbol versioning best practices somewhere? In particular, under what conditions do you need to create a new section in the versioning file given to the linker's --version-script option when new symbols are added? Every time you add _any_ new exported symbol to the API. And what do you do if you've done it wrong? For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when I should perhaps have created KEYUTILS_1.5 and added them there: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 I have been given a patch to move these symbols to KEYUTILS_1.5, but checking the keyctl program with readelf -s, I see: 47: 0 FUNCGLOBAL DEFAULT UND recursive_session_key_sca@KEYUTILS_1.4 (7) so I would guess applying this patch would break anything that uses this. I assumed that adding them to KEYUTILS_1.4 would be okay because nothing would've tried to use them previously because they didn't exist in any version. Since rpm emits dependencies based on imported symbol versions (and not whole version/symbol tuples), the problem this introduces is that an app using this new symbol will only require KEYUTILS_1.4, and some versions of keyutils will provide that version but not all of the symbols _in_ that version. But symbol versions are also permanent; now that there are apps in the world that want foo@KEYUTILS_1.4, you can never remove that. You could add it to _1.5 too, but having made the error it's not really fixing anything to do that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, Oct 21, 2014 at 12:13:19PM -0400, Adam Jackson wrote: On Tue, 2014-10-21 at 15:59 +0100, David Howells wrote: Is there a good description of ELF shared library symbol versioning best practices somewhere? In particular, under what conditions do you need to create a new section in the versioning file given to the linker's --version-script option when new symbols are added? Every time you add _any_ new exported symbol to the API. Every symbol doesn't have to have a new symbol version, it is just fine if there is just one symbol version per release that added symbols, as long as the development snapshots in between releases are not significantly wide-spread/used as stable versions. On stable branches, if you add symbols there, it typically should be that all symbols added together can share the same new symbol version, but for symbols added at different times different symbol versions should be used. But symbol versions are also permanent; now that there are apps in the world that want foo@KEYUTILS_1.4, you can never remove that. You could add it to _1.5 too, but having made the error it's not really fixing anything to do that. Yeah. You could have foo@KEYUTILS_1.4 as something users can't link to and foo@@KEYUTILS_1.5 if you want. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote: Is there a good description of ELF shared library symbol versioning best practices somewhere? In particular, under what conditions do you need to create a new section in the versioning file given to the linker's --version-script option when new symbols are added? And what do you do if you've done it wrong? For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when I should perhaps have created KEYUTILS_1.5 and added them there: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 I have been given a patch to move these symbols to KEYUTILS_1.5, but checking the keyctl program with readelf -s, I see: 47: 0 FUNCGLOBAL DEFAULT UND recursive_session_key_sca@KEYUTILS_1.4 (7) so I would guess applying this patch would break anything that uses this. I assumed that adding them to KEYUTILS_1.4 would be okay because nothing would've tried to use them previously because they didn't exist in any version. David Honestly, I don't think it matters, since the versions are all just arbitrary stings anyway. The fact that you added a symbol to an older version string rather than a new one isn't at all relevant to pre-existing binaries. And existing source code won't care about it if you happen to relink (as you note, older code won't use the new symbol anyway). The only real pain about it is that you need to keep it there now, since binaries linked against that version reference it as symbol@KEYUTILS_1.4. Irritating, maybe. Catastrophic, no. You certainly can do as libvirt does, and explicitly define the export list for every version, and there are some niceties to that, but its really not necessecary. IIRC, Glibc does exactly as you (meant to) do, in that new symbols are added into new version node piecemeal. Neil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On 10/21/2014 10:59 AM, David Howells wrote: Is there a good description of ELF shared library symbol versioning best practices somewhere? If you haven't already read Uli's paper, that's a start: http://www.akkadia.org/drepper/dsohowto.pdf (section 3 in particular) -- 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: man-db without cache update (no cron or systemd *.timer)
On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote:
Hmm, not sure I follow here. Since when is systemd an optional
component in Fedora?
I have been spending much of my time building Fedora-based Docker
containers recently. I've been sticking to the
one-process-per-container model because I think it brings a number of
advantages. One of the biggest, in my opinion, is that container
management reduces to process management, and I already have a
great process manager on my host. It's called systemd.
Decomposing an application into single-process containers also means
that it's easier to scale individual components. *And* for many
applications -- those that can log to stderr/stdout -- it means
that application logs show up in my host journal *where I want them*.
Running any sort of process manager inside the container can also have
the unintended side-effect of hiding problems from the host. If an
application is failing to start because of a configuration issue, I
don't want that managed inside the container -- I want the host to be
aware of that so that higher-level mechanisms can be involved. I want
a host- or cluster- level container manager to be able to restart
dependent containers, or to have the opportunity to reschedule a
container on another host.
I think it is absolutely essential that systemd is *able* to run
inside a container -- because I think there are invariably going to be
situations in which the one-process-per-container model simply doesn't
pan out. But I also think that in many situations it is not required
and using systemd inside the container simply complicates things.
--
Lars Kellogg-Stedman l...@redhat.com | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpM0qJf6tF8K.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
Broken deps in rawhide (coreutils)
Today I got report that there are failed builds in Copr for rawhide chroots. [1] After investigation I find that coreutils are installed too late, so they are not available to previous postcripts: Installing : crypto-policies-20140905-1.git4649b7d.fc22.noarch 136/239 /usr/bin/update-crypto-policies: line 39: cat: command not found /usr/bin/update-crypto-policies: line 43: cat: command not found Couldn't read current profile warning: %post(crypto-policies-20140905-1.git4649b7d.fc22.noarch) scriptlet failed, exit status 1 Non-fatal POSTIN scriptlet failure in rpm package crypto-policies-20140905-1.git4649b7d.fc22.noarch ... Installing : libblkid-2.25.1-1.fc22.x86_64 138/239 /var/tmp/rpm-tmp.yCcv5b: line 4: mkdir: command not found ... Installing : pam-1.1.8-18.fc22.x86_64 143/239 /var/tmp/rpm-tmp.4J2sJD: line 3: /usr/bin/install: No such file or directory warning: %post(pam-1.1.8-18.fc22.x86_64) scriptlet failed, exit status 127 Non-fatal POSTIN scriptlet failure in rpm package pam-1.1.8-18.fc22.x86_64 Installing : coreutils-8.23-4.fc22.x86_64 144/239 This is just small sample, there is much more errors. And it is not just coreutils (but that produce most errors). E.g. I seen errors caused by ordering of libXft too: Installing : pango-1.36.8-1.fc22.x86_64 133/239 /usr/bin/pango-querymodules-64: error while loading shared libraries: libXft.so.2: cannot open shared object file: No such file or directory Installing : libXft-2.3.2-2.fc22.x86_64 134/239 And there may be even more examples. You can try it yourself by: rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/* /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever rawhide install @buildsys-build --setopt=tsflags=nocontexts --nogpgcheck Few days ago it seemed to work. Does somebody have idea what changed recently? Is is because of some change in rpm, yum, something else? Why it work in koji [2]? Why is pam installed before coreutils even when pam have Requires(post): coreutils, /sbin/ldconfig ? Mirek [1] http://copr-be.cloud.fedoraproject.org/results/jwboyer/kernel-playground/fedora-rawhide-x86_64/kernel-3.18.0-0.rc1.git0.1.playground.fc22/root.log [2] https://kojipkgs.fedoraproject.org//packages/kernel/3.18.0/0.rc1.git0.1.fc22/data/logs/i686/root.log -- 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: top in Rawhide
On 10/21/2014 03:33 PM, Richard W.M. Jones wrote: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? It is in F21 too. Type: tttmmVbz1W and you get original look and feel. For discussion see bug 1153049. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
On Tue, 21 Oct 2014 08:28:16 -0400 Stephen Gallagher sgall...@redhat.com wrote: Hello folks, I raised a question with the Board a couple weeks ago[1] as to how we should be branding the different releases. It's been clear that different groups have different opinions on whether we should call something Fedora Server 21 vs. Fedora 21 Server (and Workstation and Cloud, of course). I was asked by the Board to get input from each of the working groups as well as marketing and branding folks. I'm sending this to each of these lists, but PLEASE keep all replies on the devel@lists.fedoraproject.org list or it will be impossible to keep track of the replies. (I've set the reply-to header on this email; please try not to lose it). A few specific comments that have been made on the Board ticket (to avoid rehashing them). * Fedora Server 21 sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? Anyway, we need to have a consistent branding decision made for the release (and for the Ambassadors). So please come prepared to find a consensus (not to win a fight). [1] https://fedorahosted.org/board/ticket/11 Fedora 21 - Server ? 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: top in Rawhide
On Tue, 2014-10-21 at 19:26 +0200, Miroslav Suchy wrote: On 10/21/2014 03:33 PM, Richard W.M. Jones wrote: Anyone worked out how to get top to give a normal (ie. old) display in Rawhide? It is in F21 too. Type: tttmmVbz1W and you get original look and feel. For discussion see bug 1153049. Just as a warning to anyone following these instructions, it will alter (or create) ~/.toprc, so if you just want to try it out, skip the last W (capital-'w') so it doesn't write it out. signature.asc Description: This is a digitally signed message part -- 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: Broken deps in rawhide (coreutils)
On Tue, 21 Oct 2014 19:23:29 +0200 Miroslav Suchy msu...@redhat.com wrote: Today I got report that there are failed builds in Copr for rawhide chroots. [1] ...snip... And there may be even more examples. You can try it yourself by: rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/* /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever rawhide install @buildsys-build --setopt=tsflags=nocontexts --nogpgcheck Few days ago it seemed to work. Does somebody have idea what changed recently? Is is because of some change in rpm, yum, something else? Why it work in koji [2]? Why is pam installed before coreutils even when pam have Requires(post): coreutils, /sbin/ldconfig This is a fun one. I am pointing the finger right now at icecat. It seems to be providing all the nss libraries and 'winning' the dependency. It's making all the buildroots a good deal larger than they need to be, and possibly making them link to the wrong nss/nspr, etc. ;( I'm not sure why koji buildroots aren't busted however, unless it's somehow the hosts yum (in the case of koji, f20 and copr el6) is doing things differently? 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: Improving the offline updates user experience
On Mon, 2014-10-13 at 11:26 -0400, Stephen Gallagher wrote: On Thu, 2014-10-02 at 07:53 -0400, Stephen Gallagher wrote: On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote: == The Problem == It is very common for users to have systems with encrypted root partitions (or even just /var and /etc). This may be due to a personal concern for their data or a corporate policy mandating full-disk encryption. Disk encryption requires a password (or other more complicated credentials) be be presented just after the kernel is booted and before the drives can be mounted and their data read. With the current implementation of the offline updates in Fedora, this leads to a very unpleasant user experience when updating. We offer two ways to perform offline updates in the default user environment of Fedora Workstation: Install updates and reboot or Install updates and shut down. With Install updates and reboot, the behavior is as follows: 1) The system shuts down and initiates an ACPI reboot. 2) The system presents the kernel boot menu and then starts the updater kernel. 3) The system presents the user with a password prompt for the disk encryption (possibly more than one, if the system is configured with different passwords for different partitions). 4) The offline updates occur. 5) The system shuts down and initiates an ACPI reboot. 6) The system presents the kernel boot menu and then starts the standard (possibly updated) kernel. 7) The system presents the user with a password prompt for the disk encryption (possibly more than one, if the system is configured with different passwords for different partitions). 8) The system completes booting. During this experience, the user has been required to enter their disk encryption password *twice*. The same is true for the Install and shut down case, except that the two passwords are separated by some actual wallclock time. == Proposed Improvements == We could significantly improve this situation by allowing the system to drop directly from the interactive system into the updater environment without doing a full reboot or relaunching the kernel. Lennart, would it be possible to set up a special systemd target for performing updates that would essentially stop all processes except for systemd and then apply the updates? In an ideal world, it would then also be possible after update is completed to restore operation to the standard boot targets of systemd so that the system comes back up without having to perform a total reboot. The exceptional case would of course be that in which either the kernel, libc or systemd[1] needed to be updated, in which case a reboot could be performed. In this scenario, we can reduce the number of encrypted disk challenges to at most a single one, and that only if absolutely minimal plumbing packages saw an update. I'd very much like to hear from the plumbers on this matter. [1] I'm told that this might not be necessary; that systemd can re-exec itself to pick up its own updates. That would reduce the scope presumably to only the kernel forcing reboots. I'm bumping this thread to get comments from Lennart (CCed). There's a lot of chatter in the conversation, but I'd very much like to hear an answer to the specific questions I posed in this first email. Trying one more time to get Lennart to chime in here. I spotted on another mailing list that Lennart is using a different email address these days. I'm now trying to reach him on that one instead. signature.asc Description: This is a digitally signed message part -- 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: Decision on Fedora Product branding: Fedora $PRODUCT 21 vs Fedora 21 $PRODUCT
Fedora 21 Workstation Fedora 21 Server Fedora 21 Cloud That makes it easy for us remixers - CompJournoStick 21 Workstation, for example. On Tue, Oct 21, 2014 at 11:06 AM, Simo Sorce s...@redhat.com wrote: On Tue, 21 Oct 2014 08:28:16 -0400 Stephen Gallagher sgall...@redhat.com wrote: Hello folks, I raised a question with the Board a couple weeks ago[1] as to how we should be branding the different releases. It's been clear that different groups have different opinions on whether we should call something Fedora Server 21 vs. Fedora 21 Server (and Workstation and Cloud, of course). I was asked by the Board to get input from each of the working groups as well as marketing and branding folks. I'm sending this to each of these lists, but PLEASE keep all replies on the devel@lists.fedoraproject.org list or it will be impossible to keep track of the replies. (I've set the reply-to header on this email; please try not to lose it). A few specific comments that have been made on the Board ticket (to avoid rehashing them). * Fedora Server 21 sounds like we've had 21 releases of Fedora Server and we certainly haven't. * Should we start all of the Products at version 1 and say built on the Fedora 21 platform? Anyway, we need to have a consistent branding decision made for the release (and for the Ambassadors). So please come prepared to find a consensus (not to win a fight). [1] https://fedorahosted.org/board/ticket/11 Fedora 21 - Server ? 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 -- Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick http://j.mp/CompJournoStickOverview Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What are the ELF shared lib symbol versioning best practices?
On 2014-10-21 18:11, Daniel P. Berrange wrote: On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote: I assumed that adding them to KEYUTILS_1.4 would be okay because nothing would've tried to use them previously because they didn't exist in any version. One thing to bear in mind with symbol versioning is that it also interacts with RPM versioning. ie, if an application links to a symbol foo@MYLIB_X.Y then the RPM will automatically get a Requires: mylib.so(MYLIB_X.Y) added to it. This ensures that when you install the application, it pulls in a version of the library that is new enough to have all the symbols the application needs. Note that RPM only depends on the version, not the full symbol name. So by adding new symbols to the existing KEYUTILS_1.4 version section, no new RPM dependancies will be introduced. So an RPM install of an application that uses the new symbols, will still be (mistakenly) satisfied by the an old version of the library that lacks the symbols. Within Debian, library source packages can make use of a special versioning system which is used by other packages to calculate dependencies. In this versioning system, every upstream symbol is mapped to the Debian source package version in which this symbol was introduced into the archive. For example, for the two symbols discussed above, we have [...] recursive_key_scan@KEYUTILS_1.4 1.5.2 recursive_session_key_scan@KEYUTILS_1.4 1.5.2 [...] indicating that the two upstream symbols *@KEYUTILS_1.4 where first introduced into Debian with package version 1.5.2 (apparently upstream releases 1.5.0 and 1.5.1 were skipped). Consequently, packages built against libkeyutils1 using those symbols will always depend on a Debian package version of at least 1.5.2, despite them being marked as 1.4 upstream. This allows for a much finer control of package dependency calculation than the default we use. But, of course, this only applies when the package maintainer actually decides to use this feature. Just thought this might be something interesting to share. Regards, Christian -- 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: Improving the offline updates user experience
On Fri, 12.09.14 10:46, Stephen Gallagher (sgall...@redhat.com) wrote: It is very common for users to have systems with encrypted root partitions (or even just /var and /etc). This may be due to a personal Nitpicking: we currently do not support split-off /etc on Fedora/Dracut. /var may be split out though. We could significantly improve this situation by allowing the system to drop directly from the interactive system into the updater environment without doing a full reboot or relaunching the kernel. Lennart, would it be possible to set up a special systemd target for performing updates that would essentially stop all processes except for systemd and then apply the updates? Well, the entire logic we have in place for offline updates is to ensure that they are applied in a well-defined very clean, minimal environment. Actually, that's not just the logic that is in place, that's the whole reason for having them at all! I mean, if it is OK to allow leaking runtime state into the upgrade process we could just run the updates in parallel to normal runtime, how we always did things. Or in even otherwords: offline updates are supposed to make update strictly reliable, and for that I figure a full reset and fresh boot, with everything initialized to the boot-up defaults is the closest if not only option. That all said, we have been discussing supporting a new reboot-mode in systemd, which would essentially shut down userspace, until only PID 1 remains, and then immediately start userspace again on the same kernel. This would be pretty close to what you are asking for here... However, so far we have quite some concerns about adding this, precisely for the reason that it pretends to be a reset of everything to the boot-up defaults, but actually isn't, as a ton of runtime state is retained in /sys and /proc/sys and other runtime objects. [1] I'm told that this might not be necessary; that systemd can re-exec itself to pick up its own updates. That would reduce the scope presumably to only the kernel forcing reboots. Well, you cannot really do this atomically. Offline updates are about reliability. But you cannot restart userspace reliably during runtime. Think about this: daemons talk to each other, supporting a variety of APIs and API versions. If we want to do an update, then we'd have to restart all daemons at the same instant to ensure that no daemon starts talking with another daemon at the wrong time where it might be confused by either a too old or too new daemon. However, restarten them all at once is not possible. Moreover, some daemons cannot be restarted at all (for example dbus-daemon; and journald is difficult too, as it will lose connections to all other daemon's stdout/stderr if you do, even though it other works fine). Hence: I'd really recommend leaving offline updates as is. I see the problem though and acknowledge the fact that entering the passwords multiple times is annoying. Interestingly hw hdd encryption is nicer there as the keys are not flushed out on resets... Maybe that's actually a strategy to adopt here: upload the encryption keys into the firmware as efi vars, and then pull them out on next boots or so (assuming that efi vars can be marked to survive soft reboots without making them fully persistent...) I understand this is all unsatisfying. Maybe fixing related problems might improve the situation a bit though. For example, I find it quite annoying if we always ask for both a hdd passphrase and a user passphrase at boot. It has been a long-time todo list item for systemd to add the hdd passphrases (with strict expiry) to the kernel keyring and then optionally pull them out there for gdm's autologin mode, so that they can be used for decrypting the gnome keyring and such. However, so far we haven't worked on that yet... 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: Improving the offline updates user experience
On Fri, 12.09.14 18:37, Reindl Harald (h.rei...@thelounge.net) wrote: Am 12.09.2014 um 18:33 schrieb Nathanael d. Noblet: So I don't use Firefox anymore but I do know back in the day if we had FF open when we updated it would do a double request for each page/form. However when updating we just restarted FF and it would work fine after that. I've never noticed any other issues than FF but like I said I don't use it anymore. Granted that doesn't matter obviously we don't want that kind of behaviour. I am curious though. Everyone says the only way to do it securely and safely is with nothing running. Why can't updates be applied with stuff running prior to a reboot? 1 out of a million cases needs offline updates really - the only good at it is that you can stick at using YUM and decide what you have to do at your own - rarely updates really require a reboot * lsof | grep DEL | grep /usr and restart services on servers Well, some deps are not visible like that, because they do not involve continuous mappings or open fds. Moreover, it won't help you much anyway, as some daemons are not restarble right now, most prominently dbus-daemon. And strictly speaking as you cannot restart all daemons at the very same instant, or even at the same instant as you install the new files and remove the old ones you will always have races where daemons might make use of resources or interfaces that are either newer than what they expect or older. offline updates are really about make updates fully reliable. Yes, in most cases a yum update during runtime works well enough, and yes, I usually do my updates that way too. But I am actually able to help myself if something goes wrong. And so are you. Offline updates are more for the cases where things need to be reliable, because no well educated admin is available to instantly fix things. Possibly because the machine is used by noobs only, or because the machine is buried somewhere under the see, or where so many instances of the machine are running that a human admins don't scale. Hope that makes some sense. 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: Improving the offline updates user experience
Am 21.10.2014 um 22:08 schrieb Lennart Poettering: On Fri, 12.09.14 18:37, Reindl Harald (h.rei...@thelounge.net) wrote: 1 out of a million cases needs offline updates really - the only good at it is that you can stick at using YUM and decide what you have to do at your own - rarely updates really require a reboot * lsof | grep DEL | grep /usr and restart services on servers Well, some deps are not visible like that, because they do not involve continuous mappings or open fds. may be true but in practice no problem over many years Moreover, it won't help you much anyway, as some daemons are not restarble right now, most prominently dbus-daemon you repeat that again and again while i restart dbus over years on headless machines for web/file/db-servers and frankly before F15 even messagebus was completly disabled on all that machines And strictly speaking as you cannot restart all daemons at the very same instant, or even at the same instant as you install the new files and remove the old ones you will always have races where daemons might make use of resources or interfaces that are either newer than what they expect or older. interesting is that not so long ago there where just not much such dependencies - mandatory presence of dbus is very recent other services like some webapp talking to a db-server? frankly i wrote 10 years ago db-layers to wait and retry so you can restart the db server after an update offline updates are really about make updates fully reliable. Yes, in most cases a yum update during runtime works well enough, and yes, I usually do my updates that way too. But I am actually able to help myself if something goes wrong. And so are you. true Offline updates are more for the cases where things need to be reliable, because no well educated admin is available to instantly fix things. Possibly because the machine is used by noobs only, or because the machine is buried somewhere under the see, or where so many instances of the machine are running that a human admins don't scale Hope that makes some sense yes, but keep in mind not introduce more and more dependencies to make them mandatory somewhere in the future 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
[Bug 1154974] New: perl-Devel-Timer-0.05-2.fc22 FTBFS randomly: Failed test 'sort by count' at t/test.t line 73
https://bugzilla.redhat.com/show_bug.cgi?id=1154974
Bug ID: 1154974
Summary: perl-Devel-Timer-0.05-2.fc22 FTBFS randomly: Failed
test 'sort by count' at t/test.t line 73
Product: Fedora
Version: rawhide
Component: perl-Devel-Timer
Assignee: de...@fateyev.com
Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org
perl-Devel-Timer-0.05-2.fc22 fails to build sometimes because 'sort by count'
t/test.t test fails randomly:
$ prove -b -v t/test.t
t/test.t ..
1..49
ok 1 - use Devel::Timer;
ok 2 - Total time
ok 3 - header
ok 4 - step 0
ok 5 - step 1
ok 6 - step 2
ok 7 - step 3
ok 8 - step 4
ok 9 - step 5
ok 10 - step 6
ok 11 - no step 7
ok 12 - Total time
ok 13 - header
ok 14 - A - B
ok 15 - B - C
ok 16 - B - A
ok 17 - INIT - A
ok 18 - order by time descending
ok 19 - Total time
ok 20 - header
ok 21 - A - B
ok 22 - B - C
ok 23 - B - A
ok 24 - INIT - A
not ok 25 - sort by count
# Failed test 'sort by count'
# at t/test.t line 73.
ok 26 - get_stats('A', 'B')
ok 27 - $time
ok 28 - $time
ok 29 - $percent
ok 30 - $percent
ok 31 - $count
ok 32 - get_stats('B', 'A')
ok 33 - $time
ok 34 - $time
ok 35 - $percent
ok 36 - $percent
ok 37 - $count
ok 38 - get_stats('B', 'C')
ok 39 - $time
ok 40 - $time
ok 41 - $percent
ok 42 - $percent
ok 43 - $count
ok 44 - get_stats('INIT', 'A')
ok 45 - $time
ok 46 - $time
ok 47 - $percent
ok 48 - $percent
ok 49 - $count
# Looks like you failed 1 test of 49.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/49 subtests
Test Summary Report
---
t/test.t (Wstat: 256 Tests: 49 Failed: 1)
Failed test: 25
Non-zero exit status: 1
--
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=N8lZ0bHobxa=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 1154974] perl-Devel-Timer-0.05-2.fc22 FTBFS randomly: Failed test 'sort by count' at t/test.t line 73
https://bugzilla.redhat.com/show_bug.cgi?id=1154974 --- Comment #1 from Denis Fateyev de...@fateyev.com --- I saw similar behavior sometimes earlier too, but haven't found any tendency since it can fail one 1 time per 10 runs, or so. Looks like I need to contact upstream for clarification. -- 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=eIeWcgmdcCa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Version-1.004001.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Version: 539cf46f84d54f670bff8710ce072ed2 Test-Version-1.004001.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Version] Update to 1.004001
commit 1a5274ba49f39b6fb8d555b62071efe9e0a46137
Author: Paul Howarth p...@city-fan.org
Date: Tue Oct 21 10:08:26 2014 +0100
Update to 1.004001
- New upstream release 1.004001
- Improved consistent check diagnostics (GH#11)
perl-Test-Version.spec |6 +-
sources|2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Test-Version.spec b/perl-Test-Version.spec
index d93bac4..c930ed1 100644
--- a/perl-Test-Version.spec
+++ b/perl-Test-Version.spec
@@ -2,7 +2,7 @@
%global debug_package %{nil}
Name: perl-Test-Version
-Version: 1.004000
+Version: 1.004001
Release: 1%{?dist}
Summary: Check to see that versions in modules are sane
License: Artistic 2.0
@@ -93,6 +93,10 @@ make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
%{_mandir}/man3/Test::Version.3pm*
%changelog
+* Tue Oct 21 2014 Paul Howarth p...@city-fan.org - 1.004001-1
+- Update to 1.004001
+ - Improved consistent check diagnostics (GH#11)
+
* Mon Oct 20 2014 Paul Howarth p...@city-fan.org - 1.004000-1
- Update to 1.004000
- Add consistent check (GH#10)
diff --git a/sources b/sources
index 39b33c7..3d78ba4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cf34b0f5695ea9cc47b7b4ae2a6c70e1 Test-Version-1.004000.tar.gz
+539cf46f84d54f670bff8710ce072ed2 Test-Version-1.004001.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Version/f21] Update to 1.004001
Summary of changes: 1a5274b... Update to 1.004001 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Version] Created tag perl-Test-Version-1.004001-1.fc21
The lightweight tag 'perl-Test-Version-1.004001-1.fc21' was created pointing to: 1a5274b... Update to 1.004001 -- 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-Version] Created tag perl-Test-Version-1.004001-1.fc22
The lightweight tag 'perl-Test-Version-1.004001-1.fc22' was created pointing to: 1a5274b... Update to 1.004001 -- 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 1155047] New: perl-POE-Component-Client-DNS-1.053-5.fc22 FTBFS in non-koji mock: nameservers: invalid argument at /builddir/build/BUILD/POE-Component-Client-DNS-1.053/blib/lib/POE/Component/Clien
https://bugzilla.redhat.com/show_bug.cgi?id=1155047 Bug ID: 1155047 Summary: perl-POE-Component-Client-DNS-1.053-5.fc22 FTBFS in non-koji mock: nameservers: invalid argument at /builddir/build/BUILD/POE-Component-Client-DNS-1.053/b lib/lib/POE/Component/Client/DNS.pm line 344 Product: Fedora Version: rawhide Component: perl-POE-Component-Client-DNS Assignee: psab...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com perl-POE-Component-Client-DNS-1.053-5.fc22 fails to build a mock because a test fails there: + make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -MTest::Harness -e undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch') t/*.t # Testing with Perl 5.020001, /usr/bin/perl # ExtUtils::MakeMaker version is 6.98 # Net::DNS version is 0.80 # POE version is 1.365 # Test::More version is 1.001008 # Test::NoWarnings version is 1.04 t/000-report-versions.t ... ok t/01_resolve.t ok t/02_tag_args.t ... ok t/03_api_3.t .. ok t/04_errors.t . ok nameservers: invalid argument at /builddir/build/BUILD/POE-Component-Client-DNS-1.053/blib/lib/POE/Component/Client/DNS.pm line 344. # Looks like you planned 6 tests but ran 2. # Looks like your test exited with 22 just after 2. t/05_api_4.t .. Dubious, test returned 22 (wstat 5632, 0x1600) Failed 4/6 subtests t/06_hosts.t .. ok t/release-pod-coverage.t .. skipped: these tests are for release candidate testing t/release-pod-syntax.t skipped: these tests are for release candidate testing Test Summary Report --- t/05_api_4.t(Wstat: 5632 Tests: 2 Failed: 0) Non-zero exit status: 22 Parse errors: Bad plan. You planned 6 tests but ran 2. Difference between last working and failing build root is: Removed packages: bash-4.3.24 glib2-2.41.4 libgpg-error-1.13 libtasn1-4.1 nss-3.17.0 nss-softokn-3.17.0 nss-softokn-freebl-3.17.0 nss-sysinit-3.17.0 nss-tools-3.17.0 nss-util-3.17.0 p11-kit-0.21.2 p11-kit-trust-0.21.2 pcre-8.35 perl-5.20.0 perl-Business-ISBN-2.07 perl-Business-ISBN-Data-20120719.001 perl-Compress-Raw-Bzip2-2.064 perl-Compress-Raw-Zlib-2.065 perl-Data-Dumper-2.151 perl-devel-5.20.0 perl-Exporter-5.70 perl-ExtUtils-Embed-1.32 perl-ExtUtils-Manifest-1.66 perl-HTTP-Tiny-0.049 perl-IO-Compress-2.064 perl-IO-Tty-1.11 perl-libs-5.20.0 perl-macros-5.20.0 perl-Module-CoreList-3.11 perl-Net-DNS-0.79 perl-PathTools-3.47 redhat-rpm-config-24 rpm-4.12.0 rpm-build-4.12.0 rpm-build-libs-4.12.0 rpm-libs-4.12.0 rpm-plugin-selinux-4.12.0 Added packages: bash-4.3.25 glib2-2.42.0 gnat-srpm-macros-1 libgpg-error-1.16 libtasn1-4.2 nss-3.17.1 nss-softokn-3.17.1 nss-softokn-freebl-3.17.1 nss-sysinit-3.17.1 nss-tools-3.17.1 nss-util-3.17.1 p11-kit-0.21.3 p11-kit-trust-0.21.3 pcre-8.36 perl-5.20.1 perl-Business-ISBN-2.09 perl-Business-ISBN-Data-20140910.002 perl-Compress-Raw-Bzip2-2.066 perl-Compress-Raw-Zlib-2.066 perl-Data-Dumper-2.154 perl-devel-5.20.1 perl-Exporter-5.71 perl-ExtUtils-Manifest-1.68 perl-HTTP-Tiny-0.050 perl-IO-Compress-2.066 perl-IO-Tty-1.12 perl-libs-5.20.1 perl-macros-5.20.1 perl-Module-CoreList-5.020001 perl-Net-DNS-0.80 perl-PathTools-3.48 redhat-rpm-config-26 rpm-4.12.0.1 rpm-build-4.12.0.1 rpm-build-libs-4.12.0.1 rpm-libs-4.12.0.1 rpm-plugin-selinux-4.12.0.1 -- 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=zT4MWt6YTNa=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 1127473] Please update to upstream version = 0.06
https://bugzilla.redhat.com/show_bug.cgi?id=1127473 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-HTML-WikiConverter-Mar ||kdown-0.06-1.fc19 Resolution|--- |ERRATA Last Closed||2014-10-21 06:26:18 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-HTML-WikiConverter-Markdown-0.06-1.fc19 has been pushed to the Fedora 19 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=e7FBtOIMrHa=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 1127471] Please update to upstream version = 0.06
https://bugzilla.redhat.com/show_bug.cgi?id=1127471 Bug 1127471 depends on bug 1127473, which changed state. Bug 1127473 Summary: Please update to upstream version = 0.06 https://bugzilla.redhat.com/show_bug.cgi?id=1127473 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- 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=VaDvA1d3LBa=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 1127471] Please update to upstream version = 0.06
https://bugzilla.redhat.com/show_bug.cgi?id=1127471 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-HTML-WikiConverter-Mar ||kdown-0.06-1.fc20 Resolution|--- |ERRATA Last Closed||2014-10-21 06:27:34 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-HTML-WikiConverter-Markdown-0.06-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=d4UtbrLxtBa=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 1150529] perl-POE-Test-Loops-1.359 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1150529 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-POE-Test-Loops-1.359-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=dmSv20WtUUa=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
Broken dependencies: perl-Qt
perl-Qt has broken dependencies in the rawhide tree: On x86_64: perl-Qt-0.96.0-11.fc22.x86_64 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.x86_64 requires libperl.so.5.18()(64bit) On i386: perl-Qt-0.96.0-11.fc22.i686 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.i686 requires libperl.so.5.18 On armhfp: perl-Qt-0.96.0-11.fc22.armv7hl requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.armv7hl requires libperl.so.5.18 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] plautrba:perl-Net-Daemon approveacls set to Approved
user: plautrba set for eseyman acl: approveacls of package: perl-Net-Daemon from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon commit set to Approved
user: plautrba set for eseyman acl: commit of package: perl-Net-Daemon from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchcommits set to Approved
user: plautrba set for eseyman acl: watchcommits of package: perl-Net-Daemon from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchbugzilla set to Approved
user: plautrba set for eseyman acl: watchbugzilla of package: perl-Net-Daemon from: to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchcommits set to Approved
user: plautrba set for eseyman acl: watchcommits of package: perl-Net-Daemon from: to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon commit set to Approved
user: plautrba set for eseyman acl: commit of package: perl-Net-Daemon from: to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon commit set to Approved
user: plautrba set for eseyman acl: commit of package: perl-Net-Daemon from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchcommits set to Approved
user: plautrba set for eseyman acl: watchcommits of package: perl-Net-Daemon from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon approveacls set to Approved
user: plautrba set for eseyman acl: approveacls of package: perl-Net-Daemon from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchbugzilla set to Approved
user: plautrba set for eseyman acl: watchbugzilla of package: perl-Net-Daemon from: to: Approved on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon approveacls set to Approved
user: plautrba set for eseyman acl: approveacls of package: perl-Net-Daemon from: to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchbugzilla set to Approved
user: plautrba set for eseyman acl: watchbugzilla of package: perl-Net-Daemon from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon approveacls set to Approved
user: plautrba set for eseyman acl: approveacls of package: perl-Net-Daemon from: to: Approved on branch: f19 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon approveacls set to Approved
user: plautrba set for eseyman acl: approveacls of package: perl-Net-Daemon from: to: Approved on branch: f20 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon commit set to Approved
user: plautrba set for eseyman acl: commit of package: perl-Net-Daemon from: to: Approved on branch: f19 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchcommits set to Approved
user: plautrba set for eseyman acl: watchcommits of package: perl-Net-Daemon from: to: Approved on branch: f20 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchbugzilla set to Approved
user: plautrba set for eseyman acl: watchbugzilla of package: perl-Net-Daemon from: to: Approved on branch: f19 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon approveacls set to Approved
user: plautrba set for eseyman acl: approveacls of package: perl-Net-Daemon from: to: Approved on branch: f21 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchbugzilla set to Approved
user: plautrba set for eseyman acl: watchbugzilla of package: perl-Net-Daemon from: to: Approved on branch: f20 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon set point of contact to: eseyman
user: plautrba changed point of contact of package: perl-Net-Daemon from: plautrba to: eseyman on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon commit set to Approved
user: plautrba set for eseyman acl: commit of package: perl-Net-Daemon from: to: Approved on branch: f21 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchcommits set to Approved
user: plautrba set for eseyman acl: watchcommits of package: perl-Net-Daemon from: to: Approved on branch: f19 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchbugzilla set to Approved
user: plautrba set for eseyman acl: watchbugzilla of package: perl-Net-Daemon from: to: Approved on branch: f21 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon set point of contact to: eseyman
user: plautrba changed point of contact of package: perl-Net-Daemon from: plautrba to: eseyman on branch: f21 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon watchcommits set to Approved
user: plautrba set for eseyman acl: watchcommits of package: perl-Net-Daemon from: to: Approved on branch: f21 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon set point of contact to: eseyman
user: plautrba changed point of contact of package: perl-Net-Daemon from: plautrba to: eseyman on branch: f19 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon set point of contact to: eseyman
user: plautrba changed point of contact of package: perl-Net-Daemon from: plautrba to: eseyman on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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] plautrba:perl-Net-Daemon set point of contact to: eseyman
user: plautrba changed point of contact of package: perl-Net-Daemon from: plautrba to: eseyman on branch: f20 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Net-Daemon -- 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
