Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

A question about this which is semi-related to your email.

For some C library packages we have Java bindings, eg:
https://github.com/libguestfs/libguestfs/tree/master/java

These have been disabled in Fedora for ~2 years, but when they were
around they had these BuildRequires:

  BuildRequires: java-1.8.0-openjdk
  BuildRequires: java-1.8.0-openjdk-devel
  BuildRequires: jpackage-utils

I believe the only requirements are javac, javah, javadoc (optional)
and a JVM to run the tests on.

Is it possible to keep this going, or would that require a lot of
work?  I notice that javah no longer seems to exist.

(Note I know almost nothing about how the modern JDK works)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Mat Booth]

On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones  wrote:
>
> A question about this which is semi-related to your email.
>
> For some C library packages we have Java bindings, eg:
> https://github.com/libguestfs/libguestfs/tree/master/java
>
> These have been disabled in Fedora for ~2 years, but when they were
> around they had these BuildRequires:
>
>   BuildRequires: java-1.8.0-openjdk
>   BuildRequires: java-1.8.0-openjdk-devel
>   BuildRequires: jpackage-utils
>
> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on.
>
> Is it possible to keep this going, or would that require a lot of
> work?  I notice that javah no longer seems to exist.
>
> (Note I know almost nothing about how the modern JDK works)
>
> Rich.

Hi, the functionality provided by javah has been folded into javac in
recent JDKs.

These days you can make one call to "javac -h" instead of having to
call both "javac" and "javah"

I ported quite a few packages this way when Fedora made the switch to
Java 11 by default. If you like I can probably take a look libguestfs
and send you a PR?


>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



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

Re: Fedora ? Java: The Death of Two SIGs

[Fabio Valentini]

On Mon, Sep 27, 2021 at 1:07 PM Richard W.M. Jones  wrote:
>
> A question about this which is semi-related to your email.
>
> For some C library packages we have Java bindings, eg:
> https://github.com/libguestfs/libguestfs/tree/master/java
>
> These have been disabled in Fedora for ~2 years, but when they were
> around they had these BuildRequires:
>
>   BuildRequires: java-1.8.0-openjdk
>   BuildRequires: java-1.8.0-openjdk-devel
>   BuildRequires: jpackage-utils
>
> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on.
>
> Is it possible to keep this going, or would that require a lot of
> work?  I notice that javah no longer seems to exist.
>
> (Note I know almost nothing about how the modern JDK works)

I think you'd probably want to do

1) switch to java-11-openjdk (it's the default on all currently
supported Fedora branches)
2) replace jpackage-utils with javapackages-tools (depending on what
exactly you need from that package)
3) replace javah usage (removed with Java 11) with "java -h", or
similar (for an example how I handled this for another package, look
at https://src.fedoraproject.org/rpms/jblas/pull-request/2 )

And since those bindings do not look like they require any third-party
Java libraries, you should be fine.

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

Re: Fedora ? Java: The Death of Two SIGs

[Artur Frenszek-Iwicki]

> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on. Is it possible to keep this going,
> or would that require a lot of work?
+1 on this. Having just the minimum, core packages
available in the repo would be good, especially since:
a) It would mean users can still run third-party Java apps.
b) I believe that, similar to Python, many end-users use maven
   (or whatever else) for installing dependencies, instead of the distro's repo,
   so the removal of other packages didn't affect them as much.

>  I notice that javah no longer seems to exist.
javah is now part of javac, invoked using the -h option.
If my research is right, the last edition with a separate javah was Java SE 9. 

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora-Cloud-33-20210927.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20210926.0):

ID: 1003017 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1003017
ID: 1003025 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1003025

Passed openQA tests: 7/8 (aarch64), 7/8 (x86_64)

New passes (same test not passed in Fedora-Cloud-33-20210926.0):

ID: 1003027 Test: aarch64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/1003027
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Package Update Guide: Updating inter-dependent packages

[Otto Urpelainen]

Vít Ondruch kirjoitti 24.9.2021 klo 11.13:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages 



Shouldn't it be somehow aligned with this ^^ chapter? Maybe the chapter 
should be referenced at least, because it explains how to request the 
side tag.


The difference between these two sections is that one is under "Rawhide 
and early branched", the other "Later Branched and stable releases". 
Currently, one prescribes a side tag and the other, a buildroot 
override. Probably one could just refer to the other, or both refer to 
another place.


Pointing to the Rawhide Gating page for instructions is fine, but I 
wonder would it actually be better to do it the other way, describe the 
process correctly in Package Maintainer Docs and link there from the 
Rawhide Gating page, which, judging from its title, has quite narrow scope.


There is also the page "Using the Koji build system" [1] which 
recommends yet another solution: section "Chained builds". What about 
those, what are they useful for?


Otto

[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/



Dne 23. 09. 21 v 11:29 Miro Hrončok napsal(a):
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages 



Says:

"""
You may need a buildroot override to complete a multi-package update 
successfully. For instance in the case described above, you may need 
to rebuild bar against the new libfoo package and submit both packages 
together as a multi-package update. However, in the normal course of 
events, you would not be able to build another package against your 
new libfoo build until it reached the stable state. To resolve this 
dilemma, you can request a buildroot override, which causes the libfoo 
build to be included in the buildroot for a short time in order to get 
the bar package build done.

"""

However, I think side-tags should be the preferred solution, as their 
impact is isolated. Buildroot overrides create temporary broken 
dependencies for everybody, while side-tags don't.


My understanding was that this is the de-facto consensus, so I'd lie 
to update the docs to say something like:


"""
You may need to build the inter-dependent packages in a side tag.
For instance in the case described above, you may need to rebuild bar 
against the new libfoo package and submit both packages together as a 
multi-package update. However, in the normal course of events, you 
would not be able to build another package against your new libfoo 
build until it reached the stable state. To resolve this dilemma, you 
can request a side tag and build both packages in it, which causes the 
libfoo build to be included in the bar build's buildroot.

"""

And than instead of describing the details, link to 
https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/


Any suggestions or objections?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

Re: Package Update Guide: Updating inter-dependent packages

[Artur Frenszek-Iwicki]

> section "Chained builds". What about those, what are they useful for?
Chained builds are mostly useful when you have a package B which depends on 
package A.
Instead of building package A, waiting for a confirmation that the build 
completed
and made it to the buildroot, and then manually launching the package B build,
you can specify the build-chain and koji will automatically handle the process.

They can be used both in rawhide and in side tags. They're not really compatible
with release branches, since the chainbuild would have to wait for however
long it takes package A to go through bodhi and into stable.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Need help pushing updates to bodhi (tagging problem)

[Qiyu Yan]

Hi all,

Yesterday I updated some fcitx5 related packages for f34 and f35, they
are built in side-tags. But a bug in my scripts causes one package
(fcitx5-mozc) did not build. Before I realized this, I have already
pushed the update in bodhi. Then I manually built it in side-tags, and
updated bodhi update manually (by using "edit" and the refersh
button). Then since those side-tags will not be used anymore, I
removed them.

Today I am getting errors from bodhi saying "Cannot find relevant tag
for ...", and the package is not tagged in koji. (I suppose bodhi
should have already tagged those package?)

My question is
 - What is the right way if you want add package to a side-tag update
 - How to resolve this problem

Retards,
Qiyu Yan

---
related updates:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-5616170e50
https://bodhi.fedoraproject.org/updates/FEDORA-2021-eaf29d8a38
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Review requests: four python packages to update mkdocs

[Sandro Mani]

Hi

I'd still need python-gph-import 
(https://bugzilla.redhat.com/show_bug.cgi?id=2000349) to be reviewed as 
the last dependency to be able to update mkdocs.


Thanks
Sandro

On 02.09.21 00:51, Sandro Mani wrote:


Hi

To update to the current version of mkdocs, I'd need these four 
dependencies reviewed:


- python-mkdocs-redirects: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2000347
- python-pyyaml_env_tag: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2000348
- python-ghp-import: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2000349
- python-mergedeep: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2000350


All are simple python packages.

Happy to review in exchange.

Thanks
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Need help pushing updates to bodhi (tagging problem)

[Fabio Valentini]

On Mon, Sep 27, 2021 at 12:48 PM Qiyu Yan  wrote:
>
> Hi all,
>
> Yesterday I updated some fcitx5 related packages for f34 and f35, they
> are built in side-tags. But a bug in my scripts causes one package
> (fcitx5-mozc) did not build. Before I realized this, I have already
> pushed the update in bodhi. Then I manually built it in side-tags, and
> updated bodhi update manually (by using "edit" and the refersh
> button). Then since those side-tags will not be used anymore, I
> removed them.
>
> Today I am getting errors from bodhi saying "Cannot find relevant tag
> for ...", and the package is not tagged in koji. (I suppose bodhi
> should have already tagged those package?)
>
> My question is
>  - What is the right way if you want add package to a side-tag update
>  - How to resolve this problem

I think you did the right thing. Building another package inside the
same side tag and then editing the bodhi update to refresh the list of
builds *should* work.
However, I've also hit similar bugs with this workflow before, so it
might be worth opening an issue with bodhi for this.

For your current problem, it's probably easiest to file a ticket with
https://pagure.io/releng and list the affected update and mis-tagged
builds, that should be enough information for somebody with
appropriate powers to resolve the problem.

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

Max age of side tags?

[Richard W.M. Jones]

OCaml 4.13 has just come out and we'll be rebuilding all the OCaml
packages in Rawhide into a side tag.  Jerry James - who maintains some
of these packages - is not going to be available this week.  That
means if I starts the builds now, we might need to keep the side tag
open for 2 or 3 weeks, whereas normally we'd complete everything in a
few days.

Is this a problem?  I vaguely recall that side tags had a short
maximum age (2 weeks?) but I cannot find anything about that in the
docs now.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/

If it's a problem then I can start doing the builds next week instead.

Rich.

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

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
> On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones  wrote:
> >
> > A question about this which is semi-related to your email.
> >
> > For some C library packages we have Java bindings, eg:
> > https://github.com/libguestfs/libguestfs/tree/master/java
> >
> > These have been disabled in Fedora for ~2 years, but when they were
> > around they had these BuildRequires:
> >
> >   BuildRequires: java-1.8.0-openjdk
> >   BuildRequires: java-1.8.0-openjdk-devel
> >   BuildRequires: jpackage-utils
> >
> > I believe the only requirements are javac, javah, javadoc (optional)
> > and a JVM to run the tests on.
> >
> > Is it possible to keep this going, or would that require a lot of
> > work?  I notice that javah no longer seems to exist.
> >
> > (Note I know almost nothing about how the modern JDK works)
> >
> > Rich.
> 
> Hi, the functionality provided by javah has been folded into javac in
> recent JDKs.
> 
> These days you can make one call to "javac -h" instead of having to
> call both "javac" and "javah"
> 
> I ported quite a few packages this way when Fedora made the switch to
> Java 11 by default. If you like I can probably take a look libguestfs
> and send you a PR?

Sure thing, thanks.

However before you start you might also want to know that there are
apparently some serious GC-related problems with how those bindings
work:

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

so it might be more of a saga than just changing a few commands.

Rich.

> 
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat 
> > http://people.redhat.com/~rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > virt-p2v converts physical machines to virtual machines.  Boot with a
> > live CD or over the network (PXE) and turn machines into KVM guests.
> > http://libguestfs.org/virt-v2v
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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
> 
> 
> 
> -- 
> Mat Booth
> http://fedoraproject.org/get-fedora
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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

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

Re: Fedora  Java: The Death of Two SIGs

[Peter Boy]

> Am 27.09.2021 um 12:30 schrieb Fabio Valentini :
> 
> On Mon, Sep 27, 2021 at 12:19 PM Peter Boy  wrote:
>> 
>> 
>> 
>>> Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon :
>>> 
>>> On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
 
>>> 
 What do you want to gain from it? What is the goal to be?
>>> 
>>> I believe the original email from Fabio answers both of these questions.
>> 
>> I don’t find a plan or a goal. Please, provide me with a hint.
> 
> All I wanted to say is that the current state is disingenuous at best,
> and misleading at first.

Unfortunately yes, indeed.

> By having @java-maint-sig as one of the admins of a package (and for
> most of them, also the default bugzilla assignee), while that group
> doesn't really function any longer, a false expectation of "there's a
> whole group of people maintaining this package", while the reality is
> closer to "zero or maybe one person might be looking at this package
> once a year".

I think you characterize the situation very pessimistically. Obviously the 
constructions work to a certain extent. For example, we have 3 different 
versions of the JDK available in parallel, which also receive regular updates. 
We have important applications as tomcat. So we have something to build on. 

And this kind of situation is in no way special or exclusive to Java sig. We 
have or had a similar situation with a number of other Fedora sigs, e.g. Fedora 
Server Edition which underwent a "reboot" late last year. And the current 
situation of Fedora docs is not much better than that of Java. Sociologically, 
such alternating phases are typical for volunteer projects. They need a 
"refresh" or a "revitalization“ and new members with new impulses every now and 
then. All this is normal. 

So there is no reason to give up and expect or bring about the demise of the 
Fedora Java stack. The challenge is to organize such a "reboot". It requires a 
number of prerequisites, and that is not easy.


> I'd rather have the group start from zero now, and start *adding*
> packages again that are actually really needed, wanted, and
> maintained.
> 
> This should also be a less daunting prospect for potential packagers
> who are now just lurking on the sidelines, ... (I actually know that there's 
> a few
> of those

Yes. One of the challenges is to organize a meeting where all these potential 
packagers meet - in one place and at the same time and that along with some of 
the current packagers. And that's something we're already struggling with at 
the moment.


> - thank you for contacting me off-list. you know who you are
> :) )

I have to thank you. I am still following my ‚project' and would like to 
contact you with a few questions later. 


Peter



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

bibutils soname update to 7

[Vascom]

bibutils now released a 7.1 version with soname updated from 6 to 7.
I will rebuild it for rawhide in a week.

Because no one package not depend on libbibutils I will update it for F35 too.
No one other package no need to rebuild.

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

Re: Fedora  Java: The Death of Two SIGs

[Ankur Sinha]

On Sun, Sep 26, 2021 21:20:07 +0200, Fabio Valentini wrote:
> Good evening everybody,
> 
> Not sure why it's me who's writing this message, but somebody needs to do it.
> 
> Community maintenance of Java packages in Fedora is, for all intents
> and purposes, dead. Mikolaj keeps a bare minimum of packages working
> for the maven toolchain, but that's it. Fedora 35 will ship without
> packages for the Eclipse IDE, and none of the Java applications I know
> of are still in working order. While I had hoped that setting up a
> "new" SIG and gathering members to shore up community maintenance of
> the "extended core" Java stack, this effort fizzled out after mere
> weeks.
> 
> "He's dead, Jim."
> 
> Now to the reason why I feel the need to beat a dead horse: I wonder
> if the @java-maint-sig group should actually continue to exist (or
> rather, be maintainer or bugzilla assignee for packages, because I
> don't even know if FAS groups can be deleted). It seems that none of
> the current members (I am no longer one of them) are active. Bugs,
> including security issues with assigned CVE numbers, are collecting
> dust. Packages get orphaned and retired one by one because they fail
> to build or install.
> 
> At this point, I'm still the only person with the password for the
> SIG's bugzilla account and the only administrator of the private
> mailing list - just because I wouldn't even know who to hand those
> things over to (fedora-infra?). There's nobody left, nobody is reading
> the mailing lists. Only tumbleweeds are here.
> 
> Should the @java-maint-sig group be removed from any packages it is
> still associated with? Should it be dissolved, and members be removed?
> Should the remaining ruins that used to be packages be orphaned?
> Retired? Buried? Forgotten?
> 
> I don't know.


Unfortunately, I think removing the java-maint-sig is the only thing to
do.

I was hoping to help out since some of our neuro-sig packages are Java,
but keeping the dependency chain in place to be able to make these leaf
packages available is just far too much work. The Gradle issue etc. do
not help either. I don't think we managed to find a practical solution
for that one. At the neuro-sig we've been orphaning our Java packages
and letting them be retired. We'll just point to upstream builds in our
documentation and let users fetch and use those.

I think, as folks have discussed before, the Java ecosystem is not quite
packaging friendly enough for us, and for us to spend resources on
trying to tame it isn't the best use of our rather limited resources in
my book. (I mean I won't forbid any one from doing it, but I'd rather
focus on the non-Java packages in our 200 item packaging queue instead
of using up all that time on the few Java ones)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Fedora  Java: The Death of Two SIGs

[Pierre-Yves Chibon]

On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
> 
> 
> > Am 27.09.2021 um 10:47 schrieb Ankur Sinha :
> > 
> > On Sun, Sep 26, 2021 21:20:07 +0200, Fabio Valentini wrote:
> >> Should the @java-maint-sig group be removed from any packages it is
> >> still associated with? Should it be dissolved, and members be removed?
> >> Should the remaining ruins that used to be packages be orphaned?
> >> Retired? Buried? Forgotten?
> >> 
> >> I don't know.
> > 
> > 
> > Unfortunately, I think removing the java-maint-sig is the only thing to
> > do.

As heart-breaking as it is, I agree with Ankur. Letting things as they are is
not correct.
The group itself will not disappear, so if some people wanted to revive it some
time in the future, they could still do, but it would not give the impression
that someone/some team is looking after packages while they are not.

> What do you want to gain from it? What is the goal to be? 

I believe the original email from Fabio answers both of these questions.


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

Re: Fedora  Java: The Death of Two SIGs

[Fabio Valentini]

On Mon, Sep 27, 2021 at 12:19 PM Peter Boy  wrote:
>
>
>
> > Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon :
> >
> > On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
> >>
> >
> >> What do you want to gain from it? What is the goal to be?
> >
> > I believe the original email from Fabio answers both of these questions.
>
> I don’t find a plan or a goal. Please, provide me with a hint.

All I wanted to say is that the current state is disingenuous at best,
and misleading at first.

By having @java-maint-sig as one of the admins of a package (and for
most of them, also the default bugzilla assignee), while that group
doesn't really function any longer, a false expectation of "there's a
whole group of people maintaining this package", while the reality is
closer to "zero or maybe one person might be looking at this package
once a year".

I'd rather have the group start from zero now, and start *adding*
packages again that are actually really needed, wanted, and
maintained.

This should also be a less daunting prospect for potential packagers
who are now just lurking on the sidelines, because they can't commit
to helping maintain 100+ packages (I actually know that there's a few
of those - thank you for contacting me off-list. you know who you are
:) )

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

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Jaroslav Mracek]

> 2. What happens if package P (already installed on the user's system)
> starts recommending package Q (not installed on the user's system)? Will Q
> get auto-installed together with P's update, or not? I believe it's
> important to keep auto-installation enabled for *new* weak relationships.

New weak dependencies of package P are installed.
Installed P-1-1.noarch (no recommends)
Available P-1-2.noarch (recommends ddd) will install ddd on upgrade if possible.

> 3. Similarly to above (perhaps exactly the same case), what happens when
> package Q (not installed) starts supplementing package P (installed), will
> it get auto-installed or not?

No, Q will be not installed. With supplements it is difficult to known when it 
appears, because that information is not on RPMDB.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaned packages looking for new maintainers

[Bruno Wolff III]

On Mon, Sep 20, 2021 at 18:16:17 +0200,
 Jonathan Schleifer  wrote:

Am 20.09.21 um 13:31 schrieb Miro Hrončok:

0ad  ignatenkobrain, orphan, pwalter   1 
weeks ago


I would be interested in becoming a (co)maintainer for this, but would 
need sponsorship.


I think I have something working now, and took ownership. I was able to 
build it in a scratch build and it seemed to work in very limited 
testing. I have started builds for rawhide and f35.
f33 and f34 will need to stay separate unless a conditional is added 
around the fix for python3.10. (I think that will be easy.)


I'd prefer not to be the primary person responsible for this package, as 
there are probably others that are in contact with the community and 
will catch issues I'd miss. I just cared enough to research how to fix 
the spidermonkey/python3.10 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Jaroslav Mracek]

Naming is really difficult topic. We would like to have the same name like 
libsolv has.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[Peter Boy]

> Am 27.09.2021 um 10:47 schrieb Ankur Sinha :
> 
> On Sun, Sep 26, 2021 21:20:07 +0200, Fabio Valentini wrote:
>> Should the @java-maint-sig group be removed from any packages it is
>> still associated with? Should it be dissolved, and members be removed?
>> Should the remaining ruins that used to be packages be orphaned?
>> Retired? Buried? Forgotten?
>> 
>> I don't know.
> 
> 
> Unfortunately, I think removing the java-maint-sig is the only thing to
> do.

What do you want to gain from it? What is the goal to be? 


Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: remove-retired-packages

[Miroslav Suchý]

Dne 24. 09. 21 v 10:50 Miro Hrončok napsal(a):

Should it query for removed packages instead of components?

It seem that when python-foo is retired, the script will attempt to remove python-foo instead of python3-foo (and 
python3-foo-docs etc.). 


This is fixed now. And build with the fix is in the Copr repository (link is in 
first mail in this thread).

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

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

[Coiby Xu]

With Fedora 33 network configuration is by default persisted in
/etc/NetworkManager/system-connections/*.nmconnection files. The old
/etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being 
processed
for the time being, but obviously it is time to migrate.
(cf 
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_...).


Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ?


Currently, the easiest way I can find is to to use
`nmcli clone --temporary` before the official migration tool
mentioned in [1] gets released. For example,
`nmcli c clone --temporary bond-mybond0 bond-mybond1` would clone
/etc/sysconfig/network-scripts/ifcfg-bond-mybond0 to
/run/NetworkManager/system-connections/bond-mybond1.nmconnection.

[1] 
https://blogs.gnome.org/thaller/2021/02/02/initscripts-ifcfg-rh-format-in-networkmanager-and-its-future/

--
Best regards,
Coiby
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: remove-retired-packages

[Miroslav Suchý]

Dne 24. 09. 21 v 13:55 Miro Hrončok napsal(a):
I think w are over-engineering a workaround for something that could be part of system-upgrade. See my proposal in 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DQZOCSVPW4R4MZR2QYBQTO6ZTTU3RCKW/ 
that got 0 replies:



Generally, I think we should instead strive to have configurable bahavior of 
dnf system-upgrade:
SNIP
Such solution obviously requires somebody to design it, code it, test it, support it and maintain it. I cannot speak 
for the software management team, but I guess they would have reasons not to do that (such as capacity reasons). 


DNF team has its priority list already packed. I think it make sanse to do this designing phase in separate tool. And 
only when it becomes obvious what we want and how to do it, only then merge it to core DNF code.


Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Kamil Paral]

On Mon, Sep 27, 2021 at 8:30 AM Jaroslav Mracek  wrote:

> > 2. What happens if package P (already installed on the user's system)
> > starts recommending package Q (not installed on the user's system)? Will
> Q
> > get auto-installed together with P's update, or not? I believe it's
> > important to keep auto-installation enabled for *new* weak relationships.
>
> New weak dependencies of package P are installed.
> Installed P-1-1.noarch (no recommends)
> Available P-1-2.noarch (recommends ddd) will install ddd on upgrade if
> possible.
>
> > 3. Similarly to above (perhaps exactly the same case), what happens when
> > package Q (not installed) starts supplementing package P (installed),
> will
> > it get auto-installed or not?
>
> No, Q will be not installed. With supplements it is difficult to known
> when it appears, because that information is not on RPMDB.
>

While it makes sense technically, this might be quite confusing for
packagers. Up until now I think there were no real-world differences
between forward (recommends) and backward (supplements) dependencies. This
(and also the first answer) should get documented in the Change proposal
and in the packaging guidelines [1]. Can you please add an action item to
the proposal to adjust relevant Fedora docs?

[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora-Cloud-34-20210927.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (aarch64)

New failures (same test not failed in Fedora-Cloud-34-20210926.0):

ID: 1003108 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1003108

Soft failed openQA tests: 1/8 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20210926.0):

ID: 1003100 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1003100

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 27 September (Today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 27th
September (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat). The
meeting is a public meeting, and open for everyone to attend. You can
join us over:

IRC:
https://webchat.libera.chat/?channels=#fedora-neuro

Matrix (on the Fedora homesever!): https://matrix.to/#/#neuro:fedoraproject.org

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 2021-09-27'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20210927T13=%3A=1

The meeting will be chaired by @shaneallcroft. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last week's meeting: 
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-09-13-13.00.html
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- Koschei packages check: https://koschei.fedoraproject.org/groups/neuro-sig
- CompNeuro lab compose status check for F35: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Fedora  Java: The Death of Two SIGs

[Peter Boy]

> Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon :
> 
> On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
>> 
> 
>> What do you want to gain from it? What is the goal to be? 
> 
> I believe the original email from Fabio answers both of these questions.

I don’t find a plan or a goal. Please, provide me with a hint.


Peter

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Using YubiKey for accounts.fedoraproject.org OTP?

[Stephen John Smoogen]

On Mon, 27 Sept 2021 at 09:28, Miro Hrončok  wrote:
>
> Hello,
>
> I've been trying to add the OPT token from accounts.fedoraproject.org to my
> yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.
>
> I copypasted the xxx secret (56 characters: digits and uppercase letters) and
> tried to add it via YubiKey Manager GUI via Applications/OTP as OATH-HOTP (6
> digits).
>
> I get "Failed to configure Long Touch (Slot 2). undefined" error.
>
> When I tried to use the CLI:
>
>  $ ykman otp hotp -d 6 -c 0 2 xxx
>
> I get "Error: key lengths >20 bytes not supported".
>
> Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the
> device not compatible?
>

OK let's back up a bit, since I am looking at a working yubikey for
Fedora OTP at the moment. The first thing we need to see is if the key
you are using is compatible. There are multiple generations and they
use different commands to program them :/. The ones I know which work
are the older 'black' yubikeys. The newer blue ones, do not seem to
work with the Fedora commands shipped. If I run


I am looking at my yubikeys and they all work. I know that every
sysadmin in Fedora has been using yubikeys for years. So I am guessing
something else is going on here for this device. Here is what I get
from my two Fedora ones

```
$ # This is my oldest key which works for Fedora
$ ykinfo -t -i -p -I -1 -2
touch_level: 1793
programming_sequence: 1
slot1_status: 1
slot2_status: 0
vendor_id: 1050
product_id: 10

$ # This is my 2nd gen black key and was keyed to Fedora during testing.
$ ykinfo -t -i -p -I -1 -2
touch_level: 1285
programming_sequence: 1
slot1_status: 1
slot2_status: 0
vendor_id: 1050
product_id: 110

$ # This is a blue key which I use for other websites because Fedora
commands give me
$ ykinfo -t -i -p -I -1 -2
Yubikey core error: no yubikey present
```






> Thanks,
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora 35 compose report: 20210927.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-35-20210925.n.1
NEW: Fedora-35-20210927.n.0

= SUMMARY =
Added images:1
Dropped images:  2
Added packages:  1
Dropped packages:1
Upgraded packages:   79
Downgraded packages: 0

Size of added packages:  709.34 KiB
Size of dropped packages:99.95 KiB
Size of upgraded packages:   1.58 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   16.17 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-35-20210927.n.0.iso

= DROPPED IMAGES =
Image: Python_Classroom raw-xz aarch64
Path: Labs/aarch64/images/Fedora-Python-Classroom-35-20210925.n.1.aarch64.raw.xz
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-35-20210925.n.1.aarch64.raw.xz

= ADDED PACKAGES =
Package: xdg-desktop-portal-gnome-41.1-1.fc35
Summary: Backend implementation for xdg-desktop-portal using GNOME
RPMs:xdg-desktop-portal-gnome
Size:709.34 KiB


= DROPPED PACKAGES =
Package: mk-files-20210321-2.fc35
Summary: Support files for bmake, the NetBSD make(1) tool
RPMs:mk-files
Size:99.95 KiB


= UPGRADED PACKAGES =
Package:  battray-2.3-19.fc35
Old package:  battray-2.3-17.fc35
Summary:  Tool for displaying a laptop's battery status in the system traiy
RPMs: battray
Size: 76.31 KiB
Size change:  -9 B
Changelog:
  * Wed Sep 22 2021 Ranjan Maitra  - 2.3-5
  - fixed notification issue as per BZ #2001311
  - moved to bzipped2 archive (minor)


Package:  bmake-20210803-1.fc35
Old package:  bmake-20210110-3.fc35
Summary:  The NetBSD make(1) tool
RPMs: bmake mk-files
Added RPMs:   mk-files
Size: 909.72 KiB
Size change:  115.11 KiB
Changelog:
  * Wed Aug 11 2021 Petr Menk  - 20210803-1
  - Update to 20210803


Package:  bpfmon-2.50-1.fc35
Old package:  bpfmon-2.49-3.fc35
Summary:  Traffic monitor for BPF expression/iptables rule
RPMs: bpfmon
Size: 157.73 KiB
Size change:  2.59 KiB
Changelog:
  * Tue Sep 21 2021 Boian Bonev  - 2.50-1
  - New version 2.50


Package:  c-ares-1.17.2-1.module_f35+12941+0548739f
Old package:  c-ares-1.17.1-2.module_f35+11948+8d2b9da3
Summary:  A library that performs asynchronous DNS operations
RPMs: c-ares c-ares-devel
Size: 997.35 KiB
Size change:  -1.17 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
1.17.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Mon Aug 16 2021 Tom Callaway  - 1.17.2-1
  - update to 1.17.2
  - fixes multiple security issues including CVE-2021-3672


Package:  cli11-2.1.0-1.fc35
Old package:  cli11-2.0.0-1.fc35
Summary:  Command line parser for C++11
RPMs: cli11-devel cli11-docs
Size: 4.53 MiB
Size change:  -488.56 KiB
Changelog:
  * Tue Sep 21 2021 Jerry James  - 2.1.0-1
  - Version 2.1.0


Package:  clipit-1.4.5-4.D20210513gite5fa64c.fc35
Old package:  clipit-1.4.5-3.fc35
Summary:  A lightweight, fully featured GTK+ clipboard manager
RPMs: clipit
Size: 514.75 KiB
Size change:  78.57 KiB
Changelog:
  * Wed Sep 22 2021 Mamoru TASAKA  - 
1.4.5-4.D20210513gite5fa64c
  - Update to the latest git
- increase POPUP_DELAY to workaround hotkey popup issue


Package:  cockpit-composer-31-1.fc35
Old package:  cockpit-composer-30-2.fc35
Summary:  Composer GUI for use with Cockpit
RPMs: cockpit-composer
Size: 2.00 MiB
Size change:  20.65 KiB
Changelog:
  * Thu Aug 26 2021 Jacob Kozol  - 31-1
  - Add new ostree image types
  - Improve loading state when waiting for api responses
  - Improve notification system
  - Improve test stability
  - Update NPM dependencies
  - Update translations


Package:  cppzmq-4.8.1-1.fc35
Old package:  cppzmq-4.8.0-1.fc35
Summary:  Header-only C++ binding for libzmq
RPMs: cppzmq-devel
Size: 196.68 KiB
Size change:  224 B
Changelog:
  * Wed Sep 22 2021 Elliott Sales de Andrade  4.8.1-1
  - Update to latest version (#2005750)


Package:  createrepo_c-0.17.5-1.fc35
Old package:  createrepo_c-0.17.3-2.fc35
Summary:  Creates a common metadata repository
RPMs: createrepo_c createrepo_c-devel createrepo_c-libs 
python3-createrepo_c
Size: 2.80 MiB
Size change:  2.54 KiB
Changelog:
  * Wed Sep 15 2021 Pavla Kratochvilova  - 0.17.5-1
  - Update to 0.17.5
  - Fix error when updating repo with removed modules metadata
  - Exit with status code 1 when loading of repo's metadata fails
  - Fix memory leaks and covscan warnings


Package:  dnf-4.9.0-1.fc35
Old package:  dnf-4.8.0-2.fc35
Summary:  Package manager
RPMs: dnf dnf-automatic dnf-data python3-dnf yum
Size: 993.60 KiB
Size change:  -4.36 KiB
Changelog:
  * Thu Sep 23 2021 Pavla Kratochvilova  - 4.9.0-1
  - Update to 4.9.0
  - [API] Add method "set_or_append_opt_value" to BaseConfig (RhBug:1967925)
  - A

Re: Using YubiKey for accounts.fedoraproject.org OTP?

[Miro Hrončok]

On 27. 09. 21 15:50, Stephen John Smoogen wrote:

On Mon, 27 Sept 2021 at 09:28, Miro Hrončok  wrote:


Hello,

I've been trying to add the OPT token from accounts.fedoraproject.org to my
yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.

I copypasted the xxx secret (56 characters: digits and uppercase letters) and
tried to add it via YubiKey Manager GUI via Applications/OTP as OATH-HOTP (6
digits).

I get "Failed to configure Long Touch (Slot 2). undefined" error.

When I tried to use the CLI:

  $ ykman otp hotp -d 6 -c 0 2 xxx

I get "Error: key lengths >20 bytes not supported".

Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the
device not compatible?



OK let's back up a bit, since I am looking at a working yubikey for
Fedora OTP at the moment. The first thing we need to see is if the key
you are using is compatible. There are multiple generations and they
use different commands to program them :/. The ones I know which work
are the older 'black' yubikeys. The newer blue ones, do not seem to
work with the Fedora commands shipped. If I run


I am looking at my yubikeys and they all work. I know that every
sysadmin in Fedora has been using yubikeys for years. So I am guessing
something else is going on here for this device. Here is what I get
from my two Fedora ones

```
$ # This is my oldest key which works for Fedora
$ ykinfo -t -i -p -I -1 -2
touch_level: 1793
programming_sequence: 1
slot1_status: 1
slot2_status: 0
vendor_id: 1050
product_id: 10

$ # This is my 2nd gen black key and was keyed to Fedora during testing.
$ ykinfo -t -i -p -I -1 -2
touch_level: 1285
programming_sequence: 1
slot1_status: 1
slot2_status: 0
vendor_id: 1050
product_id: 110

$ # This is a blue key which I use for other websites because Fedora
commands give me
$ ykinfo -t -i -p -I -1 -2
Yubikey core error: no yubikey present


Sorry for not mentioning that. It is a YubiKey 5 Nano with 5.4.3 firmware:

$ ykinfo -t -i -p -I -1 -2
touch_level: 1029
programming_sequence: 11
slot1_status: 1
slot2_status: 0
vendor_id: 1050
product_id: 407


BTW I know that sysadmins used YubiKeys even before noggin, there's the 
fedora-burn-yubikey command (installed via fedora-packager-yubikey), but it 
talks to the old FAS instead of the new one.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Mat Booth]

On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones  wrote:
>
> On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote:
> > On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones  wrote:
> > >
> > > A question about this which is semi-related to your email.
> > >
> > > For some C library packages we have Java bindings, eg:
> > > https://github.com/libguestfs/libguestfs/tree/master/java
> > >
> > > These have been disabled in Fedora for ~2 years, but when they were
> > > around they had these BuildRequires:
> > >
> > >   BuildRequires: java-1.8.0-openjdk
> > >   BuildRequires: java-1.8.0-openjdk-devel
> > >   BuildRequires: jpackage-utils
> > >
> > > I believe the only requirements are javac, javah, javadoc (optional)
> > > and a JVM to run the tests on.
> > >
> > > Is it possible to keep this going, or would that require a lot of
> > > work?  I notice that javah no longer seems to exist.
> > >
> > > (Note I know almost nothing about how the modern JDK works)
> > >
> > > Rich.
> >
> > Hi, the functionality provided by javah has been folded into javac in
> > recent JDKs.
> >
> > These days you can make one call to "javac -h" instead of having to
> > call both "javac" and "javah"
> >
> > I ported quite a few packages this way when Fedora made the switch to
> > Java 11 by default. If you like I can probably take a look libguestfs
> > and send you a PR?
>
> Sure thing, thanks.
>
> However before you start you might also want to know that there are
> apparently some serious GC-related problems with how those bindings
> work:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1536762
>
> so it might be more of a saga than just changing a few commands.
>
> Rich.

Hi Rich,

TBH it looks like your Java bindings should build fine on Java 11
since this change:

https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75

>
> >
> > >
> > > --
> > > Richard Jones, Virtualization Group, Red Hat 
> > > http://people.redhat.com/~rjones
> > > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > > virt-p2v converts physical machines to virtual machines.  Boot with a
> > > live CD or over the network (PXE) and turn machines into KVM guests.
> > > http://libguestfs.org/virt-v2v
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > https://docs.fedoraproject.org/en-US/project/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
> >
> >
> >
> > --
> > Mat Booth
> > http://fedoraproject.org/get-fedora
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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
>
> --
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: Fedora  Java: The Death of Two SIGs

[Stephen John Smoogen]

On Sun, 26 Sept 2021 at 16:35, Christopher  wrote:
>
> I think part of the problem is that Java is too big. There are too
> many libraries to fit into a single community. I think there's
> probably willing volunteers to maintain some libraries and application
> packages, but these are not necessarily the same people willing to do
> all the work of maintaining OpenJDK packages or the whole Eclipse
> stack.
>
> When modularity took out the whole Java stack, it did a lot of lasting
> damage that is going to be hard to recover from. In order for the vast
> majority of Java packagers to return, there needs to be a reliable

I am going to disagree here greatly. The Java stack was in exactly the
same mode it is in now before then. There was 1 person 'maintaining'
hundreds of packages for a long time. There were other 'maintainers'
listed but they were not around or ignoring things from burnout.
People had brought this up year after year and all that would happen
is everyone would say "we can't ever let things down" and pitch in to
fix things (or make the 1 person who was over-committed feel guilty
for asking to lighten the load).

Then when the defacto Java maintainer moved stuff into modules to make
his life easier.. there was a 'well we can find new people to do this
instead' and various initiatives were tried to make it. Those have all
failed because

1. Java and Fedora have a long back history of ugly fighting which
makes it hard for 'older' Java people want to work with Fedora. Like
old feuds, there are landmines which flare up fights no one remembers
exactly but they come up.
2. That ugly fighting is sort of written into the packaging guidelines
because it is a long 'compromise' between how Java wants packages done
and how Fedora wants it done. This makes it hard for 'new' Java people
because they are whiplashed between different world views. And vice
versa, if you aren't a Java person and try to make it fix a Java
package it can be a brain hurt as you try to do things like in other
packages and it all fails.
3. Most Fedora consumers just want the tools to work and pile onto the
smaller pool of developers about 'why is X always broken?' This has
caused continual burnout when new teams came up. It was also what was
burning out the previous people.

Basically Java has been 'broken' for as long as I have been part of
Fedora. The 'good' times are usually just after the last time Java was
going to be pulled out in the next release, and finally everyone drops
the things they really care for and works on it. Then everyone goes
back to their real pleasures and it falls apart again. Later, rinse,
repeat.


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: openbabel-3.1* in Rawhide

[Susi Lehtola]

On 9/26/21 05:07, Jerry James wrote:
> On Sat, Sep 25, 2021 at 5:10 PM Alexander Ploumistos
>  wrote:
>> I built the latest avogadro2 and avogadro2-libs from the srpm in your
>> copr for F34 and I hit some graphical glitches again. On Wayland,
>> Avogadro2 for X11 has a transparent canvas, whereas the other one (I
>> guess Wayland) doesn't, but as soon as I add a fourth atom to the
>> drawing, it crashes:
>>
>> /usr/include/c++/11/bits/stl_vector.h:1045: std::vector<_Tp,
>> _Alloc>::reference std::vector<_Tp,
>> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp =
>> Eigen::Matrix; _Alloc =
>> std::allocator >; std::vector<_Tp,
>> _Alloc>::reference = Eigen::Matrix&; std::vector<_Tp,
>> _Alloc>::size_type = long unsigned int]: Assertion '__n <
>> this->size()' failed.
>> Aborted (core dumped)
> 
> I don't know if this is the same as the inchi-related abort, but that
> one is caused by this code, on lines 178-180 of molecule_smiles.cpp,
> in Molecule::ToInChI():
> 
>   std::string s = ostream.str();
>   s[s.length() - 1] = '\0'; // Abort happens here
>   return ( QString( s.c_str() ) );
> 
> The abort happens because s is the empty string, so s.length() == 0,
> and assigning to s[-1] just isn't a good idea.  I'm pretty sure that
> line isn't needed anyway.  Isn't s.c_str() guaranteed to provide a
> null-terminated C string?

In addition to .c_str() providing a null-terminated C string, the above
code is wrong also in another sense: s.length() is the length of the
string EXCLUDING THE TERMINATOR so that code is in fact removing the
last letter of the string which can't be the purpose.

You can easily verify this behavior with

#include 
#include 

int main ()
{
  std::string str1(""), str2("c");
  std::cout << "str1.length()= " << str1.length() << ", str2.length()= "
<< str2.length() << std::endl;
  return 0;
}

which prints out

$ ./a.out
str1.length()= 0, str2.length()= 1
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Miro Hrončok]

On 27. 09. 21 15:01, Miro Hrončok wrote:

On 27. 09. 21 10:22, Kamil Paral wrote:

 > 3. Similarly to above (perhaps exactly the same case), what happens when
 > package Q (not installed) starts supplementing package P (installed), 
will

 > it get auto-installed or not?

    No, Q will be not installed. With supplements it is difficult to known when
    it appears, because that information is not on RPMDB.


While it makes sense technically, this might be quite confusing for packagers.


I've checked the status quo.

Package "reproducer_reversed" starts supplementing package "rpm". "rpm" is 
installed, but "reproducer_reversed" is not.


1. dnf upgarde, no rpm update available: reproducer_reversed is not pulled in
2. dnf reinstall rpm: reproducer_reversed is pulled in
3. dnf downgrade rpm: reproducer_reversed is pulled in
4. dnf upgrade rpm: reproducer_reversed is pulled in
5. dnf upgrade, rpm update avilable: reproducer_reversed is pulled in

Would this change proposal actually change the observed behavior? In what way?


I forgot to mention, here is a copr repo with reproducer_reversed: to play with

https://copr.fedorainfracloud.org/coprs/churchyard/reproducer_reversed/

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[Robert Marcano via devel]

On 9/26/21 3:20 PM, Fabio Valentini wrote:

Good evening everybody,

Not sure why it's me who's writing this message, but somebody needs to do it.

Community maintenance of Java packages in Fedora is, for all intents
and purposes, dead. Mikolaj keeps a bare minimum of packages working
for the maven toolchain, but that's it. Fedora 35 will ship without
packages for the Eclipse IDE, and none of the Java applications I know
of are still in working order. While I had hoped that setting up a
"new" SIG and gathering members to shore up community maintenance of
the "extended core" Java stack, this effort fizzled out after mere
weeks.

"He's dead, Jim."


I will add my view as someone that use to package a tiny few Java 
packages for Fedora (maily Eclipse plugins). My view may be outdated so 
everyone is free to correct me as always.


I think saying the Java ecosystem isn't friendly to traditional 
packaging could be said for any other modern language Fedora has 
accepted without a fuss. Go and Rust applications has made some of the 
traditional rules of dynamic loaded code having a preference being 
challenged by these "newcomers" that don't support it.


Meanwhile Java packages still are difficult because of the need of 
everything to be split on multiple packages and every jar found being 
replaced by symlinks to files in /usr/java/*. In Eclipse plugins this 
remain more difficult, because plugins al already jars with embeeded 
jars where a custom classloader is able to load things withour having 
everything extracted on the filesystem.


I think the only way the Java ecosystem to survive in Fedora outside of 
OpenJDK and some core components is to allow bundling (Even JavaScript 
bundling is already allowed), but how do to it without compromising 
security?


1. I propose that every package should use a modern Java build system 
that resolve dependencies (Maven, Gradle, Ant+Ivy, etc), If the package 
doesn't have that, a patch should be provided and contributed upstream.


2. We have automation to extract the dependencies required by the main 
package and allow the Fedora build system to automate the creation of 
packages for these dependencies from source and generate for example 
subpackages *-mave or something like that, that provides these 
dependencies as maven repositories locally to be use by other packages.


3. Packages embeede thes libraries like they upstream do, without having 
to patch hundred of build script to use links to /usr/java.


4. Automate that dependencies updates should trigger dependent packages 
rebuild


This as dependent Jar files as "source code" like Rust and Go are 
currently packages.


Without a process simplification for the packages like this one, or 
something better. The Java applications ecosystem being packaged on 
Fedora will not be resurrected.




Now to the reason why I feel the need to beat a dead horse: I wonder
if the @java-maint-sig group should actually continue to exist (or
rather, be maintainer or bugzilla assignee for packages, because I
don't even know if FAS groups can be deleted). It seems that none of
the current members (I am no longer one of them) are active. Bugs,
including security issues with assigned CVE numbers, are collecting
dust. Packages get orphaned and retired one by one because they fail
to build or install.

At this point, I'm still the only person with the password for the
SIG's bugzilla account and the only administrator of the private
mailing list - just because I wouldn't even know who to hand those
things over to (fedora-infra?). There's nobody left, nobody is reading
the mailing lists. Only tumbleweeds are here.

Should the @java-maint-sig group be removed from any packages it is
still associated with? Should it be dissolved, and members be removed?
Should the remaining ruins that used to be packages be orphaned?
Retired? Buried? Forgotten?

I don't know.

Fabio

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

Re: Fedora  Java: The Death of Two SIGs

[PGNet Dev]

So if you only rely in things like OpenJDK (like for running
Minecraft, as I do, too), then you'll be fine.
If you need ant or maven, you should be fine too, since those two (and
their dependencies) will continue to be maintained.
But everything else ... *tumbleweeds*


Just one user's snapshot; On a not-atypical dev-box here, installed java apps 
are

PHPStorm (upstream snap)
IntelliJ*  (upstream snap)
Eclipse (upstream tarball)
DBeaver-CE (upstream rpm)
android-studio (upstream)

In dev-user cases, any additional 'needed' apps are typically getting installed 
from upstreams -- as tarballs, snaps, flatpaks, or rpms.  Seldom, if ever, from 
Fedora pkgs.


and pkgs
rpm -qa | egrep -i "java|jdk|mvn|maven" | sort
copy-jdk-configs-4.0-1.fc34.noarch
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
java-11-openjdk-devel-11.0.12.0.7-4.fc34.x86_64
java-11-openjdk-headless-11.0.12.0.7-4.fc34.x86_64
java-latest-openjdk-17.0.0.0.35-1.rolling.fc34.x86_64
java-latest-openjdk-devel-17.0.0.0.35-1.rolling.fc34.x86_64
java-latest-openjdk-headless-17.0.0.0.35-1.rolling.fc34.x86_64
javapackages-filesystem-5.3.0-15.fc34.noarch
javapackages-tools-5.3.0-15.fc34.noarch
maven-3.6.3-8.fc34.noarch
maven-archiver-3.5.1-1.fc34.noarch
maven-artifact-2.2.1-67.fc34.noarch
maven-artifact-transfer-0.11.0-5.fc34.noarch
maven-common-artifact-filters-3.1.1-1.fc34.noarch
maven-compiler-plugin-3.8.1-8.fc34.noarch
maven-dependency-tree-3.0.1-6.fc34.noarch
maven-doxia-core-1.9.1-4.fc34.noarch
maven-doxia-logging-api-1.9.1-4.fc34.noarch
maven-doxia-module-apt-1.9.1-4.fc34.noarch
maven-doxia-module-fml-1.9.1-4.fc34.noarch
maven-doxia-module-xdoc-1.9.1-4.fc34.noarch
maven-doxia-module-xhtml-1.9.1-4.fc34.noarch
maven-doxia-module-xhtml5-1.9.1-4.fc34.noarch
maven-doxia-sink-api-1.9.1-4.fc34.noarch
maven-doxia-sitetools-1.9.2-4.fc34.noarch
maven-file-management-3.0.0-12.fc34.noarch
maven-filtering-3.2.0-2.fc34.noarch
maven-jar-plugin-3.2.0-5.fc34.noarch
maven-lib-3.6.3-8.fc34.noarch
maven-model-2.2.1-67.fc34.noarch
maven-plugin-bundle-4.2.1-4.fc34.noarch
maven-reporting-api-3.0-21.fc34.noarch
maven-resolver-api-1.4.2-5.fc34.noarch
maven-resolver-connector-basic-1.4.2-5.fc34.noarch
maven-resolver-impl-1.4.2-5.fc34.noarch
maven-resolver-spi-1.4.2-5.fc34.noarch
maven-resolver-transport-wagon-1.4.2-5.fc34.noarch
maven-resolver-util-1.4.2-5.fc34.noarch
maven-resources-plugin-3.2.0-2.fc34.noarch
maven-shared-incremental-1.1-21.fc34.noarch
maven-shared-io-3.0.0-12.fc34.noarch
maven-shared-utils-3.2.1-0.8.fc34.noarch
maven-source-plugin-3.2.1-4.fc34.noarch
maven-surefire-3.0.0~M4-1.fc34.noarch
maven-surefire-plugin-3.0.0~M4-1.fc34.noarch
maven-surefire-provider-junit-3.0.0~M4-1.fc34.noarch
maven-toolchain-2.2.1-67.fc34.noarch
maven-wagon-file-3.4.2-1.fc34.noarch
maven-wagon-http-3.4.2-1.fc34.noarch
maven-wagon-http-shared-3.4.2-1.fc34.noarch
maven-wagon-provider-api-3.4.2-1.fc34.noarch
system-switch-java-1.1.8-5.fc34.noarch
tzdata-java-2021a-1.fc34.noarch
xz-java-1.8-10.fc34.noarch


everything ELSE gets built locally -- either per-machine, or on our in-house 
distro/pgg'ing -- as needed.

similarly, on not-atypical non-dev end-user around here,

rpm -qa | egrep -i "java|jdk|mvn|maven" | sort
copy-jdk-configs-4.0-1.fc34.noarch
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
java-11-openjdk-devel-11.0.12.0.7-4.fc34.x86_64
java-11-openjdk-headless-11.0.12.0.7-4.fc34.x86_64
java-latest-openjdk-17.0.0.0.35-1.rolling.fc34.x86_64
java-latest-openjdk-devel-17.0.0.0.35-1.rolling.fc34.x86_64
java-latest-openjdk-headless-17.0.0.0.35-1.rolling.fc34.x86_64
javapackages-filesystem-5.3.0-15.fc34.noarch
javapackages-tools-5.3.0-15.fc34.noarch
system-switch-java-1.1.8-5.fc34.noarch
tzdata-java-2021a-1.fc34.noarch

and that's mostly it.

And again, in _some_ end-user cases, any 'needed' end-user apps are getting 
installed from upstreams -- as tarballs, snaps, flatpaks, or rpms.  Seldom, if 
ever, from Fedora 

Re: Using YubiKey for accounts.fedoraproject.org OTP?

[Kevin Fenzi]

On Mon, Sep 27, 2021 at 04:28:03PM +0200, Miro Hrončok wrote:
> On 27. 09. 21 16:07, Pierre-Yves Chibon wrote:
> > On Mon, Sep 27, 2021 at 03:27:43PM +0200, Miro Hrončok wrote:
> > > Hello,
> > > 
> > > I've been trying to add the OPT token from accounts.fedoraproject.org to 
> > > my
> > > yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.
> > > 
> > > I copypasted the xxx secret (56 characters: digits and uppercase letters)
> > > and tried to add it via YubiKey Manager GUI via Applications/OTP as
> > > OATH-HOTP (6 digits).
> > > 
> > > I get "Failed to configure Long Touch (Slot 2). undefined" error.
> > > 
> > > When I tried to use the CLI:
> > > 
> > >  $ ykman otp hotp -d 6 -c 0 2 xxx
> > > 
> > > I get "Error: key lengths >20 bytes not supported".
> > > 
> > > Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is 
> > > the
> > > device not compatible?
> > 
> > You may want to check: https://github.com/fedora-infra/noggin/issues/202
> 
> Thanks. From that ticket I am not quite sure what the status actually is and
> what are the next step. Should I post my failed experiment there?

My understanding: IPA supports yubikey HOTP, but noggin (the web
frontend) does not. So, it's not supported currently. You must use TOTP. 
:( 

I'll poke that ticket and see if we can move forward tho. 

kevin


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

Re: Fedora  Java: The Death of Two SIGs

[Stephen John Smoogen]

On Mon, 27 Sept 2021 at 08:45, Peter Boy  wrote:
>
>
>
> > Am 27.09.2021 um 12:30 schrieb Fabio Valentini :
> >
> > On Mon, Sep 27, 2021 at 12:19 PM Peter Boy  wrote:
> >>
> >>
> >>
> >>> Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon :
> >>>
> >>> On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
> 
> >>>
>  What do you want to gain from it? What is the goal to be?
> >>>
> >>> I believe the original email from Fabio answers both of these questions.
> >>
> >> I don’t find a plan or a goal. Please, provide me with a hint.
> >
> > All I wanted to say is that the current state is disingenuous at best,
> > and misleading at first.
>
> Unfortunately yes, indeed.
>
> > By having @java-maint-sig as one of the admins of a package (and for
> > most of them, also the default bugzilla assignee), while that group
> > doesn't really function any longer, a false expectation of "there's a
> > whole group of people maintaining this package", while the reality is
> > closer to "zero or maybe one person might be looking at this package
> > once a year".
>
> I think you characterize the situation very pessimistically. Obviously the 
> constructions work to a certain extent. For example, we have 3 different 
> versions of the JDK available in parallel, which also receive regular 
> updates. We have important applications as tomcat. So we have something to 
> build on.
>

Personally I think I found the characterization as being optimistic to
almost realistic.

There have been 3 to 5 reboots since 2008 each time with smaller
groups of people. The issue is that Java is not a 'hot-new-thing'
language that gets all the programmers running to the field. It is now
seen as the same as Pascal/COBOL was in the 1990's.. that thing you
learn in Freshman CS and then avoided unless you want to be an
accounting-programmer (aka COBOL).

There is nothing wrong with 'accounting-programmer' languages, and
they are rarely just used for accounting, but it is a simple label
people use on it. Java and languages like it are utility languages
where after spending a week getting some report or other application
to work, volunteering time to fix it for someone else is the last
thing you want to do. [As several Java programmers have put it, you
don't see plumbers volunteering to fix their neighbors pipes on
weekends.]

In the end, we have never been able to keep a pool of people
interested in making Java work. We aren't the only ones as this
problem occurs in Debian also (and it occurs in other languages like
Ruby, JS, Python also). The people who want to volunteer time on the
language are more likely to work in an area where others interested in
the language are already there. Dealing with the vaguries of 40
different slightly different disk layouts, file permissions, and other
tools  from every distribution are grit in the shoe when you already
have a 'working layout' and have people who speak your language and
problems elsewhere.





-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Using YubiKey for accounts.fedoraproject.org OTP?

[Pierre-Yves Chibon]

On Mon, Sep 27, 2021 at 03:27:43PM +0200, Miro Hrončok wrote:
> Hello,
> 
> I've been trying to add the OPT token from accounts.fedoraproject.org to my
> yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.
> 
> I copypasted the xxx secret (56 characters: digits and uppercase letters)
> and tried to add it via YubiKey Manager GUI via Applications/OTP as
> OATH-HOTP (6 digits).
> 
> I get "Failed to configure Long Touch (Slot 2). undefined" error.
> 
> When I tried to use the CLI:
> 
> $ ykman otp hotp -d 6 -c 0 2 xxx
> 
> I get "Error: key lengths >20 bytes not supported".
> 
> Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the
> device not compatible?

You may want to check: https://github.com/fedora-infra/noggin/issues/202


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

Re: Fedora  Java: The Death of Two SIGs

[Martin Jackson]

For what it's worth...

I use the OpenJDK on Fedora and I'm very happy with it.  I do not use or 
need eclipse, or as fast as I can tell, any of the other tooling (e.g. 
packaged gradle and other things).  My main uses are playing games that 
depend on Java and are packaged and built outside the Fedora toolchain.  
(One is minecraft, the other is called Megamek, a simulator for the 
tabletop war game Classic BattleTech.  minecraft...doesn't need to be 
built and megamek builds with gradle, which it knows how to download.)  
It hurts a bit to see posts like what were at the top of this thread - 
clearly Fabio and others have invested many hours into making a great 
experience for people, and I hate to see people feel that effort is 
wasted or that they're burning out.


I would like to thank those who have contributed to the Fedora java 
stack.  Maybe my case is unusual?  It meets my needs and I expect it 
will continue to.


Thanks,

Marty

On 9/27/21 09:03, PGNet Dev wrote:
Many valid/interesting points being made.  Most of them sound, 
reasonably, like developer-/maintainer-centric issues.


Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 
'service' its (java app) users?


If so, what's the current understanding of a user-driven 
ProductRequirements spec'n of JAVA apps 'round here?

Who's included in "users"? Developers? End-users? etc.
Perhaps I've missed it ...

I know as a representative of my end-users I've got plenty of opinions 
about our JAVA env.  Also as a representative of my org's JAVA devs.
But as a developer/maintainer OF java/apps @ Fedora, not much at all; 
the "solid OpenJDK & Maven" approach is good enuf here. Mostly.


And, if that^ is not a primary goal, then back to the discussion at hand.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

Re: Fedora  Java: The Death of Two SIGs

[Mario Torre]

On Mon, Sep 27, 2021 at 5:23 PM Fabio Valentini  wrote:

> I'm not sure about this (the internals of Red Hat are quite opaque),
> but as far as I know, are two different, non-overlapping teams
> involved here:
> One that maintains OpenJDK packages (which are fine), and one that
> maintains Java packages (which have been dying in Fedora for years).
> (I'm sorry If I am misrepresenting the situation inside Red Hat, but
> this the extent of my knowledge.)

I think this is because different teams do different things and
projects and contributions to Fedora are generally driven by
individuals that follow up on their main projects and maintain them
for Fedora, so it's more than "two" but probably a lot less than
"teams" :)

This makes sense, since Fedora is a community effort.

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Miro Hrončok]

On 27. 09. 21 10:22, Kamil Paral wrote:

 > 3. Similarly to above (perhaps exactly the same case), what happens when
 > package Q (not installed) starts supplementing package P (installed), 
will
 > it get auto-installed or not?

No, Q will be not installed. With supplements it is difficult to known when
it appears, because that information is not on RPMDB.


While it makes sense technically, this might be quite confusing for packagers.


I've checked the status quo.

Package "reproducer_reversed" starts supplementing package "rpm". "rpm" is 
installed, but "reproducer_reversed" is not.


1. dnf upgarde, no rpm update available: reproducer_reversed is not pulled in
2. dnf reinstall rpm: reproducer_reversed is pulled in
3. dnf downgrade rpm: reproducer_reversed is pulled in
4. dnf upgrade rpm: reproducer_reversed is pulled in
5. dnf upgrade, rpm update avilable: reproducer_reversed is pulled in

Would this change proposal actually change the observed behavior? In what way?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[Mario Torre]

On Sun, Sep 26, 2021 at 10:36 PM Christopher  wrote:
>
> I think part of the problem is that Java is too big. There are too
> many libraries to fit into a single community. I think there's
> probably willing volunteers to maintain some libraries and application
> packages, but these are not necessarily the same people willing to do
> all the work of maintaining OpenJDK packages or the whole Eclipse
> stack.
>
> When modularity took out the whole Java stack, it did a lot of lasting
> damage that is going to be hard to recover from. In order for the vast
> majority of Java packagers to return, there needs to be a reliable
> base. I'm thinking OpenJDK (which I think is reliably maintained right
> now) and XMvn. Java packagers who might be willing to support a lot of
> the rest of the libraries (guava, commons-*, etc.) need to be able to
> rely on those core components being stable first. Then, when that
> trust is restored, I'm sure end-user applications will trickle in.
>
> Right now, I'm not sure there's adequate expertise to reestablish
> trust in the Java core tools for Java packagers to start coming back.

Just my 0.2 euro cents here.

The OpenJDK packages are well maintained, in fact, the packaging work
and their updates are done by the very same team that participate to
the upstream OpenJDK development.

Regarding Eclipse, it's really a lot of work and I understand this, so
effort moved toward a flatpack version of it. I'm not sure this saves
anything, and in my experience it actually introduces some problems,
but the Eclipse maintainers have a different opinion and I think we
should trust their judgment. However the majority of people just
usually download Eclipse (or IntelliJ for what matters) from the
upstream website anyway, further suggesting that maintaining Eclipse
is not really a rewarding nor useful task.

For maven, I don't think anyone really relies on installed packages
other than a few  (mostly because of cross/transitive dependency
reasons), so I'm not sure if there is any real benefit in having
packagers spending resources and time to maintain packages that
inevitably go out of sync.

I'm not sure what's the best solution, but I guess the number one
reason to have packages within the Fedora distribution is for a matter
of trust, if this is the case I would argue that a curated list of
maven packages served via a Fedora managed repository would be a
better investment.

For that to work we need a solid distribution of OpenJDK (which we
have) and a solid distribution of maven (which we also have).

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Using YubiKey for accounts.fedoraproject.org OTP?

[Miro Hrončok]

Hello,

I've been trying to add the OPT token from accounts.fedoraproject.org to my 
yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.


I copypasted the xxx secret (56 characters: digits and uppercase letters) and 
tried to add it via YubiKey Manager GUI via Applications/OTP as OATH-HOTP (6 
digits).


I get "Failed to configure Long Touch (Slot 2). undefined" error.

When I tried to use the CLI:

$ ykman otp hotp -d 6 -c 0 2 xxx

I get "Error: key lengths >20 bytes not supported".

Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the 
device not compatible?


Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Using YubiKey for accounts.fedoraproject.org OTP?

[Miro Hrončok]

On 27. 09. 21 16:07, Pierre-Yves Chibon wrote:

On Mon, Sep 27, 2021 at 03:27:43PM +0200, Miro Hrončok wrote:

Hello,

I've been trying to add the OPT token from accounts.fedoraproject.org to my
yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.

I copypasted the xxx secret (56 characters: digits and uppercase letters)
and tried to add it via YubiKey Manager GUI via Applications/OTP as
OATH-HOTP (6 digits).

I get "Failed to configure Long Touch (Slot 2). undefined" error.

When I tried to use the CLI:

 $ ykman otp hotp -d 6 -c 0 2 xxx

I get "Error: key lengths >20 bytes not supported".

Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the
device not compatible?


You may want to check: https://github.com/fedora-infra/noggin/issues/202


Thanks. From that ticket I am not quite sure what the status actually is and 
what are the next step. Should I post my failed experiment there?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[Solomon Peachy]

On Mon, Sep 27, 2021 at 10:24:23AM -0400, Robert Marcano via devel wrote:
> 1. I propose that every package should use a modern Java build system that
> resolve dependencies (Maven, Gradle, Ant+Ivy, etc), If the package doesn't
> have that, a patch should be provided and contributed upstream.

Any proposal that requires *more* work from Fedora package maintainers 
is a complete non-starter, given the harsh reality that there already 
isn't enough packager person-hours available to keep the Fedora Java 
ship afloat.

> Without a process simplification for the packages like this one, or
> something better. The Java applications ecosystem being packaged on Fedora
> will not be resurrected.

Yep; automate (to compensate for upstream culture) or die.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (libra.chat)


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

Reminder: Upcoming summer time changes

[Ben Cotton]

As a reminder, we've reached the point in the year where jurisdictions
around the world begin or end summer time. Be sure to check your
recurring meetings on Fedocal[1] to make sure you know when you're
meeting. Some meetings are set to a fixed time UTC and others are set
to a particular time zone.

A global list of time changes is available by country[2] and by
date[3], but here are a few highlights:

* 3 October: summer time begins in Australia
* 31 October: summer time ends in Europe, the UK, and parts of Mexico
* 7 November: summer time ends in the US, Canada, and parts of Mexico

[1] https://apps.fedoraproject.org/calendar/
[2] https://www.timeanddate.com/time/dst/2021.html
[3] https://www.timeanddate.com/time/dst/2021b.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Max age of side tags?

[Kevin Fenzi]

On Mon, Sep 27, 2021 at 11:58:44AM +0100, Richard W.M. Jones wrote:
> OCaml 4.13 has just come out and we'll be rebuilding all the OCaml
> packages in Rawhide into a side tag.  Jerry James - who maintains some
> of these packages - is not going to be available this week.  That
> means if I starts the builds now, we might need to keep the side tag
> open for 2 or 3 weeks, whereas normally we'd complete everything in a
> few days.
> 
> Is this a problem?  I vaguely recall that side tags had a short
> maximum age (2 weeks?) but I cannot find anything about that in the
> docs now.
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/
> 
> If it's a problem then I can start doing the builds next week instead.

It's currently set to clean up/remove side tags that are over 30days
old, or over 14 days with nothing tagged into them. 

There was an announcement email, but yeah, should also be in docs. 
Any thoughts on where best to put it?

kevin


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

Fedora-IoT-36-20210927.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 1/16 (x86_64), 3/15 (aarch64)

Old failures (same test failed in Fedora-IoT-36-20210921.0):

ID: 1003647 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1003647
ID: 1003657 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/1003657
ID: 1003662 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1003662
ID: 1003666 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/1003666

Passed openQA tests: 12/15 (aarch64), 15/16 (x86_64)

New passes (same test not passed in Fedora-IoT-36-20210921.0):

ID: 1003665 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/1003665

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.39 to 0.24
Previous test data: https://openqa.fedoraproject.org/tests/993703#downloads
Current test data: https://openqa.fedoraproject.org/tests/1003651#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
1 services(s) removed since previous compose: dbus-parsec.service
Previous test data: https://openqa.fedoraproject.org/tests/993708#downloads
Current test data: https://openqa.fedoraproject.org/tests/1003656#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Test-Announce] 2021-09-27 @ 15:00 UTC - Fedora QA Meeting

[Luna Jernberg]

Having time and energy to attend again today

On Sat, Sep 25, 2021 at 4:46 AM Adam Williamson 
wrote:

> # Fedora Quality Assurance Meeting
> # Date: 2021-09-27
> # Time: 15:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location: #fedora-meeting on irc.libera.chat
>
> Greetings testers!
>
> Fedora 35 Beta comes out next week, so let's check in and make sure
> we're prepared.
>
> If anyone has any other items for the agenda, please reply to this
> email and suggest them! Thanks.
>
> == Proposed Agenda Topics ==
>
> 1. Previous meeting follow-up
> 2. Fedora 35 status
> 3. Test Day / community event status
> 4. Open floor
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
> ___
> test-announce mailing list -- test-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> test-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[PGNet Dev]

Many valid/interesting points being made.  Most of them sound, reasonably, like 
developer-/maintainer-centric issues.

Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 'service' its 
(java app) users?

If so, what's the current understanding of a user-driven ProductRequirements 
spec'n of JAVA apps 'round here?
Who's included in "users"? Developers? End-users? etc.
Perhaps I've missed it ...

I know as a representative of my end-users I've got plenty of opinions about 
our JAVA env.  Also as a representative of my org's JAVA devs.
But as a developer/maintainer OF java/apps @ Fedora, not much at all; the "solid OpenJDK 
& Maven" approach is good enuf here.  Mostly.

And, if that^ is not a primary goal, then back to the discussion at hand.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[Fabio Valentini]

On Mon, Sep 27, 2021 at 4:56 PM Martin Jackson  wrote:
>
> For what it's worth...
>
> I use the OpenJDK on Fedora and I'm very happy with it.  I do not use or
> need eclipse, or as fast as I can tell, any of the other tooling (e.g.
> packaged gradle and other things).  My main uses are playing games that
> depend on Java and are packaged and built outside the Fedora toolchain.
> (One is minecraft, the other is called Megamek, a simulator for the
> tabletop war game Classic BattleTech.  minecraft...doesn't need to be
> built and megamek builds with gradle, which it knows how to download.)
> It hurts a bit to see posts like what were at the top of this thread -
> clearly Fabio and others have invested many hours into making a great
> experience for people, and I hate to see people feel that effort is
> wasted or that they're burning out.
>
> I would like to thank those who have contributed to the Fedora java
> stack.  Maybe my case is unusual?  It meets my needs and I expect it
> will continue to.

Not at all, this is not unusual. If you need nothing but the JDK, then
you'll be fine.

I'm not sure about this (the internals of Red Hat are quite opaque),
but as far as I know, are two different, non-overlapping teams
involved here:
One that maintains OpenJDK packages (which are fine), and one that
maintains Java packages (which have been dying in Fedora for years).
(I'm sorry If I am misrepresenting the situation inside Red Hat, but
this the extent of my knowledge.)

So if you only rely in things like OpenJDK (like for running
Minecraft, as I do, too), then you'll be fine.
If you need ant or maven, you should be fine too, since those two (and
their dependencies) will continue to be maintained.
But everything else ... *tumbleweeds*

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

Re: Using YubiKey for accounts.fedoraproject.org OTP?

[Miro Hrončok]

On 27. 09. 21 17:48, Kevin Fenzi wrote:

On Mon, Sep 27, 2021 at 04:28:03PM +0200, Miro Hrončok wrote:

On 27. 09. 21 16:07, Pierre-Yves Chibon wrote:

On Mon, Sep 27, 2021 at 03:27:43PM +0200, Miro Hrončok wrote:

Hello,

I've been trying to add the OPT token from accounts.fedoraproject.org to my
yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.

I copypasted the xxx secret (56 characters: digits and uppercase letters)
and tried to add it via YubiKey Manager GUI via Applications/OTP as
OATH-HOTP (6 digits).

I get "Failed to configure Long Touch (Slot 2). undefined" error.

When I tried to use the CLI:

  $ ykman otp hotp -d 6 -c 0 2 xxx

I get "Error: key lengths >20 bytes not supported".

Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the
device not compatible?


You may want to check: https://github.com/fedora-infra/noggin/issues/202


Thanks. From that ticket I am not quite sure what the status actually is and
what are the next step. Should I post my failed experiment there?


My understanding: IPA supports yubikey HOTP, but noggin (the web
frontend) does not. So, it's not supported currently. You must use TOTP.
:(

I'll poke that ticket and see if we can move forward tho.


Indeed. With help from bachradsusi/plautrba on IRC, I was able to do:

$ ykman oath add -o TOTP -d 6 -t accounts.fedoraproject.org 

And now I can do:

$ ykman oath code accounts.fedoraproject.org
Touch your YubiKey...
accounts.fedoraproject.org  123456

Which is nice, however originally I wanted to be able to just touch the device 
to insert the code as if it was typed on my keyboard. That seems to work with 
my another HOTP-token based auth, but not with Fedora's TOTP one.


So this seems to boil down to HOTP support in Noggin.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

No FESCo Meeting today (2021-09-27)

[Neal Gompa]

There is nothing on the agenda, so I'm canceling this week's meeting.
I'll pick this up again next week if we have anything.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Max age of side tags?

[Richard W.M. Jones]

On Mon, Sep 27, 2021 at 08:40:08AM -0700, Kevin Fenzi wrote:
> On Mon, Sep 27, 2021 at 11:58:44AM +0100, Richard W.M. Jones wrote:
> > OCaml 4.13 has just come out and we'll be rebuilding all the OCaml
> > packages in Rawhide into a side tag.  Jerry James - who maintains some
> > of these packages - is not going to be available this week.  That
> > means if I starts the builds now, we might need to keep the side tag
> > open for 2 or 3 weeks, whereas normally we'd complete everything in a
> > few days.
> > 
> > Is this a problem?  I vaguely recall that side tags had a short
> > maximum age (2 weeks?) but I cannot find anything about that in the
> > docs now.
> > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/
> > 
> > If it's a problem then I can start doing the builds next week instead.
> 
> It's currently set to clean up/remove side tags that are over 30days
> old, or over 14 days with nothing tagged into them. 
> 
> There was an announcement email, but yeah, should also be in docs. 
> Any thoughts on where best to put it?

I guess it's good that I wasn't imagining it!  In the page
linked above probably.

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

Re: Need help pushing updates to bodhi (tagging problem)

[Mattia Verga via devel]

On 27/09/21 12:47, Qiyu Yan wrote:
> Hi all,
>
> Yesterday I updated some fcitx5 related packages for f34 and f35, they
> are built in side-tags. But a bug in my scripts causes one package
> (fcitx5-mozc) did not build. Before I realized this, I have already
> pushed the update in bodhi. Then I manually built it in side-tags, and
> updated bodhi update manually (by using "edit" and the refersh
> button). Then since those side-tags will not be used anymore, I
> removed them.
>
You shouldn't have removed the side-tag manually, Bodhi takes care of
removing the side-tag when it is not needed anymore. By removing the
side-tag manually while the update was still processed, you broke Bodhi
workflow.

The only way I can think you can fix things now is:

- unpush those two updates
- request two new side-tags for f35 and f34
- manually tag the already created builds into the appropriate new
side-tag (with koji tag-build   [ ...])
- create the new Bodhi updates for those two new side-tags

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

Re: Fedora ? Java: The Death of Two SIGs

[Mat Booth]

On Mon, 27 Sept 2021 at 17:31, Richard W.M. Jones  wrote:
>
> On Mon, Sep 27, 2021 at 04:39:03PM +0100, Mat Booth wrote:
> > On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones  wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1536762
> > >
> > > so it might be more of a saga than just changing a few commands.
> > >
> > > Rich.
> >
> > Hi Rich,
> >
> > TBH it looks like your Java bindings should build fine on Java 11
> > since this change:
> >
> > https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75
>
> You're right - I checked just now using:
>
> java-11-openjdk-headless-11.0.11.0.9-4.fc35.x86_64
> javapackages-filesystem-6.0.0-1.fc35.noarch
> javapackages-tools-6.0.0-1.fc35.noarch
>
> Tests pass too.
>
> The bug above is a bit worrying though.  I don't think anyone ever
> tried to address those issues.  I don't know enough to say if they're
> real or nice to haves, but they seem serious.
>

I think the only super serious one is the local reference leaks --
this can be fatal to an application. The other concerns seem "just"
perf-related.

> BTW another project that would be fun for Java bindings (none exist
> presently) is nbdkit https://gitlab.com/nbdkit/nbdkit
>
> Rich.




-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedora-35-20210927.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/204 (x86_64), 5/141 (aarch64)

New failures (same test not failed in Fedora-35-20210925.n.1):

ID: 1003317 Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/1003317
ID: 1003337 Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/1003337
ID: 1003429 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1003429
ID: 1003620 Test: aarch64 universal upgrade_2_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1003620

Old failures (same test failed in Fedora-35-20210925.n.1):

ID: 1003383 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1003383
ID: 1003472 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1003472
ID: 1003495 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1003495
ID: 1003537 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1003537
ID: 1003566 Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1003566
ID: 1003601 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1003601

Soft failed openQA tests: 4/204 (x86_64), 4/141 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-35-20210925.n.1):

ID: 1003357 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1003357
ID: 1003399 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1003399
ID: 1003400 Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/1003400
ID: 1003411 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1003411
ID: 1003418 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1003418
ID: 1003475 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1003475
ID: 1003484 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1003484
ID: 1003502 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1003502

Passed openQA tests: 195/204 (x86_64), 132/141 (aarch64)

New passes (same test not passed in Fedora-35-20210925.n.1):

ID: 1003323 Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/1003323
ID: 1003336 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/1003336
ID: 1003340 Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/1003340
ID: 1003386 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1003386
ID: 1003581 Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1003581
ID: 1003627 Test: aarch64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/1003627

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 198 MiB to 218 MiB
3 packages(s) added since previous compose: chkconfig, guile22, 
initscripts-service
1 packages(s) removed since previous compose: guile
Previous test data: https://openqa.fedoraproject.org/tests/1001955#downloads
Current test data: https://openqa.fedoraproject.org/tests/1003291#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
3 packages(s) added since previous compose: chkconfig, guile22, 
initscripts-service
1 packages(s) removed since previous compose: guile
Previous test data: https://openqa.fedoraproject.org/tests/1001956#downloads
Current test data: https://openqa.fedoraproject.org/tests/1003292#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
2 packages(s) added since previous compose: chkconfig, initscripts-service
Previous test data: https://openqa.fedoraproject.org/tests/1002011#downloads
Current test data: https://openqa.fedoraproject.org/tests/1003347#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
2 packages(s) added since previous compose: chkconfig, initscripts-service
Previous test data: https://openqa.fedoraproject.org/tests/1002014#downloads
Current test data: https://openqa.fedoraproject.org/tests/1003350#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
2 packages(s) added 

Re: Need help pushing updates to bodhi (tagging problem)

[Mattia Verga via devel]

On 27/09/21 18:41, Mattia Verga wrote:
> On 27/09/21 12:47, Qiyu Yan wrote:
>> Hi all,
>>
>> Yesterday I updated some fcitx5 related packages for f34 and f35, they
>> are built in side-tags. But a bug in my scripts causes one package
>> (fcitx5-mozc) did not build. Before I realized this, I have already
>> pushed the update in bodhi. Then I manually built it in side-tags, and
>> updated bodhi update manually (by using "edit" and the refersh
>> button). Then since those side-tags will not be used anymore, I
>> removed them.
>>
> You shouldn't have removed the side-tag manually, Bodhi takes care of
> removing the side-tag when it is not needed anymore. By removing the
> side-tag manually while the update was still processed, you broke Bodhi
> workflow.
>
> The only way I can think you can fix things now is:
>
> - unpush those two updates
> - request two new side-tags for f35 and f34
> - manually tag the already created builds into the appropriate new
> side-tag (with koji tag-build   [ ...])
> - create the new Bodhi updates for those two new side-tags
>
> Mattia
>
BTW I've already unpushed the updates because they're breaking the compose.

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

Re: Fedora  Java: The Death of Two SIGs

[Raphael Groner]

Hi,

""
I'm not sure what's the best solution, but I guess the number one
reason to have packages within the Fedora distribution is for a matter
of trust, if this is the case I would argue that a curated list of
maven packages served via a Fedora managed repository would be a
better investment.
""
+1

Well, the modularity movement generally disappointed a lot of previously 
motivated maintainers but was a good decision imho. for java related stuff.

just my 5ct.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Need help pushing updates to bodhi (tagging problem)

[Mattia Verga via devel]

On 27/09/21 19:08, Mattia Verga wrote:
> On 27/09/21 18:41, Mattia Verga wrote:
>> On 27/09/21 12:47, Qiyu Yan wrote:
>>> Hi all,
>>>
>>> Yesterday I updated some fcitx5 related packages for f34 and f35, they
>>> are built in side-tags. But a bug in my scripts causes one package
>>> (fcitx5-mozc) did not build. Before I realized this, I have already
>>> pushed the update in bodhi. Then I manually built it in side-tags, and
>>> updated bodhi update manually (by using "edit" and the refersh
>>> button). Then since those side-tags will not be used anymore, I
>>> removed them.
>>>
>> You shouldn't have removed the side-tag manually, Bodhi takes care of
>> removing the side-tag when it is not needed anymore. By removing the
>> side-tag manually while the update was still processed, you broke Bodhi
>> workflow.
>>
>> The only way I can think you can fix things now is:
>>
>> - unpush those two updates
>> - request two new side-tags for f35 and f34
>> - manually tag the already created builds into the appropriate new
>> side-tag (with koji tag-build   [ ...])
>> - create the new Bodhi updates for those two new side-tags
>>
>> Mattia
>>
> BTW I've already unpushed the updates because they're breaking the compose.
>
> Mattia
>
>
(This is the last reply I promise...)

After I unpushed the updates, the builds got tagged into
fxx-updates-candidate, so you can just create "normal" updates without
bothering with creating new side-tags, etc

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

Re: Fedora  Java: The Death of Two SIGs

[Christopher]

On Mon, Sep 27, 2021 at 8:52 AM Stephen John Smoogen  wrote:
>
> On Sun, 26 Sept 2021 at 16:35, Christopher  wrote:
> >
> > I think part of the problem is that Java is too big. There are too
> > many libraries to fit into a single community. I think there's
> > probably willing volunteers to maintain some libraries and application
> > packages, but these are not necessarily the same people willing to do
> > all the work of maintaining OpenJDK packages or the whole Eclipse
> > stack.
> >
> > When modularity took out the whole Java stack, it did a lot of lasting
> > damage that is going to be hard to recover from. In order for the vast
> > majority of Java packagers to return, there needs to be a reliable
>
> I am going to disagree here greatly. The Java stack was in exactly the
> same mode it is in now before then. There was 1 person 'maintaining'
> hundreds of packages for a long time. There were other 'maintainers'
> listed but they were not around or ignoring things from burnout.
> People had brought this up year after year and all that would happen
> is everyone would say "we can't ever let things down" and pitch in to
> fix things (or make the 1 person who was over-committed feel guilty
> for asking to lighten the load).

I didn't mean to imply that there wasn't a problem before. I was
merely using the mass orphaning of the traditional packages in favor
of the modules as a point of reference in the timeline. I don't know
about the prior problems, only that there were problems that were
subsequent to, and worsened by, the mass orphaning event, regardless
of what led to it.

My main point here was that treating the community as a single SIG
makes no more sense than treating all packages whose software is
written in C as a single "C SIG" community. It's too overwhelming for
people to be able to know how to step in and help. It needs to be
pieced back together from the bottom up. OpenJDK packages seem to be
reliable and healthy. Eclipse seems to have some serious problems
(it's unclear to me how important Eclipse is, since upstream binaries
seem sufficient to me). I'm uncertain about XMvn and all the common
dependencies that used to be present, but I suspect this is where the
most damage was done, and the greatest room for volunteers... if it
weren't so overwhelming.

>
> Then when the defacto Java maintainer moved stuff into modules to make
> his life easier.. there was a 'well we can find new people to do this
> instead' and various initiatives were tried to make it. Those have all
> failed because
>
> 1. Java and Fedora have a long back history of ugly fighting which
> makes it hard for 'older' Java people want to work with Fedora. Like
> old feuds, there are landmines which flare up fights no one remembers
> exactly but they come up.
> 2. That ugly fighting is sort of written into the packaging guidelines
> because it is a long 'compromise' between how Java wants packages done
> and how Fedora wants it done. This makes it hard for 'new' Java people
> because they are whiplashed between different world views. And vice
> versa, if you aren't a Java person and try to make it fix a Java
> package it can be a brain hurt as you try to do things like in other
> packages and it all fails.
> 3. Most Fedora consumers just want the tools to work and pile onto the
> smaller pool of developers about 'why is X always broken?' This has
> caused continual burnout when new teams came up. It was also what was
> burning out the previous people.

I came in with none of that history. I saw XMvn, thought it was
awesome, and started packaging with it. Perhaps some of that
history/conflict affected some packagers, but I never saw it play a
big role, based on the timing of when I started contributing. Maybe it
played a big role, maybe it didn't. I think people who have been
around longer and have been more deeply involved might have a
different perspective than people who are newer and more casual
contributors. I worry that the long-timers may not be able to
understand how the new packager experiences contribute to Fedora's
problems (particularly the ability to keep up with attrition), and
only focus on the deep and/or historical problems, even when they have
little to no impact on newer folks who aren't aware of any of that.

>
> Basically Java has been 'broken' for as long as I have been part of
> Fedora. The 'good' times are usually just after the last time Java was
> going to be pulled out in the next release, and finally everyone drops
> the things they really care for and works on it. Then everyone goes
> back to their real pleasures and it falls apart again. Later, rinse,
> repeat.
>

My experience differs. I didn't find Java in Fedora broken at all when
I started. I actually found the set of available packages in Fedora to
be quite functional prior to the mass orphaning. It may have had its
community problems, and some out-of-date packages, but the overall
experience from this casual packager maintaining a few Java

Re: Fedora ? Java: The Death of Two SIGs

[Richard W.M. Jones]

On Mon, Sep 27, 2021 at 04:39:03PM +0100, Mat Booth wrote:
> On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones  wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1536762
> >
> > so it might be more of a saga than just changing a few commands.
> >
> > Rich.
> 
> Hi Rich,
> 
> TBH it looks like your Java bindings should build fine on Java 11
> since this change:
> 
> https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75

You're right - I checked just now using:

java-11-openjdk-headless-11.0.11.0.9-4.fc35.x86_64
javapackages-filesystem-6.0.0-1.fc35.noarch
javapackages-tools-6.0.0-1.fc35.noarch

Tests pass too.

The bug above is a bit worrying though.  I don't think anyone ever
tried to address those issues.  I don't know enough to say if they're
real or nice to haves, but they seem serious.

BTW another project that would be fun for Java bindings (none exist
presently) is nbdkit https://gitlab.com/nbdkit/nbdkit

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-35-20210927.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-35-20210926.0):

ID: 1003808 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1003808

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-35-20210926.0):

ID: 1003793 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1003793

Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Florian Weimer]

* Fabio Valentini:

> On Mon, Sep 27, 2021 at 1:07 PM Richard W.M. Jones  wrote:
>>
>> A question about this which is semi-related to your email.
>>
>> For some C library packages we have Java bindings, eg:
>> https://github.com/libguestfs/libguestfs/tree/master/java
>>
>> These have been disabled in Fedora for ~2 years, but when they were
>> around they had these BuildRequires:
>>
>>   BuildRequires: java-1.8.0-openjdk
>>   BuildRequires: java-1.8.0-openjdk-devel
>>   BuildRequires: jpackage-utils
>>
>> I believe the only requirements are javac, javah, javadoc (optional)
>> and a JVM to run the tests on.
>>
>> Is it possible to keep this going, or would that require a lot of
>> work?  I notice that javah no longer seems to exist.
>>
>> (Note I know almost nothing about how the modern JDK works)
>
> I think you'd probably want to do
>
> 1) switch to java-11-openjdk (it's the default on all currently
> supported Fedora branches)

This means that the built JAR files will be unusable with OpenJDK 8,
though.  Maybe there are still some users left?

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

Re: Fedora  Java: The Death of Two SIGs

[Felix Schwarz]

Am 27.09.21 um 15:09 schrieb Mario Torre:

However the majority of people just usually download Eclipse (or IntelliJ for
what matters) from the upstream website anyway, further suggesting that
maintaining Eclipse is not really a rewarding nor useful task.


Just my 2 ¢: Since I switched from upstream Eclipse tarballs to Fedora's Eclipse 
packages my developer experience improved so much. Previously I had to make 
Eclipse cleaning up its temporary files quite often. With Fedora's Eclipse 
mostly just worked fine.


So a big thanks to the previous Java/Eclipse maintainers from me. I really 
appreciate the effort.


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

Re: Fedora  Java: The Death of Two SIGs

[Florian Weimer]

* Christopher:

> My main point here was that treating the community as a single SIG
> makes no more sense than treating all packages whose software is
> written in C as a single "C SIG" community. It's too overwhelming for
> people to be able to know how to step in and help.

I'm not sure this is actually true.  Debian has Python and Perl
packaging teams which are quite successful, and the Java packaging may
also be in better shape there.

I think the difference to C is that these languages come with their own
packaging/build systems, so creating a distribution package needs a
certain number of kludges, but once you've figured those out, you can
maintain a large number of packages.  I thought that Java used to be
like this, too, thanks to ant and later Maven, but maybe this has
changed with Gradle, SBT, and whatnot.

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

Re: Fedora ? Java: The Death of Two SIGs

[Kevin Kofler via devel]

Richard W.M. Jones wrote:
> The bug above is a bit worrying though.  I don't think anyone ever
> tried to address those issues.  I don't know enough to say if they're
> real or nice to haves, but they seem serious.

I have never seen any handwritten JNI code doing any of the things the bug 
wants you to do. Maybe some binding generators do, but handwritten JNI code 
practically never bothers.

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

Re: Fedora  Java: The Death of Two SIGs

[Kevin Kofler via devel]

Robert Marcano via devel wrote:
> I think the only way the Java ecosystem to survive in Fedora outside of
> OpenJDK and some core components is to allow bundling (Even JavaScript
> bundling is already allowed), but how do to it without compromising
> security?

The problem is that Java projects typically bundle prebuilt binaries, which 
is a complete no go. The big issue is not that the libraries are bundled, it 
is that they are bundled in prebuilt binary form, often even without the 
source code at all.

Fixing this requires work no matter whether the packager works the way you 
propose or whether they simply unbundle the dependencies. So I do not see 
any valid reason to not just go ahead and unbundle. (At least for the 
typical application. Things like Eclipse plugins, using nested JARs, are the 
exception and might indeed need special treatment.)

The Go and Rust case is different because the library packages are shipped 
as source code and the application packages then BuildRequire that source 
code. Doing the same for Java would require modifying the upstream build 
systems even more than just depending on a Fedora-built JAR would (because 
the Go/Rust way is not how Java normally works). So I do not see any 
advantage in doing things that way. (And for the record, I also think that 
Go and Rust should not work that way either! It is possible to build shared 
libraries of Go code, at least one Go toolchain supports it.)

The JavaScript case is also different because everything that is bundled is 
bundled as source code. JavaScript does not have anything like a compiled 
JAR file.

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

Fedora-Rawhide-20210927.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
3 of 43 required test results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud

Failed openQA tests: 10/206 (x86_64), 9/141 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210926.n.0):

ID: 1003905 Test: x86_64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1003905
ID: 1003907 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1003907
ID: 1003982 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1003982
ID: 1003993 Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1003993
ID: 1003998 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1003998
ID: 1004000 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1004000
ID: 1004102 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1004102
ID: 1004104 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1004104
ID: 1004204 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1004204

Old failures (same test failed in Fedora-Rawhide-20210926.n.0):

ID: 1003987 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1003987
ID: 1003995 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1003995
ID: 1004043 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1004043
ID: 1004086 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1004086
ID: 1004109 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1004109
ID: 1004142 Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/1004142
ID: 1004209 Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1004209
ID: 1004240 Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/1004240
ID: 1004252 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1004252
ID: 1004253 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1004253

Soft failed openQA tests: 4/141 (aarch64), 4/206 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20210926.n.0):

ID: 1004089 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1004089
ID: 1004108 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1004108

Old soft failures (same test soft failed in Fedora-Rawhide-20210926.n.0):

ID: 1003969 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1003969
ID: 1004011 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1004011
ID: 1004012 Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/1004012
ID: 1004023 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1004023
ID: 1004032 Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1004032
ID: 1004116 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1004116

Passed openQA tests: 192/206 (x86_64), 128/141 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20210926.n.0):

ID: 1003904 Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1003904
ID: 1003913 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/1003913
ID: 1003920 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/1003920
ID: 1003937 Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/1003937
ID: 1004029 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/1004029
ID: 1004090 Test: aarch64 Server-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1004090
ID: 1004091 Test: aarch64 

Fedora rawhide compose report: 20210927.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210926.n.0
NEW: Fedora-Rawhide-20210927.n.1

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   189
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   10.64 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   243.58 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20210927.n.1.aarch64.raw.xz

= DROPPED IMAGES =
Image: KDE raw-xz aarch64
Path: Spins/aarch64/images/Fedora-KDE-Rawhide-20210926.n.0.aarch64.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  0ad-0.0.25b-2.fc36
Old package:  0ad-0.0.24b-3.fc35
Summary:  Cross-Platform RTS Game of Ancient Warfare
RPMs: 0ad
Size: 32.97 MiB
Size change:  449.78 KiB
Changelog:
  * Mon Jul 05 2021 Richard Shaw  - 0.0.24b-4
  - Rebuild for new fmt version.

  * Wed Jul 21 2021 Fedora Release Engineering  - 
0.0.24b-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Fri Aug 06 2021 Jonathan Wakely  - 0.0.24b-6
  - Rebuilt for Boost 1.76

  * Sun Aug 08 2021 Kalev Lember  - 0.0.25-1
  - Update to 0.0.25

  * Mon Sep 06 2021 Kalev Lember  - 0.0.25b-1
  - Update to 0.0.25b

  * Mon Sep 27 2021 Bruno Wolff III  - 0.0.25b-2
  - Fix for building bundled spidermonkey with python3.10


Package:  Lmod-8.5.16-1.fc36
Old package:  Lmod-8.5.14-2.fc36
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.10 MiB
Size change:  5.11 KiB
Changelog:
  * Mon Sep 27 2021 Orion Poplawski  - 8.5.16-1
  - Update to 8.5.16


Package:  SDL2-2.0.16-3.fc36
Old package:  SDL2-2.0.16-2.fc36
Summary:  Cross-platform multimedia library
RPMs: SDL2 SDL2-devel SDL2-static
Size: 8.95 MiB
Size change:  3.81 KiB
Changelog:
  * Sun Sep 26 2021 Neal Gompa  - 2.0.16-3
  - Backport select fixes from upstream
+ Support legacy 'pulse' alias for PulseAudio driver
+ Fix handling of Ctrl key on Wayland
+ Add support for HiDPI cursors on Wayland
+ Fix keymap support on Wayland (rhbz#2007969)
+ Use EGL_EXT_present_opaque when available on Wayland
+ Expose xdg_toplevel to SysWM on Wayland


Package:  apache-cloudstack-cloudmonkey-6.2.0-1.fc36
Old package:  apache-cloudstack-cloudmonkey-6.1.0-3.fc35
Summary:  Apache Cloudstack Cloudmonkey
RPMs: apache-cloudstack-cloudmonkey 
golang-github-apache-cloudstack-cloudmonkey-devel
Size: 10.29 MiB
Size change:  -912 B
Changelog:
  * Sat Sep 25 2021 Olivier Lemasle  - 6.2.0-1
  - Update to upstream 6.2.0 (fixes rhbz#2007649)


Package:  apostrophe-2.5-2.fc36
Old package:  apostrophe-2.5-1.fc36
Summary:  Distraction free Markdown editor for GNU/Linux made with GTK+
RPMs: apostrophe
Size: 2.49 MiB
Size change:  73 B
Changelog:
  * Mon Sep 27 2021 Artem Polishchuk  - 2.5-2
  - fix(add dep): python3-chardet | rh#2008184


Package:  arbor-0.5.2-4.fc36
Old package:  arbor-0.3-9.fc35
Summary:  Multi-compartment neural network simulation library
RPMs: arbor arbor-devel arbor-doc arbor-mpich arbor-mpich-devel 
arbor-openmpi arbor-openmpi-devel
Size: 402.16 MiB
Size change:  183.60 MiB
Changelog:
  * Fri Jun 04 2021 Python Maint  0.3-11
  - Rebuilt for Python 3.10

  * Wed Jul 21 2021 Fedora Release Engineering  0.3-12
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Wed Jul 21 2021 Fedora Release Engineering  0.3-13
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-1
  - feat: update to 0.5.2

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-2
  - chore: remove unused patch

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-3
  - feat: correct flags for s390 builds

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-4
  - chore: remove second unneeded patch


Package:  bluedevil-5.22.90-2.fc36
Old package:  bluedevil-5.22.5-1.fc36
Summary:  Bluetooth stack for KDE
RPMs: bluedevil
Size: 2.05 MiB
Size change:  38.98 KiB
Changelog:
  * Fri Sep 17 2021 Marc Deop  - 5.22.90-1
  - 5.22.90

  * Sat Sep 18 2021 Marc Deop  - 5.22.90-2
  - Adjust files section


Package:  breeze-gtk-5.22.90-1.fc36
Old package:  breeze-gtk-5.22.5-1.fc36
Summary:  Breeze widget theme for GTK
RPMs: breeze-gtk breeze-gtk-common breeze-gtk-gtk2 breeze-gtk-gtk3 
breeze-gtk-gtk4
Size: 382.67 KiB
Size change:  307 B
Changelog:
  * Fri Sep 17 2021 Marc Deop  - 5.22.90-1
  - 5.22.90


Package:  cairomm-1.14.2-17.fc36
Old package:  cairomm-1.14.2-12.fc35
Summary:  C++ API for the cairo graphics library
RPMs: cairomm cairomm-devel cairomm-doc
Size: 1.66 MiB
Size

[Bug 2008137] New: perl-DBIx-Connector-0.57 is available

[bugzilla]

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

Bug ID: 2008137
   Summary: perl-DBIx-Connector-0.57 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBIx-Connector
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.57
Current version/release in rawhide: 0.56-17.fc35
URL: http://search.cpan.org/dist/DBIx-Connector/

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://fedoraproject.org/wiki/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/6691/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008137
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2008137] perl-DBIx-Connector-0.57 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/authors/id/D/DW/DWHEELER/DBIx-Connector-0.57.tar.gz
to ./DBIx-Connector-0.57.tar.gz


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008137
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-gevent and pytest-cov in el9

[Ken Dreyer]

On Sun, Sep 26, 2021 at 2:25 PM Miro Hrončok  wrote:
>
> On 24. 09. 21 21:45, Ken Dreyer wrote:
> > This means that python-pytest-cov and python-pytest-xdist won't be
> > available on epel9, since those require gevent.
>
> Ignoring the rest of your email for now, but I don't the gevent dependency 
> does
> not exsist:

You're right, gevent is not a runtime requirement. pytest-xdist
requires execnet, but execnet only BuildRequires gevent for the unit
tests. So we could build execnet on el9 if we disabled %check and the
"execmodel=gevent" feature. Maybe that's fine, since
https://github.com/pytest-dev/execnet is almost unmaintained upstream,
and users have opened unaddressed GitHub tickets in execnet and xdist
regarding gevent hangs.

This is another reason why I want to reduce Fedora's dependence on
pytest-xdist and pytest-cov, if execnet is growing more unstable.

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

[Bug 1543336] please provide missing Fedora 27 Perl modules

[bugzilla]

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

Denis Fateyev  changed:

   What|Removed |Added

  Flags||needinfo?(cpanc...@gmail.co
   ||m)



--- Comment #25 from Denis Fateyev  ---
Should be this bug finally closed?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1543336
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2008137] perl-DBIx-Connector-0.57 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-936e9343a8 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-936e9343a8


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008137
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure