Help with an s390x build failure
by Jerry James
Are there any test s390x instances available for a peon like me to use
to diagnose a build failure? Failing that, does anybody with access
to an s390x instance have time to help me? The latest bigloo release
built successfully on all arches but s390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=20740401
The failure comes after the main binary has been built and linked
successfully, but then is executed to compile some Scheme files. The
binary is reporting that it was invoked on an empty input file.
Thank you,
--
Jerry James
http://www.jamezone.org/
6 years, 8 months
Elections July/August 2017 to FESCo, Council, FAmSCo - Nomination
period is now open
by Jan Kurik
Greetings,
FESCo, Council and FAmSCo elections are now open and we're looking for
new candidates: https://fedoraproject.org/wiki/Elections
If you are interested in these roles, please add yourself to the lists
of nominees before 23:59:59 UTC on July 31st, 2017! If you wish to
nominate someone else, please consult with that person ahead of time.
If you know someone who would be a good candidate, now is a great time
to make sure they're thinking about it.
For FESCo we have opened 4 seats:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
For Council we have opened 1 seat:
https://fedoraproject.org/wiki/Council/Nominations
For FAmSCo we have opened 3 seats:
https://fedoraproject.org/wiki/FAmSCo_nominations
The Elections schedule is as follows:
* July 25 - July 31: Nomination period
* August 01 - August 07: Campaign period.
* August 08 - August 14: Voting Open
* August 15: Results announcement
Elections Questionnaire needs more questions for email/Community blog
interviews! If you have anything you would like to ask candidates to
FESCo, FAmSCo or to Council, please add it to the wiki.
http://fedoraproject.org/wiki/Elections/Questionnaire
Read more about the FESCo, FAMSCo ans Council at:
http://fedoraproject.org/wiki/Development/SteeringCommittee
https://fedoraproject.org/wiki/Fedora_Ambassadors_Steering_Committee
http://fedoraproject.org/wiki/Council
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 8 months
rpm debuginfo improvements for rawhide/f27
by Mark Wielaard
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
6 years, 8 months
FLOCK UPDATE - funding, tickets, and more
by Brian Exelbierd
This email is being sent to devel@, flock-planning@, and
flock-attendees-2017@ for visibility. I apologize if you receive it
multiple times.
# Action Required: Read below carefully to determine if you need to take
an action
## Registration
We will be placing final food orders and other attendee count related
items this week and next week. If you haven't registered yet, please do
so.
Unregistered people and unpaid and unfunded registrations as of Friday
July 27 may not be included in the counts for lunch, etc.
Registration will remain open for pre-printed badges and other items for
a while longer.
## Flock Attendees Mailing List Opened
The flock attendees mailing list has been available for some time.
However, today we mass-subscribed everyone who is registered for Flock.
Feel free to add yourself if you were missed or to modify your
subscription as needed. Future announcements for attendees may only be
sent to this list, so we encourage you to stay subscribed.
https://lists.fedoraproject.org/archives/list/flock-attendees-2017@lists....
## Hotel Rooms
Hotel room reservations at the Flock negotiated prices are still
available. These prices are not guaranteed after August 4th so you are
encouraged to book now.
## Flock Travel Funding
Flock travel funding is now exhausted. If you have not received an
offer or a notice that no funding is available, please email
flock-staff(a)fedoraproject.org.
If you have a funding offer you have not responded too, please respond
ASAP. The money to fund this is rapidly being reallocated to other cost
overruns. Offers will still be offerred, but need to be taken advantage
of quickly.
### Travel Planning
If you are a funded traveler you should have already received
information about your airfare, hotel, and bus transportation. If you
have not received details, please contact flock-staff.
Please note that the hotel has not yet sent their hotel confirmations,
those are still in progress.
Please note that bus tickets have not been issued, but details are being
confirmed now.
## Flock Schedule
The sched.org site has been set up but the schedule is not yet loaded.
We hope to load the schedule next week.
https://flock2017.sched.com/
regards,
Flock Committees and Planners
6 years, 8 months
Fedora, apps, and the Flatpak opportunity
by Matthew Miller
Containers (and particularly, Docker-style containers with Kubernetes
orchestration) are rapidly taking over the server world. This is not
hyperbole, and while one might fairly throw "everything old is new
again", it's not a fad. This is a real generational shift.
We're at the forefront of this with Fedora Atomic Host (and OpenShift
Origin in Fedora as well). This is awesome.
I think these technologies are going to come to the desktop, too. Maybe
not Kubernetes for a while (although that certainly presents an
interesting picture of a hybrid-cloud-powered future), but certainly
container tech in some form — maybe it's an iteration of Jessie
Frazelle's Docker on the Desktop, maybe it's Snappy, maybe it's
Flatpak. I think Flatpak is a good bet, because I trust Alexander
Larsson's expertise in this space — and because it's aligned with OCI,
the Open Container Initiative. (Plus, using Docker inherently hacky,
and until Snappy gets the ability to use something other than an Ubuntu
binary runtime, it's a non-starter.)
In any case, I'm definitely interested in seeing the experiment.
Ever since Fedora started, we've had several somewhat-competing key
activities — making an awesome out-of-the-box operating system (in
whatever flavors), _and_ in packaging up a universe of useful
applications and tools for users. I know *I* love that when I install
Fedora, I can install a graphics editor or an alternate terminal
program or whatever without going out to a web search and hoping
whatever I come back with isn't sketchy.
We can definitely keep doing this as RPMs. That's fine; it's working,
and we're good at it. There's some pain, but we mostly know how to deal
with that pain. We also have a huge opportunity here to take that
accumulated wealth of packaged software and the expertise encoded in
that packaging and turn it into a trove of Flatpak applications. This
would bring the benefits of
* safe online updates
* a sandboxing model
* ability to mix and match versions and streams
* a sane way to install apps on Fedora Atomic Workstation
to Fedora users — but, also, it would immediately expand the reach and
impact of our work to users on other distros, where suddenly
Fedora-created packages run seamlessly. For graphical applications, the
work we do will immediately be multiplied in user impact. This is a
huge win with minimal effort on the part of packagers, once the planned
automation is all in place.
Is this a plan for expanding Fedora domination? Yes — but I think
it's a pretty friendly one. Let's share our awesome work with more
people!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 8 months
Summary/Minutes from today's FESCo Meeting (2017-07-21)
by Adam Miller
On Fri, Jul 21, 2017 at 8:26 AM, Adam Miller
<maxamillion(a)fedoraproject.org> wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
> irc.freenode.net.
>
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/UTCHowto
>
> or run:
> date -d '2017-07-21 16:00 UTC'
>
>
> Links to all issues below can be found at:
> https://pagure.io/fesco/report/meeting_agenda
>
> = Followups =
>
> #topic #1741 - F27 System Wide Change: Graphical Applications as Flatpaks
> .fesco 1741
> https://pagure.io/fesco/issue/1741
>
> = New business =
>
> #topic #1736 - Don't automatically close security bugs on Fedora EOL
> .fesco 1736
> https://pagure.io/fesco/issue/1736
>
> #topic #1737 - Proposal: i686 SIG needs to be functional by F27
> release date or we drop i686 kernel from F28
> .fesco 1737
> https://pagure.io/fesco/issue/1737
>
> #topic #1748 - F27 System Wide Change: No More i686 Kernels
> .fesco 1748
> https://pagure.io/fesco/issue/1748
>
> #topic #1743 - F27 System Wide Change: NSS Default File Format SQL
> .fesco 1743
> https://pagure.io/fesco/issue/1743
>
> #topic #1744 - F27 System Wide Change: NSS signtool deprecation
> .fesco 1744
> https://pagure.io/fesco/issue/1744
>
> #topic #1745 - F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
> .fesco 1745
> https://pagure.io/fesco/issue/1745
>
> #topic #1746 - F27 System Wide Change: Reduce Initial Setup Redundancy
> .fesco 1746
> https://pagure.io/fesco/issue/1746
>
> #topic #1747 - F27 System Wide Change: RPM 4.14
> .fesco 1747
> https://pagure.io/fesco/issue/1747
>
> #topic #1749 - F27 Self Contained Change: VirtualBox Guest Integration
> .fesco 1749
> https://pagure.io/fesco/issue/1749
>
> #topic #1750 - Decide if EOL is one month after release, four weeks,
> or something else
> .fesco 1750
> https://pagure.io/fesco/issue/1750
>
> = Open Floor =
>
> For more complete details, please visit each individual
> issue. The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
>
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, 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.
===================================
#fedora-meeting: FESCO (2017-07-21)
===================================
Meeting started by maxamillion at 16:00:04 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2017-07-21/fesco.2017-07...
.
Meeting summary
---------------
* init process (maxamillion, 16:00:07)
* Follow Ups (maxamillion, 16:04:04)
* #1741 - F27 System Wide Change: Graphical Applications as Flatpaks
(maxamillion, 16:04:04)
* LINK: https://pagure.io/fesco/issue/1741 (maxamillion, 16:04:10)
* LINK:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
(jforbes, 16:11:21)
* AGREED: - APPROVED: F27 System Wide Change: Graphical Applications
as Flatpaks (+1:6, +0:0, -1:0) (Includes a +1 in ticket from absense
FESCo member) (maxamillion, 16:34:38)
* New Business (maxamillion, 16:34:50)
* #1736 - Don't automatically close security bugs on Fedora EOL
(maxamillion, 16:34:50)
* LINK: https://pagure.io/fesco/issue/1736 (maxamillion, 16:34:51)
* AGREED: wait another week, ask for input from program manager and
what work needs to be done with EOL scripts (+1:5, +0:0, -1:0)
(maxamillion, 16:46:27)
* #1737 - Proposal: i686 SIG needs to be functional by F27 release date
or we drop i686 kernel from F28 (maxamillion, 16:46:42)
* LINK: https://pagure.io/fesco/issue/1737 (maxamillion, 16:46:47)
* #1748 - F27 System Wide Change: No More i686 Kernels (maxamillion,
16:46:52)
* LINK: https://pagure.io/fesco/issue/1748 (maxamillion, 16:46:53)
* #1737 - Proposal: i686 SIG needs to be functional by F27 release date
or we drop i686 kernel from F28 (maxamillion, 16:49:18)
* LINK: https://pagure.io/fesco/issue/1737 (maxamillion, 16:49:23)
* AGREED: Proposal: Request criteria for what a "functional SIG" means
in a measurable way (+1:5, +0:0, -1:0) (maxamillion, 17:02:57)
* #1748 - F27 System Wide Change: No More i686 Kernels (maxamillion,
17:03:11)
* LINK: https://pagure.io/fesco/issue/1748 (maxamillion, 17:03:12)
* AGREED: Proposal: postpone #1748 to F28 pending the outcome of #1737
(+1:5, +0:0, -1:0) (maxamillion, 17:08:01)
* #1743 - F27 System Wide Change: NSS Default File Format SQL
(maxamillion, 17:08:12)
* LINK: https://pagure.io/fesco/issue/1743 (maxamillion, 17:08:12)
* AGREED: F27 System Wide Change: NSS Default File Format SQL (+1:5,
+0:0, -1:0) (maxamillion, 17:15:22)
* #1744 - F27 System Wide Change: NSS signtool deprecation
(maxamillion, 17:15:40)
* LINK: https://pagure.io/fesco/issue/1744 (maxamillion, 17:15:41)
* We will revisit this next week as we just lost FESCo Quorum and will
only cover tickets with votes in ticket by absent FESCo members for
the duration of the meeting (maxamillion, 17:28:57)
* #1746 - F27 System Wide Change: Reduce Initial Setup Redundancy
(maxamillion, 17:30:02)
* LINK: https://pagure.io/fesco/issue/1746 (maxamillion, 17:30:03)
* AGREED: APPROVED: F27 System Wide Change: Reduce Initial Setup
Redundancy (+1:5, +0:0, -1:0) (Including a +1 vote from the ticket)
(maxamillion, 17:42:07)
* #1747 - F27 System Wide Change: RPM 4.14 (maxamillion, 17:42:18)
* LINK: https://pagure.io/fesco/issue/1747 (maxamillion, 17:42:18)
* AGREED: APPROVED: F27 System Wide Change: RPM 4.14 (+1:5, +0:0,
-1:0) (Including a +1 vote from the ticket) (maxamillion, 17:52:45)
* Next week's chair (maxamillion, 17:53:04)
* jsmith volunteered last week to chair next week's meeting
(maxamillion, 17:53:05)
* Open Floor (maxamillion, 17:53:18)
*
https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_li...
(maxamillion, 18:00:12)
* AGREED: APPROVED: Packaging Rust applications and libraries
(packaging guidelines (+1:5, +0:0, -1:0) (maxamillion, 18:06:26)
* maxamillion won't be at FESCo meeting next week (maxamillion,
18:08:51)
Meeting ended at 18:10:02 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* maxamillion (150)
* Rathann (81)
* ignatenkobrain (45)
* kalev (38)
* jforbes (35)
* nirik (32)
* puiterwijk (22)
* zodbot (22)
* mclasen (16)
* otaylor_ (14)
* sgallagh (8)
* smooge (6)
* jwb (0)
* jsmith (0)
* dgilmore (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
6 years, 8 months
