I've been struggling this evening with building a particular package
into the EPEL7 repositories. At first I thought I was just going
bonkers, but I think I've narrowed down a particular behavior's cause.
At least the only cause of it that I can see.
The package in question is rubygem-activesupport and the build is
supposed to be a noarch, as the package is pure Ruby. Building locally
in a mock environment has worked without fail all evening long, but
building in Koji was giving me some issues. After eliminating
mismatched packages from the two environments by tagging one of my
prior builds into the buildroot and limiting minimum dependency
version, I was still seeing a mismatch. My local builds were still
fine, but the builds in Koji kept failing, both straight builds and
Links to the failed scratch builds:
And failed source build:
And my succeeded scratch build:
And the successful source build:
Note that nothing of consequence changed in the spec file between any
of these builds. In fact, during the two source builds NOTHING changed
in git. However, the only difference that I can see is that all of the
failed builds occurred on either VMs or PPC machines and the
successful builds all took place on hardware boxes.
I'm not sure if this is a koji thing, a Fedora/EPEL thing, or maybe
even a core Ruby thing.
Has anyone else experienced similar strange behaviors?
The mail "[Red Hat Bugzilla] Your Outstanding Requests" is showing me
these items since some time ago.
These seems to have the NEEDINFO flag, but they are CLOSED (and
several releases ago).
Should the closure of the bugreport have cancelled or provided the NEEDINFO?
I really want to get rid of this list.
Thanks in advance.
List of bugs:
Bug 869360 - IndexError: list index out of range [NEEDINFO]
Bug 887563 - anaconda manual partitioning created partitions are not
being shown in any tree ('biosboot' and 'prepboot') [NEEDINFO]
Bug 947616 - anaconda validate architecture from remote installation
sources (one can boot X86_64 dvd media and install a 32-BIT one via
NFS Installation Source) [NEEDINFO]
Bug 869785 - F18b TC6 on KVM GUEST "invalid opcode: 0000 [#1] SMP" [NEEDINFO]
Bug 868065 - [abrt] iftop-1.0-0.2.pre2.fc17: PROTO_ADDRESS_SIZE:
Process /usr/sbin/iftop was killed by signal 6 (SIGABRT) [NEEDINFO]
Bug 948369 - LVMError: lvresize failed for root: running lvm
lvresize (anaconda custom partitioning 'reformat' a lvm root having
changing the partition scheme to standard partition results in crash
during installation) [NEEDINFO]
Bug 961515 - SwapError: mkswap failed for
Bug 969667 - anaconda 'begin installation' button is unlocked with
Storage: Installation Destination in state 'no disks selected'
Bug 961138 - red banner (failed to add device) trying to add a mount
point after filling up a previous LVM VG which is restricted to
certain disks and the new mount point should use other free disks
i just stumbled over the following error while using bodhi on f22:
bodhi --buildroot-override=openvas-libraries-8.0.7-2.f22 --duration=2
--notes='new libraries needed for new manager'
No handlers could be found for logger "fedora.client.bodhi"
Traceback (most recent call last):
File "/usr/bin/bodhi", line 537, in <module>
File "/usr/bin/bodhi", line 433, in main
packages/fedora/client/openidbaseclient.py", line 240, in send_request
output = func(method, **kwargs)
packages/fedora/client/openidbaseclient.py", line 78, in _decorator
output = func(request, *args, **kwargs)
packages/fedora/client/openidbaseclient.py", line 195, in _authed_post
response = self._session.post(url, params=params, data=data,
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line
511, in post
return self.request('POST', url, data=data, json=json, **kwargs)
TypeError: request() got an unexpected keyword argument 'req_params'
there seem to be several tickets open for that, but no visible
progress. tickets in trac and bugzilla:
the webpage is by no means a substitute for the cli.
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.