date:20200330

On Mon, Mar 30, 2020 at 4:55 PM Till Maas  wrote:
>
> Please be more specific. Are these the requirements from the discussion
> different ones? The discussion had 47 requirements, 1 and 2 were
> challenged and 47 mentioned as nice-to-have. Who submitted them? I guess
> it was Ben.
>
Yes, I sent Aoife the user stories after they were discussed on the
council-discuss thread[1]. The original version had 47. One was added,
two were removed, and a few were edited to get the final count.

[1] 
https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re : kinit: Password incorrect while getting initial credentials

2020-03-30 Thread Paul Dufresne via devel

Thanks to the person who suggested to change password in the web interface (at 
least once, rather than changing by forgotten password).

I did the trick and now kinit works!___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

Hi,

On Mon, Mar 30, 2020 at 11:28:59AM +0100, Leigh Griffin wrote:

> No singular Forge satisfied every single User Story. Any feature gaps will
> land on the Backlog of Gitlab for voting and prioritisation as their
> Engineering teams see fit.

this sounds very disturbing. Please clarify this. Fedora needs a
dist-git repo with certain features/workflows that might not make sense
for a generic git forge or in other words: A git forge might just be a
part of the solution that Fedora needs for dist-git. Does this mean that
the CPE team will implement the missing features that are not part of a
gitforge and therefore no priority for Gitlab? Or will Fedora just get a
gitforge and need to figure out how to be able to implement their
workflows with it?

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

Re: CPE Git Forge Decision

Hi,

On Mon, Mar 30, 2020 at 02:40:13PM +, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 3:26 PM Till Maas  wrote:
> 
> > Hi,
> >
> > On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas  wrote:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
> > > >
> > > > > For transparency, we have published the full User Story list which is
> > > > > linked within the blog and for ease of searching is here:
> > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> > > >
> > > > the user stories list does not seem to include the original user
> > stories
> > > > that I submitted regarding package life-cycle and permission
> > management.
> > > > These are requirements for dist-git but not necessarily for a
> > git-forge.
> > > > In the past they were fulfilled by package db, now pagure is solving
> > > > this more.
> > >
> > >
> > > We received a summarised User Story list from the Fedora Council, I would
> > > suggest reaching out with your concerns.
> >
> > What is the list that you got. The list on the council discuss list
> > contained these items, for example for FESCo members, proven packagers
> > and dist-git repo admins:
> >
> > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> 
> 
> We received a Google Doc with the summation of the 44 requirements from
> Fedora Council.

Please be more specific. Are these the requirements from the discussion
different ones? The discussion had 47 requirements, 1 and 2 were
challenged and 47 mentioned as nice-to-have. Who submitted them? I guess
it was Ben.

> > In the hackmd story list, there are is only infosec, RH Legal Rep, RH
> > Infocsec Rep, RH Developer, RHEL engineer and general users, project
> > contributor, CPE team member. Nothing really maps to the user groups I
> > mentioned.
> 
> 
> As mentioned, we rolled in stories together and General Users /
> contributors map to the majority of the Fedora projects requirements
> (similar for CentOS) and a lot of individual stakeholder requirements ended
> up in the general bucket.
> 
> 
> > There is only
> >
> > | 41
> > | As a General User
> > | I want groups and group membership and management
> > | to allow me create access control on a suite of repositories
> >
> > but this is very vague.
> >
> 
> The User Stories are deliberately vague and that represents around 10
> unique requirements that boil down to having group membership and
> management capabilities.

IMHO the problem with this vague requirement is that it probably fits
every gitforge. But for Fedora, the package management aspects are more
important than generic gitforge capabilities that any gitforge can
provide.

> > Also there seems to be nothing about orphaning/adopting/retiring
> > packages, not even in a vague way.
> >
> 
> We have stories relating to specific workflow requirements (from multiple
> stakeholders including RHEL, CentOS and Fedora) for dist-git. We have
> represented a requirement (number 18 on the list) about viewing orphaned
> packages. The requirements received around this process were very much
> aligned with permissions and visibility to allow actions. They are covered
> through other User Stories and what I feel needs to be made clear, we are
> presenting the amalgamated list and as a team we read every single User
> Story that came in and processed them accordingly in making this decision.

From the experience with the migration from Packagedb to pagure, the
specific requirements for Fedora seem to require more effort than just
providing generic gitforge capabilities. For example, the adopting an
orphaned package process needs to be a self service instead of a manual
process for release engineering. And the requirements seem to be so
vague that providing GIT repos with config files for workflows appears
as a valid solution but there should be a proper user interface.

Adapting a git forge to properly provide the workflow for Fedora
dist-git seems to me to be one of the major tasks, so assessing whether
a gitforge simplifies this seems to me to be rather important to make an
informed decision.

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

Re: Odd build failure on Fedora 32

2020-03-30 Thread Jonathan Wakely


On 29/03/20 11:31 -0700, Luya Tshimbalanga wrote:

Hello team,

Can someone investigate the failure on Fedora 32 YafaRay? It seems 
related to boost [2].


It's a GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94190

It's fixed in this GCC update which has been submitted for testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b2de059578
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Compilation Error on F32

2020-03-30 Thread Jonathan Wakely


On 30/03/20 11:34 -0600, Nathanael D. Noblet wrote:

Hello,

 I have a project that isn't part of Fedora yet - though really I
should add it at this point. Its php-cpp. It allows me to write c++
extensions for PHP. Its worked well for a couple years. I upgraded to
F32 beta and now when compiling anything that includes its headers
compilation fails and I'm not entirely sure why.

g++ -MT pdf-image.o -MMD -MP -MF .d/pdf-image.Td -Wall -g -c -O2
-std=c++11 -fPIC `pkg-config poppler-cpp fontconfig openssl --
cflags`-DVERSION=\"0.11.16\"  -c -o pdf-image.o pdf-image.cpp
In file included from /usr/include/phpcpp.h:38,
from pdf-image.cpp:8:
/usr/include/phpcpp/throwable.h:29:1: error: expected class-name before
‘{’ token


It's telling you the token before the opening brace is not a
class-name. Look at the token. See why GCC thinks it's not a
class-name. The most likely reason is it's not been declared (which is
exactly what Jakub confirmed, the laborious way of actually checking
the preprocessed source).


I've attached the header. Any gcc experts out there able to tell me
what's wrong with the header format that used to compile but no longer
does?


It's not a GCC question, it's a C++ one. You didn't include the
header for something you're using.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Compilation Error on F32

2020-03-30 Thread Jonathan Wakely

On 30/03/20 20:55 +0200, Jakub Jelinek wrote:

On Mon, Mar 30, 2020 at 07:50:48PM +0200, Jakub Jelinek wrote:

On Mon, Mar 30, 2020 at 11:34:15AM -0600, Nathanael D. Noblet wrote:
>   I have a project that isn't part of Fedora yet - though really I
> should add it at this point. Its php-cpp. It allows me to write c++
> extensions for PHP. Its worked well for a couple years. I upgraded to
> F32 beta and now when compiling anything that includes its headers
> compilation fails and I'm not entirely sure why.
>
> g++ -MT pdf-image.o -MMD -MP -MF .d/pdf-image.Td -Wall -g -c -O2
> -std=c++11 -fPIC `pkg-config poppler-cpp fontconfig openssl --
> cflags`-DVERSION=\"0.11.16\"  -c -o pdf-image.o pdf-image.cpp
> In file included from /usr/include/phpcpp.h:38,
>  from pdf-image.cpp:8:
> /usr/include/phpcpp/throwable.h:29:1: error: expected class-name before
> ‘{’ token
>
> I've attached the header. Any gcc experts out there able to tell me
> what's wrong with the header format that used to compile but no longer
> does?

Please mail me a preprocessed source instead (e.g. rerun the g++ command
line with -save-temps option and mail pdf-image.ii the compiler creates,
or drop -M* options and their arguments, change -c to -E and pdf-image.o
to pdf-image.ii).

So, from the offlist posted preprocessed source, seems the TU includes the
following libstdc++ headers
#include 
#include 
#include 
#include 
#include 
#include 
#include 
and then uses std::runtime_exception.  That one is defined in 
header though, and is not included.  Before
https://gcc.gnu.org/legacy-ml/libstdc++/2019-06/msg00032.html
change it has been included as implementation detail from headers included
in ,  or  from the above list.
So, you just need to make sure  is also included if you need
classes from it.

Which is documented in the (incomplete) release info for gcc-10:
https://gcc.gnu.org/gcc-10/porting_to.html#header-dep-changes
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Compilation Error on F32

On Mon, 2020-03-30 at 13:47 -0600, Nathanael D. Noblet wrote:
> Thank you for looking into this for me. Just to be clear, the proper
> place to fix this is in the php-cpp project because it is using
> std::runtime_exception without including . Is that
> correct?

Aaaand I just tried it and it works so thanks again!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: kinit: Password incorrect while getting initial credentials

On Mon, Mar 30, 2020 at 10:36:46PM +0300, Benson Muite wrote:
> 
> 
> On Mon, Mar 30, 2020, at 8:57 PM, Paul Dufresne via devel wrote:
> > I am trying to follow instructions at:
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> > 
> > But when I do:
> > [paul@localhost ~]$ kinit pa...@fedoraproject.org
> > I get:
> > Password for pa...@fedoraproject.org: 
> > kinit: Password incorrect while getting initial credentials
> > [paul@localhost ~]$ 
> > 
> > Is it because I did not done the Introduce yourself part and that I
> > need an administrator to activate my account?
> > 
> > I use my FAS account password, and it works for other services.
> 
> Had a similar problem when trying to push a build to Koji.

There's no activation, other than having an account and setting your
password at least once (via the actual change password option on the fas
page for your account, NOT via 'forgot password')

Can you open a infra ticket and attach: 

KRB5_TRACE=/dev/stdout kinit pa...@fedoraproject.org

Also see: 

https://fedoraproject.org/wiki/Infrastructure/Kerberos#Debugging_problems

kevin


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

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

- 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: Orphaned packages looking for new maintainers

2020-03-30 Thread Emmanuel Seyman

* Scott Talbert [30/03/2020 14:38] :
>
> Because the maintainer (normunds) was non-responsive.  I don't see any
> commits from you??

Sorry, I was looking at perl-Data-Validate-Type, not at
perl-Data-Validate-Domain.

I've taken the package.

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

On Mon, 2020-03-30 at 20:55 +0200, Jakub Jelinek wrote:
> So, from the offlist posted preprocessed source, seems the TU
> includes the
> following libstdc++ headers
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> and then uses std::runtime_exception.  That one is defined in
> 
> header though, and is not included.  Before
> https://gcc.gnu.org/legacy-ml/libstdc++/2019-06/msg00032.html
> change it has been included as implementation detail from headers
> included
> in ,  or  from the above list.
> So, you just need to make sure  is also included if you
> need
> classes from it.
> 

Thank you for looking into this for me. Just to be clear, the proper
place to fix this is in the php-cpp project because it is using
std::runtime_exception without including . Is that correct?

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

On Mon, Mar 30, 2020 at 08:10:30PM +0200, Miro Hrončok wrote:
> On 30. 03. 20 18:35, Kevin Fenzi wrote:
> > On Mon, Mar 30, 2020 at 01:13:03PM +0200, Miro Hrončok wrote:
> > > 
> > > I'm afraid that this won't be good enough. Other (Fedora) builds will be
> > > submitted with lower prio as well. For example our Python 3.N+1 rebuilds 
> > > are
> > > usually submitted as such, so the wave of 3k packages doesn't block
> > > individual packagers. So unless Koji has multiple levels of priorities, I
> > 
> > It does.
> > 
> >  priority: the amount to increase (or decrease) the task priority, 
> > relative
> >to the default priority; higher values mean lower 
> > priority; only
> >admins have the right to specify a negative priority here
> > 
> > It's basically an integer.
> > createrepos/newRepo are 14
> > releng runroot jobs are 15
> > 'normal' builds are around 19
> > 'scratch' builds are around 20
> > backgrounds is 25
> > koschei sets it's builds to 50
> 
> Oh! Great. In that case, I think we can solve this somehow if needed.
> 
> How can I submit a build with a different number? Becasue neither fedpkg
> build --help nor koji build --help seem to talk about this.

There's koji set-task-priority, which should work. 

I don't see a way to set it on build submit... 

kevin


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

Re: kinit: Password incorrect while getting initial credentials

2020-03-30 Thread Benson Muite

On Mon, Mar 30, 2020, at 8:57 PM, Paul Dufresne via devel wrote:
> I am trying to follow instructions at:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> 
> But when I do:
> [paul@localhost ~]$ kinit pa...@fedoraproject.org
> I get:
> Password for pa...@fedoraproject.org: 
> kinit: Password incorrect while getting initial credentials
> [paul@localhost ~]$ 
> 
> Is it because I did not done the Introduce yourself part and that I
> need an administrator to activate my account?
> 
> I use my FAS account password, and it works for other services.

Had a similar problem when trying to push a build to Koji.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

2020-03-30 Thread Bruno Wolff III


On Mon, Mar 30, 2020 at 15:30:20 -0400,
 Neal Gompa  wrote:


I barely remember plague (it was going away when I started as a
packager). Plague was free software, but the build system for Fedora
Core was not. That and Plague were both replaced with Koji in 2007. It
was a great day, indeed.


Thanks for the correction, as it was a long time ago and apparently either 
misremembered or confused plague with the proprietary part long ago.

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

kinit: Password incorrect while getting initial credentials

2020-03-30 Thread Paul Dufresne via devel

I am trying to follow instructions at:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

But when I do:
[paul@localhost ~]$ kinit pa...@fedoraproject.org
I get:
Password for pa...@fedoraproject.org: 
kinit: Password incorrect while getting initial credentials
[paul@localhost ~]$ 

Is it because I did not done the Introduce yourself part and that I
need an administrator to activate my account?

I use my FAS account password, and it works for other services.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

On Mon, Mar 30, 2020 at 3:26 PM Bruno Wolff III  wrote:
>
> On Mon, Mar 30, 2020 at 14:42:33 -0400,
>   Alex Scheel  wrote:
> >
> >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.
>
> I've used the PR features a bit in a dist-git context. I tried to see if
> we could use it for my group at work, but somebody had already set up
> gitlab for another group and we ended up re-using their work instead.
>
> >The reasons why are well documented in Pagure's issue tracker.
>
> I have contributed to the the issue list, but not for a while.
>
> >If that's something you value, feel free to contribute to Pagure upstream.
>
> It's hard for me to keep up with packing now, so it is hard to do much more
> than report issues and test fixes.
>
> >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.
>
> Perhaps. SourceHut does look like it is really free. I'd be a little
> worried about something happening to the founder if I was reliant on
> them for improvements. Gitea also seems to be really free and seems
> to be community based. I don't know how well either works or how
> sustainable their development is. But they do seem to be alternatives
> that are really free, unlike gitlab.
>

SourceHut eschews common norms for forge-based development in favor of
email based workflows. I don't think anyone here is keen on that. :)

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.

> >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 think it is a project that is valuable for Red Hat to sponsor, but
> apparently the decision makers there don't think so.
>
> I'm still disapointed in this decision. One of the reasons I got involved
> with Fedora instead of other distributions way back, was that they were
> working on getting rid of plague and replacing it with free software.
> (It was gone by the time I was a packager, so I never used it.)

I barely remember plague (it was going away when I started as a
packager). Plague was free software, but the build system for Fedora
Core was not. That and Plague were both replaced with Koji in 2007. It
was a great day, indeed.


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

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

2020-03-30 Thread Bruno Wolff III


On Mon, Mar 30, 2020 at 14:42:33 -0400,
 Alex Scheel  wrote:


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.


I've used the PR features a bit in a dist-git context. I tried to see if 
we could use it for my group at work, but somebody had already set up 
gitlab for another group and we ended up re-using their work instead.



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


I have contributed to the the issue list, but not for a while.


If that's something you value, feel free to contribute to Pagure upstream.


It's hard for me to keep up with packing now, so it is hard to do much more 
than report issues and test fixes.



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.


Perhaps. SourceHut does look like it is really free. I'd be a little 
worried about something happening to the founder if I was reliant on 
them for improvements. Gitea also seems to be really free and seems 
to be community based. I don't know how well either works or how 
sustainable their development is. But they do seem to be alternatives 
that are really free, unlike gitlab.



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 think it is a project that is valuable for Red Hat to sponsor, but 
apparently the decision makers there don't think so.


I'm still disapointed in this decision. One of the reasons I got involved 
with Fedora instead of other distributions way back, was that they were 
working on getting rid of plague and replacing it with free software. 
(It was gone by the time I was a packager, so I never used it.)

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

- 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)

2020-03-30 Thread Martin Kolman



- Original Message -
> From: "Alex Scheel" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Leigh Griffin" 
> Sent: Monday, March 30, 2020 8:42:33 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
> 
> - 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).
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.

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

2020-03-30 Thread Simo Sorce

On Mon, 2020-03-30 at 17:41 +0200, Pavel Raiskup wrote:
> On Monday, March 30, 2020 11:17:21 AM CEST Leigh Griffin wrote:
> > Thank you for your patience while the CPE Team worked through an incredible
> > number of requirements from multiple stakeholder sources. On Friday evening
> > we announced on the Community Blog
> >  our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > ultimately hand over to the Community to maintain. It wasn't an easy
> > decision by any stretch of the imagination and we hope that the compromise
> > that we are striking will help to allow Pagure flourish and to give a
> > choice of Forges for your usage. I'm happy to field any questions or
> > comments about this decision.
> 
> Is there some tool to automatically migrate PRs->MRs and issues?
> 
> The only problem of GitLab is that Fedora - for years - was not able to
> package it.  I'm not a able to judge where the packaging problem is/was,
> any more info?  Are we going invest into packaging it?
> 
> Please make us 100% confident we are not going to be locked-in.  If we
> aren't able to package it reasonably well, it means that we have no option
> to decide to self-host GitLab in future.

If you carefully read between the lines you'd find there is no
intention of hosting or anything, we are locking ourselves into gitlab
and the benevolence of the the gitlab company, and they ability to
survive. When they will go away we'll be left with the pieces. But then
it will be some future people that will have to deal with it. Good
luck.

/me absolutely not happy with the way this affair has been handled.

-- 
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: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Compilation Error on F32

2020-03-30 Thread Jakub Jelinek

On Mon, Mar 30, 2020 at 07:50:48PM +0200, Jakub Jelinek wrote:
> On Mon, Mar 30, 2020 at 11:34:15AM -0600, Nathanael D. Noblet wrote:
> >   I have a project that isn't part of Fedora yet - though really I
> > should add it at this point. Its php-cpp. It allows me to write c++
> > extensions for PHP. Its worked well for a couple years. I upgraded to
> > F32 beta and now when compiling anything that includes its headers
> > compilation fails and I'm not entirely sure why. 
> > 
> > g++ -MT pdf-image.o -MMD -MP -MF .d/pdf-image.Td -Wall -g -c -O2
> > -std=c++11 -fPIC `pkg-config poppler-cpp fontconfig openssl --
> > cflags`-DVERSION=\"0.11.16\"  -c -o pdf-image.o pdf-image.cpp
> > In file included from /usr/include/phpcpp.h:38,
> >  from pdf-image.cpp:8:
> > /usr/include/phpcpp/throwable.h:29:1: error: expected class-name before
> > ‘{’ token
> > 
> > I've attached the header. Any gcc experts out there able to tell me
> > what's wrong with the header format that used to compile but no longer
> > does?
> 
> Please mail me a preprocessed source instead (e.g. rerun the g++ command
> line with -save-temps option and mail pdf-image.ii the compiler creates,
> or drop -M* options and their arguments, change -c to -E and pdf-image.o
> to pdf-image.ii).

So, from the offlist posted preprocessed source, seems the TU includes the
following libstdc++ headers
#include 
#include 
#include 
#include 
#include 
#include 
#include 
and then uses std::runtime_exception.  That one is defined in 
header though, and is not included.  Before
https://gcc.gnu.org/legacy-ml/libstdc++/2019-06/msg00032.html
change it has been included as implementation detail from headers included
in ,  or  from the above list.
So, you just need to make sure  is also included if you need
classes from it.

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

- 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: Orphaned packages looking for new maintainers

2020-03-30 Thread Erich Eickmeyer


On 3/30/20 11:38 AM, Scott Talbert wrote:
> On Mon, 30 Mar 2020, Emmanuel Seyman wrote:
>
>> * Miro Hrončok [30/03/2020 20:24] :
>>>
>>> perl-Data-Validate-Domain orphan   1
>>> weeks ago
>>
>> I've maintained this package for years now. Why is it considered it
>> orphaned?
>
> Because the maintainer (normunds) was non-responsive.  I don't see any
> commits from you??
>
> https://src.fedoraproject.org/rpms/perl-Data-Validate-Domain/commits/master
>
I just took lv2-ll-plugins, but it looks dead upstream. If it starts to
ftbfs, I'll likely just retire it.

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

2020-03-30 Thread Scott Talbert


On Mon, 30 Mar 2020, Emmanuel Seyman wrote:


* Miro Hrončok [30/03/2020 20:24] :


perl-Data-Validate-Domain orphan   1 weeks ago


I've maintained this package for years now. Why is it considered it orphaned?


Because the maintainer (normunds) was non-responsive.  I don't see any 
commits from you??


https://src.fedoraproject.org/rpms/perl-Data-Validate-Domain/commits/master___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaned packages looking for new maintainers

2020-03-30 Thread Andrew Bauer

perl-Net-SFTP-Foreign has been taken!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Orphaned packages looking for new maintainers

2020-03-30 Thread Emmanuel Seyman

* Miro Hrončok [30/03/2020 20:24] :
>
> perl-Data-Validate-Domain orphan   1 weeks ago

I've maintained this package for years now. Why is it considered it orphaned?

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

2020-03-30 Thread Bruno Wolff III


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.)


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

Re: Coronavirus: Fedora RTC solutions and YOU


On Mon, 2020-03-30 at 14:09 -0400, Neal Becker wrote:
> Sérgio Basto wrote:
> 
> Before jumping into jitsi, I think you should see what I got when I
> tried it 
> using the web app.
> 
> Why does it want access to my youtube??

I've used Jitsi without an account at all for over a year (at least the
one at meet.jit.si - so my guess is that is a configuration option?


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

Orphaned packages looking for new maintainers


The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-03-30.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

aalto-xml java-sig, orphan 4 weeks ago
apache-commons-jexl   mizdebsk, orphan 6 weeks ago
appframework  orphan   6 weeks ago
bean-validation-api   orphan   6 weeks ago
biboumi   jcline, orphan   0 weeks ago
clang8.0  orphan, sergesanspaille, 6 weeks ago
  tstellar
compress-lzf  orphan   4 weeks ago
containersorphan   1 weeks ago
cpptasks  orphan   3 weeks ago
cuneiform orphan   6 weeks ago
disruptor-thrift-server   orphan   4 weeks ago
dspam gnat, orphan 5 weeks ago
erlang-fs orphan   5 weeks ago
fluxcapacitor orphan, suve 5 weeks ago
freemarkerorphan   6 weeks ago
geronimo-jta  mizdebsk, orphan 6 weeks ago
glade3dridi, nonamedotc, orphan,   4 weeks ago
  rakesh
gnome-shell-extension-orphan   6 weeks ago
taskwarrior
insectfnux, orphan 2 weeks ago
jacocojvanek, kdaniel, lef, orphan 5 weeks ago
javapoet  orphan   4 weeks ago
jboss-marshalling mizdebsk, orphan 4 weeks ago
jetty-alpn-apimizdebsk, orphan 4 weeks ago
jetty-build-support   mizdebsk, orphan 3 weeks ago
jetty-toolchain   mizdebsk, orphan 1 weeks ago
jmol  jussilehtola, orphan 6 weeks ago
js-jquery-jstree  orphan   5 weeks ago
js-jquery-notyorphan   5 weeks ago
jspecview jussilehtola, orphan 6 weeks ago
jsr-311   mizdebsk, orphan 6 weeks ago
laszipdevrim, orphan   3 weeks ago
libdivecomputer-subsurfaceorphan, rdieter  5 weeks ago
liblasdevrim, orphan   3 weeks ago
llvm8.0   orphan, sergesanspaille, 6 weeks ago
  tstellar
lv2-ll-pluginsorphan   3 weeks ago
lz4-java  orphan   4 weeks ago
lzma-java orphan   4 weeks ago
maven-injection-pluginmizdebsk, orphan 3 weeks ago
maven-mapping mizdebsk, orphan 3 weeks ago
mongo-java-driver jerboaa, lef, mskalick, orphan   5 weeks ago
mvel  orphan   3 weeks ago
naga  jussilehtola, orphan 6 weeks ago
nekobee-dssi  orphan   3 weeks ago
netty mizdebsk, orphan 5 weeks ago
nimbus-jose-jwt   orphan   4 weeks ago
nodejs-grunt-wrap orphan   5 weeks ago
nodejs-historic-readline  orphan   2 weeks ago
nodejs-typeahead.js   dcallagh, orphan, vjancik6 weeks ago
objectweb-asm3dwalluck, fnasser, mizdebsk,

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

2020-03-30 Thread clime

I thought CPE ("Community Platform Engineering") is a part of the
community. But no, because you want to hand over pagure.io to "the
Community", so what community is that...People that don't have
hardware?

It seems that the whole proposal is trying to make src.fp.o and
git.centos.org part of a corporate solution and therefore eat a huge
part of Fedora & CentOS ecosystems and of their independence.

Do you realize how valuable the Fedora upstream is for RHEL?

The thing that I am saying is suggested by points like:

> 5
> As a RH Developer
> I need the ability to privately comment on a PR
> so that confidential information does not leak outside Red Hat

> 8
> As a RHEL engineer
> I want a modern git workflow
> So that I can use upstream practices in RHEL development for quicker delivery 
> of features & fixes

Taking points like this into account for Fedora dist-git only makes
sense if RHEL development would take place directly on src.fp.o. But
that's not the case. We have community upstream and then there is RHEL
that further uses and processes the upstream work. While there is some
overlap in people, these are still two separate software development
domains.

Your suggestion is: "Let's break everything." Do you know how many
existing integrations with pagure there are? Do you know how much time
and also emotions was put into building it? Do you say all that work
was useless? It's not only about technology but it's also about how
many people connected on it with a vision to build something good. And
by trying to overcome the feature gap, this can continue.

Fedora is a community Linux distribution with people that want to work
together on something, it's not just some dumb package factory.

Do you want a community help on pagure? Ask for it but not by handing
it a project that RH does not want to maintain anymore but instead try
first to describe the feature gap we are missing and see if it can be
overcome by a collective effort. It's better than rushing into a
decision which is breaking an extreme amount of stuff and which might
put into grave a good reusable technology that we have and that we
could also offer to other people and other communities for free so
that open-source can thrive.

Fedora dist-git is using pagure, CentOS dist-git is using pagure so
both these parties are, in my opinion, okay with it already. Let's
build on something we already have instead of destroying it over and
over again. Only this is a way for Fedora community to be a leading
party in the open-source and free software, which it should be.

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


On 30. 03. 20 18:35, Kevin Fenzi wrote:

On Mon, Mar 30, 2020 at 01:13:03PM +0200, Miro Hrončok wrote:


I'm afraid that this won't be good enough. Other (Fedora) builds will be
submitted with lower prio as well. For example our Python 3.N+1 rebuilds are
usually submitted as such, so the wave of 3k packages doesn't block
individual packagers. So unless Koji has multiple levels of priorities, I


It does.

 priority: the amount to increase (or decrease) the task priority, 
relative
   to the default priority; higher values mean lower priority; 
only
   admins have the right to specify a negative priority here

It's basically an integer.
createrepos/newRepo are 14
releng runroot jobs are 15
'normal' builds are around 19
'scratch' builds are around 20
backgrounds is 25
koschei sets it's builds to 50


Oh! Great. In that case, I think we can solve this somehow if needed.

How can I submit a build with a different number? Becasue neither fedpkg build 
--help nor koji build --help seem to talk about this.


--
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

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


On 30. 03. 20 17:55, David Kaufmann wrote:

What I don't understand is, why a decision this big is not taken by
FESCo (or Council) and the CentOS Governing Board itself.


FESCo cannot actually make anyone do anything. So even if FESCo says: "The 
dist-git will run on Pagure", CPE can say: "Whatever, but we are not maintaining 
it."


Not sure what would be the result of such situation, but I am pretty sure it 
would not be very nice.



That said, completely ignoring FESCo during this entire process strikes me as 
odd as well.


--
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

Re: Coronavirus: Fedora RTC solutions and YOU

2020-03-30 Thread Christopher Engelhard

On 30.03.20 19:35, Nathanael D. Noblet wrote:
> On Mon, 2020-03-30 at 18:09 +0200, Dario Lesca wrote:
>> Il giorno sab, 28/03/2020 alle 15.13 +, Sérgio Basto ha scritto:
>>> I will try packaging all Jitsi Meet suite [1] 
> 
> Me too, I've been watching that suite of tools and would love to be a
> little involved as potentially a co-maintainer but definitely a
> tester...

Same here. I don't have much experience with Java, but if I can help
with packaging in any way, let me know.

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


On 27. 03. 20 16:07, Stephen Gallagher wrote:

Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].


Assume I have the following CI Test in Fedora:

https://src.fedoraproject.org/rpms/python-setuptools/blob/master/f/tests/tests.yml

Yet in ELN, there will be no Python 3.4 or 3.5. How do I make this section work:

required_packages:
- gcc
- virtualenv
- python27
- python34
- python35
- python36
- python37
- python38
- python39
- python3-devel
- python3-tox
- mock
- rpmdevtools
- rpm-build

AFAIK there are no conditionals possible here, or are they?

One obvious solution is "ELN will inherit from rawhide, forever" but in that 
case how do I actually know whether I'm testing ELN or rawhide?


Another solution is to build all packages dragged liek this in ELN, even the 
stuff we don't intent to have in RHEL (ever). But given the state of the 
dependency graph in Fedora, that might eventually mean we need to build (close 
to) everything.


(I'm not arguing here against the change, I am actually asking how is this going 
to work.)

--
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

Re: Compilation Error on F32

2020-03-30 Thread Jakub Jelinek

On Mon, Mar 30, 2020 at 11:34:15AM -0600, Nathanael D. Noblet wrote:
>   I have a project that isn't part of Fedora yet - though really I
> should add it at this point. Its php-cpp. It allows me to write c++
> extensions for PHP. Its worked well for a couple years. I upgraded to
> F32 beta and now when compiling anything that includes its headers
> compilation fails and I'm not entirely sure why. 
> 
> g++ -MT pdf-image.o -MMD -MP -MF .d/pdf-image.Td -Wall -g -c -O2
> -std=c++11 -fPIC `pkg-config poppler-cpp fontconfig openssl --
> cflags`-DVERSION=\"0.11.16\"  -c -o pdf-image.o pdf-image.cpp
> In file included from /usr/include/phpcpp.h:38,
>  from pdf-image.cpp:8:
> /usr/include/phpcpp/throwable.h:29:1: error: expected class-name before
> ‘{’ token
> 
> I've attached the header. Any gcc experts out there able to tell me
> what's wrong with the header format that used to compile but no longer
> does?

Please mail me a preprocessed source instead (e.g. rerun the g++ command
line with -save-temps option and mail pdf-image.ii the compiler creates,
or drop -M* options and their arguments, change -c to -E and pdf-image.o
to pdf-image.ii).

Thanks.

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

On Mon, 2020-03-30 at 18:09 +0200, Dario Lesca wrote:
> Il giorno sab, 28/03/2020 alle 15.13 +, Sérgio Basto ha scritto:
> > I will try packaging all Jitsi Meet suite [1] 

Me too, I've been watching that suite of tools and would love to be a
little involved as potentially a co-maintainer but definitely a
tester...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Compilation Error on F32

Hello,

  I have a project that isn't part of Fedora yet - though really I
should add it at this point. Its php-cpp. It allows me to write c++
extensions for PHP. Its worked well for a couple years. I upgraded to
F32 beta and now when compiling anything that includes its headers
compilation fails and I'm not entirely sure why. 

g++ -MT pdf-image.o -MMD -MP -MF .d/pdf-image.Td -Wall -g -c -O2
-std=c++11 -fPIC `pkg-config poppler-cpp fontconfig openssl --
cflags`-DVERSION=\"0.11.16\"  -c -o pdf-image.o pdf-image.cpp
In file included from /usr/include/phpcpp.h:38,
 from pdf-image.cpp:8:
/usr/include/phpcpp/throwable.h:29:1: error: expected class-name before
‘{’ token

I've attached the header. Any gcc experts out there able to tell me
what's wrong with the header format that used to compile but no longer
does?

In case it is relevant PHPCPP_EXPORT has the following definition:
#define PHPCPP_EXPORT __attribute__ ((visibility ("default")))

Sincerely,
-- 
Nathanael
/**
 *  Throwable.h
 *
 *  Base class for exceptions and errors, where an error is a runtime
 *  problem with the program (like file-does-not-exist), and an error
 *  is a more fatal programming problem (like call-to-private-method).
 *
 *  @author Jasper van Eck 
 *  @author Emiel Bruijntjes 
 *  @copyright 2013 - 2019 Copernica BV
 */
#include 
#include 

/**
 *  Forward declarations
 */
struct _zend_object;

/**
 *  Set up namespace
 */
namespace Php {

/**
 *  Class definition
 */
class PHPCPP_EXPORT Throwable : public std::runtime_error
{
protected:
/**
 *  The exception code
 *  @var long int
 */
long int _code = -1;


protected:
/**
 *  Protected constructor - only derived classes can instantiate
 *  @param  message The exception message
 */
Throwable(const std::string &message) : std::runtime_error(message) {}

/**
 *  Another protected constructor
 *  @param  object
 */
Throwable(struct _zend_object *object);

public:
/**
 *  Destructor
 */
virtual ~Throwable() = default;

/**
 *  Rethrow the exception / make sure that it ends up in PHP space
 */
virtual void rethrow() = 0;
 
/**
 *  Returns the exception code
 *  @return The exception code
 */
long int code() const _NOEXCEPT
{
// expose the code
return _code;
}
};

/**
 *  End of namespace
 */
}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Introduce module Obsoletes and EOL

On Mon, Mar 30, 2020 at 10:30:51AM -0400, Ben Cotton wrote:
> 
> document: TBD
> version: 1
> data:
>   # A string representing UTC date in ISO 8601 format: -MM-DD[T ]HH:MMZ
>   # When merging, entries with a newer 'modified' value will override
> any earlier values.
>   # MANDATORY
>   modified: 2020-03-19T23:26Z
> 
>   # A boolean option to cancel/reset all previously specified obsoletes
>   # Example: repo 'fedora' has Obsoletes:nodejs:12; we want to bring
> nodejs:12 back in 'updates'
>   # If used, following options will be ignored: eol_date, obsoleted_by
>   # OPTIONAL
>   : 

What obsoletes would be covered by this? Those for this particular stream?

>   # A string representing a Name of a module that is EOLed
>   # MANDATORY
>   module: nodejs
> 
>   # A string representing a Stream of a module that is EOLed
>   # MANDATORY
>   stream: 11
> 
>   # A string representing a Context of a module that is EOLed
>   # If not specified, all contexts get EOLed.
>   # NOTE: consider specifying a list of contexts
>   # OPTIONAL
>   context: aabbccddee
> 
>   # A string representing UTC date in ISO 8601 format: -MM-DD[T ]HH:MMZ
>   # It is strongly recommended to keep HH:MM to 00:00.
>   # If not specified, the module is EOLed immediately.
>   OPTIONAL
>   eol_date: 2020-03-19T00:00Z

Normally we want the obsoletes to happen when doing a 'dnf system-upgrade'
operation, and not based on time. Does this allow us to tell dnf for this
happen during an upgrade, but not before?

>   # A string describing the change, reason, etc.
>   # MANDATORY
>   message: "Module stream nodejs:11 is no longer supported. It is
> recommended to switch to nodejs:12"
> 
>   # If a stream is not EOLed but Obsoleted, provide details about the
> obsoleting stream:
>   # OPTIONAL
>   obsoleted_by:
> module: nodejs
> stream: 12

Is the obsoleting module enabled automatically?

> == User Experience ==
> Fedora users experience upgradability problems when upgrading to Fedora 32
> when they have any module streams enabled.
> 
> If a stream no longer exists on the version of Fedora they are upgrading to,
> DNF used to error out on resolving modular dependencies which was a
> clear release blocker.
> To workaround this case, all module streams are reset during the system 
> upgrade.
> By doing this, modularity users lose information about enabled streams
> and they need to re-enable them by hand.
> 
> This Change aims at removing the upgradability problems and allowing
> Fedora modularity users
> to upgrade their systems while keeping their streams enabled, reset or
> switched (obsoleted)
> according to newly provided modular metadata.

Thanks, that sounds like a reasonable UX.

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

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

- 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://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: ELN Buildroot and Compose V2

2020-03-30 Thread Robbie Harwood

Petr Pisar  writes:

> On Sun, Mar 29, 2020 at 12:56:42AM +0100, clime wrote:
>
>> You can make a separate namespace for this in dist-git. It doesn't
>> need to be a separate branch. That way, you won't be disturbing
>> anyone elses space.
>
> A different name space means a different repository. That means a full
> copy.  A waste of space.

Without taking a stand on which approach is better: I would hope that
our git forge is smart enough to reuse storage for the same commit
hashes.  Therefore, a fork with merges will be very low overhead.

> By the way what about bug reports? Are we expect to use Bugzilla for
> the ELN bugs? A different name space has the advatange of an
> independent Bugzilla component.  Otherwise ELN bugs will get
> intermixed with (and default-assigned to) the Fedora product.

This is a good question, especially since this has not been resolved for
modular components either to my knowledge.

Thanks,
--Robbie


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

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

On 30. 03. 20 17:47, Jiri Vanek wrote:

On 3/30/20 5:04 PM, Miro Hrončok wrote:

On 30. 03. 20 16:04, Ben Cotton wrote:

* Contingency mechanism: Return jdk8 as system jdk and mass rebuild
again. Note, that this may be very hard, because during build of
packages by jdk8, by jdk11 built dependencies will be picekd up, so
build will fail. Maybe several iterations of mass rebuild will be
needed.

Can we lease do this in a side tag instead and verify basic functionality
before we merge it to
rawhide? Than the contingency might just be: Don't merge the side tag.

Sounds like good idea..the way how to go. Only I'm not familiar with how it
works.

Note that it implies that the change owners coordinate the rebuilds.

See this documentation for how we do Python upgrades of this sort (except in
Python, we need to rebuild "everything" and in a correct order, while the Java
thing seem to generally run fine when built with an older version, so tings get
easier for you):

https://fedoraproject.org/wiki/SIGs/Python/UpgradingPython#Once_ready.2C_move_into_Fedora_proper

--
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

Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

On Mon, Mar 30, 2020 at 12:46 PM Kevin Fenzi  wrote:
>
> On Mon, Mar 30, 2020 at 12:41:08PM +0300, Panu Matilainen wrote:
> > If it was up to us only, I recon we'd be looking to switch over to sqlite
> > somewhere between 2-4 weeks from the time 4.16 lands in rawhide but our
> > schedule is flexible here. What ballpark dates would we be looking at with
> > the datacenter move and builder upgrade?
>
> ok, 2-4 weeks from tomorrow would be between the 14th and the 28th?
>
> Fedora 32 preferred release date is the 21st. I'm really not sure we
> will have cycles to update all the builders in less than a week.
> Whats the impact of using rawhide rpm on f31 builders? Will there be
> deps/issues ?
>
> We probibly won't move to f32 on the builders until we are installing
> new ones in the new datacenter and switching to those. But I very leary
> of also replacing rpm on them at the same time... I guess it could work
> and we could always back it out if not. That would be the last week of
> may or so that we switch to those.
>
> So, I guess the two windows are: as soon as it looks ok with f31
> builders or last week or may/first week of june with f32. Or late june
> when we are done moving things.
>
> Thoughts?
>

RPM 4.16 is supposed to be ABI compatible to everything built against
RPM 4.15. So RPM 4.16 should be able to plug in just fine on Fedora 31
or Fedora 32.




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

Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB

On Mon, Mar 30, 2020 at 12:41:08PM +0300, Panu Matilainen wrote:
...snip...
> 
> No such things needed at this time. The database change is a separate change
> and does NOT come bundled with RPM 4.16, we'll only even consider switching
> that once 4.16 has had a proper shakedown.

ok, great. 
> > 
> > In either case, it may be hard to have cycles for this while datacenter
> > move is happening. It would help if we had a ballpark at least for when
> > it will land / some folks willing to get bootstrapping working in koji.
> > 
> > Or what would you think of the idea of landing it in rawhide, but
> > keeping default bdb until after we have the move done and can upgrade
> > builders to f32?
> 
> This was the plan all along: the dust of RPM 4.16 landing in rawhide needs
> to settle first before any database changes are considered, excact schedule
> depending on all manner of things. I thought this was clear from the SQLite
> change proposal but guess not.

Sorry if it was, perhaps I just missed that. ;( 

> If it was up to us only, I recon we'd be looking to switch over to sqlite
> somewhere between 2-4 weeks from the time 4.16 lands in rawhide but our
> schedule is flexible here. What ballpark dates would we be looking at with
> the datacenter move and builder upgrade?

ok, 2-4 weeks from tomorrow would be between the 14th and the 28th?

Fedora 32 preferred release date is the 21st. I'm really not sure we
will have cycles to update all the builders in less than a week. 
Whats the impact of using rawhide rpm on f31 builders? Will there be
deps/issues ?

We probibly won't move to f32 on the builders until we are installing
new ones in the new datacenter and switching to those. But I very leary
of also replacing rpm on them at the same time... I guess it could work
and we could always back it out if not. That would be the last week of
may or so that we switch to those. 

So, I guess the two windows are: as soon as it looks ok with f31
builders or last week or may/first week of june with f32. Or late june
when we are done moving things. 

Thoughts?

kevin

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

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

2020-03-30 Thread Andrew Haley

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.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

On Mon, Mar 30, 2020 at 01:13:03PM +0200, Miro Hrončok wrote:
> 
> I'm afraid that this won't be good enough. Other (Fedora) builds will be
> submitted with lower prio as well. For example our Python 3.N+1 rebuilds are
> usually submitted as such, so the wave of 3k packages doesn't block
> individual packagers. So unless Koji has multiple levels of priorities, I

It does. 

priority: the amount to increase (or decrease) the task priority, 
relative
  to the default priority; higher values mean lower priority; 
only
  admins have the right to specify a negative priority here

It's basically an integer. 
createrepos/newRepo are 14
releng runroot jobs are 15
'normal' builds are around 19
'scratch' builds are around 20
backgrounds is 25
koschei sets it's builds to 50

kevin


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

Summary/Minutes from today's FESCo Meeting (2020-03-30)

Meeting summary
---
* #2358 Drop the restriction on tagging for fedora-release  (zbyszek,
  15:02:45)
  * AGREED: drop fedora-release and fedora-repos from the secure-boot channel 
(+7, 0, 0)
 (zbyszek, 15:11:41)

* #2360 RPM 4.16 and sqlite db changes for Fedora 33  (zbyszek,
  15:11:57)
  * AGREED: APPROVED (both parts) (+7, 0, 0)  (zbyszek, 15:18:47)

* DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories
  despite "rpm --import"-ing the keys first  (zbyszek, 15:18:58)

* Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
  (zbyszek, 15:29:31)

* Next week's chair  (zbyszek, 16:21:48)
  * ACTION: contyk will chair next meeting  (zbyszek, 16:23:39)

* Open Floor  (zbyszek, 16:23:50)


Meeting ended Mon Mar 30 16:25:03 2020 UTC. Information about MeetBot at 
http://wiki.debian.org/MeetBot .
Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-03-30/fesco.2020-03-30-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-03-30/fesco.2020-03-30-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-03-30/fesco.2020-03-30-15.00.log.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann  wrote:

> Hi,
>
> On Mon, Mar 30, 2020 at 12:38:16PM +0100, Leigh Griffin wrote:
> > The decision is made and we are proceeding to engage with Gitlab and
> > unfortunately that won't be reversed as a decision.
>
> I haven't expected this situation, so I've read up a bit on the whole
> thing.
>
> From the outside it looks that the CPE team is trying since about a year
> to get rid of as many services as possible, due to having not enough
> resources to handle all. (I've only been looking at devel@ and blog
> posts, there is not much else I could find about the CPE team)
>

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.


>
> The problem I think I see is, that there seems to be no option of giving
> away responsibilities - the only advances I see are either "we'll
> replace this with something we think is easier" or "lets turn it off".
>
> I see one exception: Fedocal, where this list has been asked, if someone
> wants to take over. Unfortunately that seems to be stuck due to
> bureaucracy.
>

Unfortunately GDPR means we cannot give away application data, the
applications themselves are free and open for the community to take and
standup and offer to the community at large.


> What I don't understand is, why a decision this big is not taken by
> FESCo (or Council) and the CentOS Governing Board itself.
>

Neither run the git forge, CPE run it and we asked both Communities for
input as to what our next steps should be.

>
> After all in the Blogpost about how the CPE team is planning to do
> things[1], it is stated:
> "Our intention is to run all of the apps through the Fedora Council
> first, in case the Council prefers any specific alternatives to a
> particular service or app."
>

And we done that and shared intentions around Pagure (and several other
apps) and in the case of Pagure it led to a requirements gathering exercise
to decide on the appropriate direction to take.

>
> (I'm also not sure why the article states the Council directly, and not
> FESCo)
>

We engage with Council who in turn may decide to engage with other groups
including FESCo

>
> It sure feels like the CPE is not bound by either FESCo, CentOS
> Governing Board or Fedora Council - this whole thing feels quite
> arbitrary.

We take their input and guidance very seriously and they guide and shape
our backlog of initiatives to work on.


> Maybe it would be wiser to consider this as a formal error and
> either re-do the decision process or hand the decision off to the Fedora
> Council and the CentOS Governing Board (maybe as a joint decision?)
>

Ultimately CPE have to run the application, so if your scenario is to come
to pass, both Fedora Council and CentOS Board will need to invest time and
resourcing into the running and maintenance of a Git forge solution. They
are also not the only stakeholders here.


> [1]
> https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
>
> All the best,
> David
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


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

2020-03-30 Thread Dario Lesca

Il giorno sab, 28/03/2020 alle 15.13 +, Sérgio Basto ha scritto:
> I will try packaging all Jitsi Meet suite [1] 

Cool!, if you want a beta tester on Fedora, let me know.

Thanks


-- 
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

2020-03-30 Thread David Kaufmann

Hi,

On Mon, Mar 30, 2020 at 12:38:16PM +0100, Leigh Griffin wrote:
> The decision is made and we are proceeding to engage with Gitlab and
> unfortunately that won't be reversed as a decision.

I haven't expected this situation, so I've read up a bit on the whole
thing.

From the outside it looks that the CPE team is trying since about a year
to get rid of as many services as possible, due to having not enough
resources to handle all. (I've only been looking at devel@ and blog
posts, there is not much else I could find about the CPE team)

The problem I think I see is, that there seems to be no option of giving
away responsibilities - the only advances I see are either "we'll
replace this with something we think is easier" or "lets turn it off".

I see one exception: Fedocal, where this list has been asked, if someone
wants to take over. Unfortunately that seems to be stuck due to
bureaucracy.

What I don't understand is, why a decision this big is not taken by
FESCo (or Council) and the CentOS Governing Board itself.

After all in the Blogpost about how the CPE team is planning to do
things[1], it is stated:
"Our intention is to run all of the apps through the Fedora Council
first, in case the Council prefers any specific alternatives to a
particular service or app."

(I'm also not sure why the article states the Council directly, and not
FESCo)

It sure feels like the CPE is not bound by either FESCo, CentOS
Governing Board or Fedora Council - this whole thing feels quite
arbitrary. Maybe it would be wiser to consider this as a formal error and
either re-do the decision process or hand the decision off to the Fedora
Council and the CentOS Governing Board (maybe as a joint decision?)

[1] 
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/

All the best,
David

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

Re: CPE Git Forge Decision

2020-03-30 Thread Matthias Runge

On 30/03/2020 17:41, Pavel Raiskup wrote:

> The only problem of GitLab is that Fedora - for years - was not able to
> package it.  I'm not a able to judge where the packaging problem is/was,
> any more info?  Are we going invest into packaging it?
> 
> Please make us 100% confident we are not going to be locked-in.  If we
> aren't able to package it reasonably well, it means that we have no option
> to decide to self-host GitLab in future.
> 

Self-hosting was not desired. You could, if you are trusting

curl
https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh
| sudo bash

(taken from https://about.gitlab.com/install/#centos-8 )


You can also export "most of your data" from hosted solutions, see
https://about.gitlab.com/pricing/
(there is an faq "Can I export my data")

The link is
https://docs.gitlab.com/ee/user/project/settings/import_export.html
where it says:

The following items will NOT be exported:

- Build traces and artifacts
- Container registry images
- CI variables
- Webhooks
- Any encrypted tokens
- Merge Request Approvers
- Push Rules
- Awards


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

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

- 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

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

2020-03-30 Thread Jiri Vanek

On 3/30/20 5:04 PM, Miro Hrončok wrote:
> On 30. 03. 20 16:04, Ben Cotton wrote:
>> * Contingency mechanism: Return jdk8 as system jdk and mass rebuild
>> again. Note, that this may be very hard, because during build of
>> packages by jdk8, by jdk11 built dependencies will be picekd up, so
>> build will fail. Maybe several iterations of mass rebuild will be
>> needed.
> 
> Can we lease do this in a side tag instead and verify basic functionality 
> before we merge it to
> rawhide? Than the contingency might just be: Don't merge the side tag.
> 
Sounds like good idea..the way how to go. Only I'm not familiar with how it 
works.

-- 
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

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

2020-03-30 Thread Jiri Vanek

On 3/30/20 5:26 PM, Fabio Valentini wrote:
> On Mon, Mar 30, 2020 at 4:05 PM Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/Java11 .
>>
>> == Summary ==
>> Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk.
>>
>> == Owner ==
>> * Name: [[User:jvanek| Jiri Vanek]]
>> * Email: 
>> * Product: java and java stack
>> * Responsible WG: java-sig (java and java-maint)
>>
>> == Detailed Description ==
>> Fedora currently ships:
>> * java-1.8.0-openjdk (LTS)
>> * java-11-openjdk (LTS)
>> * an java-latest-openjdk (on jdk14, STS).
>> where the version-less '''java''' and '''javac''' (and friends) are
>> provided by java-1.8.0-openjdk.
>>
>> So every package honoring the packaging rules and requiring java ,
>> java-headless or java-devel is built in brew by
> 
> What is brew?

Sorry, that was supposed to be koji. Fixed in the document.
> 
>> java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in
>> runtime (See [https://fedoraproject.org/wiki/Java java] ).  Also
>> javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime
>> (see 
>> [https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting
>> changes])
...
>>
>> === "Political disclaimer" ===
>> In previous bumps, we, Red Hat's openjdk team, were a driving force to
>> bump the system JDK. In this case, we are a bit reluctant, but the
>> desire from users to bump the JDK seems strong. We are quite happy to
>> skip JDK11 as system JDK at all, and jump directly from 8 to 17  in
>> some three years.
> 
> Skipping all the way from 8 → 17 sounds like there would be even more
> potential for breaking things, so switching to 11 as an intermediary
> step seems like a good idea to me.

Right you  are. thank you.
> 
>> == Benefit to Fedora ==
>> JDK11 is out for some time, and most of the bleeding edge
>> distributions already make it default. Most of the projects already
>> adapted new features and make necessary forward-compatible chnages.
>> Although we can can expect some family of packages to remain on jdk8
>> for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should
>> flow]
...
>> * 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.
>> *** Solutions to most common errors should be gathered and published
>> * Release engineering: [https://pagure.io/releng/issue/9347 9347]
>> ** mass rebuild will be required for this change
>> * Policies and guidelines: how to deal with build failures, eventually
>> how to use some jdk11 specific build features will be provided
>> * Trademark approval: N/A (not needed for this Change)
> 
> I agree with Miro. These changes should be done in a side tag, or even
> better, also tested in COPR before that. Kind of like how the python
> 3.9 bringup is happening right now. This way, potential issues can be
> caught early.

Not sure how the coper cna be managed. As side tag, yes, woudl be awesome.
> 
> Additionally, just switching 1.8.0 → 11 and walking away will probably
> break rawhide packages for years to come, given the state the Java
> stack is in. Some Java packagers / packages will definitely need some
> help there. The Stewardship SIG can help with some issues (a few
> members are provenpackagers), but our resources are limited, and we
> "only" maintain ~200 Java packages directly.

As replied to Miro. Help will definitely be provided. But direct touch to 
packages(two
provenpackagers on board here), only in great need.   Otherwise the few of us, 
incluing fwhat
remained from java-sig, would get swamped.

Hope that sounds reasonable.

J.
> 
> Fabio
> 
> PS: I hope my post doesn't sound too negative. I'm happy this switch
> is finally happening :)

Not at all. Those must be clarified. Tahnx, cross fingers :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

2020-03-30 Thread Pavel Raiskup

On Monday, March 30, 2020 11:17:21 AM CEST Leigh Griffin wrote:
> Thank you for your patience while the CPE Team worked through an incredible
> number of requirements from multiple stakeholder sources. On Friday evening
> we announced on the Community Blog
>  our
> decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise
> that we are striking will help to allow Pagure flourish and to give a
> choice of Forges for your usage. I'm happy to field any questions or
> comments about this decision.

Is there some tool to automatically migrate PRs->MRs and issues?

The only problem of GitLab is that Fedora - for years - was not able to
package it.  I'm not a able to judge where the packaging problem is/was,
any more info?  Are we going invest into packaging it?

Please make us 100% confident we are not going to be locked-in.  If we
aren't able to package it reasonably well, it means that we have no option
to decide to self-host GitLab in future.

Pavel

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

2020-03-30 Thread Jiri Vanek

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.

> 
> 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

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

2020-03-30 Thread Fabio Valentini

On Mon, Mar 30, 2020 at 4:05 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Java11 .
>
> == Summary ==
> Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk.
>
> == Owner ==
> * Name: [[User:jvanek| Jiri Vanek]]
> * Email: 
> * Product: java and java stack
> * Responsible WG: java-sig (java and java-maint)
>
> == Detailed Description ==
> Fedora currently ships:
> * java-1.8.0-openjdk (LTS)
> * java-11-openjdk (LTS)
> * an java-latest-openjdk (on jdk14, STS).
> where the version-less '''java''' and '''javac''' (and friends) are
> provided by java-1.8.0-openjdk.
>
> So every package honoring the packaging rules and requiring java ,
> java-headless or java-devel is built in brew by

What is brew?

> java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in
> runtime (See [https://fedoraproject.org/wiki/Java java] ).  Also
> javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime
> (see 
> [https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting
> changes])
>
> Debian already moved to JDK11 as system JDK, and in Fedora community
> we can hear for last two years increasing voices for jdk11 to become
> the system one. And apparently the java stack is really quite ready
> for JDK11. Fedora is considered to be bleeding edge distribution, so
> we should move forward, however JDK11 is not 100% compatible with
> JDK8, so there may rise nasty issues and very unhappy users.
>
> Major incompatibility is in encapsulation. What was private, is now
> really private and if one was using it (and it was common) then the
> code will stop working. Unluckily, most of those issues are not only
> build time issues, but runtime issues, so hard to spot without proper
> test coverage.
>
> === A bit of history to recall: ===
> version (upstream support) - fedora state
> * Java SE 6 (LTS 2006-cca2014) - added as techpreview in F8 replaced
> GCJ around F13. See https://fedoraproject.org/wiki/Releases
> * Java SE 7 (LTS 2011-2020(?)) -  entered Fedora as tech preview
> around F16/17 replaced JDK 6 as System JDK in F17
> * Java SE 8 (LTS 2014-2026(???)) - entered Fedora as tech preview in
> F19 replaced JDK 7 as System JDK in F21. JDK6 and JDK7 later returned
> as community driven java-1-{6,7}-0-openjdk-legacy packages for a while
> * Java SE 9 (2017-2018) - entered Fedora around F26 as secondary,
> java-1.9.0-openjdk alongside java-1.8.0-openjdk
> * Java SE 10 (2018-2019) - entered F28 as secondary,
> java-latest-openjdk alongside java-1.8.0-openjdk
> * Java SE 11 (LTS 2018-??) - entered Fedora as tech preview in F29
> together with java-latest-openjdk and java-1.8.0-openjdk
> * Java SE 12 (2019) -  updated java-latest-openjdk transparently and
> keept going alongside java-1.8.0-openjdk and  alongside
> java-11-openjdk
> * Java SE 13 (2019-2020) - updated java-latest-openjdk transparently
> and keept going alongside java-1.8.0-openjdk and  alongside
> java-11-openjdk
> * Java SE 14 (March 2020-2021(?)) - is updating  java-latest-openjdk
> transparently and will continue to live next to any system JDK(s)
> * Java SE 15 (2020(?)-2021(?))  - will update  java-latest-openjdk
> transparently and will continue to live next to any system JDK(s)
> * Java SE 16 () - will update  java-latest-openjdk transparently and
> will continue to live next to any system JDK(s)
> * Java SE 17 (LTS) - will very likely update  java-latest-openjdk
> transparently  and will become future system JDK java-17-openjdk some
> year later
> * Java SE 18 () - will update  java-latest-openjdk transparently and
> will continue to live next to any system JDK(s)
> * 
>
> === "Political disclaimer" ===
> In previous bumps, we, Red Hat's openjdk team, were a driving force to
> bump the system JDK. In this case, we are a bit reluctant, but the
> desire from users to bump the JDK seems strong. We are quite happy to
> skip JDK11 as system JDK at all, and jump directly from 8 to 17  in
> some three years.

Skipping all the way from 8 → 17 sounds like there would be even more
potential for breaking things, so switching to 11 as an intermediary
step seems like a good idea to me.

> == Benefit to Fedora ==
> JDK11 is out for some time, and most of the bleeding edge
> distributions already make it default. Most of the projects already
> adapted new features and make necessary forward-compatible chnages.
> Although we can can expect some family of packages to remain on jdk8
> for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should
> flow]
>
> == Scope ==
> === keep java-1.8-0-openjdk but remove its java/javac versionless
> provides, make java-11-openjdk providing java, javac and other
> versionless provides ===
> * will guarantee fedora to be pure JDK11 distro.
> * will allow maintainers of JDK9 or up incompatible packages to keep
> using JDK8, however this is just false hope.
> ** if such an package depends on package build by JDK11, JDK8 will not
> be able to pick

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


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.


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?


As a side not, please don't mix in Jira tickets, that sounds RH internal to me.

--
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

Re: Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL

2020-03-30 Thread Petr Pisar

On Mon, Mar 30, 2020 at 10:30:51AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL
[...]
> *** When a module stream gets removed from a Fedora release, the
> maintainer of the module stream must provide a modulemd document with
> Obsoletes or EOL data.
> 
I'd like to point out that Fedora Project has already possed EOL dates. They
are provided by packagers when requesting for new dist-git branch (i.e. when
creating a new stream) and they are stored in Fedora PDC.

Examples for perl:5.26
:

{
"id": 691015,
"sla": "bug_fixes",
"branch": {
"id": 345929,
"name": "5.26",
"global_component": "perl",
"type": "module",
"critical_path": false,
"active": false
},
"eol": "2019-12-01"
}

So if you execute "dnf module list perl" in Fedora 30 you should not see
perl:5.26 accoding to this change.

Provided Fedora Project is going to keep requesting the EOL datum on creating
a branch, pungi could query PDC and automatically generate the
module-obsolete documents for streams and contexts that require those streams.

The only missing piece of information is the obsoleting stream. Either the
maintainer could edit the PDC data with this information when it is known (as
he already can edit the eol date by a rel-eng ticket
; see module_eol template type), or the
maintainer could supply its own module-obsolete document (how?) that would
inhibit the generating the document for the same stream by pungi.

In both cases it would be great if an Fedora infrastrucure send a notification
to the maintainer the OEL is approaching and he should provide the data (e.g.
by filing a bug report into Bugzilla against that module).

-- Petr

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

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


On 30. 03. 20 16:04, Ben Cotton wrote:

* Contingency mechanism: Return jdk8 as system jdk and mass rebuild
again. Note, that this may be very hard, because during build of
packages by jdk8, by jdk11 built dependencies will be picekd up, so
build will fail. Maybe several iterations of mass rebuild will be
needed.


Can we lease do this in a side tag instead and verify basic functionality before 
we merge it to rawhide? Than the contingency might just be: Don't merge the side 
tag.


--
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

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

On Mon, Mar 30, 2020 at 1:13 PM Julen Landa Alustiza <
jla...@fedoraproject.org> wrote:

>
>
> 20/3/30 13:43(e)an, Leigh Griffin igorleak idatzi zuen:
> >
> >
> > On Mon, Mar 30, 2020 at 12:24 PM Iñaki Ucar  > > wrote:
> >
> > On Mon, 30 Mar 2020 at 13:10, Leigh Griffin  > > wrote:
> > >
> > > On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar
> > mailto:iu...@fedoraproject.org>> wrote:
> > >>
> > >> So I was also waiting for those open discussions about the
> > >> requirements gathered.
> > >
> > > We had several threads on them from the Fedora perspective on both
> > devel and council lists.
> >
> > Yet again: threads on requirements gathering, not on the merits of
> the
> > final User Story list.
> >
> >
> > A merits based discussion whereby multiple stakeholders have a totally
> > different view and use case for a Forge is impossible to facilitate.
> > What is valuable to you and your use case might not be valuable to other
> > users and vice versa. I'm happy to have a conversation about any
> > individual requirements but the reality is any that made the list are
> > valid requirements from a stakeholder perspective and it's not up to me
> > or anyone to challenge that assertion.
> As I asked before on this thread, I would like to know how are you
> planning to fullfill the SLA requirement while the SLE from CPE for the
> services like AAA that the forge will require to function is lower than
> the required SLA for the forge itself.
>

The availability of the forge isn't bound by the availability of the AAA
system, that will only impact a percentage of users. I'm not sure if that
is addressing your question or not?


> >
> >
> > That's what several of us were expecting. I
> > don't think it's too hard too understand. You can say "no, that
> wasn't
> > part of the process", but then, sorry, you didn't communicate that
> > effectively.
> >
> > > I'm sorry this is disappointing but even reading the analysis by
> > Neal it is looking at the merit of the requirement and not looking
> > at the fact that it is valuable to somebody. Each stakeholder group
> > had their own means to discuss and debate the merits and had them
> > rolled into CPE who in turn analysed them and published the full
> > story list.
> >
> > Two things are obvious here: 1) not all the requirements can be met
> > (you already stated this), and 2) not all requirements have the same
> > importance. So yes, of course Neal is looking at the merit of every
> > single requirement, and that's your job too. What if I say that is
> > valuable to me that the GitHub logo is on top of the interface? Is
> > that something that should be taken into account just because it's
> > valuable to somebody?
> >
> >
> > If that came up as a UI requirement then yes we would have taken it on
> > board, would have documented it and would have presented it in the final
> > list of unique user stories we gathered. Would it be weighed equally
> > with a more core functional requirement? The answer is of course no but
> > we would have respected that request.
> >
> > The Fedora specific requirements (as I am on the Fedora lists here) had
> > very few unique needs such that both Gitlab and Pagure would have
> > satisfied their desire. Either Forge would have been satisfied the
> > requirements we received and we ultimately opted for Gitlab based on a
> > more holistic view of the stakeholder needs.
> >
> >
> > Iñaki
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > 
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> >
> >
> > --
> >
> > Leigh Griffin
> >
> > Engineering Manager
> >
> > Red Hat Waterford 
> >
> > Communications House
> >
> > Cork Road, Waterford City
> >
> > lgrif...@redhat.com 
> > M: +353877545162  IM: lgriffin
> >
> > @redhatjobs    redhatjobs
> >  @redhatjobs
> > 
> > 
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >

Re: CPE Git Forge Decision

On Mon, Mar 30, 2020 at 3:36 PM Matthias Runge 
wrote:

> On 30/03/2020 16:23, Till Maas wrote:
>
>  For transparency, we have published the full User Story list which is
>  linked within the blog and for ease of searching is here:
>  https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>
> >
> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> >
> > In the hackmd story list, there are is only infosec, RH Legal Rep, RH
> > Infocsec Rep, RH Developer, RHEL engineer and general users, project
> > contributor, CPE team member. Nothing really maps to the user groups I
> > mentioned. There is only
> >
> > | 41
> > | As a General User
> > | I want groups and group membership and management
> > | to allow me create access control on a suite of repositories
> >
> > but this is very vague.
>
>
> Comparing the two lists Ben posted and the one on hackmd.io differ quite
> a bit. Was the list of requirements changed during the process?
>

As a team we evaluated every single requirement (over 300 of them) and the
presentation in the combined User Story list is an amalgamation of like for
like User Stories to capture at a high level the spirit of the requests.

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


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


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

On Mon, Mar 30, 2020 at 3:26 PM Till Maas  wrote:

> Hi,
>
> On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> > On Mon, Mar 30, 2020 at 2:18 PM Till Maas  wrote:
> >
> > > Hi,
> > >
> > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
> > >
> > > > For transparency, we have published the full User Story list which is
> > > > linked within the blog and for ease of searching is here:
> > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> > >
> > > the user stories list does not seem to include the original user
> stories
> > > that I submitted regarding package life-cycle and permission
> management.
> > > These are requirements for dist-git but not necessarily for a
> git-forge.
> > > In the past they were fulfilled by package db, now pagure is solving
> > > this more.
> >
> >
> > We received a summarised User Story list from the Fedora Council, I would
> > suggest reaching out with your concerns.
>
> What is the list that you got. The list on the council discuss list
> contained these items, for example for FESCo members, proven packagers
> and dist-git repo admins:
>
> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/


We received a Google Doc with the summation of the 44 requirements from
Fedora Council.


>
>
> In the hackmd story list, there are is only infosec, RH Legal Rep, RH
> Infocsec Rep, RH Developer, RHEL engineer and general users, project
> contributor, CPE team member. Nothing really maps to the user groups I
> mentioned.


As mentioned, we rolled in stories together and General Users /
contributors map to the majority of the Fedora projects requirements
(similar for CentOS) and a lot of individual stakeholder requirements ended
up in the general bucket.


> There is only
>
> | 41
> | As a General User
> | I want groups and group membership and management
> | to allow me create access control on a suite of repositories
>
> but this is very vague.
>

The User Stories are deliberately vague and that represents around 10
unique requirements that boil down to having group membership and
management capabilities.

>
> Also there seems to be nothing about orphaning/adopting/retiring
> packages, not even in a vague way.
>

We have stories relating to specific workflow requirements (from multiple
stakeholders including RHEL, CentOS and Fedora) for dist-git. We have
represented a requirement (number 18 on the list) about viewing orphaned
packages. The requirements received around this process were very much
aligned with permissions and visibility to allow actions. They are covered
through other User Stories and what I feel needs to be made clear, we are
presenting the amalgamated list and as a team we read every single User
Story that came in and processed them accordingly in making this decision.

>
> Thank you,
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


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

2020-03-30 Thread Matthias Runge

On 30/03/2020 16:23, Till Maas wrote:

 For transparency, we have published the full User Story list which is
 linked within the blog and for ease of searching is here:
 https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8

> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> 
> In the hackmd story list, there are is only infosec, RH Legal Rep, RH
> Infocsec Rep, RH Developer, RHEL engineer and general users, project
> contributor, CPE team member. Nothing really maps to the user groups I
> mentioned. There is only
> 
> | 41
> | As a General User
> | I want groups and group membership and management
> | to allow me create access control on a suite of repositories
> 
> but this is very vague.


Comparing the two lists Ben posted and the one on hackmd.io differ quite
a bit. Was the list of requirements changed during the process?


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

Fedora 33 System-Wide Change proposal: Mark libdb as deprecated

https://fedoraproject.org/wiki/Changes/Libdb_deprecated

== Summary ==
This change should inform maintainers and developers about effort to
remove libdb in future.

== Owner ==
* Name: [[User:fjanus|Filip Januš]]
* Email: fja...@redhat.com


== Detailed Description ==
We would like to remove libdb from Fedora in future, because
BerkeleyDB 6.x has a more restrictive license than the previous
versions (AGPLv3 vs. LGPLv2) and due many projects can't use it.
Nowadays Fedora uses the old version (5.3.28) and we can't update to
newer. Due to many projects have libdb dependency, we propose few
steps to complete removal. First step would mark libdb as deprecated
package in Fedora 33. Next steps in Fedora 35 would provide converting
tool for existing databases and mark libdb as orphaned.


== Benefit to Fedora ==
We would like to have most recent releases of components in Fedora,
which are supported by upstreams. But due to licence of BerkeleyDB we
need to hold old BerkeleyDB version in Fedora.


== Scope ==
* Proposal owners: Not needed for this change - only deprecation
* Other developers: Developers should prepare own projects(scripts,
programs, packages, ...) for the next change and for the complete
libdb removal.
* Policies and guidelines: Not needed for this change - only deprecation
* Trademark approval: Not needed for this change - only deprecation


== Upgrade/compatibility impact ==
This change hasn't direct impact onto actual dependencies. Purpose of
this change is inform and prepare people to future change which will
affect many components.

[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O442UPRAGHD6ZN77GWTARY2VXP24VFBC/#O442UPRAGHD6ZN77GWTARY2VXP24VFBC
Here] is short discussion from Fedora-devel list.

== User Experience ==
There is no change for users. Package is marked only as deprecated
package and behaves as before.

== Dependencies ==
*Libdb has many dependencies:
*389-ds-base
*apr-util-bdb
*bind-sdb
*bogofilter
*cld
*clisp
*cyrus-sasl-lib
*dsniff
*evolution-data-server
*exim
*heimdal
*iproute
*ipv6calc
*isync
*jabberd
*jigdo
*jigdo-gui
*kdesvn
*libetpan
*libopendkim
*libserf
*lizardfs-master
*mesos
*mod_dav_svn
*mod_perl
*mod_qos
*mod_security
*netatalk
*nmh
*nss_updatedb
*nvi
*opendkim
*openldap-servers
*opensips-db_berkeley
*opensmtpd
*pam
*pam_abl
*pam_ccreds
*perdition
*perl-BDB
*perl-BerkeleyDB
*perl-DB_File
*perl-eperl
*php-dba
*pl
*postfix
*python3-bsddb3
*rapidsvn
*redland
*reprepro
*rpm
*rsvndump
*sendmail
*sks
*spamprobe
*squid
*squidGuard
*subversion
*tqsllib
*trustedqsl
*webalizer
*xemacs

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A
* Blocks release? No

== Documentation ==
There is no upstream documentation, but
[[User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora|here]] is a list
of dependencies with some useful comments and
[[User:Pkubat/BerkeleyDB_alternatives|here]] some possible
alternatives.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL

https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL

== Summary ==
Fix Fedora upgradability issues when upgrading systems with module
streams enabled.


== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dm...@redhat.com


== Detailed Description ==
DNF currently doesn't have sufficient information to perform system
upgrades of systems with enabled module streams correctly.
To solve upgradability problems, we will add additional modulemd metadata.
This includes information about a stream obsoleting another one or a
stream being EOLed.

Use Cases:
* A module (all its streams) is removed from a distribution.
* A stream has reached its EOL and must no longer be available.
** The stream packages have no replacements and must be removed from
the system (an extension of fedora-obsolete-packages?)
** The stream packages get replaced with non-modular packages
* A stream has reached its EOL and is Obsoleted by another stream.
* A stream has reached its EOL and a user wants to continue using it
regardless of EOL/Obsoletes.
* A stream has reached its EOL and a user wants to install a new host
with the EOLed stream enabled.

There is going to be a new DNF config option:

* (name: TBD) - automatically follow stream EOL/Obsoletes; only print
a warning if turned off

Proposed new modulemd document:


document: TBD
version: 1
data:
  # A string representing UTC date in ISO 8601 format: -MM-DD[T ]HH:MMZ
  # When merging, entries with a newer 'modified' value will override
any earlier values.
  # MANDATORY
  modified: 2020-03-19T23:26Z

  # A boolean option to cancel/reset all previously specified obsoletes
  # Example: repo 'fedora' has Obsoletes:nodejs:12; we want to bring
nodejs:12 back in 'updates'
  # If used, following options will be ignored: eol_date, obsoleted_by
  # OPTIONAL
  : 

  # A string representing a Name of a module that is EOLed
  # MANDATORY
  module: nodejs

  # A string representing a Stream of a module that is EOLed
  # MANDATORY
  stream: 11

  # A string representing a Context of a module that is EOLed
  # If not specified, all contexts get EOLed.
  # NOTE: consider specifying a list of contexts
  # OPTIONAL
  context: aabbccddee

  # A string representing UTC date in ISO 8601 format: -MM-DD[T ]HH:MMZ
  # It is strongly recommended to keep HH:MM to 00:00.
  # If not specified, the module is EOLed immediately.
  OPTIONAL
  eol_date: 2020-03-19T00:00Z

  # A string describing the change, reason, etc.
  # MANDATORY
  message: "Module stream nodejs:11 is no longer supported. It is
recommended to switch to nodejs:12"

  # If a stream is not EOLed but Obsoleted, provide details about the
obsoleting stream:
  # OPTIONAL
  obsoleted_by:
module: nodejs
stream: 12




== Benefit to Fedora ==
Seamless system upgrades of systems with module streams enabled.


== Scope ==
* Proposal owners:
** Introduce modularity features to:
** Obsolete a module stream
** Stream EOL
** Design a new modulemd documents for Obsoletes and EOL
** Get the new documents supported by libmodulemd
** Implement the new functionality in the DNF stack (libdnf, dnf,
microdnf) and PackageKit

* Other developers:
** Follow updated packaging policy. See the "Policies and guidelines" section.

* Release engineering: [https://pagure.io/releng/issue/9359] (a check
of an impact with Release Engineering is needed) 
Maintain and distribute new module metadata.

* Policies and guidelines:
** Packaging policy and modularity documents require a change:
*** When a module stream gets removed from a Fedora release, the
maintainer of the module stream must provide a modulemd document with
Obsoletes or EOL data.

* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
This feature solves upgradability problems of systems with module
streams enabled.


== How To Test ==
Stream Obsoletes:
* Enable a stream that is not available in the next version of Fedora
and is obsoleted by another stream in the metadata
* Run system upgrade
* Verify that the obsoleting stream is enabled instead of the obsoleted one

Stream EOL:
* Enable a stream that is not available in the next version of Fedora
and is obsoleted in its module metadata
* Run system upgrade
* Verify that the EOLed stream is no longer enabled and does not show
up in `dnf module list`

Fedora upgradability:
* Install Fedora 31 or 32
* For each $stream in available streams
** dnf module reset '*'
** dnf module enable $stream
** dnf distro-sync --releasever=33 --assumeno
** # the command must not throw any errors related to modularity,
especially related to the enabled stream


== User Experience ==
Fedora users experience upgradability problems when upgrading to Fedora 32
when they have any module streams enabled.

If a stream no longer exists on the version of Fedora they are upgrading to,
DNF used to error out on resolving modular dependencies which was a
clear release blocker.
To workaround this case, all module streams are reset during

Re: CPE Git Forge Decision

On Mon, Mar 30, 2020 at 3:07 PM Fabio Valentini 
wrote:

> On Mon, Mar 30, 2020 at 4:00 PM Leigh Griffin  wrote:
> >
> >
> >
> > On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok 
> wrote:
> >>
> >> On 30. 03. 20 14:13, Neal Gompa wrote:
> >> > And unlike Alioth, we have*serious*
> >> > integration across the board with Pagure, and a good chunk of it is
> >> > not possible to implement in GitLab. Features we have in here were
> >> > designed to meet the needs of Fedorans that we will be forced to give
> >> > up.
> >>
> >> I want to stress out that recently we even got more of it. Several
> years after
> >> the PackageDB sunset, we are finally getting to a matching packager
> experience.
> >>
> >> (For example with the Bugzilla default assignee or the
> unorphan/unretire buttons.)
> >>
> >> Is this going to be possible with GitLab?
>
>
> (snip)
>
> >
> >
> > I don't have an answer to this as we haven't done that deep level of
> tooling analysis and integration analysis yet.
>
> So you're basically saying that you've decided for GitLab (despite the
> fedora community obviously preferring pagure - whether you received
> that message or not),


It was not a formal requirement.

and you have not even looked at what that will
> mean?


We have looked into the capabilities of it to inform our decision but not
at a granular tooling level.


> And if it turns out that GitLab can't deliver some features you
> want, and not satisfy some "stakeholder user stories"?
>

Not all requirements can be satisfied in totality, we knew this before we
began and Gitlab satisfies the majority of the requirements needed.

>
> Am I crazy, or shouldn't have those problems have been taken into
> account *before* such a big decision is made?
> Your responses sound like "we made our decisions, and now we'll stick
> to them no matter what happens".
>

Like any technology decision that we as a team choose, we can revert our
decision if the service is not working as intended and not satisfying our
needs. Right now, we are proceeding with Gitlab as our choice.

And honestly, I shouldn't have expected anything else from this "kill
> pagure project".
>

Pagure was a viable choice and several hundred person hours went into
informing us of this decision because of how critical it was to get right.


>
> The way the fedora community - and the pagure project - are and were
> treated here is shameful, and you're going to lose fedora contributors
> because of it.
>
> Fabio
>
> >
> >>
> >> Will CPE implement this before we
> >> switch, or will GitLab be dumped on us and we will do toothless FESCo
> approved
> >> statements, such as "Missing Pagure features should be re-implemented in
> >> GitLab"?
> >
> >
> > CPE will take on a lot of the tooling work to ease the migration.
> >
> >>
> >> What measures will be taken to prevent yet another "open a releng
> >> ticket and a human will do this while we automate stuff" era?
> >>
> >> --
> >> 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
> >
> >
> >
> > --
> >
> > Leigh Griffin
> >
> > Engineering Manager
> >
> > Red Hat Waterford
> >
> > Communications House
> >
> > Cork Road, Waterford City
> >
> > lgrif...@redhat.com
> > M: +353877545162 IM: lgriffin
> >
> > @redhatjobs   redhatjobs @redhatjobs
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


_

Re: CPE Git Forge Decision

Hi,

On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 2:18 PM Till Maas  wrote:
> 
> > Hi,
> >
> > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
> >
> > > For transparency, we have published the full User Story list which is
> > > linked within the blog and for ease of searching is here:
> > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> >
> > the user stories list does not seem to include the original user stories
> > that I submitted regarding package life-cycle and permission management.
> > These are requirements for dist-git but not necessarily for a git-forge.
> > In the past they were fulfilled by package db, now pagure is solving
> > this more.
> 
> 
> We received a summarised User Story list from the Fedora Council, I would
> suggest reaching out with your concerns.

What is the list that you got. The list on the council discuss list
contained these items, for example for FESCo members, proven packagers
and dist-git repo admins:
https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/

In the hackmd story list, there are is only infosec, RH Legal Rep, RH
Infocsec Rep, RH Developer, RHEL engineer and general users, project
contributor, CPE team member. Nothing really maps to the user groups I
mentioned. There is only

| 41
| As a General User
| I want groups and group membership and management
| to allow me create access control on a suite of repositories

but this is very vague.

Also there seems to be nothing about orphaning/adopting/retiring
packages, not even in a vague way.

Thank you,
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

[EPEL-devel] Re: RHEL8 package list

2020-03-30 Thread Troy Dawson

On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi  wrote:
>
> On Sun, Mar 29, 2020 at 06:11:28PM +0200, Dominik 'Rathann' Mierzejewski 
> wrote:
> > On Sunday, 29 March 2020 at 15:59, Mattia Verga wrote:
> > > Is there a way to get the package list and their version available in
> > > RHEL8?  For example, I would like to make kpmcore and
> > > kde-partitionmanager available in EPEL8, but they require util-linux
> > > >= 2.33.2. Since I can't find what version is available in
> > > Bodhi/Koji/etc. I would like to know if there's some other web
> > > service where I can find that without having to install a VM just for
> > > that...
> >
> > Unofficial, but very useful:
> > http://rpms.remirepo.net/rpmphp/zoom.php
>
> There's also:
>
> https://infrastructure.fedoraproject.org/repo/json/
>
> which are pulled from the repos epel uses in koji.
>
> Looks like util-linux is 2.32.1...
>
> "util-linux": {"channels": {"codeready-builder-for-rhel-8-aarch64-rpms": 
> [{"release": "17.el8", "epoch": "0", "versions": "2.32.1"},
>

Please file a bug in bugzilla, requesting both of these to be added to EPEL8.
It's possible that we might need to use the older version from Fedora
30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4)

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

Re: multiple definitions build failure on armv7hl only

2020-03-30 Thread Dan Horák

On Thu, 5 Mar 2020 20:38:07 -0700
Orion Poplawski  wrote:

> On 3/4/20 10:09 PM, Orion Poplawski wrote:
> > Test building the latest gdl, I get the following errors only on
> > armv7hl:
> > 
> > /usr/bin/ld: CMakeFiles/gdl.dir/basic_op.cpp.o:(.rodata+0x30):
> > multiple definition of `typeinfo name for Data_'; 
> > CMakeFiles/gdl.dir/datatypes.cpp.o:(.rodata+0x50): first defined
> > here /usr/bin/ld: CMakeFiles/gdl.dir/basic_op.cpp.o:
> > (.data.rel.ro+0x0): multiple definition of `typeinfo for
> > Data_'; CMakeFiles/gdl.dir/datatypes.cpp.o:
> > (.data.rel.ro+0xc): first defined here
> > 
> > Full log: 
> > https://kojipkgs.fedoraproject.org//work/tasks/5149/42205149/build.log
> > 
> > Anything immediately suspicious here?  Seems odd to have two
> > definitions in different segments of the same object file.
> 
> This appears to be related to C++ template instantiation.  What I've
> yet to figure out is whether or not this is truly a problem in the
> code or an issue with the arm gcc/binutils tooling.  Any help would
> be greatly appreciated.

I think I have just met the same problem when building codeblocks -
https://koji.fedoraproject.org/koji/taskinfo?taskID=42870235

/usr/bin/ld: .libs/cbkeyConfigPanel.o:(.rodata+0x14): multiple definition of 
`typeinfo name for cbKeyBinder'; .libs/cbkeybinder.o:(.rodata+0x0): first 
defined here
/usr/bin/ld: .libs/cbkeyConfigPanel.o:(.data.rel.ro+0xc): multiple definition 
of `typeinfo for cbKeyBinder'; .libs/cbkeybinder.o:(.data.rel.ro+0x0): first 
defined here



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

Re: Upgrade tooling

2020-03-30 Thread Panu Matilainen


On 3/30/20 3:00 PM, Nicolas Mailhot via devel wrote:



On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote:


Yes, that is an important hurdle that Fedora generally doesn't
encounter
at all. Fedora usually waits until the new rpm functionality is
released
in older versions of Fedora before allowing it to be used in
rawhide.


Fortunately, that’s not the usual case. Any part of rpm that we refuse
to use, before it is available in older version of Fedora, is a part
that will bitrot and is unlikely to be ever used in Fedora.

Waiting does not make it more stable. Waiting makes sure the people
that were interested in the feature in the first place will move away.
Leaving rpm upstream with an untested feature no one wants to touch.

That would be even more braindamaged than forbidding the use of gcc
features not present in older versions. At least gcc sees some use dev-
side. But who is going to exercise packaging tools if packagers are
forbiddent to use them?

That being said, yes Fedora has been a terrible rpm stackaholder. That
has hurt both Fedora and rpm upstream. Half the NIH reinventing
packaging tools people just can not stand the delays associated with
rpm feature deployments.


Nicolas, thanks for this.

Indeed it's *really* hard (not to mention uninspiring and demotivating) 
to develop features in a setting where the first users of said feature 
*might* appear years in the future, at which point the feature will 
exists in some form in multiple releases already declared stable long 
ago, so its impossible to change anything, and even the simplest fixes 
would need to go to multiple branches and distros all at once.


So in this setting, with any rpm feature there's precisely one chance to 
get things *just* right. We all know how well that works with any 
software...


- Panu -



Regards,


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

Re: CPE Git Forge Decision

2020-03-30 Thread Fabio Valentini

On Mon, Mar 30, 2020 at 4:00 PM Leigh Griffin  wrote:
>
>
>
> On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok  wrote:
>>
>> On 30. 03. 20 14:13, Neal Gompa wrote:
>> > And unlike Alioth, we have*serious*
>> > integration across the board with Pagure, and a good chunk of it is
>> > not possible to implement in GitLab. Features we have in here were
>> > designed to meet the needs of Fedorans that we will be forced to give
>> > up.
>>
>> I want to stress out that recently we even got more of it. Several years 
>> after
>> the PackageDB sunset, we are finally getting to a matching packager 
>> experience.
>>
>> (For example with the Bugzilla default assignee or the unorphan/unretire 
>> buttons.)
>>
>> Is this going to be possible with GitLab?


(snip)

>
>
> I don't have an answer to this as we haven't done that deep level of tooling 
> analysis and integration analysis yet.

So you're basically saying that you've decided for GitLab (despite the
fedora community obviously preferring pagure - whether you received
that message or not), and you have not even looked at what that will
mean? And if it turns out that GitLab can't deliver some features you
want, and not satisfy some "stakeholder user stories"?

Am I crazy, or shouldn't have those problems have been taken into
account *before* such a big decision is made?
Your responses sound like "we made our decisions, and now we'll stick
to them no matter what happens".
And honestly, I shouldn't have expected anything else from this "kill
pagure project".

The way the fedora community - and the pagure project - are and were
treated here is shameful, and you're going to lose fedora contributors
because of it.

Fabio

>
>>
>> Will CPE implement this before we
>> switch, or will GitLab be dumped on us and we will do toothless FESCo 
>> approved
>> statements, such as "Missing Pagure features should be re-implemented in
>> GitLab"?
>
>
> CPE will take on a lot of the tooling work to ease the migration.
>
>>
>> What measures will be taken to prevent yet another "open a releng
>> ticket and a human will do this while we automate stuff" era?
>>
>> --
>> 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
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgrif...@redhat.com
> M: +353877545162 IM: lgriffin
>
> @redhatjobs   redhatjobs @redhatjobs
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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

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

https://fedoraproject.org/wiki/Changes/Java11 .

== Summary ==
Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk.

== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: 
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)

== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* an java-latest-openjdk (on jdk14, STS).
where the version-less '''java''' and '''javac''' (and friends) are
provided by java-1.8.0-openjdk.

So every package honoring the packaging rules and requiring java ,
java-headless or java-devel is built in brew by
java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in
runtime (See [https://fedoraproject.org/wiki/Java java] ).  Also
javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime
(see 
[https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting
changes])

Debian already moved to JDK11 as system JDK, and in Fedora community
we can hear for last two years increasing voices for jdk11 to become
the system one. And apparently the java stack is really quite ready
for JDK11. Fedora is considered to be bleeding edge distribution, so
we should move forward, however JDK11 is not 100% compatible with
JDK8, so there may rise nasty issues and very unhappy users.

Major incompatibility is in encapsulation. What was private, is now
really private and if one was using it (and it was common) then the
code will stop working. Unluckily, most of those issues are not only
build time issues, but runtime issues, so hard to spot without proper
test coverage.

=== A bit of history to recall: ===
version (upstream support) - fedora state
* Java SE 6 (LTS 2006-cca2014) - added as techpreview in F8 replaced
GCJ around F13. See https://fedoraproject.org/wiki/Releases
* Java SE 7 (LTS 2011-2020(?)) -  entered Fedora as tech preview
around F16/17 replaced JDK 6 as System JDK in F17
* Java SE 8 (LTS 2014-2026(???)) - entered Fedora as tech preview in
F19 replaced JDK 7 as System JDK in F21. JDK6 and JDK7 later returned
as community driven java-1-{6,7}-0-openjdk-legacy packages for a while
* Java SE 9 (2017-2018) - entered Fedora around F26 as secondary,
java-1.9.0-openjdk alongside java-1.8.0-openjdk
* Java SE 10 (2018-2019) - entered F28 as secondary,
java-latest-openjdk alongside java-1.8.0-openjdk
* Java SE 11 (LTS 2018-??) - entered Fedora as tech preview in F29
together with java-latest-openjdk and java-1.8.0-openjdk
* Java SE 12 (2019) -  updated java-latest-openjdk transparently and
keept going alongside java-1.8.0-openjdk and  alongside
java-11-openjdk
* Java SE 13 (2019-2020) - updated java-latest-openjdk transparently
and keept going alongside java-1.8.0-openjdk and  alongside
java-11-openjdk
* Java SE 14 (March 2020-2021(?)) - is updating  java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 15 (2020(?)-2021(?))  - will update  java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 16 () - will update  java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* Java SE 17 (LTS) - will very likely update  java-latest-openjdk
transparently  and will become future system JDK java-17-openjdk some
year later
* Java SE 18 () - will update  java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* 

=== "Political disclaimer" ===
In previous bumps, we, Red Hat's openjdk team, were a driving force to
bump the system JDK. In this case, we are a bit reluctant, but the
desire from users to bump the JDK seems strong. We are quite happy to
skip JDK11 as system JDK at all, and jump directly from 8 to 17  in
some three years.

== Benefit to Fedora ==
JDK11 is out for some time, and most of the bleeding edge
distributions already make it default. Most of the projects already
adapted new features and make necessary forward-compatible chnages.
Although we can can expect some family of packages to remain on jdk8
for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should
flow]

== Scope ==
=== keep java-1.8-0-openjdk but remove its java/javac versionless
provides, make java-11-openjdk providing java, javac and other
versionless provides ===
* will guarantee fedora to be pure JDK11 distro.
* will allow maintainers of JDK9 or up incompatible packages to keep
using JDK8, however this is just false hope.
** if such an package depends on package build by JDK11, JDK8 will not
be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat. packages, but
may be acceptable
** people developing JDK8 applications will very likely stay with fedora:)

While quite a lot of users will rejoice, there may be cases where
application is very hard to migrate to JDK11, so the contingency plan
should be taken very serious.

=== Other possible approaches already discarded by various discussions  ===
(see

Re: CPE Git Forge Decision

On Mon, Mar 30, 2020 at 2:18 PM Till Maas  wrote:

> Hi,
>
> On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
>
> > For transparency, we have published the full User Story list which is
> > linked within the blog and for ease of searching is here:
> > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>
> the user stories list does not seem to include the original user stories
> that I submitted regarding package life-cycle and permission management.
> These are requirements for dist-git but not necessarily for a git-forge.
> In the past they were fulfilled by package db, now pagure is solving
> this more.


We received a summarised User Story list from the Fedora Council, I would
suggest reaching out with your concerns.


> What is the plan for this in the future? Will there be a
> different solution instead of a git forge for this?


> Thank you
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


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

On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok  wrote:

> On 30. 03. 20 14:13, Neal Gompa wrote:
> > And unlike Alioth, we have*serious*
> > integration across the board with Pagure, and a good chunk of it is
> > not possible to implement in GitLab. Features we have in here were
> > designed to meet the needs of Fedorans that we will be forced to give
> > up.
>
> I want to stress out that recently we even got more of it. Several years
> after
> the PackageDB sunset, we are finally getting to a matching packager
> experience.
>
> (For example with the Bugzilla default assignee or the unorphan/unretire
> buttons.)
>
> Is this going to be possible with GitLab?


I don't have an answer to this as we haven't done that deep level of
tooling analysis and integration analysis yet.


> Will CPE implement this before we
> switch, or will GitLab be dumped on us and we will do toothless FESCo
> approved
> statements, such as "Missing Pagure features should be re-implemented in
> GitLab"?


CPE will take on a lot of the tooling work to ease the migration.


> What measures will be taken to prevent yet another "open a releng
> ticket and a human will do this while we automate stuff" era?
>
> --
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


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

On Mon, Mar 30, 2020 at 1:15 PM Neal Gompa  wrote:

> On Mon, Mar 30, 2020 at 7:56 AM Leigh Griffin  wrote:
> >
> > On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza <
> jla...@fedoraproject.org> wrote:
> >>
> >> Sincelery, after reading the initial announcement, I was expecting a
> >> more visible and open to the community discussion scenario.
> >> >
> >> > For transparency, we have published the full User Story list which is
> >> > linked within the blog and for ease of searching is
> >> > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> >> >
> >> > This thread is also part of the open conversation on the decision.
> >>
> >> No, this is a post decision conversation, not the promised open and live
> >> discussions *during* the process.
> >
> >
> > We haven't ironed out the full details but what was incredibly clear to
> us was that Gitlab was the decision to make. The next step in getting there
> is what we are engaging in now to get thoughts and suggestions and expect
> several threads in that capacity from a technical perspective in the coming
> weeks and months.
>
> But that's the problem. It *wasn't* clear to all of us in Fedora and
> CentOS communities. This is why I'm upset about this more than
> anything else. This is a post-decision conversation that didn't follow
> the "open decision-making process" that you had described earlier.
>

We followed the process as laid out, we had open discussions of the problem
and concluded the ideation phase with a set of requirements delivered by
Ben Cotton on behalf of the Fedora Community. We are now engaging openly on
what the challenges and next steps are.

>
> You've made the decision that we're going to move to GitLab in a way
> that feels like we were only given lip service to. You also gave no
> chance for the Pagure community to respond to meet those needs in a
> way that we wouldn't be required to move to GitLab.


I'm unsure where you got the impression that there was an opportunity for
either Forge to respond to meet future needs? The exercise looked at our
short term needs and our long term investment. Had Pagure been the right
choice on both fronts, we would have engaged with the Pagure community to
bridge the feature gap.


> I would have been
> happier if you had said: "at this current time, GitLab makes sense for
> us. We will engage with GitLab to figure out some more details, but
> here are the things we considered critical gaps. Since we're not
> making this move this year anyway, if these gaps can be closed by the
> end of the year, we will consider staying on Pagure instead of going
> forward with a plan of a GitLab migration."
>

That sounds reasonable when taken in a vacuum. We have needs to service as
a team and delaying a decision by a year or more to possibly solve some of
the technical problem isn't going to change the operational overhead that
some of the requirements is mandating. They were requirements we didn't
quiet fully grasp until we carried out the exercise. It is our intention to
have something stood up on Gitlab in the coming weeks and made available
for consumption by our Communities and team ASAP.


> It feels like "welp GitLab because GitLab", ignoring that many folks
> in Fedora did not want GitLab.


The requirements presented to us by the Fedora Community made no reference
to Gitlab or Pagure so this was not a case of Gitlab because. If anything,
and as I stated in another reply, Github ticked more boxes.


> It's like the Debian Alioth replacement
> process all over again. And unlike Alioth, we have *serious*
> integration across the board with Pagure, and a good chunk of it is
> not possible to implement in GitLab. Features we have in here were
> designed to meet the needs of Fedorans that we will be forced to give
> up.
>
> We aim to keep feature parity and any gaps in requirements or tooling will
be put forward to Gitlab for their roadmap integreations.

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


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


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

Re: Schedule for Mondays's FESCo Meeting (2020-03-30)

On Mon, Mar 30, 2020 at 01:32:54PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
> irc.freenode.net.
> 
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
> 
> or run:
>   date -d '2020-03-30 15:00 UTC'
> 
> NOTE: DAYLIGHT SAVINGS TIME CHANGE OVER THE PAST WEEKEND
> 
> 
> Links to all issues to be discussed can be found at: 
> https://pagure.io/fesco/report/meeting_agenda
> 
> = Discussed and Voted in the Ticket =
> 
> #2357 Python 2 exception (build-time-only) for ardour5
> APPROVED (+3, 0, -0)
> 
> 
> = Followups =
> 
> 
> = New business =
> 
> #2358 Drop the restriction on tagging for fedora-release
> https://pagure.io/fesco/issue/2358
> 
> #2360 RPM 4.16 and sqlite db changes for Fedora 33 
> https://pagure.io/fesco/issue/2360

Let's also add this to the agenda:

DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories despite "rpm 
--import"-ing the keys first
https://bugzilla.redhat.com/show_bug.cgi?id=1768206

Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

> = Open Floor = 
> 
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
> 
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Mondays's FESCo Meeting (2020-03-30)


Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-03-30 15:00 UTC'

NOTE: DAYLIGHT SAVINGS TIME CHANGE OVER THE PAST WEEKEND


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2357 Python 2 exception (build-time-only) for ardour5
APPROVED (+3, 0, -0)


= Followups =


= New business =

#2358 Drop the restriction on tagging for fedora-release
https://pagure.io/fesco/issue/2358

#2360 RPM 4.16 and sqlite db changes for Fedora 33 
https://pagure.io/fesco/issue/2360


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 32 Build failures on non-x86 arch - tlog

2020-03-30 Thread Dan Horák

On Mon, 30 Mar 2020 09:16:46 -0400
Justin Stephenson  wrote:

> Hello,
> 
> I received an email notification that some builds of the 'tlog'
> package are failing on aarch64 and ppc64le, with a link provided
> below:
> 
> https://koschei.fedoraproject.org/package/tlog?collection=f32
> 
> However, on my local system these builds are successful when I run
> 'fedpkg scratch-build'.
> 
> Is this something I need to investigate further? I'm not familiar with
> this tooling, Is there a way to trigger a re-run on Koschei ?

AFAIK it's gcc and annobin being out-of-sync in F-32 for a while, it
should be already fixed


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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-30 Thread Tomas Orsava


On 3/30/20 2:33 PM, Petr Pisar wrote:

On Mon, Mar 30, 2020 at 01:57:22PM +0200, Miro Hrončok wrote:

On 30. 03. 20 13:52, Petr Pisar wrote:

If I undeestand the proposal correctly there there will be an ELN branch or
a name space. But not by default. Only for those packages that reject the
change in Fedora.

I wonder where is this coming from, because that's exactly what we want and
exactly what the change owners don't want.


That's my impression from Alexandra's replies. I think she wrote that packages
that must significantly differ from Fedora will have an ELN override. So
I conclude their sources must be somewhere stored. And since Koji does not
allow building from a non-dist-git, It must be in the dist-git.



The way I understood it, the "ELN override" Alexandra described was 
using `%if %rhel` (or sometimes `%if %eln`) conditionals directly on the 
master branch.


Tomas




I frankly cannot see how the create-a-pull-request-and-wait-for-the-merge
procedure would scale if the ELN maintainer would need to adjust more than
a few packages.

The easiest way would be probably allow building ELN from pull-requests. But
the maintainability would be terrible.

-- Petr

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

Hi,

On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:

> For transparency, we have published the full User Story list which is
> linked within the blog and for ease of searching is here:
> https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8

the user stories list does not seem to include the original user stories
that I submitted regarding package life-cycle and permission management.
These are requirements for dist-git but not necessarily for a git-forge.
In the past they were fulfilled by package db, now pagure is solving
this more. What is the plan for this in the future? Will there be a
different solution instead of a git forge for this?

Thank you
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

Fedora 32 Build failures on non-x86 arch - tlog

2020-03-30 Thread Justin Stephenson

Hello,

I received an email notification that some builds of the 'tlog'
package are failing on aarch64 and ppc64le, with a link provided
below:

https://koschei.fedoraproject.org/package/tlog?collection=f32

However, on my local system these builds are successful when I run
'fedpkg scratch-build'.

Is this something I need to investigate further? I'm not familiar with
this tooling, Is there a way to trigger a re-run on Koschei ?

Thanks in advance.

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

On Mon, Mar 30, 2020 at 9:00 AM Miro Hrončok  wrote:
>
> On 30. 03. 20 14:13, Neal Gompa wrote:
> > And unlike Alioth, we have*serious*
> > integration across the board with Pagure, and a good chunk of it is
> > not possible to implement in GitLab. Features we have in here were
> > designed to meet the needs of Fedorans that we will be forced to give
> > up.
>
> I want to stress out that recently we even got more of it. Several years after
> the PackageDB sunset, we are finally getting to a matching packager 
> experience.
>
> (For example with the Bugzilla default assignee or the unorphan/unretire 
> buttons.)
>
> Is this going to be possible with GitLab? Will CPE implement this before we
> switch, or will GitLab be dumped on us and we will do toothless FESCo approved
> statements, such as "Missing Pagure features should be re-implemented in
> GitLab"? What measures will be taken to prevent yet another "open a releng
> ticket and a human will do this while we automate stuff" era?
>

And for what it's worth, the only remaining feature gap from PackageDB
is in the process of being implemented in Pagure (per branch ACLs):
https://pagure.io/pagure/pull-request/4786

Once that's done, we'll have *total* parity with the previous packager
experience.



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

Re: CPE Git Forge Decision


On 30. 03. 20 14:13, Neal Gompa wrote:

And unlike Alioth, we have*serious*
integration across the board with Pagure, and a good chunk of it is
not possible to implement in GitLab. Features we have in here were
designed to meet the needs of Fedorans that we will be forced to give
up.


I want to stress out that recently we even got more of it. Several years after 
the PackageDB sunset, we are finally getting to a matching packager experience.


(For example with the Bugzilla default assignee or the unorphan/unretire 
buttons.)

Is this going to be possible with GitLab? Will CPE implement this before we 
switch, or will GitLab be dumped on us and we will do toothless FESCo approved 
statements, such as "Missing Pagure features should be re-implemented in 
GitLab"? What measures will be taken to prevent yet another "open a releng 
ticket and a human will do this while we automate stuff" era?


--
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

Re: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)

2020-03-30 Thread Miroslav Suchý

Dne 27. 03. 20 v 8:55 Zbigniew Jędrzejewski-Szmek napsal(a):
> In current "offline upgrade" scheme, the upgrade
> tools are running on the real system, with udev active. 

How the "offline upgrade" works under hood? Do I understand correctly that even 
"offline ugprade" will have problem with
upgrade from F32 to F33 because of rpmdb?
-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ELN Buildroot and Compose V2

2020-03-30 Thread Petr Pisar

On Mon, Mar 30, 2020 at 01:57:22PM +0200, Miro Hrončok wrote:
> On 30. 03. 20 13:52, Petr Pisar wrote:
> > If I undeestand the proposal correctly there there will be an ELN branch or
> > a name space. But not by default. Only for those packages that reject the
> > change in Fedora.
> 
> I wonder where is this coming from, because that's exactly what we want and
> exactly what the change owners don't want.
> 
That's my impression from Alexandra's replies. I think she wrote that packages
that must significantly differ from Fedora will have an ELN override. So
I conclude their sources must be somewhere stored. And since Koji does not
allow building from a non-dist-git, It must be in the dist-git.

I frankly cannot see how the create-a-pull-request-and-wait-for-the-merge
procedure would scale if the ELN maintainer would need to adjust more than
a few packages.

The easiest way would be probably allow building ELN from pull-requests. But
the maintainability would be terrible.

-- Petr


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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2

2020-03-30 Thread Tomas Orsava

On 3/30/20 12:54 PM, Aleksandra Fedorova wrote:

On Mon, Mar 30, 2020 at 11:11 AM Vít Ondruch wrote:

It is kind of irony, that the ELN branch idea is still rejected.

I've made several attempts to explain this decision. You are ignoring them.

Therefore there will be PRs coming from Stephen's and Alexandra's (or
anybody else in ELN SIG) forks of packages, containing changes needed to
build some packages in ELN, which nobody is going to merge. In the
meantime, the ELN builds will keep failing.

I wonder why there can't be PR's coming from ELN branch. That would

1) Allow the ELN builds to pass.

2) Audit the work to do.

3) Give it some structure and therefore discoverability.

Just to be clear, I don't plan to accept any PR adding any "if rhel" and
similar into package I currently maintain in Fedora, sorry. Being
maintainer in Fedora and RHEL, I could have done it any time and I did
not. In every package I adopted/inherited during the years, I have
removed such conditionals, because they are PITA. While the proposal
helps with the maintenance of such conditionals, it would still harm
freedom of Fedora to innovate. I understand what is the cost and it is
not worth of it.

To be honest, I see a completely different kind of irony here.

For years Fedora packagers have to deal with nonresponsive upstreams.

How often we go to upstream developers, trying to convince them to
remove bundled libraries, adjust the licensing, to add a configuration
option, to split into subcomponents, to stop hardcoding docker in
their build system..
We know this struggle, we talk about it a lot, we discuss how we can
make upstream to listen to us, how we should help each other..

The changes you list benefit upstream (as well as downstream), so of
course it's reasonable to merge them there.
But I don't think anyone of us expects upstreams to merge
downstream-only changes. And that's exactly what you're proposing. So
this argument feels a bit disingenuous to me.

Tomas

And then, when we play the role of the upstream, we completely forget about it.

Now, I understand people's concerns about merging some downstream
specific changes into the upstream sources without proper design or
without agreement. And we highlighted several times that we are not
going to do that.

But the fact that I need to convince Fedora packagers that they should
at least listen to the problem downstream has, and at least try to
think about how it can be addressed, through conditionals or through
refactoring, or through upstream changes.. this surprises me. I
definitely didn't expect the "don't even try to bother me with those
topics" reaction.

Vít

Dne 27. 03. 20 v 16:07 Stephen Gallagher napsal(a):

There has been a lot of (really good!) discussion on the original
proposal thread, but as it has grown too large to follow anymore, I'm
restarting it. I have made numerous changes to the Change Proposal
page to improve the scope of the proposal as well as clarify some of
the questions that have come up repeatedly in the original thread.

Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].

== Summary ==
ELN is a new buildroot and compose process for Fedora that will take
Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
compose. Feedback from this build, compose and integration testing
will be provided to Fedora packagers so that they can see the
potential impact of their changes on RHEL development.

== Owner ==

* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: al...@bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgall...@redhat.com

[1] List of changes between the original and new versions:
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569655&oldid=569549
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to

devel-announce-le...@lists.fedoraproject.org

Fedora Code of Conduct:

https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/devel-annou...@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 Guideline

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

On Mon, Mar 30, 2020 at 8:13 AM Nicolas Mailhot via devel
 wrote:
>
> Le dimanche 29 mars 2020 à 23:47 -0400, Neal Gompa a écrit :
> >
> > > As a General User
> > > I want to access repos fully over https
> > > For environments where SSH is blocked
> >
> > I would be really curious if the Red Hat Infrastructure Security guys
> > have changed their opinion on this after four years of blocking the
> > development of this feature in Pagure. The two major reasons we don't
> > have this in Pagure are:
>
> Neal,
>
> Security is the usual excuse not to implement stuff. That does not work
> when competing with others that did their homework. As you noted
> yourself ssh accesss is not blameless either.
>
> Gitlab and Github work in https mode. Pagure does not. End of story.
>
> Expecting others to hole their security with corkscrew because of the
> ssh holy cow was never going to impress any third party.
>

You don't have to tell me, I already know. It was intentionally not
implemented. And even with all that, we *do* have HTTPS through SSO on
src.fp.o. We just don't have it on pagure.io. Don't expect it to be
available with the move to GitLab. GitLab admins have a toggle they
can use to disable HTTPS pushing for policy reasons, and I will
strongly bet on it being flipped so that HTTPS pushing will not be
available in our GitLab.



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

Re: CPE Git Forge Decision

On Mon, Mar 30, 2020 at 7:56 AM Leigh Griffin  wrote:
>
> On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza 
>  wrote:
>>
>> Sincelery, after reading the initial announcement, I was expecting a
>> more visible and open to the community discussion scenario.
>> >
>> > For transparency, we have published the full User Story list which is
>> > linked within the blog and for ease of searching is
>> > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>> >
>> > This thread is also part of the open conversation on the decision.
>>
>> No, this is a post decision conversation, not the promised open and live
>> discussions *during* the process.
>
>
> We haven't ironed out the full details but what was incredibly clear to us 
> was that Gitlab was the decision to make. The next step in getting there is 
> what we are engaging in now to get thoughts and suggestions and expect 
> several threads in that capacity from a technical perspective in the coming 
> weeks and months.

But that's the problem. It *wasn't* clear to all of us in Fedora and
CentOS communities. This is why I'm upset about this more than
anything else. This is a post-decision conversation that didn't follow
the "open decision-making process" that you had described earlier.

You've made the decision that we're going to move to GitLab in a way
that feels like we were only given lip service to. You also gave no
chance for the Pagure community to respond to meet those needs in a
way that we wouldn't be required to move to GitLab. I would have been
happier if you had said: "at this current time, GitLab makes sense for
us. We will engage with GitLab to figure out some more details, but
here are the things we considered critical gaps. Since we're not
making this move this year anyway, if these gaps can be closed by the
end of the year, we will consider staying on Pagure instead of going
forward with a plan of a GitLab migration."

It feels like "welp GitLab because GitLab", ignoring that many folks
in Fedora did not want GitLab. It's like the Debian Alioth replacement
process all over again. And unlike Alioth, we have *serious*
integration across the board with Pagure, and a good chunk of it is
not possible to implement in GitLab. Features we have in here were
designed to meet the needs of Fedorans that we will be forced to give
up.

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

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

2020-03-30 Thread Nicolas Mailhot via devel

Le dimanche 29 mars 2020 à 23:47 -0400, Neal Gompa a écrit :
> 
> > As a General User
> > I want to access repos fully over https
> > For environments where SSH is blocked
> 
> I would be really curious if the Red Hat Infrastructure Security guys
> have changed their opinion on this after four years of blocking the
> development of this feature in Pagure. The two major reasons we don't
> have this in Pagure are:

Neal,

Security is the usual excuse not to implement stuff. That does not work
when competing with others that did their homework. As you noted
yourself ssh accesss is not blameless either.

Gitlab and Github work in https mode. Pagure does not. End of story.

Expecting others to hole their security with corkscrew because of the
ssh holy cow was never going to impress any third party.

Regards,

-- 
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

Re: Nvidia binary drivers fail to install on Fedora 32

2020-03-30 Thread Richard Shaw

On Mon, Mar 30, 2020 at 1:54 AM Marius Schwarz 
wrote:

> Am 29.03.20 um 18:24 schrieb Kevin Kofler:
> >
> > RPM Fusion used to provide compiled kmod packages for years, and those
> just
> > worked. (Well, for the proprietary ones, they only worked as well as
> > proprietary drivers work to begin with, but that was no fault of the
> kmod
> > packages.) So why and when did that stop?
>
> The precompiled kmod-nvidia packages where hell, because they sometimes
> needed days to get online.
> While people where waiting, the system did not boot into the newest
> kernel as the needed driver was missing.
>
> akmod is the much better solution for this.
>

Yes, some sort of automated solution would only work if the kernel stopped
breaking the builds so often, requiring manual intervention. Lately I've
gotten a new kernel on my Fedora 31 install almost every update. It's just
too much to deal with. RPM Fusion has a small fraction of both the
infrastructure and volunteers as Fedora.

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

2020-03-30 Thread Julen Landa Alustiza



20/3/30 13:43(e)an, Leigh Griffin igorleak idatzi zuen:
> 
> 
> On Mon, Mar 30, 2020 at 12:24 PM Iñaki Ucar  > wrote:
> 
> On Mon, 30 Mar 2020 at 13:10, Leigh Griffin  > wrote:
> >
> > On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar
> mailto:iu...@fedoraproject.org>> wrote:
> >>
> >> So I was also waiting for those open discussions about the
> >> requirements gathered.
> >
> > We had several threads on them from the Fedora perspective on both
> devel and council lists.
> 
> Yet again: threads on requirements gathering, not on the merits of the
> final User Story list. 
> 
>  
> A merits based discussion whereby multiple stakeholders have a totally
> different view and use case for a Forge is impossible to facilitate.
> What is valuable to you and your use case might not be valuable to other
> users and vice versa. I'm happy to have a conversation about any
> individual requirements but the reality is any that made the list are
> valid requirements from a stakeholder perspective and it's not up to me
> or anyone to challenge that assertion.
As I asked before on this thread, I would like to know how are you
planning to fullfill the SLA requirement while the SLE from CPE for the
services like AAA that the forge will require to function is lower than
the required SLA for the forge itself.
>  
> 
> That's what several of us were expecting. I
> don't think it's too hard too understand. You can say "no, that wasn't
> part of the process", but then, sorry, you didn't communicate that
> effectively.
> 
> > I'm sorry this is disappointing but even reading the analysis by
> Neal it is looking at the merit of the requirement and not looking
> at the fact that it is valuable to somebody. Each stakeholder group
> had their own means to discuss and debate the merits and had them
> rolled into CPE who in turn analysed them and published the full
> story list.
> 
> Two things are obvious here: 1) not all the requirements can be met
> (you already stated this), and 2) not all requirements have the same
> importance. So yes, of course Neal is looking at the merit of every
> single requirement, and that's your job too. What if I say that is
> valuable to me that the GitHub logo is on top of the interface? Is
> that something that should be taken into account just because it's
> valuable to somebody?
> 
> 
> If that came up as a UI requirement then yes we would have taken it on
> board, would have documented it and would have presented it in the final
> list of unique user stories we gathered. Would it be weighed equally
> with a more core functional requirement? The answer is of course no but
> we would have respected that request. 
> 
> The Fedora specific requirements (as I am on the Fedora lists here) had
> very few unique needs such that both Gitlab and Pagure would have
> satisfied their desire. Either Forge would have been satisfied the
> requirements we received and we ultimately opted for Gitlab based on a
> more holistic view of the stakeholder needs.
> 
> 
> Iñaki
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> 
> -- 
> 
> Leigh Griffin
> 
> Engineering Manager
> 
> Red Hat Waterford 
> 
> Communications House
> 
> Cork Road, Waterford City
> 
> lgrif...@redhat.com     
> M: +353877545162      IM: lgriffin
> 
> @redhatjobs    redhatjobs
>  @redhatjobs
>   
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

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

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

2020-03-30 Thread Solomon Peachy

On Mon, Mar 30, 2020 at 12:45:59PM +0100, Leigh Griffin wrote:
> We done that as a Management team and with our Product Owner among other
> stakeholders. We did evaluate the merit of the requirements from a
> practicality perspective but we did not question or force our opinion on
> the validity of their asks, as we respect that it serves some demographic
> of their stakeholder group. I don't feel it's appropriate for one
> stakeholder group to criticise or attack the merits of a requirement from
> another group, that's the essence of my point.

He's not saying their opinions or asks are invalid or are without some 
merit, just that one has to evaluate those asks *in some greater 
context* to determine if they should influence the final decision.

That "evaluation" and (even the "greater context") seems to have gone 
completely missing here, and no, whatever went on in a disused lavatory 
behind a sign that says "beware of leopard" doesn't count.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Upgrade tooling

2020-03-30 Thread Nicolas Mailhot via devel

> On 3/28/20 8:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > 
> > Yes, that is an important hurdle that Fedora generally doesn't
> > encounter
> > at all. Fedora usually waits until the new rpm functionality is
> > released
> > in older versions of Fedora before allowing it to be used in
> > rawhide.

Fortunately, that’s not the usual case. Any part of rpm that we refuse
to use, before it is available in older version of Fedora, is a part
that will bitrot and is unlikely to be ever used in Fedora.

Waiting does not make it more stable. Waiting makes sure the people
that were interested in the feature in the first place will move away.
Leaving rpm upstream with an untested feature no one wants to touch.

That would be even more braindamaged than forbidding the use of gcc
features not present in older versions. At least gcc sees some use dev-
side. But who is going to exercise packaging tools if packagers are
forbiddent to use them?

That being said, yes Fedora has been a terrible rpm stackaholder. That
has hurt both Fedora and rpm upstream. Half the NIH reinventing
packaging tools people just can not stand the delays associated with
rpm feature deployments.

Regards,

-- 
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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2