Re: Are we ready for ipv6-mostly networks?

[Björn Persson]

Petr Menšík wrote:
> Hello everyone,
> 
> I have attended recently csnog.eu conference [1], where some interesting 
> presentations took place. They were usually in Czech, so it is not 
> something I am going to share more. But what took my interest were ipv6 
> readiness with some exceptions. Fedora is ready to be run on dual-stack 
> IPv4 and IPv6 networks just fine. But the presentation were about future 
> case where we run most hosts on IPv6 network only, but allow some older 
> devices to take and use also IPv4 address.
> 
> Fortunately there is roughly the same presentation[2] in English, which 
> took the place on RIPE 85 meeting. What catched my interest were talk 
> about Windows 11 and Apple systems are ready, but not really talk about 
> how any linux distribution is ready for such situation. It seems to me 
> we should improve the support for mentioned mechanisms in Fedora.

Having watched the latter presentation, I understand that the idea is
that, on a network with a limited pool of globally routable IPv4
addresses, IPv6-capable clients should use only IPv6 and refrain from
requesting IPv4 addresses, so that addresses will be available to
legacy devices that need IPv4.

It seems to me that it would be very difficult for a DHCP client
program to know whether the Fedora installation it's running on needs
an IPv4 address. I think it would have to be manually configured.

It's mentioned in the presentation that IPv6 support is required in
Apple's App Store. That's not currently the case in Fedora. In my own
opinion everything should by now assume IPv6 as the norm, and treat
IPv4 as the legacy protocol that must still be supported for
compatibility – but that's not Fedora's policy. The policy is as
follows:

| If an application contains native and stable support for both IPv4 and
| IPv6, and support for IPv6 does not negatively affect IPv4 then both
| MUST be enabled in the Fedora package.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_networking_support

That means that IPv4-only programs are still quite welcome in Fedora if
their lack of IPv6 support is an upstream limitation and not introduced
by the packager. Thus the network configuration must expect that the
user might run such a program and might need IPv4 connectivity. The
policy should probably be changed before Fedora begins requesting only
IPv6 addresses by default.

Another concern is that the entire IPv6-mostly concept seems to assume
devices that are strictly clients. It doesn't seem like it would work
for anyone who runs any kind of server or peer-to-peer program. The idea
seems to be that IPv6 clients will access IPv4-only servers over NAT64.
Like all address translation, NAT64 is an obstacle to peer-to-peer
communication. If you need to communicate with a peer who is stuck with
an RFC 1918 address behind NAT on an IPv4-only network – a case that is
still far too common – and you're using IPv6 and NAT64, then you and
your peer will both be unable to connect to each other. If globally
routable IPv4 addresses are available on the network where you are,
then you'll want one so that your peer can at least connect to you.
Users of peer-to-peer programs will want to configure their DHCP client
to request an IPv4 address in case that need arises.

Björn Persson


pgp9M7lTUUnBU.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

On Thu, Jun 1, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-06-02 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:

This week we will have a discussion about recent changes to x86_64,
specifically the adjustment to the x86_64-v3 baseline and dropping
i686 multilib.

> Source: https://calendar.fedoraproject.org//meeting/10449/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Omair Majid]

Hi,

Thanks your thoughts!

Neal Gompa  writes:

> That's actually a lot better than it was when I helped with dotnet
> package review and bootstrap with 3.1.

Heh. That's very true! 3.1 had at least two source packages that had to
be kept in sync. I think you seemed much happier with the 7.0 review?
https://bugzilla.redhat.com/show_bug.cgi?id=2142178

> The main worry I have is how we're going to be able to build dotnet
> for a new architecture when nothing exists. RISC-V is the next big
> architecture, but the build for that will be difficult.

I am working with some folks from IBM on this who have had to build .NET
on s390x and ppc64le recently. Just like RISC-V, nothing existed for
those architectures before IBM started working on it. IBM have some
tools to automate this now. They are working on sharing the tools (and
their s390x, ppc64le builds) publicly, but there are some non-technical
blockers that prevent them.

If/when RISC-V support lands in .NET (eg, minimum of
https://github.com/dotnet/runtime/issues/36748), we could use those
tools (with hopefully minimal changes) to cross compile .NET for RISC-V.

I can ask IBM to prioritize making these tools public.

> It would also be good to have packaging guidelines for .NET
> applications, since there's a number of server and desktop Linux apps
> written in .NET languages that people would want to bring to Fedora.

I don't have a great solution for this. There are a few problems here:

- .NET applications really, really aren't meant to be built offline.
  Like other package ecosystems (eg, npm) every .NET application has a
  ton of dependencies fixed at specific versions. And they are fetched
  from the internet. There's no clear way to break down the dependency
  tree so we can start this work.

- Unlike ecosystems such as npm where everyone publishes source, .NET
  packages are binaries without a clear way to go from source -> binary.
  So even if we could figure out a clear way to slices the dependency
  tree so we can start building the root packages, it would be a manual
  process build every package

  - A subproblem is that lots of libraries only support building on
Windows, or through Visual Studio only. We would have to create/port
the upstream build scripts.

- GUI applications are simply not supported on Linux. .NET has no
  implementation for this. If you try and use the .NET SDK to build
  something that uses the GUI APIs, it will simply error out.

There's more discussion upstream at
https://github.com/dotnet/core/issues/7443 and
https://github.com/dotnet/source-build/discussions/2960

As a result of this, I am not sure where to even begin thinking about
packaging applications :(

Do you have any suggestions on the most important/useful applications
that we should look at for prototyping this effort?

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Omair Majid]

Hi,

Omair Majid  writes:

> If/when RISC-V support lands in .NET (eg, minimum of
> https://github.com/dotnet/runtime/issues/36748), we could use those
> tools (with hopefully minimal changes) to cross compile .NET for RISC-V.
>
> I can ask IBM to prioritize making these tools public.

Sorry, my information was out of date.

It's already public here:
https://github.com/ppc64le/build-scripts/tree/master/d/dotnet7

The prereq_install scripts would probably need a s/ppc64el/riscv64/g for
it to work on RISC-V.

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Demi Marie Obenour]

On 6/1/23 14:30, Matthias Clasen wrote:
> Hey, 
> 
> as you've probably seen, the LibreOffice RPMS have recently been orphaned, 
> and I thought it would be good to explain the reasons
> behind this.
> 
> The Red Hat Display Systems team (the team behind most of Red Hat’s desktop 
> efforts) has maintained the LibreOffice packages in Fedora for years as part 
> of our work to support LibreOffice for Red Hat Enterprise Linux. We are 
> adjusting our engineering priorities for RHEL for Workstations and focusing 
> on gaps in Wayland, building out HDR support, building out what’s needed for 
> color-sensitive work, and a host of other refinements required by Workstation 
> users. This is work that will improve the workstation experience for Fedora 
> as well as RHEL users, and which, we hope, will be positively received by the 
> entire Linux community. 
> 
> The tradeoff is that we are pivoting away from work we had been doing on 
> desktop applications and will cease shipping LibreOffice as part of RHEL 
> starting in a future RHEL version. This also limits our ability to maintain 
> it in future versions of Fedora. 
> 
> We will continue to maintain LibreOffice in currently supported versions of 
> RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those 
> releases (as published on the Red Hat website). As part of that, the 
> engineers doing that work will contribute some fixes upstream to ensure 
> LibreOffice works better as a Flatpak, which we expect to be the way that 
> most people consume LibreOffice in the long term. 
> 
> Any community member is of course free to take over maintenance, both for the 
> RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is 
> a sizable block of packages and dependencies and a significant amount of work 
> to keep up with.
> 
> Matthias

Why is a Flatpak a better choice for LibreOffice?
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

LibreOffice packages

[Matthias Clasen]

Hey, 

as you've probably seen, the LibreOffice RPMS have recently been orphaned, and 
I thought it would be good to explain the reasons
behind this.

The Red Hat Display Systems team (the team behind most of Red Hat’s desktop 
efforts) has maintained the LibreOffice packages in Fedora for years as part of 
our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting 
our engineering priorities for RHEL for Workstations and focusing on gaps in 
Wayland, building out HDR support, building out what’s needed for 
color-sensitive work, and a host of other refinements required by Workstation 
users. This is work that will improve the workstation experience for Fedora as 
well as RHEL users, and which, we hope, will be positively received by the 
entire Linux community. 

The tradeoff is that we are pivoting away from work we had been doing on 
desktop applications and will cease shipping LibreOffice as part of RHEL 
starting in a future RHEL version. This also limits our ability to maintain it 
in future versions of Fedora. 

We will continue to maintain LibreOffice in currently supported versions of 
RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those 
releases (as published on the Red Hat website). As part of that, the engineers 
doing that work will contribute some fixes upstream to ensure LibreOffice works 
better as a Flatpak, which we expect to be the way that most people consume 
LibreOffice in the long term. 

Any community member is of course free to take over maintenance, both for the 
RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a 
sizable block of packages and dependencies and a significant amount of work to 
keep up with.

Matthias
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Demi Marie Obenour]

On 6/1/23 07:33, Kevin Kofler via devel wrote:
> Jiri Vanek wrote:
>> At elast providing ofjava/openjdk is definitley out of scope.
> 
> I do not think a Provides would be a trademark violation. It is a part of 
> the standard procedure for renaming a package. But you would have to ask Red 
> Hat Legal for a definite answer. I am not a lawyer.
> 
> That said, there might not even be a trademark issue at all, at least for 
> "OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing 
> to:
> https://openjdk.org/legal/openjdk-trademark-notice.html
> 
>> As you wrote about the liberty of choice between temurins and fdeoara ona
>> - can you be a bit more specific? Afaik if the builds are similar, we have
>> mcuh less possibility of some fedora-specific bug.
> 
> But it also means that I no longer have the option to use a Java that does 
> not bundle several libraries, possibly including security vulnerabilities, 
> bloating its size, and likely reducing system integration (there have been 
> concerns about, e.g., worse fontconfig integration in the discussion of your 
> previous Change proposal). There is now just the "choice" between a Fedora 
> package with everything bundled and third-party packages with also 
> everything bundled.
> 
>> I once wrote,m that wworked 10years to enable dynamic linking, and yes,
>> all is upstream, but there are limitations which can not be overtaken -
>> major is ahead of tie comilation. If you can do it right, you cnanot have
>> dyanmic linking.
> 
> Wait, Java does real AOT compilation now? Or are we talking about that 
> strange "feature" you already brought up in the old discussion, where you 
> basically just prepend a JRE to a JAR and ship that as a "compiled" 
> executable? That "feature", to be honest, I had never heard of before you 
> folks brought it up.
> 
> As far as I can tell, nobody in the Java world uses it. It breaks the "write 
> once, run anywhere" promise and brings us no real advantage over having the 
> JRE and the JAR separate.
> 
> It is definitely not useful for me because our customers all run Windows, 
> not Fedora or any other GNU/Linux. So really it makes no difference for me 
> whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking) 
> or on all GNU/Linux (static linking), they will not run on our customers' 
> computers anyway, making that "feature" entirely useless either way.
> 
> We have a few ways to deploy our JARs to our customers, but none of them 
> involves turning them into native executables through (either real or fake 
> as described above) AOT compilation.

I haven’t written Java in years, but my understanding is
that AOT compilation has three major advantages:

1. It reduces the size of total deliverables because the
   final executable only includes the libraries it needs.
2. It is the _only_ way to have decent performance on
   platforms where JIT compilation is forbidden.
3. AOT-compiled apps start up faster and use less memory.

In short, an AOT-compiled application behaves much more
like one that is written in a native language like C++,
Rust, or Swift.  Additionally, AOT-compiled applications
are likely significantly harder to reverse engineer.  That
is a bad thing from my perspective, but in the corporate
world it might be desirable.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Gwyn Ciesla via devel]

I've taken ownership of libreoffice for the time being, at least to keep the 
lights on. Co-maintainers, as always, welcome.



-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, June 1st, 2023 at 1:30 PM, Matthias Clasen  
wrote:


> Hey,
> 

> as you've probably seen, the LibreOffice RPMS have recently been orphaned, 
> and I thought it would be good to explain the reasons
> behind this.
> 

> The Red Hat Display Systems team (the team behind most of Red Hat’s desktop 
> efforts) has maintained the LibreOffice packages in Fedora for years as part 
> of our work to support LibreOffice for Red Hat Enterprise Linux. We are 
> adjusting our engineering priorities for RHEL for Workstations and focusing 
> on gaps in Wayland, building out HDR support, building out what’s needed for 
> color-sensitive work, and a host of other refinements required by Workstation 
> users. This is work that will improve the workstation experience for Fedora 
> as well as RHEL users, and which, we hope, will be positively received by the 
> entire Linux community.
> 

> The tradeoff is that we are pivoting away from work we had been doing on 
> desktop applications and will cease shipping LibreOffice as part of RHEL 
> starting in a future RHEL version. This also limits our ability to maintain 
> it in future versions of Fedora.
> 

> We will continue to maintain LibreOffice in currently supported versions of 
> RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those 
> releases (as published on the Red Hat website). As part of that, the 
> engineers doing that work will contribute some fixes upstream to ensure 
> LibreOffice works better as a Flatpak, which we expect to be the way that 
> most people consume LibreOffice in the long term.
> 

> Any community member is of course free to take over maintenance, both for the 
> RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is 
> a sizable block of packages and dependencies and a significant amount of work 
> to keep up with.
> 

> Matthias
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

signature.asc
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Neal Gompa]

On Thu, Jun 1, 2023 at 11:05 AM Omair Majid  wrote:
>
> Hi,
>
> Thanks your thoughts!
>
> Neal Gompa  writes:
>
> > That's actually a lot better than it was when I helped with dotnet
> > package review and bootstrap with 3.1.
>
> Heh. That's very true! 3.1 had at least two source packages that had to
> be kept in sync. I think you seemed much happier with the 7.0 review?
> https://bugzilla.redhat.com/show_bug.cgi?id=2142178
>
> > The main worry I have is how we're going to be able to build dotnet
> > for a new architecture when nothing exists. RISC-V is the next big
> > architecture, but the build for that will be difficult.
>
> I am working with some folks from IBM on this who have had to build .NET
> on s390x and ppc64le recently. Just like RISC-V, nothing existed for
> those architectures before IBM started working on it. IBM have some
> tools to automate this now. They are working on sharing the tools (and
> their s390x, ppc64le builds) publicly, but there are some non-technical
> blockers that prevent them.
>
> If/when RISC-V support lands in .NET (eg, minimum of
> https://github.com/dotnet/runtime/issues/36748), we could use those
> tools (with hopefully minimal changes) to cross compile .NET for RISC-V.
>
> I can ask IBM to prioritize making these tools public.
>

Some progress on RISC-V has been made:
https://github.com/dotnet/runtime/issues/84834

Hopefully some more will be done soon. :/

> > It would also be good to have packaging guidelines for .NET
> > applications, since there's a number of server and desktop Linux apps
> > written in .NET languages that people would want to bring to Fedora.
>
> I don't have a great solution for this. There are a few problems here:
>
> - .NET applications really, really aren't meant to be built offline.
>   Like other package ecosystems (eg, npm) every .NET application has a
>   ton of dependencies fixed at specific versions. And they are fetched
>   from the internet. There's no clear way to break down the dependency
>   tree so we can start this work.
>
> - Unlike ecosystems such as npm where everyone publishes source, .NET
>   packages are binaries without a clear way to go from source -> binary.
>   So even if we could figure out a clear way to slices the dependency
>   tree so we can start building the root packages, it would be a manual
>   process build every package
>
>   - A subproblem is that lots of libraries only support building on
> Windows, or through Visual Studio only. We would have to create/port
> the upstream build scripts.
>
> - GUI applications are simply not supported on Linux. .NET has no
>   implementation for this. If you try and use the .NET SDK to build
>   something that uses the GUI APIs, it will simply error out.
>
> There's more discussion upstream at
> https://github.com/dotnet/core/issues/7443 and
> https://github.com/dotnet/source-build/discussions/2960
>

I'm a bit less concerned about the fact that Microsoft has eliminated
MonoForms and never provided a WPF/WinUI implementation. It's
annoying, but that's not the problem to solve right now.

Being able to ship things like Avalonia would at least reduce that
barrier for GUI app dev in .NET: https://avaloniaui.net/

> As a result of this, I am not sure where to even begin thinking about
> packaging applications :(
>
> Do you have any suggestions on the most important/useful applications
> that we should look at for prototyping this effort?
>

The main one on my radar right now is Jellyfin, but I also recently
saw a GNOME Circle app in C# called TubeConverter.



--
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Peter Boy]

> Am 01.06.2023 um 15:25 schrieb Jiri Vanek :
> 
>> ...
> Me, as end user application provider would rather `dnf install/update java` 
> then maintain 3rd aprty blob. At least the java is known to be working and on 
> Fedora and is built by trusted infrastructure (which I case to agree for 
> every other vendor). And I need all four javas as are currently shipped in 
> fedora.
> Me, as fedora dummy user do not care. I need system jdk working.
> Me, as fedora advanced user do not want to solve fedora-specific issues.
> Me as jdk maintainer cares, just count:
> jdk 8,11,17, latest and 21 - 5jdks. For 3-4 live fedoras. Each with 4 
> platforms. Lets skip the platforms, but they still count to both HW and human 
> cycles.
> That is  12-20 jdk binary builds per platform which have to be certified
> If we build once and repack, that would be just 4-5  binaries which needs to 
> be certified.
> If we would keep just system jdk then it  will not help at all:
> - we have to keep java-latest-openjdk because its bleeding edge technology 
> which fedora shoudl provide
> - next LTS, and thus next system jdk is always forked from 
> java-latest-openjdk => you have *two* jdks on 3-4 systems every time (thus 
> 6-8 certifications)
> - the system JDK is not constant but shifts. In worst scenario there will be 
> 3 system JDKs in 3 live fedoras, but msot likely there will be indeed 1-2 
> system JDKS. But that is still twho from above + 1-2 from this line, and thus 
> we are back on maintaining 3-4JDKS on 3-4 fedoras:(



From view of the Fedora Server Working Group I very much agree. Fedora Server 
is aimed at productive use, not merely as a toy or experimental kit for the 
latest software. Therefore we need software build on Fedora controlled 
infrastructure, with Fedora QA, etc. And we need backwards compatibility and 
support for older hardware. And that's no contradiction to Fedora's goal of 
always providing the latest software - as some like to claim.  

And it is a great advantage that all practically essential Java versions, and 
even 1.8, are available. This also corresponds to the "spirit" of Java as 
"enterprise grade“

And if the proposed change ensures that, then +1 

(And from my impression so far, it does. Nevertheless remaining a bit 
uncomfortable - server admins do not like unnecessary changes to mission 
critical components.)



--
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 and board member
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Kevin Kofler via devel]

Demi Marie Obenour wrote:
> I haven’t written Java in years, but my understanding is
> that AOT compilation has three major advantages:
> 
> 1. It reduces the size of total deliverables because the
>final executable only includes the libraries it needs.

This may be true for real AOT compilation where the result is really 
independent of a JRE (e.g., what GCJ, which is no longer maintained, used to 
produce by default), but if the AOT compilation requires you to bundle the 
whole JRE (and that is the only case where having a statically vs. 
dynamically linked JRE matters), the total deliverable size is going to be 
much larger.

> 2. It is the _only_ way to have decent performance on
>platforms where JIT compilation is forbidden.

That is also irrelevant in this thread: If it matters how the JRE is linked, 
the AOT-compiled output includes a bundled copy of the GNU/Linux JRE 
(otherwise why would it matter?), so it will only run on GNU/Linux, which is 
NOT a "platform where JIT compilation is forbidden". (There is only really 
one such platform, iOS with Apple's totalitarian app store rules.)

> 3. AOT-compiled apps start up faster and use less memory.

That part may be true, but there too, if we are talking about a solution 
that includes bundling the JRE, I doubt it.

> In short, an AOT-compiled application behaves much more
> like one that is written in a native language like C++,

And it turns out a lot of Java applications do not actually work that way. 
Which is why GCJ had a second mode, where, instead of building a binary with 
gcj just like with g++, you would instead AOT-compile every Java class 
individually to a .so in a special directory, then run the Java application 
"the Java way" with gij, and gij would behind the scenes look up the AOT-
compiled classes to speed up the interpreted run. IMHO a very ugly hack, but 
necessary because Java applications are NOT designed to be built like native 
applications (e.g., pure AOT compilation without a JIT and/or interpreter 
fallback cannot handle classes loaded at runtime, such as dynamically 
generated or downloaded class files). Many applications worked with GCJ only 
in that mixed mode.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Christian Schaller]

Yes, sorry about that meant now of course 

On Thu, Jun 1, 2023, 6:45 PM Demi Marie Obenour 
wrote:

> On 6/1/23 15:59, Christian Schaller wrote:
> > On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour  >
> > wrote:
> >> Why is a Flatpak a better choice for LibreOffice?
> >
> > There are a lot of ways to answer this, but from any upstream the
> advantage
> > of Flatpak is that it means package once and then deploy everywhere. So
> it
> > saves them work.
> >
> > From a Fedora perspective there is of course nobody telling anyone to not
> > maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but
> even
> > if nobody does we have a good option available in the Flathub package,
> > especially with the Flathub package not being verified as the official
> > package of upstream LibreOffice.
>
> Did you mean “now”?  “not” seems like the opposite of your intended
> meaning.
>
> > Having things as Flatpaks is also of value for us to enable long term
> > efforts such as Fedora Silverblue.
> >
> > Hope this answers your question.
> >
> > Christian--
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Sandro]

On 01-06-2023 21:59, Christian Schaller wrote:

On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour 
wrote:




Why is a Flatpak a better choice for LibreOffice?
--
Sincerely,
Demi Marie Obenour (she/her/hers)



There are a lot of ways to answer this, but from any upstream the advantage
of Flatpak is that it means package once and then deploy everywhere. So it
saves them work.

 From a Fedora perspective there is of course nobody telling anyone to not
maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even
if nobody does we have a good option available in the Flathub package,
especially with the Flathub package not being verified as the official
package of upstream LibreOffice.

Having things as Flatpaks is also of value for us to enable long term
efforts such as Fedora Silverblue.


A while ago, I send a similar announcement to this list regarding 
Bottles [1]. Upstream solely wants to focus on their Flatpak package and 
actively discourages packagers to package Bottles natively for several 
distributions.


They even go as far as not accepting bug reports unless the bug is 
reproducible in the official Flatpak package.


The discussion that followed offered some arguments for preferring 
native RPM packages over Flatpak packages. I'm not going to re-iterate 
these. They can be looked up in the archive [1].


However, it surprises me that for a package, that is part of the 
deliverables of Fedora releases, no coordination effort was made to 
transition the package from Red Hat maintenance to Fedora maintenance. I 
would even go as far as that this should have been submitted as a change 
proposal, seeing that the package is in every (live) ISO Fedora ships.


Instead the package is being dropped like a hot potato, without even the 
courtesy of an announcement beforehand [2].


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VJNMRCJBEBYDPA6P3HTUCNCYRY5HOYTX/#AT5MJ55BDOYKONMCZQ6JN43QIYHCNY2R

[2] not strictly required, but customary

PS: For anyone wondering what happened to Bottles, we managed to package 
all missing dependencies and update Bottles to the latest release, 
keeping it available as RPM package.


-- Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Christian Schaller]

On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour 
wrote:

>
>
> Why is a Flatpak a better choice for LibreOffice?
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
>

There are a lot of ways to answer this, but from any upstream the advantage
of Flatpak is that it means package once and then deploy everywhere. So it
saves them work.

>From a Fedora perspective there is of course nobody telling anyone to not
maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even
if nobody does we have a good option available in the Flathub package,
especially with the Flathub package not being verified as the official
package of upstream LibreOffice.

Having things as Flatpaks is also of value for us to enable long term
efforts such as Fedora Silverblue.

Hope this answers your question.

Christian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Demi Marie Obenour]

On 6/1/23 15:59, Christian Schaller wrote:
> On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour 
> wrote:
>> Why is a Flatpak a better choice for LibreOffice?
> 
> There are a lot of ways to answer this, but from any upstream the advantage
> of Flatpak is that it means package once and then deploy everywhere. So it
> saves them work.
> 
> From a Fedora perspective there is of course nobody telling anyone to not
> maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even
> if nobody does we have a good option available in the Flathub package,
> especially with the Flathub package not being verified as the official
> package of upstream LibreOffice.

Did you mean “now”?  “not” seems like the opposite of your intended meaning.

> Having things as Flatpaks is also of value for us to enable long term
> efforts such as Fedora Silverblue.
> 
> Hope this answers your question.
> 
> Christian-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Ivan Chavero]

I can help co-maintaining and I think I can bring another co-maintainer.
We've been creating custom libreoffice packages for a project so, we can
bring a little experience

El jue, 1 jun 2023 a las 14:17, Gwyn Ciesla via devel (<
devel@lists.fedoraproject.org>) escribió:

> I've taken ownership of libreoffice for the time being, at least to keep
> the lights on. Co-maintainers, as always, welcome.
>
>
>
> --
> Gwyn Ciesla
> she/her/hers
> 
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
>
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Thursday, June 1st, 2023 at 1:30 PM, Matthias Clasen <
> mcla...@redhat.com> wrote:
>
>
> > Hey,
> >
>
> > as you've probably seen, the LibreOffice RPMS have recently been
> orphaned, and I thought it would be good to explain the reasons
> > behind this.
> >
>
> > The Red Hat Display Systems team (the team behind most of Red Hat’s
> desktop efforts) has maintained the LibreOffice packages in Fedora for
> years as part of our work to support LibreOffice for Red Hat Enterprise
> Linux. We are adjusting our engineering priorities for RHEL for
> Workstations and focusing on gaps in Wayland, building out HDR support,
> building out what’s needed for color-sensitive work, and a host of other
> refinements required by Workstation users. This is work that will improve
> the workstation experience for Fedora as well as RHEL users, and which, we
> hope, will be positively received by the entire Linux community.
> >
>
> > The tradeoff is that we are pivoting away from work we had been doing on
> desktop applications and will cease shipping LibreOffice as part of RHEL
> starting in a future RHEL version. This also limits our ability to maintain
> it in future versions of Fedora.
> >
>
> > We will continue to maintain LibreOffice in currently supported versions
> of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of
> those releases (as published on the Red Hat website). As part of that, the
> engineers doing that work will contribute some fixes upstream to ensure
> LibreOffice works better as a Flatpak, which we expect to be the way that
> most people consume LibreOffice in the long term.
> >
>
> > Any community member is of course free to take over maintenance, both
> for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware
> that this is a sizable block of packages and dependencies and a significant
> amount of work to keep up with.
> >
>
> > Matthias
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Updates failing gating: it's due to the Koji outage

[Adam Williamson]

Hi folks! If you've noticed that an update currently fails gating for
no apparent reason, like this one:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-0714f51060

it's likely because of the ongoing Koji outage. Looking at the
greenwave response shows this:

"unsatisfied_requirements":[{"error":"Koji XMLRPC fault due to: ''planned 
outage see 
https://www.fedorastatus.org''","scenario":null,"sources":[],"subject_identifier":"input-remapper-2.0.0-2.fc38","subject_type":"koji_build","testcase":"failed-fetch-gating-yaml","type":"failed-fetch-gating-yaml"}]

which indicates the Koji outage is preventing greenwave from getting
the package's gating.yaml , which it needs to do in order to find any
package-specific gating requirements. This triggers an error which
counts as an unsatisfied requirement.

I guess we could improve Bodhi to make it clearer what's going on here,
I'll have to look into how much work that would be.

Once Koji is working again, gating issues should be resolved (though it
might have to wait for the 'gating cleanup' job which runs periodically
and forcibly re-calculates the gating status of open updates, because
there won't be any fedmsg that'll immediately trigger a re-
calculation...until that happens, the web UI will likely say the update
passed gating, but the backend will still think it failed, and it won't
be pushable).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Kevin Kofler via devel]

Gwyn Ciesla via devel wrote:
> I've taken ownership of libreoffice for the time being, at least to keep
> the lights on.

Also of the many dependencies?

As far as I can tell, from the list in the orphaned package report, all 
these are part of the LibreOffice stack:
> flute orphan   0 weeks 
> ago 
> hunspell  alexl, gnome-sig, mbarnes,   0 weeks ago
>   orphan, rhughes, rstrode 
> hunspell-af   orphan   0 weeks 
> ago 
> hunspell-ak   orphan   0 weeks 
> ago 
> hunspell-am   orphan   0 weeks 
> ago 
> hunspell-ast  orphan   0 weeks 
> ago 
> hunspell-az   orphan   0 weeks 
> ago 
> hunspell-be   orphan   0 weeks 
> ago 
> hunspell-ber  orphan   0 weeks 
> ago 
> hunspell-bg   orphan   0 weeks 
> ago 
> hunspell-br   orphan   0 weeks 
> ago 
> hunspell-ca   orphan   0 weeks 
> ago 
> hunspell-cop  orphan   0 weeks 
> ago 
> hunspell-csb  orphan   0 weeks 
> ago 
> hunspell-cv   orphan   0 weeks 
> ago 
> hunspell-cy   orphan   0 weeks 
> ago 
> hunspell-da   orphan   0 weeks 
> ago 
> hunspell-dsb  orphan   0 weeks 
> ago 
> hunspell-el   orphan   0 weeks 
> ago 
> hunspell-en   alexl, gnome-sig, mbarnes,   0 weeks 
> ago 
>   orphan, rhughes, rstrode 
> hunspell-eo   orphan   0 weeks 
> ago 
> hunspell-es   olea, orphan 0 weeks 
> ago 
> hunspell-et   orphan   0 weeks 
> ago 
> hunspell-fa   orphan   0 weeks 
> ago 
> hunspell-fj   orphan   0 weeks 
> ago 
> hunspell-fo   orphan   0 weeks 
> ago 
> hunspell-fr   orphan, remi 0 weeks 
> ago 
> hunspell-fur  orphan   0 weeks 
> ago 
> hunspell-fy   orphan   0 weeks 
> ago 
> hunspell-ga   orphan   0 weeks 
> ago 
> hunspell-gd   orphan   0 weeks 
> ago 
> hunspell-gl   orphan   0 weeks 
> ago 
> hunspell-grc  orphan   0 weeks 
> ago 
> hunspell-gv   orphan   0 weeks 
> ago 
> hunspell-haw  orphan   0 weeks 
> ago 
> hunspell-hil  orphan   0 weeks 
> ago 
> hunspell-hr   orphan   0 weeks 
> ago 
> hunspell-hsb  orphan   0 weeks 
> ago 
> hunspell-ht   orphan   0 weeks 
> ago 
> hunspell-hu   orphan   0 weeks 
> ago 
> hunspell-hy   orphan   0 weeks 
> ago 
> hunspell-ia   orphan   0 weeks 
> ago 
> hunspell-id   orphan   0 weeks 
> ago 
> hunspell-is   orphan   0 weeks 
> ago 
> hunspell-it   orphan   0 weeks 
> ago 
> hunspell-kk   orphan   0 weeks 
> ago 
> hunspell-km   orphan   0 weeks 
> ago 
> hunspell-ko   orphan   0 weeks 
> ago 
> hunspell-ku   orphan   0 weeks 
> ago 
> hunspell-ky   orphan   0 weeks 
> ago 
> hunspell-la   orphan   0 weeks 
> ago 
> hunspell-lb   orphan   0 weeks 
> ago 
> hunspell-ln   orphan   0 weeks 
> ago 
> hunspell-lt   orphan   0 weeks 
> ago 
> hunspell-mg

Re: Trying to strip a library

[Paul Grosu]

Hi Orion,

There are two ways to remove the debugging symbols:

1) strip --strip-debug your_library.so

2) objcopy --strip-debug your_library.so

Below is an example of both approaches:

1) Method using strip:

paul$ objdump --syms libfoo.so | grep debug
 ld  .debug_aranges 
 .debug_aranges
 ld  .debug_info
 .debug_info
 ld  .debug_abbrev  
 .debug_abbrev
 ld  .debug_line
 .debug_line
 ld  .debug_str 
 .debug_str
paul$ strip --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$

2) Method using objdump:

paul$ objdump --syms libfoo.so | grep debug
 ld  .debug_aranges 
 .debug_aranges
 ld  .debug_info
 .debug_info
 ld  .debug_abbrev  
 .debug_abbrev
 ld  .debug_line
 .debug_line
 ld  .debug_str 
 .debug_str
paul$ objcopy --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$

Are there other symbols you are looking to strip?

Hope it helps,
Paul

On Fri, Jun 2, 2023 at 12:11 AM Orion Poplawski  wrote:

> I'm trying to resolve this packaging issue with Lmod:
>
> https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/
>
> debuginfo
> BAD /usr/share/lmod/8.7.25/lib/tcl2lua.so in Lmod-8.7.25-2.fc38 on i686
> contains debugging symbols
>
> I've dealt with a couple of issues here:
>
> https://src.fedoraproject.org/rpms/Lmod/pull-request/2
>
> but despite all of my attempts the library does not appear to get stripped.
>
> In fact:
>
> ]$ strip -g
>
> /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1
>
> $ file
>
> /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1
> /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1:
>
> ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
> linked, BuildID[sha1]=aa1ea44979190d0cf530d350f8151ffafeab0f36, not
> stripped
>
> ?
>
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> IT Systems Manager 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Trying to strip a library

[Orion Poplawski]

I'm trying to resolve this packaging issue with Lmod:

https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/

debuginfo
BAD /usr/share/lmod/8.7.25/lib/tcl2lua.so in Lmod-8.7.25-2.fc38 on i686 
contains debugging symbols


I've dealt with a couple of issues here:

https://src.fedoraproject.org/rpms/Lmod/pull-request/2

but despite all of my attempts the library does not appear to get stripped.

In fact:

]$ strip -g 
/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1


$ file 
/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1
/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1: 
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically 
linked, BuildID[sha1]=aa1ea44979190d0cf530d350f8151ffafeab0f36, not stripped


?


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libnfs soname bump

[Xavier Bachelot via devel]

Hi,

I've updated libnfs from version 4.0.0 to version 5.0.2 in rawhide, 
which implies a soname bump.


The build was done in f39-build-side-68410 sidetag.

The following packages need to be rebuild:
- qemu
- gvfs
- xine-lib

I have already taken care of xine-lib, and made a scratch build for both 
gvfs and qemu, which were successful.

Please let me know once qemu and gvfs have been rebuilt in the sidetag.

Regards,
Xavier






___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libnfs soname bump

[Richard W.M. Jones]

Never mind, too many dashes.

qemu is building now:

https://koji.fedoraproject.org/koji/taskinfo?taskID=101710059

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libnfs soname bump

[Tom Stellard]

On 6/1/23 00:33, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 09:05:23AM +0200, Xavier Bachelot wrote:

Hi,

I've updated libnfs from version 4.0.0 to version 5.0.2 in rawhide,
which implies a soname bump.

The build was done in f39-build-side-68410 sidetag.

The following packages need to be rebuild:
- qemu
- gvfs
- xine-lib

I have already taken care of xine-lib, and made a scratch build for
both gvfs and qemu, which were successful.
Please let me know once qemu and gvfs have been rebuilt in the sidetag.


Remind me what the command is to build in a side tag?  The usual
one doesn't work ...

$ fedpkg build ---target=f39-build-side-68410
...
fedpkg: error: unrecognized arguments: ---target=f39-build-side-68410



Too many dashes ?


Rich.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libnfs soname bump

[Richard W.M. Jones]

On Thu, Jun 01, 2023 at 09:05:23AM +0200, Xavier Bachelot wrote:
> Hi,
> 
> I've updated libnfs from version 4.0.0 to version 5.0.2 in rawhide,
> which implies a soname bump.
> 
> The build was done in f39-build-side-68410 sidetag.
> 
> The following packages need to be rebuild:
> - qemu
> - gvfs
> - xine-lib
> 
> I have already taken care of xine-lib, and made a scratch build for
> both gvfs and qemu, which were successful.
> Please let me know once qemu and gvfs have been rebuilt in the sidetag.

Remind me what the command is to build in a side tag?  The usual
one doesn't work ...

$ fedpkg build ---target=f39-build-side-68410 
...
fedpkg: error: unrecognized arguments: ---target=f39-build-side-68410

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Richard W.M. Jones]

On Wed, May 31, 2023 at 11:58:57PM +0200, Jun Aruga (he / him) wrote:
> This is exciting news related to the RISC-V ecosystem.
> I expect that the RISC-V Software Ecosystem (RISE) Project will be a
> leading organization to help open source projects by providing free
> RISC-V CI services to them, and sponsoring the free RISC-V SSH servers
> on the clouds to them. It is like what Works on Arm organization[1]
> has currently been doing for the Arm ecosystem.
> 
> Industry Leaders Launch RISE to Accelerate the Development of Open
> Source Software for RISC-V
> https://linuxfoundation.eu/newsroom/rise-project-launches-to-accelerate-development-of-risc-v
> 
> [1] https://www.arm.com/markets/computing-infrastructure/works-on-arm

Red Hat is a member.  In fact there's an (internal) kick-off meeting
for RISE today which I'll be attending.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Neal Gompa]

On Thu, Jun 1, 2023 at 6:18 AM Omair Majid  wrote:
>
> Hey,
>
> Neal Gompa  writes:
>
> > Keep in mind that this isn't exactly the first time we've done this
> > either: the .NET runtime is similarly screwy for its bootstrap
> > process, and that's split across a couple of source packages.
> >
> > At this point, we hold our noses and hope for the best. At least
> > there's a chance to reduce the pain with .NET over time as the Red Hat
> > .NET folks work to improve upstream. There's basically zero chance for
> > improvement with OpenJDK because of the nature of the upstream and how
> > old and crufty they are.
>
> I know it's tangential to the main discussion, but since .NET was called
> out by name, I would like to get your thoughts on this. What would you
> say are the biggest concerns with the .NET setup?
>
> Here's how I understand the current state. There's a single source
> package for each major version of .NET (dotnet6.0, dotnet7.0.). That
> source is compiled into the complete .NET SDK+Runtime for each version.
> There are no source or binary dependencies between versions. Each
> version is built/updated independently. Only the first build for each
> major version requires a full bootstrap (using prebuilt binaries), but
> that's a one time. Subsequent builds of each .NET major version use the
> previous build of that major version of .NET.
>
> With that context, what primary concerns do you think we should be
> focusing on?
>

That's actually a lot better than it was when I helped with dotnet
package review and bootstrap with 3.1.

The main worry I have is how we're going to be able to build dotnet
for a new architecture when nothing exists. RISC-V is the next big
architecture, but the build for that will be difficult.

It would also be good to have packaging guidelines for .NET
applications, since there's a number of server and desktop Linux apps
written in .NET languages that people would want to bring to Fedora.



--
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Richard W.M. Jones]

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:
> This was heavily discussed when we moved to portable build in rpms -
> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> Long story short yes, if yo wish to distribute jdk *binary* it have
> to pass java compliance suite.

It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it
from Fedora.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Herald Yu

[Betty Liu]

Hi I also come from China ~ I'm Betty and now I'm learning about how to become 
a packager (so I think it's not the time to do a self-introduction in devel now 
hhh)

Nice to have someone come from the same country! If you have the time maybe you 
can teach me about packaging and community! You can find more about me here 
https://acyanbird.com/ www
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Jun Aruga (he / him)]

> Red Hat is a member.  In fact there's an (internal) kick-off meeting
> for RISE today which I'll be attending.

I saw that Red Hat is a member of the RISE project on the page.
And it's really great to see that you will be attending the kick-off
meeting. Thank you for that. I am looking forward to seeing your
updates about it if you have something to share publicly. It's a great
step of the RISC-V to be a first class in Fedora Linux.

--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Robert Marcano via devel]

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it
from Fedora.

Rich.



It is the same discussion about Firefox that is already settled I think. 
The JVM code is open source, even free software. The trademark isn't. 
Mozilla doesn't allow anyone to call the browser Firefox without some rules.


Red Hat want to run the tests because Java corporate users want that, so 
Red Hat does it and at the same time helps to have a more robust Java 
ecosystem.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Richard W.M. Jones]

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:
> On 6/1/23 3:51 AM, Richard W.M. Jones wrote:
> >On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:
> >>This was heavily discussed when we moved to portable build in rpms -
> >>https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> >>Long story short yes, if yo wish to distribute jdk *binary* it have
> >>to pass java compliance suite.
> >
> >It sounds like the problem is the software isn't really open source
> >because it has some field of use restrictions.  The best plan would be
> >to change this upstream, and if that isn't possible then to remove it
> >from Fedora.
> >
> >Rich.
> >
> 
> It is the same discussion about Firefox that is already settled I
> think. The JVM code is open source, even free software. The
> trademark isn't. Mozilla doesn't allow anyone to call the browser
> Firefox without some rules.

Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)

> Red Hat want to run the tests because Java corporate users want
> that, so Red Hat does it and at the same time helps to have a more
> robust Java ecosystem.

That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Robert Marcano via devel]

On 6/1/23 8:33 AM, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it

>from Fedora.


Rich.



It is the same discussion about Firefox that is already settled I
think. The JVM code is open source, even free software. The
trademark isn't. Mozilla doesn't allow anyone to call the browser
Firefox without some rules.


Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)


Red Hat want to run the tests because Java corporate users want
that, so Red Hat does it and at the same time helps to have a more
robust Java ecosystem.


That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.



All this change is about the burden of maintaining so many OpenJDK 
branches as packages in FEdora. Maybe Fedora should stop distributing 
ancient Java versions as one of our missions is to be cutting edge, 
maybe we are still encouraging too many projects to stay running on Java 8.


I am saying this as some that would be affected if Java 8 isn't packaged 
anymore, I still need to develop and test some things with Java 8 
because at work we have some customers still running ancient hardware 
and have been a pain to make them move to modern distributions. So I 
will have to us another universal OpenJDK build (like Temurin)


Maybe Fedora should just package the latest JDK needed for Android 
development and the latest LTS version. An even the Android (11 I think) 
could be skipped because Android Studio includes a build of it. If there 
are packages still requiring old things, help to update them could be 
offered by packagers, or dropped from the distribution.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Kevin Kofler via devel]

Jiri Vanek wrote:
> At elast providing ofjava/openjdk is definitley out of scope.

I do not think a Provides would be a trademark violation. It is a part of 
the standard procedure for renaming a package. But you would have to ask Red 
Hat Legal for a definite answer. I am not a lawyer.

That said, there might not even be a trademark issue at all, at least for 
"OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing 
to:
https://openjdk.org/legal/openjdk-trademark-notice.html

> As you wrote about the liberty of choice between temurins and fdeoara ona
> - can you be a bit more specific? Afaik if the builds are similar, we have
> mcuh less possibility of some fedora-specific bug.

But it also means that I no longer have the option to use a Java that does 
not bundle several libraries, possibly including security vulnerabilities, 
bloating its size, and likely reducing system integration (there have been 
concerns about, e.g., worse fontconfig integration in the discussion of your 
previous Change proposal). There is now just the "choice" between a Fedora 
package with everything bundled and third-party packages with also 
everything bundled.

> I once wrote,m that wworked 10years to enable dynamic linking, and yes,
> all is upstream, but there are limitations which can not be overtaken -
> major is ahead of tie comilation. If you can do it right, you cnanot have
> dyanmic linking.

Wait, Java does real AOT compilation now? Or are we talking about that 
strange "feature" you already brought up in the old discussion, where you 
basically just prepend a JRE to a JAR and ship that as a "compiled" 
executable? That "feature", to be honest, I had never heard of before you 
folks brought it up.

As far as I can tell, nobody in the Java world uses it. It breaks the "write 
once, run anywhere" promise and brings us no real advantage over having the 
JRE and the JAR separate.

It is definitely not useful for me because our customers all run Windows, 
not Fedora or any other GNU/Linux. So really it makes no difference for me 
whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking) 
or on all GNU/Linux (static linking), they will not run on our customers' 
computers anyway, making that "feature" entirely useless either way.

We have a few ways to deploy our JARs to our customers, but none of them 
involves turning them into native executables through (either real or fake 
as described above) AOT compilation.

> The goal should still be to have fedora rpms properly integrated in
> fedora, and usable, as any other java onthe world, without hacks.

Sorry, but I believe that the old packaging was exactly that, "properly 
integrated" and "without hacks", whereas I have to politely disagree about 
the new packaging having those properties.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

On 5/31/23 20:38, Mattia Verga via devel wrote:

Il 30/05/23 20:37, Aoife Moloney ha scritto:

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 the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. Jdks in fedora are already static, and we repack portable
tarball into rpms. Currently, the portbale tarball is built for each
Fedora and Epel version. Goal here is to build each jdk
(8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
repack in all live fedoras.


If I understand this correctly, this just means that java package built
on Fedora x-2 will be tagged also in Fedora x-1, Fedora x and Rawhide.
Am I correct?



No. I'm to scared to seal integration by building rpms once, and jsut retag. So 
we choosen middle way - to build once portable packages, which is build of 
openjdk, resulting to simply tar.xz.
That rpm with only tarball in it have no integration. You can unpack that 
anywhere and run its java.

This rpm with tarbll is build reqired by rpms, which just reapck its content to 
subpakcages as we were used until now. The portable rpm with tarball is what is 
going to be tagged to all fedoras. The integration rpms will reamin per-fedora.


If so, maybe the proposal needs a better wording rather than "repack in
all live fedoras", as that sounds like RPMs are "repacked" in some way,
but the truth is that the same RPM is made available in several Fedora
repositories.


so no :)

TY!


Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

Hi Kevin!

I read all your posts.
You are mroevoer correct with everything, exept simple renaming of packages,. 
I'mnot sure it may work as strightforward. At elast providing ofjava/openjdk is 
definitley out of scope.
As you wrote about the liberty of choice between temurins and fdeoara ona - can 
you be a bit more specific? Afaik if the builds are similar, we have mcuh less 
possibility of some fedora-specific bug.
I once wrote,m that wworked 10years to enable dynamic linking, and yes, all is 
upstream, but there are limitations which can not be overtaken - major is ahead 
of tie comilation. If you can do it right, you cnanot have dyanmic linking.

The goal should still be to have fedora rpms properly integrated in fedora, and usable, as any other java onthe world, without hacks. I'm pretty confident that that is what wilbe dleivered at the end - that user will not find any 
regression, and willa ctually find soe things improved.



Thanx!!
  J.

On 6/1/23 05:41, Kevin Kofler via devel wrote:

Neal Gompa wrote:

Because the alternative is no Java runtime at all, and that's even
less acceptable.


I do not see why the way the packaging used to work all these years could
not be kept unchanged.

The only issues that were pointed out were related to the Java TCK (that it
takes too long to run on every build, and that sometimes system libraries
cause failures in some obscure test that are hard to debug), to which the
obvious answer is to just stop running it and call the package something
other than the current java-*-openjdk. (My understanding as a non-lawyer is
that it should be enough to change the package Name and the Summary and
%description. The java-*-openjdk name could still be Obsoleted/Provided, and
the binaries do not have to be renamed either.)

 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2023-06-02 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10449/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

On 6/1/23 13:33, Kevin Kofler via devel wrote:

Jiri Vanek wrote:

At elast providing ofjava/openjdk is definitley out of scope.


I do not think a Provides would be a trademark violation. It is a part of
the standard procedure for renaming a package. But you would have to ask Red
Hat Legal for a definite answer. I am not a lawyer.

That said, there might not even be a trademark issue at all, at least for
"OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing
to:
https://openjdk.org/legal/openjdk-trademark-notice.html


As you wrote about the liberty of choice between temurins and fdeoara ona
- can you be a bit more specific? Afaik if the builds are similar, we have
mcuh less possibility of some fedora-specific bug.


But it also means that I no longer have the option to use a Java that does
not bundle several libraries, possibly including security vulnerabilities,


Nope. That is actually somehting what should get better. Java is good security 
issues handling.


bloating its size, and likely reducing system integration (there have been
concerns about, e.g., worse fontconfig integration in the discussion of your


And have it proven to be true? I doubt.


previous Change proposal). There is now just the "choice" between a Fedora
package with everything bundled and third-party packages with also
everything bundled.


I once wrote,m that wworked 10years to enable dynamic linking, and yes,
all is upstream, but there are limitations which can not be overtaken -
major is ahead of tie comilation. If you can do it right, you cnanot have
dyanmic linking.


Wait, Java does real AOT compilation now? Or are we talking about that
strange "feature" you already brought up in the old discussion, where you
basically just prepend a JRE to a JAR and ship that as a "compiled"
executable? That "feature", to be honest, I had never heard of before you
folks brought it up.


It started with jlink, and then javaaot had shown the way, and now this lives 
in graal and madrel/quarkus projects. And even spring boot is working on theirs 
AOTcompiler.
I'm only observer for Mandrel project, but it seems to be working, although 
still quite a lot of work is ahead.



As far as I can tell, nobody in the Java world uses it. It breaks the "write
once, run anywhere" promise and brings us no real advantage over having the
JRE and the JAR separate.


I agree with you, adn I dont like the aot of java. However business seems to be 
going there, otherwise several big companyes would not invest so heavily to 
graal, mandrel, quarkus and springboot.
The benefits and reasoning are disputable. As I'm on your side on this I can 
not defend them.
Still, meas casual javadevloper, am delivering all - jars, wars, apks, jlinked iamges and also aot compiled binaries as needed,a s each is usefull for different customer cases. Untill static build was introduced to fedora, I had to use 33rd 
party java for jlinked and aot compiled images.




It is definitely not useful for me because our customers all run Windows,
not Fedora or any other GNU/Linux. So really it makes no difference for me
whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking)
or on all GNU/Linux (static linking), they will not run on our customers'
computers anyway, making that "feature" entirely useless either way.

We have a few ways to deploy our JARs to our customers, but none of them
involves turning them into native executables through (either real or fake
as described above) AOT compilation.


The goal should still be to have fedora rpms properly integrated in
fedora, and usable, as any other java onthe world, without hacks.


Sorry, but I believe that the old packaging was exactly that, "properly
integrated" and "without hacks", whereas I have to politely disagree about
the new packaging having those properties.


The integration wll remain intact. But I gusess we disagree on definition on 
integration.
The "only" take away are static linkings of java-crucial libraries (and my opinion as JDK developer is still that it is better), and now older build chain will be added. Except the new flags and gcc - which were sometimes hard to adapt, and 
we excluded most of them -  I do no see much lost.


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Panu Matilainen]

On 6/1/23 15:43, Robert Marcano via devel wrote:

On 6/1/23 8:33 AM, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it

>from Fedora.


Rich.



It is the same discussion about Firefox that is already settled I
think. The JVM code is open source, even free software. The
trademark isn't. Mozilla doesn't allow anyone to call the browser
Firefox without some rules.


Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)


Red Hat want to run the tests because Java corporate users want
that, so Red Hat does it and at the same time helps to have a more
robust Java ecosystem.


That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.



All this change is about the burden of maintaining so many OpenJDK 
branches as packages in FEdora. Maybe Fedora should stop distributing 
ancient Java versions as one of our missions is to be cutting edge, 
maybe we are still encouraging too many projects to stay running on Java 8.


I am saying this as some that would be affected if Java 8 isn't packaged 
anymore, I still need to develop and test some things with Java 8 
because at work we have some customers still running ancient hardware 
and have been a pain to make them move to modern distributions. So I 
will have to us another universal OpenJDK build (like Temurin)


Maybe Fedora should just package the latest JDK needed for Android 
development and the latest LTS version. An even the Android (11 I think) 
could be skipped because Android Studio includes a build of it. If there 
are packages still requiring old things, help to update them could be 
offered by packagers, or dropped from the distribution.


+1

This sounds much, much more Fedora than the proposal at hand.

Customers running ancient hardware is a problem for the RHEL space, not 
Fedora.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

All this change is about the burden of maintaining so many OpenJDK branches as packages in FEdora. Maybe Fedora should stop distributing ancient Java versions as one of our missions is to be cutting edge, maybe we are still encouraging too 
many projects to stay running on Java 8.


I am saying this as some that would be affected if Java 8 isn't packaged anymore, I still need to develop and test some things with Java 8 because at work we have some customers still running ancient hardware and have been a pain to make 
them move to modern distributions. So I will have to us another universal OpenJDK build (like Temurin)


Maybe Fedora should just package the latest JDK needed for Android development and the latest LTS version. An even the Android (11 I think) could be skipped because Android Studio includes a build of it. If there are packages still 
requiring old things, help to update them could be offered by packagers, or dropped from the distribution.



To reduce number of jdks remains an option, but few hints:
Me, as end user application provider would rather `dnf install/update java` then maintain 3rd aprty blob. At least the java is known to be working and on Fedora and is built by trusted infrastructure (which I case to agree for every other 
vendor). And I need all four javas as are currently shipped in fedora.

Me, as fedora dummy user do not care. I need system jdk working.
Me, as fedora advanced user do not want to solve fedora-specific issues.
Me as jdk maintainer cares, just count:
jdk 8,11,17, latest and 21 - 5jdks. For 3-4 live fedoras. Each with 4 
platforms. Lets skip the platforms, but they still count to both HW and human 
cycles.
That is  12-20 jdk binary builds per platform which have to be certified
If we build once and repack, that would be just 4-5  binaries which needs to be 
certified.
If we would keep just system jdk then it  will not help at all:
 - we have to keep java-latest-openjdk because its bleeding edge technology 
which fedora shoudl provide
 - next LTS, and thus next system jdk is always forked from java-latest-openjdk 
=> you have *two* jdks on 3-4 systems every time (thus 6-8 certifications)
 - the system JDK is not constant but shifts. In worst scenario there will be 3 system JDKs in 3 live fedoras, but msot likely there will be indeed 1-2 system JDKS. But that is still twho from above + 1-2 from this line, and thus we are 
back on maintaining 3-4JDKS on 3-4 fedoras:(


All is much more then buils once and repack everywhere:(

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

On 6/1/23 15:08, Panu Matilainen wrote:

On 6/1/23 15:43, Robert Marcano via devel wrote:

On 6/1/23 8:33 AM, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it

>from Fedora.


Rich.



It is the same discussion about Firefox that is already settled I
think. The JVM code is open source, even free software. The
trademark isn't. Mozilla doesn't allow anyone to call the browser
Firefox without some rules.


Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)


Red Hat want to run the tests because Java corporate users want
that, so Red Hat does it and at the same time helps to have a more
robust Java ecosystem.


That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.



All this change is about the burden of maintaining so many OpenJDK branches as packages in FEdora. Maybe Fedora should stop distributing ancient Java versions as one of our missions is to be cutting edge, maybe we are still encouraging 
too many projects to stay running on Java 8.


I am saying this as some that would be affected if Java 8 isn't packaged anymore, I still need to develop and test some things with Java 8 because at work we have some customers still running ancient hardware and have been a pain to make 
them move to modern distributions. So I will have to us another universal OpenJDK build (like Temurin)


Maybe Fedora should just package the latest JDK needed for Android development and the latest LTS version. An even the Android (11 I think) could be skipped because Android Studio includes a build of it. If there are packages still 
requiring old things, help to update them could be offered by packagers, or dropped from the distribution.


+1

This sounds much, much more Fedora than the proposal at hand.

Customers running ancient hardware is a problem for the RHEL space, not Fedora.


See my reply I ha just sent to Robert.

Thanx!

 J.


 - Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

On 5/31/23 20:02, Daniel P. Berrangé wrote:

On Wed, May 31, 2023 at 07:38:38PM +0200, Jiri Vanek wrote:

Can you clarify this a bit?  It sounds like some versions of the JDK in
Fedora will actually be built in EPEL.  I feel that all Fedora packages
should actually built for Fedora, not RHEL.

Also, what exactly does "latest live EPEL" mean - how is 8 the latest?

I guess basically, can you further explain/clarify exactly which
versions of what OS which JDKs will be built on, and when those versions
will change.



Jdk is designed, to be severely forward comaptible from os where it was built.
So jdk8, 11 and 17 would be build in oldest live fedora, and repacked
everywhere. The idea is to build them on oldest viable system, as we
can guarantee they will run ok in newer Fedroas..
java-latest-openjdk however, is built also for epel8 and elep9. Thus
logically the oldest system where we can built it to repack it everywhere
is el8. Then it can be reapcked for el8,el9, and all live fedoras.


IIRC, RHEL-8 forked from Fedora in circa F28 timeframe. Directly
comparing RHEL-8 content to Fedora is a bit of a fools errand since
RHEL does rebase certain packages periodically, but a decent chunk
of RHEL-8 is 5 years old at this point. The most notable part is
the compiler toolchain on RHEL-8 is GCC 8.x, which is 5 major
releases behind what F39 rawhide uses, and 4 major release behind
what F37 uses.

RHEL-8 also has a long lifetime left, and thus so does EPEL8. By
building JDK on EPEL8, we're fixing the toolchain for JDK in Fedora
on a version already 5 years out of date, and by the time EPEL8 goes
away, the toolchain will be 10+ years out of date.

By building JDK on the oldest stable Fedora release, we're fixing the
toolchain on a version that's never going to be much more then 1 year
out of date.

Same applies to compiler toolchain flags, though where the flags don't
depend on GCC version that can be partially mitigated in the JDK spec.

Overall, I find the idea of basing Fedora builds on oldest EPEL quite
challenging to accept, due to the age differences. It feels contrary
to Fedora goal of always being on, or at least very near, the cutting
edge.


I do not have hard requirement to build java-latest-openjdk on epel8 and
repack everywhere, but it gave sense. If the hard demand will be to build
also java-latest-opnejdk in oldest fedora, and repack in all fedoras, and
built it in oldest epel, and repack in all epels, then it gave somehow
sesnse too. Although I would conisdered it a bit wasted cycle, it is
acceptable.


IMHO it'd be more palatable for the RHEL (EPEL) build stream to be separate
from the Fedora build stream. While RHEL and Fedora share heritage, they are
ultimately different distros with different goals and needs.



Thanx for an input!

One important clarification whcih I will somehow try to include to proposal.
The epel thing is valid only for java-latest-openjdk, which is STS. It is much more likley, thet future jdk will not be buildable on epel8, and thus we wills top building it there as we did with epel7. Then we wll shift the build root to 
the epel9 and so on.


Yet again thanx for input.

 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

On 5/31/23 19:58, Chris Adams wrote:

Once upon a time, Jiri Vanek  said:

I have fixed typo in the proposal " Should be built in oldest live EPEL" instead of 
" Should be built in latest live EPEL", which was wrong.


At the moment though, the oldest live EPEL is 7, not 8.


Right. And we are nto building java-latest-openjdk here, becasue it is no 
longerbuildable by its toolcahin.
Once java-altest-openjdk (which is the only epel based) will be notbuildable in 
el8, which will stillbe live I guess, we weill dropit there,and move it to 
epel9.And so on, untill ethernity.

Will enchance proposal for this. TY!



I do not have hard requirement to build java-latest-openjdk on epel8
and repack everywhere, but it gave sense. If the hard demand will be
to build also java-latest-opnejdk in oldest fedora, and repack in
all fedoras, and built it in oldest epel, and repack in all epels,
then it gave somehow sesnse too. Although I would conisdered it a
bit wasted cycle, it is acceptable.


I think building for Fedora in Fedora would moderate the concerns about
old compiler/flags/etc., because the oldest Fedora at any point is about
a year old.  The oldest EPEL (7) is currently approaching 9 years old,
and even the oldest you listed (8) is 4 years old.

It would also help with reproducibility.  EPEL is built against RHEL,
which is not freely available (yes, there are rebuilds, there are free
limited developer licenses, etc., but it's not directly easy for someone
else to exactly reproduce the EPEL build environment).  That's okay for
EPEL builds, but I personally feel it would be more acceptable to build
Fedora packages on Fedora.



--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-XML-RegExp] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-XML-RegExp` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-RegExp/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Tk] PR #1: Update license to SPDX format

[Xavier Bachelot]

xavierb merged a pull-request against the project: `perl-Tk` that you are 
following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Tk/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-XML-DOM] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-XML-DOM` that you 
are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-DOM/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Tk] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Tk` that you are 
following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Tk/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Text-WrapI18N] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Text-WrapI18N` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Text-WrapI18N/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-XML-TokeParser] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-XML-TokeParser` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-TokeParser/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Unicode-LineBreak] PR #1: Update license to SPDX format

[Xavier Bachelot]

xavierb merged a pull-request against the project: `perl-Unicode-LineBreak` 
that you are following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Unicode-LineBreak/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Tie-IxHash] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Tie-IxHash` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Tie-IxHash/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Unicode-LineBreak] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Unicode-LineBreak` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Unicode-LineBreak/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Tie-IxHash] PR #1: Update license to SPDX format

[Tom Callaway]

spot merged a pull-request against the project: `perl-Tie-IxHash` that you are 
following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Tie-IxHash/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2211672] New: perl-Net-DNS-1.39 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2211672

Bug ID: 2211672
   Summary: perl-Net-DNS-1.39 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-DNS
  Keywords: FutureFeature, Triaged
  Assignee: paul.wout...@aiven.io
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: ka...@ucw.cz, mspa...@redhat.com,
paul.wout...@aiven.io,
perl-devel@lists.fedoraproject.org, rstr...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.39
Upstream release that is considered latest: 1.39
Current version/release in rawhide: 1.38-2.fc39
URL: http://search.cpan.org/dist/Net-DNS/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3147/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Net-DNS


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2211672
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2211672] perl-Net-DNS-1.39 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2211672



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.39-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=101712354


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2211672
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2211672] perl-Net-DNS-1.39 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2211672



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1968305
  --> https://bugzilla.redhat.com/attachment.cgi?id=1968305=edit
Update to 1.39 (#2211672)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2211672
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Parallel-ForkManager] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: 
`perl-Parallel-ForkManager` that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Parallel-ForkManager/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Scalar-List-Utils] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Scalar-List-Utils` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Sys-CPU] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Sys-CPU` that you 
are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sys-CPU/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Text-CharWidth] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Text-CharWidth` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Text-CharWidth/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Test-FailWarnings] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Test-FailWarnings` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Test-FailWarnings/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Text-Diff] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Text-Diff` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Text-Diff/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-HTML-Tree] PR #1: Update license to SPDX format

[Tom Callaway]

spot merged a pull-request against the project: `perl-HTML-Tree` that you are 
following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-HTML-Tree/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-File-HomeDir] PR #1: Update license to SPDX format

[Tom Callaway]

spot merged a pull-request against the project: `perl-File-HomeDir` that you 
are following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-File-HomeDir/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-File-Which] PR #1: Update license to SPDX format

[Tom Callaway]

spot merged a pull-request against the project: `perl-File-Which` that you are 
following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-File-Which/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Mail-Sender] PR #1: Update license to SPDX format

[Tom Callaway]

spot merged a pull-request against the project: `perl-Mail-Sender` that you are 
following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Mail-Sender/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue