bash completion dirs
by Thomas Moschny
Hi,
the "old" bash completion dir /etc/bash_completion.d is now owned by
the filesystem package, so packages don't need (actually: are
forbidden) to own that dir and also don't have to depend on the
bash-completion package. This perfectly makes sense.
However, for the same reasons, shouldn't the filesystem package also
own the "new" /usr/share/bash-completion/completions location?
- Thomas
8 years, 2 months
Packaging of PlayOnLinux
by Jiří Konečný
Hello,
I want to ask if PlayOnLinux could be packaged to Fedora. This program
has list of proprietary programs which are not downloaded but could be
installed if you give it setup.exe file.
Also it downloads Windows redistributable when user explicitly wants to
install program (which using this redist) or given redistributable.
If this is not "legal" in terms of Fedora how it's differ from
OpenSource software which are using not-OpenSource addons? Example of
this could be https://marketplace.firefox.com .
I think it's sad that this good LGPL wine prefix manager software is
not part of the Fedora and I like to change this.
Thank you for answers,
Jirka Konecny
8 years, 2 months
Strange VM/HW dichotomy building Ruby packages
by Greg Hellings
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
scratch builds.
Links to the failed scratch builds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171824
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171578
And failed source build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171784
And my succeeded scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171627
And the successful source build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171904
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?
--Greg
8 years, 2 months
bodhi broken in creating buildoverrides
by josef radinger
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>
main()
File "/usr/bin/bodhi", line 433, in main
}, auth=True)
File "/usr/lib/python2.7/site-
packages/fedora/client/openidbaseclient.py", line 240, in send_request
output = func(method, **kwargs)
File "/usr/lib/python2.7/site-
packages/fedora/client/openidbaseclient.py", line 78, in _decorator
output = func(request, *args, **kwargs)
File "/usr/lib/python2.7/site-
packages/fedora/client/openidbaseclient.py", line 195, in _authed_post
response = self._session.post(url, params=params, data=data,
**kwargs)
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:
https://bugzilla.redhat.com/show_bug.cgi?id=1278742
https://fedorahosted.org/bodhi/ticket/790
the webpage is by no means a substitute for the cli.
josef
8 years, 2 months
Building packages with clang?
by Tom Hughes
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/
8 years, 2 months
Seeking a package sponsor for Firefox Developer Edition
by Andrew Toskin
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)
8 years, 2 months
Fwd: Use suid_dumpable=2 for development releases
by Jakub Filak
----- 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
8 years, 2 months
Is anyone but me using fedfind for anything?
by Adam Williamson
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
8 years, 2 months
