Mageia CoC violation in PKGBUILD
dvzrv opened this issue · 10 comments
Hi! I'm packaging jack and jack2 for Arch Linux.
I have recently been made aware of the PKGBUILD for an Arch Linux package and noticed a statement in there, that is in violation with the Code of Conduct, that Mageia implements for itself.
@glixx As you have done this commit with your @mageia.org mail address in 5b6ca2a I suggest to remove this commit, as it reflects poorly both on you and on Mageia.
On the case of jack and jack2 "requiring" libffado: Both do not require it, but if someone wants to use a firewire interface with jack that is supported by libffado, they can install libffado and use the ffado backend (because the jack and jack2 packages are both compiled against libffado). For this use-case we have the concept of optdepends on Arch Linux.
This means: Unless pianobooster directly links to libffado.so libffado is not required as a dependency.
Taking a look at the libraries this project links against, not even libjack.so shows up:
$ find-libdeps pianobooster-0.7.2b-1-x86_64.pkg.tar.zst
libGL.so=1-64
libQt5Xml.so=5-64
libQt5OpenGL.so=5-64
libftgl.so=2-64
librtmidi.so=5-64
libQt5Widgets.so=5-64
libQt5Gui.so=5-64
libQt5Core.so=5-64
libstdc++.so=6-64
libgcc_s.so=1-64
libc.so=6-64
Further looking at the README, it becomes clear that jack is not a direct requirement at all (unless one wants to use jack), but only a soundfont synthesizer such as fluidsynth or timidity (both can work with ALSA directly).
Here is a PKGBUILD that reflects the requirements (AFAICS):
_name='PianoBooster'
pkgname=pianobooster
pkgver=0.7.2b
pkgrel=1
pkgdesc='A MIDI file player that teaches you how to play the piano'
url="https://github.com/captnfab/PianoBooster"
depends=('ftgl' 'gcc-libs' 'glibc' 'hicolor-icon-theme' 'libglvnd' 'qt5-base'
'soundfont-synthesizer' 'ttf-dejavu' 'unzip')
makedepends=('alsa-lib' 'cmake' 'mesa' 'glu' 'qt5-tools' 'rtmidi')
optdepends=('qt5-translations: for full UI translations')
arch=('x86_64')
groups=('pro-audio')
license=('GPL3')
source=("${_name}-${pkgver}.tar.gz::https://github.com/captnfab/${pkgname}/archive/v${pkgver}.tar.gz")
sha512sums=('66dd2e051804e5cdfa121ae0ea39525c8ecdd628d7bb38e2767328b59f750051ee738f13f2780435b5f220fe6cd223670648cb2d8f7938ef3e4c9acda1b9c161')
b2sums=('e7f3aa9cdc47d4ff4de6b91bb9f631c11bf81472d5ebb5e7c928509eec54ae3afab8ef5e94c66fa897a3d3e50e08cb94a07ef00bd8ff372d46b687522072e2cc')
prepare() {
mv -v "${_name}-${pkgver}" "${pkgname}-${pkgver}"
}
build () {
cd "${pkgname}-${pkgver}"
cmake -DCMAKE_INSTALL_PREFIX='/usr' \
-DCMAKE_BUILD_TYPE='None' \
-DUSE_SYSTEM_FONT=ON \
-DWITH_MAN=ON \
-Wno-dev \
-B build \
-S .
make VERBOSE=1 -C build
}
package () {
depends+=('librtmidi.so')
cd "${pkgname}-${pkgver}"
make DESTDIR="${pkgdir}" VERBOSE=1 install -C build
}
Please note: No upstream is required to carry their own PKGBUILD. Usually they are either made available via the Arch User Repository (AUR) or are integrated into the package repositories and tracked by package maintainers (when in the official repositories).
Thanks for this. I am planning to deleted all the different packaging information for all the different distributions (apart from the win32 which is needed for all the Windows build). And i am glad you have confirmed that PKGBUILD here is not needed for the Arch Linux.
jack doesn't work without libffado installed in Arch Linux!
@glixx I guess I must have a special system here then:
jack:
/usr/bin/jackd -P80 -p 512 -d alsa -d hw:PCH,0 -n 2 -p 2048 -r 48000
jackd 0.125.0
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
could not open driver .so '/usr/lib/jack/jack_firewire.so': libffado.so.2: cannot open shared object file: No such file or directory
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:PCH,0|hw:PCH,0|2048|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 2048 frames (42.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
jack2:
● jack@internal-48000.service - JACK server using internal-48000.conf profile
Loaded: loaded (/usr/lib/systemd/user/jack@.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-06-17 09:44:09 CEST; 6s ago
Docs: man:jackd(1)
Main PID: 1118299 (jackd)
Tasks: 5 (limit: 38378)
Memory: 36.7M
CPU: 56ms
CGroup: /user.slice/user-1000.slice/user@1000.service/jack.slice/jack@internal-48000.service
└─1118299 /usr/bin/jackd -P80 -p 512 -d alsa -d hw:PCH,0 -n 2 -p 2048 -r 48000
Jun 17 09:44:09 dvzrv jackd[1118299]: self-connect-mode is "Don't restrict self connect requests"
Jun 17 09:44:09 dvzrv jackd[1118299]: audio_reservation_init
Jun 17 09:44:09 dvzrv jackd[1118299]: Acquire audio card Audio1
Jun 17 09:44:09 dvzrv jackd[1118299]: creating alsa driver ... hw:PCH,0|hw:PCH,0|2048|2|48000|0|0|nomon|swmeter|-|32bit
Jun 17 09:44:09 dvzrv jackd[1118299]: configuring for 48000Hz, period = 2048 frames (42.7 ms), buffer = 2 periods
Jun 17 09:44:09 dvzrv jackd[1118299]: ALSA: final selected sample format for capture: 32bit integer little-endian
Jun 17 09:44:09 dvzrv jackd[1118299]: ALSA: use 2 periods for capture
Jun 17 09:44:09 dvzrv jackd[1118299]: ALSA: final selected sample format for playback: 32bit integer little-endian
Jun 17 09:44:09 dvzrv jackd[1118299]: ALSA: use 2 periods for playback
Jun 17 09:44:09 dvzrv systemd[1112]: Started JACK server using internal-48000.conf profile.
Both of the above are happily running without libffado installed.
Also, if you believe that this ticket is about jack, jack2 or libffado you might want to read it again.
This ticket is about you violating your own code of conduct while contributing to an upstream project and afterwards not even acknowledging it.
@dvzrv: Thank you for pointing out this disrespectful comment. I'm quite sorry and disappointed to see this kind of unnecessarily aggressive words here. My apologies to the aforementioned maintainers since I'm the one who should have been reviewing this commit. I trust @louis-barman (who is the original author and current project leader) will soon clean all that :-)
OK I have just delete this disrespectful comment along with all the distribution specific info. I have also confirmed with the Debian maintainer that distribution specific package info is not required.
@louis-barman I think this is not a good move to have removed the debian* files from the project, better to have updated them if needed. What is the logic behind this removal?
No one is testing any of these package specific information and so it is just an inaccurate duplicate of information that the Debian or other package maintainers generate for themselves. I don't even know what each of these package scripts are meant to do, so there is no point in my opinion in blindly copying them.
What is needed is an accurate list of dependencies so that everyone can build from source code . (I now need to update the BUILD.md with this info).
I do not fully agree here. Compiling isn't a good method for the end users since their package manager isn't aware of software installed by that way. With providing the correct debian/* files, then the user is able to compile & package the software, hence his package manager is aware of the software installed.
Hence, in my opinion, it's better to have the files somewhere in here.
PS: I can understand the "testing" issue that said
did you not receive my email date 13 May when i asked you and the debian maintainer about this?
I would expect users who want to build from source just to look in the build.md and i am not expecting anyone to build missing dependencies from source.
this is what I propose to change the start of the build.md to :
Ensure that the following packages are installed:
build-essential, cmake, pkg-config, libftgl-dev, qtbase5-dev, qttools5-dev, librtmidi-dev , fluid-soundfont-gm, libfluidsynth-dev
They are actually the ubuntu packages needed as I don't have access to debian but i am sure that info is helpful for other distributions. Also I am providing an AppImage reducing the need to compile from source. The info the pkgs directory was only useful for those people building packages not end users.
did you not receive my email date 13 May when i asked you and the debian maintainer about this?
Nope, I hadn't. But now, yes, thanks for having forwarded it to me. I've read it now.
[...] and i am not expecting anyone to build missing dependencies from source.
This part of the sentence looks strange to me. It sounds to me like a misunderstanding of how it works on Debian. Nobody is expected to build missing dependencies from source here.
They are actually the ubuntu packages needed as I don't have access to debian [...]
They're all taken from Debian, hence they're the same for Debian (and most probably all derivated).
Also I am providing an AppImage
I didn't know/remember that. So it can cover the case of a user who need a newer version than the one in Debian. All good then.
Thanks for having taken the time to explain precisely all of that here.