devel June 2016

devel@lists.fedoraproject.org

220 participants
287 discussions

EMEA Sponsorship Program for Flock
by Giannis Konstantinidis 05 Jul '16

05 Jul '16

Hello everyone, in the past we have had a tradition of sponsoring EMEA contributors that would like to attend Flock[0] but are not going to receive funding as speakers. The allocated budget for this year was only $800, initially. The adjusted budget is even less. As we wish to assist as many contributors in need as possible, we are going to try and raise that budget. However, no promises made at this point. This program is intended for contributors that currently reside in EMEA. Other regions may feel free to come up with similar programs for their contributors as they see fit. Priority will be given to contributors that have recently maintained a record of activity and also have some kind of work agenda for the conference (e.g. meet with fellow contributors, actively contribute on site). In any case, the budget we are going to end up with will be limited. Most likely we will be able to offer only -partial- subsidies. Do not apply if you are not okay with that. If you are able to receive funding from other sources (e.g. your employer), please do so. To request for sponsorship, file a ticket on the EMEA Trac[1], state the reason(s) for applying and what you expect to accomplish by attending the conference. Deadline should be July 5, 23:59:59 UTC +0. All tickets will be later evaluated by FAmSCo, same as last time. We will get back to you once we have more information regarding the budget. Please spread the news to your fellow Fedorians. Thank you and good luck! -Giannis [0] https://flocktofedora.org/ [1] https://fedorahosted.org/emea-swag-tracking/ -- Giannis Konstantinidis giannis(a)konstantinidis.cc http://konstantinidis.cc giannisk on irc.freenode.net

1 1

Maintainer preferred method of blocker bug notification?
by Chris Murphy 04 Jul '16

04 Jul '16

Hi, At a recent QA meeting I raised the idea of a better way for maintainers to find out when their package is a release blocking bug. Better is vaguely defined by me as: not email based, and not adamw based (Adam Williamson is in fact a person not a bot). Currently, the ways a maintainer finds out a bug is release blocking: 1. Bugzilla email. When QA determines a bug is a blocker, it's noted in the bug as a comment, and bugzilla emails (most) everyone on the cc. The problem with email is self-explanatory. If the bugzilla notification email isn't being registered in a useful way, probably more emails won't help either. 2. The very nifty Fedora Blocker Bug Tracking app https://qa.fedoraproject.org/blockerbugs/ The problem with this is, it's passive. You need to check it. So it's mainly used by QA folks to get a bird's eye view of the status of blocker bugs, and freeze exceptions. 3. The illustrious, humorous, verbose, would have been cloned by now were it affordable and timely enough, adamw, who sends out an email summary of blocking bugs to devel@. Problem, more email. 4. Adamw (or less often another human within QA) takes it upon themselves to inquire via IRC. These are effective. Unknown is if slips would have resulted if they didn't happen. But it seems at least plausible that it would increase slips without this form of nagging (reminding). The problem is, I think it's inappropriate for any one person to have to nag other people about their bugs. It's also tedious and manual. The time and interest for any QA person to do this is low. The questions then, are: - Have we reached the pinnacle notification method of blocker bugs to maintainers? Or is there a better way to do this? - Would it help to have a nagbot (or enhance zodbot) to ping maintainers on IRC? Is the nagbot more or less likely to be ignored, or would it be about the same? Of course there are lower level questions about whether it's possible, what work it entails, would it be opt in or opt out, could notifications happen outside IRC, but for now I think the "in general" high level context is more useful. -- Chris Murphy

3 3

Injecting perl-devel and perl-generators build-requires
by Petr Pisar 04 Jul '16

04 Jul '16

Hello, per Build Root Without Perl Fedora 25 change <https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl>, I'm ready to implement the most visible part of this change. I'm going to inject perl-devel and perl-generators build-requires into Fedora specification files tomorrow. That's necessary not to break building the packages when Perl will have been removed from the build root. There are 3292 packages that should build-require perl-generators, there are 491 packages that should build-require perl-devel. Some of them already contain the dependency. There are 3129 packages that miss one of them and they will be edited. The edit will consist of one commit with this commit message: Mandatory Perl build-requires added <https://fedoraproject.org/wiki/Changes/Build_Root_Without_Perl> The commit will add: BuildRequires: perl-devel or BuildRequires: perl-generators or both into a spec file. There will be no revision bump, no RPM changelog entry, no rebuild in the Koji. I expect pulling the source repositories, commiting the changes and pushing them back to the dist-git will take at least 2 hours. Package maintainers and people with watch-commit role will receive an e-mail notification about the commit as usually. Thank you for your understanding. -- Petr

11 18

[OT] Tim, Gil, et. al. (e-mail address settings)
by Joel Rees 02 Jul '16

02 Jul '16

To keep this off-list as much as possible, the rant is here: http://reiisi.blogspot.com/2016/07/to-gil-tim-fedora-et-al.html (The blame lies elsewhere. I wish I had the network and social cred to get a real movement started, away from the current faceless CA system and towards a different identity assurance system that depends on actual, existing day-to-day trust relationships.)

12 14

multi-CPU optimization inside a distribution
by Dan Horák 02 Jul '16

02 Jul '16

Hi all, we were talking about this item for some time, so let's start a thread for it to have the discussion and hopefully also a solution documented. This is meant as discussion initiation based on the situation in Fedora on POWER. I would like to ask the bigger experts than me to fill the missing details and options. Currently we set a minimal CPU level for an architecture (or use the toolchain default) on the distribution level (/usr/lib/rpm/redhat/rpmpc owned by redhat-rpm-config [1]). It allows the distro to run on such CPU and any newer evolution of it (omitting any kernel or hw issues), but it also means it doesn't generally take advantage of features and improvements in the newer CPUs. For ppc64 (the big endian POWER) the base is set by the toolchain default which is Power4/ppc970. When Power7 came we were asked what are the options to take the advantage of these CPUs, 3 generations newer than the base. The solution was the introduction of ppc64p7 subarch into the packaging and release engineering tools. But it showed more as a hack than a solution, touching rpm, yum, koji, .... The list of packages is manually maintained, requires manual updates to the buildsystem for new releases, seems new packaging tools (dnf) don't understand it correctly. Is there a way to make the subarch mechanism generic and integrated with the other tools? So we could have ppc64p8 and ppc64p9 inside Fedora for POWER ... Now I'm getting to an area where others are the experts :-) Glibc allows to build and install multiple per-cpu optimized runtimes that are selected based on the CPU. There is the IFUNC mechanism and function multi-versioning in GCC (user-friendly IFUNC) [2] to allow multiple implementations inside one library/binary. Some packages do the CPU detection during runtime and select the optimized functions themselves. There is also an option to introduce a "tertiary architecture" and rebuild everything for the new CPU, but keeping the rpm arch the same. But it has its own costs too. What do you think? Are there any recommendations for both the distro and package maintainers and upstream developers? I suppose even primary architectures are facing the same problem. [1] http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/tree/rpmrc [2] https://lwn.net/Articles/691932/ Dan

8 16

autoconf test for deprecated readdir_r
by Kaleb S. KEITHLEY 02 Jul '16

02 Jul '16

Hi, Does anyone have a good/working autoconf test for checking for deprecated readdir_r (for Fedora 25) ? I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other things.) Alternatively it would be nice if there was a some kind of feature test define in dirent.h. Thanks, -- Kaleb

5 4

Anyone know how to contact maintainer Salimma?
by Avram Lubkin 02 Jul '16

02 Jul '16

I've been trying to contact Salimma, Michel Alexandre Salim, for the last month. I've been trying to update python-sphinx which hasn't had an update since last fall. Worked through all of the issues, but maintainer hasn't responded to commit request, email, or bug reports. Bug report for newest version of Sphinx with needinfo flag. https://bugzilla.redhat.com/show_bug.cgi?id=1323202 Anyone have any info? Thanks

3 3

About dnf failing to honore conditional level in comps.xml
by Luya Tshimbalanga 01 Jul '16

01 Jul '16

dnf has issues at honoring conditional levels written on comps.xml. As a result, some packages will not be installed by either anaconda or livemedia build system. I have already submitted a bug report on the subject [1] but it was too deep to fix for Fedora 24. By the time of applying the workaround, the freeze was in the process and the suggested change to manually update the kickstart and some comps.xml came too late. That was the case with Design Suite and surprisingly other groups. Currently, the document from fedora-comps[2] fails to take account that problem caused by dnf. Now the focus is for Fedora 25, will be fix come in time so such problem will not occur again? Reference -------------- [1] https://bugzilla.redhat.com/show_bug.cgi?id=1336879 [2] https://pagure.io/fedora-comps -- Luya Tshimbalanga Graphic & Web Designer E: luya(a)fedoraproject.org W: http://www.coolest-storm.net

2 2

Looking for a proven packager
by Mattias Ellert 01 Jul '16

01 Jul '16

Hi! I submitted a bugzilla report with a patch that implements an improvement of the hadoop package in Fedora, extending the current incomplete Fedora integration patch that only supports ix86 and x86_64 to more architectures. The maintainer is unwilling to apply it, but says that if a proven packager would apply it he would be extatic. https://bugzilla.redhat.com/show_bug.cgi?id=1328076 Since I am not a proven packager myself, I am looking for one that can perform this task. Mattias

5 6

Updated hdf5, netcdf, libdap coming to rawhide tomorrow
by Orion Poplawski 30 Jun '16

30 Jun '16

I'll be updating hdf5, netcdf, and libdap in rawhide tomorrow and doing rebuilds of dependent packages. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 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 June 2016