devel September 2017

devel@lists.fedoraproject.org

189 participants
285 discussions

apitrace, bundled libbacktrace
by Sandro Mani 17 Dec '17

17 Dec '17

Hi, apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged. Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request? Thanks, Sandro

8 9

Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages
by Michael Catanzaro 13 Dec '17

13 Dec '17

Hi, This is a reminder that the webkitgtk and webkitgtk3 packages will be retired from rawhide shortly after F26 is branched from rawhide. This is due to numerous security issues affecting those packages (I just counted 204 CVEs), many of which could allow remote code execution. Bugs have already been filed against all directly-affected packages [1]. Note: to count the vulnerabilities, I just manually added up the CVEs listed at [2], ignoring the oldest advisory WSA-2015-0001, and discounting five of the older vulnerabilities in WSA-2015-0002. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=1375784 [2] https://webkitgtk.org/security.html

10 26

Improving Linux laptop battery life: Testers Wanted
by Hans de Goede 27 Nov '17

27 Nov '17

Hi All, My next project for Red Hat is to work on improving Linux laptop battery life. Part of the (hopefully) low hanging fruit here is using kernel tunables to enable more runtime powermanagement. My first target here is SATA Link Power Management (LPM) which, as Matthew Garrett blogged about 2 years ago: https://mjg59.dreamwidth.org/34868.html can lead to a significant improvement in battery life. There is only one small problem, there have been some reports that some disks/SSDs don't play well with Linux' min_power LPM policy and that this may lead to system crashes and even data corruption. As such I've written a new LPM policy, which matches the power-management defaults from the Intel RST Windows drivers. Since it mimicks Windows, this new policy will hopefully not hit any SSD firmware bugs like min_power sometimes does. So now I'm looking for people with a laptop with a SATA SSD or HDD to help me test this to make sure this won't cause any issues when we enable this by default for F28, for more details and test instructions see: https://hansdegoede.livejournal.com/18412.html Regards, Hans

5 15

F27 System Wide Change: NSS Default File Format SQL
by Jaroslav Reznik 23 Nov '17

23 Nov '17

= System Wide Change: NSS Default File Format SQL = https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql Change owner(s): * Kai Engert <kaie(a)redhat.com> Change the NSS library default to use the sqlite based data storage, when applications don't specify their preferred storage file format. == Detailed Description == Applications that use the NSS library often use a database for storage of keys, certificates and trust. NSS supports two different file formats, one called DBM (based on berkeley DB files) and another one called SQL (based on sqlite DB files). Today's default file format used by NSS, used when applications omit the type parameter, is the older DBM file format, which forbids parallel access to the storage. The suggestion is to change the default file format to SQL, which allows parallel access to the storage. Applications, or users using the NSS command line utilities, often provide the database storage location using a simple directory path parameter. Some might not be aware, or forget, that the parameter can be prefixed with a type modifier, either "dbm:" or "sql:". As a result, when not providing this parameter, the file format used will be the fragile DBM file format. This is particuarly problematic, if a user attempts to modify the NSS storage using command line tools, while another process, such as a daemon, is running concurrently, which also accesses the same database in the DBM file format. This often results in corrupted database storage, which cannot be recovered. By changing the default, all applications that currently use the DBM file format, will automatically be migrated to the SQL file format. NSS has the ability to discover if a storage location (a directory) contains the DBM file format. If configured to use the modern SQL format, NSS will automatically perform a one-time conversion from the DBM to the SQL format. The same applies to the NSS command line utilities. If the NSS library default is changed to SQL, the NSS tools will also trigger the one-time conversion, or access the already converted files. == Scope == * Proposal owners: A small downstream patch needs to be applied to the NSS library package, which changes the library default. * Other developers: It's up to developers of NSS applications, if they accept the new default and an automatic conversion, or if they prefer to continue to use the classic DBM storage format. Although not recommended, developers can easily do so, by adding a "dbm:" prefix to the storage parameter they provide to NSS at NSS library initialization time. * Release engineering: [1] No help should be necessary. No mass rebuild necessary. * Policies and guidelines: N/A * Trademark approval: N/A [1] https://pagure.io/releng/issue/6883 Thanks, Jaroslav

3 5

Call for testing - Firefox CSD/titlebar
by Martin Stransky 16 Nov '17

16 Nov '17

Guys, there's available [1] new Firefox package with emulated CSD rendering [2]. What does it mean for you? Firefox renders CSD decorations on its own then and you don't see the default gnome titlebar on top of the main window and you get a "Chromish" look. That should also work with Firefox light themes. But you need to enable it explicitly at about:config. Set "widget.allow-client-side-decoration" to true and restart the browser. Please report any issues to bugzilla.redhat.com and mentions it's the CSD version. I'm also interested on testing when "widget.allow-client-side-decoration" is false - to make sure it does not break anything. Thanks! ma. [1] Fedora 25: https://koji.fedoraproject.org/koji/buildinfo?buildID=970606 Fedora 26: https://koji.fedoraproject.org/koji/buildinfo?buildID=970604 Fedora 27: https://koji.fedoraproject.org/koji/buildinfo?buildID=970605 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1399611

14 21

CI projects in Copr
by Miroslav Suchý 01 Nov '17

01 Nov '17

Hi, I am gathering informations about various use of CI with Copr. Do you use Copr for building packages for nightlies? For building packages before pull request is merged? Do you have your set up described somewhere? What is the name of your project? Please let me know. Either here or via private reply. It will help me to understand your use of Copr and to make Copr better. Thanks in advance. Miroslav Suchy

12 30

Re: Is it possible atlas is linked wrongly by new binutils?
by Richard W.M. Jones 27 Oct '17

27 Oct '17

On Thu, Aug 10, 2017 at 11:21:30AM +0200, Jakub Martisko wrote: > > > On 9.8.2017 11:37, Richard W.M. Jones wrote: > > > > ocaml-gsl (OCaml bindings for GNU Scientific Library) currently > > fails to link to atlas: > > > > + /usr/bin/ocamlfind ocamlopt -g -I lib -linkpkg -package bigarray -I lib -I examples lib/gsl.cmxa examples/blas_ex.cmx -o examples/blas_ex.native > > /usr/lib64/atlas/libsatlas.so: undefined reference to `dlarfy_' > > /usr/lib64/atlas/libsatlas.so: undefined reference to `slarfy_' > > /usr/lib64/atlas/libsatlas.so: undefined reference to `clarfy_' > > /usr/lib64/atlas/libsatlas.so: undefined reference to `zlarfy_' > > collect2: error: ld returned 1 exit status > > > > However this only happens with the very latest atlas that was built by > > binutils 2.29 (atlas-3.10.2-18.fc27.x86_64). It doesn't occur with > > the previous version of atlas (atlas-3.10.2-16.fc26) even though there > > seems to have been no change in atlas. > > > > $ nm -D /usr/lib64/atlas/libtatlas.so | grep larfy > > U clarfy_ > > U dlarfy_ > > U slarfy_ > > U zlarfy_ > > > > I looked in /usr/lib64 on my development machine which has atlas > > installed but there is no .so* file that I can find which defines > > these symbols. I also couldn't work out where in the atlas code > > (which is a bit strange) these references are used. > > > > Hence the question: Is this breakage in atlas? binutils? > > > > Rich. > > > > OK so it seems that according to git commit messages LAPACK > has been rebased from 3.6.0 to 3.7.1 day before that mass > rebuild [1][2]. Those "larfy" subroutines have been added to > LAPACK in 3.7.0 and have not been present before[3]. I've > tried to make a scratch build of atlas [4] and the missing > symbols seem to be present... > > $ nm -D ./libtatlas.so.3|grep larfy > > T clarfy_ > T dlarfy_ > T slarfy_ > T zlarfy_ It looks as if you scratch build just changes ‘rm’ to ‘rm -f’ at one point in the spec file. Is that change also needed? I can do a bump and rebuild of atlas with or without that change - let me know. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

9 24

A less "bloated" KDE spin
by jack smith 12 Oct '17

12 Oct '17

Hello, Would you like to consider to provide a less "bloated" KDE spin ? Here is the softs I suggest to remove to have a much cleaner base experience : kolourpaint kruler qupzilla ktorrent krusader kgpg krfb kmines kpat kmahjongg krdc konversation konqueror akregator kamoso dragon ksshaskpass knode kmouth kmousetool dnfdragora k3b jovie kmail kaddressbook korganizer telepathy* ktp* kmag kfind knetattach Like every softs, if someone need one that is not in the base install, he simply can install it. Thanks !

21 42

'No More Alphas': wiki revision drafts
by Adam Williamson 11 Oct '17

11 Oct '17

Hi, folks! So I've (finally) got ready an initial round of draft changes to various wiki pages for the purpose of implementing the 'No More Alphas' Change. You can find all the drafts in the NoMoreAlphas category: https://fedoraproject.org/wiki/Category:NoMoreAlpha For each page I cloned the original text and saved it as the first edit, so you can use the 'History' tab's diff feature to see the actual changes to each page (just compare the current state to the first edit). To summarize the changes, at least as I remember them, and call out some significant choices: * Obviously, all Alpha-related points on the schedule template on the Fedora Release Life Cycle page were removed. For schedule points that were previously derived from Alpha points that got removed, I adjusted them to derive from some other still-remaining point. * My proposal for 'what do we do about release criteria / validation' is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed 'Basic Release Criteria' (note: not versioned, I don't think it should be), and we document that *all* composes - not just Beta and Final candidate composes, but also Rawhide and Branched nightlies - will be automatically tested for (and release of them gated on) compliance with them. Which is more or less what's proposed in the Change. All external references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is what changed on the other criteria pages, and on the test matrix template pages). Practically speaking, we currently have automated testing for *most* of the existing Alpha criteria, but a few items aren't covered. We can choose to move these to the Beta criteria, or leave them on Basic and just accept that *actual* coverage doesn't quite meet what we aspire to. I do *NOT* propose to have any kind of blocker tracking bug for the Basic release criteria; it doesn't seem to fit in the process, there is no Alpha release to block, and we can't realistically block nightly composes on manual test results. So a tracker bug wouldn't really have any reason to exist. In the case where a violation of the Basic criteria makes it into composes despite the automated testing, it should be marked as a Beta blocker. * There is a problem with what to do about the Change schedule: our two sources for it don't actually agree on what the schedule *is*. The Changes Policy page - https://fedoraproject.org/wiki/Changes/Policy - claims that the 'Completion deadline' "falls on the same day as the Alpha milestone freeze", but the Fedora Release Life Cycle page - https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle - claims it falls on the same day as the branch point, which is two weeks *before* the Alpha freeze. Given this inconsistency I didn't really feel confident proposing a draft for the Changes/Policy page yet; probably it'd be good for FESCo(?) as owners of the Change process to decide when they actually want the key dates of the Change process to be, In A World Without Alphas. If FESCo wants to figure that out and let me know, I can draft the changes. Please do look these over and provide any kind of feedback! Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 14

Deleting a fork in src.fedoraproject.org?
by Christopher 11 Oct '17

11 Oct '17

I was playing around in the new Pagure https://src.fedoraproject.org/ and I created a fork of a repo to test. However, I don't need or want this fork. How do I delete it? There doesn't appear to be an option.

3 2

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 September 2017