devel June 2017

devel@lists.stg.fedoraproject.org

192 participants
254 discussions

SELinux policy contibutions
by Robert Marcano 07 Oct '17

07 Oct '17

Greetings. Is https://github.com/fedora-selinux/selinux-policy-contrib the right place to contribute to the Fedora SELinux policy? I added a pull request for a small update needed for a new release of cups-pdf, but I am not sure someone is monitoring that. There is another one from rhatdan there so I presume is the right place.

5 5

Nonresponsive maintainer: attempting to contact kanarip
by James Hogarth 05 Sep '17

05 Sep '17

Hi, Has anyone heard from kanarip or able to contact him? I've been attempting to contact for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1223593 If there's no response in one week an issue will be filed with FESCo following the nonrepsonsive maintainer policy to review the ownership status of the packages. For ruby maintainers please note that this has a significant impact on you, if you want to keep track of this, as he owns puppet, rubygems and ruby ... https://admin.fedoraproject.org/pkgdb/packager/kanarip/ Regards, James

4 8

Non-responsive maintainer process for caillon, and retiring xchat
by Debarshi Ray 04 Sep '17

04 Sep '17

Hello everybody, I would like to initiate the non-responsive maintainer process [1] for Christopher Aillon [2]. A long time ago, he used to be part of the Fedora and Red Hat desktop teams. He is no longer around. He left software development and was last seen living off the grid in Hawaii [3]. Therefore I have jumped straight to the fourth step in the aforementioned process. Here is a list of his packages: https://admin.fedoraproject.org/pkgdb/packager/caillon/ I am particularly interested in xchat, which I want to retire right after removing Chris as the point of contact for his packages. HexChat [5] is the natural replacement of XChat these days. XChat is dead [6] - the last upstream release was seven years ago [7]. On the other hand, HexChat has been a part of Fedora for the last four years, upstream [4] is involved in both the Fedora [8] and GNOME communities, and I learnt that the MATE spin already ships it by default. For what it is worth, this was already discussed and approved on desktop(a)lists.fedoraproject.org [9]. Cheers, Rishi [1] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers [2] https://admin.fedoraproject.org/accounts/user/view/caillon [3] https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o… [4] https://admin.fedoraproject.org/pkgdb/package/rpms/xchat/ [5] https://hexchat.github.io/ [6] https://en.wikipedia.org/wiki/XChat [7] http://xchat.org/ [8] https://fedoraproject.org/wiki/User:Tingping [9] https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o…

3 6

PkgDB and the ArbitraryBranching Change
by Ralph Bean 20 Aug '17

20 Aug '17

Hello, As part of the Factory 2.0 and Modularity efforts[1], we’ve been developing a plan to migrate to an “arbitrary” branching model from our current model of one branch per release (as had been discussed at Flock and DevConf[2]). The main motivation behind this is to enable functionality required by Modularity[3] and to ultimately reduce some package maintenance burden. For some packages, it makes sense to have only a single branch that feeds into multiple releases. For other packages, it makes sense to have multiple branches which correlate with multiple upstream minor releases. Today, our source branches are tied to the distro release, via PkgDB. We want to decouple that and use modules to put it all back together again. To make this happen requires significant infrastructure changes. Our proposed plan[4] is to decommission PkgDB entirely and to replace it with a combination of PDC[5] and pagure over dist-git. (Tangentially, getting pagure over dist-git to play nicely with PkgDB was a challenge. This route gets us to a pull-request interface for spec files quicker.) We have brought this Change to FESCo[6][7][8] who expressed general agreement on the project but also concern that the community may be caught by off guard by the removal of PkgDB. As part of this change, we have proposed a timeline[9] that outlines the steps we plan to take to actually proceed with the migration. Please review that if you have time and provide feedback. We are most concerned with missing scripts/tools that may rely on PkgDB’s API. If you can think of any that we may have overlooked, please let us know and we will add it to the timeline! We are meeting again with FESCo next Friday, June 2nd, where a decision will be made on the Change. Any feedback before that would be greatly appreciated. Ralph and Matt, From the so-called Factory 2.0 team [1] https://fedoraproject.org/wiki/Infrastructure/Factory2 [2] https://youtu.be/5gqccjyjwFk?t=26m27s [3] https://docs.pagure.org/modularity/ [4] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranc… [5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter [6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching [7] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html [8] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html [9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org

15 27

F27 System Wide Change: perl Package to Install Core Modules
by Jan Kurik 16 Aug '17

16 Aug '17

= Proposed System Wide Change: perl Package to Install Core Modules = https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules Change owner(s): * Petr Písař <ppisar AT redhat DOT com> dnf install perl will install all core Perl modules that come with Perl upstream sources. == Detailed Description == Upstream releases Perl interpreter together many Perl modules. This set of modules is called core modules. Fedora splits the modules into subpackages so that installing perl package results in stripped-down set of modules. Fedora documents this as a feature and provides perl-core to metapackage that allows installing all the core modules as is intended by upstream. Unfortunately this seems to be confusing to Perl users because Fedora is the only distribution doing so. To align Fedora's behaviour to upstream and other distributions this change will rename perl package to perl-interpreter and perl-core package to perl'. This will allow installing all core Perl modules with dnf install perl while still retain the possibility to install only a minimal perl interpreter (/usr/bin/perl) with dnf install perl-interpreter. This change will also update Fedora Packaging Guidelines for Perl to all spec files that require perl to use perl-interpreter instead. There is only 81 binary packages affected. They will rebuilt. Otherwise no mass rebuild won't be necessary. To ease sharing spec files with older Fedoras, perl-interpreter provide will add to perl package there. == Scope == * Proposal owners: - Submit Fedora Packaging Guidelines for Perl update to Fedora Packaging Committee. - Update and rebuild perl source package. - Add Provides: perl-interpreter to perl package in older Fedoras. - Replace BuildRequires and Requires for perl with perl-interpreter in all spec files. - Rebuild packages with replaced Requires to propagate the change to repositories. - Replace perl-core with perl in compose groups definition. * Other developers: Get familiar with new Fedora Packaging Guidelines for Perl. * Release engineering: No action needed. Request to check of an impact with Release Engineering: https://pagure.io/releng/issue/6842 * List of deliverables: Anything what contains perl package * Policies and guidelines: Fedora Packaging Guidelines for Perl update request ( https://pagure.io/packaging-committee/issue/690 ) to use perl and perl-interpreter instead of perl-core and perl. 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

14 22

Two more concrete ideas for what a once-yearly+update schedule would look like
by Matthew Miller 03 Aug '17

03 Aug '17

Trying to make this idea a little more concrete. Here's two suggestions for how it might work. These are strawman ideas -- please provide alternates, poke holes, etc. And particularly from a QA and rel-eng point of view. Both of these are not taking modularity into account in any way; it's "how we could do this with our current distro-building process". Option 1: Big batched update 1. Release F26 according to schedule https://fedoraproject.org/wiki/Releases/26/Schedule 2. At the beginning of October, stop pushing non-security updates from updates-testing to updates 3. Bigger updates (desktop environment refreshes, etc.) allowed into updates-testing at this time. 4. Mid-October, freeze exceptions for getting into updates-testing even. 5. Test all of that together in Some Handwavy Way for serious problems and regressions. 6. Once all good, push from updates-testing to updates at end of October or beginning of November. Option 2: Branching! 1. Release F26 according to schedule. 2. July/August: branch F26.1 from F26 (not rawhide) 3. Updates to F26 also go into F26.1 (magic happens here?) 4. No Alpha, but do "Beta" freeze and validation as normal for release. 5. And same for F26.1 final 6. And sometime in October/November, release that (but without big press push). 7. GNOME Software presents F26.1 as upgrade option 8. F26 continues in parallel through December 9. In January, update added to F26 which activates the F26.1 repo. 10. And also in January updates stop going to F26. Some of this idea, by the way, is reminiscent of Spot's suggestions at FUDCon Lawrence in 2013. This is not completely coincidence - I always liked those ideas! -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

39 150

F27 Self Contained Change: Samba AD
by Jan Kurik 28 Jul '17

28 Jul '17

= Proposed Self Contained Change: Samba AD = https://fedoraproject.org/wiki/Changes/Samba_AD Change owner(s): * Alexander Bokovoy <abokovoy AT redhat DOT com> * Andreas Schneider <asn AT redhat DOT com> Samba AD is an open source implementation of an Active Directory set of tools and protocols. It allows Windows clients to be enrolled and managed using native Windows tools. In addition, Samba AD can serve as a domain controller for Fedora workstations and servers utilizing DCERPC, LDAP and Kerberos. == Detailed Description == Samba AD is an implementation of an Active Directory set of tools and protocols. It is developed and released as part of Samba suite. Upcoming Samba 4.7 release will contain changes to allow Samba AD to be built and used with MIT Kerberos. Prior to Samba 4.7 it was impossible to compile Samba AD with MIT Kerberos. As result, Samba AD was not packaged in Fedora. == Scope == * Proposal owners: Samba packages in Fedora already include a stub subpackage samba-dc that is going to be replaced with a full Samba AD implementation. Appropriate dependencies are already present in Fedora 27/Rawhide or will be added together with Samba 4.7 update. This mostly concerns upgrade of Samba-related libraries: libtevent, libldb, libtdb, and MIT Kerberos update to support new APIs added to accommodate Samba AD (already in Rawhide). * Other developers: N/A (not a System Wide Change) * Release engineering: - https://pagure.io/releng/issue/6869 - We believe no impact to Release Engineering is needed for this change * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide 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

4 12

rpm debuginfo improvements for rawhide/f27
by Mark Wielaard 26 Jul '17

26 Jul '17

Hi packagers, rawhide rpmbuild contains various debuginfo improvements that hopefully will make various hacks in spec files redundant. If you have your own way of handling debuginfo packages, calling find-debuginfo.sh directly, need hacks for working around debugedit limitations or split your debuginfo package by hand then please try out rpmbuild in rawhide and read below for some macros you can set to tweak debuginfo package generation. If you still need hacks in your spec file because setting macros isn't enough to get the debuginfo packages you want then please let us know. Also please let us know about packages that need to set debuginfo rpm macros to non-default values because they would crash and burn with the default settings (best to file a bug against rpmbuild). The improvements have been mainly driven by the following two change proposals for f27 (some inspired by what other distros do): https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo The first is completely done and has been enabled by default for some months now in rawhide. The second introduces two new macros to enable separate debugsource and sub-debuginfo packages, but has not been enabled by default yet. If people like the change and no bugs are found (and fesco and releng agree) we can enable them for the f27 mass rebuild. If your package already splits debuginfo packages in a (common) source package and/or sub-debuginfo packages, please try out the new macros introduced by the second change. You can enable the standard splitting by adding the following to your spec file: %global _debugsource_packages 1 %global _debuginfo_subpackages 1 Besides the above two changes debuginfo packages can now (and are by default in rawhide) build by running debug extraction in parallel. This should speed up building with lots of binaries/libraries. If you do invoke find-debuginfo.sh by hand you most likely will want to add %{?_smp_mflags} as argument to get the parallel processing speedup. If your package is invoking find-debuginfo.sh by hand also please take a look at all the new options that have been added. Also note that almost all options can be changed by setting (or undefining) rpm macros now. Using the rpm macros is preferred over invoking find-debuginfo.sh directly since it means you get any defaults and improvements that might need new find-debuginfo.sh arguments automatically. Here is an overview of various debuginfo rpm macros that you can define undefine in your spec file with the latest rpmbuild: # # Should an ELF file processed by find-debuginfo.sh having no build ID # terminate a build? This is left undefined to disable it and defined to # enable. # %_missing_build_ids_terminate_build 1 # # Include minimal debug information in build binaries. # Requires _enable_debug_packages. # %_include_minidebuginfo 1 # # Include a .gdb_index section in the .debug files. # Requires _enable_debug_packages and gdb-add-index installed. # %_include_gdb_index 1 # # Defines how and if build_id links are generated for ELF files. # The following settings are supported: # # - none # No build_id links are generated. # # - alldebug # build_id links are generated only when the __debug_package global is # defined. This will generate build_id links in the -debuginfo package # for both the main file as /usr/lib/debug/.build-id/xx/yyy and for # the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug. # This is the old style build_id links as generated by the original # find-debuginfo.sh script. # # - separate # build_id links are generate for all binary packages. If this is a # main package (the __debug_package global isn't set) then the # build_id link is generated as /usr/lib/.build-id/xx/yyy. If this is # a -debuginfo package (the __debug_package global is set) then the # build_id link is generated as /usr/lib/debug/.build-id/xx/yyy. # # - compat # Same as for "separate" but if the __debug_package global is set then # the -debuginfo package will have a compatibility link for the main # ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy %_build_id_links compat # Whether build-ids should be made unique between package version/releases # when generating debuginfo packages. If set to 1 this will pass # --build-id-seed "%{VERSION}-%{RELEASE}" to find-debuginfo.sh which will # pass it onto debugedit --build-id-seed to be used to prime the build-id # note hash. %_unique_build_ids 1 # Do not recompute build-ids but keep whatever is in the ELF file already. # Cannot be used together with _unique_build_ids (which forces recomputation). # Defaults to undefined (unset). #%_no_recompute_build_ids 1 # Whether .debug files should be made unique between package version, # release and architecture. If set to 1 this will pass # --unique-debug-suffix "-%{VERSION}-%{RELEASE}.%{_arch} find-debuginfo.sh # to create debuginfo files which end in -<ver>-<rel>.<arch>.debug # Requires _unique_build_ids. %_unique_debug_names 1 # Whether the /usr/debug/src/<package> directories should be unique between # package version, release and architecture. If set to 1 this will pass # --unique-debug-src-base "%{name}-%{VERSION}-%{RELEASE}.%{_arch}" to # find-debuginfo.sh to name the directory under /usr/debug/src as # <name>-<ver>-<rel>.<arch>. %_unique_debug_srcs 1 # Whether rpm should put debug source files into its own subpackage #%_debugsource_packages 1 # Whether rpm should create extra debuginfo packages for each subpackage #%_debuginfo_subpackages 1 # Number of debugging information entries (DIEs) above which # dwz will stop considering file for multifile optimizations # and enter a low memory mode, in which it will optimize # in about half the memory needed otherwise. %_dwz_low_mem_die_limit 10000000 # Number of DIEs above which dwz will stop processing # a file altogether. %_dwz_max_die_limit 50000000 %_find_debuginfo_dwz_opts --run-dwz\\\ --dwz-low-mem-die-limit %{_dwz_low_mem_die_limit}\\\ --dwz-max-die-limit %{_dwz_max_die_limit} If there are settings missing that would be useful, bugs with the default settings or defaults that should be changed please do file a bug report. Thanks, Mark

4 11

Self Intro: Tomofumi Hayashi
by Tomofumi Hayashi 18 Jul '17

18 Jul '17

Hi, This is intro email as a new packager to Fedora. I am Tomofumi Hayashi and live in Tokyo, Japan. I have contributed OpenStack and OPNFV. I am developing koko (container connector), which makes connection between containers with veth or with vxlan interface. https://github.com/redhat-nfvpe/koko Now I create RPM package for it and want to bring it to Fedora. Hence I am seeking a sponsor for this package. https://bugzilla.redhat.com/show_bug.cgi?id=1463492 I am looking forward to contribute Fedora more! Regards, Tomofumi Hayashi

2 3

Intel i915 firmwares
by Chris Murphy 10 Jul '17

10 Jul '17

I ran into this today: https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57 DRM firmware is loaded by default. HuC and GuC are not. Things work without them, and things work with them loaded. So what's the pro/con and if there's a pro, why isn't it the kernel default? Seems like if it should be default, either upstream should set them as the default, or the CPU/GPU should ask for it? Recently (either 4.10/4.11 kernel, or same time frame Firefox on F25/F26) I notice a blocky flickering when Firefox is launched. This doesn't happen with the firmware loaded. So that's nice I guess, but doesn't seem critical. Anyway, just curious. -- Chris Murphy

9 11

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