Orphaned some Java packages
by Mikolaj Izdebski
I've just orphaned 259 packages listed below. Almost all of them are
Java packages which I will continue to maintain as part of modules.
Intent to orphan them was already announced on java-devel [1] and
devel [2] lists, with detailed reasoning.
Originally planned time of orphaning was delayed because I was hoping
that modular packages could be allowed to be used in buildroots of
non-modular packages (ursa-major proposal [3]), which would allow me
to retire these packages and replace them with modular versions
instead, but the proposal was recently rejected.
[1] https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproj...
[2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[3] https://pagure.io/fesco/issue/2003
The list of orphaned packages follows.
aether-connector-okhttp
ant
ant-antunit
ant-contrib
antlr3
antlr4
aopalliance
apache-commons-beanutils
apache-commons-collections
apache-commons-collections4
apache-commons-compress
apache-commons-configuration
apache-commons-csv
apache-commons-daemon
apache-commons-discovery
apache-commons-el
apache-commons-fileupload
apache-commons-io
apache-commons-jexl
apache-commons-jxpath
apache-commons-lang
apache-commons-lang3
apache-commons-logging
apache-commons-net
apache-ivy
apache-james-project
apache-logging-parent
apache-mime4j
apache-parent
apache-rat
apache-resource-bundles
apiguardian
aqute-bnd
args4j
atinject
avalon-framework
avalon-logkit
base64coder
batik
bcel
bea-stax
beust-jcommander
bsf
bsh
byaccj
cal10n
checkstyle
codemodel
dain-snappy
decentxml
dom4j
easymock
eclipse-m2e-antlr
eclipse-m2e-buildhelper
eclipse-m2e-core
eclipse-m2e-cxf
eclipse-m2e-egit
eclipse-m2e-mavenarchiver
eclipse-m2e-maven-dependency-plugin
eclipse-m2e-mavendev
eclipse-m2e-modello
eclipse-m2e-plexus
eclipse-m2e-sisu
eclipse-m2e-sourcelookup
eclipse-m2e-takari
eclipse-m2e-tycho
eclipse-m2e-workspace
exec-maven-plugin
felix-bundlerepository
felix-osgi-core
felix-osgi-obr
felix-utils
geronimo-jaspic-spec
geronimo-jms
geronimo-jpa
geronimo-jta
geronimo-parent-poms
glassfish-dtd-parser
glassfish-fastinfoset
glassfish-jaxb
glassfish-jsp
glassfish-jsp-api
google-gson
google-guice
gpars
gradle
groovy
guava20
hawtjni
hsqldb
httpcomponents-client
httpcomponents-core
httpcomponents-project
httpunit
icu4j
istack-commons
jackson
jakarta-commons-httpclient
jansi
jansi-native
javacc
javacc-maven-plugin
javamail
java-service-wrapper
javassist
jaxen
jchardet
jdepend
jdependency
jeromq
jettison
jetty
jetty8
jetty-alpn
jetty-alpn-api
jetty-artifact-remote-resources
jetty-assembly-descriptors
jetty-build-support
jetty-distribution-remote-resources
jetty-parent
jetty-schemas
jetty-test-helper
jetty-test-policy
jetty-toolchain
jetty-version-maven-plugin
jflex
jmapviewer
jna
joda-convert
jortho
jsch-agent-proxy
json_simple
jsoup
jsr-311
junit
junit5
jvnet-parent
kohsuke-pom
kxml
log4j
maven
maven-antrun-plugin
maven-archetype
maven-archiver
maven-artifact-resolver
maven-artifact-transfer
maven-assembly-plugin
maven-clean-plugin
maven-compiler-plugin
maven-dependency-analyzer
maven-dependency-plugin
maven-dependency-tree
maven-doxia
maven-doxia-sitetools
maven-enforcer
maven-file-management
maven-filtering
maven-gpg-plugin
maven-idea-plugin
maven-indexer
maven-invoker
maven-jar-plugin
maven-jarsigner-plugin
maven-javadoc-plugin
maven-mapping
maven-osgi
maven-parent
maven-plugin-build-helper
maven-plugin-bundle
maven-plugins-pom
maven-plugin-testing
maven-plugin-tools
maven-reporting-api
maven-reporting-exec
maven-reporting-impl
maven-repository-builder
maven-resolver
maven-script-interpreter
maven-shade-plugin
maven-shared-incremental
maven-shared-io
maven-shared-jar
maven-shared-jarsigner
maven-shared-utils
maven-site-plugin
maven-source-plugin
maven-stapler-plugin
maven-surefire
maven-toolchains-plugin
maven-verifier
maven-wagon
mnemonicsetter
modello
mojo-parent
multiverse
munge-maven-plugin
nasm
nekohtml
netty
objectweb-asm3
objectweb-pom
okio
opentest4j
osgi-compendium
osgi-core
os-maven-plugin
plexus-ant-factory
plexus-archiver
plexus-bsh-factory
plexus-classworlds
plexus-cli
plexus-compiler
plexus-component-factories-pom
plexus-components-pom
plexus-containers
plexus-digest
plexus-i18n
plexus-interactivity
plexus-interpolation
plexus-io
plexus-languages
plexus-resources
plexus-utils
plexus-velocity
qdox
regexp
sdljava
SimplyHTML
sisu
sisu-mojos
slf4j
snakeyaml
sonatype-oss-parent
sonatype-plugins-parent
stax2-api
stringtemplate4
tagsoup
takari-archiver
takari-filemanager
takari-incrementalbuild
takari-lifecycle
takari-plugin-testing
takari-pom
takari-tycho-support
txw2
univocity-parsers
velocity
woodstox-core
xalan-j2
xbean
xml-maven-plugin
xmlrpc
xmvn
xom
xsom
xstream
xz-java
zinc
zopfli
--
Mikolaj Izdebski
4 years, 11 months
Blocking criteria proposal for F30+: Printing
by Stephen Gallagher
There was a bug[1] filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
following drivers:
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
user base).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
4 years, 12 months
Proposal: Stewardship Group / SIG for taking care of otherwise
"module-only" packages
by Fabio Valentini
Hi everybody,
In the past few weeks, it has come up regularly that future
"module-only" packages are orphaned (and hence will soon be retired),
and nobody stepped up to fix this issue - especially for non-leaf
packages. I don't think fedora as a project has a solution for this
yet.
I propose to create a "Stewardship" Group / SIG that will take care of
such packages - either until a new main maintainer steps up, or until
modularity matures enough so it won't be necessary anymore. (Or, until
it dies a quiet death, which is always a possibility.) However, I
think this is necessary until the situation stabilizes.
Comments and future contributors are very welcome.
Fabio
5 years
Can we please stop enforcing Signed-off-by commits?
by Miro Hrončok
It happened to me almost dozen times now, so here's my rage :D
I want to send a pull request to a Fedora project*, I clone it, fork it, push to
the fork, open a PR and there it goes:
! This repo requires all commits to have the Signed-off-by whatnot in them !
So I have to go again, amend with -s, push force. That is tedious and at least I
know how to do that. I assume there are people who don't.
Can we stop this nonsense? I usually smuggle something like:
Signed-off-by: Stop This <pretty(a)plea.se>
And nobody ever cares! The thing is enforced only because it can be enforced.
The line in that commit message is totally useless and doesn't provide any
benefit, just pain. I've signed the Fedora Project Contributor Agreement. That
should be enough.
Now a bit more serious:
What information am I missing? Why do Fedora upstreams enforce this?
Thanks
(* last time it was simple-koji-ci, but it's also fedpkg and other projects on
pagure.io)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 years
Tracking translation status of a package built in koji
by Sundeep Anand
Hi Everyone,
At times this could be a requirement to track or know translation status of a package which has (just) built in koji.
Transtats could be used for this purpose. We just need to run a job.
Steps:
1. Navigate to https://transtats-web-transtats.app.os.stg.fedoraproject.org/jobs/yml-based
2. Select 'Sync Package Build System' job template and proceed.
3. You may read and continue with the tasks defined in YML.
4. Select or enter package name. For example: anaconda.
Select Build System and Tag. For example: koji and rawhide
Click 'Next'
5. And run the job. Upon successful completion an unique URL will be created.
This could really be helpful. We are working on creating alerts or warnings.
Feel free to share comments on this here: http://feedback.transtats.xyz
thanks,
sundeep
5 years
HEADS UP: dhcp will ship bunded bind libraries
by Pavel Zhukov
All,
tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring
dhcp-libs-static with bundled version of libisc/libdns/etc
As ISC dropped support of single thread build of BIND libraries [1] and
dhcp requires one we decided to not patch dhcp/bind build scripts anymore
and ship bundled bind libraries just like upstream (ISC) does it. It will
allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be
expected in rawhide/F31 soon!
I'm aware of FPG recommendation to avoid shipping of bundled libraries due
to its maintenance cost but maintaining of heavy patched build sctipts and
inability to ship newer versions are even worse.
I have not find any application in Fedora repository which link with
libdhcp/libomapi. Please let me know if you aware of any.
[1] https://ftp.isc.org/isc/bind9/9.13.3/RELEASE-NOTES-bind-9.13.3.html
--
Pavel
5 years
F31 System-Wide Change proposal: BuildRequires Generators
by Ben Cotton
https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
= BuildRequires Generators =
== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
Festi]], [[User:msuchy|Miroslav Suchý]]
* Email: ignatenkobrain(a)fedoraproject.org, ffesti(a)redhat.com, miroslav(a)suchy.cz
== Detailed Description ==
For many languages (Rust, Golang, Node.Js, Ruby, Python),
BuildRequires can be automatically generated. All it takes, run some
special tool which will output dependencies in RPM format.
Q: How will it work under the hood?
A: When you build RPM, something like this will happen under the hood…
# rpm would perform %prep (which is supposed to abort if some
dependencies missing and print them)
# mock would install those dependencies and resume build
Q: Will src.rpm contain all generated dependencies?
A: This is not known yet, we'll update page once it is known.
Q: Does this mean that package builds won't be reproducible anymore?
A: No, as long as you have same buildroot and tool which is generating
BuildRequires is doing so in reproducible manner, it should not affect
reproducibility.
== Benefit to Fedora ==
Packagers won't have to pre-generate BuildRequires in the spec file
which means it will be always updated (and correct) :
* Packagers can focus of making their packages better instead of
spending all their packaging time copying BuildRequires from
documentation and third party tools.
* BuildRequires are dropped as soon as they're no longer necessary
* Packages can be easily bumped without requiring a manual BuildRequires refresh
* BuildRequires and Requires generation can use similar utilities,
making sure that the deps packages declare can also be used for
second-level building. Packages no longer need to declare the deps of
their second and n-th dependencies because someone forgot to declare
them in the correct package.
== Scope ==
* Proposal owners: Implement support for a feature in RPM and mock (if
implemented properly, Koji should just work). Make use of it in Rust
ecosystem.
* Other developers: Maintainers of language stacks are advised to use
this feature.
* Release engineering: [https://pagure.io/releng/issue/8129 #8129]
* Policies and guidelines: Packaging Guidelines need to be updated
with instructions how to use this feature.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Packagers and users who use repoquery might be affected (src.rpm might
not contain generated dependencies).
== How To Test ==
TBD.
== User Experience ==
Users won't notice differences.
== Dependencies ==
Required feature needs to be implemented in RPM and mock.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
Owners might still ship feature disabled for Fedora buildsystem but
have it available for end-users, and move full completion to the next
release.
* Contingency deadline: Beta Freeze
* Blocks release? No.
* Blocks product? No.
== Documentation ==
TBD.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years
modular repositories in mock configs: please don't
by Fabio Valentini
Hi everybody,
Recently, modular repositories were enabled in the mock configs for fedora 29+.
Now, I can't build at least one of my packages (elementary-music) in
fedora 29 chroots, due to dependency issues within modules. dnf just
gives up with this rather unhelpful message:
Problem: cannot install the best candidate for the job
- package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded
I don't want or need modules installed for this package to build.
See: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-90...
IMO it was a mistake to enable modular repositories in mock configs by
default. Now dnf only downloads even more metadata for no benefit (or,
it even breaks dependency resolution, as in this case).
Do I really have to manually edit mock's config files to disable
modular repos, to get builds equivalent to koji (where modules aren't
available / usable either)? I want to test builds locally, before I
push them to koji builders ...
Any insights why this was done?
Can it be fixed please?
Or am I the only one having problems?
Fabio
5 years
Proposal: Abandon v8 package
by Tom Callaway
Background:
I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:
1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).
3. Virtually all consumers of v8 (including chromium) take a git
checkout (not a specific one, just whatever they decided to code to) and
use that revision, often creating a local fork of v8 from that revision,
as they are either unwilling or unable to track v8 upstream.
4. Since v8 has no concept of a "stable" release that I can see, they
simply do security fixes to the master branch, which, combined with the
code changing violently, makes it very difficult to backport security fixes.
This means that other than plv8 (which is currently unable to build
against the current v8 package in Fedora), I do not see any consumers of
the Fedora v8 package (chromium has long since abandoned any possibility
of using it). It does contain a "d8" binary, which is a javascript CLI
debugger, but it is not clear to me that this is widely used, or that
the benefit of its inclusion in Fedora outweighs the pain of maintaining
this package.
Thus, I propose that the v8 package be abandoned/orphaned/taken to the
farm upstate to run and play with the other dogs.
If you disagree, or are crazy enough to want to take it over, speak now.
~tom
P.S. I'll still maintain v8-314 as best I can, since there are actually
users of that. The irony of that really ancient version being considered
stable (and thus, used by other software) as a result of Fedora sticking
on that version of v8 for so many releases is not lost on me.
5 years