devel February 2014

devel@lists.fedoraproject.org

223 participants
212 discussions

State of Python 3 as default in Fedora
by Miro Hrončok 04 Mar '14

04 Mar '14

Hi, I've just published a blogpost that summarizes what's going on with Python 3 as default in Fedora. You can find it here: http://eng.hroncok.cz/2014/02/12/python3-fedora-default/ Feel free to post any comments on my blog or here on the mailing list(s). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 5

Re: default file system, was: Comparison to Workstation Technical Specification
by Jaroslav Reznik 04 Mar '14

04 Mar '14

----- Original Message ----- > On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer <jwboyer(a)fedoraproject.org> > wrote: > > > > Yeah, agreed here. Everyone wants the latest shiniest thing, even if that > thing isn't ready. I really don't want to wade through tons of bug reports > for btrfs just because it has a lot of hype. > > Also, right now cloud is plain old ext4. Let's see if we can ship *all* of > the filesystems! It'll be fun! Yep, a lot of fun - three different file systems for free different products. And we are back to the question how much these products could differ - with limited resources we have right now - at least short term. Who can answer it - filesystem/kernel guys, if they are able and willing to support all potential filesystem, as David stated, it's possible in Anaconda but again the same question if the team would be able to maintain more filesystems support with high bar in terms of quality (even for example brtfs limited to bare minimum), QA... And it could be pretty confusing for users but that's up to us/marketing to explain that products aim specific goal and it's for good (if we would be able to support it - then it's for good, if not...). Adding devel list to CC - I expect another topic Base should be involved too. And no, no elections for file system. It's really up to WGs and coordination with the rest teams. Jaroslav > _______________________________________________ > server mailing list > server(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/server

23 70

F21 System Wide Change: Access control in PCSC
by Jaroslav Reznik 04 Mar '14

04 Mar '14

= Proposed System Wide Change: Access control in PCSC = https://fedoraproject.org/wiki/Changes/PcscAccessControl Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com> Add access control to PC/SC smart cards available in the system. Adding access control would (a) prevent unauthorized processes/users from reading data on a smart card, (b) prevent unauthorized processes/users from erasing a smart card, (c) prevent unauthorized processes/users from talking to the smart card firmware. == Detailed Description == Add access control to PC/SC smart cards available in the system. Currently smart cards may provide their own access control for certain elements of a card such as a private key. Their access control method is typically a PIN, but can also be a biometric based one. That however, is not sufficient to prevent certain actions on the non-PIN protected elements. For example cards that provide a PKCS #15 filesystem can be modified by anyone that has access in the system (e.g., erased using pkcs15-init -E). The default settings allowed should be similar to the default settings for hard disks, i.e., root and the user in console should be able to access the smart card. Adding access control would * prevent unauthorized processes/users from reading data on a smart card * prevent unauthorized processes/users from erasing a smart card * prevent unauthorized processes/users from talking to the smart card firmware The way access control will be implemented is using polkit which is already being used to control access to hard disks. As smart cards share a lot with hard disks (e.g., a filesystem, and are inserted by the console user), sharing the same access control method is beneficial. == Scope == polkit support has to be added to PC/SC daemon. An initial version has already been developed and communicated upstream * Proposal owners: The polkit support has to be merged with the Fedora package. That requires changes to the pcsc daemon only, but indirectly all packages that potentially may use smart cards are affected (opensc, firefox, ...). * Other developers: Packages that use PC/SC smart cards must be checked that they work as expected after the access control change. * Release engineering: No coordination is required. * Policies and guidelines: If there is any security policy documentation should be updated to include the new policies on smart cards (I couldn't find any such documentation though) _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

2 1

Fwd: Server Technical Specification: Agenda and First Draft
by Stephen Gallagher 04 Mar '14

04 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the sake of keeping people in the loop, here's a first pass at the Fedora Server technical specification that we will be discussing in a meeting in #fedora-meeting-1 in about 75 minutes. If you can't attend, please make comments on the server(a)lists.fedoraproject.org mailing list, so they're all in one place. - -------- Original Message -------- Subject: Server Technical Specification: Agenda and First Draft Date: Fri, 28 Feb 2014 08:40:02 -0500 From: Stephen Gallagher <sgallagh(a)redhat.com> Reply-To: server(a)lists.fedoraproject.org To: server(a)lists.fedoraproject.org I've created a wiki page[1] for the Technical Specification that we are working on. I've copied much of the structure from the Workstation tech spec, as it was well organized. There are quite a few sections in it that I have tagged as UNAPPROVED. I believe we need to make these the agenda for the Tech Spec Working Session today. What we will do is quickly go through each of them. We'll mark any that are uncontested as "Approved" and then go back and discuss any that need discussion. [1] https://fedoraproject.org/wiki/Server/Technical_Specification _______________________________________________ server mailing list server(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMQkpgACgkQeiVVYja6o6Md/wCgj67FPhsrHa/VxtuBfsCjJU4/ aUIAnRzu/lmm//qxRO0WTRogoTt44H7d =apt3 -----END PGP SIGNATURE-----

7 9

Service units for web applications
by Stephen Gallagher 04 Mar '14

04 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, I have an interesting problem to solve. I have a package that installs a web application[1] that is run automatically with httpd.service. The package can be deployed for one or more "sites" on the system (which may be different apache virtual hosts or just different paths on the same virtual host). On version upgrades, there is a helper script that needs to be run for each "site" of this package on the system to make sure that its database is updated with the latest schema changes. Originally, this helper script would have to be run manually for each site after the package was upgraded (and if you forgot, the application might not function correctly until you did so). I worked with upstream and added a new feature that allows updating all sites on the current system from a single command (getting the list of installed sites from a data file in a known location). I added this script to the %post of the RPM package so it would be run automatically on package upgrade. One problem with this approach is that it will force the database upgrade for all sites on the system, regardless of whether the httpd service is running (or currently serving that site), which could lead to unexpected behavior. The other issue with this approach is that it doesn't necessarily play nice with OSTree, since %post only gets executed on the OSTree host and not on the clients. I'd much rather be able to add the database upgrade script to a per-site service unit, so that it would only be invoked as an ExecStartPre command. This way, it would only be invoked if the service was actually being launched on the system. There are actually two pieces to this that I'd like to see (and hopefully have someone tell me are already possible): 1. The ability to add new ExecStartPre commands to the httpd service when installing new sites. 2. The ability to enable and disable specific apache sites from systemctl. Basically, I'd like to have a symlink added or removed from /etc/httpd/conf.d based on whether httpd-mysite.service was enabled or disabled. The ultimate goal here would be for me to be able to install a reviewboard-sitename.conf file to e.g. /etc/systemd/httpd/ and have it symlinked into /etc/httpd.conf.d when the service was enabled. This service file could then be PartOf=httpd.service and run ExecStartPre to invoke the upgrade script. So, am I on track here, and if so: how can I do this? [1] The package is Review Board, a Django application. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMM9R8ACgkQeiVVYja6o6NWLwCeM54Uc0gJKPFsprmvbwKoYQ0G 2nYAn0vSLoeHDlIWwCYeotXPYydiQ+7H =W5Y9 -----END PGP SIGNATURE-----

7 8

[Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Phil Knirsch 03 Mar '14

03 Mar '14

Main meeting agenda for today was a discussion about the Workstation Tech Spec and any implications, changes or actions it would require from Base. Matthias Clasen from the Workstaing WG joined us today and every a long discussion and review specifically around the Core Services and Features part we've came to the conclusion that at this point with only the Workstation WG tech spec there were no actions or changes required by Base yet. Once the other WGs provide theirs we will revisit that and see where overlaps, conflicts or items might come up that need to be resolved at the Base level. Installer is still a hot topic, but thats nothing we could resolve during our meeting and which might have to be brought up with FESCO again. Meeting ended Fri Feb 21 15:58:11 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-02-21/fedora_base_desi… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-02-21/fedora_base_desi… Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-02-21/fedora_base_desi… 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(a)redhat.com> Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany

13 21

packages from bitbucket
by Nikos Mavrogiannopoulos 02 Mar '14

02 Mar '14

Hello, I've submitted a while ago a review-request on a package [0] that is taken from bitbucket.org. Unfortunately there was no reviewer yet, and I suspect that is because unlike github [1] we have no rules on how to handle bitbucket. Have other packagers experienced something similar in other software? Is there a "good" way to handle repository-distributed software? As it is now in [0] I've tried to simulate the github rules on bitbucket. regards, Nikos [0]. https://bugzilla.redhat.com/show_bug.cgi?id=1062282 [1]. https://fedoraproject.org/wiki/Packaging:SourceURL#Github

6 9

PHP 5.6.0
by Remi Collet 02 Mar '14

02 Mar '14

Hi, PHP 5.6.0 will be soon in "beta" stage. (5.6.0alpha3 is available and should be the last alpha) So I start working on PHP 5.6 packaging. For those interested, for now, this happens in my personal repository (remi-dev). Fedora 20: http://rpms.famillecollet.com/fedora/20/devs/x86_64/repoview/ Fedora 19: http://rpms.famillecollet.com/fedora/19/devs/x86_64/repoview/ For now, 5.6.0 final is planed for June. So should be possible for Fedora 21 (change proposal not yet submitted) I will try to build most extensions to check is eveything is ok. If you have some libraries, with test suite, or some webapps, I encourage you to test again this new version (upgrade should be smooth). Remi.

1 1

Fwd: [CMake] CMake 3.0-rc1 now ready for testing!
by Orion Poplawski 28 Feb '14

28 Feb '14

I've updated rawhide to cmake 3.0.0-rc1. That's a good place to look first if your cmake build start failing suddenly. - Orion -------- Original Message -------- Subject: [CMake] CMake 3.0-rc1 now ready for testing! Date: Fri, 28 Feb 2014 14:28:55 -0500 From: Robert Maynard <robert.maynard(a)kitware.com> To: CMake Developers <cmake-developers(a)cmake.org>, CMake MailingList <cmake(a)cmake.org>, kde-devel(a)kde.org I am proud to announce that CMake 3.0 has entered the release candidate stage. Sources and binaries are available at: http://www.cmake.org/files/v3.0/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.0 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html Some of the more significant features of CMake 3.0 are: * Compatibility options supporting code written for CMake versions prior to 2.4 have been removed. * The CMake language has been extended with *Bracket Argument* and *Bracket Comment* syntax inspired by Lua long brackets. * The CMake documentation has been converted to reStructuredText and uses Sphix generation. * Generators for Visual Studio 10 (2010) and later were renamed to include the product year like generators for older VS versions: * "Visual Studio 10" -> "Visual Studio 10 2010" * "Visual Studio 11" -> "Visual Studio 11 2012" * "Visual Studio 12" -> "Visual Studio 12 2013" This clarifies which generator goes with each Visual Studio version. The old names are recognized for compatibility. * A new "CodeLite" extra generator is available for use with the Makefile or Ninja generators. * A new "Kate" extra generator is available for use with the Makefile or Ninja generators. * The "add_library()" command learned a new "INTERFACE" library type. Interface libraries have no build rules but may have properties defining "usage requirements" and may be installed, exported, and imported. This is useful to create header-only libraries that have concrete link dependencies on other libraries. * The "export()" command learned a new "EXPORT" mode that retrieves the list of targets to export from an export set configured by the "install(TARGETS)" command "EXPORT" option. This makes it easy to export from the build tree the same targets that are exported from the install tree. * The "project()" command learned to set some version variables to values specified by the new "VERSION" option or to empty strings. See policy "CMP0048". * Several long-outdated commands that should no longer be called have been disallowed in new code by policies: * Policy "CMP0029" disallows "subdir_depends()" * Policy "CMP0030" disallows "use_mangled_mesa()" * Policy "CMP0031" disallows "load_command()" * Policy "CMP0032" disallows "output_required_files()" * Policy "CMP0033" disallows "export_library_dependencies()" * Policy "CMP0034" disallows "utility_source()" * Policy "CMP0035" disallows "variable_requires()" * Policy "CMP0036" disallows "build_name()"

1 0

Wiki pages: Missing tests in %check and missing upstream test suites
by Alexander Todorov 28 Feb '14

28 Feb '14

Hi folks, thanks for your feedback in the last few days. I've created two wiki pages about packages which don't execute their tests in %check: https://fedoraproject.org/wiki/QA/Testing_in_check and another one for packages which don't seem to have test suites at all: https://fedoraproject.org/wiki/QA/Missing_upstream_test_suites My intent is for these pages to serve as a source of working material for Fedora volunteers. Note: there are some false negatives which I still haven't filtered out - work in progress. Please forward this to anyone who may be interested to work on these items as we need lots of hands to make any significant improvements! (In particular I will soon teach to students and will point them here). Any comments and proposals are welcome! Thanks, Alex

6 8

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2014