devel April 2014

devel@lists.stg.fedoraproject.org

237 participants
237 discussions

Automatically generated configuration files
by Florian Weimer 05 May '14

05 May '14

I'm working on advice on automated X.509 certificate generation during package installation. One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.) I wonder what an ideal RPM package would do in this case? -- Florian Weimer / Red Hat Product Security Team

7 9

We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
by Daniel J Walsh 05 May '14

05 May '14

The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. rpm -q --whatrequires systemd| wc -l 151 On rawhide I see 151 packages on my system which require systemd. We have a couple of options we could add a package called fakesystemd which provides a /usr/bin/systemctl that does nothing and does a provides systemd in the specfile. Then if the user wanted to install systemd into a container it would need to obsolete the fakesystemd package. Or we could break out /usr/bin/systemctl into its own package and have it be smart enough to do nothing if systemd did not exist.

26 78

F21 System Wide Change: Wayland
by Jaroslav Reznik 05 May '14

05 May '14

= Proposed System Wide Change: Wayland = https://fedoraproject.org/wiki/Changes/Wayland Change owner(s): Matthias Clasen and the desktop team <mclasen(a)redhat.com, desktop(a)lists.fedoraproject.org> Port the GNOME desktop to Wayland. == Detailed Description == GNOME is being ported to Wayland. In particular GNOME shell is changed to run as a Wayland compositor instead of an X11 compositor. Other components of GNOME that currently talk directly to the X server, such as gnome-settings- daemon or gnome-control-center, will be ported to corresponding Wayland interfaces. Many GTK+ applications will just work, using the existing Wayland backend. Applications that make use of X-specific APIs will be supported with the xwayland X server, which is started on demand. gdm will be changed to support both Wayland-based sessions and X-based sessions. This change is targeted at F21. For F20, we aim for having an experimental GNOME shell Wayland compositor available, without necessarily having all the surrounding desktop infrastructure ported. To avoid destabilizing the X compositor, mutter will ship two separate libraries, and gnome-shell will ship two binaries that will link against them. Concretely, we plan to have a separate mutter-wayland package. For more details, see this page [1]. == Scope == * Proposal owners: ** Port GNOME shell to be a Wayland compositor ** Implement Wayland equivalents for X11 APIs such as XRANDR, XI2 and accessibility features ** Port gnome-settings-daemon, gnome-control-center, gnome-desktop from X11 APIs to Wayland equivalents ** Enable gdm to launch Wayland sessions ** Complete the GTK+ Wayland backend to be on par with the X11 backend ** Package mutter-wayland as a separate package review [2] (DONE) * Other developers: ** The X team needs to improve xwayland to be good enough for all X11 application - in practice this means we need X 1.16 ** The X team needs to cooperate with us in reimplementing some X11 APIs ** The X team needs to package libevdev (DONE) ** The X team needs to package libinput (DONE) ** It is not necessary for all spins or all desktop environments in Fedora to switch to Wayland at the same time (or ever) * Release engineering: ** No tasks anticipated * Policies and guidelines: ** Once we have a basic Wayland-based GNOME session, it would be good to encourage testers and packagers to test their applications under Wayland ** For applications that are known not to work under Wayland, we will need guidelines for how to ensure that they will transparently run under xwayland [1] https://wiki.gnome.org/ThreePointNine/Features/WaylandSupport [2] https://bugzilla.redhat.com/show_bug.cgi?id=1007445 _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

9 17

kernel packaging split up landing in Rawhide
by Josh Boyer 05 May '14

05 May '14

Hi All, As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1], I've committed and pushed the kernel packaging split up into kernel-core and kernel-drivers subpackages. For those of you running rawhide, this really shouldn't be a major impact at all. When you do a yum update, you will see "kernel", "kernel-core", and "kernel-drivers" packages being installed. The end result should be in line with today's rawhide kernels. Note: Unless you're using a typical VM or Cloud image, don't uninstall the kernel or kernel-drivers packages. The machine may boot with just kernel-core, but it will lack drivers for a significant portion of bare-metal hardware without kernel-drivers installed. Despite best efforts in testing, it's always possible a bug or two snuck through. In the event that you do have an issue with this, please file a bug against the kernel package. josh [1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud

6 11

Re: [Fedora Update] [CRITPATH] [comment] mesa-10.1-6.20140305.fc20, pure-0.58-3.fc20, python-llvmpy-0.12.4-1.fc20, pocl-0.9-4.fc20.1, OpenGTL-0.9.18-9.fc20, gedit-code-assistance-0.2.0-5.fc20, gambas3-3.5.3-1.fc20.1, dragonegg-3.4-0.3.rc0.fc20, llvm-3.4-6.fc20
by Adam Jackson 05 May '14

05 May '14

On Sat, 2014-04-19 at 15:33 +0000, updates(a)fedoraproject.org wrote: > The following comment has been added to the mesa-10.1-6.20140305.fc20,pure-0.58-3.fc20,python-llvmpy-0.12.4-1.fc20,pocl-0.9-4.fc20.1,OpenGTL-0.9.18-9.fc20,gedit-code-assistance-0.2.0-5.fc20,gambas3-3.5.3-1.fc20.1,dragonegg-3.4-0.3.rc0.fc20,llvm-3.4-6.fc20 update: > > bodhi - 2014-04-19 15:33:49 (karma: 0) > This update has been submitted for stable by ignatenkobrain. Can you please not just decide to push things to updates that I'd already promised fesco I'd leave in testing for a long soak period? That be great. - ajax

8 13

Orphaning java-1.5.0-gcj
by Deepak Bhole 01 May '14

01 May '14

Hi, There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this. I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, please let me know. Please do keep in mind though that we really should just remove GCJ (despite the effect it will have on pdftk) as preferred by one of the primary authors of it (Andrew Haley): https://lists.fedoraproject.org/pipermail/devel/2014-March/196535.html https://lists.fedoraproject.org/pipermail/devel/2014-March/196895.html https://lists.fedoraproject.org/pipermail/devel/2014-March/197157.html Deepak

10 15

F21 Self Contained Change: The Shogun Machine Learning Toolbox
by Jaroslav Reznik 30 Apr '14

30 Apr '14

= Proposed Self Contained Change: The Shogun Machine Learning Toolbox = https://fedoraproject.org/wiki/Changes/shogun Change owner(s): Björn Esser <besser82(a)fedoraproject.org> SHOGUN is a large Scale Machine Learning Toolbox, being implemented in C++ and offering interfaces to C#, Java, Lua, Octave, Perl, Python, R and Ruby. == Detailed Description == * Homepage: The SHOGUN Machine Learning Toolbox [1] * SCM-repo: on GitHub [2] * Documentation: is available here [3] * further Information: on Wikipedia [4] The machine learning toolbox's focus is on large scale kernel methods and especially on Support Vector Machines (SVM). It provides a generic SVM object interfacing to several different SVM implementations, among them the state of the art LibSVM. Each of the SVMs can be combined with a variety of kernels. The toolbox not only provides efficient implementations of the most common kernels, like the Linear, Polynomial, Gaussian and Sigmoid Kernel but also comes with a number of recent string kernels as e.g. the Locality Improved, Fischer, TOP, Spectrum, Weighted Degree Kernel (with shifts). For the latter the efficient LINADD optimizations are implemented. Also SHOGUN offers the freedom of working with custom pre-computed kernels. One of its key features is the "combined kernel" which can be constructed by a weighted linear combination of a number of sub-kernels, each of which not necessarily working on the same domain. An optimal sub-kernel weighting can be learned using Multiple Kernel Learning. Currently SVM 2-class classification and regression problems can be dealt with. However SHOGUN also implements a number of linear methods like Linear Discriminant Analysis (LDA), Linear Programming Machine (LPM), (Kernel) Perceptrons and features algorithms to train hidden Markov- models. The input feature-objects can be dense, sparse or strings and of type int/short/double/char and can be converted into different feature types. Chains of "pre-processors" (e.g. subtracting the mean) can be attached to each feature object allowing for on-the-fly pre-processing. == Scope == * Proposal owners: Create the rpm-spec and file a review bug. Have the package build after review was granted. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] http://shogun-toolbox.org/ [2] https://github.com/shogun-toolbox/shogun [3] http://shogun-toolbox.org/doc/en/current/ [4] http://en.wikipedia.org/wiki/Shogun_%28toolbox%29 _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

2 1

F21 System Wide Change: Default Local DNS Resolver
by Jaroslav Reznik 30 Apr '14

30 Apr '14

= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): P J P <pjp(a)fedoraproject.org>, Pavel Šimerda <pavlix(a)pavlix.net>, Tomas Hozza <thozza(a)redhat.com> To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately, as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. This change was submitted after the Submission deadline. == Detailed Description == There are growing instances of discussions and debates about the need for a trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are multiple reasons for having such a resolver, importantly security & usability. Security & protection of user's privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide. People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust. Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but be unavoidable. Because it will perform the most important operation of establishing trust between two parties. All DNS literature strongly recommends it. And amongst all discussions and debates about issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It'll simplify and facilitate lot of other design decisions and application development in future. (See: [1], [2], [3]) People:- * Petr Spacek * Paul Wouters * Simo Sorce * Dmitri Pal * Carlos O'Donell == Scope == * Proposal owners: Proposal owners shall have to ** define the syntax and semantics for new configuration parameters/files. ** persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications. * Other developers: (especially NetworkManager and the likes) ** would have to implement the new features/workflow for their applications adhering to the new configurations and assuming the availability of the '''trusted''' local DNS resolver. ** NetworkManager already has features & capability to support local DNS resolvers. Though few details are still under development, but are expected to realize in near future. Please see [4] * Release engineering: ** would have to ensure that trusted local DNS resolver is available throughout the installation stage and the same is installed on all installations including LiveCDs etc. * Policies and guidelines: ** the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) would have to ensure that their DNS resolver starts at boot time and works out of the box without any user intervention. ** NetworkManager and others would have to be told to not tamper with the local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver entries in a separate configuration file. [1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

15 38

Schedule for Thursday's FPC Meeting (2014-04-24 16:00 UTC)
by James Antill 30 Apr '14

30 Apr '14

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-04-24 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-04-24 09:00 Thu US/Pacific PDT 2014-04-24 12:00 Thu US/Eastern EDT 2014-04-24 16:00 Thu UTC <- 2014-04-24 17:00 Thu Europe/London BST 2014-04-24 18:00 Thu Europe/Paris CEST 2014-04-24 18:00 Thu Europe/Berlin CEST 2014-04-24 21:30 Thu Asia/Calcutta IST ------------------new day---------------------- 2014-04-25 00:00 Fri Asia/Singapore SGT 2014-04-25 00:00 Fri Asia/Hong_Kong HKT 2014-04-25 01:00 Fri Asia/Tokyo JST 2014-04-25 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #400 Exception for bundled library FoX in exciting .fpc 400 https://fedorahosted.org/fpc/ticket/400 (remaining votes needed) #topic #407 Bundled lib exception request (copylibs) for sha1 bundled with apt-cacher-ng .fpc 407 https://fedorahosted.org/fpc/ticket/407 (remaining votes needed) #topic #408 Temporary jquery bundling exception for libserialport .fpc 408 https://fedorahosted.org/fpc/ticket/408 (remaining votes needed) #topic #416 Temporary bundling exception for ipython .fpc 416 https://fedorahosted.org/fpc/ticket/416 (remaining votes needed) #topic #420 PHP Guidelines change - numeric prefix .fpc 420 https://fedorahosted.org/fpc/ticket/420 = New business = #topic #411 proposal: migrate license files to %license instead of %doc .fpc 411 https://fedorahosted.org/fpc/ticket/411 #topic #413 Bundling exception request for nodejs-shelljs .fpc 413 https://fedorahosted.org/fpc/ticket/413 #topic #414 Please consider requiring AppData for all desktop applications .fpc 414 https://fedorahosted.org/fpc/ticket/414 #topic #417 sha2 library bundling in clementine .fpc 417 https://fedorahosted.org/fpc/ticket/417 #topic #418 Bundling exception for reaver-wps .fpc 418 https://fedorahosted.org/fpc/ticket/418 #topic #419 ruby193 in SCL .fpc 419 https://fedorahosted.org/fpc/ticket/419 #topic #421 Update environment modules guidelines .fpc 421 https://fedorahosted.org/fpc/ticket/421 #topic #422 move an existing package to a different upstream fork .fpc 422 https://fedorahosted.org/fpc/ticket/422 #topic #423 Bundling exception request (copylib) for TommyDS library used in SnapRAID .fpc 423 https://fedorahosted.org/fpc/ticket/423 #topic #424 Bundling exception request for nodejs-weak-map .fpc 424 https://fedorahosted.org/fpc/ticket/424 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

3 3

Dracut HostOnly two releases later
by Reindl Harald 30 Apr '14

30 Apr '14

looks like https://fedoraproject.org/wiki/Features/DracutHostOnly over the long has the opposite effect and more and more modules are included in the hostonly-initrd because regressions right and left people who used hostonly before the feature on machines where it is fine where down below 5 MB, with F19 around 6 MB and on a completly stripped down F21/Rahide we reahc 9 MB 5,9M 2014-04-27 11:47 initramfs-3.13.11-100.fc19.x86_64.img 8,9M 2014-04-30 21:47 initramfs-3.15.0-0.rc3.git1.10.fc21.x86_64.img finally nobody won and the ones with stripped down systems lost

1 0

← Newer
1
2
3
4
5
6
7
...
24
Older →

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 April 2014