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
memory.
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
-pthread test/standalone/agg_rasterizer_integer_overflow_test.o
-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
invocation)
That's from this build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13160432
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
--
Tom Hughes (tom(a)compton.nu)
http://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.
Thanks,
~Andrew Toskin
("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.
https://bugzilla.redhat.com/show_bug.cgi?id=1312462
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.
Rich.
--
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.
http://fedoraproject.org/wiki/MinGW
----- Forwarded Message -----
From: "Jakub Filak" <jfilak(a)redhat.com>
To: security(a)lists.fedoraproject.org
Sent: Thursday, February 11, 2016 9:51:04 AM
Subject: Use suid_dumpable=2 for development releases
Hello,
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.
Regards,
Jakub
--
security mailing list
security(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/security@lists.fedoraproject.org
Hi folks!
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'
branch:
https://www.happyassassin.net/cgit/fedfind/log/?h=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!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net