Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file,
breaking almost everything
by Hans de Goede
Hi All,
Just a quick headsup for users following Fedora 29, the
dbus 1.12.10-1.fc29 build is missing the systemd dbus.service
file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the
dbus.socket file expects a matching dbus.service, not
dbus-daemon.service.
So either hold of on applying updates until this is fixed
or exclude dbus.
Regards,
Hans
3 years, 8 months
Ditch RPM in favor of DPKG
by Dridi Boukelmoune
Greetings packagers,
I know how important RPM is to the Fedora Project, but it breaks
everything downstream and we'd be better off using DPKG as we should
have from day one.
I'm calling this initiative fedpkg: Fedora Embraces DPKG.
A bit of background here: I build both RPMs and DEBs for $DAYJOB and
until recently my workflow was quite painful because I needed extra steps
between git checkout and git push that involves a VM, because what we
ship as apt is in reality apt-rpm.
It finally got enough on my nerves to locally build the things I needed and
after a month I have already amortized my efforts with the time I save not
having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that
I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl
Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anything
Apt is a mix of C, Perl and C++ code, so I would be reassured if I
could have a C++ co-maintainer too. I'm only a C developer so if
something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up
the procedure for that to happen. I understand that when someone sees
they should run "apt-get install foo" somewhere on the web it's
helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is
dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find
help for the reviews and co-maintainership. The packaging does nothing
fancy, there are quirks here and there but overall it was rather easy
to put together. And of course I would be happy to help with reviews
too in exchange.
And thanks again to the mock developers, its design is so much better
than either sbuild or pdebuild that I barely have pain points left when it
comes to RPM packaging.
Thanks,
Dridi
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
[2] I'm not against apt-rpm in the base install for example
3 years, 9 months
Fedora 33 Self-Contained Change proposal: Drop mod_php
by Ben Cotton
https://fedoraproject.org/wiki/Changes/drop_mod_php
== Summary ==
mod_php (apache2handler) is an optional httpd module to execute PHP
scripts, not used.
== Owner ==
* Name: [[User:Remi| Remi Collet]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
By default php-fpm is used for a few versions. mod_php is not
supported for threaded modules. mod_php usage also increases security
risk, sharing the same process than httpd.
Drop mod_php from php build. This will only affect user of httpd in
"prefork" mode, which will also use php-fpm.
php-fpm is already used but most users of httpd and nginx without any issue.
The "php" package will be kept as a metapackage, installing (weak
dependencies) most commonly used extension, thus reducing the
difference between "yum install php" (flat repository) and "yum module
install php" (modular repository).
== Benefit to Fedora ==
Only provide the modern way to execute PHP in a web server.
== Scope ==
PHP rebuild (mod_php build is already conditional)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
* install and play with your web applications
== User Experience ==
No change.
== Dependencies ==
None (dependency on "php" is already forbidden by Guidelines)
== Contingency Plan ==
* revert
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
* Blocks product? product
== Documentation ==
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 9 months
Orphaned 215 packages
by Jamie Nguyen
Hi,
This is a follow up for this post:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Below are the packages I've orphaned. See section [d] of the linked
email to see how many times each package is listed as Requires by
something else.
Most are Node.js packages, some still maintained via the 'nodejs-sig'
user, though 'nodejs-sig' can't own packages so I orphaned instead.
- compat-libuv010
- CutyCapt
- dateformat
- expresso
- jasmine-node
- js-json
- js-zlib
- marked
- mocha
- nodejs-abbrev
- nodejs-ain2
- nodejs-ansi
- nodejs-ansi-styles
- nodejs-archy
- nodejs-asap
- nodejs-asn1
- nodejs-assertplus
- nodejs-async
- nodejs-aws-sign
- nodejs-basic-auth-connect
- nodejs-batch
- nodejs-better-assert
- nodejs-bindings
- nodejs-block-stream
- nodejs-boom
- nodejs-buffer-crc32
- nodejs-buffer-equal
- nodejs-bunker
- nodejs-burrito
- nodejs-bytes
- nodejs-callsite
- nodejs-chalk
- nodejs-character-parser
- nodejs-charm
- nodejs-child-process-close
- nodejs-chmodr
- nodejs-chownr
- nodejs-cmd-shim
- nodejs-combined-stream
- nodejs-commander
- nodejs-component-emitter
- nodejs-config-chain
- nodejs-connect-timeout
- nodejs-console-dot-log
- nodejs-cookie
- nodejs-cookiejar
- nodejs-cookie-jar
- nodejs-cookie-parser
- nodejs-cookie-signature
- nodejs-couch-login
- nodejs-cryptiles
- nodejs-css
- nodejs-cssom
- nodejs-css-parse
- nodejs-css-stringify
- nodejs-csurf
- nodejs-ctype
- nodejs-cycle
- nodejs-debug
- nodejs-defined
- nodejs-delayed-stream
- nodejs-detective
- nodejs-diff
- nodejs-dryice
- nodejs-editor
- nodejs-ejs
- nodejs-escodegen
- nodejs-estraverse
- nodejs-esutils
- nodejs-eventemitter2
- nodejs-exit
- nodejs-expect-dot-js
- nodejs-express-session
- nodejs-faye-websocket
- nodejs-fileset
- nodejs-findup-sync
- nodejs-forever-agent
- nodejs-form-data
- nodejs-formidable
- nodejs-fresh
- nodejs-fstream
- nodejs-fstream-ignore
- nodejs-fstream-npm
- nodejs-generic-pool
- nodejs-getobject
- nodejs-github-url-from-git
- nodejs-glob
- nodejs-grip
- nodejs-growl
- nodejs-grunt-compare-size
- nodejs-grunt-contrib-concat
- nodejs-grunt-contrib-internal
- nodejs-grunt-contrib-uglify
- nodejs-grunt-contrib-watch
- nodejs-grunt-git-authors
- nodejs-gzip-size
- nodejs-has-color
- nodejs-hawk
- nodejs-hoek
- nodejs-hooker
- nodejs-http-signature
- nodejs-inherits1
- nodejs-ini
- nodejs-iso8601
- nodejs-isodate
- nodejs-jasmine-reporters
- nodejs-joose
- nodejs-joosex-namespace-depended
- nodejs-joosex-simplerequest
- nodejs-jscoverage
- nodejs-jsonfile
- nodejs-jsonify
- nodejs-json-stringify-safe
- nodejs-js-yaml
- nodejs-jwt-simple
- nodejs-keypress
- nodejs-lazystream
- nodejs-lockfile
- nodejs-markdown
- nodejs-maxmin
- nodejs-methods
- nodejs-mime
- nodejs-mimeparse
- nodejs-minimatch
- nodejs-minimist
- nodejs-morgan
- nodejs-ms
- nodejs-muffin
- nodejs-multiparty
- nodejs-mute-stream
- nodejs-nan0
- nodejs-ncp
- nodejs-node-int64
- nodejs-node-uuid
- nodejs-nopt
- nodejs-noptify
- nodejs-npmlog
- nodejs-npm-user-validate
- nodejs-oauth-sign
- nodejs-opener
- nodejs-optimist
- nodejs-opts
- nodejs-osenv
- nodejs-package
- nodejs-paperboy
- nodejs-parseurl
- nodejs-pause
- nodejs-pkginfo
- nodejs-pretty-bytes
- nodejs-promise
- nodejs-promzard
- nodejs-proto-list
- nodejs-pubcontrol
- nodejs-qs
- nodejs-range-parser
- nodejs-read
- nodejs-readdirp
- nodejs-read-package-json
- nodejs-reduce-component
- nodejs-repl
- nodejs-require-cs
- nodejs-requirejs
- nodejs-resolve
- nodejs-response-time
- odejs-response-time rpms
- nodejs-retry
- nodejs-rimraf
- nodejs-ronn
- nodejs-runforcover
- nodejs-sax
- nodejs-semver
- nodejs-serve-index
- nodejs-setimmediate
- nodejs-sha
- nodejs-shelljs
- nodejs-showdown
- nodejs-sigmund
- nodejs-slide
- nodejs-source-map
- nodejs-stack-trace
- nodejs-static-favicon
- nodejs-stream-counter
- nodejs-strip-ansi
- nodejs-superagent
- nodejs-supertest
- nodejs-tar
- nodejs-temp
- nodejs-temporary
- nodejs-testswarm
- nodejs-through
- nodejs-tiny-lr-fork
- nodejs-transformers
- nodejs-traverse
- nodejs-tunnel-agent
- nodejs-uglify-to-browserify
- nodejs-uid-number
- nodejs-underscore
- nodejs-underscore-dot-string
- nodejs-utile
- nodejs-vhost
- nodejs-walkdir
- nodejs-weak-map
- nodejs-websocket-driver
- nodejs-which
- nodejs-wordwrap
- nodejs-yamlish
- nodejs-zlib-browserify
- nodejs-zlibjs
- uglify-js1
- web-assets
Kind regards,
Jamie
3 years, 9 months
Autoclosure of review requests?
by Ben Cotton
In the weekly Fedora program update that I publish on
communityblog.fedoraproject.org, I have started to include a count of the
open package review requests. As of this moment, there are ~1300 open
review requests. Some of these were opened in 2006.
The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly
excludes review request bugs. Having a large number of open, ancient review
requests isn't exactly harmful, but it's not very helpful either.
Before I make a proposal to FPC, I thought I'd open a conversation here.
What does a reasonable cleanup of review requests look like?
My initial thought is to close all review requests that were opened >2
years ago, to be performed at the EOL closure for each release.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
Default editor for LXQt spin
by Raphael Groner
Hi,
writing to general devel list intentionally. No idea if all members of lxqt-sig list can read here, too and especially @zsun.
Is there any sense why @lxqt-sig is member of packaging for featherpad? LXQt SIG decided to have enki in the spin as the default editor. Featherpad is not part of LXQt upstream.
@lupinix Could you remove lxqt-sig from the members in pagure?
Regards, Raphael
3 years, 10 months
Fedora 33 Self-Contained Change proposal: No more automagic Python
bytecompilation phase 3
by Ben Cotton
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompi...
== Summary ==
See [[Changes/No_more_automagic_Python_bytecompilation]] and
[[Changes/No_more_automagic_Python_bytecompilation_phase_2]]. Now,
<code>%global _python_bytecompile_extra 1</code> won't be allowed
anymore and raises an error with a link to this change.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbalhar(a)redhat.com
== Detailed Description ==
See the [[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of the previous Change Proposal]] and the
[[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of its phase 2]].
Currently, Fedora rawhide contains ~130 packages with `%global
_python_bytecompile_extra 1` in their specfiles but surprisingly only
42 of them actually ship any .pyc files outside the standard location
<code>/usr/lib(64)?/python[0-9]\.[0-9]+</code>. That might be caused
by either of the following:
* there is nothing to byte-compile — the statement is a leftover to be removed
* The automagic bytecompilation uses <code>/usr/bin/python</code> by
default (for historical reasons) but <code>/usr/bin/python</code> is
not present in the buildroot by default.
Our plan is to finish the announced removal of this automagic Python
bytecompilation, remove it from packages where it's not necessary and
fix it with <code>%py_byte_compile</code> for packages where it's
needed.
The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix...
documentation] already contains the following paragraph:
If you have *.py files outside of the /usr/lib(64)?/pythonX.Y/
directories and you require those files to be byte compiled (e.g. it’s
an importable Python module) you MUST compile them explicitly using
the %py_byte_compile macro. Note that not all Python files are
importable Python modules; when in doubt, grep the sources for the
appropriate import statement.
so no changes have to be made there.
=== Affected packages ===
From 2020-05-20.
bugzilla
calamares
ceph
chromium
cinnamon-screensaver
edk2
eog-plugins
fish
fleet-commander-admin
fleet-commander-client
freecad
gaupol
gazebo
gdb
gedit
gedit-latex
gedit-plugins
git-cola
glusterfs
gnome-code-assistance
gnome-devel-docs
grass
gtk-doc
gtranslator
ibus
ibus-anthy
ibus-hangul
ibus-libpinyin
ibus-libzhuyin
ibus-pinyin
ibus-table
ibus-typing-booster
ibus-uniemoji
insight
kajongg
kdevelop-python
klatexformula
libpeas
libreoffice
libsmbios
libunity
lirc
lyx
mate-menu
mingw-glib2
mirrormanager2
odcs
onboard
otf2
paraview
pcs
php-opencloud-openstack
pygobject2
pygtk2
python-cherrypy
python-flask-silk
python-genshi
python-pycurl
python-reportlab
qpid-dispatch
rhythmbox
sems
sigul
soundconverter
sugar
sugar-abacus
sugar-browse
sugar-calculator
sugar-castle
sugar-chat
sugar-clock
sugar-colordeducto
sugar-countries
sugar-deducto
sugar-distance
sugar-finance
sugar-flip
sugar-flipsticks
sugar-fototoon
sugar-fractionbounce
sugar-getiabooks
sugar-imageviewer
sugar-implode
sugar-infoslicer
sugar-jukebox
sugar-kuku
sugar-labyrinth
sugar-locosugar
sugar-log
sugar-maze
sugar-measure
sugar-memorize
sugar-moon
sugar-nutrition
sugar-paint
sugar-physics
sugar-pippy
sugar-playgo
sugar-portfolio
sugar-pukllanapac
sugar-read
sugar-recall
sugar-record
sugar-ruler
sugar-speak
sugar-srilanka
sugar-starchart
sugar-stopwatch
sugar-story
sugar-terminal
sugar-turtleart
sugar-typing-turtle
sugar-view-slides
sugar-visualmatch
sugar-words
sugar-write
sugar-xoeditor
sugar-xoirc
sugar-yupana
synfigstudio
system-config-repo
system-switch-java
system-switch-mail
texlive
totem
transmageddon
ufw-kde
variety
virt-manager
vtk
xed
== Benefit to Fedora ==
More explicit specfiles when it comes to Python byte compilation. This
change also supports the dropping of unversioned
<code>%{__python}</code> macro.
== Scope ==
* Proposal owners: Change the brp-python-bytecompile script and macros
in redhat-rpm-config package, help with transforming the packages. See
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/87
* Other developers: Maintainers of the mentioned python packages will
have to change their packages to use explicit
<code>%py_byte_compile</code>
* Release engineering: No Release engineering work is needed for this change
* Policies and guidelines: nothing to be changed
* Trademark approval: not needed
== Upgrade/compatibility impact ==
None expected.
== How To Test ==
Build a package with <code>%global _python_bytecompile_extra 1</code>.
The build should fail with an actionable error message.
== User Experience ==
The users of this change are packagers. The new behavior should make
byte-compilation more obvious, explicit, and discoverable.
Users of Fedora should not feel this (except if this change uncovers a
packaging bug).
== Contingency Plan ==
* Contingency mechanism: revert the changes in redhat-rpm-config
* Contingency deadline: none (not a System Wide Change)
* Blocks release? no (not a System Wide Change)
* Blocks product? no
== Documentation ==
The guidelines already contain up-to-date documentation.
== Release Notes ==
This change does not deserve Release Notes, it is not user-facing.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 10 months
Many packages unnecessarily link to libpython
by Charalampos Stratakis
Hello everyone,
As of Python 3.8, python C extensions modules should not link to libpython, unless they embed the interpreter in their code. Relevant upstream PR: https://github.com/python/cpython/pull/12946
If your package links to libpython without requiring it, it won't be possible to use the python3-debug binary with your python C extension, unless you recompile the extension against it.
On Fedora Rawhide, there are at this point 144 packages linking to libpython, many of those possibly without any need for it.
If your package links to libpython but it does not embed the interpreter, I would like to ask you to unlink it. Usually the fix needs to be done at the package's build system.
If you are not sure if your package links to libpython, a way to figure this out is to inspect the code for the Py_Initialize and the Py_Finalize calls [0]. If the code includes those calls, no action is required from your side. If it does not, linking to libpython is not required.
I might mass file bugzillas at a later date, but I wanted to provide you the heads up before that.
[0] https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the...
List of possibly affected packages, provided through $ repoquery --repo=rawhide --source --whatrequires 'libpython3.8.so.1.0()(64bit)'
Maintainers by package:
COPASI sagitter
HepMC3 ellert
Io-language limb
OpenImageIO hobbes1069
PyQt4 rdieter than
YafaRay luya roma slaanesh
apbs rathann sagitter
babeltrace2 mjeanson
blender design-sw hobbes1069 ignatenkobrain kwizart luya roma s4504kr slaanesh
boost denisarnaud jwakely
calamares kkofler mattia
calibre chkr heliocastro kevin nushio zbyszek
cantor jreznik rdieter than
ceph adeza branto dmick ke4qqq kkeithle ktdreyer steve stingray
clingo thofmann
collectd fab kevin mhlavink ruben xaeth
condor bbockelm bcotton eerlands matt matyas stevetraylen tstclair ttheisen valtri
createrepo_c dmach jrohel mblaha pkratoch tmlcoch
csound pbrobinson sdz
cvc4 brouhaha jjames
dionaea rebus
dmlite adev andreamanzi gbitzes okeeble rocha
fontforge frixxon kevin pnemade
freecad hobbes1069 jkastner zultron
gdb jankratochvil keiths kevinb sergiodj
gdcm ankursinha ignatenkobrain mrceresa sebp
gdl orion
getdp ignatenkobrain smani
glade kalev
globus-net-manager ellert
glom hguemar
gnucash notting
gnuradio jskarvad mmahut
gpaw marcindulak
gplugin ignatenkobrain
gr-air-modes jskarvad
gr-fcdproplus jskarvad
gr-hpsdr jskarvad
gr-iqbal jskarvad
gr-osmosdr cottsay jskarvad
gr-rds jskarvad sharkcz
hamlib hobbes1069 jskarvad lucilanga
hexchat ohaessler tingping
hokuyoaist rmattes
hugin bpostle cicku denisarnaud
insight lkundrak monnerat
kdevelop-python dvratil jgrulich minh
kernel-tools jcline jforbes jwboyer labbott pbrobinson
kicad avigne coremodule lkundrak stevenfalco tnorth
kig jreznik kkofler rdieter
kitty atim
krita heliocastro rdieter
lammps ellio167 junghans
ldns pemensik pwouters thozza
libCombine sagitter
libarcus churchyard gferon
libarcus-lulzbot spot
libbatch smani
libcec pbrobinson
libcomps akozumpl dmach jluza jmracek mblaha pkratoch
libdnf dmach jmracek jrohel mblaha pkratoch
libftdi hobbes1069 lucilanga
libkml smani
libkolabxml tpokorra
libldb abbra asn gd iboukris jhrozek lslebodn sgallagh simo
libnuml sagitter
libpeas amigadave hadess nacho
libplist hadess pbrobinson
libreoffice caolanm dtardon erack sbergmann
librepo dmach pkratoch tmlcoch
libsavitar churchyard gferon
libsbml sagitter zbyszek
libsedml sagitter
libsigrokdecode mrnuke
libtalloc asn gd iboukris jhrozek lslebodn sgallagh simo
libyang tkorbar
libyui-bindings makowski ngompa tpokorra
link-grammar devos fabiand limb
lldb airlied daveisfera jankratochvil sergesanspaille siddharths tstellar
mapserver devrim jujens oliver pali
mathgl deji krege mycae
med smani
mod_wsgi jdornak jkaluza jorton lmacken mrunge
mraa pbrobinson
nautilus-python dignan genodeftest kalev
nbdkit rjones
nemo-extensions jcpunk leigh123linux
nest ankursinha
netgen-mesher hobbes1069 smani
neuron ankursinha
nextpnr lkundrak somlo
nordugrid-arc ellert jonkni
nwchem marcindulak
openbabel itamarjp jussilehtola rathann
openscap isimluk jcerny matyc mpreisle pvrabec wsato
opentrep denisarnaud
openvdb luya slaanesh
orocos-kdl thofmann
pam_wrapper asn jhrozek
paraview deji orion sagitter
perl-Inline-Python jonkni
pidgin jskarvad mcrha nosnilmot
pitivi company elad ignatenkobrain limb wtaymans
plplot orion
postgresql hhorak jstanek panovotn pkajaba pkubat praiskup tgl
pynac pcpa tomspur
pyotherside m4rtink
pythia8 ellert
python-caja monnerat raveit65
python-graph-tool ankursinha
python-gstreamer1 farnz wtaymans
python-jep raphgro
python-qt5 rdieter than
qgis bruno volter
qpid-dispatch irina tross
qpid-proton irina
rdkit giallu
rdma-core dledford honli jwilson
renderdoc gicmo
rmol denisarnaud
root ellert
samba abbra anoopcs asn gd iboukris jarrpa jlayton jstephen obnox simo
scidavis alexpl
scribus pwalter sharkcz tripledes
sigil sharkcz
sourcextractor++ aalvarez
swift-lang tachoknight
syslog-ng czanik jpo mrunge
texworks cheeselee
thunarx-python balajig8 kevin nonamedotc
trademgen denisarnaud
trellis lkundrak somlo
unbound aegorenk akhaitov pavlix pemensik pwouters thozza
upm pbrobinson
uwsgi kad
vapoursynth slaanesh
vdr-epg-daemon martinkg
vigra bpostle
vim karsten zdohnal
vrpn bizdelnick
vtk jgu mrceresa orion
weechat asrob gchamoul hguemar niveusluna stingray
znc elyscape nb
Packages by maintainer:
aalvarez sourcextractor++
abbra libldb samba
adev dmlite
adeza ceph
aegorenk unbound
airlied lldb
akhaitov unbound
akozumpl libcomps
alexpl scidavis
amigadave libpeas
andreamanzi dmlite
ankursinha gdcm nest neuron python-graph-tool
anoopcs samba
asn libldb libtalloc pam_wrapper samba
asrob weechat
atim kitty
avigne kicad
balajig8 thunarx-python
bbockelm condor
bcotton condor
bizdelnick vrpn
bpostle hugin vigra
branto ceph
brouhaha cvc4
bruno qgis
caolanm libreoffice
cheeselee texworks
chkr calibre
churchyard libarcus libsavitar
cicku hugin
company pitivi
coremodule kicad
cottsay gr-osmosdr
czanik syslog-ng
daveisfera lldb
deji mathgl paraview
denisarnaud boost hugin opentrep rmol trademgen
design-sw blender
devos link-grammar
devrim mapserver
dignan nautilus-python
dledford rdma-core
dmach createrepo_c libcomps libdnf librepo
dmick ceph
dtardon libreoffice
dvratil kdevelop-python
eerlands condor
elad pitivi
ellert HepMC3 globus-net-manager nordugrid-arc pythia8 root
ellio167 lammps
elyscape znc
erack libreoffice
fab collectd
fabiand link-grammar
farnz python-gstreamer1
frixxon fontforge
gbitzes dmlite
gchamoul weechat
gd libldb libtalloc samba
genodeftest nautilus-python
gferon libarcus libsavitar
giallu rdkit
gicmo renderdoc
hadess libpeas libplist
heliocastro calibre krita
hguemar glom weechat
hhorak postgresql
hobbes1069 OpenImageIO blender freecad hamlib libftdi netgen-mesher
honli rdma-core
iboukris libldb libtalloc samba
ignatenkobrain blender gdcm getdp gplugin pitivi
irina qpid-dispatch qpid-proton
isimluk openscap
itamarjp openbabel
jankratochvil gdb lldb
jarrpa samba
jcerny openscap
jcline kernel-tools
jcpunk nemo-extensions
jdornak mod_wsgi
jforbes kernel-tools
jgrulich kdevelop-python
jgu vtk
jhrozek libldb libtalloc pam_wrapper
jjames cvc4
jkaluza mod_wsgi
jkastner freecad
jlayton samba
jluza libcomps
jmracek libcomps libdnf
jonkni nordugrid-arc perl-Inline-Python
jorton mod_wsgi
jpo syslog-ng
jreznik cantor kig
jrohel createrepo_c libdnf
jskarvad gnuradio gr-air-modes gr-fcdproplus gr-hpsdr gr-iqbal gr-osmosdr gr-rds hamlib pidgin
jstanek postgresql
jstephen samba
jujens mapserver
junghans lammps
jussilehtola openbabel
jwakely boost
jwboyer kernel-tools
jwilson rdma-core
kad uwsgi
kalev glade nautilus-python
karsten vim
ke4qqq ceph
keiths gdb
kevin calibre collectd fontforge thunarx-python
kevinb gdb
kkeithle ceph
kkofler calamares kig
krege mathgl
ktdreyer ceph
kwizart blender
labbott kernel-tools
leigh123linux nemo-extensions
limb Io-language link-grammar pitivi
lkundrak insight kicad nextpnr trellis
lmacken mod_wsgi
lslebodn libldb libtalloc
lucilanga hamlib libftdi
luya YafaRay blender openvdb
m4rtink pyotherside
makowski libyui-bindings
marcindulak gpaw nwchem
martinkg vdr-epg-daemon
matt condor
mattia calamares
matyas condor
matyc openscap
mblaha createrepo_c libcomps libdnf
mcrha pidgin
mhlavink collectd
minh kdevelop-python
mjeanson babeltrace2
mmahut gnuradio
monnerat insight python-caja
mpreisle openscap
mrceresa gdcm vtk
mrnuke libsigrokdecode
mrunge mod_wsgi syslog-ng
mycae mathgl
nacho libpeas
nb znc
ngompa libyui-bindings
niveusluna weechat
nonamedotc thunarx-python
nosnilmot pidgin
notting gnucash
nushio calibre
obnox samba
ohaessler hexchat
okeeble dmlite
oliver mapserver
orion gdl paraview plplot vtk
pali mapserver
panovotn postgresql
pavlix unbound
pbrobinson csound kernel-tools libcec libplist mraa upm
pcpa pynac
pemensik ldns unbound
pkajaba postgresql
pkratoch createrepo_c libcomps libdnf librepo
pkubat postgresql
pnemade fontforge
praiskup postgresql
pvrabec openscap
pwalter scribus
pwouters ldns unbound
raphgro python-jep
rathann apbs openbabel
raveit65 python-caja
rdieter PyQt4 cantor kig krita python-qt5
rebus dionaea
rjones nbdkit
rmattes hokuyoaist
rocha dmlite
roma YafaRay blender
ruben collectd
s4504kr blender
sagitter COPASI apbs libCombine libnuml libsbml libsedml paraview
sbergmann libreoffice
sdz csound
sebp gdcm
sergesanspaille lldb
sergiodj gdb
sgallagh libldb libtalloc
sharkcz gr-rds scribus sigil
siddharths lldb
simo libldb libtalloc samba
slaanesh YafaRay blender openvdb vapoursynth
smani getdp libbatch libkml med netgen-mesher
somlo nextpnr trellis
spot libarcus-lulzbot
steve ceph
stevenfalco kicad
stevetraylen condor
stingray ceph weechat
tachoknight swift-lang
tgl postgresql
than PyQt4 cantor python-qt5
thofmann clingo orocos-kdl
thozza ldns unbound
tingping hexchat
tkorbar libyang
tmlcoch createrepo_c librepo
tnorth kicad
tomspur pynac
tpokorra libkolabxml libyui-bindings
tripledes scribus
tross qpid-dispatch
tstclair condor
tstellar lldb
ttheisen condor
valtri condor
volter qgis
wsato openscap
wtaymans pitivi python-gstreamer1
xaeth collectd
zbyszek calibre libsbml
zdohnal vim
zultron freecad
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
3 years, 10 months
RFC: Automatically generated BuildRequires for maven-based Java projects
by Fabio Valentini
Good $LOCAL_TIME_OF_DAY,
I've been working on experimental support for automatically generating
BuildRequires for maven-based Java projects, and it's now available
for testing in rawhide (and in fedora 32, for local testing).
There's no "macro support" for this yet, because it's still
work-in-progress, though when it proves useful support for it might
eventually get merged into the Java packaging macros directly.
The good new is: it should basically "just work" if your package isn't
doing anything weird, but this is Java we're talking about, so there's
at least three limitations I can think of right now (the bad news):
1. no built-in blacklist for irrelevant plugins yet (e.g. maven-release-plugin)
2. no support for different profiles yet
3. no support for plugins that add additional dependencies in their
configuration
There are workarounds for the first two limitations:
1. It's pretty easy to just disable those plugins manually in %prep
with "%pom_remove_plugin :maven-foo-plugin".
2. If you know ahead of time which submodules will get activated (e.g.
based on a previous package build), just specify those modules on the
mvn-genbr command line instead of letting mvn-genbr fail to find them.
3. just continue to specify those non-discoverable dependencies manually
Usage in .spec files should be pretty simple, and similar to how other
tools handle generated BuildRequires:
- replace all java / "mvn(foo:bar)" dependencies with "BuildRequires:
mvn-genbr",
- but keep "BuildRequires: maven-local" (this is not automatically generated).
- keep your "pom.xml" modifications in %prep, as usual (e.g. removing
unnecessary maven plugins, changing dependencies, modifying XML with
XPath queries)
- add the following section to your .spec after %prep:
%generate_buildrequires
mvn-genbr -t .
If you're not running the test suite (%mvn_build -f), then drop the -t
/ --with-tests flag. If the root directory of the maven project is not
the toplevel directory, specify the name of the root directory /
directories instead of "." (mvn-genbr accepts multiple arguments for
this purpose. use "mvn-genbr --help" for current list of command line
options).
If you want to check out what automatic dependencies mvn-genbr will
generate for your package, you can try it without kicking off a
package build by dnf-installing "mvn-genbr" (available fedora 32+),
and running it with the same arguments as in your .spec file in the
source directory that's generated and processed by "fedpkg prep".
Comparisons between the generated dependency lists and those that were
curated "manually" would be of interest, especially for bug reports :)
Since this is still work-in-progress (though it works for a few simple
packages I tried it with), please feel free to report your
experiences, and - more importantly - open issues when the tool either
crashes (it shouldn't, since the POM parser successfully parsed all
non-broken maven project files from all fedora packages), or when it
generates too many (not that problematic) or too few (not so good)
dependencies.
The code for the POM parser and mvn-genbr lives in this project on pagure:
https://pagure.io/ironthree/pommes
Go forth and break my code!
Fabio
3 years, 10 months