Re: Let's revisit the FTBFS policy

[Vít Ondruch]

Dne 14. 08. 19 v 19:43 Miro Hrončok napsal(a):
> On 14. 08. 19 19:22, Ben Cotton wrote:
>> I want to publicly express my appreciation for Miro's efforts to
>> enforce our policy and his willingness to take the hits from people
>> being rightly upset at its flaws. I also appreciate that the community
>> has done a good job of understanding that the policy is the problem
>> and not making it a personal attack on Miro.
>
> Thanks. Support like this is greatly appreciated.
>
>> On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III
>>  wrote:
>>>
 "MH" == Miro Hrončok  writes:
>>>
>>> MH> If we stop here, the current "setting to ASSIGNED to stop this"
>>> MH> remains a problem.
>>>
>>> Let's think about why this is perceived as a problem.  The maintainer
>>> has performed an affirmative act that shows they noticed.  Can't we
>>> just
>>> accept that as some statement of intent and stop bugging them at that
>>> point?
>>
>> This is a reasonable compromise to make, IMO. In a perfect world, we'd
>> have enough active packagers to handle things in a timely manner. But
>> in this world, people have a lot going on and there's only so much we
>> can do. People setting a bug to ASSIGNED is a problem I'm willing to
>> accept. If there's an exceptional case, we can say FESCo has the
>> ability to step in and remove it. We should assume positive intent
>> with maintainers and trust that they're doing the right thing.
>
> What if... we only allow swaying FTBFS bugs under the carpet for a
> certain period of time?
>
> E.g.
>
>  1. Mass rebuild for Fedora N happens
>  2. Packages that fail to build get open bugzillas
>  3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly
> reminders
>  4. If the package hasn't rebuilt for a certain number of releases, it
> is flagged for removal despite the bug status.
>
> Of course the removal would still need to be communicated properly,
> but I suspect only a couple of packages would fall into that category.
>
> I suppose that at a time of a release of Fedora version, all shipped
> packages should have been rebuilt on a platform that was supported on
> the time of the release.
>
> E.g. when we release Fedora 32, Fedora 28 is already EOL for 5 months.
> It is IMHO reasonable to expect the packages were rebuilt at least on
> Fedora 29.
>
> That would effectively mean:
>
> 0. package built with .fc29 release tag before the mass rebuild
> 1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
> 2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
> 3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, kind warning
> 4. Fedora 32 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
> 5. Fedora 32 branches, package still fails to build, we retire it
>
> Or:
>
> 0. package built with .fc28 release tag before F28 branching
> 1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
> 2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, kind warning
> 3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
> 4. Fedora 31 branches, package still fails to build, we retire it
>
> That gives 1.5 years minimum (F28 branching to F31 branching) to fix a
> FTBFS. Is that reasonable?
>
> (With a possibility to request an exception in exceptional cases.)
>
> The policy is also easy enough to define:
>
> "Rawhide packages with latest successful build made in Fedora N are
> retired from master after Fedora N+3 branches."
>

Well, really, I don't see the ASSIGNED as that big deal. That at least
means the maintainer is alive and paying (some) attention and that is
important. In the end, you can't prevent such maintainer to unretire the
FTBFS package and tag it back into Fedora.

Also, in my case "rubygems" package was retired. The interesting part
here is that the binary package build from "rubygems" SRPM was not even
part of compose, so some of the proposals to remove such packages from
compose would not apply here.

Now you might wonder why we had "rubygems" package in Fedora. Partly, it
is historic reason. It used to be independent project you probably
wanted to install alongside Ruby. As the time goes, the RubyGems were
bundled into Ruby. So now "ruby" package provides "rubygems" package.
But RubyGems are still doing independent releases out of Ruby schedule.
So the "rubygems" package gives us easy way to update RubyGems in Ruby
without updating Ruby itself and adding some additional sources etc.
There was no reason to do this in more than year, that's why I did not
bother to fix the FTBFS. Now the package is retired.

Of course you might consider this special case, but apparently all the
other people who speak up had different special cases.


Vít

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

Schedule for Thursday's FPC Meeting (2019-08-15 16:00 UTC)

[James Antill]

Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2019-08-15 16:00 UTC in #fedora-meeting-1 on 
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2019-08-15 09:00 PDT  US/Pacific
2019-08-15 12:00 EDT  --> US/Eastern <--
2019-08-15 16:00 UTC  UTC   
2019-08-15 17:00 BST  Europe/London 
2019-08-15 18:00 CEST Europe/Berlin 
2019-08-15 18:00 CEST Europe/Paris  
2019-08-15 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2019-08-16 00:00 HKT  Asia/Hong_Kong
2019-08-16 00:00 +08  Asia/Singapore
2019-08-16 01:00 JST  Asia/Tokyo
2019-08-16 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followups =

#topic #902 Cleanup & enhance spec files 
.fpc 902
https://pagure.io/packaging-committee/issue/902

#topic #904 Caret versioning 
.fpc 904
https://pagure.io/packaging-committee/issue/904

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

#topic #914 Automatic R runtime dependencies
.fpc 914
https://pagure.io/packaging-committee/issue/914

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * 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: Why retire Python 2 packages and games that still work to end user ?

[Nico Kadel-Garcia]

On Wed, Aug 14, 2019 at 4:31 PM Kevin Kofler  wrote:
>
> David Sommerseth wrote:
> > Instead of spending time and resources keeping old stuff alive longer than
> > needed, rather spend that energy on porting the old Python 2 over to
> > Python 3. In the long run, this will result in far less work over time.
>
> It is not practical to get all the legacy Python 2 code ported over to
> Python 3. Keeping Python 2 (or something backwards-compatible with it such
> as Tauthon) available is actually the much more scalable approach.
>
> Your scorched earth approach will lose a lot of software that has no
> replacement and that users rely on.

I've been seeing migrations like this for d decades, with major
releases of many software tools. Preserving legacy versions, forever,
is the precise opposite of "scalable".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: friday roundup of failing images in rawhide

[Robert-André Mauchin]

On Friday, 2 August 2019 03:24:44 CEST Luya Tshimbalanga wrote:
> 
> It appears the current packaged version is far behind the upstream
> release. It would be nice a proven package release an updated version.
> 
> 
> Luya

Since I handled the previous update and have already one of the dependency 
under my wing, I am handling the update to 3.28. I got the missing dependency 
soup-sharp packaged. I'll try to get comaintainership for Sparkleshare later.

Robert-André
(FAS: eclipseo)

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

[HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Miro Hrončok]

Hello, in order to deliver Python 3.8, we are running a coordinated rebuild in a 
side tag.


    https://fedoraproject.org/wiki/Changes/Python3.8

If you see a "Rebuild for Python 3.8" commit in your package, please don't 
rebuild it in regular rawhide.

If you need to, please let me know, so we can coordinate.

If you'd like to update the package, you should be able to build it in the side 
tag via:


    on branch master:
    $ fedpkg build --target=f32-python

Note that it will take a while before the essential packages are rebuilt, so 
don't except all your dependencies to be available right away.


Thanks. Let us know if you have any questions.
--
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: RFC: Drop lz4-static

[Jason L Tibbitts III]

> "DS" == David Sommerseth  writes:

DS> As I can see it, there is little benefit of removing lz4-static.

Isn't that entirely the decision of those maintaining the package?  It's
still completely reasonable if they want to remove it for no other
reason than it eliminates ten lines from the specfile.  The question was
whether there is any pressing reason to refrain from removing it.

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

Re: Unretire linuxconsoletools package

[Marcin Zajaczkowski]

Thanks Vascom. I've just found my fpc based build failing in Rawhide due to 
that.

Marcin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Why retire Python 2 packages and games that still work to end user ?

[Stephen John Smoogen]

On Wed, 14 Aug 2019 at 16:31, Kevin Kofler  wrote:
>
> David Sommerseth wrote:
> > Instead of spending time and resources keeping old stuff alive longer than
> > needed, rather spend that energy on porting the old Python 2 over to
> > Python 3. In the long run, this will result in far less work over time.
>
> It is not practical to get all the legacy Python 2 code ported over to
> Python 3. Keeping Python 2 (or something backwards-compatible with it such
> as Tauthon) available is actually the much more scalable approach.
>
> Your scorched earth approach will lose a lot of software that has no
> replacement and that users rely on.
>

And your daily rants about everything wrong everyone else does loses a
lot of people who want to work on Fedora. The current python
maintainers have said multiple times that they would be happy if
someone took over python2 once it is completely EOL. You can take it
over just like qt3 and no one has to worry about it anymore.


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



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

Re: Unretire txt2tags package?

[Miro Hrončok]

On 14. 08. 19 22:52, Christoph Junghans wrote:

Do I need a review to unretire this package?


No. It was not retired for 8 weeks.

--
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: Unretire txt2tags package?

[Christoph Junghans]

On Wed, Aug 14, 2019 at 12:20 PM Miro Hrončok  wrote:
>
> On 14. 08. 19 20:03, Christoph Junghans wrote:
> > Hi,
> >
> > txt2tags was recently retired due to FTBFS
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1676168) as it requires
> > python2.
>
> Just a note: We haven't retired any package just because it requires python2
> (not yet anyway).
You are correct, I see it now.

The FTBFS fix is actually trivial:
diff --git a/txt2tags.spec b/txt2tags.spec
index ebb78e3..38ea2e4 100644
--- a/txt2tags.spec
+++ b/txt2tags.spec
@@ -54,6 +54,7 @@ rm -rf %{buildroot}

 #Install the executable
 install -Dp -m0755 txt2tags %{buildroot}%{_bindir}/txt2tags
+sed -i '1s/python/&2/' %{buildroot}%{_bindir}/txt2tags

 #Install manpages
 install -Dp -m0644 doc/manpage.man %{buildroot}%{_mandir}/man1/txt2tags.1

Do I need a review to unretire this package?

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



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Why retire Python 2 packages and games that still work to end user ?

[Miro Hrončok]

On 14. 08. 19 22:28, Kevin Kofler wrote:

It is not practical to get all the legacy Python 2 code ported over to
Python 3. Keeping Python 2 (or something backwards-compatible with it such
as Tauthon) available is actually the much more scalable approach.


We are keeping the Python 2 interpreter.
We are also keeping PyPy 2.7.
You can also package Tauthon if you want to.

It's the packages with the ecosystem that we want to get rid of.

--
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: RFC: Drop lz4-static

[David Sommerseth]

On 14/08/2019 07:49, Igor Gnatenko wrote:
> Hello,
> 
> I found out that nothing in Fedora depends on lz4-static (neither
> runtime nor buildtime). Is anybody using it or I'm free to drop it?
> 
> Any thoughts?

Ehm ... This is a _static_ library.  Which means you can build against it,
uninstall the lz4-static RPM and the built application still runs.

What I'm trying to say that, even though no Fedora packages does not have a
build dependency on this package, there might be other users of this library
which does static builds of some binaries.

That said, static builds have their own challenges (mostly security related) -
but also use some real cases (like running code during early boot phase before
file systems with shared libraries are available).

So there been performed a good enough check that "nothing in Fedora depends on
[it]"?

Also consider that this is the static library is built by default, it is a
tiny library which is really fast to build and the built binaries are less
than a few megabytes all together.

As I can see it, there is little benefit of removing lz4-static.  But I might
overlook something.


-- 
kind regards,

David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Why retire Python 2 packages and games that still work to end user ?

[Kevin Kofler]

David Sommerseth wrote:
> Instead of spending time and resources keeping old stuff alive longer than
> needed, rather spend that energy on porting the old Python 2 over to
> Python 3. In the long run, this will result in far less work over time.

It is not practical to get all the legacy Python 2 code ported over to 
Python 3. Keeping Python 2 (or something backwards-compatible with it such 
as Tauthon) available is actually the much more scalable approach.

Your scorched earth approach will lose a lot of software that has no 
replacement and that users rely on.

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

Re: Let's revisit the FTBFS policy

[Miro Hrončok]

On 14. 08. 19 19:43, Miro Hrončok wrote:
E.g. when we release Fedora 32, Fedora 28 is already EOL for 5 months. It is 
IMHO reasonable to expect the packages were rebuilt at least on Fedora 29.


Oh. When we release Fedora 32, Fedora 29 is already EOL for 5 months. But the 
rest checks out. So the "rebuilt on a platform that was supported on the time of 
the release" doesn't really stand, but I still think the rest of the proposal 
makes sense. It gives a reasonable time to sway things while it makes sure:


 - FTBFS packages where the bug remains NEW are orphaned
 - We don't ship FTBFS packages forever
 - We don't "rip off" packages after "just 6 months"

--
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: Let's revisit the FTBFS policy

[Pavel Valena]

- Original Message -
> From: "Miro Hrončok" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, August 14, 2019 7:43:13 PM
> Subject: Re: Let's revisit the FTBFS policy
> 
> On 14. 08. 19 19:22, Ben Cotton wrote:
> > I want to publicly express my appreciation for Miro's efforts to
> > enforce our policy and his willingness to take the hits from people
> > being rightly upset at its flaws. I also appreciate that the community
> > has done a good job of understanding that the policy is the problem
> > and not making it a personal attack on Miro.
> 
> Thanks. Support like this is greatly appreciated.
> 
> > On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III 
> > wrote:
> >>
> >>> "MH" == Miro Hrončok  writes:
> >>
> >> MH> If we stop here, the current "setting to ASSIGNED to stop this"
> >> MH> remains a problem.
> >>
> >> Let's think about why this is perceived as a problem.  The maintainer
> >> has performed an affirmative act that shows they noticed.  Can't we just
> >> accept that as some statement of intent and stop bugging them at that
> >> point?
> > 
> > This is a reasonable compromise to make, IMO. In a perfect world, we'd
> > have enough active packagers to handle things in a timely manner. But
> > in this world, people have a lot going on and there's only so much we
> > can do. People setting a bug to ASSIGNED is a problem I'm willing to
> > accept. If there's an exceptional case, we can say FESCo has the
> > ability to step in and remove it. We should assume positive intent
> > with maintainers and trust that they're doing the right thing.
> 
> What if... we only allow swaying FTBFS bugs under the carpet for a certain
> period of time?
> 
> E.g.
> 
>   1. Mass rebuild for Fedora N happens
>   2. Packages that fail to build get open bugzillas
>   3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly
>   reminders
>   4. If the package hasn't rebuilt for a certain number of releases, it is
> flagged for removal despite the bug status.
> 
> Of course the removal would still need to be communicated properly, but I
> suspect only a couple of packages would fall into that category.
> 
> I suppose that at a time of a release of Fedora version, all shipped packages
> should have been rebuilt on a platform that was supported on the time of the
> release.
> 
> E.g. when we release Fedora 32, Fedora 28 is already EOL for 5 months. It is
> IMHO reasonable to expect the packages were rebuilt at least on Fedora 29.
> 
> That would effectively mean:
> 
> 0. package built with .fc29 release tag before the mass rebuild
> 1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
> 2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
> 3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, kind warning
> 4. Fedora 32 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
> 5. Fedora 32 branches, package still fails to build, we retire it
> 
> Or:
> 
> 0. package built with .fc28 release tag before F28 branching
> 1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
> 2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, kind warning
> 3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
> 4. Fedora 31 branches, package still fails to build, we retire it
> 
> That gives 1.5 years minimum (F28 branching to F31 branching) to fix a FTBFS.
> Is
> that reasonable?
> 
> (With a possibility to request an exception in exceptional cases.)
> 
> The policy is also easy enough to define:
> 
> "Rawhide packages with latest successful build made in Fedora N are retired
> from
> master after Fedora N+3 branches."

Yes, that sounds great!

Thanks for communicating this,
Pavel

> 
> --
> 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: Join the new Minimization Team

[Robbie Harwood]

> Here's the scriptlet:
>
> %triggerun libs -- krb5-libs < 1.15.1-5
> if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then
> sed -i '1i # To opt out of the system crypto-policies
> configuration of krb5,
> remove the\n# symlink at /etc/krb5.conf.d/crypto-policies which will
> not be
> recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf
> fi
> exit 0
>
> So... there's not actually a call to awk.  And the last version of
> Fedora to have anything older than 1.15.1 was F28.

Please CC maintainers when discussing their package.  We like it because
it avoids us getting blindsided by requirements/changes, and sometimes
we know things about our packages and can be helpful :)

There are two uses of awk: one at build-time, and one for the triggers.
I assume no one cares that I need awk to build.  You're correct that the
use for the triggers can probably go away since they're aren't any right
now, but... does this actually matter?  Please file a bugzilla if so.

> We don't supports updates from F28 to F31 (and certainly not updates
> from F28 when it was rawhide), so the scriptlet is no longer necessary
> at all.  It has come and gone a few times throughout history but the
> dependency has remained.

Just because something /can/ go doesn't mean it /should/.  A trigger
that doesn't fire won't hurt anything, and its removal is more noise to
filter through.  And there are often other considerations: for instance,
the el8 spec file is branched from the Fedora one - el7 has a
1.15-series krb5.  The upgrade window I have to support is larger than
what's mandated by Fedora - and that's fine!  It's not causing any
problems for other things, so it doesn't matter to anyone but me.

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: Why does anaconda-core runtime depend on python3-coverage?

[Adam Williamson]

On Wed, 2019-08-14 at 11:29 -0700, Brian C. Lane wrote:
> On Mon, Aug 12, 2019 at 08:44:24PM +0200, Igor Gnatenko wrote:
> > What is the point of this? I am probably missing something obvious..
> 
> I think this was because getting good coverage data from anaconda
> without actually booting the installer iso wasn't possible. atodorov may
> be able to provide more context.

was this possibly to do with the kickstart-tests effort - an attempt to
figure out the code coverage of those tests?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Why does anaconda-core runtime depend on python3-coverage?

[Brian C. Lane]

On Mon, Aug 12, 2019 at 08:44:24PM +0200, Igor Gnatenko wrote:
> What is the point of this? I am probably missing something obvious..

I think this was because getting good coverage data from anaconda
without actually booting the installer iso wasn't possible. atodorov may
be able to provide more context.

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Unretire txt2tags package?

[Miro Hrončok]

On 14. 08. 19 20:03, Christoph Junghans wrote:

Hi,

txt2tags was recently retired due to FTBFS
(https://bugzilla.redhat.com/show_bug.cgi?id=1676168) as it requires
python2.


Just a note: We haven't retired any package just because it requires python2 
(not yet anyway).


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

Unretire txt2tags package?

[Christoph Junghans]

Hi,

txt2tags was recently retired due to FTBFS
(https://bugzilla.redhat.com/show_bug.cgi?id=1676168) as it requires
python2.

txt2tags is still needed for some of my packages, e.g. votca-csg to
build manpages.

There is an python3 port of the last release by rednotebook (see
https://github.com/txt2tags/txt2tags/issues/207#issuecomment-461846655),
which we could package.

Any objections? Alternatively, we could disable the manpages in votca-csg.

Christoph





-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Let's revisit the FTBFS policy

[Miro Hrončok]

On 14. 08. 19 19:22, Ben Cotton wrote:

I want to publicly express my appreciation for Miro's efforts to
enforce our policy and his willingness to take the hits from people
being rightly upset at its flaws. I also appreciate that the community
has done a good job of understanding that the policy is the problem
and not making it a personal attack on Miro.


Thanks. Support like this is greatly appreciated.


On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III  wrote:



"MH" == Miro Hrončok  writes:


MH> If we stop here, the current "setting to ASSIGNED to stop this"
MH> remains a problem.

Let's think about why this is perceived as a problem.  The maintainer
has performed an affirmative act that shows they noticed.  Can't we just
accept that as some statement of intent and stop bugging them at that
point?


This is a reasonable compromise to make, IMO. In a perfect world, we'd
have enough active packagers to handle things in a timely manner. But
in this world, people have a lot going on and there's only so much we
can do. People setting a bug to ASSIGNED is a problem I'm willing to
accept. If there's an exceptional case, we can say FESCo has the
ability to step in and remove it. We should assume positive intent
with maintainers and trust that they're doing the right thing.


What if... we only allow swaying FTBFS bugs under the carpet for a certain 
period of time?


E.g.

 1. Mass rebuild for Fedora N happens
 2. Packages that fail to build get open bugzillas
 3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly reminders
 4. If the package hasn't rebuilt for a certain number of releases, it is 
flagged for removal despite the bug status.


Of course the removal would still need to be communicated properly, but I 
suspect only a couple of packages would fall into that category.


I suppose that at a time of a release of Fedora version, all shipped packages 
should have been rebuilt on a platform that was supported on the time of the 
release.


E.g. when we release Fedora 32, Fedora 28 is already EOL for 5 months. It is 
IMHO reasonable to expect the packages were rebuilt at least on Fedora 29.


That would effectively mean:

0. package built with .fc29 release tag before the mass rebuild
1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, kind warning
4. Fedora 32 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
5. Fedora 32 branches, package still fails to build, we retire it

Or:

0. package built with .fc28 release tag before F28 branching
1. Fedora 29 mass rebuild, package FTBFS, is ASSIGNED, nothing happens
2. Fedora 30 mass rebuild, package FTBFS, is ASSIGNED, kind warning
3. Fedora 31 mass rebuild, package FTBFS, is ASSIGNED, big fat warning
4. Fedora 31 branches, package still fails to build, we retire it

That gives 1.5 years minimum (F28 branching to F31 branching) to fix a FTBFS. Is 
that reasonable?


(With a possibility to request an exception in exceptional cases.)

The policy is also easy enough to define:

"Rawhide packages with latest successful build made in Fedora N are retired from 
master after Fedora N+3 branches."


--
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: Let's revisit the FTBFS policy

[Ben Cotton]

On Wed, Aug 14, 2019 at 1:31 PM Adam Williamson
 wrote:
>
> I actually think the consequences of the revival of the old policy have
> been fine. We are throwing out tons of cruft. Occasionally we find
> something very crufty yet important: this is a *good* outcome of the
> process. It alerts us to the fact that important stuff depends on
> something which is not being properly maintained and allows us to
> address that.
>
I'm sympathetic to this argument, and I agree that it produces a
better output in a vaccuum. My concern is the effect that this has on
the community. We rely on the volunteer labor of a lot of people, and
I think that obligates us to make compromises. Package retirements are
easily reversible; packager retirements are less so.

Part of the problem is that the policy went unenforced for so long. I
wonder if we've started enforcement too quickly. Leaving some
loopholes in place—and acknowledging that some people will take
advantage of them—may be a way to keep the impact on packagers low for
now. Then perhaps some of the packager experience initiatives that are
in the works can have time to come in and make a more aggressive
enforcement palatable.


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

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

I just tested hg-5.1.0 with the latest git version of hg-evolve on
python3 and at least some basic things seem to be working.  One
problem:
hg
*** failed to import extension hggit: No module named 'compat'

That's with the latest pip version of hg-git (0.8.12).

hg-git is a supported fedora package, so I think we need this to work.

On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka  wrote:
>
>
>
> On 12. 08. 19 22:36, Miro Hrončok wrote:
> > On 12. 08. 19 20:37, Petr Stodulka wrote:
> >> Can you explain better what do you mean by that? I am little lost
> >> here.
> >
> > Sure. The idea was:
> >
> > 1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch 
> > to rawhide (Fedora 32)
> >
> > 2) See what happens, collect feedback.
> >
> > 3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide 
> > whether this is worth pushing to F31 (probably not)
> >
> > 4) Soon before F32 mass Python 2 removal flag day (scheduled for mid 
> > November [2]), decide whether to revert and request and exception or not
> >
> > [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> > [2] 
> > https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> >
>
> Thanks Miro for explanation. That sounds asi the best idea now probably. From 
> that point, I will not create new subpackages for Py2 / Py3 and I will just 
> do the switch tomorrow.
>
> @mercurial-maintainers: if anyone have something against or better solution, 
> answer here guys, otherwise I will do the rebase.
> Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because of 
> PTO. So in case of troubles, I will not be able to do anything during that 
> time. From that point, I could postpone the rebase if needed, but I hope that 
> someone else will be able to help around instead of me in case of troubles.
>
> --
> Petr Stodulka
> OS & Application Modernization
> IRC nicks: pstodulk, skytak
> Software Engineer
> Red Hat Czech s.r.o.



-- 
Those who don't understand recursion are doomed to repeat 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: Let's revisit the FTBFS policy

[Adam Williamson]

On Wed, 2019-08-14 at 13:22 -0400, Ben Cotton wrote:
> I want to publicly express my appreciation for Miro's efforts to
> enforce our policy and his willingness to take the hits from people
> being rightly upset at its flaws. I also appreciate that the community
> has done a good job of understanding that the policy is the problem
> and not making it a personal attack on Miro.
> 
> On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III  
> wrote:
> > > > > > > "MH" == Miro Hrončok  writes:
> > 
> > MH> If we stop here, the current "setting to ASSIGNED to stop this"
> > MH> remains a problem.
> > 
> > Let's think about why this is perceived as a problem.  The maintainer
> > has performed an affirmative act that shows they noticed.  Can't we just
> > accept that as some statement of intent and stop bugging them at that
> > point?
> 
> This is a reasonable compromise to make, IMO. In a perfect world, we'd
> have enough active packagers to handle things in a timely manner. But
> in this world, people have a lot going on and there's only so much we
> can do. People setting a bug to ASSIGNED is a problem I'm willing to
> accept. If there's an exceptional case, we can say FESCo has the
> ability to step in and remove it. We should assume positive intent
> with maintainers and trust that they're doing the right thing.

Alternate perspective, entirely a personal one:

I think the process is actually great. I kinda prefer the direction of
travel where we expect that packages are actively maintained and quite
aggressively throw them out if they aren't, to the direction where we
accumulate cruft and only throw it out after extremely longwinded and
easily-subverted processes.

If a package hasn't built for months that's a *problem*. I don't think
a packager should be allowed to get away with just setting a bug to
ASSIGNED to have the package duck auto-orphaning and eventual removal,
possibly forever. That shouldn't be a thing. Packages need to be taken
care of.

Exceptions should be for things that really ought to be removed but
which we need to keep around. Removing unmaintained things shouldn't be
the exception.

I actually think the consequences of the revival of the old policy have
been fine. We are throwing out tons of cruft. Occasionally we find
something very crufty yet important: this is a *good* outcome of the
process. It alerts us to the fact that important stuff depends on
something which is not being properly maintained and allows us to
address that.

No actions here are reversible, retired packages can be and have been
unretired.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Let's revisit the FTBFS policy

[Ben Cotton]

I want to publicly express my appreciation for Miro's efforts to
enforce our policy and his willingness to take the hits from people
being rightly upset at its flaws. I also appreciate that the community
has done a good job of understanding that the policy is the problem
and not making it a personal attack on Miro.

On Wed, Aug 14, 2019 at 12:24 PM Jason L Tibbitts III  wrote:
>
> > "MH" == Miro Hrončok  writes:
>
> MH> If we stop here, the current "setting to ASSIGNED to stop this"
> MH> remains a problem.
>
> Let's think about why this is perceived as a problem.  The maintainer
> has performed an affirmative act that shows they noticed.  Can't we just
> accept that as some statement of intent and stop bugging them at that
> point?

This is a reasonable compromise to make, IMO. In a perfect world, we'd
have enough active packagers to handle things in a timely manner. But
in this world, people have a lot going on and there's only so much we
can do. People setting a bug to ASSIGNED is a problem I'm willing to
accept. If there's an exceptional case, we can say FESCo has the
ability to step in and remove it. We should assume positive intent
with maintainers and trust that they're doing the right thing.

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

Re: Let's revisit the FTBFS policy

[Jason L Tibbitts III]

> "FW" == Florian Weimer  writes:

FW> Debian treats FTBFS bugs as release-critical.  They either have to
FW> be fixed, or the package gets removed from the release.  However,
FW> this is not an automated process.

Of course, Debian works on a slightly different release schedule, so
it's not exactly a direct comparison.

FW> I wonder if something similar could work for Fedora: The package
FW> would remain available in rawhide, but would be removed from the
FW> release composes.

That's an interesting option, I suppose.  In part I think it depends on
just why some people have been upset over the recent orphaning.  Is it
the removal from the distribution, the shock of having the project say
"we don't want this package any longer", the fact that user's won't be
able to access the package any longer, the annoyance with process for
getting the package into the distribution if it's fixed, or something
else?  (Certainly those aren't mutually exclusive and the true answer is
more complicated and differs between people.)

Technical solutions to some of these are possible, though I don't know
how feasible they would be.  Procedural solutions (such as making it
easier for such packages to get back into the distribution) could also
help.

FW> In the end, someone has to fix the packages eventually, and the
FW> package maintainers are probably best qualified to deal with that.
FW> If they lack the resources for that, it points to a much more
FW> significant problem that needs solving separately, I think.

Yes, this is fundamental.

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

Re: Requesting F31 branches

[Gwyn Ciesla via devel]

I believe Mohan has corrected this in git, but hasn't cut a release yet.

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

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, August 14, 2019 11:33 AM, Igor Gnatenko 
 wrote:

> I think Gwyn needs to update fedscm-admin.
> 

> On Wed, Aug 14, 2019, 17:52 Robert-André Mauchin  wrote:
> 

> > Hello,
> > 

> > What does this error means when requesting F31 branches:
> > 

> > > Invalid body, keys: sls missing
> > 

> > https://pagure.io/releng/fedora-scm-requests/issue/15093
> > 

> > This is cryptic, can anyone explain what is the issue?
> > 

> > Best regards,
> > 

> > Robert-André
> > 

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

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

Re: Requesting F31 branches

[Igor Gnatenko]

I think Gwyn needs to update fedscm-admin.

On Wed, Aug 14, 2019, 17:52 Robert-André Mauchin  wrote:

> Hello,
>
> What does this error means when requesting F31 branches:
>
> > Invalid body, keys: sls missing
>
> https://pagure.io/releng/fedora-scm-requests/issue/15093
>
> This is cryptic, can anyone explain what is the issue?
>
> Best regards,
>
> Robert-André
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: Let's revisit the FTBFS policy

[Jason L Tibbitts III]

> "MH" == Miro Hrončok  writes:

MH> If we stop here, the current "setting to ASSIGNED to stop this"
MH> remains a problem.

Let's think about why this is perceived as a problem.  The maintainer
has performed an affirmative act that shows they noticed.  Can't we just
accept that as some statement of intent and stop bugging them at that
point?  Further emails have utility only as periodic reminders, and
experience has shown that we can't predict whether those would be
perceived positively or negatively.

Certainly the _real_ problem here (that the packages fail to build)
isn't solved by continuing to send bug spam mail.  And similarly, we
should spend time to evaluate why that is perceived as a problem.

If a package is installable and works, certainly it meets some
acceptability criteria for packages in the distribution and fails
others.  So let's list a few (not a comprehensive list, I'm sure):

1. Can end users install and use the package properly?

2. Does the package have unresolved security issues which would prevent
   end users from using it safely?

3. Does the package somehow prevent progress or cause additional
   maintenance burden elsewhere in Fedora?

4. Can those packages be consumed by those who want to modify or rebuild
   them locally?

I think the last two points are often missed in the discussion.

If someone keeps having to maintain some old compatibility package
because packages which use it can't be rebuilt for a new version, then
that's a problem (but it's an issue that goes beyond FTBFS).  Still,
people who maintain such compatibility packages should still be able to
drop them, under the doctrine that nobody can force them to maintain
them.  And then point #1 would fail, which we all agree should force the
removal of a package.

And if someone goes to check out a package from git or grabs an SRPM and
finds that they can't actually build it, even after spending time
setting up a proper build environment (which I know isn't terribly
difficult, but still), then that's not great.  I know I do this all the
time, but maybe that's atypical.  It still looks a bit sloppy in any
case.  I do think our duty to people who want to do that goes beyond
simply complying with licenses and handing out source.

So in summary, I guess I mostly support allowing packages which can't be
rebuilt to stay in the distribution as long as they actually work and
aren't causing maintenance burden elsewhere (which needs input from the
release engineering folks and such as to whether these things waste
their time).  But I do think that everyone who advocates for that
position needs to consider the negatives.  These things do have nonzero
impact even if it's not immediately obvious.  And everyone needs to be
aware that unbuildable packages are more prone to being removed pretty
much as soon as they impede work elsewhere in the distribution.

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

Requesting F31 branches

[Robert-André Mauchin]

Hello,

What does this error means when requesting F31 branches:

> Invalid body, keys: sls missing

https://pagure.io/releng/fedora-scm-requests/issue/15093

This is cryptic, can anyone explain what is the issue?

Best regards,

Robert-André

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

[Martin Kolman]

On Wed, 2019-08-14 at 14:55 +0200, Vít Ondruch wrote:
> Dne 14. 08. 19 v 14:23 Miro Hrončok napsal(a):
> > Hello.
> > 
> > Recently, a couple hundred packages were retired from rawhide (Fedora
> > 31 at that time) based on the Fedora Failed to Build From Source
> > Policy [1]. From various reactions over several threads it seems this
> > policy is not ideal. This is an attempt to collect feedback and make
> > the policy better serve Fedora's needs.
> > 
> > Fedora has a policy for a long time that can be simplified as:
> > 
> >  1. Mass rebuild for Fedora N happens by releng
> >  2. Packages that fail to build get open bugzillas by releng
> >  3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly
> > reminders by releng
> 
> I think it would be probably enough to stop here. Orphaned packages gets
> garbage collected ATM. The step 4 was a bit unexpected for packages with
> bugs in ASSIGNED state especially.
> 
> Also the timing with mass rebuild and shifting packages from Rawhide to
> F31 is unfortunate. I saw a lot of packages, which were reported as
> FTBFS in BZ, then they were retired but later the bugs were moved from
> Rawhide to F31, that was strange.
While not directly policy related, I strongly suggest, if possible, to do a 
test compose
with the packages removed to see how it fares & ideally run some tests (Open QA 
?) on the result,
to prevent avoidable breakage.

Droping such big batches of packages without testing we can still produce out 
blocking deliverables
& checking the deliverables appear to work simply seems too invasive to me.
> 
> 
> Vít
> 
> 
> >  4. A week before Fedora N+1 branching any packages which still have
> > open Fedora N FTBFS bug are retired by releng
> > 
> > However, 3 or 4 haven't happened since Fedora ~26, because the
> > automation was not working any more for various reasons I don't
> > understand.
> > 
> > The policy was then updated by FESCo to allow anybody to step up and
> > do 3. manually.
> > However it needs 2 e-mails to devel directed at the package owners and
> > that may be understood as a personal attack by some.
> > So nobody ever did that but me (twice) IIRC (and I got my share of
> > shame for that).
> > 
> > Currently, the FTBFS retirement is problematic due to various things:
> > 
> > 1) Bugzilla spam: Maintainers are spammed weekly by releng, some of
> > them find that annoying and simply switch the bug to ASSIGNED to make
> > it stop.
> > 
> > The problem is, how do we both keep notifying the maintainers that
> > action is needed and not spam them with stuff that will make them
> > filter all Fedora e-mails to /dev/null.
> > 
> > 2) Retirement out of the blue. When releng executes 4., packagers that
> > stopped the bugzilla spam by setting the bug to ASSIGNED are suddenly
> > surprised the package was retired. OTOH arguably they made a
> > deliberate action to stop the notifications. However, most
> > importantly, any dependent packages were not notified at all, which is
> > **not fair**.
> > 
> > This state is broken mostly because there is no automatic orphaning of
> > packages that have NEW bugzillas and there is no orphaning at all for
> > packages where the bugzillas are ASSIGNED for months. For the second
> > bit, everything indicates that packagers are aware of the problem and
> > will fix the bug in time before 4., but they don't and things blow up.
> > 
> > 3) Questionable importance of the FTBFS bug.
> > 
> > Repeatedly, it has been stated by some, the FTBFS bug is not important
> > and we should not retire packages at all based on the fact that they
> > "simply" fail to build. I personally don't agree with this for various
> > reasons, but I can imagine a situation, where it is reasonable to say
> > so and delay the problem. Obvious argument is: Better to have 1
> > package nonbuildable than have 100 packages nonisntallable. So we need
> > a way to opt-out from the retirement, however simply setting the
> > bugzilla to ASSIGNED is not it, because we will end up with packages
> > last built 6 years ago (and I believe this is not what we want).
> > 
> > 
> > I'm starting this thread to collect the ideas about how to make this
> > better.
> > If you see more problems, share them. I promise I'll do my best to
> > make the policy work better for both Fedora and the people who make
> > Fedora.
> > 
> > [1]
> > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
> > 
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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.

Announcing EPEL-8.0 Release

[Stephen John Smoogen]

The EPEL Steering Committee is pleased to announce that the initial
EPEL-8 is ready for release. We would like to thank everyone in the
community for helping us get the initial set of builds out to mirrors
and to consumers worldwide. Special thanks go to Patrick Uiterwijk,
Jeroen van Meeuwen, Robert Scheck, and many others in the community
who helped in the last 6 months to get this release done.

EPEL-8.0 has packages for the x86_64, ppc64le, aarch64, and now the
s390x platforms.

## What is EPEL?

EPEL stands for Extra Packages for Enterprise Linux and is a
subcommunity of the Fedora and CentOS projects aimed at bringing a
subset of packages out of Fedora releases ready to be used and
installed on various Red Hat Enterprise Linux (RHEL). It is not a
complete rebuild of Fedora or even of previous EPEL releases. EPEL is
also a community and not a product. As such we need community members
to help get packages into the repository more than done in Fedora.

If you are interested in getting a package into EPEL, contact the
package maintainer through bugzilla. This way the request can be
tracked, and if the primary maintainer is not interested in branching
to EPEL, others can step in and do so. Optionally you can send a
request to the epel-de...@lists.fedoraproject.org mailing list. If you
do so, please include why the package is needed, to help other
volunteers decide whether they can support it.

## What is new?

### Playground for Rawhide like things
We have added an additional set of channels for EPEL-8 called
playground. It is similar to Fedora Rawhide so packagers can work on
versions of software that are too fast moving or will have large API
changes compared to versions in the regular channel.

To make this purpose transparent, when a package is built in epel8, it
will normally also be built in epel8-playground. This is done via a
packages.cfg file which lists the targets for fedpkg to build against.
A successful package build will then go through two different paths:
* epel8 package will go into bodhi to be put into epel8-testing
* epel8-playground will bypass bodhi and go directly into
epel8-playground the next compose.

If a packager needs to focus only on epel8 or epel8-playground they
can edit packages.cfg to change the target=epel8 epel8-playground to
target=epel8.

Packages in epel8-playground are intended to be used in the following manner:
* To test out a new version of the package that might not be stable yet.
* To test out new packaging of the package
* To test a major version change of the package intended for the next
EPEL-8 minor release.
* To build a package that will never be stable enough for EPEL-8, but
still could be useful to some.

At minor RHEL releases (ie, 8.1, 8.2) people can pull in big changes
from playground to the main EPEL-8 packages. Since people will be
upgrading and paying more attention than usual anyhow at those points,
it’s a great chance to do that change, but you can test beforehand in
the playground to make sure these changes work.
Consumers should be aware that packages in EPEL8-playground are
without any Service Level Expectations. You may want to only cherry
pick packages from the playground as needed.

### New Architecture: s390x

We have added the s390x platform to builds. Some consumers have wanted
this platform for many years but we did not have the time to integrate
necessary changes. We have done this with EPEL-8, and hope to be able
to do so for EPEL-7 if there are continued requests for it.

## What is next? (Why is it called EPEL-8.0?)
The goal for EPEL-8.1 will be implementing modules into the
repository, which allows builds for packages that depend on
non-shipped devel packages. It also allows maintainers to supplement
and replace other packages they could not under standard EPEL rules.

## Known Issues:
1. EPEL-8.0 does not come with modules. Packages built for perl,
python and other modules are only built against “default” modules. For
example installing a perl library from EPEL will work with the
perl-5.26 but not with the perl-5.24 module.
2. RHEL-8.0 and RHEL-8.1 beta do not come with the same packages in
all architectures. There are 720 ‘desktop’ packages which were only
shipped for x86_64 and ppc64le. Packagers looking to deliver GNOME,
KDE, or other platforms will need to exclude s390x and aarch64 at this
time.
3. The dnf in RHEL-8.1 beta does not work with the EPEL repository due
to zchunk code. This has been opened as an upstream bug as
https://bugzilla.redhat.com/show_bug.cgi?id=1719830
4. Until modularity and module builds are implemented in EPEL, there
will be many packages which can not be built for EPEL. This is mainly
due to RHEL-8 not shipping many -devel packages and the need for us to
rebuild those packages in a module to make those -devel available to
build against. When running into this please open a ticket with
https://pagure.io/epel/new_issue for us to put in a request for it to
be added to Red Hat’s Code Ready Builder. Please

Re: Unretire linuxconsoletools package

[Vít Ondruch]

Just FTR, the re-review was not necessary:


https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package



V.



Dne 13. 08. 19 v 14:12 Vascom napsal(a):
> Please approve review of linuxconsoletools package
> https://bugzilla.redhat.com/show_bug.cgi?id=1740634
>
> It was retired due to FTBFS but needed for gpm, fpc, lazarus to build
> pascal programs.
> Situation same as with gettext.
>
> --
> Best regards,
> Vasiliy Glazov
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Better interactivity in low-memory situations

[S.]

(Oops, sorry, re-post because I messed up the threading.)

I'm not a developer, nor do I pretend to understand the nuances of memory management. But 
I signed up for this list just to say "thanks" to all the devs and others that 
are finally discussing what I consider to be one of the biggest problems with Linux on 
the desktop.

My experience with desktop Linux distros with SSDs when a few processes start 
to leak memory, or if I launch a new program when my system is right at the 
limits, is a full system hang where only the mouse occasionally moves jerkily, 
and I can't switch to a virtual terminal. I recently learned the SysRq trick to 
evoke the OOM killer, but I personally think that the kernel should deal with 
that, not the user. As unfortunate as it is for the OOM killer to have to 
randomly kill something, I am of the opinion that the OS should *never* lock 
up, period. I would strongly prefer that one application get killed instead of 
losing all my applications and working data because of a necessary hard reboot.

I don't know if this helps or not, but anecdotally I started see this issue 
*after* SSDs became more common, i.e. I don't think I ever experienced it with 
spinning rust. Maybe something to do with the vastly faster I/O of an SSD, 
which allows it to more quickly saturate the RAM before the OOM killer has time 
to react?

Also, I've had relatively low memory KVM guests running on a VPS under very high load, 
and they never lockup. The OOM killer does occasionally kick in, but the affected daemon 
or systemd service restarts and it's amazingly undramatic. It appears that this issue 
only occurs with Xorg (and I imagine Wayland) and "desktop" usage.

As for the problem of the randomness of the OOM killer, couldn't it be made to 
take into account the PID and/or how long the process has been running? 
Normally Xorg (and I assume Wayland stuff) gets started before the other 
desktop programs that tend to consume a lot of memory. So if it's a higher PID 
and/or has been running for less time, give it a higher score for killability.

In my experience on a system with 8GB of RAM and an SSD, the amount of swap 
space makes no difference. I've tried with no swap space, with 2GB, with 8GB, 
etc, and it still hangs under high memory usage. I've also tried tuning a lot 
of sysctl parameters such as vm.swappiness, vm.vfs_cache_pressure, and 
vm.min_free_kbytes, to no avail.

Don't know if this helps, but here are some additional discussions of Linux 
unresponsiveness under low memory situations from a layman's perspective:
- osnews.com/story/130117/kde-usability-and-productivity-are-we-there-yet/ (in 
the comments)
- 
unix.stackexchange.com/questions/373312/oom-killer-doesnt-work-properly-leads-to-a-frozen-os
- bbs.archlinux.org/viewtopic.php?id=233843
- 
askubuntu.com/questions/432809/why-is-kswapd0-running-on-a-computer-with-no-swap/432827#432827
- 
unix.stackexchange.com/questions/24625/how-to-completely-disable-swap/24646#24646

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

Bugzilla branching emails

[Ben Cotton]

Hi everyone!

It turns out that the Bugzilla branching script was not correctly
suppressing email notifications, so you may have received "a few"
messages as we branched rawhide bugs to F31 yesterday. This is fixed
now, with help from Miro Hrončok. I apologize for the spam.

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

re: Better interactivity in low-memory situations

[S.]

I'm not a developer, nor do I pretend to understand the nuances of memory management. But 
I signed up for this list just to say "thanks" to all the devs and others that 
are finally discussing what I consider to be one of the biggest problems with Linux on 
the desktop.

My experience with desktop Linux distros with SSDs when a few processes start 
to leak memory, or if I launch a new program when my system is right at the 
limits, is a full system hang where only the mouse occasionally moves jerkily, 
and I can't switch to a virtual terminal. I recently learned the SysRq trick to 
evoke the OOM killer, but I personally think that the kernel should deal with 
that, not the user. As unfortunate as it is for the OOM killer to have to 
randomly kill something, I am of the opinion that the OS should *never* lock 
up, period. I would strongly prefer that one application get killed instead of 
losing all my applications and working data because of a necessary hard reboot.

I don't know if this helps or not, but anecdotally I started see this issue 
*after* SSDs became more common, i.e. I don't think I ever experienced it with 
spinning rust. Maybe something to do with the vastly faster I/O of an SSD, 
which allows it to more quickly saturate the RAM before the OOM killer has time 
to react?

Also, I've had relatively low memory KVM guests running on a VPS under very high load, 
and they never lockup. The OOM killer does occasionally kick in, but the affected daemon 
or systemd service restarts and it's amazingly undramatic. It appears that this issue 
only occurs with Xorg (and I imagine Wayland) and "desktop" usage.

As for the problem of the randomness of the OOM killer, couldn't it be made to 
take into account the PID and/or how long the process has been running? 
Normally Xorg (and I assume Wayland stuff) gets started before the other 
desktop programs that tend to consume a lot of memory. So if it's a higher PID 
and/or has been running for less time, give it a higher score for killability.

In my experience on a system with 8GB of RAM and an SSD, the amount of swap 
space makes no difference. I've tried with no swap space, with 2GB, with 8GB, 
etc, and it still hangs under high memory usage. I've also tried tuning a lot 
of sysctl parameters such as vm.swappiness, vm.vfs_cache_pressure, and 
vm.min_free_kbytes, to no avail.

Don't know if this helps, but here are some additional discussions of Linux 
unresponsiveness under low memory situations from a layman's perspective:
- osnews.com/story/130117/kde-usability-and-productivity-are-we-there-yet/ (in 
the comments)
- 
unix.stackexchange.com/questions/373312/oom-killer-doesnt-work-properly-leads-to-a-frozen-os
- bbs.archlinux.org/viewtopic.php?id=233843
- 
askubuntu.com/questions/432809/why-is-kswapd0-running-on-a-computer-with-no-swap/432827#432827
- 
unix.stackexchange.com/questions/24625/how-to-completely-disable-swap/24646#24646

Thanks again to everyone for looking into this!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Let's revisit the FTBFS policy

[Vít Ondruch]

Dne 14. 08. 19 v 15:20 Miro Hrončok napsal(a):
> On 14. 08. 19 14:55, Vít Ondruch wrote:
>> I think it would be probably enough to stop here. Orphaned packages gets
>> garbage collected ATM. The step 4 was a bit unexpected for packages with
>> bugs in ASSIGNED state especially.
>
> If we stop here, the current "setting to ASSIGNED to stop this"
> remains a problem.


It depends. I agree that this might prevent some packages from removing
immediately. OTOH, the FTBFS package is reported with every mass
rebuild, i.e. every 6 months. So if something changes in these 6+
months, the new ticket will eventually stay in NEW and the package will
be orphaned and later garbage collected ...



Vít

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

Re: Why retire Python 2 packages and games that still work to end user ?

[David Sommerseth]

On 14/08/2019 15:01, Kevin Kofler wrote:
> David Sommerseth wrote:
>> Like it or not, Python 2 is going to die:
>> 
>>
>> Python 2 will not be maintained by upstream after January 1, 2020.  Python
>> 2 will go EOL during the lifetime of Fedora 31.
> 
> So what? Qt 3 had its last release (3.3.8b) in 2008 (and that was basically 
> just a relicensing of the final 2007 release 3.3.8). Yet, we (mostly me) 
> still maintain qt3 and backport security fixes where issues are reported to 
> us, and Qt 3 applications still work fine. I have KSensors (a qt3/kdelibs3 
> application) sitting in my system tray all the time. It still works (thanks 
> also to Plasma 5's xembedsniproxy). I also use Quanta Plus to edit HTML. It 
> also works as expected.

So what?  You chose to do this work to keep this alive.  In my personal
opinion, that's wasting of precious time and I would never have done that.
You chose differently, and I respect that.

> Just because upstream no longer releases something does not mean it has to 
> disappear from distributions instantly. I see no other distribution being as 
> aggressive about removing Python 2 as Fedora is.

I honestly don't care much what other distros do.  I care about the road
forward for Fedora.  In my point of view, putting legacy software which has
reached EOL from upstream behind is really sane.  If you want/need it, then
port it forward to the future.

Secondly, this isn't "disappearing instantly", as you say.   Fedora started
this migration almost 4 years ago.  If this feels "instantly", someone has not
paid attention.

> There is also a fork trying to keep Python 2 alive:
> https://github.com/naftaliharris/tauthon
> though it is unfortunately unclear whether the most important point 
> (backporting security issues) will be taken care of reliably:
> https://github.com/naftaliharris/tauthon/issues/109

And this is why we should let Python 2 rest in peace once it reaches EOL.
Python 3 contains a lot of improvements over Python 2.  The world need to move
forward and not linger in the past.

> But it is always possible to do the backports downstream, as we are doing 
> for the Qt 3 and 4 stacks.

Who will do this job?  And which guarantees do we have it will be done in a
way providing the same quality work the Python community has done so far?

If the result is less secure Python 2 updates, nothing really improves at all
... except keeping code which should be ported forward to Python 3 alive
longer than really needed.

Instead of spending time and resources keeping old stuff alive longer than
needed, rather spend that energy on porting the old Python 2 over to Python 3.
 In the long run, this will result in far less work over time.


-- 
kind regards,

David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Let's revisit the FTBFS policy

[Miro Hrončok]

On 14. 08. 19 14:55, Vít Ondruch wrote:

I think it would be probably enough to stop here. Orphaned packages gets
garbage collected ATM. The step 4 was a bit unexpected for packages with
bugs in ASSIGNED state especially.


If we stop here, the current "setting to ASSIGNED to stop this" remains a 
problem.


Also the timing with mass rebuild and shifting packages from Rawhide to
F31 is unfortunate. I saw a lot of packages, which were reported as
FTBFS in BZ, then they were retired but later the bugs were moved from
Rawhide to F31, that was strange.


IMHO we should probably do this after branching and in rawhide only, to avoid 
breakage few weeks before the beta freeze.


--
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: Orphaning 13 packages

[Vít Ondruch]

Dne 14. 08. 19 v 12:39 Jan Kaluza napsal(a):
> Hi,
>
> I'm orphaning packages which I used to maintain in my spare time. I do
> not have enough time and motivation these days/months/years to
> continue maintaining them:
>
> - adevs - https://src.fedoraproject.org/rpms/adevs
> - dfish - https://src.fedoraproject.org/rpms/dfish
> - gob2 - https://src.fedoraproject.org/rpms/gob2
> - httpdtap - https://src.fedoraproject.org/rpms/httpdtap
> - libcommuni - https://src.fedoraproject.org/rpms/libcommuni
> - libeio - https://src.fedoraproject.org/rpms/libeio
> - ncbi-blast+ - https://src.fedoraproject.org/rpms/ncbi-blast+
> - python-restauth - https://src.fedoraproject.org/rpms/python-restauth
> - python-restauth-common -
> https://src.fedoraproject.org/rpms/python-restauth-common
> - restauth - https://src.fedoraproject.org/rpms/restauth
> - rinetd - https://src.fedoraproject.org/rpms/rinetd
> - rubygem-passenger - https://src.fedoraproject.org/rpms/rubygem-passenger


This one is retired (due to renaming) for some while:

https://src.fedoraproject.org/rpms/rubygem-passenger

It is sad, that the maintainers are kept around indefinitely even for
retired packages :/


Vít


> - swift - https://src.fedoraproject.org/rpms/swift
>
> I'm also going to remove myself as "maintainer" for "passenger" and
> "python-mimeparse", but for these packages, there are co-maintainers,
> so I'm going to ask them first before orphaning.
>
> Regards,
> Jan Kaluza
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kevin Kofler]

Florian Weimer wrote:
> You dropped too much context here.  Drivers which are rottenware (Panu's
> term) are exactly in this category.  We can only hope that upstreams
> remove them, based on feedback from the larger community.

The question is, how do you know whether the unmaintained driver last tested 
years ago still works (making potentially hundreds of silent users happy, 
and removing it will force them to spend money on replacing their hardware) 
or is actually completely broken? You have just no way to know.

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

Re: Why retire Python 2 packages and games that still work to end user ?

[Kevin Kofler]

David Sommerseth wrote:
> Like it or not, Python 2 is going to die:
> 
> 
> Python 2 will not be maintained by upstream after January 1, 2020.  Python
> 2 will go EOL during the lifetime of Fedora 31.

So what? Qt 3 had its last release (3.3.8b) in 2008 (and that was basically 
just a relicensing of the final 2007 release 3.3.8). Yet, we (mostly me) 
still maintain qt3 and backport security fixes where issues are reported to 
us, and Qt 3 applications still work fine. I have KSensors (a qt3/kdelibs3 
application) sitting in my system tray all the time. It still works (thanks 
also to Plasma 5's xembedsniproxy). I also use Quanta Plus to edit HTML. It 
also works as expected.

Just because upstream no longer releases something does not mean it has to 
disappear from distributions instantly. I see no other distribution being as 
aggressive about removing Python 2 as Fedora is.

There is also a fork trying to keep Python 2 alive:
https://github.com/naftaliharris/tauthon
though it is unfortunately unclear whether the most important point 
(backporting security issues) will be taken care of reliably:
https://github.com/naftaliharris/tauthon/issues/109
But it is always possible to do the backports downstream, as we are doing 
for the Qt 3 and 4 stacks.

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

Re: Let's revisit the FTBFS policy

[Vít Ondruch]

Dne 14. 08. 19 v 14:23 Miro Hrončok napsal(a):
> Hello.
>
> Recently, a couple hundred packages were retired from rawhide (Fedora
> 31 at that time) based on the Fedora Failed to Build From Source
> Policy [1]. From various reactions over several threads it seems this
> policy is not ideal. This is an attempt to collect feedback and make
> the policy better serve Fedora's needs.
>
> Fedora has a policy for a long time that can be simplified as:
>
>  1. Mass rebuild for Fedora N happens by releng
>  2. Packages that fail to build get open bugzillas by releng
>  3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly
> reminders by releng


I think it would be probably enough to stop here. Orphaned packages gets
garbage collected ATM. The step 4 was a bit unexpected for packages with
bugs in ASSIGNED state especially.

Also the timing with mass rebuild and shifting packages from Rawhide to
F31 is unfortunate. I saw a lot of packages, which were reported as
FTBFS in BZ, then they were retired but later the bugs were moved from
Rawhide to F31, that was strange.


Vít


>
>  4. A week before Fedora N+1 branching any packages which still have
> open Fedora N FTBFS bug are retired by releng
>
> However, 3 or 4 haven't happened since Fedora ~26, because the
> automation was not working any more for various reasons I don't
> understand.
>
> The policy was then updated by FESCo to allow anybody to step up and
> do 3. manually.
> However it needs 2 e-mails to devel directed at the package owners and
> that may be understood as a personal attack by some.
> So nobody ever did that but me (twice) IIRC (and I got my share of
> shame for that).
>
> Currently, the FTBFS retirement is problematic due to various things:
>
> 1) Bugzilla spam: Maintainers are spammed weekly by releng, some of
> them find that annoying and simply switch the bug to ASSIGNED to make
> it stop.
>
> The problem is, how do we both keep notifying the maintainers that
> action is needed and not spam them with stuff that will make them
> filter all Fedora e-mails to /dev/null.
>
> 2) Retirement out of the blue. When releng executes 4., packagers that
> stopped the bugzilla spam by setting the bug to ASSIGNED are suddenly
> surprised the package was retired. OTOH arguably they made a
> deliberate action to stop the notifications. However, most
> importantly, any dependent packages were not notified at all, which is
> **not fair**.
>
> This state is broken mostly because there is no automatic orphaning of
> packages that have NEW bugzillas and there is no orphaning at all for
> packages where the bugzillas are ASSIGNED for months. For the second
> bit, everything indicates that packagers are aware of the problem and
> will fix the bug in time before 4., but they don't and things blow up.
>
> 3) Questionable importance of the FTBFS bug.
>
> Repeatedly, it has been stated by some, the FTBFS bug is not important
> and we should not retire packages at all based on the fact that they
> "simply" fail to build. I personally don't agree with this for various
> reasons, but I can imagine a situation, where it is reasonable to say
> so and delay the problem. Obvious argument is: Better to have 1
> package nonbuildable than have 100 packages nonisntallable. So we need
> a way to opt-out from the retirement, however simply setting the
> bugzilla to ASSIGNED is not it, because we will end up with packages
> last built 6 years ago (and I believe this is not what we want).
>
>
> I'm starting this thread to collect the ideas about how to make this
> better.
> If you see more problems, share them. I promise I'll do my best to
> make the policy work better for both Fedora and the people who make
> Fedora.
>
> [1]
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 System-Wide Change: glusterfs dropping 32-bit arches

[Aleksandar Kurtakov]

On Wed, Aug 14, 2019 at 3:31 PM Kevin Kofler  wrote:

> Aleksandar Kurtakov wrote:
> > The real question which every packager should ask himself is: Do I have
> > the capacity (time, knowledge, hardware, etc.) to solve problems on
> > non-supported architecture by upstream?
> > And if the answer is no - it is probably better to drop the arch instead
> > of shipping smth that not even the maintainer knows whether it is usable
> > at all (like I used to ship eclipse on 32 bit arm although I'm quite sure
> > it was not usable at all).
>
> By that definition, all my packages would really be ExclusiveArch: x86_64.
> Is that really what you want?
>

There is big difference between what I want and what I can do :) . Setting
clear expectations is crucial for any system to work properly and
issues(e.g. understaffed) being noticed before it's late.


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


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Why retire Python 2 packages and games that still work to end user ?

[Kevin Kofler]

Peter Robinson wrote:
> So why do package maintainers have to do a whole lot of extra work to
> keep a package that has already been approved in the distro. There's a
> lot of work going into various stacks upstream for python3 work but in
> a lot of cases the time available is split and now we're asking the
> limited maintainers of packaged in Fedora to do more work
> unnecessarily to keep their packages around otherwise they're be
> aggressively killed off and they'll have to then do even more work to
> get them back or probably just go and use Ubuntu or CentOS or
> something else instead. This is frankly a ridiculous policy!

Are you also bringing this one to the Council?

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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Florian Weimer]

* Kevin Kofler:

> Florian Weimer wrote:
>> I think that's only a problem if reported bugs don't get fixed.  If such
>> bugs are fixed, shipping everything that builds aligns well with
>> building a community-tested distribution.
>> 
>> Exceptions could be software that leads to purchases of some kind, based
>> on an incorrect assumption of Fedora support due to the existence of the
>> non-working package.
>
> Well, that would exclude a lot of hardware drivers, and make Fedora pretty 
> useless. (You cannot realistically test Fedora on all hardware on which 
> users want to use it.)

You dropped too much context here.  Drivers which are rottenware (Panu's
term) are exactly in this category.  We can only hope that upstreams
remove them, based on feedback from the larger community.

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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kevin Kofler]

Florian Weimer wrote:
> I think that's only a problem if reported bugs don't get fixed.  If such
> bugs are fixed, shipping everything that builds aligns well with
> building a community-tested distribution.
> 
> Exceptions could be software that leads to purchases of some kind, based
> on an incorrect assumption of Fedora support due to the existence of the
> non-working package.

Well, that would exclude a lot of hardware drivers, and make Fedora pretty 
useless. (You cannot realistically test Fedora on all hardware on which 
users want to use it.)

In the end, if I need, e.g., a printer, I just have to buy some model, check 
the model lists upstream (in my example: Gutenprint, HPLIP, etc.) claims to 
support (for printers, openprinting.org can also be of help) and then hope 
it works. Short hardware compatibility lists with regularly tested models 
are not always helpful because the listed models are often no longer 
available and/or not in the desired price and/or feature range.

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

Re: Let's revisit the FTBFS policy

[Florian Weimer]

* Miro Hrončok:

> Recently, a couple hundred packages were retired from rawhide (Fedora
> 31 at that time) based on the Fedora Failed to Build From Source
> Policy [1]. From various reactions over several threads it seems this
> policy is not ideal. This is an attempt to collect feedback and make
> the policy better serve Fedora's needs.

Debian treats FTBFS bugs as release-critical.  They either have to be
fixed, or the package gets removed from the release.  However, this is
not an automated process.

I wonder if something similar could work for Fedora: The package would
remain available in rawhide, but would be removed from the release
composes.

In the end, someone has to fix the packages eventually, and the package
maintainers are probably best qualified to deal with that.  If they lack
the resources for that, it points to a much more significant problem
that needs solving separately, I think.

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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Kevin Kofler]

Aleksandar Kurtakov wrote:
> The real question which every packager should ask himself is: Do I have
> the capacity (time, knowledge, hardware, etc.) to solve problems on
> non-supported architecture by upstream?
> And if the answer is no - it is probably better to drop the arch instead
> of shipping smth that not even the maintainer knows whether it is usable
> at all (like I used to ship eclipse on 32 bit arm although I'm quite sure
> it was not usable at all).

By that definition, all my packages would really be ExclusiveArch: x86_64. 
Is that really what you want?

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

Re: Where can I remove myself from bug emails for packages I am not a maintainer anymore

[Robert Marcano]

On 8/14/19 4:08 AM, Petr Pisar wrote:

On 2019-08-13, Robert Marcano  wrote:

I am not maintaining eclipse-subclipse from a long time ago, I am not
listed as a member at
https://src.fedoraproject.org/rpms/eclipse-subclipse but I still get
FTBFS bugzilla emails.


That's because synchronization from dist-git Pagure to Bugzilla is
broken .

I recommend you to file a new request for removing you form default CC
of that Bugzilla component at
.


Thanks!



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

Let's revisit the FTBFS policy

[Miro Hrončok]

Hello.

Recently, a couple hundred packages were retired from rawhide (Fedora 31 at that 
time) based on the Fedora Failed to Build From Source Policy [1]. From various 
reactions over several threads it seems this policy is not ideal. This is an 
attempt to collect feedback and make the policy better serve Fedora's needs.


Fedora has a policy for a long time that can be simplified as:

 1. Mass rebuild for Fedora N happens by releng
 2. Packages that fail to build get open bugzillas by releng
 3. Packages with NEW bugizllas are orphaned after 8 weeks with weekly 
reminders by releng
 4. A week before Fedora N+1 branching any packages which still have open 
Fedora N FTBFS bug are retired by releng


However, 3 or 4 haven't happened since Fedora ~26, because the automation was 
not working any more for various reasons I don't understand.


The policy was then updated by FESCo to allow anybody to step up and do 3. 
manually.
However it needs 2 e-mails to devel directed at the package owners and that may 
be understood as a personal attack by some.

So nobody ever did that but me (twice) IIRC (and I got my share of shame for 
that).

Currently, the FTBFS retirement is problematic due to various things:

1) Bugzilla spam: Maintainers are spammed weekly by releng, some of them find 
that annoying and simply switch the bug to ASSIGNED to make it stop.


The problem is, how do we both keep notifying the maintainers that action is 
needed and not spam them with stuff that will make them filter all Fedora 
e-mails to /dev/null.


2) Retirement out of the blue. When releng executes 4., packagers that stopped 
the bugzilla spam by setting the bug to ASSIGNED are suddenly surprised the 
package was retired. OTOH arguably they made a deliberate action to stop the 
notifications. However, most importantly, any dependent packages were not 
notified at all, which is **not fair**.


This state is broken mostly because there is no automatic orphaning of packages 
that have NEW bugzillas and there is no orphaning at all for packages where the 
bugzillas are ASSIGNED for months. For the second bit, everything indicates that 
packagers are aware of the problem and will fix the bug in time before 4., but 
they don't and things blow up.


3) Questionable importance of the FTBFS bug.

Repeatedly, it has been stated by some, the FTBFS bug is not important and we 
should not retire packages at all based on the fact that they "simply" fail to 
build. I personally don't agree with this for various reasons, but I can imagine 
a situation, where it is reasonable to say so and delay the problem. Obvious 
argument is: Better to have 1 package nonbuildable than have 100 packages 
nonisntallable. So we need a way to opt-out from the retirement, however simply 
setting the bugzilla to ASSIGNED is not it, because we will end up with packages 
last built 6 years ago (and I believe this is not what we want).



I'm starting this thread to collect the ideas about how to make this better.
If you see more problems, share them. I promise I'll do my best to make the 
policy work better for both Fedora and the people who make Fedora.


[1] 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/



--
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: [HEADS-UP] gradle will go away

[Fabio Valentini]

On Wed, Aug 14, 2019, 13:48 Mat Booth  wrote:

>
>
> On Fri, 9 Aug 2019 at 14:24, Fabio Valentini  wrote:
> >
> > Hi everybody!
> >
> > After some discussions, we (the Stewardship SIG) have decided that we
> > cannot continue to maintain gradle in fedora.
> >
> > - the current version packaged in fedora is outdated (4.4.1, from Dec.
> > 2017, vs. 5.5.1 from July 2019)
> > - it currently doesn't build itself (not even in bootstrap mode), and
> > needs an older version tagged into rawhide as a buildroot override to
> > even build (this doesn't work anymore, due to rawhide gating)
>
> Is that really true? You can't create buildroot overrides for it?
>

Yes. This issue came up in the flock talk about rawhide gating. It's
currently not possible to create buildroot overrides for rawhide, since the
packages get stuck in the wrong tag.

Even so, creating buildroot overrides in rawhide should never be necessary
except in extraordinary circumstances (like only an older version of gradle
being able to build itself).

Fabio

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

Re: efivar and mokutil long standing FTBFS

[Miro Hrončok]

On 14. 08. 19 12:54, Peter Robinson wrote:

Well you can't currently see the forest for the trees and this
bullshit, for the first time in 15 years in making me think about
quitting the Fedora project, and I spoke with many at Flock are
seriously stressed about it and sick of it. I will be bringing this up
at council because this is not sustainable and whether it be by
retiring all of the packages because everything that depends on the
kernel is retired or scaring away all the part time contributors this
militant level of process is causing active harm to the project.


Despite our differences, I'd like to say that I would really regret it, if the 
actions that me and FESCo/Releng took caused you to quit Fedora.


Maintaining a modern distribution is a complex task, so there will inherently be 
disagreements about processes and methodologies, but I believe we all share the 
goal of making Fedora better.


I'm glad that you're offering to bring this issue at Council, as you're right, 
this is a sensitive topic, and could definitely benefit from more voices so we 
can fine tune process to both be positive for Fedora, but also not to alienate 
maintainers such as yourself.


--
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: [HEADS-UP] gradle will go away

[Mat Booth]

On Fri, 9 Aug 2019 at 14:24, Fabio Valentini  wrote:
>
> Hi everybody!
>
> After some discussions, we (the Stewardship SIG) have decided that we
> cannot continue to maintain gradle in fedora.
>
> - the current version packaged in fedora is outdated (4.4.1, from Dec.
> 2017, vs. 5.5.1 from July 2019)
> - it currently doesn't build itself (not even in bootstrap mode), and
> needs an older version tagged into rawhide as a buildroot override to
> even build (this doesn't work anymore, due to rawhide gating)

Is that really true? You can't create buildroot overrides for 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: Why retire Python 2 packages and games that still work to end user ?

[David Sommerseth]

On 11/08/2019 01:45, Kevin Kofler wrote:
>> My opinion at least postpone this decision one or two releases to
>> Fedors 33/34 , many things still just work with python 2 .
> 
> I second that wholeheartedly.

Like it or not, Python 2 is going to die:


Python 2 will not be maintained by upstream after January 1, 2020.  Python 2
will go EOL during the lifetime of Fedora 31.

So why are we here?  Because Python maintainers have ignored this, or have
hoped this will not be a reality or it will be postponed.  But the PEP-373
defining and documenting the EOL of Python 2 was created in November 2008(!).
 That is 11 years ago(!).

Life must move on, like or not.  Python must move on, like it or not.

And since so many Python package maintainers have ignored this fact, we are
having this discussion now.

By not enforcing Python 2 to really die in Fedora, we will have exactly the
same discussion in the coming decade as well.  There has been plenty of time
to get ready for the Python 3 move:
 ... This happened
in Fedora 23 - which was released in November 2015.  That is close to 4 years 
ago.

So why are we here?  Because Python 2 package maintainers in the Fedora
community have ignored this fact, for almost 4 years.  Yes, I know it's not
necessarily an easy task.  But 4 years in Fedora land is quite a long time; it
is 8 Fedora releases.  If we want to do a move, it is possible to do such a
change in 4 years.

Time has run up.  It is time to move on and accept the fate of Python 2
packages not being ready.  Those caring so much for unported Python 2 packages
now got a brilliant chance to help moving them forward to Python 3 too.


-- 
kind regards,

David Sommerseth
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Why retire Python 2 packages and games that still work to end user ?

[Peter Robinson]

On Sun, Aug 11, 2019 at 9:33 AM Miro Hrončok  wrote:
>
> On 11. 08. 19 3:45, Kevin Kofler wrote:
> > Nico Kadel-Garcia wrote:
> >> Maintaining python 2 requires maintaining a*lot*  of infrastructure.
> > What kind of infrastructure do you need to maintain a package that is (will
> > be) no longer updated upstream? This takes almost no work. The only thing to
> > do is to backport some security fixes from Python 3, and occasionally to fix
> > FTBFS bugs.
>
>
> We are still planning to maintain the interpreter. As is documented in the
> change. So can we please stop arguing about maintaining the interpreter over 
> and
> over? It is staying and our team will maintain it at least until RHEL 7 EOL,
> possibly longer.

So why do package maintainers have to do a whole lot of extra work to
keep a package that has already been approved in the distro. There's a
lot of work going into various stacks upstream for python3 work but in
a lot of cases the time available is split and now we're asking the
limited maintainers of packaged in Fedora to do more work
unnecessarily to keep their packages around otherwise they're be
aggressively killed off and they'll have to then do even more work to
get them back or probably just go and use Ubuntu or CentOS or
something else instead. This is frankly a ridiculous policy!

> > Now if your concern is maintaining all the python2-* packages, then there
> > ought to be some middle ground between maintaining all of them including
> > ones that are not used by anything in Fedora anymore, and just dropping all
> > of them (with or without the planned exception process, whose usefulness
> > depends entirely on how willing FESCo will be to approve the requests).
> > Maybe the set of python2-* modules in EL7 or EL8, with or without EPEL,
> > minus the ones already retired from Fedora by now, would be a reasonable
> > starting point?
>
> Yes the concern is about maintaining the python2-* packages.
>
> The difference between EL and Fedora is that package sin Fedora get recent
> rebases / updates to newer version. You cannot just package them and call it
> "done". And most of the upstreams are coming to a point where you cannot 
> update
> the Python 2 package because the new version doe snot support Python 2.
>
> That at the end means you need to go over nonobvious bumps to split the 
> Python 2
> package out of the "common" package, in order to update the "common" (now 
> Python
> 3 only) package. And this problem spreads further with dependencies (even
> transitive ones). I don't have the energy or time to split hundreds of 
> packages
> and maintain a separate stack of Python 2 packages. If somebody else has, go 
> for it.
>
> The set of python2-* packages to remain is determined by the FESCo exceptions.
> It is fairly easy really: We don't have the necessary information to 
> understand
> what Python packages are "important" and what are "cruft". Hence if your 
> package
> is important, you just need to explain that. Obviously, if you need to 
> maintain
> the package as a dependency, for another important package, the exception can 
> be
> requested at once, you don't need to request dozens of exception to keep e.g.
> chromium around.
>
> > I also think that there ought to be more cooperation from the maintainers of
> > individual python2-* modules. The approved Fedora 31 Change makes it way too
> > easy for maintainers to just drop Python 2 support for no reason.
>
> When a packager doesn't want to maintain it, that's good enough reason.
>
> You have a right to orphan a package, why you should not have the right to
> orphan a half of your package, when he other half works without it?
>
> > If
> > upstream dropped Python 2 support from the current version and so an old
> > version has to be packaged specifically for Python 2, that is one good
> > reason to require somebody else to pick up maintenance, but as it stands, no
> > such reason is required and Fedora maintainers can arbitrarily drop Python 2
> > support from their Python modules even if upstream still supports it. This
> > is just pointless and unhelpful.
>
> Requiring others to maintain the packages your packages (or you) need just
> because they maintained it until now is not very friendly. Of course, you can
> ask nicely, but you cannot say this is their duty.
>
> > We can try to find people to pick up python2 and a bunch of python2-*
> > modules, but expecting the python2 maintainer(s) to sign up for maintaining
> > each and every python2-* module is unreasonable and unrealistic. Even if
> > several of them will also be dead upstream (at least the version that works
> > with Python 2) and thus require very little maintenance effort.
>
> Arguably, maintaining dead software requires more effort than maintaining live
> one. But that kinda depends on the particular package.
>
> I don't need people to maintain **all** Python 2 packages, just mine. But
> possibly other maintainers also don't want to maintain theirs. As the s

Re: efivar and mokutil long standing FTBFS

[Peter Robinson]

> On 13. 08. 19 19:43, Peter Robinson wrote:
> > Firstly they're just FTBFS in F-30 This isn't exactly long
> > standing, if it was F-26 like some that were retired I could
> > completely understand that statement but F-30 is pushing the rhetoric
> > a bit here.
>
> It has been half a year without any response. Hence it is long standing.
> You may think that half a year is not long standing. Fine. Sorry for using 
> that
> language when I should have said "6 months old" instead.
>
> >> efivar and mokutil fail to build from source. They have been retired, then
> >> unretired and they still fail to build from source.
> >
> > What do you mean by retired and unretired and still FTB?
>
> They have been retired as part of the FTBFS policy.
> Then they have been unretired and retagged because it broke the compose.
> Yet they still have not been rebuilt.

The retirement, which took me by shock and IMO wasn't well advertised,
happened while people were traveling to flock last Wednesday, and
people are still returning a week later. People also have deadlines
and real work to do and there's literally _SO_ much bugzilla mail from
all of this most people just mute it or out right delete it because
they can't damn well keep up [1]

[1] https://twitter.com/hughsient/status/1161382573228142594

> >> Following the policy:
> >> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
> >>
> >> I kindly ask the maintainers to rebuild them or orphan them if they cannot 
> >> take
> >> care of them.
> >
> > Maybe you're not aware of this thing called RHEL-8, maybe the
> > maintainer has been snowed under and as they stand they work as
> > intended and it's not exactly a complete drama if they're not fixed
> > right away. Or maybe he's drowning in email from the 8+ pointless
> > repetitive bug updates that have been added to the bugs.
>
> I believe that if a maintainer doesn't have 5 minutes to say "I'm swamped with
> RHEL 8 (or whatever else), please, can somebody help me with those FTBFS" or
> even "I don't care" they are pretty much no-maintainers. Getting the FTBFS 
> fixed
> in 6 months is not right-away. If you find the repetitive bug updates 
> pointless,
> feel free to propose a better approach.

In some cases, and using these cases as a perfect example, they
require specialised information about low level things like UEFI,
secure boot, signing of core boot process where there's specialised
information and I don't even fill up a hand of fingers listing the
people that have this skill set and all of those people are so
overloaded with work that they actively prioritide stuff. This isn't a
basic python binding here.

> > I happen to know he's working on updates to them, but he also has
> > other priorities.
>
> I don't happen to know that. The lack of communication is making it hard. For
> what i know they are not even aware of this issue.

Well the deluge of a bazillion extra bug emails doesn't help TBH. I
have generally kept up with bug emails and this is now stressing me
out I'm probably going to quit!

> Don't we all have other priorities? Is it so hard to communicate about out
> priorities openly?

Yes! For some it is.

> > There really has to be a better way to deal with this, I spoke with
> > many people, that are drowning in pointless email, like weekly SPAM
> > reminders are really too much. One group I had a discussion with are
> > well aware of the problems of their FTB packages but have other
> > priorities and fix them when they get moments between the tidal waves.
> >
> > For example the OLPC/sugar stuff I do I'm slowly, as I and they get
> > time, training others up on the packaging/Spin side of things,
> > upstream is moving towards python3 and everyone is aware of this and
> > the issues involved, but while we do this we now have hours of extra
> > work to do because a whole bunch of the packages have been ripped out
> > from under us in the process without proper notification if you happen
> > to miss an email to devel, or in some of the people I'm working with
> > aren't even on devel. PLEASE make it stop I'm actually considering
> > stopping most of my work in Fedora because it makes me way too anxious
> > to continue and that coming from me is something, I'd really hate to
> > think how many silent contributors we're losing from this.
>
> Are you proposing to stop doing exactly what? Following policies? Having
> policies? Or is something that I personally am doing that I should stop? I
> gladly head proposals of how to make things better. But "PLEASE make it 
> stop..."
> isn't really a constructive proposal.
>
> I realize that getting constant notifications is overwhelming. But when we 
> don't
> do that, people are angry about "unannounced" breakage.

Well you can't currently see the forest for the trees and this
bullshit, for the first time in 15 years in making me think about
quitting the Fedora project, and I spoke with many at Flock are
seriously stressed a

Orphaning 13 packages

[Jan Kaluza]

Hi,

I'm orphaning packages which I used to maintain in my spare time. I do
not have enough time and motivation these days/months/years to
continue maintaining them:

- adevs - https://src.fedoraproject.org/rpms/adevs
- dfish - https://src.fedoraproject.org/rpms/dfish
- gob2 - https://src.fedoraproject.org/rpms/gob2
- httpdtap - https://src.fedoraproject.org/rpms/httpdtap
- libcommuni - https://src.fedoraproject.org/rpms/libcommuni
- libeio - https://src.fedoraproject.org/rpms/libeio
- ncbi-blast+ - https://src.fedoraproject.org/rpms/ncbi-blast+
- python-restauth - https://src.fedoraproject.org/rpms/python-restauth
- python-restauth-common -
https://src.fedoraproject.org/rpms/python-restauth-common
- restauth - https://src.fedoraproject.org/rpms/restauth
- rinetd - https://src.fedoraproject.org/rpms/rinetd
- rubygem-passenger - https://src.fedoraproject.org/rpms/rubygem-passenger
- swift - https://src.fedoraproject.org/rpms/swift

I'm also going to remove myself as "maintainer" for "passenger" and
"python-mimeparse", but for these packages, there are co-maintainers,
so I'm going to ask them first before orphaning.

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

Some Java packages in need of new permanent maintainer(s)

[Fabio Valentini]

Hello packagers,

The Stewardship SIG is currently providing only bare-minimum
maintenance for some Java packages, and none of our packages depend on
them anymore.
So, we're looking for someone to take better care of them, preferably
someone who actively uses these packages or maintains a package that
depends on them.

The packages are:

- apache-commons-csv
- apache-commons-discovery
- apache-commons-el
- apache-commons-fileupload
- apache-rat
- c3p0
- emma
- geronimo-jaspic-spec
- glassfish-jsp
- gpars
- groovy
- httpunit
- jboss-connector-1.7-api
- jboss-jsf-2.1-api
- jboss-websocket-1.0-api
- jetty8
- jetty-alpn
- jetty-distribution-remote-resources
- jetty-schemas
- jetty-test-helper
- jline1
- kohsuke-pom
- maven-mapping
- xmlrpc
- xom
- zinc

Directly dependent packages of apache-commons-csv:
- HikariCP
- tika

Directly dependent packages of apache-commons-discovery:
- eclipse-webtools
- jenkins
- mx4j

Directly dependent packages of apache-commons-el:
- eclipse

Directly dependent packages of apache-commons-fileupload:
- async-http-client1
- axis2
- eclipse
- jenkins
- restlet-jse
- solr3
- sslext
- struts

Directly dependent packages of apache-rat:
- apache-commons-jcs
- apache-log4j-extras
- apache-rat
- artemis
- bval
- johnzon
- maven-shared-resources
- qpid-jms
- shiro
- terracotta-statistics

Directly dependent packages of c3p0:
- datanucleus-rdbms
- hibernate
- hibernate4
- mysql-connector-java
- quartz

Directly dependent packages of emma:
- fastutil
- time-api

Directly dependent packages of geronimo-jaspic-spec:
- jetty

Directly dependent packages of glassfish-jsp:
- eclipse
- jspc

Directly dependent packages of gpars:
- groovy
- groovy18

Directly dependent packages of groovy:
- axis2
- codenarc
- elasticsearch
- gmavenplus-plugin
- gmetrics
- gpars
- groovy
- hazelcast
- http-builder
- jamon-maven-plugin
- logback
- tesla-polyglot

Directly dependent packages of httpunit:
- httpunit
- openjpa
- picketlink-bindings

Directly dependent packages of jboss-connector-1.7-api:
- artemis
- eclipselink
- geronimo-txmanager
- jboss-transaction-spi

Directly dependent packages of jboss-jsf-2.1-api:
- apache-commons-chain

Directly dependent packages of jboss-websocket-1.0-api:
- jetty
- johnzon
- tyrus

Directly dependent packages of jetty8:
- apacheds
- async-http-client1
- jenkins-winstone
- littleproxy

Directly dependent packages of jetty-alpn:
- jetty

Directly dependent packages of jetty-distribution-remote-resources:
- jetty

Directly dependent packages of jetty-schemas:
- jetty

Directly dependent packages of jetty-test-helper:
- jetty

Directly dependent packages of jline1:
- frysk
- groovy18
- jenkins
- zookeeper

Directly dependent packages of kohsuke-pom:
- access-modifier-annotation
- akuma
- groovy-sandbox
- libpam4j
- metainf-services
- trilead-putty-extension

Directly dependent packages of maven-mapping:
- maven-war-plugin

Directly dependent packages of xmlrpc:
- eclipse-mylyn
- eclipse-pydev
- ini4j
- rome
- swizzle

Directly dependent packages of xom:
- jenkins-xstream
- json-lib
- maven-eclipse-plugin
- saxon
- validator-htmlparser

Directly dependent packages of zinc:
(none)


If you received this email directly, you're a (co-)maintainer of one
of these packages, and would probably be best qualified to take care
of the package in question.

If you want to take one, some, or all of them off our hands, just fill
out the "package_adoption_request" template here, and we will transfer
the package to you.
https://www.pagure.io/stewardship-sig/new_issue

If nobody claims the packages within the next two weeks, we will
orphan them again, setting them on their course towards retirement in
about two months.

Thanks,
Fabio (decathorpe), for the Stewardship SIG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 System-Wide Change: glusterfs dropping 32-bit arches

[Panu Matilainen]

On 8/14/19 12:28 PM, Florian Weimer wrote:

* Panu Matilainen:


Attitudes like that is why there's rottenware in the distro that last
actually worked sometime around 2011, dutifully rebuilt on each
mass-rebuild and even spec cleanups taking place but the software
itself crashes on startup (or is otherwise entirely dysfunctional)
ever since.


I think that's only a problem if reported bugs don't get fixed.  If such
bugs are fixed, shipping everything that builds aligns well with
building a community-tested distribution.


Part of the problem is the auto-close of bugs. When bugs get auto-closed 
for the umpteenth time without anybody attending them, people tend to 
give up, and the component ends up looking like there are no bugs at 
all. Which actually is quite a good indicator of a broken, dead package...


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

Some NodeJS packages in need of new permanent maintainer(s)

[Fabio Valentini]

Hello packagers,

The Stewardship SIG is currently providing only bare-minimum
maintenance for some NodeJS packages, and none of our packages depend
on them anymore.
So, we're looking for someone to take better care of them, preferably
someone who actively uses these packages or maintains a package that
depends on them.

The packages are:

- nodejs-formatio
- nodejs-lolex
- nodejs-samsam
- nodejs-util

Directly dependent packages of nodejs-formatio:
- nodejs-sinon

Directly dependent packages of nodejs-lolex:
- nodejs-sinon

Directly dependent packages of nodejs-samsam:
- nodejs-formatio
- nodejs-sinon

Directly dependent packages of nodejs-util:
- nodejs-sinon

If you received this email directly, you're a (co-)maintainer of
nodejs-sinon, and would probably be best qualified to take care of
these packages.

If you want to take some or all of them off our hands, just fill out
the "package_adoption_request" template here, and we will transfer the
package to you.
https://www.pagure.io/stewardship-sig/new_issue

If nobody claims the package within the next two weeks, we will orphan
it again, setting it on its course towards retirement in about two
months.

Thanks,
Fabio (decathorpe), for the Stewardship SIG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 System-Wide Change: glusterfs dropping 32-bit arches

[Florian Weimer]

* Panu Matilainen:

> Attitudes like that is why there's rottenware in the distro that last
> actually worked sometime around 2011, dutifully rebuilt on each
> mass-rebuild and even spec cleanups taking place but the software
> itself crashes on startup (or is otherwise entirely dysfunctional)
> ever since.

I think that's only a problem if reported bugs don't get fixed.  If such
bugs are fixed, shipping everything that builds aligns well with
building a community-tested distribution.

Exceptions could be software that leads to purchases of some kind, based
on an incorrect assumption of Fedora support due to the existence of the
non-working package.

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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Panu Matilainen]

On 8/14/19 10:59 AM, Andreas Tunek wrote:



On Tue, 13 Aug 2019, 23:33 Kevin Kofler, > wrote:


Kaleb Keithley wrote:
 > Building it on 32-bit in the CI is only to ensure correctness of
sprintf
 > format strings. It's a compile-only test.

And that is sufficient. As long as it compiles, you can package it.
Whether
upstream "supports" it or not is irrelevant.

         Kevin Kofler



If it compiles, ship it!



That's not fun at all.

Attitudes like that is why there's rottenware in the distro that last 
actually worked sometime around 2011, dutifully rebuilt on each 
mass-rebuild and even spec cleanups taking place but the software itself 
crashes on startup (or is otherwise entirely dysfunctional) ever since.


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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Aleksandar Kurtakov]

On Wed, Aug 14, 2019 at 11:29 AM Miro Hrončok  wrote:

> On 14. 08. 19 8:55, Frantisek Zatloukal wrote:
> > It depends on package maintainer. If upstream dropped 32-bit support,
> I'd stop
> > building it for that arch in Fedora.
> >
> > Why would package maintainer have to bear the burden of potential
> breakage if
> > upstream doesn't test it?
>
> If neither of my upstreams officially supports s390x, should I just drop
> it
> everywhere?
>

The real question which every packager should ask himself is: Do I have the
capacity (time, knowledge, hardware, etc.) to solve problems on
non-supported architecture by upstream?
And if the answer is no - it is probably better to drop the arch instead of
shipping smth that not even the maintainer knows whether it is usable at
all (like I used to ship eclipse on 32 bit arm although I'm quite sure it
was not usable at all).


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


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 System-Wide Change: glusterfs dropping 32-bit arches

[Miro Hrončok]

On 14. 08. 19 8:55, Frantisek Zatloukal wrote:
It depends on package maintainer. If upstream dropped 32-bit support, I'd stop 
building it for that arch in Fedora.


Why would package maintainer have to bear the burden of potential breakage if 
upstream doesn't test it?


If neither of my upstreams officially supports s390x, should I just drop it 
everywhere?


--
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: Where can I remove myself from bug emails for packages I am not a maintainer anymore

[Petr Pisar]

On 2019-08-13, Robert Marcano  wrote:
> I am not maintaining eclipse-subclipse from a long time ago, I am not 
> listed as a member at 
> https://src.fedoraproject.org/rpms/eclipse-subclipse but I still get 
> FTBFS bugzilla emails.
>
That's because synchronization from dist-git Pagure to Bugzilla is
broken .

I recommend you to file a new request for removing you form default CC
of that Bugzilla component at
.

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

Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches

[Andreas Tunek]

On Tue, 13 Aug 2019, 23:33 Kevin Kofler,  wrote:

> Kaleb Keithley wrote:
> > Building it on 32-bit in the CI is only to ensure correctness of sprintf
> > format strings. It's a compile-only test.
>
> And that is sufficient. As long as it compiles, you can package it.
> Whether
> upstream "supports" it or not is irrelevant.
>
> Kevin Kofler
>


If it compiles, ship 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Proper way to keep service enabled when updated from sysv to systemd?

[Robin Lee]

On Tue, Aug 13, 2019 at 10:37 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Aug 13, 2019 at 06:02:42PM +0800, Robin Lee wrote:
> > Hi,
> >
> > I packaged xe-guest-utilities with a systemd service for Fedora.
> >
> > But there is an upstream rpm package that include the same service as
> > a sysv one. And the
> > service is enabled with the 'Default-Start' info in the init script
> > after '/sbin/chkconfig --del xe-linux-distribution'.
> >
> > And when people update the package from upstream one to the Fedora
> > one. Since the service changed to a systemd one. The service is then
> > disabled by default without regard to the sysv service.
> >
> > That surprises end users. So the new package should make it compatible
> > in the scriptlets.
> > But which is the proper way?
>
> You can add a %trigger script. Something like this, completely untested:
> %triggerun xe-linux-distribution < …old…version+1…
> if test -e /etc/rc.d/rc3.d/Snn-…; then
># enable systemd service based on old status
>systemctl enable xe-linux-distribution.service
> fi

Thanks for your tips!

I now use such version:

%triggerun -- %{name}
if /bin/ls /etc/rc3.d/S*%{service_name} >/dev/null 2>&1; then
# Re-enable the service if it was enabled in sysv mode
/usr/bin/systemctl enable %{service_name} >dev/null 2>&1||:
/bin/rm /etc/rc3.d/S*%{service_name} >/dev/null 2>&1||:
/usr/bin/systemctl try-restart %{service_name} >dev/null 2>&1||:
fi

>
> Please note that for new packages, the general guidelines apply
> (https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/)
> and services should be managed through presets. But keeping enablement
> state on upgrade is outside of the guidelines and a nice thing to do.
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org