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

[updates]

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

ncdu-1.14.1-1.el6

Details about builds:



 ncdu-1.14.1-1.el6 (FEDORA-EPEL-2019-b2627c8def)
 Text-based disk usage viewer

Update Information:

Update to new version 1.14.1:  * Fix `--exclude-caches` * Improve handling of
out-of-memory situations

ChangeLog:

* Sun Aug 11 2019 Richard Fearn  - 1.14.1-1
- Update to new upstream version 1.14.1


___
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] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 362  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 138  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294   
cinnamon-3.6.7-5.el7
 104  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
 101  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12067fc897   
dosbox-0.74.3-2.el7
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-487a6fb279   
knot-2.8.2-1.el7 knot-resolver-4.1.0-1.el7
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aabd063c30   
squirrelmail-1.4.23-1.el7.20190710
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-44d26d23ea   
upx-3.95-4.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b6948289f0   
pdns-4.1.11-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ad7b11b384   
igraph-0.7.1-12.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-643d621522   
jhead-3.03-4.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4e6da66b9f   
python-django-1.11.23-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-204f810692   
clamav-0.101.3-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5f75a76f4e   
kf5-kconfig-5.52.0-1.el7.1
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aa84623a4e   
libmspack-0.5-0.0.7.alpha.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-26e64681f6   
hostapd-2.9-1.el7


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

ncdu-1.14.1-1.el7
zabbix40-4.0.11-1.el7

Details about builds:



 ncdu-1.14.1-1.el7 (FEDORA-EPEL-2019-125a40b822)
 Text-based disk usage viewer

Update Information:

Update to new version 1.14.1:  * Fix `--exclude-caches` * Improve handling of
out-of-memory situations

ChangeLog:

* Sun Aug 11 2019 Richard Fearn  - 1.14.1-1
- Update to new upstream version 1.14.1




 zabbix40-4.0.11-1.el7 (FEDORA-EPEL-2019-bf21598a7d)
 Open-source monitoring solution for your IT infrastructure

Update Information:

Release notes: https://www.zabbix.com/rn/rn4.0.11

ChangeLog:

* Sat Aug 10 2019 Morten Stevens  - 4.0.11-1
- Update to 4.0.11


___
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-20190811.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 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: 10/143 (x86_64), 1/2 (arm)

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

ID: 430756  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430756
ID: 430757  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/430757
ID: 430783  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/430783
ID: 430785  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/430785
ID: 430786  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/430786
ID: 430847  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/430847
ID: 430855  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/430855
ID: 430858  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/430858
ID: 430859  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/430859
ID: 430861  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/430861
ID: 430862  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/430862

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

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

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

Passed openQA tests: 116/143 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20190808.n.0):

ID: 430732  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/430732
ID: 430781  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/430781

Skipped gating openQA tests: 4/143 (x86_64)

Old skipped gating tests (same test skipped in Fedora-Rawhide-20190808.n.0):

ID: 430761  Test: x86_64 Workstation-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/430761
ID: 430762  Test: x86_64 Workstation-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/430762
ID: 430764  Test: x86_64 Workstation-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/430764
ID: 430765  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/430765

Skipped non-gating openQA tests: 13 of 145

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 173 MiB to 197 MiB
Previous test data: https://openqa.fedoraproject.org/tests/430132#downloads
Current test data: https://openqa.fedoraproject.org/tests/430721#downloads

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 173 MiB to 196 MiB
Previous test data: https://openqa.fedoraproject.org/tests/430133#downloads
Current test data: https://openqa.fedoraproject.org/tests/430722#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
2 packages(s) added since previous compose: libmaxminddb, libtextstyle
2 packages(s) removed since previous compose: GeoIP, GeoIP-GeoLite-data
Previous test data: https://openqa.fedoraproject.org/tests/430134#downloads
Current test data: https://openqa.fedoraproject.org/tests/430723#downloads

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

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
Used mem changed from 133 MiB to 153 MiB
Previous test data: https://openqa.fedoraproject.org/tests/430165#downloads
Current test data: https://openqa.fedoraproject.org/tests/430754#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Used mem changed from 132 MiB to 152 MiB
Previous test data: 

repoquery: Modular dependency problems: nothing provides module(platform:f30)

[Miro Hrončok]

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

Re: Better interactivity in low-memory situations

[Chris Murphy]

On Sun, Aug 11, 2019 at 1:02 PM Jan Kratochvil
 wrote:
>
> On Sun, 11 Aug 2019 20:54:28 +0200, Chris Murphy wrote:
> > and likely experiences data loss and possibly even file system
> > corruption as a direct consequence of having to force power off on the
> > machine because for all practical purposes normal control has been
> > lost.
>
> Not really, this is what journaling filesystem is there for.

Successful journal replay obviates the need for fsck, it has nothing
to do with avoiding corruption. And in any case, anything the user is
working on that isn't already saved and committed to stable media,
isn't going to survive the poweroff.

> But then there still can be an application-level data corruptions if an
> application does not handle its sudden termination properly.
> Which should be rare but IIRC I did see it for example with Firefox.

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.


-- 
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: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 11. 08. 19 20:41, Tuomo Soini wrote:

On Fri, 9 Aug 2019 17:39:45 +0200
Miro Hrončok  wrote:


On 09. 08. 19 17:38, Stephen John Smoogen wrote:



I tested all three and gave karma.


Thanks. I'll wait for the push and retire the old packages.

I hope everything will work as expected.



I noticed a issue, python-pip-epel can't be build on up to date 7.7
system because python3_other srpm related macros are not provided by
any package. I guess python-epel-rpm-macros package should provide
python3-other-srpm-macros for python34 related bits. And these two new
packages python3-other-srpm-macros and python3-other-rpm-macros should
be added as dependency to epel-rpm-macros.


There is python-epel-rpm-macros source package in EPEL now.
It builds the python3-other-rpm-macros package.

python34-devel requires python3-other-rpm-macros.

epel-rpm-macros requires python-srpm-macros.

python-srpm-macros form RHEL 7.7+ indeed don't have this bit:

%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

Thanks for the report!

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

[Jan Kratochvil]

On Sun, 11 Aug 2019 20:54:28 +0200, Chris Murphy wrote:
> and likely experiences data loss and possibly even file system
> corruption as a direct consequence of having to force power off on the
> machine because for all practical purposes normal control has been
> lost.

Not really, this is what journaling filesystem is there for.

But then there still can be an application-level data corruptions if an
application does not handle its sudden termination properly.
Which should be rare but IIRC I did see it for example with Firefox.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Sun, Aug 11, 2019 at 10:36 AM  wrote:
>
> On Sun, Aug 11, 2019 at 10:50 AM, Chris Murphy
>  wrote:
> > Let's take another argument. If the user manually specifies 'ninja -j
> > 64' on this same system, is that sabotage? I'd say it is. And
> > therefore why isn't it sabotage that the ninja default computes N jobs
> > as nrcpus + 2?  And also doesn't take available memory into account
> > when deciding what resources to demand? I can build linux all day long
> > on this system with its defaults and never run into a concurrent
> > usability problem.
> >
> > There does seem to be a dual responsibility, somehow, between the
> > operating system and the application, to make sure sane requests are
> > made and honored.
>
> This seems like a distraction from the real goal here, which is to
> ensure Fedora remains responsive under heavy memory pressure, and to
> ensure unprivileged processes cannot take down the system by allocating
> large amounts of memory. Fixing ninja and make to dynamically scale the
> number of parallel build processes based on memory pressure would be
> wonderful, but it's not going to solve the underlying issue here, which
> is that random user processes should never be able to hang the system.

That's fair.

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

[Chris Murphy]

On Sun, Aug 11, 2019 at 11:21 AM Jan Kratochvil
 wrote:
>
> On Sun, 11 Aug 2019 17:50:17 +0200, Chris Murphy wrote:
> > I don't follow. You're saying RelWithDebInfo is never suitable for a
> > local build?
>
> Most of the time. What is your use case for it?

My use case is testing the responsiveness of Fedora Workstation under
CPU and memory pressure, as experienced by an ordinary user.


> > In file included from Source/JavaScriptCore/config.h:32,
> >  from 
> > Source/JavaScriptCore/llint/LLIntSettingsExtractor.cpp:26:
> > Source/JavaScriptCore/runtime/JSExportMacros.h:32:10: fatal error: 
> > wtf/ExportMacros.h: No such file or directory
>
> You are reinventing the wheel Fedora packager has already done for this
> package.

That's out of scope.

I said from the outset this is an example. The central topic is that
an unprivileged program is able to ask for resources that do not
exist, and the operating system tries and fails to supply those
resources, resulting not only in task failure, but the entire system
is lost. In this example the user is doing other things concurrently
and likely experiences data loss and possibly even file system
corruption as a direct consequence of having to force power off on the
machine because for all practical purposes normal control has been
lost.


> > Let's take another argument. If the user manually specifies 'ninja -j
> > 64' on this same system, is that sabotage?
>
> For untrusted users Linux has given up for that, it is too big can of worms.
> Use virtual machine (KVM) with specified resources (memory size).  Nowadays it
> should be also possible with less overhead by using Docker containers.
>
> If you mean some local builds of your own causing runaway then
> (1) Turn off swap as RAM is cheap enough today.
> If something really runs out of the RAM it gets killed by kernel OOM.
> (2) Have the swap on NVMe, it from my experience does not kill the machine.
> (3) Use some reasonable ulimits in your ~/.bash_profile.
> (4) When the machine is really unresponsible login there from a different box
> and kill the culprits. From my own experience the machine is still able to
> accept new SSH connection, despite a bit slowly.
> But yes, I agree this problem has AFAIK no perfect solution.


I don't think it's acceptable in 2019 that an unpriviledged task takes
out the entire operating system. As I mention in the very first post,
remote ssh was not responsive for 30 minutes, at which point I gave up
and forced power off. It's a bit of a trap though to suggest the user
needs the ability and skill to remote ssh to kill off runaway
programs, I refuse that premise.

It's completely sane for an ordinary user to consider that control of
the system has been lost immediately upon experiencing a frozen mouse
arrow.



-- 
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: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Tuomo Soini]

On Fri, 9 Aug 2019 17:39:45 +0200
Miro Hrončok  wrote:

> On 09. 08. 19 17:38, Stephen John Smoogen wrote:
> > 
> > 
> > I tested all three and gave karma.  
> 
> Thanks. I'll wait for the push and retire the old packages.
> 
> I hope everything will work as expected.
> 

I noticed a issue, python-pip-epel can't be build on up to date 7.7
system because python3_other srpm related macros are not provided by
any package. I guess python-epel-rpm-macros package should provide
python3-other-srpm-macros for python34 related bits. And these two new
packages python3-other-srpm-macros and python3-other-rpm-macros should
be added as dependency to epel-rpm-macros.

Issue caused by missing packages is %python3_other_pkgversion is unset,
in mock log:

DEBUG util.py:587:  Error: No Package found for
python%{python3_other_pkgversion}-devel
DEBUG util.py:587:  Error: No
Package found for python%{python3_other_pkgversion}-setuptools

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

Re: Better interactivity in low-memory situations

[Jan Kratochvil]

On Sun, 11 Aug 2019 17:50:17 +0200, Chris Murphy wrote:
> I don't follow. You're saying RelWithDebInfo is never suitable for a
> local build?

Most of the time. What is your use case for it?


> isn't relevant to getting a successful build.

With powerful enough machine everything is possible.  Just be aware
RelWithDebInfo is the most resource demanding option compared to Release and
Debug and at the same time it is the least useful one for local builds.


> In file included from Source/JavaScriptCore/config.h:32,
>  from 
> Source/JavaScriptCore/llint/LLIntSettingsExtractor.cpp:26:
> Source/JavaScriptCore/runtime/JSExportMacros.h:32:10: fatal error: 
> wtf/ExportMacros.h: No such file or directory

You are reinventing the wheel Fedora packager has already done for this
package.  I guess you are missing some dependency.  If you have a problem
stick to the proven build (unless it is temporarily FTBFS which this package
is not now).  I think Fedora recommends mock for such rebuild but I find mock
inconvenient for local development so I use (I have some scripts for that):
dnf download --source webkit2gtk3
mkdir webkit2gtk3-2.24.3-1.fc30.src
cd webkit2gtk3-2.24.3-1.fc30.src
rpm2cpio ../webkit2gtk3-2.24.3-1.fc30.src.rpm|cpio -id
function rpmbuildlocal { time MAKEFLAGS= rpmbuild --define "_topdir 
$PWD" --define "_builddir $PWD" --define "_rpmdir $PWD" --define "_sourcedir 
$PWD" --define "_specdir $PWD" --define "_srcrpmdir $PWD" --define 
"_build_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm" "$@"; rmdir 
&>/dev/null BUILDROOT; }
# Is the .src.rpm rebuild still needed?  
https://bugzilla.redhat.com/show_bug.cgi?id=1210276
rpmbuildlocal -bs *.spec
sudo dnf builddep webkit2gtk3-2.24.3-1.fc30.src.rpm
rm webkit2gtk3-2.24.3-1.fc30.src.rpm
rpmbuildlocal -bc webkit2gtk3.spec 2>&1|tee log
# or -bb or what do you want.
It has built fine for me here now.


> Let's take another argument. If the user manually specifies 'ninja -j
> 64' on this same system, is that sabotage?

For untrusted users Linux has given up for that, it is too big can of worms.
Use virtual machine (KVM) with specified resources (memory size).  Nowadays it
should be also possible with less overhead by using Docker containers.

If you mean some local builds of your own causing runaway then
(1) Turn off swap as RAM is cheap enough today.
If something really runs out of the RAM it gets killed by kernel OOM.
(2) Have the swap on NVMe, it from my experience does not kill the machine.
(3) Use some reasonable ulimits in your ~/.bash_profile.
(4) When the machine is really unresponsible login there from a different box
and kill the culprits. From my own experience the machine is still able to
accept new SSH connection, despite a bit slowly.
But yes, I agree this problem has AFAIK no perfect solution.


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

[Dusty Mabe]

On 8/9/19 8:56 PM, Adam Williamson wrote:
> Hey folks! I'm starting a new thread for this to trim the recipient
> list a bit and include devel@ and coreos@.

Hey Adam!

> 
> The Story So Far: there is a Fedora release criterion which requires
> Fedora to boot on Xen:
> 
> "The release must boot successfully as Xen DomU with releases providing
> a functional, supported Xen Dom0 and widely used cloud providers
> utilizing Xen."
> 
> We (QA group) had a discussion about removing this criterion entirely.
> That has now morphed into the idea that we should tweak it to be
> focused exclusively on the "widely used cloud providers utilizing
> Xen"...by which we mean EC2. At the time this criterion was invented,
> all EC2 instance types used Xen; now, some still use Xen, and some use
> KVM.
> 
> So it seems like this would also be a good opportunity to revisit and
> nail down more specifically exactly what our cloud requirements are.
> bcotton suggested  that we require two sample instance types to be
> tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas
> Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed
> like it might be worthwhile - he's promised to get back to me).
> 
> So, for now, let me propose this as a trial balloon: we rewrite the
> above criterion to say:
> 
> "Release-blocking cloud disk images must be published to Amazon EC2 as
> AMIs, and these must boot successfully and meet other relevant release
> criteria on c5.large and t3.large instance types."

Sounds good to me if we trim it down to a few instance types that we think
will cover Xen and KVM based booting in EC2. For Fedora CoreOS we'll be doing
some automated testing in EC2. I don't know if we have a certain set of instance
types we'll be using for that, but the information that Matt provided should
help us decide.

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

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

[Kevin Fenzi]

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




signature.asc
Description: OpenPGP digital signature
___
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: Better interactivity in low-memory situations

[mcatanzaro]

On Sun, Aug 11, 2019 at 10:50 AM, Chris Murphy 
 wrote:

Let's take another argument. If the user manually specifies 'ninja -j
64' on this same system, is that sabotage? I'd say it is. And
therefore why isn't it sabotage that the ninja default computes N jobs
as nrcpus + 2?  And also doesn't take available memory into account
when deciding what resources to demand? I can build linux all day long
on this system with its defaults and never run into a concurrent
usability problem.

There does seem to be a dual responsibility, somehow, between the
operating system and the application, to make sure sane requests are
made and honored.


This seems like a distraction from the real goal here, which is to 
ensure Fedora remains responsive under heavy memory pressure, and to 
ensure unprivileged processes cannot take down the system by allocating 
large amounts of memory. Fixing ninja and make to dynamically scale the 
number of parallel build processes based on memory pressure would be 
wonderful, but it's not going to solve the underlying issue here, which 
is that random user processes should never be able to hang the system.


Michael

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

Re: Better interactivity in low-memory situations

[Chris Murphy]

On Sat, Aug 10, 2019 at 3:07 AM Jan Kratochvil
 wrote:
>
> On Fri, 09 Aug 2019 23:50:43 +0200, Chris Murphy wrote:
> > $ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
>
> RelWithDebInfo is -O2 -g build.  That is not suitable for debugging, for
> debugging you should use -DCMAKE_BUILD_TYPE=Debug (that is -g).
> RelWithDebInfo is useful for final rpm packages but those are build in Koji.

I don't follow. You're saying RelWithDebInfo is never suitable for a
local build?

I'm not convinced that matters, because what the user-developer is
trying to accomplish post-build isn't relevant to getting a successful
build. And also, this is just one example of how apparently easy it is
to take down a system with an unprivileged task, per the various
discussions I've had with members of the Workstation WG.

Anyway, the build fails for a different reason when I use Debug
instead of RelWithDebInfo so I can't test it.

In file included from Source/JavaScriptCore/config.h:32,
 from Source/JavaScriptCore/llint/LLIntSettingsExtractor.cpp:26:
Source/JavaScriptCore/runtime/JSExportMacros.h:32:10: fatal error:
wtf/ExportMacros.h: No such file or directory
   32 | #include 
  |  ^~~~
compilation terminated.
[1131/2911] Building CXX object Sourc...er/preprocessor/DiagnosticsBase.cpp.o
ninja: build stopped: subcommand failed.



> Debug build will have smaller debug info so the problem may go away.
>
> If it does not go away then tune the parallelism. Low -j makes the build
> needlessly slow during compilation phase while high -j (up to about #cpus
> + 2 or so) will make the final linking phase with debug info to run out of
> memory. This is why LLVM has separate "-j" for the linking phase but that is
> implemented only in LLVM CMakeLists.txt files:
> https://llvm.org/docs/CMake.html
> LLVM_PARALLEL_LINK_JOBS
> So that you leave the default -j high but set LLVM_PARALLEL_LINK_JOBS to 1 or 
> 2.
>
> Other options for faster build times are also LLVM specific:
> -DLLVM_USE_LINKER=gold (maybe also lld now?)
>  - as ld.gold or ld.lld are faster than ld.bfd
> -DLLVM_USE_SPLIT_DWARF=ON
>  - Linking phase no longer deals with the huge debug info
>
> Which should be applicable for other projects by something like (untested!):
> -DCMAKE_C_FLAGS="-gsplit-dwarf"
> -DCMAKE_CXX_FLAGS="-gsplit-dwarf"
> -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index"
> -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index"
>
> (That gdb-index is useful if you are really going to debug it using GDB as
> I expect you are going to do when you want RelWithDebInfo and not Release; but
> then I would recommend Debug in such case anyway as debugging optimized code
> is very difficult.)
>
>
> > is there a practical way right now of enforcing CPU
> > and memory limits on unprivileged applications?
>
> $ help ulimit
>   -mthe maximum resident set size
>   -uthe maximum number of user processes
>   -vthe size of virtual memory
>
> One can also run it with 'nice -n19', 'ionice -c3'
> and/or "cgclassify -g '*':hammock" (config attached).

Thanks. I'll have to defer to others about how to incorporate this so
the default build is more intelligently taking actual resources into
account. My strong bias is that the user-developer can't be burdened
with knowing esoteric things. The defaults should just work.

Let's take another argument. If the user manually specifies 'ninja -j
64' on this same system, is that sabotage? I'd say it is. And
therefore why isn't it sabotage that the ninja default computes N jobs
as nrcpus + 2?  And also doesn't take available memory into account
when deciding what resources to demand? I can build linux all day long
on this system with its defaults and never run into a concurrent
usability problem.

There does seem to be a dual responsibility, somehow, between the
operating system and the application, to make sure sane requests are
made and honored.

> But after all I recommend just more memory, it is cheap nowadays and I find
> 64GB just about the right size.

That's an optimization. It can't be used as an excuse for an
unprivileged task taking down a system.


-- 
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: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Sérgio Basto]

If it helps Copr (and mock) use centos 7 [1]

[1]
https://github.com/rpm-software-management/mock/blob/master/mock-core-configs/etc/mock/epel-7-x86_64.cfg


On Sun, 2019-08-11 at 10:44 +0200, 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.)
> -- 
> 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
-- 
Sérgio M. B.
___
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.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Stephen John Smoogen]

On Sun, 11 Aug 2019 at 03:32, Miro Hrončok  wrote:

> On 11. 08. 19 2:58, Stephen John Smoogen wrote:
> > On Sat, 10 Aug 2019 at 17:12, Miro Hrončok  > > wrote:
> >
> > On 10. 08. 19 21:23, Miro Hrončok wrote:
> >  > While I really tried to do my best, it seems that I broke CentOS
> by retiring
> >  > python36. Should it be unretired? Or is it reasonable to say:
> Please wait
> > for
> >  > CentOS 7.7?
> >  >
> >  > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
> >
> > If any EPEL expert thinks the package should be unretired for now,
> please do so.
> >
> >
> > Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is
> out in
> > the CR repo. My apologies for not thinking of this when you were
> mentioning
> > things yesterday. I do not have the rights to unretire things so will
> need to
> > get in touch with Mohan/Kevin/Mizdebsk on what to do.
>
> https://pagure.io/releng/issue/8607
>
>
Thank you. I just want to say that you are not in any way responsible for
the problems. I did not clearly think out what would happen when I gave you
the go-ahead last week. I should have seen this and said we need to wait.



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


-- 
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: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Igor Gnatenko]

I think it uses koji build repo. So same as epel buildroot does.

On Sun, Aug 11, 2019, 10:47 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.)
> --
> 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 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

packages stuck in f31-updates-testing-pending

[Mukundan Ragavan]

Can someone from releng re-tag these packages and push them to stable?

https://koji.fedoraproject.org/koji/buildinfo?buildID=1344119
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344089
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344114
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344121
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344125
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344127
https://koji.fedoraproject.org/koji/buildinfo?buildID=1344130

They are stuck in f31-updates-testing-pending.

Thanks.



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

[Bug 1739331] rebuilding src.rpm failed due to missing website

[bugzilla]

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



--- Comment #2 from Emmanuel Seyman  ---
Looking furthur into this, I realized the test is skipped if the host cannot
reach www.perl.com. I patched the test to check diberri.dyndns.org instead.

Sharuzzaman, can you test the .src.rpm at
https://koji.fedoraproject.org/koji/buildinfo?buildID=1349556 and report back
if it fixes your problem ?

-- 
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 1738791] Upgrade perl-TheSchwartz to 1.13

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

   Fixed In Version||perl-TheSchwartz-1.13-1.fc3
   ||1



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1349544

-- 
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: OpenCL on Intel processors

[Kevin Kofler]

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

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

[Kevin Kofler]

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

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

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.

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

We do not normally require this level of bureaucracy for things depending on 
a compatibility package, and I think this is a very dangerous precedent to 
set.

> When a packager doesn't want to maintain it, that's good enough reason.
> 
> You have a right to orphan a package, why you should not have the right to
> orphan a half of your package, when he other half works without it?

When it takes no extra effort to maintain the Python 2 module because the 
current upstream still supports it just fine, what is the rationale for 
dropping it, other than "I don't like Python 2 anymore"? As I wrote above, 
if upstream stops supporting Python 2, that is a valid reason. If nothing in 
Fedora (nor in popular third-party repositories) requires the Python 2 parts 
anymore, that is a reason too.

> Requiring others to maintain the packages your packages (or you) need just
> because they maintained it until now is not very friendly. Of course, you
> can ask nicely, but you cannot say this is their duty.

All I am asking for is to not actively drop python2-* subpackages without a 
good reason to do so. (It actually requires more effort to go and delete the 
specfile portions than to just keep them. ;-) )

> Arguably, maintaining dead software requires more effort than maintaining
> live one. But that kinda depends on the particular package.

My experience maintaining the Qt 3 stack is quite the opposite. Those 
packages require a lot less effort to keep going than, say, qt5-qtwebengine.

> I don't need people to maintain **all** Python 2 packages, just mine. But
> possibly other maintainers also don't want to maintain theirs. As the
> snowball rolls, you need somebody to maintain **almost all** of them.

My idea is that people depending on specific python2-* modules should 
maintain them, as usual when a library gets orphaned. But we cannot expect 
one person to maintain all of them. Neither you, nor me, nor 

Re: OpenCL on Intel processors

[Dominik 'Rathann' Mierzejewski]

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?

> 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
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Please sweep bodhi updates to testing in a timely manner

[Kevin Kofler]

Brian (bex) Exelbierd wrote:
> I didn't see your comment until after I opened
> https://pagure.io/fesco/issue/2207 - would love your feedback on that.

https://pagure.io/fesco/issue/2207#comment-589009

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

Amateur radio dnf group in comps.xml

[Geoffrey Marr]

Devel team,

I am interested in creating a package group specific for Fedora amateur/ham
radio users. I know people in my local area who have interest in such a
group, and surely others out there, that could bring more ham radio users
to Fedora, if the ability to install all the packages needed for a ham
radio setup was easier than installing all packages separately. I would
maintain the group of packages in comps.xml and remove/modify it should a
discrepancy arise. How should I proceed?

I have been working on Fedora since May of 2016 as a member of Fedora QA
and have modified comps.xml before adding/fixing some broken packages in
the 'Electronics Lab' group.

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

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

[Nico Kadel-Garcia]

On Sun, Aug 11, 2019 at 4:33 AM Miro Hrončok  wrote:

> > I also think that there ought to be more cooperation from the maintainers of
> > individual python2-* modules. The approved Fedora 31 Change makes it way too
> > easy for maintainers to just drop Python 2 support for no reason.
>
> When a packager doesn't want to maintain it, that's good enough reason.
>
> You have a right to orphan a package, why you should not have the right to
> orphan a half of your package, when he other half works without it?
>
> > If
> > upstream dropped Python 2 support from the current version and so an old
> > version has to be packaged specifically for Python 2, that is one good
> > reason to require somebody else to pick up maintenance, but as it stands, no
> > such reason is required and Fedora maintainers can arbitrarily drop Python 2
> > support from their Python modules even if upstream still supports it. This
> > is just pointless and unhelpful.
>
> Requiring others to maintain the packages your packages (or you) need just
> because they maintained it until now is not very friendly. Of course, you can
> ask nicely, but you cannot say this is their duty.

It's not merely difficult, it's burning time better spent porting the
python2 packages to python3

> > We can try to find people to pick up python2 and a bunch of python2-*
> > modules, but expecting the python2 maintainer(s) to sign up for maintaining
> > each and every python2-* module is unreasonable and unrealistic. Even if
> > several of them will also be dead upstream (at least the version that works
> > with Python 2) and thus require very little maintenance effort.
>
> Arguably, maintaining dead software requires more effort than maintaining live
> one. But that kinda depends on the particular package.
>
> I don't need people to maintain **all** Python 2 packages, just mine. But
> possibly other maintainers also don't want to maintain theirs. As the snowball
> rolls, you need somebody to maintain **almost all** of them.

I've run into this snowball, quite recently, backporting awscli to
RHEL 6. I finally had to throw in the towel for Samba and give up on
RHEL 6 for current Samba releases with the domain controller enabled.

> >> Simply replacing the "python2" line iwth "python27" is not a difficent
> >> edit in most source code.
> > But it is still a completely unnecessary edit.
>
> Yes.

It's proven helpful with the python3 enabled packages to use
"%{_python3}" and "%{_python2}" consistently, especially when
splitting packages for versions backported to RHEL or publiswhed in
EPEL. Red Hat is due to publish a python3 built right into RHEL 7.7,
so it should be possible to discard python2 more generally for folks
like me that do backports.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Please sweep bodhi updates to testing in a timely manner

[Brian (bex) Exelbierd]

Kevin,

I didn't see your comment until after I opened
https://pagure.io/fesco/issue/2207 - would love your feedback on that.

regards,

bex

On Sun, Aug 11, 2019 at 1:01 PM Kevin Kofler  wrote:
>
> Kevin Fenzi wrote:
> > I'm not sure what else you would like me to do here...
>
> How about changing the Bodhi rules to allow stable pushes 7 days after
> update submission rather than 7 days after the push to testing actually
> happens? That would make things much more predictable for maintainers and
> not hold them accountable for delays in infrastructure that are none of
> their fault. (And it would actually give an incentive to rel-eng to get
> testing pushes out in a timely manner, since any delay would chew on the
> testing time. ;-) )
>
> 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



-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Please sweep bodhi updates to testing in a timely manner

[Kevin Kofler]

Kevin Fenzi wrote:
> I'm not sure what else you would like me to do here...

How about changing the Bodhi rules to allow stable pushes 7 days after 
update submission rather than 7 days after the push to testing actually 
happens? That would make things much more predictable for maintainers and 
not hold them accountable for delays in infrastructure that are none of 
their fault. (And it would actually give an incentive to rel-eng to get 
testing pushes out in a timely manner, since any delay would chew on the 
testing time. ;-) )

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

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Miro Hrončok]

On 10. 08. 19 21:23, Miro Hrončok wrote:
While I really tried to do my best, it seems that I broke CentOS by retiring 
python36. Should it be unretired? Or is it reasonable to say: Please wait for 
CentOS 7.7?


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

Currently I cannot even init an epel7 mock:

Error:
 Problem: conflicting requests
  - nothing provides python-rpm-macros needed by epel-rpm-macros-7-20.noarch
  - nothing provides python-srpm-macros needed by epel-rpm-macros-7-20.noarch
  - nothing provides python2-rpm-macros needed by epel-rpm-macros-7-20.noarch

--
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: Package removal for FTBFS: Add automatic orphaning?

[Kevin Kofler]

Miro Hrončok wrote:
> I hear that this was not properly communicated. I am already trying to
> figure out how to make that better -see my e-mail that started this thread
> or https://pagure.io/releng/issue/8599

IMHO, proper communication would have been to at least add another reminder 
comment with a final warning to each still open FTBFS bug 1 or 2 weeks 
before actually retiring the package.

The surprise came because months-old bugs that maintainers had long 
forgotten of suddenly got acted upon with no further warning.

Luckily, in my case, the FTBFS for my KDE 3 packages actually resolved 
itself (the output of the "file" tool on aarch64 was somehow changed back to 
something the old libtool understands, so the workaround that I had already 
applied to a handful packages and was intending to apply to the rest (had I 
actually been warned before the mass retirement started) was no longer 
needed) and so the bugs were closed as WORKSFORME and the packages not 
retired. But I could easily had been hit too.

The 4 F31 FTBFS bugs that I'm CCed on are all already fixed now, by the way. 
(Though qtwebkit will be screwed again when your draconian python2 removal 
hits, but that is for another thread.)

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

Re: [Bug 1675390] mingw-wine-gecko: FTBFS in Fedora rawhide/f30

[Kevin Kofler]

Zbigniew Jędrzejewski-Szmek wrote:
> Right. So it sounds like the package could be made to "build" very easily.

By shipping the upstream blob as is? That would not really be compliant to 
Fedora packaging guidelines, would it? At least I would hope it would not 
be! (This is not really firmware, WINE loads it into the regular userspace.)

The problem is that the code no longer compiles with the current cross-MinGW 
toolchain, and upstream has not done anything to fix that because they still 
ship their old binary.

> The fact that maintainers could not do this since 2016 is IMO a good
> reason to retire the package. We need to drop packages which FTBFS, FTI,
> or have multiple security bugs open. Each package that fails at the mass
> rebuild sucks up time of other maintainers who will try to figure out what
> it doesn't build and fix it. Every package that FTI sucks up time of users
> who try to install the package. Every package that has CVEs without any
> response means that users (reasonably) have doubts about the overall
> security of Fedora, and also obscures other issues which might be really
> important. Over the years Fedora has collected a lot of "cruft". We need
> to do cleanup sweeps because otherwise the distro becomes a garbage site
> where it's impossible to do any kind of improvement at scale.

Retiring packages leaves the user with no software at all to fulfill their 
needs. Users want the best software available to perform their tasks. That 
software may be in a less than ideal state, it may even be insecure, but 
that can still be better than not having the software available at all. If 
the software does not install at all (or installs but does not run), that 
obviously needs fixing, but if it just FTBFS and/or has some CVEs that are 
not critical in the user's environment (e.g., mingw-wine-gecko is more 
likely to be used to view either some local HTML files in Windows programs 
or parts of a specific ISV's website than to browse the entire untrusted 
Internet), having the software available is often better than having nothing 
at all.

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

Re: Removal of Python 2 from the Xfce spin

[Miro Hrončok]

On 09. 01. 19 9:34, Miro Hrončok wrote:
Hi, we've successfully removed Python 2 from default Workstation installation 
years ago, today I'd like to see if we could do it in Xfce Spin as well.


Current rawhide Xfce spin is Python 2 free \o/

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

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

[Miro Hrončok]

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?


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

Re: [Bug 1675390] mingw-wine-gecko: FTBFS in Fedora rawhide/f30

[Zbigniew Jędrzejewski-Szmek]

On Sun, Aug 11, 2019 at 01:12:20AM +0200, Kevin Kofler wrote:
> Miro Hrončok wrote:
> > What would you want to do instead? Keep shipping th Fedora 26 package
> > forever?
> 
> Since this is actually an MSI blob that is a drop-in replacement for the MSI 
> blob from WINE upstream (where the version number expected by WINE is 
> hardcoded and has not changed for years) and that contains PE binaries that 
> are loaded by WINE, there is no reason why the F26 package would not just 
> work. The PE binaries are covered by the W32/W64 binary compatibility 
> guarantees, and the upstream blob being replaced has not changed for years.

Right. So it sounds like the package could be made to "build" very easily.
The fact that maintainers could not do this since 2016 is IMO a good reason
to retire the package. We need to drop packages which FTBFS, FTI, or have
multiple security bugs open. Each package that fails at the mass rebuild sucks
up time of other maintainers who will try to figure out what it doesn't build
and fix it. Every package that FTI sucks up time of users who try to install
the package. Every package that has CVEs without any response means that users
(reasonably) have doubts about the overall security of Fedora, and also obscures
other issues which might be really important. Over the years Fedora has 
collected
a lot of "cruft". We need to do cleanup sweeps because otherwise the distro
becomes a garbage site where it's impossible to do any kind of improvement at 
scale.

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

Re: Fedora 31 release-blocking deliverables

[Zbigniew Jędrzejewski-Szmek]

On Wed, Aug 07, 2019 at 07:46:06AM -0700, Adam Williamson wrote:
> Listing some-but-not-all non-blocking deliverables doesn't make any
> sense at all.

+1. A full list is very useful.

What about https://fedoraproject.org/wiki/Changes/AArch64_Xfce_Desktop_image?
I assume it's non-blocking, but it'd be nice to see it included with a "no" to
be sure that it wasn't just forgotten.

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

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Miro Hrončok]

On 11. 08. 19 9:59, Mohan Boddu wrote:
I unretired the packages and tagged the old builds, I think that should fix the 
buildroot and got a testing build working.



Thanks, now.

Assuming Koji sees RHEL 7.7, can we somehow:

 - keep the packages in the repos
 - but make Koji prefer the RHEL ones (they have higher EVR)?

--
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] Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Miro Hrončok]

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

[Miro Hrončok]

On 11. 08. 19 3:45, Kevin Kofler wrote:

Nico Kadel-Garcia wrote:

Maintaining python 2 requires maintaining a*lot*  of infrastructure.

What kind of infrastructure do you need to maintain a package that is (will
be) no longer updated upstream? This takes almost no work. The only thing to
do is to backport some security fixes from Python 3, and occasionally to fix
FTBFS bugs.



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



Now if your concern is maintaining all the python2-* packages, then there
ought to be some middle ground between maintaining all of them including
ones that are not used by anything in Fedora anymore, and just dropping all
of them (with or without the planned exception process, whose usefulness
depends entirely on how willing FESCo will be to approve the requests).
Maybe the set of python2-* modules in EL7 or EL8, with or without EPEL,
minus the ones already retired from Fedora by now, would be a reasonable
starting point?


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

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


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


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



I also think that there ought to be more cooperation from the maintainers of
individual python2-* modules. The approved Fedora 31 Change makes it way too
easy for maintainers to just drop Python 2 support for no reason.


When a packager doesn't want to maintain it, that's good enough reason.

You have a right to orphan a package, why you should not have the right to 
orphan a half of your package, when he other half works without it?



If
upstream dropped Python 2 support from the current version and so an old
version has to be packaged specifically for Python 2, that is one good
reason to require somebody else to pick up maintenance, but as it stands, no
such reason is required and Fedora maintainers can arbitrarily drop Python 2
support from their Python modules even if upstream still supports it. This
is just pointless and unhelpful.


Requiring others to maintain the packages your packages (or you) need just 
because they maintained it until now is not very friendly. Of course, you can 
ask nicely, but you cannot say this is their duty.



We can try to find people to pick up python2 and a bunch of python2-*
modules, but expecting the python2 maintainer(s) to sign up for maintaining
each and every python2-* module is unreasonable and unrealistic. Even if
several of them will also be dead upstream (at least the version that works
with Python 2) and thus require very little maintenance effort.


Arguably, maintaining dead software requires more effort than maintaining live 
one. But that kinda depends on the particular package.


I don't need people to maintain **all** Python 2 packages, just mine. But 
possibly other maintainers also don't want to maintain theirs. As the snowball 
rolls, you need somebody to maintain **almost all** of them.



To support multiple pythons, python26, python28 if it ever happens,
python36 python38 when it comes out.

The whole reason for this discussion is that Python 2.8 will likely never
happen. It definitely will not happen from Python upstream. Otherwise, there
would not be all this talk about dropping Python 2 due to being unsupported
upstream.


Correct. We just want to signal that this is a compat package. We will most 
likely still provide python2 (so users can discover it more easily). Why is the 
package name so important to you?



I don't see much point in supporting Python 2.6, which is even more ancient
than Python 2.7, and 2.7 is backwards-compatible with 2.6.


The point is to support developers who use Fedora as they workstation but need 
to 

Re: Package removal for FTBFS: Add automatic orphaning?

[Miro Hrončok]

On 11. 08. 19 10:05, Miro Hrončok wrote:

My package doesn't help, I have no idea what to do now.


My package doesn't build I have no idea what to do now.

(I'll try to read my next e-mail before posting it.)
--
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: Orphaned some (mostly Python) packages

[Miro Hrončok]

On 11. 08. 19 8:14, Elliott Sales de Andrade wrote:

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



I can take this one, since my packages depend on it.


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

Re: Package removal for FTBFS: Add automatic orphaning?

[Miro Hrončok]

On 11. 08. 19 2:31, Christopher wrote:

On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok  wrote:


On 11. 08. 19 0:34, Kevin Kofler wrote:

Miro Hrončok wrote:

Obviously, we can prevent this by only orphaning packages with NEW bugz,
but that doesn't really solve anything, because lot of the retired
packages were actually ASSIGNED/POST/MODIFIED (for months).

Of course they were, to prevent you from retiring them even sooner.


If the only reason to set the status to ASSIGNED/POST/MODIFIED is to prevent
**me** from retiring the package, something is fundamentally broken.

If somebody has a legitimate reason to have a FTBFS package not retired, they
can ask for some kind of exception from Releng, not provide inaccurate 
information.



I was actually trying to work on some of mine... one of the FTBFS
(thrift) I had was actually because of an optional python2-only
component from upstream I was intending to disable once F31 was
released, if I couldn't recruit a python person to help me fix it
(because I don't know python). But, the entire package was retired
anyway it was *very* much unexpected for me, because I thought I'd
have some more time to patch it once F31 came out (the package in F30
is fine... and I don't care about rawhide... I care about the latest
version of Fedora that people are actually using).


I hear that this was not properly communicated. I am already trying to figure 
out how to make that better -see my e-mail that started this thread or 
https://pagure.io/releng/issue/8599


(Note that other people care about rawhide.)

Also: You can unretire the package if this was not expected by you, it's not 
like the retirement is endgame.



Several other packages I had were Java packages that I was still
trying to figure out the state of their BuildRequires which were in
modules. The last I read on this list was "there may be some news
about that"... and then *bam* RETIRED... at least one I know for sure
was marked ASSIGNED. At least one of these I had fixed the FTBFS once,
but then it broke again, so I left the same issue open until I could
fix that one also... but it also was retired.


If that package was actually buil after the F30 mass rebuild, it should ahve not 
been retired. Do you have the package name?



This FTBFS policy is *TOO* aggressive, and very unfriendly to casual
packagers, and at a time of significant disruption in Fedora due to
modularity. There should be some extra leniency for a few versions
while the dust from modularity settles, and it *definitely* should be
orphaned first if the maintainer isn't responding to FTBFS bugs.


Any idea how to:

 - prevent arguably broken packages to stay in the distro forever
 - stop being too aggressive to casual contributors?

We can change the policy and I am listening to ideas and arguments.

OTOH I think that we should stop breaking the distro (via modularity and other 
means) and not invent workarounds for the situation.


(Arguably, we should deal with every FTBFS bug individually, but we lack the 
resources for that. A policy is needed.)



There's so much disruption going on in Fedora right now... things are
moving too quickly for casual packagers, and it seems like a lot of it
is behind the scenes, motivated by internal interests of RedHat, and
*not* what is in the best interests of the community. It was *not* the
right time to forcibly retire hundreds of packages while these changes
are occurring. Many of these broken packages are probably because
casual maintainers like me are struggling to keep up with the changes.
Instead, now is the time to apply more mentoring, and leadership to
assist those packagers get things in order, to figure out how to get
those packages into appropriate modules, as needed, to assist in
patching for python3, to help them take orphaned BRs, etc.

This sends a very bad message, something along the lines of "only
hard-core, full-time, dedicated packagers allowed; you're on your own
and if you can't get things working in Fedora, you're out".



That is indeed a bad message. The message intended here was:

"FTBFS packages are not allowed, fix them or remove them"

Obviously, if you cannot fix it, that's not an actionable message.
Packagers should be able to reach for help in that case. Ask on devel: My 
package doesn't help, I have no idea what to do now.


This again comes to the main issue: The procedure didn't happen since Fedora 
~25. People were surprised this time (as it was not properly communicated).


If people are actually used to this process they now that FTBFS needs to be 
fixed and if they don't know how, the proper thing to do is to ask for help, 
possibly for exception, rather than doing nothing.



Also, I have a question about retirement as it pertains to modularity:
let's say a package was retired because its BRs moved into modules
but now the only way to get the BRs (short of packaging all the java
stuff myself) is to put it in a module. Can I do this for a retired
package? Does 

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Mohan Boddu]

I unretired the packages and tagged the old builds, I think that should fix
the buildroot and got a testing build working.

On Sun, Aug 11, 2019 at 3:29 AM Miro Hrončok  wrote:

> On 11. 08. 19 2:58, Stephen John Smoogen wrote:
> > On Sat, 10 Aug 2019 at 17:12, Miro Hrončok  > > wrote:
> >
> > On 10. 08. 19 21:23, Miro Hrončok wrote:
> >  > While I really tried to do my best, it seems that I broke CentOS
> by retiring
> >  > python36. Should it be unretired? Or is it reasonable to say:
> Please wait
> > for
> >  > CentOS 7.7?
> >  >
> >  > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
> >
> > If any EPEL expert thinks the package should be unretired for now,
> please do so.
> >
> >
> > Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is
> out in
> > the CR repo. My apologies for not thinking of this when you were
> mentioning
> > things yesterday. I do not have the rights to unretire things so will
> need to
> > get in touch with Mohan/Kevin/Mizdebsk on what to do.
>
> https://pagure.io/releng/issue/8607
>
> --
> 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 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.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Miro Hrončok]

On 11. 08. 19 2:58, Stephen John Smoogen wrote:
On Sat, 10 Aug 2019 at 17:12, Miro Hrončok > wrote:


On 10. 08. 19 21:23, Miro Hrončok wrote:
 > While I really tried to do my best, it seems that I broke CentOS by 
retiring
 > python36. Should it be unretired? Or is it reasonable to say: Please wait
for
 > CentOS 7.7?
 >
 > https://bugzilla.redhat.com/show_bug.cgi?id=1739804

If any EPEL expert thinks the package should be unretired for now, please 
do so.


Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is out in 
the CR repo. My apologies for not thinking of this when you were mentioning 
things yesterday. I do not have the rights to unretire things so will need to 
get in touch with Mohan/Kevin/Mizdebsk on what to do.


https://pagure.io/releng/issue/8607

--
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: RFE: automatically enable rpmlint gating test for packages with a foo.rpmlintrc

[Dominik Perpeet]

Excellent suggestion!

In fact, as part of the CI Objective we want to enable more such
distribution-wide tests, such as rpminspect [0], installability and reverse
dependency testing. The tests that have been run by Fedora QA are also
being evaluated and those will be used directly or migrated.

At flock yesterday we had some good discussions on how to make opt-in more
accessible, and I'm sure the Fedora CI SIG will take your suggestions into
consideration. We all agree the current way of doing it isn't quite
optimal. :)

Stay tuned in the coming weeks to hear more about how to opt into gating!

Thanks,
-Dominik



[0] https://github.com/dcantrell/rpminspect


On Sat, Aug 10, 2019 at 9:59 PM Hans de Goede  wrote:

> Hi All,
>
> So what I've been reading from the rawhide gating mailthread,
> creating the gating rules unfortunately is somewhat convoluted /
> involved.
>
> As such I was wondering if maybe it is an idea to automatically
> enabled the rpmlint gating test for packages which have a
> .rpmlint rc. ?
>
> Alternatively a wiki page with gating confif snippets, mirroring
> how have a wiki page for specfile scriptlet snippets, might be a
> good idea. I would like to opt in to test-gating where possible,
> esp. with the rpmlint tests, but I do not have a lot of time to
> spend on this. More in general I believe that the easier this
> is made to use, the better chances are that people will actually
> use this.
>
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned some (mostly Python) packages

[Elliott Sales de Andrade]

Hi Miro,

On Wed, 7 Aug 2019 at 07:21, Miro Hrončok  wrote:
>
> # 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.
>

I can take this one, since my packages depend on it.

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



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