experiencing dnf Error: Failed to synchronize cache for repo 'fedora' or ''updates'

[Michal Novotny]

Hello,

I am occasionally experiencing the following error in my day-to-day dnf use:

Failed to synchronize cache for repo 'fedora'

or

Failed to synchronize cache for repo 'updates'

I've had that happened even in local mock builds.

Do you also experience this error upon dnf operations like `dnf install` or
`dnf refresh` or in local mock builds?

Thank you
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RPRS3I7QTMLGLYXXRP2R3EQE3G2R6MY6/

Re: Auto-filing of FTBFS bugs gone wild

[Dan Callaghan]

Excerpts from Miro Hrončok's message of 2018-07-19 17:48 +02:00:
> I know it is not comfortable, yet at this point reverting the change 
> and doing another mass rebuild is IMHO more work than fixing the 
> packages.

Also, let me take this opportunity to give Koschei a shout-out.

I have it enabled on all my packages and the handful of packages which 
Igor's script did not automatically fix for me, Koschei immediately told 
me about. And I was able to fix them up earlier this week, before the 
FTBFS bugs were filed.

I strongly recommend everyone turns Koschei tracking on for all their 
packages because it makes it quite easy to find problems like this.

(Sadly, you do get a bit more noise when pushes something that breaks 
the entire distro, but it's still worth it.)

-- 
Dan Callaghan 
Senior Software Engineer, Products & Technologies DevOps
Red Hat


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

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

No offense but can you kindly rephrase whatever you said.Its kinda
difficult to decipher as your sentences seem to contradict.

On Thu, 19 Jul 2018, 20:06 Chris Murphy,  wrote:

> On Mon, Jul 16, 2018 at 10:49 AM, Manas Mangaonkar
>  wrote:
> > The Actual Url
> >
>
>
> I've got the copr enabled, but I can't figure out how to install the
> kernel. Even though I don't have -devel -cross-headers -headers for
> this kernel installed, those packages are included in a normal 'dnf
> update' for some reason. But not the kernel. And 'dnf install kernel'
> just points out the obvious, that kernels are already installed.
>
>
>
>
> --
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L4BZ6II4JKV3NSM7OSD5N2CDCQ2UBPV2/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QWAPE4BTIRTHPEANKXMXSDLZHCKOR7AM/

[Bug 1604806] New: rt-4.4.3 is available

[bugzilla]

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

Bug ID: 1604806
   Summary: rt-4.4.3 is available
   Product: Fedora
   Version: rawhide
 Component: rt
  Keywords: FutureFeature, Triaged
  Assignee: rc040...@freenet.de
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, ti...@math.uh.edu



Latest upstream release: 4.4.3
Current version/release in rawhide: 4.4.2-4.fc29
URL: http://bestpractical.com/request-tracker/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/7292/

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MCUHQZQINZWETPNBOZI4JUZW737V2ZEG/

[Bug 1604727] New: ctstream-28 is available

[bugzilla]

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

Bug ID: 1604727
   Summary: ctstream-28 is available
   Product: Fedora
   Version: rawhide
 Component: ctstream
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 28
Current version/release in rawhide: 27-4.fc29
URL: http://xpisar.wz.cz/ctstream/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/377/

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ABUWK6GBNCWQEKIBCLCJS5L4ILTH5S2W/

Re: Compilation issue after gcc removal

[Michael Schwendt]

On Fri, 20 Jul 2018 01:08:55 +0200, Marcin Zajączkowski wrote:

> On 2018-07-20 00:26, Artur Iwicki wrote:
> > I looked at libattr and in the changelog, there's this:  
> >> * Tue Jul 17 2018 Kamil Dudka  2.4.48-3
> >> - temporarily provide attr/xattr.h symlink until users are migrated 
> >> (#1601482)  
> > 
> > The bugzilla ticket says that attr/xattr.h was removed from libattr and is 
> > now a symlink to sys/xattr.h. Taking a look at those two files, the old 
> > attr/xattr.h has these lines in it:  
> >> #ifndef ENOATTR
> >> # define ENOATTR ENODATA/* No such attribute */
> >> #endif  
> > These are absent in sys/xattr.h, so the compiler rightfully complains that 
> > it does not know of ENOATTR. I guess you should either add a patch that 
> > replaces usages of ENOATTR to ENODATA, or a patch that adds this define 
> > somewhere.  
> 
> Thanks Artur for your findings! Trying to report that problem upstream I
> founded this thread: https://github.com/iustin/pyxattr/pull/15
> 
> I will give it a few days to work out some general way to solve it.

The fix is valid. It also affects other projects.
For reference:
http://git.savannah.nongnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M6FZOBL7LKNOMMEJBERIDIOMDNX3JWQH/

Compilation issue after gcc removal

[Marcin Zajączkowski]

On 2018-07-20 00:26, Artur Iwicki wrote:
> I looked at libattr and in the changelog, there's this:
>> * Tue Jul 17 2018 Kamil Dudka  2.4.48-3
>> - temporarily provide attr/xattr.h symlink until users are migrated 
>> (#1601482)
> 
> The bugzilla ticket says that attr/xattr.h was removed from libattr and is 
> now a symlink to sys/xattr.h. Taking a look at those two files, the old 
> attr/xattr.h has these lines in it:
>> #ifndef ENOATTR
>> # define ENOATTR ENODATA/* No such attribute */
>> #endif
> These are absent in sys/xattr.h, so the compiler rightfully complains that it 
> does not know of ENOATTR. I guess you should either add a patch that replaces 
> usages of ENOATTR to ENODATA, or a patch that adds this define somewhere.

Thanks Artur for your findings! Trying to report that problem upstream I
founded this thread: https://github.com/iustin/pyxattr/pull/15

I will give it a few days to work out some general way to solve it.

Marcin

-- 
https://blog.solidsoft.info/ - Working code is not enough
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XDBPYWNUBEMRVB3KH2BJGUGCTY2NTO5A/

audiofile package to become an orphan

[Michael Schwendt]

When I picked up the package in 2015, the upstream maintainer(s) apparently
had stopped the maintenance already. Meanwhile, there have been a few CVEs
and other fixes that have been ignored upstream. Recently, another CVE has
been assigned to an issue, and there isn't any upstream interest either.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DWV2ZWNYJH4IJXOHIIWV6WKHZNXCHLV6/

Re: Compilation issue after gcc removal

[Artur Iwicki]

I looked at libattr and in the changelog, there's this:
>* Tue Jul 17 2018 Kamil Dudka  2.4.48-3
>- temporarily provide attr/xattr.h symlink until users are migrated (#1601482)

The bugzilla ticket says that attr/xattr.h was removed from libattr and is now 
a symlink to sys/xattr.h. Taking a look at those two files, the old 
attr/xattr.h has these lines in it:
>#ifndef ENOATTR
># define ENOATTR ENODATA/* No such attribute */
>#endif
These are absent in sys/xattr.h, so the compiler rightfully complains that it 
does not know of ENOATTR. I guess you should either add a patch that replaces 
usages of ENOATTR to ENODATA, or a patch that adds this define somewhere.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XDBIKZGW62EI4T3TXH5EOIVHWEW2UZMU/

Compilation issue after gcc removal

[Marcin Zajączkowski]

Hi,

After the recent gcc removal from build root [1] I added explicit
dependency on gcc [2], but even though my pyxattr package started to
fail with [3][4]:
> xattr.c:532:56: error: 'ENOATTR' undeclared (first use in this function); did 
> you mean 'ENOTTY'?

I've checked it and ENOATTR should be defined in attr/xattr.h which is
provided by the build dependency - libattr-devel. In addition are
installed glibc-headers [5].

I haven't been programming in C for years. Do you know what can be a reason?


[1] - https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
[2] -
https://src.fedoraproject.org/rpms/pyxattr/c/3e584e38e14140ee9c4287cfcff75a79268ba3da?branch=master
[3] - https://kojipkgs.fedoraproject.org//work/tasks/2137/28452137/build.log
[4] - https://koji.fedoraproject.org/koji/taskinfo?taskID=28452137
[5] - https://kojipkgs.fedoraproject.org//work/tasks/2137/28452137/root.log

> gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
> -fstack-protector-strong -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
> -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -fexceptions -fstack-protector-strong -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
> -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
> -fstack-protector-strong -grecord-gcc-switches 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC 
> -D_XATTR_VERSION="0.5.3" -D_XATTR_AUTHOR="Iustin Pop" 
> -D_XATTR_EMAIL="iu...@k1024.org" -I/usr/include/python2.7 -c xattr.c -o 
> build/temp.linux-x86_64-2.7/xattr.o -Wall -Werror
> xattr.c: In function 'get_all':
> xattr.c:532:56: error: 'ENOATTR' undeclared (first use in this function); did 
> you mean 'ENOTTY'?
>  } else if(errno == ENODATA || errno == ENOATTR) {
> ^~~
> ENOTTY
> xattr.c:532:56: note: each undeclared identifier is reported only once for 
> each function it appears in
> error: command 'gcc' failed with exit status 1

Marcin

-- 
https://blog.solidsoft.info/ - Working code is not enough
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CX7NL6VOXD7JMM3Q2SZU7K46VS2SDITR/

Orphaning some of my packages

[Raphael Groner]

HI, 
I'll orphan the packages cpptest and dreamchess-tools because both currently 
FTBFS and I don't find any time to fix them in near future, besides I don't 
currently use those packages.
Maybe a simple add of BuildRequires: gcc-c++ would fix the builds. In case of 
cpptest, there's CppUTest [1] as a (better?) alternative where upstream looks 
to be more active.
Regards, Raphael

[1] http://cpputest.github.io
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EAWOV7OYNRDCSIYFREPW7AFS6CIAHW5V/

Re: Errors in compiling darktable subpackages

[Fabio Valentini]

On Thu, Jul 19, 2018 at 9:28 PM Germano Massullo
 wrote:
>
> I am working on adding more features to darktable (basecurve tool and noise 
> tool subpackages).
>
> In log [1] from line
>
> BUILDSTDERR: /usr/bin/ld: CMakeFiles/dt-curve-tool.dir/dt-curve-tool.c.o: 
> relocation R_X86_64_32S against symbol `spline_set' can not be used when 
> making a shared object; recompile with -fPIC

I used to get these errors too for some of my packages. It turned out
that upstream made some mistakes in their CMakeLists.txt files:
The errors were usually caused by some CMakeLists.txt file overriding
the system-provided CFLAGS with something else, instead of only
appending necessary flags.

I hope that helps.

Fabio

> there are many errors, and I don't understand if they are upstream 
> programming errors or more likely errors in my spec file.
>
> Build URL is 
> https://copr.fedorainfracloud.org/coprs/germano/darktable_2_4/build/779148/
>
> Thank you for your time
>
> [1]: 
> https://copr-be.cloud.fedoraproject.org/results/germano/darktable_2_4/fedora-28-x86_64/00779148-darktable/build.log.gz
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MAALXQOLRTKJVLMKDCDLFBJZFMCJLB5Z/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A5V7VDH7PA3UNGBRO32O27FP3RS6NWKC/

[Bug 1602758] perl-Thread-Queue-3.13 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Thread-Queue-3.13-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7410f335d2

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TOBHP7VUUK5KWGZOMPEDWCNHP4A3XNBB/

Re: Auto-filing of FTBFS bugs gone wild

[Igor Gnatenko]

On Thu, Jul 19, 2018 at 6:13 PM Hans de Goede  wrote:

> Hi,
>
> On 19-07-18 17:42, Igor Gnatenko wrote:
> > On Thu, Jul 19, 2018 at 5:33 PM Hans de Goede  > wrote:
> >
> > Hi All,
> >
> > I've just got 20 bugs auto-filed against packages which I co-maintain
> > and that is just for packages starting with the letter 'a'.
> >
> > A quick check shows that these are all caused by a missing
> > BuildRequires on gcc / g++ related to:
> >
> > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> >
> > I'm not sure if this means that the FTBFS script has been run before
> > all the automatic fixing which was planned for this was in place;
> > or if this means that the automatic fixing missed many many
> > packages, but either way something needs to happen here, the amount
> > of work now being pushed onto packagers caused by:
> >
> > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> >
> > Is unacceptable IMHO.
> >
> > If the FTBFS script has ran too early, all the FTBFS bugs need to be
> > closed and the FTBFS script has to be run again later.
> >
> > If the automatic BuildRequires fixing script missed all these, then
> > I suggest that:
> >
> > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> >
> > Gets reverted for now and we again close all the FTBFS bugs and
> > rerun the script for them after doing a fresh build with the
> > buildroot restored as it was.
> >
> >
> > No one promised that I'm going to fix 100% of packages, I've fixed
> around 2k packages. What my regex couldn't catch -- please send me list of
> packages, I will analyze them and try to fix as much as possible.
>
> Ok, thank you for offering to take a look at this. Here are the
> FTBFS bugs which I've received so far, it seems that the bot
> has stopped filing bugs after getting through all packages
> starting with a-b? Or no packages which I co-maintain have
> failed starting with c-z??
>
> Anyways here is the list so far. Note I've not yet analyzed
> these, so some might have a different cause, feel free to
> leave those as is and I will get around to them eventually.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1603260
> https://bugzilla.redhat.com/show_bug.cgi?id=1603263
> https://bugzilla.redhat.com/show_bug.cgi?id=1603266
> https://bugzilla.redhat.com/show_bug.cgi?id=1603267
> https://bugzilla.redhat.com/show_bug.cgi?id=1603274
> https://bugzilla.redhat.com/show_bug.cgi?id=1603319
> https://bugzilla.redhat.com/show_bug.cgi?id=1603321
> https://bugzilla.redhat.com/show_bug.cgi?id=1603348
> https://bugzilla.redhat.com/show_bug.cgi?id=1603351
> https://bugzilla.redhat.com/show_bug.cgi?id=1603365
> https://bugzilla.redhat.com/show_bug.cgi?id=1603366
> https://bugzilla.redhat.com/show_bug.cgi?id=1603369
> https://bugzilla.redhat.com/show_bug.cgi?id=1603383
> https://bugzilla.redhat.com/show_bug.cgi?id=1603398
> https://bugzilla.redhat.com/show_bug.cgi?id=1603410
> https://bugzilla.redhat.com/show_bug.cgi?id=1603431
> https://bugzilla.redhat.com/show_bug.cgi?id=1603456
> https://bugzilla.redhat.com/show_bug.cgi?id=1603457
> https://bugzilla.redhat.com/show_bug.cgi?id=1603503
> https://bugzilla.redhat.com/show_bug.cgi?id=1603506


I've fixed regex a bit and fixed ~150 more packages.

I believe that the rest could be done by maintainers.
-- 

-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7KIII23YPP62PU335FAEAPHXOAOQEZEZ/

Errors in compiling darktable subpackages

[Germano Massullo]

I am working on adding more features to darktable (basecurve tool and
noise tool subpackages).

In log [1] from line

BUILDSTDERR: /usr/bin/ld:
CMakeFiles/dt-curve-tool.dir/dt-curve-tool.c.o: relocation R_X86_64_32S
against symbol `spline_set' can not be used when making a shared object;
recompile with -fPIC

there are many errors, and I don't understand if they are upstream
programming errors or more likely errors in my spec file.

Build URL is
https://copr.fedorainfracloud.org/coprs/germano/darktable_2_4/build/779148/

Thank you for your time

[1]:
https://copr-be.cloud.fedoraproject.org/results/germano/darktable_2_4/fedora-28-x86_64/00779148-darktable/build.log.gz

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

Fedora Rawhide-20180719.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 29/138 (x86_64), 24/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180714.n.0):

ID: 258720  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/258720
ID: 258728  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/258728
ID: 258735  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/258735
ID: 258737  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/258737
ID: 258742  Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/258742
ID: 258745  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/258745
ID: 258758  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/258758
ID: 258779  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/258779
ID: 258799  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/258799
ID: 258802  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/258802
ID: 258804  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/258804
ID: 258805  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/258805
ID: 258815  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/258815
ID: 258816  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/258816
ID: 258821  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/258821
ID: 258832  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/258832
ID: 258837  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/258837
ID: 258864  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/258864
ID: 258882  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/258882

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

ID: 258743  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/258743
ID: 258744  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/258744
ID: 258747  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/258747
ID: 258748  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/258748
ID: 258749  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/258749
ID: 258760  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/258760
ID: 258764  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/258764
ID: 258765  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/258765
ID: 258766  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/258766
ID: 258780  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/258780
ID: 258781  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/258781
ID: 258810  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/258810
ID: 258819  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/258819
ID: 258839  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/258839
ID: 258840  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/258840
ID: 258841  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/258841
ID: 258842  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/258842
ID: 258854  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/258854
ID: 258863  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/258863
ID: 258867  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/258867
ID: 258868  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/258868
ID: 258869  Test: i386 universal install_simple_encrypted
URL: 

Re: Again, please announce your so-name bumps!

[Adam Williamson]

On Thu, 2018-07-19 at 09:59 -0700, Adam Williamson wrote:
> On Thu, 2018-07-19 at 08:19 +0200, Christian Dersch wrote:
> > Hi all,
> > 
> > please announce your so-name bumps *before* you push them. This time LibRaw
> > bumped its version, as a result we have broken dependencies and some
> > composes like Astronomy spin fail to build…
> > 
> >  Problem 1: conflicting requests
> >   - nothing provides libraw.so.16()(64bit) needed by 
> > siril-0.9.9-2.fc29.x86_64
> >  Problem 2: conflicting requests
> >   - nothing provides libraw.so.16()(64bit) needed by
> > kstars-1:2.9.6-2.fc29.x86_64
> >  Problem 3: conflicting requests
> >   - nothing provides libraw.so.16()(64bit) needed by
> > indi-gphoto-1.7.2-2.fc29.x86_64
> >  Problem 4: conflicting requests
> >   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
> > libgegl-0.4.so.0()(64bit), but none of the providers can be installed
> >   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
> > libgegl-npd-0.4.so()(64bit), but none of the providers can be
> > installed
> >   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires gegl04(x86-64) >=
> > 0.4.4, but none of the providers can be installed
> >   - nothing provides libraw.so.16()(64bit) needed by 
> > gegl04-0.4.4-1.fc29.x86_64
> > 
> > I'm going to rebuild gimp, indi-gphoto, kstars and siril now. But I'm sure
> > there are more broken dependencies.
> 
> Here's the others:
> 
> LibRaw-0.18.12-1.fc29.src.rpm
> deepin-image-viewer-1.2.16.8-1.fc29.src.rpm
> efl-1.20.7-2.fc29.src.rpm
> elementary-photos-0.2.5-2.fc29.src.rpm
> fotoxx-18.01.3-1.fc29.src.rpm
> freeimage-3.17.0-14.fc28.src.rpm
> gegl03-0.3.30-1.fc29.src.rpm
> gegl04-0.4.4-1.fc29.src.rpm
> gthumb-3.6.1-1.fc29.src.rpm
> kf5-libkdcraw-18.04.2-1.fc29.src.rpm
> krita-4.1.0-1.fc29.src.rpm
> nomacs-3.8.1-0.1.20180223git9b305e2.fc29.src.rpm
> oyranos-0.9.5-25.fc28.src.rpm
> photoqt-1.7.1-1.fc29.src.rpm
> shotwell-0.28.3-2.fc29.src.rpm

I think all will shortly be done except fotoxx, krita and kf5-libkdcraw 
. krita and kf5-libkdcraw seem to actually need changing for libraw API
changes, rdieter is looking into this. fotoxx is FTBFS with a bunch of
"error: reference to (FOO) is ambiguous" errors, and I'm not really
inclined to try and fix that right now.
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ANURYO2S3JKVOILOX7NJVT5QELOKMI5I/

Re: Intent to orphan js-jquery1 and js-jquery2

[Christopher]

On Wed, Jul 18, 2018 at 1:32 AM Christopher 
wrote:

> It is my intention to orphan js-jquery1 and js-jquery2. Does anybody want
> to take them over?
>
> These very old versions of jQuery have security issues that I do not have
> time nor expertise to maintain. Upstream's last patch for either of these
> occurred over 2 years ago. Everybody should be using jQuery 3 by now
> (js-jquery). Anything older is insecure and unsafe.
>
> Personally, I think they should be retired, but I don't know (or have time
> to check) to see if that would cause problems for anybody.
>
>
I've orphaned js-jquery1 and js-jquery2.

For those packages which still depend on them, I strongly recommend that
you update your package to depend on the latest version of js-jquery.

Also, as an aside, I noticed that jquery1 appears to be bundled into
nodejs-flot; that should be fixed. In fact, I think nodejs-flot and
ghc-js-flot need to coordinate to remove the duplication, since they are
both are packaging flot... but in very different ways.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MI7W7TT3MUGMQTLYZYE5FKXUJCKFUXU7/

[Bug 1591449] CVE-2018-10860 perl-Archive-Zip: Directory traversal in Archive::Zip

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-Archive-Zip-1.60-3.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/66XZLT75LKZJNYLTUQ7EQWLA4H46KSEA/

[Bug 1596132] CVE-2018-10860 perl-Archive-Zip: Directory traversal in Archive::Zip [fedora-all]

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Archive-Zip-1.60-3.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/S2AQJW2B6HTLOT34K4X2J454V6UZYO4U/

[Bug 1591449] CVE-2018-10860 perl-Archive-Zip: Directory traversal in Archive::Zip

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Archive-Zip-1.59-6.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/QVI7PZHZ3OVFJLDZBGHHMOS32GKHZUMR/

[Bug 1596132] CVE-2018-10860 perl-Archive-Zip: Directory traversal in Archive::Zip [fedora-all]

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Archive-Zip-1.59-6.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GK3CEEHZKN6LWCANQQ37LCQSXZK3R2EQ/

Re: Again, please announce your so-name bumps!

[Christian Dersch]

On 19/07/18 18:59, Adam Williamson wrote:

On Thu, 2018-07-19 at 08:19 +0200, Christian Dersch wrote:

Hi all,

please announce your so-name bumps *before* you push them. This time LibRaw
bumped its version, as a result we have broken dependencies and some
composes like Astronomy spin fail to build…

  Problem 1: conflicting requests
   - nothing provides libraw.so.16()(64bit) needed by siril-0.9.9-2.fc29.x86_64
  Problem 2: conflicting requests
   - nothing provides libraw.so.16()(64bit) needed by
kstars-1:2.9.6-2.fc29.x86_64
  Problem 3: conflicting requests
   - nothing provides libraw.so.16()(64bit) needed by
indi-gphoto-1.7.2-2.fc29.x86_64
  Problem 4: conflicting requests
   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
libgegl-0.4.so.0()(64bit), but none of the providers can be installed
   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
libgegl-npd-0.4.so()(64bit), but none of the providers can be
installed
   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires gegl04(x86-64) >=
0.4.4, but none of the providers can be installed
   - nothing provides libraw.so.16()(64bit) needed by gegl04-0.4.4-1.fc29.x86_64

I'm going to rebuild gimp, indi-gphoto, kstars and siril now. But I'm sure
there are more broken dependencies.

Here's the others:

LibRaw-0.18.12-1.fc29.src.rpm
deepin-image-viewer-1.2.16.8-1.fc29.src.rpm
efl-1.20.7-2.fc29.src.rpm
elementary-photos-0.2.5-2.fc29.src.rpm
fotoxx-18.01.3-1.fc29.src.rpm
freeimage-3.17.0-14.fc28.src.rpm
gegl03-0.3.30-1.fc29.src.rpm
gegl04-0.4.4-1.fc29.src.rpm
gthumb-3.6.1-1.fc29.src.rpm
kf5-libkdcraw-18.04.2-1.fc29.src.rpm
krita-4.1.0-1.fc29.src.rpm
nomacs-3.8.1-0.1.20180223git9b305e2.fc29.src.rpm
oyranos-0.9.5-25.fc28.src.rpm
photoqt-1.7.1-1.fc29.src.rpm
shotwell-0.28.3-2.fc29.src.rpm

Note gimp didn't actually need rebuilding - its issue is via gegl04 ,
as the message shows.


Yes, this is what I actually did (gegl04 rebuild), gimp itself was a 
mistake in my mail.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4I3YJ7XSK6QACFKAWFVCXGZZDAEE2WBS/

Re: F29 Self-Contained Change: Basic FPGA Support

[Justin Forbes]

On Wed, Jul 18, 2018 at 4:26 PM, Ben Cotton  wrote:

> == Summary ==
> A number of devices like Xilinx ZYNQ based devices such as the
> 96boards Ultra96 and the Intel based UP² have onboard FPGAs. FPGA
> manager is a vendor-neutral framework that has been upstream in the
> kernel since 4.4. This is the initial support for FPGAs in Fedora
> using open source vendor agnostic tools.
>
> == Owner ==
> * Name: Peter Robinson
> * Email: pbrobinson at fedora project dot org
>
> == Detailed Description ==
>
> The use of Artificial Intelligence and Machine Learning is growing.
> There's a number types of compute power used to drive this, the
> standard system CPU can handle basic work, but for more powerful needs
> this workload gets moved to auxiliary processors such as GPGPU, FPGAs
> or Neural Network processors. This will add initial support for FPGAs
> in Fedora using the Linux Kernel support which currently supports
> Altera,  Zynq, Lattice and other FPGAs. The use of FPGAs with Open
> Source software is improving and this is the beginning of ensuring
> that can be consumed in Fedora as easily as possible.
>
> == Benefit to Fedora ==
>
> The general purpose use of FPGAs is growing in the tech industry,
> especially in AI and Machine Learning usecases for IoT and numerous
> other places where special purpose workload acceleration is needed.
> This will help developing these workloads on top of Fedora for use
> across the distribution.
>
> == Scope ==
> * Proposal owners: Kernel and userspace changes
>

Is there a list of the proposed kernel changes anywhere?


>
> * Other developers: N/A (not a System Wide Change)
>
> == Upgrade/compatibility impact ==
> There is no impact to upgrades or platforms that don't contain FPGAs.
>
> == How To Test ==
> Testing will require hardware with a supported FPGA. The initial
> devices for this will be a 96boards Ultra96 or a UP² with a Altera
> FPGA. Other devices will be supported and testing will be welcome.
>
> The process for testing will be linked to here.
>
> == User Experience ==
> Currently the Fedora support for FPGAs is basically non existent.
> There's currently a few open tools for specific FPGAs. This is the
> beginning of improving this with the intention of having a uniform as
> possible  user experience across FPGAs as is currently possible.
>
>
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/PNQJ3E4GC4AITL3VMJ5OVZK2MGW2TTLL/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LJ27WRBNUSTT47SA3SGQV7OOPHOWEJCB/

Re: Again, please announce your so-name bumps!

[Adam Williamson]

On Thu, 2018-07-19 at 09:59 -0700, Adam Williamson wrote:
> On Thu, 2018-07-19 at 08:19 +0200, Christian Dersch wrote:
> > Hi all,
> > 
> > please announce your so-name bumps *before* you push them. This time LibRaw
> > bumped its version, as a result we have broken dependencies and some
> > composes like Astronomy spin fail to build…
> > 
> >  Problem 1: conflicting requests
> >   - nothing provides libraw.so.16()(64bit) needed by 
> > siril-0.9.9-2.fc29.x86_64
> >  Problem 2: conflicting requests
> >   - nothing provides libraw.so.16()(64bit) needed by
> > kstars-1:2.9.6-2.fc29.x86_64
> >  Problem 3: conflicting requests
> >   - nothing provides libraw.so.16()(64bit) needed by
> > indi-gphoto-1.7.2-2.fc29.x86_64
> >  Problem 4: conflicting requests
> >   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
> > libgegl-0.4.so.0()(64bit), but none of the providers can be installed
> >   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
> > libgegl-npd-0.4.so()(64bit), but none of the providers can be
> > installed
> >   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires gegl04(x86-64) >=
> > 0.4.4, but none of the providers can be installed
> >   - nothing provides libraw.so.16()(64bit) needed by 
> > gegl04-0.4.4-1.fc29.x86_64
> > 
> > I'm going to rebuild gimp, indi-gphoto, kstars and siril now. But I'm sure
> > there are more broken dependencies.
> 
> Here's the others:

BTW, I suspect what may have happened here is the bump was
inadvertently introduced by the mass rebuild. It looks like Gwyn
committed the bump to 0.19 to dist-git on 2018-06-29 but (presumably
intentionally) did not actually *build* it - there is no 0.19 build
prior to the 0.19.0-2.fc29 that was done by the mass rebuild. So I
think perhaps Gwyn was waiting to be ready to rebuild all the
dependencies, but things got pre-empted by the mass rebuild :/

I'm working through the list now. So far it looks like kf5-libkdcraw
and krita (which actually appears to have a bundled copy of the same
library:
https://github.com/KDE/krita/tree/master/plugins/impex/raw/3rdparty/libkdcraw )
need actual code changes to build with 0.19.
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NIQ6YZ3JO6NFHZQAXX3NUATNYM6XHCM4/

[Bug 1602758] perl-Thread-Queue-3.13 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Thread-Queue-3.13-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4a9eacc23e

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/H7MKHNNXEPJPCBZWRZDOJF27X54HQMKI/

Re: F29 Self-Contained Change: Basic FPGA Support

[Thomas Daede]

On 07/18/2018 02:26 PM, Ben Cotton wrote:
> == User Experience ==
> Currently the Fedora support for FPGAs is basically non existent.
> There's currently a few open tools for specific FPGAs. This is the
> beginning of improving this with the intention of having a uniform as
> possible  user experience across FPGAs as is currently possible.

There is zero overlap between the open tools for FPGAs and the FPGAs
supported by the kernel FPGA manager right now. You should limit the
scope of this change to the FPGAs you actually want to support.

I wouldn't actually mind the open tools getting packaged (icestrom,
yosys, arachne-pnr, abc, tinyprog) but you should be clear if you're
doing that or not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CTKWEQ6EK45RXK6UBA734H2Z6V2YBOD3/

Re: Again, please announce your so-name bumps!

[Adam Williamson]

On Thu, 2018-07-19 at 08:19 +0200, Christian Dersch wrote:
> Hi all,
> 
> please announce your so-name bumps *before* you push them. This time LibRaw
> bumped its version, as a result we have broken dependencies and some
> composes like Astronomy spin fail to build…
> 
>  Problem 1: conflicting requests
>   - nothing provides libraw.so.16()(64bit) needed by siril-0.9.9-2.fc29.x86_64
>  Problem 2: conflicting requests
>   - nothing provides libraw.so.16()(64bit) needed by
> kstars-1:2.9.6-2.fc29.x86_64
>  Problem 3: conflicting requests
>   - nothing provides libraw.so.16()(64bit) needed by
> indi-gphoto-1.7.2-2.fc29.x86_64
>  Problem 4: conflicting requests
>   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
> libgegl-0.4.so.0()(64bit), but none of the providers can be installed
>   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
> libgegl-npd-0.4.so()(64bit), but none of the providers can be
> installed
>   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires gegl04(x86-64) >=
> 0.4.4, but none of the providers can be installed
>   - nothing provides libraw.so.16()(64bit) needed by 
> gegl04-0.4.4-1.fc29.x86_64
> 
> I'm going to rebuild gimp, indi-gphoto, kstars and siril now. But I'm sure
> there are more broken dependencies.

Here's the others:

LibRaw-0.18.12-1.fc29.src.rpm
deepin-image-viewer-1.2.16.8-1.fc29.src.rpm
efl-1.20.7-2.fc29.src.rpm
elementary-photos-0.2.5-2.fc29.src.rpm
fotoxx-18.01.3-1.fc29.src.rpm
freeimage-3.17.0-14.fc28.src.rpm
gegl03-0.3.30-1.fc29.src.rpm
gegl04-0.4.4-1.fc29.src.rpm
gthumb-3.6.1-1.fc29.src.rpm
kf5-libkdcraw-18.04.2-1.fc29.src.rpm
krita-4.1.0-1.fc29.src.rpm
nomacs-3.8.1-0.1.20180223git9b305e2.fc29.src.rpm
oyranos-0.9.5-25.fc28.src.rpm
photoqt-1.7.1-1.fc29.src.rpm
shotwell-0.28.3-2.fc29.src.rpm

Note gimp didn't actually need rebuilding - its issue is via gegl04 ,
as the message shows.
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AFKGDP2UDBHGLW5O3ZJJXMOU4BETIVFV/

Re: [EPEL-devel] Re: python 2 retirement commo efforts

[R P Herrold]

On Thu, 19 Jul 2018, Miro Hrončok wrote:

> > The ** POINT ** of producing such a report is to  'put
> > numbers' on the scope of the work rather than loose armwaving
> > assertions such as:
> > 
> > > Fedora still has more than 3000 packages depending on
> > > python2 – many more than we can support without upstream
> > > help.
> 
> Those are real Fedora numbers [0]. No armwaving involved.
> 
> 1311 python2 only packages
> 1734 python2+python3 packages
> + 88 with packaging problem where I'm not sure
> 
> That is something between 3045 and 3133. That can be rounded to 3k.
> 
> No idea why we moved the discussion to another list as well, but stop accusing
> us from armwaving. We have data (for Fedora, because that where we started the
> discussion). As for RHEL/EPEL: current ones can remain as they are. Future
> ones see [1].

"accusing" ?  I think it is pretty clear that more than a 
little projection is going on here.  I offered a description 
of methodology, hard numbers on six archives, and the 
generation script to nail down numbers.  Before your most 
recent email,  nope

The _reason_ that it was off an EPEL thread (EPEL of course 
being PART OF FEDORAPROJECT, last time I looked) is that is 
the harder one to solve, and also there was a thread going as 
to planning a meeting, of which that hard data was a part


If I go to a car dealer and seek to buy a car and ask a price, 
and am told by the salesperson:

"more than 3000" dollars

they have not yet not told me a price they will sell the car 
at

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E4FYVZMRWLMIQ6L7PIJMBV6R2K4GMD7C/

Re: Auto-filing of FTBFS bugs gone wild

[Hans de Goede]

Hi,

On 19-07-18 17:42, Igor Gnatenko wrote:

On Thu, Jul 19, 2018 at 5:33 PM Hans de Goede mailto:hdego...@redhat.com>> wrote:

Hi All,

I've just got 20 bugs auto-filed against packages which I co-maintain
and that is just for packages starting with the letter 'a'.

A quick check shows that these are all caused by a missing
BuildRequires on gcc / g++ related to:

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

I'm not sure if this means that the FTBFS script has been run before
all the automatic fixing which was planned for this was in place;
or if this means that the automatic fixing missed many many
packages, but either way something needs to happen here, the amount
of work now being pushed onto packagers caused by:

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

Is unacceptable IMHO.

If the FTBFS script has ran too early, all the FTBFS bugs need to be
closed and the FTBFS script has to be run again later.

If the automatic BuildRequires fixing script missed all these, then
I suggest that:

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

Gets reverted for now and we again close all the FTBFS bugs and
rerun the script for them after doing a fresh build with the
buildroot restored as it was.


No one promised that I'm going to fix 100% of packages, I've fixed around 2k 
packages. What my regex couldn't catch -- please send me list of packages, I 
will analyze them and try to fix as much as possible.


Ok, thank you for offering to take a look at this. Here are the
FTBFS bugs which I've received so far, it seems that the bot
has stopped filing bugs after getting through all packages
starting with a-b? Or no packages which I co-maintain have
failed starting with c-z??

Anyways here is the list so far. Note I've not yet analyzed
these, so some might have a different cause, feel free to
leave those as is and I will get around to them eventually.

https://bugzilla.redhat.com/show_bug.cgi?id=1603260
https://bugzilla.redhat.com/show_bug.cgi?id=1603263
https://bugzilla.redhat.com/show_bug.cgi?id=1603266
https://bugzilla.redhat.com/show_bug.cgi?id=1603267
https://bugzilla.redhat.com/show_bug.cgi?id=1603274
https://bugzilla.redhat.com/show_bug.cgi?id=1603319
https://bugzilla.redhat.com/show_bug.cgi?id=1603321
https://bugzilla.redhat.com/show_bug.cgi?id=1603348
https://bugzilla.redhat.com/show_bug.cgi?id=1603351
https://bugzilla.redhat.com/show_bug.cgi?id=1603365
https://bugzilla.redhat.com/show_bug.cgi?id=1603366
https://bugzilla.redhat.com/show_bug.cgi?id=1603369
https://bugzilla.redhat.com/show_bug.cgi?id=1603383
https://bugzilla.redhat.com/show_bug.cgi?id=1603398
https://bugzilla.redhat.com/show_bug.cgi?id=1603410
https://bugzilla.redhat.com/show_bug.cgi?id=1603431
https://bugzilla.redhat.com/show_bug.cgi?id=1603456
https://bugzilla.redhat.com/show_bug.cgi?id=1603457
https://bugzilla.redhat.com/show_bug.cgi?id=1603503
https://bugzilla.redhat.com/show_bug.cgi?id=1603506

Regards,

Hans

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

Re: Auto-filing of FTBFS bugs gone wild

[Miro Hrončok]

On 19.7.2018 17:15, Hans de Goede wrote:

Hi All,

I've just got 20 bugs auto-filed against packages which I co-maintain
and that is just for packages starting with the letter 'a'.

A quick check shows that these are all caused by a missing
BuildRequires on gcc / g++ related to:

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

I'm not sure if this means that the FTBFS script has been run before
all the automatic fixing which was planned for this was in place;
or if this means that the automatic fixing missed many many
packages, but either way something needs to happen here, the amount
of work now being pushed onto packagers caused by:

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

Is unacceptable IMHO.

If the FTBFS script has ran too early, all the FTBFS bugs need to be
closed and the FTBFS script has to be run again later.

If the automatic BuildRequires fixing script missed all these, then
I suggest that:

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

Gets reverted for now and we again close all the FTBFS bugs and
rerun the script for them after doing a fresh build with the
buildroot restored as it was.


I know it is not comfortable, yet at this point reverting the change and 
doing another mass rebuild is IMHO more work than fixing the packages.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NXHWPD63ESIUVSDLTHSC3S53663RTCUT/

Re: Again, please announce your so-name bumps!

[Rex Dieter]

Christian Dersch wrote:

> Hi all,
> 
> please announce your so-name bumps *before* you push them. This time
> LibRaw bumped its version

I added explicit soname tracking there so hopefully it won't happen again 
(at least not by surprise),

https://src.fedoraproject.org/rpms/LibRaw/c/7b3e5da5e27adb2872bb3a54dc0386e01cc77d0e

-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3ICMGY5KBI2ARQCCMCY4UXYXOCETKTCU/

Re: Auto-filing of FTBFS bugs gone wild

[Hans de Goede]

Hi,

On 19-07-18 17:30, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Jul 19, 2018 at 05:15:47PM +0200, Hans de Goede wrote:

Hi All,

I've just got 20 bugs auto-filed against packages which I co-maintain
and that is just for packages starting with the letter 'a'.

A quick check shows that these are all caused by a missing
BuildRequires on gcc / g++ related to:

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

I'm not sure if this means that the FTBFS script has been run before
all the automatic fixing which was planned for this was in place;
or if this means that the automatic fixing missed many many
packages, but either way something needs to happen here, the amount
of work now being pushed onto packagers caused by:

The patches adding BR have already been pushed, but, as shown above,
they missed many cases. I think it's probably best to report the missed
ones to ignatenko.


I'm not sure how reporting these to ignatenko is going to help, once I
know what the issue is I can fix it myself trivially. Unless
ignatenko is going to use this to improve his script and do another
run and then something is going to auto-close fixed FTBFS errors ?

Anyways here are the 2 which I've checked sofar which both seem to be a
missing BR on g++:

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

Regards,

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

Re: Auto-filing of FTBFS bugs gone wild

[Igor Gnatenko]

On Thu, Jul 19, 2018 at 5:33 PM Hans de Goede  wrote:

> Hi All,
>
> I've just got 20 bugs auto-filed against packages which I co-maintain
> and that is just for packages starting with the letter 'a'.
>
> A quick check shows that these are all caused by a missing
> BuildRequires on gcc / g++ related to:
>
> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
>
> I'm not sure if this means that the FTBFS script has been run before
> all the automatic fixing which was planned for this was in place;
> or if this means that the automatic fixing missed many many
> packages, but either way something needs to happen here, the amount
> of work now being pushed onto packagers caused by:
>
> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
>
> Is unacceptable IMHO.
>
> If the FTBFS script has ran too early, all the FTBFS bugs need to be
> closed and the FTBFS script has to be run again later.
>
> If the automatic BuildRequires fixing script missed all these, then
> I suggest that:
>
> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
>
> Gets reverted for now and we again close all the FTBFS bugs and
> rerun the script for them after doing a fresh build with the
> buildroot restored as it was.
>

No one promised that I'm going to fix 100% of packages, I've fixed around
2k packages. What my regex couldn't catch -- please send me list of
packages, I will analyze them and try to fix as much as possible.
-- 

-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TJTXELL4KMVCWX3FOKZQPTUJL3VZ3H6V/

Re: Update to scotch-6.0.6

[Sandro Mani]

On 19.07.2018 13:35, Sandro Mani wrote:

Hi

I'm updating to scotch-6.0.6, which carries a soname bump. I'll 
rebuild the following dependent packages:


hypre
mmg
MUMPS
petsc
qrmumps
superlu_dist

I've done a test run in this [1] COPR repo and all dependencies built 
successfully.

All rebuilds have now successfully completed.

Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YG73VPNGG3LORSSUM27SDZ3NBG2NHFFB/

Re: Auto-filing of FTBFS bugs gone wild

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 19, 2018 at 05:15:47PM +0200, Hans de Goede wrote:
> Hi All,
> 
> I've just got 20 bugs auto-filed against packages which I co-maintain
> and that is just for packages starting with the letter 'a'.
> 
> A quick check shows that these are all caused by a missing
> BuildRequires on gcc / g++ related to:
> 
> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> 
> I'm not sure if this means that the FTBFS script has been run before
> all the automatic fixing which was planned for this was in place;
> or if this means that the automatic fixing missed many many
> packages, but either way something needs to happen here, the amount
> of work now being pushed onto packagers caused by:
The patches adding BR have already been pushed, but, as shown above,
they missed many cases. I think it's probably best to report the missed
ones to ignatenko.

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

Auto-filing of FTBFS bugs gone wild

[Hans de Goede]

Hi All,

I've just got 20 bugs auto-filed against packages which I co-maintain
and that is just for packages starting with the letter 'a'.

A quick check shows that these are all caused by a missing
BuildRequires on gcc / g++ related to:

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

I'm not sure if this means that the FTBFS script has been run before
all the automatic fixing which was planned for this was in place;
or if this means that the automatic fixing missed many many
packages, but either way something needs to happen here, the amount
of work now being pushed onto packagers caused by:

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

Is unacceptable IMHO.

If the FTBFS script has ran too early, all the FTBFS bugs need to be
closed and the FTBFS script has to be run again later.

If the automatic BuildRequires fixing script missed all these, then
I suggest that:

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

Gets reverted for now and we again close all the FTBFS bugs and
rerun the script for them after doing a fresh build with the
buildroot restored as it was.

Regards,

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  39  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c4ebc0d2d   
wordpress-4.9.7-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d801e05f92   
uwsgi-2.0.17.1-1.el6


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

aha-0.4.10.6-2.el6
gitolite3-3.6.8-1.el6
globus-ftp-control-8.5-1.el6
globus-gridftp-server-12.7-1.el6
globus-gridftp-server-control-6.3-1.el6
icat-0.5-2.el6
libpng10-1.0.69-5.el6
singularity-2.5.99-1.1.el6

Details about builds:



 aha-0.4.10.6-2.el6 (FEDORA-EPEL-2018-c6bff39762)
 Convert terminal output to HTML

Update Information:

New package - first build & update

References:

  [ 1 ] Bug #1601224 - Review Request: aha - Convert terminal output to HTML
https://bugzilla.redhat.com/show_bug.cgi?id=1601224




 gitolite3-3.6.8-1.el6 (FEDORA-EPEL-2018-33baccb6ce)
 Highly flexible server for git directory version tracker

Update Information:

3.6.8

ChangeLog:

* Tue Jul 17 2018 Gwyn Ciesla  - 1:3.6.8-1
- Latest upstream.
* Fri Jul 13 2018 Fedora Release Engineering  - 
1:3.6.7-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Wed Jun 27 2018 Jitka Plesnikova  - 1:3.6.7-6
- Perl 5.28 rebuild
* Tue Apr 24 2018 Pierre-Yves Chibon  - 1:3.6.7-5
- Back upstream patch making gitolite respect the ALLOW_ORPHAN_GL_CONF
  configuration variabe
- Include the compile-1 command upstream brought in Fedora in:
  https://github.com/sitaramc/gitolite/commit/afb8afa14a892895dc48664c6526351cb
* Wed Feb  7 2018 Fedora Release Engineering  - 
1:3.6.7-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Aug 23 2017 Pierre-Yves Chibon  - 1:3.6.7-3
- Backport upstream patch for dist-git
  Upstream: 
https://github.com/sitaramc/gitolite/commit/41b7885b77cfe992ad3c96d0b021ece51ce1b3e3
* Wed Jul 26 2017 Fedora Release Engineering  - 
1:3.6.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild




 globus-ftp-control-8.5-1.el6 (FEDORA-EPEL-2018-eed9870623)
 Globus Toolkit - GridFTP Control Library

Update Information:

globus-gridftp-server (12.7)  * Force IPC encryption if server configuration
requires * Fix old IPC bug making it hard to diagnose racy connection failures
globus-gridftp-server-control (6.3), globus-ftp-control (8.5)  * Force
encryption on TLS control channel

ChangeLog:

* Sun Jul 15 2018 Mattias Ellert  - 8.5-1
- GT6 update: Force encryption on TLS control channel
* Fri Jul 13 2018 Fedora Release Engineering  - 8.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild




 globus-gridftp-server-12.7-1.el6 (FEDORA-EPEL-2018-eed9870623)
 Globus Toolkit - Globus GridFTP Server

Update Information:

globus-gridftp-server (12.7)  * Force IPC encryption if server configuration
requires * Fix old IPC bug making it hard to diagnose racy connection failures
globus-gridftp-server-control (6.3), globus-ftp-control (8.5)  * Force
encryption on TLS control channel

ChangeLog:

* Sun Jul 15 2018 Mattias Ellert  - 12.7-1
- GT6 update:
  - Force IPC encryption if server configuration requires
  - Fix old IPC bug making it hard to diagnose racy connection failures
* Fri Jul 13 2018 Fedora Release Engineering  - 12.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild




 globus-gridftp-server-control-6.3-1.el6 (FEDORA-EPEL-2018-eed9870623)
 Globus Toolkit - Globus GridFTP Server Library

[Bug 1603528] bugzilla: FTBFS in Fedora rawhide

[bugzilla]

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



--- Comment #1 from Mohan Boddu  ---
Created attachment 1460805
  --> https://bugzilla.redhat.com/attachment.cgi?id=1460805=edit
build.log

file build.log too big, will only attach last 1024 bytes

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/BOOJTIRJ67TOB7GFF2EYA3K3J5QLLTHU/

[Bug 1603528] bugzilla: FTBFS in Fedora rawhide

[bugzilla]

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



--- Comment #3 from Mohan Boddu  ---
Created attachment 1460807
  --> https://bugzilla.redhat.com/attachment.cgi?id=1460807=edit
state.log

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/T3XMXQ5WJU7AH3ZLND6NBJ5K4YLC5DG7/

[Bug 1603528] bugzilla: FTBFS in Fedora rawhide

[bugzilla]

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



--- Comment #2 from Mohan Boddu  ---
Created attachment 1460806
  --> https://bugzilla.redhat.com/attachment.cgi?id=1460806=edit
root.log

file root.log too big, will only attach last 1024 bytes

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GBEAIMRTDAIBK7BUB3S6KG3VGMNZBPKD/

[Bug 1603528] New: bugzilla: FTBFS in Fedora rawhide

[bugzilla]

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

Bug ID: 1603528
   Summary: bugzilla: FTBFS in Fedora rawhide
   Product: Fedora
   Version: rawhide
 Component: bugzilla
  Assignee: ita...@ispbrasil.com.br
  Reporter: mbo...@bhujji.com
QA Contact: extras...@fedoraproject.org
CC: bazanlui...@gmail.com, emman...@seyman.fr,
ita...@ispbrasil.com.br,
perl-devel@lists.fedoraproject.org
Blocks: 1602938



bugzilla failed to build from source in Fedora rawhide

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


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
Please fix bugzilla at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
bugzilla will be orphaned. Before branching of Fedora 30,
bugzilla will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://fedoraproject.org/wiki/Fails_to_build_from_source


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1602938
[Bug 1602938] (F29FTBFS) Fedora 29 Mass Rebuild FTBFS Tracker
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/Z6TNBSPRAH22YFIOWJXISRZB2YUW5O6M/

Re: Self introduction: Eduardo Otubo

[Fabio Valentini]

On Thu, Jul 19, 2018, 15:24 Cole Robinson  wrote:

> Welcome Eduardo :)
>
> On 07/19/2018 06:47 AM, Eduardo Otubo wrote:
> > Hello all,
> >
> > My name is Eduardo and I'll be helping co-maintaining the cloud-init
> package for Fedora.
> >
> > I've been working with QEMU/KVM since 2011. In 2013 I became the
> maintainer of
> > the seccomp subsystem in QEMU. In mid-2017 I joined Red Hat to support
> RHEL in
> > different clouds (Hyper-V, Xen, etc) and supporting cloud-init on RHEL
> is now
> > part of my job as well.
> >
> > I've been reading the "Join the package collection maintainers" wiki
> page and
> > it's been good so far :) except for a tiny question about the process for
> > cloud-init package: How exactly do we decide things like rebase from
> upstream or
> > release dates? I didn't find any specific cloud-init mailing list
> here[0], or
> > anything relevant on the #cloud-init channel at Freenode.
> >
>
> Usually there isn't any policy around how/when specific packages are
> updated in Fedora, it's up to the discretion of the maintainers. Some
> people push latest versions of their packages to every stable Fedora
> branch, others only rebase in rawhide, and everything in between. So I
> suggest talking to your co-maintainers about how they've done things,
> and go from there
>

There *IS* policy for how updates to rawhide and stable releases should be
handled. They are available on the aptly named "Updates Policy" wiki page:
https://fedoraproject.org/wiki/Updates_Policy

Fabio


> The main thing I'd think is to not rebase cloud-init too late into a
> Fedora dev cycle, so there's plenty of time to ensure the cloud images
> are in good shape (I don't know if the cloud images are ever regenerated
> after Fedora GA release). But I know very little about cloud-init...
> maybe it releases all the time, maybe it doesn't regress much, etc.
>
> - Cole
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VLS2XTKAHFJI7WTKZQLFUGNX7WOH33LT/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NFLHURGG6XGYZLMC45JBEFQTUIGGIT7A/

Re: JSharing some poor experience

[Dominik 'Rathann' Mierzejewski]

On Thursday, 19 July 2018 at 16:31, Theodore Papadopoulo wrote:
>   Hello,
> 
> I recently upgraded my computer to Fedora 28 and experienced some
> strange behaviour with the cinnamon deskop when having two screens.
> On the second screen there was a black "border" around windows (eg
> terminals) that was flickering and expanding eg when the mouse was
> moving
> 
> This was somewhat unpleasant but manageable... Today, it started
> bothering me a little, so I did a little search and found (rather easily
> once I had the right keywords):
> 
> https://fedoraproject.org/wiki/Changes/VA-API_1.0.0
> 
> which clearly states that for intel graphic cards, it is necessary to
> install libva-intel-driver which is only available from rpmfusion-free.
> In my case, it was not installed, so I guess the troubles were coming
> from the software rendering...
> 
> What I find strange is that fedora 28 depends (in my configuration with
> the two external screen configuration, which is probably not that
> common) on something which is outside it repositories to properly
> function. And the information on this new dependency is not very
> explicit (eg in the release notes as far as I can tell).

VA is for video acceleration only (encoding and decoding), so whatever
your issue with terminal window rendering is, it's unrelated to VA.

As for VA itself, there's libva-intel-hybrid-driver which is available
in Fedora. It doesn't support all Intel CPUs, though.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XQTCD3F7IR62TUJ4M2KJRFZV4SW3GM7L/

Re: dnf history - change in how rpmdb checksum is computed

[Peter Robinson]

On Thu, Jul 19, 2018 at 3:26 PM, Neal Gompa  wrote:
> On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling  wrote:
>>
>> Regarding these two questions:
>>
 Are there any concerns about such change?
 I believe that >90% users wouldn't notice anything as it's related to the 
 history database only.
>>
>>
>>>
>>> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko 
>>>  wrote:
>>> Since we've changed the database entirely, what's the point of keeping same 
>>> algorithm for calculating checksum?
>>
>>
>>> On Wed, Jul 18, 2018 at 9:34 AM Daniel P. Berrangé  
>>> wrote:
>>> What's the benefit in changing to be compatible with YUM as opposed
>>> to stickin with current alogorithm ?
>>>
>>> Surely if we don't change it, even fewer users will notice that DNF's
>>> behaviour is different from YUM's, since DNF has been the default for
>>> many releases now.
>>>
>>> I could understand the motiviation to stay compatible with YUM if we
>>> were only just about to switch Fedora from YUM to DNF, but time is
>>> way in the past now. Shouldn't we optimize for the fact that DNF is
>>> the more widely deployed & used tool, and thus not worry about
>>> YUM compatibility in respect of the history DB ?
>>
>>
>> It is true that going forward in the Fedora world it matters less.  It is 
>> more of an impact for yum-3 compatibility as yum4/dnf is being considered in 
>> the RHEL7/CentOS7 userspace environments as described at 
>> https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/
>>
>> Currently yum version 3 and what the proof-of-concept project is calling 
>> yum4 work very well together side by side.  Users can safely switch back and 
>> forth.  The major problem is yum/dnf histories being different and the rpmdb 
>> checksum difference is a blocker for resolving the history compatibility.
>>
>> So think of this as an effort to bring package management parity between 
>> Fedora, RHEL 7, & CentOS7, as the latter two still have a long life ahead of 
>> them.
>>
>
> Is there a reason why we can't change YUM to match the DNF behavior?
> IMO, the YUM behavior is nonsense and isn't even a valid package
> identifier.

What about all the enterprise applications and other traditional
platforms that are deployed that expect the existing functionality or
outcomes, not saying it's necessarily correct but there's a lot of
technical debt out there. In a lot of cases there's legacy out there
that needs to be supported and that requires existing APIs to work as
they currently do so there can be migrations.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YNSIGFNMX5POCDRGKVUEFWXQCD4DLVV2/

Re: Intel's Clear Linux optimizations

[Chris Murphy]

On Mon, Jul 16, 2018 at 10:49 AM, Manas Mangaonkar
 wrote:
> The Actual Url
>


I've got the copr enabled, but I can't figure out how to install the
kernel. Even though I don't have -devel -cross-headers -headers for
this kernel installed, those packages are included in a normal 'dnf
update' for some reason. But not the kernel. And 'dnf install kernel'
just points out the obvious, that kernels are already installed.




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

JSharing some poor experience

[Theodore Papadopoulo]

Hello,

I recently upgraded my computer to Fedora 28 and experienced some
strange behaviour with the cinnamon deskop when having two screens.
On the second screen there was a black "border" around windows (eg
terminals) that was flickering and expanding eg when the mouse was
moving

This was somewhat unpleasant but manageable... Today, it started
bothering me a little, so I did a little search and found (rather easily
once I had the right keywords):

https://fedoraproject.org/wiki/Changes/VA-API_1.0.0

which clearly states that for intel graphic cards, it is necessary to
install libva-intel-driver which is only available from rpmfusion-free.
In my case, it was not installed, so I guess the troubles were coming
from the software rendering...

What I find strange is that fedora 28 depends (in my configuration with
the two external screen configuration, which is probably not that
common) on something which is outside it repositories to properly
function. And the information on this new dependency is not very
explicit (eg in the release notes as far as I can tell).

I just wanted to share this small glitch for others that might have
encountered the same problem and in the hope that this situation can
improve so that it become invisible to the end-user. For example, can
the rpm migrate to fedora repos since it's free and the proper
dependency is added, so that it is installed by default with desktops
(or the desktops that need it) ? Or otherwise, fix the software
rendering (which is probably more difficult and more work).

Otherwise Fedora 28 is so far a great vintage... Tahnk you for all the
great work.

Theo.


0x12BF16AD4F273D5D.asc
Description: application/pgp-keys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ESPOSV4DX76FYZEA4PZQR35FTX6UUMDP/

Re: dnf history - change in how rpmdb checksum is computed

[Neal Gompa]

On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling  wrote:
>
> Regarding these two questions:
>
>>> Are there any concerns about such change?
>>> I believe that >90% users wouldn't notice anything as it's related to the 
>>> history database only.
>
>
>>
>> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko 
>>  wrote:
>> Since we've changed the database entirely, what's the point of keeping same 
>> algorithm for calculating checksum?
>
>
>> On Wed, Jul 18, 2018 at 9:34 AM Daniel P. Berrangé  
>> wrote:
>> What's the benefit in changing to be compatible with YUM as opposed
>> to stickin with current alogorithm ?
>>
>> Surely if we don't change it, even fewer users will notice that DNF's
>> behaviour is different from YUM's, since DNF has been the default for
>> many releases now.
>>
>> I could understand the motiviation to stay compatible with YUM if we
>> were only just about to switch Fedora from YUM to DNF, but time is
>> way in the past now. Shouldn't we optimize for the fact that DNF is
>> the more widely deployed & used tool, and thus not worry about
>> YUM compatibility in respect of the history DB ?
>
>
> It is true that going forward in the Fedora world it matters less.  It is 
> more of an impact for yum-3 compatibility as yum4/dnf is being considered in 
> the RHEL7/CentOS7 userspace environments as described at 
> https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/
>
> Currently yum version 3 and what the proof-of-concept project is calling yum4 
> work very well together side by side.  Users can safely switch back and 
> forth.  The major problem is yum/dnf histories being different and the rpmdb 
> checksum difference is a blocker for resolving the history compatibility.
>
> So think of this as an effort to bring package management parity between 
> Fedora, RHEL 7, & CentOS7, as the latter two still have a long life ahead of 
> them.
>

Is there a reason why we can't change YUM to match the DNF behavior?
IMO, the YUM behavior is nonsense and isn't even a valid package
identifier.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SU43ILZ3GELAKUWQSM2345LK7PEKCQFE/

Re: Self introduction: Eduardo Otubo

[Cole Robinson]

Welcome Eduardo :)

On 07/19/2018 06:47 AM, Eduardo Otubo wrote:
> Hello all,
> 
> My name is Eduardo and I'll be helping co-maintaining the cloud-init package 
> for Fedora.
> 
> I've been working with QEMU/KVM since 2011. In 2013 I became the maintainer of
> the seccomp subsystem in QEMU. In mid-2017 I joined Red Hat to support RHEL in
> different clouds (Hyper-V, Xen, etc) and supporting cloud-init on RHEL is now
> part of my job as well.
> 
> I've been reading the "Join the package collection maintainers" wiki page and
> it's been good so far :) except for a tiny question about the process for
> cloud-init package: How exactly do we decide things like rebase from upstream 
> or
> release dates? I didn't find any specific cloud-init mailing list here[0], or
> anything relevant on the #cloud-init channel at Freenode.
> 

Usually there isn't any policy around how/when specific packages are
updated in Fedora, it's up to the discretion of the maintainers. Some
people push latest versions of their packages to every stable Fedora
branch, others only rebase in rawhide, and everything in between. So I
suggest talking to your co-maintainers about how they've done things,
and go from there

The main thing I'd think is to not rebase cloud-init too late into a
Fedora dev cycle, so there's plenty of time to ensure the cloud images
are in good shape (I don't know if the cloud images are ever regenerated
after Fedora GA release). But I know very little about cloud-init...
maybe it releases all the time, maybe it doesn't regress much, etc.

- Cole
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VLS2XTKAHFJI7WTKZQLFUGNX7WOH33LT/

Re: [HEADS UP] Removal of GCC from the buildroot

[Vít Ondruch]

Dne 12.7.2018 v 18:00 Mikolaj Izdebski napsal(a):
> On 07/11/2018 10:27 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> The effects of fsync are impossible to see unless you hard-reboot the
>> machine. (OK, strictly speaking, you can time the fsync call, but let's
>> ignore that). I'd be more worried about some side-effects of the way
>> that nosync is implemented with a LD_PRELOAD. I wonder if it wouldn't be
>> more robust to use nspawn's syscall filter to filter the fsync calls.
>> (If nspawn is already used by koji, not sure.)
> Koji does not use systemd-nspawn. It uses plain old chroot.
>

Actually, it would be nice if somebody wanted to implement this for us
who use mock with systemd-nspawn :)

V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5A6MD4SV6ZBXG7KFGCYEBKGYS43UTI3E/

[Bug 1603196] New: perl-Parallel-ForkManager-1.20 is available

[bugzilla]

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

Bug ID: 1603196
   Summary: perl-Parallel-ForkManager-1.20 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Parallel-ForkManager
  Keywords: FutureFeature, Triaged
  Assignee: ti...@math.uh.edu
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: maria...@tuxette.fr,
perl-devel@lists.fedoraproject.org, ti...@math.uh.edu,
w...@gouldfamily.org



Latest upstream release: 1.20
Current version/release in rawhide: 1.19-7.fc29
URL: http://search.cpan.org/dist/Parallel-ForkManager/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/5674/

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YN5SEZAWLYFSGIHUIDTOY4FI74IHXCTK/

Update to scotch-6.0.6

[Sandro Mani]

Hi

I'm updating to scotch-6.0.6, which carries a soname bump. I'll rebuild 
the following dependent packages:


hypre
mmg
MUMPS
petsc
qrmumps
superlu_dist

I've done a test run in this [1] COPR repo and all dependencies built 
successfully.


Sandro

[1] https://copr.fedorainfracloud.org/coprs/smani/scotch

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6D67XW6SJKSM226DAKYQLHEUNAGUPHLN/

Re: Again, please announce your so-name bumps!

[Christian Dersch]

Rebuilds done for gegl04, indi-gphoto, kstars and siril. This should fix 
the broken dependencies resulting in the compose failures of Astronomy 
Lab (gimp(gegl04),indi-gphoto,kstars,siril), Design Suite 
(gnome-photos(gegl04)) and Scientific (gimp).


Greetings,
Christian


On 19/07/18 08:19, Christian Dersch wrote:

Hi all,

please announce your so-name bumps *before* you push them. This time 
LibRaw bumped its version, as a result we have broken dependencies and 
some composes like Astronomy spin fail to build…


  Problem 1: conflicting requests
   - nothing provides libraw.so.16()(64bit) needed by siril-0.9.9-2.fc29.x86_64
  Problem 2: conflicting requests
   - nothing provides libraw.so.16()(64bit) needed by 
kstars-1:2.9.6-2.fc29.x86_64
  Problem 3: conflicting requests
   - nothing provides libraw.so.16()(64bit) needed by 
indi-gphoto-1.7.2-2.fc29.x86_64
  Problem 4: conflicting requests
   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires libgegl-0.4.so.0()(64bit), 
but none of the providers can be installed
   - package gimp-2:2.10.4-1.fc29.1.x86_64 requireslibgegl-npd-0.4.so 
()(64bit), but none of the providers can be installed
   - package gimp-2:2.10.4-1.fc29.1.x86_64 requires gegl04(x86-64) >= 0.4.4, 
but none of the providers can be installed
   - nothing provides libraw.so.16()(64bit) needed by gegl04-0.4.4-1.fc29.x86_64
I'm going to rebuild gimp, indi-gphoto, kstars and siril now. But I'm 
sure there are more broken dependencies.


Greetings,
Christian


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

Self introduction: Eduardo Otubo

[Eduardo Otubo]

Hello all,

My name is Eduardo and I'll be helping co-maintaining the cloud-init package 
for Fedora.

I've been working with QEMU/KVM since 2011. In 2013 I became the maintainer of
the seccomp subsystem in QEMU. In mid-2017 I joined Red Hat to support RHEL in
different clouds (Hyper-V, Xen, etc) and supporting cloud-init on RHEL is now
part of my job as well.

I've been reading the "Join the package collection maintainers" wiki page and
it's been good so far :) except for a tiny question about the process for
cloud-init package: How exactly do we decide things like rebase from upstream or
release dates? I didn't find any specific cloud-init mailing list here[0], or
anything relevant on the #cloud-init channel at Freenode.

Regards,

[0] https://lists.stg.fedoraproject.org

That would be my PGP key:

-BEGIN PGP PUBLIC KEY BLOCK-

mQENBFlLcNoBCADP1cr8swJdAdZto2e5/3xt3R7G2JWQUQHjd1zoXel0rD7aI91D
o+DzFcTsW7sOTub7d7woiReopXm7o8ISGO+PP3AVezSyTf0nA51hALjrnyK5ARCi
kCy5JCNMsAOjnwW1FAGrvdvzvnbJ/bU0Oq0VBufKBYwJVhPPtk9IDYi5Mz0MiJqg
JK+E9CdL01S0BI17UOehK9sT2VwXKrrQr8L8h8Ub39tLEZT8TckwyEsz1vEhARvc
HTrrp5fMrx28TOv6tGF1fdUIYaY5yW6DCWA/0Aw6lHhzZ2vXFnHKsge3+Diqmz9l
05sjXWajBk52nkq2MUYNFgwKaXcye74LeDC/ABEBAAG0O0VkdWFyZG8gT3R1Ym8g
KFNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcikgPG90dWJvQHJlZGhhdC5jb20+iQE4
BBMBAgAiBQJZS3DaAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDfMufA
8P/5ovMkB/9dmINe3yGS7IZ4rYOAz4Ooxjwh2U6iYMKjH0M0LDlgxh1vYk3p9UAJ
aNVMHtJ7poWBJJ/n4aWRQSqMzGl3pyQuOhY3LWLvEudCx5QLIkq4Axc2fJoyFuHA
1cjVcIzRbx6t2dTBMzKxX5Z36Lcj+NVc7Mp6mcYZ0HPUrUfBAbh/okwCgD2jCK5O
B0ZXUixPT9aZXMjwVPzNqgIDV/XIq/c/4G5FN4DS+9J/o3M+81p+D3VDqsqPeADM
iwOsKhxJf7YvzPUS94bk5hn8dqC4B4+vo9YQdAooQ4ttus8bQ6bKE5YRurYMjwZw
jXIwWtFQvz504SXA5hqe0S7u+IAEbZ2SiQEcBBABAgAGBQJZ8kYSAAoJEK0ScMxN
0CebfjkH/3nAlrnWzFyEZ8u3HMBrtCMUJZmvhxjIvRurOaEOwVYQ1kDF7dmmHvWy
SVD8Mi7ra0RDHcotS/SlcqBPFz1Ib3R4ROljCtOnts8LPZv3Ut344vUE3J2vrFE3
hB9OObgobl9Qy2kxgoiGCHG4mGfKH87W23EThyLPy7UmmN7TpHo0AY+M2lXBGdfv
HbetM4l7zkvZ2GYzG8XZ0mHSAOCIJhYvjvXzzE5lQKnD17pcHM8fbVpn7vAcIqYO
CXN84HfOeLUpU4i90nNNRP/6W1KzTaJjGkb33ajaazSw/NQR7nXieF6UT0jI7CFr
3r7whjjbS32Th4QBVe2QjZcqwj3tLZyJARwEEAECAAYFAlnyRjYACgkQZN846K9+
IV8b5wf/cUI4IGc9cWK46bc+oLMOv82BgQcBFyYORRRmRP9kTIQDrfbrC3CxSpQE
aIFWpimpJcpwUz1lI2+ahPGqC2/J1VW43DsyCuttJn8IkjpBuB2VEOelRpRJPoZY
cXTThSZBA/L9BGOxQ1KzO19cLXW1S53LOMtZJn9AylnxdLQYuKTeurh52vgtX8B5
S/637dn5KF7SMThob7OQ7m70Xx3HYCtQHVTnofkgKYTngVs9SXZ01XRl6cTfXiKX
I+AmJadCTI99WqKebuSqk7YwlvzLnVh013iM6dY/AUYFHDZ5TVOkmHD4YDDJU7Yc
o2s1iwPIWo+UeM/UfY0Bw0/Wp0siX4kBHAQQAQIABgUCWfnR7wAKCRCcpKuzgatz
yLRdCADIee4MKiTphggQPkQyZrSgBix77+D0mssGhBYRCCrPf0khvpiSSXI3kj8g
iNqknQAhUIxy4bK85OkBGohvj31yyH2EzB4u/S9Qu8KODfiFuB5QJc8NF7J7jFse
xIbgULqlZ/krC+1T4KaJZaC1yp5qBSRYLWRzlKtzJIAuWTYN992SUrgmDYIBrxxX
ifEi+hD150OeZ+6iWSRSSxhTuNrz0GEEF4NfSw9dS1K7epH2z+5fO1PTTzB3tFGj
lAVH1DHuYUquSHwxq5oJpkwPnAu1Y6l907MhiOsgO8Pmjy7Tf/dr2ArpLgOE7Ril
TtjAUKlHHkaWnoRgsLsBMEJV9bDriQIcBBABAgAGBQJZU4QXAAoJEC7Z13T+cC21
1PQP/A14gf/MlreS9a2oaY4Puny/lUGqiq3Jcy2uR6hFHL/ENY8knSMzGkgKf9Eo
q02pgLjVuLlGcQt+6JZYAZFA7nt7NzSh67FkAtcURdAutvcnzPAkSXEj48kKTGCN
fb4ecH2ti7/vRl23v2HBd+FnHQckZ18VpsmS5hlZmZS3DEib0JRBOLEfUC1nXnCp
sdvxmDNtfsJ8F3VHqthdelDOT9h1DKMt6CKA3tztvkj9lX/ApGt9W3vb8GoQVkHk
kEfmBhSCFtUD077206wV81XrLgNg479NR6ebm2cguJeBaKq+K+hoS+u+GVSuaH68
rTDxstseypaMC6IYrAyxlX84bayQEtNMRTRjjm8VWZ5YCpB2SYis1/4WgSwOLwt6
r2HZOx6d9BJbh4FnFWMlUiXymXZuA6cm9OXJHr55Tdh0DiNyQQbiE/EpzyR3gGZO
gd4JwFIIDW0OE19PYc47TncIjO4CES/9V77VZ1nRwaJ1nsrw6233+IMRI1mQYiFJ
jC6dcgg7kI6TEza2zHyQGAFnWrIpJDLhyqlqzHuKmoovpWYbd1kUrMP5LKi/Wkrl
dYLqxK9WSjWOAwrcSR8Uobm+QNOwvESUtNWis8UKI4LefoLM5kv/MaD6wAYYv3Kf
vJWEImid5GMRsV8yjLrQMmlyIr+LpNcFhViA/1x4QB8BMhJQiQIcBBABAgAGBQJZ
9wf9AAoJEFvKiuDxQZHUrrwP/3LqT4fmZ3Q+hHQXFuxYoXu6t9w1djb21LBK2qh8
/2+TFhqNdctEZg/M5hL0dLnp6fJ2HD3vxLJewkZV0SlGpPPF7H7Rh3K9yy9oZAAc
avaYQHK7fjWhquL9OiOigdy2KzzmJpCOq3zqJKnmKT3MeNOVC4QuiqV+N8pRuSeL
USIuWGrY8GWfQRCSylXnNWJOGhKfEA7FrFALFJATuwTqWSEralOS5tvXUaNPXz7t
1kMxd/X8blI/b+foiyoF668EqunKb8JeS24MZduTkrVdx3lHdYKRzOE4/p+/y7Rl
7aDjqVf6tZPSKn46Le2YJnPRBrUu4s7/lRhFUwQVPOqi0IA3VKWJPGAoFGZTUFgj
6DNusisBpu6nuC+1zf4ta1DkDzM4dq+jEVpRdRdWBwFIyK9pv7lMIPZXc4tIQslw
+eSmexumXvyKcwglGoCmDB5zbIviAoV8l6JXXiQ3A4V3l5Sz4cKBZvR4TIo5WKIs
hoRsoV3ofS2ewDMOgOf8iiVtD5MiTE+C5msdp9GtRwZvTMvfVRIxWc7fX6gGJ8SJ
P2daNDx1LD17ikpEdvV+9XRTVa0Z4u7YT2pe9+kJQIpS6gKZdImVvKRLm+Zw5nbL
LYV/OMS4Z380uxrS0HLSICwxuZENRzMg1mPe3bKcV3Q2m7hqbeOIsBvMTnaAOB8K
4wmYiQIcBBABCAAGBQJZ8v3pAAoJEL6G67QVEE/fHJAP/3o0aT9Dyx6HhZShYQF6
1nNRq4TtXtsT6YA08yOr9gPGw0RdxMJVH5qCmPC2asoQkEfX/1eNNN5zdmjZqPCL
AarS9BWZVDJA57+ThLmqR18XK6E0SeKF5Fb31aWrySWhKC/SSiKaCm8r8zu7z9dQ
mrFXy1i9enW3oHyiWYFdQhmwbJqFjjm3OF4WuU+Bt9Qw1Ug3Uml9k/HpFVhR4LtO
52/UT1d2tPL6NzkuBysBdosr0ilfCS2gLIAupdKXQXQQYvyRJ4Rj1zf4livBURTC
bNub8nzyLVgIzAr6ajdDF0OeAc/GkwG59KhDLzFbauwYZe4O8sYqW5CflWKK+S5b
9R3bNCHlDNsTkWmpxnjdNAjr7FvPeK4L58LlmZRrF7uXt7Nx6FEFxf29VJlLIOvb
GZMOyAgaqdSftKKEaE1kazVqc5dWLf5J+PZIITXiIlxVLLc4tk3Rnu18QVpX4e7Y
iKG67+iIePzgR7GPPwO3hyjhWSvXP43VcWvyyhg5rOzFdkPFNWCbSfS3YUJOJ9xr

Re: glibc-2.27.9000 and struct statx_timestamp

[Rafal Luzynski]

19.07.2018 00:10 Sandro Mani  wrote:
> 
>  Hi
> 
>  I'm hitting the following with qt5-qtbase:
> 
>  /usr/include/linux/stat.h:56:8: error: redefinition of 'struct
> statx_timestamp'
>   struct statx_timestamp {
>  ^~~
>  In file included from /usr/include/sys/stat.h:446,
>   from
> /builddir/build/BUILD/qtbase-everywhere-src-5.11.1/mkspecs/linux-g++/qplatformdefs.h:75,
>   from
> /builddir/build/BUILD/qtbase-everywhere-src-5.11.1/src/corelib/io/qfilesystemengine_unix.cpp:42:
>  /usr/include/bits/statx.h:25:8: note: previous definition of 'struct
> statx_timestamp'
>   struct statx_timestamp
>  ^~~
> 
> 
>  I.e. struct statx_timestamp in linux/stat.h (included directly by
> qfilesystemengine_unix.cpp) is conflicting with struct statx_timestamp in
> bits/statx.h included via sys/stat.h.
> 
>  This has begun with glibc-2.27.9000.
> 
>  Any ideas?

True, this change has been introduced with the upstream commit 93304f5 [1]
and has reached Fedora Rawhide since glibc-2.27.9000-38. [2]
Maybe /usr/include/linux/stat.h requires some conditional #ifdef including
the relevant part only if GLIBC < 2.28. But that's part of kernel, should
be reported and fixed upstream.

I think that Florian who is also active in this list should speak. For now
the simplest workaround for you is to downgrade glibc to something just few
days older.

Regards,

Rafal


[1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=93304f5
[2]
https://src.fedoraproject.org/rpms/glibc/c/6404b258962769f7c4d1108c52aece4b314ee27f?branch=master
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WIIFDJYB5N4HA7CLWH7M4KRZOAOWZVF6/

Re: F29 Mass rebuild - Help needed to fix failed build

[Miro Hrončok]

On 18.7.2018 15:23, Zoltan Kota wrote:

Hi All,

The Mass rebuild of pybliographer failed. See below:

Fwd: releng's pybliographer-1.2.18-4.fc29 failed to build

Notification time stamped 2018-07-15 03:04:40 UTC

releng's pybliographer-1.2.18-4.fc29 failed to build
http://koji.fedoraproject.org/koji/buildinfo?buildID=1121364

It seems the .configure script does not find 'python'. The script uses 
Python variable to store python path (configure.ac 
: AC_PATH_PROG(Python, python, no) ).


Can I add/override this variable in the spec file?
eg. %configure Python=%{__python2}

or what is the correct syntax/way to fix the issue?


A PR: https://src.fedoraproject.org/rpms/pybliographer/pull-request/1

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

Re: some trac plugins looking for point of contacts

[Paul Howarth]

On Wed, 18 Jul 2018 12:41:53 -0700
Kevin Fenzi  wrote:

> Hey all.
> 
> I have:
> 
> trac-bazaar-plugin
> trac-git-plugin
> trac-iniadmin-plugin
> trac-mercurial-plugin
> trac-ticketdelete-plugin

I took a look at trac-ticketdelete-plugin as I've had that on my system
for a long time but it seems its functionality has long since been
included in trac itself, so I removed the package from my system and all
was well. It might be more appropriate to retire that one rather than
orphan it.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BN2K62TLYNRE4UN3CDPQLU7LI7VG5PXL/

Re: F29 Mass rebuild - Help needed to fix failed build

[Miro Hrončok]

On 18.7.2018 18:07, Peter Robinson wrote:

On Wed, Jul 18, 2018 at 3:18 PM, Mattias Ellert
 wrote:

ons 2018-07-18 klockan 15:23 +0200 skrev Zoltan Kota:

Hi All,

The Mass rebuild of pybliographer failed. See below:

Fwd: releng's pybliographer-1.2.18-4.fc29 failed to build

Notification time stamped 2018-07-15 03:04:40 UTC

releng's pybliographer-1.2.18-4.fc29 failed to build
 http://koji.fedoraproject.org/koji/buildinfo?buildID=1121364

It seems the .configure script does not find 'python'. The script uses Python 
variable to store python path (configure.ac: AC_PATH_PROG(Python, python, no) ).

Can I add/override this variable in the spec file?
eg. %configure Python=%{__python2}

or what is the correct syntax/way to fix the issue?

Thanks,
Zoltan


diff --git a/pybliographer.spec b/pybliographer.spec
index ac77e97..4649812 100644
--- a/pybliographer.spec
+++ b/pybliographer.spec
@@ -47,6 +47,7 @@ file formats: BibTeX, ISI, Medline, Ovid, Refer.
  %setup -q

  %build
+export Python=/usr/bin/python2


Or you can add:

BuildRequires: python-unversioned-command



No. You cannot.

1) that is supposed to be a temporary workaround, not a solution. this 
is an easyfix that needs no workarounds.
2) also 
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Don.27t_.28Build.29Require_python-unversioned-command.2C_but_.2Fusr.2Fbin.2Fpython


Using unversioned python command in build of RPM packages in Fedora is 
against the guidelines. We realize that sometimes it's unavoidable, but 
this is not the case. Please stop providing advice that is against the 
packaging guidelines.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AA76S5NQUVCSPFZOZH4CRDMBQCOFL6O7/

[EPEL-devel] Re: python 2 retirement commo efforts

[Miro Hrončok]

On 18.7.2018 20:24, R P Herrold wrote:

On Tue, 17 Jul 2018, R P Herrold wrote:


I've poked at getting accurate counts and manifests of unique
python(2) package SRPMs off my mirror today -- I'll supplement
this email with the script and links to the mainfests
tomorrow.  A 'sort | uniq' let me down as to getting an
accurate count released today


tomorrow arrived on me,  but here are the promised report and
links to the results and the generator script

[/share/MD0_DATA/Mirror/lftp] # time ./stats.sh
# packages starting with target: python
#   but NOT python3
#   collated from a mirror: 20180718

 264 /tmp/redhat_rhel_SRPMSonly_6Server.txt
 475 /tmp/redhat_rhel_SRPMSonly_7Server.txt
 644 /tmp/redhat_epel_6.txt
 825 /tmp/redhat_epel_7.txt
2776 /tmp/redhat_fedora_fedora-28.txt
2132 /tmp/redhat_rawhide2017.txt

real64m28.714s
user1m11.330s
sys 3m6.450s


The first column is the number of unique SRPMs for a given
archive, seen.  Inside the files (the link of which is my
second column and the basename of which is accessible per the
links below) are detail counts of the number for each distinct
SRPMs within a given package name, as seen on a local private
mirror I use and maintain


Copies of the detail, and of the script producing the
reports are at:

http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt
http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt
http://gallery.herrold.com/stuff/redhat_epel_6.txt
http://gallery.herrold.com/stuff/redhat_epel_7.txt
http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt
http://gallery.herrold.com/stuff/redhat_rawhide2017.txt

http://gallery.herrold.com/stuff/stats.sh


The _purpose_ of getting the count of 'number of updated
packages' for each given package is to permit seeing 'hot
spots', and the 'no issues' 'build once and forget' packages
particularly in RHEL and EPEL.  Because of the way that
current Fedora and RawHide are built, there is churn on
rebuilds, even with non-material internal changes.  THe


The ** POINT ** of producing such a report is to  'put
numbers' on the scope of the work rather than loose armwaving
assertions such as:


Fedora still has more than 3000 packages depending on
python2 – many more than we can support without upstream
help.


Those are real Fedora numbers [0]. No armwaving involved.

1311 python2 only packages
1734 python2+python3 packages
+ 88 with packaging problem where I'm not sure

That is something between 3045 and 3133. That can be rounded to 3k.

No idea why we moved the discussion to another list as well, but stop 
accusing us from armwaving. We have data (for Fedora, because that where 
we started the discussion). As for RHEL/EPEL: current ones can remain as 
they are. Future ones see [1].


> Python 2 will be replaced with Python 3 in the next Red Hat Enterprise
> Linux (RHEL) major release.

[0] http://fedora.portingdb.xyz/
[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality





--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DYI742D7UPV2M2EGDHUW55R6TJLEE5VH/

Re: [EPEL-devel] Re: python 2 retirement commo efforts

[Miro Hrončok]

On 18.7.2018 20:24, R P Herrold wrote:

On Tue, 17 Jul 2018, R P Herrold wrote:


I've poked at getting accurate counts and manifests of unique
python(2) package SRPMs off my mirror today -- I'll supplement
this email with the script and links to the mainfests
tomorrow.  A 'sort | uniq' let me down as to getting an
accurate count released today


tomorrow arrived on me,  but here are the promised report and
links to the results and the generator script

[/share/MD0_DATA/Mirror/lftp] # time ./stats.sh
# packages starting with target: python
#   but NOT python3
#   collated from a mirror: 20180718

 264 /tmp/redhat_rhel_SRPMSonly_6Server.txt
 475 /tmp/redhat_rhel_SRPMSonly_7Server.txt
 644 /tmp/redhat_epel_6.txt
 825 /tmp/redhat_epel_7.txt
2776 /tmp/redhat_fedora_fedora-28.txt
2132 /tmp/redhat_rawhide2017.txt

real64m28.714s
user1m11.330s
sys 3m6.450s


The first column is the number of unique SRPMs for a given
archive, seen.  Inside the files (the link of which is my
second column and the basename of which is accessible per the
links below) are detail counts of the number for each distinct
SRPMs within a given package name, as seen on a local private
mirror I use and maintain


Copies of the detail, and of the script producing the
reports are at:

http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt
http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt
http://gallery.herrold.com/stuff/redhat_epel_6.txt
http://gallery.herrold.com/stuff/redhat_epel_7.txt
http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt
http://gallery.herrold.com/stuff/redhat_rawhide2017.txt

http://gallery.herrold.com/stuff/stats.sh


The _purpose_ of getting the count of 'number of updated
packages' for each given package is to permit seeing 'hot
spots', and the 'no issues' 'build once and forget' packages
particularly in RHEL and EPEL.  Because of the way that
current Fedora and RawHide are built, there is churn on
rebuilds, even with non-material internal changes.  THe


The ** POINT ** of producing such a report is to  'put
numbers' on the scope of the work rather than loose armwaving
assertions such as:


Fedora still has more than 3000 packages depending on
python2 – many more than we can support without upstream
help.


Those are real Fedora numbers [0]. No armwaving involved.

1311 python2 only packages
1734 python2+python3 packages
+ 88 with packaging problem where I'm not sure

That is something between 3045 and 3133. That can be rounded to 3k.

No idea why we moved the discussion to another list as well, but stop 
accusing us from armwaving. We have data (for Fedora, because that where 
we started the discussion). As for RHEL/EPEL: current ones can remain as 
they are. Future ones see [1].


> Python 2 will be replaced with Python 3 in the next Red Hat Enterprise
> Linux (RHEL) major release.

[0] http://fedora.portingdb.xyz/
[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality





--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DYI742D7UPV2M2EGDHUW55R6TJLEE5VH/

Re: Lots a permission denied activity

[Richard W.M. Jones]

On Mon, Jul 16, 2018 at 07:54:48PM +0100, Sérgio Basto wrote:
> On Mon, 2018-07-16 at 14:27 -0400, Steve Grubb wrote:
> > Hello,
> > 
> > I have been testing a new set of audit rules and have run across
> > some 
> > processes that are doing things that might out to be changed.
> > Typically, 
> > audit users expect a normally functioning system to not be noisy.
> > There is a 
> > requirement to audit failed file access due to permission denied.
> > What I'm 
> > finding is that two processes are generating tens of thousands of
> > events 
> > every day.
> > 
> > There is a /usr/libexec/tracker-extract process that searches my
> > directories 
> > about every 11 seconds. I can imagine on a laptop that would be a lot
> > of disk 
> > activity. Sometimes I use root in my home directory and accidentally
> > create 
> > files owned by root. This leads to a lots of events on my system.
> > Does it 
> > really need to run with this frequency?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1271872
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=747689 (closed as fixed !?!
> )  yet today someone also complains about tracker 

I've given up hoping that we'll have a reliable way to disable
tracker, so now I have added this in ~/.bashrc in all the desktop
machines I use:

  # Kill with fire.
  killall -9 -r tracker-.* >& /dev/null

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YONV4DC26HGXNB2YIYQQE73I2IDY26CT/

Re: F29 Self-Contained Change: Basic FPGA Support

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 18, 2018 at 05:26:08PM -0400, Ben Cotton wrote:
> == Summary ==
> A number of devices like Xilinx ZYNQ based devices such as the
> 96boards Ultra96 and the Intel based UP² have onboard FPGAs. FPGA
> manager is a vendor-neutral framework that has been upstream in the
> kernel since 4.4. This is the initial support for FPGAs in Fedora
> using open source vendor agnostic tools.
> 
> == Owner ==
> * Name: Peter Robinson
> * Email: pbrobinson at fedora project dot org
> 
> == Detailed Description ==
> 
> The use of Artificial Intelligence and Machine Learning is growing.
> There's a number types of compute power used to drive this, the
> standard system CPU can handle basic work, but for more powerful needs
> this workload gets moved to auxiliary processors such as GPGPU, FPGAs
> or Neural Network processors. This will add initial support for FPGAs
> in Fedora using the Linux Kernel support which currently supports
> Altera,  Zynq, Lattice and other FPGAs. The use of FPGAs with Open
> Source software is improving and this is the beginning of ensuring
> that can be consumed in Fedora as easily as possible.
> 
> == Benefit to Fedora ==
> 
> The general purpose use of FPGAs is growing in the tech industry,
> especially in AI and Machine Learning usecases for IoT and numerous
> other places where special purpose workload acceleration is needed.
> This will help developing these workloads on top of Fedora for use
> across the distribution.
> 
> == Scope ==
> * Proposal owners: Kernel and userspace changes

Hm, what is the actual scope of this change? Summary, Detailed Desc.,
and Benefit to Fedora all talk about FPGA in general, but not about
what will change in Fedora.

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

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

Can you give some more details as those would help Investigate the problem
better.

On Thu, 19 Jul 2018, 10:38 Rajeesh K V,  wrote:

>
>
> On Mon, Jul 16, 2018 at 10:33 PM Manas Mangaonkar <
> manasmangaon...@gmail.com> wrote:
>
>> The Actual Url
>> 
>>
>
> FYI, have been running kernel 4.18.0-0.rc0.git10.1.fc28.x86_64 since a
> day, haven't noticed any breakages :-)
> But 'swapper' process seems to be hyperactive compared to the fc28 4.17.6
> kernel. Output from $perf top -sort comm,dso
>
>   28.20%  swapper  [kernel]
>6.44%  konsole  libQt5Gui.so.5.10.1
>5.85%  plasmashell  [kernel]
>5.76%  Xorg [kernel]
>4.00%  konsole  [kernel]
>3.87%  kwin_x11 [kernel]
>2.96%  QXcbEventReader  [kernel]
>2.74%  Xorg libc-2.27.so
>2.66%  firefox  libxul.so
>2.50%  swapper  [unknown]
>2.35%  kworker/0:2-mm_  [kernel]
>2.34%  kworker/1:1-mm_  [kernel]
>2.01%  irq/51-SYNA2B29  [kernel]
>1.72%  Xorg Xorg
>1.54%  InputThread  [kernel]
>1.42%  konsole  libkonsoleprivate.so.17.12.2
>1.32%  plasmashell  libQt5Core.so.5.10.1
>1.06%  konsole  libharfbuzz.so.0.10705.0
>1.03%  firefox  [kernel]
>0.92%  konsole  libQt5XcbQpa.so.5.10.1
>0.76%  kworker/u8:4-ev  [kernel]
>0.75%  kwin_x11 libQt5Core.so.5.10.1
>0.72%  konsole  libQt5Core.so.5.10.1
>0.72%  perf libslang.so.2.3.2
>0.69%  kworker/0:3-eve  [kernel]
>0.60%  perf [kernel]
>0.58%  kwin_x11 i965_dri.so
>0.48%  plasmashell  libglib-2.0.so.0.5600.1
>0.45%  rcu_sched[kernel]
>0.43%  JS Helperlibxul.so
>0.39%  konsole  libpthread-2.27.so
>0.39%  kwin_x11 libkwin.so.5.13.3
>0.37%  kwin_x11 libc-2.27.so
>
>
> --
> Rajeesh
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BPX6HFVK3WXLPIGCFZVPLT2FM7E64T2B/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UROWFBDET5BON2FRBAS3YVCUTAX46KZR/

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

Thabks

On Thu, 19 Jul 2018, 12:29 Rajeesh K V,  wrote:

> On 7/19/18, Manas Mangaonkar  wrote:
> > Good to here there haven't been any breakages.
> >
> > I will look into the swapper process issue asap.
>
> Thanks.
> Output from $perf top -F 49
>
>  16.19%  [kernel]   [k] sdhci_irq
>7.72%  [unknown]  [.] 
>5.50%  [kernel]   [k] __lock_acquire
>2.70%  [kernel]   [k] lock_release
>2.14%  [kernel]   [k] lock_acquire
>1.95%  [kernel]   [k] lock_is_held_type
>1.73%  [kernel]   [k] native_sched_clock
>1.18%  [kernel]   [k] dw_readl
>1.17%  libc-2.27.so   [.]
> __memmove_avx_unaligned_erms
>1.07%  [kernel]   [k] lock_acquired
>1.05%  [kernel]   [k] __fget
>1.01%  libQt5Core.so.5.10.1   [.] QString::append
>0.85%  libQt5Core.so.5.10.1   [.] 0x002be7d4
>0.72%  [kernel]   [k] get_mem_cgroup_from_mm
>0.71%  [kernel]   [k] mark_lock
>0.69%  [kernel]   [k] __lock_is_held
>0.69%  [kernel]   [k] idma64_irq
>0.63%  libxul.so  [.] 0x0345edd4
>0.61%  [kernel]   [k] match_held_lock
>0.59%  [kernel]   [k] update_blocked_averages
>0.59%  [kernel]   [k] _raw_spin_lock_irqsave
>0.58%  firefox[.] free
>0.58%  libpthread-2.27.so [.] __pthread_mutex_lock
>0.53%  [kernel]   [k] __schedule
>0.52%  [kernel]   [k] do_raw_spin_trylock
>0.52%  libc-2.27.so   [.] malloc
>0.49%  libxul.so  [.] 0x02543cd2
>0.49%  [kernel]   [k] sock_poll
>0.47%  [kernel]   [k] policy_node
>
>
> --
> Rajeesh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IPKTLOTVP32TPB37B43DAWXEMBOAV2JK/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/H7XJKDOUUSHEGNNK7WKOLYCPVLDS56KT/

Re: GCC 8/9 ABI change: call for rebuilds

[Wolfgang Stoeggl]

In the meantime, gcc-8.1.1-5 is available as an update for F28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KWRHNP54HKNMN3DG5XI5URE6REYTYPGW/

Re: Intel's Clear Linux optimizations

[Rajeesh K V]

On 7/19/18, Manas Mangaonkar  wrote:
> Good to here there haven't been any breakages.
>
> I will look into the swapper process issue asap.

Thanks.
Output from $perf top -F 49

 16.19%  [kernel]   [k] sdhci_irq
   7.72%  [unknown]  [.] 
   5.50%  [kernel]   [k] __lock_acquire
   2.70%  [kernel]   [k] lock_release
   2.14%  [kernel]   [k] lock_acquire
   1.95%  [kernel]   [k] lock_is_held_type
   1.73%  [kernel]   [k] native_sched_clock
   1.18%  [kernel]   [k] dw_readl
   1.17%  libc-2.27.so   [.] __memmove_avx_unaligned_erms
   1.07%  [kernel]   [k] lock_acquired
   1.05%  [kernel]   [k] __fget
   1.01%  libQt5Core.so.5.10.1   [.] QString::append
   0.85%  libQt5Core.so.5.10.1   [.] 0x002be7d4
   0.72%  [kernel]   [k] get_mem_cgroup_from_mm
   0.71%  [kernel]   [k] mark_lock
   0.69%  [kernel]   [k] __lock_is_held
   0.69%  [kernel]   [k] idma64_irq
   0.63%  libxul.so  [.] 0x0345edd4
   0.61%  [kernel]   [k] match_held_lock
   0.59%  [kernel]   [k] update_blocked_averages
   0.59%  [kernel]   [k] _raw_spin_lock_irqsave
   0.58%  firefox[.] free
   0.58%  libpthread-2.27.so [.] __pthread_mutex_lock
   0.53%  [kernel]   [k] __schedule
   0.52%  [kernel]   [k] do_raw_spin_trylock
   0.52%  libc-2.27.so   [.] malloc
   0.49%  libxul.so  [.] 0x02543cd2
   0.49%  [kernel]   [k] sock_poll
   0.47%  [kernel]   [k] policy_node


-- 
Rajeesh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IPKTLOTVP32TPB37B43DAWXEMBOAV2JK/

Re: Mass rebuild, mass Golang packages failures

[Jakub Cajka]

- Original Message -
> From: "Robert-André Mauchin" 
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, July 17, 2018 2:52:05 PM
> Subject: Re: Mass rebuild, mass Golang packages failures
> 
> On mardi 17 juillet 2018 14:34:49 CEST you wrote:
> > Hello,
> > 
> > 
> > Since the mass rebuild and maybe because of Golang 1.11 beta 1, all the
> > Golang package containing a binary fail because the debuginfo are not
> > generated:
> > 
> > RPM build errors:
> > error: Empty %files file /builddir/build/BUILD/rclone-1.42/
> > debugsourcefiles.list
> > Empty %files file
> > /builddir/build/BUILD/rclone-1.42/debugsourcefiles.list Child return code
> > was: 1
> > 
> >  whereas it was working correctly before.
> > 
> > Has anyone any idea what is causing this and how it can be fixed?
> > 
> > 
> > Best regards,
> > 
> > Robert-André
> 
> The problem seems to be caused by the compressing of debug info:
> https://github.com/golang/go/issues/11799
> 
> Disabling the compression with -ldflags=-compressdwarf=false seems to solve
> the issue.
> 
> I don't know if this should be made default in %gobuild or if we ned to find
> a
> way to extract compressed debuginfo.
> 
For the record.

I have patched Golang to not output compressed DWARF information by default 
until the underlying issue in the rpm/debuginfo is 
resolved(https://bugzilla.redhat.com/show_bug.cgi?id=1602096). You can enable 
it, if you wish to use it outside of RPM, by using the 
-ldflags=-compressdwarf=true.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EEF5P4JS5HE25ISRQWAVIYAVRAB4PTLJ/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NOVNHHLKC3V356MPVF5LSQVZN4GXL4D4/

Again, please announce your so-name bumps!

[Christian Dersch]

Hi all,

please announce your so-name bumps *before* you push them. This time LibRaw
bumped its version, as a result we have broken dependencies and some
composes like Astronomy spin fail to build…

 Problem 1: conflicting requests
  - nothing provides libraw.so.16()(64bit) needed by siril-0.9.9-2.fc29.x86_64
 Problem 2: conflicting requests
  - nothing provides libraw.so.16()(64bit) needed by
kstars-1:2.9.6-2.fc29.x86_64
 Problem 3: conflicting requests
  - nothing provides libraw.so.16()(64bit) needed by
indi-gphoto-1.7.2-2.fc29.x86_64
 Problem 4: conflicting requests
  - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
libgegl-0.4.so.0()(64bit), but none of the providers can be installed
  - package gimp-2:2.10.4-1.fc29.1.x86_64 requires
libgegl-npd-0.4.so()(64bit), but none of the providers can be
installed
  - package gimp-2:2.10.4-1.fc29.1.x86_64 requires gegl04(x86-64) >=
0.4.4, but none of the providers can be installed
  - nothing provides libraw.so.16()(64bit) needed by gegl04-0.4.4-1.fc29.x86_64

I'm going to rebuild gimp, indi-gphoto, kstars and siril now. But I'm sure
there are more broken dependencies.

Greetings,
Christian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7WU6VQNCWD2UKHUNDP2APFLEITWVEM3T/