Re: nss_myhostname as default in Fedora

[Glen Turner]

> It's part of what nss-myhostname provides.  There's clearly no
> consensus on the "gateway" feature.

The belief of operating systems' programmers that a lack of a default 
gateway must imply no network connectivity constricts useful network 
designs.

My objection to the "gateway" name is simply that "ping gateway" gives 
applications another way to test this incorrect belief.

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

Re: F24 Self Contained Change: System Python

[Neal Gompa]

On Mon, Feb 8, 2016 at 2:37 AM, Florian Weimer  wrote:
> On 02/08/2016 08:27 AM, Jan Kurik wrote:
>> = Proposed Self Contained Change: System Python =
>> https://fedoraproject.org/wiki/Changes/System_Python
>
> Is this intended to mirror Debian's python-minimal?
>
> What steps have been taken to accommodate Python upstream's wishes
> against creating subsets of the standard distribution?  If I recall
> correctly, this was a major point of discussion when Debian introduced
> python-minimal.
>

This sounds like a really bad idea. How do we know what to expect is
provided in a given Python package? We don't currently have anything
that creates package-independent virtual Provides/Requires of Python
modules that would cover the scope necessary to make this more
effective.

Technically, there is one for independent Python module packages
coming in RPM upstream that is currently disabled by default (in fact,
I've got a pull request to improve it based on feedback from the
Python SIG as well as Mageia[1]), but I don't think that is currently
designed to handle the kind of complexity this is going to introduce.

How in the world would we handle such a dramatic departure from how we
currently package Python?

[1]: https://github.com/rpm-software-management/rpm/pull/50


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Pidora

[Timotheus Pokorra]

> During his DevConf presentation, Ian mentioned that he had to recompile a lot 
> of the base packages to get it working, so I'm guessing not. His presentation 
> should be on YouTube by now if you're interested.

You might also want to have a look at "Fedora 23 Remix for Pi 2B" [1]
by Vaughan.
The Kolab Systems people were using that remix for offering
installations of Kolab on Fedora for Raspberry Pi at the FOSDEM [2].

hope this helps,
 Timotheus

[1] https://www.raspberrypi.org/forums/viewtopic.php?t=125548&p=883557
[2] https://kanarip.wordpress.com/2016/01/28/kolab-for-raspberry-pi-2/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: In A World Where...TCs don't exist?

[Kashyap Chamarthy]

On Sat, Jan 30, 2016 at 09:11:49PM +0100, Dennis Gilmore wrote:
> Already added to our next grooming meeting.

Nice.  Without realizing this discussion already happened here, I asked
Dennis the same question as Rich, about the status of the its
(virt-builder's) metadata distribution as part of Fedora composes,
earlier this afternoon during his Rel Eng talk at DevConf in Brno.

Thanks for the talk, Dennis!

> On January 29, 2016 7:56:05 PM GMT+01:00, Matthew Miller 
>  wrote:
> >On Fri, Jan 29, 2016 at 10:07:14AM -0600, Dennis Gilmore wrote:
> >> > > >   https://fedorahosted.org/rel-eng/ticket/5805
> >[...]
> >> We have none of that info and its not yet on our radar.
> >> https://fedoraproject.org/wiki/ReleaseEngineering/PriorityPipeline is
> >> the list of things we have coming up. I think there are some not
> >> documented as well as they should be.
> >
> >I think this request just kind of fell through and didn't get included
> >in the new prioritization process. Let's get it added in as something
> >for _sometime_ in the future, even if it doesn't bump current
> >priorities.

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

Orphaning liborigin and liborigin2

[Christian Dersch]

Hi all,

I'm going to orphan liborigin and liborigin2 in Rawhide. Last liborigin
dependency was LabPlot, but this does not depend on liborigin with 2.x
releases available in Rawhide. Same for liborigin2 which was required by
scidavis. Upstream development is dead for years now and newer Origin
files are not covered by these releases. Feel free to take it if you
need it :)

Greetings,
Christian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaning liborigin and liborigin2

[Alexander Ploumistos]

On Mon, Feb 8, 2016 at 12:51 PM, Christian Dersch  wrote:
> Upstream development is dead for years now and newer Origin
> files are not covered by these releases.

Would you happen to know the latest Origin version supported by liborigin?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaning liborigin and liborigin2

[Christian Dersch]

liborigin: Origin 7.5 (last release 2008)
liborigin2: Origin 8.1 (last release 2010)

On 02/08/2016 12:22 PM, Alexander Ploumistos wrote:
> On Mon, Feb 8, 2016 at 12:51 PM, Christian Dersch  wrote:
>> Upstream development is dead for years now and newer Origin
>> files are not covered by these releases.
> Would you happen to know the latest Origin version supported by liborigin?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: Graphical System Upgrades

[Kamil Paral]

> Also can we ensure that gnome software/packagekit updates the dnf database
> correctly before we recommend, or even enable, this upgrade method?

> It's bad enough right now with F23 and dnf autoremoving stuff installed via
> the packagekit interfaces but add in a whole system upgrade being out of
> sync with the way dnf thinks of the system and it sounds like a recipe for
> disaster.

This is a very valid point. I believe this is the bug we're talking about:
https://bugzilla.redhat.com/show_bug.cgi?id=1259865
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora 24 Mass Rebuild

[Kamil Paral]

> > #2) Not sure how the rpmlint notification system is setup, but I
> > found it odd that I received notification of packages that passed.
> > Really why send those? Or is it something I can configure what type
> > of notification I would want?
> 
> It seems there's only triggers on 'new result' or 'particular type of
> task'. I think it would be nice to be able to filter on failed or
> success too.
> 
> Filed a issue on it:
> https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/issues/356

I added a reply to that github ticket. TLDR: Sorry, we're working on it.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Jonathan Wakely]

On 08/02/16 08:27 +0100, Jan Kurik wrote:

python3 package to be split in several more subpackages:
* system-python-libs - a subset of standard Python library considered
essential to run "system tools" requiring Python
* system-python - /usr/bin/system-python binary (interpreter) for the
tools to be able to run, provides system-python(abi)
* python3-libs brings in the remaining subset of standard Python
library and will require system-python-libs, thus packages requiring
it (directly or indirectly) will get the entire standard Python
library
* python3 still requires python3-libs and provides python(abi)

The term "system tool" in this context means any package where a
maintainer wishes to require system-python package instead of python3
package.


I'm not opposed to this change (I don't have an opinion) but this
seems like an almost circular definition.

system-python-libs is defined as "whatever system tools want to use"
and "system tools" are defined as "anything that uses system-python".

So I could create a package that uses system-python, but requires some
large or obscure piece of the Python standard library, and then insist
that it is added to system-python-libs. The definitions should prevent
that.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaning liborigin and liborigin2

[Alexander Ploumistos]

On Mon, Feb 8, 2016 at 1:43 PM, Christian Dersch  wrote:
> liborigin: Origin 7.5 (last release 2008)
> liborigin2: Origin 8.1 (last release 2010)

Hmm, I have a lot of colleagues using versions 7.5 and 8.0, so I am
tempted to take them.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: rpmlint FAILED for cppad-20160000.0-2.fc24

[Kamil Paral]

> I have comments at the top of the spec file that explain the reason for
> the warning below. In addition, I have posted messages about this
> warning on this list; see
> project.org/thread/GI3L74J47OLRTYLQIMSEUA7SUZR5VLU7/#JUUSDFET2HBPUDIP3G7CPHB7Q7XCCLEG
> 
> Should I just ignore the message below ?
> 
> On 2/3/2016 8:15 PM, notificati...@fedoraproject.org wrote:
> > rpmlint FAILED for cppad-2016.0-2.fc24
> > 
> > https://taskotron.fedoraproject.org/artifacts/all/38d832c0-cac2-11e5-8d1c-525400120b80/task_output/cppad-2016.0-2.fc24.log

Hello, we have an RFE for adding a rpmlint whitelist feature here:
https://phab.qadevel.cloud.fedoraproject.org/T692

For the moment, please ignore those warnings/errors that you know that do not 
apply to your case. Thanks.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaning liborigin and liborigin2

[Christian Dersch]

On 02/08/2016 02:13 PM, Alexander Ploumistos wrote:
> On Mon, Feb 8, 2016 at 1:43 PM, Christian Dersch  wrote:
>> liborigin: Origin 7.5 (last release 2008)
>> liborigin2: Origin 8.1 (last release 2010)
> Hmm, I have a lot of colleagues using versions 7.5 and 8.0, so I am
> tempted to take them.
Feel free to do so, in past they very easy to maintain. Main reason for
orphaning: Starting with Fedora 24 I have no more applications using
them and I only want to maintain packages I'm using (which means: I know
they work), especially if upstream is dead and I have to work on fixes
by my own (which need to be tested then).

Greetings,
Christian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


3 packages were orphaned

idjc [f23, f22] was orphaned by sergiomb
 DJ application for streaming audio
 https://admin.fedoraproject.org/pkgdb/package/idjc
lemonpos [epel7] was orphaned by germano
 Point Of Sale Application For KDE4
 https://admin.fedoraproject.org/pkgdb/package/lemonpos
tar-split [f23] was orphaned by runcom
 tar archive assembly/disassembly
 https://admin.fedoraproject.org/pkgdb/package/tar-split

25 packages were retired
-
d-feet [el6] was retired by till
 A powerful D-Bus Debugger
 https://admin.fedoraproject.org/pkgdb/package/d-feet
diorite [master] was retired by martinkg
 Utility and widget library for Nuvola Player
 https://admin.fedoraproject.org/pkgdb/package/diorite
electronics-menu [epel7] was retired by till
 Electronics Menu for the Desktop
 https://admin.fedoraproject.org/pkgdb/package/electronics-menu
emesene [master] was retired by itamarjp
 Instant messaging client for Windows Live Messenger network
 https://admin.fedoraproject.org/pkgdb/package/emesene
ganymed-ssh2 [el6] was retired by till
 SSH-2 protocol implementation in pure Java
 https://admin.fedoraproject.org/pkgdb/package/ganymed-ssh2
gdl [el5] was retired by till
 GNU Data Language
 https://admin.fedoraproject.org/pkgdb/package/gdl
gfal2-plugin-xrootd [el6, epel7, el5] was retired by till
 Provide xrootd support for GFAL2
 https://admin.fedoraproject.org/pkgdb/package/gfal2-plugin-xrootd
ipcalculator [master] was retired by till
 A utility for computing broadcast, network, mask, and host ranges
 https://admin.fedoraproject.org/pkgdb/package/ipcalculator
libskindesignerapi [master] was retired by martinkg
 Library which provides the Skindesigner API to other VDR Plugins
 https://admin.fedoraproject.org/pkgdb/package/libskindesignerapi
listen [master] was retired by hguemar
 A music manager and player for GNOME
 https://admin.fedoraproject.org/pkgdb/package/listen
mimepull [el6] was retired by till
 Streaming API to access attachments from a MIME message
 https://admin.fedoraproject.org/pkgdb/package/mimepull
monkeysphere [el6] was retired by till
 Use the OpenPGP web of trust to verify SSH connections
 https://admin.fedoraproject.org/pkgdb/package/monkeysphere
nuvolaplayer [master] was retired by martinkg
 Cloud Music Integration for your Linux Desktop
 https://admin.fedoraproject.org/pkgdb/package/nuvolaplayer
papyon [master] was retired by itamarjp
 Python libraries for MSN Messenger network
 https://admin.fedoraproject.org/pkgdb/package/papyon
passenger [epel7] was retired by till
 Phusion Passenger application server
 https://admin.fedoraproject.org/pkgdb/package/passenger
purple-msn-pecan [master] was retired by itamarjp
 Alternative MSN protocol plug-in for lib-purple
 https://admin.fedoraproject.org/pkgdb/package/purple-msn-pecan
python-pywt [el6] was retired by till
 Python wavelet transforms module
 https://admin.fedoraproject.org/pkgdb/package/python-pywt
python-suds [el6, el5] was retired by swt2c
 A python SOAP client
 https://admin.fedoraproject.org/pkgdb/package/python-suds
python3-nose [master] was retired by orion
 Discovery-based unittest extension for Python 3
 https://admin.fedoraproject.org/pkgdb/package/python3-nose
re2c [el5] was retired by till
 Tool for generating C-based recognizers from regular expressions
 https://admin.fedoraproject.org/pkgdb/package/re2c
scidavis [master] was retired by lupinix
 Application for Scientific Data Analysis and Visualization
 https://admin.fedoraproject.org/pkgdb/package/scidavis
shorewall [el6] was retired by till
 An iptables front end for firewall configuration
 https://admin.fedoraproject.org/pkgdb/package/shorewall
tailor [el6] was retired by till
 A tool to migrate changesets between several version control systems
 https://admin.fedoraproject.org/pkgdb/package/tailor
tar-split [master] was retired by runcom
 tar archive assembly/disassembly
 https://admin.fedoraproject.org/pkgdb/package/tar-split
yarock [master] was retired by till
 A lightweight, beautiful music player
 https://admin.fedoraproject.org/pkgdb/package/yarock

4 packages unorphaned
-
gtkparasite [f23, f22, master] was unorphaned by amigadave
 A GUI debugging tool for GTK+ applications
 https://admin.fedoraproject.org/pkgdb/package/gtkparasite
monkeysphere [f23, f22, master, epel7] was unorphaned by barracks510
 Use the OpenPGP web of trust to verify SSH connections
 https://admin.fedoraproject.org/pkgdb/package/monkeysphere
rubygem-rest-client [el6] was unorphaned by limb
 Simple REST client for Ruby
 https://admin.fedoraproject.org/pkgdb/package/rubygem-rest-client
scratch [f23,

Re: Intent to orphan shorewall

[Raphael Groner]

You should not orphan packages in rawhide, not cause of "not used any more". 
Check upstream for activity and users. What about future security patches? To 
retire shorewall is obviously a bad idea.
I would be happy to see someone to take and continue shorewall maintainership, 
at least in rawhide. But I do not feel competent enough to do it by myself.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Pidora

[Solomon Peachy]

On Sun, Feb 07, 2016 at 05:52:05PM +0100, Till Maas wrote:
> At DevConf I understood that Pidora is dead and the people cannot be
> reached. However the new rebuild from Ian is already more awesome (it
> contains Ada and Haskell). However, we still need more people interested
> in helping there.

I'm one of those folks who would love to see a maintained Fedora spin 
for the armv6hf RPi targets, and I'm willing to put in elbow grease to 
help keep it happen.

(Pesonally, I have a few Pi1 boards running the now-abandoned Pidora 20 
 spin, and a Pi2 running Vaughan's F23 remix...)

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Intent to orphan shorewall

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/08/2016 08:31 AM, Raphael Groner wrote:
> You should not orphan packages in rawhide, not cause of "not used any
> more". Check upstream for activity and users. What about future security
> patches? To retire shorewall is obviously a bad idea. I would be happy to
> see someone to take and continue shorewall maintainership, at least in
> rawhide. But I do not feel competent enough to do it by myself.


Orphaning isn't the same as "retiring". Orphaning means "I can't maintain this
any more" and it's an invitation for someone else to step up and do so.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAla4mUAACgkQeiVVYja6o6NRGwCfSpAeRNjKs9CKp3ayYdlR5U7D
/j4An15IxYzdTANbAaLJV6ApZGl6pLX4
=dfKX
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Intent to orphan shorewall

[Michele Baldessari]

On Thu, Dec 17, 2015 at 11:03:46PM -0500, Digimer wrote:
> On 17/12/15 09:26 PM, Orion Poplawski wrote:
> > On 12/17/2015 05:27 PM, Digimer wrote:
> >> I'll take co-maintainer to assist Alex as she comes up to speed. I
> >> maintained the "cluster" package in Fedora up until it was retired in
> >> F16. I'm a little rusty now, but shorewall is a fairly simple package
> >> and we already maintain a repo of our own, so I expect little trouble.
> >>
> >> digimer
> >>
> >> On 17/12/15 10:48 AM, Alex Bruneau wrote:
> >>> I am new to package maintaining, but Alteeve's Niche uses Shorewall
> >>> in one of our offerings, and I'd be happy to take it on. Our tech
> >>> lead is available to assist as well. Thank you for all of your work
> >>> on the package!
> > 
> > So, Alex (nyz ?) appears to not be a packager, and I can't find
> > digimer's FAS name.  I'll just have to ask that people add themselves to
> > the package:
> > 
> > https://admin.fedoraproject.org/pkgdb/package/rpms/shorewall/
> 
> I just added myself as a watcher.
> 
> Alex (nick is 'nyz', yes) just setup her account today. I'll chat with
> her tomorrow about setting up on FAS.

I see this is still orphaned. I am happy to step in if you guys changed
your mind, as I use shorewall quite a bit in my setups.

Please let me know,
Michele
-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Attempting to contact unresponsive maintainers - lnovich ooprala and vjancik

[Kevin Fenzi]

On Sat, 06 Feb 2016 09:38:28 +0100
Ondřej Vašík  wrote:

> Kevin Fenzi píše v Čt 04. 02. 2016 v 13:34 -0700:
> > Greetings, we've been told that the email addresses
> > for these package maintainers are no longer valid.  I'm starting the
> > unresponsive maintainer policy to find out if they are still
> > interested in maintaining their packages (and if so, have them
> > update their email addresses in FAS).  If they're not interested in
> > maintaining or we can't locate them I'll have FESCo orphan the
> > packages so that others can take them over.  
> 
> 
> > 
> > lnovich:
> > 
> > default_assignee
> >  - virtualization-administration-guide (Fedora Documentation)
> >  - virtualization-deployment-and-administrative-guide (Fedora
> >Documentation)
> > 
> > ooprala:
> > 
> > Point of contact:
> > 
> > rpms/bash -- The GNU Bourne Again shell ( master f23 f22 )
> > rpms/mtools -- Programs for accessing MS-DOS disks without
> > mounting the disks ( master f23 f22 )  
> 
> Please use either me or dkas...@redhat.com as a primary contact for
> now. Primary maintainer will change soon.

Done. 

> > vjancik:
> > 
> > Point of contact:
> > 
> > rpms/less -- A text file browser similar to more, but better
> >   ( master f23 f22 ) 
> > rpms/transfig -- Utility for converting FIG files (made by
> > xfig) to other formats ( master f23 f22 )  
> 
> I would suggest to use hho...@redhat.com as a temporary primary
> contact for these.

ok. 

Thanks!

kevin



pgpAHSdImbg_5.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Containers: we're asking for ponies, so here's a suggestion for the Minimum Viable (Modular) Pony Show

[Matthew Miller]

At DevConf.cz, I said that 2016 needed to be the year of the _show_
part of "show & tell" for what we started with the "rings" proposal and
now what we're calling, vaguely, "modularity".

Some of that is scary, because anything really new always is. It's
important that we do this in a way that *both* brings useful new
functionality _and_ doesn't break what we have.

In the commercial world, there's a concept of "minimum viable product" --
not done, not perfect, but what it takes to actually start solving problems
and providing value. In Fedora, we're not in business in the same way, but
some of the same can apply. So, here's my suggestions for a "minimum viable
demo" for what a container-based module might look like in Fedora.

Particularly, when I've spoken to people about delivering parts of Fedora as
containers, the part about tracking security and proving updates becames
disturbingly hand-wavy, with "yeah, of course, we'll do something to cover
that". I think to be successful, we need to make sure that this is addressed
early. So, this proposal for a demo I'd like to see.

I've broken it down into three parts of increasing complexity and
usefulness: starting with "and I want a pony", then moving up to "actually,
a unicorn", and then "also, could you put wings on that?"

So, first:


The Minimum Viable Pony
---


This is a basic web server module delivered as a container.

Part A: the basic module:

  * Answers on port 80 and serves out static web pages.

  * Content comes from /var/www/html... or another container, or whatever.

  * Doesn't even need to be configurable. It's a demo.

  * It's composed entirely from RPMs already existing in Fedora.


Part B: DNF Plugin to list CVEs

  * Works like 
https://docs.fedoraproject.org/en-US/Fedora/17/html/Security_Guide/sect-Security_Guide-CVE-yum_plugin-using_yum_plugin_security.html

- lists all RPMs on host system where a security update is available
  - can list by CVE
  - also by Bugzilla
  - also with link to update notice
  - with various breakdowns by severity level

- **additionally** lists "modules" which need updates (with same links)
  - has option to list which specific RPMs within the module have the
problem.


So that's a good start. As a sysadmin, I'm feeling a little less scared
about. But we also need...


To Take It to Unicorn Level
---

It's all well and good to fix the problem, but we also need to be able to
fix it. So, the next level is:

* Image is built in Fedora's new Layered Image Build Service
  https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service

* If there is a security vulnerability in any RPM that is in the image, it
  is automatically rebuilt and made available somewhere.

* And automatically tested!

  - Here, just a basic test that makes sure that input web content comes
out. It's a proof-of-concept so no real in-depth testing is needed.

* And, then, a dnf plugin which actually downloads and applies the update.

Now, not only do we have comforting tooling (minimizing change pain), we
also have a real, practical improvement (there will be cake!). In the
current system, while we do hands-on testing of individual updates, they
aren't necessarily tested in the application to which they apply. For
example, if the web server here is Nginx and the security flaw in the SSL
library, current update testing does not guarantee that the update has been
tested *for that use*. But this will. Plus, in addition to whatever human
oversight, there will be an _automatic_ test.

So that's pretty good. But finally, to get to the glorious future, I'd also
like to see this unicorn become also a pegasus (my daughter tells me that
this makes it an "alicorn")...



Taking Flight
-

Same as above, but with two new things:

New Thing One:

  * Instead of RPMs, a module which uses some non-RPM upstream packaging
format as part of its composition
- Ruby gem, Python egg or wheel, Java jar... whatever

  * And the DNF list-security command still works
- and the verbose flag now tells us about the CVEs or whatever for the
  non-RPM package

New Thing Two:

  * There is enough metadata and intelligence such that when the new
container is updated, that update happens without downtime. This may
involve multiple containers.

  * If the update fails locally for some reason (despite the best efforts at
upstream testing), it's rolled back automatically



From here, I can imagine all sorts of other mythical creatures. But, you
know, for a start. What do you think?

As a user/sysadmin, is there something more you'd like to see? If
you're skeptical about containers, would this make you feel better? If
not, what might?

If you're excited about them, does this seem like a useful start?
What's missing?

And, of course, if you're a developer working on this stuff, can I have
ponies please?


-- 
Matthew Miller

Fedora Project 

Re: Containers: we're asking for ponies, so here's a suggestion for the Minimum Viable (Modular) Pony Show

[Šimon Lukašík]

On 02/08/2016 03:53 PM, Matthew Miller wrote:


At DevConf.cz, I said that 2016 needed to be the year of the _show_
part of "show & tell" for what we started with the "rings" proposal and
now what we're calling, vaguely, "modularity".

Some of that is scary, because anything really new always is. It's
important that we do this in a way that *both* brings useful new
functionality _and_ doesn't break what we have.

In the commercial world, there's a concept of "minimum viable product" --
not done, not perfect, but what it takes to actually start solving problems
and providing value. In Fedora, we're not in business in the same way, but
some of the same can apply. So, here's my suggestions for a "minimum viable
demo" for what a container-based module might look like in Fedora.

Particularly, when I've spoken to people about delivering parts of Fedora as
containers, the part about tracking security and proving updates becames
disturbingly hand-wavy, with "yeah, of course, we'll do something to cover
that". I think to be successful, we need to make sure that this is addressed
early. So, this proposal for a demo I'd like to see.

I've broken it down into three parts of increasing complexity and
usefulness: starting with "and I want a pony", then moving up to "actually,
a unicorn", and then "also, could you put wings on that?"

So, first:


The Minimum Viable Pony
---


This is a basic web server module delivered as a container.

Part A: the basic module:

   * Answers on port 80 and serves out static web pages.

   * Content comes from /var/www/html... or another container, or whatever.

   * Doesn't even need to be configurable. It's a demo.

   * It's composed entirely from RPMs already existing in Fedora.


Part B: DNF Plugin to list CVEs

   * Works like 
https://docs.fedoraproject.org/en-US/Fedora/17/html/Security_Guide/sect-Security_Guide-CVE-yum_plugin-using_yum_plugin_security.html

 - lists all RPMs on host system where a security update is available
   - can list by CVE
   - also by Bugzilla
   - also with link to update notice
   - with various breakdowns by severity level

 - **additionally** lists "modules" which need updates (with same links)
   - has option to list which specific RPMs within the module have the
 problem.



We are already able to do this kind of stuff with OpenSCAP. ( 
http://www.open-scap.org ).


Thing is just we have slightly different approach. Let me explain.

Running dnf/yum plugin is often regarded as a partial solution. It may 
be good enough for Fedora users. However, there are still use-cases. 
Where dnf/yum plugin may not be good enough:

 * disconnected system (a container without internet access)
 * cloned remote repositories (latest Fedora contains bugfixes, but my 
custom repo may not)
 * disabled local repositories (software was installed to the 
container, but the repofile is missing for some reason).


So, we try to examine what is actually installed on the system. Here is 
one example 
https://www.open-scap.org/resources/documentation/security-compliance-of-rhel7-docker-containers/


During the last months guys have integrated this solution more tightly 
with atomic, allowing the scanner to be actually inside super-privileged 
container. 
https://martin.preisler.me/2015/11/atomic-scan-and-openscap-daemon/


The problem we are currently facing in Fedora is that you need to have a 
data that you feed to the scanner. Hence, this CVE analysis can be done 
only for RHEL, SuSE and Debian systems. So, we are done, once we are 
able to develop plug-in to bodhi to generate the data feed for us.


Do you think this approach is sensible for the ponycorn? :)



So that's a good start. As a sysadmin, I'm feeling a little less scared
about. But we also need...


To Take It to Unicorn Level
---

It's all well and good to fix the problem, but we also need to be able to
fix it. So, the next level is:

* Image is built in Fedora's new Layered Image Build Service
   https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service

* If there is a security vulnerability in any RPM that is in the image, it
   is automatically rebuilt and made available somewhere.

* And automatically tested!

   - Here, just a basic test that makes sure that input web content comes
 out. It's a proof-of-concept so no real in-depth testing is needed.



Also some basic security checks should be in place before publishing the 
image. I think this represents good starting point: 
https://github.com/OpenSCAP/scap-security-guide/issues/589 (Don't be 
confused by RHEL7 label, we have the same thing prepared for Fedora in 
upstream).


~š.


* And, then, a dnf plugin which actually downloads and applies the update.

Now, not only do we have comforting tooling (minimizing change pain), we
also have a real, practical improvement (there will be cake!). In the
current system, while we do hands-on testing of individual

Re: Containers: we're asking for ponies, so here's a suggestion for the Minimum Viable (Modular) Pony Show

[Šimon Lukašík]

On 02/08/2016 03:53 PM, Matthew Miller wrote:


At DevConf.cz, I said that 2016 needed to be the year of the _show_
part of "show & tell" for what we started with the "rings" proposal and
now what we're calling, vaguely, "modularity".

Some of that is scary, because anything really new always is. It's
important that we do this in a way that *both* brings useful new
functionality _and_ doesn't break what we have.

In the commercial world, there's a concept of "minimum viable product" --
not done, not perfect, but what it takes to actually start solving problems
and providing value. In Fedora, we're not in business in the same way, but
some of the same can apply. So, here's my suggestions for a "minimum viable
demo" for what a container-based module might look like in Fedora.

Particularly, when I've spoken to people about delivering parts of Fedora as
containers, the part about tracking security and proving updates becames
disturbingly hand-wavy, with "yeah, of course, we'll do something to cover
that". I think to be successful, we need to make sure that this is addressed
early. So, this proposal for a demo I'd like to see.

I've broken it down into three parts of increasing complexity and
usefulness: starting with "and I want a pony", then moving up to "actually,
a unicorn", and then "also, could you put wings on that?"

So, first:


The Minimum Viable Pony
---


This is a basic web server module delivered as a container.

Part A: the basic module:

   * Answers on port 80 and serves out static web pages.

   * Content comes from /var/www/html... or another container, or whatever.

   * Doesn't even need to be configurable. It's a demo.

   * It's composed entirely from RPMs already existing in Fedora.


Part B: DNF Plugin to list CVEs

   * Works like 
https://docs.fedoraproject.org/en-US/Fedora/17/html/Security_Guide/sect-Security_Guide-CVE-yum_plugin-using_yum_plugin_security.html

 - lists all RPMs on host system where a security update is available
   - can list by CVE
   - also by Bugzilla
   - also with link to update notice
   - with various breakdowns by severity level

 - **additionally** lists "modules" which need updates (with same links)
   - has option to list which specific RPMs within the module have the
 problem.



We are already able to do this kind of stuff with OpenSCAP. ( 
http://www.open-scap.org ).


Thing is just we have slightly different approach. Let me explain.

Running dnf/yum plugin is often regarded as a partial solution. It may 
be good enough for Fedora users. However, there are still use-cases. 
Where dnf/yum plugin may not be good enough:

 * disconnected system (a container without internet access)
 * cloned remote repositories (latest Fedora contains bugfixes, but my 
custom repo may not)
 * disabled local repositories (software was installed to the 
container, but the repofile is missing for some reason).


So, we try to examine what is actually installed on the system. Here is 
one example 
https://www.open-scap.org/resources/documentation/security-compliance-of-rhel7-docker-containers/


During the last months guys have integrated this solution more tightly 
with atomic, allowing the scanner to be actually inside super-privileged 
container. 
https://martin.preisler.me/2015/11/atomic-scan-and-openscap-daemon/


The problem we are currently facing in Fedora is that you need to have a 
data that you feed to the scanner. Hence, this CVE analysis can be done 
only for RHEL, SuSE and Debian systems. So, we are done, once we are 
able to develop plug-in to bodhi to generate the data feed for us.


Do you think this approach is sensible for the ponycorn? :)



So that's a good start. As a sysadmin, I'm feeling a little less scared
about. But we also need...


To Take It to Unicorn Level
---

It's all well and good to fix the problem, but we also need to be able to
fix it. So, the next level is:

* Image is built in Fedora's new Layered Image Build Service
   https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service

* If there is a security vulnerability in any RPM that is in the image, it
   is automatically rebuilt and made available somewhere.

* And automatically tested!

   - Here, just a basic test that makes sure that input web content comes
 out. It's a proof-of-concept so no real in-depth testing is needed.



Also some basic security checks should be in place before publishing the 
image. I think this represents good starting point: 
https://github.com/OpenSCAP/scap-security-guide/issues/589 (Don't be 
confused by RHEL7 label, we have the same thing prepared for Fedora in 
upstream).


~š.


* And, then, a dnf plugin which actually downloads and applies the update.

Now, not only do we have comforting tooling (minimizing change pain), we
also have a real, practical improvement (there will be cake!). In the
current system, while we do hands-on testing of individual

Re: Intent to orphan shorewall

[Pierre-Yves Chibon]

On Mon, Feb 08, 2016 at 01:31:12PM -, Raphael Groner wrote:
> You should not orphan packages in rawhide, not cause of "not used any more". 
> Check upstream for activity and users. What about future security patches? To 
> retire shorewall is obviously a bad idea.

That's quite the opposite, you can orphan a package on any branch, because the
git repo remains open, people can still step in and fix eventual issues, it's
just that there is  no-one actively maintaining the package.
Retiring can only be done in rawhide, branch (pre-alpha) and EPEL branches.

So if you want to stop maintaining a packager, orphaning it is definitely the
thing to do. Once it has been orphaned for a little while, it will be retired
from rawhide (iirc, at the time we branch) and slowly it will be retired on all
activate branches of Fedora.

We're all volunteers, time comes and goes. It is totally fine to say: I can no
longer make the time to maintain foo/bar, do X, Y, and orphaning  packages is
also fine.


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

Re: ebay-cors-filter's dependencies failed to resolve in f24

[Sandro Bonazzola]

Hi, just received:

On Mon, Feb 8, 2016 at 4:46 PM,  wrote:

> ebay-cors-filter's dependencies failed to resolve in f24
> https://apps.fedoraproject.org/koschei/package/ebay-cors-filter
>
> --
> You received this message due to your preference settings at
>
> https://apps.fedoraproject.org/notifications/sbonazzo.id.fedoraproject.org/email/29603



but koschei page doesn't show any relevant error. Any pointer to a log I
can check to see what's missing there?


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Intent to orphan shorewall

[Digimer]

On 08/02/16 08:56 AM, Michele Baldessari wrote:
> On Thu, Dec 17, 2015 at 11:03:46PM -0500, Digimer wrote:
>> On 17/12/15 09:26 PM, Orion Poplawski wrote:
>>> On 12/17/2015 05:27 PM, Digimer wrote:
 I'll take co-maintainer to assist Alex as she comes up to speed. I
 maintained the "cluster" package in Fedora up until it was retired in
 F16. I'm a little rusty now, but shorewall is a fairly simple package
 and we already maintain a repo of our own, so I expect little trouble.

 digimer

 On 17/12/15 10:48 AM, Alex Bruneau wrote:
> I am new to package maintaining, but Alteeve's Niche uses Shorewall
> in one of our offerings, and I'd be happy to take it on. Our tech
> lead is available to assist as well. Thank you for all of your work
> on the package!
>>>
>>> So, Alex (nyz ?) appears to not be a packager, and I can't find
>>> digimer's FAS name.  I'll just have to ask that people add themselves to
>>> the package:
>>>
>>> https://admin.fedoraproject.org/pkgdb/package/rpms/shorewall/
>>
>> I just added myself as a watcher.
>>
>> Alex (nick is 'nyz', yes) just setup her account today. I'll chat with
>> her tomorrow about setting up on FAS.
> 
> I see this is still orphaned. I am happy to step in if you guys changed
> your mind, as I use shorewall quite a bit in my setups.
> 
> Please let me know,
> Michele

I want to take it over, but work has proven more busy that I expected.
If you have the cycles, please take it. I would be happy to be
co-maintainer though. This would have been my first package, so it's
probably smarter if I helped someone with experience rather than try to
do it myself. :)

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ebay-cors-filter's dependencies failed to resolve in f24

[gil]

hi
depend on https://bugzilla.redhat.com/show_bug.cgi?id=1305015
regards
.g

Il 08/02/2016 16:51, Sandro Bonazzola ha scritto:

Hi, just received:

On Mon, Feb 8, 2016 at 4:46 PM, > wrote:


ebay-cors-filter's dependencies failed to resolve in f24
https://apps.fedoraproject.org/koschei/package/ebay-cors-filter

--
You received this message due to your preference settings at

https://apps.fedoraproject.org/notifications/sbonazzo.id.fedoraproject.org/email/29603



but koschei page doesn't show any relevant error. Any pointer to a log 
I can check to see what's missing there?



--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com 


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


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

Review swaps (4 R packages)

[Mattias Ellert]

Hi!

I have 4 R package that I submitted for review.

https://bugzilla.redhat.com/show_bug.cgi?id=1305333 R-highlight
https://bugzilla.redhat.com/show_bug.cgi?id=1305334 R-inline
https://bugzilla.redhat.com/show_bug.cgi?id=1305335 R-Rcpp
https://bugzilla.redhat.com/show_bug.cgi?id=1305336 R-RInside

There is a dependency chain: The 3rd depends on the first two, and the
4th depends on the 3rd.

Review swaps welcome.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Containers: we're asking for ponies, so here's a suggestion for the Minimum Viable (Modular) Pony Show

[Matthew Miller]

On Mon, Feb 08, 2016 at 04:37:40PM +0100, Šimon Lukašík wrote:
> Thing is just we have slightly different approach. Let me explain.

Using OpenSCAP sounds great. Mostly, I wanted to focus on results and
what the user sees rather than implementation details.

The advantages you describe sound exciting, which falls under the
offering-carrots aspect: new functionality that we can give people that
they'll be actively want to switch to. However, I think we also need to
do the "we replaced your favorite coffee brand... and you don't even
know it" part wherever possible. *

So, I really _do_ want the existing command to work, but maybe it's
OpenSCAP underneath.

[...]
> The problem we are currently facing in Fedora is that you need to
> have a data that you feed to the scanner. Hence, this CVE analysis
> can be done only for RHEL, SuSE and Debian systems. So, we are done,
> once we are able to develop plug-in to bodhi to generate the data
> feed for us.

What is needed for that to happen?

> Do you think this approach is sensible for the ponycorn? :)

Yes, with the above notes.

Man, I missed a really good opportunity to call this message an "RFP".
:)



* I need to unify this metaphor... it's carrots and coffee rather than
carrots and sticks, since we have no sticks. But on the other hand, I
don't think horses like coffee.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/08/2016 09:21 AM, Neal Gompa wrote:
> On Mon, Feb 8, 2016 at 2:37 AM, Florian Weimer  wrote:
>> On 02/08/2016 08:27 AM, Jan Kurik wrote:
>>> = Proposed Self Contained Change: System Python =
>>> https://fedoraproject.org/wiki/Changes/System_Python
>>
>> Is this intended to mirror Debian's python-minimal?

Not necessarily, thought if the subset is similar we might re-use it.

>> What steps have been taken to accommodate Python upstream's wishes
>> against creating subsets of the standard distribution?  If I recall
>> correctly, this was a major point of discussion when Debian introduced
>> python-minimal.

The system-python is not a general-purpose Python interpreter. It should
only be called from programs that explicitly opt in to it.
Perhaps is should be /usr/libexec/system-python rather than
/usr/bin/system-python, to drive the idea home.

> This sounds like a really bad idea. How do we know what to expect is
> provided in a given Python package?

Part of the change is defining the exact subset. The idea is that it
should be small, to keep cloud images small for apps that don't use
Python themselves.

> We don't currently have anything
> that creates package-independent virtual Provides/Requires of Python
> modules that would cover the scope necessary to make this more
> effective.

Right. Every package using system-python would need to explicitly
disable the automatic Python requires, and add the system-python ones.

> Technically, there is one for independent Python module packages
> coming in RPM upstream that is currently disabled by default (in fact,
> I've got a pull request to improve it based on feedback from the
> Python SIG as well as Mageia[1]), but I don't think that is currently
> designed to handle the kind of complexity this is going to introduce.
> 
> How in the world would we handle such a dramatic departure from how we
> currently package Python?

It's a change designed for a few system tools that can accept the
limitations.  we can make Python-less containers and cloud images
smaller. Normal Python packages would be unaffected.
So I don't think it's a dramatic departure.


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Petr Viktorin]

On 02/08/2016 02:13 PM, Jonathan Wakely wrote:
> On 08/02/16 08:27 +0100, Jan Kurik wrote:
>> python3 package to be split in several more subpackages:
>> * system-python-libs - a subset of standard Python library considered
>> essential to run "system tools" requiring Python
>> * system-python - /usr/bin/system-python binary (interpreter) for the
>> tools to be able to run, provides system-python(abi)
>> * python3-libs brings in the remaining subset of standard Python
>> library and will require system-python-libs, thus packages requiring
>> it (directly or indirectly) will get the entire standard Python
>> library
>> * python3 still requires python3-libs and provides python(abi)
>>
>> The term "system tool" in this context means any package where a
>> maintainer wishes to require system-python package instead of python3
>> package.
> 
> I'm not opposed to this change (I don't have an opinion) but this
> seems like an almost circular definition.
> 
> system-python-libs is defined as "whatever system tools want to use"
> and "system tools" are defined as "anything that uses system-python".
> 
> So I could create a package that uses system-python, but requires some
> large or obscure piece of the Python standard library, and then insist
> that it is added to system-python-libs. The definitions should prevent
> that.

Right, currently all we have is the circular definition.
The first step (listed under "Scope") is defining what
system-python-libs will contain. Once that's done, it'll be much harder
to add obscure libraries.


-- 
Petr Viktorin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Firefox - call for testing (Gtk3 effort)

[Jakub Filak]

abrt should write the reason why it ignores crashes of Firefox to system 
logs.




Jakub

On 02/03/2016 02:48 PM, Martin Stransky wrote:

On 02/03/2016 02:45 PM, Jakub Jelen wrote:

On 02/03/2016 10:53 AM, Martin Stransky wrote:

Also please remove Firefox from ABRT blacklist at:

/etc/abrt/abrt-action-save-package-data.conf

ma.

On 02/03/2016 10:43 AM, Martin Stransky wrote:

Folks,

we see many Gtk3 crashes in Firefox recently
(https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes 
from

Gtk3 system library.

If you's like to help here, please install latest FF updates from 
koji:


F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61
F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54

and also enable the ABRT tool. If Firefox crashes please submit the
crash stat to ABRT retrace server.

That would help up greatly to investigate root of this problem.



Installed the package from koji, debuginfo, set up the ABRT to handle
the crashes (GPG,Unpackaged,Blacklist), restarted abrtd, crashed firefox
few times, but I still don't see the crashes in abrt-cli. Is there some
another config I am missing?


Hm, no idea. Maybe ABRT maintainer may help here? (cc 
mhabr...@redhat.com)


ma.


Anyway I found that the Firefox was crashed by DNSSEC/TLSA Validator
plugin:

https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/

Disabled and works fine for me so far.




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

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

Fwd: [ANNOUNCE] NSS 3.22 Release

[el...@gmail.com]

FYI:  Coming to Rawhide soon.

- Elio

-- Forwarded message --
From: Kai Engert 
Date: Wed, Feb 3, 2016 at 1:01 AM
Subject: [ANNOUNCE] NSS 3.22 Release
To: mozilla-dev-tech-crypto 


The NSS team has released Network Security Services (NSS) 3.22,
which is a minor release.

New functionality:
* RSA-PSS signatures are now supported (bug 1215295)
* Pseudorandom functions based on hashes other than SHA-1 are now supported
* Enforce an External Policy on NSS from a config file (bug 1009429)

New Functions:
* PK11_SignWithMechanism - an extended version PK11_Sign()
* PK11_VerifyWithMechanism - an extended version of PK11_Verify()
* SSL_PeerSignedCertTimestamps - Get signed_certificate_timestamp
  TLS extension data
* SSL_SetSignedCertTimestamps - Set signed_certificate_timestamp
  TLS extension data

New Types:
* ssl_signed_cert_timestamp_xtn is added to SSLExtensionType
* Constants for several object IDs are added to SECOidTag

New Macros:
* SSL_ENABLE_SIGNED_CERT_TIMESTAMPS
* NSS_USE_ALG_IN_SSL
* NSS_USE_POLICY_IN_SSL
* NSS_RSA_MIN_KEY_SIZE
* NSS_DH_MIN_KEY_SIZE
* NSS_DSA_MIN_KEY_SIZE
* NSS_TLS_VERSION_MIN_POLICY
* NSS_TLS_VERSION_MAX_POLICY
* NSS_DTLS_VERSION_MIN_POLICY
* NSS_DTLS_VERSION_MAX_POLICY
* CKP_PKCS5_PBKD2_HMAC_SHA224
* CKP_PKCS5_PBKD2_HMAC_SHA256
* CKP_PKCS5_PBKD2_HMAC_SHA384
* CKP_PKCS5_PBKD2_HMAC_SHA512
* CKP_PKCS5_PBKD2_HMAC_GOSTR3411 - (not supported)
* CKP_PKCS5_PBKD2_HMAC_SHA512_224 - (not supported)
* CKP_PKCS5_PBKD2_HMAC_SHA512_256 - (not supported)

Notable Changes:
* NSS C++ tests are built by default, requiring a C++11 compiler.
  Set the NSS_DISABLE_GTESTS variable to 1 to disable building these tests.

The full release notes are available at
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.22_release_notes

The HG tag is NSS_3_22_RTM. NSS 3.22 requires NSPR 4.11 or newer.

NSS 3.22 source distributions are available for secure HTTPS download:
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_22_RTM/src/

A complete list of all bugs resolved in this release can be obtained at
https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&classification=Components&query_format=advanced&target_milestone=3.22&product=NSS

--
dev-tech-crypto mailing list
dev-tech-cry...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaning liborigin and liborigin2

[Alexander Ploumistos]

I've taken them for the time being and I'll go over the specs and
sources sometime this week. Can I bug you if I have any questions?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1305134] Review Request: perl-Data-Page-Pageset - Change long page list to be shorter and well navigate

[bugzilla]

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

Denis Fateyev  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Mathieu Bridon]

On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
> Part of the change is defining the exact subset. The idea is that it
> should be small, to keep cloud images small for apps that don't use
> Python themselves.

Wouldn't it be a better goal to not have Python at all on Cloud images?


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

Re: F24 Self Contained Change: System Python

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/08/2016 12:45 PM, Mathieu Bridon wrote:
> On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
>> Part of the change is defining the exact subset. The idea is that it 
>> should be small, to keep cloud images small for apps that don't use 
>> Python themselves.
> 
> Wouldn't it be a better goal to not have Python at all on Cloud images?
> 

So... no dnf? That seems a little unlikely to yield a good long-term result.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAla41L4ACgkQeiVVYja6o6OqnACgsDqgtI5B8OUVaGeDcqxway4n
eHcAn1y6WDxqkDWAQzokD0az9CpCVwXl
=7e9P
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Mathieu Bridon]

On Mon, 2016-02-08 at 12:47 -0500, Stephen Gallagher wrote:
> On 02/08/2016 12:45 PM, Mathieu Bridon wrote:
> > On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
> > > Part of the change is defining the exact subset. The idea is that
> > > it 
> > > should be small, to keep cloud images small for apps that don't
> > > use 
> > > Python themselves.
> > 
> > Wouldn't it be a better goal to not have Python at all on Cloud
> > images?
> > 
> 
> So... no dnf? That seems a little unlikely to yield a good long-term
> result.

Or maybe dnf shouldn't be written in Python?

I mean, if a goal is to minimize the size of the deliverables, at some
point you need to cut down on dependencies.

And removing a whole language and its ecosystem seems like a pretty
good win dependency-wise.

Lots of dnf deps are already C libs, so it's not like the heavy-lifting 
is not available in C.

And then for plugins, it is certainly possible to have a C apps and let
people write plugins in various languages, among which Python. gedit
does this for example, through libpeas.

So no, I didn't mean to throw dnf out, I meant to consider what is the
minimal features (and dnf strikes me as one), and then radically reduce
what those depend on.

Note that I'm a Python developer by trade as well as by heart. So I'm
certainly not saying Python is terrible and should be eliminated. I
just think that managing to remove it from the minimum images would
lead better results (and much less confusion) than splitting it into
various subpackages.


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

Re: F24 Self Contained Change: System Python

[Chris Murphy]

On Mon, Feb 8, 2016 at 10:47 AM, Stephen Gallagher  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/08/2016 12:45 PM, Mathieu Bridon wrote:
>> On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
>>> Part of the change is defining the exact subset. The idea is that it
>>> should be small, to keep cloud images small for apps that don't use
>>> Python themselves.
>>
>> Wouldn't it be a better goal to not have Python at all on Cloud images?
>>
>
> So... no dnf? That seems a little unlikely to yield a good long-term result.

If Cloud becomes Atomic, it probably wouldn't have dnf. Current atomic
builds don't. I'm not sure how far off the hybrid rpm install rpms in
an rpm-ostree release is going to be.

-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: System Python

[Daniel J Walsh]

On 02/08/2016 01:16 PM, Chris Murphy wrote:
> On Mon, Feb 8, 2016 at 10:47 AM, Stephen Gallagher  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 02/08/2016 12:45 PM, Mathieu Bridon wrote:
>>> On Mon, 2016-02-08 at 17:21 +0100, Petr Viktorin wrote:
 Part of the change is defining the exact subset. The idea is that it
 should be small, to keep cloud images small for apps that don't use
 Python themselves.
>>> Wouldn't it be a better goal to not have Python at all on Cloud images?
>>>
>> So... no dnf? That seems a little unlikely to yield a good long-term result.
> If Cloud becomes Atomic, it probably wouldn't have dnf. Current atomic
> builds don't. I'm not sure how far off the hybrid rpm install rpms in
> an rpm-ostree release is going to be.
>
That might be the goal, that anything in atomic would have to use
sysstem-python.  Would be a good start.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Python packages not compliant to Fedora guidelines

[Till Maas]

On Sat, Feb 06, 2016 at 11:00:29AM +0100, Haïkel wrote:

> Problem is that these guidelines are not compliant with EL7 guidelines.
> I have the reverse problem that packages from EPEL7 don't build
> anymore on CentOS.

Where are these guidelines documented?

Kind regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaning liborigin and liborigin2

[Christian Dersch]

Of course

On 02/08/2016 06:32 PM, Alexander Ploumistos wrote:
> I've taken them for the time being and I'll go over the specs and
> sources sometime this week. Can I bug you if I have any questions?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Intent to orphan shorewall

[Orion Poplawski]

On 02/08/2016 08:56 AM, Digimer wrote:
> On 08/02/16 08:56 AM, Michele Baldessari wrote:
>> On Thu, Dec 17, 2015 at 11:03:46PM -0500, Digimer wrote:
>>> On 17/12/15 09:26 PM, Orion Poplawski wrote:
 On 12/17/2015 05:27 PM, Digimer wrote:
> I'll take co-maintainer to assist Alex as she comes up to speed. I
> maintained the "cluster" package in Fedora up until it was retired in
> F16. I'm a little rusty now, but shorewall is a fairly simple package
> and we already maintain a repo of our own, so I expect little trouble.
>
> digimer
>
> On 17/12/15 10:48 AM, Alex Bruneau wrote:
>> I am new to package maintaining, but Alteeve's Niche uses Shorewall
>> in one of our offerings, and I'd be happy to take it on. Our tech
>> lead is available to assist as well. Thank you for all of your work
>> on the package!

 So, Alex (nyz ?) appears to not be a packager, and I can't find
 digimer's FAS name.  I'll just have to ask that people add themselves to
 the package:

 https://admin.fedoraproject.org/pkgdb/package/rpms/shorewall/
>>>
>>> I just added myself as a watcher.
>>>
>>> Alex (nick is 'nyz', yes) just setup her account today. I'll chat with
>>> her tomorrow about setting up on FAS.
>>
>> I see this is still orphaned. I am happy to step in if you guys changed
>> your mind, as I use shorewall quite a bit in my setups.
>>
>> Please let me know,
>> Michele
> 
> I want to take it over, but work has proven more busy that I expected.
> If you have the cycles, please take it. I would be happy to be
> co-maintainer though. This would have been my first package, so it's
> probably smarter if I helped someone with experience rather than try to
> do it myself. :)
> 

I've orphaned this now.  Interested parties step up and take it.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ebay-cors-filter's dependencies failed to resolve in f24

[Orion Poplawski]

On 02/08/2016 08:51 AM, Sandro Bonazzola wrote:
> Hi, just received:
> 
> On Mon, Feb 8, 2016 at 4:46 PM,  > wrote:
> 
> ebay-cors-filter's dependencies failed to resolve in f24
> https://apps.fedoraproject.org/koschei/package/ebay-cors-filter
> 
> --
> You received this message due to your preference settings at
> 
> https://apps.fedoraproject.org/notifications/sbonazzo.id.fedoraproject.org/email/29603
> 
> 
> 
> but koschei page doesn't show any relevant error. Any pointer to a log I can
> check to see what's missing there?

It does, it says:

Dependency problems nothing provides mvn(org.codehaus.groovy:groovy-all)
needed by xbean-4.4-2.fc24.noarch


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: rpmlint FAILED for cppad-20160000.0-2.fc24

[Jason L Tibbitts III]

> "KP" == Kamil Paral  writes:

KP> Hello, we have an RFE for adding a rpmlint whitelist feature here:
KP> https://phab.qadevel.cloud.fedoraproject.org/T692

I can't actually log into phabricator to respond there, but really this
needs to be with the spec file.

I edit spec files in vim, with syntastic calling rpmlint to check syntax
on the fly.  Having a per-package rpmlintrc is the only reasonable way
to handle this kind of thing; taskotron just needs to know how to get to
it.  I really wish more packagers did this, because sometimes rpmlint
has so many complaints about a package that you have to wonder if
anyone's actually run it against the package I'm viewing.  Having
taskotron do some spamming is a great start.

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

F24 Self Contained Change: Let's Encrypt client now in Fedora

[Jan Kurik]

= Proposed Self Contained Change: Let's Encrypt client now in Fedora =
https://fedoraproject.org/wiki/Changes/LetsEncrypt#Scope

Change owner(s):
* Nick Bebout 
*James Hogarth 
* Nick Le Mouton 

The Let's Encrypt client is now packaged in Fedora. This will allow
Fedora users to easily install the Let's Encrypt client (letsencrypt)
and generate free SSL certificates for their websites (or other
services which use SSL)


== Detailed Description ==
The Let's Encrypt client is now packaged in Fedora. This will allow
Fedora users to easily install the Let's Encrypt client (letsencrypt)
and generate free SSL certificates for their websites (or other
services which use SSL)


== Scope ==
Proposal owners:
* To implement this Change

Other developers: N/A (not a System Wide Change)

Release engineering: N/A (not a System Wide Change)

List of deliverables: N/A (not a System Wide Change)

Policies and guidelines: N/A (not a System Wide Change)

Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Review swaps (4 R packages)

[Mukundan Ragavan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/08/2016 11:14 AM, Mattias Ellert wrote:
> Hi!
> 
> I have 4 R package that I submitted for review.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1305333 R-highlight 
> https://bugzilla.redhat.com/show_bug.cgi?id=1305334 R-inline 
> https://bugzilla.redhat.com/show_bug.cgi?id=1305335 R-Rcpp 
> https://bugzilla.redhat.com/show_bug.cgi?id=1305336 R-RInside
> 
> There is a dependency chain: The 3rd depends on the first two, and 
> the 4th depends on the 3rd.
> 
> Review swaps welcome.
> 
> Mattias
> 


I can take these up for review.

Mukundan.


- -- 
GPG Key - E5C8BC67
- ---


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWuUk2AAoJEHE/1K3lyLxnSEMQAJhc5VWfvVThfwlU1YnIXjZi
XGdTyeJyo7RToXfCiGhaaJajq8ATJNtO0oNiNVHFy3f9ZGqf3XIRnYowPDanRL3l
CUcmem1kNJMpPAnMVxT0IrKdXbWo+GsxAdr0uc5Ne4fgAk0rSiX7u0hIuz7rlyrt
V0QVUwq0Qeho7OfJEX2LL2Lrpv0yuwr3nc9ODxM1VVhNekcxCPGvDsC0UpAvl3FK
WVUKyMB09OKnIjvbxIHTTBAZXC0v4MyD4h+zE3VnOBBryyt8vdD366Ch3vuV7jQs
Fj5gHTtx8VGjUczpu7oxmfLhk1O/8w/9DncqyJ5G0GzYjJv6vUTkmsZNXgulk92R
aFw37NzriOZQ9YfGRXaEZJy6u07qZMwMzwurAMYfANMK1WfIlfs3vUbl+PmQjm7v
3dHeSdmiAJbbGpkNV+G6OnZp70UqSGxCtl76P10PRlmHLspS4ryi3rACI+yjRVL3
0xiWqDx3Mv6CIk8hhAYXhLVC0fSVHQR+7GLGd1zGtZobgvMmhbjT2jEiuQLHjRnS
609IPV5UOS8bYuPNZTCaie6ORAFY/DSvRBbrvhrk3PClQxs8hnGQbKY7cx4I9iyy
XugZ4gUrupb+eayE4ldrHxB5tlaqdNOZETsvBNTzuywhjO87kB/3+d9yF9RvNTj/
XFlVVBv/H+NQAd9iEqxE
=erLs
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: Let's Encrypt client now in Fedora

[Neal Gompa]

On Mon, Feb 8, 2016 at 8:45 PM, Jan Kurik  wrote:
> = Proposed Self Contained Change: Let's Encrypt client now in Fedora =
> https://fedoraproject.org/wiki/Changes/LetsEncrypt#Scope
>

Why is this a proposed Change? Let's Encrypt was pushed out to *all*
currently supported Fedora releases, so of course it's naturally in
the next one. And aren't we supposed to *not* do stuff like this
anymore?



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org