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

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

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

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

Fedora-Rawhide-20190811.n.1 compose check report

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:

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

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:

Re: Better interactivity in low-memory situations

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

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

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

Re: Better interactivity in low-memory situations

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

Re: Better interactivity in low-memory situations

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

Re: Better interactivity in low-memory situations

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

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

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,

Re: Better interactivity in low-memory situations

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.

Re: Xen / EC2 release criteria proposal

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

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

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

Re: Better interactivity in low-memory situations

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

Re: Better interactivity in low-memory situations

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

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

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

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

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

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

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 >

packages stuck in f31-updates-testing-pending

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

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

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

[Bug 1738791] Upgrade perl-TheSchwartz to 1.13

https://bugzilla.redhat.com/show_bug.cgi?id=1738791 Emmanuel Seyman changed: What|Removed |Added Fixed In Version||perl-TheSchwartz-1.13-1.fc3

Re: OpenCL on Intel processors

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

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

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

Re: OpenCL on Intel processors

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

Re: Please sweep bodhi updates to testing in a timely manner

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

Amateur radio dnf group in comps.xml

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

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

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

Re: Please sweep bodhi updates to testing in a timely manner

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

Re: Please sweep bodhi updates to testing in a timely manner

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

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

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

Re: Package removal for FTBFS: Add automatic orphaning?

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

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

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,

Re: Removal of Python 2 from the Xfce spin

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

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? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___

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

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

Re: Fedora 31 release-blocking deliverables

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

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

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

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

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

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

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

Re: Package removal for FTBFS: Add automatic orphaning?

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

Re: Orphaned some (mostly Python) packages

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

Re: Package removal for FTBFS: Add automatic orphaning?

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

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

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 >

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

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

Re: RFE: automatically enable rpmlint gating test for packages with a foo.rpmlintrc

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.

Re: Orphaned some (mostly Python) packages

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,