date:20140819

EPEL epel beta report: 20140819 changes

2014-08-19 Thread EPEL Beta Report

Compose started at Tue Aug 19 08:15:02 UTC 2014

New package: gkrellm-top-2.2.13-5.el7
 GKrellM plugin which shows 3 most CPU intensive processes

New package: perl-Crypt-RC4-2.02-6.el7
 Perl implementation of the RC4 encryption algorithm

New package: perl-Devel-CheckBin-0.02-2.el7
 Check that a command is available

New package: perl-Spreadsheet-ParseExcel-0.5900-8.el7
 Extract information from an Excel file

New package: python-flup-1.0.2-9.el7
 Random assortment of WSGI servers for python

New package: qbittorrent-3.1.9-2.el7
 A Bittorrent Client

New package: qtlockedfile-2.4-11.el7
 QFile extension with advisory locking functions

New package: qtsingleapplication-2.6.1-11.el7
 Qt library to start applications only once per user

New package: rb_libtorrent-0.16.17-2.el7
 A C++ BitTorrent library aiming to be the best alternative

New package: re2-20131024-1.el7
 C++ fast alternative to backtracking RE engines

New package: xls2csv-1.07-2.el7
 A script that recodes a spreadsheet's charset and saves as CSV


Updated Packages:

ReviewBoard-2.0.5-1.el7.2
-
* Mon Aug 18 2014 Stephen Gallagher sgall...@redhat.com 2.0.5-1.2
- Fix runtime dependencies


fedora-dockerfiles-0-0.11.git0d2f49b.el7

* Sat Aug 16 2014 Aditya Patawari adima...@fedoraproject.org - 0-0.11.git
- we don't want debug package since it is noarch


gnuradio-3.7.4-6.el7

* Mon Aug 18 2014 Jaroslav Škarvada jskar...@redhat.com - 3.7.4-6
- Removed explicit PyQwt requirement on RHEL-7

* Sat Aug 16 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 3.7.4-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild


libspnav-0.2.3-1.el7

* Mon Aug 18 2014 Richard Shaw hobbes1...@gmail.com - 0.2.3-1
- Update to latest upstream release.

* Sun Aug 17 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.2.2-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild

* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.2.2-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild


ocsinventory-2.1.2-3.el7

* Mon Aug 18 2014 Remi Collet r...@fedoraproject.org - 2.1.2-3
- fix SELinux context
  use httpd_sys_rw_content_t instead of httpd_sys_script_rw_t
- requires mariadb-server to avoid pulling mysql-galera (EL-7)


perl-Sub-Name-0.09-1.el7

* Mon Aug 18 2014 Paul Howarth p...@city-fan.org - 0.09-1
- Update to 0.09
  - Copy the contents of the %DB::sub entry if it exists; fixes
Devel::NYTProf's anon sub handling (CPAN RT#50524)
- Drop upstreamed debugger patch
- Drop EL-5 compatibility since we need Devel::CheckBin, which can't be
  built for EPEL-5 or EPEL-6

* Sun Aug 17 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.08-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild


phpMyAdmin-4.2.7.1-1.el7

* Mon Aug 18 2014 Robert Scheck rob...@fedoraproject.org 4.2.7.1-1
- Upgrade to 4.2.7.1 (#1130865, #1130866, #1131104)


python-libcloud-0.15.1-1.el7

* Mon Jul 21 2014 Daniel Bruno dbr...@fedoraproject.org - 0.15.1-2
- Libcloud 0.15.1 bug-fix release


qpid-dispatch-0.2-7.el7
---

spacenavd-0.6-1.el7
---
* Mon Aug 18 2014 Richard Shaw hobbes1...@gmail.com - 0.6-1
- Update to latest upstream release.

* Mon Aug 18 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.5-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild

* Sun Jun 08 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org 
- 0.5-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild



Summary:
Added Packages: 11
Removed Packages: 0
Modified Packages: 10
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Orphaned packages with vulnerabilities

2014-08-19 Thread Karel Volný



Hi,


There is now a security initiative to handle the outstanding security
bugs.


that's cool that somebody cares

however, do you really think that users will appreciate this 
way of handling the bugs, i.e. removing important libraries instead

of patching them?


If there is nobody that patches the library, I do not see how this is an
option.


the key is this if ...

the person who cares about the security bugs could have been the one to 
patch - it is not uncommon that things are fixed by other people than the 
owner (e.g. qmmp, that is owned by me, got recently updated in F20 by Rex 
Dieter because of some PulseAudio stuff ..)



...
I've always thought that it works in the way that if package 
gets orphaned,
it simply won't make it into next version of the distribution, not that 

it
should get removed from the current version, causing regressions for 

users

...? ...


For me it is kind of common sense. Why should it be a good idea to ship
packages with known vulnerabilities?


as said below - not to cause regressions by removing what users rely upon, 
because pros may overweight cons ... maybe not always good but often 
less evil



As you can see from the long list of orphaned packages with known
vulnerabilities, just orphaning packages in EPEL creates a dangerous
situation where users installing packages from EPEL assume they are well
taken care of, but in reality they are not.


I thought we've always advertised EPEL as best effort, so I'd dismiss 
such assumptions as unfounded ... well, I know this is not nice, but I see 
it as the best (i.e. least bad) option, as we don't have the capacity to 
deal with every single problem in the (enterprise linux) world


this is the usual conflict between having things perfect but lack of them 
or having at least something - I often vote for the opposite, better 
nothing than something that makes the situation worse, but in this concrete 
case I *think* the better option is to have at least something ... MOD 
music is a niche market these days, but it used to be one of things I liked 
about linux that it's not just for the majority



So I discussed this with others and retiring orphaned packages
after a certain time seemed good to us.


okay, I believe you (and others) know better than me, as I don't have 
enough insight into various aspects of the distribution (which doesn't mean 
that I couldn't express my objections :-))


what I'd like to see are clear rules for this, and a bit better process ...

However, I did not intentionally retire a package that is depended upon, 

but
since it is really easy to undo retirement in EPEL, I do not see much 

harm

done.


so ... suppose someone will follow
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages

but it won't fix the cves ... what now, will it get back anyways?


So if you would like to have the package in EPEL, you need to find
a maintainer or maintain it.


sorry, I just don't follow your logic

it wasn't me who did the action - why should I undo it?


I really do not get what what is your motivation. You are a package
maintainer with a package that depends on an orphaned library with
security vulnerabilities. Why do you not want to fix this?


it's not my package and I don't want it to become mine

someone just put that you want it back so you fix it, creating work for 
me (or someone else who'd want the same)


but I have enough things to do, I don't manage to give enough love to 
things I do maintain, I really don't want someone to create more work for 
me - I didn't want the package to be removed in the first place, if it 
wouldn't be removed, there would be no work to get it back ...



First you wanted to get a better heads up, which I agree would have been
better, but I do not see how this would have changed anything, because 

still

nobody cares enough about libmodplug to unretire it and fix the security
vulnerability.


what would have changed is that we wouldn't have broken dependencies and an 
user filing bug that would need (or need) to be taken care of


the fact that nobody cares isn't something that can't be changed -


Since you maintain a package that depends on it, you are
the first candidate to do this.


together with xine maintainers ...

I'm not a good candidate, I'm not a programmer ... I understand the things 
enough to cherry pick a patch that can be applied directly, but I can 
hardly rewrite the patch for a different code of some old version, 
especially when I'm completely unfamiliar with the sources; probably I'd be 
able to handle it somehow in the end, but for a price of a lot of time that 
I'd need to use for other things (hey, I have a family waiting for me :-))


from what I understand from the bugzilla, everything got fixed upstream so 
rebase would be the least-effor solution that basically anyone (including 
me) could handle


however, we don't like to do rebases in EPEL ... would it be viable in this

Re: EPEL 5 orphaned packages status

2014-08-19 Thread Paul Howarth


On 19/08/14 07:06, Till Maas wrote:

Hi,

there are a lot of orphaned packages in EPEL 5, that should IMHO either
be properly maintained or retired, here is a rough overview:

...

I took perl-DateTime-Format-Mail

Paul.

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL Fedora 6 updates-testing report

2014-08-19 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 849  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
 196  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6
 181  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6
  68  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6
  58  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1693/perl-Email-Address-1.905-1.el6
  18  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2088/tor-0.2.4.23-1.el6
  17  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2099/v8-3.14.5.10-11.el6
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2123/ReviewBoard-1.7.27-1.el6
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2117/ansible-1.7-1.el6
  12  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2144/mediawiki119-1.19.18-1.el6
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2159/iodine-0.7.0-1.el6
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2158/drupal7-7.31-1.el6
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2148/drupal6-6.33-1.el6
  10  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2162/wordpress-3.9.2-3.el6
   6  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2185/sks-1.1.5-2.el6
   3  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2218/pen-0.25.1-1.el6
   0  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2229/phpMyAdmin-4.0.10.2-1.el6


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

almas-mongolian-title-fonts-1.0-4.el6
bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el6
fts-rest-3.2.26-2.el6
google-phetsarath-fonts-1.01-2.el6
tharlon-fonts-1.002-3.el6
trabajo-fonts-2.0-2.el6
tuladha-jejeg-fonts-2.01-2.el6

Details about builds:



 almas-mongolian-title-fonts-1.0-4.el6 (FEDORA-EPEL-2014-2244)
 Mongolian Title font

Update Information:

Mongolian Title font

References:

  [ 1 ] Bug #859819 - Review Request: almas-mongolian-title-fonts - Mongolian 
Title font
https://bugzilla.redhat.com/show_bug.cgi?id=859819




 bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el6 (FEDORA-EPEL-2014-2251)
 Convert DNS zone files in BIND format to tinydns format

Update Information:

Updated to latest upstream snapshot; fixes SRV record support
Updated to latest upstream snapshot; supports  records




 fts-rest-3.2.26-2.el6 (FEDORA-EPEL-2014-2254)
 FTS3 Rest Interface

Update Information:

Update for new upstream release

ChangeLog:

* Fri Aug 15 2014 Michal Simon michal.si...@cern.ch - 3.2.26-2
- Update for new upstream release




 google-phetsarath-fonts-1.01-2.el6 (FEDORA-EPEL-2014-2248)
 The font for the Lao language

Update Information:

The font for the Lao language

References:

  [ 1 ] Bug #1031588 - Review Request:  google-phetsarath-fonts - The font for 
the Lao language
https://bugzilla.redhat.com/show_bug.cgi?id=1031588




 tharlon-fonts-1.002-3.el6 (FEDORA-EPEL-2014-2253)
 The Myanmar font which is designed by Ngwe Tun

Update Information:

The Myanmar font which is designed by Ngwe Tun

References:

  [ 1 ] Bug #1031587 - Review Request: tharlon-fonts - The Myanmar font which 
is designed by Ngwe Tun
https://bugzilla.redhat.com/show_bug.cgi?id=1031587

EPEL Fedora 5 updates-testing report

2014-08-19 Thread updates

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 849  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
 303  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5
  68  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5
  58  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1696/perl-Email-Address-1.905-1.el5
  53  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1747/mediawiki119-1.19.17-1.el5
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2165/iodine-0.7.0-1.el5
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2153/drupal6-6.33-1.el5
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2150/drupal7-7.31-1.el5
  10  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2155/wordpress-3.9.2-3.el5
   6  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2184/389-ds-base-1.2.11.30-1.el5


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

almas-mongolian-title-fonts-1.0-4.el5
bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el5
easytag-2.1-4.el5
google-phetsarath-fonts-1.01-2.el5
tharlon-fonts-1.002-3.el5
trabajo-fonts-2.0-2.el5
tuladha-jejeg-fonts-2.01-2.el5

Details about builds:



 almas-mongolian-title-fonts-1.0-4.el5 (FEDORA-EPEL-2014-2247)
 Mongolian Title font

Update Information:

Mongolian Title font

References:

  [ 1 ] Bug #859819 - Review Request: almas-mongolian-title-fonts - Mongolian 
Title font
https://bugzilla.redhat.com/show_bug.cgi?id=859819




 bind-to-tinydns-0.4.3-15.20140818gitdf0ddc3.el5 (FEDORA-EPEL-2014-2246)
 Convert DNS zone files in BIND format to tinydns format

Update Information:

Updated to latest upstream snapshot; fixes SRV record support

ChangeLog:

* Mon Aug 18 2014 Tim Jackson r...@timj.co.uk 0.4.3-15.20140818gitdf0ddc3
- Updated to latest upstream snapshot; fixes SRV record support




 easytag-2.1-4.el5 (FEDORA-EPEL-2014-2241)
 Tag editor for mp3, ogg, flac and other music files

Update Information:

EasyTAG 2.1 for EPEL 5




 google-phetsarath-fonts-1.01-2.el5 (FEDORA-EPEL-2014-2252)
 The font for the Lao language

Update Information:

The font for the Lao language

References:

  [ 1 ] Bug #1031588 - Review Request:  google-phetsarath-fonts - The font for 
the Lao language
https://bugzilla.redhat.com/show_bug.cgi?id=1031588




 tharlon-fonts-1.002-3.el5 (FEDORA-EPEL-2014-2245)
 The Myanmar font which is designed by Ngwe Tun

Update Information:

The Myanmar font which is designed by Ngwe Tun

References:

  [ 1 ] Bug #1031587 - Review Request: tharlon-fonts - The Myanmar font which 
is designed by Ngwe Tun
https://bugzilla.redhat.com/show_bug.cgi?id=1031587




 trabajo-fonts-2.0-2.el5 (FEDORA-EPEL-2014-2249)
 Latin Serif font that supports Shavian alphabet

Update Information:

Latin Serif font that supports Shavian alphabet

References:

  [ 1 ] Bug #991724 - Review Request: trabajo-fonts - Latin Serif font that 
supports Shavian alphabet
https://bugzilla.redhat.com/show_bug.cgi?id=991724

Re: EPEL Orphaned packages with vulnerabilities

2014-08-19 Thread Till Maas

On Tue, Aug 19, 2014 at 03:02:27PM +0200, Karel Volný wrote:

the person who cares about the security bugs could have been the one to
patch - it is not uncommon that things are fixed by other people than the
owner (e.g. qmmp, that is owned by me, got recently updated in F20 by Rex
Dieter because of some PulseAudio stuff ..)

Yes, it is not necessarily the maintainer that needs to take care of
stuff, but the maintainer should at least ask for help or coordinate
this.

I thought we've always advertised EPEL as best effort, so I'd dismiss such
assumptions as unfounded ... well, I know this is not nice, but I see it as
the best (i.e. least bad) option, as we don't have the capacity to deal with
every single problem in the (enterprise linux) world

so ... suppose someone will follow
http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages

but it won't fix the cves ... what now, will it get back anyways?

I'm not a good candidate, I'm not a programmer ... I understand the things
enough to cherry pick a patch that can be applied directly, but I can hardly
rewrite the patch for a different code of some old version, especially when
I'm completely unfamiliar with the sources; probably I'd be able to handle
it somehow in the end, but for a price of a lot of time that I'd need to use
for other things (hey, I have a family waiting for me :-))

from what I understand from the bugzilla, everything got fixed upstream so
rebase would be the least-effor solution that basically anyone (including
me) could handle

however, we don't like to do rebases in EPEL ... would it be viable in this
situation?

- at least on EL5 it would mean the need to rebuild the dependant packages
... but we need to rebuild them anyways as the dependency became broken ...

Yes, a simple rebase will help here and is IMHO applicable here, since
it is the lesser evil. It is not necessarily necessary to rebuild the
dependent packages, if libmodplug did not change too much. Therefore in
this case, I would consider it pretty irresponsible to just get
libmodplug back in the state it is without taking care of the easy to
fix vulnerabilities.

Regards
Till
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Schedule for Wednesday's FESCo Meeting (2014-08-20)

2014-08-19 Thread Tomas Hozza

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 '-MM-DD 17:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1178 Fedora 21 scheduling strategy
.fesco 1178
https://fedorahosted.org/fesco/ticket/1178

#topic #1322 F21 Changes - Progress on Changes Freeze
.fesco 1322
https://fedorahosted.org/fesco/ticket/1322

= New business =

#topic #1330 F22 System Wide Change: Perl 5.20 -
https://fedoraproject.org/wiki/Changes/perl5.20
.fesco 1330
https://fedorahosted.org/fesco/ticket/1330

#topic #1331 The package pipelight violates Fedora guidelines regarding
downloading of 3rd party software
.fesco 1331
https://fedorahosted.org/fesco/ticket/1331

#topic #1332 F22 retire orphan packags after 4 weeks instead of once per
release
.fesco 1332
https://fedorahosted.org/fesco/ticket/1332

= 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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review swap

2014-08-19 Thread Richard W.M. Jones


https://bugzilla.redhat.com/show_bug.cgi?id=1131423
http://oirase.annexia.org/reviews/menhir/
menhir - an LR(1) parser generator

It's a simple package, so will swap for something not over-complex.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Heads up: Python: SSL module backported from Python3 in Rawhide

2014-08-19 Thread Robert Kuska

Hi everyone,

I've just pushed update [0] to Python 2.7.8 in Rawhide
which backports Python3 SSL module into Python2, this
patch was created by upstream [1] and will be part of Python2
in the next release. This effort already discovered minor
issue in test_ssl.py [2] while scratch building.

Next step of this effort is (scratch-)rebuilding some ssl dependant
packages in Rawhide, once updated Python2 is built [3]. If you know
that your package is using ssl from std lib please rebuild it and
share the feedback with me/us.

Thank you

Regards,

Robert Kuska 
-
rkuska @ 
#fedora-devel on freenode
#brno #gulag #software-collections on brq.redhat

[0] 
http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=833dc39f61926c2fb84d9880dd43c81aab1479ec
[1] http://bugs.python.org/issue21308
[2] http://bugs.python.org/msg225489
[3] http://koji.fedoraproject.org/koji/taskinfo?taskID=7426209
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Agenda for Env-and-Stacks WG meeting (2014-08-19)

2014-08-19 Thread Honza Horak

WG meeting will be at 13:00 UTC (14:00 London, 15:00 Brno, 9:00 Boston, 
22:00 Tokyo) in #fedora-meeting on Freenode.


= Topic =
* Flock -- what we learnt, what needs to be done
* OpenFloor
--
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 exactly is a bundled library? (was Re: apitrace, bundled libbacktrace)

2014-08-19 Thread Pavel Alexeev

13.06.2014 01:42, Adam Williamson пишет:
 On Tue, 2014-05-13 at 18:56 +0200, Sandro Mani wrote:
 Hi,

 apitrace 5.0 bundles libbacktrace, which looks like is living within the 
 gcc sources. libbacktrace is not build as a shared library from the gcc 
 sources, and not packaged.

 Is it feasible to build libbacktrace as a shared library and ship it in 
 a corresponding package? Or should I rather go for a bundling exception 
 request?
 So in writing a reply to this, I noticed the guidelines around this are
 actually fairly unclear and subject to interpretation.

 The section on this topic from
 https://fedoraproject.org/wiki/Packaging:Guidelines reads:

 Duplication of system libraries

 A package should not include or build against a local copy of a library
 that exists on a system. The package should be patched to use the system
 libraries. This prevents old bugs and security holes from living on
 after the core system libraries have been fixed.

 In this RPM packaging context, the definition of the term 'library'
 includes: compiled third party source code resulting in shared or static
 linkable files, interpreted third party source code such as Python, PHP
 and others. At this time JavaScript intended to be served to a web
 browser on another computer is specifically exempted from this but this
 will likely change in the future.

 Note that for C and C++ there's only one system in Fedora but for some
 other languages we have parallel stacks. For instance, python, python3,
 jython, and pypy are all implementations of the python language but they
 are separate interpreters with slightly different implementations of the
 language. Each stack is considered its own system and can each contain
 its own copy of a library.

 The thing that is particularly unclear there is the definition of a
 system (as in a library that exists on a system). The following
 paragraphs seem to imply that Fedora's stacks for languages/frameworks
 that implement some kind of shared library functionality are to be
 understood as systems in that context. This is still not made
 *entirely* clear, though, really.

 The page https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
 has all sorts of rationale and process stuff, but still no clear
 definition of precisely what it is that constitutes a bundled library.

 Even more confusingly,
 https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries
 seems to have a rather different definition from that given on
 Packaging:Guidelines. It reads:

 (bundled libraries being defined as libraries which exist and are
 mantained independently, whether or not they are packaged separately for
 Fedora)

 to me, that seems fundamentally different from the definition that is
 somewhat unclearly implied on the Packaging:Guidelines page.

 Has this been considered before? Is there a superior definition
 somewhere, or an accepted interpretation which is consistent with both
 pages?

 Do we in fact need a section in Packaging:Guidelines and then two
 separate 'subsidiary' pages all on the topic of bundled libraries? Would
 it make more sense to combine all the details onto a single subsidiary
 page and have Packaging:Guidelines just have a very short sort of
 'summary' and a link to that one subsidiary page? Would that reduce the
 likelihood of confusion?

 Thanks!

 I've seen several cases in the Real World where 'bundled' libraries that
 are not a part of the Fedora repositories were considered to be OK under
 the policy, which is a possible interpretation of the policy as given on
 Packaging:Guidelines, but doesn't really seem to be a possible
 interpretation of the policy as given on
 Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states
 whether or not they are packaged separately for Fedora). This could
 have considerable implementations for webapps if it were interpreted
 strictly, I think.
Sorry for the old thread.
But it is very interesting question to clearly determine bundled
library to which returning happened again and again.
Does it hang again now or something indeed changed?
-- 
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

unsigned f21 package: perl-Term-ANSIColor

2014-08-19 Thread Dusty Mabe

I get this when I try to install vim via yum on my f21 candidate cloud image:

Package perl-Term-ANSIColor-4.03-2.fc21.noarch.rpm is not signed

Is this on anyones radar already?

Dusty 
-- 
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: unsigned f21 package: perl-Term-ANSIColor

2014-08-19 Thread Josh Boyer

On Tue, Aug 19, 2014 at 7:29 AM, Dusty Mabe dustym...@gmail.com wrote:
 I get this when I try to install vim via yum on my f21 candidate cloud image:

 Package perl-Term-ANSIColor-4.03-2.fc21.noarch.rpm is not signed

 Is this on anyones radar already?

http://rawhidewatch.wordpress.com/2014/07/29/fedora-21-package-signing-no-its-not-just-you/

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2014-08-20)

2014-08-19 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/19/2014 04:14 AM, Tomas Hozza wrote:
 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 '-MM-DD 17:00 UTC'
 
 
 Links to all tickets below can be found at: 
 https://fedorahosted.org/fesco/report/9
 
 = Followups =
 
 #topic #1178 Fedora 21 scheduling strategy .fesco 1178 
 https://fedorahosted.org/fesco/ticket/1178
 
 #topic #1322 F21 Changes - Progress on Changes Freeze .fesco 1322 
 https://fedorahosted.org/fesco/ticket/1322
 
 = New business =
 
 #topic #1330 F22 System Wide Change: Perl 5.20 - 
 https://fedoraproject.org/wiki/Changes/perl5.20 .fesco 1330 
 https://fedorahosted.org/fesco/ticket/1330
 
 #topic #1331 The package pipelight violates Fedora guidelines
 regarding downloading of 3rd party software .fesco 1331 
 https://fedorahosted.org/fesco/ticket/1331
 
 #topic #1332 F22 retire orphan packags after 4 weeks instead of
 once per release .fesco 1332 
 https://fedorahosted.org/fesco/ticket/1332
 
 = 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.
 

I opened https://fedorahosted.org/fesco/ticket/1333 this morning; can
we get that onto the agenda for tomorrow as well, please?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPzN8cACgkQeiVVYja6o6O8mQCfZBFfxus/PDueLVLi3jXZ668+
xmEAn0f1SGeKarhEsBswcGixV6c8G9ow
=qoqR
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unsigned f21 package: perl-Term-ANSIColor

2014-08-19 Thread Dusty Mabe

On Tue, Aug 19, 2014 at 07:37:13AM -0400, Josh Boyer wrote:
 On Tue, Aug 19, 2014 at 7:29 AM, Dusty Mabe dustym...@gmail.com wrote:
  I get this when I try to install vim via yum on my f21 candidate cloud 
  image:
 
  Package perl-Term-ANSIColor-4.03-2.fc21.noarch.rpm is not signed
 
  Is this on anyones radar already?
 
 http://rawhidewatch.wordpress.com/2014/07/29/fedora-21-package-signing-no-its-not-just-you/

Thanks Josh.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2014-08-20)

2014-08-19 Thread Tomas Hozza

On Tue 19 Aug 2014 01:40:55 PM CEST, Stephen Gallagher wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 08/19/2014 04:14 AM, Tomas Hozza wrote:
 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 '-MM-DD 17:00 UTC'


 Links to all tickets below can be found at:
 https://fedorahosted.org/fesco/report/9

 = Followups =

 #topic #1178 Fedora 21 scheduling strategy .fesco 1178
 https://fedorahosted.org/fesco/ticket/1178

 #topic #1322 F21 Changes - Progress on Changes Freeze .fesco 1322
 https://fedorahosted.org/fesco/ticket/1322

 = New business =

 #topic #1330 F22 System Wide Change: Perl 5.20 -
 https://fedoraproject.org/wiki/Changes/perl5.20 .fesco 1330
 https://fedorahosted.org/fesco/ticket/1330

 #topic #1331 The package pipelight violates Fedora guidelines
 regarding downloading of 3rd party software .fesco 1331
 https://fedorahosted.org/fesco/ticket/1331

 #topic #1332 F22 retire orphan packags after 4 weeks instead of
 once per release .fesco 1332
 https://fedorahosted.org/fesco/ticket/1332


#topic #1333 OpenJDK maintainer refuses to address F20-F21 upgrade bug
once per release .fesco 1333
https://fedorahosted.org/fesco/ticket/1333

 = 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.


 I opened https://fedorahosted.org/fesco/ticket/1333 this morning; can
 we get that onto the agenda for tomorrow as well, please?

Sure, I added the ticket to the New Business section.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iEYEARECAAYFAlPzN8cACgkQeiVVYja6o6O8mQCfZBFfxus/PDueLVLi3jXZ668+
 xmEAn0f1SGeKarhEsBswcGixV6c8G9ow
 =qoqR
 -END PGP SIGNATURE-

Regards,
Tomas
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

is there a way to view a spec file?

2014-08-19 Thread Neal Becker

Something like github for fedora, where I can view/dl arbitrary files?  I'd like
to be able to view a spec file for any given package, without d/l the whole 
package.

-- 
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: is there a way to view a spec file?

2014-08-19 Thread Sandro Mani



On 19.08.2014 15:01, Neal Becker wrote:

Something like github for fedora, where I can view/dl arbitrary files?  I'd like
to be able to view a spec file for any given package, without d/l the whole
package.


Hi,

Look here: http://pkgs.fedoraproject.org/cgit/

--
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: 20140819 changes

2014-08-19 Thread Fedora Branched Report

Compose started at Tue Aug 19 07:15:03 UTC 2014

Broken deps for armhfp
--
[APLpy]
APLpy-0.9.8-5.fc21.noarch requires pywcs
[PyKDE]
PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) = 0:10.0
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[csound]
csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj
csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so
csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[docker-registry]
docker-registry-0.7.3-1.fc21.noarch requires docker-io
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-4.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-4.fc21.armv7hl requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache = 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.20.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
1:fatrat-1.2.0-0.20.beta2.fc21.armv7hl requires libgloox.so.11
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1
[flush]
flush-0.9.12-9.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-3.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[ghc-concrete-typerep]
ghc-concrete-typerep-devel-0.1.0.2-4.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[ghc-ghc-mtl]
ghc-ghc-mtl-devel-1.2.1.0-2.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[ghc-hint]
ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[ghc-ltk]
ghc-ltk-devel-0.12.1.0-12.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires 
libupower-glib.so.2
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0
[golang-github-smarterclayton-go-systemd]

golang-github-smarterclayton-go-systemd-devel-0-0.5.git5cb9e9e.fc21.noarch 
requires golang(github.com/guelfey/go.dbus)
[haddock]
ghc-haddock-devel-2.13.2-4.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[hibernate-search]
hibernate-search-4.5.1-4.fc21.noarch requires mvn(org.apache.avro:avro)
[ice]
ice-php-3.5.1-4.fc21.armv7hl requires php(zend-abi) = 0:20121212-32
ice-php-3.5.1-4.fc21.armv7hl requires php(api) = 0:20121113-32
[jenkins]
jenkins-cli-1.569-3.fc21.noarch requires 
mvn(org.codehaus.groovy:groovy18:1.8)
jenkins-core-1.569-3.fc21.noarch requires 
mvn(org.codehaus.groovy:groovy18:1.8)
[json-lib]
jenkins-json-lib-2.4-7.fc21.noarch requires 
mvn(org.codehaus.groovy:groovy18-all:1.8)
json-lib-2.4-7.fc21.noarch requires 
mvn(org.codehaus.groovy:groovy18:1.8)
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[leksah]
ghc-leksah-devel-0.12.1.3-15.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[leksah-server]
ghc-leksah-server-devel-0.12.1.2-15.fc21.armv7hl requires 
ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc)
[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
[libvirt]
libvirt-lock-sanlock-1.2.7-1.fc21.armv7hl requires sanlock = 0:2.4
libvirt-lock-sanlock-1.2.7-1.fc21.armv7hl requires 
libsanlock_client.so.1
[licq]
licq-1.8.2-1.fc21.armv7hl requires

Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

2014-08-19 Thread Miloslav Trmač

- Original Message -
 If you experience such situations, the right approach is to contact the
 owner of the certificate (or the server), and ask them to get a
 replacement certificate, or to install a replacement certificate on
 their SSL/TLS server.

That’s the right thing to do of course, but leaves the users with an unusable 
system in the mean time.  Could the update description at least generally point 
to how to work around this if the certificate owner is not (sufficiently 
quickly) responsive?
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

Meeting minutes Env-and-Stacks WG meeting (2014-08-19)

2014-08-19 Thread Honza Horak



#fedora-meeting: Env and Stacks (2014-08-19)



Meeting started by hhorak at 13:05:26 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-08-19/env-and-stacks.2014-08-19-13.05.log.html
.



Meeting summary
---
* Flock -- what we learnt  (hhorak, 13:10:11)
  * ACTION: hhorak will send a summary about what other WGs did before
the next meeting  (hhorak, 13:27:43)
  * ACTION: sicampbell will adjust wiki page to tell people how to
request things of this WG  (hhorak, 13:33:43)
  * we might talk during some of the next meetings about (and start to
participate in) the epel/epic proposal from Stephen Smoogen
(https://www.youtube.com/watch?v=CDmkg9V_NzU)  (hhorak, 13:46:30)

* OpenFloor  (hhorak, 14:07:38)

Meeting ended at 14:11:48 UTC.




Action Items

* hhorak will send a summary about what other WGs did before the next
  meeting
* sicampbell will adjust wiki page to tell people how to request things
  of this WG




Action Items, by person
---
* hhorak
  * hhorak will send a summary about what other WGs did before the next
meeting
* sic
  * sicampbell will adjust wiki page to tell people how to request
things of this WG
* sicampbell
  * sicampbell will adjust wiki page to tell people how to request
things of this WG
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* hhorak (43)
* pkovar (27)
* sicampbell (12)
* zodbot (5)
* Southern_Gentlem (5)
* bkabrda (3)
* samkottler (0)
* vpavlin (0)
* tjanez (0)
* mmaslano (0)
* juhp (0)
* sic (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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

2014-08-19 Thread Kai Engert

On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
 - Original Message -
  If you experience such situations, the right approach is to contact the
  owner of the certificate (or the server), and ask them to get a
  replacement certificate, or to install a replacement certificate on
  their SSL/TLS server.
 
 That’s the right thing to do of course, but leaves the users with an
 unusable system in the mean time.  Could the update description at
 least generally point to how to work around this if the certificate
 owner is not (sufficiently quickly) responsive? Mirek

Most software has options to override certificate errors.

I don't want to encourage how to do that, and covering all potential
applications would result in a big list.

I'd assume that people who are desparate will find the options on how to
override certificate errors and connect anyway.

Kai


-- 
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: is there a way to view a spec file?

2014-08-19 Thread Vít Ondruch

Dne 19.8.2014 15:01, Sandro Mani napsal(a):

 On 19.08.2014 15:01, Neal Becker wrote:
 Something like github for fedora, where I can view/dl arbitrary
 files?  I'd like
 to be able to view a spec file for any given package, without d/l the
 whole
 package.

 Hi,

 Look here: http://pkgs.fedoraproject.org/cgit/


Or this should be possibility:

https://apps.fedoraproject.org/packages/ruby/sources/spec/

But I can't say it works reliable :/


Vít

-- 
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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

2014-08-19 Thread Kai Engert

On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
 That’s the right thing to do of course, but leaves the users with an
 unusable system in the mean time.  Could the update description at
 least generally point to how to work around this if the certificate
 owner is not (sufficiently quickly) responsive?

I'd expect that users would be blocked from using just one application,
or from connecting to just a few servers - but should be able to connect
to the majority of the Internet just fine.

Can you think of scenarios, where a system is mostly unusable?

A general workaround is to downgrade to the previous package version, do
you think we need to state that explicitly in the update description?

Kai


-- 
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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

2014-08-19 Thread Miloslav Trmač

- Original Message -
 On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
  That’s the right thing to do of course, but leaves the users with an
  unusable system in the mean time.  Could the update description at
  least generally point to how to work around this if the certificate
  owner is not (sufficiently quickly) responsive?
 
 I'd expect that users would be blocked from using just one application,

Isn’t that enough?  Imagine Fedora contributors being blocked from using “just” 
koji :)

 A general workaround is to downgrade to the previous package version, do
 you think we need to state that explicitly in the update description?

Well, it’s not a _long-term_ workaround but it does resolve the way I have 
worded the issue, where everyone involved wants to upgrade the certificate and 
only the timing isn’t right.  Fair enough.
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: BIND 9.10.1 beta with seccomp functionality

2014-08-19 Thread Chris Adams

Once upon a time, Tomas Hozza tho...@redhat.com said:
 That's where seccomp kicks in, it acts as a 2nd wall of defence. In case
 of a security hole being present in the server process, it goes further
 than a chroot, it prevents the attacker from making socket connections
 orexecuting his code, as his playing field is significantly reduced.
 There's very little he can do.”

How is that different from an SELinux policy?  How is the additional
resitrction handled (if it isn't SELinux, what mechanism is used to do
the restriction)?
-- 
Chris Adams li...@cmadams.net
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

BIND 9.10.1 beta with seccomp functionality

2014-08-19 Thread Tomas Hozza

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

ISC is working on new BIND 9.10 release which includes the seccomp
functionality. It can be turned on by configuring BIND before build with
--enable-seccomp.

ISC asked me to kindly ask Fedora community if they would be willing to
test it. Currently I'm working on rebasing BIND to 9.10 in rawhide.
However it is still not finished. Since DHCP (including dhclient)
depends on BIND libraries I'm not able to easily provide a testing RPMs
that would be installable.

In the future I would like to turn the feature on by default.

So if you are willing to test the feature, you can download latest BIND
9.10.1b2 on http://www.isc.org/downloads/

Configure it with --enable-seccomp and you're good to go.

You can send your feedback to bind-beta-respo...@lists.isc.org,
bind-us...@lists.isc.org or bind-b...@isc.org

Some words about the feature from the contributor:
It goes further than a chroot. chroot limits an attacker to a
filesystem. it doesn't prevent the attacker from running his exploit
aka nefarious code and making socket connections over the internet that
would give him some kind of backdoor access where he can remotely
execute his code.

That's where seccomp kicks in, it acts as a 2nd wall of defence. In case
of a security hole being present in the server process, it goes further
than a chroot, it prevents the attacker from making socket connections
orexecuting his code, as his playing field is significantly reduced.
There's very little he can do.”

Thank you.

Regards,
- -- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.   http://cz.redhat.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT82i/AAoJEMWIetUdnzwtooYH/1hffLhpDtY1zTPNVtSlFLUx
236mJQGZMS5jsHAKPtd354qLCSMSIBTEeeGPCUkV9YC3ZtrF+wT6FCN1XFgDylpr
7S2toCAVOpjbPIUIOJZ8HvRZENb//KGxUHg8GrlIfHZMeXB9EXhvaTcxLC1QTX04
JSZyQKXIaDWurTGM/AQESAwHkIWK1vaubmrI2dt8L0mp9e5RWc3N/sb5XAup0jfa
zfkP/oPsmeS6mZvKdoc/BiwDDj8bLm8NBLHFO++tES0e43HnWAo9+H4HqSNuX5JQ
0q4a11zy55VtL8G99kzGN64gdvtXbiNDVuxulecWxxK9BUncHv3aXu5t4ggO0yg=
=MtKc
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: BIND 9.10.1 beta with seccomp functionality

2014-08-19 Thread Tomas Hozza

On Tue 19 Aug 2014 05:12:31 PM CEST, Chris Adams wrote:
 Once upon a time, Tomas Hozza tho...@redhat.com said:
 That's where seccomp kicks in, it acts as a 2nd wall of defence. In case
 of a security hole being present in the server process, it goes further
 than a chroot, it prevents the attacker from making socket connections
 orexecuting his code, as his playing field is significantly reduced.
 There's very little he can do.”

 How is that different from an SELinux policy?  How is the additional
 resitrction handled (if it isn't SELinux, what mechanism is used to do
 the restriction)?

I'm not such expert in this field to answer your question. However by 
googling you can find some information about seccomp:
https://wiki.mozilla.org/Security/Sandbox/Seccomp
http://outflux.net/teach-seccomp/

However I would love to see some opinion and response from someone 
working on SELinux and security.

Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: BIND 9.10.1 beta with seccomp functionality

2014-08-19 Thread Tomasz Torcz

On Tue, Aug 19, 2014 at 10:12:31AM -0500, Chris Adams wrote:
 Once upon a time, Tomas Hozza tho...@redhat.com said:
  That's where seccomp kicks in, it acts as a 2nd wall of defence. In case
  of a security hole being present in the server process, it goes further
  than a chroot, it prevents the attacker from making socket connections
  orexecuting his code, as his playing field is significantly reduced.
  There's very little he can do.”
 
 How is that different from an SELinux policy?  How is the additional
 resitrction handled (if it isn't SELinux, what mechanism is used to do
 the restriction)?

  The mechanism is called ”seccomp” – http://en.wikipedia.org/wiki/Seccomp

-- 
Tomasz TorczFuneral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening. - Alan Cox

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

vte3 version goes backwards in F20

2014-08-19 Thread Jerry James

This is pretty much the same scenario as the last one I reported, namely
competing updates where the wrong update wins.  Here's the blow by blow
account of what happened.

9 May 2014
mclasen submits update FEDORA-2014-6201 (
https://admin.fedoraproject.org/updates/FEDORA-2014-6201/vte3-0.34.9-2.fc20
).

14 May 2014
FEDORA-2014-6201 acquires karma of 2, including a critical path approval.

15 May 2014
rishi submits update FEDORA-2014-6387 (
https://admin.fedoraproject.org/updates/FEDORA-2014-6387/gnome-themes-standard-3.10.0-2.fc20,vte3-0.34.9-3.fc20,gnome-terminal-3.10.2-2.fc20),
which includes a further update of vte3, but FEDORA-2014-6201 is not
canceled nor commented on.

16 May 2014
FEDORA-2014-6387 acquires karma of 2, including a critical path approval,
before it even lands in the testing updates repository.

17 May 2014
FEDORA-2014-6387 acquires karma of 3.

18 May 2014
FEDORA-2014-6387 acquires karma of 4 and is pushed stable.

16 Aug 2014
Proventester kparal gives FEDORA-2014-6201 karma of 3, and it is pushed
stable.

End result: vte3-0.34.9-2.fc20 is now the current version in the updates
repository, even though vte3-0.34.9-3.fc20 used to be there.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[PkgDB] pghmcfc:perl-DateTime-Format-Mail set point of contact to: pghmcfc

2014-08-19 Thread pkgdb

user: pghmcfc changed point of contact of package: perl-DateTime-Format-Mail 
from: orphan to: pghmcfc on branch: el5

To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Format-Mail
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[PkgDB] pghmcfc:perl-DateTime-Format-Mail watchcommits set to Approved

2014-08-19 Thread pkgdb

user: pghmcfc set for pghmcfc acl: watchcommits of package: 
perl-DateTime-Format-Mail from: Approved to: Approved on branch: el5

To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Format-Mail
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1131377] Module-Install 1.10 is available

2014-08-19 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1131377

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|st...@silug.org |ppi...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=OUESSX6yica=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Review swap

2014-08-19 Thread Richard W.M. Jones

On Tue, Aug 19, 2014 at 10:18:29AM +0100, Richard W.M. Jones wrote:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1131423
 http://oirase.annexia.org/reviews/menhir/
 menhir - an LR(1) parser generator

It turns out this package already exists in Fedora :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: BIND 9.10.1 beta with seccomp functionality

2014-08-19 Thread Daniel J Walsh


On 08/19/2014 11:20 AM, Tomasz Torcz wrote:
 On Tue, Aug 19, 2014 at 10:12:31AM -0500, Chris Adams wrote:
 Once upon a time, Tomas Hozza tho...@redhat.com said:
 That's where seccomp kicks in, it acts as a 2nd wall of defence. In case
 of a security hole being present in the server process, it goes further
 than a chroot, it prevents the attacker from making socket connections
 orexecuting his code, as his playing field is significantly reduced.
 There's very little he can do.”
 How is that different from an SELinux policy?  How is the additional
 resitrction handled (if it isn't SELinux, what mechanism is used to do
 the restriction)?
   The mechanism is called ”seccomp” – http://en.wikipedia.org/wiki/Seccomp

Seccomp can add additional security features to SELinux by eliminating
certain syscalls. 
I think using both SELinux and seccomp is a good idea.  Security in Depth.


-- 
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: BIND 9.10.1 beta with seccomp functionality

2014-08-19 Thread devzero2000

Il 19/Ago/2014 17:10 Tomas Hozza tho...@redhat.com ha scritto:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello.

 ISC is working on new BIND 9.10 release which includes the seccomp
 functionality. It can be turned on by configuring BIND before build with
 --enable-seccomp.

 ISC asked me to kindly ask Fedora community if they would be willing to
 test it. Currently I'm working on rebasing BIND to 9.10 in rawhide.
 However it is still not finished. Since DHCP (including dhclient)
 depends on BIND libraries I'm not able to easily provide a testing RPMs
 that would be installable.

 In the future I would like to turn the feature on by default.

 So if you are willing to test the feature, you can download latest BIND
 9.10.1b2 on http://www.isc.org/downloads/

 Configure it with --enable-seccomp and you're good to go.

 You can send your feedback to bind-beta-respo...@lists.isc.org,
 bind-us...@lists.isc.org or bind-b...@isc.org

 Some words about the feature from the contributor:
 It goes further than a chroot. chroot limits an attacker to a
 filesystem. it doesn't prevent the attacker from running his exploit
 aka nefarious code and making socket connections over the internet that
 would give him some kind of backdoor access where he can remotely
 execute his code.

 That's where seccomp kicks in, it acts as a 2nd wall of defence. In case
 of a security hole being present in the server process, it goes further
 than a chroot, it prevents the attacker from making socket connections
 orexecuting his code, as his playing field is significantly reduced.
 There's very little he can do.”

Are there some duplication of security feature that some mac system offer
as selinux, in first place ? Sure someone can Tell that selinux could be
disabled by the lazy sysadmin.

Thanks

Best regards

 Thank you.

 Regards,
 - --
 Tomas Hozza
 Software Engineer - EMEA ENG Developer Experience

 PGP: 1D9F3C2D
 Red Hat Inc.   http://cz.redhat.com
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJT82i/AAoJEMWIetUdnzwtooYH/1hffLhpDtY1zTPNVtSlFLUx
 236mJQGZMS5jsHAKPtd354qLCSMSIBTEeeGPCUkV9YC3ZtrF+wT6FCN1XFgDylpr
 7S2toCAVOpjbPIUIOJZ8HvRZENb//KGxUHg8GrlIfHZMeXB9EXhvaTcxLC1QTX04
 JSZyQKXIaDWurTGM/AQESAwHkIWK1vaubmrI2dt8L0mp9e5RWc3N/sb5XAup0jfa
 zfkP/oPsmeS6mZvKdoc/BiwDDj8bLm8NBLHFO++tES0e43HnWAo9+H4HqSNuX5JQ
 0q4a11zy55VtL8G99kzGN64gdvtXbiNDVuxulecWxxK9BUncHv3aXu5t4ggO0yg=
 =MtKc
 -END PGP SIGNATURE-
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

FESCo #1263 question (optional javadocs)

2014-08-19 Thread Christopher

Regarding https://fedorahosted.org/fesco/ticket/1263

Does this policy change affect updates to older releases still receiving
updates? Or only F21 and later?


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Wrong perms of shared objects generated by python?

2014-08-19 Thread Christopher Meng

Hi,

I've met an issue since last year, as many python2 packages generate
.so files finally with 775 set:

non-standard-executable-perm /usr/lib/python2.7/site-packages/xxx.so 0775L

Is it suppose to be the default?

-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

nss-3.17 released, making its way to fedora

2014-08-19 Thread el...@gmail.com

This is a minor release. For notable changes please see the upstream
release notes at

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.17_release_notes

Rawhide and the f21 branch have been updated. It should appear in updates
testing for the stable branches early next week.

Elio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-TestML] 0.49 bump

2014-08-19 Thread Petr Pisar

commit c2b2f64a2c8622aef3a8da91c25c2f9408b6ff18
Author: Petr Písař ppi...@redhat.com
Date:   Mon Aug 18 17:23:31 2014 +0200

0.49 bump

 .gitignore   |1 +
 perl-TestML.spec |8 +---
 sources  |2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0a8f234..002f6e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /TestML-0.42.tar.gz
 /TestML-0.43.tar.gz
 /TestML-0.44.tar.gz
+/TestML-0.49.tar.gz
diff --git a/perl-TestML.spec b/perl-TestML.spec
index 1b17dd0..8125cb8 100644
--- a/perl-TestML.spec
+++ b/perl-TestML.spec
@@ -1,5 +1,5 @@
 Name:   perl-TestML
-Version:0.44
+Version:0.49
 Release:1%{?dist}
 Summary:Generic software Testing Meta Language
 License:GPL+ or Artistic
@@ -17,14 +17,12 @@ BuildRequires:  perl(constant)
 BuildRequires:  perl(Exporter)
 BuildRequires:  perl(File::Basename)
 # IO::All not used at test-time
-# Module::Install::Base not used at test-time
 # Used Pegex::Parser is not versioned, depend on Pegex version
 BuildRequires:  perl(Pegex) = 0.30
 BuildRequires:  perl(Pegex::Parser)
 # Template::Toolkit::Simple not used at test-time
 BuildRequires:  perl(Test::Builder)
 # Text::Diff not used at test-time
-# vars not used at test-time
 BuildRequires:  perl(YAML::XS)
 # Tests:
 BuildRequires:  perl(base)
@@ -36,6 +34,7 @@ Requires:   perl(:MODULE_COMPAT_%(eval `perl 
-V:version`; echo $version))
 # Used Pegex::Parser is not versioned, depend on Pegex version
 Requires:   perl(Pegex) = 0.30
 Requires:   perl(Text::Diff)
+Requires:   perl(warnings)
 
 %description
 TestML http://www.testml.org/ is a generic, programming language agnostic,
@@ -75,6 +74,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Aug 18 2014 Petr Pisar ppi...@redhat.com - 0.49-1
+- 0.49 bump
+
 * Thu Aug 14 2014 Petr Pisar ppi...@redhat.com - 0.44-1
 - 0.44 bump
 
diff --git a/sources b/sources
index fb3d6e8..0a9d90f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-674965ade9e8ee0719ec0b7504727890  TestML-0.44.tar.gz
+296dfa6482494129ece3f5645152fd42  TestML-0.49.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

1 2 >

1 - 100 of 109 matches

Mail list logo