devel February 2018

devel@lists.fedoraproject.org

237 participants
244 discussions

Koji build: cannot find spec file
by Jerry James 30 Mar '18

30 Mar '18

This is the second of two attempts to build sympy this evening, both of which failed the same way: https://koji.fedoraproject.org/koji/taskinfo?taskID=25124365 According to mock_output.log, the spec file can't be found. What is going on? -- Jerry James http://www.jamezone.org/

5 6

Orphaning ofono
by Rex Dieter 28 Mar '18

28 Mar '18

I will be orphaning the ofono package today. I'd primarily packaged it with the the intention that it may become a new dependency of pulseaudio (which never happened), and I've not been able to give it the time it needs. Recently updated to latest 1.22 release which fixed a long-standing FTBFS issue, so at least it is in good shape for anyone interested in picking it up. -- Rex

3 6

COPR src.fp.o auto-rebuilds
by Michal Novotny 21 Mar '18

21 Mar '18

Hello, you can now very easily setup auto-rebuilds for your src.fp.o package: 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork (please, use the https:// cloning option) 2) make sure "Webhook Rebuild" checkbox is checked when you are creating the package 3) Go to settings for your package at src.fp.o and almost at the bottom in Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update" button. If your package is a main package (not a fork), then you can omit step 3. See https://pagure.io/copr/copr/issue/142 for more info. COPR team

3 4

[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
by Igor Gnatenko 19 Mar '18

19 Mar '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Over this weekend I've performed scratch-mass-rebuild without having gcc and gcc-c++ in buildroot of all Fedora packages, many of which failed due to random reasons and I grepped all logs for some common errors found by analyzing hundreds of build logs. Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire s_and_Requies The grep output is located here: https://ignatenkobrain.fedorapeople.org/gcc-removal.txt Some packages might be missed due to short koji outage, broken dependencies and so on, but majority of real failures is below. If you fixed package(s), found false positive, found missing packages in list or anything else -- please let me know. Note to packages which use CMake buildsystem. When you have project(xxx) in CMakeLists.txt it checks both for C and CXX compilers. So you might encounter packages where you have BuildRequires: gcc and it fails on CXX compiler (even you think you don't need it). Solution for this is to send patch to upstream switching to something like project(xxx C), or if problem is opposite to project(xxx CXX). List of packages and respective maintainers: https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8 X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+ ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9 bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5 ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7 Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8= =KRiO -----END PGP SIGNATURE----- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org

69 109

Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)
by Adam Williamson 16 Mar '18

16 Mar '18

qpdf was updated from 7.1.1-4 to 8.0.0-1 in Rawhide on 2018-02-26. This update bumped the soname from libqpdf.so.18 to libqpdf.so.21 . This soname bump was not announced, as it is supposed to be, and dependent packages were not rebuilt. cups-filters depends on qpdf, so anything that includes cups-filters is now broken. This includes at least the Astronomy_KDE live image, per https://pagure.io/dusty/failed-composes/issue/24#comment-496381 . Once again, folks, *please* announce your soname bumps, and co-ordinate rebuilds. (In fact it looks like Zdenek is the maintainer of both packages and could have rebuilt cups-filters, but just forgot to). I will attempt a rebuild of cups-filters using provenpackager privileges. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

28 73

New "tests" namespace to share test code
by Petr Splichal 13 Mar '18

13 Mar '18

Hi! While working on adding CI tests [0] using the Standard Test Interface a need arose to have a shared git repository where tests could be stored: * A large number of test files makes a dist-git repository more difficult to maintain * Tests might follow a different branching pattern than the dist-git repo, leading to code duplication * Shared maintenance for tests sometimes benefits from different access levels than the release dist-git repository The plan is to create a new “tests” namespace in Fedora git/pagure dedicated to storing the shared test code. To enable execution of these tests by the CI pipeline, tests.yml file in dist-git will be used to link the tests in the standard way as defined by the Standard Test Interface [1]. This approach should help to efficiently maintain tests & minimize test code duplication. Using a dedicated git repo for test code also means to keep dist-git more as a place for storing metadata only: Build metadata (spec file = how to build the package) and test metadata (tests.yml = how to test the package) rather than mixing spec files with test code itself. Please note that this does not mean that all tests should now go into this new namespace. You can still link tests directly from upstream (like GitHub) or any other source. Also, for unit tests it makes more sense to be kept directly with the project source and executed there. Shared tests namespace in Fedora will be suitable especially for functional and integration testing which should help to continuously ensure the OS works as a whole. For more detailed motivation and real-life examples see the Share Test Code proposal on the Fedora CI list [2]. If you have any questions or comments feel free to share them here or in the pagure issue requesting the new namespace: https://pagure.io/fedora-infrastructure/issue/6478 Thanks. psss... [0] https://fedoraproject.org/wiki/CI [1] https://fedoraproject.org/wiki/Changes/InvokingTests [2] https://lists.fedoraproject.org/archives/list/ci@lists.fedoraproject.org/th…

7 18

F29 System Wide Change: Enable dbus-broker
by Jan Kurik 13 Mar '18

13 Mar '18

Proposed System Wide Change: Enable dbus-broker https://fedoraproject.org/wiki/Changes/EnableDbusBroker Owner(s): * David Herrmann <dh dot herrmann at gmail dot com> * Tom Gundersen <teg at jklm dot no> Enable dbus-broker.service to use dbus-broker as system and session message bus backend. == Detailed description == The dbus-broker project is an implementation of a message bus as defined by the D-Bus specification. Its aim is to provide high performance and reliability, while keeping compatibility to the D-Bus reference implementation. It is exclusively written for linux systems, and makes use of many modern features provided by recent linux kernel releases. The main focus points of dbus-broker are reliability, scalability and security. The dbus-broker project tries to improve on these points over dbus-daemon, and thus provide a better alternative. And in-depth analysis can be found in the initial [https://dvdhrm.github.io/rethinking-the-dbus-message-bus/ announcement] of dbus-broker. An excerpt: * [https://github.com/bus1/dbus-broker/wiki/Accounting Accounting]: dbus-broker maintains per-user accounting, including inter-user quotas. This guarantees that no single user can cause irregularly high memory consumption in the daemon. Unlike dbus-broker, dbus-daemon accounts memory in a multi-tier system, based on plain resource counters on users, connections, and other resources. The multi-tier system suffers from resource-chaining-exhaustion, where clients effectively circumvent the accounting by creating multiple connections/objects, which themselves grant them each a new set of quotas. The [https://github.com/bus1/dbus-broker/wiki/Accounting single-tier accounting] scheme of dbus-broker avoids this, while at the same time adding inter-user quotas to prevent misuse even across clients. * [https://github.com/bus1/dbus-broker/wiki/Reliability Reliability]: While D-Bus is used on reliable transports, dbus-daemon might still silently drop messages and given circumstances. This is the only possible solution dbus-daemon has, given several of its runtime guarantees. The dbus-broker project changed the architecture of the bus daemon to a degree, that it can provide many [https://github.com/bus1/dbus-broker/wiki/Reliability guarantees], including that no message will be silently, or unexpectedly, dropped. * [https://github.com/bus1/dbus-broker/wiki/Scalability Scalability]: The message bus broker is a crucial infrastructure on modern linux system, which is a hot-path for almost all IPC going on. Hence, the broker should perform fast and be scalable to its users. dbus-daemon has several **global** data-structures that affect the overall scalability of independent message transactions. dbus-broker does not employ any global data-structures (unless required by the spec), as such any message transaction is only affected by the data provided by the involved peers. Moreover, even for spec-defined global behavior, dbus-broker avoids global data-structures, unless clients actually make use of these obscure features. In several other cases, dbus-daemon scales O(n) time looking up message targets and related data. dbus-broker runs all these in O(log(n)) time. * Linux-specific: The dbus-broker project was explicitly designed for linux system, making use of many linux-specific APIs and behavior. This allows mitigation of several possible DoS attacks. == Scope == * Proposal owners: ** Fix regressions. ** Enabledbus-broker.service in system and user-global context of systemd (via systemd presets). ** Pull in dbus-broker package from dbus package. * Other developers: ** Watch for regressions * Release engineering: [https://pagure.io/releng/issues/7262 #7262] ** List of deliverables: N/A * Policies and guidelines: No changes needed. * Trademark approval: No changes needed. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

3 3

fedpkg request-repo always fails - Could not execute request_repo
by Martin Gansser 13 Mar '18

13 Mar '18

Hi, tried to create a new repo, but this fails always with: [martin@f27 ~]$ fedpkg --module-name gnome-shell-extension-netspeed request-repo 1377631 Could not execute request_repo: The following error occurred while creating a new issue in Pagure: Invalid or expired token. Please visit https://pagure.io/ to get or renew your API token. already create a new API Token on [1] and migrate the API token described here [2] [1] https://pagure.io/ [2] https://fedoraproject.org/wiki/Changes/fedrepo-req-to-fedpkg#Migration any help ?

2 2

F28 System Wide Change: Replace glibc's libcrypt with libxcrypt
by Jan Kurik 12 Mar '18

12 Mar '18

= System Wide Change: Replace glibc's libcrypt with libxcrypt = https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Change owner(s): * Björn Esser <besser82 AT fedoraproject DOT org,> * Florian Weimer <fweimer AT redhat DOT com> There are plans to remove libcrypt from glibc, so we should have a replacement. == Detailed Description == Since there has been some discussion in the last time about removing libcrypt from glibc in some time and splitting it out into a separate project which can evolve quicker, Zack Weinberg and I put some work into libxcrypt to make it a basically suitable replacement. It comes with a set of extended interfaces pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and crypt_gensalt_ra. The crypt and gensalt functions are supporting all (except for Crypt16, which was used on Ultrix and Tru64, only) widely used password hashing algorithms, which before were specific to just some operating system's implementations of libcrypt. == Scope == * Proposal owners: - Apply needed packaging changes to glibc - Review, import and build libxcrypt for Fedora 28 * Other developers: Test their applications using one of the following interfaces for unexpected changes in functionality: - crypt() - crypt_r() - encrypt() - encrypt_r() - fcrypt() - setkey() - setkey_r() Release engineering: #7160 https://pagure.io/releng/issue/7160 none expected * Policies and guidelines: N/A (not needed for this 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

5 10

Escaping macros in %changelog
by Igor Gnatenko 11 Mar '18

11 Mar '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, It seems that a lot of people have %file, %check, %build, %whatsoever in their changelog section. Is there any reason I should not go and automatically escape them? %check → %%check %build → %%build %whatsoever → %%whatsoever There might be valid use-cases, but I'm not sure if they really are: %{_localstatedir}/ft/ → %%{_localstatedir}/ft/ Thoughts? - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp8dIIACgkQaVcUvRu8 X0zOaA//WIbQAPp0ZjyWEEVAOl3d0EsG6y2Pk38B2K2ubFY8SYzJzpaZdAv3Lkdz wJDA0rSdLrfNGRKzuEIpciGX03tCRSGENg6XeUT4mGjFPIsN467F0sC9RHkH5nWM 2H1weD4K1MeukqcvEWU8vJjyB+Wqd8qtFKGgpypp+d5jMh1ZOCeJbul4raRzQjGu mvIVI1Qvg9x/3ZdNKk1GQdBslVRZqq/r+QLubkFjq04abAW1E3Dr5rFnRN+fWhQ7 E56UcuWxuJk21JG6LxRjNeDCMvqwHMZ44So1MqxIxGTPVHlucustNTnJwVFSLMEm j7iPN4o9PxKew786Pm0/ggw6b49Y1w4ElzdFX6sfzQG4tAWu5Pa10paqUZyn/4IR RpqQhOyhXjqv1DxN5z+CGvgZNps/CtIXTE9HNG1Gs1bi3taX4tHOh8bpXVlj+ocw +03Q67LrgFVaqYaKfxW1jgfuvCRWUu3mdz16tx0W5ZuMkDgsq9H6ByYcVR8v/4Ly W+jL/H6kYzzviCu6k+hlOGccw9PKuhN9Iwg2wmQ100QiKIU58SKlb27YqlmRDVLz 12jl1R9qzLwR9A+yDbkQqxABPKNvOdY4RPOoqMKVGb0ZRuwMsVDLofVYpcnCBfIB wd8Rs9Kj36PxOO+HrHXKF05qRy2hOYiniS4XncmqPiFitd8GPQ4= =rcey -----END PGP SIGNATURE-----

32 62

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 2018