Phil Knirsch | 2 Oct 18:28 2014

[Base] Base Design WG agenda meeting 03 October 2014 15:00 UTC on #fedora-meeting

Unfortunately tomorrow is a public holiday in Germany, but if someone 
else from the WG would run the meeting i've put together a proposed 
agenda for tomorrow to give a few updates:

  - Update buildrequires cleanup work (davids)
  - Update Alpha base image
  - Open Floor

Thanks & regards, Phil

Philipp Knirsch              | Tel.:  +49-711-96437-470
Manager Core Services        | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch <at>>
Wankelstrasse 5              | Web:
D-70563 Stuttgart, Germany

devel mailing list
devel <at>
Fedora Code of Conduct:
Honza Horak | 2 Oct 17:00 2014

Idea: Ability to define dependencies between coprs (correctly)

Hi all,

I have a proposal that would change how dependencies are defined in copr:

Currently, copr allows to add a link to an arbitrary repo URL that is 
available for installing dependencies during building in copr. Using 
this dependent repo link we are able to build packages in coprA with 
dependencies in another coprB.

However, when enabling only coprA and installing some packages from this 
copr, we can miss some packages from coprB, because those packages are 
not available since coprB is not enabled.

We should be able to define dependency between coprs correctly. When 
creating coprA, we would add one or more depended coprs ('userB/coprB') 
instead of repo link. Then all packages from these coprs would be 
available during build, correct buildroots would be used (no need to 
specify variables $releasever and in addition, we would be able to 
provide correct (all) RPMs also when *installing* coprs.

There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically 
installed all related coprs. That means when running `dnf copr enable -r 
userA/coprA`, user would end with two coprs enabled: userA/coprA and 

2) More complicated, preferred by me :) :
(Continue reading)

Fedora Branched Report | 2 Oct 12:07 2014

F-21 Branched report: 20141002 changes

Compose started at Thu Oct  2 07:15:02 UTC 2014
Broken deps for armhfp
	PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
	audtty-0.1.12-9.fc20.armv7hl requires
	authhub-0.1.2-3.fc19.armv7hl requires
	avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
	avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
	cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90
	check-mk-agent-1.2.4p5-1.fc21.armv7hl requires /usr/bin/ksh
	check-mk-multisite-1.2.4p5-1.fc21.noarch requires /usr/bin/ksh
	cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
	cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
	cp2k-openmpi-2.5.1-8.fc21.armv7hl requires
	cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
	deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers)
	deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles)
	django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
	docker-registry-0.7.3-1.fc21.noarch requires docker-io
(Continue reading)

Rahul Sundaram | 2 Oct 04:39 2014

Dash as default shell


Is it worth considering using Dash as the default (non-interactive) shell in Fedora?  Other distributions including Ubuntu and Debian ( have been using dash as the default shell and Android uses mksh.  While this appears to have been done primary to increase bootup efficiency (which is not relevant with systemd), it might help with security

Since the recent Shellshock aka Bashdoor vulnerability, there have been some discussions about more distributions switching over ( and I was wondering whether it is worth considering for Fedora?  FWIW, both dash and mksh is already packaged in Fedora.


devel mailing list
devel <at>
Fedora Code of Conduct:
Jerry James | 2 Oct 00:21 2014

Broken image links on

I'm sure I should file a ticket about this somewhere, but I'm not sure where.

I was just signing up for yet another Fedora mailing list, and saw the default image boxes at the bottom of the screen that indicate broken links.  Sure enough, I'm getting 404s for these URLs, all of which are referred to by the various mailing list information pages:

I checked the information page for several mailing lists, and they're all broken.  Regards,
Jerry James

devel mailing list
devel <at>
Fedora Code of Conduct:
Mike Ruckman | 1 Oct 22:31 2014

[Test-Announce] 2014-10-03 <at> 16:00 UTC ** Out of band Blocker Review Meeting

# F21 Blocker Review meeting
# Date: 2014-10-03
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on

Towards the end of today's blocker review meeting, we decided it would be good
for us to have a another meeting this week to deal with the unusually large 
number of blockers left we have to go through. Currently the number we still 
have is 15. So if you're available to help go through the list this Friday,
we'd appreciate the help going through the list.

On the other hand, if it works out for more people to do the meeting tomorrow,
we can do that as well. I just feared it would be too short of notice to go
ahead and schedule for tomorrow. Reply to test <at> or ping
me on IRC if tomorrow works better for you, we can adjust accordingly if there
is enough interest.

If you want to take a look at the accepted blockers, the full list can be found

We'll be evaluating these bugs to see if they violate the Beta
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki [0]. Product specific plans are still being solidified, but that
should be sorted quickly.

For more information about the Blocker and Freeze exception process,
check out these links:

And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out the SOP
on the wiki:

See you Friday!


// Mike 
Fedora QA
freenode: roshi
test-announce mailing list
test-announce <at>

devel mailing list
devel <at>
Fedora Code of Conduct:
Andre Robatino | 1 Oct 16:43 2014

[Test-Announce] Fedora 21 Beta Test Compose 1 (TC1) Available Now!

As per the Fedora 21 schedule [1], Fedora 21 Beta Test Compose 1
(TC1) is now available for testing. Content information, including
changes, can be found at . Please see the following
pages for download links (including delta ISOs) and testing
instructions. Normally should provide the fastest
download, but is available as a mirror
(with an approximately 1 hour lag) in case of trouble. To use it, just
replace "dl" with "download-ib01" in the download URL.



Workstation and Desktop:


Ideally, all Alpha and Beta priority test cases for each of these test
pages [2] should pass in order to meet the Beta Release Criteria [3].
Help is available on #fedora-qa on [4], or on the test
list [5].

Create Fedora 21 Beta test compose (TC) and release candidate (RC)

Current Blocker and Freeze Exception bugs:

[4] irc://

test-announce mailing list
test-announce <at>

devel mailing list
devel <at>
Fedora Code of Conduct:
Jaroslav Reznik | 1 Oct 15:18 2014

Fedora 21 Accepted Changes 100% Complete Deadline in two weeks

This time I'm sending "Accepted Changes 100% Complete" reminder a bit
earlier than usually as we still have quite a lot of work to do on
Changes and it's going to  help other teams to participate in Changes
process earlier (aka Docs team etc.).

2014-10-14 Accepted Changes 100% Complete 

Expected bug state is ON_QA - Change has to be code completed and
can be tested in the Beta release (optionally by Fedora QA).

Please make sure to update state of yours Change(s) bug(s) on time.
In case of any problems, let me know, we will try to find solution.

Expect more nagging in Change bug(s) between now and Beta Freeze ;-).

Your friendly Change Wrangler
devel-announce mailing list
devel-announce <at>

devel mailing list
devel <at>
Fedora Code of Conduct:
Gilboa Davara | 1 Oct 14:02 2014
Picon uses self-signed certificates?

Hello all,

When trying to download my package source files from I'm getting self-signed SSL certificates (see details below).
While it's most likely a minor infrastructure issue, I'd suggest exercising caution when downloading sources from
I've also sent an email to admin <at>

FWIW, the certificate information is:

Subject Name:
C (Country):    US
ST (State):    North Carolina
O (Organization):    Fedora Project
OU (Organizational Unit):    Fedora Builders
CN (Common Name):
EMAIL (Email Address):    buildsys <at>

Issuer Name:
C (Country):    US
ST (State):    North Carolina
L (Locality):    Raleigh
O (Organization):    Fedora Project
OU (Organizational Unit):    Fedora Project CA
CN (Common Name):    Fedora Project CA
EMAIL (Email Address):    admin <at>


devel mailing list
devel <at>
Fedora Code of Conduct:
Pranav Kant | 1 Oct 11:11 2014

Packaging STLPlus

<div dir="ltr"><div><div><div>Hello,<br></div>I am trying to package
STLPlus (<a href=""
library for fedora. There are few doubts I have in mind regarding
packaging it.<br><br></div>1. The library is dependent on another
project viz. 'makefiles' (<a
 This project is also distributed in a separate tar ball. This project
only contains few helper files that are included by the
STLPlus library's makefile (Hence, STLPlus requires this package for
build only). Other projects can also make use of this project to write
their makefiles quickly. I think makefiles project is more generic and
not quite specific to STLPlus, hence must be packaged separately. Is it
right to package it separately ? Though I understand that 'makefiles'
name is too general and should be renamed to something else may be
 Re. Location of 'makefiles' project : Since, it only contains few
helper files, I am wondering what would be the best location for
installing these files ? datadir ? libdir ?<br clear="all"><br>--
<br><div dir="ltr"><div>Regards,<br>Pranav
Kant,<br></div><div>Department of Computer Science<br>National
Institute of Technology Hamirpur<br></div><div><a

devel mailing list
devel <at>
Fedora Code of Conduct:
Václav Pavlín | 1 Oct 09:56 2014

[Base] F21 Alpha Docker base image release


Dennis, could you please build Alpha base image with updated bash? (And 
probably also prepare F20 and Rawhide images so that we can really call 
the Fedora image official with all it's tags?)

We should probably also consider using Fedora Cloud SIG account on 
github to push these image to Docker Automated builds - it would 
probably look better then using Lokesh's account (no offence:) ).

The *interim* workflow for uploading official Fedora image to Docker Hub 
would be:

1. Download tar.gz and ks from Koji
2. Unpack
3. Compress layer.tar as xz
4. Upload Dockerfile, ks and *.tar.xz to Fedora Cloud SIG github 
repository (same as
5. Update

I agree with Matt we should ship what we have and follow up with Docker 
on enablement of import for our images (containing metadata) built in Koji.

Does this make sense to you? If there will be no objections, could we vote?

Lokesh, would you like to continue to maintain the process of getting 
Fedora Docker base images to the audience?

Thanks & regards,


Lead Infrastructure Engineer
Developer Experience
Brno, Czech Republic


devel mailing list
devel <at>
Fedora Code of Conduct: