Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 29/05/2022 02:57, Gerald Henriksen wrote: There is no indication that the JDK is such a thing - in fact given the packagers are struggling that is a good indication that the JDK is being regularly updated. Every 3 months in a patch release. I don't think maintainers will manually backport patches to the bundled libraries. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Sun, May 29, 2022 at 2:57 AM Gerald Henriksen wrote: > > On Sat, 28 May 2022 20:52:51 +0200, you wrote: > > >On 28/05/2022 19:31, drago01 wrote: > >> That's incorrect. They can be outdated, but there is no inherit reason > >> why they have to be. > > > >Most upstreams don't care about bundled libraries. They bundle them once > >and then forget. > > But most != all as you claimed. > > There is no indication that the JDK is such a thing - in fact given > the packagers are struggling that is a good indication that the JDK is > being regularly updated. It could also imply the opposite (that is, the bundled libraries are *not* being updated), if TCK failures are occurring simply because we're dynamically linking those libraries. -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Sat, 28 May 2022 20:52:51 +0200, you wrote: >On 28/05/2022 19:31, drago01 wrote: >> That's incorrect. They can be outdated, but there is no inherit reason >> why they have to be. > >Most upstreams don't care about bundled libraries. They bundle them once >and then forget. But most != all as you claimed. There is no indication that the JDK is such a thing - in fact given the packagers are struggling that is a good indication that the JDK is being regularly updated. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Sat, May 28, 2022 at 2:53 PM Vitaly Zaitsev via devel wrote: > > On 28/05/2022 19:31, drago01 wrote: > > That's incorrect. They can be outdated, but there is no inherit reason > > why they have to be. > > Most upstreams don't care about bundled libraries. They bundle them once > and then forget. Internally bundled libraries are an issue. I deal with it in the Samba backports, enabling the Heimdal kerberos rather than Fedora and RHEL built-in MIT Kerberos for better support from the Samba project. The python s3transfer includes internal modules, as do the latest ansible-core packages, and subversion has been a nightmare with SQLite and other internal library dependencies on various platforms. It can be quite difficult to keep them up to date. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 28/05/2022 19:31, drago01 wrote: That's incorrect. They can be outdated, but there is no inherit reason why they have to be. Most upstreams don't care about bundled libraries. They bundle them once and then forget. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Friday, May 27, 2022, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 26/05/2022 19:31, drago01 wrote: > >> But bundled libs and properly tested / certified vs dynamic linking and >> less testing / no certification. >> > > Bundled libraries are always outdated and even vulnerable. We should avoid > bundling as much as possible. > > That's incorrect. They can be outdated, but there is no inherit reason why they have to be. > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org > /en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.or > g/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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
> Am 27.05.2022 um 17:37 schrieb Vitaly Zaitsev via devel > : > > On 27/05/2022 15:30, Peter Boy wrote: >> Really sorry, but such a statement is simply intellectual bullshit. >> Unfortunately, it is not possible to formulate this in a more friendly yet >> unambiguous way. And in this thread in particular, the many allegations, >> unclouded by any expertise but made all the more decisively, are simply >> annoying - and a huge waste of everyone’s time in the long run. > > But it's true. > > One of my packages had a bundled library with 6 critical vulnerabilities > (outdated for 5 years). The upstream developers said they didn't care because > they needed their app to run under Ubuntu 12.04 LTS. Fixed it manually by > switching to the packaged version. > > Another package had bundled OpenSSL, which was 3 years out of date. Yes, but your examples and experiences are not related to a lib bundled or not, but it is about the effort a maintainer puts in their package. We had also (unbundled) libs, which were outdated and we had to wait a long time until a vulnerability was fixed. And given the high quality of our openjdk packages and given experiences of the last nearly 2 decades with the regularity of updates, I’m sure we get an openjdk update as soon as an issue with one of the bundled libs arises. And as an afterthought: Sorry for the wording. I was (and I am) seriously annoyed by this thread (and some others of that kind). We have had such excellent Java JDKs for years and right now in the last 4 major JDK versions in parallel, that is just great! It is allowing any developer to test their software in a comprehensive and enterprise ready manner. This deserves unrestricted respect and not this nagging about problems that are claimed but do not exist. If someone is not so well versed in Java universe, no problem. Everyone is welcome to ask questions, but not to throw any wild assertions into the room. Thanks Peter -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 27/05/2022 15:30, Peter Boy wrote: Really sorry, but such a statement is simply intellectual bullshit. Unfortunately, it is not possible to formulate this in a more friendly yet unambiguous way. And in this thread in particular, the many allegations, unclouded by any expertise but made all the more decisively, are simply annoying - and a huge waste of everyone’s time in the long run. But it's true. One of my packages had a bundled library with 6 critical vulnerabilities (outdated for 5 years). The upstream developers said they didn't care because they needed their app to run under Ubuntu 12.04 LTS. Fixed it manually by switching to the packaged version. Another package had bundled OpenSSL, which was 3 years out of date. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
> Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel > : > > Bundled libraries are always outdated and even vulnerable. Really sorry, but such a statement is simply intellectual bullshit. Unfortunately, it is not possible to formulate this in a more friendly yet unambiguous way. And in this thread in particular, the many allegations, unclouded by any expertise but made all the more decisively, are simply annoying - and a huge waste of everyone’s time in the long run. With technically correct workflow, there is at least a time x where the included libs are not outdated and where vulnerability is unknown at worst. How someone comes up with "always" is beyond me. And whether to include a lib in a package is a tradeoff between various pros and cons. Depending on the circumstances, the result is different. The Change proposal correctly includes several reasons for consideration. And no viable argument has yet been put forward as to why the consideration given is *necessarily* incorrect. Several conceivable alternatives would also be viable. But as long as no one is directly affected in a negative way and no one comes forward to do the work involved with an alternative, -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
> Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel > : > > Bundled libraries are always outdated and even vulnerable. Really sorry, but such a statement is simply intellectual bullshit. Unfortunately, it is not possible to formulate this in a more friendly yet unambiguous way. And in this thread in particular, the many allegations, unclouded by any expertise but made all the more decisively, are simply annoying - and a huge waste of everyone’s time in the long run. With technically correct workflow, there is at least a time x where the included libs are not outdated and where vulnerability is unknown at worst. How someone comes up with "always" is beyond me. And whether to include a lib in a package is a tradeoff between various pros and cons. Depending on the circumstances, the result is different. The Change proposal correctly includes several reasons for consideration. And no viable argument has yet been put forward as to why the consideration given is *necessarily* incorrect. Several conceivable alternatives would also be viable. But as long as no one is directly affected in a negative way and no one comes forward to do the work involved with an alternative, -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 20:29, Stephen Snow wrote: Libraries are bundled into jars not the source, etc... this all snowballs across what 4 version now supported? OpenJDK is a native ELF binary, not a JAR. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 19:31, drago01 wrote: But bundled libs and properly tested / certified vs dynamic linking and less testing / no certification. Bundled libraries are always outdated and even vulnerable. We should avoid bundling as much as possible. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 17:40, drago01 wrote: Why would we do that? Is the build process really more important than shipping tested software? Yes. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 14:17, Stephen Snow wrote: Also, it may be good to take a look at what AdoptOpenJDK is doing with the Eclipse Foundation based Adoptium Project, specifically the Eclipse Temurin subproject https://projects.eclipse.org/proposals/eclipse-temurin-compliance which is going to handle the compliance requirements. In this scenerio the Eclipse Foundation is the license holder and the Adoptium project submits to the Temurin project to get certified. Maybe Fedora could use something similar with RH, who are signatories on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project. Just another thought on it. That is just correct summary. That is exactly what wea re doing. We certify with RH signatories. J. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 12:31, drago01 wrote: I am not talking about FLOSS vs non FLOSS, that's obvious. But bundled libs and properly tested / certified vs dynamic linking and less testing / no certification. But if OpenJDK-based binaries can't be distributed without passing the TCK, then it isn't really FLOSS. -- Google Where SkyNet meets Idiocracy ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Thu, 2022-05-26 at 14:07 -0400, Solomon Peachy wrote: > On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote: > > I am not talking about FLOSS vs non FLOSS, that's obvious. But > > bundled libs > > and properly tested / certified vs dynamic linking and less testing > > / no > > certification. > > I've been following this circular thread from the outset (And I do > make > use of Fedora's JDK packages), but one thing I don't recall seeing is > a > specific (or even general) example of the sort of failures/problems > that > have come from linking against system libraries vs just using the > bundled ones. > > Relatedly, I think it would also be very valuable to know if these > problems are mostly one-off (eg a major release of the jdk or > dependent > library lands in rawhide and breakage ensues), or occur throughout a > specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a > critical > security update which leads to a failure to pass TCK, or quarterly > java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to > fedora's > bundled library libfoo version) > I don't think that was the gist of it. I believe that it relates to the numbers of OpenJDK we carry, and the difficulty faced by the packagers of that to comply with packaging in Fedora's ecosystem when doing it. Libraries are bundled into jars not the source, etc... this all snowballs across what 4 version now supported? I don't remeber reading about unspecified TCK failures, just the workload as a result of our packaging requirements. > I mean, it's been strongly implied (if not outright stated) that > resolving these unspecified TCK failures, caused by using non-bundled > libraries, is the real burden, not the act of running the TCK for > each > build -- but is the TCK (or upstream JDK) really that _brittle_? > I built Netbeans for F36 Silverblue and when building it from source, it still uses maven repo to download binary tools (maven plugin's) to build with, this would be in violation of the packaging guidelines I think. So to package it I would need to also package all of those plugin's along side to support it in the Fedora Project ecosystem, just for the actual build process. Regards, Stephen Snow > - Solomon > ___ > 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
So my take on the TCK is that Red Hat signed the OCTLA and Fedora Community get's to test their OpenJDK against it as a subequence. I didn't think Fedora the project, had any legal except what Red Hat provides, maybe I'm mistaken though so someone should clarify if they know for sure. Not only that, if we (Fedora Project) were the signatories, we would need auditing internally and externally to comply with requirements of the OCTLA from what I understand, which I imagine we do not have, nor want to entertain since it would require significant dedicated support likely. Basically anytime you use the TCK you need the paper trail. I still think the original proposal has some merrit at least of raisng the point of the workload required to maintain Fedora Lunix's java development stack. A rethink here would be good overall and really the technical build issues Jiri Vanik presented need to be overcome and should be the projects focus, not legal. Perhaps Fedora Project lead could discuss this with RH legal to get their perspective. I'm sure they're aware of the arrangement as it has been used by Fedora, and Fedora is not listed as signatory, and someone had to sign the agreement to get the TCK in the first place. >From that POV, to me as OpenJDK is still GPL3 released, and Fedora Project get's to use Red Hat's TCK to verify certification of compliance, so win win. Red Hat needs it for their own OpenJDK, which we no doubt have some involvement with, so again win win. Regards, Stephen Snow On Thu, 2022-05-26 at 11:38 -0400, Stephen Smoogen wrote: > > > On Thu, 26 May 2022 at 11:32, Kevin P. Fleming > wrote: > > On 5/26/22 11:06, Stephen Smoogen wrote: > > > 2. Are there ways that a non-TCK compliant version could be > > distributed? > > > > I would suggest phrasing that slightly differently: the version > > being > > distributed could very well be fully compliant (would pass the TCK > > if > > tested), but may not have been tested. > > > > > > > Yes, that goes into the my misunderstanding of what TCK is. Some > systems can only say they are 'compliant' if they are 'certified' and > anything else is 'fraudulent'. Others allow for 'complaint' and > 'certified' to be different. > > In either case, I should have clarified with 'certified'. > > > -- > > Kevin P. Fleming > > He/Him/His > > Principal Program Manager, RHEL > > Red Hat US/Eastern Time Zone > > ___ > > 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 ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote: > I am not talking about FLOSS vs non FLOSS, that's obvious. But bundled libs > and properly tested / certified vs dynamic linking and less testing / no > certification. I've been following this circular thread from the outset (And I do make use of Fedora's JDK packages), but one thing I don't recall seeing is a specific (or even general) example of the sort of failures/problems that have come from linking against system libraries vs just using the bundled ones. Relatedly, I think it would also be very valuable to know if these problems are mostly one-off (eg a major release of the jdk or dependent library lands in rawhide and breakage ensues), or occur throughout a specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a critical security update which leads to a failure to pass TCK, or quarterly java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to fedora's bundled library libfoo version) I mean, it's been strongly implied (if not outright stated) that resolving these unspecified TCK failures, caused by using non-bundled libraries, is the real burden, not the act of running the TCK for each build -- but is the TCK (or upstream JDK) really that _brittle_? - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (libra.chat) signature.asc Description: PGP signature ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Thursday, May 26, 2022, Ian Pilcher wrote: > On 5/26/22 10:40, drago01 wrote: > >> Why would we do that? Is the build process really more important than >> shipping tested software? >> > > For Fedora? Yes. > > Fedora includes lots of untested (in the formal, TCK sense) software. > It does not include non-FLOSS software (except maybe in very specific > circumstances such as firmware). I am not talking about FLOSS vs non FLOSS, that's obvious. But bundled libs and properly tested / certified vs dynamic linking and less testing / no certification. > > -- > > Google Where SkyNet meets Idiocracy > > ___ > 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.or > g/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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 10:40, drago01 wrote: Why would we do that? Is the build process really more important than shipping tested software? For Fedora? Yes. Fedora includes lots of untested (in the formal, TCK sense) software. It does not include non-FLOSS software (except maybe in very specific circumstances such as firmware). -- Google Where SkyNet meets Idiocracy ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Thursday, May 26, 2022, Kevin P. Fleming wrote: > On 5/26/22 11:06, Stephen Smoogen wrote: > >> 2. Are there ways that a non-TCK compliant version could be distributed? >> > > I would suggest phrasing that slightly differently: the version being > distributed could very well be fully compliant (would pass the TCK if > tested), but may not have been tested. > > Why would we do that? Is the build process really more important than shipping tested software? > -- > Kevin P. Fleming > He/Him/His > Principal Program Manager, RHEL > Red Hat US/Eastern Time Zone > ___ > 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.or > g/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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Thu, 26 May 2022 at 11:32, Kevin P. Fleming wrote: > On 5/26/22 11:06, Stephen Smoogen wrote: > > 2. Are there ways that a non-TCK compliant version could be distributed? > > I would suggest phrasing that slightly differently: the version being > distributed could very well be fully compliant (would pass the TCK if > tested), but may not have been tested. > > Yes, that goes into the my misunderstanding of what TCK is. Some systems can only say they are 'compliant' if they are 'certified' and anything else is 'fraudulent'. Others allow for 'complaint' and 'certified' to be different. In either case, I should have clarified with 'certified'. > -- > Kevin P. Fleming > He/Him/His > Principal Program Manager, RHEL > Red Hat US/Eastern Time Zone > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 11:06, Stephen Smoogen wrote: 2. Are there ways that a non-TCK compliant version could be distributed? I would suggest phrasing that slightly differently: the version being distributed could very well be fully compliant (would pass the TCK if tested), but may not have been tested. -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Thu, 26 May 2022 at 08:19, Stephen Snow wrote: > > > On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote: > > On 26/05/2022 00:02, Demi Marie Obenour wrote: > > > IANAL, but I believe APIs are not eligible for > > > trademark protection, so Fedora would only need to change the stuff > > > that is*not* part of the API. > > > > Yes. Google won a lawsuit against Oracle in the Supreme Court. > > > What law suit, and how does it apply to our situation? > > The only lawsuit I know of is https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc. where while Google 'won' parts, many issues have been remanded back to a lower court and are still outstanding. [This means that they could still be interpreted as a win for Oracle on narrower bands.] It is unclear enough that various groups have had different interpretations. That said there are several trademark lawsuits on the usage of 'coffee-themed-languages' which have been posted in the past by Oracle ranging from Starbucks to various smaller software companies. Trademark and copyright sound like they are the same thing but they are different parts of the law and can 'override' one another in different ways. In any case, I think this needs an official review by the Fedora Council: 0. Are the outside requirements on how 'coffee-themed languages' must be published making them non-Free/Open in the way Fedora Project expects things to be? 1. What are the legal concerns that the Fedora Project must do to distribute OpenJDK? 2. Are there ways that a non-TCK compliant version could be distributed? 3. Clearer guidance to the volunteers on how to deal with these requirements. These are deeper issues which I think need to be dealt with before we can even think about the F37 change proposal. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Also, it may be good to take a look at what AdoptOpenJDK is doing with the Eclipse Foundation based Adoptium Project, specifically the Eclipse Temurin subproject https://projects.eclipse.org/proposals/eclipse-temurin-compliance which is going to handle the compliance requirements. In this scenerio the Eclipse Foundation is the license holder and the Adoptium project submits to the Temurin project to get certified. Maybe Fedora could use something similar with RH, who are signatories on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project. Just another thought on it. On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote: > On 26/05/2022 00:02, Demi Marie Obenour wrote: > > IANAL, but I believe APIs are not eligible for > > trademark protection, so Fedora would only need to change the stuff > > that is*not* part of the API. > > Yes. Google won a lawsuit against Oracle in the Supreme Court. > What law suit, and how does it apply to our situation? Regards, Stephen Snow > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
There sure seems to be confusion here around what exactly the TCK or JCK actually is. First off it is not a license. It is however a technical compatability certification which guarantees technical compatability between the different flavours of OpenJDK available out there, like RedHats (https://www.redhat.com/en/resources/build-of-openjdk-datasheet) Who signed the agreement (OTCLA) to get the TCK/JCK obviously The license aspect is found at https://openjdk.java.net/legal/OCTLA-JDK9+.pdf and is the agreement you sign to get access to the certification toolkit. Yes, everyone who distributes a version of OpenJDK does this, and I would think outside of hobby or education purposes, if you develop in Java you want this too. Regards, Stephen Snow On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote: > On 26/05/2022 00:02, Demi Marie Obenour wrote: > > IANAL, but I believe APIs are not eligible for > > trademark protection, so Fedora would only need to change the stuff > > that is*not* part of the API. > > Yes. Google won a lawsuit against Oracle in the Supreme Court. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 00:02, Demi Marie Obenour wrote: IANAL, but I believe APIs are not eligible for trademark protection, so Fedora would only need to change the stuff that is*not* part of the API. Yes. Google won a lawsuit against Oracle in the Supreme Court. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/25/22 13:49, Jiri Vanek wrote: > The rename will really not help. If it is not possible to ship an uncertified version then OpenJDK is not free software and Fedora should not have it at all, in which case the whole discussion is moot. Otherwise, it is possible to ship a compatible version without the trademarks and without TCK certification. IANAL, but I believe APIs are not eligible for trademark protection, so Fedora would only need to change the stuff that is *not* part of the API. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
The rename will really not help. On 5/25/22 18:01, Vitaly Zaitsev via devel wrote: On 25/05/2022 15:03, Jiri Vanek wrote: We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear. Let's rename it to icedtea then. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 25/05/2022 15:34, Jiri Vanek wrote: When we were shipping icedtea6 and later icedtea7, it still required TCK, so iced tea is not an option. Easy fix: java-XX-openjdk -> coffee-named-language-XX. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 25/05/2022 15:03, Jiri Vanek wrote: We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear. Let's rename it to icedtea then. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
BTW, I noticed that despite java-17-openjdk being the default system JDK on Fedora 36, it wasn't installed instead of java-11-openjdk when I upgraded from Fedora 35. That sounds like the change proposal wasn't That sounds like super severe bug. I had tried it manytimes, in testing environemtn with various basic pre-update setups when I was finishing the change, and was ok. When I updated my three personal machnes to f36 al was ok. But I''m afraid here jdk8, jdk11 and jdk17 and jdk18. fully implemented, either? Wouldn't the upgrade approach leave the installed JDK as default? Just asking since I have the default installed on F36 (17) and I also have the latest(18) which I didn't explicitly install. Just asking If we consider the unlikely super basic usecase, wehn you had only jdk17 in f35, then the upgrade to f36 should add jdk 17. So btoh jdk11 and 17 will be there, and jdk17 will become selected. If you have lets say 8 and 11, and you *manually* select 8, then after update there will be 8,11 and 17, and 8 will remain selected. Alternatives honor your selction. The system jdk wil not be affeted byt maual selection of jdk - https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting J. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-25 at 15:40 +0200, Fabio Valentini wrote: > On Wed, May 25, 2022 at 3:17 PM Jiri Vanek wrote: > > > > On 5/24/22 22:02, Fabio Valentini wrote: > > > Is this based on user requests, or is this only what you *think* > > > users > > > > I'm not sure what you mean - from above - what is based on > > mine/wider thinking > > Generally waht I wrote here it is based on judgmeent of about 10 > > people around OpenJDK pacages in Fedora. > > The equations above are based on realistic view and experience. Do > > you yo find some misscalcualtion above? > > > > I really appreciate you opinions, and would be happyt answer more > > precisely. > > Thank you for your response, I appreciate that you're engaging with > feedback here. > > The way I understood your last message, it seemed to me that you were > claiming that actual Fedora users are requesting that you ship so > many > different OpenJDK versions. > However, in this thread, I see the opposite - almost everybody is > asking you to consider dropping support for at least some non-default > OpenJDK versions, and nobody is advocating for keeping all of them. > So > my question was whether you have actual user feedback requesting that > so many different versions are available on Fedora. > > > > of OpenJDK on Fedora need? > > > Speaking for myself, I have never used anything other than the > > > default > > > "system JDK" for running Java applications on Fedora. > > > > Are you really sure? Many applications runtime requiter non system > > jdk, so they pull it in and use, and maybe you have not even > > noticed. > > Many develoeprs ahve installe dmany JDKS (in my case all from > > repos, unless I need to compile jimage) and the switch as needed. > > I'm quite sure, though I'm not using as many Java applications as I > used to. > The Minecraft "Java Edition" has always worked fine with the "system > / > default JDK", so I never needed to install another one. > And the JetBrains IDEs have bundled their own JDK for a while now, I > think, so I don't have to deal with those, either (and I wouldn't > even > want to mess with my main development environment to make it use > something other than the JDK it ships with). > > > > > > > What would you think about the following scenario: > > > > > > - Fedora X defaults to new OpenJDK LTS N > > > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the > > > change > > > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was > > > already > > > the default for one release > > > - do not backport OpenJDK n to Fedora X-1 and X-2 > > > - keep java-latest-openjdk, as you seen to need this for > > > bootstrapping > > > new OpenJDK releases > > > > This is possible solution. It will lower the TCK burden to aprox > > 3/5 with lost of most widely used JDKs from repositories. > > I'm open to this proposal. But the removal will hurt and way back > > will be much harder then swithing static builds back to dynamic. > > > > > > You could even drop java-latest-openjdk from all branches but > > > rawhide, > > > since it's only needed for bootstrapping there. > > > > Taht is very valid point. Cost is it will force huge number of > > uses to download 3rd party latest STS jdk. it is where all new > > features live. > > Are there really that many Fedora users who need and install > java-latest-openjdk? Do you have estimates of how many people do > this, > compared to how many users just use the default system JDK? > > > > This should pretty dramatically reduce the size of your test > > > matrix. > > > Applying the current numbers: > > > > > > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk > > > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case > > > the > > > default needs to be switched back), java-latest-openjdk > > > - Fedora 35: java-11-openjdk, java-latest-openjdk > > > > > > > it is a bit less then I wrote, - about 3/5 of current load but do > > yoreally wish to cut all those jdks from fedora? > > To me the static repacked build sill somehow seems as smaller evil > > then drop practically all interesting jdks out of distro. > > Yeah, why not? I'm asking whether it's actually worth your time to > keep them around. Given that there's probably limited userbase and > the > resources that are needed to keep them around, this is a valid > question, I think. Speaking for myself, I'd rather have the default, > integrated, system JDK be of the high quality it has been in Fedora, > rather than having many different, less-integrated versions around. > > > So here I need to rephrase your question - is it based on your's > > thinking or on what fedora users really needs? > > I think the oposite - they need all jdks which are around. Proeprly > > integrated with system. How they are built .. they do not care. > > If update to neewer Fedora wil lmake some older JDK disapear, or if > > need of new one will force me to update Fedora when I don't want or > > cant. I call it
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 25 May 2022 at 09:34, Jiri Vanek wrote: > > > On 5/25/22 15:19, Stephen Smoogen wrote: > > > > > > On Wed, 25 May 2022 at 09:04, Jiri Vanek jva...@redhat.com>> wrote: > > > > > > > > On 5/24/22 21:41, Vitaly Zaitsev via devel wrote: > > > On 24/05/2022 21:00, Jiri Vanek wrote: > > >> I repeat what was told several times.We really do no t like this > change, especially in its full sound of one static build repacked to all > ive fedoras, but we have nto found a better way. > > > > > > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't > need certified binaries. > > We can not ship uncerified JDK. Sooner or later a swarm of lawyers > would appear. > > > > > > So could it be shipped instead as a icedtea? > > When we were shipping icedtea6 and later icedtea7, it still required TCK, > so iced tea is not an option. > I added bot Andrews to cc, as they remains masters of IcedTea even now, > when it is agesd dead (maybe technically beyond resurrection) > > IIRC, icedtea is set of patches on top of openjdk. So it remains Opendk. > So it reqwuires TCK. Pelase anybody if yo really know, correct me. I'm also > not lawyer. > > Thanx a lot for writting this down > > By icedtea I was assuming a cleanout of trademarks like Firefox and Mozilla is done in Debian. This was not how the previous icedtea was done but it may be what needs to be reviewed. It does require a legal review and that would be something for this team to ask the Board and internal Red Hat to do. If the licenses for how the coffee-themed language requires a TCK no matter what, then I would say that JDK is not open/free in a way that is easily distributable and that would be another thing Fedora board needs to deal with. In either case it is not you or your team's fault here... and people saying so need to back off. > > > > The reason I am asking is that I think we need to look seriously at the > alternatives and see how much work the community is going to need to do. > > 1. Fedora no longer ships a trademarked 'coffee-themed language'. > Instead it adds an external repository where your team is able to focus on > what they can deliver. > > 2. Fedora no longer ships a trademarked 'coffee-themed language'. > Instead, a volunteer driven SIG puts in an icedtea back into into Fedora > instead. > > 3. Fedora no longer ships a trademarked 'coffee-themed language'. > Instead people wanting it will need to find an external place which builds > it. > > 4. Fedora ships a trademarked 'coffee-themed language' that is static. > However this doesn't decrease the workload enough and we need to move to > 1-3 in 2 to 3 years. > > If we exclude Red hat from Openjdk and it will remain purely on community, > and if they will be good enogh to really maintian JDKs fo fedora, I cant > predict impact of Law, when ..someone .. finds it is driven by anonymous > without signed > agreement and without TCK. I realy do not know. > > Thanx!!! > J. > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 25, 2022 at 9:38 AM Jiri Vanek wrote: > > > > On 5/25/22 15:28, Neal Gompa wrote: > > On Wed, May 25, 2022 at 9:17 AM Jiri Vanek wrote: > >> > >> > >> > >> On 5/24/22 22:02, Fabio Valentini wrote: > >>> On Tue, May 24, 2022 at 5:03 PM Jiri Vanek wrote: > I replied it already in that thread, but happy to repeat: > It will help, but less then it seems so. > Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of > jdk8 is in some 4 years, so fedora will suffer a bit. But it will be > nice 12 TCK runs down. > but we can not droop 11, as it is system jdk in f35 > Similarly, we couldn't introduce fresh jdk17 directly to f36 as system > JDK. It needs it time to be tuned before being proposed as system jdk. > And we can not drop java-latest-openjdk, becasue it is necessary to boot > next system JDK. > Yes, in 8 months, we would be able to drop 11. And live for 1 year only > on latest and 17. Which is putting load for one year to 1/2. But the > cost of not having 11 (and 8) will be felt by fedora users more, then > having static jdk from repos. > Unluckily, with new future system jdk, we will need to boostrap it by > latest, keep it as secondary jdk at least for one , better two, fedora > cycles, so again we will be in 3 jdks x 3 systems. > Sure, we do not need to backport newest future system jdk to older > fedoras, but usually the users want us to do so. tbh, I do not have > strong preference on it. it is like 51 for backport, and 49 for not. > Even with knwoledge of TCK burden. > >>> > >>> Is this based on user requests, or is this only what you *think* users > >> > >> I'm not sure what you mean - from above - what is based on mine/wider > >> thinking > >> Generally waht I wrote here it is based on judgmeent of about 10 people > >> around OpenJDK pacages in Fedora. > >> The equations above are based on realistic view and experience. Do you yo > >> find some misscalcualtion above? > >> > >> I really appreciate you opinions, and would be happyt answer more > >> precisely. > >> > >> > >>> of OpenJDK on Fedora need? > >>> Speaking for myself, I have never used anything other than the default > >>> "system JDK" for running Java applications on Fedora. > >> > >> Are you really sure? Many applications runtime requiter non system jdk, > >> so they pull it in and use, and maybe you have not even noticed. > >> Many develoeprs ahve installe dmany JDKS (in my case all from repos, > >> unless I need to compile jimage) and the switch as needed. > >> > >>> > >>> What would you think about the following scenario: > >>> > >>> - Fedora X defaults to new OpenJDK LTS N > >>> - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change > >>> - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already > >>> the default for one release > >>> - do not backport OpenJDK n to Fedora X-1 and X-2 > >>> - keep java-latest-openjdk, as you seen to need this for bootstrapping > >>> new OpenJDK releases > >> > >> This is possible solution. It will lower the TCK burden to aprox 3/5 with > >> lost of most widely used JDKs from repositories. > >> I'm open to this proposal. But the removal will hurt and way back will be > >> much harder then swithing static builds back to dynamic. > >>> > >>> You could even drop java-latest-openjdk from all branches but rawhide, > >>> since it's only needed for bootstrapping there. > >> > >> Taht is very valid point. Cost is it will force huge number of uses to > >> download 3rd party latest STS jdk. it is where all new features live. > >>> This should pretty dramatically reduce the size of your test matrix. > >>> Applying the current numbers: > >>> > >>> - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk > >>> - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the > >>> default needs to be switched back), java-latest-openjdk > >>> - Fedora 35: java-11-openjdk, java-latest-openjdk > >>> > >> > >> it is a bit less then I wrote, - about 3/5 of current load but do yoreally > >> wish to cut all those jdks from fedora? > >> To me the static repacked build sill somehow seems as smaller evil then > >> drop practically all interesting jdks out of distro. > >> > >> So here I need to rephrase your question - is it based on your's thinking > >> or on what fedora users really needs? > >> I think the oposite - they need all jdks which are around. Proeprly > >> integrated with system. How they are built .. they do not care. > >> If update to neewer Fedora wil lmake some older JDK disapear, or if need > >> of new one will force me to update Fedora when I don't want or cant. I > >> call it much worse user expereince > >> > > > > What about only making the older JDKs use bundled static libraries, > > and the latest LTS and STS versions continue to use dynamic? That > > would significantly cut down TCK versions and allow
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 25, 2022 at 3:17 PM Jiri Vanek wrote: > > On 5/24/22 22:02, Fabio Valentini wrote: > > Is this based on user requests, or is this only what you *think* users > > I'm not sure what you mean - from above - what is based on mine/wider > thinking > Generally waht I wrote here it is based on judgmeent of about 10 people > around OpenJDK pacages in Fedora. > The equations above are based on realistic view and experience. Do you yo > find some misscalcualtion above? > > I really appreciate you opinions, and would be happyt answer more precisely. Thank you for your response, I appreciate that you're engaging with feedback here. The way I understood your last message, it seemed to me that you were claiming that actual Fedora users are requesting that you ship so many different OpenJDK versions. However, in this thread, I see the opposite - almost everybody is asking you to consider dropping support for at least some non-default OpenJDK versions, and nobody is advocating for keeping all of them. So my question was whether you have actual user feedback requesting that so many different versions are available on Fedora. > > of OpenJDK on Fedora need? > > Speaking for myself, I have never used anything other than the default > > "system JDK" for running Java applications on Fedora. > > Are you really sure? Many applications runtime requiter non system jdk, so > they pull it in and use, and maybe you have not even noticed. > Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I > need to compile jimage) and the switch as needed. I'm quite sure, though I'm not using as many Java applications as I used to. The Minecraft "Java Edition" has always worked fine with the "system / default JDK", so I never needed to install another one. And the JetBrains IDEs have bundled their own JDK for a while now, I think, so I don't have to deal with those, either (and I wouldn't even want to mess with my main development environment to make it use something other than the JDK it ships with). > > > > What would you think about the following scenario: > > > > - Fedora X defaults to new OpenJDK LTS N > > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change > > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already > > the default for one release > > - do not backport OpenJDK n to Fedora X-1 and X-2 > > - keep java-latest-openjdk, as you seen to need this for bootstrapping > > new OpenJDK releases > > This is possible solution. It will lower the TCK burden to aprox 3/5 with > lost of most widely used JDKs from repositories. > I'm open to this proposal. But the removal will hurt and way back will be > much harder then swithing static builds back to dynamic. > > > > You could even drop java-latest-openjdk from all branches but rawhide, > > since it's only needed for bootstrapping there. > > Taht is very valid point. Cost is it will force huge number of uses to > download 3rd party latest STS jdk. it is where all new features live. Are there really that many Fedora users who need and install java-latest-openjdk? Do you have estimates of how many people do this, compared to how many users just use the default system JDK? > > This should pretty dramatically reduce the size of your test matrix. > > Applying the current numbers: > > > > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk > > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the > > default needs to be switched back), java-latest-openjdk > > - Fedora 35: java-11-openjdk, java-latest-openjdk > > > > it is a bit less then I wrote, - about 3/5 of current load but do yoreally > wish to cut all those jdks from fedora? > To me the static repacked build sill somehow seems as smaller evil then drop > practically all interesting jdks out of distro. Yeah, why not? I'm asking whether it's actually worth your time to keep them around. Given that there's probably limited userbase and the resources that are needed to keep them around, this is a valid question, I think. Speaking for myself, I'd rather have the default, integrated, system JDK be of the high quality it has been in Fedora, rather than having many different, less-integrated versions around. > So here I need to rephrase your question - is it based on your's thinking or > on what fedora users really needs? > I think the oposite - they need all jdks which are around. Proeprly > integrated with system. How they are built .. they do not care. > If update to neewer Fedora wil lmake some older JDK disapear, or if need of > new one will force me to update Fedora when I don't want or cant. I call it > much worse user expereince Well, isn't that the point? BTW, I noticed that despite java-17-openjdk being the default system JDK on Fedora 36, it wasn't installed instead of java-11-openjdk when I upgraded from Fedora 35. That sounds like the change proposal wasn't fully implemented, either? Fabio
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/25/22 15:28, Neal Gompa wrote: On Wed, May 25, 2022 at 9:17 AM Jiri Vanek wrote: On 5/24/22 22:02, Fabio Valentini wrote: On Tue, May 24, 2022 at 5:03 PM Jiri Vanek wrote: I replied it already in that thread, but happy to repeat: It will help, but less then it seems so. Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down. but we can not droop 11, as it is system jdk in f35 Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs it time to be tuned before being proposed as system jdk. And we can not drop java-latest-openjdk, becasue it is necessary to boot next system JDK. Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be felt by fedora users more, then having static jdk from repos. Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as secondary jdk at least for one , better two, fedora cycles, so again we will be in 3 jdks x 3 systems. Sure, we do not need to backport newest future system jdk to older fedoras, but usually the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden. Is this based on user requests, or is this only what you *think* users I'm not sure what you mean - from above - what is based on mine/wider thinking Generally waht I wrote here it is based on judgmeent of about 10 people around OpenJDK pacages in Fedora. The equations above are based on realistic view and experience. Do you yo find some misscalcualtion above? I really appreciate you opinions, and would be happyt answer more precisely. of OpenJDK on Fedora need? Speaking for myself, I have never used anything other than the default "system JDK" for running Java applications on Fedora. Are you really sure? Many applications runtime requiter non system jdk, so they pull it in and use, and maybe you have not even noticed. Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I need to compile jimage) and the switch as needed. What would you think about the following scenario: - Fedora X defaults to new OpenJDK LTS N - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already the default for one release - do not backport OpenJDK n to Fedora X-1 and X-2 - keep java-latest-openjdk, as you seen to need this for bootstrapping new OpenJDK releases This is possible solution. It will lower the TCK burden to aprox 3/5 with lost of most widely used JDKs from repositories. I'm open to this proposal. But the removal will hurt and way back will be much harder then swithing static builds back to dynamic. You could even drop java-latest-openjdk from all branches but rawhide, since it's only needed for bootstrapping there. Taht is very valid point. Cost is it will force huge number of uses to download 3rd party latest STS jdk. it is where all new features live. This should pretty dramatically reduce the size of your test matrix. Applying the current numbers: - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the default needs to be switched back), java-latest-openjdk - Fedora 35: java-11-openjdk, java-latest-openjdk it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish to cut all those jdks from fedora? To me the static repacked build sill somehow seems as smaller evil then drop practically all interesting jdks out of distro. So here I need to rephrase your question - is it based on your's thinking or on what fedora users really needs? I think the oposite - they need all jdks which are around. Proeprly integrated with system. How they are built .. they do not care. If update to neewer Fedora wil lmake some older JDK disapear, or if need of new one will force me to update Fedora when I don't want or cant. I call it much worse user expereince What about only making the older JDKs use bundled static libraries, and the latest LTS and STS versions continue to use dynamic? That would significantly cut down TCK versions and allow you to focus dynamic support where it matters (latest Java runtime code). Quite a fresh thinking! What about all jdks except system one being static (and repacked), but the system one dynamic. That can go below 1/2 of QA runs, without any cut of jdks in fedora. There exists Quite a high risk, that the system jdk will trasnfer form static to dynamic in some point (or oposite), and that will lead to unknown new issues prety late in lifecycle. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-25 at 15:03 +0200, Jiri Vanek wrote: > > > On 5/24/22 21:41, Vitaly Zaitsev via devel wrote: > > On 24/05/2022 21:00, Jiri Vanek wrote: > > > I repeat what was told several times.We really do no t like this > > > change, especially in its full sound of one static build repacked > > > to all ive fedoras, but we have nto found a better way. > > > > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't > > need certified binaries. > We can not ship uncerified JDK. Sooner or later a swarm of lawyers > would appear. > 100%, though I am not one, I understand as much from the TCK itslef. > > All they need is a working and well packaged OpenJDK. > > > > From point of view of JDK, the jdk will remain working. From point > of JDK and generric java world the jdk will be even better. > From view of distributions standarts it will become weird misshape. > Serving it purpose in build root well, serving as system or > distribution jdk well. But yeah... all was said on this toppic > already:( > As a user of the JDK as Fedora Linux currently ships it, I can say I am very grateful for the efforts being made to accomodate it. > > 2. Reduce the number of OpenJDK branches in the repositories. I > > think the latest LTS version will be enough. > I have also suggested this, but in historical context JDK 6 hung around about 10 years longer than expected I think due in large part to the inertia built by it's prolific use in enterprise systems. This will undoubtably hold true for JDK 8 as well, since it is currently the preferred choice by most. Technically speaking WRT JDK releases, some fall by the wayside (jdk 9 and jdk 10 are two recent). > I wish it is so simple. Please see my reply to Kevin when I > enumerated, that we can not keep "jsut latest" lts. > > > Regards, Stephen Snow just some dude who can program ... whatever > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/25/22 15:19, Stephen Smoogen wrote: On Wed, 25 May 2022 at 09:04, Jiri Vanek mailto:jva...@redhat.com>> wrote: On 5/24/22 21:41, Vitaly Zaitsev via devel wrote: > On 24/05/2022 21:00, Jiri Vanek wrote: >> I repeat what was told several times.We really do no t like this change, especially in its full sound of one static build repacked to all ive fedoras, but we have nto found a better way. > > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need certified binaries. We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear. So could it be shipped instead as a icedtea? When we were shipping icedtea6 and later icedtea7, it still required TCK, so iced tea is not an option. I added bot Andrews to cc, as they remains masters of IcedTea even now, when it is agesd dead (maybe technically beyond resurrection) IIRC, icedtea is set of patches on top of openjdk. So it remains Opendk. So it reqwuires TCK. Pelase anybody if yo really know, correct me. I'm also not lawyer. Thanx a lot for writting this down The reason I am asking is that I think we need to look seriously at the alternatives and see how much work the community is going to need to do. 1. Fedora no longer ships a trademarked 'coffee-themed language'. Instead it adds an external repository where your team is able to focus on what they can deliver. 2. Fedora no longer ships a trademarked 'coffee-themed language'. Instead, a volunteer driven SIG puts in an icedtea back into into Fedora instead. 3. Fedora no longer ships a trademarked 'coffee-themed language'. Instead people wanting it will need to find an external place which builds it. 4. Fedora ships a trademarked 'coffee-themed language' that is static. However this doesn't decrease the workload enough and we need to move to 1-3 in 2 to 3 years. If we exclude Red hat from Openjdk and it will remain purely on community, and if they will be good enogh to really maintian JDKs fo fedora, I cant predict impact of Law, when ..someone .. finds it is driven by anonymous without signed agreement and without TCK. I realy do not know. Thanx!!! J. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 25, 2022 at 9:17 AM Jiri Vanek wrote: > > > > On 5/24/22 22:02, Fabio Valentini wrote: > > On Tue, May 24, 2022 at 5:03 PM Jiri Vanek wrote: > >> I replied it already in that thread, but happy to repeat: > >> It will help, but less then it seems so. > >> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of > >> jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice > >> 12 TCK runs down. > >> but we can not droop 11, as it is system jdk in f35 > >> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system > >> JDK. It needs it time to be tuned before being proposed as system jdk. > >> And we can not drop java-latest-openjdk, becasue it is necessary to boot > >> next system JDK. > >> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on > >> latest and 17. Which is putting load for one year to 1/2. But the cost of > >> not having 11 (and 8) will be felt by fedora users more, then having > >> static jdk from repos. > >> Unluckily, with new future system jdk, we will need to boostrap it by > >> latest, keep it as secondary jdk at least for one , better two, fedora > >> cycles, so again we will be in 3 jdks x 3 systems. > >> Sure, we do not need to backport newest future system jdk to older > >> fedoras, but usually the users want us to do so. tbh, I do not have strong > >> preference on it. it is like 51 for backport, and 49 for not. Even with > >> knwoledge of TCK burden. > > > > Is this based on user requests, or is this only what you *think* users > > I'm not sure what you mean - from above - what is based on mine/wider > thinking > Generally waht I wrote here it is based on judgmeent of about 10 people > around OpenJDK pacages in Fedora. > The equations above are based on realistic view and experience. Do you yo > find some misscalcualtion above? > > I really appreciate you opinions, and would be happyt answer more precisely. > > > > of OpenJDK on Fedora need? > > Speaking for myself, I have never used anything other than the default > > "system JDK" for running Java applications on Fedora. > > Are you really sure? Many applications runtime requiter non system jdk, so > they pull it in and use, and maybe you have not even noticed. > Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I > need to compile jimage) and the switch as needed. > > > > > What would you think about the following scenario: > > > > - Fedora X defaults to new OpenJDK LTS N > > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change > > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already > > the default for one release > > - do not backport OpenJDK n to Fedora X-1 and X-2 > > - keep java-latest-openjdk, as you seen to need this for bootstrapping > > new OpenJDK releases > > This is possible solution. It will lower the TCK burden to aprox 3/5 with > lost of most widely used JDKs from repositories. > I'm open to this proposal. But the removal will hurt and way back will be > much harder then swithing static builds back to dynamic. > > > > You could even drop java-latest-openjdk from all branches but rawhide, > > since it's only needed for bootstrapping there. > > Taht is very valid point. Cost is it will force huge number of uses to > download 3rd party latest STS jdk. it is where all new features live. > > This should pretty dramatically reduce the size of your test matrix. > > Applying the current numbers: > > > > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk > > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the > > default needs to be switched back), java-latest-openjdk > > - Fedora 35: java-11-openjdk, java-latest-openjdk > > > > it is a bit less then I wrote, - about 3/5 of current load but do yoreally > wish to cut all those jdks from fedora? > To me the static repacked build sill somehow seems as smaller evil then drop > practically all interesting jdks out of distro. > > So here I need to rephrase your question - is it based on your's thinking or > on what fedora users really needs? > I think the oposite - they need all jdks which are around. Proeprly > integrated with system. How they are built .. they do not care. > If update to neewer Fedora wil lmake some older JDK disapear, or if need of > new one will force me to update Fedora when I don't want or cant. I call it > much worse user expereince > What about only making the older JDKs use bundled static libraries, and the latest LTS and STS versions continue to use dynamic? That would significantly cut down TCK versions and allow you to focus dynamic support where it matters (latest Java runtime code). -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 22:14, Kevin Fenzi wrote: On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote: We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so we have to. But that is much easier, as the usptream is static within intree libraries. And we have to run also for 17 and 18/19 as we need this reference run, to be sure that downstream is guilty, not vanilla jdk. Thus we test the (source x build) just once. And we can test the binary on some known system where we always pass. Well, I meant test the _dynamic_ build that Fedora does now... Yy , I got that. What made you think I did not? But in downstream, new issues usually appear due to the dynamic linking and nature of system where only it can be installed. Also for dowstram, each sources are built N times, so N times tested in thsoe N systems - usually each with its psecific failures. Could we integrate the TCK testing in our CI to save you overhead of managing submitting, etc? Or where is the most time spent in this workflow? As I described in another reply, it is both human and hw. Hw to run all those swarm of builds on all platforms, and humans to verify the issue and to fix it. TCK are very complex, and you need at least three machines in distributed system to run them. At least two of those slaves are not trivial (krb master and system where tck are running). Generally saying, I have autoamtion to prepare that all, but second part is reproducibility. If the "non mine" setup run will fail for some reason, can I rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters. Would it help to have some cloud resources to do this in? We could definitely get you access to some ec2 instances to setup a test cluster for testing fedora builds. it is quite hard to imagine better testing resources then I have in Red hat. Since some amount of HW/remote 3rd party clusters - which we reached - you really do not want to continue take care of it. Also HW and infra failures will suddenly multiply to the level that tehre are still some. And at the end, who wil watch results? And will debugging remain smooth? So generall sayong - yes more hw would help. But with more HW one needs more pople to contorl that and fix, and to check results. So no, really since soem amount of workload, jsut more HW is not solution. Of course that imply possible heavy reorganization JDK team in RH which cares about Fedora rpms in theirs free time, maybe have to do. I know others have suggested fewer openjdk streams to reduce workload, but I didn't see any reply on that from change owners. I replied it already in that thread, but happy to repeat: It will help, but less then it seems so. Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down. but we can not droop 11, as it is system jdk in f35 Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs it time to be tuned before being proposed as system jdk. And we can not drop java-latest-openjdk, becasue it is necessary to boot next system JDK. Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be felt by fedora users more, then having static jdk from repos. Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as secondary jdk at least for one , better two, fedora cycles, so again we will be in 3 jdks x 3 systems. Sure, we do not need to backport newest future system jdk to older fedoras, but usually the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden. If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK With this shortage, we would have 2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That sound like a reasonable drop, but only for very short period of time, duriong which we will nee to have capcity reserved for ppreparation of next system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage, With much more stress about possible integration issues and with - imo(!) - considerable negative imapct to fedora. ok, sorry I missed a previous reply on this. ;) So, what would you then think about just: 1. having some cloud resources to setup a tck test env that you could manage better than some ci somewhere and use to test fedora builds. and Nope. I really ahve huge HW capacity. yes, we reached its capacity. Addng more capacity woudl help, but with that will arrive need of more poeple. 2. switching fedora to the static system libraries so you didn't need to keep the dynamic ones in sync. Taht is first step. Maybe we will really find that we can not do it in distro, and cut of JDK packed will
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 25 May 2022 at 09:04, Jiri Vanek wrote: > > > On 5/24/22 21:41, Vitaly Zaitsev via devel wrote: > > On 24/05/2022 21:00, Jiri Vanek wrote: > >> I repeat what was told several times.We really do no t like this > change, especially in its full sound of one static build repacked to all > ive fedoras, but we have nto found a better way. > > > > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need > certified binaries. > We can not ship uncerified JDK. Sooner or later a swarm of lawyers would > appear. > > So could it be shipped instead as a icedtea? The reason I am asking is that I think we need to look seriously at the alternatives and see how much work the community is going to need to do. 1. Fedora no longer ships a trademarked 'coffee-themed language'. Instead it adds an external repository where your team is able to focus on what they can deliver. 2. Fedora no longer ships a trademarked 'coffee-themed language'. Instead, a volunteer driven SIG puts in an icedtea back into into Fedora instead. 3. Fedora no longer ships a trademarked 'coffee-themed language'. Instead people wanting it will need to find an external place which builds it. 4. Fedora ships a trademarked 'coffee-themed language' that is static. However this doesn't decrease the workload enough and we need to move to 1-3 in 2 to 3 years. > > All they need is a working and well packaged OpenJDK. > > > > From point of view of JDK, the jdk will remain working. From point of > JDK and generric java world the jdk will be even better. > From view of distributions standarts it will become weird misshape. > Serving it purpose in build root well, serving as system or distribution > jdk well. But yeah... all was said on this toppic already:( > > > 2. Reduce the number of OpenJDK branches in the repositories. I think > the latest LTS version will be enough. > > I wish it is so simple. Please see my reply to Kevin when I enumerated, > that we can not keep "jsut latest" lts. > > > > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 22:02, Fabio Valentini wrote: On Tue, May 24, 2022 at 5:03 PM Jiri Vanek wrote: I replied it already in that thread, but happy to repeat: It will help, but less then it seems so. Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down. but we can not droop 11, as it is system jdk in f35 Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs it time to be tuned before being proposed as system jdk. And we can not drop java-latest-openjdk, becasue it is necessary to boot next system JDK. Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be felt by fedora users more, then having static jdk from repos. Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as secondary jdk at least for one , better two, fedora cycles, so again we will be in 3 jdks x 3 systems. Sure, we do not need to backport newest future system jdk to older fedoras, but usually the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden. Is this based on user requests, or is this only what you *think* users I'm not sure what you mean - from above - what is based on mine/wider thinking Generally waht I wrote here it is based on judgmeent of about 10 people around OpenJDK pacages in Fedora. The equations above are based on realistic view and experience. Do you yo find some misscalcualtion above? I really appreciate you opinions, and would be happyt answer more precisely. of OpenJDK on Fedora need? Speaking for myself, I have never used anything other than the default "system JDK" for running Java applications on Fedora. Are you really sure? Many applications runtime requiter non system jdk, so they pull it in and use, and maybe you have not even noticed. Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I need to compile jimage) and the switch as needed. What would you think about the following scenario: - Fedora X defaults to new OpenJDK LTS N - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already the default for one release - do not backport OpenJDK n to Fedora X-1 and X-2 - keep java-latest-openjdk, as you seen to need this for bootstrapping new OpenJDK releases This is possible solution. It will lower the TCK burden to aprox 3/5 with lost of most widely used JDKs from repositories. I'm open to this proposal. But the removal will hurt and way back will be much harder then swithing static builds back to dynamic. You could even drop java-latest-openjdk from all branches but rawhide, since it's only needed for bootstrapping there. Taht is very valid point. Cost is it will force huge number of uses to download 3rd party latest STS jdk. it is where all new features live. This should pretty dramatically reduce the size of your test matrix. Applying the current numbers: - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the default needs to be switched back), java-latest-openjdk - Fedora 35: java-11-openjdk, java-latest-openjdk it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish to cut all those jdks from fedora? To me the static repacked build sill somehow seems as smaller evil then drop practically all interesting jdks out of distro. So here I need to rephrase your question - is it based on your's thinking or on what fedora users really needs? I think the oposite - they need all jdks which are around. Proeprly integrated with system. How they are built .. they do not care. If update to neewer Fedora wil lmake some older JDK disapear, or if need of new one will force me to update Fedora when I don't want or cant. I call it much worse user expereince With much more stress about possible integration issues and with - imo(!) - considerable negative imapct to fedora. Would this reduced set of supported OpenJDK versions, but keeping the "latest" version, address this "considerable negative impact"? Of course it will. But afaik the imapct is really mch worse then it seems. Thanx a lot! J. ___ 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:
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 21:41, Vitaly Zaitsev via devel wrote: On 24/05/2022 21:00, Jiri Vanek wrote: I repeat what was told several times.We really do no t like this change, especially in its full sound of one static build repacked to all ive fedoras, but we have nto found a better way. 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need certified binaries. We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear. All they need is a working and well packaged OpenJDK. From point of view of JDK, the jdk will remain working. From point of JDK and generric java world the jdk will be even better. From view of distributions standarts it will become weird misshape. Serving it purpose in build root well, serving as system or distribution jdk well. But yeah... all was said on this toppic already:( 2. Reduce the number of OpenJDK branches in the repositories. I think the latest LTS version will be enough. I wish it is so simple. Please see my reply to Kevin when I enumerated, that we can not keep "jsut latest" lts. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote: > > We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, > so we have to. But that is much easier, as the usptream is static within > intree libraries. And we have to run also for 17 and 18/19 as we need this > reference run, to be sure that downstream is guilty, not vanilla jdk. Thus > we test the (source x build) just once. And we can test the binary on some > known system where we always pass. Well, I meant test the _dynamic_ build that Fedora does now... > But in downstream, new issues usually appear due to the dynamic linking and > nature of system where only it can be installed. Also for dowstram, each > sources are built N times, so N times tested in thsoe N systems - usually > each with its psecific failures. > > > > > Could we integrate the TCK testing in our CI to save you overhead of > > managing submitting, etc? Or where is the most time spent in this > > workflow? > > As I described in another reply, it is both human and hw. Hw to run all those > swarm of builds on all platforms, and humans to verify the issue and to fix > it. > TCK are very complex, and you need at least three machines in distributed > system to run them. At least two of those slaves are not trivial (krb master > and system where tck are running). > Generally saying, I have autoamtion to prepare that all, but second part is > reproducibility. If the "non mine" setup run will fail for some reason, can I > rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters. Would it help to have some cloud resources to do this in? We could definitely get you access to some ec2 instances to setup a test cluster for testing fedora builds. > > I know others have suggested fewer openjdk streams to reduce workload, > > but I didn't see any reply on that from change owners. > > > > I replied it already in that thread, but happy to repeat: > It will help, but less then it seems so. > Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 > is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK > runs down. > but we can not droop 11, as it is system jdk in f35 > Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. > It needs it time to be tuned before being proposed as system jdk. > And we can not drop java-latest-openjdk, becasue it is necessary to boot next > system JDK. > Yes, in 8 months, we would be able to drop 11. And live for 1 year only on > latest and 17. Which is putting load for one year to 1/2. But the cost of not > having 11 (and 8) will be felt by fedora users more, then having static jdk > from repos. > Unluckily, with new future system jdk, we will need to boostrap it by latest, > keep it as secondary jdk at least for one , better two, fedora cycles, so > again we will be in 3 jdks x 3 systems. > Sure, we do not need to backport newest future system jdk to older fedoras, > but usually the users want us to do so. tbh, I do not have strong preference > on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK > burden. > > If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK > With this shortage, we would have > 2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That > sound like a reasonable drop, but only for very short period of time, duriong > which we will nee to have capcity reserved for ppreparation of next > system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage, > With much more stress about possible integration issues and with - imo(!) - > considerable negative imapct to fedora. ok, sorry I missed a previous reply on this. ;) So, what would you then think about just: 1. having some cloud resources to setup a tck test env that you could manage better than some ci somewhere and use to test fedora builds. and 2. switching fedora to the static system libraries so you didn't need to keep the dynamic ones in sync. but then trying to see if that reduces your workload to a sustainable level and avoid the 'build once, certify' thing that is going to end up being a lot of trouble. kevin signature.asc Description: PGP signature ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Tue, May 24, 2022 at 5:03 PM Jiri Vanek wrote: > I replied it already in that thread, but happy to repeat: > It will help, but less then it seems so. > Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 > is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK > runs down. > but we can not droop 11, as it is system jdk in f35 > Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. > It needs it time to be tuned before being proposed as system jdk. > And we can not drop java-latest-openjdk, becasue it is necessary to boot next > system JDK. > Yes, in 8 months, we would be able to drop 11. And live for 1 year only on > latest and 17. Which is putting load for one year to 1/2. But the cost of not > having 11 (and 8) will be felt by fedora users more, then having static jdk > from repos. > Unluckily, with new future system jdk, we will need to boostrap it by latest, > keep it as secondary jdk at least for one , better two, fedora cycles, so > again we will be in 3 jdks x 3 systems. > Sure, we do not need to backport newest future system jdk to older fedoras, > but usually the users want us to do so. tbh, I do not have strong preference > on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK > burden. Is this based on user requests, or is this only what you *think* users of OpenJDK on Fedora need? Speaking for myself, I have never used anything other than the default "system JDK" for running Java applications on Fedora. What would you think about the following scenario: - Fedora X defaults to new OpenJDK LTS N - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already the default for one release - do not backport OpenJDK n to Fedora X-1 and X-2 - keep java-latest-openjdk, as you seen to need this for bootstrapping new OpenJDK releases You could even drop java-latest-openjdk from all branches but rawhide, since it's only needed for bootstrapping there. This should pretty dramatically reduce the size of your test matrix. Applying the current numbers: - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the default needs to be switched back), java-latest-openjdk - Fedora 35: java-11-openjdk, java-latest-openjdk > With much more stress about possible integration issues and with - imo(!) - > considerable negative imapct to fedora. Would this reduced set of supported OpenJDK versions, but keeping the "latest" version, address this "considerable negative impact"? 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
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 24/05/2022 21:00, Jiri Vanek wrote: I repeat what was told several times.We really do no t like this change, especially in its full sound of one static build repacked to all ive fedoras, but we have nto found a better way. 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need certified binaries. All they need is a working and well packaged OpenJDK. 2. Reduce the number of OpenJDK branches in the repositories. I think the latest LTS version will be enough. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 18:37, Vitaly Zaitsev via devel wrote: On 24/05/2022 16:31, Jiri Vanek wrote: The goal is to go as shim and cisco - to build in koji, certify, and repack. shim and openh264 have a good reason for this - legal issues. OpenJDK doesn't. Sorry, but I can't treat the laziness of the maintainers as a good reason. Even if you woulf call 10 years of 5 engineers to keep dynamic builds (and generlay jdk in Fedora) alivem, tt had become human-impossible to continue in current way of things. It will lead to lost of JDK or heavy rework of how JDK s handled now I repeat what was told several times.We really do no t like this change, especially in its full sound of one static build repacked to all ive fedoras, but we have nto found a better way. Really sorry, J. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 10:57, Jiri Vanek wrote: > > > On 5/23/22 20:40, Kevin Fenzi wrote: >> So, just replying here since this is a nice monster of a thread. ;( >> >> First, just to clear up some previous coments, shim does build against >> the oldest stable Fedora in koji and then is manually tagged into newer >> ones. This is not at all a good process. It only gets a bodhi update for >> the one release (and sometimes not even that), so it never gets good >> testing. It requires manual intervention from releng each time there's >> an update. I think the only reason this has kept going is that shim is >> very small and simple and updates rarely. If we need to do this for tons >> of openjdk updates, we really should revisit the process, although I am >> not sure how to make it more open to testing and less a burden on >> releng. ;( > > Thanx for bringing up additional details! >> >> Next, My understanding of the current process for openjdks (openjdki?): >> >> for each openjdk: >> >> Build dyanmically linking against system libraries in all fedoras. >> Submit to TCK and wait for them all to process. >> Fix any TCK failures and repeat >> Once there's no failures, push the builds to updates >> >> Is that right? And keeping the dynamic builds passing is taking more >> cycles than you have to give for the number of jdks? > > super correct. > >> >> What about the possibility of adding CI _upstream_ to test against the >> dynamic version? Then TCK failures would be caught upstream and not >> downstream where it's a lot of work for you to fix? > > We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so > we have to. But that is much easier, as the usptream is static within intree > libraries. And we have to run also for 17 and 18/19 as we need this reference > run, > to be sure that downstream is guilty, not vanilla jdk. Thus we test the > (source x build) just once. And we can test the binary on some known system > where we always pass. > But in downstream, new issues usually appear due to the dynamic linking and > nature of system where only it can be installed. Also for dowstram, each > sources are built N times, so N times tested in thsoe N systems - usually > each with its > psecific failures. Kevin’s suggestion is for upstream to test dynamic builds, not just static ones, in its CI. That means that if the dynamic build breaks, it would be upstream’s problem. In other words: Instead of shipping a static JDK in Fedora, make the dynamic JDK a first-class citizen upstream. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Once upon a time, Vitaly Zaitsev said: > Sorry, but I can't treat the laziness of the > maintainers as a good reason. Can you PLEASE stop with the personal attacks? -- Chris Adams ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 24/05/2022 16:31, Jiri Vanek wrote: The goal is to go as shim and cisco - to build in koji, certify, and repack. shim and openh264 have a good reason for this - legal issues. OpenJDK doesn't. Sorry, but I can't treat the laziness of the maintainers as a good reason. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/21/22 13:38, Neal Gompa wrote: On Sat, May 21, 2022 at 7:28 AM Jiri Vanek wrote: On 5/20/22 14:57, Vitaly Zaitsev via devel wrote: On 20/05/2022 14:28, Jiri Vanek wrote: wait, what? What do you mean? And waht give you this impression? https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > Make the normal rpms to not built jdk, but to repack the portable rpms with all integration thanx. Or are you already in the follwoing year, when the attempt will be doen to build each JDK in koji just once, and ship it to al llive fedoras? Repackaging of anything even it was built in Koji is strictly prohibited. All packages must be built from sources. No exceptions. shim? Shim is technically built on Fedora infrastructure as shim-unsigned. Microsoft signs that binary and the shim package has those binaries as sources in that package. OpenJDK is not that strict, and frankly I don't think we'd want to do more than just that package that way. It's a massive pain and it's pretty evident that this arrangement causes us serious problems too, since it locks the Fedora community out of fixing issues at that level. Hm. For "silent observer" (in case of shmi and codecs) the burden seemed not so high, But as Kevinlater described, it was a bit underestimated. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/23/22 20:40, Kevin Fenzi wrote: So, just replying here since this is a nice monster of a thread. ;( First, just to clear up some previous coments, shim does build against the oldest stable Fedora in koji and then is manually tagged into newer ones. This is not at all a good process. It only gets a bodhi update for the one release (and sometimes not even that), so it never gets good testing. It requires manual intervention from releng each time there's an update. I think the only reason this has kept going is that shim is very small and simple and updates rarely. If we need to do this for tons of openjdk updates, we really should revisit the process, although I am not sure how to make it more open to testing and less a burden on releng. ;( Thanx for bringing up additional details! Next, My understanding of the current process for openjdks (openjdki?): for each openjdk: Build dyanmically linking against system libraries in all fedoras. Submit to TCK and wait for them all to process. Fix any TCK failures and repeat Once there's no failures, push the builds to updates Is that right? And keeping the dynamic builds passing is taking more cycles than you have to give for the number of jdks? super correct. What about the possibility of adding CI _upstream_ to test against the dynamic version? Then TCK failures would be caught upstream and not downstream where it's a lot of work for you to fix? We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so we have to. But that is much easier, as the usptream is static within intree libraries. And we have to run also for 17 and 18/19 as we need this reference run, to be sure that downstream is guilty, not vanilla jdk. Thus we test the (source x build) just once. And we can test the binary on some known system where we always pass. But in downstream, new issues usually appear due to the dynamic linking and nature of system where only it can be installed. Also for dowstram, each sources are built N times, so N times tested in thsoe N systems - usually each with its psecific failures. Could we integrate the TCK testing in our CI to save you overhead of managing submitting, etc? Or where is the most time spent in this workflow? As I described in another reply, it is both human and hw. Hw to run all those swarm of builds on all platforms, and humans to verify the issue and to fix it. TCK are very complex, and you need at least three machines in distributed system to run them. At least two of those slaves are not trivial (krb master and system where tck are running). Generally saying, I have autoamtion to prepare that all, but second part is reproducibility. If the "non mine" setup run will fail for some reason, can I rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters. I know others have suggested fewer openjdk streams to reduce workload, but I didn't see any reply on that from change owners. I replied it already in that thread, but happy to repeat: It will help, but less then it seems so. Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down. but we can not droop 11, as it is system jdk in f35 Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs it time to be tuned before being proposed as system jdk. And we can not drop java-latest-openjdk, becasue it is necessary to boot next system JDK. Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be felt by fedora users more, then having static jdk from repos. Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as secondary jdk at least for one , better two, fedora cycles, so again we will be in 3 jdks x 3 systems. Sure, we do not need to backport newest future system jdk to older fedoras, but usually the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden. If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK With this shortage, we would have 2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That sound like a reasonable drop, but only for very short period of time, duriong which we will nee to have capcity reserved for ppreparation of next system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage, With much more stress about possible integration issues and with - imo(!) - considerable negative imapct to fedora. TYVM! ___ 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
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/21/22 13:51, Vitaly Zaitsev via devel wrote: On 21/05/2022 13:22, Jiri Vanek wrote: shim? Built on Koji from sources as shim-unsigned, then uploaded to Microsoft for signing. This is a special legal case, just like openh264 and Cisco. Both of them built from sources on Fedora infra. I repeat, aprox 21st time - I will never ever use blob. I will always build from sources in koji. The goal is to go as shim and cisco - to build in koji, certify, and repack. J. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Hi, > Il giorno 10 mag 2022, alle ore 15:29, Ben Cotton ha > scritto: > > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > This is initial step to move JDKs to be more like other JDKs, to build > proper transferable images, and to lower certification burden of each > binary. Long storyshort, first step in: > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > > This first step will move, one by one, individual JDKs in F37 to be > built `--with-stdc++lib=static` and against in-tree (bundeld) > libraries: `--with-zlib="bundled" --with-freetype="bundled" > --with-libjpeg="bundled" --with-giflib="bundled" > --withlibpng="bundled" --with-lcms="bundled" > --with-harfbuzz="bundled" ` > -1 here, we should avoid bundled libraries > We already made a heavy testing of the behavior, and user should not > face negative experience. I'm not sure if this is > > == Owner == > * Name: [[User:jvanek| Jiri Vanek]] > * Email: jva...@redhat.com > > > == Detailed Description == > Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > for whole picture > > Please see > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable > for this particular step. I would rather keep the details in the main > page then here. > > == Feedback == > According to short investigations, there are already precedents, where > certification is a reason to build once, certificate, and repack. > > According to developers, the non-portbale JDK is causing upredicted > behavior different from other JDK vendors > > According to JDK packagers and testers, there is to much JDKs now, and > the > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration > is the only way out > > == Benefit to Fedora == > Please see > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation > for whole picture. > > This particular proposal's main benefit will be that Fedora's JDKs as > packed in RPMs will again start to resemble upstream JDKs and other > vendors build, and some platform specific issues disappear, while JDKs > remain same in view of system integration and user experience > > == Scope == > * Proposal owners: push improved version of > https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff > to all JDKs - one by one from latest, over 17 to 11 and 8. Once > settled down in F37 the backport to F36 is expected. > > * Other developers: really, nothing. If there will be unexpected > impact to other developers, the > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may > need rework > > * Release engineering: N/A [https://pagure.io/releng/issues #Releng > issue number] > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > > == Upgrade/compatibility impact == > The compatibility and upgrade path should remain completely smooth. > > > == How To Test == > Install system JDK (java-17-openjdk) and ru your favorite application > or development. No regression should be noted. > > > == User Experience == > > Because of in-tree libraries, minimal image or font rendering > differences canbe spotted after very detailed investigations - > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_effects > - still, no of th e > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_issues > should be hit by this proposal. > > > == Dependencies == > No dependent packages should notice the change. > > > == Contingency Plan == > * Contingency mechanism: Revert the patches and rework > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > * Contingency deadline: before f37 release > * Blocks release? Unless the java-stack will become completely borked then no. > > > == Documentation == > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > > > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ I don’t agree with this proposal, a big -1 for this FAS: tartina Ciao ___ 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:
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
So, just replying here since this is a nice monster of a thread. ;( First, just to clear up some previous coments, shim does build against the oldest stable Fedora in koji and then is manually tagged into newer ones. This is not at all a good process. It only gets a bodhi update for the one release (and sometimes not even that), so it never gets good testing. It requires manual intervention from releng each time there's an update. I think the only reason this has kept going is that shim is very small and simple and updates rarely. If we need to do this for tons of openjdk updates, we really should revisit the process, although I am not sure how to make it more open to testing and less a burden on releng. ;( Next, My understanding of the current process for openjdks (openjdki?): for each openjdk: Build dyanmically linking against system libraries in all fedoras. Submit to TCK and wait for them all to process. Fix any TCK failures and repeat Once there's no failures, push the builds to updates Is that right? And keeping the dynamic builds passing is taking more cycles than you have to give for the number of jdks? What about the possibility of adding CI _upstream_ to test against the dynamic version? Then TCK failures would be caught upstream and not downstream where it's a lot of work for you to fix? Could we integrate the TCK testing in our CI to save you overhead of managing submitting, etc? Or where is the most time spent in this workflow? I know others have suggested fewer openjdk streams to reduce workload, but I didn't see any reply on that from change owners. Thanks, kevin signature.asc Description: PGP signature ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 21/05/2022 13:22, Jiri Vanek wrote: shim? Built on Koji from sources as shim-unsigned, then uploaded to Microsoft for signing. This is a special legal case, just like openh264 and Cisco. Both of them built from sources on Fedora infra. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Sat, May 21, 2022 at 7:28 AM Jiri Vanek wrote: > > > > On 5/20/22 14:57, Vitaly Zaitsev via devel wrote: > > On 20/05/2022 14:28, Jiri Vanek wrote: > >> wait, what? What do you mean? And waht give you this impression? > > > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > > > > > Make the normal rpms to not built jdk, but to repack the portable rpms > > with all integration > > thanx. > > > > >> Or are you already in the follwoing year, when the attempt will be doen to > >> build each JDK in koji just once, and ship it to al llive fedoras? > > > > Repackaging of anything even it was built in Koji is strictly prohibited. > > All packages must be built from sources. No exceptions. > > shim? Shim is technically built on Fedora infrastructure as shim-unsigned. Microsoft signs that binary and the shim package has those binaries as sources in that package. OpenJDK is not that strict, and frankly I don't think we'd want to do more than just that package that way. It's a massive pain and it's pretty evident that this arrangement causes us serious problems too, since it locks the Fedora community out of fixing issues at that level. -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/20/22 14:57, Vitaly Zaitsev via devel wrote: On 20/05/2022 14:28, Jiri Vanek wrote: wait, what? What do you mean? And waht give you this impression? https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > Make the normal rpms to not built jdk, but to repack the portable rpms with all integration thanx. Or are you already in the follwoing year, when the attempt will be doen to build each JDK in koji just once, and ship it to al llive fedoras? Repackaging of anything even it was built in Koji is strictly prohibited. All packages must be built from sources. No exceptions. shim? -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/20/22 14:57, Vitaly Zaitsev via devel wrote: On 20/05/2022 14:28, Jiri Vanek wrote: wait, what? What do you mean? And waht give you this impression? https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > Make the normal rpms to not built jdk, but to repack the portable rpms with all integration thanx. Or are you already in the follwoing year, when the attempt will be doen to build each JDK in koji just once, and ship it to al llive fedoras? Repackaging of anything even it was built in Koji is strictly prohibited. All packages must be built from sources. No exceptions. shim? -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
It is not so bad. and I definitely do not feel offended or even close to. Many languages have very interesting words which go far beyond true/false untrue/not false/ correct/incorrect right/left/lie Thus saying many languages can not match to other langunages meaning of simple true/false right/left/lie 1:1 And even if they can, there remain cases which only native speaker can recognize. Thus saying, I was wrong write down driver, where I meant firmware. I was wrong and am happy for correction. It was sure form begining that this proposal will rise emotions - some one wrote it perfectly: clash of cultures. And will take bilions of liens to explain. And where it indeed rised a lot of emotions, lets leave the language details, and lets turn back to topic. Still thanx a lot alle, ven for this part language corner part. it was educative. J. On 5/20/22 14:46, Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 18 May 2022 at 17:18, Vitaly Zaitsev via devel wrote: On 18/05/2022 17:04, Stephen Smoogen wrote: It generally means and is interpreted as 'not true with the intention of deceiving'. 'incorrect' is considered 'not true'. The Oxford English Dictionary gives the following answer: lie (noun) - an intentionally false statement used with reference to a situation involving deception or founded on a mistaken impression Exactly. So, you implied malicious intent where there was none. Regards, Dominik -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Fri, 20 May 2022 at 08:43, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 20/05/2022 14:03, Jiri Vanek wrote: > > As writtten several times - this si not true. It will eb always source > > codebuilt in koji. > > From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > > I looked through the wiki history and it has said the following since the first page in April 8th: ``` It is also not a goal, to pack third party blob. Jdk will still continue to build in koji as it should. ``` Is there some other section which counters this? > Make the normal rpms to not built jdk, but to repack the portable rpms > with all integration > > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:33, Jiri Vanek wrote: Who shold hire them. You? Me? Fedoraproject? Red Hat. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:28, Jiri Vanek wrote: wait, what? What do you mean? And waht give you this impression? https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: > Make the normal rpms to not built jdk, but to repack the portable rpms with all integration Or are you already in the follwoing year, when the attempt will be doen to build each JDK in koji just once, and ship it to al llive fedoras? Repackaging of anything even it was built in Koji is strictly prohibited. All packages must be built from sources. No exceptions. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:46, Dominik 'Rathann' Mierzejewski wrote: Exactly. So, you implied malicious intent where there was none. we don't know for sure. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wednesday, 18 May 2022 at 17:18, Vitaly Zaitsev via devel wrote: > On 18/05/2022 17:04, Stephen Smoogen wrote: > > It generally means and is interpreted as 'not true with the intention of > > deceiving'. 'incorrect' is considered 'not true'. > > The Oxford English Dictionary gives the following answer: > > lie (noun) - an intentionally false statement > used with reference to a situation involving deception or founded on a > mistaken impression Exactly. So, you implied malicious intent where there was none. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:34, Vitaly Zaitsev via devel wrote: On 18/05/2022 17:51, jiri vanek wrote: You can not put uncertified JDK to fedora. Why not? And we can no longer properly support certified dynamic builds Hire new maintainers who can. Who shold hire them. You? Me? Fedoraproject? -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:36, Neal Gompa wrote: On Wed, May 18, 2022 at 12:33 PM jiri vanek wrote: Hi Neal! We are participating on Wakefield too. Why do you think JDK in feora should miss it ? It does nto metter if it is static or dynamic one, it will just run correctly under wayaland. Or do I miss something? The runtime libraries for integrating into Wayland are evolving at a fast pace. Moreover, if you build only once on the oldest distribution and tag up, it becomes even more difficult to take advantage of improvements to Wayland components in the distribution. My gut feeling is that changing OpenJDK to not rely on system libraries will make this considerably harder because we will have to wait for upstream to sync up and then pull it down. Additionally, depending on what their CI target is, it may wind up being even more difficult because older distributions *cannot* build some newer libraries because of missing build or runtime components. I've been dealing with that enough with KDE Plasma in Fedora and EPEL that I'm concerned we'd be in trouble with Wakefield on Fedora with this proposal. Thanx for writing it up. As wakefield is targetting jdk 20 at soonest, I wil both keep it in mind for wakefile project, and for Fedora jdk, this may be an interesting testing how the bundling actually works. My rough assumtpion would be, that it will remain runtime-laoding part, as JDK have to decide, if it is on X or Wayland, and load acordingly. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:32, Vitaly Zaitsev via devel wrote: On 18/05/2022 18:01, Neal Gompa wrote: At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. They also want to bundle pre-built binaries into dependent packages. wait, what? What do you mean? And waht give you this impression? Or are you already in the follwoing year, when the attempt will be doen to build each JDK in koji just once, and ship it to al llive fedoras? -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 19:14, Michael Catanzaro wrote: On Wed, May 18 2022 at 12:01:33 PM -0400, Neal Gompa wrote: At this point, I'd rather have an OpenJDK in Fedora than not. I'll bite: why? Just so that it's easily available via RPM? It's starting to sound like Fedora would be providing very little value here on top of what is offered by upstream. At a certain point, getting your software directly from upstream might make more sense. For leaf application this is siple. But for uttermost root of one huge depndency chain, it would be bad. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. Provides: bundled(foo) is very important. With this, every time a CVE is found in a dependent library, Product Security is going to report a bug against Java, and it will be expected to be fixed in Java. It's a lot of extra responsibility. Without the Provides, tracking such issues is impractical. Every bundled library needs a Provides, not only the ones that would be affected by this change. I agree. and it will be there/ Michael ___ 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 -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:03, Jiri Vanek wrote: As writtten several times - this si not true. It will eb always source codebuilt in koji. From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs: Make the normal rpms to not built jdk, but to repack the portable rpms with all integration -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:22, Fabio Valentini wrote: On Wed, May 18, 2022 at 6:04 PM Neal Gompa wrote: On Wed, May 18, 2022 at 11:55 AM jiri vanek wrote: You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite complicated setup. The pull and setup and run is completely autoamted, but it is a lot of HW you need (all architecures x all oses x all jdks). In adition, you need human power to keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails... and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with usptream and TCK evolution. But it is not easy from human resources point of view. At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. Can we do this without going down the route of building only once at one distribution tag and tagging the binary into everything else? I agree. Can we discuss alternative routes to reduce maintenance burden for OpenJDK than what you're currently planning for the long term? thanx for this understanidng:( Maybe we can think about whether it's absolutely necessary to keep maintaining three different LTS versions of OpenJDK? Dropping at least java-1.8.0-openjdk would already reduce maintenance burden for OpenJDK packages by over 25% (given that 1.8.0 seems to cause you most of the problems recenty). This would of course help, but I would rahter keep 4 different jdks packed once, then 1 jdk packed 4 times. Still we will need to maintain usually 1, but very opften two system jdks, and we will need to continue maintain java-latest-openjdk as we need it to bootsrap next main jdk. Also we need java-lates-opnjdk live in release, not jsut in buidlroot, so we can tune integration of future jdk fluently. If statically linking against bundled versions of *some* dependencies would really help that much, it might also be worth considering, as a last resort, to keep OpenJDK packages in Fedora at all. However, I personally am strongly against the "follow-up" proposal, MoveFedoraJDKsToBecomePortableJDKs. Most importantly, the "Known issues" section on this wiki page sounds to me like it should be completely out of the question to actually go forward with the proposal. We are going to fix known issue. Unless the known issues are solved, we can not continue. All except debuginfo are somehow solvable. Can you please enumerate what parts of known issues toruel syou most? that would be super valuable information. I rate them all moreover in same level, as anoying, but really fixable (not jsut workaround-able) for common benefit. Some time ago, jiri vanek wrote: We realy do no like this change, but we do not see another way. I wonder how this happened? Has this issue been brewing for a while? We have the issues which led to this proposal since jdk 11 appeared in fedora. The issue was unluckily not getting away, and was jsut getting worse, until this proposal occured. Or will Red Hat be downsizing the OpenJDK team in the near future? ;) nope, but the multiplying of JDK employees is unluckily nor following multiplying of JDKs... 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 -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:01, Neal Gompa wrote: On Wed, May 18, 2022 at 11:55 AM jiri vanek wrote: You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite complicated setup. The pull and setup and run is completely autoamted, but it is a lot of HW you need (all architecures x all oses x all jdks). In adition, you need human power to keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails... and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with usptream and TCK evolution. But it is not easy from human resources point of view. At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. I deeply appreciate your understanding. Can we do this without going down the route of building only once at one distribution tag and tagging the binary into everything else? If we do only this dirst part, then the TCK burden would not be lifted. Still it make maintaneace much more easy. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Just to repeat i one more times, and maybe a bit more loudly - the rendering seems to be SAME for both static and dynamic linking. Please anybody who complains in this thread, can yo have any proof that dynamic linking really makes yor eyes bleed?? J. On 5/18/22 15:48, Mario Torre wrote: On Tue, May 10, 2022 at 11:52 PM Neal Gompa wrote: I'm confused how this would not negatively impact the user experience, because things like FreeType and HarfBuzz in Fedora have features and configuration that are non-default that improve the font rendering capabilities of applications that link to FreeType. I would rather have our shared maintenance and evolution of font stuff be reused in Java too... The rendering is always done in OpenJDK, those libraries are not used for the actual rendering. The generation of glyphs types and the metrics are obtained via those libraries, but it's been ages since the old patented algorithms would produce better quality, and anyway those would not be available in Fedora anyway. There are settings that influence the rendering, which is why sometimes users have worse quality on KDE vs Gnome, but those aren't settings in the libraries, are configurations such as environment variables or gnome properties. If you experience font quality differences, I would pretty much like to know, this would be a bug. They would also be very surprising though, applications such as IntelliJ bundle their own JDKs, I recall once one argument was exactly because of "better" font rendering, which is clearly not an actual argument. Btw, I know this because I fixed a gazillion font related bugs in OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I rarely ever had to touch 8 or later. Cheers, Mario -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 13:02, Fabio Valentini wrote: On Wed, May 18, 2022 at 12:28 PM jiri vanek wrote: Once, long ago, we were the leader in the Linux Java ecosystem, but ironically as Red Hat's influence in OpenJDK grew, investment in Fedora dwindled. That really is not true. But maybe we were doing to much to keep any java somehow alive. This proposal will untie our hands, and we wil be able to focus to toher things - exactl those which you propose. My experience with trying to keep Java packages in Fedora alive does not allow me to agree with you. I tried to keep Java ecosystem from disintegrating *twice* and both times I was discouraged by Red Hat employees. Can you elaborate more please? I guess one of this interactions was me. Which makes me double courious what caused you this experience. We've also lost most of our Java based apps to even test OpenJDK with. What the heck are we supposed to do to test and give karma? We lost Eclipse last year, and we lost IntellJ and NetBeans several years ago. Azureus was removed a year ago, too. The larger Java community stopped encouraging the development of desktop apps more than seven years ago, Excelent point - the reason why they quit, is that it is impossible to maintain compelte dependency chain, and having downloadable blob is so much easier for the maintenance. And JDK world is moving into this direction. If we will not be allowed to do so, JDK can leave fedora at all. That's not a valid argument, though, is it? If you have the choice between doing something that is 1) hard or 2) forbidden, then you don't really have a choice, do you? That is correct. But afaik there are three 1) hard 2) a bit easier 3) forbidden As fedora ahve bundling already allwod, the 2 is choice if 1 was attempted and proved to cost really a lot. Redistributing binary blobs or pre-compiled JAR files is not something we can do with Fedora RPM packages. As writtten several times - this si not true. It will eb always source codebuilt in koji. Of course it would be much simpler if we could just take JAR files from Maven Central and wrap them in an RPM, but that is forbidden in Fedora for good reason. Here I agree. if fedora move to prepacked blobs, then all freedome of source is gone. No way. If I ever suggest that, I will give you happily my address so you can take proper steps to stop it;) And that does not even account for the packages in Fedora that contain some amount of Java support code or tools that happen to be written in Java, and so rely on at least some parts of the Java ecosystem (javac, maybe maven or ant) to be available as RPMs during package builds. But that is again not going to change. I fail to understand your point here. Nor did I got why my argument is not valid. Maybe you misunderstood "having downloadable blob is so much easier for the maintenance" I ment downloadable from internet, not as rpms. Some simple mvn assembly:assembly which will do all the build work on developer's local machine, and then mvn release:release which will publish on project's web page and maintianer is done. On contrary, with more then 10 dependencies (unpacked for distro) it is already quite a fight to put it in. And if dependency (version) hell strikes, the apckager is lsot, where upstream maintainer and publisher is not. 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 -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Btw, I know this because I fixed a gazillion font related bugs in OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I rarely ever had to touch 8 or later. I make my own IntelliJ packages for my own use that rips out their Java runtime and uses Fedora's OpenJDK. :) Idea still provides that JBR-less tarball isnt it? Also the idealauncher honour java_home, so it can work with "any" jdk. I run idea only with fedora system jdk, and if I find some trace of JBR, it is removed withotu compromises. HAd issues with thsi just recenlty, after f36 udpate, which have java-17-oepnjdk suddnely, whch idea was not ready. dnf install of 11 resovled it withotu issues -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
I don't think so. The entire Java ecosystem on Fedora was destroyed by Fedora Modularity. Volunteers tried several times to revive it but failed due to opposition. I personally heavily agree:((( The modularity was great idea, but worst implementation ever. And for java it was indeed death blow which will take years to fix. J. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 17:31, Neal Gompa wrote: On Wed, May 18, 2022 at 11:28 AM Peter Boy wrote: Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel : On 18/05/2022 11:27, Peter Boy wrote: We didn’t lost Eclipse, we switched from RPM to another distribution method. The same with Netbeans. No RPMS in Fedora repositories => Fedora lost them. You neglect the reality. One alternative installation source is flatpak, that is gaining approval among more and more Fedora developers, and more and more are switching to it. There may still be initial difficulties, but this is a clear trend. Meanwhile, this is also an accepted Fedora repository. Not that I think that's great, but it's the reality. Another way is to run software as a „black box“ container. If I run CoreOS or Silverblue I would primarily look in container repositories, not any dnf find … These two options do not use a Fedora Java runtime, I'm still new to silverblue, so I don not parse. What does it use if not system java please? Or you just download the jar or Linux installation tar from the project. They usually contain a shell script to invoke the jre and provide a class path. That’s all you need for a java app. So Fedora (= Fedora users) can use it as they could for years. There is nothing lost. But circumstances and the nature of management and maintenance are changing. 20 years ago we had no virtualization and no containers, no generic package managers as flatpack, snap, etc. And Java development was much more about using ant and source code libraries instead of maven and depository dependencies. Java was almost never about source code libraries, that's been the problem the entire time. The entire focus has been on introspectable binary JAR files, which is how most libraries are distributed. That's what makes Java the odd duck out compared to most ecosystems. It also I would say this is one fo the strengths of the java. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 14:40, Felix Schwarz wrote: Am 18.05.22 um 11:27 schrieb Peter Boy: We didn’t lost Eclipse, we switched from RPM to another distribution method. Do you mean the Eclipse flatpak? I tried the flatpak but in the end went back to upstream's plain binaries as the Flatpak does not work well when using pydev. So for my use case Fedora lost Eclipse. I tend to agree. No flatpak ide ever proeprly fored for me, especially becasue of impossibility to use any custom jdk or thrd party servers (including in fedora packed ones) proeprly. On the other side, huge java projecs (like eclipse or netbeasn) are so complex and so impossibel to pack properly, that wgeted tarball remmains win win. Even in time of those ides packed,the tarballs freom web was quite a lot better. J:( Felix ___ 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 -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/17/22 00:10, Fabio Valentini wrote: On Mon, May 16, 2022 at 4:54 PM Andrew Hughes wrote: Let me join the train of -1 votes. I consider this a step entirely in the wrong direction. The JDK should be linked to system libraries wherever possible just like our other packages. Language interpreters/JITs are not exempt from that. In fact, I see very little value in providing JDK packages at all if they are built that way. I expect JDK users would disagree with you. JDKs from other vendors (Amazon, Azul, Oracle, etc.) are built in exactly this way. We (and likely other GNU/Linux distributions) are the exception here. I don't think this is a valid argument, because you're looking at OpenJDK in isolation. As far as I know, almost all compilers and runtimes we ship in Fedora are built with a certain amount of downstream patches that make them "slightly different" than what you might install in binary form from "$foo-lang.org" (if only to make them usable to build other packages that use them), so OpenJDK is not an exception here at all. I would even argue that users are *aware* that the compilers / runtimes that are provided by Linux distributions are at least *slightly modified* (if only to cater to linux distribution use cases), and will already fall back to "official" binaries, when necessary. If you really want to lower your maintenance burden for OpenJDK packages, I'd start by not shipping four (or soon five?) different versions of them. For example, do we really still need java-1.8.0-openjdk? Or is it time to retire the ancient Java packages that only still work on a Java runtime that's almost a decade old? Or, can even java-11-openjdk be dropped in the near future, since java-17-openjdk is the default for Fedora 36 and future Fedora releases? And do we actually need the "java-latest-openjdk" version at all? If anybody needs such an up-to-date Java compiler / runtime for their development work, they'll surely already download an official binary distribution. Well yes. Taht is of course option to support only system jdk and be done with that. We will need to continue t build - but never release- -latest- package, so we are able to bootsrap next system jdk (21 or what) Note one super huge bad side effect - the new system jdk will be totally untested, including integration. Thus saying, I woudl ratehr support 4 static different fully jdks tested, then 1 jdk build 4times, which is fully untested Thanx! J. 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 -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/19/22 01:00, Kevin Kofler via devel wrote: > Demi Marie Obenour wrote: >> If Fedora legally cannot ship a version of OpenJDK that hasn’t >> passed the TCK, but which is still compatible with the vast majority >> of Java code, then OpenJDK isn’t free software and Fedora cannot >> ship it at all. Conversely, if OpenJDK is free software, then Fedora >> can strip out any problematic trademarks without losing compatibility. > > This abuse of trademarks to make Free Software not really free is an > alarming pattern. See also Firefox. Firefox does not bother me too much: disabling branding was just a configure switch last I checked, and the no-branding build will still work fine. I believe seL4 just says if you ship a modified version you have to call it something different, and I am fine with that too. My main problem is when removing trademarks is technically difficult and/or causes breakage. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Demi Marie Obenour wrote: > If Fedora legally cannot ship a version of OpenJDK that hasn’t > passed the TCK, but which is still compatible with the vast majority > of Java code, then OpenJDK isn’t free software and Fedora cannot > ship it at all. Conversely, if OpenJDK is free software, then Fedora > can strip out any problematic trademarks without losing compatibility. This abuse of trademarks to make Free Software not really free is an alarming pattern. See also Firefox. 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
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 19:14, Michael Catanzaro wrote: Every bundled library needs a Provides, not only the ones that would be affected by this change. Yes. And maintainers must include and keep up to date this information in SPECs: All packages whose upstreams have no mechanism to build against system libraries MAY opt to carry bundled libraries, but if they do, they MUST include an indication of what they bundle. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 06:45, jiri vanek wrote: >> Why did you give up? >> > > I'm unable to enumerate number of bugs we solved, or even dropped as > unsolvable due to dynamic nature of distribution-correct JDK. Can you provide an example of an unsolvable one? >> At one point AdoptOpenJDK distributed binaries that were not tested >> against the TCK (https://dzone.com/articles/an-overview-on-jdk-vendors). > > They indeed did it once, and had pretty hard time fromthat. Now they TCK > propelry. >> >> Why is running the TCK such a burden? Is it due to hardware >> resource limitations? Do we really need to claim that >> we are Java SE compatible? > > We ahve claim the comaptibility. Tck run in the paralel mode 24h per os and > arch and jdk. And there are tricky issues, and even more tricky failures. So > both human and hw cycles are heavily under preassure Why is claiming compatibility necessary? >> Is this purely because of the TCK requirement? If so, I would prefer >> that Fedora ship an uncertified binary, or ship both a certified >> static binary and an uncertified dynamic binary, with the latter >> being the default. > > Interesting idea. Not sure if legally possible but worthy of shot. If Fedora legally cannot ship a version of OpenJDK that hasn’t passed the TCK, but which is still compatible with the vast majority of Java code, then OpenJDK isn’t free software and Fedora cannot ship it at all. Conversely, if OpenJDK is free software, then Fedora can strip out any problematic trademarks without losing compatibility. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18 2022 at 12:01:33 PM -0400, Neal Gompa wrote: At this point, I'd rather have an OpenJDK in Fedora than not. I'll bite: why? Just so that it's easily available via RPM? It's starting to sound like Fedora would be providing very little value here on top of what is offered by upstream. At a certain point, getting your software directly from upstream might make more sense. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. Provides: bundled(foo) is very important. With this, every time a CVE is found in a dependent library, Product Security is going to report a bug against Java, and it will be expected to be fixed in Java. It's a lot of extra responsibility. Without the Provides, tracking such issues is impractical. Every bundled library needs a Provides, not only the ones that would be affected by this change. Michael ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 18:26, Simon Farnsworth wrote: In English, "lie" means "a statement made by someone knowing it is not true". It carries with it the idea that the person making the false statement knew it was false, but claimed it was true anyway. True, but we don't know for sure was it a mistake or an attempt to justify inclusion of prebuilt blobs. If this offended anyone, I apologize. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 12:33 PM jiri vanek wrote: > > Hi Neal! > > We are participating on Wakefield too. Why do you think JDK in feora should > miss it ? > It does nto metter if it is static or dynamic one, it will just run correctly > under wayaland. Or do I miss something? The runtime libraries for integrating into Wayland are evolving at a fast pace. Moreover, if you build only once on the oldest distribution and tag up, it becomes even more difficult to take advantage of improvements to Wayland components in the distribution. My gut feeling is that changing OpenJDK to not rely on system libraries will make this considerably harder because we will have to wait for upstream to sync up and then pull it down. Additionally, depending on what their CI target is, it may wind up being even more difficult because older distributions *cannot* build some newer libraries because of missing build or runtime components. I've been dealing with that enough with KDE Plasma in Fedora and EPEL that I'm concerned we'd be in trouble with Wakefield on Fedora with this proposal. -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 17:51, jiri vanek wrote: You can not put uncertified JDK to fedora. Why not? And we can no longer properly support certified dynamic builds Hire new maintainers who can. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Hi Neal! We are participating on Wakefield too. Why do you think JDK in feora should miss it ? It does nto metter if it is static or dynamic one, it will just run correctly under wayaland. Or do I miss something? ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 18:01, Neal Gompa wrote: At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. They also want to bundle pre-built binaries into dependent packages. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 17:28, Peter Boy wrote: You neglect the reality. RPM is still the main package format on Fedora. One alternative installation source is flatpak, that is gaining approval among more and more Fedora developers, and more and more are switching to it. Do you mean a third-party repository Flathub by "Flatpak"? Sorry, but I can't trust Flathub, because they even doesn't build a lot of popular apps from sources[1]. They are just repackaging DEBs. There is nothing lost. I don't think so. The entire Java ecosystem on Fedora was destroyed by Fedora Modularity. Volunteers tried several times to revive it but failed due to opposition. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wednesday, 18 May 2022 15:41:17 BST Vitaly Zaitsev via devel wrote: > On 18/05/2022 13:47, Dominik 'Rathann' Mierzejewski wrote: > > > Then call it "incorrect". Saying it's a lie implies intent to mislead, > > while there obviously was none. > > > Saying "lie" means "not true". > In English, "lie" means "a statement made by someone knowing it is not true". It carries with it the idea that the person making the false statement knew it was false, but claimed it was true anyway. "Incorrect" or "not true" do not carry the implication that the person making the statement knew it was false. -- Simon Farnsworth ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 6:04 PM Neal Gompa wrote: > > On Wed, May 18, 2022 at 11:55 AM jiri vanek wrote: > > > > You can imagine TCK as gigantic and pretty good testsuite, runing 24hours > > with quite complicated setup. The pull and setup and run is completely > > autoamted, but it is a lot of HW you need (all architecures x all oses x > > all jdks). In adition, you need human power to keep with TCK evolution, > > sometimes to dapt setup, and to check resutls if they fails... and.. to fix > > it. We have HW from Red hat, and we deal with failures we keep track with > > usptream and TCK evolution. But it is not easy from human resources point > > of view. > > At this point, I'd rather have an OpenJDK in Fedora than not. If that > means switching to bundled libraries, then fine. But all bundled > libraries need to be documented in the spec file and that information > needs to be kept up to date. > > Can we do this without going down the route of building only once at > one distribution tag and tagging the binary into everything else? I agree. Can we discuss alternative routes to reduce maintenance burden for OpenJDK than what you're currently planning for the long term? Maybe we can think about whether it's absolutely necessary to keep maintaining three different LTS versions of OpenJDK? Dropping at least java-1.8.0-openjdk would already reduce maintenance burden for OpenJDK packages by over 25% (given that 1.8.0 seems to cause you most of the problems recenty). If statically linking against bundled versions of *some* dependencies would really help that much, it might also be worth considering, as a last resort, to keep OpenJDK packages in Fedora at all. However, I personally am strongly against the "follow-up" proposal, MoveFedoraJDKsToBecomePortableJDKs. Most importantly, the "Known issues" section on this wiki page sounds to me like it should be completely out of the question to actually go forward with the proposal. > Some time ago, jiri vanek wrote: > We realy do no like this change, but we do not see another way. I wonder how this happened? Has this issue been brewing for a while? Or will Red Hat be downsizing the OpenJDK team in the near future? ;) 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
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 11:55 AM jiri vanek wrote: > > You can imagine TCK as gigantic and pretty good testsuite, runing 24hours > with quite complicated setup. The pull and setup and run is completely > autoamted, but it is a lot of HW you need (all architecures x all oses x all > jdks). In adition, you need human power to keep with TCK evolution, sometimes > to dapt setup, and to check resutls if they fails... and.. to fix it. We have > HW from Red hat, and we deal with failures we keep track with usptream and > TCK evolution. But it is not easy from human resources point of view. At this point, I'd rather have an OpenJDK in Fedora than not. If that means switching to bundled libraries, then fine. But all bundled libraries need to be documented in the spec file and that information needs to be kept up to date. Can we do this without going down the route of building only once at one distribution tag and tagging the binary into everything else? -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
One one side it is good testsuite, on second something yo have to pass to publish. So if users in fedora should have distribution-packed JDKs, someone have to run (At least) them. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite complicated setup. The pull and setup and run is completely autoamted, but it is a lot of HW you need (all architecures x all oses x all jdks). In adition, you need human power to keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails... and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with usptream and TCK evolution. But it is not easy from human resources point of view. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
You can not put uncertified JDK to fedora. And we can no longer properly support certified dynamic builds. We realy do no like this change, but we do not see another way. ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 11:28 AM Peter Boy wrote: > > > > > Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel > > : > > > > On 18/05/2022 11:27, Peter Boy wrote: > >> We didn’t lost Eclipse, we switched from RPM to another distribution > >> method. The same with Netbeans. > > > > No RPMS in Fedora repositories => Fedora lost them. > > You neglect the reality. > > One alternative installation source is flatpak, that is gaining approval > among more and more Fedora developers, and more and more are switching to it. > There may still be initial difficulties, but this is a clear trend. > Meanwhile, this is also an accepted Fedora repository. Not that I think > that's great, but it's the reality. > > Another way is to run software as a „black box“ container. If I run CoreOS or > Silverblue I would primarily look in container repositories, not any dnf find > … > These two options do not use a Fedora Java runtime, > Or you just download the jar or Linux installation tar from the project. They > usually contain a shell script to invoke the jre and provide a class path. > That’s all you need for a java app. > > So Fedora (= Fedora users) can use it as they could for years. There is > nothing lost. But circumstances and the nature of management and maintenance > are changing. 20 years ago we had no virtualization and no containers, no > generic package managers as flatpack, snap, etc. And Java development was > much more about using ant and source code libraries instead of maven and > depository dependencies. > Java was almost never about source code libraries, that's been the problem the entire time. The entire focus has been on introspectable binary JAR files, which is how most libraries are distributed. That's what makes Java the odd duck out compared to most ecosystems. It also makes Java applications more difficult to fix, because there's no built-in assumption or ecosystem drive to promote shipping source code. -- 真実はいつも一つ!/ Always, there's only one truth! ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
> Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel > : > > On 18/05/2022 11:27, Peter Boy wrote: >> We didn’t lost Eclipse, we switched from RPM to another distribution method. >> The same with Netbeans. > > No RPMS in Fedora repositories => Fedora lost them. You neglect the reality. One alternative installation source is flatpak, that is gaining approval among more and more Fedora developers, and more and more are switching to it. There may still be initial difficulties, but this is a clear trend. Meanwhile, this is also an accepted Fedora repository. Not that I think that's great, but it's the reality. Another way is to run software as a „black box“ container. If I run CoreOS or Silverblue I would primarily look in container repositories, not any dnf find … Or you just download the jar or Linux installation tar from the project. They usually contain a shell script to invoke the jre and provide a class path. That’s all you need for a java app. So Fedora (= Fedora users) can use it as they could for years. There is nothing lost. But circumstances and the nature of management and maintenance are changing. 20 years ago we had no virtualization and no containers, no generic package managers as flatpack, snap, etc. And Java development was much more about using ant and source code libraries instead of maven and depository dependencies. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 17:04, Stephen Smoogen wrote: It generally means and is interpreted as 'not true with the intention of deceiving'. 'incorrect' is considered 'not true'. The Oxford English Dictionary gives the following answer: lie (noun) - an intentionally false statement used with reference to a situation involving deception or founded on a mistaken impression -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure