I have a package that struggles to build on 32 bit x86 and arm because
the compiler tends to use so much memory that the builder runs out of
Upstream is aware of the issue, and mentioned that clang uses
considerably less memory to build the problem file so I thought I would
see if building with clang would work.
Unfortunately although it works on F23 I always seem to get link errors
when building with rawhide:
clang++ -o test/standalone/agg_rasterizer_integer_overflow_test-bin
-Ldeps/agg -Lsrc -Lsrc/json -Lsrc/wkt -L/usr/lib -L/usr/lib64 -lmapnik
-lmapnik-wkt -lmapnik-json -lagg -lboost_filesystem -lboost_regex
-lcairo -lpng -lproj -ltiff -lwebp -lxml2 -licui18n -lboost_system
-lharfbuzz -ljpeg -licuuc -lfreetype -lz -ldl -lboost_program_options
src/libmapnik.so: undefined reference to
`std::ios_base::failure::failure(char const*, std::error_code const&)'
clang-3.8: error: linker command failed with exit code 1 (use -v to see
That's from this build:
Is building packages with clang actually allowed and/or expected to
work? The C/C++ guidelines seem to suggest it is given that they say you
should require either gc or clang.
As far as I can see the symbol being complained about does exist, though
with an abi tag in libstdc++ (but that is true in F23 as well).
Tom Hughes (tom(a)compton.nu)
Hello! I'm interested in learning about RPM packaging for Fedora, and I'd like to see the "Developer Edition" release channel for Firefox (formerly called Firefox Aurora) available in the Fedora repositories. So my partner Bob and I are working on packaging firefox-dev. Our spec file repository is forked from the Fedora package for the regular release of Firefox. It's not in a working state yet, but you can see our progress on GitHub -- https://github.com/Bob131/firefox-dev/
And we have a Copr here -- https://copr.fedoraproject.org/coprs/bob131/firefox-dev/
Firefox Developer Edition and regular Firefox are able to share the same user profile (the bookmarks, preferences, etc) or use separate profiles, we're aiming to allow both versions of Firefox to coexist on the same system.
Bob and I are both fairly new to the packaging process, so any help will be appreciated.
("terrycloth" on GitHub and FAS)
Anyone understand what's going on here? Any program at all (even
trivial ones) linked to tcmalloc crash during startup on ARM 32 bit.
At Tom's recommendation, I have added a patch to dist-git that
disables hardened build on 32 bit ARM builds of gperftools, but that's
quite a big hammer, and neither of us understands the underlying
problem very much.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
----- Forwarded Message -----
From: "Jakub Filak" <jfilak(a)redhat.com>
Sent: Thursday, February 11, 2016 9:51:04 AM
Subject: Use suid_dumpable=2 for development releases
As a maintainer of ABRT, I have been asked several times why ABRT does not catch
crashes of many processes and one kind of reasons dominate among other reasons
- processes that executes set-user-ID programs (man 5 core). These processes
are not dumped at all if the value of /proc/sys/fs/suid_dumpable is 0 (man 5
proc) which is the default value. With the default suid_dumpable
value, crashes caused by SIGABRT are not detectable because kernel doesn't even
write a log message about that.
The default value 0 is there for good security reason, but I would like to
propose changing the default value to 2 for development Fedora releases (Alpha,
Beta, Rawhide). In this case, kernel would send core dump to ABRT (or
systemd-coredump) and the ABRT record would be accessible only to root.
I believe that maintainers of packages like chrony will be really delighted
with this change, while will not weaken security of Fedora for regular users.
security mailing list
So, I spent most of this week rewriting my 'fedfind' tool for the new
world of Pungi 4 composes. The work is currently on the 'pungi4'
I'm more or less happy with what I've got now, but it makes some rather
large API changes.
I've made the CLI continue to work more or less unchanged; there's a
new --respin arg for specifying the 'respin' for relevant compose
types, and the debug output looks slightly different, but any way you
could run it before you should still be able to run it now and it
should behave basically the same. So if you just use fedfind as a CLI
tool, relax, you don't have to worry.
However, I wanted to ask if anyone apart from me is using fedfind as a
Python package. If there *are* any non-me users, I'll probably try to
be a bit polite about sending out the new code as a stable release and
pushing it to the Fedora repositories. If I *don't* find any non-me
users I'm just going to convert the things I'm in charge of that use
fedfind, and then send out a 2.0 release everywhere.
So if you're using it, please speak up :) Thanks!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
- it's effectively dead upstream (and has been for about 5 years...)
- it has a variety of crashers I haven't gotten around to finding time to fix
- I don't really use it any more anyways
Suggestions: use hexchat, or polari, or irccloud, or.... really anything else.
Or take it if you want.
I just added
chroots to Copr. I automatically enabled those chroots for every project, which has fedora-rawhide-* enabled. And I
copied all build artifact from rawhide to fedora-24-* repository.
Ppc64le repositories are not available yet. I will enable it and send another email once it will be available.
P.S. we already discovered issue that old builds (~10+ months old) were not copied. If you need them, please submit it
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
The PyOpenGL package has been renamed to python-pyopengl on the f24
and master branches, and the Provides have been updated to reflect
current python packaging guidelines. If your package depends on
PyOpenGL, or any of its sub-packages everything will continue to work,
but you should change your Requires lines as follows:
1) PyOpenGL -> python2-pyopengl
2) python3-PyOpenGL -> python3-pyopengl
3) PyOpenGL-Tk -> python2-pyopengl-tk
4) python3-PyOpenGL-Tk -> python3-pyopengl-tk
As I say, no upgrade paths should be broken, as the new package adds
compatibility Provides, but they will be removed in the Fedora 27
Packages affected (maybe incomplete):