[EPEL-devel] Questions about the PTPd package

[Claudio Scordino]

I need to create a reliable and accurate synchronization between two CentOS
6 machines connected through a direct Ethernet connection. I've seen that
on Linux several implementations of the IEEE 1588 Precision Time Protocol
(PTP)  exist:

   - PTPd :
  - Apparently, this is the original implentation
  - Apparently, it is still maintained 
   - PTPd2 :
  - A new version meant to supersede the previous implementation
  - Apparently unmaintained
  - Available only in the EPEL repositories as ptpd package
  - PTPv2d :
  - A further implementation
  - Unmaintained as well
   - linuxptp :
  - A specific implementation for Linux
  - Maintained
  - Available on the CentOS repositories
  - Suggested by the RedHat documentation for both RedHat 6
  

  and RedHat 7
  


My questions follow:

   - Does the ptpd package provided by EPEL refer to the ptpd or to the
   ptpd2 project ? (the EPEL package is called "ptpd" while the included
   binary is called "ptpd2"...)
   - Why does EPEL provide PTPd2 while RedHat suggests and already provides
   linuxptp on its own repositories ? Which are differences between PTPd2 and
   Linuxptp in terms of reliability and timing accuracy ?

Many thanks and best regards.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 5 updates-testing report

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 822  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2013-11893   
libguestfs-1.20.12-1.el5
 587  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-1626   
puppet-2.7.26-1.el5
 436  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
  79  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
  51  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  32  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-d1309b0eb2   
libsndfile-1.0.17-8.el5
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-512e1f2343   
wordpress-4.4.1-1.el5
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7191918aa5   
openssl101e-1.0.1e-6.el5
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d4bdacdc4a   
prosody-0.9.9-2.el5
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-43d6b4225b   
mbedtls-2.2.1-1.el5


The following builds have been pushed to Fedora EPEL 5 updates-testing

perl-Crypt-RC4-2.02-1.el5

Details about builds:



 perl-Crypt-RC4-2.02-1.el5 (FEDORA-EPEL-2016-70c923f5af)
 Perl implementation of the RC4 encryption algorithm

Update Information:

A simple implementation of the RC4 algorithm, developed by RSA Security, Inc.
Here is the description from RSA's website:  RC4 is a stream cipher designed by
Rivest for RSA Data Security (now RSA Security). It is a variable key-size
stream cipher with byte-oriented operations. The algorithm is based on the use
of a random permutation. Analysis shows that the period of the cipher is
overwhelmingly likely to be greater than 10100. Eight to sixteen machine
operations are required per output byte, and the cipher can be expected to run
very quickly in software. Independent analysts have scrutinized the algorithm
and it is considered secure.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Mass rebuild of EPEL6 (2016-01-19)

[Parag Nemade]

Hi,

On Wed, Jan 20, 2016 at 9:46 AM, Jason L Tibbitts III  wrote:
> After spending far too much time playing with my mass rebuild script,
> and a whole lot of CPU time building packages, I've done another mass
> rebuild of EPEL6.  This involves an initial build of EPEL6 (with
> testing), another three builds of any failing packages, and then a final
> build of the current git of each failed package.  Packages which are
> excluded on x86_64 were skipped.
>
> The following packages are skipped because they take absolutely forever
> to build:
>
> elpa - Still building after two days on a rather fast machine!
> nwchem
> pypy
>
> This one's test suite appears to simply hang forever:
>
> rubygem-eventmachine
>
> Missing dependencies:
>
> dinotrace
> erlang-erlsom
> erlang-ibrowse
> freecad
> golang-github-endophage-gotuf
> golang-github-go-ldap-ldap
> golang-github-gonum-blas
> golang-github-gonum-floats
> golang-github-gorilla-sessions
> golang-github-hashicorp-serf
> golang-github-lsegal-gucumber
> golang-github-prometheus-client_golang
> golang-github-spf13-cast
> golang-github-spf13-viper
> gpredict
> jmtpfs
> nodejs-ascii-tree
> nodejs-duplexify
> nodejs-nsp-audit-shrinkwrap
> nodejs-nth-check
> nodejs-rc
> nodejs-registry-url
> nodejs-seq
> nodejs-silent-npm-registry-client
> nodejs-stream-spigot
> nodejs-test

I checked all above nodejs packages. I have already pushed
(epel-testing) most of them by replacing %{nodejs_arches} with its
actual definition and they are working fine. The only remaining
problematic package is nodejs-nsp-audit-shrinkwrap which I will get
fixed today. I am not sure about nodejs-nth-check which package needs
it.

Regards,
Parag.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Adding epel-rpm-macros to the buildroot

[Jason L Tibbitts III]

I've now done many mass rebuilds both with and without epel-rpm-macros
in the buildroot and have found exactly 31 failures which result from
the presence of the macro package.  This macro package enables, in
EPEL6, the use of %license in the %files section of the spec without
having to conditionally define it.

Twenty-nine of these build failures are due to the use of %define
instead of %global and are trivially fixed by making that replacement.
One is due to having a macro in a "comment" which breaks because the
macro is now multi-line.  The final fail7ure is due to a recursive
expansion resulting from the mistaken assumption that a macro will not
be defined at a particular place.  The latter two are fixed simply by
doubling a single '%'.

I have all of these fixed in my local git repo.

I would like to do two things:

1) File a releng ticket to have epel-rpm-macros added to the EPEL6
   buildroot, as it is with EPEL7.

2) Push my changes to the 31 outstanding packages, by committing the
   small changes required to the el6 branches in git, but not rebuilding
   anything.  This allows current git to build, but if maintainers would
   prefer to commit those changes to rawhide and pull them down to el6
   they can easily revert my changes.
   
Does anyone have any objections to me doing either of these?  If I can
get the macro package into the buildroot then I can move on with adding
some of the other requested macros.  This should all be much easier with
the rebuild infrastructure I have in place now.  I can also move on to
trying to help out EPEL5 as well.  I'd really like to put this phase of
the work to bed as soon as is feasible.

The list of packages needing the minor tweaks is below.  All just need
%define -> %global except for qt5-qttranslations and tesseract which
need a single doubled '%' each.

electronics-menu (chitlesh)
epylog (smooge, icon)
geos (devrim)
itcl (orion, krege)
itk (orion, krege)
iwidgets (orion, krege)
pdsh (spstarr, dmlb2000)
postgresql-plruby (devrim, hhorak, praiskup, jmlich)
python-clientform (lmacken)
python-ruledispatch (lmacken)
python-tgext-crud (lmacken)
python-tgfastdata (lmacken)
python-TurboMail (lmacken, fschwarz)
qt5-qttranslations (rdieter, than, jreznik, ltinkl, rnovacek, jgrulich, 
group::kde-sig)
retrace-server (mtoman, jfilak)
ruby-augeas (lutter, skottler, domcleal)
rubygem-sqlite3-ruby (kanarip, stahnma)
ruby-ldap (stahnma, stevetraylen)
ruby-libvirt (stahnma, clalance)
ruby-mysql (orion, kanarip)
ruby-ncurses (isimluk)
ruby-shadow (stahnma, tmz, skottler)
snake (jlaska, wwoods)
tcllib (krege)
tcl-mysqltcl (renep)
tcl-tcludp (spot)
tcl-tktreectrl (spot)
tesseract (karlik, smani)
tkcon (sergiopr)
xpa (sergiopr)
zanata-python-client (dchen, jamesni, seanf, anishpatil, robyduck, pnemade)

 - J<
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 317  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
  79  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  42  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-f82c6fc04a   
p7zip-15.09-4.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e04c714f9d   
gajim-0.16.5-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ec85678f0c   
nodejs-ws-1.0.1-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-dd35749dd3   
wordpress-4.4.1-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-43613cf75a   
keepassx-0.4.4-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e34ffdd692   
prosody-0.9.9-2.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-273a82f7db   
owncloud-8.0.10-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8da165e1bb   
mbedtls-2.2.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6f526f521d   
python-rsa-3.3-2.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-043f77342d   
cgit-0.12-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

BibTool-2.63-1.el7
R-3.2.3-2.el7
fetch-crl-3.0.17-3.el7
jcuber-4.3.3-2.el7
python-django-redis-4.3.0-1.el7
python-docker-scripts-0.4.4-1.el7
rubygem-bcrypt-3.1.10-4.el7
rubygem-uglifier-2.4.0-3.el7
sundials-2.6.2-14.el7

Details about builds:



 BibTool-2.63-1.el7 (FEDORA-EPEL-2016-b2e11374aa)
 A Tool for manipulating BibTeX data bases

Update Information:

rebase to BibTool 2.63




 R-3.2.3-2.el7 (FEDORA-EPEL-2016-3790a288f6)
 A language for data analysis and graphics

Update Information:

Add Requires: redhat-rpm-config on targets that are hardened, because R inherits
the compiler flags that it was built with and passes them to all modules built
for it later.




 fetch-crl-3.0.17-3.el7 (FEDORA-EPEL-2016-a219678d44)
 Downloads Certificate Revocation Lists

Update Information:

* If used fetch-crl-boot.service now supports /etc/sysconfig/fetch-crl * On el6
and el7 perl Requires are now explicit. In particular perl(LWP) has now been
added.

References:

  [ 1 ] Bug #1299141 - fetch-crl-boot ignores /etc/sysconfig/fetch-crl on EL7
https://bugzilla.redhat.com/show_bug.cgi?id=1299141




 jcuber-4.3.3-2.el7 (FEDORA-EPEL-2016-ab59601aab)
 CUBE reader for Java

Update Information:

New package

References:

  [ 1 ] Bug #1269844 - Review Request: jcuber - CUBE reader for Java
https://bugzilla.redhat.com/show_bug.cgi?id=1269844




 python-django-redis-4.3.0-1.el7 (FEDORA-EPEL-2016-7fc78b04da)
 Full featured redis cache backend for Django

Update Information:

Django add-on adding the possibility use redis as caching engine.

References:

  [ 1 ] Bug #1268564 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1268564




 python-docker-scripts-0.4.4-1.el7 (FEDORA-EPEL-2016-8c818fe460)
 Collection of scripts to help manage Docker

Update Information:

Upstream release 0.4.4

References:

  [ 1 ] Bug #1224780 - python-docker-scripts-0.4.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1224780

[EPEL-devel] Re: Additional python34 components for epel7

[Avram Lubkin]

So what should package maintainers do? I modified a package to use
python3_pkgversion and it builds fine if with_python3 is set, but it
doesn't seem to be set in the EPEL 7 build environment. I noticed a couple
packages enable it by default. Is that what we should be doing? Or should
we just build it into python/python3_epel7 in copr for now, and it so how?

Avram


On Mon, Jan 4, 2016 at 2:08 PM, Jason L Tibbitts III 
wrote:

> > "DF" == Denis Fateyev  writes:
>
> DF> If we just could work "the same SRPMS name" problem around ;-)
> DF> Healthy repos with the master branch orphaned [1] may look a little
> DF> weird to users...
>
> That is not abnormal for EPEL-only packages, though.  The dead.package
> file in master should simply indicate that the package is EPEL-only.
>
>  - J<
> ___
> python-devel mailing list
> python-de...@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/python-de...@lists.fedoraproject.org
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org