Re: Fedora 32 FTBFS packages to be orphaned in 1 week

[Mattia Verga via devel]

Il 10/04/20 21:18, Ian McInerney ha scritto:

> On Fri, Apr 10, 2020 at 8:06 PM Mattia Verga via devel 
>  wrote:
>
>> For pam_url I need help from someone with C skills, since there's an
>> error at build time:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=43192974
>
> Looks like another GCC10 fno-common problem. For now, you should be able to 
> put "%define _legacy_common_support 1" in the spec and have it build. Is 
> there an upstream you can report this to so that they can fix it?
>
> -Ian

Yes, I filed [1], but upstream seems quite abandoned... I'll try your 
suggestion, thanks.

Mattia

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

non-responsive maintainer: elyscape (Eli Young)

[Felix Schwarz]

Hi,

following the policy for non-responsive package maintainers [0], I'm
asking here if anybody knows how to contact elyscape (Eli Young).

Eli, if you're still interested in maintaining your packages, please respond.

Open bugs:
- python-digitalocean-1.15.0 is available
  https://bugzilla.redhat.com/show_bug.cgi?id=1793188

- python-digitalocean: please provide a package for EPEL 8
  https://bugzilla.redhat.com/show_bug.cgi?id=1813735

- python-tldextract-2.2.2 is available
  https://bugzilla.redhat.com/show_bug.cgi?id=1762086


Felix

[0]: 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

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

[389-devel] 389 DS nightly 2020-04-11 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/04/11/report-389-ds-base-1.4.3.5-20200410git36c593d.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1823026] perl-Net-SMTPS-0.10 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-SMTPS-0.10-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=43206320


-- 
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 1823026] perl-Net-SMTPS-0.10 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1677952
  --> https://bugzilla.redhat.com/attachment.cgi?id=1677952=edit
[patch] Update to 0.10 (#1823026)


-- 
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 1823025] New: perl-Net-POP3S-0.11 is available

[bugzilla]

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

Bug ID: 1823025
   Summary: perl-Net-POP3S-0.11 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-POP3S
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.11
Current version/release in rawhide: 0.10-8.fc32
URL: http://search.cpan.org/dist/Net-POP3S/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3159/


-- 
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 1823025] perl-Net-POP3S-0.11 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An unexpected error occurred while creating the scratch build and has been
automatically reported. Sorry!


-- 
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 1823026] New: perl-Net-SMTPS-0.10 is available

[bugzilla]

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

Bug ID: 1823026
   Summary: perl-Net-SMTPS-0.10 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-SMTPS
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.10
Current version/release in rawhide: 0.09-8.fc32
URL: http://search.cpan.org/dist/Net-SMTPS/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3162/


-- 
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 1823020] New: perl-Net-SSH2-0.71 is available

[bugzilla]

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

Bug ID: 1823020
   Summary: perl-Net-SSH2-0.71 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-SSH2
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.71
Current version/release in rawhide: 0.70-4.fc32
URL: http://search.cpan.org/dist/Net-SSH2/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3163/


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

[EPEL-devel] Re: Input Requested: revising policy for stalled EPEL requests

[Troy Dawson]

On Fri, Apr 3, 2020 at 3:21 PM Troy Dawson  wrote:
>
> EPEL Issue #101 [1] has pointed out that our current policy for
> stalled EPEL requests is fairly in-efficient and can cause some long
> delays.
>
> What do people think the process should be?
>
> Here is an example:
> * A packager opens a bugzilla requesting a package be added to EPEL.
> They also express that they are willing to help maintain / co-maintain
> that package in EPEL.
> * A period of time goes by with no response
> * They re-say that they are willing to maintain / co-maintain the
> package in EPEL
> * Another period of time goes by with no response
> * They file a rel-eng ticket, that points to the bugzilla, requesting
> appropriate privileges to be able to branch and build that package in
> EPELX
> * That happens.
> * They then request branch, and build the package in EPELX following
> normal ways.
>
> This is just an example, but it's what I picture in my head.
> Troy
>
> [1] - https://pagure.io/epel/issue/101

This is the proposed policy. If people could look through it for any
problems, it would be appreciated.

**Stalled EPEL Requests**
There are times that an EPEL / Fedora package maintainer isn't
responding to an EPEL package request. If a different packager would
like to build and maintain that package in EPEL, these are the steps
they take.

* A packager opens a bugzilla requesting a package be added to EPEL.
They also express that they are willing to help maintain / co-maintain
that package in EPEL-X.

* A week goes by with no response

* They re-say that they are willing to maintain / co-maintain the
package in EPEL
** This is just incase the initial message was missed.

* A week goes by with no response

* They file a rel-eng ticket, that points to the bugzilla, requesting
appropriate privileges to be able to branch and build that package in
EPEL-X
** Currently that privilege is "admin"
** This part of the policy will adjust as various features get
implemented in pagure and dist-git

* The privileges are given
* They then request a branch, and build the package in EPEL-X
following normal steps.
___
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

Review Swap: simde - SIMD Everywhere

[Jun Aruga]

Hi,

Could anyone want to swap a review?

Review Request: simde - SIMD Everywhere
https://bugzilla.redhat.com/show_bug.cgi?id=1823001

simde [1] is a header files only library for a software implementing
SIMD [2] to build with multiple CPU architectures.

Thanks.
Jun

[1] https://github.com/nemequ/simde
[2] SIMD: https://en.wikipedia.org/wiki/SIMD

-- 
Jun | He - His - Him
___
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: git-core deps under f32

[clime]

On Fri, 10 Apr 2020 at 13:15, Josh Boyer  wrote:
>
> On Fri, Apr 10, 2020 at 3:49 AM clime  wrote:
> >
> >
> >
> > Dne pá 10. dub 2020 4:12 uživatel Todd Zullinger  napsal:
> >>
> >> I wrote:
> >> > clime wrote:
> >> >> It seems the f32's git-core got many more deps for some reason, even
> >> >> such as dbus-broker or systemd.
> >> [...]
> >> > I'll try to poke a bit in the next few days as I can make
> >> > some time.  I had not noticed the inflated depchain.  Thank
> >> > you for pointing it out.
> >>
> >> I was curious, so I looked at this tonight.  The git-core
> >> requires are the same on f31 and f32:
> >>
> >> $ diff -qs \
> >>   <(rpm -qp --requires git-core-2.25.2-1.fc31.x86_64.rpm 2>/dev/null) \
> >>   <(rpm -qp --requires git-core-2.26.0-1.fc32.x86_64.rpm 2>/dev/null)
> >> Files /dev/fd/63 and /dev/fd/62 are identical
> >>
> >> Checking each of those deps, openssh-clients grew a dep on
> >> libfido2, which in turn requires u2f-hidraw-policy that is
> >> provided by systemd.  That looks like the main chain which
> >> leads to the additional packages installed in a mock chroot.
> >>
> >> In a fedora 32 container (and most "regular" installs),
> >> systemd is already present, so the change should have very
> >> little impact outside of mock or other targets which are
> >> smaller than the default fedora 32 container image.
>
> That might be true in fedora and fedora-minimal (???) but looking
> forward we should really avoid this dep growth if we can.  The current
> ubi8-minimal image doesn't include systemd and I'd like to keep it
> that way.  There's really little reason to have systemd in a container
> at all unless you're using it to run services that require systemd,
> and most container usage doesn't.  However, git usage in a container
> environment is very common.
>
> >> I don't think that git-core should drop openssh-clients and
> >> it seems pretty reasonable for openssh-clients to require
> >> libfido2 to enable two factor authentication.
> >>
> >> Does that sound alright to you as well, clime?
> >
> >
> > Todd, thanks for looking at it. It sounds that everything is alright from 
> > git-core's point of view, however the whole dep chain seems quite large.
> >
> > I would like to install git-core into mock chroot to have git shell client 
> > available to read git metadata of fedora package repository and 
> > preproprecess spec file based on it. (side note: I don't actually even need 
> > pulling/pushing/cloning but it is probably already impossible to have git 
> > without those.)
> >
> > Maybe u2f-hidraw-policy could be separated out from systemd? I probably 
> > should open a request there.
>
> Would you please?

I did https://bugzilla.redhat.com/show_bug.cgi?id=1823002

Feel free to comment there.

Best regards!
clime

>
> The Minimization Objective is probably interested in this as well, so
> I've copied Adam.
>
>
> josh
>
> >
> > Thanks again for your help! I am really happy git-core exists!
> > clime
> >
> >>
> >> --
> >> Todd
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: git-core deps under f32

[clime]

On Fri, 10 Apr 2020 at 22:02, Gary Buhrmaster  wrote:
>
> On Fri, Apr 10, 2020 at 2:12 AM Todd Zullinger  wrote:
>
> > Checking each of those deps, openssh-clients grew a dep on
> > libfido2, which in turn requires u2f-hidraw-policy that is
> > provided by systemd.  That looks like the main chain which
> > leads to the additional packages installed in a mock chroot.
>
> I *think* that systemd replaced the independent u2f-hidraw-policy
> package as part of the added systemd-homed capability (I admit
> I might have the history wrong there).

Under f31:
$ dnf repoquery --whatprovides u2f-hidraw-policy
u2f-hidraw-policy-0:1.0.2-10.fc31.x86_64

Under f32:
$ dnf repoquery --whatprovides u2f-hidraw-policy
systemd-0:245.4-1.fc32.x86_64

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 604  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 346  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
 344  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  53  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6   
python-waitress-1.4.3-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b23fa957bb   
drupal7-ckeditor-1.19-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-16bf726581   
php-robrichards-xmlseclibs1-1.4.3-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-181270fbae   
chromium-80.0.3987.163-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-34295ace88   
cacti-1.2.11-1.el7 cacti-spine-1.2.11-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b6453e2708   
nrpe-4.0.2-1.el7


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

composer-1.10.5-1.el7
diff-pdf-0.4.1-3.el7
java-latest-openjdk-14.0.0.36-3.rolling.el7
nagios-plugins-2.3.3-2.el7
ocserv-1.0.1-1.el7

Details about builds:



 composer-1.10.5-1.el7 (FEDORA-EPEL-2020-095b5b072f)
 Dependency Manager for PHP

Update Information:

**Version 1.10.5** -  2020-04-10  * Fixed self-update on PHP <5.6, seriously
please upgrade people, it's time * Fixed 1.10.2 regression with PATH resolution
in scripts     **Version 1.10.4** - 2020-04-09  * Fixed 1.10.2 regression in
path symlinking with absolute path repos    **Version 1.10.3** -  2020-04-09
* Fixed invalid --2 flag warning in `self-update` when no channel is requested
  **Version 1.10.2** - 2020-04-09  * Added --1 flag to `self-update` command
which can be added to automated self-update runs to make sure it won't
automatically jump to 2.0 once that is released * Fixed path repository symlinks
being made relative when the repo url is defined as absolute paths * Fixed
potential issues when using "composer ..." in scripts and composer/composer was
also required in the project * Fixed 1.10.0 regression when downloading GitHub
archives from non-API URLs * Fixed handling of malformed info in fund command *
Fixed Symfony5 compatibility issues in a few commands

ChangeLog:

* Fri Apr 10 2020 Remi Collet  - 1.10.5-1
- update to 1.10.5
* Thu Apr  9 2020 Remi Collet  - 1.10.4-1
- update to 1.10.4




 diff-pdf-0.4.1-3.el7 (FEDORA-EPEL-2020-833fef9cfc)
 A simple tool for visually comparing two PDF files

Update Information:

Small fix.

ChangeLog:





 java-latest-openjdk-14.0.0.36-3.rolling.el7 (FEDORA-EPEL-2020-c891285978)
 OpenJDK Runtime Environment 14

Update Information:

java-latest-openjdk update to OpenJDK 14

ChangeLog:

* Tue Mar 24 2020 Petra Alice Mikova  - 
1:14.0.0.36-3.rolling
- uploaded new src tarball
* Mon Mar 23 2020 Petra Alice Mikova  - 
1:14.0.0.36-2.rolling
- removed backslashes at the end of alternatives command
* Fri Mar 13 2020 Petra Alice Mikova  - 
1:14.0.0.36-1.rolling
- update to jdk 14+36 ga build
- removed pack200 and unpack200 binaries, slaves, manpages and libunpack.so 
library
- added listings for jpackage binary, manpages and added slave records to 
alternatives




 nagios-plugins-2.3.3-2.el7 (FEDORA-EPEL-2020-95e11af536)
 Host/service/network monitoring program plugins for Nagios

Update Information:

New upstream version    New upstream version

ChangeLog:

* Thu Apr  9 2020 Martin Jackson  - 2.3.3-2
- New upstream version




 ocserv-1.0.1-1.el7 

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a5eb3ef5   
librabbitmq-0.5.2-2.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-22ba261c73   
drupal7-ckeditor-1.19-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-082ab81e5f   
php-robrichards-xmlseclibs1-1.4.3-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fc983d39e7   
nrpe-4.0.2-1.el6


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

nagios-plugins-2.3.3-1.el6

Details about builds:



 nagios-plugins-2.3.3-1.el6 (FEDORA-EPEL-2020-9fa9c48cbb)
 Host/service/network monitoring program plugins for Nagios

Update Information:

New upstream version

ChangeLog:

* Thu Apr  9 2020 Martin Jackson  - 2.3.3-1
- New upstream version


___
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 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  33  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4   
ansible-2.9.6-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83cd17b92f   
nrpe-4.0.2-2.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6637ed458e   
chromium-80.0.3987.163-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8fcf741d7f   
cacti-1.2.11-1.el8 cacti-spine-1.2.11-1.el8


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

MUMPS-5.2.1-8.el8
diff-pdf-0.4.1-3.el8
geany-1.36-3.el8
geany-plugins-1.36-4.el8
geany-themes-1.27-8.el8
java-latest-openjdk-14.0.0.36-3.rolling.el8
netatalk-3.1.12-14.el8
ocserv-1.0.1-1.el8
pdns-4.3.0-1.el8
python-extras-1.0.0-1.el8
swift-lang-5.2.1-1.el8

Details about builds:



 MUMPS-5.2.1-8.el8 (FEDORA-EPEL-2020-412e9f5404)
 A MUltifrontal Massively Parallel sparse direct Solver

Update Information:

- Linked to openclas

ChangeLog:

* Wed Apr  8 2020 Antonio Trande  - 5.2.1-8
- Fix rhbz#1819796 on epel8
* Thu Apr  2 2020 Antonio Trande  - 5.2.1-7
- Fix rhbz#1819796
* Tue Jan 28 2020 Fedora Release Engineering  - 
5.2.1-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Sat Jan 25 2020 Antonio Trande  - 5.2.1-5
- Workaround for GFortran 10 (-fallow-argument-mismatch)
* Wed Jan  1 2020 Antonio Trande  - 5.2.1-4
- Use libmpiblacs separately with scalapack-2.1.*
* Sun Nov 17 2019 Tom Callaway  - 5.2.1-3
- libmpiblacs is now inside of libscalapack

References:

  [ 1 ] Bug #1819796 - package is linked against reference BLAS, not openblas
https://bugzilla.redhat.com/show_bug.cgi?id=1819796




 diff-pdf-0.4.1-3.el8 (FEDORA-EPEL-2020-ad12243ba2)
 A simple tool for visually comparing two PDF files

Update Information:

Small fix.

ChangeLog:

* Thu Apr  9 2020 Vasiliy Glazov  - 0.4.1-3
- Disable silent make rules, thanks Orion Poplawski
* Tue Jan 28 2020 Fedora Release Engineering  - 
0.4.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild




 geany-1.36-3.el8 (FEDORA-EPEL-2020-5392d2e45e)
 A fast and lightweight IDE using GTK3

Update Information:

Theis update brings Geany to EPEL8! Have fun with using this on your RHEL8-based
linux distribution of choice!

ChangeLog:


References:

  [ 1 ] Bug #1754361 - Request for Geany IDE for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1754361
  [ 2 ] Bug #1820110 - [RFE] : geany : epel8 build request
https://bugzilla.redhat.com/show_bug.cgi?id=1820110




 geany-plugins-1.36-4.el8 (FEDORA-EPEL-2020-5392d2e45e)
 Plugins for Geany

Update Information:

Theis update brings Geany to EPEL8! Have fun with using this on your RHEL8-based
linux distribution of choice!

ChangeLog:


References:

  [ 1 ] Bug #1754361 - Request for Geany IDE for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1754361
  [ 2 ] Bug #1820110 - [RFE] : geany : epel8 build request
https://bugzilla.redhat.com/show_bug.cgi?id=1820110




 geany-themes-1.27-8.el8 (FEDORA-EPEL-2020-5392d2e45e)
 A collection of syntax highlighting color schemes for Geany

Update Information:

Theis update brings Geany to EPEL8! Have fun with using this on your RHEL8-based
linux distribution 

Re: git-core deps under f32

[Gary Buhrmaster]

On Fri, Apr 10, 2020 at 2:12 AM Todd Zullinger  wrote:

> Checking each of those deps, openssh-clients grew a dep on
> libfido2, which in turn requires u2f-hidraw-policy that is
> provided by systemd.  That looks like the main chain which
> leads to the additional packages installed in a mock chroot.

I *think* that systemd replaced the independent u2f-hidraw-policy
package as part of the added systemd-homed capability (I admit
I might have the history wrong there).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200410.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200408.n.1
NEW: Fedora-Rawhide-20200410.n.0

= SUMMARY =
Added images:3
Dropped images:  0
Added packages:  2
Dropped packages:6
Upgraded packages:   122
Downgraded packages: 1

Size of added packages:  105.16 KiB
Size of dropped packages:2.16 MiB
Size of upgraded packages:   2.78 GiB
Size of downgraded packages: 10.95 MiB

Size change of upgraded packages:   96.18 MiB
Size change of downgraded packages: -15.59 KiB

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20200410.n.0.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20200410.n.0.iso
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20200410.n.0.aarch64.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: perl-Mojolicious-Plugin-OpenAPI-3.31-2.fc33
Summary: OpenAPI / Swagger plugin for Mojolicious
RPMs:perl-Mojolicious-Plugin-OpenAPI
Size:77.80 KiB

Package: python-apypie-0.2.2-1.fc33
Summary: Apipie bindings for Python
RPMs:python3-apypie
Size:27.36 KiB


= DROPPED PACKAGES =
Package: aalto-xml-1.2.2-2.fc32
Summary: Ultra-high performance non-blocking XML processor (Stax/Stax2, 
SAX/SAX2)
RPMs:aalto-xml aalto-xml-javadoc
Size:589.43 KiB

Package: compress-lzf-1.0.4-2.fc32
Summary: Basic LZF codec, compatible with standard C LZF package
RPMs:compress-lzf compress-lzf-javadoc
Size:165.32 KiB

Package: jboss-marshalling-1.4.11-8.fc32
Summary: JBoss Marshalling
RPMs:jboss-marshalling jboss-marshalling-javadoc jboss-marshalling-osgi
Size:551.43 KiB

Package: jetty-alpn-api-1.1.3-8.fc32
Summary: Jetty ALPN API
RPMs:jetty-alpn-api jetty-alpn-api-javadoc
Size:52.64 KiB

Package: lz4-java-1.3.0-13.fc32
Summary: LZ4 compression for Java
RPMs:lz4-java lz4-java-javadoc
Size:743.91 KiB

Package: lzma-java-1.3-9.fc32
Summary: LZMA library for Java
RPMs:lzma-java lzma-java-javadoc
Size:111.27 KiB


= UPGRADED PACKAGES =
Package:  MUMPS-5.2.1-8.fc33
Old package:  MUMPS-5.2.1-7.fc33
Summary:  A MUltifrontal Massively Parallel sparse direct Solver
RPMs: MUMPS MUMPS-common MUMPS-devel MUMPS-examples MUMPS-mpich 
MUMPS-mpich-devel MUMPS-mpich-examples MUMPS-openmp MUMPS-openmp-devel 
MUMPS-openmp-examples MUMPS-openmpi MUMPS-openmpi-devel MUMPS-openmpi-examples
Size: 75.04 MiB
Size change:  7.26 KiB
Changelog:
  * Wed Apr 08 2020 Antonio Trande  - 5.2.1-8
  - Fix rhbz#1819796 on epel8


Package:  aircrack-ng-1.6-2.fc33
Old package:  aircrack-ng-1.6-1.fc33
Summary:  802.11 (wireless) sniffer and WEP/WPA-PSK key cracker
RPMs: aircrack-ng aircrack-ng-devel aircrack-ng-doc
Size: 6.01 MiB
Size change:  -2.71 KiB
Changelog:
  * Thu Apr 09 2020 Vitaly Zaitsev  - 1.6-2
  - Moved libraries to main package.
  - Moved OUI database to data directory.


Package:  alt-ergo-2.0.0-13.fc33
Old package:  alt-ergo-2.0.0-12.fc33
Summary:  Automated theorem prover including linear arithmetic
RPMs: alt-ergo alt-ergo-gui
Size: 34.14 MiB
Size change:  -24.88 KiB
Changelog:
  * Wed Apr 08 2020 Jerry James  - 2.0.0-13
  - Filter out Requires for private interfaces we do not Provide


Package:  awscli-1.18.39-1.fc33
Old package:  awscli-1.18.38-1.fc33
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.71 MiB
Size change:  253 B
Changelog:
  * Thu Apr 09 2020 Gwyn Ciesla  - 1.18.39-1
  - 1.18.39


Package:  bless-0.6.2-2.fc33
Old package:  bless-0.6.0-27.fc31
Summary:  High quality, full featured hex editor
RPMs: bless bless-doc
Size: 2.35 MiB
Size change:  -59.11 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
0.6.0-28
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Thu Feb 20 2020 Timotheus Pokorra  - 
0.6.0-29
  - Fix build with new mono 6, fixing confusion about System.Range and 
Bless.Util.Range

  * Wed Apr 08 2020 Timotheus Pokorra  - 
0.6.2-1
  - Update to new upstream release 0.6.2

  * Wed Apr 08 2020 Timotheus Pokorra  - 
0.6.2-2
  - default edit mode is now Overwrite instead of Insert


Package:  buildah-1.15.0-0.32.dev.gite48fa75.fc33
Old package:  buildah-1.15.0-0.31.dev.gitc554675.fc33
Summary:  A command line tool used for creating OCI Images
RPMs: buildah buildah-tests
Size: 87.79 MiB
Size change:  -39.58 KiB
Changelog:
  * Thu Apr 09 2020 RH Container Bot  - 
1.15.0-0.32.dev.gite48fa75
  - autobuilt e48fa75


Package:  containernetworking-plugins-0.8.5-4.1.gitf4332fe.fc33
Old package:  containernetworking-plugins-0.8.5-3.1.git117e30f.fc33
Summary:  Libraries for writing CNI plugin
RPMs: containernetworking-plugins containernetworking-plugins-devel 
containernetworking-plugins-unit-test-devel
Size: 51.69 MiB
Size

Re: Fedora 32 FTBFS packages to be orphaned in 1 week

[Ian McInerney]

On Fri, Apr 10, 2020 at 8:06 PM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

>
> For pam_url I need help from someone with C skills, since there's an
> error at build time:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43192974
>
>
Looks like another GCC10 fno-common problem. For now, you should be able to
put "%define _legacy_common_support 1" in the spec and have it build. Is
there an upstream you can report this to so that they can fix it?

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

Re: Fedora 32 FTBFS packages to be orphaned in 1 week

[Mattia Verga via devel]

Il 29/03/20 13:13, Miro Hrončok ha scritto:
> pam_url  herlo icon
> python-robosignatory abompard ralph
> reg  cverna

It turned out on infra mailing list that those are required to 
infrastructure, so I've taken them before they are retired.

However, I will need some assistance in fixing them. I've already fixed 
python-robosignatory, which was an easy fix, but the other two are 
problematic.

For pam_url I need help from someone with C skills, since there's an 
error at build time:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43192974

For reg I need help from someone with Golang packaging skills and 
language knowledge (and this package will probably need to be renamed in 
golang-github-reg to adhere to packaging guidelines, from a quick read).

I would also be happy to add people as co-maintainers...

Mattia

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

Fedora-IoT-32-20200410.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

Old failures (same test failed in Fedora-IoT-32-20200408.0):

ID: 572758  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/572758

Passed openQA tests: 7/8 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

On Fri, Apr 10, 2020 at 11:14 AM Olivier Fourdan  wrote:
>
> On Fri, Apr 10, 2020 at 4:38 PM Adam Jackson  wrote:
>>
>> On Fri, 2020-04-10 at 15:35 +0200, Olivier Fourdan wrote:
>> > [...]
>> > Adam, want me to launch an official build, just to rebuild?
>>
>> Yes, please!
>
> Oops, looks like I've been presumptuous on that one, I don't have the rights.

xorg-x11-drv-intel has very extensive set of BuildRequires, which
seems rather large for a driver. I presume koji satisfies those and
your test builds do indeed match the official ones.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-33-20200410.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 1/8 (x86_64)

Old failures (same test failed in Fedora-IoT-33-20200409.0):

ID: 572750  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/572750

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

Old soft failures (same test soft failed in Fedora-IoT-33-20200409.0):

ID: 572745  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/572745
ID: 572746  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/572746

Passed openQA tests: 5/8 (x86_64)

New passes (same test not passed in Fedora-IoT-33-20200409.0):

ID: 572752  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/572752
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 compose report: 20200410.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200409.n.0
NEW: Fedora-32-20200410.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  12
Dropped packages:0
Upgraded packages:   134
Downgraded packages: 0

Size of added packages:  27.41 MiB
Size of dropped packages:0 B
Size of upgraded packages:   3.83 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: adb-enhanced-2.5.4-1.fc32
Summary: Swiss-army knife for Android testing and development
RPMs:adb-enhanced
Size:7.35 MiB

Package: golang-github-resty-2.2.0-2.fc32
Summary: Simple HTTP and REST client library
RPMs:golang-github-resty-devel
Size:52.12 KiB

Package: httprobe-0.1.2-1.fc32
Summary: Probing tool for working HTTP and HTTPS servers
RPMs:golang-github-tomnomnom-httprobe-devel httprobe
Size:9.30 MiB

Package: jmdns-3.5.5-1.fc32
Summary: Java implementation of multi-cast DNS
RPMs:jmdns
Size:207.91 KiB

Package: libevdevPlus-0.1.1-5.fc32
Summary: A C++ wrapper around libevdev
RPMs:libevdevPlus libevdevPlus-devel
Size:227.01 KiB

Package: libuInputPlus-0.1.4-5.fc32
Summary: A C++ wrapper around libuinput
RPMs:libuInputPlus libuInputPlus-devel
Size:180.79 KiB

Package: musl-1.2.0-2.fc32
Summary: Fully featured lightweight standard C library for Linux
RPMs:musl-clang musl-devel musl-filesystem musl-gcc musl-libc 
musl-libc-static
Size:8.21 MiB

Package: pg-semver-0.21.0-1.module_f32+8457+62e6e19f
Summary: A semantic version data type for PostgreSQL
RPMs:pg-semver
Size:128.09 KiB

Package: python-ajpy-0.0.4-1.fc32
Summary: AJP package crafting library
RPMs:python3-ajpy
Size:17.82 KiB

Package: python-plugnplay-0.5.4-1.fc32
Summary: A generic plug-in system for Python
RPMs:python3-plugnplay
Size:22.55 KiB

Package: workspace-1.1.0-1.fc32
Summary: A tool to create scratch directories by users with an expiration date
RPMs:workspace
Size:1.30 MiB

Package: xsecurelock-1.7.0-1.fc32
Summary: X11 screen lock utility with security in mind
RPMs:xsecurelock
Size:450.34 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  YafaRay-3.4.0-1.fc32
Old package:  YafaRay-3.3.0-32.20190819git0a182c1.fc32
Summary:  A free open-source ray-tracing render engine
RPMs: YafaRay YafaRay-blender YafaRay-devel YafaRay-lib
Size: 5.18 MiB
Size change:  -8.15 KiB
Changelog:
  * Sun Mar 15 2020 Luya Tshimbalanga  - 
3.3.0-33.20190819git0a182c1
  - Rebuild for blender 2.82a

  * Sat Mar 28 2020 Luya Tshimbalanga  - 3.4.0-1
  - Update to 3.4.0


Package:  arch-install-scripts-23-1.fc32
Old package:  arch-install-scripts-21-3.fc32
Summary:  Scripts to bootstrap Arch Linux distribution
RPMs: arch-install-scripts
Size: 27.38 KiB
Size change:  5.68 KiB
Changelog:
  * Tue Mar 31 2020 Zbigniew J??drzejewski-Szmek  - 23-1
  - Update to latest version (#1717676)


Package:  archlinux-keyring-20200108-1.fc32
Old package:  archlinux-keyring-20191219-2.fc32
Summary:  GPG keys used by Arch distribution to sign packages
RPMs: archlinux-keyring
Size: 872.04 KiB
Size change:  -55.04 KiB
Changelog:
  * Tue Mar 31 2020 Zbigniew J??drzejewski-Szmek  - 
20200108-1
  - New upstream release (#1785315).


Package:  arm-image-installer-2.16-1.fc32
Old package:  arm-image-installer-2.15-2.fc32
Summary:  Writes binary image files to any specified block device
RPMs: arm-image-installer
Size: 47.76 KiB
Size change:  -224 B
Changelog:
  * Tue Apr 07 2020 Paul Whalen  - 2.16-1
  - Update to 2.16


Package:  armadillo-9.860.1-1.fc32
Old package:  armadillo-9.850.1-1.fc32
Summary:  Fast C++ matrix library with syntax similar to MATLAB and Octave
RPMs: armadillo armadillo-devel
Size: 10.91 MiB
Size change:  20.52 KiB
Changelog:
  * Wed Apr 01 2020 Jos?? Matos  - 9.860.1-1
  - update to 9.860.1


Package:  audacity-2.3.3-4.fc32
Old package:  audacity-2.3.3-1.fc32
Summary:  Multitrack audio editor
RPMs: audacity audacity-manual
Size: 45.89 MiB
Size change:  -398.23 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
2.3.3-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Wed Apr 01 2020 Ian McInerney  - 2.3.3-3
  - Use legacy -fcommon support with GCC10.

  * Mon Apr 06 2020 Ian McInerney  - 2.3.3-4
  - Fix changelog date from last entry


Package:  bcm283x-firmware-20200401-1.c2c6ce8.fc32
Old package:  bcm283x-firmware-20200326-1.5574077.fc32
Summary:  Broadcom bcm283x firmware for the Raspberry Pi
RPMs: bcm283x-firmware
Size: 12.71 MiB
Size change:  -6.00 KiB
Changelog:
  * Mon Apr 06 2020 Peter Robinson  
20200401-1.c2c6ce8
  - Latest firmware update


Package:  bind-32:9.11.17-1.fc32
Old package:  bind-32

Re: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

On Fri, Apr 10, 2020 at 4:38 PM Adam Jackson  wrote:

> On Fri, 2020-04-10 at 15:35 +0200, Olivier Fourdan wrote:
> > [...]
> > Adam, want me to launch an official build, just to rebuild?
>
> Yes, please!
>

Oops, looks like I've been presumptuous on that one, I don't have the
rights.

So I've filed a PR in pagure instead:

rawhide:
https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/pull-request/6

Then f32 needs to be rebased, etc.

Sorry about that...

Cheers
Olivier
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

On Fri, 2020-04-10 at 15:35 +0200, Olivier Fourdan wrote:
> On Fri, Apr 10, 2020 at 3:24 PM Alexei Podtelezhnikov  
> wrote:
> > >>
> > >> Is koji still fc31? My problematic rebuilds are obviously fc32.
> > >
> > >
> > > All the scratch builds I spawned for this issue are for F32 of course.
> > 
> > I am pondering a compiler bug. Your scratch builds are fine so it
> > seems. What if you rebuild without koji on your desktop using shiny
> > Fedora 32.
> 
> Yes, I also thought of that, looks like there've been a few gcc changes 
> between the current Fedora build of xorg-x11-drv-intel and now. 
> 
> The driver works equally well if I compile locally of course (which is how I 
> figured, trying to bisect), but koji uses mock which installs the same gcc 
> version to build of course, you can see that here:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/1463/43191463/root.log
> 
> Either way, good to know the scratch build works for you.
> 
> Adam, want me to launch an official build, just to rebuild?

Yes, please!

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

[Test-Announce] Fedora 32 Branched 20200410.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200410.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
python-blivet - 20200407.n.0: python-blivet-3.2.0-3.fc32.src, 20200410.n.0: 
python-blivet-3.2.1-1.fc32.src
pykickstart - 20200407.n.0: pykickstart-3.23-2.fc32.src, 20200410.n.0: 
pykickstart-3.24-1.fc32.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200410.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200410.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200410.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200410.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200410.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200410.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200410.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@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: Updating MUMPS/Sundials/PETSc

[Antonio Trande]

The release 3.13.0-4 should be okay.

> On 09/04/20 02:37, David S wrote>
> I found an issue, where linking against petsc (mpi version) and hdf5
> (serial version), this causes an error with unresolved dependencies for
> libpetsc.so
> This is caused by petsc linking against the mpi hdf5, but I only had
> hdf5-devel installed. Thus the linker selected the serial version.
> Thus I needed to install the hdf5-{mpich,openmpi}-devel package if
> linking against petsc(mpi) and hdf5.
> This was confusing for me, and there might be other libraries affected
> by this.
> Maybe a
> Requires: (hdf5-mpich-devel if hdf5-devel)
> for the petsc-mpich-devel could help - but I am not sure about this one.
> I am neither sure that this is sufficient, nor whether this is the right
> place to do this.
> 
> Thanks for getting this all fixed,
> David

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



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

Re: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

On Fri, Apr 10, 2020 at 3:24 PM Alexei Podtelezhnikov 
wrote:

> >>
> >> Is koji still fc31? My problematic rebuilds are obviously fc32.
> >
> >
> > All the scratch builds I spawned for this issue are for F32 of course.
>
> I am pondering a compiler bug. Your scratch builds are fine so it
> seems. What if you rebuild without koji on your desktop using shiny
> Fedora 32.
>

Yes, I also thought of that, looks like there've been a few gcc changes
between the current Fedora build of xorg-x11-drv-intel and now.

The driver works equally well if I compile locally of course (which is how
I figured, trying to bisect), but koji uses mock which installs the same
gcc version to build of course, you can see that here:

https://kojipkgs.fedoraproject.org//work/tasks/1463/43191463/root.log

Either way, good to know the scratch build works for you.

Adam, want me to launch an official build, just to rebuild?

Cheers
Olivier
___
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: Urgently downgrade xorg-x11-drv-intel

[Frantisek Zatloukal]

On Fri, Apr 10, 2020 at 3:24 PM Alexei Podtelezhnikov 
wrote:

> >>
> >> Is koji still fc31? My problematic rebuilds are obviously fc32.
> >
> >
> > All the scratch builds I spawned for this issue are for F32 of course.
>
> I am pondering a compiler bug. Your scratch builds are fine so it
> seems. What if you rebuild without koji on your desktop using shiny
> Fedora 32.
>

Are you using mock for local rebuilds? It should behave in the same way as
koji does...
___
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: Fwd: Fedora EPEL 7 Update: sourcextractor++-0.10-1.el7

[Tony Schreiner]

My blunder, it was looking for sextractor++
apologies for the noise

On Fri, Apr 10, 2020 at 9:20 AM Scott Talbert  wrote:

> I see:
>
>
> https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/s/sourcextractor++-0.10-1.el7.x86_64.rpm
>
> On Fri, 10 Apr 2020, Tony Schreiner wrote:
>
> >
> > This announcement is 11 days ago now, but I still don't see the package
> with
> > yum, nor on https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/
> > -- Forwarded message -
> > From: 
> > Date: Tue, Mar 31, 2020 at 10:57 PM
> > Subject: Fedora EPEL 7 Update: sourcextractor++-0.10-1.el7
> > To: 
> >
> >
> >
> ---
> > -
> > Fedora EPEL Update Notification
> > FEDORA-EPEL-2020-58450ed489
> > 2020-04-01 02:57:29.009592
> >
> ---
> > -
> >
> > Name: sourcextractor++
> > Product : Fedora EPEL 7
> > Version : 0.10
> > Release : 1.el7
> > URL : https://github.com/astrorama/sourcextractorplusplus
> > Summary : A program that extracts a catalog of sources from
> astronomical
> > images, and the successor of SExtractor
> > Description :
> > sourcextractor++ is a program that extracts a catalog of sources from
> > astronomical images. It is the successor to the original SExtractor
> > package.
> >
> >
> ---
> > -
> > Update Information:
> >
> > New RPM
> >
> ---
> > -
> > ChangeLog:
> >
> >
> ---
> > -
> >
> > This update can be installed with the "yum" update programs.  Use
> > su -c 'yum update sourcextractor++' at the command line.
> > For more information, refer to "YUM", available at
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7\
> > /html/System_Administrators_Guide/ch-yum.html
> >
> > All packages are signed with the Fedora EPEL GPG key.  More details on
> the
> > GPG keys used by the Fedora Project can be found at
> > https://fedoraproject.org/keys
> >
> ---
> > -
> > ___
> > epel-package-announce mailing list --
> > epel-package-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> > epel-package-announce-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.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-package-announce@lists.f
> > edoraproject.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

Re: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

>>
>> Is koji still fc31? My problematic rebuilds are obviously fc32.
>
>
> All the scratch builds I spawned for this issue are for F32 of course.

I am pondering a compiler bug. Your scratch builds are fine so it
seems. What if you rebuild without koji on your desktop using shiny
Fedora 32.
___
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: Fwd: Fedora EPEL 7 Update: sourcextractor++-0.10-1.el7

[Scott Talbert]

I see:

https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/s/sourcextractor++-0.10-1.el7.x86_64.rpm

On Fri, 10 Apr 2020, Tony Schreiner wrote:



This announcement is 11 days ago now, but I still don't see the package with
yum, nor on https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/
-- Forwarded message -
From: 
Date: Tue, Mar 31, 2020 at 10:57 PM
Subject: Fedora EPEL 7 Update: sourcextractor++-0.10-1.el7
To: 


---
-
Fedora EPEL Update Notification
FEDORA-EPEL-2020-58450ed489
2020-04-01 02:57:29.009592
---
-

Name        : sourcextractor++
Product     : Fedora EPEL 7
Version     : 0.10
Release     : 1.el7
URL         : https://github.com/astrorama/sourcextractorplusplus
Summary     : A program that extracts a catalog of sources from astronomical
images, and the successor of SExtractor
Description :
sourcextractor++ is a program that extracts a catalog of sources from
astronomical images. It is the successor to the original SExtractor
package.

---
-
Update Information:

New RPM
---
-
ChangeLog:

---
-

This update can be installed with the "yum" update programs.  Use
su -c 'yum update sourcextractor++' at the command line.
For more information, refer to "YUM", available at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7\
/html/System_Administrators_Guide/ch-yum.html

All packages are signed with the Fedora EPEL GPG key.  More details on the
GPG keys used by the Fedora Project can be found at
https://fedoraproject.org/keys
---
-
___
epel-package-announce mailing list --
epel-package-annou...@lists.fedoraproject.org
To unsubscribe send an email to
epel-package-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.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-package-announce@lists.f
edoraproject.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] Fwd: Fedora EPEL 7 Update: sourcextractor++-0.10-1.el7

[Tony Schreiner]

This announcement is 11 days ago now, but I still don't see the package
with yum, nor on https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/

-- Forwarded message -
From: 
Date: Tue, Mar 31, 2020 at 10:57 PM
Subject: Fedora EPEL 7 Update: sourcextractor++-0.10-1.el7
To: 



Fedora EPEL Update Notification
FEDORA-EPEL-2020-58450ed489
2020-04-01 02:57:29.009592


Name: sourcextractor++
Product : Fedora EPEL 7
Version : 0.10
Release : 1.el7
URL : https://github.com/astrorama/sourcextractorplusplus
Summary : A program that extracts a catalog of sources from
astronomical images, and the successor of SExtractor
Description :
sourcextractor++ is a program that extracts a catalog of sources from
astronomical images. It is the successor to the original SExtractor
package.


Update Information:

New RPM

ChangeLog:



This update can be installed with the "yum" update programs.  Use
su -c 'yum update sourcextractor++' at the command line.
For more information, refer to "YUM", available at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7\
/html/System_Administrators_Guide/ch-yum.html


All packages are signed with the Fedora EPEL GPG key.  More details on the
GPG keys used by the Fedora Project can be found at
https://fedoraproject.org/keys

___
epel-package-announce mailing list --
epel-package-annou...@lists.fedoraproject.org
To unsubscribe send an email to
epel-package-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.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-package-annou...@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

Re: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

On Fri, Apr 10, 2020 at 2:57 PM Alexei Podtelezhnikov 
wrote:

> On Fri, Apr 10, 2020 at 8:48 AM Alexei Podtelezhnikov
>  wrote:
> >
> > On Fri, Apr 10, 2020 at 7:55 AM Olivier Fourdan 
> wrote:
> > > The backtrace I get with the current Fedora build is the same every
> time, but does not involve `sna_accel_flush()`  (it crashes in
> `kgem_buffer_release()` down from `sna_accel_block()`)
> >
> > That is because the debug build triggers the the assertion rather than
> > progressing the segmentation fault
> >
> > > May I ask you to give
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43188723 a try, just
> in case?
> >
> > Hmmm. So far so good but why???
>
> Is koji still fc31? My problematic rebuilds are obviously fc32.
>

All the scratch builds I spawned for this issue are for F32 of course.

Cheers
Olivier
___
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-configobj - need Python 3 version for EPEL7 but RHEL ships python-configobj

[Miro Hrončok]

On 10. 04. 20 14:58, Felix Schwarz wrote:

I guess I'll start with the other packages to ensure I don't miss any
blockers. May I add you to the cc of the review request to ensure this will be
handled correctly?


Sure. Also, at this point, feel free not to package the python3_other 
subpackage.

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

[EPEL-devel] Re: python-configobj - need Python 3 version for EPEL7 but RHEL ships python-configobj

[Felix Schwarz]

Am 10.04.20 um 13:40 schrieb Miro Hrončok:
> On 10. 04. 20 12:05, Felix Schwarz wrote:
>> What is the best way to get a Python 3 version for EPEL 7?
> 
> Do a new package review request for an epel7 only package called
> python3-configobj that looks like:

Thank you for your advice - even though I hoped I could make this someone
else's problem ;-)

I guess I'll start with the other packages to ensure I don't miss any
blockers. May I add you to the cc of the review request to ensure this will be
handled correctly?

Felix
___
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: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

On Fri, Apr 10, 2020 at 8:48 AM Alexei Podtelezhnikov
 wrote:
>
> On Fri, Apr 10, 2020 at 7:55 AM Olivier Fourdan  wrote:
> > The backtrace I get with the current Fedora build is the same every time, 
> > but does not involve `sna_accel_flush()`  (it crashes in 
> > `kgem_buffer_release()` down from `sna_accel_block()`)
>
> That is because the debug build triggers the the assertion rather than
> progressing the segmentation fault
>
> > May I ask you to give 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=43188723 a try, just in 
> > case?
>
> Hmmm. So far so good but why???

Is koji still fc31? My problematic rebuilds are obviously fc32.
___
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: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

On Fri, Apr 10, 2020 at 7:55 AM Olivier Fourdan  wrote:
> The backtrace I get with the current Fedora build is the same every time, but 
> does not involve `sna_accel_flush()`  (it crashes in `kgem_buffer_release()` 
> down from `sna_accel_block()`)

That is because the debug build triggers the the assertion rather than
progressing the segmentation fault

> May I ask you to give 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43188723 a try, just in 
> case?

Hmmm. So far so good but why???
___
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: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

Hi Alexei,

On Fri, Apr 10, 2020 at 1:54 PM Olivier Fourdan  wrote:

> On Fri, Apr 10, 2020 at 1:14 PM Alexei Podtelezhnikov 
> wrote:
>
[...]
>
I rebuild the driver several times recently with and without full
> debugging. Nothing is fixed yet, except that I fixed
> --enable-debug=full and found
>
> Fatal server error:
> [   461.108] (EE) sna_accel_flush:17413 assertion '!ret ||
> priv->gpu_bo == NULL' failed
>
[...]
>

Right, so maybe we are not seeing the same issue.

Based on your comment I checked the changes in sna_accel.c between the two
builds (20180618 vs. 20200205) and there are actually very few changes,
luckily.

One of them makes a call to `sna_accel_flush()` unconditional.

It's a complete shoot in the dark, but who knows... could you try this
scratch build as well:

https://koji.fedoraproject.org/koji/taskinfo?taskID=43191463

Cheers
Olivier
___
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: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

Hi Alexei

On Fri, Apr 10, 2020 at 1:14 PM Alexei Podtelezhnikov 
wrote:

> > As a test, I just rebuilt the current package (no change in the code)
> and it works fine here, no more crash:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=43188723
>
> I rebuild the driver several times recently with and without full
> debugging. Nothing is fixed yet, except that I fixed
> --enable-debug=full and found
> I suggest you test a littlee longer: sometimes it crashes on login,
> sometimes it takes poking around. I contacted the upstream too. Please
> chime in
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/189
>

Well, with the current build I manage to crash within 1 minute.

The backtrace I get with the current Fedora build is the same every time,
but does not involve `sna_accel_flush()`  (it crashes in
`kgem_buffer_release()` down from `sna_accel_block()`)

With the scratch build, I haven't managed to reproduce, no matter what I
try (x11perf, map/unmap windows programatically, etc.).

May I ask you to give
https://koji.fedoraproject.org/koji/taskinfo?taskID=43188723 a try, just in
case?

Cheers
Olivier
___
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-configobj - need Python 3 version for EPEL7 but RHEL ships python-configobj

[Miro Hrončok]

On 10. 04. 20 12:05, Felix Schwarz wrote:

What is the best way to get a Python 3 version for EPEL 7?


Do a new package review request for an epel7 only package called 
python3-configobj that looks like:


https://src.fedoraproject.org/rpms/python3-six/blob/epel7/f/python3-six.spec

When approved, unorphan this and create an epel7 branch:

https://src.fedoraproject.org/rpms/python3-configobj

(Make sure to use a releng ticket that explains that you want to own it, but not 
to unretire it on master.)


> Maybe the Fedora maintainers of python-configobj change the spec file so on
>  EPEL 7 we only generate a Python 3 version?

This is not going to work, as the python-configobj component cannot be included 
in epel7.



--
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: git-core deps under f32

[Josh Boyer]

On Fri, Apr 10, 2020 at 3:49 AM clime  wrote:
>
>
>
> Dne pá 10. dub 2020 4:12 uživatel Todd Zullinger  napsal:
>>
>> I wrote:
>> > clime wrote:
>> >> It seems the f32's git-core got many more deps for some reason, even
>> >> such as dbus-broker or systemd.
>> [...]
>> > I'll try to poke a bit in the next few days as I can make
>> > some time.  I had not noticed the inflated depchain.  Thank
>> > you for pointing it out.
>>
>> I was curious, so I looked at this tonight.  The git-core
>> requires are the same on f31 and f32:
>>
>> $ diff -qs \
>>   <(rpm -qp --requires git-core-2.25.2-1.fc31.x86_64.rpm 2>/dev/null) \
>>   <(rpm -qp --requires git-core-2.26.0-1.fc32.x86_64.rpm 2>/dev/null)
>> Files /dev/fd/63 and /dev/fd/62 are identical
>>
>> Checking each of those deps, openssh-clients grew a dep on
>> libfido2, which in turn requires u2f-hidraw-policy that is
>> provided by systemd.  That looks like the main chain which
>> leads to the additional packages installed in a mock chroot.
>>
>> In a fedora 32 container (and most "regular" installs),
>> systemd is already present, so the change should have very
>> little impact outside of mock or other targets which are
>> smaller than the default fedora 32 container image.

That might be true in fedora and fedora-minimal (???) but looking
forward we should really avoid this dep growth if we can.  The current
ubi8-minimal image doesn't include systemd and I'd like to keep it
that way.  There's really little reason to have systemd in a container
at all unless you're using it to run services that require systemd,
and most container usage doesn't.  However, git usage in a container
environment is very common.

>> I don't think that git-core should drop openssh-clients and
>> it seems pretty reasonable for openssh-clients to require
>> libfido2 to enable two factor authentication.
>>
>> Does that sound alright to you as well, clime?
>
>
> Todd, thanks for looking at it. It sounds that everything is alright from 
> git-core's point of view, however the whole dep chain seems quite large.
>
> I would like to install git-core into mock chroot to have git shell client 
> available to read git metadata of fedora package repository and preproprecess 
> spec file based on it. (side note: I don't actually even need 
> pulling/pushing/cloning but it is probably already impossible to have git 
> without those.)
>
> Maybe u2f-hidraw-policy could be separated out from systemd? I probably 
> should open a request there.

Would you please?

The Minimization Objective is probably interested in this as well, so
I've copied Adam.


josh

>
> Thanks again for your help! I am really happy git-core exists!
> clime
>
>>
>> --
>> Todd
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Urgently downgrade xorg-x11-drv-intel

[Alexei Podtelezhnikov]

> As a test, I just rebuilt the current package (no change in the code) and it 
> works fine here, no more crash:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43188723

I rebuild the driver several times recently with and without full
debugging. Nothing is fixed yet, except that I fixed
--enable-debug=full and found

Fatal server error:
[   461.108] (EE) sna_accel_flush:17413 assertion '!ret ||
priv->gpu_bo == NULL' failed

I suggest you test a littlee longer: sometimes it crashes on login,
sometimes it takes poking around. I contacted the upstream too. Please
chime in 
https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/189
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning soundtracker

[Michael Schwendt]

On Thu, 9 Apr 2020 07:10:48 -0700, Erich Eickmeyer wrote:

> soundtracker is FTBFS and is basically gnome 1 software that
> necro-limped along like a zombie for a few years (read: decades). As it
> FTBFS and is dead upstream, I believe it's suffering bitrot so it's
> probably time to let it die.
> 
> As such, I'm orphaning this package, and it will probably be retired.

It should largely depend on either your personal interest in this tool and
whether you are aware of anyone still using it to compose music with it.
There have been many, more capable music tracker editors since the original
one from 1987.

There has been a v1.0.1-pre1 release for GTK2 in February 2020 (as update
for the 1.0.0 release from Dec 2019) while Fedora's package is stuck at
0.6.8 for GTK1. There is a branch for GTK3, too. Either one could help
with the FTBFS issue in case you want to keep this tool alive.
___
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] python-configobj - need Python 3 version for EPEL7 but RHEL ships python-configobj

[Felix Schwarz]

Hi,

I want to move certbot from Python 2 -> Python 3 in EPEL 7. As you might 
imagine this means getting Python3 packages of all required libraries. Most of 
them are pretty straight forward (I hope) - just build the Python 3 version 
also on EPEL 7.


However there is python-configobj which is provided by RHEL as a Python 2-only 
version.


What is the best way to get a Python 3 version for EPEL 7?
- Maybe the Fedora maintainers of python-configobj change the spec file so on
  EPEL 7 we only generate a Python 3 version?

- New package which is only used for EPEL 7?

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1813678 a while ago but 
noticed that it was assigned to "orphan owner" so I guess nobody every looked 
at it.


Felix
___
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: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

Hi,

On Fri, Apr 10, 2020 at 10:16 AM Olivier Fourdan 
wrote:

> On Fri, Apr 10, 2020 at 9:29 AM Olivier Fourdan 
> wrote:
>
>> On Fri, Apr 10, 2020 at 9:09 AM Adam Williamson <
>> adamw...@fedoraproject.org> wrote:
>>
>>>
>>> I think these do all look like the same problem. If we can verify a fix
>>> for this, an FE is probably reasonable...
>>>
>>>
>> Looks like I can reproduce locally, so this is not HW dependent (I mean,
>> other than using an intel GPU).
>>
>> I'll run a bisection to see what broke it.
>>
>
> Well, we might be lucky one that one, it looks like using a current git
> snapshot fixes the issue for me...
>
> If you want to give it a try, I ran a scratch build here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43186375
>
> Please let me know.
>

Humm, there is actually no (relevant) change in the code we use for Fedora
between the two git snapshots.

However, I noticed the current package was built in february and therefore
was built against the xserver 1.20.6 (as this was what we had in Fedora at
the time) while we upgraded to 1.20.7 mid march and then 1.20.8 recently.

As a test, I just rebuilt the current package (no change in the code) and
it works fine here, no more crash:

https://koji.fedoraproject.org/koji/taskinfo?taskID=43188723

So, FWIW, it looks like it might be just a matter of rebuilding the current
package to fix the issue.

Please let me know how that build works for you.

Cheers
Olivier
___
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: Call for testers for rpmautospec in staging

[Miro Hrončok]

On 10. 04. 20 1:50, Miro Hrončok wrote:

On 09. 04. 20 23:57, Miro Hrončok wrote:

On 09. 04. 20 20:45, Pierre-Yves Chibon wrote:

I actually cannot comment on this, it may be worth opening a koji ticket to ask
if this is the case or not and if it is if they can think of a way to deal with
this.


I plan to test this in staging and follow up on that, but possibly after Easter.


I was curious:

https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=90028113

CallbackError: Error running postSCMCheckout callback from 
_koji_plugin__rpmautospec_builder:

Traceback (most recent call last):
   File "/usr/lib/python3.7/site-packages/koji/plugin.py", line 195, in 
run_callbacks

     func(cbtype, *cb_args, **cb_kwargs)
   File "/usr/lib/koji-builder-plugins/rpmautospec_builder.py", line 91, in 
process_distgit_cb

     raise koji.BuildError("Installing `rpmautospec` into the build root 
failed.")
koji.BuildError: Installing `rpmautospec` into the build root failed.

Error:
  Problem: package python3-rpmautospec-0.1.3-1.fc33.noarch requires 
python3-koji, but none of the providers can be installed
   - package rpmautospec-0.1.3-1.fc33.noarch requires python3-rpmautospec = 
0.1.3-1.fc33, but none of the providers can be installed
   - package python3-koji-1.20.0-1.fc32.noarch requires python3-six, but none of 
the providers can be installed

   - conflicting requests
   - nothing provides this_is_broken_on_purpose needed by 
python3-six-1.12.0-8.fc33.noarch


So there are 2 reasonable things I think that can be done apart from rewriting 
rpmautospec into Rust ;)



## Koji side tag buildSRPMFromSCM self inavailability solution

Based on my testing, it is clear that builds from the on demand side tags 
(created with `fedpkg request-side-tag`) use the builds from its own side tag 
both in the actual buildArch tasks and in the buildSRPMFromSCM task.


OTOH I know we can have side tags that don't use their own builds  in neither 
task, for example the side tags we use for mass rebuilds behave this way.


So the actual question is: Can we have side tags that do both of the following 
things at the same time?


 - use their own builds in the buildArch tasks
 - don't see/use their own builds in the buildSRPMFromSCM tasks

(CCed Kevin, Mohan and Tomáš for this before I go file tickets.)

Pros:

1. I'd say that rpmautospec can't be the first thing ever that would need this 
kind fo treatment. We need to be able to bootstrap things that are used in 
buildSRPMFromSCM tasks, right?


2. No significant changes needed in rpmautospec.

Cons:

1. If Koji doesn't support this use case yet, it might require significant 
changes there.


2. If packages start using rpmautospec at scale, side tag must be always used to 
bootstrap anything in the dependency chain. While I'd very much like to see this 
happening regardless of rpmautospec, the truth is, that people do "simple chain 
builds" directly in rawhide all the time (e.g. gcc + annobin, 
python-cryptogtaphy-vectors + python-cryptogtaphy).


In the case of rpmautospec this means that if somebody bumps python3-urllib3 in 
rawhide first to go to bump python3-requests immediately after that, if the old 
requests don't install with the new urllib3 AND requests use %autorel, things 
will blow up, builds will need to be untagged and tagged to a new side tag just 
to untangle this.



## Move (most of) rpmautospec outside of the mock chroot

Another solution I can think of is that the koji-builder-plugin-rpmautospec 
package does all the nice things like figure out what to inject into the spec 
file and prepares everything for needed for rpmautospec *outside of the mock 
chroot*.


rpmautospec than in fact would only be responsible of actually putting the 
information into the specfile without using all the 3rd party Python libraries.
It would be a simple script (see fedpkg-minimal that exists for this very 
reason) -- keeping it in written in Python remain an option (as long as it only 
uses stdlib and doesn't live in site-packages), but making it Bash (like 
fedpkg-minimal) would be even less fragile.


However, what are the reasons to determine the spec content from within the 
buildroot? Does it heavily depend on values of macros like %fedora or %dist?


What parts of the procedure are safe to do from a different system and what 
needs to be done from within?


Pros:

1. Much more robust solution, smaller package footprint in buildSRPMFromSCM 
means smaller "bungle surface" (like "attack surface" but without the ill will).


Cons:

2. Significant (design) changes in rpmautospec needed.
3. I don't know the exact reasons rpmautospec runs from within the chroot.

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

Fedora-Cloud-31-20200410.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

On Fri, Apr 10, 2020 at 9:29 AM Olivier Fourdan  wrote:

> On Fri, Apr 10, 2020 at 9:09 AM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>>
>> I think these do all look like the same problem. If we can verify a fix
>> for this, an FE is probably reasonable...
>>
>>
> Looks like I can reproduce locally, so this is not HW dependent (I mean,
> other than using an intel GPU).
>
> I'll run a bisection to see what broke it.
>

Well, we might be lucky one that one, it looks like using a current git
snapshot fixes the issue for me...

If you want to give it a try, I ran a scratch build here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=43186375

Please let me know.

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

Fedora-Cloud-30-20200410.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: git-core deps under f32

[clime]

Dne pá 10. dub 2020 4:12 uživatel Todd Zullinger  napsal:

> I wrote:
> > clime wrote:
> >> It seems the f32's git-core got many more deps for some reason, even
> >> such as dbus-broker or systemd.
> [...]
> > I'll try to poke a bit in the next few days as I can make
> > some time.  I had not noticed the inflated depchain.  Thank
> > you for pointing it out.
>
> I was curious, so I looked at this tonight.  The git-core
> requires are the same on f31 and f32:
>
> $ diff -qs \
>   <(rpm -qp --requires git-core-2.25.2-1.fc31.x86_64.rpm 2>/dev/null) \
>   <(rpm -qp --requires git-core-2.26.0-1.fc32.x86_64.rpm 2>/dev/null)
> Files /dev/fd/63 and /dev/fd/62 are identical
>
> Checking each of those deps, openssh-clients grew a dep on
> libfido2, which in turn requires u2f-hidraw-policy that is
> provided by systemd.  That looks like the main chain which
> leads to the additional packages installed in a mock chroot.
>
> In a fedora 32 container (and most "regular" installs),
> systemd is already present, so the change should have very
> little impact outside of mock or other targets which are
> smaller than the default fedora 32 container image.
>
> I don't think that git-core should drop openssh-clients and
> it seems pretty reasonable for openssh-clients to require
> libfido2 to enable two factor authentication.
>
> Does that sound alright to you as well, clime?
>

Todd, thanks for looking at it. It sounds that everything is alright from
git-core's point of view, however the whole dep chain seems quite large.

I would like to install git-core into mock chroot to have git shell client
available to read git metadata of fedora package repository and
preproprecess spec file based on it. (side note: I don't actually even need
pulling/pushing/cloning but it is probably already impossible to have git
without those.)

Maybe u2f-hidraw-policy could be separated out from systemd? I probably
should open a request there.

Thanks again for your help! I am really happy git-core exists!
clime


> --
> Todd
> ___
> 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: Urgently downgrade xorg-x11-drv-intel

[Olivier Fourdan]

Hi,

On Fri, Apr 10, 2020 at 9:09 AM Adam Williamson 
wrote:

> On Fri, 2020-04-10 at 00:19 -0400, Alexei Podtelezhnikov wrote:
> > On Mon, Apr 6, 2020 at 12:57 PM Adam Jackson  wrote:
> > > And this mostly doesn't matter because we default to a different driver
> > > for most Intel hardware released since about 2006, with the notable
> > > exception of your (Alexei's) machine which was new as of about 2010.
> >
> > Please consider Freeze Exception for xorg-x11-drv-intel because not
> > just my old hardware is failing
> > Bug 1775929 is AMD Ryzen 7 2700X Eight-Core Processor
>
> I don't think this is the same bug - at least not the initial report
> from Mikhail. It's hard to tell about Martin's as he provided no logs.
> As I explained in
> https://bugzilla.redhat.com/show_bug.cgi?id=1775929#c10 , just the fact
> that X crashes in OsLookupColor means very little.
>
> > Bug 1808767 is Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
> > Bug 1818972 is Intel(R) Pentium(R) CPU N4200 @ 1.10GHz
> > Bug 1818605 is unknown
> > Bug 1820815 is my old Intel(R) Atom N550
>
> I think these do all look like the same problem. If we can verify a fix
> for this, an FE is probably reasonable...
>
>
Looks like I can reproduce locally, so this is not HW dependent (I mean,
other than using an intel GPU).

I'll run a bisection to see what broke it.

Cheers
Olivier
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Williamson]

On Fri, 2020-04-10 at 00:19 -0400, Alexei Podtelezhnikov wrote:
> On Mon, Apr 6, 2020 at 12:57 PM Adam Jackson  wrote:
> > And this mostly doesn't matter because we default to a different driver
> > for most Intel hardware released since about 2006, with the notable
> > exception of your (Alexei's) machine which was new as of about 2010.
> 
> Please consider Freeze Exception for xorg-x11-drv-intel because not
> just my old hardware is failing
> Bug 1775929 is AMD Ryzen 7 2700X Eight-Core Processor

I don't think this is the same bug - at least not the initial report
from Mikhail. It's hard to tell about Martin's as he provided no logs.
As I explained in 
https://bugzilla.redhat.com/show_bug.cgi?id=1775929#c10 , just the fact
that X crashes in OsLookupColor means very little.

> Bug 1808767 is Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
> Bug 1818972 is Intel(R) Pentium(R) CPU N4200 @ 1.10GHz
> Bug 1818605 is unknown
> Bug 1820815 is my old Intel(R) Atom N550

I think these do all look like the same problem. If we can verify a fix
for this, an FE is probably reasonable...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for testers for rpmautospec in staging

[Pierre-Yves Chibon]

On Fri, Apr 10, 2020 at 01:58:20AM +0200, Miro Hrončok wrote:
> On 09. 04. 20 15:43, Pierre-Yves Chibon wrote:
> > To remove some of the warnings thrown by `fedpkg` or to simply keep 
> > `rpmbuild`
> > working locally, you will have to install the `rpmautospec-rpm-macros` 
> > package
> > available in your nearest bodhi (it's still hot from the oven at the time of
> > writing this email so it hasn't made it yet to updates-testing).
> 
> There is also this warning:
> 
> $ fedpkg-stage build
> Could not execute build: Package 3dprinter-udev-rules-0.2.2-1.fc33 has
> already been built
> Note: You can skip this check with --skip-nvr-check. See help for more info.
> 
> Because locally, it always thinks I'm at release 1.fc33, but this has been
> already built. With --skip-nvr-check, it works, obviously.
> 
> I suppose this could be fixed (workarounded?) in fedpkg (it could default to
> --skip-nvr-check if it finds the %autorel macro in the spec).

Yes we're aware of this one and I thought we documented it but apparently we
only covered the part about the missing macros.

I'll add this to the doc, thanks!

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