[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following builds have been pushed to Fedora EPEL 8 updates-testing

indent-2.2.12-4.el8
pugixml-1.9-1.el8
python-ratelimitingfilter-1.1-3.el8
robin-map-0.6.1-2.el8
will-crash-0.12-3.el8

Details about builds:



 indent-2.2.12-4.el8 (FEDORA-EPEL-2019-891ee8a7be)
 A GNU program for formatting C code

Update Information:

This brings indent tool, a formatter for C code.




 pugixml-1.9-1.el8 (FEDORA-EPEL-2019-70dbc966dd)
 A light-weight C++ XML processing library

Update Information:

Initial builds for epel 8.




 python-ratelimitingfilter-1.1-3.el8 (FEDORA-EPEL-2019-d230ef1f86)
 A rate limiting filter for the Python logging system

Update Information:

- Build for epel8 - Dropped python2 from epel8 - Upstream version 1.1




 robin-map-0.6.1-2.el8 (FEDORA-EPEL-2019-70dbc966dd)
 C++ implementation of a fast hash map and hash set using robin hood hashing

Update Information:

Initial builds for epel 8.




 will-crash-0.12-3.el8 (FEDORA-EPEL-2019-c90d8a0b9c)
 Set of crashing executables written in various languages

Update Information:

- Build for epel8 - Update to 0.12


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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-08-13 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



Source: https://apps.fedoraproject.org/calendar/meeting/9480/

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

[389-devel] 389 DS nightly 2019-08-13 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/13/report-389-ds-base-1.4.1.6-20190812git21ba842.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Dridi Boukelmoune]

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

python-{act,block,nw,seq}diag packages build fine without pep8, I
dropped the build dependency. I'm pretty sure it used to not be the
case though.

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

Re: Better interactivity in low-memory situations

[Chris Murphy]

On Mon, Aug 12, 2019 at 6:31 PM David Airlie  wrote:
>
> On Sun, Aug 11, 2019 at 2:57 AM Georg Sauthoff  wrote:
> >
> > On Fri, Aug 09, 2019 at 03:50:43PM -0600, Chris Murphy wrote:
> > [..]
> > > Problem and thesis statement:
> > > Certain workloads, such as building webkitGTK from source, results in
> > > heavy swap usage eventually leading to the system becoming totally
> > > unresponsive. Look into switching from disk based swap, to swap on a
> > > ZRAM device.
> > >
> > > Summary of findings (restated, but basically the same as found at [2]):
> > > Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
> > > Samsung SSD 840 EVO, Fedora Rawhide Workstation.
> > > Test case, build WebKitGTK from source.
> > [..]
> >
> > To avoid such issues I disable swap on my machines. I really don't see
> > the point of having a swap partition if you have 16 or 32 GiB RAM. Even
> > with 8 GiB I disable swap.
>
> Disabling swap doesn't avoid the issues, it can in fact make them worse.
>
> If you have apps allocate memory they don't always OOM before the
> kernel tries to evict text pages, but since SSDs are fast it then
> tries to pull back in those text pages before realising (that is what
> most of the latest rounds of articles has been about). Something like
> firefox runs with no swap, starts to need more memory than the system
> has, parts of firefox executable get paged out, but then are needed
> for firefox to use the RAM, and round in circles it goes.
>
> Having swap is still in this day and age better for your system that
> not having it.

I agree that it's better to have swap for incidental swap purposes,
rather than random things just getting abruptly hit with oom. I say
random, because I see the oom_score_adj is the same for every process
other than systemd-udev, auditd, sshd, and dbus. Plausibly the shell
could get oom killed without warning, taking out the entire user
session, all apps, and all the build processes.

I just discovered in the log from yesterday, that iotop was subject to
oom killer, rather than one of the large cc1plus processes, which is
what I'd previously consistently witnessed. So iotop and cc1plus must
be in the ballpark oom score wise and oom killer just so happens to
pick one or the other. iotop going away relieved just enough memory
that nothing else was subject to oom killer, and yet processes were
clearly resource starved nevertheless: the GUI was frozen, but then
also other processes had already been dying due to timeouts, for
example:

Aug 11 18:26:57 fmac.local systemd[1]: sssd-kcm.service: Control
process exited, code=killed, status=15/TERM
Aug 11 18:26:57 fmac.local systemd[1]: sssd-kcm.service: Failed with
result 'timeout'.

Aug 11 18:27:00 fmac.local systemd[1]: systemd-journald.service: State
'stop-sigterm' timed out. Killing.
Aug 11 18:27:00 fmac.local systemd[1]: systemd-journald.service:
Killing process 31010 (systemd-journal) with signal SIGKILL.
Aug 11 18:27:00 fmac.local systemd[1]: systemd-journald.service: Main
process exited, code=killed, status=9/KILL

This is like a train wreck where there are all sorts of interesting
sub failures happening. At one point I think, well we need better oom
scores so the truly lowest important process is killed off. But upon
big picture scrutiny, the system is failing before oom killer has been
triggered. Processes are dying with timeouts. The GUI including the
mouse pointer is frozen, even when swap is half full. Practically
speaking, it's a goner the moment the mouse pointer froze the very
first time. I might tolerate some stuttering here and there, but
minutes of frozen state? Nah - not interested in seeing if this is
another 5 minutes of choke, or 5 days.

And that's the bad side of swap is when the system is more than
incidentally using it, and is depending on it. And apparently nothing
is on a deadline timer if things can just start timing out on their
own, including the system journal! That was a surprise to see. If it
was that hung up, maybe I can't trust the journal entry times or
order, maybe important entries were lost.


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

Re: Better interactivity in low-memory situations

[David Airlie]

On Sun, Aug 11, 2019 at 2:57 AM Georg Sauthoff  wrote:
>
> On Fri, Aug 09, 2019 at 03:50:43PM -0600, Chris Murphy wrote:
> [..]
> > Problem and thesis statement:
> > Certain workloads, such as building webkitGTK from source, results in
> > heavy swap usage eventually leading to the system becoming totally
> > unresponsive. Look into switching from disk based swap, to swap on a
> > ZRAM device.
> >
> > Summary of findings (restated, but basically the same as found at [2]):
> > Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
> > Samsung SSD 840 EVO, Fedora Rawhide Workstation.
> > Test case, build WebKitGTK from source.
> [..]
>
> To avoid such issues I disable swap on my machines. I really don't see
> the point of having a swap partition if you have 16 or 32 GiB RAM. Even
> with 8 GiB I disable swap.

Disabling swap doesn't avoid the issues, it can in fact make them worse.

If you have apps allocate memory they don't always OOM before the
kernel tries to evict text pages, but since SSDs are fast it then
tries to pull back in those text pages before realising (that is what
most of the latest rounds of articles has been about). Something like
firefox runs with no swap, starts to need more memory than the system
has, parts of firefox executable get paged out, but then are needed
for firefox to use the RAM, and round in circles it goes.

Having swap is still in this day and age better for your system that
not having it.

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

Orphaned some (mostly Python) packages

[Miro Hrončok]

# python-behave
Leaf.
Doesn't build yet with Python 3.8, but a patch exists:
https://bugzilla.redhat.com/show_bug.cgi?id=1706085


# python-cligj
python-rasterio and python-fiona depend on that.


# python-coverage_pth
python-pytest-testmon depends on that.


# python-jeepney
python-SecretStorage -> python-keyring depends on that.


# python-pathtools
Needed by:
  python-sphinx-autobuild
  python-watchdog
  python-Lektor
  python-pytest-watch


# python-pep8
BuildRequired by many, but they have been warned:
https://bugzilla.redhat.com/show_bug.cgi?id=1667200
Switch to python-pycodestyle or better stop linting in %check.


# rpmlint-scl-config
Leaf. Packaged long time ago and never touched since.


--
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: Better interactivity in low-memory situations

[Chris Murphy]

On Mon, Aug 12, 2019 at 11:07 AM Benjamin Kircher
 wrote:
>
> (… I definitely need to play around with Silverblue to learn what they are 
> doing.)

I'm pretty sure Silverblue will be rebased on Fedora CoreOS which
recently released a preview. I'm not sure what the time frame for that
is, but maybe that work will be concurrent with work on a release
version of Fedora CoreOS. The central means of installing/uninstalling
and running applications on a future immutable system is flatpak. But
you don't need to commit a system to Silverblue to use and test
flatpak applications on Fedora 29/30 Workstation. Containerization is
an option not a requirement of flatpaks, as is running it as a systemd
--user instance.

Since layering is permitted with rpm-ostree based systems, using
overlayfs, there still needs to be some way for the per-user service
manager to enforce limits on unprivileged programs. The use of the
word "limit" might be misleading. Perhaps instead it should be on
defining and preserving the user interface responsiveness, whether
that's CLI or GUI, so that control isn't lost. i.e. the unprivileged
program gets the leftover resources, it's not a peer with the user
interface. Promoting the active user interfaces relative to the
unprivileged task would provide a way of effectively containing the
unprivileged tasks, by one always being able to preempt the other.

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

[EPEL-devel] Re: how to use epel8-playground?

[Stephen John Smoogen]

On Mon, 12 Aug 2019 at 17:47, Troy Dawson  wrote:

> Looks like you need at least fedpkg-1.37-3.el7 for it to work with the
> playground stuff, so you should be good.
> When I did the branches for KDE (about 350 of them) there were 6 that
> didn't properly branch to epel8-playground.
> They *said* they were branched, but they weren't.
> I was able to push and create a branch though, because everything else
> was setup.
>
>   fedpkg switch-branch f30
>   git checkout -b epel8-playground
>   fedpkg push
>
> I did f30 instead of master because that's the version we wanted for
> KDE.  You can do that from master if you want.
>
>
Please be aware that when you do this you create an email for every commit
ever done as they are each resent to the various scm-commit lists. This
caused several hundred thousand emails when the KDE was done this way.


> Troy
>
> On Mon, Aug 12, 2019 at 2:17 PM Dave Dykstra  wrote:
> >
> > Hi Kevin,
> >
> > I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
> > updated it from 1.37-2 on August 6 an hour and a half before I started
> > this thread.  If I recall correctly I saw an instruction somewhere that
> > said to update it, and I did that before my initial attempt.
> >
> > Dave
> >
> > On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> > > On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > > > Stephen,
> > > >
> > > > The package is singularity.
> > > >
> > > > The term "branch" in this context is not very clear to me.  All I
> know
> > > > is that there's no git branch on
> pkgs.fedoraproject.org/rpms/singularity;
> > > > I don't know about other systems.
> > >
> > > What version of fedpkg do you have there?
> > >
> > > It might be the version is too old to understand the epel8-playground
> > > request?
> > >
> > > kevin
> > >
> > >
> >
> >
> >
> >
> > > ___
> > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > > To unsubscribe send an email to
> epel-devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>


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

[EPEL-devel] Re: how to use epel8-playground?

[Troy Dawson]

Looks like you need at least fedpkg-1.37-3.el7 for it to work with the
playground stuff, so you should be good.
When I did the branches for KDE (about 350 of them) there were 6 that
didn't properly branch to epel8-playground.
They *said* they were branched, but they weren't.
I was able to push and create a branch though, because everything else
was setup.

  fedpkg switch-branch f30
  git checkout -b epel8-playground
  fedpkg push

I did f30 instead of master because that's the version we wanted for
KDE.  You can do that from master if you want.

Troy

On Mon, Aug 12, 2019 at 2:17 PM Dave Dykstra  wrote:
>
> Hi Kevin,
>
> I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
> updated it from 1.37-2 on August 6 an hour and a half before I started
> this thread.  If I recall correctly I saw an instruction somewhere that
> said to update it, and I did that before my initial attempt.
>
> Dave
>
> On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> > On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > > Stephen,
> > >
> > > The package is singularity.
> > >
> > > The term "branch" in this context is not very clear to me.  All I know
> > > is that there's no git branch on pkgs.fedoraproject.org/rpms/singularity;
> > > I don't know about other systems.
> >
> > What version of fedpkg do you have there?
> >
> > It might be the version is too old to understand the epel8-playground
> > request?
> >
> > kevin
> >
> >
>
>
>
>
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: how to use epel8-playground?

[Dave Dykstra]

Hi Kevin,

I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
updated it from 1.37-2 on August 6 an hour and a half before I started
this thread.  If I recall correctly I saw an instruction somewhere that
said to update it, and I did that before my initial attempt.

Dave

On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > Stephen,
> > 
> > The package is singularity.
> > 
> > The term "branch" in this context is not very clear to me.  All I know
> > is that there's no git branch on pkgs.fedoraproject.org/rpms/singularity;
> > I don't know about other systems.
> 
> What version of fedpkg do you have there?
> 
> It might be the version is too old to understand the epel8-playground
> request?
> 
> kevin
> 
> 




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

[EPEL-devel] RHEL-7.7 problems

[Stephen John Smoogen]

This release has had a multitude of problems this release.

* The python3 problems were caused because there were complaints that the
python36 was conflicting with the RHEL-7 python3 causing build problems.
The maintainers removed python36 to try and fix this and broke centos
consumers who relied on EPEL.

* The real problem turned out to be definitions which RHEL over-rode EPEL
build srpm definitions. This needed further package updates which are in
the buildroot, but while debugging this we found at least two more
buildroot problems.

* One of the items is that RHEL did not update the rhel-alt platform which
contained aarch64 or power9 with the EL7.7 release. This means that these
are frozen at 7.6 it would seem. I am not sure what to do about this at the
moment.

* The other problem is that reposync broke once again with the Red Hat cdn.
Running the script by hand would show that it thought it had downloaded
everything but it was clear only parts of the 7.7 had been downloaded for
various architectures. Only by starting over seems to have gotten things to
unstick.

I expect we will have several more issues/problems to deal with.

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

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

[Miro Hrončok]

On 12. 08. 19 20:37, Petr Stodulka wrote:

Can you explain better what do you mean by that? I am little lost
here.


Sure. The idea was:

1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the switch to 
rawhide (Fedora 32)


2) See what happens, collect feedback.

3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide whether 
this is worth pushing to F31 (probably not)


4) Soon before F32 mass Python 2 removal flag day (scheduled for mid November 
[2]), decide whether to revert and request and exception or not


[1] https://fedoraproject.org/wiki/Releases/31/Schedule
[2] https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description

--
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: What other external trackers would you like added to Bugzilla?

[Florian Weimer]

* Ankur Sinha:

> The new "external trackers" bits in Bugzilla leaves out quite a few
> commonly used ones. I filed a ticket[1] and was asked to contact the
> admins. Before I do so, I thought I'd post here so we can make a list of
> trackers we want to get added. Here is what I have so far:
>
> - src.fp.o so that one can link to PRs: https://src.fedoraproject.org/
> - Opensuse: https://bugzilla.opensuse.org/
> - ArchLinux: https://bugs.archlinux.org/
> - Sourceforge: https://sourceforge.net/p//bugs/

Chromium.  URLs are of this form:

  

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: What other external trackers would you like added to Bugzilla?

[Dan Book]

On Mon, Aug 12, 2019 at 3:11 PM Dan Book  wrote:

> On Mon, Aug 12, 2019 at 2:36 PM Petr Pisar  wrote:
>
>> - Perl: https://rt.perl.org/Public/
>
>
> I would not expend effort on this, as it is planned to be moved the github
> in the near future.
>
> https://www.nntp.perl.org/group/perl.perl5.porters/2019/06/msg255335.html
>

However, CPAN modules not from the Perl core have bugtrackers on
https://rt.cpan.org which is an unrelated instance that will not be moving
(they may also have trackers on github). If it matters.

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

Re: What other external trackers would you like added to Bugzilla?

[Dan Book]

On Mon, Aug 12, 2019 at 2:36 PM Petr Pisar  wrote:

> - Perl: https://rt.perl.org/Public/


I would not expend effort on this, as it is planned to be moved the github
in the near future.

https://www.nntp.perl.org/group/perl.perl5.porters/2019/06/msg255335.html

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

Re: What other external trackers would you like added to Bugzilla?

[Miro Hrončok]

On 12. 08. 19 20:24, Ankur Sinha wrote:

Hi,

The new "external trackers" bits in Bugzilla leaves out quite a few
commonly used ones. I filed a ticket[1] and was asked to contact the
admins. Before I do so, I thought I'd post here so we can make a list of
trackers we want to get added. Here is what I have so far:


bitbucket.org


--
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: Better interactivity in low-memory situations

[Lennart Poettering]

On Mo, 12.08.19 19:06, Benjamin Kircher (benjamin.kirc...@gmail.com) wrote:

>
>
> > On 12. Aug 2019, at 18:16, Lennart Poettering  wrote:
> >
> > On Mo, 12.08.19 09:40, Chris Murphy (li...@colorremedies.com) wrote:
> >
> >> How to do this automatically? Could there be a mechanism for the
> >> system and the requesting application to negotiate resources?
> >
> > Ideally, GNOME would run all its apps as systemd --user services. We
> > could then set DefaultMemoryHigh= globally for the systemd --user
> > instance to some percentage value (which is taken relative to the
> > physical RAM size). This would then mean every user app individually
> > could use — let's say — 75% of the physical RAM size and when it wants
> > more it would be penalized during reclaim compared to apps using less.
> >
> > If GNOME would run all apps as user services we could do various other
> > nice things too. For example, it could dynamically assign the fg app
> > more CPU/IO weight than the bg apps, if the system is starved of
> > both.
>
> I really like the ideas. Why isn’t this done this way anyway?

Well, let's just say certain popular container managers blocked
switching to cgroupsv2, and only in cgroupsv2 delegating cgroup
subtrees to unprivileged users is safe. Hence doing this kind of
resource management wasn't really doable without ugly hacks.

But as it appears cgroupsv2 has a chance of becoming a reality on
Fedora now, so this opens a lot of doors.

> I don’t have a GNOME desktop at hand right now to investigate how
> GNOME starts applications and so on but aren’t new processes started
> by the user — GNOME or not — always children of the user.slice? Is
> there a difference if I start a GNOME application or a normal
> process from my shell?

Well, "user.slice" is a concept of the *system* service manager, but
desktop apps are if anything a concept of the *per-user* service
manager.

> And for the beginning, wouldn’t it be enough to differentiate
> between user slices and system slice and set DefaultMemoryHigh= in a
> way to make sure there is always some headroom left for the system?

From the system service manager's PoV all user apps together make up
the user's 'user@.service' instance, it doesn#t look below.

i.e. cgroups is hierarchial, and various components can manage their
own subtrees. PID 1 manages the top of the tree, and the per-user
service manager a subtree of it that is below it and arranges per-user
apps below that. But from PID1's PoV each of those per-user subtrees
is opaque and it won't do resource management beneath that
boundary. It's the job of the per-user service manager to do resource
management there.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: License correction in teckit-2.5.9-2.fc31

[Igor Gnatenko]

This is horrifying :) Curious how much time it took to figure that out..

On Mon, Aug 12, 2019, 14:21 Petr Pisar  wrote:

> After unretiring teckit I reviewed the sources and corrected a license
> tag from
>
> LGPLv2+ or CPL
>
> to
>
> (LGPLv2+ or CPL) and (LGPLv2+ or GPLv2+ or MPLv2.0 or MPLv1.1)
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Igor Gnatenko]

What is the point of this? I am probably missing something obvious..

On Mon, Aug 12, 2019, 18:46 Brian C. Lane  wrote:

> On Sun, Aug 11, 2019 at 11:39:34AM +0200, Miro Hrončok wrote:
> > Hey, I have noticed that anaconda-core has a runtime dependency on
> python3-coverage.
> >
> > Is it some weird error, or does anaconda actually need a test coverage
> > measuring tool at runtime?
>
> Yes. If you pass inst.debug=1 it will generate a coverage report.
>
> https://github.com/rhinstaller/anaconda/blob/master/anaconda.py#L35
>
> --
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning cloud-init, python-boto

[Igor Gnatenko]

python-boto is dead and deprecated. Why do you want to take it?

On Sun, Aug 11, 2019, 03:43 Gwyn Ciesla via devel <
devel@lists.fedoraproject.org> wrote:

> I'll take python-goto. FAS: limb.
>
>
> Sent from ProtonMail mobile
>
>
>
>  Original Message 
> On Aug 10, 2019, 8:06 PM, Garrett Holmstrom < gho...@fedoraproject.org>
> wrote:
>
>
> Hi,
>
> My time to work on Fedora cloud-related things has diminished in
> recent months, so I have not been able to give the cloud-init and
> python-boto packages the care they deserve. They are free to a good
> home.
>
> Thanks,
> --
> Garrett Holmstrom
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Petr Stodulka]

On 12. 08. 19 16:33, Miro Hrončok wrote:

On 12. 08. 19 16:19, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Aug 06, 2019 at 09:35:50PM +0200, Petr Stodulka wrote:

Hi guys,
as discussion was started week ago, Python2 is dying. As that, some
dependencies of mercurial will be orphaned soon (or they are already)
and mercurial as it is has to move in weeks on Python3. As I wrote
in [0], I already started some testing and investigation.

Currently it seems that with ugly hacky fix, we are able to run
somi-working mercurial with Python3. I did just simple testing
that worked for me and in the latest copr-build (below), it seems
that hgk extension is workin as well. But many of you extensions
will be probably broken. So, I guess the most probably mercurial
will be broken for the others who use it.

So it's question, should I rebase it in rawhide and setup for Python3
already even when it is so broken, or should I wait several weeks yet
for additional fixes?


I think it's reasonable to ship in rawhide, if the basic clone
operations work. This will satisfy 99% of use cases, i.e. cloning
of repos from the web without any further interaction with the VCS.
I don't have any data to back this up, but since Mercurial has lost
a lot of it's erstwhile popularity, based on how things go with
other python2-only projects, chances are that most extensions will not
be updated in time for F31. And it's better to have somewhat functional
clone operation than nothing.


I suggest to switch after the branching in F32 only and than (re)consider doing 
a backport before the F31 beta freeze.



Can you explain better what do you mean by that? I am little lost
here. Anyway, pointing out that Neal found python3 version for
him unusable and do not want to put it into rawhide.

There is suggestion about mercurial for python3 in subpackages.
I will prepare this week PoC for that, to provide at least some
way for users to have still working mercurial and provide the
benefit for developers to prepare for Python3.

I will send patch before I will do any changes in rawhide.

--
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Software Engineer
Red Hat Czech s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What other external trackers would you like added to Bugzilla?

[Petr Pisar]

On 2019-08-12, Ankur Sinha  wrote:
> The new "external trackers" bits in Bugzilla leaves out quite a few
> commonly used ones. I filed a ticket[1] and was asked to contact the
> admins. Before I do so, I thought I'd post here so we can make a list of
> trackers we want to get added. Here is what I have so far:
>
> - src.fp.o so that one can link to PRs: https://src.fedoraproject.org/
> - Opensuse: https://bugzilla.opensuse.org/
> - ArchLinux: https://bugs.archlinux.org/
> - Sourceforge: https://sourceforge.net/p//bugs/
>
>
> Please add to the list, and I'll contact the admins by the end of the
> week (on Friday maybe).
>
- Exim: https://bugs.exim.org/
- Perl: https://rt.perl.org/Public/

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

Re: What other external trackers would you like added to Bugzilla?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Aug 12, 2019 at 07:24:49PM +0100, Ankur Sinha wrote:
> Hi,
> 
> The new "external trackers" bits in Bugzilla leaves out quite a few
> commonly used ones. I filed a ticket[1] and was asked to contact the
> admins. Before I do so, I thought I'd post here so we can make a list of
> trackers we want to get added. Here is what I have so far:
> 
> - src.fp.o so that one can link to PRs: https://src.fedoraproject.org/
> - Opensuse: https://bugzilla.opensuse.org/
> - ArchLinux: https://bugs.archlinux.org/
> - Sourceforge: https://sourceforge.net/p//bugs/

Maybe also pagure PRs? I tried to link to one today and it was rejected.

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

What other external trackers would you like added to Bugzilla?

[Ankur Sinha]

Hi,

The new "external trackers" bits in Bugzilla leaves out quite a few
commonly used ones. I filed a ticket[1] and was asked to contact the
admins. Before I do so, I thought I'd post here so we can make a list of
trackers we want to get added. Here is what I have so far:

- src.fp.o so that one can link to PRs: https://src.fedoraproject.org/
- Opensuse: https://bugzilla.opensuse.org/
- ArchLinux: https://bugs.archlinux.org/
- Sourceforge: https://sourceforge.net/p//bugs/


Please add to the list, and I'll contact the admins by the end of the
week (on Friday maybe).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1736849

-- 
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: Orphaning cloud-init, python-boto

[Dusty Mabe]

On 8/10/19 9:06 PM, Garrett Holmstrom wrote:
> Hi,
> 
> My time to work on Fedora cloud-related things has diminished in
> recent months, so I have not been able to give the cloud-init and
> python-boto packages the care they deserve.  They are free to a good
> home.
> 

Maybe larks (cc) would be interested.

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

Re: Better interactivity in low-memory situations

[Benjamin Kircher]

> On 12. Aug 2019, at 18:16, Lennart Poettering  wrote:
> 
> On Mo, 12.08.19 09:40, Chris Murphy (li...@colorremedies.com) wrote:
> 
>> How to do this automatically? Could there be a mechanism for the
>> system and the requesting application to negotiate resources?
> 
> Ideally, GNOME would run all its apps as systemd --user services. We
> could then set DefaultMemoryHigh= globally for the systemd --user
> instance to some percentage value (which is taken relative to the
> physical RAM size). This would then mean every user app individually
> could use — let's say — 75% of the physical RAM size and when it wants
> more it would be penalized during reclaim compared to apps using less.
> 
> If GNOME would run all apps as user services we could do various other
> nice things too. For example, it could dynamically assign the fg app
> more CPU/IO weight than the bg apps, if the system is starved of
> both.

I really like the ideas. Why isn’t this done this way anyway?

I don’t have a GNOME desktop at hand right now to investigate how GNOME starts 
applications and so on but aren’t new processes started by the user — GNOME or 
not — always children of the user.slice? Is there a difference if I start a 
GNOME application or a normal process from my shell?

And for the beginning, wouldn’t it be enough to differentiate between user 
slices and system slice and set DefaultMemoryHigh= in a way to make sure there 
is always some headroom left for the system?

BK

(… I definitely need to play around with Silverblue to learn what they are 
doing.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Better interactivity in low-memory situations

[Benjamin Kircher]

> On 12. Aug 2019, at 17:40, Chris Murphy  wrote:
> 
> If I just run the example program, let's say systemd MemoryLimit is
> set to /proc/meminfo MemAvailable, the program is still going to try
> and bust out of that and fail. The failure reason is also non-obvious.
> Yes this is definitely an improvement in that the system isn't taken
> down.
> 
> How to do this automatically? Could there be a mechanism for the
> system and the requesting application to negotiate resources?

Honestly, right now, doing this automatically is not possible.

Instead, we anticipate the workload or the nature of the work. Like as when we 
connect remotely to a box and start some long running process, we anticipate 
trouble with the network and use a terminal multiplexer, right? Same thing with 
resource intensive processes.

But in future, I could imagine that this whole control group mechanism really 
pays off in a way where we distribute system resources automatically.

Isn’t that what Silverblue is all about? Having a base system and on top of 
that, everything is run in a container that could be potentially resource 
constraint?

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

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

[Brian C. Lane]

On Sun, Aug 11, 2019 at 11:39:34AM +0200, Miro Hrončok wrote:
> Hey, I have noticed that anaconda-core has a runtime dependency on 
> python3-coverage.
> 
> Is it some weird error, or does anaconda actually need a test coverage
> measuring tool at runtime?

Yes. If you pass inst.debug=1 it will generate a coverage report.

https://github.com/rhinstaller/anaconda/blob/master/anaconda.py#L35

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Xen-devel] Xen / EC2 release criteria proposal

[Adam Williamson]

On Sat, 2019-08-10 at 20:12 +0200, Dridi Boukelmoune wrote:
> Sorry for the top posting, "smart" phone...
> 
> What about Qubes OS? Isn't their dom0 using xen, based on Fedora?
> 
> Do they use Xen as packaged by Fedora? If not, couldn't they contribute
> whatever they do that Fedora doesn't here?
> 
> It might be worth getting in touch with them. They look like a significant
> Xen user, on Fedora.

I have no idea, but those seem like reasonable questions. I'll see if I
can track down a contact point for them. Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Better interactivity in low-memory situations

[Lennart Poettering]

On Mo, 12.08.19 09:40, Chris Murphy (li...@colorremedies.com) wrote:

> How to do this automatically? Could there be a mechanism for the
> system and the requesting application to negotiate resources?

Ideally, GNOME would run all its apps as systemd --user services. We
could then set DefaultMemoryHigh= globally for the systemd --user
instance to some percentage value (which is taken relative to the
physical RAM size). This would then mean every user app individually
could use — let's say — 75% of the physical RAM size and when it wants
more it would be penalized during reclaim compared to apps using less.

If GNOME would run all apps as user services we could do various other
nice things too. For example, it could dynamically assign the fg app
more CPU/IO weight than the bg apps, if the system is starved of
both.

> Right now the only lever to avoid swap, is to not create a swap
> partition at installation time. Or create a smaller one instead of 1:1
> ratio with RAM. Or use a 1/4 RAM sized swap on ZRAM. A consequence of
> each of these alternatives, is hibernation can't be used. Fedora
> already explicitly does not support hibernation, but strictly that
> means we don't block release on hibernation related bugs. Fedora does
> still create a swap that meets the minimum size for hibernation, and
> also inserts the required 'resume' kernel  parameter to locate the
> hibernation image at the next boot. So we kinda sorta do support it.

We could add a mode to systemd's hibernation support to only "swapon"
a swap partition immediately before hibernating, and "swapoff" it
right after coming back. This has been proposed before, but noone so
far did the work on it. But quite frankly this feels just like taping
over the fact that the Linux kernel is rubbish when it comes to
swapping...

> Another reality is, the example program, also doesn't have a good way
> of estimating the resources it needs. It has some levers, that just
> aren't being used by default, including -l option which reads "do not
> start new jobs if the load average is greater than N". But that's
> different than "tell me the box sizes you can use" and then the system
> supplying a matching box, and for the program to work within it.

As suggested above, I think DefaultMemoryHigh=75% would be an OK
approach which would allow us adjust to the "beefiness" of a machine
automatically.

Lennart

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

Re: Better interactivity in low-memory situations

[Chris Murphy]

On Mon, Aug 12, 2019 at 1:01 AM Florian Weimer  wrote:
>
> * Chris Murphy:
>
> > Summary of findings (restated, but basically the same as found at [2]):
> > Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
> > Samsung SSD 840 EVO, Fedora Rawhide Workstation.
>
> Do you use the built-in Intel graphics?  Can you test with something
> else?

Only intel graphics. The AMD GPU on the test system is
non-functional/defective. Other systems only have Intel graphics. I
have tested this in a VM which I think is qxl graphics (?), and I get
the same results, with minimal sample size. It seems like the oom
happens more often and sooner on the VM, but that might because the VM
is necessarily even more resource constrained than the host. But I
have reproduced the total and seemingly indefinite hang. The results
aren't completely deterministic, whether baremetal or VM. They're all
"failures" in one form or another, but how they fail does differ run
to run. And that's expected because to what degree I'm simultaneously
browsing in Firefox, how many tabs are open, other programs being
used, the user is a cause of that non-determinism and is a relevant
factor.


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

[Bug 1740223] Upgrade perl-Module-CPANTS-Analyse to 1.01

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Module-CPANTS-Analyse-
   ||1.01-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 15:45:28



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=36959532

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Better interactivity in low-memory situations

[Chris Murphy]

On Mon, Aug 12, 2019 at 12:30 AM Benjamin Kircher
 wrote:
>
>
>
> > On 11. Aug 2019, at 23:05, Chris Murphy  wrote:
> >
> > I think the point at which the mouse pointer has frozen, the user has
> > no practical means of controlling or interacting with the system, it's
> > a failure.
> >
> > In the short term, is it reasonable and possible, to get the oom
> > killer to trigger sooner and thereby avoid the system becoming
> > unresponsive in the first place? The oom score for most all processes
> > is 0, and niced processes have their oom score increased. I'm not
> > seeing levers to control how aggressive it is, only a way of hinting
> > at which processes can be more readily subject to being killed. In
> > fact, a requirement of oom killer is that swap is completely consumed,
> > which if swap is on anything other than a fast SSD, swapping creates
> > its own performance problems way before oom can be a rescuer. I think
> > I just argued against my own question.
>
> Yes you just did :-)
>
> From what I understand from this LKML thread [1] fast swap on NVMe is only 
> part of the issue (or adds to the issue). The kernel really really tries hard 
> not to OOM kill anything and keep the system going. And this overcommitment 
> is where it eventually gets unresponsive to the extend that the machine needs 
> to be hard rebooted.
>
> The LKML thread also mentions that user-space OOM handling could help.
>
> But what about cgroups? Isn’t there a systemd utility that helps me wrap 
> processes in resource constrained groups? Something along the line
>
> $ systemd-run -p MemoryLimit=1G firefox
>
> (Not tested.) I imagine that a well-behaved program will handle a bad malloc 
> by ending itself?
>
> BTW, this happens not only on Linux. I’m used to deal with quite big files 
> during my day job and if you accidentally write some… em… very 
> unsophisticated code that attempts to read the entire file into memory at 
> once you can experience the same behavior on a recent macOS, too. You’re left 
> with nothing else than force rebooting your machine.
>
> [1] https://lkml.org/lkml/2019/8/4/15
>

If I just run the example program, let's say systemd MemoryLimit is
set to /proc/meminfo MemAvailable, the program is still going to try
and bust out of that and fail. The failure reason is also non-obvious.
Yes this is definitely an improvement in that the system isn't taken
down.

How to do this automatically? Could there be a mechanism for the
system and the requesting application to negotiate resources?

One reality is, the system isn't a good estimator of system
responsiveness from the user's point of view. Anytime swap is under
significant pressure (what's the definition of significant?) the
system is effectively lost at that point, *if* this is a desktop
system (includes laptops). In the example case, once swap is being
heavily used on either the SSD, or on ZRAM, the mouse pointer is
frozen variably 50%-90% of the time. It's not a usable system, well
before swap is full. How does the system learn that a light swap rate
is OK, but a heavy swap rate will lead to an angry user? And even
heavy swap might be OK on NVMe, or on a server.

Right now the only lever to avoid swap, is to not create a swap
partition at installation time. Or create a smaller one instead of 1:1
ratio with RAM. Or use a 1/4 RAM sized swap on ZRAM. A consequence of
each of these alternatives, is hibernation can't be used. Fedora
already explicitly does not support hibernation, but strictly that
means we don't block release on hibernation related bugs. Fedora does
still create a swap that meets the minimum size for hibernation, and
also inserts the required 'resume' kernel  parameter to locate the
hibernation image at the next boot. So we kinda sorta do support it.

Another reality is, the example program, also doesn't have a good way
of estimating the resources it needs. It has some levers, that just
aren't being used by default, including -l option which reads "do not
start new jobs if the load average is greater than N". But that's
different than "tell me the box sizes you can use" and then the system
supplying a matching box, and for the program to work within it.


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

[Bug 1740151] Upgrade perl-Class-Method-Modifiers to 2.13

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Class-Method-Modifiers
   ||-2.13-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 15:32:05



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=36959025

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740154] Upgrade perl-Compress-Raw-Lzma to 2.087

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Compress-Raw-Lzma-2.08
   ||7-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 15:06:32



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=36958105

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Better interactivity in low-memory situations

[Florian Weimer]

* Petr Pisar:

> On 2019-08-12, Florian Weimer  wrote:
>> Do you use the built-in Intel graphics?  Can you test with something
>> else?
>>

> Does it have any effect? It happens to me even with a discrete GPU.

I expect that the GEM shrinker (or rather, the reason why it is needed)
radically alters kernel memory management.

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: Better interactivity in low-memory situations

[Petr Pisar]

On 2019-08-12, Florian Weimer  wrote:
> Do you use the built-in Intel graphics?  Can you test with something
> else?
>
Does it have any effect? It happens to me even with a discrete GPU.

As far as I know integrated graphics arrays do not share physical memory
from point of view of the CPU address space. The physical memory is
split between GPU and CPU regions and CPU never see the GPU's physical
memory. IOMMU can be asked for mapping GPU's memory into CPU's virtual
space as can be done with any PCI card, but the physical memory is
always separated. (Although it lives in the same memory chip.) Some
BIOSes allows to define the UMA split (ratio beteen GPU and CPU memory).
But that is out of control of an operating system and cannot be change
until reset.

What actually happens is that some CPU physical memory is used for a GUI
program text and some CPU memory for a block device I/O cache. Both
purposes are handled uniformly by Linux. When the physical memory is
exhausted, a memory allocator starts paging to a swap device. The evil
thing is how memory pages are selected to be swapped out. The algorithm
is to swap out the least recently used ones. And that is often the
program text. Not the block cache. As a result your GUI becomes
unresponsive because all the physical memory is filled with a block
cache and the program text has to be reloaded from a block device. And
what's worse, this happens even without swap space because program text
pages are backed by a file and thus can dropped and loaded from a file
system later. I.e. program text is always swapable.

A cure would be more fair memory allocator that could magically
discover that a user is more interested in the few megabytes of his
window manager than the gigabytes of a transfered file. The issue is
that the allocator does not discriminate. A process can actully provide
some hints using madvise(2) and mlock(2), but that does not apply to
the program text, neither to the block cache in the kernel space. And
even if processes provided hints, there always could be some adversarial
program abusing others. Maybe if ulimit were augmented with a block
cache maximal usage and an I/O scheduler accounted for that. That could
help.

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

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

[Miro Hrončok]

On 12. 08. 19 16:19, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Aug 06, 2019 at 09:35:50PM +0200, Petr Stodulka wrote:

Hi guys,
as discussion was started week ago, Python2 is dying. As that, some
dependencies of mercurial will be orphaned soon (or they are already)
and mercurial as it is has to move in weeks on Python3. As I wrote
in [0], I already started some testing and investigation.

Currently it seems that with ugly hacky fix, we are able to run
somi-working mercurial with Python3. I did just simple testing
that worked for me and in the latest copr-build (below), it seems
that hgk extension is workin as well. But many of you extensions
will be probably broken. So, I guess the most probably mercurial
will be broken for the others who use it.

So it's question, should I rebase it in rawhide and setup for Python3
already even when it is so broken, or should I wait several weeks yet
for additional fixes?


I think it's reasonable to ship in rawhide, if the basic clone
operations work. This will satisfy 99% of use cases, i.e. cloning
of repos from the web without any further interaction with the VCS.
I don't have any data to back this up, but since Mercurial has lost
a lot of it's erstwhile popularity, based on how things go with
other python2-only projects, chances are that most extensions will not
be updated in time for F31. And it's better to have somewhat functional
clone operation than nothing.


I suggest to switch after the branching in F32 only and than (re)consider doing 
a backport before the F31 beta freeze.


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

[Bug 1740224] Upgrade perl-PDF-API2 to 2.035

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-PDF-API2-2.035-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 14:23:10



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 06, 2019 at 09:35:50PM +0200, Petr Stodulka wrote:
> Hi guys,
> as discussion was started week ago, Python2 is dying. As that, some
> dependencies of mercurial will be orphaned soon (or they are already)
> and mercurial as it is has to move in weeks on Python3. As I wrote
> in [0], I already started some testing and investigation.
> 
> Currently it seems that with ugly hacky fix, we are able to run
> somi-working mercurial with Python3. I did just simple testing
> that worked for me and in the latest copr-build (below), it seems
> that hgk extension is workin as well. But many of you extensions
> will be probably broken. So, I guess the most probably mercurial
> will be broken for the others who use it.
> 
> So it's question, should I rebase it in rawhide and setup for Python3
> already even when it is so broken, or should I wait several weeks yet
> for additional fixes?

I think it's reasonable to ship in rawhide, if the basic clone
operations work. This will satisfy 99% of use cases, i.e. cloning
of repos from the web without any further interaction with the VCS.
I don't have any data to back this up, but since Mercurial has lost
a lot of it's erstwhile popularity, based on how things go with
other python2-only projects, chances are that most extensions will not
be updated in time for F31. And it's better to have somewhat functional
clone operation than 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

[Bug 1740224] New: Upgrade perl-PDF-API2 to 2.035

[bugzilla]

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

Bug ID: 1740224
   Summary: Upgrade perl-PDF-API2 to 2.035
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PDF-API2
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.034 version. Upstream released 2.035. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740223] New: Upgrade perl-Module-CPANTS-Analyse to 1.01

[bugzilla]

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

Bug ID: 1740223
   Summary: Upgrade perl-Module-CPANTS-Analyse to 1.01
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-CPANTS-Analyse
  Assignee: p...@city-fan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, lkund...@v3.sk,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.00 version. Upstream released 1.01. When you have free
time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740149] Upgrade perl-App-cpm to 0.983

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-App-cpm-0.983-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 13:17:50



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740200] New: perl-Scalar-List-Utils 1.51 is available

[bugzilla]

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

Bug ID: 1740200
   Summary: perl-Scalar-List-Utils 1.51 is available
   Product: Fedora
   Version: rawhide
   URL: https://metacpan.org/release/Scalar-List-Utils
Status: NEW
 Component: perl-Scalar-List-Utils
  Keywords: FutureFeature
  Assignee: jpazdzi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jpazdzi...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.50 version. Upstream released 1.51 version. When you
have free time, please upgrade it.

Be ware there is a  bug
that manifests on uselongdouble Perls. This is not a case of Fedora.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

good to keep your package in sync (for translations)

[Sundeep Anand]

Hi,

With the deployment of Transtats[1] latest release at 
https://transtats.fedoraproject.org/ we can track packages which are out of 
sync. This can answer: Is everything translated packaged? A couple of features:

(1) Package Translation Completeness: At a glance picture of statistics from 
source repo, translation platform and build system - with any differences found 
(based on branch mapping)[2]

(2) Translation Coverage: This is for, to get into insights (to see numbers) - 
for example, number of messages translated in platform vs packaged. This is 
based on rules[3] and hence flexible. Demo: 
https://www.youtube.com/watch?v=-X5G_zH-3TE (2.18 Minutes)

Quick start page is here: https://transtats.fedoraproject.org/quick-start

(Transtats sync with translation platform and build system at intervals to keep 
stats latest.)

thanks,
sundeep

[1] http://transtats.org
[2] 
https://speakerdeck.com/sundeep/use-cases-for-transtats-in-the-fedora-community?slide=6
[3] https://transtats.fedoraproject.org/coverage/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

no fesco meeting today

[Zbigniew Jędrzejewski-Szmek]

This is just a clarification that we decided not to hold a meeting
today because people are travelling back from Flock. We'll hold a
meeting on the 19th.

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

[Bug 1740155] Upgrade perl-Compress-Raw-Zlib to 2.087

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Compress-Raw-Zlib-2.08
   ||7-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 12:12:03



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Stephen John Smoogen]

On Mon, 12 Aug 2019 at 07:21, Miro Hrončok  wrote:

> On 09. 08. 19 11:13, Antonio Trande wrote:
> > Hi all.
> >
> > 'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
> > EPEL7 ppc64le only?
> >
> >
> https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000
>
> Funny thing:
>
> ppc64le gets:
>
> Problem: conflicting requests
>   - nothing provides python-rpm-macros > 3-30 needed by
> python-devel-2.7.5-86.el7.ppc64le
>   - nothing provides python2-rpm-macros > 3-30 needed by
> python-devel-2.7.5-86.el7.ppc64le
>
> x86_64 gets python-devel-2.7.5-80.el7.x86_64
>
> It seems that the ppc64le build has the arched package from RHEL 7.7 but
> misses
> the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages
> from
> RHEL 7.6 altogether.
>
>
OK our certificate to using Red Hat Network was made invalid during a sync.
I am 'fixing'.

>
>

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

License correction in teckit-2.5.9-2.fc31

[Petr Pisar]

After unretiring teckit I reviewed the sources and corrected a license
tag from

LGPLv2+ or CPL

to

(LGPLv2+ or CPL) and (LGPLv2+ or GPLv2+ or MPLv2.0 or MPLv1.1)

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

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

[Fedora compose checker]

No missing expected images.

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

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

New failures (same test not failed in Fedora-Rawhide-20190811.n.1):

ID: 430933  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/430933
ID: 430934  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/430934
ID: 430962  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/430962
ID: 430966  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/430966
ID: 430985  Test: x86_64 universal install_delete_pata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/430985
ID: 430993  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/430993

Old failures (same test failed in Fedora-Rawhide-20190811.n.1):

ID: 430941  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430941
ID: 430942  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430942
ID: 430968  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/430968
ID: 430970  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/430970
ID: 430971  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/430971
ID: 431032  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/431032
ID: 431040  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/431040
ID: 431043  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/431043
ID: 431044  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/431044
ID: 431046  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/431046
ID: 431047  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/431047

Passed openQA tests: 111/143 (x86_64)

Skipped gating openQA tests: 4/143 (x86_64)

Old skipped gating tests (same test skipped in Fedora-Rawhide-20190811.n.1):

ID: 430946  Test: x86_64 Workstation-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/430946
ID: 430947  Test: x86_64 Workstation-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/430947
ID: 430949  Test: x86_64 Workstation-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/430949
ID: 430950  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/430950

Skipped non-gating openQA tests: 13 of 145

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
1 packages(s) added since previous compose: libtextstyle
2 packages(s) removed since previous compose: GeoIP, GeoIP-GeoLite-data
Previous test data: https://openqa.fedoraproject.org/tests/430721#downloads
Current test data: https://openqa.fedoraproject.org/tests/430906#downloads

Installed system changes in test x86_64 Server-boot-iso install_default: 
1 packages(s) added since previous compose: libtextstyle
2 packages(s) removed since previous compose: GeoIP, GeoIP-GeoLite-data
Previous test data: https://openqa.fedoraproject.org/tests/430722#downloads
Current test data: https://openqa.fedoraproject.org/tests/430907#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.05 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/430723#downloads
Current test data: https://openqa.fedoraproject.org/tests/430908#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
1 packages(s) added since previous compose: libtextstyle
Previous test data: https://openqa.fedoraproject.org/tests/430754#downloads
Current test data: https://openqa.fedoraproject.org/tests/430939#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
1 packages(s) added since previous compose: libtextstyle
Previous test data: https://openqa.fedoraproject.org/tests/430755#downloads
Current test data: 

[Bug 1740152] Upgrade perl-Compress-Raw-Bzip2 to 2.087

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Compress-Raw-Bzip2-2.0
   ||87-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 11:48:42



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Miro Hrončok]

On 12. 08. 19 13:20, Miro Hrončok wrote:

On 09. 08. 19 11:13, Antonio Trande wrote:

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000 



Funny thing:

ppc64le gets:

Problem: conflicting requests
  - nothing provides python-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le
  - nothing provides python2-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le


x86_64 gets python-devel-2.7.5-80.el7.x86_64

It seems that the ppc64le build has the arched package from RHEL 7.7 but misses 
the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages from 
RHEL 7.6 altogether.


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

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

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

[Hans de Goede]

Hi,

On 11-08-19 01:05, Sérgio Basto wrote:

Hi,

Why we would retire childsplay or gcompris or gdesklets ? IMHO we still
haven't a replacement .


childsplay and gcompris maintainer here.

Childsplay has been in a zombie state upstream for years, some work has
been done upstream but mostly focusing on reusing the code into a memory
trainer app for the elderly, rather then on educational activities.
Childsplay has always had a significant overlap with gcompris, given
the lack of upstream activity and the overlap with gcompris the time has
come to retire childsplay

gcompris has been replaced upstream by gcompris-qt, which is also in
Fedora and which we will keep around.

Both gcompris and childsplay have not seen much if any upstream love for
yeas now and have been kept functional only because of my efforts to keep
them building and working. The lack of any realistic path to get these
ported over to Python 3 is the last straw that breaks the camel's back.

The same goes e.g. for vegastrike which also has seen close to no
activity upstream for I guess 5 years at least...

Regards,

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

[Bug 1740156] New: Upgrade perl-IO-Compress to 2.087

[bugzilla]

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

Bug ID: 1740156
   Summary: Upgrade perl-IO-Compress to 2.087
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Compress
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
rland...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.086 version. Upstream released 2.087. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740157] New: Upgrade perl-IO-Compress-Lzma to 2.087

[bugzilla]

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

Bug ID: 1740157
   Summary: Upgrade perl-IO-Compress-Lzma to 2.087
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Compress-Lzma
  Assignee: p...@city-fan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.086 version. Upstream released 2.087. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740154] New: Upgrade perl-Compress-Raw-Lzma to 2.087

[bugzilla]

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

Bug ID: 1740154
   Summary: Upgrade perl-Compress-Raw-Lzma to 2.087
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Compress-Raw-Lzma
  Assignee: p...@city-fan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jn...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.086 version. Upstream released 2.087. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740155] New: Upgrade perl-Compress-Raw-Zlib to 2.087

[bugzilla]

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

Bug ID: 1740155
   Summary: Upgrade perl-Compress-Raw-Zlib to 2.087
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Compress-Raw-Zlib
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.086 version. Upstream released 2.087. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740152] New: Upgrade perl-Compress-Raw-Bzip2 to 2.087

[bugzilla]

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

Bug ID: 1740152
   Summary: Upgrade perl-Compress-Raw-Bzip2 to 2.087
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Compress-Raw-Bzip2
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.086 version. Upstream released 2.087. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740151] New: Upgrade perl-Class-Method-Modifiers to 2.13

[bugzilla]

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

Bug ID: 1740151
   Summary: Upgrade perl-Class-Method-Modifiers to 2.13
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Class-Method-Modifiers
  Assignee: p...@city-fan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.12 version. Upstream released 2.13. When you have free
time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1731802] Upgrade perl-Carp-Assert-More to 1.20

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Summary|Upgrade |Upgrade
   |perl-Carp-Assert-More to|perl-Carp-Assert-More to
   |1.18|1.20



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1740149] New: Upgrade perl-App-cpm to 0.983

[bugzilla]

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

Bug ID: 1740149
   Summary: Upgrade perl-App-cpm to 0.983
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-App-cpm
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.982 version. Upstream released 0.983. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Miro Hrončok]

On 09. 08. 19 11:13, Antonio Trande wrote:

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000


Funny thing:

ppc64le gets:

Problem: conflicting requests
 - nothing provides python-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le
 - nothing provides python2-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le


x86_64 gets python-devel-2.7.5-80.el7.x86_64

It seems that the ppc64le build has the arched package from RHEL 7.7 but misses 
the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages from 
RHEL 7.6 altogether.


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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Tuomo Soini]

On Mon, 12 Aug 2019 10:52:34 +0200
Miro Hrončok  wrote:

> > python3_other is now defined to 3 in rhel7.7.  
> 
> By what? Do you mean python3_pkgversion? W can override that as well.

Sorry. python3_pkgversion.


-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Fedora rawhide compose report: 20190812.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190811.n.1
NEW: Fedora-Rawhide-20190812.n.0

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

Size of added packages:  24.57 MiB
Size of dropped packages:267.33 KiB
Size of upgraded packages:   264.35 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: wine-dxvk-1.3.2-1.fc31
Summary: Vulkan-based D3D11 and D3D10 implementation for Linux / Wine
RPMs:wine-dxvk wine-dxvk-dxgi
Size:24.57 MiB


= DROPPED PACKAGES =
Package: gwsmhg-0.13.2-16.fc31
Summary: A PyGTK GUI wrapper for hg and mq
RPMs:gwsmhg
Size:246.60 KiB

Package: python-pthreading-0.1.3-14.fc31
Summary: Re-implement threading.Lock, RLock and Condition with libpthread
RPMs:python2-pthreading
Size:20.73 KiB


= UPGRADED PACKAGES =
Package:  3Depict-0.0.22-3.fc31
Old package:  3Depict-0.0.21-3.fc30
Summary:  Valued 3D point cloud visualization and analysis
RPMs: 3Depict
Size: 34.10 MiB
Size change:  777.22 KiB
Changelog:
  * Fri Apr 05 2019 D Haley  - 0.0.22-1
  - Update to 0.0.22

  * Wed Jul 24 2019 Fedora Release Engineering  - 
0.0.22-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Sun Aug 11 2019 D Haley  - 0.0.22-3
  - Fix for PPC64LE qhull include bug (#1735406)


Package:  aircrack-ng-1.5.2-7.fc31
Old package:  aircrack-ng-1.5.2-5.fc30
Summary:  802.11 (wireless) sniffer and WEP/WPA-PSK key cracker
RPMs: aircrack-ng
Size: 19.74 MiB
Size change:  242.58 KiB
Changelog:
  * Wed Jul 24 2019 Fedora Release Engineering  - 
1.5.2-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Sun Aug 11 2019 Filipe Rosset  - 1.5.2-7
  - Fix FTBFS on rawhide fixes rhbz#1734928 and rhbz#1735447


Package:  git-2.23.0-0.2.rc2.fc31
Old package:  git-2.23.0-0.1.rc1.fc31
Summary:  Fast Version Control System
RPMs: git git-all git-core git-core-doc git-cvs git-daemon git-email 
git-gui git-instaweb git-subtree git-svn gitk gitweb perl-Git perl-Git-SVN
Size: 37.38 MiB
Size change:  -2.15 KiB
Changelog:
  * Sun Aug 11 2019 Todd Zullinger  - 2.23.0-0.2.rc2
  - Update to 2.23.0-rc2


Package:  gsequencer-2.2.37-0.fc31
Old package:  gsequencer-2.2.28-0.fc31
Summary:  Audio processing engine
RPMs: gsequencer gsequencer-devel gsequencer-devel-doc
Size: 20.16 MiB
Size change:  22.03 KiB

Package:  igt-gpu-tools-1.23-1.20190811gitf43f5fa.fc31
Old package:  igt-gpu-tools-1.23-1.20190801gitb3138fb.fc31
Summary:  Test suite and tools for DRM drivers
RPMs: igt-gpu-tools igt-gpu-tools-docs
Size: 12.43 MiB
Size change:  7.36 KiB
Changelog:
  * Sun Aug 11 2019 Lyude Paul  - 1.23-1.20190811gitf43f5fa
  - New git snapshot


Package:  ocaml-charinfo-width-1.1.0-3.fc31
Old package:  ocaml-charinfo-width-1.1.0-2.fc31
Summary:  Determine column width for a character
RPMs: ocaml-charinfo-width ocaml-charinfo-width-devel
Size: 1.37 MiB
Size change:  1.48 KiB
Changelog:
  * Sun Aug 11 2019 Ben Rosser  - 1.1.0-3
  - Rebuilt for camomile 1.0.2.


Package:  ocaml-lwt-log-1.1.1-1.fc31
Old package:  ocaml-lwt-log-1.1.0-4.fc31
Summary:  Lwt logging library
RPMs: ocaml-lwt-log ocaml-lwt-log-devel
Size: 1.68 MiB
Size change:  691.58 KiB
Changelog:
  * Wed Aug 07 2019 Ben Rosser  - 1.1.0-5
  - Fix use of deprecated Lwt_main.exit_hooks in lwt 4.1+.

  * Thu Aug 08 2019 Ben Rosser  - 1.1.1-1
  - Update to latest upstream release, 1.1.1.


Package:  ocaml-zed-2.0.3-1.fc31
Old package:  ocaml-zed-2.0.2-2.fc31
Summary:  Abstract engine for text edition in OCaml
RPMs: ocaml-zed ocaml-zed-devel
Size: 6.97 MiB
Size change:  66.14 KiB
Changelog:
  * Sun Aug 11 2019 Ben Rosser  - 2.0.3-1
  - Updated to latest upstream release.


Package:  podman-2:1.5.1-0.6.dev.git2348c28.fc31
Old package:  podman-2:1.5.1-0.3.dev.git3bc861c.fc31
Summary:  Manage Pods, Containers and Container Images
RPMs: podman podman-docker podman-manpages podman-remote podman-tests
Size: 125.58 MiB
Size change:  -28.66 KiB
Changelog:
  * Sun Aug 11 2019 Lokesh Mandvekar (Bot)  - 
2:1.5.1-0.4.dev.git7bbaa36
  - autobuilt 7bbaa36

  * Sun Aug 11 2019 Lokesh Mandvekar (Bot)  - 
2:1.5.1-0.5.dev.git1467197
  - autobuilt 1467197

  * Mon Aug 12 2019 Lokesh Mandvekar (Bot)  - 
2:1.5.1-0.6.dev.git2348c28
  - autobuilt 2348c28


Package:  python-dmidecode-3.12.2-16.fc31
Old package:  python-dmidecode-3.12.2-15.fc31
Summary:  Python module to access DMI data
RPMs: python3-dmidecode
Dropped RPMs: python2-dmidecode
Size: 553.45 KiB
Size change:  -559.50 KiB
Changelog:
  * Sun Aug 11 2019 Miro Hron??ok  - 3.12.2-16
  - Subpackage

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

[Martin Kolman]

- Original Message -
> From: "Miro Hrončok" 
> To: "Development discussions related to Fedora" 
> 
> Cc: anaconda-maint-l...@redhat.com
> Sent: Sunday, August 11, 2019 11:39:34 AM
> Subject: Why does anaconda-core runtime depend on python3-coverage?
> 
> Hey, I have noticed that anaconda-core has a runtime dependency on
> python3-coverage.
> 
> Is it some weird error, or does anaconda actually need a test coverage
> measuring
> tool at runtime?
This is working as intended - Anaconda supports recording code coverage 
information at runtime,
so it is possible to check code coverage during real installation runs, not 
just when running
unit tests.

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

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

[Petr Viktorin]

On 8/11/19 2:28 PM, Kevin Kofler wrote:

Miro Hrončok wrote:

We are still planning to maintain the interpreter. As is documented in the
change. So can we please stop arguing about maintaining the interpreter
over and over? It is staying and our team will maintain it at least until
RHEL 7 EOL, possibly longer.


Then why do you require all this FESCo exception bureaucracy, including a
Python 3 migration plan, for every single package requiring Python 2, even
if it is only the interpreter (and the shipped standard library)?


Python 2 will not get the attention, fixes, and security updates that 
people have been used to in the past decade. That's a big deal, and 
unfortunately we know no good way to properly communicate this to all 
the affected packagers.
We hope the bureaucracy works for the hundreds of packages with inactive 
maintainers; the flip side is that the active maintainers do have to do 
some more work, even if it's just filing a ticket and switching a 
BuildRequires. Sorry for that.


As for the Python 3 migration plan: we can agree to maintain Python 2 
for you to depend on, if there's a feasible plan of moving away from 
Python 2. If there's no plan, you'll just run into trouble in a few more 
years. If you consider your package important, we really want to know 
about the situation.


The Python 3 migration plan is not a requirement, but a very common and 
useful piece of information that we want to hear about. Every package is 
different; we can't know where each upstream does their planning. As a 
packager, you know best where to ask for this info, so we ask you to 
find it and paste the link in a Fedora place -- Bugzilla or a FESCo ticket.
If there's another plan instead of a "Python 3 porting plan" (like port 
to Rust instead, or to Tauthon, or maintain Python 2 forever), we'd also 
like to know about it.




Yes the concern is about maintaining the python2-* packages.

The difference between EL and Fedora is that package sin Fedora get recent
rebases / updates to newer version. You cannot just package them and call
it "done". And most of the upstreams are coming to a point where you
cannot update the Python 2 package because the new version doe snot
support Python 2.

That at the end means you need to go over nonobvious bumps to split the
Python 2 package out of the "common" package, in order to update the
"common" (now Python 3 only) package. And this problem spreads further
with dependencies (even transitive ones). I don't have the energy or time
to split hundreds of packages and maintain a separate stack of Python 2
packages. If somebody else has, go for it.


And that is a perfectly valid reason to orphan the Python 2 parts. My issue
with the policy you proposed and FESCo approved for F31 is that it does not
require this to be the case, but allows maintainers to drop the Python 2
subpackage just because they don't like Python 2 (or simply want to avoid
going through the bureaucracy you're requiring for F32), which is a quite
antisocial thing to do.

If the partial orphaning policy were limited to packages where upstream
dropped or is in the process of dropping Python 2 support, I would not
object.


The policy is for those *and their dependencies*.

See, I have a "package where upstream is in the process of dropping 
Python 2 support". It's called "python2".
I could just drop it and call it a day, but since people still want it, 
I'll maintain it. But only for those who care and who understand the 
situation; not for the hundreds of inactive maintainers.
(To be clear: making it possible and straightforward to build Fedora 
RPMs with python3 *is* more work than just maintaining the interpreter 
for users.)



That said, those are also the cases where the split out python2-* package
WOULD in fact be "done" and never require getting updated to a newer
version, unless upstream maintains some legacy/LTS branch. So the situation
for whomever ends up stuck maintaining the python2-* package would not be
that different from the RHEL situation.


Sure, but this "python2" one does need ongoing maintenance.


The set of python2-* packages to remain is determined by the FESCo
exceptions. It is fairly easy really: We don't have the necessary
information to understand what Python packages are "important" and what
are "cruft". Hence if your package is important, you just need to explain
that. Obviously, if you need to maintain the package as a dependency, for
another important package, the exception can be requested at once, you
don't need to request dozens of exception to keep e.g. chromium around.


But why does this have to go through FESCo and a formal approval process?
Why is it not sufficient that the maintainer says "yes, this is still
needed"? If a maintainer wants to keep the package, this clearly means it is
important to SOMEBODY, so why do we need an approval by committee to confirm
this (or worse, veto this against the wishes of the maintainer)?


The maintainer needs to say "yes, 

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Mikolaj Izdebski]

On Mon, Aug 12, 2019 at 11:21 AM Miro Hrončok  wrote:
>
> On 12. 08. 19 11:16, Mikolaj Izdebski wrote:
> > On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok  wrote:
> >>
> >> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> >>> On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:
> 
>  See for example:
> 
>  https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
>  2019-08-11 07:50:11
> 
>  - nothing provides python(abi) = 3.6 ...
> 
>  This is provided in RHEL 7.7.
> 
>  (Note that we've unretired the python36 package, so later it resolved 
>  correctly.)
> >>>
> >>> Koschei uses Koji repos. You can find out the exact repo URL at given
> >>> timestamp in the following way:
> >>>
> >>> In [1]: import koji, datetime
> >>> In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> >>> In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> >>> In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> >>> In [5]: event = ks.getLastEvent(before=ts)
> >>> In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> >>> event=event['id'])
> >>> In [7]: pi.repo(repo['id'], 'epel7-build')
> >>> Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
> >>
> >> And for RHEL packages?
> >
> > Selected RHEL packages are available in EPEL buildroots.
>
> Oh. Do you know any pointers about how do I add more?

EPEL 7 build uses repos from 5 RHEL 7 channels.
You can see them with the following command:

$ koji list-external-repos --tag epel7-base
Pri External repo nameMode   URL
--- - --

10  rhel7-server  koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-rpms/
11  rhel7-rhel-extras koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-extras-rpms/
12  rhel7-server-ha   koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-ha-for-rhel-7-server-rpms/
15  rhel7-server-optional koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-optional-rpms/
20  rhel7-server-rhscl-7  koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-server-rhscl-7-rpms/

Koji admins (i.e. Release Engineering) can add more channels upon
request from EPEL developers.
Before adding to Koji, RHEL repos would need to be synced from RHN to
Fedora servers (this can be requested from Fedora Infrastructure).


>
> >>> x86_64 repos are used for dependency resolution. At that time python36
> >>> was not available in epel7-build:
> >>
> >> Are RHEL packages available directly from epel7-build?
> >
> > Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
> > RHEL build.
>
> I see. Thanks.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Miro Hrončok]

On 12. 08. 19 11:16, Mikolaj Izdebski wrote:

On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok  wrote:


On 12. 08. 19 11:12, Mikolaj Izdebski wrote:

On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:


See for example:

https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
2019-08-11 07:50:11

- nothing provides python(abi) = 3.6 ...

This is provided in RHEL 7.7.

(Note that we've unretired the python36 package, so later it resolved 
correctly.)


Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:

In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'


And for RHEL packages?


Selected RHEL packages are available in EPEL buildroots.


Oh. Do you know any pointers about how do I add more?


x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:


Are RHEL packages available directly from epel7-build?


Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
RHEL build.


I see. Thanks.

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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Mikolaj Izdebski]

On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok  wrote:
>
> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> > On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:
> >>
> >> See for example:
> >>
> >> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> >> 2019-08-11 07:50:11
> >>
> >> - nothing provides python(abi) = 3.6 ...
> >>
> >> This is provided in RHEL 7.7.
> >>
> >> (Note that we've unretired the python36 package, so later it resolved 
> >> correctly.)
> >
> > Koschei uses Koji repos. You can find out the exact repo URL at given
> > timestamp in the following way:
> >
> > In [1]: import koji, datetime
> > In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> > In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> > In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> > In [5]: event = ks.getLastEvent(before=ts)
> > In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> > event=event['id'])
> > In [7]: pi.repo(repo['id'], 'epel7-build')
> > Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
>
> And for RHEL packages?

Selected RHEL packages are available in EPEL buildroots.

>
> > x86_64 repos are used for dependency resolution. At that time python36
> > was not available in epel7-build:
>
> Are RHEL packages available directly from epel7-build?

Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
RHEL build.

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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 12. 08. 19 10:52, Miro Hrončok wrote:

On 12. 08. 19 8:14, Tuomo Soini wrote:

On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok  wrote:


%python3_other_pkgversion 34

I believe the easiest fix is to define that directly in
epel-rpm-macros:

https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5


Correct. That fixes this issue but not the huge issue we have now.


Thanks for the report!


I agree. But we have much bigger problem with epel python naming.

python3_other is now defined to 3 in rhel7.7.


By what? Do you mean python3_pkgversion? W can override that as well.


Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.

Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.

We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-.

Let's list some history, please notify if I forgot something important.

python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.

When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion

rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.

Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36- to python3- so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-.

There are two possibilities how to handle this:

Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.


Let's do that as a quick hotfix for now decide the rest later.


Updated https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5

Please some EPEL people, review and possibly build soon.

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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Miro Hrončok]

On 12. 08. 19 11:12, Mikolaj Izdebski wrote:

On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:


See for example:

https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
2019-08-11 07:50:11

- nothing provides python(abi) = 3.6 ...

This is provided in RHEL 7.7.

(Note that we've unretired the python36 package, so later it resolved 
correctly.)


Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:

In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'


And for RHEL packages?


x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:


Are RHEL packages available directly from epel7-build?

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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Mikolaj Izdebski]

On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:
>
> See for example:
>
> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> 2019-08-11 07:50:11
>
> - nothing provides python(abi) = 3.6 ...
>
> This is provided in RHEL 7.7.
>
> (Note that we've unretired the python36 package, so later it resolved 
> correctly.)

Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:

In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'

x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:

$ dnf -q --repofrompath
epel7-build-1234463,https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463/x86_64/
--repo epel7-build-1234463 repoquery --whatprovides 'python(abi)'
python-0:2.7.5-80.el7_6.x86_64
python34-0:3.4.10-2.el7.x86_64


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

Re: [Fedora-join] NeuroFedora is looking for a Spin/Labs master

[Ankur Sinha]

On Mon, Aug 12, 2019 07:11:13 +0200, Vendaval wrote:
> Hello Ankur,

Hello!

> I found this idea very interesting; also, I attend one of the talks in the
> FLOCK.
> 
> If you still don't have a spin master, I will do it.

Sure. We've had @dan1mal volunteer, but we'd like to have a team around
it rather than individuals. I've created a ticket to get you started
with NeuroFedora now:

https://pagure.io/neuro-sig/NeuroFedora/issue/269

Welcome to the team!

-- 
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: Self Introduction: Muneendra

[Muneendra Kumar M via devel]

Hi All,

I have addressed the review comments and the details of SPEC and SRPM are
available in the below path.

Spec URL:
https://github.com/brocade/bsn-fc-txptd/blob/master/SPEC/fc_txptd.spec

SRPM URL:
https://github.com/brocade/bsn-fc-txptd/blob/master/fc_txptd-0.1-1.fc28.sr
c.rpm



Regards,
Muneendra.

-Original Message-
From: Muneendra Kumar M [mailto:muneendra.ku...@broadcom.com]
Sent: Friday, August 2, 2019 9:27 PM
To: 'Matthew Miller' 
Cc: 'Development discussions related to Fedora'

Subject: RE: Self Introduction: Muneendra

Hi Mathew,
I don't have sponsor.
I need a sponsor any help here would be great.

Regards,
Muneendra.


-Original Message-
From: Matthew Miller [mailto:mat...@fedoraproject.org]
Sent: Friday, August 2, 2019 9:25 PM
To: Muneendra Kumar M 
Cc: Development discussions related to Fedora

Subject: Re: Self Introduction: Muneendra

On Fri, Aug 02, 2019 at 09:18:35PM +0530, Muneendra Kumar M wrote:
> Hi Mathew,
>
> Thanks for providing the info.
> One quick question.
> Robert-Andre has given some review(feedaback) on my spec.
> Once I update the changes do I need to reply in the comments or is
> there any other procedure.
> If there is any link to the same if so could you please point me the
same.
> This info  would help me a lot.


Sure -- the process is documented here:
https://fedoraproject.org/wiki/Package_Review_Process

Do you have a sponsor into the packaging group? You'll need that as well.

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

[Bug 1738791] Upgrade perl-TheSchwartz to 1.13

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2019-08-12 07:32:40



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Better interactivity in low-memory situations

[Florian Weimer]

* Chris Murphy:

> Summary of findings (restated, but basically the same as found at [2]):
> Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
> Samsung SSD 840 EVO, Fedora Rawhide Workstation.

Do you use the built-in Intel graphics?  Can you test with something
else?

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: repoquery: Modular dependency problems: nothing provides module(platform:f30)

[Miro Hrončok]

On 12. 08. 19 8:21, Igor Gnatenko wrote:

You need to explicitly set --setopt=module_platform_id=platform:F31

I thought itvwas fixed, but probably it does not work for repoquery.


It was fixed for a long time. This just started again now.

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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 12. 08. 19 8:14, Tuomo Soini wrote:

On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok  wrote:


%python3_other_pkgversion 34

I believe the easiest fix is to define that directly in
epel-rpm-macros:

https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5


Correct. That fixes this issue but not the huge issue we have now.


Thanks for the report!


I agree. But we have much bigger problem with epel python naming.

python3_other is now defined to 3 in rhel7.7.


By what? Do you mean python3_pkgversion? W can override that as well.


Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.

Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.

We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-.

Let's list some history, please notify if I forgot something important.

python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.

When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion

rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.

Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36- to python3- so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-.

There are two possibilities how to handle this:

Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.


Let's do that as a quick hotfix for now decide the rest later.


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

Re: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)

[Lennart Poettering]

On Sa, 10.08.19 12:18, Dridi Boukelmoune (dridi.boukelmo...@gmail.com) wrote:

> Hi,
>
> > That only works properly on distros that implement the boot loader
> > spec and the boot loader interface properly:
> >
> > https://systemd.io/BOOT_LOADER_SPECIFICATION
> > https://systemd.io/BOOT_LOADER_INTERFACE
>
> Thanks for the links, I looked briefly when you replied but figured
> I'd need a quiet setup since this is unfamiliar territory. I have
> finally read both documents, and they are very accessible even to
> someone without prior knowledge.
>
> > Unfortunately, Fedora/grub do not support either.
> >
> > (Which is a pity of course, since it also means there's no working
> > "systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl
> > kexec" support).
>
> I see. Do I understand from reading the specification that it was put
> together during the Fedora 18 days? Do I understand from reading the
> boot loader interface documented that systemd supported all this in
> the f18 days too?

Well, it went through many revisions, and some of the bits are very
recent. For example, the pre-boot random seed stuff has been added in
v243, of which we only posted an -rc1 so far,

However, the basics have been around very early on, yes.

Lennart

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

[Benson Muite]

Ok. Arm and AMD also support OpenCL

https://developer.arm.com/solutions/graphics/apis/opencl

https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime

https://rocm.github.io/install.html

AMD part for OpenCL only seems to be MIT licensed.

On 8/12/19 9:24 AM, Igor Gnatenko wrote:
I've dropped beignet a while ago since I was getting bugs, but 
upstream is dead. Also many times, POCL performed better than beignet.


And after all, if you want to do something complicated with OpenCL, 
you already have high-end AMD or latest Intel card..


However, anyone is free to unretire it.

On Sun, Aug 11, 2019, 14:57 Kevin Kofler > wrote:


Dominik 'Rathann' Mierzejewski wrote:
> Unfortunately the one above is for Broadwell and newer, which means
> it doesn't work with any of my machines.

Don't you love planned obsolescence? A whopping 3 CPU/IGP
generations from
https://wiki.freedesktop.org/www/Software/Beignet/#supportedtargets
got
dropped by the rewrite. :-(

Will Beignet be kept in Fedora or will everyone with those 3 CPU/IGP
generations be stuck with running POCL on the CPU (essentially
defeating the
purpose of OpenCL) instead?

        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


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

[Benson Muite]

On 8/11/19 3:19 PM, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 08 August 2019 at 08:19, Benson Muite wrote:

Hi,

Beignet has been deprecated, might it be possible to put Intel(R) Graphics
Compute Runtime for OpenCL(TM) in the Fedora repositories? There is a COPR
repository at:

https://copr.fedorainfracloud.org/coprs/jdanecki/intel-opencl/

It should be possible, it looks like it's MIT licensed. Have you tried
contacting the maintainer of that COPR?


Yes, he is responsive:

https://github.com/intel/compute-runtime/issues/196




Is there a means by which generation of CPU and GPU being used can be
detected to give a warning or recommendation as to the compatibility of the
OpenCL library?

Unfortunately the one above is for Broadwell and newer, which means
it doesn't work with any of my machines.

Regards,
Dominik

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

Re: Better interactivity in low-memory situations

[Benjamin Kircher]

> On 11. Aug 2019, at 23:05, Chris Murphy  wrote:
> 
> I think the point at which the mouse pointer has frozen, the user has
> no practical means of controlling or interacting with the system, it's
> a failure.
> 
> In the short term, is it reasonable and possible, to get the oom
> killer to trigger sooner and thereby avoid the system becoming
> unresponsive in the first place? The oom score for most all processes
> is 0, and niced processes have their oom score increased. I'm not
> seeing levers to control how aggressive it is, only a way of hinting
> at which processes can be more readily subject to being killed. In
> fact, a requirement of oom killer is that swap is completely consumed,
> which if swap is on anything other than a fast SSD, swapping creates
> its own performance problems way before oom can be a rescuer. I think
> I just argued against my own question.

Yes you just did :-)

From what I understand from this LKML thread [1] fast swap on NVMe is only part 
of the issue (or adds to the issue). The kernel really really tries hard not to 
OOM kill anything and keep the system going. And this overcommitment is where 
it eventually gets unresponsive to the extend that the machine needs to be hard 
rebooted.

The LKML thread also mentions that user-space OOM handling could help.

But what about cgroups? Isn’t there a systemd utility that helps me wrap 
processes in resource constrained groups? Something along the line

$ systemd-run -p MemoryLimit=1G firefox

(Not tested.) I imagine that a well-behaved program will handle a bad malloc by 
ending itself?

BTW, this happens not only on Linux. I’m used to deal with quite big files 
during my day job and if you accidentally write some… em… very unsophisticated 
code that attempts to read the entire file into memory at once you can 
experience the same behavior on a recent macOS, too. You’re left with nothing 
else than force rebooting your machine.

[1] https://lkml.org/lkml/2019/8/4/15

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

[Igor Gnatenko]

I've dropped beignet a while ago since I was getting bugs, but upstream is
dead. Also many times, POCL performed better than beignet.

And after all, if you want to do something complicated with OpenCL, you
already have high-end AMD or latest Intel card..

However, anyone is free to unretire it.

On Sun, Aug 11, 2019, 14:57 Kevin Kofler  wrote:

> Dominik 'Rathann' Mierzejewski wrote:
> > Unfortunately the one above is for Broadwell and newer, which means
> > it doesn't work with any of my machines.
>
> Don't you love planned obsolescence? A whopping 3 CPU/IGP generations from
> https://wiki.freedesktop.org/www/Software/Beignet/#supportedtargets got
> dropped by the rewrite. :-(
>
> Will Beignet be kept in Fedora or will everyone with those 3 CPU/IGP
> generations be stuck with running POCL on the CPU (essentially defeating
> the
> purpose of OpenCL) instead?
>
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: repoquery: Modular dependency problems: nothing provides module(platform:f30)

[Igor Gnatenko]

You need to explicitly set --setopt=module_platform_id=platform:F31

I thought itvwas fixed, but probably it does not work for repoquery.

On Sun, Aug 11, 2019, 23:07 Miro Hrončok  wrote:

> I've noticed that recently, I see this with repoquery regardless of the
> query:
>
> $ repoquery --repo=rawhide ...
> Modular dependency problems:
>
>   Problem 1: conflicting requests
>- nothing provides module(platform:f30) needed by module
> exa:latest:3020190721165838:a23e773d-0.x86_64
>   Problem 2: conflicting requests
>- nothing provides module(platform:f30) needed by module
> fd-find:rolling:3020190722174030:a23e773d-0.x86_64
>   Problem 3: conflicting requests
>- nothing provides module(platform:f30) needed by module
> libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
>   Problem 4: conflicting requests
>- nothing provides module(platform:f30) needed by module
> ripgrep:latest:3020190722062006:a23e773d-0.x86_64
>
>
> --
> 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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Tuomo Soini]

On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok  wrote:

> %python3_other_pkgversion 34
> 
> I believe the easiest fix is to define that directly in
> epel-rpm-macros:
> 
> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5

Correct. That fixes this issue but not the huge issue we have now.

> Thanks for the report!

I agree. But we have much bigger problem with epel python naming.

python3_other is now defined to 3 in rhel7.7.

Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.

Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.

We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-.

Let's list some history, please notify if I forgot something important.

python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.

When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion

rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.

Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36- to python3- so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-.

There are two possibilities how to handle this:

Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.

This would cause pain in every occasion when there is new python3
package added to rhel7 because rhel7 uses different naming. That
would mean we would need to manually patch dependencies on packages in
rhel7 because we don't have any guarantee that rhel packagers remember
epel when doing rhel packages. So we need to manually change
dependencies to rhel packages to be python3, not
python%{python3_pkgversion}.

My suggestion for this is to do big python3 rebuild again in epel7,
this time with python3_pkgversion from rhel7.7 and move clearly to
rhel7.7 python3 naming and obsolete pythn34 now, people have already
been notified that python34 is end of the life and not supported by
upstream.

Add epel specific python_provide macro which for python3-modname does:
normal provides as it did before.

Provides: python3- = %{version}-%{release}
Obsoletes: python36- < %{version}-%{release}
Obsoletes: python34- < %{version}-%{release}

Remove python3_other from epel7.

Only downside from this is that python3-modname source rpm naming won't
work any more because rpm doesn't allow python3-modname naming in
sub-package. My suggestion for that is to name these epel only
source packages with python3-epel-modname or python3-modname-epel
naming so that they can generate python3-modname.


-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org