Re: RFC7919 Diffie-Hellman parameters in Fedora

[Alex Scheel]

- Original Message -
> From: "Simo Sorce" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, August 24, 2020 2:06:19 PM
> Subject: Re: RFC7919 Diffie-Hellman parameters in Fedora
> 
> On Mon, 2020-08-24 at 19:29 +0200, Christopher Engelhard wrote:
> > On 24.08.20 18:43, Simo Sorce wrote:
> > > On Fri, 2020-08-21 at 16:13 +0200, Christopher Engelhard wrote:
> > > We already are making it easier in some ways, but feel free to open a
> > > bug if there are specific components you are worried about.
> > 
> > What ways are that?
> 
> Some of the crypto libraries use only named DH moduli in FIPS mode
> (more relevant for RHEL) for example, regardless of configuration.
> So we have already some experience with this problem, but we haven't
> pursued this to force everything to just use the RFC parameters.
> 
> > I'm not worried about any specific component, I'm just looking for
> > opinions wrt Fedora defaulting to these parameters generally, where
> > possible.
> > 
> > (I was thinking along the lines of a package containing those parameters
> > & letting other packages link to those files instead of of asking the
> > user to get/create the files themselves - so dovecot, instead of having
> > /etc/dovecot/dh.pem in it's default conf files, could Require: that
> > package and have /etc/pki/dhparam/something.pem or whatever.)
> 
> This has been proposed (somewhere, I forgot where) before, and it is a
> definite possibility.
> Unclear what package would distribute them, potentially the crypto-
> policies package.

I at least mentioned this in a conversation with you IRC or perhaps email.

As a maintainer, this would've made the late FIPS changes much more
palatable. 

I've opened the following BZ for this:

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


- Alex

> 
> Simo.
> 
> > Christopher
> > 
> > > Simo.
> > > 
> > > > For a long time, the general recommendation for Finite-Field
> > > > Diffie-Hellman Ephemeral Parameters (FFDHE, for use with
> > > > non-elliptic-curve DH, i.e. the dhparam-file many server configs ask us
> > > > to specify) used in TLS was to generate your own. However, RFC7919
> > > > specifies fixed, auditable parameters with lengths of 2048-8102 bits
> > > > [1], Mozilla has switched their recommendation from 'generate your own'
> > > > to 'use ffdhe2048' [2] and IIRC TLSv3 mandates their use.
> > > > 
> > > > Main advantage in using them is a) since they're fixed & well-defined,
> > > > they can be and are audited, b) clients don't have to check whether
> > > > parameters they're given by a server are legit or meddled with
> > > > (something that usually any client program would have to but few
> > > > actually do).
> > > > 
> > > > So, questions:
> > > > 1) do we already ship these groups somewhere, e.g. via a package that I
> > > > don't know about? If not, should we maybe add one?
> > > > 2) Many programs either ship their own dhparam files (on my systems at
> > > > least proftpd, certbot & openssh, via the moduli file) or expect the
> > > > user to point them to one (like webservers, dovecot, postfix etc.) +
> > > > some for sure hardcode some defaults if the user does not specify
> > > > parameters. Would it make sense to change their defaults - if possible
> > > > -
> > > > to use (one of the) RFC7919 groups? One could even integrate this with
> > > > crypto-policies, if at some point one wants to e.g. change the desired
> > > > group size.
> > > > 
> > > > Best,
> > > > Christopher
> > > > 
> > > > [1] https://tools.ietf.org/html/rfc7919
> > > > [2] https://wiki.mozilla.org/index.php?title=Security/Server_Side_TLS
> > > > ___
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > > Fedora Code of Conduct:
> > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 

Re: Respinning rawhide images every filesystem update?

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, August 6, 2020 10:55:51 AM
> Subject: Re: Respinning rawhide images every filesystem update?
> 
> On Thu, 6 Aug 2020 at 10:05, Alex Scheel  wrote:
> >
> > - Original Message -
> > > From: "Stephen John Smoogen" 
> > > To: "Development discussions related to Fedora"
> > > , asch...@redhat.com
> > > Sent: Thursday, August 6, 2020 9:55:17 AM
> > > Subject: Re: Respinning rawhide images every filesystem update?
> > >
> > > On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
> > > >
> > > > I'm bumping this thread. This is still broken.
> > > >
> > >
> > > Please open a ticket at
> > > https://pagure.io/fedora-infrastructure/new_issue and open new issue
> > > with an explanation of what is broken and where you are pulling from.
> > > If it is a fedora registry then infrastructure can work on a fix. If
> > > it is from docker.io or quay or elsewhere we can try to find the
> > > people who fix it and let them know.
> >
> > Opened:
> >
> > https://pagure.io/fedora-infrastructure/issue/9208
> >
> > This was also posted to devel to hopefully get the attention of the
> > filesystem maintainer.
> >
> >
> > They seem to have ignored 1548403 since 2018. :-)
> >
> >
> 
> OK so this ticket clarifies the problem because I thought this was a
> problem with the filesystem in the container image with how it is spun
> or delivered. It is instead with the package filesystem. Here is the
> ticket contents (since most people don't follow links in emails).

There's three ways to solve this:

 1) Make the filesystem upgrade nicely in a container, or
 2) Have the container runtime/user namespace system/... support the
type of change that upgrading the filesystem package makes, or
 3) Just respin the container image quickly whenever this happens; this
hides the problem from users without solving the problem.

1 isn't happening because the maintainer isn't involved.
2 isn't happening because the container runtime maintainers punted on it.
3 is the easiest left to accomplish.


If I had a choice, I'd be really happy with 3. I don't know what
all is involved to respin container images with a new package. I'm 
sure it takes time, but I'd imagine it'd be mostly automated. The
problem gets fixed eventually anyways.

- Alex

(Arguably there is 4, quit rebuilding the filesystem package needlessly,
 but we seem to like mass-rebuilds of all packages, and it might set a
 weird precedence if we special case things). 

> filesystem package breaks Fedora containers because dnf cannot
> successfully update the package. See:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> 
> Every time filesystem updates, it causes this problem. The solution is
> to rebuild Fedora containers with the new filesystem package upgrade,
> so dnf upgrade will already have the updated filesystem package.
> 
> Alternatively, the filesystem maintainer could make their package
> container friendly.
> 
> This is from the main Fedora registry:
> 
> [ascheel@ascheel-p50 ~]$ podman run -ti
> registry.fedoraproject.org/fedora:rawhide /bin/bash
> [root@5808bc88f6ab /]# dnf update --refresh -y
> Fedora 33 openh264 (From Cisco) - x86_64  6.9 kB/s | 5.1 kB 00:00
> Fedora - Modular Rawhide - Developmental pack 2.6 MB/s | 3.1 MB 00:01
> Fedora - Rawhide - Developmental packages for  17 MB/s |  73 MB 00:04
> Dependencies resolved.
> ==
>  Package Arch   Version Repo Size
> ==
> Upgrading:
> 
> 
> 
>  filesystem  x86_64 3.14-3.fc33 rawhide 1.1 M
> 
> 
> 
>   Upgrading: filesystem-3.14-3.fc33.x86_64  3/341
> Error unpacking rpm package filesystem-3.14-3.fc33.x86_64
> 
> 
> 
> Failed:
>   filesystem-3.14-2.fc32.x86_64 filesystem-3.14-3.fc33.x86_64
> 
> Error: Transaction failed
> 
> 
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guide

Re: Respinning rawhide images every filesystem update?

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> , asch...@redhat.com
> Sent: Thursday, August 6, 2020 9:55:17 AM
> Subject: Re: Respinning rawhide images every filesystem update?
> 
> On Thu, 6 Aug 2020 at 09:36, Alex Scheel  wrote:
> >
> > I'm bumping this thread. This is still broken.
> >
> 
> Please open a ticket at
> https://pagure.io/fedora-infrastructure/new_issue and open new issue
> with an explanation of what is broken and where you are pulling from.
> If it is a fedora registry then infrastructure can work on a fix. If
> it is from docker.io or quay or elsewhere we can try to find the
> people who fix it and let them know.

Opened:

https://pagure.io/fedora-infrastructure/issue/9208

This was also posted to devel to hopefully get the attention of the
filesystem maintainer.


They seem to have ignored 1548403 since 2018. :-)


- Alex

> 
> Without that information, it is very likely it will stay broken unless
> fixed by accident because no one knows what is meant by 'still broken'
> 
> > - Original Message -
> > > From: "Alex Scheel" 
> > > To: "Development discussions related to Fedora"
> > > 
> > > Sent: Monday, August 3, 2020 2:36:40 PM
> > > Subject: Respinning rawhide images every filesystem update?
> > >
> > > Hey list,
> > >
> > >
> > > How do Fedora rawhide images get respun? Every time filesystem updates,
> > > it causes `dnf update` to fail in a podman container because filesystem
> > > can't be updated in a container. We either need to make sure filesystem
> > > updates  cause rawhide containers to be rebuilt, or figure out how to
> > > ship a container-friendly filesystem package.
> > >
> > >
> > > See:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> > >
> > >
> > > And I'm sure many other discussions.
> > >
> > > - Alex
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> 
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Respinning rawhide images every filesystem update?

[Alex Scheel]

I'm bumping this thread. This is still broken.

- Original Message -
> From: "Alex Scheel" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, August 3, 2020 2:36:40 PM
> Subject: Respinning rawhide images every filesystem update?
> 
> Hey list,
> 
> 
> How do Fedora rawhide images get respun? Every time filesystem updates,
> it causes `dnf update` to fail in a podman container because filesystem
> can't be updated in a container. We either need to make sure filesystem
> updates  cause rawhide containers to be rebuilt, or figure out how to
> ship a container-friendly filesystem package.
> 
> 
> See:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> https://bugzilla.redhat.com/show_bug.cgi?id=1708249
> 
> 
> And I'm sure many other discussions.
> 
> - Alex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Respinning rawhide images every filesystem update?

[Alex Scheel]

Hey list,


How do Fedora rawhide images get respun? Every time filesystem updates,
it causes `dnf update` to fail in a podman container because filesystem
can't be updated in a container. We either need to make sure filesystem
updates  cause rawhide containers to be rebuilt, or figure out how to
ship a container-friendly filesystem package.


See:

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


And I'm sure many other discussions.

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

Re: [pam_radius] aarch64 GCC failures during ./configure's working compiler step?

[Alex Scheel]

- Original Message -
> From: "Dan Čermák" 
> To: "Alex Scheel" , "Development discussions related to 
> Fedora" 
> Sent: Monday, July 27, 2020 8:25:27 AM
> Subject: Re: [pam_radius] aarch64 GCC failures during ./configure's working 
> compiler step?
> 
> Hi Alex,
> 
> 
> This is most likely due to annobin being broken in rawhide on aarch64
> (see Neal's email to devel from Saturday).

Ah, thanks Dan and Peter! I must've missed it for another thread. I'll
be patient. :D

- A

> 
> 
> Cheers,
> 
> Dan
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[pam_radius] aarch64 GCC failures during ./configure's working compiler step?

[Alex Scheel]

Not to pile on to what seems like a common topic... :-)

Koschei notified me that one of my co-owned packages, pam_radius failed
to build on aarch64 with the recent gcc update (10.1.1 -> 10.2.1). ppc and
x86 built just fine.

Looking at the build log, I'm almost inclined to kick off a new build
on aarch64 to see if it is still there, or just issued at the wrong
time:

https://kojipkgs.fedoraproject.org/work/tasks/8159/47858159/build.log

> + ./configure --build=aarch64-redhat-linux-gnu 
> --host=aarch64-redhat-linux-gnu --program-prefix= 
> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr 
> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
> --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec 
> --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man 
> --infodir=/usr/share/info --enable-werror
> configure: WARNING: unrecognized options: --disable-dependency-tracking
> checking build system type... aarch64-redhat-linux-gnu
> checking host system type... aarch64-redhat-linux-gnu
> checking target system type... aarch64-redhat-linux-gnu
> checking for aarch64-redhat-linux-gnu-gcc... gcc
> checking whether the C compiler works... no
> configure: error: in `/builddir/build/BUILD/pam_radius-1.4.0':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> error: Bad exit status from /var/tmp/rpm-tmp.McMZL0 (%build)
> Bad exit status from /var/tmp/rpm-tmp.McMZL0 (%build)
> RPM build errors:
> Child return code was: 1

The spec file was well before my time but seems fairly straight
forward:

https://src.fedoraproject.org/rpms/pam_radius/blob/master/f/pam_radius.spec#_43


The configure script is admittedly from 7 years ago, perhaps I should
just nuke it and rebuild it from configure.ac with a newer version of
autotools?

https://github.com/FreeRADIUS/pam_radius/blob/release_1_4_0/configure


Any thoughts? Should I try and grab the config.log from a scratch build? 


Thanks!

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

Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

[Alex Scheel]

Just to revisit this, my issue turned out to be a bug in a p11-kit
component, opencryptoki, that failed to lock, causing its
deinitialization routine to trample some stuff. That's been fixed
now. Sorry for blaming glibc, Florian! :)


- Alex

- Original Message -
> From: "Vít Ondruch" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, July 2, 2020 4:35:27 AM
> Subject: Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?
> 
> I just met something which might be of similar nature. Recent FF
> 78.0-1.fc33.x86_64 fails to start with older glibc:
> 
> 
> ~~~
> 
> $ firefox
> XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
> /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
> version GLIBC_2.32
> Couldn't load XPCOM.
> 
> ~~~
> 
> 
> Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to
> glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless
> issues like this are unexpected. There should be something, what would
> force glibc update if FF requires more recent one.
> 
> 
> Vít
> 
> 
> Dne 01. 07. 20 v 6:57 Florian Weimer napsal(a):
> > * Alex Scheel:
> >
> >> Is Fedora Rawhide unstable at the moment, pending a mass rebuild?
> >>
> >> I've seen a lot of random problems related to pthreads at the
> >> moment, such as:
> >>
> >> 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child
> >> aborted***Exception:   0.99 sec
> >> FINE: CryptoManager: loading JSS library
> >> FINE: CryptoManager: loaded JSS library from java.library.path
> >> java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion
> >> `mutex->__data.__owner == 0' failed.
> >>
> >>
> >> Another, different stack trace here (pthreads fails to lock,
> >> triggering a bug in opencryptoki):
> >>
> >> https://pagure.io/dogtagpki/issue/3181#comment-661911
> > I don't see why this would be fixed by a mass rebuild.
> >
> > This is probably some sort of memory corruption: something has
> > overwritten the mutex data structure, and glibc happens to detect that.
> >
> > 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, July 1, 2020 9:21:31 AM
> Subject: Re: [fedora-java] Re: java stack is dead, long live the javastack 
> (was "500 packages FTBFS in rawhide with
> java-11-openjdk as system JDK")
> 
> On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov 
> wrote:
> >
> > Fabio, does it mean that the Java SIG agrees with progressing with the
> > Change to Java 11 as a default?
> 
> Speaking for myself, yes.
> 
> I can't speak for all other SIG members (we haven't formally voted on
> this or something like that), but from conversations we've had I
> gather that all active package maintainers are looking forward to
> finally getting Java 11 by default.

Speaking on behalf of the Dogtag team, we too are fine with Java 11 change.

(Technically we're the next most active members of the Stewardship SIG,
 and I guess we're part of Java Maint SIG but we've not yet contributed
 in that capacity).

We're mostly there, but still need upstream CI in place to prevent
regressions and ensure we fix problems before they get started.

Plus, Debian has already made this change so we're going to need this
eventually. RHEL will get there too.


My personal preference is to get the Stewardship SIG's top-level packages
building (iirc, Eclipse, Dogtag, and Libreoffice) on Java 11 and then we'll
let the rest drop. IIRC most of the 200 packages not building in our COPR
aren't pulled in by Dogtag so we're mostly fine once we fix our top-level
Dogtag package.



- Alex



> 
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

rawhide - glibc/pthreads/... - broken pending mass rebuild?

[Alex Scheel]

Is Fedora Rawhide unstable at the moment, pending a mass rebuild?

I've seen a lot of random problems related to pthreads at the
moment, such as:

16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child 
aborted***Exception:   0.99 sec
FINE: CryptoManager: loading JSS library
FINE: CryptoManager: loaded JSS library from java.library.path
java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion 
`mutex->__data.__owner == 0' failed.


Another, different stack trace here (pthreads fails to lock,
triggering a bug in opencryptoki):

https://pagure.io/dogtagpki/issue/3181#comment-661911


And others. They don't reproduce consistently though.

Should I go ahead and file a bug or just wait and be patient? :)



This is blocking some rebuilds on rawhide at the moment for us.

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

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Alex Scheel]

- Original Message -
> From: "James Cassell" 
> To: "Fedora Development List" 
> Sent: Tuesday, June 30, 2020 6:08:30 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default 
> file system for desktop variants
> 
> On Tue, Jun 30, 2020, at 10:18 AM, Steven Whitehouse wrote:
> > I know it has been rather confined to Red Hat internally, however that
> > was not the intention, and in fact I would like to strongly encourage
> > community involvement. There is an upstream mailing list, which
> > currently has almost no traffic: springfi...@sourceware.org so please
> > do join and ask questions, if anybody is interested in finding out more.
> > 
> 
> Indeed, this is the first I've heard of "Project Springfield" -- it looks
> like the list only had a couple of messages at its start in 2018 and nothing
> since.
> 
> https://springfield-project.github.io/
> 
> The "subscribe" link is broken... it should probably point to
> https://sourceware.org/mailman/listinfo/springfield
> 
> I'd send a pull request, but I couldn't find the github repo associated with
> the page.

https://github.com/springfield-project/springfield-project.github.io/blob/master/index.md#so-youd-like-to-contribute


https://.github.io/ -- you'll almost always find it at
https://github.com//github.io, unless it is a
repo-specific GH pages.

Then it'd be:

https://.github.io// -- which you'll find somewhere
in the https://github.com// repo (either docs/
folder in the default branch or gh-pages branch). 


https://help.github.com/en/github/working-with-github-pages/about-github-pages

- Alex

> 
> 
> V/r,
> James Cassell
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RHEL 9 and modularity

[Alex Scheel]

- Original Message -
> From: "Daniel P. Berrangé" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, June 19, 2020 5:58:28 AM
> Subject: Re: RHEL 9 and modularity
> 
> On Fri, Jun 19, 2020 at 11:28:58AM +0200, Vít Ondruch wrote:
> > 
> > Dne 18. 06. 20 v 21:40 Stephen Gallagher napsal(a):
> > > On Thu, Jun 18, 2020 at 3:34 PM John M. Harris Jr 
> > > wrote:
> > >> The issues I've seen so far affect both Fedora and RHEL, but have gotten
> > >> a bit
> > >> better in Fedora. For example, a major concern that has been much worse
> > >> in
> > >> Fedora than RHEL, for obvious reasons:
> > >>
> > >> One month you can do a fresh install, install a package that, as it
> > >> turns out,
> > >> is a module for some reason.
> > >>
> > >> Then you install a fresh system the next month, install the same
> > >> package.
> > >> Perform a dnf update on the previous system, and you'll find that you
> > >> have a
> > >> different version of the package installed, because you're tracking a
> > >> different version of a default stream.
> > >>
> > > Can you give an example of where you've seen this? Because our
> > > policies in Fedora forbid changing a default stream in a released
> > > Fedora. There were a couple exceptions around Java/Maven and libgit2
> > > in the past due to their default streams being broken
> > 
> > 
> > Sorry, but I don't remember this as "their default streams being
> > broken". AFAIR, there were multiple applications trying to use different
> > version of libgit2 at the same time which is not possible. That is
> > problem of modules design, not problem of the specific default stream as
> > you put it.
> 
> That clashing libraries problem is the fatal design flaw in modularity
> as it exists today.
> 
> We've made it possible for each module to ship arbitrarily different
> versions of the same libraries, while all wanting to install into
> the same directory prefix. Thus two separately maintained modules can
> easily become mutually exclusive, which is a big pain for users who
> need to use both concurrently. This is essentially the "DLL Hell"
> problem.
> 
> The single shared /usr hierarchy only works (in the general case) when
> you have a single stream where everyone agrees on using the same version
> of each package.
> 
> I can only see this being solvable if non-default modules streams are
> required to be built into a unique /opt prefix instead of /usr.

Or better, if all the work that has gone into maintaining separately
packaged libraries went into maintaining one version and fixing
associated dependent packages as necessary... Especially for Java and
libgit2.

> 
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange
> |:|
> |: https://libvirt.org -o-https://fstop138.berrange.com
> |:|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange
> |:|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

glassfish-hk2 - orphaning event notification

[Alex Scheel]

After much trimming, pruning, and hair-pulling by our fearless leader,
glassfish-hk2 was determined to be a spurious dependency which Fabio
replaced with one line of `sed` magic.

Please see: https://pagure.io/stewardship-sig/issue/91

If anyone is interested in taking this package back for whatever reason,
feel free to adopt it and claim ownership. However, the Stewardship SIG
no longer has use for this package and thus orphaned it.


Thanks,

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

Re: Re-Launching the Java SIG

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 9:44:33 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 3:34 PM Alex Scheel  wrote:
> >
> > Obviously count us in, Fabio :-)
> 
> *Us* means the three guys from the Dogtag PKI team? :)

Yeah, but mostly expect Dinesh and I :)

> 
> > Do we need a two-step bootstrap process? A first (offline) step where we
> > run
> > gradle-wrapper and fetch all the resources, put all online dependencies
> > into a
> > SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
> > bootstrapped version which works) and then replacing _all_ assets with
> > versions
> > built using the bootstrapped gradle and finally rebuilding gradle?
> >
> > It'd be hell to set up the first time (two .specs?) and hell to make sure
> > we
> > get every package at the right version. But theoretically possible? :-)
> >
> >
> > But it might allow us to skip incremental bootstrap from a really old
> > gradle
> > version and might even get us a process which works for future bootstraps.
> 
> That's an innocent thought :) I'm afraid it won't work though.
> Do you think gradle is downloading source code for its dependencies?
> Nope, it only downloads prebuilt JARs.

Right -- I wasn't suggesting that it'd download source code. Merely that a
binary-JAR-bootstrapped Gradle could be used to (re)-build all of the
libraries it needed (from source this time!) and then re-build itself
(using those source-built libraries and building a new gradle from
source).

The internet-downloaded JARs could be put into lookaside and the SRPM
could pull them, put them in the right location, and finish the initial
Gradle build. Koji would finish the build and the resulting gradle would
be available for us to use.

IIRC the restriction on source code builds of packages can be waived for
bootstrap-only builds. So for initial build of gradle, we're fine using
the binary wrapper as long as we fully replace it with source-only builds.

Someone with a more recent understanding of packaging policy can weigh
in here though.

> 
> So the build script loads a prebuilt gradle-wraper.jar (that's shipped
> with the gradle sources) that then in turn downloads more prebuilt
> JARs from the gradle repository to satisfy gradle's build dependencies
> which are then used to actually build full gradle ...

Right :) So we'd take all of those new downloads and put them into
lookaside and ship a SPRM that finishes the build based off of those
internet-downloaded JARs. This satisifies Koji's no-internet policy
while giving us a (hopefully) useful Gradle build system as output.

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

Re: Re-Launching the Java SIG

[Alex Scheel]

Obviously count us in, Fabio :-)

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 6:39:04 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:
> > Right, I figured it was some Fedora policy and not up to you. I suppose
> > I should have been more clear there. Sorry for any confusion, it was
> > aimed at the Fedora project as a whole as this is a Fedora issue.
> 
> I am aware that Arch is just packaging up the binary release artifacts
> published by the gradle project.
> But that's just never going to fly for fedora.
> 
> Arch is also the only distro I looked at that does this, everybody
> else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
> version, if gradle is available at all.
> 
> > FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
> > code via:
> >
> >
> > ./gradlew allZip
> 
> Now try doing that offline and without using the pre-built
> gradle/wrapper/gradle-wrapper.jar :)
> You'll be surprised how much junk the build process still needs to download.

Do we need a two-step bootstrap process? A first (offline) step where we run
gradle-wrapper and fetch all the resources, put all online dependencies into a
SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
bootstrapped version which works) and then replacing _all_ assets with versions
built using the bootstrapped gradle and finally rebuilding gradle?

It'd be hell to set up the first time (two .specs?) and hell to make sure we
get every package at the right version. But theoretically possible? :-)


But it might allow us to skip incremental bootstrap from a really old gradle
version and might even get us a process which works for future bootstraps.



- Alex

> 
> Fabio
> 
> > >
> > > 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
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Revise FESCo voting policy

[Alex Scheel]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, May 11, 2020 11:52:24 AM
> Subject: Proposal: Revise FESCo voting policy
> 
> During today's FESCo meeting, we encountered an unusual voting
> situation for the first time: Four FESCo members voted in favor (+1)
> of a measure and five FESCo members opted to abstain (0) for various
> reasons. However, the FESCo voting policy currently reads: "A majority
> of the committee (that is, five out of nine) is required to pass a
> proposal in a meeting." As a result, we were actually at an impasse
> until two of the FESCo members opted to change their votes to +1 to
> resolve the confusion.

Obviously FESCo members changing their votes is within their prerogative,
but what if nobody wanted to change their votes? I think the original policy
is correct: if you don't have a majority explicitly voting yes, you don't
have enough support and the resolution shouldn't pass. Abstaining is in two
categories:

 - I abstain because I don't care about this topic,
 - I abstain because I object to this line item, but not strongly enough to
   explicitly vote no, e.g., when the idea is generally correct but I don't
   explicitly back it or disagree with minor items in it.

I don't think a revision should be made, and counting the latter bucket of
votes into the former category isn't correct in the general case.

> It was subsequently suggested that we revise the policy to avoid this
> pitfall in the future. I volunteered to put together a proposal for
> how this could work and send it to the Fedora Development list for
> discussion. I propose the following changes to the FESCo voting
> policy:
> 
> * To pass any measure, a majority — defined as the greater of half the
> eligible votes (rounded up) — must vote in favor of the measure. The
> standard set of eligible votes is one vote per FESCo member. No
> measure may pass without at least one vote in favor.
> 
> * Abstaining from a vote (aka "voting 0") is considered to have
> removed that FESCo member's vote from the set of eligible votes. This
> must be done explicitly and is never to be assumed from lack of
> communication.
> 
> A practical effect of the new abstention rule is that if two FESCo
> members abstain, the measure would then require only a +4 vote to
> pass. (A single abstention would still require a +5 vote).

I'm confused how this holds. There are 9 seats on the council. If one
abstains, there's now an effective seat count of 8. Half of 8 is exactly
4, so wouldn't this mean a +4 vote is sufficient? What happens if the
vote is (+4, 1, -4)? Shouldn't this fail / end in a tie?

One way to implement your examples is to always add 0.5 before rounding:

 9 -> ceil(4.5 + 0.5) -> 5
 8 -> ceil(4 + 0.5) -> 5
 7 -> ceil(3.5 + 0.5) -> 4
 6 -> ceil(3 + 0.5) -> 4
 ...
 2 -> ceil(1 + 0.5) -> 2
 1 -> ceil(0.5 + 0.5) -> 1

> 
> 
> I'd also like to propose an additional policy modification that
> occurred to me while writing this message:
> 
> * A FESCo member may grant their proxy vote to another member of the
> Fedora community if they cannot be in attendance for a vote. If they
> do so, that vote is counted equivalently to any other. Proxy votes
> MUST be limited to predetermined topics and time period. (e.g. I can
> say "bookwar has my proxy vote on any topic directly related to ELN"
> while I am on vacation from MMDD until MMDD, but I cannot give my
> FESCo seat to a person of my choosing.)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Backports of fixes from F32 -> F31?

[Alex Scheel]

Just wanted to follow up and say thanks for this! Much appreciated;
I've given it karma. :)

- Alex

- Original Message -
> From: "Florian Müllner" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Florian Muellner" 
> Sent: Thursday, April 30, 2020 11:54:21 AM
> Subject: Re: Backports of fixes from F32 -> F31?
> 
> 
> 
> Hey,
> 
> On Thu, Apr 30, 2020 at 09:30, Alex Scheel  wrote:
> > 
> > And yeah, agreed. Backports are time consuming. But this is F31, not
> > F30.
> > There's at least another 6 months of support on this distro
> > (technically...)
> > and as referenced on that ticket, I'm not the only one that has hit
> > it;
> > there's about 10 people CC'd or replying saying they're affected.
> > 
> > Plus -- all I'm looking for is a yes/no. Is that too much to ask a
> > maintainer? :-)
> 
> 
> I'm afraid F31 does usually lose out to upstream/rawhide, RHEL 7, RHEL
> 8 and F32, sorry :-(
> 
> But regarding this particular issue, Olivier was kind enough to
> backport his fix upstream and I rolled another old-stable release.
> 
> The update is now available at
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d29c22c817, testing
> and karma are appreciated.
> 
> Regards,
> 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
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 system wide change, java-11-openjdk as system jdk

[Alex Scheel]

Ah cool, so my guess was correct. :-) We're working on fixing this upstream
and then we'll get it pulled into Fedora. Mind if we ping you for a rebuild
when we're ready?


- Alex

- Original Message -
> From: judov...@email.cz
> To: devel@lists.fedoraproject.org
> Sent: Friday, May 1, 2020 2:19:17 PM
> Subject: Re: F33 system wide change, java-11-openjdk as system jdk
> 
> Hi Alex, both your packages
> "BuildRequires:java-1.8.0-openjdk-devel"
> So I could not pull it. According to the packaging guidelines   you should
> require only  "java-devel" (exactly for this case:)). Thus I could not found
> your packages by using build-requires queries. Even If I found, It would be
> useless, because java-1.8.0-openjdk-devel  will still be providing  itself.
> Please adapt your packages to java-devel only.  And when in int, bump them to
> build n that copr of mine.
> I will happily include them to the copr once you fix the BR. Crossing
> fingers! TYVM!
> 
> Jiri (sorry for different email, only github login worked for me today)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 system wide change, java-11-openjdk as system jdk

[Alex Scheel]

\o Hey Jiri,

I don't see two of our packages in the copr:

https://src.fedoraproject.org/rpms/pki-core/
https://src.fedoraproject.org/rpms/dogtag-pki/

Is there a way to know why they were excluded?

Thanks!


- Alex

- Original Message -
> From: "Jiri Vanek" 
> To: "Development discussions related to Fedora" 
> , "Fedora Java Development List"
> 
> Sent: Thursday, April 30, 2020 12:31:43 PM
> Subject: F33 system wide change, java-11-openjdk as system jdk
> 
> 
> 
> Hello fellow java package maintainers!
> 
> We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk
> for F33. Please see
> https://fedoraproject.org/wiki/Changes/Java11
> 
> Short Story:
>  * if you have some java package, be aware that we are bumping JDK in rawhide
>  * Ensure your package builds and runs fine with JDK11 (see the
> https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/)
>  * there is special tooling ready for this, before mass rebuild is launched
>  ** See
>  https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild
>  * If you do not want Fedora rotten with JDK8 for ever, continue reading
> 
> Long Story:
> We ran a preliminary mass rebuild of javastack in copr repo
> https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all"
> instead of "25" at the
> bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy
> & comp for build. You
> can see, the result was quite dramatic:
> 1225  total; attempted to rebuild
> 483   failed; from those 191 are trivial failures (but if you fix it, there
> is no guarantee real
> troubles are not hidden behind that)
> 186   succeeded
> 556   orphans or dead or otherwise tragic so the build did not even start
> 
> I would kindly ask you to search yourself in this list:
> https://jvanek.fedorapeople.org/java11/people
> If you are here, please check status of your package in
> https://jvanek.fedorapeople.org/java11/init
> (pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds).
>  * If your package is "succeeded",  congratulations nothing to do, and just
>  keep en eye on JDK bump
>  * If there is "failed" but contains "-   -" then it is probably orphan. 
> If
>  you wish to resurrect it,
> please ensure it runs against JDK11 (see lower)
>  * If there is "failed" but failed in "seconds", then those packages failed
>  so quickly, that the
> build was in initial phases. That usually mean that you build with
> source/target lower then 1.6
> JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to
> allow existence of
> compact 1.8 packages alongside main javastack. See
> https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version.
> Don't forget to
> upstream the patch, or maybe it is enough to update to more fresh upstream
> release which supports
> JDK11? it may happen, that after the fix, your build will fail in more
> terrible way (see below)
>  * If there is "failed", and its none of above, then your package simply
>  failed. Very often the
> scary error may be fixed by bump to latest upstream version. JDK 11 is out
> for several years.
> Please, try to fix the package. Don't hesitate to ask on
> de...@fedoraproject.org or
> java-de...@fedoraproject.org or directly to me jva...@redhat.com. If you fix
> the fail, feel free to
> share your fix, it may help others.
> We are trying to gather the most common issues at
> https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions
> .
>  Feel free to enhance the page, or write us your case (possibly both with
>  solution and without) so
> we can add it here.
> 
> Debugging Your failures.
> The copr repo we maintain, contains builds of java-11-openjdk as system JDK,
> javapackages-tools
> honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains
> successfully rebuilt
> packages. You can directly use this copr repo in several ways.
>  * first glance on error. On
>  https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your
> build  (select "all" instead of "25" at the bottom),
>  ** Click its number, select chroot (currently  fedora-32-x86_64 ) and check
>  the logs. Main log is
> build.log.gz.
>  * anything you push to rawhide, will automatically rebuild here in f32
>  chroot (we have a JDK in
> rawhide broken a bit currently)
>  ** It is the best approach. If you can fix your package in rawhide directly,
>  without breaking the
> rawhide too much, go for it
>  ** If yo need to experiment, I have a mock config for you (generated from
>  copr-cli mock-config
> jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use
> -
> https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg .
> Eg:
> 
>  sudo cp downloaded-fedora-32-x86_64.cfg
>  /etc/mock/jvanek-java11-fedora-32-x86_64.cfg
>  # change spec, bump sources, apply patches
>  fedpkg srpm
>  mock -r jvanek-java11-fedora-32-x86_64  *.src.rpm
> 
> Or any 

Re: Backports of fixes from F32 -> F31?

[Alex Scheel]

- Original Message -
> From: "Josh Boyer" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Florian Muellner" 
> Sent: Wednesday, April 29, 2020 9:04:12 PM
> Subject: Re: Backports of fixes from F32 -> F31?

> > > Just a curious observation/question.  Backports can often be time
> > > consuming and expensive.  Is there something preventing you from
> > > upgrading to Fedora 32?
> >
> > I don't know about Alex, but in general, upgrading can also be time
> 
> That's why I was asking Alex :)

Sure :-) 

I have four systems in my house running Fedora. Two I've updated to F32
because I don't care if I lose personal time to messing around with F32
the day of the release. That's how I've been able to confirm it fixes
this bug.

A third is my router-desktop. Rarely used with a display and affects other
people if I slow reboot it for upgrade + relabel. Bug isn't a problem there.

But my work laptop on F31 is where I spend 80% of my time. Its the most...
temperamental of the machines. F31 has been more stable than 29 or 30 before
it. Until I know F32 is stable on the others, I'm not going to update it.
I'll probably wait for the next company holiday or a weekend.

---

And yeah, agreed. Backports are time consuming. But this is F31, not F30.
There's at least another 6 months of support on this distro (technically...)
and as referenced on that ticket, I'm not the only one that has hit it;
there's about 10 people CC'd or replying saying they're affected.

Plus -- all I'm looking for is a yes/no. Is that too much to ask a 
maintainer? :-)


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

Re: Backports of fixes from F32 -> F31?

[Alex Scheel]

Let's try this with the right Florian...


Sorry!

- Original Message -
> From: "Alex Scheel" 
> To: "Florian Weimer" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 29, 2020 4:02:48 PM
> Subject: Backports of fixes from F32 -> F31?
> 
> Hi Florian,
> 
> I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> such as this one against mutter:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1770296
> 
> 
> Could we get some of these fixes backported? I've not heard from you on
> this bug at all, despite a needinfo request since March.
> 
> 
> Thanks,
> 
> - Alex
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Backports of fixes from F32 -> F31?

[Alex Scheel]

Hi Florian,

I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
such as this one against mutter:

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


Could we get some of these fixes backported? I've not heard from you on
this bug at all, despite a needinfo request since March.


Thanks,

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

Re: Modularity Survey

[Alex Scheel]

Hey Daniel, do you mind updating the GDPR compliance tag to include
Google?

Thanks!

- Original Message -
> From: "Adam Williamson" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 8, 2020 1:22:27 PM
> Subject: Re: Modularity Survey
> 
> On Wed, 2020-04-08 at 08:41 -0400, Alex Scheel wrote:
> > 
> > There's a marketing piece from 2017 that alleges that none of gsuite
> > (including their gmail for gsuite!) gets scanned for ads:
> > 
> > https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/
> > 
> > 
> > I think we can agree that--at one point in time (2014-2017)--Google's
> > position was that they aren't scanning gsuite content.
> 
> But that's not what a GDPR declaration is about at all. It doesn't have
> anything to do with what the entity who gets the data claims they are
> or are not doing with it. Only with whether or not they get the data.
> 
> I don't know or care whether Google is automatically scanning the
> content for the purpose of showing advertising or not, really. But
> that's not the question here at all.

I'm going to quit responding sometime as this really has gotten out of
hand, but please look at the context for my original mail in this
subthread.


Please, read the context in which I was responding!

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RGNGPXMXW4E6W4X6DUTLYWI4ZYQS3CHF/
and 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BBA25DUX4HZMYLGEDS7ZDLN2SQX5IYFU/

> > Indeed. Once again, Fedora is depending on third-party, proprietary, 
> > privacy-invading SaaS.
> Meets exactly my thoughts...
> This is yet again another disappointing choice of tool.
> 
> I'm not going to give anything to Google, hence I can _not_ answer the 
> survey.
> Too bad, there is much to be said about modularity, as the lengthy 
> threads have already shown.
> 
> Unfortunately, Fedora is drifting more and more away from the Libre 
> Software philosophy that over time made me a Linux-only user and a 
> Fedora packager. At some point, I will have to put my money where my 
> mouth is and find another ship.
> Yes, I'm bitter...

The replies I was responding to weren't expressly GDPR comments!

They're attacks on people!

IMO, that should've been called out. So I did. I agree, from a GDPR
compliance perspective, someone with access to the survey could add
a disclaimer.

But insinuations that Google is using the data submitted by this form,
on their own, is IMO, wrong. And should be called out. That's why I did.

> > I'll make the assumption that, were this to have changed, a number
> > of large businesses would've been upset and there would've been
> > media reports and potentially legal proceedings. I haven't found
> > any. :-)
> 
> Again I don't know why you're all making assumptions like this? Don't
> you read the news? Google (and Facebook et al) have been "caught" doing
> all sorts of stuff with user data all the time. It does make the news.
> Frequently.

I do read the news.

Google and Facebook have been caught abusing **individual** data. I agree
with you on that. I think it is wrong and they should stop.

But we're not talking about that.

We're talking about an enterprise gsuite account with a contract between
Google and Red Hat. Where are the news articles about Google doing data
mining on other companies data? Perhaps I've missed all the relevant news
articles though. I'd imagine, with all the data companies store in Google
drive, this would've been an easy case.

To not use GMail is one thing. To attack those who created an optional
survey--based on an unproven premise--is IMO, out of line. It isn't being
excellent to others. And to be clear, the two posters I replied to weren't
being excellent; you were ok.


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

Re: Modularity Survey

[Alex Scheel]

(I had several replies to Adam, but I ultimately got stuck finding
 supporting URLs until I revisited it this morning.)

IANAL.

- Original Message -
> From: "Kamil Paral" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 8, 2020 4:25:55 AM
> Subject: Re: Modularity Survey
> 
> On Tue, Apr 7, 2020 at 7:22 PM Adam Williamson 
> wrote:
> 
> > On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote:
> > > I'm sure we can trust that Red Hat did its
> > >
> > > due diligence and Google isn't using responses to a customer's form to
> > >
> > > track those taking the survey.
> >
> > I don't really know why you'd think anyone can trust that. Google
> > tracks everyone everywhere as hard as it can. It's what Google *does*.
> >
> > But I didn't actually suggest it's Terribly Awful to run this survey
> > through Google. I just said the privacy declaration seems to be wrong.
> >
> 
> I personally considered it quite clear that the intended meaning was that
> they are not giving the data away to anyone external deliberately. Your
> responses will be read and understood by a very small group of people and
> not published in raw form. Yes there are servers and software providers
> along the way. But this way you could also include the ISPs who also are
> not prevented from snooping in your packets (and it's trivial at least for
> plain text emails). And even if they provided a "direct" way to send your
> responses to their email, and we ignored the ISPs, still, Google is the
> email provider for most RedHatters. So there's no improvement at all.
> 
> I'm not saying we shouldn't talk about it, but the points mentioned are
> common for most data submissions anywhere. I don't think it was the core of
> the message.

:-) It is tricky trying to pin down what Google does, on the outside,
without any knowledge of what contracts actually got negotiated.

There is an undated white paper which directly discusses it:

https://gsuite.google.com/learn-more/security/security-whitepaper/page-6.html#no-advertising

The only date mentioned there is 2014. 


Coincidentally, the 2014 Google Apps privacy policy also explicitly called
it out:

https://gsuite.google.com/intl/en_us/terms/2014/2/premier_terms_ie.html


I tried looking at the new terms link on gsuite's page:

https://www.google.com/intl/en/policies/terms/

But that just redirects to the generic, Google-wide page:

https://policies.google.com/terms?hl=en

Which is geared more towards consumers than enterprises. Neither "enterprise"
nor "premier" appear. On the list of apps page:

https://policies.google.com/terms/service-specific?hl=en

There's a link here:

https://www.google.com/drive/terms-of-service/?hl=en


You can control who sees ads even, in a gsuite account, so maybe that's
sufficient:

https://support.google.com/a/answer/6304811?hl=en


There's a marketing piece from 2017 that alleges that none of gsuite
(including their gmail for gsuite!) gets scanned for ads:

https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/


I think we can agree that--at one point in time (2014-2017)--Google's
position was that they aren't scanning gsuite content. 

I'll make the assumption that, were this to have changed, a number
of large businesses would've been upset and there would've been
media reports and potentially legal proceedings. I haven't found
any. :-)


My 2c.

- Alex


Not delivered by GMail ;-)

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

Re: Modularity Survey

[Alex Scheel]

- Original Message -
> From: "Xavier Bachelot" 
> To: "Development discussions related to Fedora" 
> , "Kevin Kofler"
> 
> Sent: Tuesday, April 7, 2020 12:15:37 PM
> Subject: Re: Modularity Survey
> 
> Le 07/04/2020 à 12:29, Kevin Kofler a écrit :
> > Adam Williamson wrote:
> >> Well. Uh. Clearly it's being provided to *Google*.
> > 
> > Indeed. Once again, Fedora is depending on third-party, proprietary,
> > privacy-invading SaaS.
> > 
> 
> Meets exactly my thoughts...
> This is yet again another disappointing choice of tool.
> 
> I'm not going to give anything to Google, hence I can _not_ answer the
> survey.
> Too bad, there is much to be said about modularity, as the lengthy
> threads have already shown.
> 
> Unfortunately, Fedora is drifting more and more away from the Libre
> Software philosophy that over time made me a Linux-only user and a
> Fedora packager. At some point, I will have to put my money where my
> mouth is and find another ship.
> Yes, I'm bitter...

(I'm not on the modularity team).

Look folks. This isn't a Fedora-only survey. It is a survey run by Red Hat
members who are looking to engage with a community that includes Fedora,
Red Hat, CentOS and a bunch of other stakeholders as well. I think we can
all recognize that Google Apps usage is high among businesses. 

Yeah, if this were a Fedora-only survey, we all would've hoped they'd go
for an open source tool. But it isn't Fedora-only. And pretending like it
matters for this IMO, isn't a legitimate complaint. This is a business
backed Google Apps account. I'm sure we can trust that Red Hat did its
due diligence and Google isn't using responses to a customer's form to
track those taking the survey. But by definition, they need to hold a copy
of that data. Someone, somewhere would. That's how the internet works.  


I sit on the new Modularity meetings now. I'll be the first to admit I'm not
a strong supporter of Modularity. I've been very vocal against it in the
past. But I do think that this new team is honestly trying to do the right
thing and engage with the community. They aren't trying to push features 
top-down and they're trying to understand what is wrong and are trying
their best to fix it.

Part of that is collecting data and stories from people.

If we, as a community, push them away now, we'll never see any much-needed
improvements to modularity. And tbh, I'm not even sure we're in a place now
where we could remove it if we truly needed to, without a lot of pain in the
upgrade path.


Let's try and be reasonable here.


I'm willing to pass along any comments people have individually.



Thanks,

- Alex


> Regards,
> Xavier
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Till Maas" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, April 6, 2020 1:39:49 PM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> On Mon, Apr 06, 2020 at 08:35:28AM -0400, Alex Scheel wrote:
> > - Original Message -
> > > From: "Miro Hrončok" 
> > > To: devel@lists.fedoraproject.org
> > > Sent: Monday, April 6, 2020 8:28:15 AM
> > > Subject: Re: CPE Weekly: 2020-04-04
> > > 
> > > On 06. 04. 20 14:19, Alex Scheel wrote:
> > > > That part isn't actually clear to me. There's certainly a vocal portion
> > > > against using GitLab
> > > 
> > > I think it's hard to see who's vocal against GitLab and who just wants a
> > > truly
> > > open decision process for this.
> > > 
> > > I've heard people who would love to get GitLab, but who are genuinely sad
> > > about how CPE management handled this.
> > 
> > Sure, can we have two positions in this voting system?
> > 
> >  1. I want GitLab,
> >  2. I want Pagure,
> >  3. I want something not listed here,
> >  4. I don't particularly care.
> 
> What do you want to do with this information? 

I'm not in CPE.

I'm curious what the _community's_ position is. There's a small portion of
people responding to this thread. We can make assumptions about what the
Fedora community thinks (and certainly we know what individuals of it think),
but until we have data, do we really know what the majority opinion is?

I value data over a few loud voices. :)

> Also I do not think it is
> a good idea to micro-manager CPE into a specific solution. IMHO it is
> more important to get the dist-git features that Fedora requested and
> probably also issue trackers for Fedora groups (for example Council,
> FESCo, ...) currently implemented in
> pagure.io), GIT repos with a git forge for Fedora (for example for docs,
> infra, releng). And it would be great to also ensure that Fedora
> contributors/Fedora Infra/CPE can contribute to these solutions to
> ensure that Fedora specific requirements can be met.

As I said elsewhere, I don't want to use this for a decision. I just
want to see what more than the ~60 people responding here and in the
other thread actually think about this issue.

I do agree, if this were a vote, it would boxes CPE in. But before the
Fedora community can engage with CPE, shouldn't the leadership (and those
of us arguing on the thread) understand what the rest of the Fedora
community thinks, such that we all can represent something cohesively to
CPE?

IMO, that was the step lacking from this process on the Fedora side.

> If it is easier to customize Gitlab to meet Fedora's dist-git
> requirements than to customize pagure, then it would be good for CPE
> to do this even if more people would like to prefer pagure. If it is the
> other way, then it could still make sense to use Gitlab for tasks used
> by pagure.io to benefit from better Gitforge features, there, but keep
> pagure for dist-git.
>
> Also, I do not have any idea how easy it is to get changes into Gitlab,
> so this is also something that needs to be taken into consideration.
> I find it somewhat troublesome that these questions are not answered,
> especially since the migration from pkgdb to pagure was very painful and
> is not yet completed.

Thanks for your opinion, your response has been recorded in this informal
poll. :)
 
> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Daniel P. Berrangé" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 11:02:52 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 

> Watching the discussion in the other big thread, I feel it has become
> rather too toxic & negative, going over & over the same points, verging
> into personal insults, and repeatly beating people over the previous
> communication or process failures. I struggle to see anything positive
> coming from further contributors joining in that discussion thread,
> which I expect is why so many choose to remain silent.

Agreed on the toxicity and negativity, but I still think it is important
to get a sense of everyone's thoughts, not just those of us who participate
in this thread.

> Going for a formal vote on this topic would not be a good step at this
> point in time, as the issue is far too emotive & raw. A vote will serve
> to crystalize division instead of healing it & we need to consider what
> is viable, as voting for something that can't then be delivered is even
> worse.

I wasn't suggesting a formal vote. I was suggesting a survey, using an
existing mechanism. We could also use Google forms (like Modularity did),
but that'd make the results less visible and some people don't like
Google. Also, the voting mechanism ties into FAS ID's and has restrictions
on who can participate (users with two different groups right?). It'd be
hard to enforce something similar with Google forms.

> IMHO there needs to be a general cooling off period, followed by a fresh
> look at what the realistic options available to Fedora are, given the
> current decisions that have been made & the resources available to the
> project[1]. We need to be positive & constructive if we're to make any
> progress, and get out of the negative blame game we're in right now.

I think we need to involve everyone who CPE works with in one forum,
otherwise we'll likely arrive at maintaining two separate projects,
one just for Fedora and one for CentOS and Red Hat. Perhaps that is
what is best though, who knows.

> Regards,
> Daniel
> 
> [1] I'm not saying that we must go ahead with the decision to replace
> Pagure with GitLab. Just that we need to carefully consider where
> to go from here, as any decision needs to be sustainable for the
> project in the long term.
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange
> |:|
> |: https://libvirt.org -o-https://fstop138.berrange.com
> |:|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange
> |:|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 10:57:40 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> Le lundi 06 avril 2020 à 10:09 -0400, Alex Scheel a écrit :
> > 
> > In the last FESCo election, 273 ballots were cast [0]. According to
> > the
> > graph maintained by Matthew Miller [1], we have between 225 and 375
> > active maintainers in Fedora, depending on how you count.
> 
> That’s *weekly* activity. As in, the packager finished something, and
> was active a specific week landing the result in Fedora. It does not
> count all what happens outside Fedora infra before the result lands.

I'm not sure why what happens outside Fedora infra has anything to do
with the dist-git discussion. Are you suggesting that all contributors
to all Fedora upstream should weigh in on this discussion as well? I
mean, that'd be nice I suppose, but mostly this a discussion for people
who interact with dist-git frequently. 

I do recognize that perhaps a monthly contributor list might have higher
magnitude than 300. But there's still old bugs, new bugs, and random other
contributions that could count as activity besides pushing a Bodhi update.


My 2c.

- Alex

> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Ben Rosser" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, April 6, 2020 9:49:13 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 

Thanks for sharing your thoughts. :-)

> Not saying you're wrong that it would be nice to have the ability to
> poll a broader selection of packagers. But I'm not sure using the
> FESCo voting system would really accomplish that either. How many
> people actually vote in FESCo elections relative to the number of
> active packagers? I'm sure you could argue that, depending on the
> turnout, the results wouldn't be necessarily representative either.

In the last FESCo election, 273 ballots were cast [0]. According to the
graph maintained by Matthew Miller [1], we have between 225 and 375
active maintainers in Fedora, depending on how you count.

That says that FESCo elections are ~5x more participated in than these
mailing list discussions, and are a much more representative sample of
all our (active?) packagers. I'm not sure if FESCo votes count as
packager activity in the above graphs; I'm guessing not.


My 2c.

- Alex

[0]: subj: "FESCo election results", sent 6/Dec/'19 by bcot...@redhat.com,
 to this mailing list.
[1]: 
https://mattdm.org/fedora/fedora-contributor-trends/active-contributors-by-week.svg

> 
> Ben Rosser
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Nicolas Mailhot" 
> Sent: Monday, April 6, 2020 9:10:56 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
> > 
> > It'd be interesting to see if the FESCo election system could be
> > repurposed to get a sense of all packagers' opinions, rather than
> > make assumptions on how the community as a whole feels based on a few
> > vocal members and their participation in the mailing lists.
> 
> 
> Fedora guidelines ask Fedora packagers to subscribe to the devel list,
> so it’s the official place to reach Fedora packagers.

That's not the point I was making.

Not everyone is inclined to loudly argue their positions on the mailing
list. There have only been 12 unique participants to this thread and 57
to the other thread.

That isn't indicative of the entire Fedora packager ecosystem. A lot of
people are staying silent.


I believe we need a different way to engage the rest of our packager
base.

- Alex

> And practically, ignoring officialdom, yes there is a self selection
> bias, every packager does not follow guidelines and the list. But, it
> is a bias in favor of people who do stuff, and use the list to
> coordinate, ie the portion of the packaging community you least want to
> ignore, because they pull all the others.
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Miro Hrončok" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, April 6, 2020 8:28:15 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> On 06. 04. 20 14:19, Alex Scheel wrote:
> > That part isn't actually clear to me. There's certainly a vocal portion
> > against using GitLab
> 
> I think it's hard to see who's vocal against GitLab and who just wants a
> truly
> open decision process for this.
> 
> I've heard people who would love to get GitLab, but who are genuinely sad
> about how CPE management handled this.

Sure, can we have two positions in this voting system?

 1. I want GitLab,
 2. I want Pagure,
 3. I want something not listed here,
 4. I don't particularly care.

--- 

 a. I am OK with how this was handled,
 b. I would prefer an open process,
 c. I don't care how it was handled.


IIRC, FESCo voting is a ranked voting scheme, so we'd also get a sense of
preference for each of these items.


It'd need some disclaimer that this is meant as a survey and not as an
actual decision mechanism and that the results wouldn't necessarily
influence the outcome. But as a way of reading the temperature of the
entire room and not guessing based on mailing list participation, it
might be better.


My 2c,

- Alex

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

Re: CPE Weekly: 2020-04-04

[Alex Scheel]

- Original Message -
> From: "Dominik 'Rathann' Mierzejewski" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, April 6, 2020 7:09:38 AM
> Subject: Re: CPE Weekly: 2020-04-04
> 
> On Monday, 06 April 2020 at 12:41, Leigh Griffin wrote:
> > On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow 
> > wrote:
> > 
> > > On 4/4/20 3:02 PM, Aoife Moloney wrote:
> > > > However we do
> > > > recognize that it was still nonetheless a decision that was not made
> > > > in public, and for that we can only now offer our apologies for this
> > > > mistake and learn a hard lesson from it.
> > >
> > > It's simply not true that this is the only thing that can be done. You
> > > can hold off on making a decision, and follow an open process instead.
> > 
> > We are engaged with the Fedora Council on the next steps here for the
> > adoption of Gitlab / the retirement of Pagure from the CPE remit. That much
> > of the decision has been made, the actual specifics are what we are
> > engaging on to make sure that the Fedora needs are satisfied as we move
> > forward.
> 
> The majority here is telling you to hold off execution of that
> "decision" and revisit it, but you're ignoring those voices entirely and
> offering useless "apologies" instead. You cannot pretend to be part of a
> community if you just ignore its other members and do your own thing.

That part isn't actually clear to me. There's certainly a vocal portion
against using GitLab, but is that sufficient to determine it is the
majority of the Fedora packager community? I at least felt tired of
arguing and decided to mostly quit arguing versus continuing to participate
in this thread.

It'd be interesting to see if the FESCo election system could be
repurposed to get a sense of all packagers' opinions, rather than
make assumptions on how the community as a whole feels based on a few
vocal members and their participation in the mailing lists.


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

Re: CPE Git Forge Decision

[Alex Scheel]

- Original Message -
> From: "Panu Matilainen" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, April 1, 2020 6:22:39 AM
> Subject: Re: CPE Git Forge Decision
> 

> > I also appreciate that as a community developing our own solutions is
> > something important and something that seems to matter a lot, but we
> > have to realize that the development and maintenance effort cannot be
> > carried out by the CPE team any more. Maybe this is a opportunity to
> > create a SIG or a working group for people that are interested to carry
> > on this effort.
> 
> But this is precisely at the heart of the problem: people feel they were
> not given an opportunity to lend a hand, and that now its too late
> because the messaging is that we go with GitLab, no matter what.

Pagure has huge developer experience bugs filed against it for many
years. Where have all these contributors been? Are those of us who really
dislike Pagure's workflows in the minority? Or are others more prone
to put up with it because it is free, open source software?


IMO, it seems like an ideological argument, not a sound technical
one.

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

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

[Alex Scheel]

- Original Message -
> From: "Neal Gompa" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Alex Scheel" , "Leigh Griffin" 
> Sent: Monday, March 30, 2020 3:30:20 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
> 

> As for Gitea, we're basically at parity with Gitea now. The major
> difference between Pagure and Gitea is that Pagure is highly
> extensible and Gitea is designed to be a very self-contained
> application. Plugging Pagure into workflows and infrastructure is
> substantially easier than doing the same with Gitea.

The following "just work" with Gitea and have usable defaults:

 - Full Text Search by default
   https://pagure.io/pagure/issue/2505
 - A real search bar
   https://pagure.io/pagure/issue/4543
 - Proper diff line numbers
   https://pagure.io/pagure/issue/2193
   https://pagure.io/pagure/issue/724
 - Proper inline comments
   https://pagure.io/pagure/issue/3488
   https://pagure.io/pagure/issue/4488
   https://pagure.io/pagure/issue/3646
 - ... I could go on

Pagure isn't at parity with Gitea. Please run an instance of Gitea and
compare. The UX with Gitea is _much_ better.

If these issues are old, please close them. 


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

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

[Alex Scheel]

- Original Message -
> From: "Martin Kolman" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Leigh Griffin" 
> Sent: Monday, March 30, 2020 3:05:54 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)


> > And to be clear: there's a difference between a Fedora-sponsored
> > Development forge and a new git forge for dist-git. A lot of this
> > discussion has conflated these two cases. I mostly care about it
> > releasing the former role (pagure.io) and don't care much about
> > the latter role (s.fp.o).
> I personally see this pretty much the other way - there are many good
> or usable forges for hosting ones project. There is at the moment pretty much
> only one git forge with good (and any at all any) integration with Fedora
> processes
> - Pagure.
> 
> That's why I see Pagure as important mostly in the Fedora family context and
> less
> important in the general git forge are. It would certainly be nice to see
> Pagure
> take over that as well, but I see having a fully open git forge with full
> Fedora integration sitting on top of distgit as more important.

I don't really use dist-git's forge for much. Maybe for hitting "fork" when
I need to open a PR against another repo, and filing the PR. Everything else
happens via fedpkg/git/bodhi/koji... on the command line. 

I don't really care about showing the latest versions of packages on dist-git
(that's what bodhi/koji is for). That's the most recent user-visible feature,
yes? Why that? ~shrugs~

Having a little better admin/group integration would be nice.

But as long as it doesn't take ages to fork a repo (and Pagure does sometimes!),
I don't really care. I'm also not a proven packager or the owner of a huge
package dependency tree (python, java, perl, ...). I really just care about a
few packages, plus whatever is in the Stewardship SIG.

I guess a little nicer orphan/unorphan package procedure would be nice, but
you'd still need a ticket for unretiring dead packages, which is where I've hit
the most problems/delays.

But as long as I can continue to work from the command line, I don't really
care what the WebUI is as long as it works and isn't too slow.



My 2c. but I'm really agnostic about dist-git forges. :-)

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

Re: The Git forge decision (was CPE Weekly: 2020-03-28)

[Alex Scheel]

- Original Message -
> From: "Bruno Wolff III" 
> To: "Leigh Griffin" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Monday, March 30, 2020 2:08:21 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
> 
> On Mon, Mar 30, 2020 at 17:20:04 +0100,
>   Leigh Griffin  wrote:
> >On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann  wrote:
> >
> >We are trying to reduce the total ownership of the team to allow us to
> >provide value on initiatives that are requested of us by our stakeholders.
> 
> Pagure has value beyond Fedora and RedHat. In some ways it has more value
> than Fedora the OS, because there are less free options in the git forge
> space. (Gitlab isn't usably free as is. It would need a real fork to
> get out from under the sponsor's conflicts of interest.)

Have you tried to use Pagure as a development based git forge? And not
just as a dist-git hosting location? It needs a lot of help! More than the
current resources provide.

The reasons why are well documented in Pagure's issue tracker.

If that's something you value, feel free to contribute to Pagure upstream.
But Pagure can't compete with Gitlab as a development forge in its current
state.

There are other public git forges that behave better than Pagure:

 - SourceHut 
 - Gitea
 - ...

So I don't think this actually has as much value as you think.


And to be clear: there's a difference between a Fedora-sponsored
Development forge and a new git forge for dist-git. A lot of this
discussion has conflated these two cases. I mostly care about it
releasing the former role (pagure.io) and don't care much about
the latter role (s.fp.o).


My 2c. 

- Alex

> 
> I would have expected the council to consider this an important project
> worth pursuing on its own, not just for running part of Fedora's
> 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
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33

[Alex Scheel]

- Original Message -
> From: "Andrew Haley" 
> To: "Development discussions related to Fedora" 
> , "Alex Scheel" 
> Cc: "Omair Majid" 
> Sent: Monday, March 30, 2020 12:36:23 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system 
> JDK in F33
> 
> On 3/30/20 4:47 PM, Alex Scheel wrote:
> > For one example here, take the long-standing Debian ticket against Dogtag:
> > 
> > https://www.pagure.io/dogtagpki/issue/3088
> > 
> > OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA
> > isn't
> > available. This is a requirement for our particular application.
> > 
> > It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works
> > fine
> > on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time
> > to
> > debug and figure out what broke in OpenJDK.
> > 
> > 
> > With the introduction of JSS's SSLEngine, we can work around this problem,
> > but
> > that isn't yet merged.
> > 
> > https://github.com/dogtagpki/jss/pull/150
> 
> Tricky. It's kinda inevitable that some things will break at some time. We
> have to decide whether Dogtag is a blocker for JDK 11 as system JDK.

FWIW, Dogtag is part of IPA, which is already a blocker for GA releases. But,
we're concurrently working on an alternative SSLEngine implementation that will
fix our problems by not using the JDK TLS stack.


- Alex

> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33

[Alex Scheel]

- Original Message -
> From: "Jiri Vanek" 
> To: "Development discussions related to Fedora" 
> , "Miro Hrončok"
> , "Deepak Bhole" , "Severin Gehwolf" 
> , "Omair Majid"
> 
> Sent: Monday, March 30, 2020 11:38:34 AM
> Subject: Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system 
> JDK in F33
> 
> On 3/30/20 5:11 PM, Miro Hrončok wrote:
> > On 30. 03. 20 16:04, Ben Cotton wrote:
> >> === Other ===
> >> * Proposal owners:
> >> ** based on above, adapt jdk8 and jdk11 package provides
> >> ** If necessary tune the build environment
> >>
> >> * Other developers:
> >> ** based on selected approach to tune the main build tools
> >> *** at least jpackage-tools and maven will be very likely affected
> >> ** based on selected approach to tune the rpmbuild/macros
> >> ** many java package maintainers will maybe need to adapt theirs packages
> >> *** After the approach is agreed, mass rebuild must be performed
> >> *** FTBFS bugs connected with this proposal, maybe with jira ticket to
> >> allow discussion.
> 
> Thank you for bringing it up!
> > 
> > I don't understand who does all the hard work. Will the change owners just
> > change the default and go
> > away, or will the change owners handle the rebuilds?
> 
> We will handle the tuning of jdk8 and jdk11 rpms. Also we will do an initial
> testing if it does what
> it should.
> Once it is done, mass rebuild is launched. we will then see. But it will be
> in on individual package
> owners to fix theirs packages.
> We will definitely help where necessary or where needed, and will most likely
> gather the most common
> cases, but to push to not-owned repos... only in critical cases.
> 
> Of course we can reconsider, but it is not on powers of few (5?) individuals
> to fix 2500 packages,
> even if it will be only two or three most common cases.
> 
> As for the runtime part, it is another story. There again we will do
> everything necessary to fix the
> problems both usptream and downstream, but the runtime casaes will flow up
> only in later stages of
> lifecycle  of f33. Possibly even after f33 release.  Note, that if there is
> serious runtime issues,
> then it would be really poorly written usptream application or very outdated
> downstream, not broken
> migration. Still the help will be attempted to be provided.

For one example here, take the long-standing Debian ticket against Dogtag:

https://www.pagure.io/dogtagpki/issue/3088

OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA isn't
available. This is a requirement for our particular application.

It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works fine
on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time to
debug and figure out what broke in OpenJDK.


With the introduction of JSS's SSLEngine, we can work around this problem, but
that isn't yet merged. 

https://github.com/dogtagpki/jss/pull/150



My 2c., but I hope help is given, especially in testing the new packages to
make sure nothing subtle broke.

- Alex

> 
> > 
> > As a side not, please don't mix in Jira tickets, that sounds RH internal to
> > me.
> 
> Sure. If I did, then not intentionally. By jira ticket in the above  I had in
> mind general ticket on
> pagure or similarly. The word jira did not belonged here. fixed the doc.
> > 
> Thanx!
>  thanx a lot,
> J.
> 
> --
> Jiri Vanek
> Senior QE engineer, OpenJDK QE lead, Mgr.
> Red Hat Czech
> jva...@redhat.comM: +420775390109
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Java Packaging Guidelines - .so in JARs?

[Alex Scheel]

Per $SUBJ, I was looking for guidance from the Java community about
embedding .so files within JARs.

I found these docs:

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

Which seem to have conflicting commentary on this:

 - A Java package uses JNI if it contains a .so file. Note that this file can
   be embedded within JAR files themselves.
 - JNI shared objects MUST be placed in %{_libdir}/%{name}

As long as the JAR for the application is played in 
%{_libdir}/%{name}/%{name}.jar,
does this mean that the .so can be placed within the JAR?


The benefit to .so-in-JAR is that the JAR always knows where to find the .so,
even if the user installs multiple versions of the same package, or, worse,
copies JARs from different systems around.


Wondering what the community's thoughts are,

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

Re: Non-Responsive Maintainer Check for jsmith

[Alex Scheel]

Thanks! Non-responsive maintainer check canceled from my perspective.

- Original Message -
> From: "Jared Smith" 
> To: "Alex Scheel" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, February 12, 2020 1:14:11 AM
> Subject: Re: Non-Responsive Maintainer Check for jsmith
> 
> On Tue, Feb 11, 2020 at 4:01 PM Alex Scheel  wrote:
> 
> > I'm initiating the non-responsive maintainer policy for jsmith.
> >
> 
> Sorry for the slow reply -- I've been busy lately finishing up graduate
> school, and I was on vacation last week.  I will attempt to respond to your
> bugzilla request as quickly as possible.
> 
> -Jared
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Non-Responsive Maintainer Check for jsmith

[Alex Scheel]

I'm initiating the non-responsive maintainer policy for jsmith.

Per: 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

Week -1:

Mail to jsmith (cc: devel@). Sent 7 February 2020. Subject:
nodejs-babel-runtime - orphan?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQUA2OFJRDAUY7ROC3LU5QL2LYHVSHL4/

Week 0: 

Filed BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1801896
Open Bugs (381 count):

https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__=Fedora=jsmith.fedora_to1=1=substring_id=10832612=Fedora_format=advanced


Does anyone know how to contact jsmith? 

I'm specifically looking for a solution to the nodejs-babel-runtime
package not being installable on Fedora: 

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



Thanks,

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

nodejs-babel-runtime - orphan?

[Alex Scheel]

\o Hey Jared,

I recently tried looking for the Babel compiler in Fedora, and
stumbled upon the packaged version, nodejs-babel-runtime. However,
it isn't installable:

Error: 
 Problem: conflicting requests
  - nothing provides (npm(regenerator-runtime) >= 0.10.0 with 
npm(regenerator-runtime) < 0.11) needed by 
nodejs-babel-runtime-6.23.0-6.fc31.noarch


This has been a known issue for quite some time:

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



Do you still have cycles to maintain nodejs-babel-runtime, or
should it be orphaned?



Thanks!

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

Re: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Stephen John Smoogen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, January 29, 2020 8:47:46 AM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> On Wed, 29 Jan 2020 at 05:14, Andrew Haley  wrote:
> >
> > On 1/27/20 3:13 PM, Alex Scheel wrote:
> > > N.B.: I'd like to thank the Red Hat JVM team for being solid in
> > > their Fedora execution. But they maintain only the JVM, and not
> > > the rest of the Java ecosystem. :-)
> >
> > Thank you.
> >
> > One (perhaps) rather minor point in the middle of this important
> > discussion: there is no "Red Hat JVM team." We're responsible for the
> > entire base Java (SE) platform, that is to say the VM and the
> > surrounding Java libraries.
> >
> > Also, we're not just responsible for RHEL and Fedora: our team and our
> > partners in a few other organizations are responsible for all OpenJDK
> > updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
> > to say, apart from Oracle's proprietary customers, most of the Java in
> > the world.
> >
> 
> The issue is that people (developers, users, maintainers) lump the
> entire ecosystem together.. so yes you maintain that but why don't you
> also maintain all the java packages which sit on that platform so it
> is 'useful' to them. [Yes the question is one of scope, time and
> resources.. but to a lot of people it needs clear explanations in the
> same way that people will take their Ford to a Toyoto autoshop because
> 'its a car, you should be able to fix it']

Right Andrew: Stephen was drawing the distinction I was trying to make.
I lump the Java SE platform into "roughly" what I was calling the JVM
team. You're roughly the group that does what'd be the "core" work in
other languages: maintains the compilers and the stdlib. My terminology
there was incorrect; I suppose "JRE" is more correct.

Is it correct to say that your team and immediate coworkers don't
maintain say, the Apache libraries, the various build systems, IDEs,
and the JBoss libraries? 

My point is that some language SIGs/teams take a more active role in
making sure a decent amount of non-stdlib software runs and is
maintained by them. The "core" Java (JVM + JRE) team doesn't seem to
engage in other places. Which is totally fine, from my PoV, as long
as there is communication between the two parts and between the group
and the wider Fedora community, and the overall experience is inclusive.


Instead, most of the library support falls to Joe's team, including
Mikolaj. That's where most of the shortcomings in Java packaging are
seen, including unfriendly, non-inclusive modularization policies.
They're the ones that have orphaned large segments of packages, which
ultimately lead to starting this mail thread. :-)

Perhaps putting words in Bill's mouth here, but I don't subscribe any
of his issues to the JRE team. They're mostly caused by issues in a
lot of packages disappearing, and Matt Booth trying his best to clean
up after that (with the help of Stewardship SIG). But we're all busy
folks and sometimes we can handle that new package load and sometimes
we can't.


And yes, you do a lot of great work in other places too. I thank you
for that the few times I need to touch Java on non-Linux platforms. :-)


Keep up the good work,

- Alex

> 
> 
> 
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Java Dev Group and Fedora Quality

[Alex Scheel]

- Original Message -
> From: "Tom Seewald" 
> To: devel@lists.fedoraproject.org
> Sent: Sunday, January 26, 2020 12:35:32 PM
> Subject: Re: Java Dev Group and Fedora Quality
> 
> > On Sat, Jan 25, 2020 at 11:07 PM Bill Chatfield via devel
> *snip*
> > True. Nobody cares about Java packages in fedora, not even Red Hat
> > employees. If you look at the members of the Java SIG, a lot of them
> > were (or still are) Red Hat employees. For example, even JBoss /
> > WildFly (a pretty big Java project by Red Hat) was unmaintained and
> > broken, and most of it has now been removed from future fedora
> > releases. I wonder what they are going to do with RHEL 9 - maybe
> > somebody notices their stuff isn't available on fedora anymore.
> 
> Do you happen to know what the Red Hat employees who maintain Java-based
> products use as their desktop OS? RHEL? macOS?

As a Hatter, I'm proud to say that I--and most all of my team--use
Fedora for our work machines. I run F31 without modular repos on all
four of my boxes in my home office.

I work on Dogtag PKI (https://www.dogtagpki.org), a private CA, built
on top of a Tomcat/Java stack.


Responding to the JBoss dismissal: JBoss is its own product and doesn't
have the goal of shipping on Fedora before it ships in its own product.
All of the JBoss packages maintained in Fedora are maintained by the
community (including non-JBoss Red Hatters) who need them in other
packages.

Concretely, if you'd like to see more JBoss packages, join us in the
Stewardship SIG and collaborate to revive the ones you care
about. :-)


- Alex


N.B.: I'd like to thank the Red Hat JVM team for being solid in
their Fedora execution. But they maintain only the JVM, and not
the rest of the Java ecosystem. :-)

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

Re: Git Forge Requirements: Please see the Community Blog

[Alex Scheel]

- Original Message -
> From: "Michael Catanzaro" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 21, 2020 4:31:47 PM
> Subject: Re: Git Forge Requirements: Please see the Community Blog
> 
> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  wrote:
> > And any discussion of GitHub isn't going to involve self-hosted, it's
> > going to involve GitHub.com, which means we're talking about losing
> > more of our independence as a project. This is one of those things
> > that I'm not sure is a wise move.
> 
> Well since we have a request for requirements: I propose requirements
> #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
> community would be outraged if we fail to meet either requirement.
> 
> So if we can agree on that much, then we can avoid wasting time by
> including GitHub in the list of options. That would bring us to a
> choice between GitLab CE and Pagure. (Are there any other serious
> options?)

I'd mention sr.ht (sourcehut) and gitea; the latter I run myself.

https://sourcehut.org/ (live: https://git.sr.ht/)
https://github.com/go-gitea/gitea demo: https://try.gitea.io/)

YMMV.

> 
> Michael
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Alex Scheel]

I had replied to Fabio on IRC but... :-)

- Original Message -
> From: "Guido Aulisi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 21, 2020 3:48:31 PM
> Subject: Re: Git Forge Requirements: Please see the Community Blog
> 
> 
> 
> > Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini
> >  ha scritto:
> > 
> > On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  > > wrote:
> >> 
> >> Hey Everyone,
> >> 
> >> On behalf of the CPE team I want to draw the communities attention to a
> >> recent blog post which you may be impacted by:
> >> https://communityblog.fedoraproject.org/git-forge-requirements/
> >> 
> >> 
> >> We will be seeking input and requirements in an open and transparent
> >> manner on the future of a git forge solution which will be run by the CPE
> >> team on behalf of the Fedora Community. This mail is being sent to the
> >> devel, mindshare and council-discuss lists for maximum visibility on a
> >> BCC to allow each list have their own views. Please forward it to any
> >> other list you may feel is relevant to maximise the exposure.
> >> 
> >> Thanks in advance,
> >> Leigh
> > 
> > Alright, I have some questions that are not answered by the blog post.
> > 
> > - What is going to happen to the two pagure instances at pagure.io
> > ,
> > and src.fedoraproject.org ?
> > 
> > I think pagure.io  is a good home for fedora-related
> > projects (it was
> > the successor to fedorahosted.org , after all,
> > IIRC). I know that many
> > group efforts are hosting their source code, ticketing system, etc.
> > there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> > shut down pagure.io , I assume those projects will have
> > to be moved
> > somewhere?
> +1
> 
> > Also, it's very nice to have a PR-based workflow for some
> > shared-maintenance packages on src.fedoraproject.org
> > , and I don't
> > think losing that feature would be a good thing for fedora.
> +1
> 
> > - How is GitHub considered to be an alternative here?
> +1 …and to my knowledge GitHub is closed source.
> 
> > I don't think (public or hosted) GitHub can do what is currently done
> > on src.fedoraproject.org , can it?
> > I'd also not want to see fedora use a closed-source product for such a
> > core service ...
> > 
> > - Which features are missing from pagure, compared to the other forges?
> +1 It’s not clear reading the original POST
> 
> > For my purposes, I don't miss any feature on pagure.io 
> > compared to my
> > repositories on github.com , and OTTOMH, I can't come
> > up with any
> > missing features, at all …
> +1

From a _development_ POV, there's a number of things missing for it being
the primary git forge for pagure.io (not arguing about src.fedoraproject.org
or packaging use cases -- but some of those will benefit by these as well):

 - Real full-text search across issues and PRs. No need to RTFM.
(
 For those not having RTFM'd, you use "content:" to do a
 full-text search in current Pagure. I've argued that it should
 behave like other forge's searches:
 https://pagure.io/pagure/issue/2505#comment-582516
)
 - A UI with a UX that makes sense.
   https://pagure.io/pagure/issue/4543
   https://pagure.io/pagure/issue/2193
   https://pagure.io/pagure/issue/42(duped: 343)
   https://pagure.io/pagure/issue/2167
   (and you could keep cherry-picking issues. There's a section of
opened ones with UI tags).
 - The above is a huge category and I think its worth restating
   some items:
- Search, search, search.
- Split diff
- Real line numbers in the diff
- Expanding context around the diff
  (Diff, diff, diff?)
- Workflow on reviewing PRs is sub-optimal compared to most
  other forges.
 - Pagure is often slower than GitLab for me. YMMV.
 - ...

For a period of time, IDM tried using Pagure for FreeIPA development.
They filed a huge number of issues. Now we host issues on Pagure, and
have moved development to GitHub. [*] I think we've mostly quit filing
bugs; the Pagure team has done a good job with the resources they've
been given, but they definitely need more resources to pull this off
to a high level.

I still try and file issues from time to time...

...but Pagure really doesn't compare in quality to Gogs/Gitea, much
less GitLab or GitHub from strictly a development point of view.


My 2c.

- Alex


[*]: My team (Dogtag) is also considering moving our issues off of 
Pagure onto GitHub, to host them along side our code. I don't claim
to speak for all of IDM here though, just noting what they've done.

> > 
> > TL;DR:
> > Can we please keep pagure? It already has the fedora-specific features
> > we need, and I 

Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

[Alex Scheel]

> 1. I didn't ask for/want a module.
> 2. They aren't actually needed. After disabling them and reinstalling the
> programs I care about (or could have used distro-sync) they weren't
> actually needed.

This is where I'll drop a plug for the Stewardship SIG. Thanks in large
part to Fabio's great work, 2 has been possible since the ant and maven
modules were introduced.

The only distribution we don't maintain as ursine is eclipse. But we
still maintain many of the dependencies of the Java stack (including 
LibreOffice,
Dogtag, Ant and Maven) as ursine.

For some of us in the SIG, this means that we're able to run without 
modular repos enabled at all, and continue doing or daily jobs requiring
the Java stack. 


If you like the work, consider helping out!


We keep a list of packages that we're looking for updates on:

https://decathorpe.fedorapeople.org/stewardship-sig-stats.html

But check our list of pending PRs first:

https://decathorpe.fedorapeople.org/stewardship-sig-prs.html


Feel free to join #fedora-stewardship on Freenode if you're interested
in helping out but don't know where to start. 

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

Re: [fedora-java] What's the State of the Java SIG?

[Alex Scheel]

- Original Message -
> From: "Gerald Henriksen" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, November 18, 2019 6:40:54 PM
> Subject: Re: [fedora-java] What's the State of the Java SIG?
> 
> On Mon, 18 Nov 2019 13:37:39 +0100, you wrote:
> 
> >Fabio Valentini wrote:
> >> Or is it time for a "tabula rasa" and restart the SIG?
> >
> >IMHO, yes. Kick out the 1 or 2 Modularity fundamentalists that form the
> >current remains of the Java SIG and create a new Java SIG from scratch that
> >actually cares about packaging Java properly in and for (non-modular)
> >Fedora.
> 
> Great, you eliminate the remaining members of the Java SIG (those who
> didn't go running away because forcing Java stuff into RPMs was too
> painful).
> 
> Now where are you going to get new members to create this new Java
> SIG?
> 
> I mean, the Java SIG isn't forcing Java packagers to use Modularity,
> so that isn't why the Java SIG is dying.

For historical context...

Without Ursa Prime/Major/whatever we're calling it now, that's where
we've been for the last... n > 6 months. If you depended on Ant, Maven,
or any of the minor libraries they've modularized and put in their default
module stream, the Java SIG's (un)official(?) policy was to have you
modularize. Because that was the only way to use these packages! And if
your runtime dependencies are in javapackages-tools? Good luck! You have
to rebuild them inside your own module!

It has entirely been the efforts of the Stewardship SIG to enable ursine
users. We've done that by continuing to packaging many of the libraries
that the Java SIG has either dropped entirely or made modular-only. For
the last n > 6 months, packages such as LibreOffice and Dogtag have
continued building only because we keep maintaining these packages as
ursine. We did this in part to keep our own packages building and in
part because we don't believe modular packages are a real answer to
maintainership problems. 

Purely speculation on my part, but part of what likely caused the Java
SIG to effectively dissolve was because each maintainer was an island,
a hero. They maintained all their packages on their own; there is no
"Java SIG" FAS packaging group. As Mikolaj has said, the meetings stopped,
the mails stopped. People probably just quit working together.

Part of what we've tried to do differently in the Stewardship SIG is
encourage community and peer support. We're a FAS group and all our
packages are owned by the collective group. We maintain public lists of
what's in need of review [0], what we maintain [1], what we're looking
for updates on [2], and what we're in the process of doing [3]. Anyone
is free to contribute to the Stewardship SIG too! Fabio does a lot of
work, and we're deeply thankful for that! But a few of us double check
his work, help out on minimizing package dependencies as we get time,
catch CVE updates, and perform rebases too. We're always looking for
more members, and if you're interested in joining, just shoot a mail!


Now, I do want to point out there are two faces to the Java SIG. There's
the set of maintainers who maintain the soft underbelly of Java libraries.
That's mostly Mikolaj now. People like gil and others, while at one point
large Java package maintainers, have since moved on and their packages
have been orphaned through the unresponsive maintainer process. I think
the Eclipse team is part of that too. But it did seem rather uncoordinated,
from the outside, the whole ant+maven causing Eclipse to modularize dance.

But there's also the quiet maintainers of the JVM itself, who we're all
grateful for their quiet work. They've not tried to modularize as far
as I can tell. For all their hard work, we're thankful!


We, the Stewardship SIG, have said before that if you need packages
maintained that we're about to orphan, tell us! We'd keep them around
and do our best to update them. We try not to orphan everything we have,
we announce on the list and cc dependent package maintainers, and generally
try to be good stewards of the community. We had offered in the past,
on the list, to help Eclipse maintain whatever packages they needed to
stay ursine, but that offer went unanswered. And if your application is
major or critical to Fedora, like LibreOffice, Dogtag, or even Eclipse are,
we'd be consider taking on new packages and maintaining them too, if they
benefit the community.

However, without new members and more time on our hands, I'm not sure how
longer we'll be able to continue. Being brutally honest, Fabio does a LOT
of work. We need a long term solution that doesn't leave all our ursine
packages broken. Regardless of whether they're part of Fedora, existing only
hidden, private networks of universities and corporations, or lurking in
someone's COPR.


- Alex

[0]: https://decathorpe.fedorapeople.org/stewardship-sig-prs.html
[1]: https://decathorpe.fedorapeople.org/stewardship-sig.html
[2]: 

Re: What's the State of the Java SIG?

[Alex Scheel]

- Original Message -
> From: "Mikolaj Izdebski" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "java-devel" 
> Sent: Monday, November 18, 2019 5:42:20 AM
> Subject: Re: What's the State of the Java SIG?

~snip~

> Maintenance of obsolete packages is non-goal for Java SIG.

A number of packages -- which the Java SIG has dropped -- are still
under active development. The Apache Commons collection, JBoss packages,
glassfish/jakarata/... packages, plexus,  Sure, we have a few dead
packages. We've tried our best to drop many of these. And admittedly we're
still on the JavaEE packages pre-Eclipse donation (and rename to Jakarata).
But calling these large package collections maintained by three large,
active maintainer bases (Apache Foundation, Red Hat JBoss, and the Eclipse
Foundation) unmaintained seems... wrong?

~snip~

> > Or is it time for a "tabula rasa" and restart the SIG?
> >
> > I really hope we can get something off the ground, soon - because I
> > and other members of the Stewardship SIG have been spending a lot of
> > hours each week on keeping this stuff working, but my patience and
> > energy are reaching their limits. I'd really like to slowly start
> > handing over Java packages to someone who's actually using them, and
> > is interested in keeping them maintained.
> 
> IMHO effort spent on maintenance of most of these ursine Java packages
> is mostly wasted effort. As I said before, many times, these packages
> should be retired and replaced by modular packages, which are
> maintained by Java SIG members like me. maven and ant modules are
> already default streams, so users should get them instead of ursine
> packages. The last remaining step is enabling javapackages-tools in
> ursine buildroot so that ursine packages can be built with modular
> maven. Once that happens, there will be no reason to maintain ursine.
> Therefore, instead of putting time on updating ursine Maven et al.
> I recommend to put effort towards enabling modules in ursine buildroots.
> 
> > PS, side note about Modularity: If I understand the current state of
> > things correctly, the plan is to make the "maven:3.5" and "ant:1.10"
> > modular packages be installable alongside non-modular Java packages.
> > They're currently shadowing non-modular packages (since they have
> > default streams), but I understand this is getting fixed. This means
> 
> Shadowing of ursine packages by modular packages is not a defect.
> That is a feature of modularity. Therefore there is nothing to fix there.

I'm sorry Mikolaj, but I'm really confused reading this part of your mail.

A number of these packages exist as ursine packages precisely because
you've made them BUILDROOT-only! We, the Dogtag team, asked you to
reconsider that choice because we needed these as runtime dependencies,
not build-time only. You declined and said our choices were to maintain
our own modular forks or maintain the ursine variety. So, here we are.
And now, you're telling us to switch to modules? But that doesn't help
us access those BUILDROOT-only packages at runtime!


Could you help me understand how we're supposed to move forward?

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

Re: What are the benefits of default modular streams over non-modular packages?

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, November 15, 2019 10:58:04 AM
> Subject: Re: What are the benefits of default modular streams over 
> non-modular packages?
> 

~snipping long thread~

> Another issue is that the modular Java packages are now getting built
> with OpenJDK 11, while the non-modular default is still OpenJDK 8, and
> nobody is left to drive an OpenJDK 8 → 11 transition in fedora
> forward. We're basically the only holdout on Java 8 still, with even
> debian stable (!) defaulting to OpenJDK 11 now. This will probably
> lead to all kinds of fun incompatiblities between modular (Java 11)
> and non-modular (Java 8) packages. And I've not even mentioned the
> myriad of other, slightly incompatible changes between modular and
> non-modular Java packages ... *SIGH*

I think, assuming the proper -target / -release flags are used in
all modular packages, this will largely be a non-issue. Java does its
best to allow building packages with newer JDK versions while still
allowing older JREs to run the code. That's not the case if -target and
-release flags are missing. It also only really affects the consumers
of Java _libraries_ built with JDK11. Almost nobody will notice if Maven
was built with JDK 11. However this issue has been discussed elsewhere,
and we've determined that we'll be fine (TM):

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UNAKWOA4HZP233PT34OVXSYFWFX47FSF/

I do agree that we will need to migrate to JDK 11, but that'll take
time. Perhaps we need Miro's fine management skills and strict policy
enforcement to get us there a la python2->python3 migration.

> > Perhaps this stuff is obvious to others already.  In RHEL8 while we have
> > certainly hit various problems with modularity at least I don't recall
> > my teams hitting major issues with default streams being available for
> > non-modular packages.
> 
> Maybe the dogtag-pki team can offer some opinions here? I know that
> they've had to deal with this on both RHEL and fedora.

Most of the RHCS team's perceived shortcomings of Modularity have come from
general issues, not ones stemming particularly from default streams. A
portion has probably been because we did this the wrong way and committed
to shipping it in RHEL before it was stabilized in Fedora. As has been
mentioned before on this list, we have some version of Ursa {Prime,Major}
in RHEL and we don't have large, conflicting efforts to maintain ursine build
trees in parallel to modular ones like Fedora has.

I've aired most of our opinions on this list in other threads. I don't think
it is worth reiterating here. But I will say we have much more leniency
when it comes to packaging there than we do here.

---

My personal opinion is that modules in Fedora are broken because of
politics and a lack of policy that exacerbates the technical problems.
Mostly that's because people are refusing to collaborate and work
together to solve problems, preferring to build their own silos. That'll
drive contributors away and vastly increase technical debt in the long run,
which we do really need to avoid to have a healthy community.


Default modular streams shadowing non-modular packages is one such
problem, especially when they ship libraries.


My 2c.

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

Re: Modularity and all the things

[Alex Scheel]

- Original Message -
> From: "Matthew Miller" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, November 11, 2019 1:16:22 PM
> Subject: Re: Modularity and all the things
> 
> On Tue, Nov 05, 2019 at 10:28:02PM +0100, Fabio Valentini wrote:
> > That's all well and good, but you seem to be forgetting that people
> > are actually getting *paid* to work on modularity for fedora.
> > Any proposal for an alternative, which apparently needs to arrive at
> > least at MVP / proof-of-concept quality before it is even *considered*
> > as an alternative without getting called "trolling", can likely only
> > be worked on in somebody's spare time. I don't think that's a fair
> > requirement, and "exploring and contributing" will stay limited to RH
> > employees if that's the case.
> 
> Well, it really depends on the circumstance. In general, it's just practical
> reality that a proof of concept or MVP will get you a lot further than a
> suggestion -- that's not, like, a Fedora law or something.
> 
> There are certainly many examples of awesome great stuff that's been created
> in Fedora without the investment of Red Hat (or anyone's) full time
> employees. The zchunk metadata feature is a recent example. The Stewardship
> SIG is another one. This is good stuff, and I'm super-happy to support it.
> In both of those cases the people interested in that thing happening put in
> exactly the kind of effort I'm talking about here.

Hi Matthew,


While we certainly aren't numerous, Dinesh (fas: dmoluguw) and myself
(fas: cipherboy) contribute to the Stewardship SIG. Miro (fas: churchyard)
also contributes a lot. And if the load got worse, I'm sure Endi
(fas: edewata) would be willing to help.

From my organization at least, we have PM and management buy-in to
continue contributing so long as we don't have a long-term solution
that somebody else manages for us. So far, ursine packages have been
our solution and we've helped with maintaining the stack as community
members and giving back. That benefits all of Fedora.

I think we've accomplished something useful with the Stewardship SIG.


So sure, we don't work only on the Stewardship SIG... But three paid
Red Hat employees contributing in official capacities (as we have time)
should, IMO, count for something. :-)

- Alex

> 
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Will orphan packages with NEW F31FTBFS bugs tomorrow

[Alex Scheel]

- Original Message -
> From: "Vitaly Zaitsev via devel" 
> To: devel@lists.fedoraproject.org
> Cc: "Vitaly Zaitsev" 
> Sent: Friday, November 8, 2019 10:04:57 AM
> Subject: Re: Will orphan packages with NEW F31FTBFS bugs tomorrow
> 
> On 08.11.2019 13:16, Miro Hrončok wrote:
> 

~snip~

> > kf5-kactivities
> > kf5-kactivities-stats
> > kf5-kio
> 
> KF5 is not a FTBFS. Please check your scripts next time.

Just pulling a few random bugs:

- kf5-kactivities: https://bugzilla.redhat.com/show_bug.cgi?id=1735931
  needs to be closed: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=18750

- kf5-kactivities-stats: https://bugzilla.redhat.com/show_bug.cgi?id=1735932
  needs to be closed: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=22330

- kf5-kio: https://bugzilla.redhat.com/show_bug.cgi?id=1735947
  needs to be closed: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=18722

Not going to check the rest of the components, but I think Miro's
scripts work fine. It is the bugs that are out of date... ...and
if they're out of date, not much Miro's scripts can do.


Would you mind closing some of the bugs as fixed, please? :)

- Alex

> 
> --
> Sincerely,
>   Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Alex Scheel]

- Original Message -
> From: "Ralf Corsepius" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, November 6, 2019 3:32:03 AM
> Subject: Re: Modularity: The Official Complaint Thread
> 
> On 11/5/19 9:41 PM, Alex Scheel wrote:
> 
> > IMO, without a resolution in Fedora we'll never get one in RHEL.
> 
> And? Why should Fedora care about RHEL?

Why? Because Modularity was foisted the wrong direction.

In an ideal world, Modularity would've been proposed to Fedora,
it would've been discussed by the community, improved, perfected,
and _then_ brought into the RHEL fold only when stable! Fedora
would've _driven_ the innovation, rather than having to keep up
with whatever RHEL decided to do, being careful not to break
anything.

We don't live in an ideal world and deadlines, initial rejection
by Fedora, and issues implementing Modularity forced at least _some_
of it to go the other direction, RHEL -> Fedora.

So now we're stuck trying to improve Modularity in Fedora, without
stepping on any RHEL toes, and knowing full well that if the
community rejects Modularity in Fedora (again!), we're stuck supporting
it in RHEL through RHEL 8 (and, likely into RHEL 9). And I think that
worries some people, hence the attempt to influence discussions, name
calling,  Others however, want Fedora to remain fully independent
of RHEL, and thus have asked that _failure_ be an option explicitly
on the table. 

I don't work on Modularity though. I only have to use it. I'm, at
best, agnostic as to whether or not it survives in Fedora. But, I
do have to use it in RHEL. There, I'd far rather see it improve
(and, have a chance to influence improvements to issues I've directly
hit NOW rather than later). I'd hate to see it stagnate in its
current state.



> I for one consider RHEL not to be its partner, but it to be an
> initiative to gradually push Fedora out of this planet.

I think that's going a little far. They cater to two different
audiences: hackers or business people. The former will put up with
cutting-edge software and whatever documentation is freely available.
The latter will pay big money for support and consulting to make
sure nothing breaks, and to fix it if it does. 

I'd argue that if RHEL wanted to push anyone out, Fedora would be
a stupid target. RHEL doesn't really compete with Fedora. Target CentOS
first! Its RHEL, but free!

But we don't. Red Hat stepped _up_ its participation in CentOS. We
pay people to work on CentOS full-time, so it keeps going. I think
that's the _opposite_ of trying to push CentOS out of this planet.
Same goes for Fedora. And with RHEL 9, we've announced that we view
Fedora as the _upstream_ for RHEL. More collaboration, not less!

https://fedoramagazine.org/fedora-and-centos-stream/


I'd ask you to consider that we aren't Microsoft of the '90s... We
are human and make mistakes from time to time, but we aren't evil.
We're an Open Source company, and try our best to embody that. We
try our best to work _with_ the community, not against it. That's
why all of these modularity discussions _have_ been in the open and
happening right here, in Fedora. Not on some private mailing list
inside Red Hat. 


At any rate, Pierre's points are also valid.

- Alex

> 
> Ralf
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity: The Official Complaint Thread

[Alex Scheel]

- Original Message -
> From: "Kevin Kofler" 
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, November 5, 2019 7:48:47 PM
> Subject: Re: Modularity: The Official Complaint Thread
> 
> Alex Scheel wrote:
> > Special care needs to be taken to make sure we discuss what happens
> > when a _module maintainer_ wants to switch the module stream of one
> > of its dependencies, especially a dependency the user never
> > specifically selected a stream for. That should be an allowed and fully
> > supported use case.
> > 
> > This was the pki-core<->idm module fiasco that was never resolved by
> > DNF/Modularity.
> > 
> > I'd post the bug number but the bug isn't public.
> > 
> > 
> > So perhaps split this into:
> > 
> >  1. How does a _user_ change module streams during upgrade?
> >  2. How does the _maintainer_ change module streams of a dependent
> > module? (module a -dep-> module b -- change stream of b from 1 to 2)
> > 
> > 
> > IMO, without a resolution in Fedora we'll never get one in RHEL.
> 
> Indeed, in Fedora, it is quite plausible for a package to be ported to a new
> major version of a library in an update. (In RHEL, it actually also is, but
> for different reasons, i.e., its extremely long lifetime.)
> 
> But this shows how modules are the wrong answer for non-leaf packages. What
> happens if one of the packages you had installed wants to bump the module
> stream of its dependency and another one doesn't? Then suddenly, your system
> cannot be updated anymore, because the packages that previously coexisted
> just fine now irremediably conflict.
> 
> (In fact, this is just a particularly nasty special case of the more general
> design flaw of Modularity that Stephen Gallagher has unfortunately forgotten
> in his list in the original post, the version conflicts caused by versioned
> dependencies without parallel installability. The special case is that the
> conflicts can also be introduced on updates to previously non-conflicting
> packages.)
> 
> Providing incompatible versions of non-leaf packages MUST be done in a
> parallel-installable way. There is no other way out.

Since this is all public, for the rest of the audience:

 - There are three modules in question here, in core RHEL:

   1. pki-deps, an artifact of the original, broken attempt at Modularity
  in RHEL, when builds would take eons. This contains a bunch of
  dependencies of Dogtag. 
   2. pki-core, the core packages of Dogtag:
  - JSS
  - Tomcatjss
  - ldap-jdk
  - Dogtag PKI
   3. The IPA module and its "DL1" stream.

   You can pull these three modules today on RHEL and try them out if
   you want. 

 - The dependency tree is thus: 

IPA:DL1 -> pki-core:10.6 -> pki-deps:10.6

 - What we had wished to do was provide two sets of module streams:

pki-core @ 10.6 -- Dogtag at 10.6 version (in RHEL 8.0 only)
pki-core @ 10.7 -- Dogtag at 10.7 version (in RHEL 8.1 only).

   Anyone who was using pki-core by itself could stay on 10.6 if they
   so desired (by staying on RHEL 8.0) or upgrade to 10.7 (by upgrading
   to RHEL 8.1). This allowed us, in the future, to support multiple
   versions on the same RHEL version if there were breaking changes
   between them. 

   Since IPA is a monolith and wanted features in 10.7, it was going to
   switch to 10.7 in the new RHEL 8.1 release (out today!) because it
   wanted some things we introduced there.

 - Instead, since switching branches as described above wasn't supported,
   we ended up shipping our 10.7 version release in the (now incorrectly
   named) 10.6 branch. This means, on the whole, the pki-core module isn't
   netting us any value. It functions just like an ursine collection of
   packages with only a single version stream available.


So to answer your question:

> What happens if one of the packages you had installed wants to bump the
> module stream of its dependency and another one doesn't?

This was RHEL. We (the Dogtag / RHCS team at Red Hat) had full control
over our package. We could choose to ship whatever version we want. That
meant that we have to _work_ with other teams (in this case, exactly one:
IPA) and ensure what we wanted to ship wouldn't break anything. Part of
that was making sure we can switch streams. It turns out that, while we
wanted to and got sign-off from IPA, the issue was a fundamental limitation
in DNF. In RHEL, we know there is only one such dependent, IPA, and we can
deal with that.

In short, inside RHEL, we can take this as risk and control for it. In
Fedora, it is harder and would require (packaging/FESCO/Modularity/...)
policy to enforce. But it really _isn't_ a hard thing to do: limit it to
Rawhide, require changes to be announced and coordinated (like SONAME b

Re: Modularity: The Official Complaint Thread

[Alex Scheel]

- Original Message -
> From: "Stephen Gallagher" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, November 5, 2019 3:17:28 PM
> Subject: Modularity: The Official Complaint Thread

~snip~

> 1. Once enabled, a module stream is never changed on behalf of the
> user. While this adds some strong guarantees to those who want to run
> applications built from those streams, the presence of default streams
> changes the expected upgrade behavior for users. Traditionally, at
> upgrade a user would get the new release's most-updated version of all
> packages currently on their system. With Modularity, if one of their
> packages comes from a default stream and that stream is not the
> default for the next release, they will stay on the current stream (or
> be blocked from upgrading, if the current stream is unavailable on the
> next release). [2]

Special care needs to be taken to make sure we discuss what happens
when a _module maintainer_ wants to switch the module stream of one
of its dependencies, especially a dependency the user never
specifically selected a stream for. That should be an allowed and fully
supported use case.

This was the pki-core<->idm module fiasco that was never resolved by
DNF/Modularity.

I'd post the bug number but the bug isn't public.


So perhaps split this into: 

 1. How does a _user_ change module streams during upgrade?
 2. How does the _maintainer_ change module streams of a dependent
module? (module a -dep-> module b -- change stream of b from 1 to 2)


IMO, without a resolution in Fedora we'll never get one in RHEL.

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

Re: Java Package Orphanings

[Alex Scheel]

The deed has been done. 

- A

- Original Message -
> From: "Alex Scheel" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, October 30, 2019 9:21:35 AM
> Subject: Java Package Orphanings
> 
> All,
> 
> In the process of unorphaning resteasy, I picked up several other
> packages necessary to keep it alive. After trimming resteasy
> down, I was left with the following packages.
> 
>  - classmate (cc: lef)
>  - cli-parser (cc: lef)
>  - glassfish-gmbal
>  - glassfish-management-api
>  - glassifsh-pfl
>  - grizzly
>  - grizzly-npn
>  - jackson-dataformat-xml (cc: lef, dchen)
>  - jandex-maven-plugin (cc: lef)
>  - java-oauth (cc: lef)
>  - jboss-connector-1.6-api (cc: lef, gil)
>  - jboss-jaspi-1.1-api (cc: lef)
>  - jersey (cc: dchen, gwei3)
>  - mimepull (cc: lef, java-sig)
>  - mustache-java (cc: dchen, lef, mizdebsk)
>  - netty3 (cc: lef, jerboaa)
>  - picketbox (cc: lef, gil)
>  - picketbox-commons (cc: lef, gil)
>  - picketbox-xacml (cc: lef, gil)
>  - rxjava (cc: rfenkhuber)
>  - simple
> 
> I intend to orphan them all on Friday unless someone else
> wants these packages.
> 
> 
> Thanks,
> 
> - Alex
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Java Package Orphanings

[Alex Scheel]

All,

In the process of unorphaning resteasy, I picked up several other
packages necessary to keep it alive. After trimming resteasy
down, I was left with the following packages.

 - classmate (cc: lef)
 - cli-parser (cc: lef)
 - glassfish-gmbal
 - glassfish-management-api
 - glassifsh-pfl 
 - grizzly 
 - grizzly-npn
 - jackson-dataformat-xml (cc: lef, dchen)
 - jandex-maven-plugin (cc: lef)
 - java-oauth (cc: lef)
 - jboss-connector-1.6-api (cc: lef, gil)
 - jboss-jaspi-1.1-api (cc: lef)
 - jersey (cc: dchen, gwei3)
 - mimepull (cc: lef, java-sig)
 - mustache-java (cc: dchen, lef, mizdebsk)
 - netty3 (cc: lef, jerboaa)
 - picketbox (cc: lef, gil)
 - picketbox-commons (cc: lef, gil)
 - picketbox-xacml (cc: lef, gil)
 - rxjava (cc: rfenkhuber)
 - simple

I intend to orphan them all on Friday unless someone else
wants these packages.


Thanks,

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

Re: Switching Maven and Ant to OpenJDK 11

[Alex Scheel]

- Original Message -
> From: "Mikolaj Izdebski" 
> To: "java-devel" 
> Cc: maven-ow...@fedoraproject.org, "ant-owner" , 
> mbo...@fedoraproject.org
> Sent: Friday, October 25, 2019 1:30:32 PM
> Subject: Switching Maven and Ant to OpenJDK 11
> 
> Hello,
> 
> Currently default Java runtime in Fedora is OpenJDK 8. This is not the
> latest OpenJDK packaged, but still remains system-default version.
> Because of that Apache Maven and Apache Ant in Fedora are built using
> OpenJDK 8 and run on OpenJDK 8.
> 
> I am planning to switch Maven 3.6 and Ant 1.10 modules to build with
> and run on OpenJDK 11, which is the latest LTS release of OpenJDK.
> This also means that future streams of javapackages-tools module will
> default to use OpenJDK 11 for building packages. Please let me know if
> you have any concerns.

My concern is what will happen to the libraries in the default module
stream? When installing, e.g., dogtag-pki, this brings in the following
packages from a default module stream:

apache-commons-cli-0:1.4-4.module_f28+3939+dc18cd75.noarch
apache-commons-codec-0:1.11-3.module_f28+3939+dc18cd75.noarch
apache-commons-io-1:2.6-3.module_f28+3939+dc18cd75.noarch
apache-commons-logging-0:1.2-13.module_f28+3939+dc18cd75.noarch
httpcomponents-client-0:4.5.5-4.module_f28+3939+dc18cd75.noarch
httpcomponents-core-0:4.4.10-3.module_f28+3939+dc18cd75.noarch

Of these, apache-commons-{cli,codec,io,logging} are all directly required
by dogtag-pki, which doesn't yet fully work with JDK-11. (I'm not quite
sure how httpcomponents-{client,core} gets pulled in).


Will you continue building these with a target bytecode version for use
with JDK8, even though you're building with JDK11? Or are you only building
the maven and ant packages with JDK 11 (and not building all libraries
in the module with JDK 11)?


Thanks,

- Alex 


> 
> --
> Mikolaj Izdebski
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org