on fedora the build process of vdr-epg-daemon fails with this message:
make: Entering directory '/builddir/build/BUILD/vdr-epg-daemon-1.1.100'
cat contrib/epgd.service | sed s:"<BINDEST>":"/usr/bin":g | sed s:"<AFTER>":"mariadb.service":g | sed s:"<PLGDEST>":"/usr/lib64/epgd":g | install -C -D /dev/stdin /builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epgd.service
chmod a+r /builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epgd.service
cat contrib/epghttpd.service | sed s:"<BINDEST>":"/usr/bin":g | install -C -D /dev/stdin /builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epghttpd.service
chmod a+r /builddir/build/BUILDROOT/vdr-epg-daemon-1.1.100-1.fc26.x86_64/usr/lib/systemd/system/epghttpd.service
Failed to connect to bus: No such file or directory
make: Leaving directory '/builddir/build/BUILD/vdr-epg-daemon-1.1.100'
make: *** [Makefile:121: install-systemd] Error 1
make: *** [Makefile:97: install] Error 2
rpm spec file:
# for now i removed systemctl daemon-reload from Makefile
sed -i -e 's|systemctl daemon-reload||' Makefile
Is there any other solution ?
I've been playing with touchpad pointer acceleration in libinput again and
finally found something I'm happy with. Most notably it has a wide range of
configurable speed settings, from "tar" to "speed-skating ring". Please give
this scratch build a test and let me know how you go:
Reminder: after installing you *must* log out of X/Wayland for the changes
to take effect.
I'm wondering if ABRT is still actively-developed since one of the main
developers left Red Hat recently. I have a few complaints that have
been annoying me for some time:
(1) ABRT is frankly very bad at detecting whether bugs are duplicates
of each other. It keeps telling users that their bugs are duplicates of
completely and totally unrelated bugs. The only commonality is that a
*non-crashing* thread in the backtrace is blocked in pthread_cond_wait,
which is almost always the case in WebKit crashes, for example. I guess
this is just a bug, and ABRT is failing to detect the crashing thread
properly. I've mentioned a few cases in https://bugzilla.redhat.com/sho
w_bug.cgi?id=1396475, but there are really dozens of these that I
haven't bothered to mention there. Users keep marking their bugs as
duplicates of unrelated bugs, because ABRT tells them that the bugs are
duplicates, which makes it harder to manage bugs and is getting *very*
annoying. Most recent case of this is https://bugzilla.redhat.com/show_
bug.cgi?id=1426813, but I'm sure there have been two or three more in
the past week.
(2) I don't want to ever receive any private bug reports, since all I
do is forward them to public upstream Bugzilla. The reasonable options
are (a) ignore the bug report, since it cannot be forwarded, or (b)
make it public. I always use (b), except in the extremely unusual cases
where the bug report really does contain some obvious sensitive data
(like a URL) and I happen to notice it, in which case I'll ask the
reporter. My point is the private bug report feature is useless if the
reports are either going to be ignored or set public anyway. This was
not previously much of a problem because bug reports were always public
by default, so not many people used them. But nowadays, bug reports are
almost always private by default, due to (3).
(3) The heuristic that guesses whether a bug report contains sensitive
data is terrible. If the word "key" is present in the backtrace, ABRT
decides that bugs should be private by default. But "key" is always
going to be in your backtrace if your application uses hash tables.
I've filed dozens, maybe hundreds, of ABRT reports, and am genuinely
uncertain if I've ever seen either (a) ABRT not flag sensitive data in
a backtrace I was going to upload (it almost always flags "key"), or
(b) a backtrace I was going to upload that actually contains sensitive
data. 99% of the time it is just false positives, so I always ignore
ABRT's sensitive data warnings. I think simply not matching on "key"
would help a lot here. Otherwise, the entire sensitive info warning is
basically useless due to the false positives.