armv7hl builds running out of memory
by Kaleb S. KEITHLEY
trying to build ceph-12 on f27 armv7hl.
It builds on everything x86_64, aarch64, s390x, and i686 (w/o java), but
on armv7hl the build fails, reporting out of memory.
...
[100%] Built target ceph-osd
cc1plus: out of memory allocating 11284160 bytes after a total of
58859520 bytes
make[2]: *** [src/CMakeFiles/ceph-dencoder.dir/build.make:64:
src/CMakeFiles/ceph-dencoder.dir/test/encoding/ceph_dencoder.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1626:
src/CMakeFiles/ceph-dencoder.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
...
full log at
https://kojipkgs.fedoraproject.org//work/tasks/4038/20724038/build.log
Is there any way to bump up swap on the builders? Or any trick to get
more memory or run on a particular machine that has more memory?
Thanks
--
Kaleb
6 years, 9 months
Recompiling/relinking dependent applications/libraries on DSO change
by Florian Weimer
binutils 2.29 introduced an optimization which requires that in the
general case, applications and libraries linking against a DSO will have
to be rebuilt when the DSO change the implementation of functions (i.e.,
changes to a function body can change ABI). This is how many native
programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
but it's a material change for C and C++.
The question is: Do we want to move into that direction, or do we need
to ask binutils upstream to back out this change?
Thanks,
Florian
6 years, 9 months
ppc64le build failure, does it look familiar?
by Kaleb S. KEITHLEY
More ceph-12.1.1
This has built successfully previously, including the recent mass
rebuild. Today the other associated builds have either finished or
passed this point, but on the ppc64le build today I got this:
...
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb
--target ppc64le --nodeps /builddir/build/SPECS/ceph.spec'] with env
{'SHELL': '/bin/bash', 'PROMPT_COMMAND': 'printf
"\\033]0;<mock-chroot>\\007"', 'HOME': '/builddir', 'HOSTNAME': 'mock',
'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8', 'TERM':
'vt100', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'} and shell False
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/lua: error loading module 'posix.ctype' from file
'/usr/lib64/lua/5.3/posix.so':
/lib64/librt.so.1: expected localentry:0 `pthread_attr_setdetachstate'
stack traceback:
[C]: in ?
[C]: in function 'require'
/usr/share/lua/5.3/posix/init.lua:29: in main chunk
[C]: in function 'require'
/usr/share/lmod/lmod/libexec/addto:64: in main chunk
[C]: in ?
/usr/bin/ps: error while loading shared libraries: /lib64/librt.so.1:
expected localentry:0 `pthread_attr_setdetachstate'
/usr/bin/basename: missing operand
Try '/usr/bin/basename --help' for more information.
Building target platforms: ppc64le
...
Full build log at
https://kojipkgs.fedoraproject.org//work/tasks/6424/20856424/build.log
Look familiar to anyone?
Thanks,
--
Kaleb
6 years, 9 months
Summary/Minutes from today's FESCo Meeting (2017-07-28)
by Jared K. Smith
We had a short meeting today because we lost quorum part-way through
the meeting.
===================================
#fedora-meeting: FESCO (2017-07-28)
===================================
Meeting started by jsmith at 16:01:24 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting/2017-07-28/fesco.2017-...
.
Meeting summary
---------------
* init process (jsmith, 16:01:25)
* Follow-ups (jsmith, 16:13:28)
* #1736 - Don't automatically close security bugs on Fedora EOL
(jsmith, 16:13:28)
* LINK: https://pagure.io/fesco/issue/1736 (jsmith, 16:13:28)
* AGREED: #1736 Enumerate various ideas i nthe ticket and on the list,
and revist next week (+1:5, +0:0, -1:0) (jsmith, 16:23:25)
* #1737 - Proposal: i686 SIG needs to be functional by F27 release date
(jsmith, 16:23:41)
* LINK: https://pagure.io/fesco/issue/1737 (jsmith, 16:23:41)
* AGREED: #1737 Defer to next week due to lack of quorum. (jsmith,
16:39:06)
* Next week's chair (jsmith, 16:41:29)
* Election reminder (jsmith, 16:43:04)
* 16:43 < jsmith> Just a reminder of the upcoming elections -- do you
part -- nominate yourself or a friend, and participate in the
elections. (dgilmore, 16:43:57)
* Open Floor (jsmith, 16:44:15)
* LINK: https://pagure.io/releng/issue/6898#comment-450892
(dgilmore, 16:48:38)
Meeting ended at 16:58:20 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
6 years, 9 months
Coming soon: Pagure service for dist-git
by Paul W. Frields
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For some time, the Fedora Infrastructure team and fellow community
members have been working on service upgrades for package dist-git.
This includes creating a Pagure front end like the one at
<https://pagure.io>, a separate instance that enables forks and pull
requests on dist-git. This change solves multiple problems -- both
common, current ones, and predicted future ones -- that stymie
community growth and contribution. Examples include proposing simple
packaging fixes, changes to the dist-git branching model, and enabling
better, more continuous production models for Fedora.
These changes will *not* require packagers to change their workflows
for existing processes. Using fedpkg and git at the command line to
manage packaging will work just as before. However, it will now be
possible for other contributors to suggest changes in a
fork/pull-request model.
WE'VE TALKED ABOUT THIS FOR A LONG TIME. WHY NOW?
- -------------------------------------------------
If you've been paying attention to release tooling efforts in Fedora,
you know we're trying to accelerate the release of the Atomic Host
deliverable. Part of this effort is establishing a pipeline for
continuous integration and delivery (CI/CD) in Fedora[1]. This and
the modularity effort also are driving the establishment of services
like this dist-git front end. The hooks and capabilities of Pagure
are part of enabling CI/CD.
In early phases, these efforts will target the packages that comprise
the Atomic Host, rather than the entire universe of Fedora packages.
This temporary measure will prove out the pipeline in an open source,
iterative way. In later phases, packagers throughout Fedora will be
able to opt-in to the pipeline as well. The benefit is that we will
know more often whether a package has problems before either breaking
the distro or impacting users. In the future, we hope this will have
a positive impact on Rawhide, making it usable by more of the
community, more often.
WHAT TO EXPECT
- --------------
One of the contributions expected in this early phase is testing. The
standard interface[2] developed as part of the CI effort provides a
framework for test contributions. Shortly after Pagure/dist-git shows
up, we hope to receive test contributions from quality engineers for
packages that comprise the Atomic Host. These should come in the form
of pull requests for the package maintainers, following the
established standards.
This is a benefit for Fedora not only because it kickstarts the CI
effort, but because it provides examples the whole Fedora community
can use in later phases. The intention is that maintainers and
co-maintainers continue to control these tests so they can modify or
add to them as needed.
If you're a packager with a package in the Atomic Host, you may
receive pull requests soon after the new Pagure instance is deployed,
with these tests included. We encourage you to review and merge these
pull requests (provided they look good), so your package can take
advantage of the CI work. If you have problems with the pull request,
you can use the Pagure instance to work with the contributor to fix
it.
It is possible to turn off PRs for your dist-git repo in the repo
settings. However, we strongly encourage you to allow PRs because
this is a strong source of potential contributions with little or no
downside. We plan to work with FESCo on a project-wide policy that
makes sense and fits Fedora's values.
WANT TO TRY IT OUT?
- -------------------
If you're interested to see what this new capability looks like, and
want to test a working version, visit
<https://src.stg.fedoraproject.org/pagure/>. Changes here won't
affect the actual Fedora RPMs, but the staging instance lets you
explore the new functionality. Note that the staging content is
updated on a schedule, so some newer package data may not appear
there.
It will be at least a few more weeks before the production instance is
ready. We appreciate your constructive feedback and bugs[3], as
always.
* * *
[1] https://fedoraproject.org/wiki/CI
[2] https://fedoraproject.org/wiki/Changes/InvokingTests
[3] https://pagure.io/pagure/issues
- --
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
-----BEGIN PGP SIGNATURE-----
iD8DBQFZXmrvrNvJN70RNxcRAv2CAJsHL66rtcFl6z/ooEOyfexkye3gBQCeOpHF
LQjAwhGOmVD2kjCD4W5Ql0c=
=AyX9
-----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
6 years, 9 months
F27 Self Contained Change: Samba AD
by Jan Kurik
= 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
6 years, 9 months
openQA failures caused by arch mismatch
by Adam Williamson
Hi, folks! This is just a heads-up for anyone who's been watching the
openQA test results for an update, or something, and been confused.
A few days ago we added a new ppc64 openQA worker host box; ultimately
we're aiming to enable some of the openQA tests to run on ppc64 as well
as x86_64 and i686. Unfortunately, it seems that openQA's protection
against running jobs on workers of the wrong arch isn't working
properly in our configuration, and since then, openQA has tried to run
quite a lot of x86_64 jobs on ppc64 workers, which of course doesn't
work at all (it blows up immediately because qemu-kvm isn't available,
in point of fact, but it could go wrong for *all kinds* of other
reasons too!)
I'm just now putting a change in place which should prevent this
happening again, and will try to re-run the tests for all updates which
were affected by this. I do apologize for the bogus failures.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6 years, 9 months
