Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
HEADS_UP: The Change of autoconf to version 2.71 is built and done. F36FTBFS bugs are created [1] for failed builds of packages. Most of them are caused by minor issues and not merged pull-requests of fixes regarding autoconf-2.71 change. Hopefully have this done in a short time. Thanks for cooperation! Ondrej [1] https://bugzilla.redhat.com/show_bug.cgi?id=1999424 On Mon, Aug 30, 2021 at 5:32 PM Fabio Valentini wrote: > On Mon, Aug 30, 2021 at 5:29 PM Miro Hrončok wrote: > > > > On 30. 08. 21 17:02, Fabio Valentini wrote: > > > On Mon, Aug 30, 2021 at 11:49 AM Ondrej Dubaj > wrote: > > >> > > >> HEADS-UP: > > >> > > >> autoconf-2.71 is merged and built in Fedora rawhide together with the > rest of autotools: automake-1.16-4.1 and libtool-2.4.6-43. > > >> > > >> In the next few days, scratch-build for each dependent package will > be executed and failed packages F36FTBFS trackers will be created. > > >> > > >> Thank you all for your cooperation! Hopefully we will manage to bring > this change to the end. > > > > > > Thanks for working on this! > > > > > > I wonder why you'll only submit test scratch builds of dependent > > > packages, instead of "real" rebuilds for autoconf 2.71? > > > > That was my advice to Ondrej. > > > > My reasoning was that the real rebuild adds no value here, except it > generates > > meaningless updates for rawhide users. > > Ah, yeah that makes sense, since this change should only affect the > build itself. Thanks for the explanation. > > 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
HEADS-UP: autoconf-2.71 is merged and built in Fedora rawhide together with the rest of autotools: automake-1.16-4.1 and libtool-2.4.6-43. In the next few days, scratch-build for each dependent package will be executed and failed packages F36FTBFS trackers will be created. Thank you all for your cooperation! Hopefully we will manage to bring this change to the end. Ondrej On Mon, Aug 30, 2021 at 10:45 AM Ian Kent wrote: > On Mon, 2021-08-30 at 07:55 +0200, Ondrej Dubaj wrote: > > Hi, > > > > Thank you for the update Ian. It was not meant the way every packager > > is ignoring the opened issues, we appreciate your work on this > > autoconf-2.71 issue. Sorry for generalizing this. > > And my comment was not meant to sound negative, getting an update > like this done is very challenging, to say the least, hopefully > everything will go well, ;) > > Truth is I would have liked to get it done earlier but was unable > to, at least I have managed to get it done now. > > > > > Glad to hear that it will build OK today. > > > > HEADS-UP: > > > > Starting with merging autoconf-2.71 changes. This week a scratch- > > build for all dependent packages will be executed. If you want to > > test your packages by yourself, you can execute your own scratch- > > build and see if it works properly. I will write here when autoconf- > > 2.71 will be stable. > > > > Thanks for your cooperation and hope to see very few failures this > > week :) > > > > Regards, > > Ondrej > > > > On Fri, Aug 27, 2021 at 2:36 PM Ian Kent wrote: > > > On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote: > > > > Hello, > > > > > > > > In the near future, there is a plan to merge autoconf-2.71 to > > > > rawhide. Due to the size of the change and possible breakage of > > > > multiple packages going FTBFS. The number of these packages > > > > should > > > > not be many, currently we have ~32 opened FTBFS trackers > > > > according > > > to > > > > autoconf-2.71, where the majority of them are just ignored by > > > > maintainers [1]. This can also be a possibility to remove > > > unnecessary > > > > packages from Fedora. After merging the change, there should be a > > > > mechanism for validating. From my perspective, it is effective to > > > > rebuild dependent packages (~1700 packages). After the rebuild, > > > there > > > > should not be many FTBFS packages, but according to the change > > > there > > > > will be some. There was enough time (~6 months) for the > > > > maintainers > > > > to prepare for this change. > > > > > > Not everyone is ignoring the bugs I have been working on the am- > > > utils > > > package for this. > > > > > > The package is very old and it utilizes autoconf very heavily. > > > Most of the autoconf noise is use of obsolete macros and I have > > > updated > > > this were I can but there are some things I simply can't fix and > > > some > > > things that shouldn't be changed. > > > > > > I'll keep coming back to it over time since the changes I have made > > > or > > > (rather will be committing over the weekend) do allow the package > > > to > > > build and function on F33 and build in the Copr updated autoconf > > > environment. > > > > > > I expect it will build ok on Monday. > > > > > > > > > > > If there are any concerns or other opinions about the steps after > > > > merging the change, please share your thoughts and we can discuss > > > > them here. > > > > > > > > Thanks very much! > > > > > > > > Regards, > > > > Ondrej > > > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967 > > > > > > > > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj > > > > wrote: > > > > > Hello, according to the size of this change and the possible > > > > > breakage of multiple packages before f35 mass rebuild, we > > > > > decided > > > > > (team working on this change) to postpone this change to early > > > > > lifecycle of f36, where we will have enough time to resolve any > > > > > problems until f36 mass rebuild. > > > > > > > > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi > > >
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hi, Thank you for the update Ian. It was not meant the way every packager is ignoring the opened issues, we appreciate your work on this autoconf-2.71 issue. Sorry for generalizing this. Glad to hear that it will build OK today. HEADS-UP: Starting with merging autoconf-2.71 changes. This week a scratch-build for all dependent packages will be executed. If you want to test your packages by yourself, you can execute your own scratch-build and see if it works properly. I will write here when autoconf-2.71 will be stable. Thanks for your cooperation and hope to see very few failures this week :) Regards, Ondrej On Fri, Aug 27, 2021 at 2:36 PM Ian Kent wrote: > On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote: > > Hello, > > > > In the near future, there is a plan to merge autoconf-2.71 to > > rawhide. Due to the size of the change and possible breakage of > > multiple packages going FTBFS. The number of these packages should > > not be many, currently we have ~32 opened FTBFS trackers according to > > autoconf-2.71, where the majority of them are just ignored by > > maintainers [1]. This can also be a possibility to remove unnecessary > > packages from Fedora. After merging the change, there should be a > > mechanism for validating. From my perspective, it is effective to > > rebuild dependent packages (~1700 packages). After the rebuild, there > > should not be many FTBFS packages, but according to the change there > > will be some. There was enough time (~6 months) for the maintainers > > to prepare for this change. > > Not everyone is ignoring the bugs I have been working on the am-utils > package for this. > > The package is very old and it utilizes autoconf very heavily. > Most of the autoconf noise is use of obsolete macros and I have updated > this were I can but there are some things I simply can't fix and some > things that shouldn't be changed. > > I'll keep coming back to it over time since the changes I have made or > (rather will be committing over the weekend) do allow the package to > build and function on F33 and build in the Copr updated autoconf > environment. > > I expect it will build ok on Monday. > > > > > If there are any concerns or other opinions about the steps after > > merging the change, please share your thoughts and we can discuss > > them here. > > > > Thanks very much! > > > > Regards, > > Ondrej > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967 > > > > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj > > wrote: > > > Hello, according to the size of this change and the possible > > > breakage of multiple packages before f35 mass rebuild, we decided > > > (team working on this change) to postpone this change to early > > > lifecycle of f36, where we will have enough time to resolve any > > > problems until f36 mass rebuild. > > > > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi wrote: > > > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote: > > > > > Currently, we are trying to stay away from the compat package > > > > > and > > > > with the > > > > > help of other package maintainers trying to fix the failures. > > > > > We > > > > will give > > > > > time to react accordingly and see other possible steps in a few > > > > weeks time. > > > > > > > > > > Currently multiple FTBFS bugs in bugzilla were created > > > > > according > > > > to > > > > > autoconf-2.71. More information available here: > > > > > > > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > > > > > > Whats the current status of this Change? > > > > > > > > It didn't land before mass rebuild. Is it still planned for f35? > > > > > > > > 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 > > > > Do not reply to spam on the list, report it: > > > > https://pagure.io/fedora-infrastructure > > _
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hello, maybe the bug was not closed by the maintainer, as grep seems to be building properly https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/package/grep/ Ondrej On Fri, Aug 27, 2021 at 8:10 AM Ondrej Dubaj wrote: > Thanks, I'll look at it. > > Ondrej > > On Thu, Aug 26, 2021 at 5:19 PM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > >> On Thu, Aug 26, 2021 at 02:39:13PM +0200, Ondrej Dubaj wrote: >> > Hi, >> > >> > thanks for your reply, there should not be any packages on critical >> path, >> > which are not building currently. >> >> I see grep on the list: >> https://bugzilla.redhat.com/show_bug.cgi?id=1943083 >> We should probably fix that quickly. >> >> Zbyszek >> ___ >> 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thanks, I'll look at it. Ondrej On Thu, Aug 26, 2021 at 5:19 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Thu, Aug 26, 2021 at 02:39:13PM +0200, Ondrej Dubaj wrote: > > Hi, > > > > thanks for your reply, there should not be any packages on critical path, > > which are not building currently. > > I see grep on the list: > https://bugzilla.redhat.com/show_bug.cgi?id=1943083 > We should probably fix that quickly. > > Zbyszek > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hi, thanks for your reply, there should not be any packages on critical path, which are not building currently. HEADS-UP: The plan for merging autoconf-2.71 to rawhide is Monday (30th Aug 2021), if no issues will come up. After that, there is no need to do a regular build of dependent packages, but we will schedule a scratch-build, which should be enough to test, if everything works as expected. According to results of these scratch-builds, F36FTBFS trackers in bugzilla will be created for each failed package. I will send a message to this thread after merging and building autoconf-2.71, to make things clear. Thanks. Ondrej On Wed, Aug 25, 2021 at 7:59 PM Kevin Fenzi wrote: > On Tue, Aug 24, 2021 at 10:53:15AM +0200, Ondrej Dubaj wrote: > > Hello, > > > > In the near future, there is a plan to merge autoconf-2.71 to rawhide. > Due > > to the size of the change and possible breakage of multiple packages > going > > FTBFS. The number of these packages should not be many, currently we have > > ~32 opened FTBFS trackers according to autoconf-2.71, where the majority > of > > them are just ignored by maintainers [1]. This can also be a possibility > to > > remove unnecessary packages from Fedora. After merging the change, there > > Are any of these on the critical path (ie would cause composes to fail?) > I don't see any off hand, but if so, I would get those fixed before > landing if you can at all. Otherwise I would say land as soon as you > like. > > > should be a mechanism for validating. From my perspective, it is > effective > > to rebuild dependent packages (~1700 packages). After the rebuild, there > > should not be many FTBFS packages, but according to the change there will > > be some. There was enough time (~6 months) for the maintainers to prepare > > for this change. > > > > If there are any concerns or other opinions about the steps after merging > > the change, please share your thoughts and we can discuss them here. > > Thanks for all this work, it's appreciated. ;) > > > Thanks very much! > > > > Regards, > > Ondrej > > kevin > -- > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967 > > > > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj wrote: > > > > > Hello, according to the size of this change and the possible breakage > of multiple packages before f35 mass rebuild, we decided (team working on > this change) to postpone this change to early lifecycle of f36, where we > will have enough time to resolve any problems until f36 mass rebuild. > > > > > > > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi wrote: > > > > > >> On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote: > > >> > Currently, we are trying to stay away from the compat package and > with > > >> the > > >> > help of other package maintainers trying to fix the failures. We > will > > >> give > > >> > time to react accordingly and see other possible steps in a few > weeks > > >> time. > > >> > > > >> > Currently multiple FTBFS bugs in bugzilla were created according to > > >> > autoconf-2.71. More information available here: > > >> > > > >> > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > >> > > >> Whats the current status of this Change? > > >> > > >> It didn't land before mass rebuild. Is it still planned for f35? > > >> > > >> 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 > > >> 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 Archiv
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hello, In the near future, there is a plan to merge autoconf-2.71 to rawhide. Due to the size of the change and possible breakage of multiple packages going FTBFS. The number of these packages should not be many, currently we have ~32 opened FTBFS trackers according to autoconf-2.71, where the majority of them are just ignored by maintainers [1]. This can also be a possibility to remove unnecessary packages from Fedora. After merging the change, there should be a mechanism for validating. From my perspective, it is effective to rebuild dependent packages (~1700 packages). After the rebuild, there should not be many FTBFS packages, but according to the change there will be some. There was enough time (~6 months) for the maintainers to prepare for this change. If there are any concerns or other opinions about the steps after merging the change, please share your thoughts and we can discuss them here. Thanks very much! Regards, Ondrej [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967 On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj wrote: > Hello, according to the size of this change and the possible breakage of > multiple packages before f35 mass rebuild, we decided (team working on this > change) to postpone this change to early lifecycle of f36, where we will have > enough time to resolve any problems until f36 mass rebuild. > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi wrote: > >> On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote: >> > Currently, we are trying to stay away from the compat package and with >> the >> > help of other package maintainers trying to fix the failures. We will >> give >> > time to react accordingly and see other possible steps in a few weeks >> time. >> > >> > Currently multiple FTBFS bugs in bugzilla were created according to >> > autoconf-2.71. More information available here: >> > >> > https://fedoraproject.org/wiki/Changes/Autoconf_271 >> >> Whats the current status of this Change? >> >> It didn't land before mass rebuild. Is it still planned for f35? >> >> 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 >> 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hello, according to the size of this change and the possible breakage of multiple packages before f35 mass rebuild, we decided (team working on this change) to postpone this change to early lifecycle of f36, where we will have enough time to resolve any problems until f36 mass rebuild. On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi wrote: > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote: > > Currently, we are trying to stay away from the compat package and with > the > > help of other package maintainers trying to fix the failures. We will > give > > time to react accordingly and see other possible steps in a few weeks > time. > > > > Currently multiple FTBFS bugs in bugzilla were created according to > > autoconf-2.71. More information available here: > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > Whats the current status of this Change? > > It didn't land before mass rebuild. Is it still planned for f35? > > 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 > 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
Announcement: New major version of mariadb-java-client-3.0.0
Hi, today a new major version 3.0.0 of mariadb-java-client landed in Fedora-Rawhide. This version is not 100% compatible with the previous version 2.7.3, but it should not affect many applications. The reason for such an update is, that we want this version to be present in RHEL-9-beta and according to good packaging manners, it should land in Fedora first. Currently we have Alpha version release but soon (29.7.2021) Beta version will be released and later (24.9.2021) also GA. Details about the changes available here [1]. Regards, Ondrej [1] https://mariadb.com/kb/en/mariadb-connector-j-300-release-notes/ ___ 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: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
This change won't be applied, so no action is required. Ondrej On Wed, Jul 14, 2021 at 8:14 PM Paul Wouters wrote: > On Mon, 12 Jul 2021, Simo Sorce wrote: > > >> SQLite is a general-purpose tool. Not every use of SHA-1 is > >> cryptographically relevant. Most uses in the context of SQLite probably > >> aren't, so the removal just annoys users for no good reason. > > > > Note that this is a Sqlite decision, from RHEL engineering we only > > requested the removal in digital signatures and where integrity > > protection is required for security. > > Also note that we do not require full removal, just that SHA-1 is not > > used unless users intentionally change configuration. > > How does this affect users of NSS who have created "default" databases, > eg using certutil -N ? Do these use SHA1? If so, can they be migrated > to SHA2? Automatically ? > > Paul > ___ > 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: Is it me, or is it autotools being silly?
This should be also fixed in Fedora already https://src.fedoraproject.org/rpms/automake/c/3327906e94b767330433fda3da2d0997292c55ad?branch=rawhide Ondrej On Wed, Jul 14, 2021 at 12:11 PM Richard W.M. Jones wrote: > On Wed, Jul 14, 2021 at 11:49:23AM +0200, David Sommerseth wrote: > > > > Hi, > > > > So I'm running some builds for the openvpn3-linux project on Fedora > > Rawhide ... And we have this little line in configure.ac: > > > > AM_PATH_PYTHON([3.5],, [:]) > > > > When ./configure runs, it reports: > > > > checking for python3 version... 3.1 > > > > As a colleague said, mathematically this is correct. But that > > doesn't really help. Who/what is truncating Python 3.10 to 3.1? > > And how can that be fixed? Is someone already looking into this? > > It's a bug in AM_PATH_PYTHON (defined in > /usr/share/aclocal-1.16/python.m4). > > AC_CACHE_CHECK([for $am_display_PYTHON version], [am_cv_python_version], > [am_cv_python_version=`$PYTHON -c "import sys; > sys.stdout.write(sys.version[[:3]])"`]) > > In the Python 3.10 interpreter: > > >>> print(sys.version[:3]) > 3.1 > > (because the first 3 characters of the string "3.10.0b2" are "3.1") > > This seems to have been fixed upstream already: > > https://git.savannah.gnu.org/cgit/automake.git/tree/m4/python.m4#n89 > > https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=e21d46fddd0753e66a4acda88317670fee07f3e6 > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > ___ > 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: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)
Hello, According to the response from upstream [1], it seems I have come up with a solution too quickly. I apologize for this. I will go through a cancellation process of this Change Proposal, as there seems to be no valid reason to remove SHA-1 support in sqlite. Thanks for your help and understanding. Regards, Ondrej [1] https://sqlite.org/forum/forumpost/eec8e1bc739aee7d?raw On Sun, Jul 11, 2021 at 7:04 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Sat, Jul 10, 2021 at 12:13:20AM +0200, Felix Schwarz wrote: > > > > Am 09.07.21 um 17:45 schrieb Ben Cotton: > > >== Detailed Description == > > >The use of SHA-1 is no longer permitted for Digital Signatures or > > >authentication in RHEL-9. Due to this reason, there is a need to > > >remove SHA-1 extension from sqlite in RHEL-9 and therefore also > > >Fedora. > > > > I don't think that this is a valid logical conclusion. Fedora is > > (should be?) upstream to RHEL 9 so you can disable SHA1 in RHEL 9 > > but keep it enabled in Fedora. There is certainly no "need" for this > > change as demonstrated by the various packaging changes done in > > RHEL. > > > > (FWIW I don't particularly care about SHA1 functionality in sqlite.) > > Also: if it is not the recommended choice, why not just select > something else as the default (which is already the case, iiuc), > and let users use sha-1 to access existing databases? > > Zbyszek > ___ > 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: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Fri, Apr 16, 2021 at 3:30 PM David Cantrell wrote: > On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote: > >Hijacking this thread originally about > >https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > >What is the current thinking in Fedora about always running > >"autoreconf -i" during builds that use autotools? > > I think we are likely to see the least problems for projects that > created their configure.ac files using autoscan. For projects that > constructed them manually or in other ways, we'll likely see some > fallout. I would encourage maintainers to work towards fixing these > things and contributing them back upstream. Still, we would need to > provide a way to disable the autoreconf step for particular > problematic packages. > > Some projects provide their own autotools macros and wrappers around > autoreconf. For example, Xfce either provides or provided xdt-autogen > as a wrapper to run autoreconf with the Xfce-specific macros and other > defines available. If it's best to rerun xdt-autogen in these cases, > how could we handle that in the spec file so it runs the correct > 'autoreconf' command? > > >The cons of always autoreconfing are that it slows down builds, > >sometimes considerably. It also could fail - I noticed that autoconf > >2.71 has several incompatibilities with the most widely used autoconf > >(2.69). > > I think the failures will be the most frustrating part of this rather > than the build time. An FAQ or something of how to fix common > failures for 2.71 would be useful for contributors. > Document with common failures and fixes already exists [1]. Also multiple ways of testing are documented in the change proposal [2], where the link to the document [1] is present. Updating autoconf to version 2.71 is a hard process, we are doing our best to make it as fluent as possible. There is a copr created for testing, bugs in bugzilla created (with link to change proposal) for failing components and we are actively moving things forward. Hopefully it will be enough to make this possible. [1] https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit [2] https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > Thanks, > > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > > ___ 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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Added, thanks! On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto wrote: > https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > > As I think this is not trivial we should add to How_To_Test paragraph : > > After: > copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 > > odubaj-autoconf-2.70_fedora-34-x86_64.cfg > mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock > > we may run: > mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild > ufraw-0.23-0.11.20210413.fc35.src.rpm > > Than you > -- > 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
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Currently, we are trying to stay away from the compat package and with the help of other package maintainers trying to fix the failures. We will give time to react accordingly and see other possible steps in a few weeks time. Currently multiple FTBFS bugs in bugzilla were created according to autoconf-2.71. More information available here: https://fedoraproject.org/wiki/Changes/Autoconf_271 Ondrej On Fri, Mar 19, 2021 at 5:59 PM Patrik Novotny wrote: > I'd advocate strongly against a compat package. > > The whole point of the change is to push the move to the new autoconf > upstream release. Not the availability of autoconf 2.71 to the end user. > For that, we would do much better with providing the end users with a > modular release, I think. > > As for the argument of other distributions, Fedora has always been an > early adopter. If we will create a compat package providing the 2.69 > version, what's the point of moving to autoconf 2.71 (maybe over providing > a modular build) anyway? > > What I would argue is that we should make an effort to fully move to the > new version of autoconf, and postpone the change if we find out that it is > not doable in time for F35. Historically, it took some effort to mitigate > providing compat packages of autoconf, and experience tells us that when we > do, the motivation to fix packages incompatible with the new version > virtually disappears. > > IMO, the only scenario, where a compat package would make sense, is if we > were to push for the removal of this compat package right from the moment > of it's introduction. In that case, the only real benefit of completing the > Autoconf 2.71 change, would be *a little* easier process of making > necessary changes to now incompatible packages in exchange for any real > motivation to actually do so. If the point of this change is the > availability of autoconf 2.71 to the end-user, I would argue that a modular > build would be a much cleaner approach. > > We should push for this change to be done the proper way, not for the > possibility of making a slow progress over long period of time for the > price of duplicating packages. If we need more time for that, this change > should be postponed. > > On Fri, Mar 12, 2021 at 4:27 PM Jonathan Wakely > wrote: > >> On 09/03/21 09:15 +, Tomasz Kłoczko wrote: >> >Some time ago gcc, binutils IIRC received an update for ac 2.71 so at >> least >> >those two should be by now off-the-table (Am I right?). >> >> No. GCC has a hard requirement on autoconf-2.69, but the Fedora >> package doesn't need to run autoconf for it (that happens when >> upstream creates the snapshot tarball). >> >> I'm not sure about binutils, but I would be very surprised if it is >> different from GCC. >> ___ >> 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 >> > > > -- > Patrik Novotný > Associate Software Engineer > Red Hat > panov...@redhat.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: autoconf FTBFS bugs being filed but no obvious build failure
Not yet, will keep you updated when it will be created. On Thu, Mar 25, 2021 at 3:34 PM Gwyn Ciesla via devel < devel@lists.fedoraproject.org> wrote: > Does the koji side tag exist yet? > > -- > Gwyn Ciesla > she/her/hers > > in your fear, seek only peace > in your fear, seek only love > -d. bowie > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, March 25, 2021 8:02 AM, Ondrej Dubaj > wrote: > > Hi, > > there might be some "false negatives". If the packages are successfully > built in the given copr, please close the trackers. In most cases the FTBFS > bugs are relevant. > > Thank you. > > Ondrej > > On Thu, Mar 25, 2021 at 1:57 PM Richard W.M. Jones > wrote: > >> >> eg: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1943008 >> "coccinelle: FTBFS with upcoming autoconf-2.71" >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1943041 >> "ocaml-curses: FTBFS with upcoming autoconf-2.71" >> >> I followed the links given in both, but as far as I can tell the >> builds succeeded in both cases. Unless I'm looking at the wrong thing - >> it's hard to tell. >> >> Rich. >> >> -- >> Richard Jones, Virtualization Group, Red Hat >> http://people.redhat.com/~rjones >> Read my programming and virtualization blog: http://rwmj.wordpress.com >> libguestfs lets you edit virtual machines. Supports shell scripting, >> bindings from many languages. http://libguestfs.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: autoconf FTBFS bugs being filed but no obvious build failure
Hi, there might be some "false negatives". If the packages are successfully built in the given copr, please close the trackers. In most cases the FTBFS bugs are relevant. Thank you. Ondrej On Thu, Mar 25, 2021 at 1:57 PM Richard W.M. Jones wrote: > > eg: > > https://bugzilla.redhat.com/show_bug.cgi?id=1943008 > "coccinelle: FTBFS with upcoming autoconf-2.71" > > https://bugzilla.redhat.com/show_bug.cgi?id=1943041 > "ocaml-curses: FTBFS with upcoming autoconf-2.71" > > I followed the links given in both, but as far as I can tell the > builds succeeded in both cases. Unless I'm looking at the wrong thing - > it's hard to tell. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.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
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thanks for your advice. Already contacted maintainers of redhat-rpm-config to discuss adding the appropriate command and see what their response is. Ondrej On Wed, Mar 10, 2021 at 8:06 PM Brian C. Lane wrote: > On Tue, Mar 09, 2021 at 09:15:23AM +, Tomasz Kłoczko wrote: > > On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj wrote: > > > > > If any concerns about the autoconf2.69-2.69 compat package ? If needed > it > > > can be implemented as non-parallelly instalable, > > > > > > > Really .. instead wasting time on packaging stuff which is ~7 years old > it > > would be better to use that time to fix one of those handful packages > which > > Well the reason why it is 7 years old is there weren't any updates, so I > think we should expect a reasonable amount of time to pass before > upstreams transition. > > Like I said earlier, for parted we're not going to change until 2.71 is > widely available, so I need something that either works with both or a > compatibility package. > > > So .. anyone knows any other packages dist sources trees on which > something > > like "autoreconf -fiv" fails? > > THIS is what I needed. I hadn't tried -i so I continued to get failures > when I worked on this a few weeks back. Adding -fiv did the trick and > parted-3.4-3.fc35 will work with 2.69 or 2.71 so I no longer need the > compatibility package, thanks. > > I still think having 2.69 is necessary though, and we should revisit > convincing upstreams to use 2.71 after F36 or so. > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thanks for advice guys, setting commitish to back rawhide in copr. Sorry for the bad advice to other maintainers. Please use pull-requests against rawhide as Miro mentioned. Ondrej. On Wed, Mar 10, 2021 at 11:01 AM Miro Hrončok wrote: > On 10. 03. 21 10:47, Fabio Valentini wrote: > > On Wed, Mar 10, 2021 at 10:27 AM Ondrej Dubaj wrote: > >> > >> Hello, > >> > >> Thank you for your suggestions, but as you might understand, I do not > have the capacity to resolve problems of dependent packages when building > with autoconf-2.71. > >> > >> I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 > for other maintainers, so they are able to make appropriate changes and > test them in copr. Testing is possible by pushing the changes to a new > created branch "rawhide-autoconf-2.71", where in your package you can use > autoconf dependency (autoconf-2.71) or autoconf2.69 dependency (compat > package for autoconf-2.69). After pushing to the given branch, the package > will be built automatically in copr and you can test the update of your > package. You can do this many times until you are certain your package > works good. > >> > >> Thanks for understanding and cooperation. > > > > Please don't do branches like this in "official" dist-git > > repositories. It's a big PITA to clean up such branches. > > I concur. > > Set the committish of the packages in your copr to "rawhide". Packagers > can send > pull requests with changes and the results will appear in your Copr e.g. > in: > > > https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/builds/?dirname=autoconf-2.70:pr:18 > > Pull requests, unlike arbitrary branches, can be safely rebased until the > result > is good. Once merged, they are "gone" (technically, they remain in your > fork, > but that should not bother anybody and can be deleted if needed). > > -- > 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hello, Thank you for your suggestions, but as you might understand, I do not have the capacity to resolve problems of dependent packages when building with autoconf-2.71. I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for other maintainers, so they are able to make appropriate changes and test them in copr. Testing is possible by pushing the changes to a new created branch "rawhide-autoconf-2.71", where in your package you can use autoconf dependency (autoconf-2.71) or autoconf2.69 dependency (compat package for autoconf-2.69). After pushing to the given branch, the package will be built automatically in copr and you can test the update of your package. You can do this many times until you are certain your package works good. Thanks for understanding and cooperation. Ondrej On Tue, Mar 9, 2021 at 10:19 AM Tomasz Kłoczko wrote: > On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj wrote: > >> If any concerns about the autoconf2.69-2.69 compat package ? If needed it >> can be implemented as non-parallelly instalable, >> > > Really .. instead wasting time on packaging stuff which is ~7 years old it > would be better to use that time to fix one of those handful packages which > are still not ac 2.71 compliant (like openldap > https://bugs.openldap.org/show_bug.cgi?id=9485). > Listing all those failing packages + posting URL from where is possible to > upload ac 2.71 package would allow more people to work on those few > remaining packages which still needs to be cleaned/updated. > > Otherwise some stuff will end up like the firefox, mozjs, nss, nspr > packages which still are using even older autoconf :/ (which is in own > sense ridiculous that one of the most actively maintained source trees > still is using so old build tooling) > > Some time ago gcc, binutils IIRC received an update for ac 2.71 so at > least those two should be by now off-the-table (Am I right?). > > In many cases executing "autoupdate", adding patch out of the changes > generated by that command to spec and submitting PR/MR against the original > source tree is all what needs to be done. This is not rocket science .. > > So .. anyone knows any other packages dist sources trees on which > something like "autoreconf -fiv" fails? > So far I found only two like that: openldap and gettext (in that case most > of the issues are caused by using gnulib which is another swampy area). > > It is still plenty of time before the f35 cycle needs to be finished, and > still it can be done RightWay(tm) .. no rush. > > For now posting ~óne time a week with updates about progress on wiping out > ac 2.69 should allow IMO final upgrade autoconf to 2.71 relatively soon. > > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
If any concerns about the autoconf2.69-2.69 compat package ? If needed it can be implemented as non-parallelly instalable, Thanks. Regards, Ondrej On Fri, Mar 5, 2021 at 8:08 AM Ondrej Dubaj wrote: > Thanks for your notes. If wanted, the first version of autoconf2.69-2.69 > compat package is available in copr for testing. This is a version which is > parallelly installable with autoconf-2.71. Please check/update your > packages and rebuild them. > > Thanks. Regards, > > Ondrej > > copr: > https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/ > > On Wed, Mar 3, 2021 at 2:45 PM Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > >> Miro Hrončok wrote: >> > 1) Why 269 and not 2.69? >> >> I guess that this is a historical thing: past autoconf compatibility >> packages always had names such as autoconf213. Back then, dots in package >> names were considered unusual or harmful, standard practice was to omit >> them. The rule that the dot should be included was added relatively >> recently >> (but already a couple years ago by now) to the packaging guidelines. >> >> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thanks for your notes. If wanted, the first version of autoconf2.69-2.69 compat package is available in copr for testing. This is a version which is parallelly installable with autoconf-2.71. Please check/update your packages and rebuild them. Thanks. Regards, Ondrej copr: https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/ On Wed, Mar 3, 2021 at 2:45 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Miro Hrončok wrote: > > 1) Why 269 and not 2.69? > > I guess that this is a historical thing: past autoconf compatibility > packages always had names such as autoconf213. Back then, dots in package > names were considered unusual or harmful, standard practice was to omit > them. The rule that the dot should be included was added relatively > recently > (but already a couple years ago by now) to the packaging guidelines. > > 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, Mar 3, 2021 at 1:51 PM Miro Hrončok wrote: > On 03. 03. 21 13:47, Ondrej Dubaj wrote: > > > > > > On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok > <mailto:mhron...@redhat.com>> wrote: > > > > On 03. 03. 21 12:49, Ondrej Dubaj wrote: > > > Compat package prepared. > > > > > > Package autoconf269-2.69-1 provides: > > > > > > /usr/bin/autoconf269 > > > /usr/bin/autoheader269 > > > /usr/bin/autom4te269 > > > /usr/bin/autoreconf269 > > > /usr/bin/autoscan269 > > > /usr/bin/autoupdate269 > > > /usr/bin/ifnames269 > > > ... > > > > > > Parallel installation successful. > > > > > > Any suggestions/concerns are welcome. > > > > My concerns are: > > > > 1) Why 269 and not 2.69? > > > > Just a naming convention, if needed can be easily changed > > There is no need to complicate stuff by removing the dot. The naming > convention > for compat packages is to include the version: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple Ok, will change immediately. > > > > 2) Is the parallel installability worth the trouble of different > names? > > > > It is up to us to discuss this. > > How are most of the packages in Fedora using? Is it spelling out > "autoconf" in > the spec file, or trough some configure scripts? If it is the second, I > worry > that a command will mean patching (or sedding) would be required. > Both, actually. > > -- > 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok wrote: > On 03. 03. 21 12:49, Ondrej Dubaj wrote: > > Compat package prepared. > > > > Package autoconf269-2.69-1 provides: > > > > /usr/bin/autoconf269 > > /usr/bin/autoheader269 > > /usr/bin/autom4te269 > > /usr/bin/autoreconf269 > > /usr/bin/autoscan269 > > /usr/bin/autoupdate269 > > /usr/bin/ifnames269 > > ... > > > > Parallel installation successful. > > > > Any suggestions/concerns are welcome. > > My concerns are: > > 1) Why 269 and not 2.69? > Just a naming convention, if needed can be easily changed 2) Is the parallel installability worth the trouble of different names? > It is up to us to discuss this. > > -- > 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
/share/autoconf/autotest/autotest.m4 /usr/share/autoconf/autotest/autotest.m4f /usr/share/autoconf/autotest/general.m4 /usr/share/autoconf/autotest/specific.m4 /usr/share/autoconf/build-aux /usr/share/autoconf/build-aux/config.guess /usr/share/autoconf/build-aux/config.sub /usr/share/autoconf/build-aux/install-sh /usr/share/autoconf/m4sugar /usr/share/autoconf/m4sugar/foreach.m4 /usr/share/autoconf/m4sugar/m4sh.m4 /usr/share/autoconf/m4sugar/m4sh.m4f /usr/share/autoconf/m4sugar/m4sugar.m4 /usr/share/autoconf/m4sugar/m4sugar.m4f /usr/share/autoconf/m4sugar/version.m4 /usr/share/config.site /usr/share/doc/autoconf /usr/share/doc/autoconf/AUTHORS /usr/share/doc/autoconf/ChangeLog /usr/share/doc/autoconf/NEWS /usr/share/doc/autoconf/README /usr/share/doc/autoconf/THANKS /usr/share/doc/autoconf/TODO /usr/share/emacs/site-lisp/autoconf /usr/share/emacs/site-lisp/autoconf/autoconf-mode.el /usr/share/emacs/site-lisp/autoconf/autoconf-mode.elc /usr/share/emacs/site-lisp/autoconf/autotest-mode.el /usr/share/emacs/site-lisp/autoconf/autotest-mode.elc /usr/share/emacs/site-lisp/site-start.d /usr/share/emacs/site-lisp/site-start.d/autoconf-init.el /usr/share/info/autoconf.info.gz /usr/share/licenses/autoconf /usr/share/licenses/autoconf/COPYING /usr/share/licenses/autoconf/COPYING.EXCEPTION /usr/share/licenses/autoconf/COPYINGv3 /usr/share/man/man1/autoconf.1.gz /usr/share/man/man1/autoheader.1.gz /usr/share/man/man1/autom4te.1.gz /usr/share/man/man1/autoreconf.1.gz /usr/share/man/man1/autoscan.1.gz /usr/share/man/man1/autoupdate.1.gz /usr/share/man/man1/ifnames.1.gz Parallel installation successful. Any suggestions/concerns are welcome. Ondrej On Wed, Mar 3, 2021 at 9:37 AM Dominique Martinet wrote: > Zbigniew Jędrzejewski-Szmek wrote on Wed, Mar 03, 2021 at 08:25:30AM +: > > On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote: > > > Understand, starting to work on delivering autoconf-2.69 compat > package. > > > Have to investigate if it would be possible to install autoconf-2.69 > and > > > autoconf-2.71 next to each other on the system. Will keep you updated. > > > > Actually, it might not be necessary to have them parallel-installable. > > If that is easy, then that's a nice property to have. But just being > > able to install one or the other in mock is enough. > > For what it's worth debian has compat packages so it doesn't look too bad: > > configure --normal-flags --program-suffix=2.69 > make pkgdatadir=/usr/share/autoconf2.69 > mv /usr/share/autoconf /usr/share/autoconf2.69 (at install time) > > seems to be most of it > > (that said I do agree it's not worth spending hours on it) > -- > Dominique > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Actually yes, you are right. Currently all fedora prackages are buildable with autoconf-2.69 and there is a small part (~190), which are not buildable with autoconf-2.71 (will use compat package instead). Thanks for your advice, I didn't realize this at the moment. Ondrej On Wed, Mar 3, 2021 at 9:31 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote: > > Understand, starting to work on delivering autoconf-2.69 compat package. > > Have to investigate if it would be possible to install autoconf-2.69 and > > autoconf-2.71 next to each other on the system. Will keep you updated. > > Actually, it might not be necessary to have them parallel-installable. > If that is easy, then that's a nice property to have. But just being > able to install one or the other in mock is enough. > > Zbyszek > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Understand, starting to work on delivering autoconf-2.69 compat package. Have to investigate if it would be possible to install autoconf-2.69 and autoconf-2.71 next to each other on the system. Will keep you updated. Ondrej On Mon, Mar 1, 2021 at 7:35 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, Feb 10, 2021 at 12:47:25PM -0500, Ben Cotton wrote: > > == Contingency Plan == > > * Contingency mechanism: moving this change to Fedora 36, if not > > successfully finished until Fedora 35 branching from Rawhide > > * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10) > > * Blocks release? No > > What is the final decision wrt. to compat package creation? With 190 > packages failing to build, I think it's very likely that at least some > of those will still fail to build 5 months from now. The contingency > mechanism, as described, would be to postpone the update to F36 at that > point. I think this is not desirable, not least because it doesn't > guarantee > that we will not have a very similar situation *12* months from now. > > So instead, I'd very much propose to plan that a compat package will > be created, and that *some* packages will require autoconf-2.69, and > if they do, switch them over to use the compat package. *If* it turns > out early enough that the compat package is not needed, we can skip it. > > Overall, I think things would go much smoother this way. With the > current plan, by creating a flag day, we're actually making it harder > to develop against 2.71, because it'll not be available in Fedora > until *everything* has been switched over. > > Zbyszek > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
I understand, thanks for the explanation. We will wait to see what other maintainers and upstreams will say. This explanation is exactly what we need to have as much information as we can. Hopefully other maintainers will soonly present their opinions as well. Thanks. Ondrej On Thu, Feb 25, 2021 at 5:51 PM Brian C. Lane wrote: > On Thu, Feb 25, 2021 at 07:55:09AM +0100, Ondrej Dubaj wrote: > > Brian, > > > > I understand, but as I already said, compat package can lead to > > unwillingness to move forward to autoconf-2.71. For example, we can have > a > > compat package for f35 to have time to deal with the problems, but > > certainly not for f36 or f37. After release of autoconf-2.71, I expect > most > > of the upstream packages moving to autoconf-2.71 in one year time, so > > hopefully no compat package will be needed. > > I think you are optimistic :) > > > > > Why are you not thinking of moving parted to autoconf-2.71 ? Are there > any > > special reasons for not doing this? > > Nobody else is using it yet. Ubuntu, Debian, Alpine, and FreeBSD (and I'm > pretty sure the other *BSD flavors) are still using 2.69. The Gentoo has > it available, as does the Debian experimental branch but it doesn't look > like they are ready for general use yet. > > We (the parted maintainers) need to make sure that parted remains > buildable for all the users of it, not just Fedora, so it can't switch > until 2.71 is widely available and is well tested. I have a big patch > that seems to work, but that's going to make patching difficult for me > until upstream is ready to switch so I'd rather just stick with 2.69 > > There needs to be a period of overlap to allow upstreams to experiment > with the new version. > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > > ___ 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Brian, I understand, but as I already said, compat package can lead to unwillingness to move forward to autoconf-2.71. For example, we can have a compat package for f35 to have time to deal with the problems, but certainly not for f36 or f37. After release of autoconf-2.71, I expect most of the upstream packages moving to autoconf-2.71 in one year time, so hopefully no compat package will be needed. Why are you not thinking of moving parted to autoconf-2.71 ? Are there any special reasons for not doing this? Thanks. Ondrej On Wed, Feb 24, 2021 at 6:36 PM Brian C. Lane wrote: > On Wed, Feb 24, 2021 at 08:14:17AM +0100, Ondrej Dubaj wrote: > > Brian, > > > > you are right there are some changes which are now backward compatible. > > That's the reason why we need cross-component cooperation from other > > maintainers to detect these pieces and potentially report them to > upstream > > and see if they are willing to fix them. Another option is also to > create a > > compat package for autoconf-2.69 for f35, but it can lead to a result, > > where some of the maintainers/upstreams will never use autoconf-2.71. > > I think we need to create a 2.69 compat package. I certainly have no > current plans to switch upstream parted to 2.71 and while I now have a > wonderful 1.8M patch that fixes it for Fedora I'd rather just use the > upstream tar release with 2.69 until we're comfortable moving. > > Having 2.71 available is valuable, so both should be packaged, but it > should not be a requirement at this point. > > Brian > > -- > Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart > > ___ 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Brian, you are right there are some changes which are now backward compatible. That's the reason why we need cross-component cooperation from other maintainers to detect these pieces and potentially report them to upstream and see if they are willing to fix them. Another option is also to create a compat package for autoconf-2.69 for f35, but it can lead to a result, where some of the maintainers/upstreams will never use autoconf-2.71. If there are any packages, which are already orphaned, do not hesitate to let me know and I will remove them. Also, if you are missing any package there. Autoconf changes have a huge impact on the whole system, so it needs to be properly tested and agreed. Thanks for your cooperation! Ondrej On Wed, Feb 24, 2021 at 1:44 AM Jeff Law wrote: > > > On 2/23/21 4:54 PM, Jerry James wrote: > > On Tue, Feb 23, 2021 at 4:52 PM Jeff Law wrote: > >> On 2/23/21 4:39 PM, Brian C. Lane wrote: > >>> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote: > >>>> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/ > >>> Doesn't work, with or without :8080 > >> Not sure what you're referring to, it just worked fine for me. > > As Ondrej said: "Attaching also results from a tester launched by Jeff > > Law [2] (accessible only on Red Hat VPN)". Those of us without access > > to the Red Hat VPN cannot see those results. > But Brian is (or can be) inside the VPN. That's what I was referring to. > > jeff > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thanks for your note, I will look at the dependent packages (they were selected ~1 month ago). But technically, it does not disturb us if some package does not require on autoconf and builds successfully. We have to focus on failed builds and investigate where the problem is. Ondrej On Tue, Feb 23, 2021 at 12:55 PM Ian McInerney wrote: > On Tue, Feb 23, 2021 at 10:38 AM Ondrej Dubaj wrote: > >> Hello, >> >> please see attached rebuild of autoconf-dependencies [1]. I would like to >> ask maintainers of the dependent packages to check if their packages are >> buildable with autoconf-2.71. It seems that lots of packages are checking >> for exactly version 2.69, which blocks the build and there might be no >> problem with version 2.71. Also there are some minor issues (unresolved >> dependencies, failure in %check phase,...), which can be resolved by a >> small fix. Please investigate the appropriate copr builds. If your fix is >> ready, just push it to the rawhide branch and it will be automatically >> rebuilt with the new autoconf-2.71 in copr. Most of the packages are >> successfully built with autoconf (~1450 from ~1600), so there are ~150 >> packages to investigate. >> >> Attaching also results from a tester launched by Jeff Law [2] (accessible >> only on Red Hat VPN) which shows changes of packages with autoconf-2.69 and >> autoconf-2.71. This may help to understand the changes better. >> >> Thank you for your cooperation! >> >> Ondrej. >> >> [1] >> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/ >> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/ >> >> > How did you find the dependent packages? I would suggest updating the > dependent packages list again, since audacity can be removed from the list > of packages needing a rebuild since you are using 2.4.2. That release > switched to CMake from autotools because upstream unceremoniously removed > the entire autotools build system in the patch release. > > -Ian > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Hello, please see attached rebuild of autoconf-dependencies [1]. I would like to ask maintainers of the dependent packages to check if their packages are buildable with autoconf-2.71. It seems that lots of packages are checking for exactly version 2.69, which blocks the build and there might be no problem with version 2.71. Also there are some minor issues (unresolved dependencies, failure in %check phase,...), which can be resolved by a small fix. Please investigate the appropriate copr builds. If your fix is ready, just push it to the rawhide branch and it will be automatically rebuilt with the new autoconf-2.71 in copr. Most of the packages are successfully built with autoconf (~1450 from ~1600), so there are ~150 packages to investigate. Attaching also results from a tester launched by Jeff Law [2] (accessible only on Red Hat VPN) which shows changes of packages with autoconf-2.69 and autoconf-2.71. This may help to understand the changes better. Thank you for your cooperation! Ondrej. [1] https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/ [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/ On Fri, Feb 12, 2021 at 11:00 PM David Cantrell wrote: > Sounds good. Just find me on IRC or by email and let me know what you > would like help on. I can help run/monitor scripts of builds and help > script reporting to BZ for things that fail. > > Thanks, > > On Thu, Feb 11, 2021 at 03:55:41PM +0100, Ondrej Dubaj wrote: > >Thank you for your advice and willingness to help with testing. There is a > >plan to create a side tag and test appropriate changes there. > > > >Changed category to system-wide change. > > > >Ondrej > > > >On Thu, Feb 11, 2021 at 3:42 PM David Cantrell > wrote: > > > >> On Wed, Feb 10, 2021 at 12:30:20PM -0700, Jeff Law wrote: > >> > > >> > > >> >On 2/10/21 11:00 AM, Miro Hrončok wrote: > >> >> On 10. 02. 21 18:47, Ben Cotton wrote: > >> >>> == Upgrade/compatibility impact == > >> >>> Problems during build can appear in multiple packages what can lead > to > >> >>> build failure, as multiple packages require autoconf-2.69 as their > >> >>> upstream dependency. These problems have to be resolved before > adding > >> >>> autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages > >> >>> are having problems during build, which could be caused by a problem > >> >>> with same pattern. > >> >> > >> >> In absolute numbers, what is 20%? I see ~200 failures at > >> >> > https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/ > >> >> (obviously not all of them are necessarily caused by autoconf). > >> >> > >> >> Should this be a system-wide change instead? > >> >Given how many packages use autoconf, I think so. > >> > >> +1 > >> > >> autoconf changes are a big build impact and [most?] maintainers like > >> to avoid surprises here. > >> > >> >I've already volunteered my tester to help shake out this change. It's > >> >actually a really good fit because of the autoconf/LTO interactions we > >> >had to sort out for F33/LTO. The plan is to spin it up next week. > >> > > >> >In simplest terms autoconf generated code to test for the existence of > >> >certain capabilities can be optimized away completely by LTO. This > >> >results in autoconf incorrectly claiming certain capabilities exist. > >> >This can cause packages to FTBFS or to even mis-behave at runtime. > >> > > >> >Thus it was critical to find these cases and deal with them as part of > >> >the LTO effort. So my tester has the ability to capture generated > >> >config.h files across its control and test builds and will report a > >> >failure if the generated config.h files differ (with an ability to > >> >exclude those where timestamps and such end up in the generated > config.h > >> >files). > >> > > >> >In the test I'm going to run the only difference between the control > and > >> >test build will be the version of autoconf. So the failures should > give > >> >us a highly accurate picture of how autoconf-2.70 will impact the > >> >distribution as a whole. > >> > >> This is a good idea. But really, I would like to see packages that > >> run autoconf during build to be checked. I do not think it is > >> sufficient to just check a subset of packages or even one part
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Thank you for your advice and willingness to help with testing. There is a plan to create a side tag and test appropriate changes there. Changed category to system-wide change. Ondrej On Thu, Feb 11, 2021 at 3:42 PM David Cantrell wrote: > On Wed, Feb 10, 2021 at 12:30:20PM -0700, Jeff Law wrote: > > > > > >On 2/10/21 11:00 AM, Miro Hrončok wrote: > >> On 10. 02. 21 18:47, Ben Cotton wrote: > >>> == Upgrade/compatibility impact == > >>> Problems during build can appear in multiple packages what can lead to > >>> build failure, as multiple packages require autoconf-2.69 as their > >>> upstream dependency. These problems have to be resolved before adding > >>> autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages > >>> are having problems during build, which could be caused by a problem > >>> with same pattern. > >> > >> In absolute numbers, what is 20%? I see ~200 failures at > >> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/ > >> (obviously not all of them are necessarily caused by autoconf). > >> > >> Should this be a system-wide change instead? > >Given how many packages use autoconf, I think so. > > +1 > > autoconf changes are a big build impact and [most?] maintainers like > to avoid surprises here. > > >I've already volunteered my tester to help shake out this change. It's > >actually a really good fit because of the autoconf/LTO interactions we > >had to sort out for F33/LTO. The plan is to spin it up next week. > > > >In simplest terms autoconf generated code to test for the existence of > >certain capabilities can be optimized away completely by LTO. This > >results in autoconf incorrectly claiming certain capabilities exist. > >This can cause packages to FTBFS or to even mis-behave at runtime. > > > >Thus it was critical to find these cases and deal with them as part of > >the LTO effort. So my tester has the ability to capture generated > >config.h files across its control and test builds and will report a > >failure if the generated config.h files differ (with an ability to > >exclude those where timestamps and such end up in the generated config.h > >files). > > > >In the test I'm going to run the only difference between the control and > >test build will be the version of autoconf. So the failures should give > >us a highly accurate picture of how autoconf-2.70 will impact the > >distribution as a whole. > > This is a good idea. But really, I would like to see packages that > run autoconf during build to be checked. I do not think it is > sufficient to just check a subset of packages or even one particular > use case. I think to do this with minimal impact, we kind of need to > make sure everything using autoconf has incorporated the necessary > changes for autoconf-2.71. In many cases, things may be ready to go. > But I don't think we can assume that. > > The approach mhroncok@ and others have used for major Python changes I > think could be applied here. As an autoconf user [under duress, but > still, I have to rely on it], I would like the opportunity to have an > autoconf-2.71 side tag to verify my packages build there before we > update rawhide with 2.71. We could automate builds to test things out > and file bugs for package maintainers for failures. I know this is a > lot of work, but I think the proactive approach is better than > throwing it in to rawhide and fixing the fallout. > > I am volunteering to help perform these test builds and file bugs > and/or PRs for packages since what I am suggesting is a lot of work. > > Thanks, > > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > ___ > 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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Jeff, thank you for your offer, I will gladly use your tester. What information/RPMs/SRPMs do you need from me? Miro, maybe it could be a system-wide change. If you think so, I can change it. About the absolute numbers, as you said, not all FTBFS are necessarily caused by autoconf, but I did not have the time to investigate all of them. >From my perspective, lots of failures were caused by upstream/downstream dependency directly on autoconf-2.69, so we have to discuss these changes with package maintainers. Ondrej On Wed, Feb 10, 2021 at 8:32 PM Jeff Law wrote: > > > On 2/10/21 11:00 AM, Miro Hrončok wrote: > > On 10. 02. 21 18:47, Ben Cotton wrote: > >> == Upgrade/compatibility impact == > >> Problems during build can appear in multiple packages what can lead to > >> build failure, as multiple packages require autoconf-2.69 as their > >> upstream dependency. These problems have to be resolved before adding > >> autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages > >> are having problems during build, which could be caused by a problem > >> with same pattern. > > > > In absolute numbers, what is 20%? I see ~200 failures at > > https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/ > > (obviously not all of them are necessarily caused by autoconf). > > > > Should this be a system-wide change instead? > Given how many packages use autoconf, I think so. > > -- > > I've already volunteered my tester to help shake out this change. It's > actually a really good fit because of the autoconf/LTO interactions we > had to sort out for F33/LTO. The plan is to spin it up next week. > > In simplest terms autoconf generated code to test for the existence of > certain capabilities can be optimized away completely by LTO. This > results in autoconf incorrectly claiming certain capabilities exist. > This can cause packages to FTBFS or to even mis-behave at runtime. > > Thus it was critical to find these cases and deal with them as part of > the LTO effort. So my tester has the ability to capture generated > config.h files across its control and test builds and will report a > failure if the generated config.h files differ (with an ability to > exclude those where timestamps and such end up in the generated config.h > files). > > In the test I'm going to run the only difference between the control and > test build will be the version of autoconf. So the failures should give > us a highly accurate picture of how autoconf-2.70 will impact the > distribution as a whole. > > jeff > ___ > 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Announcement: orphaning java-comment-preprocessor
Hello, orphaning java-comment-preprocessor due to missing dependencies for the new version (cannot be rebased) and no other package dependents on it. Regards, Ondrej ___ 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: Announcement: unixODBC - moving unversioned plugins and libraries
Hi Michal,
there was already a discussion in email thread with the maintainers of
packages which depend on unixODBC or unixODBC-devel according to these
changes. I did not planned to submit any PRs but the maintainers should be
informed about this change. The results as you see it is an end product of
the discussion. I agree that some of the packages might be affected and
also some end-users can have problems and need to edit their config files,
but I am unable to fix these things on all sides. This needs a cooperation
between maintainers and it is necessary to make changes in affected
packages according to the described changes.
Ondrej
On Fri, Oct 23, 2020 at 9:00 AM Michal Schorm wrote:
> On Fri, Oct 23, 2020 at 8:31 AM Ondrej Dubaj wrote:
> > announcing moving unversioned libraries from unixODBC main package to
> unixODBC-devel package. Also moving unversioned plugins, which are in main
> package from %{_libdir} to %{_libdir}/unixODBC according to fedora
> packaging standards
>
> I'm glad to see this happening.
>
> Will you also take care of the packages which pack the ODBC plugins
> (e.g. ODBC connectors to databases) to the %{_libdir} at the moment
> (so their location is aligned with the other unixODBC libraries) ?
> I know that at least two of my packages are affected, however it would
> be great if you would either post a list of affected packages and
> their maintainers, or submit PRs to them.
>
> Michal
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
> ___
> 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
Announcement: unixODBC - moving unversioned plugins and libraries
Hello,
announcing moving unversioned libraries from unixODBC main package to
unixODBC-devel package. Also moving unversioned plugins, which are in main
package from %{_libdir} to %{_libdir}/unixODBC according to fedora
packaging standards [1]
So the resolution will look like
Main package:
%{_libdir}/libodbccr.so.2
%{_libdir}/libodbccr.so.2.0.0
%{_libdir}/libodbcdrvcfg1S.so.2
%{_libdir}/libodbcdrvcfg1S.so.2.0.0
%{_libdir}/libodbcdrvcfg2S.so.2
%{_libdir}/libodbcdrvcfg2S.so.2.0.0
%{_libdir}/libodbcinst.so.2
%{_libdir}/libodbcinst.so.2.0.0
%{_libdir}/libodbcminiS.so.2
%{_libdir}/libodbcminiS.so.2.0.0
%{_libdir}/libodbcmyS.so.2
%{_libdir}/libodbcmyS.so.2.0.0
%{_libdir}/libodbcnnS.so.2
%{_libdir}/libodbcnnS.so.2.0.0
%{_libdir}/libodbcpsqlS.so.2
%{_libdir}/libodbcpsqlS.so.2.0.0
%{_libdir}/libodbc.so.2
%{_libdir}/libodbc.so.2.0.0
%{_libdir}/libodbctxtS.so.2
%{_libdir}/libodbctxtS.so.2.0.0
%{_libdir}/unixODBC/libodbcmyS.so
%{_libdir}/unixODBC/libodbcpsqlS.so
%{_libdir}/unixODBC/libtdsS.so
+ rest of the provided files, which won't be changed
Devel-package:
%{_libdir}/libodbccr.so
%{_libdir}/libodbcinst.so
%{_libdir}/libodbc.so
%{_libdir}/libodbcdrvcfg1S.so
%{_libdir}/libodbcdrvcfg2S.so
%{_libdir}/libodbcminiS.so
%{_libdir}/libodbcnnS.so
%{_libdir}//libodbctxtS.so
+ rest of the provided files, which won't be changed
Thanks for understanding.
Regards,
Ondrej
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
___
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
Unresponsive maintainer: pkajaba
Hello, does anyone know how to contact pkajaba, who is main admin of java-comment-preprocessor in fedora ? https://bugzilla.redhat.com/show_bug.cgi?id=1890573 Thanks, Ondrej ___ 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
Announcement: orphaning java-comment-preprocessor
Hello, as no more package depends anymore on java-comment-preprocessor and we are unable to update this package to the latest upstream version due to missing dependencies, we are orphaning it. If someone has any concerns, please share them with us. Thanks, Ondrej ___ 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: Aiming to orphan java-comment-preprocessor package
Aiming to orphan this package soon, any concerns ? Thanks. Ondrej On Thu, Oct 15, 2020 at 10:26 AM Ondrej Dubaj wrote: > Proposed upstream change: > > https://github.com/pgjdbc/pgjdbc/pull/1930 > > Downstream change will be done during this day. > > Thanks! > > Ondrej > > On Thu, Oct 15, 2020 at 10:20 AM Pavel Raiskup > wrote: > >> On Thursday, October 15, 2020 10:10:20 AM CEST Ondrej Dubaj wrote: >> > Yes, thanks for the notice. This package is buildable without >> > java-comment-preprocessor ( >> > https://koji.fedoraproject.org/koji/taskinfo?taskID=5346). Do you >> know >> > about any other packages ? >> >> You should have tell that pgjdbc stopped using this project (please drop >> the >> BuildRequires in the upstream repo, and also downstream). So +1 for drop. >> >> Pavel >> >> > On Thu, Oct 15, 2020 at 9:30 AM Pavel Raiskup >> wrote: >> > >> > > On Thursday, October 15, 2020 8:37:02 AM CEST Ondrej Dubaj wrote: >> > > > Hi guys, >> > > > >> > > > I am aiming to orphan java-comment-precprocessor package, as it >> seems, >> > > > there are no other packages (AFAIK) depending on it. If there is >> someone, >> > > > who is actively using this package, or maintains a package, which >> depends >> > > > on it, please let us know to this thread, so we can discuss next >> steps. >> > > >> > > postgresql-jdbc.spec BuildRequires the java-comment-preprocessor. >> > > >> > > Pavel >> > > >> > > > Thanks! >> > > > >> > > > Regards, >> > > > Ondrej >> > > > >> > > >> > > >> > > >> > > >> > > >> > >> >> >> >> >> ___ 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: Aiming to orphan java-comment-preprocessor package
Proposed upstream change: https://github.com/pgjdbc/pgjdbc/pull/1930 Downstream change will be done during this day. Thanks! Ondrej On Thu, Oct 15, 2020 at 10:20 AM Pavel Raiskup wrote: > On Thursday, October 15, 2020 10:10:20 AM CEST Ondrej Dubaj wrote: > > Yes, thanks for the notice. This package is buildable without > > java-comment-preprocessor ( > > https://koji.fedoraproject.org/koji/taskinfo?taskID=5346). Do you > know > > about any other packages ? > > You should have tell that pgjdbc stopped using this project (please drop > the > BuildRequires in the upstream repo, and also downstream). So +1 for drop. > > Pavel > > > On Thu, Oct 15, 2020 at 9:30 AM Pavel Raiskup > wrote: > > > > > On Thursday, October 15, 2020 8:37:02 AM CEST Ondrej Dubaj wrote: > > > > Hi guys, > > > > > > > > I am aiming to orphan java-comment-precprocessor package, as it > seems, > > > > there are no other packages (AFAIK) depending on it. If there is > someone, > > > > who is actively using this package, or maintains a package, which > depends > > > > on it, please let us know to this thread, so we can discuss next > steps. > > > > > > postgresql-jdbc.spec BuildRequires the java-comment-preprocessor. > > > > > > Pavel > > > > > > > Thanks! > > > > > > > > Regards, > > > > Ondrej > > > > > > > > > > > > > > > > > > > > > > > > > > ___ 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: Aiming to orphan java-comment-preprocessor package
Yes, thanks for the notice. This package is buildable without java-comment-preprocessor ( https://koji.fedoraproject.org/koji/taskinfo?taskID=5346). Do you know about any other packages ? Thanks. Ondrej On Thu, Oct 15, 2020 at 9:30 AM Pavel Raiskup wrote: > On Thursday, October 15, 2020 8:37:02 AM CEST Ondrej Dubaj wrote: > > Hi guys, > > > > I am aiming to orphan java-comment-precprocessor package, as it seems, > > there are no other packages (AFAIK) depending on it. If there is someone, > > who is actively using this package, or maintains a package, which depends > > on it, please let us know to this thread, so we can discuss next steps. > > postgresql-jdbc.spec BuildRequires the java-comment-preprocessor. > > Pavel > > > Thanks! > > > > Regards, > > Ondrej > > > > > > > ___ 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
Aiming to orphan java-comment-preprocessor package
Hi guys, I am aiming to orphan java-comment-precprocessor package, as it seems, there are no other packages (AFAIK) depending on it. If there is someone, who is actively using this package, or maintains a package, which depends on it, please let us know to this thread, so we can discuss next steps. Thanks! Regards, Ondrej ___ 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Rebuild of dependent packages with the new unixODBC seems to be quite optimistic. The are only few failures and none of them seems to be caused by some missing libraries. We can now discuss only about the runtime problems, as it seems, almost no buildtime problems occurred https://copr.fedorainfracloud.org/coprs/odubaj/unixODBC/builds/ On Thu, Oct 1, 2020 at 1:20 PM Ondrej Dubaj wrote: > My apologies, of course we are aiming to package the unversioned symbolic > links to the "real" libraries to *-devel package. I thought it was clear > from the beginning. > > Why should we hack the soversion ? There are no changes to the soname or > ABI compatibility coming, we want to just package the unversioned symbolic > links to the "real" libraries to *-devel package. > > On Thu, Oct 1, 2020 at 1:14 PM Richard Shaw wrote: > >> Adding my $0.02 here... >> >> Since they are real libraries, they don't belong in a -devel package, the >> intent is to package the unversioned symbolic links to the "real" >> libraries. A end user package should never require a -devel package to run. >> >> One option would be to hack in a soversion to the build process. I did >> this for many years with openCOLLADA, and used either >> abi-compliance-checker or abipkgdiff to determine when a soversion bump was >> required. >> >> Thanks, >> Richard >> ___ >> 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
My apologies, of course we are aiming to package the unversioned symbolic links to the "real" libraries to *-devel package. I thought it was clear from the beginning. Why should we hack the soversion ? There are no changes to the soname or ABI compatibility coming, we want to just package the unversioned symbolic links to the "real" libraries to *-devel package. On Thu, Oct 1, 2020 at 1:14 PM Richard Shaw wrote: > Adding my $0.02 here... > > Since they are real libraries, they don't belong in a -devel package, the > intent is to package the unversioned symbolic links to the "real" > libraries. A end user package should never require a -devel package to run. > > One option would be to hack in a soversion to the build process. I did > this for many years with openCOLLADA, and used either > abi-compliance-checker or abipkgdiff to determine when a soversion bump was > required. > > Thanks, > Richard > ___ > 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
I see no other discussion here and related arguments not to make this update. I know it might break other packages, but it needs to be done to be according to the guidelines. I do not see it as a big problem to rebuild the dependend packages with additional dependency on unixODBC-devel package, if it will be needed. Or if there will be some runtime problem, it can be easily fixed by editing the config file and dlopening the versioned libraries. If there will be a big need not to edit the config files, there is nothing simpler than installing unixODBC-devel package and everything works again. Am I missing some other cases ? Thanks for your ideas. On Mon, Sep 21, 2020 at 8:13 AM Ondrej Dubaj wrote: > any other suggestions here ? I will be glad, if maintainers of dependent > packages will share their opinions. If we fix this issue and it breaks > dependent packages, simple workaround via symlink is available until the > problems will be solved, so I see no reason for ignoring this problem. > > On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch wrote: > >> >> Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a): >> > * Tom Hughes via devel: >> > >> >> On 11/09/2020 07:13, Ondrej Dubaj wrote: >> >> >> >>> There seemed to be no big reason for moving the libraries to the >> >>> main package in the past, so I consider f34 as a good candidate for >> >>> such a change. It would be great, if you share your opinions and >> >>> concerns for this topic. >> >> Tom Lane has explained the reason on the ticket, it's because the >> >> library is often dlopened by a client application instead of being >> >> linked to. >> >> >> "often" is relative. I see this mentioned for following packages: >> >> >> java-1.5.0-ibm-jdbc >> >> java-1.6.0-sun-jdbc >> >> java-1.5.0-bea-jdbc >> >> >> Which probably shares common history and at least one of them admitted >> the mistake [1] and started to use the versioned .so file. >> >> So are there any other cases? >> >> >> > Yes, that is sufficient reason not to do the move. Third-party >> > applications will break. >> >> >> And they should be fixed. I understand there is never the right time to >> fix this, but if not now, then when? >> >> >> > Some people also really dislike installing >> > *-devel packages in production, so there might not be an easy fix for >> > them. >> > >> > The library probably should not have a versioned soname in the first >> > place, with backwards compatibility achieved by different means. But >> > that does not matter now. >> > >> > Thanks, >> > Florian >> >> >> Vít >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24 >> >> ___ >> 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
any other suggestions here ? I will be glad, if maintainers of dependent packages will share their opinions. If we fix this issue and it breaks dependent packages, simple workaround via symlink is available until the problems will be solved, so I see no reason for ignoring this problem. On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch wrote: > > Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a): > > * Tom Hughes via devel: > > > >> On 11/09/2020 07:13, Ondrej Dubaj wrote: > >> > >>> There seemed to be no big reason for moving the libraries to the > >>> main package in the past, so I consider f34 as a good candidate for > >>> such a change. It would be great, if you share your opinions and > >>> concerns for this topic. > >> Tom Lane has explained the reason on the ticket, it's because the > >> library is often dlopened by a client application instead of being > >> linked to. > > > "often" is relative. I see this mentioned for following packages: > > > java-1.5.0-ibm-jdbc > > java-1.6.0-sun-jdbc > > java-1.5.0-bea-jdbc > > > Which probably shares common history and at least one of them admitted > the mistake [1] and started to use the versioned .so file. > > So are there any other cases? > > > > Yes, that is sufficient reason not to do the move. Third-party > > applications will break. > > > And they should be fixed. I understand there is never the right time to > fix this, but if not now, then when? > > > > Some people also really dislike installing > > *-devel packages in production, so there might not be an easy fix for > > them. > > > > The library probably should not have a versioned soname in the first > > place, with backwards compatibility achieved by different means. But > > that does not matter now. > > > > Thanks, > > Florian > > > Vít > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24 > > ___ > 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
On Fri, Sep 11, 2020 at 9:15 AM Lukas Javorsky wrote:
> From my point of view, it's a good idea to move them into the *-devel
> package.
>
> It's more effective and ordered for future development.
> Because if someone only needs a few libraries, they don't have to require
> the whole main package and can just require a devel package, which is the
> way we want it as far as I know.
>
That is not the case we are aiming for, as unixODBC-devel requires
unixODBC, so the devel package will pull the main package as a dependency
during installation. The aim is that the main package should not contain
the unversioned shared libraries, as they are supposed to be used during
development and not dynamic linking. But there might be a problem if client
applications dynamically load the unversioned libraries, are they actually
able to dlopen the versioned ones ? Even if using some kind of config file
to specify the version of the shared library?
Thanks,
Ondrej
>
> Lukas
>
> On Fri, Sep 11, 2020 at 8:14 AM Ondrej Dubaj wrote:
>
>> Hello everyone,
>>
>> I would like to start a discussion about moving unversioned *.so files
>> back to unixODBC-devel package, as they are currently in the main package.
>> The reason for this discussion is primary have things in order according to
>> future rhel-9.
>>
>> There will potentially be a change of moving 5 files {libodbc.so
>> libodbcinst.so libodbcpsqlS.so libodbcmyS.so libtdsS.so} to devel
>> package, so from the maintainers/users perspective, dependent packages will
>> have to require also the devel package and should be rebuild as well. No
>> other changes will be made.
>>
>> There seemed to be no big reason for moving the libraries to the main
>> package in the past, so I consider f34 as a good candidate for such a
>> change. It would be great, if you share your opinions and concerns for
>> this topic.
>>
>> Sharing also the official documentation [1], tracker in bugzilla [2] and
>> upcoming changes in unixODBC package [3]
>>
>> Thanks!
>>
>> Ondrej
>>
>> [1]
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1877720
>> [3]
>> https://src.fedoraproject.org/fork/odubaj/rpms/unixODBC/c/7ecddca7cfcc4e014bf65085dd9547f1c5981138
>> ___
>> 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
>>
>
>
> --
> S pozdravom/ Best regards
>
> Lukas Javorsky
>
> Intern, Core service - Databases
>
> Red Hat <https://www.redhat.com>
>
> Purkyňova 115 (TPB-C)
>
> 612 00 Brno - Královo Pole
>
> ljavo...@redhat.com
> <https://www.redhat.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
>
___
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
Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Hello everyone,
I would like to start a discussion about moving unversioned *.so files back
to unixODBC-devel package, as they are currently in the main package. The
reason for this discussion is primary have things in order according to
future rhel-9.
There will potentially be a change of moving 5 files {libodbc.so
libodbcinst.so libodbcpsqlS.so libodbcmyS.so libtdsS.so} to devel package,
so from the maintainers/users perspective, dependent packages will have to
require also the devel package and should be rebuild as well. No other
changes will be made.
There seemed to be no big reason for moving the libraries to the main
package in the past, so I consider f34 as a good candidate for such a
change. It would be great, if you share your opinions and concerns for
this topic.
Sharing also the official documentation [1], tracker in bugzilla [2] and
upcoming changes in unixODBC package [3]
Thanks!
Ondrej
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1877720
[3]
https://src.fedoraproject.org/fork/odubaj/rpms/unixODBC/c/7ecddca7cfcc4e014bf65085dd9547f1c5981138
___
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: Strange Java package build failures (Error in scriptlet ?)
On Fri, Aug 14, 2020 at 7:07 PM Fabio Valentini wrote: > Hi everybody, > > Since ~2 days ago, the rawhide koji buildroot has exhibited some > *really weird* issues when building Java packages with maven (when > building packages locally with "mock -r fedora-rawhide-x86_64 > --enablerepo local foo.src.rpm"). > > During installation of the build dependencies, some random (?) Java > package will have a scriptlet failure like this: "Error in > scriptlet in rpm package mockito" (the package that this error occurs > in is not always the same). This is always the last scriptlet run > before the "Verifying" stage of "dnf install". > > Then, later, during execution of %build, the following errors show up, > which make the it fail: > /usr/share/maven/bin/mvn: Failed to set JAVACMD > The JAVA_HOME environment variable is not defined correctly > This environment variable is needed to run this program > NB: JAVA_HOME should point to a JDK not a JRE > Experiencing the same problem. Haven;t found any usefull info about this > > Sometimes, scrubbing the mock buildroot makes the next build succeed, > sometimes it doesn't. I tried entering the buildroot with "mock shell" > but it didn't yield any useful information. > > I see that the scripts setting up JAVA_HOME etc. try to find a java + > javac executable, but they're all there, and the alternatives setup > also looks sane (no broken links in /etc/alternatives). > > The only Java related updates I see in the buildroot for the "critical > time frame" are builds of java-11-openjdk, but I'm not sure how they > could have introduced such inconsistently buggy buildroot behaviour :( > > Does anybody have an idea what might be the problem here? It's really > annoying to be unable to build Java packages locally most of the time > (curiously, I haven't seen this issue happen in any koji builds yet). > > 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 > ___ 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: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide
Hello everyone, today I am removing libdb-java subpackage from Fedora-rawhide (see messages above for more info). If someone of you will face any problems, please let us know. Thanks! Regards, Ondrej On Wed, Jun 24, 2020 at 11:27 AM Ondrej Dubaj wrote: > I don;t think this is a reason not removing libdb-java subpackage from > Fedora-Rawhide. If you are an active user of it, or you know somebody who > actively uses it, we can discuss more about these issues. > > Thanks, > Ondrej > > On Mon, Jun 15, 2020 at 9:54 AM Florian Weimer wrote: > >> * Jiri Vanek: >> >> > Is there some replacemnt for this subpackage? At least theoretical? >> >> For the JDBC connector to SQLite, there's sqlite-jdbc and javasqlite. >> But the on-disk format will be different. >> >> For the key-value store, there is the je package, but again the on-disk >> format is different. >> >> Thanks, >> Florian >> >> ___ 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: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide
I don;t think this is a reason not removing libdb-java subpackage from Fedora-Rawhide. If you are an active user of it, or you know somebody who actively uses it, we can discuss more about these issues. Thanks, Ondrej On Mon, Jun 15, 2020 at 9:54 AM Florian Weimer wrote: > * Jiri Vanek: > > > Is there some replacemnt for this subpackage? At least theoretical? > > For the JDBC connector to SQLite, there's sqlite-jdbc and javasqlite. > But the on-disk format will be different. > > For the key-value store, there is the je package, but again the on-disk > format is different. > > Thanks, > Florian > > ___ 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: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide
Agree, I am not aware of any replacement of this JDBC connector. As you said, it can be easily returned if it would be missed. On Mon, Jun 15, 2020 at 9:27 AM Jiri Vanek wrote: > On 6/15/20 9:13 AM, Florian Weimer wrote: > > * Ondrej Dubaj: > > > >> The problem is unknown runtime behaviour of libdb-java (build with > >> jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an > >> active user of libdb java ? > > > > I am not. > > > > Upon second thought, it doesn't seem to make sense to preserve > > libdb-java (although I expect that it's only necessary to fix the > > autoconf check). > > Maybe. However upstream of is dead. And usptream confirmed that they are > unable to verify that it > works in JDK11. > > Imho droppoing such possibly instbale package is probably good way. If it > will be missed, then it > can be returned, and the one wishing its return will be used as tester. > > Is there some replacemnt for this subpackage? At least theoretical? > > > > Thanks, > > Florian > > ___ > > java-devel mailing list -- java-de...@lists.fedoraproject.org > > To unsubscribe send an email to java-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/java-de...@lists.fedoraproject.org > > > > > -- > Jiri Vanek > Senior QE engineer, OpenJDK QE lead, Mgr. > Red Hat Czech > jva...@redhat.comM: +420775390109 > > ___ 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: Announcement: Aim to remove libdb-java from Fedora-rawhide
I edited the autoconf check and it seems there are other issues, which are causing problems. I also contacted upstream and they do not have any experience with this version working with jdk-11 or jvm-11. I see it as a high risk to "somehow" rebuild it and push it to rawhide. In addition, there is a deprecation announcement to whole libdb, so I consider this as a good first step. Thanks, Ondrej On Mon, Jun 15, 2020 at 9:13 AM Florian Weimer wrote: > * Ondrej Dubaj: > > > The problem is unknown runtime behaviour of libdb-java (build with > > jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an > > active user of libdb java ? > > I am not. > > Upon second thought, it doesn't seem to make sense to preserve > libdb-java (although I expect that it's only necessary to fix the > autoconf check). > > Thanks, > Florian > > ___ 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: Announcement: Aim to remove libdb-java from Fedora-rawhide
The problem is unknown runtime behaviour of libdb-java (build with jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an active user of libdb java ? Thanks, Ondrej On Thu, Jun 11, 2020 at 10:28 PM Florian Weimer wrote: > * Ondrej Dubaj: > > > we are aiming to remove libdb-java package from Fedora-rawhide, as we > > are currently preparing for jdk update from jdk-1.8 to jdk-11 in > > Fedora rawhide. The problem is that we are unable to rebuild this > > package with jdk-11. It is still possible to "hack" it and rebuild it > > with jdk-1.8, but that can cause unexpected runtime behaviour > > according to JVM-11, which will soon be default in Fedora-rawhide. > > Out of curiosity, what is the exact problem? > > Thanks, > Florian > > ___ 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
Announcement: Aim to remove libdb-java from Fedora-rawhide
Hello everyone, we are aiming to remove libdb-java package from Fedora-rawhide, as we are currently preparing for jdk update from jdk-1.8 to jdk-11 in Fedora rawhide. The problem is that we are unable to rebuild this package with jdk-11. It is still possible to "hack" it and rebuild it with jdk-1.8, but that can cause unexpected runtime behaviour according to JVM-11, which will soon be default in Fedora-rawhide. There seems to be no packages, which depend directly to libdb-java and upstream does not support version 5.3.28 anymore. If anyone has any reasons why this should not be made, or someone is currently active user of this JDBC connector, please leave a comment with your opinion in the tracker [1] mentioned below. There is also an existing tracker for deprecating libdb in Fedora [2], so this can be understand as a first step. Additional info about jdk-11 here [3]. Best regards, Ondrej Dubaj Associate Software Engineer Red Hat [1] https://bugzilla.redhat.com/show_bug.cgi?id=1846398 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1834842 [3] https://fedoraproject.org/wiki/Changes/Java11#Intermediate_step_build_with_java-1.8.0-openjdk-devel_and_run_with_java_.28that_means_any_sytem_java.2C_eg_java-11-openjdk.29 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Announcement: Aim to remove libdb-java from Fedora-rawhide
Hello everyone, we are aiming to remove libdb-java package from Fedora-rawhide, as we are currently preparing for jdk update from jdk-1.8 to jdk-11 in Fedora rawhide. The problem is that we are unable to rebuild this package with jdk-11. It is still possible to "hack" it and rebuild it with jdk-1.8, but that can cause unexpected runtime behaviour according to JVM-11, which will soon be default in Fedora-rawhide. There seems to be no packages, which depend directly to libdb-java and upstream does not support version 5.3.28 anymore. If anyone has any reasons why this should not be made, or someone is currently active user of this JDBC connector, please leave a comment with your opinion in the tracker [1] mentioned below. There is also an existing tracker for deprecating libdb in Fedora [2], so this can be understand as a first step. Additional info about jdk-11 here [3]. Best regards, Ondrej Dubaj Associate Software Engineer Red Hat [1] https://bugzilla.redhat.com/show_bug.cgi?id=1846398 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1834842 [3] https://fedoraproject.org/wiki/Changes/Java11#Intermediate_step_build_with_java-1.8.0-openjdk-devel_and_run_with_java_.28that_means_any_sytem_java.2C_eg_java-11-openjdk.29 ___ 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: 500 packages FTBFS in rawhide with java-11-openjdk as system JDK
Hi, after discussion with upstream mysql-connector-java is not able to be build with jdk-11, as the code contains deprecated API. Reference here: https://bugs.mysql.com/bug.php?id=99750 Best regards, Ondrej On Tue, Jun 9, 2020 at 6:42 PM Jiri Vanek wrote: > On 6/9/20 5:07 PM, Fabio Valentini wrote: > > On Tue, Jun 9, 2020 at 4:52 PM Fabio Valentini > wrote: > >> > >> On Tue, Jun 9, 2020 at 4:05 PM Jiri Vanek wrote: > >>> Please see > >>> > https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions > >>> Please fix your packages according to > >>> https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild > >>> Inidivdual packagers are being emailed with details > >> > >> I've asked mizdebsk whether he thinks we can switch to using > >> xmvn-javadoc, which solves the majority of those build failures (over > >> half, by my count). > >> I also sent this proposal to the devel and java-devel mailing lists, > >> and there was no opposition to the change. > >> > >> For other failures, I've begun to track "EasyFix" solutions (mostly, > >> overriding -source 1.8 and -target 1.8, as suggested in the Change > >> proposal), and I've started to either push this change directly (for > >> packages I am associated with), or filing Pull Requests for them: > >> https://pagure.io/java-maint-sig/issue/1 > >> > >> However, I am only one man, with only so much time, so without help, > >> this "applying EasyFixes" will still take a while. > >> > >> With both changes (switching from maven-javadoc-plugin to > >> xmvn-javadoc, and applying the -source / -target 1.8 EasyFixes), the > >> number of build failures should be lower than 100, not over 500. > >> That's still a big number of broken packages, but it's *much* more > manageable. > > I had missed any coordinated effort to mass fix to the packages via > -source / -target 1.8 and > --xmvn-javadoc. If this is happening, I will happily stop spamming, and > will try to keep myself in loop. > > > > Can you also please stop pushing changes to packages without > > coordinating with either the Java SIG or the Stewardship SIG (in one > > case, even by abusing provenpackager rights to push directly to a > > PR-only package)? > > I should be pushing only where I'm co/maintainer. > > > > Both beust-jcommander (*with tests*) and google-gson build fine with > > xmvn-javadoc, yes, but both your commits wouldn't be necessary if > > we're going ahead with switching to xmvn-javadoc by default, as I > > suggested *2 weeks ago*: > > I know. And I'm using --xmvn-javadoc where possble now. And had listedit > also on the know fixes page. > > > > > https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-44930 > > > https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/thread/UD7Q5DYAWI7YO4VW7UZPDWR644V7S462/ > > > > Fabio > > > > > -- > Jiri Vanek > Senior QE engineer, OpenJDK QE lead, Mgr. > Red Hat Czech > jva...@redhat.comM: +420775390109 > ___ > 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
Announcement: taking over classloader-leak-test-framework
Hi, announcing taking over classloader-leak-test-framework, as it is needed by postgresql-jdbc., which I am maintainer of. Best regards, Ondrej Dubaj ___ 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
Orphaning hibernate
Hi everyone, I am orphaning hibernate, as I do not maintain any package, which depends on it. Will anyone of you consider becoming a new main maintainer? Thanks. Regards, Ondrej ___ 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
Orphaning infinispan from fedora
Hi all!. I orphaned infinispan package from fedora. Anyone of you guys know a reason why it shouldn't be orphaned? It is orphaned because no major packages depend on infinispan and it is also not in RHEL anymore (as I am RedHatter). If you do want to leave it in Fedora, will anyone of you became main admin? Thanks for answers! Ondrej Dubaj ___ 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
