[Bug 2222] New: Review request: libactp - Adaptive Clearing Tool Path Library
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2222
Bug #: 2222
Summary: Review request: libactp - Adaptive Clearing Tool Path
Library
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: SpikeFedora(a)gmail.com
CC: rpmfusion-package-review(a)rpmfusion.org
Blocks: 2
Spec URL:
http://spike.fedorapeople.org/libactp/libactp.spec
SRPM URL:
http://spike.fedorapeople.org/libactp/libactp-0.0.2-0.1.20111219giteb97a6...
Description:
The libactp (Adaptive Clearing Tool Path Library) is an implementation of the
GPL'ed algorithm demonstrated in FreeSteel as a set of C library functions
Why this package is not eligible to be included in Fedora:
"Some software is not functional or useful without the presence of external
code dependencies in the runtime operating system environment. When those
external code dependencies are non-free, legally unacceptable, or binary-only
[...], then the dependent software is not acceptable for inclusion in
Fedora"[1]
Since atm only HeeksCNC uses this lib and HeeksCNC depends on OCE
(HeeksCNC->HeeksCAD-devel->OCE-devel), which is considered non-free, I assume
the term "not useful" applies here.
[1] http://fedoraproject.org/wiki/Packaging:Guidelines
rpmlint output:
SPECS/libactp.spec: W: invalid-url Source0: libactp-svnHEAD.tar.bz2
libactp.src: W: invalid-url Source0: libactp-svnHEAD.tar.bz2
1 packages and 1 specfiles checked; 0 errors, 2 warnings.
Upstream doesn't provide a release package tarball.
Careful: I usually don't do any python packaging. Here be dragons!
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
6 years, 9 months
[Bug 2363] New: jitsi - Open Source Video Calls and Chat
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2363
Bug #: 2363
Summary: jitsi - Open Source Video Calls and Chat
Classification: Unclassified
Product: Package Reviews
Version: Current
Platform: All
OS/Version: GNU/Linux
Status: NEW
Severity: normal
Priority: P5
Component: Review Request
AssignedTo: rpmfusion-package-review(a)rpmfusion.org
ReportedBy: fedora(a)marionline.it
CC: rpmfusion-package-review(a)rpmfusion.org
SPEC: http://marionline.fedorapeople.org/packages/SPECS/jitsi.spec
SRPMS:
http://marionline.fedorapeople.org/packages/SRPMS/jitsi-1.1-1.nightly.bui...
Description:
Jitsi (previously SIP Communicator) is an audio/video and chat communicator
that supports protocols such as SIP, XMPP/Jabber, AIM/ICQ, Windows Live, Yahoo!
and many other useful features.
Why here:
This package cannot be shipped into official fedora repository because upstream
use ffmpeg library.
Rpmlint:
jitsi.src: W: invalid-url Source4: portaudio-hotplug-r1838.tar.gz
jitsi.src: W: invalid-url Source3: jdic-r1736.tar.gz
jitsi.x86_64: W: devel-file-in-non-devel-package
/usr/lib64/portaudio-hotplug-r1838/libportaudio.a
jitsi.x86_64: W: devel-file-in-non-devel-package
/usr/include/portaudio-hotplug-r1838/portaudio.h
jitsi.x86_64: W: devel-file-in-non-devel-package
/usr/lib64/portaudio-hotplug-r1838/pkgconfig/portaudio-2.0.pc
jitsi.x86_64: W: devel-file-in-non-devel-package
/usr/include/portaudio-hotplug-r1838/pa_linux_alsa.h
jitsi.x86_64: W: no-manual-page-for-binary jitsi
4 packages and 0 specfiles checked; 0 errors, 7 warnings.
I think jdic and portaudio branch hotplug for now is useful just for jitsi so I
include them directly in this package. There are not official releases of this
two packages, I checkout the code from svn repository.
This is not my first RPM package. I just open another review request here for
another SIP software, homer:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2237
--
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
6 years, 9 months
nVidia howto question or solution
by Sérgio Basto
Hello,
After on IRC another fellow, had problems on install nVidia drives on
first installation and reboot, I also had a similar problem that make
me think. And I think I found the issue, instead try blacklist nouveau
on boot we should run:
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
xorg-x11-drv-nvidia package have blacklist-nouveau.conf [1] but just
install a new kernel nouveau enter in blacklist isn't it ? , so after
installing nVidia drives (for the first time) we should also run dracut
to generate initramfs without nouveau module isn't it ? anyway like
blacklist-nouveau.conf text says.
Conclusion we should/need update https://rpmfusion.org/Howto/nVidia
Best regards,
[1]
https://pkgs.rpmfusion.org/cgit/nonfree/xorg-x11-drv-nvidia.git/tree/bl
acklist-nouveau.conf
--
Sérgio M. B.
6 years, 9 months
F28 ffmpeg-3.5 rebuild, FTBFS list
by Leigh Scott
Here's a list of the packages that fail to build
cmus
libquicktime
mplayer
freshplayerplugin
guvcview
lightspark
moc
lives
pianobar
qtav
kodi
transcode
tvheadend
zoneminder
gstreamer1-libav
vdr-softhddevice-openglosd
vdr-softhddevice
vdr-markad
6 years, 9 months
Access to the Rpmfusion repositories
by Antonio Trande
Hi all.
I can't checkout a package's GIT module:
$ rfpkg clone free/lives
Deprecation warning: kojiconfig is deprecated. Instead, kojiprofile
should be used.
Cloning into 'lives'...
ssh: Could not resolve hostname # my fas username# https: Name or
service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Command '['git', 'clone', 'ssh://# My FAS
username#
https://fedoraproject.org/wiki/Infrastructure/Kerberossagitter@pkgs.rpmfu...',
'--origin', 'origin']' returned non-zero exit status 128
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/
6 years, 9 months
[Bug 4441] New: Review request: discord - All-in-one voice and text
chat for gamers
by RPM Fusion Bugzilla
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4441
Bug ID: 4441
Summary: Review request: discord - All-in-one voice and text
chat for gamers
Product: Package Reviews
Version: Current
Hardware: x86_64
OS: GNU/Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: Review Request
Assignee: rpmfusion-package-review(a)rpmfusion.org
Reporter: seancallaway(a)gmail.com
CC: rpmfusion-package-review(a)rpmfusion.org
SPEC URL: https://seansblag.com/software/discord/discord.spec
SRPM URL: https://seansblag.com/software/discord/discord-0.0.1-1.fc25.src.rpm
DESCRIPTION:
Discord is a free-of-cost proprietary VoIP application designed for gaming
communities.
WHY NOT IN FEDORA?
Discord is a proprietary application *and* relies on nonfree libraries (such as
ffmpeg), which the developer has bundled into the application.
RPMLINT OUTPUT (SRPM):
discord.src: W: spelling-error Summary(en_US) gamers -> gamer, games, tamers
discord.src: W: invalid-license Proprietary
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
RPMLINT OUTPUT (RPM):
discord.x86_64: W: spelling-error Summary(en_US) gamers -> gamer, games, tamers
discord.x86_64: W: invalid-license Proprietary
discord.x86_64: W: binaryinfo-readelf-failed
/usr/lib64/discord/resources/bootstrap/discord_voice.zip readelf: Error: Not an
ELF file - it has the wrong magic bytes at the start
discord.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/discord/Discord
['$ORIGIN', '$ORIGIN/lib/']
discord.x86_64: W: binaryinfo-readelf-failed
/usr/lib64/discord/resources/bootstrap/discord_toaster.zip readelf: Error: Not
an ELF file - it has the wrong magic bytes at the start
discord.x86_64: W: binaryinfo-readelf-failed
/usr/lib64/discord/resources/bootstrap/discord_utils.zip readelf: Error: Not an
ELF file - it has the wrong magic bytes at the start
discord.x86_64: W: no-documentation
discord.x86_64: W: no-manual-page-for-binary Discord
discord.x86_64: W: desktopfile-without-binary
/usr/share/applications/discord.desktop /usr/bin/Discord
JUSTIFICATIONS FOR ERRORS AND WARNINGS:
* spelling-error: gamers is the proper plural of gamer.
* invalid-license: rpmlint doesn't seem to support nonfree licenses
* binaryinfo-readelf-failed: It's right. There's aren't ELF binaries, as
they're ZIP files. Not sure how to remove this error, but am more than willing
to do something to fix this.
* binary-or-shlib-defines-rpath: The developer has built their proprietary
binary to use bundled libraries. It's not ideal, but it's what they've done. I
can try to convince them to just include those libs as a requirement in their
Linux release.
* no-documentation and no-manual-page-for-binary: No documentation is provided
for Discord outside of their website.
* desktopfile-without-binary: /usr/bin/Discord is a symlink to
/usr/lib64/discord/Discord due to the bundled libraries.
NOTES:
This is my first RPMFusion package (and first desktop application package), but
not my first package. I package re2c and openvpn-auth-ldap for EPEL.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
6 years, 9 months
RPM Fusion Projects for 2018
by Nicolas Chauvet
Hi there,
With the new year already beginning I would like to sum-up the few
projects I'll try to achieve this year. Hopefully we could look
backward next year and see how it went.
- Cuda repository:
I plan to have dedicated koji target and a separate cuda namespace
(along with free/nonfree separation) This would allow to build cuda
enabled packages using the nvidia provided cuda compiler and software
collection if needed (as external repositories for theses build
target). The feature isn't fully backed yet so I'd like to have others
thought but this namespace would have branches based on cuda versions
(not fedora/el) and have a relaxed policy about replacement packages
(unless it can easily complement).
- libdvdcss: With the new "cuda-drivers repository", it's now possible
to have another "side repository" to handle this package, over using
livna. Last time we discussed this topic, I beleive this solution was
talked about but none volunteered to submit a libdvdcss package review
to start with...
The name of such "side repository" would need to be found, specially
if others packages could fall into such "forbidden item" category.
- Infra maintainers bring-up: I'm sure there are lot of people very
capable as sysadmin. Unfortunately I'm not able to evaluate and see if
we can work together as appropriate. This is a similar situation when
one wonders if he could give provenpackager rigths to a person that
haven't shown much packaging work yet. This is not possible as the
risk to have lot to recover is high.
Fedora wouldn't allow to default to trust either.
But there is also a need to break this circle to better evaluate
sysadmin candidates. One of them is to instantiate a cloud vm where
people could start installing packages and playing with ansible
(similar to the fedora infra apprentice group, but eventually with
some sudo rights).
- Less packages in the review queue:
Here is the list of the pending review (today there are 45 waiting packages):
https://bugzilla.rpmfusion.org/buglist.cgi?component=Review%20Request&lis...
There is a need to close non-responsive submitter and to bring new
maintainer into action.
- Drop old packages and concentrate on new:
I would prefer to concentrate on packaging Natron than cinelera-cv,
libquicktime should be nuked.
- RPM Fusion containers images:
It should be possible to provide containers for software from higher
fedora than what's currently installed. For example, ffmpeg 3.5
containers using a fedora 28 base. This would dramatically reduce the
need to provide newer softwares on older releases. And would leave
room to more work into a "deep stable" releases process along with
recent software. (as soon as it's a binary only package, not a
graphical application).
(see docker pull rpmfusion/ffmpeg as a first attempt).
- Better Multimedia for EL (scl-like):
Software Collection (scl) is a mean to provide an alternate version of
a given stack using a different path. RPM Fusion could use a dedicated
koji target to rebuild fedora/rpmfusion packages using such
collection.
- Flatpak/Module/Etc support.
Fedora tries to experiment in few directions to work towards better
support for alternates version.
I personally prefer native packages over flatpak by several order of
magnitude. But for toying and by popular demand, we might inevitably
"regress" to provide flatpak.
- RPM Fusion spins:
With the current infra, it should be easier to provide spins. Either
live or "ostree" images. Both of them could be provided as x86_64
armhfp and aarch64 (that would be fun to maintain a compatible hw list
for arm side).
* Multimedia Center: something about Koji (would need arm* fixes) and
mythtv or else.
* Arcade Gaming:
* Other: I know others are maintaining Spins from the community.
Thoses would be nice in a
- Drop the repoview from mirrors and use the "packages" applications.
repoview categories are outdated and relies on Group from spec files,
best would be to use the "packages" application and adapt for
rpmfusion. This would be a good candidate for the infra bring-up.
- Rework of the frontpage and wiki:
Right now the frontpage is part of the wiki. But it could be separate
components. There is a need to renew both of them. Either using the
same techno or something else. Suggestion ?
- Delegate more coordination tasks:
I would like to progressively phase down my involved in the project
with me acting as a infra maintainer. I specifically want to focus on
finding hw sponsor so we don't need to rely
(we have DNS domain bought for the next 5 years at least)
I'm pretty sure there are others items in my list, but at least that's
the main ones, of course if you don't know what you do, I have things
to suggests.
Thx for any help and other initiatives in these area.
--
-
Nicolas (kwizart)
6 years, 9 months
RPM Fusion update report 2018-01-28
by noreply＠rpmfusion.org
RPM Fusion update report
------------------------
Section free:
-------------
Fedora 25
-------------
Pushed to testing:
Pushed to stable:
Fedora 26
-------------
Pushed to testing:
devedeng-4.8.12-1.fc26
xmltv-0.5.70-1.fc26
yle-dl-2.26-2.fc26
Pushed to stable:
freshplayerplugin-0.3.9-1.fc26
mythtv-29.0-9.20180111.77.g771115f47d.fc26
qt5-qtwebengine-freeworld-5.10.0-1.fc26
transcode-1.1.7-22.fc26
vdr-xineliboutput-2.1.0-1.20180118gitcdd6595.fc26
Fedora 27
-------------
Pushed to testing:
devedeng-4.8.12-1.fc27
libva-intel-driver-1.8.3-3.fc27
qt5-qtwebengine-freeworld-5.10.0-1.fc27.1
xmltv-0.5.70-1.fc27
xpra-codecs-freeworld-2.2.2-1.fc27
yle-dl-2.26-2.fc27
Pushed to stable:
VirtualBox-5.2.6-2.fc27
VirtualBox-kmod-5.2.6-2.fc27
freshplayerplugin-0.3.9-1.fc27
gstreamer1-plugins-ugly-1.12.4-3.fc27
mythtv-29.0-9.20180111.77.g771115f47d.fc27
transcode-1.1.7-22.fc27
vdr-xineliboutput-2.1.0-1.20180118gitcdd6595.fc27
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
Pushed to stable:
mythtv-29.0-6.20171226.71.g339b08e467.el7
mythtv-29.0-9.20180111.77.g771115f47d.el7
Section nonfree:
-------------
Fedora 25
-------------
Pushed to testing:
Pushed to stable:
Fedora 26
-------------
Pushed to testing:
Pushed to stable:
lpf-flash-plugin-28.0.0.137-1.fc26
unrar-5.5.8-1.fc26
yapeSDL-0.70.2-2.fc26
Fedora 27
-------------
Pushed to testing:
Pushed to stable:
dwarffortress-0.44.05-1.fc27
lpf-flash-plugin-28.0.0.137-1.fc27
unrar-5.5.8-1.fc27
yapeSDL-0.70.2-2.fc27
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
Pushed to stable:
Theses packages will be available in main mirror in few minutes. Wait for local mirrors to sync
Please report any issue to https://bugzilla.rpmfusion.org
6 years, 9 months
About transcode and dvdrip
by Nicolas Chauvet
Hi,
Forwarding from IRC to mailing list since I don't have IRC access today.
I think transcode could be retired nowadays (along dvdrip)
1/ It's not maintained upstream.
2/ It lost any interest already since pvm3 support was dropped from fedora
(nowadays transcoding performance are better accelerated using gpu
than load distributed to many workstations).
Dvdrip is only a frontend to transcode. And having transcode without
pvm support already make this package pointless.
So If no other component rely on them, I'm good to retired both.
Thx
--
-
Nicolas (kwizart)
6 years, 9 months
