orphaned some java packages : jakarta-saaj, jakarta-xml-ws , jmock
Hi, I just orphaned some java packages : - jakarta-saaj - jakarta-xml-ws - jmock Lack of time and nothing depend on it Happy new year ! -- Sérgio M. B. ___ 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
Orphaned some Java packages
Hi all, I've just orphaned a few Java packages that were previously maintained by the Stewardship SIG, but we don't need them anymore as none of our packages depend on them now. - cpptasks - jetty-build-support - maven-injection-plugin - maven-mapping - mvel - randomizedtesting 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
Re: Orphaned some Java packages
On Mon, Apr 8, 2019 at 12:21 PM Mikolaj Izdebski wrote:
>
> On Sat, Mar 30, 2019 at 1:34 AM Christopher
> wrote:
> >
> > On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski
> > wrote:
> > >
> > > On Thu, Mar 28, 2019 at 7:46 PM Christopher
> > > wrote:
> > > >
> > > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski
> > > > wrote:
> > > > > - javapackages-tools, stream 201801 (buildroot-only module, not
> > > > > intended to be delivered to users)
> > > >
> > > > How do I enable/install this module locally? It would be very helpful
> > > > for local builds/testing, but is not available in:
> > > > sudo dnf --releasever=30 module list
> > >
> > > The official, recommended way of building modules locally is "fedpkg
> > > module-build-local". This command should take care of fetching and
> > > installing all required dependencies specified in modulemd being
> > > built. Therefore in this case it is enough to add dependency on
> > > javapackages-tools and it should "just work", for both local and
> > > remote builds.
> >
> > Hmm. I don't know how to do modules yet. I don't know how to create a
> > modulemd, or where it lives, or which packages I need to put in which
> > module, or how to name modules, or anything. I just want to install
> > all the tools from javapackages-tools, so I can do a plain old `fedpkg
> > local` build of my regular RPMs. I know this isn't going to work in
> > Koji for Fedora... but it would help me, as a user of those tools,
> > have access to them for my own RPM building purposes.
>
> You don't have to use these packages. You can keep using traditional,
> "ursine" Java packages that are still available in non-modular repos.
> These packages new owners who signed up to maintain them.
>
I know I don't have to use them, but... I *want* to use them. My
understanding is that those new owners maintaining them is an interim
solution, *minimally* maintained to prevent catastrophe, not the
stable long-term solution. I'd prefer the go to where the fully
maintained packages are going... not stay with the minimally
maintained ones. Besides, the catastrophe can still occur, if we don't
work to migrate while we have the chance.
> In addition to the above set of traditional, "ursine", packages, there
> is also javapackages-tools module, that contains Java packages
> intended for building certain other modules. Module maintainers can
> choose whether they want to build their modules using ursine Java
> packages, or using javapackages-tools module. Ursine package
> maintainers have no such choice and they are limited to depending on
> ursine Java packages only.
>
I'm trying to get on board the modular train, and convert my ursine
packages to modules. I want to learn how to do this correctly locally.
How can I get local builds of my modular packages, using the versions
I want them to use from the javapackages-tools module? I think the
lack of local availability of the packages in this module will make it
harder to transition to the modular versions, and will keep the
requirement for the ursine packages around longer.
> The original goal was to have a single set of modular packages that
> would be used for both building other modules and for building
> non-modular ("ursine") packages. However, in the end this set was
> split/forked and now we have two package sets, but with different
> maintainers. These packages are similar for now, but I expect them to
> diverge more over time. I don't like this situation either, but I've
> done everything I could to avoid it.
>
I understand, and appreciate what you've done to sound the alarm, and
the effort you've put into these packages to benefit the Java
ecosystem within Fedora. That's why I'm trying to follow the path
you're going, rather than stay on the ursine packages. I'm just
finding it extremely difficult to do so, because I do not understand
how to do modules, and the fact that some of them are less available
than others, makes it hard to "play" to learn on my own.
> >
> > >
> > > The module is not included in any compose, therefore dnf won't be able
> > > to find it in default repos. If you really want to install the module
> > > on your system for some reason then you can use ODCS [1] to generate a
> > > compose containing the module. Install ODCS client with "dnf install
> > > odcs-client" and then request compose with "odcs create module
> > > javapackages-tools:201801". ODCS will (usually) quickly create repo
> > > with the module and output repo URL, which you can put in a config
> > > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath
> > > option. Note that contents of javapackages-tools module are not signed
> > > and therefore you need to skip GPG verification in order to be able to
> > > install it.
> >
> > It seems a bit crazy to me that we have packages built for Fedora that
> > aren't available for users to install. Why wouldn't we make everything
> > maximally available? I used to love Fedora, because I just
Re: Orphaned some Java packages
On Sat, Mar 30, 2019 at 1:34 AM Christopher wrote:
>
> On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski wrote:
> >
> > On Thu, Mar 28, 2019 at 7:46 PM Christopher
> > wrote:
> > >
> > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski
> > > wrote:
> > > > - javapackages-tools, stream 201801 (buildroot-only module, not
> > > > intended to be delivered to users)
> > >
> > > How do I enable/install this module locally? It would be very helpful
> > > for local builds/testing, but is not available in:
> > > sudo dnf --releasever=30 module list
> >
> > The official, recommended way of building modules locally is "fedpkg
> > module-build-local". This command should take care of fetching and
> > installing all required dependencies specified in modulemd being
> > built. Therefore in this case it is enough to add dependency on
> > javapackages-tools and it should "just work", for both local and
> > remote builds.
>
> Hmm. I don't know how to do modules yet. I don't know how to create a
> modulemd, or where it lives, or which packages I need to put in which
> module, or how to name modules, or anything. I just want to install
> all the tools from javapackages-tools, so I can do a plain old `fedpkg
> local` build of my regular RPMs. I know this isn't going to work in
> Koji for Fedora... but it would help me, as a user of those tools,
> have access to them for my own RPM building purposes.
You don't have to use these packages. You can keep using traditional,
"ursine" Java packages that are still available in non-modular repos.
These packages new owners who signed up to maintain them.
In addition to the above set of traditional, "ursine", packages, there
is also javapackages-tools module, that contains Java packages
intended for building certain other modules. Module maintainers can
choose whether they want to build their modules using ursine Java
packages, or using javapackages-tools module. Ursine package
maintainers have no such choice and they are limited to depending on
ursine Java packages only.
The original goal was to have a single set of modular packages that
would be used for both building other modules and for building
non-modular ("ursine") packages. However, in the end this set was
split/forked and now we have two package sets, but with different
maintainers. These packages are similar for now, but I expect them to
diverge more over time. I don't like this situation either, but I've
done everything I could to avoid it.
>
> >
> > The module is not included in any compose, therefore dnf won't be able
> > to find it in default repos. If you really want to install the module
> > on your system for some reason then you can use ODCS [1] to generate a
> > compose containing the module. Install ODCS client with "dnf install
> > odcs-client" and then request compose with "odcs create module
> > javapackages-tools:201801". ODCS will (usually) quickly create repo
> > with the module and output repo URL, which you can put in a config
> > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath
> > option. Note that contents of javapackages-tools module are not signed
> > and therefore you need to skip GPG verification in order to be able to
> > install it.
>
> It seems a bit crazy to me that we have packages built for Fedora that
> aren't available for users to install. Why wouldn't we make everything
> maximally available? I used to love Fedora, because I just play with
> all the bits. But now, a lot of those bits are going away... I have
> less to play with... and the focus seems more targeted towards
> Fedora's internal needs, and not Fedora's users needs. Contributing to
> Fedora is so much harder now. Do we have to make it harder by making
> certain packages unavailable to regular users (and casual
> packager-contributors like me)?
We already have packages that are built by Fedora and for Fedora, but
are not distributed to users for various reasons. These include
glibc32, some buildroot overrides and even non-distributable-rpms [1],
which are not only not included in Fedora repos, but also users are
also blocked from downloading them from Koji.
[1] https://fedoraproject.org/wiki/Non-distributable-rpms
--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On Fri, Mar 29, 2019 at 11:25 AM Aleksandra Fedorova wrote: > if I understand correctly, you say that javapackages-tools module is not > included in any Fedora Modular repositories. That is correct. > But you want it to be included in Fedora buildroot through Ursa Major. No, not any longer. > Can you explain why you don't make it available through a Modular repo? Because that requires too much effort from my side. More effort that I can spend on Fedora package maintenance. Shipping content to users has serious implications, coming from "Package maintainers responsibility" and other policies and documents. By limiting "supported" use case of the module to only building other Fedora package I can reduce the work required to maintain the module by at least a factor of two. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski wrote: > > On Thu, Mar 28, 2019 at 7:46 PM Christopher > wrote: > > > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski > > wrote: > > > - javapackages-tools, stream 201801 (buildroot-only module, not > > > intended to be delivered to users) > > > > How do I enable/install this module locally? It would be very helpful > > for local builds/testing, but is not available in: > > sudo dnf --releasever=30 module list > > The official, recommended way of building modules locally is "fedpkg > module-build-local". This command should take care of fetching and > installing all required dependencies specified in modulemd being > built. Therefore in this case it is enough to add dependency on > javapackages-tools and it should "just work", for both local and > remote builds. Hmm. I don't know how to do modules yet. I don't know how to create a modulemd, or where it lives, or which packages I need to put in which module, or how to name modules, or anything. I just want to install all the tools from javapackages-tools, so I can do a plain old `fedpkg local` build of my regular RPMs. I know this isn't going to work in Koji for Fedora... but it would help me, as a user of those tools, have access to them for my own RPM building purposes. > > The module is not included in any compose, therefore dnf won't be able > to find it in default repos. If you really want to install the module > on your system for some reason then you can use ODCS [1] to generate a > compose containing the module. Install ODCS client with "dnf install > odcs-client" and then request compose with "odcs create module > javapackages-tools:201801". ODCS will (usually) quickly create repo > with the module and output repo URL, which you can put in a config > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath > option. Note that contents of javapackages-tools module are not signed > and therefore you need to skip GPG verification in order to be able to > install it. It seems a bit crazy to me that we have packages built for Fedora that aren't available for users to install. Why wouldn't we make everything maximally available? I used to love Fedora, because I just play with all the bits. But now, a lot of those bits are going away... I have less to play with... and the focus seems more targeted towards Fedora's internal needs, and not Fedora's users needs. Contributing to Fedora is so much harder now. Do we have to make it harder by making certain packages unavailable to regular users (and casual packager-contributors like me)? > [1] https://pagure.io/odcs > > -- > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
Hi, Mikolaj, On Fri, Mar 29, 2019 at 10:24 AM Mikolaj Izdebski wrote: > On Thu, Mar 28, 2019 at 7:46 PM Christopher > wrote: > > > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski > wrote: > > > - javapackages-tools, stream 201801 (buildroot-only module, not > > > intended to be delivered to users) > > > > How do I enable/install this module locally? It would be very helpful > > for local builds/testing, but is not available in: > > sudo dnf --releasever=30 module list > > The official, recommended way of building modules locally is "fedpkg > module-build-local". This command should take care of fetching and > installing all required dependencies specified in modulemd being > built. Therefore in this case it is enough to add dependency on > javapackages-tools and it should "just work", for both local and > remote builds. > > The module is not included in any compose, therefore dnf won't be able > to find it in default repos. if I understand correctly, you say that javapackages-tools module is not included in any Fedora Modular repositories. But you want it to be included in Fedora buildroot through Ursa Major. Can you explain why you don't make it available through a Modular repo? > If you really want to install the module > on your system for some reason then you can use ODCS [1] to generate a > compose containing the module. Install ODCS client with "dnf install > odcs-client" and then request compose with "odcs create module > javapackages-tools:201801". ODCS will (usually) quickly create repo > with the module and output repo URL, which you can put in a config > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath > option. Note that contents of javapackages-tools module are not signed > and therefore you need to skip GPG verification in order to be able to > install it. > > [1] https://pagure.io/odcs > > -- > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
Dne 28. 03. 19 v 14:53 Mikolaj Izdebski napsal(a): > On Thu, Mar 28, 2019 at 8:44 AM Vít Ondruch wrote: >> Trying to take look from the other side, the java.yaml might need some >> love [1], because the GH links are broken [2, 3] > java module doesn't have any complete builds. It is not actively maintained. Good to know that we have unmaintained modules in Fedora, nobody notice, nobody cares, there is no procedure how to get rid of them, etc ... Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On Thu, Mar 28, 2019 at 7:46 PM Christopher wrote: > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski wrote: > > - javapackages-tools, stream 201801 (buildroot-only module, not > > intended to be delivered to users) > > How do I enable/install this module locally? It would be very helpful > for local builds/testing, but is not available in: > sudo dnf --releasever=30 module list The official, recommended way of building modules locally is "fedpkg module-build-local". This command should take care of fetching and installing all required dependencies specified in modulemd being built. Therefore in this case it is enough to add dependency on javapackages-tools and it should "just work", for both local and remote builds. The module is not included in any compose, therefore dnf won't be able to find it in default repos. If you really want to install the module on your system for some reason then you can use ODCS [1] to generate a compose containing the module. Install ODCS client with "dnf install odcs-client" and then request compose with "odcs create module javapackages-tools:201801". ODCS will (usually) quickly create repo with the module and output repo URL, which you can put in a config file under /etc/yum.repos.d/, or pass to dnf using --repofrompath option. Note that contents of javapackages-tools module are not signed and therefore you need to skip GPG verification in order to be able to install it. [1] https://pagure.io/odcs -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski wrote: > - javapackages-tools, stream 201801 (buildroot-only module, not > intended to be delivered to users) How do I enable/install this module locally? It would be very helpful for local builds/testing, but is not available in: sudo dnf --releasever=30 module list ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On Thu, Mar 28, 2019 at 3:04 PM Miro Hrončok wrote: > On 28. 03. 19 14:49, Mikolaj Izdebski wrote: > > On Thu, Mar 28, 2019 at 12:49 AM Miro Hrončok wrote: > >> > >> I took over google-gson, but I see no stream branch. > > > > IIRC google-gson is not part of any modules I am currently maintaining > > in Fedora. > > So from the 259 orphaned packages, how many are actually in modules? When you look at source package counts, only 127 out of 259 orphaned packages are part of javapackages-tools module. This is because the module is built with lots of non-essential features disabled through multiple bconds [1] [1] https://src.fedoraproject.org/modules/javapackages-tools/blob/201801/f/javapackages-tools.yaml#_32 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On 28. 03. 19 14:49, Mikolaj Izdebski wrote:
On Thu, Mar 28, 2019 at 12:49 AM Miro Hrončok wrote:
On 05. 02. 19 11:07, Mikolaj Izdebski wrote:
I've just orphaned 259 packages listed below. Almost all of them are
Java packages which I will continue to maintain as part of modules.
Intent to orphan them was already announced on java-devel [1] and
devel [2] lists, with detailed reasoning.
Hi Mikolaj,
do you have some kind out outline about what packages are in what modules?
Currently I maintain the following 4 modules/streams:
- javapackages-tools, stream 201801 (buildroot-only module, not
intended to be delivered to users)
- maven, stream 3.5
- ant, stream 1.10
- scala, stream 2.10
Below I explained how to get lists of packages in each of the modules.
I took over google-gson, but I see no stream branch.
IIRC google-gson is not part of any modules I am currently maintaining
in Fedora.
So from the 259 orphaned packages, how many are actually in modules?
junit has javapackages branch
https://src.fedoraproject.org/rpms/junit/commits/javapackages
Is this the branch you use to build a module?
Correct.
Thanks.
A friend sent me a list of package they were able to find in a module by some
dark magic. BTW what is the supported way to query this kind of information?
First you need to find out module NSVC (name, stream version and
context). You can do that in many ways, for example to query Koji for
complete javapackages-tools module builds with highest version you can
run this query:
koji list-builds --type module --package javapackages-tools --state
COMPLETE -k version | head -3
Once you know NSVC you can see component builds corresponding to that
module using the following command:
koji list-tagged module-${NAME}-${STREAM}-${VERSION}-${CONTEXT}
For example:
koji list-tagged module-javapackages-tools-201801-2820190319130429-819b5873
I will try this. Thank You.
--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On Thu, Mar 28, 2019 at 8:44 AM Vít Ondruch wrote: > Trying to take look from the other side, the java.yaml might need some > love [1], because the GH links are broken [2, 3] java module doesn't have any complete builds. It is not actively maintained. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On Thu, Mar 28, 2019 at 12:49 AM Miro Hrončok wrote:
>
> On 05. 02. 19 11:07, Mikolaj Izdebski wrote:
> > I've just orphaned 259 packages listed below. Almost all of them are
> > Java packages which I will continue to maintain as part of modules.
> > Intent to orphan them was already announced on java-devel [1] and
> > devel [2] lists, with detailed reasoning.
>
> Hi Mikolaj,
>
> do you have some kind out outline about what packages are in what modules?
Currently I maintain the following 4 modules/streams:
- javapackages-tools, stream 201801 (buildroot-only module, not
intended to be delivered to users)
- maven, stream 3.5
- ant, stream 1.10
- scala, stream 2.10
Below I explained how to get lists of packages in each of the modules.
>
> I took over google-gson, but I see no stream branch.
IIRC google-gson is not part of any modules I am currently maintaining
in Fedora.
> junit has javapackages branch
> https://src.fedoraproject.org/rpms/junit/commits/javapackages
>
> Is this the branch you use to build a module?
Correct.
> A friend sent me a list of package they were able to find in a module by some
> dark magic. BTW what is the supported way to query this kind of information?
First you need to find out module NSVC (name, stream version and
context). You can do that in many ways, for example to query Koji for
complete javapackages-tools module builds with highest version you can
run this query:
koji list-builds --type module --package javapackages-tools --state
COMPLETE -k version | head -3
Once you know NSVC you can see component builds corresponding to that
module using the following command:
koji list-tagged module-${NAME}-${STREAM}-${VERSION}-${CONTEXT}
For example:
koji list-tagged module-javapackages-tools-201801-2820190319130429-819b5873
--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
Dne 28. 03. 19 v 0:48 Miro Hrončok napsal(a): > On 05. 02. 19 11:07, Mikolaj Izdebski wrote: >> I've just orphaned 259 packages listed below. Almost all of them are >> Java packages which I will continue to maintain as part of modules. >> Intent to orphan them was already announced on java-devel [1] and >> devel [2] lists, with detailed reasoning. > > Hi Mikolaj, > > do you have some kind out outline about what packages are in what > modules? > > I took over google-gson, but I see no stream branch. > > junit has javapackages branch > https://src.fedoraproject.org/rpms/junit/commits/javapackages > > Is this the branch you use to build a module? > > A friend sent me a list of package they were able to find in a module > by some dark magic. BTW what is the supported way to query this kind > of information? > > You say almost all of the 259 Java packages will be maintained as part > of modules, yet it's hard for me to find the rest. Trying to take look from the other side, the java.yaml might need some love [1], because the GH links are broken [2, 3] Vít [1] https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml [2] https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_18 [3] https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_19 > > Thanks. > > ant-antlr: ant > ant-apache-bcel: ant > ant-apache-bsf: ant > ant-apache-log4j: ant > ant-apache-oro: ant > ant-apache-regexp: ant > ant-apache-resolver: ant > ant-apache-xalan2: ant > ant-commons-logging: ant > ant-commons-net: ant > ant-javamail: ant > ant-jdepend: ant > ant-jmf: ant > ant-jsch: ant > ant-junit5: ant > ant-junit: ant > ant-lib: ant > ant-swing: ant > ant-testutil: ant > ant-xz: ant > ant: ant > antlr-C++-doc: ant > antlr-tool: ant > aopalliance: maven > apache-commons-cli: maven > apache-commons-codec: maven > apache-commons-io: maven > apache-commons-lang3: maven > apache-commons-logging: ant > apache-commons-logging: maven > apache-commons-net: ant > atinject: maven > bcel: ant > bsf: ant > cdi-api: maven > geronimo-annotation: maven > glassfish-el-api: maven > google-guice: maven > guava20: maven > hamcrest-core: ant > hawtjni-runtime: maven > hawtjni-runtime: scala > httpcomponents-client: maven > httpcomponents-core: maven > jakarta-oro: ant > jansi-native: maven > jansi-native: scala > jansi: maven > jansi: scala > javamail: ant > jboss-interceptors-1.2-api: maven > jcl-over-slf4j: maven > jdepend: ant > jline: scala > jsch: ant > jsoup: maven > junit5: ant > junit: ant > jzlib: ant > log4j12: ant > maven-lib: maven > maven-resolver-api: maven > maven-resolver-connector-basic: maven > maven-resolver-impl: maven > maven-resolver-spi: maven > maven-resolver-transport-wagon: maven > maven-resolver-util: maven > maven-shared-utils: maven > maven-wagon-file: maven > maven-wagon-http-shared: maven > maven-wagon-http: maven > maven-wagon-provider-api: maven > maven: maven > opentest4j: ant > plexus-cipher: maven > plexus-classworlds: maven > plexus-containers-component-annotations: maven > plexus-interpolation: maven > plexus-sec-dispatcher: maven > plexus-utils: maven > python2-antlr: ant > regexp: ant > scala-apidoc: scala > scala-swing: scala > scala: scala > sisu-inject: maven > sisu-plexus: maven > slf4j: maven > univocity-parsers: ant > xalan-j2: ant > xerces-j2: ant > xml-commons-apis: ant > xml-commons-resolver: ant > xz-java: ant > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned some Java packages
On 05. 02. 19 11:07, Mikolaj Izdebski wrote: I've just orphaned 259 packages listed below. Almost all of them are Java packages which I will continue to maintain as part of modules. Intent to orphan them was already announced on java-devel [1] and devel [2] lists, with detailed reasoning. Hi Mikolaj, do you have some kind out outline about what packages are in what modules? I took over google-gson, but I see no stream branch. junit has javapackages branch https://src.fedoraproject.org/rpms/junit/commits/javapackages Is this the branch you use to build a module? A friend sent me a list of package they were able to find in a module by some dark magic. BTW what is the supported way to query this kind of information? You say almost all of the 259 Java packages will be maintained as part of modules, yet it's hard for me to find the rest. Thanks. ant-antlr: ant ant-apache-bcel: ant ant-apache-bsf: ant ant-apache-log4j: ant ant-apache-oro: ant ant-apache-regexp: ant ant-apache-resolver: ant ant-apache-xalan2: ant ant-commons-logging: ant ant-commons-net: ant ant-javamail: ant ant-jdepend: ant ant-jmf: ant ant-jsch: ant ant-junit5: ant ant-junit: ant ant-lib: ant ant-swing: ant ant-testutil: ant ant-xz: ant ant: ant antlr-C++-doc: ant antlr-tool: ant aopalliance: maven apache-commons-cli: maven apache-commons-codec: maven apache-commons-io: maven apache-commons-lang3: maven apache-commons-logging: ant apache-commons-logging: maven apache-commons-net: ant atinject: maven bcel: ant bsf: ant cdi-api: maven geronimo-annotation: maven glassfish-el-api: maven google-guice: maven guava20: maven hamcrest-core: ant hawtjni-runtime: maven hawtjni-runtime: scala httpcomponents-client: maven httpcomponents-core: maven jakarta-oro: ant jansi-native: maven jansi-native: scala jansi: maven jansi: scala javamail: ant jboss-interceptors-1.2-api: maven jcl-over-slf4j: maven jdepend: ant jline: scala jsch: ant jsoup: maven junit5: ant junit: ant jzlib: ant log4j12: ant maven-lib: maven maven-resolver-api: maven maven-resolver-connector-basic: maven maven-resolver-impl: maven maven-resolver-spi: maven maven-resolver-transport-wagon: maven maven-resolver-util: maven maven-shared-utils: maven maven-wagon-file: maven maven-wagon-http-shared: maven maven-wagon-http: maven maven-wagon-provider-api: maven maven: maven opentest4j: ant plexus-cipher: maven plexus-classworlds: maven plexus-containers-component-annotations: maven plexus-interpolation: maven plexus-sec-dispatcher: maven plexus-utils: maven python2-antlr: ant regexp: ant scala-apidoc: scala scala-swing: scala scala: scala sisu-inject: maven sisu-plexus: maven slf4j: maven univocity-parsers: ant xalan-j2: ant xerces-j2: ant xml-commons-apis: ant xml-commons-resolver: ant xz-java: ant -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned some Java packages
I've just orphaned 259 packages listed below. Almost all of them are Java packages which I will continue to maintain as part of modules. Intent to orphan them was already announced on java-devel [1] and devel [2] lists, with detailed reasoning. Originally planned time of orphaning was delayed because I was hoping that modular packages could be allowed to be used in buildroots of non-modular packages (ursa-major proposal [3]), which would allow me to retire these packages and replace them with modular versions instead, but the proposal was recently rejected. [1] https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/message/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/ [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YFUXS7ZX6UDEMEKJWONKFMVDTSBABZID/ [3] https://pagure.io/fesco/issue/2003 The list of orphaned packages follows. aether-connector-okhttp ant ant-antunit ant-contrib antlr3 antlr4 aopalliance apache-commons-beanutils apache-commons-collections apache-commons-collections4 apache-commons-compress apache-commons-configuration apache-commons-csv apache-commons-daemon apache-commons-discovery apache-commons-el apache-commons-fileupload apache-commons-io apache-commons-jexl apache-commons-jxpath apache-commons-lang apache-commons-lang3 apache-commons-logging apache-commons-net apache-ivy apache-james-project apache-logging-parent apache-mime4j apache-parent apache-rat apache-resource-bundles apiguardian aqute-bnd args4j atinject avalon-framework avalon-logkit base64coder batik bcel bea-stax beust-jcommander bsf bsh byaccj cal10n checkstyle codemodel dain-snappy decentxml dom4j easymock eclipse-m2e-antlr eclipse-m2e-buildhelper eclipse-m2e-core eclipse-m2e-cxf eclipse-m2e-egit eclipse-m2e-mavenarchiver eclipse-m2e-maven-dependency-plugin eclipse-m2e-mavendev eclipse-m2e-modello eclipse-m2e-plexus eclipse-m2e-sisu eclipse-m2e-sourcelookup eclipse-m2e-takari eclipse-m2e-tycho eclipse-m2e-workspace exec-maven-plugin felix-bundlerepository felix-osgi-core felix-osgi-obr felix-utils geronimo-jaspic-spec geronimo-jms geronimo-jpa geronimo-jta geronimo-parent-poms glassfish-dtd-parser glassfish-fastinfoset glassfish-jaxb glassfish-jsp glassfish-jsp-api google-gson google-guice gpars gradle groovy guava20 hawtjni hsqldb httpcomponents-client httpcomponents-core httpcomponents-project httpunit icu4j istack-commons jackson jakarta-commons-httpclient jansi jansi-native javacc javacc-maven-plugin javamail java-service-wrapper javassist jaxen jchardet jdepend jdependency jeromq jettison jetty jetty8 jetty-alpn jetty-alpn-api jetty-artifact-remote-resources jetty-assembly-descriptors jetty-build-support jetty-distribution-remote-resources jetty-parent jetty-schemas jetty-test-helper jetty-test-policy jetty-toolchain jetty-version-maven-plugin jflex jmapviewer jna joda-convert jortho jsch-agent-proxy json_simple jsoup jsr-311 junit junit5 jvnet-parent kohsuke-pom kxml log4j maven maven-antrun-plugin maven-archetype maven-archiver maven-artifact-resolver maven-artifact-transfer maven-assembly-plugin maven-clean-plugin maven-compiler-plugin maven-dependency-analyzer maven-dependency-plugin maven-dependency-tree maven-doxia maven-doxia-sitetools maven-enforcer maven-file-management maven-filtering maven-gpg-plugin maven-idea-plugin maven-indexer maven-invoker maven-jar-plugin maven-jarsigner-plugin maven-javadoc-plugin maven-mapping maven-osgi maven-parent maven-plugin-build-helper maven-plugin-bundle maven-plugins-pom maven-plugin-testing maven-plugin-tools maven-reporting-api maven-reporting-exec maven-reporting-impl maven-repository-builder maven-resolver maven-script-interpreter maven-shade-plugin maven-shared-incremental maven-shared-io maven-shared-jar maven-shared-jarsigner maven-shared-utils maven-site-plugin maven-source-plugin maven-stapler-plugin maven-surefire maven-toolchains-plugin maven-verifier maven-wagon mnemonicsetter modello mojo-parent multiverse munge-maven-plugin nasm nekohtml netty objectweb-asm3 objectweb-pom okio opentest4j osgi-compendium osgi-core os-maven-plugin plexus-ant-factory plexus-archiver plexus-bsh-factory plexus-classworlds plexus-cli plexus-compiler plexus-component-factories-pom plexus-components-pom plexus-containers plexus-digest plexus-i18n plexus-interactivity plexus-interpolation plexus-io plexus-languages plexus-resources plexus-utils plexus-velocity qdox regexp sdljava SimplyHTML sisu sisu-mojos slf4j snakeyaml sonatype-oss-parent sonatype-plugins-parent stax2-api stringtemplate4 tagsoup takari-archiver takari-filemanager takari-incrementalbuild takari-lifecycle takari-plugin-testing takari-pom takari-tycho-support txw2 univocity-parsers velocity woodstox-core xalan-j2 xbean xml-maven-plugin xmlrpc xmvn xom xsom xstream xz-java zinc zopfli -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to
Orphaned some Java packages
I've just orphaned Java packages listed below. All of them are leaf packages - not required or buildrequired by anything that I know of. I divided these packages into 3 groups: Group 1: packages that were only orphaned and are still active in all branches, including master; they may be still useful and are waiting for new maintainers to adopt them, or to be retired by release engineering. Group 2: packages that were orphaned and their master branches were retired for various reasons (described in dead.package in dist-git); they still have active branches other than master. Group 3: packages that do not have any active branches in PDC, but dist-git is not in sync with PDC and shows f27 as active; I orphaned these packages to make them stop appearing in list of my packages in dist-git. 1. Still active in master: freemind java-deptools jai-imageio-core jgoodies-animation jpathwatch snifflib 2. Retired in master, active in f29 and other branches: gossip infomas-asl maven-downloader maven-jsf-plugin maven-jxr maven-toolchains-plugin openid4java-team port-allocator-maven-plugin takari-local-repository 3. No active branches in PDC: aether aether-ant-tasks jenkins-openid-plugin keytool-maven-plugin pmd pmd-build-tools tycho-pomless werken-xpath xpp2 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
