Hi all,
I would like to keep jacop in Fedora. It is in danger of removal, due to the orphaning of scala. I've taken a look at keeping scala in Fedora, and updating it to its most recent version; see:
https://copr.fedorainfracloud.org/coprs/jjames/scala/
One issue is that recent scala needs jline 3.x (we have 2.x in Rawhide), and jline 3.x needs jansi 2.x (we have 1.x in Rawhide). Neither is backwards compatible with its previous major version. I have made jansi 1.x/2.x and jline 2.x/3.x parallel installable, but there is still at least one issue. The current jansi package Provides:
jansi = 1.18-5.fc33 mvn(org.fusesource.jansi:jansi) = 1.18 mvn(org.fusesource.jansi:jansi-project:pom:) = 1.18 mvn(org.fusesource.jansi:jansi:pom:) = 1.18 osgi(org.fusesource.jansi) = 1.18.0
The jansi2 package on COPR Provides:
jansi2 = 2.1.0-1.fc34 jansi2(x86-64) = 2.1.0-1.fc34 libjansi.so()(64bit) mvn(org.fusesource.jansi:jansi) = 2.1.0 mvn(org.fusesource.jansi:jansi:pom:) = 2.1.0 osgi(org.fusesource.jansi) = 2.1.0
There is overlap between the Provides, albeit with different version numbers. How should this be handled? I guess that packages that need version 1.x would have to include "BuildRequires: jansi < 2" and "Requires: jansi"?
Also, is it better to keep the existing jansi and jline packages, and add jansi2 and jline3 packages as I have done on COPR, or would it be better to add jansi1 and jline2 packages containing the current contents of jansi and jline, and then move jansi and jline to their latest versions?
I appreciate any thoughts anyone has on the matter. Regards,
Hi,
I believe the right thing to do would be to move to jline 3 for package 'jline' in rawhide and better, and perhaps keep jline2 as a compatibility package[1], like jline1 was at some point. That is, if some packages won't work with jline 3.
%mvn_compat_version macro might be helpful. See for example: https://src.fedoraproject.org/rpms/jline1/blob/f31/f/jline1.spec#_95
HTH, Severin
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_compatibili...
On Sun, 2020-12-13 at 20:43 -0700, Jerry James wrote: Hi all,
I would like to keep jacop in Fedora. It is in danger of removal, due to the orphaning of scala. I've taken a look at keeping scala in Fedora, and updating it to its most recent version; see:
https://copr.fedorainfracloud.org/coprs/jjames/scala/
One issue is that recent scala needs jline 3.x (we have 2.x in Rawhide), and jline 3.x needs jansi 2.x (we have 1.x in Rawhide). Neither is backwards compatible with its previous major version. I have made jansi 1.x/2.x and jline 2.x/3.x parallel installable, but there is still at least one issue. The current jansi package Provides:
jansi = 1.18-5.fc33 mvn(org.fusesource.jansi:jansi) = 1.18 mvn(org.fusesource.jansi:jansi-project:pom:) = 1.18 mvn(org.fusesource.jansi:jansi:pom:) = 1.18 osgi(org.fusesource.jansi) = 1.18.0
The jansi2 package on COPR Provides:
jansi2 = 2.1.0-1.fc34 jansi2(x86-64) = 2.1.0-1.fc34 libjansi.so()(64bit) mvn(org.fusesource.jansi:jansi) = 2.1.0 mvn(org.fusesource.jansi:jansi:pom:) = 2.1.0 osgi(org.fusesource.jansi) = 2.1.0
There is overlap between the Provides, albeit with different version numbers. How should this be handled? I guess that packages that need version 1.x would have to include "BuildRequires: jansi < 2" and "Requires: jansi"?
Also, is it better to keep the existing jansi and jline packages, and add jansi2 and jline3 packages as I have done on COPR, or would it be better to add jansi1 and jline2 packages containing the current contents of jansi and jline, and then move jansi and jline to their latest versions?
I appreciate any thoughts anyone has on the matter. Regards,
On Mon, Dec 14, 2020 at 2:21 AM Severin Gehwolf sgehwolf@redhat.com wrote:
I believe the right thing to do would be to move to jline 3 for package 'jline' in rawhide and better, and perhaps keep jline2 as a compatibility package[1], like jline1 was at some point. That is, if some packages won't work with jline 3.
Yes, some packages won't even build with jline 3.
%mvn_compat_version macro might be helpful. See for example: https://src.fedoraproject.org/rpms/jline1/blob/f31/f/jline1.spec#_95
Ah, that's what %mvn_compat_version is for! I found its man page to be rather unhelpful, I'm afraid. Okay, I will try that out. Thank you!
On Mon, Dec 14, 2020 at 4:46 AM Jerry James loganjerry@gmail.com wrote:
Hi all,
I would like to keep jacop in Fedora. It is in danger of removal, due to the orphaning of scala. I've taken a look at keeping scala in Fedora, and updating it to its most recent version; see:
https://copr.fedorainfracloud.org/coprs/jjames/scala/
One issue is that recent scala needs jline 3.x (we have 2.x in Rawhide), and jline 3.x needs jansi 2.x (we have 1.x in Rawhide). Neither is backwards compatible with its previous major version. I have made jansi 1.x/2.x and jline 2.x/3.x parallel installable, but there is still at least one issue. The current jansi package Provides:
jansi = 1.18-5.fc33 mvn(org.fusesource.jansi:jansi) = 1.18 mvn(org.fusesource.jansi:jansi-project:pom:) = 1.18 mvn(org.fusesource.jansi:jansi:pom:) = 1.18 osgi(org.fusesource.jansi) = 1.18.0
The jansi2 package on COPR Provides:
jansi2 = 2.1.0-1.fc34 jansi2(x86-64) = 2.1.0-1.fc34 libjansi.so()(64bit) mvn(org.fusesource.jansi:jansi) = 2.1.0 mvn(org.fusesource.jansi:jansi:pom:) = 2.1.0 osgi(org.fusesource.jansi) = 2.1.0
There is overlap between the Provides, albeit with different version numbers. How should this be handled? I guess that packages that need version 1.x would have to include "BuildRequires: jansi < 2" and "Requires: jansi"?
Duplicate osgi provides are generally not a problem. Duplicate mvn provides are, but there is a solution to this problem: compat packages, see https://fedora-java.github.io/howto/latest/#compat_packages Compat packages have different mvn provides, eg. mvn(org.fusesource.jansi:jansi:1) = 1.18
Also, is it better to keep the existing jansi and jline packages, and add jansi2 and jline3 packages as I have done on COPR, or would it be better to add jansi1 and jline2 packages containing the current contents of jansi and jline, and then move jansi and jline to their latest versions?
My preference would be to update jansi/jline to latest upstream versions and introduce compat packages jansi1/jline2 if necessary.
I appreciate any thoughts anyone has on the matter. Regards,
Jerry James http://www.jamezone.org/ _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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/java-devel@lists.fedoraproject...
On Tue, Dec 15, 2020 at 6:57 AM Mikolaj Izdebski mizdebsk@redhat.com wrote:
Duplicate osgi provides are generally not a problem. Duplicate mvn provides are, but there is a solution to this problem: compat packages, see https://fedora-java.github.io/howto/latest/#compat_packages Compat packages have different mvn provides, eg. mvn(org.fusesource.jansi:jansi:1) = 1.18
Yes, Severin pointed that out, so I have updated the COPR accordingly. This means little changes and rebuilds for packages that consume jansi 1.x and jline 2.x, which I have also built in COPR:
https://copr.fedorainfracloud.org/coprs/jjames/scala/
My preference would be to update jansi/jline to latest upstream versions and introduce compat packages jansi1/jline2 if necessary.
Thanks for the input, Mikolaj. Since that seems to be everybody's preference, I will go with that plan. Regards,
On Tue, Dec 15, 2020 at 4:36 PM Jerry James loganjerry@gmail.com wrote:
On Tue, Dec 15, 2020 at 6:57 AM Mikolaj Izdebski mizdebsk@redhat.com wrote:
Duplicate osgi provides are generally not a problem. Duplicate mvn provides are, but there is a solution to this problem: compat packages, see https://fedora-java.github.io/howto/latest/#compat_packages Compat packages have different mvn provides, eg. mvn(org.fusesource.jansi:jansi:1) = 1.18
Yes, Severin pointed that out, so I have updated the COPR accordingly. This means little changes and rebuilds for packages that consume jansi 1.x and jline 2.x, which I have also built in COPR:
https://copr.fedorainfracloud.org/coprs/jjames/scala/
My preference would be to update jansi/jline to latest upstream versions and introduce compat packages jansi1/jline2 if necessary.
Thanks for the input, Mikolaj. Since that seems to be everybody's preference, I will go with that plan. Regards,
Thanks for working on this! As main admin for jansi/-native, I approve of this approach. Do you plan to submit PRs for jansi and jline? At least creating the compat packages is at least easy.
Fabio
On Tue, Dec 15, 2020 at 8:43 AM Fabio Valentini decathorpe@gmail.com wrote:
Thanks for working on this! As main admin for jansi/-native, I approve of this approach. Do you plan to submit PRs for jansi and jline? At least creating the compat packages is at least easy.
Yes, I hope to get the review requests and pull requests all submitted today. I'm still making a few small tweaks to packages here and there, but I think it's about ready to go. Right now I'm submitting a few upstream pull requests for the handful of patches I needed to add.
On Tue, Dec 15, 2020 at 5:01 PM Jerry James loganjerry@gmail.com wrote:
On Tue, Dec 15, 2020 at 8:43 AM Fabio Valentini decathorpe@gmail.com wrote:
Thanks for working on this! As main admin for jansi/-native, I approve of this approach. Do you plan to submit PRs for jansi and jline? At least creating the compat packages is at least easy.
Yes, I hope to get the review requests and pull requests all submitted today. I'm still making a few small tweaks to packages here and there, but I think it's about ready to go. Right now I'm submitting a few upstream pull requests for the handful of patches I needed to add.
Great! Be aware that compat packages don't need to go through package review (just pass the --exception flag to fedpkg request-repo instead of a bug number).
Fabio
On Tue, Dec 15, 2020 at 9:03 AM Fabio Valentini decathorpe@gmail.com wrote:
Great! Be aware that compat packages don't need to go through package review (just pass the --exception flag to fedpkg request-repo instead of a bug number).
Thanks for the reminder. I had forgotten that.
On Tue, Dec 15, 2020 at 5:04 PM Jerry James loganjerry@gmail.com wrote:
On Tue, Dec 15, 2020 at 8:43 AM Fabio Valentini decathorpe@gmail.com wrote:
Thanks for working on this! As main admin for jansi/-native, I approve of this approach. Do you plan to submit PRs for jansi and jline? At least creating the compat packages is at least easy.
Yes, I hope to get the review requests and pull requests all submitted today. I'm still making a few small tweaks to packages here and there, but I think it's about ready to go. Right now I'm submitting a few upstream pull requests for the handful of patches I needed to add.
FYI, when adding compat packages you don't need to follow the review process, see the second bullet of https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
-- Jerry James http://www.jamezone.org/ _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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/java-devel@lists.fedoraproject...
On Wed, Dec 16, 2020 at 1:48 AM Mikolaj Izdebski mizdebsk@redhat.com wrote:
FYI, when adding compat packages you don't need to follow the review process, see the second bullet of https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
Right, that's a nice shortcut. I'll try to round up some volunteers today to do the handful of necessary reviews (juniversalchardet for jline 3.x, and 3 more for scala), and then build everything into a side tag so I don't disrupt life for everyone while we're in the middle of building. Thanks again for the help and advice. Regards,
On Wed, Dec 16, 2020 at 9:57 AM Jerry James loganjerry@gmail.com wrote:
Right, that's a nice shortcut. I'll try to round up some volunteers today to do the handful of necessary reviews (juniversalchardet for jline 3.x, and 3 more for scala), and then build everything into a side tag so I don't disrupt life for everyone while we're in the middle of building. Thanks again for the help and advice. Regards,
The jansi1 and jline2 packages have been built into a side tag. The next step is for maintainers to review and hopefully merge the open pull requests against jansi and jline:
https://src.fedoraproject.org/rpms/jansi/pull-request/2 https://src.fedoraproject.org/rpms/jline/pull-request/2
Those packages should then be built into the side tag:
fedpkg build --target=f34-build-side-35261
Once the jansi pull request has been merged and built, the following pull requests can then be merged and built into the side tag:
https://src.fedoraproject.org/rpms/log4j/pull-request/7 https://src.fedoraproject.org/rpms/maven/pull-request/27
Once the jline pull request has been merged and built, the following pull requests can then be merged and built into the side tag:
https://src.fedoraproject.org/rpms/aqute-bnd/pull-request/8 https://src.fedoraproject.org/rpms/bsh/pull-request/2 https://src.fedoraproject.org/rpms/eclipse-m2e-core/pull-request/1 https://src.fedoraproject.org/rpms/frysk/pull-request/3 https://src.fedoraproject.org/rpms/jython/pull-request/5 https://src.fedoraproject.org/rpms/rhino/pull-request/2
Once those builds have taken place, we can merge the side tag back in, and I can get on with reviving scala. Thanks everybody.
On Wed, Jan 6, 2021 at 4:43 PM Jerry James loganjerry@gmail.com wrote:
On Wed, Dec 16, 2020 at 9:57 AM Jerry James loganjerry@gmail.com wrote:
Right, that's a nice shortcut. I'll try to round up some volunteers today to do the handful of necessary reviews (juniversalchardet for jline 3.x, and 3 more for scala), and then build everything into a side tag so I don't disrupt life for everyone while we're in the middle of building. Thanks again for the help and advice. Regards,
The jansi1 and jline2 packages have been built into a side tag. The next step is for maintainers to review and hopefully merge the open pull requests against jansi and jline:
https://src.fedoraproject.org/rpms/jansi/pull-request/2 https://src.fedoraproject.org/rpms/jline/pull-request/2
Those packages should then be built into the side tag:
fedpkg build --target=f34-build-side-35261
Once the jansi pull request has been merged and built, the following pull requests can then be merged and built into the side tag:
https://src.fedoraproject.org/rpms/log4j/pull-request/7 https://src.fedoraproject.org/rpms/maven/pull-request/27
I am building jansi 2.1.1 in the side tag, and will build log4j and maven once that's done. I'd like to have mbooth look at the jline PR, it's his package.
Thanks again for working on this.
Fabio
On Wed, Jan 6, 2021 at 12:22 PM Fabio Valentini decathorpe@gmail.com wrote:
I am building jansi 2.1.1 in the side tag, and will build log4j and maven once that's done. I'd like to have mbooth look at the jline PR, it's his package.
By all means! More eyes on a change like this is a good thing.
Thanks again for working on this.
My pleasure. I seem to have a weak spot for programming languages. Once all this is done, I'll be maintaining 3 Common Lisps, a Scheme, a Prolog, an ML, and finally Scala. :-) Honestly, though, in every case it isn't the language itself that I'm interested in, but rather some other package(s) written in that language.
On Thu, Jan 7, 2021 at 5:36 PM Jerry James loganjerry@gmail.com wrote:
On Wed, Jan 6, 2021 at 12:22 PM Fabio Valentini decathorpe@gmail.com wrote:
I am building jansi 2.1.1 in the side tag, and will build log4j and maven once that's done. I'd like to have mbooth look at the jline PR, it's his package.
By all means! More eyes on a change like this is a good thing.
Thanks again for working on this.
My pleasure. I seem to have a weak spot for programming languages. Once all this is done, I'll be maintaining 3 Common Lisps, a Scheme, a Prolog, an ML, and finally Scala. :-) Honestly, though, in every case it isn't the language itself that I'm interested in, but rather some other package(s) written in that language.
I mentioned the jline 3 transition to mbooth on the #fedora-java IRC channel, and he told me that so long as there's a transition plan for migrating packages to the jline2 compat package, it's fine.
Fabio
On Mon, Jan 11, 2021 at 7:33 AM Fabio Valentini decathorpe@gmail.com wrote:
I mentioned the jline 3 transition to mbooth on the #fedora-java IRC channel, and he told me that so long as there's a transition plan for migrating packages to the jline2 compat package, it's fine.
Thanks for pinging him. I'm not sure what "it's fine" means, though. That's what all of the other pull requests are for, certainly. But does that mean that I should merge the jline changes and do the build myself, or are you or Matt going to do that?
On Mon, Jan 11, 2021 at 9:55 PM Jerry James loganjerry@gmail.com wrote:
On Mon, Jan 11, 2021 at 7:33 AM Fabio Valentini decathorpe@gmail.com wrote:
I mentioned the jline 3 transition to mbooth on the #fedora-java IRC channel, and he told me that so long as there's a transition plan for migrating packages to the jline2 compat package, it's fine.
Thanks for pinging him. I'm not sure what "it's fine" means, though. That's what all of the other pull requests are for, certainly. But does that mean that I should merge the jline changes and do the build myself, or are you or Matt going to do that?
Sorry, I should have clarified. We can coordinate merging those PRs and submitting the builds if you want help, or you have my go-ahead and can coordinate with yourself (which is hopefully easier than coordinating with three people). :)
Fabio
On Mon, Jan 11, 2021 at 2:35 PM Fabio Valentini decathorpe@gmail.com wrote:
Sorry, I should have clarified. We can coordinate merging those PRs and submitting the builds if you want help, or you have my go-ahead and can coordinate with yourself (which is hopefully easier than coordinating with three people). :)
I generally coordinate very well with myself, the primary exception being attempting to walk, chew gum, and think about a software problem all at the same time, which tends to overload the cranial circuits. I'll get the builds going. Thanks, Fabio!
On Mon, Jan 11, 2021 at 2:35 PM Fabio Valentini decathorpe@gmail.com wrote:
Sorry, I should have clarified. We can coordinate merging those PRs and submitting the builds if you want help, or you have my go-ahead and can coordinate with yourself (which is hopefully easier than coordinating with three people). :)
The builds are done, and I have requested that the side tag be merged. As noted in the eclipse-m2e-core pull request, that package was already failing to build in Rawhide prior to this change. I submitted a build anyway in case the problem lay in some other package and had since been fixed, but that build failed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=59470754
The package will now have broken dependencies in Rawhide. I'll poke at it a bit and see if I can figure out the nature of the build failure.
java-devel@lists.fedoraproject.org