Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
quires` on the system JDK is kept for Java applications. Would this be clearer if it says "the JRE from the system JDK"? Since the apps are not actually pulling in the full JDK itself. You are right, throughout these sections I was talking mostly about the runtime environment rather than the development kit. Best regards, -- ___ 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 -- Marián Konček -- ___ 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: Review request: mruby
Nice catch, using it and removing the line "conf.enable_debug" makes the
build use the proper flags. However, I still don't know how to tell Rake
to add a `-Wl,-soname,...` option to each .so separately.
On 16. 4. 2024 18:11, Jarek Prokop wrote:
On 4/16/24 4:16 PM, Marián Konček wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=2275294
I applied downstream changes which build a shared object (upstream
provides no way of doing so, only a static library).
Upstream provides many ways to compile to many targets including using
solibs, have a look:
https://github.com/mruby/mruby/tree/3.3.0/build_config
One can even write it themselves if the upstream ones doesn't cater to
one's needs of their goal.
Definitions in that directory can be referred to in MRUBY_CONFIG
variable used in rake command as the filename without the extension,
for example to build a shared library:`rake MRUBY_CONFIG=host-shared
all `
Though in my small tests some adjustment for the upstream code would
be needed to have it respect Fedora {C,CXX,LD}FLAGS properly, but I
might've missed something.
Regards,
Jarek
--
___
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
--
Marián Konček
--
___
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
Review request: mruby
https://bugzilla.redhat.com/show_bug.cgi?id=2275294 I applied downstream changes which build a shared object (upstream provides no way of doing so, only a static library). -- Marián Konček -- ___ 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
Note that mingw-* packages currently in Fedora install into the
/usr/i686-w64-mingw32/ or /usr/x86_64-w64-mingw32/ directories.
This is a different topic but if each archful package installed its
files into a directory containing the arch name, it would allow parallel
installability without configuring dnf and possibly make it more
convenient for cross-platform development.
On 2. 1. 2024 16:23, Vít Ondruch wrote:
Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote:
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be
nested in a place such as
`/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
`/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
universal.
Adding directories to the /usr sub-space generally gets bogged down
into 'You are polluting my name-space' arguments which get no-where
because some of the people getting angry is having to live with some
3rd party rules and regulations which stipulated how things look and
will only get updated once a decade or so. [The same goes with
subdirectories in /usr/bin etc where it causes similar problems.]
There tends to be no 'general' case which works unless it gets
'agreed' upon by some outside of the distro body that publishes
'versioned' standards.
Checking what Debian does, they have paths such as
`/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
Vít
Vít
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.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 todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.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
--
Marián Konček
--
___
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
Intention to update httpcomponents-core and httpcomponents-client to major version 5
I will provide compat packages of version 4. Review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2254309 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2254310 -- Marián Konček -- ___ 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
org.eclipse.Java flatpak crashes
I installed Eclipse from https://flathub.org/apps/org.eclipse.Java on my F38 KDE Lenovo T14 (FS = btrfs). I reported this issue: https://github.com/flathub/org.eclipse.Java/issues/78 I tried to debug it using strace, but Flatpaks are not easy to debug. I have noticed many error messages, and not sure which one of them is fatal. What is strange is that the Flatpak seems to run normally on my other laptop T480S also with Fedora 38 KDE (FS = ext4). -- Marián Konček ___ 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: Orphaned packages looking for new maintainers
Hi, I want to let you know that all packages depending on maven-clean-plugin can most probably just use: %prep ... %pom_remove_plugin :maven-clean-plugin and live happily after. I am not aware of any purpose of maven-clean-plugin for Fedora package builds. On 12. 9. 2023 12:54, Markku Korkeala wrote: On Mon, Sep 04, 2023 at 05:10:55PM +0200, Miro Hrončok wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2023-08-21.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change maven-clean-pluginmizdebsk, mkulik, orphan 4 weeks ago Hi all, I took maven-clean-plugin as some of my packages depend on it. Best wishes, Markku ___ 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 -- Marián Konček ___ 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
Request to review a MinGW subpackges in libsodium
I opened a PR adding mingw subpackages to libsodium according to my best knowledge (which is not too large related to mingw packaging): https://src.fedoraproject.org/rpms/libsodium/pull-request/3 I talked with the maintainer and it could be accepted, but I would like someone more experienced from https://fedoraproject.org/wiki/MinGW to take a look and tell me if i missed some simplifications. Thanks. -- Marián Konček ___ 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: Color Bash Prompt (System Wide)
I actually copy-paste the Debian prompt since Debian Jessie on my systems. Even though it uses blue-green colors, I can see it very well on both white and black background. I think it would be nicer if we played around with several options and have the user have a simple way of choosing. There are many variants, some using git info, some using exit codes and so... On 7. 7. 2023 14:56, Chris Adams wrote: Once upon a time, Vít Ondruch said: Shouldn't blue be the default for Fedora? Blue is probably a bad idea in a prompt, as the human eye doesn't perceive blue as strongly as green. The prompt isn't about art/style, it's purely about functionality. -- Marián Konček ___ 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: more distinct default bash prompt?
AFAIK Gnome Terminal is the only terminal that uses white background by default. To my knowledge, all the other terminals use black background. On 26. 5. 2023 8:50, Barry wrote: On 25 May 2023, at 16:58, stan via devel wrote: I find the green too bright, I would prefer it with a little more black in it. The colours that a particular users sees on particular hardware will vary a large amount. Also the inability of CLI code to know if dark mode is in used or not means default colour choices can make text difficult to read. Barry ___ 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 -- Marián Konček ___ 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
Review request: glsl-language-server
I would like to add this package to Fedora to enable LSP support for OpenGL Shading Language. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2208531 My PR for upstream KDE text editor Kate has already been merged: https://invent.kde.org/utilities/kate/-/merge_requests/1227 This project currently statically links libraries from the glslang package. According to the maintainers, upstream glslang project does not provide ABI to version it's libraries. -- Marián Konček ___ 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
jaxb, jaxb-fi, jakarta-activation license change
After my updates to several jaxb packages, some of the licenses changed: Source package jaxb: jaxb-rngom: BSD -> (MIT and BSD) jaxb-xjc: BSD -> (BSD and ASL 2.0) Source package jaxb-fi: jaxb-fi-tests (previously known as FastInfosetRoundTripTests): (ASL 2.0 and BSD and ASL 1.1) -> (ASL 2.0 and BSD) Source package jakarta-activation: jakarta-activation: BSD -> (EPL-2.0 or BSD or GPLv2 with exceptions) -- Marián Konček ___ 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: Intention to update jakarta-activation to major version 2
Sorry, I meant "jakarta" instead of "javax" package name. On 29. 11. 2022 13:39, Marián Konček wrote: I am planning to update jakarta-activation to version 2 along with updating jaxb-* packages. The package's classes use a different namespace "jakarta" instead of "jaxb". I am also planning to add a compatibility package jakarta-annotations1. Nevertheless, dependent packages may need to change their BuildRequires. -- Marián Konček ___ 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
Intention to update jaxb-api to major version 4
I am planning to update jaxb-api to version 2 along with updating jaxb-* packages. The package's classes use a different namespace "jakarta" instead of "javax". I am also planning to add a compatibility package jaxb-api2. Nevertheless, dependent packages may need to change their BuildRequires. -- Marián Konček ___ 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
Intention to update jakarta-activation to major version 2
I am planning to update jakarta-activation to version 2 along with updating jaxb-* packages. The package's classes use a different namespace "jakarta" instead of "jaxb". I am also planning to add a compatibility package jakarta-annotations1. Nevertheless, dependent packages may need to change their BuildRequires. -- Marián Konček ___ 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: Planning to start unifying native and mingw packages
I noticed this thread, I develop a personal project where I use about 10 C libraries, I noticed that "glfw", "libsodium" and "libevent" do not have their corresponding mingw packages. I was considering trying to package them but unifying them with the native packages would be better. Of course, this would put more pressure on the maintainers. I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? On 24. 8. 2022 16:00, Daniel P. Berrangé wrote: On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote: On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé wrote: On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: I've done the same with all the mingw packages I maintained just before Fedora 37 branched. So the following native packages now just contain mingw sub-RPMs: libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc I'm so happy to have reduced this maint burden. I see a few new mingw packages pending in package review and think it'd be nice to first ask the native maintainer to consider unified package, before we approve any new separate mingw packages. Our Mingw packaging guidelines, however, exclusively describe fully separated mingw packages. So if I suggest this to a native package maintainer who is not already familiar with mingw, they would be right to question whether this is a desirable thing. IOW, I think we need to look at getting the mingw packaging docs updated to promote unified packaging as an officially supported (and even preferred) option, alongside separate packaging. Sounds great. The Packaging Committee is looking forward to your PR ;) I don't want to rush into doing that myself in case someone else reading along is very enthusiastic to do the work themselves ;-P With regards, Daniel -- Marián Konček ___ 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: Why is there antlr4-project package?
There is no right or wrong, I just saw this as unusual.
I see this is a complex package and you went through some decision
process when deciding on this.
I would still do something about the manually expanded %mvn_install macro.
Is it a big problem to have the java artifacts placed into a
"anrlt4-project" directory?
If nothing else, maybe you could rpm --eval %%mvn_install | sed '-n
%{name}' or something like that in the %prep section?
On 26. 7. 2022 11:33, Fabio Valentini wrote:
On Tue, Jul 26, 2022 at 11:08 AM Marián Konček wrote:
I used a wrong mailing list, I meant to send it here.
I still see this approach as wrong. You can change the archfulness of
the main package. You can add a -java subpackage which is noarch and
provides the main package name for example. In the .spec I see you
manually invoke expanded %mvn_install macro.
"antlr4-project" is what "antlr4" should be in my opinion.
If you want to blame somebody for this, then blame me.
It was my suggestion to do it this way during package review:
https://bugzilla.redhat.com/show_bug.cgi?id=1795470#c2
However, I still think it was the right decision to do it this way.
And I don't think your alternative approach would work, because this
statement from your suggested alternative approach is wrong:
You can change the archfulness of the main package.
The main / source package needs to be "archful", because noarch source
packages cannot have non-noarch subpackages.
I just checked, and subpackages inherit the "BuildArch" tag from the
source package.
So you can override subpackages to make them noarch (archful package
with noarch subpackages), but *not* the other way round.
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Marián Konček
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Why is there antlr4-project package?
I used a wrong mailing list, I meant to send it here. I still see this approach as wrong. You can change the archfulness of the main package. You can add a -java subpackage which is noarch and provides the main package name for example. In the .spec I see you manually invoke expanded %mvn_install macro. "antlr4-project" is what "antlr4" should be in my opinion. On 25. 7. 2022 16:28, Jerry James wrote: On Mon, Jul 25, 2022 at 1:07 AM Marián Konček wrote: I noticed that the package "antlr4" was retired and another package "anrlt4-project" was created some time after that. Why was a new package added instead of antlr4 being unretired? The problem is that the antlr4 package is noarch, and it is not possible to have an archful subpackage of a noarch main package. The noarch antlr4 package was retired so that the archful antlr4-project repo could be created with the various language runtimes. Can we unretire antlr4? No. Why do you want to? There is an antlr4 package, one of the subpackages of antlr4-project. -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
lucene license change
Since I unretired the package lucene and switched to a different build process, the package now contains possibly different set of packages. I went through the license breakdown provided by upstream and added "BSD" and "MIT" licenses to the previously declared "ASL-2.0". -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Package proposal: google-drive-ocamlfuse
I recently discovered this project: https://github.com/astrada/google-drive-ocamlfuse Supposedly it makes it possible to mount google drive as a filesystem using fuse. I wanted to try to package it myself, but ocaml seems a bit esoteric and we are currently missing at least 5 dependencies in Fedora. Nevertheless I think this package would be useful for many people. Would anyone (perhaps someone who maintains other ocaml packages) be willing to package this? -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: All maven RPM builds no longer possible
That is correct, we removed maven-javadoc-plugin from Fedora since we had found a way to build maven without it. xmvn has its own javadoc generator. On 27. 6. 2022 21:46, Jerry James wrote: On Mon, Jun 27, 2022 at 3:04 AM Graham Leggett via devel wrote: I just tried to start from "probably simplest spec file possible” as described below in order to package a maven artefact properly as an RPM: https://docs.fedoraproject.org/en-US/java-packaging-howto/packaging_maven_project/ The build failed because the maven-javadoc-plugin package no longer exists, which is core to building the javadoc package required by the spec. I have since been down a dependency hell rabbithole to try and get something to work, with no luck to date. Googling has revealed that java code has been in various states of brokenness for a while, but we’re at a point where it isn’t possible to build any package using the maven macros in an RPM spec file at all. Are people aware things are this broken? My understanding is that xmvn has its own javadoc support, so maven-javadoc-plugin isn't used even if it is installed. Try adding this to %prep: %pom_remove_plugin -r :maven-javadoc-plugin -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: All maven RPM builds no longer possible
Hi, thanks for pointing this out, we have already been planning to update the howto guide soon™. On 27. 6. 2022 11:02, Graham Leggett via devel wrote: Hi all, I just tried to start from "probably simplest spec file possible” as described below in order to package a maven artefact properly as an RPM: https://docs.fedoraproject.org/en-US/java-packaging-howto/packaging_maven_project/ The build failed because the maven-javadoc-plugin package no longer exists, which is core to building the javadoc package required by the spec. I have since been down a dependency hell rabbithole to try and get something to work, with no luck to date. Googling has revealed that java code has been in various states of brokenness for a while, but we’re at a point where it isn’t possible to build any package using the maven macros in an RPM spec file at all. Are people aware things are this broken? Regards, Graham — ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Review Request: zstd-jni
Zstd-jni are java bindings for de-/compressing zstd archives. It is used for example by apache-commons-compress which currently has zstd support patched out. Zstd is one of archive formats used by rpm. Some other java programs that handle rpms also require this library. I had to unbundle bundled zstd-lib and rebundle the one present in Fedora. The library uses both java and native code. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2088487 -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
zstd-jni: packaging issues
Hi, I am trying to create a new package in Fedora: "zstd-jni" https://github.com/luben/zstd-jni This would allow our package "apache-commons-compress" to use zstd compression. Note that zstd-jni is a separate project from zstd. They just add some jni C and Java librry to use them. I am facing some issues: The upstream bundles sources of "zstd" project. I believe that in Fedora this bundling is not justified. They only use some internal headers, not .c files. Unfortunately most of these headers are internal and not provided by "zstd-devel" package. Otherwise dynamic linking to the installed "zstd" package is solved. I can choose the following approaches: 1) Keep it bundled - simpler package maintenance, possibility of issues if "zstd" shared library is updated and is incompatible with the current bundled headers, duplicate fixing of CVEs. 2) Make "zstd" package expose internal headers either in "-devel" subpackage or create a new "-internal" subpackage and copy those during the build. 3) Somehow share the sources of the "zstd" source package in "zstd-jni" package. Moreover, how should Requires look like if i make the package dynamically link to the Fedora zstd? Should i require exact version match? Or a major / minor version match? -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: A way to prepare custom source tarballs from .spec file to improve CI experience
I agree with Vit, I want to add to this:
* still having to maintain a custom script is not an improvement over
our current situation.
* make sure that $VERSION can be processed, there are cases when for
example the tilde "~" needs to be swapped for dash "-".
* More complex case of $VERSION: obtain a specific commit from upstream,
example:
https://src.fedoraproject.org/fork/mkoncek/rpms/javapackages-bootstrap/blob/rawhide/f/javapackages-bootstrap.spec#_19
The only thing that needs to happen in this phase is removing files.
Therefore there is no need to allow the flexibility like in the %prep
stage. The whole function should look like this:
`obtain_sources $processed_version $list_of_patterns_to_exclude`
where $processed_version as well as $list_of_patterns_to_exclude can be
written / computed directly in the .spec file.
Like in
"|https://github.com/fedora-java/javapackages-bootstrap/archive/%{git_short_hash}.tar.gz|"
For $list_of_patterns_to_exclude, we generally want to exclude either
specific files / directories or names based on their prefixes /
suffixes. Basically we need the functionality of chained `rm` and `find
... -delete`.
On 6. 5. 2022 11:36, Vít Ondruch wrote:
Dne 05. 05. 22 v 19:35 Fabio Valentini napsal(a):
On Tue, Apr 26, 2022 at 1:50 PM Marián Konček
wrote:
Adding onto this, as I mentioned an additional step, I can also imagine
defining some macros which would be used in the .spec file. We could
have a simple generic one that would be available within rpm with the
extension possibility of each working group defining their own macros
which they would use in their own ecosystems.
Not everything has to be an RPM macro ... And I'm not even sure how
you would extract the value of these macros from the .spec file for
external consumption. Parsing RPM .spec files yourself is very hard,
and RPM's own spec parsing machinery doesn't really expose all that
much of its innards to the outside via its API.
I've spent a few minutes working on a DRAFT of my suggested
"SourceScript"-based functionality for spectool here:
https://pagure.io/rpmdevtools/pull-request/94
It was surprisingly simple to implement, works just fine, and
integrates with the default "spectool -g *.spec" use case.
It just calls the specified script with the value of the .spec file's
"Version" tag as an argument (making it unnecessary to parse the .spec
file in the script for a second time, just to extract the version
string again). Adding other CLI arguments (though I wouldn't know any
argument other than "%{version}" that would be useful here) would be
simple.
I'd be interested to see whether that would be enough to satisfy the
use case mentioned at the start of the thread, though I think the
current implementation should be flexible enough (maybe too flexible,
even).
Sorry, but I am not happy about that, because
1) the script is external to the .spec file
2) there still needs to be related `Source10: path-to-script.sh` to
have the script included in SRPM.
Vít
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure
--
Marián Konček
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: "The system is going down for suspend NOW!" broadcast messages
On my system (Fedora Rawhide with KDE) I suspend either by holding the power button for a short time where it asks me what action I want to take, or directly from the "start" menu. On 27. 4. 2022 10:29, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Apr 27, 2022 at 09:36:47AM +0200, Petr Pisar wrote: V Mon, Apr 25, 2022 at 11:45:44AM -0400, Simo Sorce napsal(a): On Mon, 2022-04-25 at 16:28 +0200, Petr Pisar wrote: V Mon, Apr 25, 2022 at 12:54:10PM +0200, Sandro Mani napsal(a): Since some recent update (can't pinpoint which exactly), everytime the system suspends, it sends a "The system is going down for suspend NOW!" broadcast message to all terminals. Any idea anyone how to switch this off? (Running up-to-date rawhide). How is the suspend triggered (i.e. by some explicit command, or key press, or a desktop environment timer…)? Also please describe your enviroment, so it's easier to reproduce. What's wrong with the message? Do you not want to notify all the users of your system that it will be powered down? On a workstation? No, you already know you are suspending and there is no need to spam terminals, you want them to stay as they are so when yo un-suspend the output is not "corrupted". On a single-user system no. Ideally the emmitter of the warning should count users of an interactive sessions. This message is emitted by shutdown tool. That tool has --no-wall option to disable the message. You need to find out what executes that command and then patch it. It could be e.g. systemd/logind. This message is emitted by logind. Is this an upstream change? I have no idea. I do not use suspend. I only know that a similar message is reported for reboot and poweroff. On Fedora /usr/sbin/shutdown is provided by systemd. I was unable to find any relevant notice in systemd's NEWS. I don't think we should emit messages for suspend. This is probably an unintended effect of recent changes, https://github.com/systemd/systemd/commit/cdf370626f seems like the most likely culprit. For some reason, I can't reproduce the issue (tried 'systemctl suspend' and 'systemctl suspend --message …' and 'sudo busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager Suspend b 0'). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: A way to prepare custom source tarballs from .spec file to improve CI experience
Adding onto this, as I mentioned an additional step, I can also imagine defining some macros which would be used in the .spec file. We could have a simple generic one that would be available within rpm with the extension possibility of each working group defining their own macros which they would use in their own ecosystems. Debian has an article about reproducible packaging: https://wiki.debian.org/ReproducibleBuilds/Howto#Introduction Especially look for the string: "tarball" -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: A way to prepare custom source tarballs from .spec file to improve CI experience
I would also be interested in this. In our set of java packages we have
a few cases where upstream releases .jars with bundled binary files
which either cannot be stored within .src.rpm files because of licensing
issues or because they would be unreasonably large. Example here:
https://src.fedoraproject.org/rpms/byte-buddy/blob/rawhide/f/generate-tarball.sh
Our scripts are mostly copy-paste with some additional removals where
needed. This is in addition to the %prep step where we tend to remove
some parts as well. I never questioned this approach but I agree that I
would like to have it automated.
When repackaging, there are issues that need to be addressed and decided
whether they pose a real problem like file attributes, file sorting,
timestamps for example.
It looks like we would want some %pre-prep step :)
On 25. 4. 2022 10:41, Vít Ondruch wrote:
Dne 21. 04. 22 v 14:58 Miroslav Suchý napsal(a):
Dne 21. 04. 22 v 13:20 Vít Ondruch napsal(a):
Now I am looking for feedback about general approach. Of course it
could be somehow polished and improved to hide some boiler plate.
This part:
%{echo:%(
[ ! -e %{S:1} ] &&
Looks really clumsy. After reading the
https://pagure.io/packaging-committee/issue/1132#comment-769233
I like
# Script: gen_clean_tarball.sh
approach. Whether it will be special comment, macro (with support for
extraction in spectool) or new tag in RPM - I do not care. The
important part is that it is standalone file, which can be easily
locally executed. That would ease development and debugging.
1) Standalone script is kind of against RPM philosophy, where the idea
always was that the .spec file should contain everything.
2) Standalone script does not solve the main issue and that is a way
CI could obtain the tarball. Of course you mentioned "with support for
extraction in spectool", but that is also part of the issue, because
that would need the "spectool" changes as well as CI changes. My
proposal does not need that. Of course, this is proof of concept,
while the part of the script you point out could be possibly improved
and abstracted by some macro.
Vít
Miroslav
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report
it:https://pagure.io/fedora-infrastructure
--
Marián Konček
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Package requests: mingw-glfw, gtkmm-4
As a hobbyist developer it is very convenient to use Fedora even for building for Windows. In dnf i see a huge array of mingw-* libraries but glfw is missing. The upstream project https://www.glfw.org/ provides them so it is probably simple enough. So my first question is related to this: How are mingw packages built in Fedora? Who usually maintains them (the maintainer of the linux library package)? Is the process of building a mingw library largely automated is the build for the linux package is available? Is there a reason why there is no mingw-glfw in Fedora? 2) gtkmm-4. I noticed there is already gtk4-devel but no gtkmm-4 (the C++ wrapper). Are there any plans to include this as well? Thanks. -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F33 to F34
Error: Problem 1: package openmw-0.46.0-2.fc33.x86_64 requires libboost_filesystem.so.1.73.0()(64bit), but none of the providers can be installed - boost-filesystem-1.73.0-9.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package openmw-0.46.0-2.fc33.x86_64 Problem 2: rdma-core-33.0-2.fc33.i686 has inferior architecture - rdma-core-33.0-2.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package rdma-core-33.0-2.fc33.i686 Problem 3: package generic-release-common-34-0.1.noarch conflicts with fedora-release-common provided by fedora-release-common-34-0.13.noarch - problem with installed package fedora-release-common-33-3.noarch - package redhat-internal-NetworkManager-openvpn-profiles-non-gnome-0.1-30.el7.csb.noarch requires redhat-release >= redhat-release-workstation-7.0-0.5, but none of the providers can be installed - fedora-release-common-33-3.noarch does not belong to a distupgrade repository - problem with installed package redhat-internal-NetworkManager-openvpn-profiles-non-gnome-0.1-30.el7.csb.noarch On 20. 2. 2021 10:49, Miroslav Suchý wrote: Do you want to make Fedora 34 better? Please spend 1 minute of your time and try to run: # Run this only if you use default Fedora modules # next time you run any DNF command default modules will be enabled again sudo dnf module reset '*' sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \ --enablerepo=updates-testing --enablerepo=updates-testing-modular \ distro-sync This command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf upgrade` before running this command. If you have have rdma-core.i686 installed you have to pass `--allowerasing`. https://bugzilla.redhat.com/show_bug.cgi?id=1919864 If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer N and nothing happens, no need to test the actual upgrade. But very likely you get some dependency problem now. In that case, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in Fedora 34. Please check existing reports against fedora-obsolete-packages first: https://red.ht/2kuBDPu and also there is already bunch of "Fails to install" reports: https://bugzilla.redhat.com/show_bug.cgi?id=F34FailsToInstall Thank you P.S. sent from workstation successfully upgraded to F34 :) -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
aqute-bnd 4.3.0 license change
The package aqute-bnd version 4.3.0 has changed the license from (ASL 2.0, some parts being under EPL-2.0) to (ASL 2.0 or EPL-2.0). As the package was built in as a part of module, the license should be changed in this .spec file: https://src.fedoraproject.org/rpms/aqute-bnd/blob/stream-javapackages-tools-201902/f/aqute-bnd.spec -- Marián Konček ___ 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
glassfish-el-3.0.1~b11 license change
Since the pre release version ~b11 (last was ~b08) some files in the directory "/api/src/main/java/javax/el" no longer contain two licenses (CDDL and ASL 2.0) but only ASL 2.0. Therefore I am adding ASL 2.0 as an additional license. -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F30 to F31
My attempt revealed these errors Problem: conflicting requests - nothing provides module(platform:f30) needed by module eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 Error: Problem 1: problem with installed package eclipse-jgit-5.4.0-4.module_f30+5264+0fe54b96.noarch - eclipse-jgit-5.4.0-4.module_f30+5264+0fe54b96.noarch does not belong to a distupgrade repository - nothing provides jgit = 5.3.0-5.fc31 needed by eclipse-jgit-5.3.0-5.fc31.noarch Problem 2: package kate-plugins-19.08.0-1.fc31.x86_64 requires libKF5TextEditor.so.5()(64bit), but none of the providers can be installed - problem with installed package kate-plugins-19.04.2-1.fc30.x86_64 - package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed - kf5-ktexteditor-5.59.0-1.fc30.x86_64 does not belong to a distupgrade repository - kate-plugins-19.04.2-1.fc30.x86_64 does not belong to a distupgrade repository - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded - package libgit2-0.28.2-3.fc31.x86_64 is excluded (try to add '--skip-broken' to skip uninstallable packages) On 11. 9. 2019 14:54, Miroslav Suchý wrote: Do you want to make Fedora 31 better? Please spend 1 minute of your time and try to run [*]: sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 --enablerepo=updates-testing distro-sync If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer N and nothing happens, no need to test the actual upgrade. But very likely you get some dependency problem now. In that case, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in Fedora 31. Please check existing reports first: https://red.ht/2kuBDPu Thank you [*] this command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf upgrade` before running this command. -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning/retiring 3 Java packages
It would be possible, but I really only have about less than a year of experience. And I would need some preparations (like example packages). On 6. 8. 2019 15:30, D L wrote: Perhaps, if this introduction is done by video conference it could be recorded and archived for future reference on this page – https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ If its not too much trouble. -- Danny Lee mailto:drea...@panix.com>> /I have been impressed with the urgency of doing. Knowing is not enough; we must apply. Being willing is not enough; we must do. ~ Leonardo da Vinci/ *From: *Marián Konček <mailto:mkon...@redhat.com> *Sent: *Tuesday, August 6, 2019 6:20 AM *To: *devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> *Cc: *p...@barkhof.uni-bremen.de <mailto:p...@barkhof.uni-bremen.de> *Subject: *Re: Orphaning/retiring 3 Java packages I could introduce Peter into Fedora java packaging. On 24. 7. 2019 20:03, Peter Boy wrote: > >> Am 23.07.2019 um 16:08 schrieb Mikolaj Izdebski : >> >> On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok wrote: >>> On 23. 07. 19 13:27, Mikolaj Izdebski wrote: >>>> Soon after Fedora 31 branching I intend to retire java-packaging-howto >>>> package and orphan byaccj and javapackages-tools packages. The reason >>>> is that I intend to maintain these packages as part of modules. >>>> >>>> I will continue to maintain non-modular packages through lifecycles of >>>> Fedora 29-31, but starting from Fedora 32 I will maintain modular >>>> versions only. >>> Do you realize that while your decision to move essential bits of Java packaging >>> to modules might untie your hands a lot, it is causing everybody else involved >>> more and more trouble? >> Perhaps I don't realize the trouble, could you elaborate? I expect >> orphaned packages to be adopted by someone, likely a member of >> Stewardship SIG. These two packages are low-maintenance and don't >> require much work - they don't have many upstream changes and don't >> get many bugs reported. So I don't see that much trouble in this case. >> >>> I acknowledge that it is your right to orphan essentially anything you want, >>> however the motivation here seems a bit... nonempathetic. >>> >>> Would you mind to reconsider? >> Definitely - this is the reason I wrote to the list. Do you have any >> proposal what to do with these packages instead of orphaning them? > > Sorry for jumping in. I think this might be an opportunity to participate in the Fedora Projekt. I’ve a lot of experience in java development and in creating application rpms, but none in the specialties of Fedora packaging. Would you accept me as co-maintainer and provide some guidance at the beginning? > > > > Peter > > > > >> -- >> Mikolaj Izdebski >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://docs.fedoraproject.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 > — > Dr. Peter Boy > Universität Bremen > Mary-Sommerville-Str. 5 > 28359 Bremen > Germany > > p...@zes.uni-bremen.de > www.zes.uni-bremen.de > > > > Are you looking for a web content management system for scientific research organizations? > Have a look at http://www.scientificcms.org > > > Are you looking for a web content management system for public administrations? > Have a look at http://www.aplaws.org & https://fedorahosted.org/aplaws/ > > ___ > 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 -- Marián Konček ___ 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.fedorap
Re: Orphaning/retiring 3 Java packages
I could introduce Peter into Fedora java packaging. On 24. 7. 2019 20:03, Peter Boy wrote: Am 23.07.2019 um 16:08 schrieb Mikolaj Izdebski : On Tue, Jul 23, 2019 at 1:50 PM Miro Hrončok wrote: On 23. 07. 19 13:27, Mikolaj Izdebski wrote: Soon after Fedora 31 branching I intend to retire java-packaging-howto package and orphan byaccj and javapackages-tools packages. The reason is that I intend to maintain these packages as part of modules. I will continue to maintain non-modular packages through lifecycles of Fedora 29-31, but starting from Fedora 32 I will maintain modular versions only. Do you realize that while your decision to move essential bits of Java packaging to modules might untie your hands a lot, it is causing everybody else involved more and more trouble? Perhaps I don't realize the trouble, could you elaborate? I expect orphaned packages to be adopted by someone, likely a member of Stewardship SIG. These two packages are low-maintenance and don't require much work - they don't have many upstream changes and don't get many bugs reported. So I don't see that much trouble in this case. I acknowledge that it is your right to orphan essentially anything you want, however the motivation here seems a bit... nonempathetic. Would you mind to reconsider? Definitely - this is the reason I wrote to the list. Do you have any proposal what to do with these packages instead of orphaning them? Sorry for jumping in. I think this might be an opportunity to participate in the Fedora Projekt. I’ve a lot of experience in java development and in creating application rpms, but none in the specialties of Fedora packaging. Would you accept me as co-maintainer and provide some guidance at the beginning? Peter -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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 — Dr. Peter Boy Universität Bremen Mary-Sommerville-Str. 5 28359 Bremen Germany p...@zes.uni-bremen.de www.zes.uni-bremen.de Are you looking for a web content management system for scientific research organizations? Have a look at http://www.scientificcms.org Are you looking for a web content management system for public administrations? Have a look at http://www.aplaws.org & https://fedorahosted.org/aplaws/ ___ 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 -- Marián Konček ___ 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
xmlunit 2 license change
The package xmlunit since version 2 uses two licenses. The legacy module retains BSD from version 1. The rest is licensed under ASL 2.0. I improperly marked it as ASL 2.0 only, this should be fixed in this PR: https://src.fedoraproject.org/rpms/xmlunit/pull-request/2 if we still want to update the ursine package. I fixed this in MBI: https://src.fedoraproject.org/fork/mbi/rpms/xmlunit/c/cdf8080bd32bde75520fff74828ddbae14a0213b?branch=master -- Marián Konček ___ 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
jaxen-1.2.0 license change
The package jaxen at least since version 1.2.0 no longer includes the only differently (under W3C) licensed file from the rest (BSD) which leaves the package with a single license (BSD). -- Marián Konček ___ 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
