ABI change announce svt-vp9

[Vascom]

ABI changed in svt-vp9 0.1.1 release.
All changes 
https://taskotron.fedoraproject.org/artifacts/all/6720382c-ebf1-11e9-904f-52540077ca13/tests.yml/svt-vp9-0.1.1-1.fc32.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Temporarily using `best=False' for EPEL-8 builds in Copr

[Leigh Scott]

Shame on Redhat for using an untested feature 
https://bugzilla.redhat.com/show_bug.cgi?id=1671683
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: koji web interface is very slow

[Orion Poplawski]

On 10/10/19 4:57 PM, Orion Poplawski wrote:

On 10/10/19 9:23 AM, Kevin Fenzi wrote:

On Thu, Oct 10, 2019 at 03:30:40PM +0200, Robert-André Mauchin wrote:

On Thursday, 10 October 2019 04:42:57 CEST Orion Poplawski wrote:

Anyone else seeing this?  If so, anyone know the reason and plans to
fix?  Thanks!


I concur, yesterday it was taking around  a minute to get an answer 
from the

server.


Pretty please can you all indicate approximately when (UTC) you were
seeing the slowness? I suspect it may be the nightly database dump job,
but I can't tell without knowing when you saw the slowness...

I did a bunch of work recently to make it faster... but that seems to
have made the db dump cause it to be much slower.

This includes bumping the memory on the vm from 32gb to 120gb,
increasing postgresql's shared_buffers to 48G and effective_cache size
to 32GB.

I just killed the dump that was running.
Can you all confirm it's much faster after 15:15UTC?

If indeed it's the dump, will try and figure out a way to tune it
better.


Thanks, it is much better now.  I feel like I've hit periods of slowness 
over several days recently so I will definitely note times if I run into 
it again.


Definitely slower again:
Fri Oct 11 02:20:53 UTC 2019


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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: Temporarily using `best=False' for EPEL-8 builds in Copr

[Nico Kadel-Garcia]

> On Oct 10, 2019, at 7:34 PM, Jakub Kadlcik  wrote:
> 
> Hello,
> 
> currently, there is a problem with building EPEL-8 packages because of
> DNF bugs regarding modularity (see RHBZ 1758459).
> 
> The only known workaround is to use DNF with `best=False'. Even though
> it is something you don't really want to use longterm, we are patching
> mock configs epel-8-* chroots, so there can be at least some EPEL-8
> building in Copr.

These bugs exist in RHEL 8 as well as CentOS 8 based environments. Why do you 
think that modularity will *ever* work this way?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and the system-upgrade path

[Kevin Kofler]

Lukas Ruzicka wrote:
> Just for illustration, this is what I wanted to say about it:
> 
>1. Modularity should stay away from my system until I call for it ->
>now it is not the case, because modularity sneaks into users' computer
>through modular defaults that overcome the non-modular packages. Gimp
>is the first such "horse" that jumps into almost everybody's desktop
>and they are modular without even knowing it.
>2. Modularity should provide alternative content, if I need it and when
>I need it. Modules should be installable only through "dnf module"
>command and not through the regular dnf command, so that I explicitely
>need to allow modularity on my system.
>3. The naming conventions of the streams should be *obligatory* for
>every module packager. So, if we decide that we want a "latest" stream,
>then all modules should have a "latest" stream for rolling updates.
>Currently, they all have various names of streams, from which I cannot
>tell anything. If there should be a "slow" path, then again, all
>modules should have a "slow" path.
>4. Non-modular Fedora must be a valid use case and remain an option.
>5. If I decide to go modular, there must be a way to go non-modular
>again, without breaking the system. Or, if modular is the only option,
>so if I go into specific streams, there must be a way to go to defaults
>without breaking the system. With non-modular defaults, this seems
>easy. With modules? I am not sure.
>6. We need to expect that once there are hundreds of modules, people
>will install all possible combinations and they all will need to work.
>I am not sure, we will be able to test something like that.

+1 to all of the above.

> Seeing the reaction of the Modularity WG ... I do not understand how it is
> possible that such important decisions are taken by 4 people without any
> Fedora wide discussions like this. And yet, it seems a little bit that
> even opinions on this list will not fall on fertile grounds.

Indeed, this is a real issue.

I think what needs to happen is that the people who allowed this to happen 
get voted out of FESCo, at least if they still refuse to act on the mailing 
list feedback. They no longer seem to have a majority behind them, if they 
even ever did. But for that to happen, we need to have people actually 
running for FESCo and taking a clear position against forced Modularity 
(i.e., either make Modularity fully optional as proposed in this thread or 
axe it entirely, no third option). Democracy can only possibly work if there 
is an actual choice of candidates with non-uniform positions. In the last 
few elections, pretty much all the candidates uniformly claimed that 
Modularity was great and the way to go, only a few (like Miro) had some 
reservations about it (but still did not dare actually declaring themselves 
AGAINST Modularity in the election campaign – Miro's proposal in this thread 
definitely goes the right way though).

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: Defining the future of the packager workflow in Fedora

[Kevin Kofler]

Matthew Miller wrote:
> On Thu, Oct 10, 2019 at 12:28:37AM +0200, Kevin Kofler wrote:
>> The problem does not only happen if the module is a non-leaf at module
>> level, but there can also be conflicts at package level, if the modules
>> bundle non-leaf packages that then conflict between the 2 modules.
>
> Yes. I'm less worried about that because I think containerization is the
> right answer for most of these cases. I realize that reasonable people can
> disagree with me on this, but it's definitely the general trend on
> servers, devices, and desktops.

And I think you are absolutely wrong, for the reasons I have already stated 
in:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LODBTWKZAKR2XPW2AAVVGFKYQH24FLKF/

I shall also point out that there is no difference between module-level 
conflicts and package-level conflicts there: both can be "solved" by 
containerizing the conflicting modules. But this is a very heavy workaround 
for a conflict that is really the distribution's job to avoid. (I would even 
argue that this is even the whole purpose of a distribution, as opposed to 
just downloading random software directly from random sources.)

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

Temporarily using `best=False' for EPEL-8 builds in Copr

[Jakub Kadlcik]

Hello,

currently, there is a problem with building EPEL-8 packages because of
DNF bugs regarding modularity (see RHBZ 1758459).

The only known workaround is to use DNF with `best=False'. Even though
it is something you don't really want to use longterm, we are patching
mock configs epel-8-* chroots, so there can be at least some EPEL-8
building in Copr.

(I am doing the change right now, but it won't affect already
spined-up builders. It will take a while until they get recycled and
use new configuration)

Once the DNF issues get resolved, we are going to drop those patches
and use `best=True` again.

For additional information, please see RHBZ 1756681 and RHBZ 1758467.


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

module package exclusion behavior on EL8

[Orion Poplawski]

I continue to run into strange (at least to me) issues with modules on 
EL8.  RHEL8 ships a 'rhn-tools' module that ships only the "koan" 
package from the cobbler srpm [1].  When this module is enabled, I 
cannot install cobbler from my copr - dnf reports that 'cobbler' is 
excluded.


Can someone fill me in more on this.? Is this expected?  I don't see 
anything in the module file (assuming I have the right module file) that 
specifically calls out cobbler for exclusion (such as a filter entry) - 
so is it just automatically creating an exclusion for all unshipped 
packages?


There is very little feedback from dnf - the cobbler package simply 
disappears:


# dnf list cobbler
Available Packages
cobbler.noarch  3.0.1-2.el8 copr:copr.fedorainfracloud.org:orion:cobbler
cobbler.src 3.0.1-2.el8 copr:copr.fedorainfracloud.org:orion:cobbler

# dnf module enable rhn-tools

# dnf list cobbler
Available Packages
cobbler.src 3.0.1-2.el8 copr:copr.fedorainfracloud.org:orion:cobbler

# dnf install cobbler
No match for argument: cobbler

What then does this imply for us being able to provide a cobbler module 
(or just package) for EPEL?



1 - 
https://git.centos.org/modules/rhn-tools/blob/c8-stream-1.0/f/rhn-tools.yaml



--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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: koji web interface is very slow

[Orion Poplawski]

On 10/10/19 9:23 AM, Kevin Fenzi wrote:

On Thu, Oct 10, 2019 at 03:30:40PM +0200, Robert-André Mauchin wrote:

On Thursday, 10 October 2019 04:42:57 CEST Orion Poplawski wrote:

Anyone else seeing this?  If so, anyone know the reason and plans to
fix?  Thanks!


I concur, yesterday it was taking around  a minute to get an answer from the
server.


Pretty please can you all indicate approximately when (UTC) you were
seeing the slowness? I suspect it may be the nightly database dump job,
but I can't tell without knowing when you saw the slowness...

I did a bunch of work recently to make it faster... but that seems to
have made the db dump cause it to be much slower.

This includes bumping the memory on the vm from 32gb to 120gb,
increasing postgresql's shared_buffers to 48G and effective_cache size
to 32GB.

I just killed the dump that was running.
Can you all confirm it's much faster after 15:15UTC?

If indeed it's the dump, will try and figure out a way to tune it
better.


Thanks, it is much better now.  I feel like I've hit periods of slowness 
over several days recently so I will definitely note times if I run into 
it again.



--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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: Non-responsive maintainer: awjb (Andreas Bierfert)

[Robbie Harwood]

Andreas Bierfert  writes:

> On Thu, 2019-10-10 at 14:23 -0400, Robbie Harwood wrote:
>> Hello,
>> 
>> In accordance with Fedora non-responsive maintainer policy, I'm
>> sending this message in attempt to contact Andreas Bierfert (awjb).
>> 
>> Required non-responsive maintainer bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1760528
>> 
>> Open unaddressed bugs (53 in total):
>> https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&classification=Fedora&email1=andreas.bierfert%40lowlatency.de&emailassigned_to1=1&emailtype1=substring&list_id=10561046&product=Fedora&query_format=advanced
>> 
>> I'm specifically looking for a resolution to a longstanding issue
>> where rxvt-unicode's terminfo isn't present in ncurses - that's
>> tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1741278 and
>> https://bugzilla.redhat.com/show_bug.cgi?id=1430935 (oldest for this
>> is https://bugzilla.redhat.com/show_bug.cgi?id=949921 ) both of which
>> have longstanding NEEDINFO on awjb.
>> 
>> Also in this list are multiple unaddressed CVE bugs (rxvt, rxvt-
>> unicode, ncmpc, dosbox) and nineteen FTBFS in rawhide.
>
> Hi Robbie,
>
> I am not totally missing in action (at least not yet)
>
> I am just super involved with some pretty big work projects and (for
> the fun of it) with some big private projects at the same time.
>
> That is why I could not jump in to take care of these outstanding bugs
> and put in the care I would like to put in for my packages. This stuff
> will go on till early next year... :/. I would like to come back with
> much more time once this stuff is done.

Okay, so here's the problem.  Not only have you not been maintaining
your packages, but you also haven't been communicating with *anyone* as
far as I can tell.  You certainly haven't been answering your NEEDINFOs
on bugzilla.

Do you plan to hand off packages you no longer have time for?  For
instance, wine is being handled by mooninite, and dosbox by fcami, but
they're not primary maintainer.  More importantly, what about packages
for which you have no co-maintainer?

> As it is all about collaboration I am more than happy for you to jump
> in and help with the rxvt stuff if you are interested in it.

Yes, I'm happy to help with that.  My understanding is that we need to
coordinate moving the terminfo files with ncurses and that's the only
obstacle.  So it requires commit bits.

Are your comaintainers runcom and jamielinux inactive?

> I will try to have a look at the pressing issues next week and see
> what I can cook up with the spare time I have on my hands atm.

Okay.

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: FreeCAD required updates (PySide2 & Coin4)

[Richard Shaw]

On Thu, Oct 10, 2019 at 2:36 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> > So the PRs were for Rawhide, but the bug I'm trying to fix exists on all
> > supported Fedora releases. I wasn't planning on updating F29 at this
> point
> > but F30 does have a lot of life left.
> >
> > I don't like the idea of major upgrades within a release but the list of
> > dependencies (as noted by the list of PRs) is fairly small and through my
> > COPR I have found no *build* issues with the update.
> >
> > I'm open to suggestion here but I don't like leaving broken software in
> > Fedora and basically having to tell the user, "It's fixed in Rawhide so
> > you'll get it eventually..."
> >
> > Thoughts?
>
> Let's get everything built and tested in rawhide first. Based
> on how this turns out, an update in F30 and F31 might be appropriate
> (with a suitably long testing period, etc). I agree that if the version
> in stable Fedora is sufficiently broken, it's better to release an
> working update with major version changes than to do nothing.
>

FreeCAD is now built for Rawhide. I don't run rawhide so not much I can
test but I did built the same stack in my COPR for F30 and 31 as well and
tested FreeCAD as best I could.

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

Re: s390x: glibc32 and gcc

[Jerry James]

On Thu, Oct 10, 2019 at 12:39 AM Florian Weimer  wrote:
> Sorry, I wasn't aware that you were trying to rebuild gcc this week.  I
> spoke to Jakub about the glibc32 change, and he had no objections.
>
> It's not clear how you are handling the transition.  Why do you need to
> change GCC build requirements?  Did anyone request this?
>
> I would have expected a run-time-only compat-mpfr library with the old
> soname, so that GCC keeps working until it is rebuilt.

It's a little trickier than you might expect, because of libmpc, which
is also linked with mpfr.  We had to come up with a way to have mpfr
3, libmpc linked with mpfr 3, mpfr 4, and libmpc linked with mpfr 4
all in the build root at the same time, the former two for the
existing gcc, the latter two to build the new gcc.  That was the
sticking point with the previous effort to move to mpfr 4, back in the
F28 timeframe.  My solution (which no doubt could be improved upon)
was described in the 5th message of this thread, back in July:

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

I don't understand your question about changing GCC build
requirements.  They're changing *back* now, to what they were before
the transition began; i.e., mpfr-devel and libmpc-devel.

Thanks for responding so quickly.  I appreciate you fixing the gcc
build and getting it restarted.  I expect it will finish while I am
sleeping tonight, so I'll get the rest of the builds launched first
thing in the morning tomorrow.  Given that we still have to get
through the flint-Singular-polymake-sagemath sequence of builds, they
probably won't finish until Sunday night, or possibly even Monday
morning.  I appreciate everybody's patience with this process.

Regards,
-- 
Jerry James
http://www.jamezone.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: Non-responsive maintainer: awjb (Andreas Bierfert)

[Robbie Harwood]

... and that's the wrong list.  My bad.

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

Non-responsive maintainer: awjb (Andreas Bierfert)

[Robbie Harwood]

Hello,

In accordance with Fedora non-responsive maintainer policy, I'm sending
this message in attempt to contact Andreas Bierfert (awjb).

Required non-responsive maintainer bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1760528

Open unaddressed bugs (53 in total):
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&classification=Fedora&email1=andreas.bierfert%40lowlatency.de&emailassigned_to1=1&emailtype1=substring&list_id=10561046&product=Fedora&query_format=advanced

I'm specifically looking for a resolution to a longstanding issue where
rxvt-unicode's terminfo isn't present in ncurses - that's tracked in
https://bugzilla.redhat.com/show_bug.cgi?id=1741278 and
https://bugzilla.redhat.com/show_bug.cgi?id=1430935 (oldest for this is
https://bugzilla.redhat.com/show_bug.cgi?id=949921 ) both of which have
longstanding NEEDINFO on awjb.

Also in this list are multiple unaddressed CVE bugs (rxvt, rxvt-unicode,
ncmpc, dosbox) and nineteen FTBFS in rawhide.

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: koji web interface is very slow

[Sérgio Basto]

On Thu, 2019-10-10 at 08:23 -0700, Kevin Fenzi wrote:
> On Thu, Oct 10, 2019 at 03:30:40PM +0200, Robert-André Mauchin wrote:
> > On Thursday, 10 October 2019 04:42:57 CEST Orion Poplawski wrote:
> > > Anyone else seeing this?  If so, anyone know the reason and plans
> > > to
> > > fix?  Thanks!
> > 
> > I concur, yesterday it was taking around  a minute to get an answer
> > from the 
> > server.
> 
> Pretty please can you all indicate approximately when (UTC) you were
> seeing the slowness? I suspect it may be the nightly database dump
> job,
> but I can't tell without knowing when you saw the slowness...
> 
> I did a bunch of work recently to make it faster... but that seems to
> have made the db dump cause it to be much slower. 
> 
> This includes bumping the memory on the vm from 32gb to 120gb,
> increasing postgresql's shared_buffers to 48G and effective_cache
> size
> to 32GB. 
> 
> I just killed the dump that was running. 
> Can you all confirm it's much faster after 15:15UTC?

yes , is much faster than yesterday , yesterday (2019-10-09 07:02:40 or
2019-10-08 22:32:15 ) I felt some slowness but not as much as described
by Robert



> If indeed it's the dump, will try and figure out a way to tune it
> better. 
> 
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Defining the future of the packager workflow in Fedora

[Matthew Miller]

On Thu, Oct 10, 2019 at 12:28:37AM +0200, Kevin Kofler wrote:
> > Yeah, I agree that there's a problem with non-parallel-installable modules
> > that aren't effectively leaves.
> The problem does not only happen if the module is a non-leaf at module 
> level, but there can also be conflicts at package level, if the modules 
> bundle non-leaf packages that then conflict between the 2 modules. 

Yes. I'm less worried about that because I think containerization is the right
answer for most of these cases. I realize that reasonable people can
disagree with me on this, but it's definitely the general trend on servers,
devices, and desktops.

-- 
Matthew Miller

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

Re: Fedora 32 Self-Contained Change proposal: Replace Bazaar with Breezy

[Miro Hrončok]

On 09. 10. 19 15:14, Ben Cotton wrote:

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

Note that this was originally discussed on the devel mailing list:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQX67DLC/#TBWSCGWFSGUFFYIBEAIOSPSP43WYQ7WI



Some updates here:

 1. breezy is packaged in f32 and f31, [update] in testing
 2. breezy does not replace bzr yet, but there is a [bcond] to be flipped in f32
 3. the Python 3.8 issue has a working workaround in [pr]


[update] https://bodhi.fedoraproject.org/updates/FEDORA-2019-7fb253a20a
[bcond] https://src.fedoraproject.org/rpms/breezy/blob/master/f/breezy.spec#_13
[pr] https://src.fedoraproject.org/rpms/breezy/pull-request/1

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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Miro Hrončok]

On 10. 10. 19 17:46, Igor Gnatenko wrote:

On Thu, Oct 10, 2019 at 12:52 AM Miro Hrončok  wrote:


On 09. 10. 19 22:46, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot

Enable module default streams in the buildroot repository for modular
and non-modular RPMs.

== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
"traditional") RPMs.

== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com
* Responsible WG: Modularity WG

== Detailed Description ==
As a major part of the Modularity design, we have a concept of default
module streams. These streams are built as modules, but the RPM
artifacts they deliver are intended to be used just like non-modular
RPMS. The aspirational goal is that a user of the system who never
executes a module-specific command (such as `dnf module install
nodejs:8`) should experience no meaningful changes in behavior from
how they would interact with a completely non-modular system. In
practice, this may mean that the informational output of package
managers may indicate that modules are being enabled and used, but a
user that does not have a specific reason to interact with the
selection of a module stream should have that managed on their behalf.


If this is the goal of default modular streams, wouldn't it be in fact much
easier to keep the default versions as urisne packages?


That means, you have 2 different workflows: for default version and
for an additional one.
When branching happens, instead of just updating one file which points
to the new default, you would have to create new stream, retire the
one which is about to become default and update package in
non-modular.



Yes. It puts additional (arguably fairly trivial) work for the modular 
maintainers. Other than that, it makes lives of every other maiantainar, of the 
dnf maintainers and of Fedora users easier.


I call it a good deal.

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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Igor Gnatenko]

On Thu, Oct 10, 2019 at 12:52 AM Miro Hrončok  wrote:
>
> On 09. 10. 19 22:46, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> >
> > Enable module default streams in the buildroot repository for modular
> > and non-modular RPMs.
> >
> > == Summary ==
> > This Change (colloquially referred to as "Ursa Prime") enables the
> > Koji build-system to include the RPM artifacts provided by module
> > default streams in the buildroot when building non-modular (or
> > "traditional") RPMs.
> >
> > == Owner ==
> > * Name: [[User:Sgallagh| Stephen Gallagher]]
> > * Email: sgall...@redhat.com
> > * Responsible WG: Modularity WG
> >
> > == Detailed Description ==
> > As a major part of the Modularity design, we have a concept of default
> > module streams. These streams are built as modules, but the RPM
> > artifacts they deliver are intended to be used just like non-modular
> > RPMS. The aspirational goal is that a user of the system who never
> > executes a module-specific command (such as `dnf module install
> > nodejs:8`) should experience no meaningful changes in behavior from
> > how they would interact with a completely non-modular system. In
> > practice, this may mean that the informational output of package
> > managers may indicate that modules are being enabled and used, but a
> > user that does not have a specific reason to interact with the
> > selection of a module stream should have that managed on their behalf.
>
> If this is the goal of default modular streams, wouldn't it be in fact much
> easier to keep the default versions as urisne packages?

That means, you have 2 different workflows: for default version and
for an additional one.
When branching happens, instead of just updating one file which points
to the new default, you would have to create new stream, retire the
one which is about to become default and update package in
non-modular.

> > Similarly, the experience for package maintainers of non-modular
> > packages should be unaffected by an RPM dependency moving from the
> > non-modular repository into a default module stream. Up to the
> > present, this has not been the case; no module stream content has been
> > available in the non-modular buildroot for other packages to consume.
> > Koji builds of non-modular RPMs have had only the other non-modular
> > RPMs from that release available to their buildroots. In contrast,
> > building on local systems has access to both the non-modular RPMs and
> > the RPMs from any of the default module streams. With this Change,
> > Koji builds will have the same behavior and be able to depend on
> > content provided by default module streams. It also enables the same
> > behavior for Modular builds: the `platform` stream will now include
> > the contents of the default module streams for each release and do not
> > need to be explicitly specified in the modulemd `buildrequires`.
>
> What I miss in the description is:
>
> 1. How does this thing actually work? is there an additional repository 
> composed
> from the default streams available in Koji only?
>
> 2. How are conflicts between packages from the default streams and ursine
> package be handled?
>
> 3. What is the local experience if the packager is using mock. What if they 
> are
> using rpmbuild directly?
>
> 4. How are we handling default streams with dependencies on non-default 
> streams
> of other modules?
>
> > ...
> > == Scope ==
> > * Proposal owners:
> > # Update Packaging Guidelines with
> > [https://pagure.io/modularity/issue/146#comment-600328 requirements]
> > for module default streams
> > # Create a Pungi configuration to generate the buildroot from the
> > default module streams.
> > # Include `default_modules_scm_url` in the platform virtual module 
> > specification
> > # Configure Koji tags for inheriting the new modular-defaults
> > buildroot into the standard buildroot
> >
> > * Other developers:
> >
> > Packagers of default module streams will be required to conform to the
> > [https://pagure.io/modularity/issue/146#comment-600328 policy]
> > regarding visibility of stream artifacts. Any default module stream
> > that is not in compliance by one week before Beta Freeze will cease to
> > be a default stream.
>
> What are the packagers of ursine packages that are shadowed by their modular
> counterparts supposed to do here (assuming such shadowing happens)?
>
> What are the packagers of modular packages that are shadowed by their ursine
> counterparts supposed to do here (assuming such shadowing happens)?
>
> > ...
> > == How To Test ==
> > # Build a modular stream
> > # Make that stream a default stream (or a buildroot override)
> > # Build a non-modular RPM that requires an artifact RPM from the modular 
> > stream.
>
> How can I test this as an ursine package maintainer assuming I have build
> dependencies that were ursine packages but now will be form modules?
>
> > ...
> > == Contingency Plan ==
> > * Contingency mechanism: Dis

Re: Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Mattia Verga via devel]

Il 10/10/19 16:35, Ben Cotton ha scritto:
> == Scope ==
> All packages depending on `fpc` should be rebuilt with the new `fpc`
> once it hits F32, or, if there is not enough time for that, just all
> packages built after the new `fpc` hits the buildroots.
>
> * Proposal owners:
> ** Update the `fpc` package to version 3.2.0.
> ** Cross-compile the compiler for AArch64 and ppc64le (required for
> bootstrapping).
> ** Add AArch64 and ppc64le to the `ExclusiveArch:` tag in the package spec.

Just update `fpc-rpm-macros` package first, then set `ExclusiveArch:  
%{fpc_arches}` and rebuild.

Really, all packages depending on fpc should just use that macro as 
ExclusiveArch and then, if needed, set any ExcludeArch.

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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Igor Gnatenko]

> https://pagure.io/releng/issue/8880 - Include default_modules_scm_url in 
> platform 31 virtual module

platform *f32*?

Other than that, it would be nice to have more specific rules *when*
and *how* modules are checked to conform to the guidelines…


On Wed, Oct 9, 2019 at 10:51 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
>
> Enable module default streams in the buildroot repository for modular
> and non-modular RPMs.
>
> == Summary ==
> This Change (colloquially referred to as "Ursa Prime") enables the
> Koji build-system to include the RPM artifacts provided by module
> default streams in the buildroot when building non-modular (or
> "traditional") RPMs.
>
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgall...@redhat.com
> * Responsible WG: Modularity WG
>
> == Detailed Description ==
> As a major part of the Modularity design, we have a concept of default
> module streams. These streams are built as modules, but the RPM
> artifacts they deliver are intended to be used just like non-modular
> RPMS. The aspirational goal is that a user of the system who never
> executes a module-specific command (such as `dnf module install
> nodejs:8`) should experience no meaningful changes in behavior from
> how they would interact with a completely non-modular system. In
> practice, this may mean that the informational output of package
> managers may indicate that modules are being enabled and used, but a
> user that does not have a specific reason to interact with the
> selection of a module stream should have that managed on their behalf.
>
> Similarly, the experience for package maintainers of non-modular
> packages should be unaffected by an RPM dependency moving from the
> non-modular repository into a default module stream. Up to the
> present, this has not been the case; no module stream content has been
> available in the non-modular buildroot for other packages to consume.
> Koji builds of non-modular RPMs have had only the other non-modular
> RPMs from that release available to their buildroots. In contrast,
> building on local systems has access to both the non-modular RPMs and
> the RPMs from any of the default module streams. With this Change,
> Koji builds will have the same behavior and be able to depend on
> content provided by default module streams. It also enables the same
> behavior for Modular builds: the `platform` stream will now include
> the contents of the default module streams for each release and do not
> need to be explicitly specified in the modulemd `buildrequires`.
>
> Note: This Change does not address the other major Modularity issue we
> are facing around distribution upgrades with differing default
> streams. When discussing this Change, please keep that topic separate.
>
> == Benefit to Fedora ==
>
> This will simplify the lives of package maintainers in Fedora in two
> primary ways. I'll use a hypothetical example of the Node.js
> interpreter and a JSApp package which is capable of running on Node.js
> 10 or 12 (but requires newer features than are provided by Node.js 8).
> Additionally, the JSApp package requires the same versions of Node.js
> at build-time.
>
> * Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> streams. The `nodejs:10` stream is set as the default stream.
> * Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
> streams. The `nodejs:10` stream is set as the default stream.
> * Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
> `nodejs:12` stream is set as the default stream. The `nodejs:14`
> stream will likely become available during the F31 lifetime.
> * Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
> `nodejs:12` stream is set as the default stream. The `nodejs:14`
> stream will likely become available during the F32 lifetime.
>
> On Fedora 29 through 31, the Node.js package maintainer needs to build
> the `nodejs:10` package both as a module and as a non-modular RPM in
> the distribution so that the JSApp package can be built. With this
> Change, the Node.js package maintainer in Fedora 32+ will only need to
> build the various Node.js streams and make one of them the default
> stream. The packages from it will then be added to the buildroot for
> non-modular packages. This will also make the packaging process
> somewhat more efficient, as the maintainer needs only to manage the
> module stream and the MBS will build it for all configured platforms.
>
> Similarly, from the perspective of dependent maintainers, there will
> no longer be anxiety about needing to move their package to a module
> if one or more of their dependencies drops their non-modular version
> in favor of a default stream. Their builds will continue to work as
> they do today.
>
> == Scope ==
> * Proposal owners:
> # Update Packaging Guidelines with
> [https://pagure.io/modularity/issue/146#comment-600328 requirements]
> for module default streams

Re: koji web interface is very slow

[Kevin Fenzi]

On Thu, Oct 10, 2019 at 03:30:40PM +0200, Robert-André Mauchin wrote:
> On Thursday, 10 October 2019 04:42:57 CEST Orion Poplawski wrote:
> > Anyone else seeing this?  If so, anyone know the reason and plans to
> > fix?  Thanks!
> 
> I concur, yesterday it was taking around  a minute to get an answer from the 
> server.

Pretty please can you all indicate approximately when (UTC) you were
seeing the slowness? I suspect it may be the nightly database dump job,
but I can't tell without knowing when you saw the slowness...

I did a bunch of work recently to make it faster... but that seems to
have made the db dump cause it to be much slower. 

This includes bumping the memory on the vm from 32gb to 120gb,
increasing postgresql's shared_buffers to 48G and effective_cache size
to 32GB. 

I just killed the dump that was running. 
Can you all confirm it's much faster after 15:15UTC?

If indeed it's the dump, will try and figure out a way to tune it
better. 

kevin


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

Logs from Open NeuroFedora team meeting: 1500 UTC on Thursday, 10th October

[Ankur Sinha]

Hello,

We had a rather short meeting where I quickly ran over the agenda. A few
action items are pending, so we'll work on those:


===
#fedora-neuro: NeuroFedora - 2019-10-10
===

Meeting started by FranciscoD at 15:01:56 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-neuro/2019-10-10/neurofedora.2019-10-10-15.01.log.html
 .

Meeting summary
---
* Agenda for today  (FranciscoD, 15:02:30)
  * Introductions and roll call  (FranciscoD, 15:02:37)
  * tasks from last week  (FranciscoD, 15:02:41)
  * pagure tickets  (FranciscoD, 15:02:44)
  * open bugs  (FranciscoD, 15:02:48)
  * neuroscience query of the week  (FranciscoD, 15:02:59)
  * next meeting, chair  (FranciscoD, 15:03:04)
  * open floor  (FranciscoD, 15:03:06)

* Introductions and roll call  (FranciscoD, 15:03:14)

* Tasks from last week  (FranciscoD, 15:06:52)
  * FranciscoD look at updating ITK to new version: WIP  (FranciscoD,
15:07:12)
  * FranciscoD sponsor mhough to neuro-sig and e-mail devel: WIP (doing
it now)  (FranciscoD, 15:07:30)
  * FranciscoD write blog post on neurofedora updates: Pending
(FranciscoD, 15:07:42)
  * ACTION: FranciscoD write blog post on neurofedora updates
(FranciscoD, 15:07:49)
  * mhough create ticket to document what ITK features we need, and
block other packages that need them: Pending  (FranciscoD, 15:08:23)
  * ACTION: mhough create ticket to document what ITK features we need,
and block other packages that need them  (FranciscoD, 15:08:28)
  * MeWjOr investigate why comp-neuro installer looks like netinstaller:
WIP  (FranciscoD, 15:08:56)

* Pagure tickets  (FranciscoD, 15:09:14)
  * No pagure tickets to discuss this week  (FranciscoD, 15:09:23)

* Open bugs  (FranciscoD, 15:09:29)
  * NeuroFedora bug list: https://tinyurl.com/neurofedora-bugs
(FranciscoD, 15:09:41)
  * A bunch of simple python package updates. Please work on them if you
have some time  (FranciscoD, 15:10:40)

* Open floor  (FranciscoD, 15:11:46)
  * Ticket with releng about kickstart PR:
https://pagure.io/releng/issue/8873  (FranciscoD, 15:11:58)
  * we need to open a PR at
https://pagure.io/fedora-kickstarts/tree/master  (FranciscoD,
15:12:30)
  * we also need to update the pungi configs at
https://pagure.io/pungi-fedora  (FranciscoD, 15:12:47)
  * Plese give feedback on neurofedora brochure that dan1mal made:
https://pagure.io/neuro-sig/NeuroFedora/issue/301  (FranciscoD,
15:13:17)
  * ACTION: FranciscoD send out logs  (FranciscoD, 15:17:54)

Meeting ended at 15:17:57 UTC.

Action Items

* FranciscoD write blog post on neurofedora updates
* mhough create ticket to document what ITK features we need, and block
  other packages that need them
* FranciscoD send out logs

Action Items, by person
---
* FranciscoD
  * FranciscoD write blog post on neurofedora updates
  * FranciscoD send out logs
* **UNASSIGNED**
  * mhough create ticket to document what ITK features we need, and
block other packages that need them

People Present (lines said)
---
* FranciscoD (53)
* zodbot (10)
* alciregi (6)
* MeWjOr (1)
* fm-neuro (1)
* tg-fedneuro1 (1)
* bt0 (0)


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


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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Miro Hrončok]

On 10. 10. 19 16:15, Stephen John Smoogen wrote:

On Wed, 9 Oct 2019 at 19:56, Miro Hrončok  wrote:


On 10. 10. 19 1:44, Stephen John Smoogen wrote:

On Wed, 9 Oct 2019 at 18:46, Miro Hrončok  wrote:





What I miss in the description is:

1. How does this thing actually work? is there an additional repository composed
from the default streams available in Koji only?

2. How are conflicts between packages from the default streams and ursine
package be handled?

3. What is the local experience if the packager is using mock. What if they are
using rpmbuild directly?



So from doing a lot of builds with mock, then the packager should be
ok because mock pulls in modules and you can define in mock which
module streams you want if you needed something differently. For
rpmbuild it is a bit harder because you may have used one module on
your local system and built with another.. However in someways this is
similar to rpm where I might have installed an F31 package on my F30
system to test something and then found out my local rpmbuild didn't
work.

In many ways I found working with mock easier than working with any of
the other system tools when dealing with modules. The file is very
well commented and it was clear what I needed to do to make it work.
So I can't answer anything else.. but I think the local experience for
mock users will be smoother than elsewhere.


What I really care about here is that the mock experience more or less equals
the Koji experience. I.e. I don't want the packagers to (need to) enable modules
in mock when in fact in Koji they are not enabled, but some other magic is
happening.

Having a description about what this change actually does to enable modules in
the buildroot will hopefully steer this discussion more to the specifics of how
to enable the same thing in mock (by default).


So for all my builds.. it works by default in mock already. [I am not
going to say that it works for everyone.. but when I rebuilt a couple
thousand packages earlier with mockchain.. mock did the right thing
without me futzing.] It is in koji that it fails because koji has no
idea about modules and does not pass any of the extra data mock can
use to make decisions for itself. [I believe Koji doesn't want mock to
make decisions because then the build is not record-ably
reproducible.] This is more about making the decisions that mock would
do for itself be something koji would be able to record and force.
[AKA where mock would use dnf to pull in the default module X, koji
instead determines all the packages to put into its own repo that it
points mock on the builder to. This is meant to make sure the build is
auditable and repeatable.]


AFAIK mock has currently modular repos disabled by default for Fedora configs.
So it might work for EPEL8, or it might work if you enable them, or it might 
work because no modules were used at all.


It does not "work by default" for Fedora modules.

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

Fedora rawhide compose report: 20191010.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191009.n.0
NEW: Fedora-Rawhide-20191010.n.0

= SUMMARY =
Added images:2
Dropped images:  3
Added packages:  13
Dropped packages:1
Upgraded packages:   64
Downgraded packages: 0

Size of added packages:  46.87 MiB
Size of dropped packages:771.67 KiB
Size of upgraded packages:   1.49 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -910.82 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Workstation raw-xz aarch64
Path: 
Workstation/aarch64/images/Fedora-Workstation-Rawhide-20191010.n.0.aarch64.raw.xz
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20191010.n.0-sda.raw.xz

= DROPPED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20191009.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20191009.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20191009.n.0.iso

= ADDED PACKAGES =
Package: breezy-3.0.1-1.fc32
Summary: Friendly distributed version control system
RPMs:breezy breezy-doc
Size:31.16 MiB

Package: htslib-1.9-1.fc32
Summary: C library for high-throughput sequencing data formats
RPMs:htslib htslib-devel htslib-tools
Size:4.28 MiB

Package: libretro-beetle-ngp-0-0.1.20190911git6130e40.fc32
Summary: Standalone port of Mednafen NGP to the libretro API, itself a fork of 
Neopop
RPMs:libretro-beetle-ngp
Size:578.00 KiB

Package: libretro-beetle-pce-fast-0-0.2.20190911git7bbbdf1.fc32
Summary: Standalone port of Mednafen PCE Fast to libretro
RPMs:libretro-beetle-pce-fast
Size:2.21 MiB

Package: libretro-beetle-vb-0-0.1.20190912git9066cda.fc32
Summary: Standalone port of Mednafen VB to libretro
RPMs:libretro-beetle-vb
Size:518.97 KiB

Package: libretro-beetle-wswan-0-0.1.20190914git925cb8c.fc32
Summary: Standalone port of Mednafen WonderSwan to libretro, itself a fork of 
Cygne
RPMs:libretro-beetle-wswan
Size:509.08 KiB

Package: libretro-bsnes-mercury-0-0.2.20190817git4a38262.fc32
Summary: Fork of bsnes with various performance improvements
RPMs:libretro-bsnes-mercury
Size:2.76 MiB

Package: libretro-handy-0-0.2.20190801git6b19a4f.fc32
Summary: Atari Lynx emulator Handy for libretro
RPMs:libretro-handy
Size:295.33 KiB

Package: libretro-mgba-0.1.1-0.1.20190912git4865aaa.fc32
Summary: mGBA Game Boy Advance Emulator
RPMs:libretro-mgba
Size:1.46 MiB

Package: libretro-nestopia-0-0.1.20190921git7f48c21.fc32
Summary: Nestopia emulator with libretro interface
RPMs:libretro-nestopia
Size:2.76 MiB

Package: procdump-1.0.1-1.fc32
Summary: Sysinternals process dump utility
RPMs:procdump
Size:303.10 KiB

Package: python-dijitso-2019.1.0-1.fc32
Summary: Distributed just-in-time building of shared libraries
RPMs:python3-dijitso
Size:68.73 KiB

Package: python-pytest-metadata-1.7.0-1.fc32
Summary: Pytest plugin that provides access to test session metadata
RPMs:python3-pytest-metadata
Size:20.95 KiB


= DROPPED PACKAGES =
Package: mingw-qwt5-5.2.3-5.fc31
Summary: MinGW Windows qwt5 library
RPMs:mingw32-qwt5-qt4 mingw64-qwt5-qt4
Size:771.67 KiB


= UPGRADED PACKAGES =
Package:  OpenSceneGraph-3.4.1-13.fc32
Old package:  OpenSceneGraph-3.4.1-12.fc32
Summary:  High performance real-time graphics toolkit
RPMs: OpenSceneGraph OpenSceneGraph-Collada OpenSceneGraph-OpenEXR 
OpenSceneGraph-devel OpenSceneGraph-examples OpenSceneGraph-examples-SDL 
OpenSceneGraph-examples-fltk OpenSceneGraph-examples-gtk 
OpenSceneGraph-examples-qt OpenSceneGraph-gdal OpenSceneGraph-gstreamer 
OpenSceneGraph-libs OpenSceneGraph-qt OpenSceneGraph-qt-devel OpenThreads 
OpenThreads-devel
Size: 65.93 MiB
Size change:  6.30 KiB
Changelog:
  * Wed Oct 09 2019 Richard Shaw  - 3.4.1-13
  - Rebuild with Coin4.


Package:  SIMVoleon-2.0.3-1.fc32
Old package:  SIMVoleon-2.0.1-31.fc31
Summary:  Volume rendering library for Coin
RPMs: SIMVoleon SIMVoleon-devel
Size: 2.14 MiB
Size change:  845.10 KiB
Changelog:
  * Thu Sep 05 2019 Richard Shaw  - 2.0.3-1
  - Update to 2.0.3.
  - Move from autotools to CMake based build.


Package:  SoQt-1.6.0-1.fc32
Old package:  SoQt-1.5.0-27.fc31
Summary:  High-level 3D visualization library
RPMs: SoQt SoQt-devel
Size: 4.62 MiB
Size change:  1.46 MiB
Changelog:
  * Thu Sep 05 2019 Richard Shaw  - 1.6.0-1
  - Update to 1.6.0.
  - Move from autotools to CMake based build.


Package:  asc-2.8.0.2-7.fc32
Old package:  asc-2.8.0.2-6.fc31
Summary:  Advanced Strategic Command
RPMs: asc
Size: 165.18 MiB
Size change:  -1.50 KiB
Changelog:
  * Wed Oct 09 2019 Hans de Goede  - 2.8.0.2-7
  - Add patch from gcc team for compilation with the upcoming gcc-10 release

Re: Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Richard Shaw]

Is there a COPR available for testing?

hedgewars just released 1.0 and I need to see if I have any issues with the
new compiler stack, especially since it looks like I won't need ExcludeArch
anymore.

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

Re: Modularity and the system-upgrade path

[Lukas Ruzicka]

> So despite providing zero feedback here, this was voted at the modularity
> meeting:
>
> * Tagging Module Defaults into non-modular repo  (sgallagh, 15:41:37)
>* AGREED: We disagree with merging default streams into the main repo
>  as non-modular packages. Our approach is to implement a mechanism of
>  following default streams to give people the experience they want.
>  (+4 0 -0)  (asamalik, 16:07:40)
>

Well,
based on this discussion, pushing content in modular defaults is not the
experience that people want. I have been a bit ill
for some time and before I could add my point to the discussion, everything
has been more or less said.
Just for illustration, this is what I wanted to say about it:

   1. Modularity should stay away from my system until I call for it -> now
   it is not the case, because modularity sneaks into users' computer through
   modular defaults that overcome the non-modular packages. Gimp is the first
   such "horse" that jumps into almost everybody's desktop and they are
   modular without even knowing it.
   2. Modularity should provide alternative content, if I need it and when
   I need it. Modules should be installable only through "dnf module" command
   and not through the regular dnf command, so that I explicitely need to
   allow modularity on my system.
   3. The naming conventions of the streams should be *obligatory* for
   every module packager. So, if we decide that we want a "latest" stream,
   then all modules should have a "latest" stream for rolling updates.
   Currently, they all have various names of streams, from which I cannot tell
   anything. If there should be a "slow" path, then again, all modules should
   have a "slow" path.
   4. Non-modular Fedora must be a valid use case and remain an option.
   5. If I decide to go modular, there must be a way to go non-modular
   again, without breaking the system. Or, if modular is the only option, so
   if I go into specific streams, there must be a way to go to defaults
   without breaking the system. With non-modular defaults, this seems easy.
   With modules? I am not sure.
   6. We need to expect that once there are hundreds of modules, people
   will install all possible combinations and they all will need to work. I am
   not sure, we will be able to test something like that.

Seeing the reaction of the Modularity WG ... I do not understand how it is
possible that such important decisions are taken by 4 people without any
Fedora wide discussions like this. And yet, it seems a little bit that even
opinions on this list will not fall on fertile grounds.

I wish the communication improved in the first place. Community means
togetherness.



> should aim for solution 1. if solution 2. is not negotiable by the
> modularity WG.
>

+1




-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0

== Summary ==
Update the Free Pascal Compiler used within Fedora to version 3.2.0,
once it is published, and enable building (previously unsupported)
AArch64 and ppc64le packages using the compiler.

== Owners ==
* Name: [[User:suve|Artur Iwicki]]
* Email: 

* Name: [[User:joost|Joost van der Sluis]]
* Email: 

== Detailed Description ==
The Free Pascal Compiler team plans to release a new release, 3.2.0,
somewhere until the end of this year (2019). This date falls within
the Fedora 32 release schedule, so the new compiler version could be
introduced into F32 once it's released.

== Benefit to Fedora ==
The Free Pascal Compiler will support new architectures, which in turn
will allow programs compiled using FPC to run on more architectures
supported by Fedora.

See also [https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New
Features 3.2] for a list of other new compiler features.

== Scope ==
All packages depending on `fpc` should be rebuilt with the new `fpc`
once it hits F32, or, if there is not enough time for that, just all
packages built after the new `fpc` hits the buildroots.

* Proposal owners:
** Update the `fpc` package to version 3.2.0.
** Cross-compile the compiler for AArch64 and ppc64le (required for
bootstrapping).
** Add AArch64 and ppc64le to the `ExclusiveArch:` tag in the package spec.
** Build the compiler for the new architectures, using the
cross-compiled binaries.
** Build the compiler once again, this time using the self-hosted binary.
** Update the `fpc-rpm-macros` package to accurately reflect the new,
expanded architecture list.

* Other developers: In the first few days or weeks, just voluntary
rebuilds using the new `fpc`. Should there be any build failures, look
at the [https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2]
page to see if the package is affected by any backwards-incompatible
change. If the packaged program/library does not support one of the
newly introduced architectures (AArch64/ppc64le), either resolve the
issue or add an `ExcludeArch:` tag to the spec.

* Release engineering: Mass rebuild requested for F32.

* Policies and guidelines: No changes needed.

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

== Upgrade/compatibility impact ==
No impact

== How To Test ==
Since the main impact of this change is adding support for new
architectures, a mass-rebuild of dependent packages will also act as a
test.

Users wanting to test this change may want to submit a scratch build
against rawhide. If needed, a [b]copr[/b] repo may also be created, so
anyone interested may install the compiler on F31 or F30.

== User Experience ==
FPC-dependent packages will become available on a larger number of
architectures.

== Dependencies ==
Lazarus depends on FPC exact version, so it will need to be rebuilt.

== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the
bugs. I do not expect the compiler to introduce any bugs for x86 /
x86_64 / ARM, so the main question will be whether the new AArch64 and
ppc64le targets work correctly.

* Contingency mechanism: If errors occur only for AArch64 / ppc64le
builds, keep the compiler at the new version (3.2.0), but disable
AArch64 and ppc64le (attempt to enable them again once F32 branches
from Rawhide). If errors are also spotted on x86 / x86_64 / ARM,
revert to the the older version (3.0.4). After choosing either option,
perform a mass rebuild of dependent packages.
* Contingency deadline: Before release
* Blocks release? No
* Blocks product? No

== Documentation ==
Free Pascal wiki pages:
* [https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New Features 3.2]
* [https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2]

== Release Notes ==
Fedora 32 ships with Free Pascal Compiler 3.2.0, see the
[https://wiki.freepascal.org/FPC_New_Features_3.2|FPC New Features
3.2] page for a list of new features and consult the
[https://wiki.freepascal.org/User_Changes_3.2|User Changes 3.2] page
for a list of backwards-incompatible changes.

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

Fedora-31-20191010.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/153 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20191009.n.0):

ID: 466566  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/466566
ID: 466618  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/466618
ID: 466656  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/466656

Old failures (same test failed in Fedora-31-20191009.n.0):

ID: 466508  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/466508
ID: 466547  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/466547
ID: 466570  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/466570

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

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

ID: 466562  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/466562
ID: 466650  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/466650

Old soft failures (same test soft failed in Fedora-31-20191009.n.0):

ID: 466626  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/466626

Passed openQA tests: 145/153 (x86_64)

New passes (same test not passed in Fedora-31-20191009.n.0):

ID: 466557  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/466557

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.17 to 0.06
Previous test data: https://openqa.fedoraproject.org/tests/465787#downloads
Current test data: https://openqa.fedoraproject.org/tests/466502#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.04 to 0.27
Previous test data: https://openqa.fedoraproject.org/tests/465791#downloads
Current test data: https://openqa.fedoraproject.org/tests/466506#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 0.53 to 0.27
Average CPU usage changed from 27.61904762 to 13.74761905
Previous test data: https://openqa.fedoraproject.org/tests/465824#downloads
Current test data: https://openqa.fedoraproject.org/tests/466539#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 896 MiB to 734 MiB
System load changed from 1.36 to 0.47
Previous test data: https://openqa.fedoraproject.org/tests/465839#downloads
Current test data: https://openqa.fedoraproject.org/tests/466554#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
1 services(s) added since previous compose: pcscd.service
System load changed from 0.76 to 1.92
Average CPU usage changed from 24.92857143 to 86.85238095
Previous test data: https://openqa.fedoraproject.org/tests/465841#downloads
Current test data: https://openqa.fedoraproject.org/tests/466556#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.29 to 0.11
Previous test data: https://openqa.fedoraproject.org/tests/465857#downloads
Current test data: https://openqa.fedoraproject.org/tests/466572#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 2.22 to 0.72
Average CPU usage changed from 86.46190476 to 26.71428571
Previous test data: https://openqa.fedoraproject.org/tests/465932#downloads
Current test data: https://openqa.fedoraproject.org/tests/466647#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20191010.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 45 required tests failed, 2 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

Failed openQA tests: 3/143 (x86_64), 1/2 (arm)

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

ID: 466704  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/466704

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

ID: 43  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/43
ID: 466721  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/466721
ID: 466725  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/466725

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

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

ID: 466659  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/466659
ID: 41  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/41
ID: 466672  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/466672
ID: 466674  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/466674
ID: 466682  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/466682
ID: 466687  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/466687
ID: 466690  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/466690
ID: 466691  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/466691
ID: 466727  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/466727
ID: 466728  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/466728
ID: 466729  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/466729
ID: 466730  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/466730
ID: 466731  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/466731
ID: 466732  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/466732
ID: 466733  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/466733
ID: 466734  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/466734
ID: 466735  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/466735
ID: 466736  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/466736
ID: 466737  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/466737
ID: 466740  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/466740
ID: 466741  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/466741
ID: 466743  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/466743
ID: 466744  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/466744
ID: 466746  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/466746
ID: 466747  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/466747
ID: 466748  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/466748
ID: 466749  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/466749
ID: 466750  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/466750
ID: 466751  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/466751
ID: 466752  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/466752
ID: 466753  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/466753
ID: 466754  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/466754
ID: 466755  Test: x86

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Stephen John Smoogen]

On Wed, 9 Oct 2019 at 19:56, Miro Hrončok  wrote:
>
> On 10. 10. 19 1:44, Stephen John Smoogen wrote:
> > On Wed, 9 Oct 2019 at 18:46, Miro Hrončok  wrote:
> >>
> >
> >> What I miss in the description is:
> >>
> >> 1. How does this thing actually work? is there an additional repository 
> >> composed
> >> from the default streams available in Koji only?
> >>
> >> 2. How are conflicts between packages from the default streams and ursine
> >> package be handled?
> >>
> >> 3. What is the local experience if the packager is using mock. What if 
> >> they are
> >> using rpmbuild directly?
> >>
> >
> > So from doing a lot of builds with mock, then the packager should be
> > ok because mock pulls in modules and you can define in mock which
> > module streams you want if you needed something differently. For
> > rpmbuild it is a bit harder because you may have used one module on
> > your local system and built with another.. However in someways this is
> > similar to rpm where I might have installed an F31 package on my F30
> > system to test something and then found out my local rpmbuild didn't
> > work.
> >
> > In many ways I found working with mock easier than working with any of
> > the other system tools when dealing with modules. The file is very
> > well commented and it was clear what I needed to do to make it work.
> > So I can't answer anything else.. but I think the local experience for
> > mock users will be smoother than elsewhere.
>
> What I really care about here is that the mock experience more or less equals
> the Koji experience. I.e. I don't want the packagers to (need to) enable 
> modules
> in mock when in fact in Koji they are not enabled, but some other magic is
> happening.
>
> Having a description about what this change actually does to enable modules in
> the buildroot will hopefully steer this discussion more to the specifics of 
> how
> to enable the same thing in mock (by default).

So for all my builds.. it works by default in mock already. [I am not
going to say that it works for everyone.. but when I rebuilt a couple
thousand packages earlier with mockchain.. mock did the right thing
without me futzing.] It is in koji that it fails because koji has no
idea about modules and does not pass any of the extra data mock can
use to make decisions for itself. [I believe Koji doesn't want mock to
make decisions because then the build is not record-ably
reproducible.] This is more about making the decisions that mock would
do for itself be something koji would be able to record and force.
[AKA where mock would use dnf to pull in the default module X, koji
instead determines all the packages to put into its own repo that it
points mock on the builder to. This is meant to make sure the build is
auditable and repeatable.]




--
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: Orphaned packages to be retired

[Sérgio Basto]

On Thu, 2019-10-10 at 14:06 +, Sergey Avseyev wrote:
> mypaint

is not retired you can take the onwership 

-- 
Sérgio M. B.

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

Re: Orphaned packages to be retired

[Sergey Avseyev]

Is it too late to restore maintenance of mypaint? I've just fixed all
issues, and only about to push last patch, but cannot do it unfortunately
anymore.

--
Sergey Avseyev


El lun., 7 ene. 2019 a las 7:59, Miro Hrončok ()
escribió:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> I plan to retire packages that were already announced 3 times next Monday.
>
> Unorphan/unretire packages at https://pagure.io/releng/issues
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
>  Package  (co)maintainers Status Change
>
> 
> autotrash frafra, orphan, robyduck 1 weeks
> ago
> bluecove  orphan   5 weeks
> ago
> bouml orphan   2 weeks
> ago
> bouml-doc orphan   2 weeks
> ago
> ecryptfs-simple   orphan   3 weeks
> ago
> fasd  orphan   1 weeks
> ago
> golang-github-go-sig, jchaloup, orphan 10
> weeks ago
> AudriusButkevicius-kcp-go
> golang-github-go-sig, orphan   10
> weeks ago
> AudriusButkevicius-pfilter
> golang-github-calmh-luhn  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-ccding-go-stun  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-b go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-fileutil  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-golex go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-internal  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-lex   go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-lexer go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-lldb  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-mathutil  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-qlgo-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-sortutil  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-strutil   go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-cznic-zappy go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-edsrzf-mmap-go  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-klauspost-  go-sig, jchaloup, orphan 10
> weeks ago
> reedsolomon
> golang-github-remyoudompheng- go-sig, jchaloup, orphan 10
> weeks ago
> bigfft
> golang-github-templexxx-cpufeat   go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-templexxx-  go-sig, jchaloup, orphan 10
> weeks ago
> reedsolomon
> golang-github-templexxx-xor   go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-tjfoc-gmsm  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-xtaci-kcp-gogo-sig, jchaloup, orphan 10
> weeks ago
> golang-github-xtaci-smux  go-sig, jchaloup, orphan 10
> weeks ago
> golang-github-zillode-notify  go-sig, orphan   10
> weeks ago
> gossiporphan   12
> weeks ago
> hdapsdorphan   6 weeks
> ago
> hoard orphan   26
> weeks ago
> jlibrtp   orphan   3 weeks
> ago
> jmake orphan   3 weeks
> ago
> libgltf   orphan   4 weeks
> ago
> lzma  cicku, fale, mjakubicek, 64
> weeks ago
>orphan
> maven-downloader  orphan   12
> weeks ago
> maven-jsf-plugin  orphan   12
> weeks ago
> maven-jxr akurtakov, orphan12
> weeks ago
> nuvola-app-8tracksorphan   11
> weeks ago
> nuvola-app-deezer orphan   11
> weeks ago
> nuvola-app-google-play-m

Fedora 31 compose report: 20191010.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20191009.n.0
NEW: Fedora-31-20191010.n.0

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

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

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

= ADDED IMAGES =
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-31-20191010.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-31-20191010.n.0.x86_64.vagrant-libvirt.box

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: koji web interface is very slow

[Robert-André Mauchin]

On Thursday, 10 October 2019 04:42:57 CEST Orion Poplawski wrote:
> Anyone else seeing this?  If so, anyone know the reason and plans to
> fix?  Thanks!

I concur, yesterday it was taking around  a minute to get an answer from the 
server.

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

[Ondřej Lysoněk]

Hi,

Phil Sutter  writes:

> Hi,
>
> On Tue, Oct 08, 2019 at 01:23:01PM +0100, Tomasz Kłoczko wrote:
>> On Tue, 8 Oct 2019 at 12:58,  wrote:
>> 
>> > Notification time stamped 2019-10-08 11:54:56 UTC
>> >
>> > From 26d638db91fa316f706ea947ab076bce216ec8cc Mon Sep 17 00:00:00 2001
>> > From: Phil Sutter 
>> > Date: Oct 08 2019 11:51:27 +
>> > Subject: iproute-5.3.0-2
>> >
>> >
>> > - ifcfg script uses killall, therefore requires psmisc package
>> >
>> 
>> IMO that fix is fundamentally wrong.
>
> Thanks for the heads-up. Maybe Ondřej might tell us the reason for the
> new dependency (it was his pull-request I merged).

I just happened to run ifcfg on a system that did not have killall
installed and noticed an error message about killall missing. I don't
really have a use case for ifcfg; I just noticed a bug and fixed it.

ifcfg uses killall, so the iproute package must Require it. The fix is
obviously correct, not fundamentally wrong. Tomasz appears to be arguing
that systemctl should be used instead of killall, which is of course a
completely separate issue. Feel free to fix that upstream, Tomasz.

Regards,
Ondra

>
>> Instead using killall it should be used systemd to reload service
>> ("systenctrl reload rdisc").
>
> I guess users preferring to use ifcfg for interface configuration over
> NetworkManager also don't care about rdisc systemd unit. 
>
>> Why? In case of using LXC or other containerisation ifcfg which will be
>> using killal and used from global zone/namespace will cause to reload
>> all rdisc (those running in containers as well).
>
> Is this a theoretical point or to you know of any real use-case where
> ifcfg is used? If so, what's the reason for not using nmcli?
>
>> Next is that rdisc is part of the iputils which is not listed in list of
>> iproure dependencies (I'm not sure is it correct to add that dependency but
>> seems it is legit).
>> 
>> Other thing is that ifcfg script is bash dependent because
>> 
>> $ grep -w local /usr/sbin/ifcfg
>>   local sbase fwd
>>   local class;
>
> So sounds like even more dependencies are required to be formally
> correct. Maybe this even justifies putting ifcfg (and probably other
> shell scripts as well) into a dedicated sub-package to not impose too
> many dependencies onto the core iproute package.
>
>> Those two lines can be removed without harming anything to make that script
>> full POSIX sh compliant (and still working correctly with bash as
>> /usr/bin/sh).
>
> Feel free to submit a patch upstream. Sadly these scripts are not very
> well maintained, probably just because hardly anyone uses them.
>
>> BTW. Looks like no one in Fedora have been looking on all cases like above
>> to have proper separation between zones/container/namespaces.
>
> Not just in Fedora, it seems. ;)
>
> Cheers, Phil
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Intent to unretire libresample package, needs re-review

[Jared K. Smith]

On Wed, Oct 9, 2019 at 8:46 AM Jared K. Smith 
wrote:

> I will open a Rel-Eng ticket for unretirement once the package has been
> re-reviewed.
>
>
The package has been re-reviewed and re-approved, and I have opened the
rel-eng ticket at https://pagure.io/releng/issue/8891.

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

[Miro Hrončok]

On 07. 10. 19 11:39, Miro Hrončok wrote:

On 06. 10. 19 23:52, Kevin Fenzi wrote:

On Sun, Oct 06, 2019 at 09:00:18PM +0200, Miro Hrončok wrote:


It says: package python3-3.7.4-5.fc31.armv7hl is excluded
I don't know why would it be. How do i debug why it gets excluded?
Only python36 and python38 was excluded, not python37.


...and I dug into this and found that we were composing the f31 images
with the master/rawhide/f32 comps branch. ;( So that branch did have a
exclude on python37, which explains everything.

https://pagure.io/pungi-fedora/pull-request/770

fixes this. :(

I'm glad we caught it now, but sad that it's been happening since
branching. ;(


Oh. Thanks for the fix. I hope nothing other will break now.
Are the branches diverged in some other serious ways?



Anyway, https://koji.fedoraproject.org/koji/packageinfo?packageID=23843 LGTM.

Could you please confirm that everything is alright with the Python Classroom 
Lab (build-wise)?


--
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: removing Xen from Fedora release criteria

[Javier Martinez Canillas]

On Tue, Oct 8, 2019 at 3:53 AM Chris Murphy  wrote:
>
> Release criterion
> https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Xen_DomU
>
> Bug since Fedora 30 also affects Fedora 31 and has been proposed as a
> Fedora 31 blocker bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1703700
>

This bug has been fixed now  and the Xen folks have tested that it
works for them. I've also backported the fix for F30.

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

[Florian Weimer]

* Florian Weimer:

> * Jerry James:
>
>> On Wed, Oct 9, 2019 at 8:25 PM Jerry James  wrote:
>>> The previous build managed to grab the last build of glibc32 for
>>> s390x, it seems.  I'm going to assume that this means that s390x
>>> should be removed from the multilib_64_arches variable in the gcc
>>> spec, just so I can keep these builds going.  (There are at least 3
>>> days of builds still to go.)  If that is wrong, please let me know
>>> ASAP so I can make it right before anything lands in Rawhide.
>>
>> Sadly, simply removing s390x from multilib_64_arches was insufficient.
>>
>> In file included from /usr/include/features.h:489,
>>  from /usr/include/bits/libc-header-start.h:33,
>>  from /usr/include/stdio.h:27,
>>  from ../../../../libgcc/../gcc/tsystem.h:87,
>>  from ../../../../libgcc/libgcov.h:42,
>>  from ../../../../libgcc/libgcov-merge.c:26:
>> /usr/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-32.h: No such
>> file or directory
>> 8 | # include 
>>   |   ^~~~
>> compilation terminated.
>> make[5]: *** [Makefile:920: _gcov_merge_add.o] Error 1
>>
>>
>> So does that mean that glibc has to be rebuilt first, with s390 and
>> s390x removed from biarcharches?
>
> Sorry, I wasn't aware that you were trying to rebuild gcc this week.  I
> spoke to Jakub about the glibc32 change, and he had no objections.
>
> It's not clear how you are handling the transition.  Why do you need to
> change GCC build requirements?  Did anyone request this?
>
> I would have expected a run-time-only compat-mpfr library with the old
> soname, so that GCC keeps working until it is rebuilt.

Anyway, I tweaked gcc.spec some more, and the build has no processed
past the critical point.  We'll see if the paths are correct in the
end. 8-/

We might still do further changes on s390x, but this can hopefully wait
until after the mpfr transition.

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: koji web interface is very slow

[Peter Robinson]

> > Anyone else seeing this?  If so, anyone know the reason and plans to fix?
> > Thanks!
>
> You'll have to be more specific than this, there has been some work put 
> recently
> on its database which led to some improvements so if you still find koji slow,
> you'll have to provide some more information.

There was an outage, not sure if it was maintenance or something else,
and ever since the web interface has been glacial. Things like running
builds take ages to load or refresh. Over all I think the cli is
actually slow too but that's much harder to get objective feedback on
that.

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

[Pierre-Yves Chibon]

On Wed, Oct 09, 2019 at 08:42:57PM -0600, Orion Poplawski wrote:
> Anyone else seeing this?  If so, anyone know the reason and plans to fix?
> Thanks!

You'll have to be more specific than this, there has been some work put recently
on its database which led to some improvements so if you still find koji slow,
you'll have to provide some more information.


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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Pierre-Yves Chibon]

On Thu, Oct 10, 2019 at 12:46:00AM +0200, Miro Hrončok wrote:
> On 09. 10. 19 22:46, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
> > 
> > Enable module default streams in the buildroot repository for modular
> > and non-modular RPMs.
> > 
> > == Summary ==
> > This Change (colloquially referred to as "Ursa Prime") enables the
> > Koji build-system to include the RPM artifacts provided by module
> > default streams in the buildroot when building non-modular (or
> > "traditional") RPMs.
> > 
> > == Owner ==
> > * Name: [[User:Sgallagh| Stephen Gallagher]]
> > * Email: sgall...@redhat.com
> > * Responsible WG: Modularity WG
> > 
> > == Detailed Description ==
> > As a major part of the Modularity design, we have a concept of default
> > module streams. These streams are built as modules, but the RPM
> > artifacts they deliver are intended to be used just like non-modular
> > RPMS. The aspirational goal is that a user of the system who never
> > executes a module-specific command (such as `dnf module install
> > nodejs:8`) should experience no meaningful changes in behavior from
> > how they would interact with a completely non-modular system. In
> > practice, this may mean that the informational output of package
> > managers may indicate that modules are being enabled and used, but a
> > user that does not have a specific reason to interact with the
> > selection of a module stream should have that managed on their behalf.
> 
> If this is the goal of default modular streams, wouldn't it be in fact much
> easier to keep the default versions as urisne packages?

This question has been asked a few times now and I think it's a good one and
deserves to be answered.


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

Re: FreeCAD required updates (PySide2 & Coin4)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 09, 2019 at 08:50:44PM -0500, Richard Shaw wrote:
> On Tue, Oct 8, 2019 at 3:54 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > On Tue, Oct 08, 2019 at 08:32:47AM +0200, Ralf Corsepius wrote:
> > > >
> > > >Those are fairly substantial changes, but time is of essence here.
> > > I could not disagree more. Quality and stability is of more essence,
> > here.
> >
> > Richard is working on updating Coin to the latest version along with the
> > dependent packages. The PRs were for rawhide. I don't think there's much
> > choice: we need to update to latest versions of packages and rawhide is
> > the appropriate place to do it, and we are early in the release cycle.
> >
> 
> So the PRs were for Rawhide, but the bug I'm trying to fix exists on all
> supported Fedora releases. I wasn't planning on updating F29 at this point
> but F30 does have a lot of life left.
> 
> I don't like the idea of major upgrades within a release but the list of
> dependencies (as noted by the list of PRs) is fairly small and through my
> COPR I have found no *build* issues with the update.
> 
> I'm open to suggestion here but I don't like leaving broken software in
> Fedora and basically having to tell the user, "It's fixed in Rawhide so
> you'll get it eventually..."
> 
> Thoughts?

Let's get everything built and tested in rawhide first. Based
on how this turns out, an update in F30 and F31 might be appropriate
(with a suitably long testing period, etc). I agree that if the version
in stable Fedora is sufficiently broken, it's better to release an
working update with major version changes than to do nothing.

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

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

[James Antill]

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

 Local time information (via. uitime):

= Day: Thursday ==
2019-10-10 09:00 PDT  US/Pacific
2019-10-10 12:00 EDT  --> US/Eastern <--
2019-10-10 16:00 UTC  UTC   
2019-10-10 17:00 BST  Europe/London 
2019-10-10 18:00 CEST Europe/Berlin 
2019-10-10 18:00 CEST Europe/Paris  
2019-10-10 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2019-10-11 00:00 HKT  Asia/Hong_Kong
2019-10-11 00:00 +08  Asia/Singapore
2019-10-11 01:00 JST  Asia/Tokyo
2019-10-11 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 #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

= Pull Requests =

#topic #814 Add SELinux Independent Policy Guidelines 
https://pagure.io/packaging-committee/pull-request/814

= 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