Re: List of long term FTBFS packages to be retired in August
On Tue, Jul 25, 2023 at 2:48 PM Hans de Goede wrote: > > xmvn-connector-ivymizdebsk > > This one has a long long list of deps which will break if it is > retired and there is a pull-req here fixing the FTBFS: > > https://src.fedoraproject.org/rpms/xmvn-connector-ivy/pull-request/2 > > Are there any objections against solving it with the rebase to > a newer git snapshot (it already is a git snapshot) ? > > If not then I'll use my proven-packager rights to get this > pull-request merge and close the FTBFS bug. > > Mikolaj any objections against merging the pull-request ? I made a new upstream release of version 4.0.0 and updated the package to the latest version. Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-41256115ad > > Miro can you hold of on retiring xmvn-connector-ivy please ? > > Regards, > > Hans > > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Apache Maven 3.9 update in Fedora
Package maven in Fedora Rawhide will be updated from version 3.8.6 to version 3.9.1 on 31 March 2023. This minor version update contains breaking behavioral changes that are known to affect some packages. More information can be found in upstream release notes at https://maven.apache.org/docs/3.9.0/release-notes.html I will take care of fixing packages listed on https://versions.kjnet.xyz/ There is no API/ABI break that I know of, so I'm not CCing maintainers of dependent packages directly. Packages are known to require or build-require maven: - DecodeIR - IPAddress - ant-antunit - antlr-maven-plugin - antlr3 - antlr32 - antlr4-project - antlrworks - apache-commons-beanutils - apache-commons-cli - apache-commons-collections - apache-commons-collections4 - apache-commons-compress - apache-commons-digester - apache-commons-exec - apache-commons-fileupload - apache-commons-jxpath - apache-commons-logging - apache-commons-math - apache-commons-modeler - apache-commons-net - apache-commons-parent - apache-commons-pool - apache-parent - apache-resource-bundles - apache-sshd - apiguardian - aqute-bnd - args4j - assertj-core - atinject - auto - batik - bcel - beust-jcommander - build-helper-maven-plugin - buildnumber-maven-plugin - byte-buddy - byteman - canl-java - cdi-api - cglib - classloader-leak-test-framework - classpathless-compiler - clojure - clojure-core-specs-alpha - clojure-maven-plugin - clojure-spec-alpha - codehaus-parent - decentxml - directory-maven-plugin - dirgra - disruptor - dogtag-pki - dom4j - easymock - ed25519-java - exec-maven-plugin - extra-enforcer-rules - fasterxml-oss-parent - felix-parent - felix-utils - fishbowl - fop - forge-parent - fusesource-pom - google-gson - hamcrest - hawtjni - hibernate-jpa-2.0-api - hibernate-jpa-2.1-api - hid4java - httpcomponents-project - jackson-annotations - jackson-bom - jackson-core - jackson-databind - jackson-dataformats-binary - jackson-dataformats-text - jackson-jaxrs-providers - jackson-modules-base - jackson-parent - jacoco - jacop - jakarta-activation - jakarta-activation1 - jakarta-annotations - jakarta-el - jakarta-interceptors - jakarta-json - jakarta-mail - jakarta-saaj - jakarta-server-pages - jakarta-servlet - jakarta-xml-ws - janino - jansi - jansi-native - jansi1 - java-diff-utils - java-dirq - java-jd-decompiler - java-runtime-decompiler - java-scrypt - javacc-maven-plugin - javaewah - javapackages-tools - javaparser - javapoet - javassist - jaxb - jaxb-api - jaxb-api2 - jaxb-dtd-parser - jaxb-fi - jaxb-istack-commons - jaxb-stax-ex - jaxen - jboss-jaxrs-2.0-api - jboss-logging - jboss-logging-tools - jboss-parent - jchardet - jcommon - jdeparser - jdependency - jetty - jflex - jfreechart - jgit - jglobus - jgoodies-common - jgoodies-forms - jgoodies-looks - jigawatts - jline - jline2 - jmock - jneuroml-core - jni-inchi - jol - jolokia-jvm-agent - joni - jopt-simple - jsch - jsch-agent-proxy - json_simple - junit - junit5 - juniversalchardet - jzlib - log4j - lucene - mariadb-java-client - maven - maven-antrun-plugin - maven-archetype - maven-archiver - maven-artifact-transfer - maven-assembly-plugin - maven-bundle-plugin - maven-clean-plugin - maven-common-artifact-filters - 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-invoker - maven-invoker-plugin - maven-jar-plugin - maven-mapping - maven-native - maven-parent - maven-patch-plugin - maven-plugin-testing - maven-plugin-tools - maven-remote-resources-plugin - maven-reporting-api - maven-reporting-impl - maven-resources-plugin - maven-script-interpreter - maven-shade-plugin - maven-shared-incremental - maven-shared-io - maven-shared-utils - maven-source-plugin - maven-surefire - maven-verifier - maven-verifier-plugin - maven2 - mockito - modello - modulemaker-maven-plugin - mojo-executor - mojo-parent - munge-maven-plugin - mxparser - nom-tam-fits - objectweb-asm - objenesis - ongres-scram - ongres-stringprep - openjdk-asmtools - openjdk-asmtools7 - openjfx - openstack-java-sdk - opentest4j - options - osgi-annotation - osgi-compendium - osgi-core - parserng - pcfi - pdfbox - picocli - plexus-active-collections - plexus-archiver - plexus-build-api - plexus-compiler - plexus-component-api - plexus-components-pom - plexus-containers - plexus-i18n - plexus-languages - plexus-pom - plexus-resources - plexus-utils - plexus-velocity - pomchecker - postgresql-jdbc - prometheus-jmx-exporter - prometheus-simpleclient-java - python-javaobj - qdox - rachota - reflections - replacer - resteasy - rhino - rsyntaxtextarea - scala - scalacheck - scannotation - sequence-library - serp - sisu-mojos - snakeyaml - spec-version-maven-plugin - spice-parent - string-template-maven-plugin - stringtemplate4 - svnkit - t-digest - testng - tomcat-taglibs-parent - treelayout - trilead-ssh2 - truth - tuxguitar - univocity-parsers - velocity -
Google Guice 5 update in Fedora
Package google-guice in Fedora Rawhide will be updated from version 4.2.3 to version 5.1.0 on 31 March 2023. This major version update breaks ABI and API, so I'm sending this notice one week in advance, per Fedora Updates Policy. Packages that require or build-require google-guice: - maven - maven-resolver - maven-shade-plugin - modello - pomchecker - sisu - testng - xmvn I will take care of porting all above packages except pomchecker. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On Mon, Jan 23, 2023 at 12:22 AM Jerry James wrote: > > On Fri, Jan 20, 2023 at 9:52 PM Jerry James wrote: > > > maven-scm mizdebsk, trawets > > > > For those affected by this, I've made a COPR with a possible > > resolution: > > https://copr.fedorainfracloud.org/coprs/jjames/buildnumber-maven-plugin/. > > Things to note: > > > > - plexus-interactivity must be unretired. > > - I first tried updating maven-scm to version 1.13.0, but it requires > > an older version of jgit than we have in Fedora Rawhide. It would not > > build. I had to go to 2.0.0-M3 to get a successful build. > > - There is a possible XMvn bug affecting maven-scm. See the comment > > in the %build section. There are duplicate entries in .xmvn-reactor > > for every pom.xml that includes pom. I'm not > > certain if this is an XMvn bug, or if the maven-scm pom.xml files are > > wrong somehow. > > - buildnumber-maven-plugin version 1.4 was too old, so I moved all the > > way to 3.0.0. Even then, it needed a small patch to work with > > maven-scm 2.0.0. > > > > Or we can all remove mvn-scm and buildnumber-maven-plugin from our > > respective packages' POMs. > > I should note that I intend to do the latter for jakarta-json. If > somebody wants to keep maven-scm or buildnumber-maven-plugin in > Fedora, feel free to take anything you want from that COPR, remove my > name, and slap your own in there. I'm not going to do it, however. I am in favor of removing buildnumber-maven-plugin. In all my packages this plugin is explicitly disabled as it is not very useful for building Fedora packages. -- Mikolaj Izdebski > > Regards, > -- > Jerry James > https://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Let's enable Koschei for all packages automatically
On Wed, Aug 31, 2022 at 3:57 PM Stephen Smoogen wrote: > > > > On Tue, 30 Aug 2022 at 14:16, Mikolaj Izdebski wrote: >> >> On Thu, Aug 25, 2022 at 9:53 AM Miro Hrončok wrote: >> >> To submit more scratch builds we would need larger builder capacity. >> This doesn't necessarily mean more or better hardware. >> Better Koji configuration would help a lot. >> We have some very powerful builders with up to 224 processors, but >> their capacity is set to 2. >> This means that the builder stops accepting new tasks once load gets >> to 2, which is less than 1 %. >> >> Example buildhw-a64-20.iad2.fedoraproject.org >> Capacity is 2, check with: koji hostinfo >> buildhw-a64-20.iad2.fedoraproject.org >> 224 CPUs, load average: 2.04, 2.07, 2.05 >> memory: 251Gi total, 7.3Gi used, 242Gi available >> Yet, at the time of writing the builder is marked as not ready (!!) >> for taking more builds due to exceeded capacity. >> >> This is not an individual case, we have many builders like that. >> > > I believe there are 2 builders with 224 CPU's. They are both 'prototype' > aarch64 systems we got on loan from a vendor and are tempermental. They do > not have good disk IO and do not have the capability of increasing the disk > IO. This means that you have a very very fast cpu and slow as treacle disk > io. The network on them has also been 'fun' where if the net access got too > high, it would require a complete power cycle with the plugs pulled out > because the BMC is not licensed. Slow disk could be worked around by using tmpfs for mock chroots - there is lots of free memory. I was not aware of the networking issues. -- Mikolaj Izdebski > > Most of the 'big' builders I remember are similar in hardware.. They look > great on paper, but if you try to give them a large capacity you end up with > even slower builds because they are loaners or spares which are good for > specific workloads and not general usage. > > > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. -- > Ian MacClaren > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Let's enable Koschei for all packages automatically
On Wed, Aug 31, 2022 at 4:03 PM Miro Hrončok wrote: > > On 30. 08. 22 20:15, Mikolaj Izdebski wrote: > >> 2) One-time enablement of all existing packages > >> > >> That should be doable. Right? > >> > >> > >> 3) Automatic enablement of all new packages > >> > >> That should be just a matter of changing the defaults. Correct? > > I can implement points 2 and 3 easily, as long as there is consensus to do > > so. > > I plan to propose a Fedora Linux 38 change proposal for this to get consensus. > Should I list you as a change owner? I don't think the Change process is needed for this infrastructure change. But if you like to, feel free to. I can be a co-owner if you like. My plan was to bring this topic to the infrastructure list and gather more feedback there. Unless there were any objections I would proceed to implement the proposal after Fedora 37 beta freeze - end of September. I would rather not implement this during infra freeze as this change is likely to put more load on services Koschei depends on. -- Mikolaj Izdebski > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Let's enable Koschei for all packages automatically
On Fri, Aug 26, 2022 at 10:09 AM Vít Ondruch wrote: > > > Dne 25. 08. 22 v 16:38 Fabio Valentini napsal(a): > > On Thu, Aug 25, 2022 at 4:34 PM Ankur Sinha wrote: > >> On Thu, Aug 25, 2022 15:58:12 +0200, Fabio Valentini wrote: > >>> Yeah that should be pretty simple. Get list of source packages in > >>> $release, paste it into the "Add packages" page, set release combobox > >>> to $release, submit. > >>> I do that regularly for all Rust packages. > >> The rust-sig packages are also set to automatically be tracked by > >> Koschei from the looks of it and I expect this can then be done for all > >> packages instead of for individual SIGs: > >> > >> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/koschei/vars/production.yml#_45 > > As far as I understand, this only automatically adds packages that are > > associated with the "@rust-sig" group on dist-git to the "rust-sig" > > group on koschei. > > We still need to manually enable tracking for new packages, but > > syncing group membership is automatic. > > > https://pagure.io/fedora-infra/ansible/blob/c2c063d22fe9a36b167fd27496aa1bd832ff1ca7/f/roles/openshift-apps/koschei/vars/production.yml#_47 > > https://github.com/fedora-infra/koschei/blob/master/bin/koschei-track-group > > Checking these two ^^ I'd say that the whole group is automatically tracked. That is correct. All packages for which rust-sig dist-git group is a watcher (configurable in dist-git) are added to rust-sig group in Koschei. Then all packages that belong to the rust-sig group in Koschei are set as tracked. This is done by cron jobs scheduled every 3 hours. Anyone can request packages meeting certain criteria (eg. name matching some pattern, or owned/watched by a particular person/group) to be auto-tracked by Koschei or added to a particular group of packages. -- Mikolaj Izdebski > > > Vít > > > > > > > Fabio > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Let's enable Koschei for all packages automatically
On Thu, Aug 25, 2022 at 9:53 AM Miro Hrončok wrote: > > Hello folks, > > during our Nest FESCo session, we've talked about enabling Koschei [1] for all > packages automatically. > > There seem to be a consensus by FESCo members, that it would be a good thing. > > What would it take? > > 1) Koji resources > > I think we can try to enable this and see if it burns. I think ti won't. I don't expect Koschei would use much more Koji resources than it already does. Koschei maintains a priority queue of package rebuilds and submits scratch builds as available Koji resources allow. The queue is almost never empty - there are almost always some packages to rebuild. An increased number of tracked packages would simply grow the queue, but would not lead to submitting much more scratch builds. IOW, packages would simply be rebuilt less often. To submit more scratch builds we would need larger builder capacity. This doesn't necessarily mean more or better hardware. Better Koji configuration would help a lot. We have some very powerful builders with up to 224 processors, but their capacity is set to 2. This means that the builder stops accepting new tasks once load gets to 2, which is less than 1 %. Example buildhw-a64-20.iad2.fedoraproject.org Capacity is 2, check with: koji hostinfo buildhw-a64-20.iad2.fedoraproject.org 224 CPUs, load average: 2.04, 2.07, 2.05 memory: 251Gi total, 7.3Gi used, 242Gi available Yet, at the time of writing the builder is marked as not ready (!!) for taking more builds due to exceeded capacity. This is not an individual case, we have many builders like that. Making all packages as tracked without increasing Koji builder capacity will limit Koschei usefulness for packagers that care about Koschei enough to manually opt-in. > 2) One-time enablement of all existing packages > > That should be doable. Right? > > > 3) Automatic enablement of all new packages > > That should be just a matter of changing the defaults. Correct? I can implement points 2 and 3 easily, as long as there is consensus to do so. -- Mikolaj Izdebski > > > Can we do this? How can I help? > > > [1] https://fedoraproject.org/wiki/Koschei > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
SLF4J 2.0.0 update in Fedora Rawhide
Hello, In September package slf4j in Fedora Rawhide will be updated to a new major version 2.0.0. This update contains API and ABI breaks, therefore I am announcing it in advance. More details follow. SLF4J is a popular Java logging framework. A new major version 2.0.0 has been recently released. For summary of changes see upstream changelog: https://www.slf4j.org/news.html Notably some functionality has been removed without replacement and some classes have been renamed. Code changes may be required to port code to the new version of SLF4J. Currently Fedora Rawhide ships version 1.7.32 of SLF4J, but I am preparing to push the new version 2.0.0. A proof of concept code is available as pull request: https://src.fedoraproject.org/rpms/slf4j/pull-request/10 In the PR above you can also find a Koji scratch build of the new version, that can be used for testing dependent packages. ETA for submitting Bodhi update to stable is mid September 2022. Please contact me on the list or on IRC on #fedora-java if you want to cooperate on building and pushing related updates together. A compat package slf4j1 may be created if it turns out that porting multiple packages at the same time is infeasible. A rebuild of dependent packages with trivial changes (such as updating BuildRequires) may still be needed to start using the compat package. Packages that are known to require or build-require slf4j and therefore are possibly affected by the update: antlr3 antlr4-project apache-sshd aqute-bnd dogtag-pki freemarker hdf hdf5 java-dirq jboss-logging jericho-html jetty jgit jss ldapjdk log4j mariadb-java-client maven maven-artifact-transfer maven-plugin-bundle maven-resolver maven-script-interpreter maven-shade-plugin maven-wagon mysql-connector-java openas2 plexus-resources pomchecker resteasy sisu sisu-mojos slf4j tomcatjss xbean xmvn xmvn-connector-ivy Maintainers of affected packages are BCC-ed. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: ANTLR packages and i686
On Thu, Jul 7, 2022 at 4:15 AM Jerry James wrote: > > The various ANTLR packages will be impacted by > https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs. The parser > generators, which are written in Java, will no longer be available on > i686. If absolutely necessary, we could continue to package the > various language runtimes for i686. That would be a major pain in the > neck. WIth ANTLR 4 in particular, the version currently in Rawhide > (4.10.1) is not compatible with previous runtimes. Most of the > consumers we have in Rawhide ship parsers that were generated with > ANTLR 4.6 through 4.9 generators, so they are not compatible with the > 4.10.1 runtimes. (We regenerate the parsers at build time.) > Continuing to support i686 would therefore mean packaging old versions > of the language runtimes, just for i686. > > My preference is to stop building everything ANTLR-related on i686. > This has consequences for packages written in C, C++, Go, and OCaml, > at least. I'll omit Java packages other than the ANTLR packages from > the lists below, since they will disappear from i686 on their own. I agree. That would be my preference too. > Affected packages with maintainers: > - antlr3 (jjames, mizdebsk, dchen, mjakubicek, walters): we could > conceivably keep the C, C++, and JavaScript runtimes if absolutely > necessary > - antlr4-project (jjames, mhayden, @go-sig): we could conceivably keep > the C++, Go, JavaScript, Python3, and Swift runtimes, but see above > - azure-cli (mhayden, @python-sig): needs the Python3 runtime from the > antlr4-project package > - belle-sip (nucleo, sdgathman): needs the C runtime from the antlr3 package > - coq (amdunn, jjames): needs the Python3 runtime from the > antlr4-project package > - cvc4 (jjames, brouhaha): needs the C runtime from the antlr3 package > - flocq (jjames): depends on coq > - frama-c (jjames): depends on why3 > - gappalib-coq (jjames): depends on flocq > - golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime > from the antlr4-project package > - golang-google-grpc (eclipseo, @go-sig): needs > golang-github-google-cel. Is consumed by a TON of other Go packages, > so many that I did not attempt to trace them. > - ocaml-menhir (jjames): we can remove the coq subpackage only on > i686; it isn't consumed by anything in Fedora > - why3 (jjames): depends on flocq Not sure why your list does not include these, but the following packages also build-require antlr-C++: * gdl - already has java bcond; BR on antlr would need to be wrapped into bcond * nco - seems to have ability to be built without antlr (with limited features) * sqlitebrowser - looks like application (and we don't ship i686 kernel) * vfrnav - likewise > > Packages by maintainer: > @go-sig: antlr4-project, golang-github-google-cel, golang-google-grpc, > numerous consumers of golang-google-grpc > @python-sig: azure-cli > amdunn: coq > brouhaha: cvc4 > dchen: antlr3 > eclipseo: golang-github-google-cel, golang-google-grpc > jjames: antlr3, antlr4-project, coq, cvc4, flocq, frama-c, > gappalib-coq, ocaml-menhir, why3 > mhayden: antlr4-project, azure-cli > mizdebsk: antlr3 > mjakubicek: antlr3 > nucleo: belle-sip > sdgathman: belle-sip > walters: antlr3 > > I am going to be mostly offline starting Saturday, so I intend to deal > with this when I get back, approximately July 18. That is just before > the mass rebuild, of course. If anybody has a problem with dropping > i686 builds for the above packages, please come up with a plan to deal > with the situation by then. > -- > Jerry James > http://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Modello update in rawhide
On Fri, Apr 22, 2022 at 7:14 PM Mikolaj Izdebski wrote: > > In one week modello package will be updated in rawhide (Fedora 37) > from version 1.11 to version 2.0.0. > > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2053953 > PR: https://src.fedoraproject.org/rpms/modello/pull-request/4 Bodhi has just passed gating and has been pushed to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2022-cda0335c5f -- Mikolaj Izdebski > > The new major version introduces API break and packages may need to be > ported to work with the new version. > > Packages that build-require modello and are possibly affected by this update: > > antlr-maven-plugin > maven > maven-archetype > maven-assembly-plugin > maven-doxia > maven-doxia-sitetools > maven-file-management > maven-invoker-plugin > maven-plugin-tools > maven-remote-resources-plugin > maven-scm > maven2 > plexus-sec-dispatcher > xmvn > > > -- > Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rust Stack Spring Cleaning (April 2022 Edition)
On Thu, Apr 28, 2022 at 4:34 PM Fabio Valentini wrote: > > On Thu, Apr 28, 2022 at 1:59 PM Mikolaj Izdebski wrote: > > > > On Wed, Apr 27, 2022 at 3:45 PM Fabio Valentini > > wrote: > > > There is also the question about whether anitya release-monitoring.org is > > > actually set up for those packages, but I don't have an easy way to make > > > scripted checks for this yet. If you add new Rust packages to Fedora, > > > please > > > make sure to set up release-monitoring with these settings: > > > > You can use Anitya API to easily check whether there is a mapping from > > Fedora package to Release Monitoring project, eg.: > > https://release-monitoring.org/api/v2/packages/?name=rust-drg=Fedora > > > > Then you can get project details with: > > https://release-monitoring.org/api/v2/projects/?name=drg > > Oh, that's very nice. This is exactly what I need :) > I wanted to look into whether anitya has an API, but couldn't find > documentation for it. > Thanks for the pointers. Documentation for Anitya API can be found at https://anitya.readthedocs.io/en/stable/api.html -- Mikolaj Izdebski > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rust Stack Spring Cleaning (April 2022 Edition)
On Wed, Apr 27, 2022 at 3:45 PM Fabio Valentini wrote: > There is also the question about whether anitya release-monitoring.org is > actually set up for those packages, but I don't have an easy way to make > scripted checks for this yet. If you add new Rust packages to Fedora, please > make sure to set up release-monitoring with these settings: You can use Anitya API to easily check whether there is a mapping from Fedora package to Release Monitoring project, eg.: https://release-monitoring.org/api/v2/packages/?name=rust-drg=Fedora Then you can get project details with: https://release-monitoring.org/api/v2/projects/?name=drg -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Modello update in rawhide
On Tue, Apr 26, 2022 at 8:25 PM Kevin Kofler via devel wrote: > > 4. This is not a policy, but just a guide, an outdated one. Updates > > policy does not require maintainers to use side tags in this case. > > The Updates Policy is not relevant for Rawhide. What is relevant is that > Rawhide rules have become much stricter than in the past and that it is no > longer allowed to just break Rawhide. I am not a fan of the new rules either > (and I have speaken out against them more than once), but they are there, > and infrastructure has been depending on them for months already (e.g., > these days, if there is a broken dependency in any release-critical > deliverable, the whole Rawhide compose fails and everything stands still, > nothing gets delivered to mirrors at all until it is fixed, which in turn > prevents third-party repositories from rebuilding their packages against > both your and other simultaneous Rawhide changes). So if you are unhappy > about the rules, please help getting them changed, but do not just ignore > them. Updates policy does apply to rawhide too. There is even a section specific to rawhide. -- Mikolaj Izdebski > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Modello update in rawhide
On Mon, Apr 25, 2022 at 1:38 PM Mattia Verga via devel wrote: > > Il 24/04/22 22:06, Mikolaj Izdebski ha scritto: > > On Sun, Apr 24, 2022 at 1:56 AM Fabio Valentini > > wrote: > >> On Sat, Apr 23, 2022 at 7:26 PM Mikolaj Izdebski > >> wrote: > >>> On Sat, Apr 23, 2022 at 9:32 AM Mattia Verga via devel > >>> wrote: > >>>> Il 22/04/22 19:14, Mikolaj Izdebski ha scritto: > >>>>> In one week modello package will be updated in rawhide (Fedora 37) > >>>>> from version 1.11 to version 2.0.0. > >>>>> > >>>>> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2053953 > >>>>> PR: https://src.fedoraproject.org/rpms/modello/pull-request/4 > >>>>> > >>>>> The new major version introduces API break and packages may need to be > >>>>> ported to work with the new version. > >>>>> > >>>>> Packages that build-require modello and are possibly affected by this > >>>>> update: > >>>>> > >>>>> antlr-maven-plugin > >>>>> maven > >>>>> maven-archetype > >>>>> maven-assembly-plugin > >>>>> maven-doxia > >>>>> maven-doxia-sitetools > >>>>> maven-file-management > >>>>> maven-invoker-plugin > >>>>> maven-plugin-tools > >>>>> maven-remote-resources-plugin > >>>>> maven-scm > >>>>> maven2 > >>>>> plexus-sec-dispatcher > >>>>> xmvn > >>>>> > >>>>> > >>>>> -- > >>>>> Mikolaj Izdebski > >>>> Please build it in a side-tag, so that affected package maintainers can > >>>> try to rebuild their packages there and the final update can be delayed > >>>> until you're sure to not break anything. > >>> Using side tags for single build updates is an overkill. There are > >>> many different ways of testing packages, most of them don't involve > >>> using sidetags. But if anyone actually wants to test modello update in > >>> a sidetag, let me know and I will create one. > >> I think Mattia wanted to say that this should not be a single-build > >> update at all, given that it breaks API and probably requires changes > >> in dependent packages. Hence, the update + all required adaptations > >> should only be pushed together, as a single update. > > I've just built Modello 2.0.0 in Koji: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1955290 > > Anyone interested can test dependent packages against this build. > > If dependent packages need to be fixed to work with updated Modello, > > their builds can be submitted together with Modello as a multi-build update. > > Otherwise I'll submit Modello 2.0.0 as a single-build Bodhi update on > > Friday. > > > > -- > > Mikolaj Izdebsk > > > > > As said before, you should (must) not submit the update as a single > build update, because this will break dependent packages in rawhide. Do you have any evidence for this claim that the update will break any package? If so, please share it. > You must build your package in a side-tag and coordinate with > maintainers of dependent packages OR take care of rebuild those packages > in the side-tag OR ask any provenpackager to do so (if the primary > maintainer is unresponsive). See > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages 1. There is no evidence that the update is going to break anything. 2. The link refers to "Later Branched and stable releases" section, while I'm preparing update only for rawhide. 3. This section of update guide does not even mention side tags. 4. This is not a policy, but just a guide, an outdated one. Updates policy does not require maintainers to use side tags in this case. -- Mikolaj Izdebski > > Mattia > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
JDepend license change
jdepend package in rawhide is going to change license from "BSD" to "MIT". Upstream version 2.9.1 that is currently in rawhide is licensed under BSD license. I'm updating rawhide to version 2.10, which is licensed under MIT license. Relevant upstream commit: https://github.com/clarkware/jdepend/commit/62ffd67c9f9a7d411a09dd378f757ea726a8ef0c Fedora pull request: https://src.fedoraproject.org/rpms/jdepend/pull-request/1 Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1811262 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Modello update in rawhide
On Sun, Apr 24, 2022 at 1:56 AM Fabio Valentini wrote: > > On Sat, Apr 23, 2022 at 7:26 PM Mikolaj Izdebski wrote: > > > > On Sat, Apr 23, 2022 at 9:32 AM Mattia Verga via devel > > wrote: > > > > > > Il 22/04/22 19:14, Mikolaj Izdebski ha scritto: > > > > In one week modello package will be updated in rawhide (Fedora 37) > > > > from version 1.11 to version 2.0.0. > > > > > > > > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2053953 > > > > PR: https://src.fedoraproject.org/rpms/modello/pull-request/4 > > > > > > > > The new major version introduces API break and packages may need to be > > > > ported to work with the new version. > > > > > > > > Packages that build-require modello and are possibly affected by this > > > > update: > > > > > > > > antlr-maven-plugin > > > > maven > > > > maven-archetype > > > > maven-assembly-plugin > > > > maven-doxia > > > > maven-doxia-sitetools > > > > maven-file-management > > > > maven-invoker-plugin > > > > maven-plugin-tools > > > > maven-remote-resources-plugin > > > > maven-scm > > > > maven2 > > > > plexus-sec-dispatcher > > > > xmvn > > > > > > > > > > > > -- > > > > Mikolaj Izdebski > > > > > > Please build it in a side-tag, so that affected package maintainers can > > > try to rebuild their packages there and the final update can be delayed > > > until you're sure to not break anything. > > > > Using side tags for single build updates is an overkill. There are > > many different ways of testing packages, most of them don't involve > > using sidetags. But if anyone actually wants to test modello update in > > a sidetag, let me know and I will create one. > > I think Mattia wanted to say that this should not be a single-build > update at all, given that it breaks API and probably requires changes > in dependent packages. Hence, the update + all required adaptations > should only be pushed together, as a single update. I've just built Modello 2.0.0 in Koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=1955290 Anyone interested can test dependent packages against this build. If dependent packages need to be fixed to work with updated Modello, their builds can be submitted together with Modello as a multi-build update. Otherwise I'll submit Modello 2.0.0 as a single-build Bodhi update on Friday. -- Mikolaj Izdebsk > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Modello update in rawhide
On Sat, Apr 23, 2022 at 9:32 AM Mattia Verga via devel wrote: > > Il 22/04/22 19:14, Mikolaj Izdebski ha scritto: > > In one week modello package will be updated in rawhide (Fedora 37) > > from version 1.11 to version 2.0.0. > > > > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2053953 > > PR: https://src.fedoraproject.org/rpms/modello/pull-request/4 > > > > The new major version introduces API break and packages may need to be > > ported to work with the new version. > > > > Packages that build-require modello and are possibly affected by this > > update: > > > > antlr-maven-plugin > > maven > > maven-archetype > > maven-assembly-plugin > > maven-doxia > > maven-doxia-sitetools > > maven-file-management > > maven-invoker-plugin > > maven-plugin-tools > > maven-remote-resources-plugin > > maven-scm > > maven2 > > plexus-sec-dispatcher > > xmvn > > > > > > -- > > Mikolaj Izdebski > > Please build it in a side-tag, so that affected package maintainers can > try to rebuild their packages there and the final update can be delayed > until you're sure to not break anything. Using side tags for single build updates is an overkill. There are many different ways of testing packages, most of them don't involve using sidetags. But if anyone actually wants to test modello update in a sidetag, let me know and I will create one. > > Mattia > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Modello update in rawhide
In one week modello package will be updated in rawhide (Fedora 37) from version 1.11 to version 2.0.0. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2053953 PR: https://src.fedoraproject.org/rpms/modello/pull-request/4 The new major version introduces API break and packages may need to be ported to work with the new version. Packages that build-require modello and are possibly affected by this update: antlr-maven-plugin maven maven-archetype maven-assembly-plugin maven-doxia maven-doxia-sitetools maven-file-management maven-invoker-plugin maven-plugin-tools maven-remote-resources-plugin maven-scm maven2 plexus-sec-dispatcher xmvn -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Orphaning Jsoup
I'm going to orphan jsoup package. jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods. I am no longer interested in maintaining jsoup in Fedora. It has outstanding moderate CVE: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2021-37714 There is a new upstream version available. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Maven 3.8.4 update in rawhide
It's been a week. Maven 3.8.4 has been built in Koji.
Bodhi update will be created and submitted to stable within a few hours.
It will contain the following builds:
$ koji list-tagged f36-build-side-49560
Build Tag Built by
javapackages-bootstrap-1.5.0^20220105.git9f283b7-1.fc36
f36-build-side-49560 mizdebsk
javapackages-tools-6.0.0-5.fc36 f36-build-side-49560 mizdebsk
maven-3.8.4-1.fc36f36-build-side-49560 mizdebsk
maven-artifact-transfer-0.13.1-4.fc36 f36-build-side-49560 mizdebsk
maven-common-artifact-filters-3.2.0-1.fc36 f36-build-side-49560 mizdebsk
maven-plugin-testing-3.3.0-23.fc36f36-build-side-49560 mizdebsk
maven-resolver-1.7.3-1.fc36 f36-build-side-49560 mizdebsk
xmvn-4.0.0-5.fc36 f36-build-side-49560 mizdebsk
--
Mikolaj Izdebski
On Fri, Jan 7, 2022 at 1:23 PM Mikolaj Izdebski wrote:
>
> Hello,
>
> The maven package in Fedora rawhide will be updated from version 3.6.3
> to version 3.8.4 in one week. This update contains API and ABI
> changes, hence I'm sending this notice in advance per Fedora Updates
> policy.
>
> Kudos to Marian Koncek, who is driving this change.
>
> Proposed pull request:
> https://src.fedoraproject.org/rpms/maven/pull-request/33
>
> Maven 3.8.4 will be built in a Koji side tag together with some other
> packages that require patches or updates in order to work with updated
> Maven, including:
>
> https://src.fedoraproject.org/rpms/maven-artifact-transfer/pull-request/2
> https://src.fedoraproject.org/rpms/maven-common-artifact-filters/pull-request/3
> https://src.fedoraproject.org/rpms/maven-plugin-testing/pull-request/2
> https://src.fedoraproject.org/rpms/maven-resolver/pull-request/8
>
> List of packages that directly require or build-require maven and
> hence are possibly affected by this update:
>
> antlr-maven-plugin
> antlr3
> antlr32
> antlr4-project
> aqute-bnd
> buildnumber-maven-plugin
> byte-buddy
> byteman
> clojure-maven-plugin
> directory-maven-plugin
> exec-maven-plugin
> hawtjni
> icedtea-web
> jacoco
> javacc-maven-plugin
> jaxb-istack-commons
> maven-antrun-plugin
> maven-archetype
> maven-archiver
> maven-artifact-transfer
> maven-assembly-plugin
> maven-clean-plugin
> maven-common-artifact-filters
> maven-compiler-plugin
> maven-dependency-analyzer
> maven-dependency-plugin
> maven-dependency-tree
> maven-doxia-sitetools
> maven-enforcer
> maven-file-management
> maven-filtering
> maven-invoker-plugin
> maven-jar-plugin
> maven-mapping
> maven-native
> maven-patch-plugin
> maven-plugin-build-helper
> maven-plugin-bundle
> maven-plugin-testing
> maven-plugin-tools
> maven-remote-resources-plugin
> maven-reporting-impl
> maven-resources-plugin
> maven-scm
> maven-script-interpreter
> maven-shade-plugin
> maven-shared-incremental
> maven-shared-io
> maven-shared-utils
> maven-source-plugin
> maven-surefire
> maven-verifier-plugin
> maven2
> modello
> mojo-executor
> munge-maven-plugin
> plexus-containers
> pomchecker
> replacer
> sisu-mojos
> spec-version-maven-plugin
> string-template-maven-plugin
> xml-maven-plugin
> xmvn
>
> --
> Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Maven 3.8.4 update in rawhide
Hello, The maven package in Fedora rawhide will be updated from version 3.6.3 to version 3.8.4 in one week. This update contains API and ABI changes, hence I'm sending this notice in advance per Fedora Updates policy. Kudos to Marian Koncek, who is driving this change. Proposed pull request: https://src.fedoraproject.org/rpms/maven/pull-request/33 Maven 3.8.4 will be built in a Koji side tag together with some other packages that require patches or updates in order to work with updated Maven, including: https://src.fedoraproject.org/rpms/maven-artifact-transfer/pull-request/2 https://src.fedoraproject.org/rpms/maven-common-artifact-filters/pull-request/3 https://src.fedoraproject.org/rpms/maven-plugin-testing/pull-request/2 https://src.fedoraproject.org/rpms/maven-resolver/pull-request/8 List of packages that directly require or build-require maven and hence are possibly affected by this update: antlr-maven-plugin antlr3 antlr32 antlr4-project aqute-bnd buildnumber-maven-plugin byte-buddy byteman clojure-maven-plugin directory-maven-plugin exec-maven-plugin hawtjni icedtea-web jacoco javacc-maven-plugin jaxb-istack-commons maven-antrun-plugin maven-archetype maven-archiver maven-artifact-transfer maven-assembly-plugin maven-clean-plugin maven-common-artifact-filters maven-compiler-plugin maven-dependency-analyzer maven-dependency-plugin maven-dependency-tree maven-doxia-sitetools maven-enforcer maven-file-management maven-filtering maven-invoker-plugin maven-jar-plugin maven-mapping maven-native maven-patch-plugin maven-plugin-build-helper maven-plugin-bundle maven-plugin-testing maven-plugin-tools maven-remote-resources-plugin maven-reporting-impl maven-resources-plugin maven-scm maven-script-interpreter maven-shade-plugin maven-shared-incremental maven-shared-io maven-shared-utils maven-source-plugin maven-surefire maven-verifier-plugin maven2 modello mojo-executor munge-maven-plugin plexus-containers pomchecker replacer sisu-mojos spec-version-maven-plugin string-template-maven-plugin xml-maven-plugin xmvn -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: python-lxml license change
On Fri, Jun 4, 2021 at 3:03 PM Mikolaj Izdebski wrote: > > License of python-lxml package was changed from "BSD" to "BSD and MIT and > zlib" The license change happened in rawhide in June 2021. Currently there are pending updates introducing the same license change to Fedora 34 and Fedora 35. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: java-17-openjdk mass-rebuild for f36 in copr I
On Mon, Nov 29, 2021 at 2:17 PM Jiri Vanek wrote: > I would kindly ask you to search yourself in this list: > https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/fillCopr/exemplarResults/maintainers.jbump > If you are here, please check status of your package in > https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer/exemplarResults/coprBuildTable.jbump > (pain text of > https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/). Out of 225 packages listed as mine in the above list, there are only 15 failures. All 15 failed builds are for packages where I'm a co-maintainer, not primary maintainer. I don't have plans for fixing these packages - I would rather see them retired due to FTBFS if primary maintainers don't care to fix them. But if primary maintainers are interested in fixing these packages and need assistance in fixing non-trivial issues, I offer my help. As always, you can reach me on #fedora-java (on Libera.Chat). -- Mikolaj Izdebski > * If all your packages are "succeeded", congratulations nothing to do, and > just keep en eye on JDK bump > * If there is "failed" but contains "--" then even srpm built > failes. If you wish to resurrect it, please ensure it runs against > java-17-openjdk (see lower) > * If there is "failed" but failed in "seconds", then those packages failed > so quickly, that the build was in initial phases. That usually mean that you > build with source/target/release lower then 1.7. java-17-openjdk supports 1.7 > and up. > We recommend to bump the source/target to 1.8, to allow existence of compact > 1.8 packages alongside main javastack. See > https://fedoraproject.org/wiki/Changes/Java17#Wrong_source.2Ftarget_version. > Don't forget to upstream the patch, or > maybe it is enough to update to more fresh upstream release which supports > java-17-openjdk? it may happen, that after the fix, your build will fail in > more terrible way (see below) > * If there is "failed", and its none of above, then your package simply > failed. Very often the scary error may be fixed by bump to latest upstream > version. java-17-openjdk is out shortly, but changes against java-11-openjdk > are minimal, > and upstreams keep an track. Please, try to fix the package. Don't hesitate > to ask on de...@fedoraproject.org or java-de...@fedoraproject.org or directly > to me jva...@redhat.com. If you fix the fail, feel free to share your fix, it > may help > others. > We are trying to gather the most common issues at > https://fedoraproject.org/wiki/Changes/Java17#common_issues_packagers_can_face_and_gathered_solutions > . Feel free to enhance the page, or write us your case (possibly both with > solution and > without) so we can add it here. > > If your package is missing, and you wish it here, I will gladly add it! Just > let me know - jva...@redhat.com > > Debugging Your failures. > The copr repo we maintain, contains builds of java-17-openjdk as system JDK, > javapackages-tools, maven & comp. honoring that, and java-11-openjdk as non > system JDK. Also it contains successfully rebuilt packages. You can directly > use this > copr repo in several ways. > * first glance on error. On > https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ find your build > (select "all" instead of "25" at the bottom), > ** Click its number, select chroot (currently fedora-rawhide-x86_64 ) and > check the logs. Main log is build.log.gz. > * anything you push to rawhide, will automatically rebuild here in > fedora-rawhide-x86_64 chroot. > ** It is the best approach. If you can fix your package in rawhide > directly, without breaking the rawhide too much, go for it > ** If yo need to experiment, I have a mock config for you (generated from > copr-cli mock-config jvanek/java17 fedora-rawhide-x86_64) which you can copy > to your /etc/mock and use - > https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer/exemplarResults/jvanek-java17-fedora-rawhide-x86_64.cfg > . Eg: > > # as root, globally > sudo wget > https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scritps/spammer/exemplarResults/jvanek-java17-fedora-rawhide-x86_64.cfg > -O /etc/mock/jvanek-java17-fedora-rawhide-x86_64.cfg > # or as user, locally (after creating ~/.config/mock/) > wget > https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scritps/spammer/exemplarResults/jvanek-java17-fedora-rawhide-x86_64.cfg > -O ~/.config/mock/jvanek-java17-fedora-rawhide-x86_64.cfg > # change spec, bump sources, apply patches > fedpkg srpm > mock -r jvanek-java17-fedora-rawhide-x86_64
Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)
On Wed, Nov 3, 2021 at 9:41 AM Petr Pisar wrote: > > V Wed, Nov 03, 2021 at 01:45:00AM +0100, Miroslav Suchý napsal(a): > > Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a): > > > === Why not just use the rpm database? === > > > > > > > > > 17:34:33 The main reason for this appears to be that we > > > need the RPM db locally to resolve build-ids to package names. But > > > since containers wipe /var/lib/rpm, we can't do that. So the solution > > > is to put the ''nevra'' in ELF metadata? > > > 17:34:39 That feels like the wrong approach. > > > > > > > > > First, there are legitimate reasons to strip packaging metadata from > > > images. For example, for an initrd image from rpms, I get 117 MB of > > > files (without compression), and out of this `/var/lib/rpm` is 5.9 MB, > > > and `/var/lib/dnf` is 4.2 MB. This is an overhead of 9%. This is ''not > > > much'', but still too much to keep in the image unless necessary. > > > Similar ratios will happen for containers of similar size. Reducing > > > image size by one tenth is important. There is no `rpm` or `dnf` in > > > the image, to the package database is not even usable without external > > > tools. > > > > Devil advocate here: > > > > **Some** people wipe `/var/lib/rpm` to save 5.9 MB. And because of this we > > will put another 5.9 MB [citation needed] as metadata split across various > > ELF objects for **everybody**. > > > > When someone want really tiny image, I will expect they will start stipping > > ELF objects when they discover this feature. > > > Morover it only pertains ELF. What about other files? E.g. compiled Java > classes, or minified JavaScript libriaries? I will be proposing a separate system-wide F36 change for embedding package NVR inside Java JAR files iff the ELF change is accepted. -- Mikolaj Izdebski > > What about storing the RPM package identifier by a package manager when > installing a file into an extedned attribute of the file? That > would track origin of all files and users not intersted in the tracking > could easily remove the data. Effectively it would become a feature of the > package manager. Not of a build system. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 36 System-Wide Change: java-17-openjdk as system JDK in F36 pre-announcement
On Mon, Nov 1, 2021 at 11:07 AM Jiri Vanek wrote: > > Hello! > > For wide hearing/reading, before final announcement, > https://fedoraproject.org/wiki/Changes/Java17 have anybody any opinion or > anything to say for/against? I am for this change. Fedora should use the latest OpenJDK by default. Required tooling changes (javapackages-tools etc.) that are needed to build packages with OpenJDK 17 are ready to be pushed once the change is accepted. All my packages (Maven, Ant and their dependencies) were already ported to Java 17, more info on java-devel list. -- Mikolaj > > > Happy Hacking, > J. > > > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Zuzana Miklankova
On Tue, Nov 2, 2021 at 3:23 PM Zuzana Miklankova wrote: > > Hi all, > > I am an employee of Red Hat, using Fedora as my main working environment. > > I have tried various Linux distributions yet, even though I have never > contributed to any. > However, I have gained some experience in contributing to open-source > projects during my studies at university. > > I will be maintaining some java database-related packages. And I have also > already > submitted my first package [1]. Welcome. Please consider joining java-devel mailing list [1] used for Java-related packaging topics. -- Mikolaj Izdebski [1] https://fedoraproject.org/wiki/SIGs/Java#Mailing_list > > Looking forward to future cooperation, > Zuzana. > > [1] https://src.fedoraproject.org/rpms/container-workflow-tool > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
guava 31.0.1 update in rawhide
Hello, In one week guava package will be updated from version 30.1 to version 31.0.1 in rawhide. The new version changes API/ABI, so an action may be required to update packages that depend on guava. Upstream release notes: https://github.com/google/guava/releases/tag/v31.0 Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=77257569 Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1556627 Pull request: https://src.fedoraproject.org/rpms/guava/pull-request/2 Packages that depend on guava: auto caffeine clojure-maven-plugin compile-command-annotations google-guice jackson-dataformats-text libidn maven-shade-plugin plexus-containers protobuf xmvn -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL package and Java 11 requirement.
On Tue, Oct 5, 2021 at 10:41 AM Stefan Bluhm wrote: > > When opening a Buzilla, these common issues popped up: > > java-11-openjdk-headless RPM does not provide java-headless capability > - https://bugzilla.redhat.com/show_bug.cgi?id=1797054 > - "Hi. This is intentional. It will be added once jdk8 will stop to be the > system JDK." > > javapackages-tools: wrong generated Requires: `java-headless >= 11` > - https://bugzilla.redhat.com/show_bug.cgi?id=1993879 > - "The culprint *may* be xmvn, as there is (at least) one pkg in rhel8 which > is jdk11 based but is build by Makefile, and do not suffer the issue." > - "A proper long-term fix would mean redesigning how provides and > auto-requires are supposed to work. There are several possibilities." > - "Another possibility is removing auto-requires on java-headless altogether > - they add little value and cause much trouble." > > Is it possible to disable the auto-require generation in xmvn? > Otherwise it seems I have to skip usage of xmvn just for that. > > Best wishes, > > Stefan > > > - Ursprüngliche Mail - > Von: "fedoraproject org" > An: "epel-devel" > Gesendet: Dienstag, 5. Oktober 2021 09:05:13 > Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement. > > Hello Mike, > > I thought (!) I read somewhere that this difference between java-headless and > java-11-headless was intentional (or at least I understood it that way). > Let me open a Bugzilla against Java 11. > > > > How did others tackle this issue in the past/currently though? I can't be the > first one creating an rpm with an autogenerated java-headless >= 1:9 tag. > > Is there a way to disable/remove this autogeneration or force it to be > something different? > Also I noticed some packages where the headless tag was not generated at all. > So maybe I could just remove the trigger for that. It is possible to filter generated requires. This was described in a comment in one of the bugs you referred to: https://bugzilla.redhat.com/show_bug.cgi?id=1993879#c10 -- Mikolaj Izdebski > > I tried removing maven-compiler-plugin from the pom and adding the > compiler.target=11 line in the build section but that gave the same result. > > Thanks and best wishes, > > Stefan > > - Ursprüngliche Mail - > Von: "Mike Rochefort" > An: "epel-devel" > Gesendet: Montag, 4. Oktober 2021 22:57:09 > Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement. > > On Mon, Oct 4, 2021 at 3:50 PM Stefan Bluhm > wrote: > > > > it provides "java-11-headless". Not "java-headless". At least not on my > > machine > > Doing my own checks on CentOS Stream 8 and RHEL 8.4, this sounds like a Fedora > change that didn't make its way back to RHEL. Worth opening a Bugzilla > report on? > > For posterity, only java-1.8.0 returns when checking for java-headless > on EL8 (latest > versions on RHEL for 1.8 and 11 as of writing). > > $ rpm -qp --provides > java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el8_4.x86_64.rpm > /usr/bin/jjs > config(java-1.8.0-openjdk-headless) = 1:1.8.0.302.b08-0.el8_4 > java-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 > java-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > java-1.8.0-openjdk-headless(x86-64) = 1:1.8.0.302.b08-0.el8_4 > java-headless = 1:1.8.0 > java-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > jre-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 > jre-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > jre-headless = 1:1.8.0 > jre-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 > libjava.so()(64bit) > libjava.so(SUNWprivate_1.1)(64bit) > libjsig.so()(64bit) > libjvm.so()(64bit) > libjvm.so(SUNWprivate_1.1)(64bit) > libverify.so()(64bit) > libverify.so(SUNWprivate_1.1)(64bit) > > $ rpm -qp --provides java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64.rpm > config(java-11-openjdk-headless) = 1:11.0.12.0.7-0.el8_4 > java-11-headless = 1:11.0.12.0.7-0.el8_4 > java-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 > java-11-openjdk-headless(x86-64) = 1:11.0.12.0.7-0.el8_4 > jre-11-headless = 1:11.0.12.0.7-0.el8_4 > jre-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 > > -- > Mike > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org >
Re: Fedora Java: The Death of Two SIGs
On Tue, Oct 5, 2021 at 1:27 PM Peter Boy wrote:
>
>
>
> > Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski :
> >
> > On Mon, Oct 4, 2021 at 2:08 PM Peter Boy wrote:
> >> However, we lack concepts on how to proceed after removing java-maint-sig.
> >> What consequences do we draw from the analyses?
> >
> > … If you want
> > to improve docs, just do it. And so on. ...
> > ... or to plan editing the wiki. Whoever wants to clean up some wiki
> > pages can simply do so, without asking.
>
> It’s not as easy as you think of. That way you will end with the docs as
> Stephen Smoogen described 4 posts back, just chaos and misinformation. You
> need collaboration and agreement (shared plan) from participants in all
> affected areas - including you as the (main) developer of a core package (not
> writing text, but e.g check the concept, check technical correctness and
> completeness). It simply doesn’t work the way you are proposing.
Sure, some major changes may indeed require planning or cooperation.
That's what we have the SIG and its communication channels for. For
example, if I wanted to rewrite Java documentation and move it from
the wiki to docs.fedoraproject.org at the same time, I would start
with sending a proposal to java-devel mailing list and ask for
feedback. We would discuss what should and what should not be
documented, who wants to document what and so on. Depending on how the
discussion goes there, I might propose an IRC meeting to ease the
discussion process.
>
>
> >> I posted on the java list some ideas some time ago ('Empowering Fedora
> >> Java’). Any comments on those?
> >
> > These were about java-maint-sig, IIRC, which basically does not exist
> > any longer.
>
> No! It was about:
> > The biggest success is that with all the adversities in java packaging we
> > have a stabilized Fedora Java core platform.
I'll re-read it then and try to reply.
> >
> > The next urgent step, in my opinion, is to update and improve information
> > materials and documentation, followed by a community building process based
> > on it.
> >
> >
> > I can offer to do the writing. …
> followed by tentative ideas about details of documentation.
>
> You wrote:
> > Java SIG has resources in form
> > of communication channels that can be used by members to help each
> > other. There is a mailing list and an IRC channel.
> So much for the theory, yes. I would have appreciated even a tiny bit of it.
I don't understand. These communication channels exist and are
functional. The most active Java packagers I know of are subscribed to
the mailing list and are present in the IRC channel. The fact that
there is not much ongoing communication is a different problem - I
find that people very often approach me directly or through other
channels, and many times I ask them to use public Java SIG channels
because that allows others to benefit from the conversation.
> You are one of the developers without whose contributions the Fedora Java
> stack would probably collapse in a short time. I would really be interested
> in the same question as to Mat: With java-paint-sig removed, are you really
> completely content with the Fedora Java world? No change? No improvement
> anywhere?
I'm happy with how Java SIG works in general - as an informal group
that does not limit packagers freedom, like by enforcing agile
processes, or mandating code review for every change. I like that Java
SIG doesn't have any authority to make any decisions - there can be
discussion, but ultimately each package owner makes decisions
regarding their own packages, within boundaries defined by Fedora
policies. The Fedora change process can be used when required - anyone
can propose a change, and once approved by FESCo, the package owner
must obey. I like that unmaintained packages are being removed from
distribution - with decreasing manpower in Java SIG I think it's
better to focus on fewer important packages.
For sure we should clean outdated Java SIG wiki pages - that's
relatively simple and I can do that myself. We should pay better
attention to announcing important changes that can affect others. We
can try regular IRC meetings instead of ad-hoc meetings. We could try
to come up with common goals for the SIG, but I'm not sure if that
will help. Right now I don't have any other ideas regarding improving
Java SIG organization.
Regarding Java content in Fedora Linux, there is a lot to improve, and
I have many ideas. I started writing them down as they come to my mind
and for each of them I'll start separate threads on java-devel list.
I also promise to document ongoing or planned projects that I am or
would like to be working on. Then anyone interested will be able to
more easily see what is going on,
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller wrote: > > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote: > > I'm not sure what's the best solution, but I guess the number one > > reason to have packages within the Fedora distribution is for a matter > > of trust, if this is the case I would argue that a curated list of > > maven packages served via a Fedora managed repository would be a > > better investment. > > I'd love to see someone interested in this pursue this idea! I know we > talked about it as long ago as... Flock Prague... and probably before. That's a very old idea that has been partially implemented years ago, but never approved for use in Fedora. Maven artifacts can be built in Koji (there is an existing "koji maven-build" command). Once built they appear in a "curated" Maven repository hosted on Koji, that can be synced to mirrors, from where users can consume it. Consumers of this Maven repository don't need to be running Fedora, not even Linux. Curated Maven repository contains additional metadata, eg. CVEs affecting given artifact version, whether upstream is active, whether given artifact is available in Fedora and in which releases, etc. For each Fedora Linux release there is an auto-generated BOM (bill of materials POM) listing artifacts available in the release. Binaries from this trusted/curated Maven repository can also be wrapped into RPMs (using "koji wrapper-rpm" command) and put into distribution repos and composes. Other packages can depend on such RPMs. This is a hybrid packaging model, where some Java RPM packages can be built in the traditional way (where code is compiled during rpmbuild) and some are built elsewhere, and only wrapped in RPMs. -- Mikolaj Izdebski > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Mon, Oct 4, 2021 at 3:08 PM Mat Booth wrote:
>
> On Mon, 4 Oct 2021 at 13:07, Peter Boy wrote:
> >
> > We had a spirited and detailed discussion so far. But nevertheless, I
> > think we are none the wiser at the moment. We have many informative
> > contributions to the discussion and analyses of the situation.
> >
> > However, we lack concepts on how to proceed after removing java-maint-sig.
> > What consequences do we draw from the analyses?
> >
> > Emmanuel Seyman has made some suggestions, about 16 posts back. Thoughts
> > on those? I posted on the java list some ideas some time ago ('Empowering
> > Fedora Java’). Any comments on those?
> >
> >
> >
>
> Like many Open Source projects, Fedora is a "do-ocracy" -- those who
> step up to do the work win the responsibility of getting it done. If
> you have a clear goal in mind, just go for it.
>
> As I said before there's always a lot of discussion from people who,
> in the end, never get involved. And then there are people who are
> quietly working away and Getting Things Done™ without the need for
> endless discussion. A good example is Nicolas De Amicis who recently
> stepped up to revive SWT because he really cares about openjfx in
> Fedora and SWT was a dependency. And that is awesome; it is the
> do-ocracy in action! Picking a goal you care about and setting about
> achieving it doesn't require a SIG, it requires you to "do."
>
> So, do you have any specific, concrete goal you want to achieve? If
> the removal of a Java package has affected you directly or a Java
> application you care about is in danger of being removed that would be
> a excellent place to start.
I totally agree with Mat.
If you want to contribute, just do it. If you need help, feel free to
ask around.
--
Mikolaj Izdebski
>
>
>
>
>
>
>
>
> --
> Mat Booth
> http://fedoraproject.org/get-fedora
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Mon, Oct 4, 2021 at 2:08 PM Peter Boy wrote:
> However, we lack concepts on how to proceed after removing java-maint-sig.
> What consequences do we draw from the analyses?
The java-maint-sig formal group ceased to exist. Java SIG continues to
exist as an informal group, in the shape it existed before
java-maint-sig was formed. Anyone who wants to improve Java in Fedora
can simply do so. Eg. If you want to package something, you can do it.
If you need help, you can ask on IRC or mailing list. If you want to
test existing packages, feel free to do it and open bugs. If you want
to improve docs, just do it. And so on. Java SIG has resources in form
of communication channels that can be used by members to help each
other. There is a mailing list and an IRC channel. We can even
schedule an IRC meeting if anyone has a particular topic to discuss
during a meeting.
> Emmanuel Seyman has made some suggestions, about 16 posts back. Thoughts on
> those?
I'm for removing java-maint-sig group and documenting the current
state of affairs. But I don't think there is a need to "restart Java
SIG" or to plan editing the wiki. Whoever wants to clean up some wiki
pages can simply do so, without asking.
> I posted on the java list some ideas some time ago ('Empowering Fedora
> Java’). Any comments on those?
These were about java-maint-sig, IIRC, which basically does not exist
any longer.
--
Mikolaj Izdebski
>
>
>
> Peter
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Thu, Sep 30, 2021 at 12:13 PM Fabio Valentini wrote: > > On Thu, Sep 30, 2021 at 11:17 AM Mikolaj Izdebski wrote: > > > > On Wed, Sep 29, 2021 at 1:51 PM Miro Hrončok wrote: > > > Since the @java-maint-sig group is esentially non-responsive, I suggest > > > we do > > > the following: > > > > Thanks for making this distinction - @java-maint-sig group is not the > > same as Java SIG. > > Some of the most active members of Java SIG (like me or OpenJDK > > maintainers) are not > > (and never were) members of @java-maint-sig. > > That's true. The "old" Java SIG was never properly set up as a FAS > group. Its Wiki page has contained obsolete information for *years*, > and the list of members there hasn't been accurate for years, either. Java SIG is an informal group. By definition, SIGs are informal groups within Fedora Project. Therefore there is no formal membership of Java SIG. Anyone interested in contributing to make Java in Fedora better can be considered a member of Java SIG. > On the other hand, you were explicitly welcome to join the newly set > up group, which you never bothered to do, since you were pretending @java-maint-sig evolved from Stewardship SIG, which was formed with a goal of preventing unmaintained packages from being retired, which I don't appreciate. My opinion is that retirement of unmaintained packages is desired. I want Fedora Linux to be a high quality distribution and I believe it's better to have fewer, but better quality packages. This is the primary reason for me not joining @java-maint-sig. Besides that I'm not a big fan of collaborative package maintenance groups such as @java-maint-sig. I prefer a model with a single primary maintainer who owns the package, like a product owner - has the authority to make technical decisions about the package. Similarly to cathedral vs bazaar, both of which are valid software development models. > that Modularity will solve all of humanity's problems, and obviously > preferred to work alone, never offering help or feedback, unless > *maybe* when explicitly asked. Now that modules won't solve Java I never claimed that modularity was perfect, nor that it was better than traditional package maintenance. Modularity solves some important problems, but introduces others. From my PoV, the most important feature of modularity that I wanted to take advantage of - building packages in a controlled, isolated environment - is now implemented as Koji dynamic sidetags (BTW, I was the original author of sidetag-koji-plugin). Another important feature - private dependencies - is now solved by allowing bundling much more freely and by exempting compat packages from the package review process. Therefore I no longer see modularity as a good approach to maintain default versions Maven and Ant - it could still be used for alternative versions. > packaging either, you're back, and bad-mouthing all the work the SIG > did while it was active to keep the shit from hitting the fan while > you were AWOL, which I find a bit rich. I am back to maintaining non-modular Java packages because I want to keep contributing to Fedora as a Java package maintainer and Fedora engineering leadership decided that non-modular packages are strongly preferred over modules. I don't disagree with that decision and I respectfully obey it. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Wed, Sep 29, 2021 at 1:51 PM Miro Hrončok wrote: > Since the @java-maint-sig group is esentially non-responsive, I suggest we do > the following: Thanks for making this distinction - @java-maint-sig group is not the same as Java SIG. Some of the most active members of Java SIG (like me or OpenJDK maintainers) are not (and never were) members of @java-maint-sig. > 1) We remove all BZ assignee overrides to @java-maint-sig. This is a must. > 2) We remove access of @java-maint-sig from all packages. > 3) We ask the members of the group if they want to admin the list/BZ account. >3a) We give it to the volunteer. >3b) We empty the group and cancel the BZ account/list if nobody shows up. > 4) We *don't orphan the packages*, they have some "de jure" maintainers. +1 That is a good plan. Several months ago I demoted @java-maint-sig from admin to committer for all packages I am primary maintainer of, and I was considering demoting it further to collaborator or ticket level, or removing altogether as I my packages did not receive any contribution from the group for the past months, except for a couple PRs that don't require direct access to the packages. -- Mikolaj Izdebski > > The packages that fail to install and/or build will eventually die out due to > the existing processes. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Mon, Sep 27, 2021 at 4:06 PM PGNet Dev wrote: > > Many valid/interesting points being made. Most of them sound, reasonably, > like developer-/maintainer-centric issues. > > Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 'service' its > (java app) users? There is no single primary goal of Java SIG. The group consists of individuals and sub-groups that have different focus or goals. I think of Java packages as grouped into logical layers. The lowest first foundation layer is OpenJDK. The second layer is Java RPM tooling (with dependencies, the build systems) which enables everything else, the third layer, to be built. In other words, OpenJDK with Maven/Ant/Javapackages/XMvn form a platform on which other packages can be built. I am mostly working within MBI sub-SIG that is working on development and maintenance of the second layer - Java build systems and RPM tooling for Java packaging. The group has 2 goals: 1) We deliver, maintain and support Ant and Maven in Fedora. Our aim is to provide developers with the most popular Java build systems which are reviewed, tested, and updated through the release lifecycle. 2) We design, develop and document tooling that enables anyone to package Java software with a simple, efficient and scalable process. We are also active members of Java SIG, collaborating on complex changes and guiding new contributors. The first goal is directed towards Fedora Linux users who want to build any Java software, the second one towards anyone who wants to package software they care about, but primarily towards Fedora contributors. Maintenance of random Java libraries or apps is a non-goal for us. From my PoV, all Fedora Java buildsystem packages (around 120 of them) are in good shape, with only two known security bugs, no important or critical security bugs, no FTBFS or FTI bugs. I am actively triaging all bugs reported and responding to pull requests opened. Due to recent CentOS Stream 9 development work we are behind on a couple of updates, but we should process them in the next month or two. -- Mikolaj Izdebski > > If so, what's the current understanding of a user-driven ProductRequirements > spec'n of JAVA apps 'round here? > Who's included in "users"? Developers? End-users? etc. > Perhaps I've missed it ... > > I know as a representative of my end-users I've got plenty of opinions about > our JAVA env. Also as a representative of my org's JAVA devs. > But as a developer/maintainer OF java/apps @ Fedora, not much at all; the > "solid OpenJDK & Maven" approach is good enuf here. Mostly. > > And, if that^ is not a primary goal, then back to the discussion at hand. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Thu, Sep 30, 2021 at 1:25 AM Mat Booth wrote: > > On Wed, 29 Sept 2021 at 23:48, Emmanuel Seyman wrote: > > On that topic, I've just read an interview of Nicolas Lécureuil, the > > president of the Mageia board, in which he says that Mageia's Java stack > > is based on Fedora's and that he interacts with Fedora's Java team > > (leading me to wonder who exactly he is interacting with given Fabio's > > description of the SIG's activity in the opening mail of this thread). > > > > I've interacted with Java people from Mageia many times over the > years. They periodically rebase their stack on Fedora's and have been > pretty good at finding things that I didn't notice had stopped working > such as bootstapping modes that we don't exercise very often for > example. I've made a bunch of changes based on their reports and > merged a bunch of changes from them too, so kudos to them. They've > historically been active on #fedora-java IRC channel, so I'm sure I'm > not the only one with such interactions. Likewise, I talked with Mageia Java maintainers, including Nicolas, numerous times in the past couple years. I am happy to work with them as relationship with Mageia brings value to Fedora for several reasons, such as getting bugs/RFEs from them that help our packages to be improved. -- Mikolaj > > > -- > Mat Booth > http://fedoraproject.org/get-fedora > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Flagged projects in Anitya
On Fri, Jul 30, 2021 at 8:54 PM Richard Fearn wrote: > > Hi, > > Does anyone know who looks after flagged projects in Anitya? I've > flagged a couple of projects for deletion, but so far nothing has > happened. Thank you for bringing this up. The flags are processed by admins of Anitya. I have just processed your ones. -- Mikolaj Izdebski > > Regards, > > Richard > > -- > Richard Fearn > richardfe...@gmail.com > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Java packaging issue on EPEL7
On Mon, Jul 19, 2021 at 7:31 PM Vitaly Zaitsev via devel wrote: > > Hello. > > Found a strange RPM autodeps issue, related to Java packaging, only on > EPEL7. > > EPEL7 package contains additional auto-detected strict dependencies: > osgi(com.github.jnr.jffi) and osgi(com.sun.jna). That's why the package > cannot be installed due to lack of dependencies on RHEL/CentOS 7: > > Error: Package: pycharm-community-2021.1.3-1.el7.x86_64 (phracek-PyCharm) > Requires: osgi(com.github.jnr.jffi) > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest [...] > How I can fix this? You can disable osgi requires generator or filter osgi requires (with eg. __requires_exclude or __requires_exclude_from macros). -- Mikolaj Izdebski > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Mon, Jun 21, 2021 at 2:54 PM Andrew Bauer wrote: > > Looks like jakarta-mail affects quite a few packages. I have taken it. You can transfer jakarta-mail package to me if you like. It's a dependency of Ant which I'm maintainer of . -- Mikolaj Izdebski > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: hamcrest update to 2.2 in Fedora rawhide
On Tue, Jun 1, 2021 at 8:40 AM Stephan Bergmann wrote: > > On 01/06/2021 05:42, Mikolaj Izdebski wrote: > > On Mon, May 31, 2021 at 1:12 PM Miro Hrončok wrote: > [...] > >> Seems like the configure script (or whatever that is) fails to find > >> hamcrest. > > > > That's because libreoffice hardcodes path to hamcrest JAR in the > > configure script, instead of using one of the tools designed to locate > > JAR files in the system. That is covered in Java Packaging Guidelines > > [1]. > > "packager SHOULD use one of tools designed to locating JAR files in the > system": whatever those tools are; that packaging guidelines page > doesn't seem to tell These would be find-jar, build-classpath, build-jar-repository etc. from javapackages-tools. They are described in Java Packaging HOWTO. Java packaging guideline is fairly minimal and primarily defines policy (MUSTs and SHOULDs) for packaging Java. It strives not to provide specific examples directly, but rather refers to Java packaging HOWTO. The split into two documents, one maintained by FPC that defines packaging policy and the other maintained by Java SIG that provides packaging documentation, is intentional - it gives Java SIG ability to work on packaging documentation without involving FPC and at the same time keeps FPC in control of packaging policy. -- Mikolaj Izdebski > > >> The bugzilla is https://bugzilla.redhat.com/show_bug.cgi?id=1965975 > > > > I could add a compat symlink to the hamcrest package, but it seems > > that the issue was fixed on the libreoffice side. > > yes, thanks, no need to adapt the hamcrest side > > [...] > > [1] > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_hardcoded_paths > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Javapocalypse is Monday
On Fri, Jun 4, 2021 at 1:44 PM Coty Sutherland wrote: > > On Thu, Jun 3, 2021 at 5:56 PM Sérgio Basto wrote: >> >> On Thu, 2021-06-03 at 15:30 -0600, Jerry James wrote: >> > I've just been looking through my packager-dashboard page. A >> > depressingly large chunk of my packages are going to become >> > unbuildable on Monday when a bunch of orphaned Java packages are >> > retired. I think a lot of us are going to be affected. In my case, >> > there are quite a few non-Java packages involved (due to the parser >> > generators antlr3 and antlr4-project), primarily OCaml and python >> > packages. Mikolaj has a huge pile of work on his shoulders, so don't >> > take this as criticism of him. >> > >> > Here are some of the pain points: >> > - log4j will be retired, which will break ant. >> > - hamcrest2 will be retired, which will break apache-commons-lang3, >> > which will break bcel, which will also break ant. >> > - google-gson and javassist will be retired, which will break >> > reflections, which will break jna, which is used by about a dozen >> > packages, including bcel. >> >> I may take these 4 > > > That would be great :D My package (Tomcat) still uses ant to build, so if you > could save it from retirement that would be great. I don't have bandwidth to > take on any additional packages right now, but I don't mind being a > co-maintainer if you feel you need it. > >> >> > - maven-install-plugin will be retired, which will break tycho, which >> > will break eclipse. >> >> Eclipse for me may fall, I already use eclipse installer from >> https://www.eclipse.org/downloads/ >> >> >> > - args4j will be retired, which will break jacoco and jgit. >> > - maven-invoker-plugin and several of its dependencies >> > (maven-doxia-sitetools, plexus-velocity, maven-reporting-api, >> > maven-script-interpreter, and maven-reporting-impl) will be retired, >> > which will break xml-maven-plugin, which is used by eclipse. >> > - jakarta-el and jakarta-server-pages will be retired, which will >> > break eclipse. >> > - aopalliance will be retired, which will break maven-native. >> > - jdependency will be retired, which will break maven-shade-plugin, >> > which is used by openjfx8, a dependency of java-1.8.0-openjdk. >> > - apache-ivy will be retired, which will break javapackages-tools. >> > >> >> I can also take these two jdependency and apache-ivy . >> >> maybe I should also take maven-invoker-plugin . >> >> what do you think ? >> >> >> > I have packages that depend directly on the following, so I am >> > willing >> > to adopt them if nobody more competent shows up (although there is no >> > point in taking ant-contrib if ant is going to be broken anyway): >> > - ant-contrib >> > - jakarta-common-httpclient >> > - jakarta-ws-rs >> > - maven-invoker-plugin >> > - spec-version-maven-plugin >> > >> > I introduced the jansi1 and jline2 packages so that jansi could be >> > moved to 2.x and jline to 3.x, but I don't actually maintain any >> > packages that need the old versions. I would like to give them away >> > to someone who needs them, but note that you will need to grab >> > jansi-native as well, before Monday! >> > >> > Has anybody already done something about any of these packages (and >> > my >> > packager-dashboard page just hasn't caught up yet)? Is anybody >> > planning to do something about any of these packages before they are >> > retired on Monday? > > > I've dropped all the direct dependencies that I had which were being > orphaned, so the only outstanding problems I have are ant (which may be > addressed by Sérgio) and javapackages-tools, which I'm a bit confused about. > It seems that the latest build relies on java-11, not java-8 so not sure why > it's showing up that way in the dep map. It seems that the map isn't > generated often, so maybe it's just outdated? Some subpackages of javapackages-tools depend on OpenJDK 11, some on OpenJDK 8. That is intentional - it gives packagers an ability to choose which JDK should be used to build their packages. -- Mikolaj Izdebski > >> > -- >> > Jerry James >> > http://www.jamezone.org/ >> > ___ >> > devel mailing list -- devel@lists.fedoraproject.org >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > Fedor
Re: The Javapocalypse is Monday
On Thu, Jun 3, 2021 at 11:46 PM Bruno Wolff III wrote: > > I knew that a bunch of java stuff was going away, but I am not sure what > the impact of that is going to be. Is there a feature page or similar > that summarizes what the effect we be? > > I have one package that produces a java program using ant that I like to be > able to keep building somehow. There is also an OCaml package I help > maintain, that is used in an old game that I doubt gets much use these days > and I wouldn't be too sad if that went away. Ant stays in Fedora. I am committed to maintaining it. > Is there a recommendation to move to maven? Is there anything like the > old gcc based java compiler that could be used? Is there still going > to be a java runtime? No, it is not recommended to switch projects built with Ant to use Maven. GCJ has been retired from Fedora many years ago, OpenJDK is the only JDK/JRE that is currently in Fedora and it is expected to stay in Fedora - it is not expected to be retired. -- Mikolaj Izdebski > I spend a lot of time using the former as a passtime game and would miss it > if it wasn't in Fedora any more. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Javapocalypse is Monday
On Thu, Jun 3, 2021 at 11:32 PM Jerry James wrote: > > I've just been looking through my packager-dashboard page. A > depressingly large chunk of my packages are going to become > unbuildable on Monday when a bunch of orphaned Java packages are > retired. I think a lot of us are going to be affected. In my case, > there are quite a few non-Java packages involved (due to the parser > generators antlr3 and antlr4-project), primarily OCaml and python > packages. Mikolaj has a huge pile of work on his shoulders, so don't > take this as criticism of him. > > Here are some of the pain points: > - log4j will be retired, which will break ant. I will either adopt log4j or unretire log4j12; ant should still be functional. > - hamcrest2 will be retired, which will break apache-commons-lang3, apache-commons-lang3 depends on hamcrest, not hamcrest2. > - maven-install-plugin will be retired, which will break tycho, which > will break eclipse. maven-install-plugin depends on maven2 which has been deprecated in Fedora end EOL upstream for more than 12 years. Therefore I'm not going to maintain it. It should be fairly easy to patch tycho not to depend on maven-install-plugin (one liner patch). > - apache-ivy will be retired, which will break javapackages-tools. Dependency on apache-ivy is optional. There is a bcond in javapackages-tools.spec file which I will toggle in case apache-ivy is retired. > I have packages that depend directly on the following, so I am willing > to adopt them if nobody more competent shows up (although there is no > point in taking ant-contrib if ant is going to be broken anyway): > - ant-contrib > - jakarta-common-httpclient > - jakarta-ws-rs > - maven-invoker-plugin > - spec-version-maven-plugin I will be maintaining ant. maven-invoker-plugin is typically a test dependency, so alternatively you can disable tests in your packages. spec-version-maven-plugin can be easily removed, for example see jakarta-annotations package. > I introduced the jansi1 and jline2 packages so that jansi could be > moved to 2.x and jline to 3.x, but I don't actually maintain any > packages that need the old versions. I would like to give them away > to someone who needs them, but note that you will need to grab > jansi-native as well, before Monday! Fedora should ideally ship only a single version of libraries like jansi and jline. Compat packages are intended to be used transitively until packages are ready to migrate to the latest version. maven package is a good example - it used to depend on jansi1, but has recently been ported to jansi, version 2. If no one is interested in jansi1 and jline2 then it's natural course of action to orphan and retire them. -- Mikolaj Izdebski > Has anybody already done something about any of these packages (and my > packager-dashboard page just hasn't caught up yet)? Is anybody > planning to do something about any of these packages before they are > retired on Monday? > -- > Jerry James > http://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
python-lxml license change
License of python-lxml package was changed from "BSD" to "BSD and MIT and zlib" ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: hamcrest update to 2.2 in Fedora rawhide
On Mon, May 31, 2021 at 1:12 PM Miro Hrončok wrote: > > On 17. 05. 21 21:57, Mikolaj Izdebski wrote: > > Hello, > > > > Next week I'm going to update package hamcrest in Fedora rawhide from > > version 1.3 to version 2.2. > > > > The proposed update contains an API change that can affect packages > > depending on hamcrest. You may need to rebuild your packages to keep > > working with updated hamcrest. > > > > The update has already been checked into dist-git and a Koji build has > > already been done, but Bodhi update has not been submitted yet. Bodhi > > update is expected after a week, to comply with Updates Policy that > > mandates a notification one week in advance before submitting an API > > changing update. > > > >Current NVR in rawhide: hamcrest-1.3-31.fc34 > >Updated NVR: hamcrest-2.2-3.fc35 > >Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748364 > > > > Packages depending on hamcrest that are possibly affected by this update: > > * eclipse, maintained by lef jerboaa dbhole rgrunber jjohnstn > > akurtakov ebaron oliver mbooth arobinso > > * freemarker, maintained by filiperosset > > * hamcrest, maintained by akurtakov mizdebsk jerboaa > > * hdf, maintained by sagitter orion > > * hdf5, maintained by deji sagitter orion ignatenkobrain > > * icedtea-web, maintained by jvanek dbhole omajid > > * jmock, maintained by orphan > > * openas2, maintained by sdgathman > > * py4j, maintained by raphgro > > Hey Mikolaj, > > libreoffice now fails to build because of this change and without building > libreoffice, we might need to postpone the Python 3.10 rebuild. I'd rather > avoid doing that. Would you please be able to help? > The error is: > > checking for included Hamcrest... Not included > checking for standalone hamcrest jar configure: error: junit does not > contain hamcrest; please use a junit jar that includes hamcrest, install a > hamcrest jar in the default location (/usr/share/java), >specify its path with --with-hamcrest=..., or > disable junit with --without-junit > > > Seems like the configure script (or whatever that is) fails to find hamcrest. That's because libreoffice hardcodes path to hamcrest JAR in the configure script, instead of using one of the tools designed to locate JAR files in the system. That is covered in Java Packaging Guidelines [1]. > The bugzilla is https://bugzilla.redhat.com/show_bug.cgi?id=1965975 I could add a compat symlink to the hamcrest package, but it seems that the issue was fixed on the libreoffice side. -- Mikolaj Izdebski [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_hardcoded_paths > > Thanks, > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: hamcrest update to 2.2 in Fedora rawhide
On Fri, May 21, 2021 at 1:55 AM Fabio Valentini wrote: > > On Fri, May 21, 2021 at 1:10 AM Mikolaj Izdebski wrote: > > > > Hello, > > > > Next week I'm going to update package hamcrest in Fedora rawhide from > > version 1.3 to version 2.2. > > > > The proposed update contains an API change that can affect packages > > depending on hamcrest. You may need to rebuild your packages to keep > > working with updated hamcrest. > > > > The update has already been checked into dist-git and a Koji build has > > already been done, but Bodhi update has not been submitted yet. Bodhi > > update is expected after a week, to comply with Updates Policy that > > mandates a notification one week in advance before submitting an API > > changing update. > > > > Current NVR in rawhide: hamcrest-1.3-31.fc34 > > Updated NVR: hamcrest-2.2-3.fc35 > > Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748364 > > Note that hamcrest versions 2.x have already been available for over a year: > https://src.fedoraproject.org/rpms/hamcrest2 hamcrest2 package is orphaned and it will be retired soon, unless someone adopts it. As maintainer of hamcrest I would like to keep it at the latest upstream version. Older versions can of course be packaged as compat packages with version suffix in the name, if anyone wishes to maintain them. > We packaged them separately because, IIRC, maven artifact coordinates > and java package import paths are completely separate between version > 1.x and 2.x so packages can't just be updated, but actually need to be > ported to the new 2.x APIs. That is the API break I was speaking of. Hence I gave maintainers of dependent packages a week to respond and prepare their packages to work with updated hamcrest, by porting to hamcrest 2.2 or by packaging version 1.x as hamcrest1 compat package and switching packages to use it instead of hamcrest. -- Mikolaj Izdebski > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
maven-plugin-bundle update to 5.1.1 in Fedora rawhide
Hello, Next week I'm going to update package maven-plugin-bundle in Fedora rawhide from version 4.2.1 to version 5.1.1. The proposed update contains an API change that can affect packages depending on maven-plugin-bundle. You may need to rebuild your packages to keep working with updated maven-plugin-bundle. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: maven-plugin-bundle-4.2.1-4.fc34 Updated NVR: maven-plugin-bundle-5.1.1-2.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748398 Packages depending on maven-plugin-bundle that are possibly affected by this update: * antlr32, maintained by mbooth * apache-commons-parent, maintained by mizdebsk * byteman, maintained by jhuttana jerboaa * cglib, maintained by mef mizdebsk jerboaa * fasterxml-oss-parent, maintained by orphan * google-guice, maintained by mizdebsk * hibernate-jpa-2.1-api, maintained by jjelen lef * java-diff-utils, maintained by jjames * jaxb-istack-commons, maintained by orphan * jcommon, maintained by caolanm jerboaa * jfreechart, maintained by lkundrak jerboaa * jline, maintained by msimacek jjames mizdebsk jerboaa * lucene, maintained by jerboaa msimacek kdaniel rgrunber akurtakov dchen lef * portlet-2.0-api, maintained by jjelen * postgresql-jdbc, maintained by jjanco praiskup jmlich odubaj hhorak * tomcat-taglibs-parent, maintained by fcami abbra * xmlunit, maintained by bubeck mizdebsk -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
hamcrest update to 2.2 in Fedora rawhide
Hello, Next week I'm going to update package hamcrest in Fedora rawhide from version 1.3 to version 2.2. The proposed update contains an API change that can affect packages depending on hamcrest. You may need to rebuild your packages to keep working with updated hamcrest. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: hamcrest-1.3-31.fc34 Updated NVR: hamcrest-2.2-3.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748364 Packages depending on hamcrest that are possibly affected by this update: * eclipse, maintained by lef jerboaa dbhole rgrunber jjohnstn akurtakov ebaron oliver mbooth arobinso * freemarker, maintained by filiperosset * hamcrest, maintained by akurtakov mizdebsk jerboaa * hdf, maintained by sagitter orion * hdf5, maintained by deji sagitter orion ignatenkobrain * icedtea-web, maintained by jvanek dbhole omajid * jmock, maintained by orphan * openas2, maintained by sdgathman * py4j, maintained by raphgro -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
guava update to 30.1 in Fedora rawhide
Hello, Next week I'm going to update package guava in Fedora rawhide from version 25.0 to version 30.1. The proposed update contains an API change that can affect packages depending on guava. You may need to rebuild your packages to keep working with updated guava. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: guava-25.0-10.fc34 Updated NVR: guava-30.1-2.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748368 Packages depending on guava that are possibly affected by this update: * auto, maintained by mbooth * clojure-maven-plugin, maintained by korkeala * eclipse-m2e-core, maintained by mizdebsk mbooth galileo * google-guice, maintained by mizdebsk * guava, maintained by mizdebsk * maven, maintained by mizdebsk * maven-indexer, maintained by mizdebsk mbooth galileo * maven-shade-plugin, maintained by mizdebsk deamn pingou * plexus-containers, maintained by mizdebsk * protobuf, maintained by mizdebsk abbot ignatenkobrain * xmvn, maintained by mizdebsk -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
testng update to 7.3.0 in Fedora rawhide
Hello, Next week I'm going to update package testng in Fedora rawhide from version 6.14.3 to version 7.3.0. The proposed update contains an API change that can affect packages depending on testng. You may need to rebuild your packages to keep working with updated testng. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: testng-6.14.3-14.fc34 Updated NVR: testng-7.3.0-2.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748441 Packages depending on testng that are possibly affected by this update: * byteman, maintained by jhuttana jerboaa * hamcrest, maintained by akurtakov mizdebsk jerboaa * testng-remote, maintained by mbooth -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
osgi-core update to 8.0.0 in Fedora rawhide
Hello, Next week I'm going to update package osgi-core in Fedora rawhide from version 7.0.0 to version 8.0.0. The proposed update contains an API change that can affect packages depending on osgi-core. You may need to rebuild your packages to keep working with updated osgi-core. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: osgi-core-7.0.0-6.fc34 Updated NVR: osgi-core-8.0.0-2.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748429 Packages depending on osgi-core that are possibly affected by this update: * aqute-bnd, maintained by mizdebsk * geronimo-osgi-support, maintained by orphan mizdebsk * jackson-modules-base, maintained by edewata jmagne cipherboy * maven-plugin-bundle, maintained by mizdebsk * openas2, maintained by sdgathman -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
maven-antrun-plugin update to 3.0.0 in Fedora rawhide
Hello, Next week I'm going to update package maven-antrun-plugin in Fedora rawhide from version 1.8 to version 3.0.0. The proposed update contains an API change that can affect packages depending on maven-antrun-plugin. You may need to rebuild your packages to keep working with updated maven-antrun-plugin. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: maven-antrun-plugin-1.8-13.fc34 Updated NVR: maven-antrun-plugin-3.0.0-2.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748394 Packages depending on maven-antrun-plugin that are possibly affected by this update: * apache-commons-parent, maintained by mizdebsk * eclipse, maintained by lef jerboaa dbhole rgrunber jjohnstn akurtakov ebaron oliver mbooth arobinso * eclipse-egit, maintained by jerboaa kdaniel rgrunber akurtakov jjohnstn mbooth arobinso * eclipse-gef, maintained by kdaniel rgrunber akurtakov mbooth * maven-invoker, maintained by orphan mizdebsk * tuxguitar, maintained by oget -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
apache-resource-bundles update to 30 in Fedora rawhide
Hello, Next week I'm going to update package apache-resource-bundles in Fedora rawhide from version 2 to version 30. The proposed update contains an API change that can affect packages depending on apache-resource-bundles. You may need to rebuild your packages to keep working with updated apache-resource-bundles. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: apache-resource-bundles-2-27.fc34 Updated NVR: apache-resource-bundles-30-2.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748379 Packages depending on apache-resource-bundles that are possibly affected by this update: * apache-parent, maintained by mizdebsk * maven-license-plugin, maintained by guidograzioli * xmltool, maintained by guidograzioli -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
aqute-bnd update to 5.2.0 in Fedora rawhide
Hello, Next week I'm going to update package aqute-bnd in Fedora rawhide from version 4.3.1 to version 5.2.0. The proposed update contains an API change that can affect packages depending on aqute-bnd. You may need to rebuild your packages to keep working with updated aqute-bnd. The update has already been checked into dist-git and a Koji build has already been done, but Bodhi update has not been submitted yet. Bodhi update is expected after a week, to comply with Updates Policy that mandates a notification one week in advance before submitting an API changing update. Current NVR in rawhide: aqute-bnd-4.3.1-4.fc34 Updated NVR: aqute-bnd-5.2.0-2.fc35 Build link: https://koji.fedoraproject.org/koji/buildinfo?buildID=1748372 Packages depending on aqute-bnd that are possibly affected by this update: * bouncycastle, maintained by ellert gil rgrunber jjohnstn mbooth * freemarker, maintained by filiperosset * jdom2, maintained by mizdebsk * scala, maintained by jjames geoff mizdebsk * tomcat, maintained by huwang csutherl coolsvap van -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
Hi Hans, On Wed, Apr 28, 2021 at 3:47 PM Hans de Goede wrote: > Also I hope it is ok if I pick your brain a bit on a java > packaging issue which I've been having. > > I maintain a couple of java leave packages (games) + some deps > which AFAIK are only used by these games. > > One of these deps (dom4j) has been FTBFS since F34: > https://bugzilla.redhat.com/show_bug.cgi?id=1923601 > > I've been looking into this and the actual problem seems to > be with Java 9 now including what once was the org.relaxng.datatype > except they did not just bundle it, they also changed where it > sits in the namespace to com.sun.tools.rngdatatype > > Just doing a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ > got me a bit further, but it seems that msv, which is a dep of > dom4j needs to be rebuild first with the same search-replace > done on it and the FTBFS bug of msv is stuck because of one > of its deps getting orphaned+retired : > https://bugzilla.redhat.com/show_bug.cgi?id=1923446 > > So I think I can fix this by: > > 1. Unorphaning jvnet-parent, which is the missing msv dep You can unorphan/unretire it, but removing dependency on jvnet-parent is another choice. Probably better choice as jvnet-parent is no longer developed or maintained by upstream. > 2. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in msv, rebuild > 3. Do a s/org.relaxng.datatype/com.sun.tools.rngdatatype/ in dom4j, rebuild relaxngDatatype was retired in Fedora. A replacement is jaxb-relaxng-datatype package (built from jaxb source package), but it uses a different namespace. Therefore steps 2 and 3 seem correct and necessary. > And then either do this only for rawhide, or push all 3 modified > packages to F34 in a single bodhi update. > > Mikolaj, does this sounds like a reasonable plan to you; or > should I approach this differently? Yes, that sounds good. I would also double check to see whether msv/dom4j are really needed by your packages. > Also if yes this is a reasonable plan any advice on also > pushing the fixed packages to F34, or not ? I am in favor of F34 update. Users of dom4j/msv that do not rely on relaxngDatatype-related functionality should be unaffected by the update. Users that do rely on it would get it fixed. > > Regards, > > Hans > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Tue, Apr 27, 2021 at 5:18 PM Dan Čermák wrote: > > Hi Mikolaj, > > Mikolaj Izdebski writes: > > > 5) automating the process of bootstrapping Maven and Ant with related > > components, so that new versions can be imported and built > > reproducibly and with consistent quality. > > You might want to take a look at openSUSE's maven package: > https://build.opensuse.org/package/show/Java:packages/maven > > It builds itself using ant and not using maven. You'll probably > recognize a good chunk of the spec, because it originally came from > Fedora (I'm also pretty certain that Fridrich, the package maintainer, > would not object to a cross distribution collaboration). Thanks for the suggestion, but IMO Maven in Fedora should be built the same way as upstream builds it, that is with Maven. That minimizes the possibility of deviating from upstream and introducing unnoticed bugs. Instead a custom project was created that is used to build from scratch a minimal environment that contains Maven and that can be used to build Maven package. Then Maven can be used to rebuild itself as many times as needed. -- Mikolaj Izdebski > > > Cheers, > > Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, Apr 26, 2021 at 9:26 PM Fabio Valentini wrote: > I will orphan all Java packages I am the main admin of, later today. I've adopted the majority of Java packages that were orphaned by Fabio, primarily those that are related to Maven or Ant. I've been maintaining numerous Java packages in Fedora for more than 9 years. As modularity was developed, I saw it as an opportunity to make my life as a package maintainer easier. Initially I tried to make Maven and Ant available as default streams and in the buildroot so they could be available and consumed by non-modular packages. In the end that did not and I completely respect the decisions of FESCo to disallow default streams to then to disallow modules except for alternative versions. That means I'll be maintaining Maven and Ant with their runtime and build dependencies as non-modular packages. My plans for the upcoming months regarding adopted packages include: 1) triaging all open bugs and reviewing all open pull requests, 2) closing the gap between Fedora and CentOS, by merging dist-git contents of appropriate components in Fedora Rawhide and CentOS Stream 9, 3) unretiring some of Maven and Ant dependencies, 4) improving testing automation, especially implementing package-specific tests for use in gating, 5) automating the process of bootstrapping Maven and Ant with related components, so that new versions can be imported and built reproducibly and with consistent quality. 6) restoring Maven compatibility with OpenJDK 8, so that users who are stuck with older JDKs have an ability to keep using their build tools with JDK of their preference. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What is the most time consuming task for you as packager?
On Thu, Dec 17, 2020 at 9:11 PM Kevin Fenzi wrote: > > On Wed, Dec 16, 2020 at 03:56:25PM -0500, Neal Gompa wrote: > ...snip... > > > > What I'd really like would be a "test mass rebuild" process, where a > > > > prospective package is uploaded and everything that depends on it is > > > > automatically rebuilt (ideally after creating the dependency graph so > > > > each individual package doesn't get rebuilt until its dependencies are > > > > finished building). > > > > > > > > Creating the dependency graph by hand is fairly tedious, but maybe I'm > > > > missing an automated way. The point of creating that graph is to avoid > > > > wasting time and power doing and redoing builds that will fail until > > > > something else has been built (which is the problem with mock's > > > > --chain command, if I understand correctly). > > > > > > > > Once I have that graph, I use Make to control the process, because it > > > > handles the dependency graph, as well as parallelism, and not > > > > rebuilding things unnecessarily. > > > > > > Yeah, all this ^ > > > > > > > So I've written tools for doing this, and Igor has written tools for > > doing this, but it seems like people think that this is "impossible" > > and so the effort goes nowhere despite several PoCs. > > > > If we're interested in this again for real this time, I could try to > > dig out my old code for it, but we might be better off just pulling > > out Koschei's code and turning it into something that Koji's > > chain-build command and Mock's --chain option use to sort through > > package sets and build them correctly. > > Can you expand on which 'this' you mean? Getting the build > order/dependency graph? Or a tool to use that to rebuild everything and > tell you what failed? or ? > > I don't think you can ever be 100% on dependency graph/build order, > because there's sometimes bootstraps or loops in there. :( > > Anyhow I would love to be able to locally build a new library and run > 'fedpkg does-it-blend foo.src.rpm' and have it tell me exaclty what > other packages that breaks. That feature was implemented [1] in Koschei long time ago, but it is not enabled in Fedora production instance of Koschei due to Copr not completing RFR [2]. It should be deployed in Fedora staging instance of Koschei. You can build one or more package updates locally or in Copr and send request to Koschei to test the set of packages. Koschei will check which packages are affected by the update by resolving dependencies and running builds in Copr. Koschei provides an overview page saying which packages were affected (broken or fixed) by the update. Another variant of this feature was implemented [3] more recently without reliance on Copr - it makes use of Koji side tags. It was intended to be integrated with CI and gating - Koschei can test side tags and emit results to messaging bus in CI format [4] that is understood by CI system and can be used by packagers to implement gating for their packages. Again, this feature is not enabled in production, only in staging. [1] https://github.com/fedora-infra/koschei/issues/113 [2] https://pagure.io/fedora-infrastructure/issue/5166 [3] https://pagure.io/fedora-ci/general/issue/45#comment-606344 [4] https://pagure.io/fedora-ci/messages > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Mon, Dec 21, 2020 at 11:13 AM Vít Ondruch wrote: > > There is also a possibility for a group or individual to request their > > packages to be auto-tracked - whenever the person or group gets at > > least commit privileges to a package in dist-git, Koschei will start > > tracking it. To request auto-tracking of packages in Koschei you can > > open a ticket with Fedora Infrastructure, or contact me directly. > > > I definitely want all my packages autotracked! It happens from time to > time I adopt some package just to find out later it is not included in > Koschei. And similar case are probably new packages ... Auto-tracking for individual users is currently broken due to Pagure API break [1], so it needs development work to fix it. [1] https://pagure.io/pagure/issue/3824 > > > Vít > > > > > > -- > > Mikolaj Izdebski > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is the most time consuming task for you as packager?
On Wed, Dec 16, 2020 at 8:18 PM Jonathan Wakely wrote: > Can we just add everything to Koschei instead > of having it opt-in? That is technically possible, but so far no one asked about this. Currently 53 % of all packages (and 59 % of rawhide packages) are "tracked", which means Koschei submits scratch builds for them. The rest is not tracked, which means Koschei only resolves dependencies for them, but does not submit scratch builds to Koji to save resources. There is also a possibility for a group or individual to request their packages to be auto-tracked - whenever the person or group gets at least commit privileges to a package in dist-git, Koschei will start tracking it. To request auto-tracking of packages in Koschei you can open a ticket with Fedora Infrastructure, or contact me directly. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java reviews (with swaps)
On Mon, Nov 16, 2020 at 8:30 PM Jerry James wrote: > I would like to ask for some input from those of you with Java > packaging experience. The jsonp package has been orphaned, but the > antlr4-project package (which I maintain) still needs it. Since jsonp > has transitioned to the eclipse-ee4j project, I thought it best to let > the current jsonp package die, and replace it with a jakarta-jsonp > package. > > The parent POM for jakarta-jsonp, org.eclipse.ee4j:project:pom:, has > not been packaged for Fedora. Other packages with that parent have > simply added %pom_remove_parent to their spec files. With > jakarta-jsonp, though, I'm running into some difficulties doing so. > The parent POM has default version numbers for various plugins. Those > version numbers are not duplicated in the jakarta-jsonp POM. This > leads to maven telling me that the missing version numbers invoke > deprecated functionality and that the project will stop building with > some future version of maven. I could: This warning is relevant for upstream projects, but you can safely ignore it when building RPM packages with XMvn - it always uses packaged versions of Maven plugins, ignoring versions configured in POM. > (1) add %pom_remove_parent and ignore maven until the project actually breaks; > (2) add %pom_remove_parent and then do some XPath gymnastics to add > the missing version numbers into the jakarta-jsonp POM; or > (3) package the parent POM and stop worrying. > > I've chosen to do (3). Tell me if you think this is wrong. IMHO (1), (3), (2), in that order of preference. (3) is the most elegant solution, but requires maintaining one more package than (1), which also works. (2) doesn't make much sense - it would only silence the warning at the cost of cluttering the spec file, making it harder to maintain. > As for jakarta-jsonp itself, the latest version is 2.0.0, but it fails > to build because it needs jakarta-ws-rs 3.x and jakarta-annotations > 2.x. We have versions 2.1.6 and 1.3.5, respectively, in Rawhide right > now. Therefore, I have gone with version 1.1.6 of jakarta-jsonp for > now. That should be fine. Packaging the latest available version is not always the best choice. > Here's the next bit of input I need: why does "%pom_remove_plugin -r > org.apache.maven.plugins:maven-javadoc-plugin" only remove the plugin > from the top-level POM, in spite of the -r flag? I have to manually > remove it from the subdirectory POMs. It's hard to say without looking at the POM structure. I can check if you give me a reference to the code (upstream, SRPM etc). -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Fri, Sep 11, 2020 at 11:01 AM Miro Hrončok wrote: > > Thank you for describing the entire story from your pov, I think it's very > helpful! > > On 11. 09. 20 9:34, Mikolaj Izdebski wrote: > > I can't drop my > > packages and move back to co-maintaining ursine packages as it would > > mean losing 2 years of my work and the features I developed. > > I guess there are two sides of this: > > - the lost features > > Can you work together with the new Java maint SIG to have those features > integrated in the nonmodular packages? Possibly. I will think about this more. > > - the lost years > > While sad I believe that at a certain point, we need to be able to admit that > the years are lost in order to save ourselves from loosing even more years. > This > is a very important aspect in accepting that modularity in Fedora was a > failure. > If we don't do this, we'll keep failing. I agree and I accept that. Thanks, -- Mikolaj > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Fri, Sep 11, 2020 at 10:54 AM Tomasz Torcz wrote:
>
> On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> > You get a side tag in Koji where you can have private build-only
> > dependencies that are discarded (filtered) once they are no longer
> > needed, after module build is done. For build-only packages most of
> > security vulnerabilities are not exploitable easily, or at all,
> > therefore are low-severity, which greatly limits maintenance work
> > required to address them. For example, if upstream tests are ran on an
> > obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> > but I can package old Tomcat and run the tests.
>
> Whoha! Let's step back for a minute and look at this example.
> What are the reasons to run tests? To make sure the package will run
> correctly..
To prevent RPM build from succeeding in case bugs are found and
forcing the maintainer to investigate the issue (fix the bug, disable
broken test etc.)
> Why run tests on 12-years old version instead of on current one?
> Probably because tests fail on current version?
Because at the time tests were developed that was the most recent
Tomcat version. Since then upstream did not update the perfectly
working test suite ("If it ain't broke, don't fix it"). They will not
even accept our contribution to update the test suite.
> Will the end user run the package on obsolete Tomcat or on the current one?
Neither. The package is a HTTP client and tests merely need the server
side (Tomcat).
> Of course on the current one. The one on which tests fail.
> Tests in this case are worthless, they are not testing the real
> situation. Disabling tests is no worse than testing on obsolete version.
> Relying on such tests is a disservice for the end user.
>
> The point of testing is to validate code in real situation.
> Crafting special, unrealistic environment (12 years old Tomcat) just to have
> test pass is missing the point of tests.
>
> --
> Tomasz Torcz There exists no separation between gods and men:
> to...@pipebreaker.pl one blends softly casual into the other. — Frank
> Herbert
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Fri, Sep 11, 2020 at 8:44 AM Petr Pisar wrote: > > On Thu, Sep 10, 2020 at 09:59:05PM +, Zbigniew Jędrzejewski-Szmek wrote: > > For Maven packaging the appeal of Modularity is clearly the privatization of > > the dependency tree, which obviously undercuts the ecosystem of packages. > > > You are right that bundling is one of the features of Modularity and that this > freedom undermines an integration effort on the Fedora distribution level. > > But bundling is not the only appeal for Maven maintainers. If I can speek for > Mikolaj, then another appeal is sharing a module among multiple Fedora > releases. Because byte-compiled Java code is portable, it is possible to build > a module on Fedora 31 and have the same module build available on Fedora 34. > This saves the module maintainers from the burden of rebuilding the Java > packages for each Fedora and Modularity is the first place that actuallty can > leverage this Java feature. Right. Building modules once and shipping the same packages to all releases used to be important to me, but since then I developed a new way of bootstrapping Maven (MBI - Maven Bootstrap Initiative) so that now I can build Maven in a reliable, reproducible way. That modularity feature is therefore no longer important to me. -- Mikolaj ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Thu, Sep 10, 2020 at 9:59 PM Matthew Miller wrote: > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote: > > maintain the non-modular packages. We are not going to promise to > > commit time and resources to maintain the non-modular packages. > > Joe, here's a part I hope you can help me understand better. Modularity > isn't an entirely new packaging technology. It's simply a layer on top of > RPM. Modules are made out of RPMs, and by design, their specfiles are > exactly the same as RPMs which happen to be grouped into modules. Modularity provides not only a different way of grouping or delivering RPM packages, but most importantly, a different way of building RPM packages. You get a side tag in Koji where you can have private build-only dependencies that are discarded (filtered) once they are no longer needed, after module build is done. For build-only packages most of security vulnerabilities are not exploitable easily, or at all, therefore are low-severity, which greatly limits maintenance work required to address them. For example, if upstream tests are ran on an obsolete, 12-years old version of Tomcat, I don't need to skip tests, but I can package old Tomcat and run the tests. I don't need to update that Tomcat or fix security issues as they are not exploitable in buildroot - Tomcat runs in embedded mode, does not listen on the network etc. Not something that I could with ursine Tomcat packages - it would get delivered to users, and we have no control how they use it - we would need to fix all important user-reported bugs and CVEs as they are potentially exploitable. Modularity also introduced the concept of API packages - non-API packages can have limited usability, with some non-important features removed. For example if all I need is a small part of Tomcat, I can reduce tomcat package to build just the tiny parts that I need, which don't have any dependencies. Again, not something I could do with ursine Tomcat package. Another, more concrete example: core Ant doesn't have any dependencies beyond JDK. It is easy to build and maintain, yet very functional. On the other hand, full Ant with all the optional tasks depends on more than 200 Java packages. For the purpose of building all packages that I am interested in, core Ant with JUnit tasks (total of 3 packages) is sufficient. Functionalities of Ant like sending emails or image processing are obviously not needed in this case. If building other packages is the only use of Ant then it can be maintained much more easily (3 instead of ~250 packages). But when Ant is ursine package in Fedora then it should be the full Ant - we can't claim to deliver Ant to users while it is just part of it. Eclipse in Fedora requires full Ant too. > I understand that it's nice to have exactly one workflow, but it doesn't > seem like it's actually all that much extra effort on top of what you > already have to do to maintain the module to make a non-modular build. Is > this something where triggering the non-modular builds in the same way you > build the module would make a difference? It's not about the workflow, it is about reducing package maintenance work that is required. Modularity allows us to greatly reduce the number of packages by patching-out non-API packages to remove unneeded features and it allows us to spend less time on fixing bugs in packages that are used merely as build dependencies and which we don't intend to be used by end users. > > Or is there something else that I'm not seeing? > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Fri, Sep 11, 2020 at 12:32 AM Zbigniew Jędrzejewski-Szmek wrote: > This exchange summarizes the situation nicely. > > Modularity can be considered an over-complicated hyped-through-the-roof > bundling mechanism. > > For a long time Fedora has very strongly discouraged bundling in the sense of > subsumming one package into another to have a custom build of a dependency. > > The disapproval of bundling is not because it doesn't work: it does, and in > fact with some crappy libraries it's the least bad solution. The disapproval > is motivated by the fact that bundling doesn't scale and that it subtracts > from > the ecosystem. Instead of us all cooperating and each bugfix helping all > users of a given dependency, a maintainer of a bundled library is only helping > themselves and their package. > > Bundling is not inherently bad: currently the policy even allows it as > a workaround if using the system-wide package is not feasible. It is a > pragmatic choice to allow it as a last resort. But the effect of bundling > on other packages must be minimized any conflicts or confusion with the > system version avoided. > > With Modularity, we threw this accumulated wisdom away. > In two ways: by encouraging private^Wbuild-only dependencies and by > letting bundled^Wmodularized rpms shadow normal rpms. > > For Maven packaging the appeal of Modularity is clearly the privatization of > the dependency tree, which obviously undercuts the ecosystem of packages. > > The Java ecosystem collapsed so quickly because it was already weak > — hundreds of packages on the shoulders of one person. But even in a stronger > ecosystem, with enough packages modularized, the packaging ecosystem of > mutual cooperation would collapse. > > For some other modules, the appeal is the overriding of package deps, which > means that the modular rpms don't have to worry about getting it deps > precisely > declared, at the cost of breaking the deps declared in other packages. > > If there wasn't Modularity and instead Maven would bundle it's deps into > one huge srpm, the effect on the ecosystem would be the same. As with > bundling, Modularization gives short-term relief at a very high long-term > cost. We should avoid modularization like we avoid bundling. You summarized it really well, thanks Zbyszek. To me bundling is, and always was, an important design feature of modularity. There are other important aspects of it, but I dare to say that from my PoV its form of bundling is the most important feature. I wanted to expand on your story, present my version of the same story. For a long time we (Java maintenance team at Red Hat) were maintaining Fedora packages without any form of bundling because it was considered harmful and was not allowed in any way, not without explicit exception. Over time the number of contributors to Java packaging (number of active Java SIG members) was decreasing, most of Java maintainers were gone, or "unresponsive". Making changes to our packages, like improving packaging automation, required testing and possibly adjusting thousands of others' packages, most of which were largely unmaintained. Unresponsive maintainer processes would not work as it would require us to take maintenance of orphaned packages, which we could not afford. In the meantime our Java maintenance team was shrunk from 4 people down to just one person, me. I had to severely limit the time I spent on Fedora due to other commitments - I had to spend more time on RHEL work and other side projects, like Koschei, that I was responsible for. I could not afford to spend my free after-work time on Fedora due to personal reasons (I got married, started building a house etc.) Combined with the collapse of Java SIG, the situation was difficult. Then a new, sophisticated way of bundling, called modularization, was designed and came to my help. This way of bundling was no only considered not harmful, but also approved and even made as a Fedora objective. Since it solved the biggest issues I had with packaging, I became a very eager early adopter and quickly built everything as modules. I was still maintaining non-modular packages, but I hoped that one day non-modular packages would be completely replaced by modules. When modules were added to Fedora proper, I made them default streams and waited for a solution like Ursa-Major that would allow me to retire ursine packages, replacing them with modular packages. RHEL enabled Ursa-Major. My javapackages-tools module was the first ones to make use of it in RHEL and we succeeded to retire all ursine packages in RHEL. When Fedora finally rejected Ursa-Major, I was very frustrated as I perceived it as begin of collapse of modularity, the great feature that promised to solve the problems I had with packaging. I could not easily move back to ursine packages and I was already committed to maintaining modules in RHEL, so I decided to live with Fedora decision and orphan almost all of my ursine packages.
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Thu, Sep 10, 2020 at 7:31 PM Daniel P. Berrangé wrote: > > On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote: > > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote: > > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote: > > > > > > > 4. The benefit we want to preserve from modules is to maintain packages > > > > with varying expectation of quality, specifically separating the > > > > build-time-only vs runtime dependencies. e.g. in that case that a web > > > > server like Eclipse Jetty is required as a dep for testing another > > > > component during the build, we want to be able to use and build that > > > > component, without being indefinitely on the hook for security errata. > > > > (The build dependency tree is particularly complex for Maven and > > > > involves many examples of packages with frequent and high severity > > > > vulnerabilies) > > > > > > What are you doing different in terms of supporting deps in the module > > > that reduces the security errata burden, compared to non-modular builds ? > > > > > > It feels like if we have some policy that is creating unsustainable > > > maint burden wrt non-modular packaging, we should re-examine this > > > policy rather than trying to workaround it by going modular, which > > > creates a different kind of maint burden. > > > > > In non-modular Fedora all packages that we have in Fedora build system > > (Koji) > > are tagged into Fedora repositories and made available to all users on their > > computers for any purpose. That implies that all packages in Fedora build > > system > > must be fully supported including addressing all security issues. > > > > In modular Fedora that's (effectively) not true. Packages that only exist > > for the sake of building other packages (i.e. build-only dependencies) can > > be > > retained in the Fedora build system and never left it. That means those > > packages are never made available to Fedora users and thus a service level > > for > > them is significantly lower. E.g. no security fixes, not bug fixes, no > > integration, not tests, no API/ABI stability. The only requirement is that > > they can be built and used for building other packages. > > So conceptually, one way we can solve this problem by implementing a way > to mark certain non-modular RPMs as "build root only" packages and thus > composing them into a separate "build root" yum repo, that is not enabled > by default except in the build system. Yes. This can also be achieved with on-demand side tags that are already implemented: "build-only" packages are built in a sidetag and untagged before sidetag is merged. They never appear in release tags and they are not shipped to users. Builds can be reproduced locally in mock with configs generated by "koji mock-config" command. > Modularity is being used because it is the only solution that is available > today, not because it is a good/desired solution. Right. Modularity is definitely not the best solution, and IMHO it definitely has worse user experience compared to ursine packages. Modularity is used because it was the only solution available at the moment the decision (to modularize Maven and Ant) was made. Since then an alternative solution was developed, but we haven't decided to switch back to ursine packages yet, although we are considering that. > > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Thu, Sep 10, 2020 at 4:35 PM Tomasz Torcz wrote: > > On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote: > > In non-modular Fedora all packages that we have in Fedora build system > > (Koji) > > are tagged into Fedora repositories and made available to all users on their > > computers for any purpose. That implies that all packages in Fedora build > > system > > must be fully supported including addressing all security issues. > > > > In modular Fedora that's (effectively) not true. Packages that only exist > > for the sake of building other packages (i.e. build-only dependencies) can > > be > > retained in the Fedora build system and never left it. That means those > > packages are never made available to Fedora users and thus a service level > > for > > them is significantly lower. E.g. no security fixes, not bug fixes, no > > integration, not tests, no API/ABI stability. The only requirement is that > > they can be built and used for building other packages. > > > So, if user wants to locally rebuild the package, they won't be able to > do it? Because BuildRequired packages won't be available? Modules can be built locally with "fedpkg module-build-local", which downloads required dependencies from Koji and installs them in mock chroot. These packages are not installed directly (outsides of chroot) on users systems. > > > -- > Tomasz Torcz“Funeral in the morning, IDE hacking > to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Thu, Sep 10, 2020 at 3:46 PM Alexander Scheel wrote: > > Hi Joe, > > On Thu, Sep 10, 2020 at 8:52 AM Joe Orton wrote: > > > > Hi all, > > > > I'm writing as the Red Hat engineering manager responsible for Maven and > > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my > > team. I want to give a broad response to some of the points here: > > > > 1. The team has two missions in Fedora: > > > > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is > > to provide developers with the most popular Java build systems which are > > reviewed, tested, and updated through the release lifecycle. > > > > b) We design, develop and document tooling that enables anyone to > > package Java software with a simple, efficient and scalable process. We > > are also active members of Java SIG, collaborating on complex changes > > and guiding new contributors. > > > > 2. We are committed to maintaining the Ant and Maven modules in > > Fedora. We have always expected to make them available as default > > streams and in the buildroot so they can be available and consumed by > > non-modular packages, but we completely respect the decisions of FESCo > > to disallow default streams and of other contributors to adopt and > > maintain the non-modular packages. We are not going to promise to > > commit time and resources to maintain the non-modular packages. > > As a reminder (as in my RHEL devel-list reply): there are no default > module streams in Fedora. There is also no Ursa Major/Prime, so were > they to exist, there would still be no way for non-modular packages to > use them. There are default module streams in Fedora 31. > This makes the artifacts produced here useful only to other modules. > Non-modular packages maintained by other Red Hatters, like Eclipse and > Dogtag PKI cannot use these artifacts. Both of these stacks have tried > to modularize in Fedora but ultimately remained non-modular. Our goal is to deliver Maven and Ant to end users, maintaining dependencies of Dogtag PKI is outside of my area of interest. End users can consume Maven and Ant from the modules, which aligns with our mission statement. > > 3. Our efforts are currently directed mainly at minimization of the > > dependency tree which leads to maven and ant, automating the process of > > bootstrapping maven and updating related components, so that new > > versions can be imported and built reproducibly and with consistent > > quality. > > > > 4. The benefit we want to preserve from modules is to maintain packages > > with varying expectation of quality, specifically separating the > > build-time-only vs runtime dependencies. e.g. in that case that a web > > server like Eclipse Jetty is required as a dep for testing another > > component during the build, we want to be able to use and build that > > component, without being indefinitely on the hook for security errata. > > (The build dependency tree is particularly complex for Maven and > > involves many examples of packages with frequent and high severity > > vulnerabilies) > > > > Regards, Joe > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Thu, Sep 10, 2020 at 4:04 PM Petr Pisar wrote: > > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote: > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote: > > > > > 4. The benefit we want to preserve from modules is to maintain packages > > > with varying expectation of quality, specifically separating the > > > build-time-only vs runtime dependencies. e.g. in that case that a web > > > server like Eclipse Jetty is required as a dep for testing another > > > component during the build, we want to be able to use and build that > > > component, without being indefinitely on the hook for security errata. > > > (The build dependency tree is particularly complex for Maven and > > > involves many examples of packages with frequent and high severity > > > vulnerabilies) > > > > What are you doing different in terms of supporting deps in the module > > that reduces the security errata burden, compared to non-modular builds ? > > > > It feels like if we have some policy that is creating unsustainable > > maint burden wrt non-modular packaging, we should re-examine this > > policy rather than trying to workaround it by going modular, which > > creates a different kind of maint burden. > > > In non-modular Fedora all packages that we have in Fedora build system (Koji) > are tagged into Fedora repositories and made available to all users on their > computers for any purpose. That implies that all packages in Fedora build > system > must be fully supported including addressing all security issues. > > In modular Fedora that's (effectively) not true. Packages that only exist > for the sake of building other packages (i.e. build-only dependencies) can be > retained in the Fedora build system and never left it. That means those > packages are never made available to Fedora users and thus a service level for > them is significantly lower. E.g. no security fixes, not bug fixes, no > integration, not tests, no API/ABI stability. The only requirement is that > they can be built and used for building other packages. > > I wrote that it was not effectively true. There is probably no such policy > that would de jure allowed lowering the service level for the build-only > packages. But at the same time there is nobody who could enforce it. Users do > not have the packages, security team does know about them, they cannot break > a compose, and they do not intefere with packages from other modules. The only > place where they are visible is dist-git and Koji. Thus they only need to pass > a review (a legal requirement). +1 That is very well put, thanks Petr for explaining it in detail. > > -- Petr > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Thu, Sep 10, 2020 at 3:29 PM Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 10 September 2020 at 14:50, Joe Orton wrote: > [...] > > 1. The team has two missions in Fedora: > > > > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim > > is to provide developers with the most popular Java build systems > > which are reviewed, tested, and updated through the release > > lifecycle. > > > > b) We design, develop and document tooling that enables anyone to > > package Java software with a simple, efficient and scalable process. > > We are also active members of Java SIG, collaborating on complex > > changes and guiding new contributors. > > > > 2. We are committed to maintaining the Ant and Maven modules in > > Fedora. We have always expected to make them available as default > > streams and in the buildroot so they can be available and consumed by > > non-modular packages, but we completely respect the decisions of FESCo > > to disallow default streams and of other contributors to adopt and > > maintain the non-modular packages. We are not going to promise to > > commit time and resources to maintain the non-modular packages. > > Points 1b and 2 mean that nobody can consume your packages for > maintaining non-modular Java packages, which raises the bar for > maintaining Java packages considerably. Javapackages is the main project that provides Java packaging tooling. I am maintaining it both upstream [1] and in Fedora, also as ursine package [2]. > [...] > > 4. The benefit we want to preserve from modules is to maintain > > packages with varying expectation of quality, specifically separating > > the build-time-only vs runtime dependencies. e.g. in that case that a > > web server like Eclipse Jetty is required as a dep for testing another > > component during the build, we want to be able to use and build that > > component, without being indefinitely on the hook for security > > errata. (The build dependency tree is particularly complex for Maven > > and involves many examples of packages with frequent and high severity > > vulnerabilies) > > On one hand, that's understandable, but you're effectively maintaining > those packages anyway. And I don't see any reason why you couldn't do > that in the traditional non-modular way, which makes it easier for > others to step in and co-maintain. I'm not sure what you mean by > "indefinitely on the hook for security errata". Can you elaborate? All Fedora packages shipped to users are expected to be high-quality and well maintained, which may impose a very significant burden on maintainers. But for build-only packages (packages are used only during build, not shipped to users), many of package maintainer responsibilities [3] can be reduced to almost nothing. For example "manage security issues" means triaging them and fixing only very small subset of them (since user can't install the packages, most of vulnerabilities are not exploitable), "deal with reported bugs" means closing them NOTABUG as users can't possibly install the package in a "supported" way, "track dependency issues" duty is reduced as nothing non-modular can depend on the package, and so on. [1] https://github.com/fedora-java/javapackages [2] https://src.fedoraproject.org/rpms/javapackages-tools [3] https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Removing a branch created by mistake
On Wed, Sep 9, 2020 at 3:15 PM Jun Aruga wrote: > > Yesterday I created the "wip/2.7" branch on modules/ruby dist-git > repository by mistake. ;-< > https://src.fedoraproject.org/modules/ruby/branches > > I remember the current rule is we can not remove the branch we created, right? The branch can be removed as long as commits in the branch are reachable from another branch. See https://pagure.io/fesco/issue/2340#comment-628281 -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What's up with koschei?
On Mon, Feb 17, 2020 at 10:27 AM Fabio Valentini wrote: > I've noticed that koschei doesn't seem to have scheduled any scratch > builds since around the fedora 32 mass rebuild, and it also hasn't > picked up the f32 branch yet. Koschei collections are manipulated manually by Koschei admins (members of sysadmin-koschei FAS group). Since all sysadmin-koschei members were on vacation during and after Fedora 32 branching, corresponding collections have not been created yet. I expect to create them this week. > Is there a known "outage" or is it just sitting there idle for some > reason? I really like to know when my packages start to FTBFS ... That was unplanned outage - someone scaled scheduler service down to zero replicas, so it was not running. Unfortunately after move to OpenShift we don't have decent monitoring for Koschei, so we don't have a way of seeing such problems until they are reported by users. I've just scaled scheduler up and it seems to be running again. Thanks for the report. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Who maintains the service at mbs.fedoraproject.org:443?
mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You can report issues at [2]. [1] https://fedoraproject.org/wiki/Infrastructure [2] https://pagure.io/fedora-infrastructure/issues -- Mikolaj Izdebski On Mon, Feb 17, 2020 at 12:20 PM Stephan Bergmann wrote: > > I am trying to do a build of LibreOffice from Fedora RPMs (à la > <https://docs.fedoraproject.org/en-US/flatpak/>), but `fedpkg > module-build` keeps failing with > > > The modulemd libreoffice.yaml is invalid. Please verify the syntax is > > correct. > > after > <https://src.fedoraproject.org/flatpaks/libreoffice/c/6aad9bd0db5a067c71a0dcfbc27185466fc3a7dc?branch=master> > "Restrict builds to x86_64". > > Judging from strace and what little information the --verbose option of > fedpkg provides, it looks like that error message is reported back from > mbs.fedoraproject.org:443. Could it be that that installation is > missing > <https://github.com/fedora-modularity/libmodulemd/commit/c54a0fff7ece446603835464a394a3f854408e47> > "Add support for new ModulemdBuildopts arches attribute"? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
On Sat, Feb 8, 2020 at 12:23 PM Ankur Sinha wrote: > > Hello, > > netcdf-java[1] uses the Gradle build system, and is required to update > hdfview[2] to the latest version. Gradle, however, was retired[3] as > "out of date, broken, fails to build, basically unmaintainable". > > Now, I know that following our system, one must package Gradle first but > given the retirement comment, packaging and then maintaining it does not > appear a simple task, and for one dependency only, it seems overkill. > > Is there perhaps a way of bypassing that somehow? For example, is there > a way to use good old Maven to build a Gradle based project? There are several different ways to handle this problem. In this case my recommendation is to port packages to be built with Maven instead of Gradle. The exact way to do this varies between projects, but in general you'd need to obtain Maven POMs for particular project (eg. from Maven Central), add missing build instructions ( section of POM files) and model composition/inheritance ( and elements of POM). There are several cases of packages that are built this way in Fedora, which you can use as examples. Let me know if you need more help. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
On Thu, Feb 13, 2020 at 11:33 AM Jun Aruga wrote: > > > Anyone with the time to (co-)maintain Gradle? :) > > I added Mikolaj and Daniel to TO. > They had maintained gradle before being dead.package, seeing the past > commits in rpms/gradle. > Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle? Currently I don't have time to maintain Gradle in Fedora. Several of my packages are built with Gradle by their upstreams, but currently it is more feasible to port packages to be built with Maven rather than maintaining Gradle in Fedora. But this may change in the future - as more projects start to use Gradle I may decide to take up its maintenance in upcoming years. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java Dev Group and Fedora Quality
On Tue, Jan 28, 2020 at 12:18 AM Neal Gompa wrote: > Honestly, the correct thing is to make it so the maven to RPM > interface is as transparent as possible. We've done a reasonably good > job with this in Rust, Ruby, and Python, and the situation is (slowly) > improving in Go. But nobody has sat down and looked at what we have in > RPM today and taken a fresh look at how Java packaging *could* work. I [...] > Riffing off what Florian had for his DevConf.cz talk title, > JPackage/RPM Java is basically packaging like it's 1999. The rest of > the ecosystems are moving forward. Java has not. And I think that's > where a lot of the pain exists. That is not true. Java packaging in Fedora has been improved a lot over the past years. In the last few years we have automated or improved many things, such as: - removal of post/postun scriptlets for Maven metadata generation, - auto-requires/provides for Maven and OSGi artifacts, - versioned auto-requires on JRE/JDK, - macros for POM editing, - integration with various build systems, incl. Maven, Tycho, Gradle, Ivy, - automatic documentation (javadoc) generation, - javadoc subpackage generation, - buildrequires generation during build, - auto buildrequires (with mock plugin), and many more > But without interest or investment from the Java stack packagers at > Red Hat, there's basically no way to get a redesign of Java packaging > done, much less even on the table. I don't see any need for total redesign of Java packaging, but if anyone wants to do it, you can count on me to participate in that effort. Likewise, I'm interested in making smaller improvements to the current design. If anyone has any requests or suggestions for improvements to Java packaging, you can write to java-devel list or open issue at https://github.com/fedora-java/javapackages/issues -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Groovy Build Failing Due to Disappearance of groovy-local
On Mon, Jan 27, 2020 at 1:08 PM Miro Hrončok wrote: > > On 27. 01. 20 10:34, Mikolaj Izdebski wrote: > > On Mon, Jan 27, 2020 at 6:04 AM Bill Chatfield via devel > > wrote: > >> > >> I have chosen a delinquent Java package to work fix. But I need some help > >> understanding what's going on. Groovy is failing to build because it > >> depends on gradle-local which doesn't exist. But gradle-local did exist at > >> one time because groovy was successfully build with it on 2019-07-30. So, > >> where did gradle-local go? Why has it disappeared? I guess the important > >> question is how can I get it back? > > > > Building of "gradle-local" was disabled with a build conditional. > > Re-enabling it is possible as long as its dependencies are packaged > > and included in Fedora. To enable it, first make sure that its > > dependencies (i.e. "gradle" and "xmvn-connector-gradle") are in > > Fedora, then open a bug against "javapackages-tools" asking me to > > re-enable "gradle-local". > > In other words, you need to add gradle to add gradle-local and you ned to add > gradle-local to add gradle. This requires something we call bootstrapping and > is > one of the complicated stuff that usually requires package maintainers of all > relevant packages cooperating very closely. "gradle" can be built without "gradle-local" if "with bootstrap" bcond is used. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Groovy Build Failing Due to Disappearance of groovy-local
On Mon, Jan 27, 2020 at 6:04 AM Bill Chatfield via devel wrote: > > I have chosen a delinquent Java package to work fix. But I need some help > understanding what's going on. Groovy is failing to build because it depends > on gradle-local which doesn't exist. But gradle-local did exist at one time > because groovy was successfully build with it on 2019-07-30. So, where did > gradle-local go? Why has it disappeared? I guess the important question is > how can I get it back? Building of "gradle-local" was disabled with a build conditional. Re-enabling it is possible as long as its dependencies are packaged and included in Fedora. To enable it, first make sure that its dependencies (i.e. "gradle" and "xmvn-connector-gradle") are in Fedora, then open a bug against "javapackages-tools" asking me to re-enable "gradle-local". -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is the MBS (Module Build Service ?) alright?
On Wed, Nov 20, 2019 at 11:43 AM Fabio Valentini wrote: > I've been noticing irregular, weird surges in koji activity for the > past few weeks, and today, another one happened. Within 2 hours (8AM > and 10AM UTC), MBS submitted ±350 builds to koji (of which almost half > failed), drowning out any other build activity: > > koji list-builds --after=2019-11-20 --before=2019-11-21 --sort-key=-build-id On November 20, 2019, 07:35:08 UTC I submitted module build #7074 [1], which completed successfully. On November 20, 2019, 09:33:54 UTC I submitted module build #7079 [2], which failed. [1] https://release-engineering.github.io/mbs-ui/module/7074 [2] https://release-engineering.github.io/mbs-ui/module/7079 > Previous occurrences of these surges (at least the ones I noticed, > because koji was awfully slow to schedule any of my builds) were on > Nov 6, Nov 8, and Nov 12. > See: https://twitter.com/decathorpe/status/1192061920829984768 Whenever someone submits a big module build, MBS can submit hundreds of individual component builds to Koji. In case of javapackages-tools module it is ~168 components. Koji builds are picked up and processed in FCFS order, meaning that any builds submitted after module component builds will be picked up after modular builds. > I hope that's some sign that something is not working as intended? This is expected behaviour of MBS. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What's the State of the Java SIG?
On Mon, Nov 18, 2019 at 12:17 PM John M. Harris Jr wrote: > > On Monday, November 18, 2019 3:42:20 AM MST Mikolaj Izdebski wrote: > > IMHO effort spent on maintenance of most of these ursine Java packages > > is mostly wasted effort. As I said before, many times, these packages > > should be retired and replaced by modular packages, which are > > maintained by Java SIG members like me. maven and ant modules are > > already default streams, so users should get them instead of ursine > > packages. The last remaining step is enabling javapackages-tools in > > ursine buildroot so that ursine packages can be built with modular > > maven. Once that happens, there will be no reason to maintain ursine. > > Therefore, instead of putting time on updating ursine Maven et al. > > I recommend to put effort towards enabling modules in ursine buildroots. > > Why in the world do you want to move even more to modules? Not move more to modules, but to reduce duplication by putting module into buildroot and retiring corresponding ursine packages. > > That is not true. It is entirely possible and feasible to build a > > distribution without ursine Maven/XMvn etc. For example look at > > RHEL 8 - it includes Maven and Ant only as modules. Modules are > > used to build ursine Java packages. The same solution should be > > implemented in Fedora. > > I must disagree. That it "works" in RHEL doesn't mean that it should be done > in Fedora. The current situation in Fedora, where maven and ant have been > "moved" to modules has screwed over the Eclipse packagers, for example, and > more are to follow. That was not what I said. I made a point that it is not necessary to indefinitely maintain ursine Maven because modular Maven can be used to build ursine packages. I used RHEL as a proof that this is doable. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What are the benefits of default modular streams over non-modular packages?
On Thu, Nov 14, 2019 at 4:59 PM Miro Hrončok wrote: > I've asked whether it wouldn't be in fact much easier to keep the default > versions of our packages non-modular. > > Others have said they are interested in this as well. A huge thread happened > but > it hasn't delivered an answer. > Arguments were made that default modular streams are planned to deliver the > exact same experience as non-modular packages, yet it was not said if it > wouldn't be easier to just deliver non-modular packages for default versions. > > Maybe it would be helpful to try to reformulate the question: > > > **What are the benefits of default modular streams over non-modular > packages?** As Petr Pisar noted earlier, default streams are designed to deliver the same user experience as ursine packages, therefore there is no *direct* advantage or disadvantage of them over ursine packages, for Fedora *users*. Default streams are modules. Building packages as modules has very significant advantages to some package maintainers. Certain maintainers (like me) can save a lot of time by building packages as modules. This *indirectly* benefits users and other Fedora contributors - maintainers who can more easily build packages have more time to spend on important bugs and features affecting users, can get more involved in other Fedora activities etc. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What's the State of the Java SIG?
gt; They're currently shadowing non-modular packages (since they have > default streams), but I understand this is getting fixed. This means Shadowing of ursine packages by modular packages is not a defect. That is a feature of modularity. Therefore there is nothing to fix there. > that the non-modular Java packages (especially maven, ant, xmvn, their > dependencies, and other packages which are used for building Java RPM > packages in fedora) will need to be maintained as non-modular packages > indefinitely. That is not true. It is entirely possible and feasible to build a distribution without ursine Maven/XMvn etc. For example look at RHEL 8 - it includes Maven and Ant only as modules. Modules are used to build ursine Java packages. The same solution should be implemented in Fedora. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Switching Maven and Ant to OpenJDK 11
On Mon, Oct 28, 2019 at 1:52 PM Alex Scheel wrote:
> > I am planning to switch Maven 3.6 and Ant 1.10 modules to build with
> > and run on OpenJDK 11, which is the latest LTS release of OpenJDK.
> > This also means that future streams of javapackages-tools module will
> > default to use OpenJDK 11 for building packages. Please let me know if
> > you have any concerns.
>
> My concern is what will happen to the libraries in the default module
> stream? When installing, e.g., dogtag-pki, this brings in the following
> packages from a default module stream:
This is a valid concern, thanks for bringing it up.
>
> apache-commons-cli-0:1.4-4.module_f28+3939+dc18cd75.noarch
> apache-commons-codec-0:1.11-3.module_f28+3939+dc18cd75.noarch
> apache-commons-io-1:2.6-3.module_f28+3939+dc18cd75.noarch
> apache-commons-logging-0:1.2-13.module_f28+3939+dc18cd75.noarch
> httpcomponents-client-0:4.5.5-4.module_f28+3939+dc18cd75.noarch
> httpcomponents-core-0:4.4.10-3.module_f28+3939+dc18cd75.noarch
>
> Of these, apache-commons-{cli,codec,io,logging} are all directly required
> by dogtag-pki, which doesn't yet fully work with JDK-11. (I'm not quite
> sure how httpcomponents-{client,core} gets pulled in).
>
>
> Will you continue building these with a target bytecode version for use
> with JDK8, even though you're building with JDK11? Or are you only building
> the maven and ant packages with JDK 11 (and not building all libraries
> in the module with JDK 11)?
These libraries will still be built with JDK <= 8 bytecode, so they
should continue to work with JDK 8.
--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Switching Maven and Ant to OpenJDK 11
On Fri, Oct 25, 2019 at 11:27 PM Fabio Valentini wrote: > > > E.g. would the dependent OpenJDK 8 packages still build in stable > > > releases if > > > this change is done globally and for example if Ursa Major/Prime/... is > > > activated? > > > > Changing underlying OpenJDK version of maven:3.6 module doesn't change > > anything with regards to building other packages. Right now nothing > > build-depends on maven:3.6 module. And if Ursa-Major were enabled in > > Fedora, most of ursine Java packages would become FTBFS anyway as > > maven modules are not capable of building packages with. See below for > > more details. > > Uhh ... wait, what? That's not good. Is there anything we can do to > prevent this clusterf*ck? I'm planning to make Maven modules parallel-installable with ursine packages - maven-3.6 module would not have any conflicts with any ursine packages. The required packaging work is already done, parallel-installable PoC of Maven 3.6 is available from MBI repos [1]. Currently I'm waiting for one MBS/Koji [2] issue to be resolved before building the module in Fedora infrastructure. The issue is already fixed in staging Koji and I hope that production will be fixed soon too. Once parallel-installability is implemented, existence of Maven modules will not affect building any packages. Ursine Java packages will be built with ursine Maven, while modular Java packages will be built with javapackages-tools module, maintained by me. [1] https://koji.kjnet.xyz/kojifiles/repos/m36/latest/x86_64/ [2] https://pagure.io/fm-orchestrator/issue/1321 -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Switching Maven and Ant to OpenJDK 11
On Fri, Oct 25, 2019 at 8:47 PM Miro Hrončok wrote: > > On 25. 10. 19 19:30, Mikolaj Izdebski wrote: > > Hello, > > > > Currently default Java runtime in Fedora is OpenJDK 8. This is not the > > latest OpenJDK packaged, but still remains system-default version. > > Because of that Apache Maven and Apache Ant in Fedora are built using > > OpenJDK 8 and run on OpenJDK 8. > > > > I am planning to switch Maven 3.6 and Ant 1.10 modules to build with > > and run on OpenJDK 11, which is the latest LTS release of OpenJDK. > > This also means that future streams of javapackages-tools module will > > default to use OpenJDK 11 for building packages. Please let me know if > > you have any concerns. > > Hello, I am not very familiar with how Java works in this regard, but since > this > is the default stream etc., wouldn't it be wise to coordinate such change > with a > general OpenJDK 11 default Fedora system wide change? It probably would, but I'm not aware of any existing change proposal to switch default OpenJDK versions in Fedora. > E.g. would the dependent OpenJDK 8 packages still build in stable releases if > this change is done globally and for example if Ursa Major/Prime/... is > activated? Changing underlying OpenJDK version of maven:3.6 module doesn't change anything with regards to building other packages. Right now nothing build-depends on maven:3.6 module. And if Ursa-Major were enabled in Fedora, most of ursine Java packages would become FTBFS anyway as maven modules are not capable of building packages with. See below for more details. Since always Maven in Fedora was available in 2 flavors, each having different purposes. "maven" module provides Maven application for end users. This is pure upstream Maven that doesn't "know" how to access libraries packaged as RPMs and included in Fedora. Therefore it is mostly useless for building packages with and I am not aware of any package in Fedora being built with this pure Maven. For purposes of building packages "javapackages-tools" module is available - it provides XMvn - Maven with extensions that enable it to be used for building packages. It also provides RPM macros and other necessary tools which are not available in "maven". -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and all the things
On Wed, Oct 23, 2019 at 2:43 PM Petr Šabata wrote: > While these issues are being resolved, we are considering temporarily > disallowing default streams in Fedora. I don’t want to abandon the > idea completely, as doing so reduces the motivation to actually build > modules and reap the benefits they might provide. What do you mean by "disallowing" default streams? Do you mean removing them from Fedora? -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Koschei enablement for EPEL 8
Based on feedback received I have just added "EPEL 8" and "EPEL 8 playground" collections to Koschei. For now only a single package is tracked in each collection - epel-release package, but are free to add more packages as needed. On Wed, Aug 28, 2019 at 9:15 AM Mikolaj Izdebski wrote: > > Fedora infrastructure has been asked [1] to enable Koschei [2] for > EPEL 8. Would this be useful to anyone? If yes, which of build targets > (epel8-candidate, epel8-playground-candidate) should Koschei submit > scratch builds for? > > [1] https://pagure.io/fedora-infrastructure/issue/8099 > [2] https://fedoraproject.org/wiki/Koschei ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
License change of several Java packages
During licensing review several Java packages have been found out to have inaccurate license tags. I have fixed them in my forks in dist-git and I will eventually build fixed packages. Summary of changes made follows. spec-version-maven-plugin: -License: CDDL or GPLv2 with exceptions +License: CDDL-1.0 or GPLv2 with exceptions glassfish-annotation-api: -License: CDDL or GPLv2 with exceptions +License: CDDL-1.0 or GPLv2 with exceptions glassfish-el: -License:CDDL-1.1 or GPLv2 with exceptions +License:CDDL-1.0 or GPLv2 with exceptions glassfish-el-api: -License: (CDDL or GPLv2 with exceptions) and ASL 2.0 +License: (CDDL-1.0 or GPLv2 with exceptions) and ASL 2.0 jboss-interceptors-1.2-api: -License:CDDL or GPLv2 with exceptions +License:CDDL-1.0 or GPLv2 with exceptions glassfish-servlet-api: -License:(CDDL or GPLv2 with exceptions) and ASL 2.0 +License:(CDDL-1.0 or GPLv2 with exceptions) and ASL 2.0 glassfish-master-pom: -License: CDDL or GPLv2 with exceptions +License: CDDL-1.0 or GPLv2 with exceptions glassfish-legal: -License: CDDL or GPLv2 with exceptions +License: CDDL-1.0 or GPLv2 with exceptions -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Koschei enablement for EPEL 8
On Wed, Aug 28, 2019 at 2:53 PM Stephen John Smoogen wrote: > > On Wed, 28 Aug 2019 at 03:16, Mikolaj Izdebski wrote: > > > > Fedora infrastructure has been asked [1] to enable Koschei [2] for > > EPEL 8. Would this be useful to anyone? If yes, which of build targets > > (epel8-candidate, epel8-playground-candidate) should Koschei submit > > scratch builds for? > > > > Can koschei be limited to a single architecture or does it need to > build against all targets? I am worried about the number of s390 > builds we may be adding. Yes, Koschei can be limited to certain architectures, possibly just one. The instances that are ran on Fedora infrastructure are limited to x86_64, aarch64, ppc64 and ppc64le in production and just x86_64 in staging. Noarch builds can be ran on other architectures too, including s390x, but this is how Fedora Koji is configured. -- Mikolaj Izdebski ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Koschei enablement for EPEL 8
Fedora infrastructure has been asked [1] to enable Koschei [2] for EPEL 8. Would this be useful to anyone? If yes, which of build targets (epel8-candidate, epel8-playground-candidate) should Koschei submit scratch builds for? [1] https://pagure.io/fedora-infrastructure/issue/8099 [2] https://fedoraproject.org/wiki/Koschei ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Koschei branching?
On Sun, Aug 25, 2019 at 2:33 PM Igor Gnatenko wrote: > I see that there is no Fedora 31. Is anybody working on creating that > and moving rawhide forward to 32? Koschei branching is now complete. Sorry for the delay - it was caused by scheduled vacation of mine [1,2] as well as other unexpected events. [1] https://apps.fedoraproject.org/calendar/vacation/2019/8/12/#m9594 [2] https://apps.fedoraproject.org/calendar/vacation/2019/8/19/#m9595 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On Mon, Aug 12, 2019 at 11:21 AM Miro Hrončok wrote:
>
> On 12. 08. 19 11:16, Mikolaj Izdebski wrote:
> > On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok wrote:
> >>
> >> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> >>> On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
> >>>>
> >>>> See for example:
> >>>>
> >>>> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> >>>> 2019-08-11 07:50:11
> >>>>
> >>>> - nothing provides python(abi) = 3.6 ...
> >>>>
> >>>> This is provided in RHEL 7.7.
> >>>>
> >>>> (Note that we've unretired the python36 package, so later it resolved
> >>>> correctly.)
> >>>
> >>> Koschei uses Koji repos. You can find out the exact repo URL at given
> >>> timestamp in the following way:
> >>>
> >>> In [1]: import koji, datetime
> >>> In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> >>> In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> >>> In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> >>> In [5]: event = ks.getLastEvent(before=ts)
> >>> In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> >>> event=event['id'])
> >>> In [7]: pi.repo(repo['id'], 'epel7-build')
> >>> Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
> >>
> >> And for RHEL packages?
> >
> > Selected RHEL packages are available in EPEL buildroots.
>
> Oh. Do you know any pointers about how do I add more?
EPEL 7 build uses repos from 5 RHEL 7 channels.
You can see them with the following command:
$ koji list-external-repos --tag epel7-base
Pri External repo nameMode URL
--- - --
10 rhel7-server koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-rpms/
11 rhel7-rhel-extras koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-extras-rpms/
12 rhel7-server-ha koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-ha-for-rhel-7-server-rpms/
15 rhel7-server-optional koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-optional-rpms/
20 rhel7-server-rhscl-7 koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-server-rhscl-7-rpms/
Koji admins (i.e. Release Engineering) can add more channels upon
request from EPEL developers.
Before adding to Koji, RHEL repos would need to be synced from RHN to
Fedora servers (this can be requested from Fedora Infrastructure).
>
> >>> x86_64 repos are used for dependency resolution. At that time python36
> >>> was not available in epel7-build:
> >>
> >> Are RHEL packages available directly from epel7-build?
> >
> > Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
> > RHEL build.
>
> I see. Thanks.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok wrote:
>
> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> > On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
> >>
> >> See for example:
> >>
> >> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> >> 2019-08-11 07:50:11
> >>
> >> - nothing provides python(abi) = 3.6 ...
> >>
> >> This is provided in RHEL 7.7.
> >>
> >> (Note that we've unretired the python36 package, so later it resolved
> >> correctly.)
> >
> > Koschei uses Koji repos. You can find out the exact repo URL at given
> > timestamp in the following way:
> >
> > In [1]: import koji, datetime
> > In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> > In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> > In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> > In [5]: event = ks.getLastEvent(before=ts)
> > In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> > event=event['id'])
> > In [7]: pi.repo(repo['id'], 'epel7-build')
> > Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
>
> And for RHEL packages?
Selected RHEL packages are available in EPEL buildroots.
>
> > x86_64 repos are used for dependency resolution. At that time python36
> > was not available in epel7-build:
>
> Are RHEL packages available directly from epel7-build?
Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
RHEL build.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
>
> See for example:
>
> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> 2019-08-11 07:50:11
>
> - nothing provides python(abi) = 3.6 ...
>
> This is provided in RHEL 7.7.
>
> (Note that we've unretired the python36 package, so later it resolved
> correctly.)
Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:
In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:
$ dnf -q --repofrompath
epel7-build-1234463,https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463/x86_64/
--repo epel7-build-1234463 repoquery --whatprovides 'python(abi)'
python-0:2.7.5-80.el7_6.x86_64
python34-0:3.4.10-2.el7.x86_64
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: I wish to drop python2-Cython
On Tue, Aug 6, 2019 at 3:23 PM Fabio Valentini wrote: > On Tue, Aug 6, 2019, 15:17 Miro Hrončok wrote: >> > On Tue, 6 Aug 2019 at 13:11, Miro Hrončok > > <mailto:mhron...@redhat.com>> wrote: >> > On 06. 08. 19 14:07, Mat Booth wrote: >> > Eclipse will be shipping in modules only from F31. > > > If that's the case, do you plan to retire the packages in non-modular > branches? Right now, they're all broken, and "pollute" dependency queries > (this also affects the Stewardship SIG). We can't retire Eclipse packages as others depend on them. But after the recent mass-retirement of packages Eclipse packages are FTBFS [1] in rawhide and will be retired by releng, unless someone fixes them before Fedora 32 branching. [1] https://apps.fedoraproject.org/koschei/groups/eclipse?collection=f31 -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
On Mon, Aug 5, 2019 at 1:50 PM Hans de Goede wrote: > > Hi Fabio, > > On 05-08-19 13:37, Fabio Valentini wrote: > > On Mon, Aug 5, 2019 at 1:15 PM Mikolaj Izdebski wrote: > >> > >> On Mon, Aug 5, 2019 at 12:07 PM Hans de Goede wrote: > >>> In the extended version: > >>> https://churchyard.fedorapeople.org/orphans-2019-08-05.txt > >>> I see that javapackages-tools is still on the list (because it depends on > >>> gradle) > >>> and that in turn brings problems for lot of other packages. > >>> > >>> So I wonder what the plan forward is. I've been looking at my own packages > >>> which depend on javapackages-tools and they really only need 2 things: > >> > >> From my side as owner of javapackages-tools the plan is to do nothing > >> as there is no problem with javapackages-tools packages (that I know > >> of). If at some point of time javapackages-tools becomes FTBFS or FTI > >> due to gradle or another of its dependencies being retired, I will fix > >> the problem in an adequate way. > >> > >>> > >>> 1) javapackages-filesystem > >>> 2) %jpackage_script macro (and it deps) > >>> > >>> Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty > >>> much > >>> the minimum set of what packages need to follow the guidelines. It seems > >>> that > >>> javapackages-tools contains way more then this and I'm wondering if it > >>> would > >>> be a good idea to do a javapackages-tools-minimal as a separate package > >>> and > >>> move the 2 items from above there. Then over time we can move > >>> java-packages > >>> in the base package set to use javapackages-tools-minimal and eventually > >>> drop > >>> the full javapackages-tools from the base package set. > >> > >> I don't see any reason to add javapackages-tools-minimal or migrate > >> any packages. If there are any issues with javapackages-tools then > >> please open bugs and I will respond to them. > > > > To clarify, the package that *does* depend on a number of orphans is > > gradle, which also marks javapackages-tools and its sub-packages as > > affected. > > gradle is currently owned by the Stewardship SIG, but there is no > > reason for us to "maintain" it indefinitely. In fact, the gradle > > packaging is problematic in some ways: > > > > - the version packaged by fedora (and every other distro building it > > from source) is really outdated (4.4.1, released Dec 2017, vs. 5.5.1, > > released July 2019) > > - the build process is rather involved, and gradle currently can't > > even build itself > > > > Only about 10 "active" fedora packages are built with gradle, and they > > could be ported to use maven instead. There's already some fedora > > packages which are built with maven "downstream" instead of with the > > upstream gradle build system - including junit5, testng, and > > aqute-bnd. > > > > So, I am currently preparing to drop gradle after f31 was branched > > from rawhide (but keep it working in f31), unless somebody else steps > > up to maintain gradle and the dozens of dependencies it pulls in. If / > > when gradle support is eventually dropped, then we'll then have to > > remove gradle-local from javapackages-tools as well (which is easy, > > since that change already happened in modular branches). > > Thank you for all your work on this I'm happy to hear that the > gradle -> javapackages-tools -> lots of packages dep chain is > going to get fixed for F31. > > I do wonder though if the modular version of javapackages-tools has > already dropped gradle-local, perhaps we can move ahead and already > do the same thing in Fedora (31+)? Less cross package deps seems like > a good thing to me? But I guess that some other packages in the base > repo still depend on gradle-local? gradle-local package can't be removed yet because other packages depend on it. Removing dependency involves porting packages from Gradle to Maven, which can only be done by package maintainers. However most of Java package maintainers are not really active. Only after gradle package is retired, packages that transitively build-depend on it (through graldle-local) will become FTBFS and I will be allowed to fix them per provenpackager policy. -- Mikolaj ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
On Mon, Aug 5, 2019 at 12:07 PM Hans de Goede wrote: > In the extended version: > https://churchyard.fedorapeople.org/orphans-2019-08-05.txt > I see that javapackages-tools is still on the list (because it depends on > gradle) > and that in turn brings problems for lot of other packages. > > So I wonder what the plan forward is. I've been looking at my own packages > which depend on javapackages-tools and they really only need 2 things: From my side as owner of javapackages-tools the plan is to do nothing as there is no problem with javapackages-tools packages (that I know of). If at some point of time javapackages-tools becomes FTBFS or FTI due to gradle or another of its dependencies being retired, I will fix the problem in an adequate way. > > 1) javapackages-filesystem > 2) %jpackage_script macro (and it deps) > > Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty much > the minimum set of what packages need to follow the guidelines. It seems that > javapackages-tools contains way more then this and I'm wondering if it would > be a good idea to do a javapackages-tools-minimal as a separate package and > move the 2 items from above there. Then over time we can move java-packages > in the base package set to use javapackages-tools-minimal and eventually drop > the full javapackages-tools from the base package set. I don't see any reason to add javapackages-tools-minimal or migrate any packages. If there are any issues with javapackages-tools then please open bugs and I will respond to them. -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning/retiring 3 Java packages
On Wed, Jul 24, 2019 at 8:04 PM Peter Boy wrote: > Sorry for jumping in. I think this might be an opportunity to participate in > the Fedora Projekt. I’ve a lot of experience in java development and in > creating application rpms, but none in the specialties of Fedora packaging. > Would you accept me as co-maintainer and provide some guidance at the > beginning? I suppose you're not a packager yet. Regarding guidance, you can start with reading Java Packaging HOWTO [1] and Fedora packaging documentation on the wiki. If you have any questions then feel free to contact Java SIG [2] members through IRC or our mailing list. You don't need to be co-maintainer to contribute to Fedora packages - you can attach patches to bugs (either existing ones, or newly opened by you). Some maintainers also accept pull requests. Once you prove yourself you may be sponsored as packager and added as co-maintainer. [1] https://fedora-java.github.io/howto [2] https://fedoraproject.org/wiki/SIGs/Java -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
