Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Fri, 2017-08-25 at 06:59 +0200, Remi Collet wrote:
> Le 25/08/2017 à 03:31, Adam Williamson a écrit :
> > On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
> > > On 08/24/2017 11:36 AM, Adam Williamson wrote:
> > > > Sorry, of course we have to actually build 6.9.9-9. It looks like
> > > > you're on this already, thanks.
> > > 
> > > I've also created updates in Bodhi. Please feel free to attach your 
> > > builds to it.
> > > 
> > > F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f
> > > F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31
> > 
> > I have done nearly all the rebuilds and added them to the updates, just
> > waiting on inkscape for f25 to finish up, and buildroot overrides for
> > synfig to kick in so I can build synfigstudio.
> 
> Thanks for your work on this.
> 
> About php-pecl-imagick, I think we'll have to apply patch from
> 
>   https://github.com/mkoppanen/imagick/pull/186
> 
> In Fedora 25 / 26, so users will be aware of some removed methods in
> Fedora 27
> 
> Waiting for upstream feedback about this very old PR, and will try to
> manage it (probably after the current update will be in stable to not
> differ it more than needed)

Sure, sounds sensible (assuming we actually wind up sticking with 7.x
in F27+; it does seem like quite a bit of work will be needed for
that).

> 
> Remi
> 
> 
> P.S. I also need to manage update of ImageMagick6 and ImageMagick7 for
> users of my repository, to not break everything, and push new build at
> same time than official updates...

The updates have autokarma disabled; I guess Michael and I will try to
synchronize with you, and other major third-party repo maintainers,
when we're planning to push them stable. Thanks for the note!
-- 
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

Re: Urgent attention required; ImageMagick update breakage

[Remi Collet]

Le 25/08/2017 à 03:31, Adam Williamson a écrit :
> On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
>> On 08/24/2017 11:36 AM, Adam Williamson wrote:
>>> Sorry, of course we have to actually build 6.9.9-9. It looks like
>>> you're on this already, thanks.
>>
>> I've also created updates in Bodhi. Please feel free to attach your builds 
>> to it.
>>
>> F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f
>> F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31
> 
> I have done nearly all the rebuilds and added them to the updates, just
> waiting on inkscape for f25 to finish up, and buildroot overrides for
> synfig to kick in so I can build synfigstudio.

Thanks for your work on this.

About php-pecl-imagick, I think we'll have to apply patch from

https://github.com/mkoppanen/imagick/pull/186

In Fedora 25 / 26, so users will be aware of some removed methods in
Fedora 27

Waiting for upstream feedback about this very old PR, and will try to
manage it (probably after the current update will be in stable to not
differ it more than needed)


Remi


P.S. I also need to manage update of ImageMagick6 and ImageMagick7 for
users of my repository, to not break everything, and push new build at
same time than official updates...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
> On 08/24/2017 11:36 AM, Adam Williamson wrote:
> > Sorry, of course we have to actually build 6.9.9-9. It looks like
> > you're on this already, thanks.
> 
> I've also created updates in Bodhi. Please feel free to attach your builds to 
> it.
> 
> F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f
> F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31

I have done nearly all the rebuilds and added them to the updates, just
waiting on inkscape for f25 to finish up, and buildroot overrides for
synfig to kick in so I can build synfigstudio.

Note: php-magickwand does not build with PHP 7 and no-one upstream
seems terribly inclined to fix it any time soon, so that one's just
going to have to stay broken (I doubt the current package is even
installable on F25 or F26, so this is not likely a regression) unless
someone wants to step up and do the PHP 7 port (I...do not).
-- 
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

[Bug 1484858] perl-Net-IPv6Addr-0.6 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Net-IPv6Addr-0.5 is|perl-Net-IPv6Addr-0.6 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.6
Current version/release in rawhide: 0.2-23.fc27
URL: http://search.cpan.org/dist/Net-IPv6Addr/

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

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 778  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 772  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 662  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 634  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 244  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 140  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  42  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e8124f23c8   
heimdal-7.4.0-1.el6
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-87be2d4d20   
potrace-1.15-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-938c876edd   
php-PHPMailer-5.2.24-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-035ed8efb3   
qpdf-5.1.1-5.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3f527c60d9   
firebird-2.5.7.27050.0-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0ad4c424f0   
redis-3.2.10-2.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-01dbc69547   
exim-4.89-2.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f14c660f60   
tomcat-7.0.81-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c28c0c3e0c   
cacti-1.1.19-1.el6


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

golang-github-MakeNowJust-heredoc-0-0.9.gitbb23615.el6
golang-github-vishvananda-netlink-0-0.15.gitf5a6f69.el6
golang-googlecode-net-0-0.40.git1c05540.el6
golang-googlecode-text-0-0.21.git3bd178b.el6

Details about builds:



 golang-github-MakeNowJust-heredoc-0-0.9.gitbb23615.el6 
(FEDORA-EPEL-2017-f638515a35)
 Package heredoc provides the here-document with keeping indent

Update Information:

Bump to bb23615498cded5e105af4ce27de75b089cbe851

References:

  [ 1 ] Bug #1365480 - Tracker for golang-github-MakeNowJust-heredoc
https://bugzilla.redhat.com/show_bug.cgi?id=1365480




 golang-github-vishvananda-netlink-0-0.15.gitf5a6f69.el6 
(FEDORA-EPEL-2017-2a5235eb65)
 Simple netlink library for go

Update Information:

Bump to upstream f5a6f697a596c788d474984a38a0ac4ba0719e93

References:

  [ 1 ] Bug #1398575 - FTBFS on s390x and ppc64
https://bugzilla.redhat.com/show_bug.cgi?id=1398575




 golang-googlecode-net-0-0.40.git1c05540.el6 (FEDORA-EPEL-2017-5ef68b86b4)
 Supplementary Go networking libraries

Update Information:

Bump to upstream 1c05540f6879653db88113bc4a2b70aec4bd491f

References:

  [ 1 ] Bug #1326890 - FTBFS with gcc-go on s390x
https://bugzilla.redhat.com/show_bug.cgi?id=1326890




 golang-googlecode-text-0-0.21.git3bd178b.el6 (FEDORA-EPEL-2017-1f74963b0b)
 Supplementary Go text libraries

Update Information:

Bump to upstream 3bd178b88a8180be2df394a1fbb81313916f0e7b

References:

  [ 1 ] Bug #1254601 - Tracker for golang-googlecode-text
https://bugzilla.redhat.com/show_bug.cgi?id=1254601

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 10:43 -0500, Michael Cronenworth wrote:
> On 08/24/2017 10:24 AM, Adam Williamson wrote:
> > As Remi said, the changes in 6.9.9 are far less significant than those
> > in 7.0.6. As several people pointed out, sending 7.x to stable releases
> > is clearly against the updates policy. I'd agree we definitely must
> > revert to 6.x for F25 and F26 updates; for those we should send out a
> > 6.9.9-9 update with rebuilds of all deps. I don't care if F27 and
> > Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon
> > at least for F27.
> > 
> > I'm also willing to work on this, but everyone who's interested should
> > agree on a plan first, and then we could possibly split the work up
> > (e.g. into 6.x and 7.x work).
> 
> I'll compromise with F25/26 with 6.9 and F27+ getting 7.0.
> 
> I'll get an Epoch bump started... when it completes if you want to do 
> rebuilds for 
> F25/26 I'll work on F27+.

Note, I am rebuilding ImageMagick itself again for F27 and Rawhide,
because the versioning was wrong: Moez incorrectly moved the patchlevel
from %{version} to %{release}. This is wrong because it is part of the
upstream versioning, not the downstream. Note the NEVRs listed in the
%changelog were still in the old, correct form, but the *actual* NEVRs
of the recent builds were wrong. I have reverted the relevant parts of
the spec to exactly how it was before, and corrected the changelog so
it gives the real NEVRs for each build.

This is significant to rubygem-rmagick.spec , which must specify the
exact version (including patchlevel) of ImageMagick it's built against.
So I had to go ahead and fix this in order to be able to rebuild
rubygem-rmagick correctly (I'm going to do the F27+ rebuilds of it as
well as the F25/F26 rebuilds for git consistency reasons).
-- 
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

[EPEL-devel] How to clean up EPEL 7 broken repoclosure

[Stephen John Smoogen]

So with CentOS-7 CR updated to 7.4 I did a repoclosure of our current
repository. Various packages are needing items which are neither in
CentOS or EPEL. The most needed requirements are:

  2  librados2-devel = 1:0.80.7
  2  libxfce4util.so.6()(64bit)
  2  libzmq.so.4()(64bit)
  2  nautilus-python
  7  nodejs(abi) = 0:0.10
  7  nodejs(v8-abi) = 0:3.14
  2  python-musicbrainzngs >= 0:0.4
  2  python-paste-script
  4  python-rados = 1:0.80.7
  3  python-rbd = 1:0.80.7

Including epel-testing did not help as it just added more packages
which are without requirements.
  7  golang(github.com/stretchr/testify/assert)
 10  golang(golang.org/x/net/context)
  3  golang(golang.org/x/net/context/ctxhttp)
  2  golang(golang.org/x/net/http2)
  2  golang(golang.org/x/net/http2/hpack)
  4  librados2-devel = 1:0.80.7
  2  librbd1-devel = 1:0.80.7
  2  libxfce4util.so.6()(64bit)
  2  libzmq.so.4()(64bit)
  7  nodejs(abi) = 0:0.10
  7  nodejs(v8-abi) = 0:3.14
  2  python-docker-squash >= 0:1.0.0-0.3
  2  python-musicbrainzngs >= 0:0.4
  2  python-oslo-config
  3  python-oslo-utils
  3  python-paste-script
  8  python-rados = 1:0.80.7
  6  python-rbd = 1:0.80.7

There are a lot of

The 79 packages with problems are

TurboGears-1.1.3-8.el7.noarch
airinv-1.00.1-2.el7.x86_64
banshee-2.6.2-11.el7.x86_64
beets-1.4.3-2.el7.noarch
beets-plugins-1.4.3-2.el7.noarch
bionetgen-2.2.5-2.el7.x86_64
blender-2.68a-6.el7.x86_64
ceph-0.80.7-0.8.el7.x86_64
ceph-0.80.7-0.9.el7.x86_64
ceph-common-0.80.7-0.8.el7.x86_64
ceph-common-0.80.7-0.9.el7.x86_64
ceph-devel-compat-0.80.7-0.8.el7.x86_64
ceph-devel-compat-0.80.7-0.9.el7.x86_64
claws-mail-plugins-vcalendar-3.11.1-5.el7.x86_64
dragonegg-3.4-5.el7.x86_64
golang-github-aws-aws-sdk-go-devel-1.4.22-0.1.git6c577e9.el7.noarch
golang-github-cockroachdb-cmux-devel-0-0.4.git112f050.el7.noarch
golang-github-cockroachdb-cmux-unit-test-devel-0-0.4.git112f050.el7.x86_64
golang-github-golang-appengine-devel-0-0.9.git6a43653.el7.noarch
golang-github-grpc-ecosystem-grpc-gateway-devel-1.0.0-0.2.gitf52d055.el7.noarch
golang-github-grpc-grpc-go-devel-1.0.0-0.2.git231b4cf.el7.noarch
golang-github-hashicorp-go-sockaddr-devel-0-0.2.gitaf174a6.el7.noarch
golang-github-jmespath-go-jmespath-unit-test-devel-0.2.2-0.1.gitbd40a43.el7.x86_64
golang-github-lsegal-gucumber-devel-0-0.5.git71608e2.el7.noarch
golang-github-smartystreets-assertions-devel-1.6.0-0.3.git287b434.el7.noarch
golang-github-spf13-cast-unit-test-0-0.6.gite31f36f.el7.x86_64
golang-github-spf13-jWalterWeatherman-unit-test-0-0.6.git33c24e7.el7.x86_64
golang-github-spf13-viper-devel-0-0.7.git1699063.el7.noarch
golang-github-spf13-viper-unit-test-0-0.7.git1699063.el7.x86_64
golang-github-stretchr-objx-devel-0-0.8.gitcbeaeb1.el7.noarch
golang-github-xeipuuv-gojsonschema-unit-test-devel-0-0.1.gitd5336c7.el7.x86_64
golang-golangorg-crypto-devel-0-0.13.git81372b2.el7.noarch
golang-golangorg-oauth2-devel-0-0.18.git1364adb.el7.noarch
golang-google-golang-api-devel-0-0.16.gite6294e6.el7.noarch
golang-google-golangorg-cloud-devel-0-0.10.git872c736.el7.noarch
golang-googlecode-go-crypto-devel-0-0.13.git81372b2.el7.noarch
gramps-3.4.8-1.el7.noarch
hdf5-mpich-devel-1.8.12-9.el7.x86_64
jabber-roster-0.1.1-7.el7.noarch
libcephfs1-devel-0.80.7-0.8.el7.x86_64
libcephfs1-devel-0.80.7-0.9.el7.x86_64
libxfcegui4-4.10.0-5.el7.x86_64
mod_cluster-java-tomcat8-1.3.3-10.el7.noarch
modularity-testing-framework-0.5.1-2.el7.noarch
nodejs-bson-0.2.9-1.el7.x86_64
nodejs-follow-0.11.4-2.el7.noarch
nodejs-fs-ext-0.4.2-2.el7.x86_64
nodejs-i18n-transform-2.1.3-1.el7.noarch
nodejs-i2c-0.1.4-9.el7.x86_64
nodejs-libxmljs-0.9.0-1.el7.x86_64
nodejs-node-expat-2.1.4-5.el7.x86_64
nodejs-node-stringprep-0.2.3-5.el7.x86_64
nodejs-pg-0.12.3-2.el7.x86_64
notify-sharp3-3.0.3-2.el7.x86_64
psad-2.4.3-4.el7.x86_64
python-atomic-reactor-1.6.17-1.el7.noarch
python-atomic-reactor-1.6.23.2-1.el7.noarch
python-ceph-compat-0.80.7-0.8.el7.x86_64
python-ceph-compat-0.80.7-0.9.el7.x86_64
python-cephfs-0.80.7-0.8.el7.x86_64
python-cephfs-0.80.7-0.9.el7.x86_64
python-moksha-wsgi-1.2.2-2.el7.noarch
python-oslo-concurrency-1.4.1-2.el7.noarch
python-proliantutils-2.1.0-1.el7.noarch
python-pylons-1.0.1-2.el7.noarch
python-tahrir-0.8.2-1.el7.noarch
python-tahrir-0.9.0-1.el7.noarch
python-tooz-0.9-1.el7.noarch
python2-abclient-0.2.3-4.el7.noarch
python2-cotyledon-tests-1.2.7-2.el7.noarch
python2-pyfakefs-3.1-1.el7.noarch
python2-staplelib-0.3.3-8.el7.noarch
python3-yamlordereddictloader-0.3.0-1.el7.noarch
rubygem-apipie-bindings-0.0.10-2.el7.noarch
simcrs-1.01.1-2.el7.x86_64
slim-1.3.6-6.el7.x86_64
spacefm-Faenza-1.0.5-2.el7.noarch
unifont-viewer-9.0.06-2.el7.noarch
workrave-xfce-1.10.10-1.el7.x86_64

I think some of the packages are being pulled: (ceph) and some need
rebuilds. I would like to get 

Re: Is a package providing and requiring the same library in the package normal?

[Kevin Kofler]

Rex Dieter wrote:

> Cheng Ye wrote:
> 
>> Hi,
>> This is probably a simple packaging question.
> 
> Yes, per SUBJECT, this is normal and not out of the ordinary.

Right. In particular, it happens if the package containing the library 
libfoo.so.1 also contains an executable or another library linked to 
libfoo.so.1. Then RPM will produce both an AutoProvides and an AutoRequires 
for the library. This is not strictly necessary, but harmless (and 
technically correct). You could use the AutoRequires filtering to filter out 
the unnecessary Requires, but I would not bother doing that, as the Requires 
is technically correct and causes no issues, so filtering it out would just 
be a waste of your time.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modularizing the world fast and iteratively

[Kevin Kofler]

Matthew Miller wrote:
> Core-Extras was a bad ideas because Core was developed inside Red Hat
> in a non-open way and did not allow community involvement beyond that
> of beta testing. Merging it all together was probably the only
> realistic way to fix that (and fixing that was absolutely the best
> thing to do), but if we'd kept separate repos, we'd have addressed the
> technical problems sooner and had a lot more of the flexibility that we
> _really_ need to keep growing.

That was only one aspect of the problem. The bigger issue is that packages 
routinely had to be built without some features because the package was in 
Core and the feature would have required something from Extras (an issue we 
are still seeing with RHEL and EPEL nowadays), packages had to be brought 
from Extras to Core as dependencies, and in some cases, packages actually 
had to be moved from Core to Extras to be able to use dependencies from 
Extras. This issue is now coming back with the modules. Some packages also 
actually had to be split into 2 SRPMs from the same sources, one in Core and 
one in Extras, instead of using subpackages, due to build-time requirements 
on Extras packages. (One example was the package I got sponsored with: 
redhat-artwork-kde, split out from redhat-artwork as part of 
https://fedoraproject.org/wiki/Archive:UnleashKDE – I maintained that for 2 
weeks, then the Core-Extras Merge happened and it was already obsolete. ;-) 
That was an interesting start of a packager career. ;-) )

Having a unified Everything repository from which individual binary packages 
can then be picked from is a huge advantage. It is just too common that you 
have things such as:
* optional plugin subpackages requiring extra dependencies to build. You
  want to build the package with those dependencies, then split the plugins
  into subpackages so that the main runtime package can be installed without
  those dependencies. But with the module isolation, you cannot do that
  anymore.
* documentation requiring huge toolchains such as LaTeX to build, but not to
  view.
* dependencies required only for the test suite, as in the autotools case.

In addition, having a unified end of life makes system maintenance A LOT 
easier for the users.

I consider the whole concept of modularity fatally flawed by design. You are 
about to eat the cake and to not realize that you will not have it anymore 
then. The feature's promise that you can eat your cake and have it too is 
impossible to fulfill.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f25). "Rebuild for ImageMagick"

[notifications]

From 5740cd94afcd3d63ad0bf682ddffc814509baa17 Mon Sep 17 00:00:00 2001
From: Kevin Fenzi 
Date: Jul 30 2017 23:13:11 +
Subject: Rebuild for ImageMagick


---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index 40e794a..f0baa62 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-SubImageFind
 Version:0.03
-Release:12%{?dist}
+Release:13%{?dist}
 Summary:Perl extension for locating a sub-image within an image
 License:GPLv2 and GPLv2+
 # patch to address 
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address has 
been sent upstream at https://rt.cpan.org/Ticket/Display.html?id=93990
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jul 30 2017 Kevin Fenzi  - 0.03-13
+- Rebuild for ImageMagick
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.03-12
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/5740cd94afcd3d63ad0bf682ddffc814509baa17?branch=f25
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f25). "perl dependency renamed to perl-interpreter "

[notifications]

From 3da5e866d4ed8c7fedfde9ec84c8ed41fe7a45c2 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jul 12 2017 13:14:21 +
Subject: perl dependency renamed to perl-interpreter 



---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index 6bbce5c..a36d92e 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -12,7 +12,7 @@ Patch1: image_subimagefind_makefile.patch
 BuildRequires:  fftw-devel
 BuildRequires:  libstdc++-devel
 BuildRequires:  ImageMagick-c++-devel
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
 BuildRequires:  perl(Cwd)



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/3da5e866d4ed8c7fedfde9ec84c8ed41fe7a45c2?branch=f25
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f25). "Perl 5.26 rebuild"

[notifications]

From 92247fed4755b4689c3a373449735adad54c03af Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jun 04 2017 04:47:40 +
Subject: Perl 5.26 rebuild


---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index aedd4f5..6bbce5c 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-SubImageFind
 Version:0.03
-Release:10%{?dist}
+Release:11%{?dist}
 Summary:Perl extension for locating a sub-image within an image
 License:GPLv2 and GPLv2+
 # patch to address 
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address has 
been sent upstream at https://rt.cpan.org/Ticket/Display.html?id=93990
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jun 04 2017 Jitka Plesnikova  - 0.03-11
+- Perl 5.26 rebuild
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
0.03-10
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/92247fed4755b4689c3a373449735adad54c03af?branch=f25
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f25). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild"

[notifications]

From ea52107887624ee4f4921f82bd71b2acd39d724f Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Feb 11 2017 03:40:44 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild


---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index 3a6d417..aedd4f5 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-SubImageFind
 Version:0.03
-Release:9%{?dist}
+Release:10%{?dist}
 Summary:Perl extension for locating a sub-image within an image
 License:GPLv2 and GPLv2+
 # patch to address 
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address has 
been sent upstream at https://rt.cpan.org/Ticket/Display.html?id=93990
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sat Feb 11 2017 Fedora Release Engineering  - 
0.03-10
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
+
 * Sun May 15 2016 Jitka Plesnikova  - 0.03-9
 - Perl 5.24 rebuild
 



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/ea52107887624ee4f4921f82bd71b2acd39d724f?branch=f25
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f25). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild"

[notifications]

From bba450bf9109d101f9617e9f3e2a890c85a2ae4d Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 27 2017 04:30:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild


---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index a36d92e..40e794a 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-SubImageFind
 Version:0.03
-Release:11%{?dist}
+Release:12%{?dist}
 Summary:Perl extension for locating a sub-image within an image
 License:GPLv2 and GPLv2+
 # patch to address 
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address has 
been sent upstream at https://rt.cpan.org/Ticket/Display.html?id=93990
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 27 2017 Fedora Release Engineering  - 
0.03-12
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 0.03-11
 - Perl 5.26 rebuild
 



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/bba450bf9109d101f9617e9f3e2a890c85a2ae4d?branch=f25
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f26). "Rebuild for ImageMagick"

[notifications]

From 5740cd94afcd3d63ad0bf682ddffc814509baa17 Mon Sep 17 00:00:00 2001
From: Kevin Fenzi 
Date: Jul 30 2017 23:13:11 +
Subject: Rebuild for ImageMagick


---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index 40e794a..f0baa62 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-SubImageFind
 Version:0.03
-Release:12%{?dist}
+Release:13%{?dist}
 Summary:Perl extension for locating a sub-image within an image
 License:GPLv2 and GPLv2+
 # patch to address 
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address has 
been sent upstream at https://rt.cpan.org/Ticket/Display.html?id=93990
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jul 30 2017 Kevin Fenzi  - 0.03-13
+- Rebuild for ImageMagick
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.03-12
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/5740cd94afcd3d63ad0bf682ddffc814509baa17?branch=f26
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f26). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild"

[notifications]

From bba450bf9109d101f9617e9f3e2a890c85a2ae4d Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 27 2017 04:30:10 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild


---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index a36d92e..40e794a 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-SubImageFind
 Version:0.03
-Release:11%{?dist}
+Release:12%{?dist}
 Summary:Perl extension for locating a sub-image within an image
 License:GPLv2 and GPLv2+
 # patch to address 
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address has 
been sent upstream at https://rt.cpan.org/Ticket/Display.html?id=93990
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 27 2017 Fedora Release Engineering  - 
0.03-12
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 0.03-11
 - Perl 5.26 rebuild
 



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/bba450bf9109d101f9617e9f3e2a890c85a2ae4d?branch=f26
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f26). "perl dependency renamed to perl-interpreter "

[notifications]

From 3da5e866d4ed8c7fedfde9ec84c8ed41fe7a45c2 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jul 12 2017 13:14:21 +
Subject: perl dependency renamed to perl-interpreter 



---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index 6bbce5c..a36d92e 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -12,7 +12,7 @@ Patch1: image_subimagefind_makefile.patch
 BuildRequires:  fftw-devel
 BuildRequires:  libstdc++-devel
 BuildRequires:  ImageMagick-c++-devel
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
 BuildRequires:  perl(Cwd)



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/3da5e866d4ed8c7fedfde9ec84c8ed41fe7a45c2?branch=f26
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adamwill pushed to perl-Image-SubImageFind (f26). "Perl 5.26 rebuild"

[notifications]

From 92247fed4755b4689c3a373449735adad54c03af Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jun 04 2017 04:47:40 +
Subject: Perl 5.26 rebuild


---

diff --git a/perl-Image-SubImageFind.spec b/perl-Image-SubImageFind.spec
index aedd4f5..6bbce5c 100644
--- a/perl-Image-SubImageFind.spec
+++ b/perl-Image-SubImageFind.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-SubImageFind
 Version:0.03
-Release:10%{?dist}
+Release:11%{?dist}
 Summary:Perl extension for locating a sub-image within an image
 License:GPLv2 and GPLv2+
 # patch to address 
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address has 
been sent upstream at https://rt.cpan.org/Ticket/Display.html?id=93990
@@ -56,6 +56,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Sun Jun 04 2017 Jitka Plesnikova  - 0.03-11
+- Perl 5.26 rebuild
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
0.03-10
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Image-SubImageFind/c/92247fed4755b4689c3a373449735adad54c03af?branch=f26
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Jan Kratochvil]

On Thu, 24 Aug 2017 21:51:59 +0200, Sandro Mani wrote:
> May well be mistaken, but doesn't ABRT work with coredumps, which you can't
> get on Windows systems?

OK, thanks for showing me the setup.  I was still imagining running PE32
binaries by Wine, I did not realize there exist real Windows systems. :-)


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 10:43 -0500, Michael Cronenworth wrote:
> 
> I'll get an Epoch bump started... when it completes if you want to do 
> rebuilds for 
> F25/26 I'll work on F27+.

BTW, it occurred to me for F27+ it may be worth checking if each
project supports a less messy alternative, like GraphicsMagick, which I
think seems to be a rather saner option. For F25/F26 of course I won't
make such switches.
-- 
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 Rawhide-20170824.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 29/137 (x86_64), 1/2 (arm)

ID: 133935  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133935
ID: 133942  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/133942
ID: 133944  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/133944
ID: 133948  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/133948
ID: 133956  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/133956
ID: 133958  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133958
ID: 133962  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/133962
ID: 133970  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133970
ID: 133975  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133975
ID: 133979  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/133979
ID: 133983  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/133983
ID: 133984  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/133984
ID: 133988  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133988
ID: 133989  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133989
ID: 133990  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/133990
ID: 133999  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/133999
ID: 134000  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/134000
ID: 134001  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/134001
ID: 134003  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/134003
ID: 134004  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/134004
ID: 134005  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/134005
ID: 134006  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/134006
ID: 134007  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/134007
ID: 134008  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/134008
ID: 134009  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/134009
ID: 134011  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/134011
ID: 134012  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/134012
ID: 134066  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/134066
ID: 134067  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/134067
ID: 134068  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/134068

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

ID: 133954  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133954
ID: 134015  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/134015

Passed openQA tests: 94/137 (x86_64)

Skipped openQA tests: 9 of 139
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Sandro Mani]

On 24.08.2017 21:42, Jan Kratochvil wrote:

On Thu, 24 Aug 2017 21:36:29 +0200, Sandro Mani wrote:

While I'm at it, my current technique for interpreting mingw stacktraces
produced without debuginfos is parsing the text and calling addr2line for
each stack frame. Is there a neater technique?

Unaware of.  But then why you do not have the debuginfos?
You deploy the application without debuginfos to save space, and then 
have a crash-handler which attaches gdb to the dying process, produces a 
stacktrace, and sends it to the developer if the user wants.

And also why ABRT
does not process it?  ABRT has its retrace server infrastructure to do exactly
that but I guess ABRT cannot handle PE32.
May well be mistaken, but doesn't ABRT work with coredumps, which you 
can't get on Windows systems?




when one has to do live-debugging on without debuginfos.

Why?  debuginfos are easily available from standard repos.
One example: you are at a customers to debug some misbehaviour on a 
crippled down Windows system where you can't place the *.debug files 
next to the binaries, and perhaps don't event have internet access...

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Jan Kratochvil]

On Thu, 24 Aug 2017 21:36:29 +0200, Sandro Mani wrote:
> While I'm at it, my current technique for interpreting mingw stacktraces
> produced without debuginfos is parsing the text and calling addr2line for
> each stack frame. Is there a neater technique?

Unaware of.  But then why you do not have the debuginfos?  And also why ABRT
does not process it?  ABRT has its retrace server infrastructure to do exactly
that but I guess ABRT cannot handle PE32.


> when one has to do live-debugging on without debuginfos.

Why?  debuginfos are easily available from standard repos.


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Sandro Mani]

On 24.08.2017 14:52, Jan Kratochvil wrote:

On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote:

On 24.08.2017 14:18, Jan Kratochvil wrote:

On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:

I'm investigating why gdb returns so unreliable backtraces for mingw
binaries without debuginfos,

They are perfectly reliable.  They just do not show the function names.
But those can be looked up later from *-debuginfo.rpm.

I regularly have the issue that with larger programs, gdb aborts with
"Backtrace stopped: previous frame inner to this frame (corrupt stack?) " if
the crash happens somewhere deep down, say in some Qt library, and never
gets to printing the frames of the caller of the application code I'm
interested in. If debugsymbols are available, it prints the all the frames.
Hence "unreliable". I supose this might be a bug, but I have no idea how to
investigate.

In your OP example:

: #0  0x0040157d in ?? ()
: #1  0x004015b5 in ?? ()
: #2  0x004013f7 in ?? ()
: #3  0x0040152b in ?? ()
: #4  0x76af652d in KERNEL32!BaseThreadInitThunk ()
:from C:\Windows\system32\kernel32.dll
: #5  0x76d2c521 in ntdll!RtlUserThreadStart ()
:from C:\Windows\SYSTEM32\ntdll.dll
: #6  0x in ?? ()
: Backtrace stopped: previous frame inner to this frame (corrupt stack?)
:
: With strip-debug, gdb reports:
:
: #0  0x0040157d in foo() ()
: #1  0x004015b5 in main ()

You can see the backtrace is the same. I guess you will see that
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

even with installed *-debuginfo.rpm after you enter:
(gdb) set backtrace past-main on
(gdb) set backtrace past-entry on

The symbols (particularly the "main" symbol) just tell GDB to stop backtracing
earlier.  But the part that it already backtraced is the same.

In some cases *-debuginfo.rpm can really improve the backtrace (even the
numerical-only one, ignoring the address->functionname decoration).
This is due to .debug_frame sections there when the main binary is missing
corresponding .eh_frame.  But I have no idea how this works in PE32 and then
it is a packaging bug (missing -fasynchronous-unwind-tables) as the
numerical-only backtraces should be the same with and without debuginfo.

Last difference can be due to inlined functions being shown just with
*-debuginfo.rpm but that is not much important (and reconstructable from the
numerical-only backtrace).
Thanks for your explanations. Actually I wonder if indeed fooled by the 
"backtrace past-main on" thing. Next time I'll hit some cryptic 
stacktrace I'll double check.


While I'm at it, my current technique for interpreting mingw stacktraces 
produced without debuginfos is parsing the text and calling addr2line 
for each stack frame. Is there a neater technique?

But these *-debuginfo.rpm differences will not happen with your planned bare
functionname symbols (called ELF symbols or PE32 symbols in your case).
I'll do a quick size-analysis of some common packages (say gtk, qt) and 
if the size increase is not prohibitively large, I'll file a change to 
have these symbols included by default in the mingw binaries. Beyond 
possible stacktrace quality differences, I'm also interested in making 
life more pleasant when one has to do live-debugging on without debuginfos.


Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 11:28 -0700, Moez Roy wrote:
> 
> A rebuild of affected packages would be required regardless, so it made
> more sense to just update it directly to v7 which has High Dynamic Range
> Imaging by default and more Pixel channels.

The problem is that 7.x makes *more*, and more significant, API/ABI
changes than 6.9.9. It's very likely some code will rebuild without
modification against 6.9.9 but not at all against 7.x. And landing
major updates with major behaviour changes in stable releases is just
flat out against the updates policy, even if you rebuild dependent
packages.
-- 
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

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 13:47 -0500, Michael Cronenworth wrote:
> On 08/24/2017 11:36 AM, Adam Williamson wrote:
> > Sorry, of course we have to actually build 6.9.9-9. It looks like
> > you're on this already, thanks.
> 
> I've also created updates in Bodhi. Please feel free to attach your builds to 
> it.
> 
> F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f
> F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31

Roger, thanks. I'm also still working on rdma-related rebuilds for
Rawhide / F27, so I'll be kinda picking things up through the day. If
anyone else wants to help out, feel free - maybe just call out on
#fedora-devel what packages you're working on, so we don't duplicate
work.
-- 
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

Re: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

On 08/24/2017 11:36 AM, Adam Williamson wrote:

Sorry, of course we have to actually build 6.9.9-9. It looks like
you're on this already, thanks.


I've also created updates in Bodhi. Please feel free to attach your builds to 
it.

F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f27031c8f
F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3a568adb31
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Moez Roy]

On Thu, Aug 24, 2017 at 11:12 AM, Michael Cronenworth 
wrote:

> On 08/24/2017 11:36 AM, Adam Williamson wrote:
>
>> Sorry, of course we have to actually build 6.9.9-9. It looks like
>> you're on this already, thanks.
>>
>
> The build override has landed.
>
> Thanks,
> Michael
>

​I transferred ownership of ImageMagick to you (mooninite).​


​I don't have the privs to rebuild affected packages as mentioned in notes,
so it is better if a proven packager owns this package.

A rebuild of affected packages would be required regardless, so it made
more sense to just update it directly to v7 which has High Dynamic Range
Imaging by default and more Pixel channels.

-Moez Roy​
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

On 08/24/2017 11:36 AM, Adam Williamson wrote:

Sorry, of course we have to actually build 6.9.9-9. It looks like
you're on this already, thanks.


The build override has landed.

Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: modularity: (my) expectations vs. reality

[stan]

On Thu, 24 Aug 2017 08:21:57 +0200
Tomas Tomecek  wrote:

> ​We would need to develop a dedicated, non-trivial tooling to enable
> this functionality.​ And honestly, I can't even imagine how this
> could be even possible to implement for all ecosystems (compiled
> languages, interpreted languages).

Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

malloc trace/playback for glibc 2.26 and rawhide...

[DJ Delorie]

With glibc 2.26 there's a new per-thread cache in malloc, which
improves malloc performance in general, and hopefully, specifically
for the apps which each of you are most concerned about.  In the event
that you feel it doesn't help, or if you have other concerns about
malloc performance, there's another part of my malloc performance work
that's not in glibc 2.26 - the ability to capture and play back malloc
activity.

I created these tools to help with the malloc performance testing,
since reliably recreating situations I wanted to test was difficult -
especially with apps that interacted with the user, like LibreOffice.
It's also handy for capturing data from apps that are difficult to
configure (think, "requires other hosts to provide services" or "only
happens with my /etc/passwd") and the occasional (gasp!) proprietary
app that cannot be included in a bug report.

Anyway, I've put the patch (suitable for rpmbuild) and tools tarball
(they can run on a separate machine), along with a pointer to a COPR
repo with F26 and rawhide builds of glibc-2.26.90-5 (x86 32/64 only
for F26, ppc64le included for rawhide), here:

  http://people.redhat.com/dj/glibc/

Instructions for using the tools are also there.  The tarball also
includes a sample trace (of /bin/ls ;) to play with.

So, if you think you have malloc-related performance issues, or want
to benchmark a difficult application on different malloc
implementations (the simulator is a regular app, you can LD_PRELOAD an
interposed malloc), please give this a try.

If you think you have an unusual app and want me to consider your
malloc performance in future work, please feel free to send me
(privately, they're huge) a workload to include in my collection :-)

Thanks!
DJ
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1484602] perl-Test-Trap-v0.3.3 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Test-Trap-0.3.3-1.fc26 has been pushed to the Fedora 26 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-2017-8b5aae8a94

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

Re: %py3_install fails to accept arguments

[Juan Orti Alcaine]

2017-08-24 9:54 GMT+02:00 Juan Orti Alcaine :
> Hi,
>
> I'm getting failed builds [1] in rawhide and f27 because the macro
> %py3_install fails when called with arguments. It was fine until f26.
>
> The package is rhythmbox-ampache, and I call the macro like this:
>
>
> %global py_install_args --no-glib-compile-schemas

Enquoting the value seems to fix it !?

%global py_install_args "--no-glib-compile-schemas"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Josh Stone]

On 08/24/2017 05:18 AM, Jan Kratochvil wrote:
> But the symbols take less space there as they are compressed.  You can check
> how it looks like for Linux ELF binaries by:
>   rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section 
> .gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz -dv 
> /tmp/bash-debugdata.xz;readelf -Wa /tmp/bash-debugdata|less

FWIW, elfutils can read .gnu_debugdata directly:

eu-readelf --elf-section -Wa /bin/bash
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Platform Python changes and python3dist tags

[Miro Hrončok]

On 24.8.2017 03:17, Scott Talbert wrote:

On Tue, 22 Aug 2017, Scott Talbert wrote:


Hi,

I was just trying to build a new package in Rawhide that built fine a 
few days ago.  The failure seems to be occurring because the python3 
setuptools_scm module isn't being found.  I'm using the new 
pythonXdist tags:


BuildRequires:  %{py2_dist py pytest setuptools_scm}
BuildRequires:  %{py3_dist py pytest setuptools_scm}

It seems this is causing several of the recently added platform-python
packages to be pulled in:
Installing:
platform-python-pytestnoarch3.2.1-2.fc28   fedora 
438 k
platform-python-setuptools_scmnoarch1.15.6-4.fc28  fedora 
36 k


Both the python3-setuptools_scm and platform-python-setuptools_scm 
packages have the python3dist tag:


$ rpm -q --provides -p 
platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm: 
Header V3 RSA/SHA256 Signature, key ID 9db62fb1: NOKEY

platform-python-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6

$ rpm -q --provides -p python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 
RSA/SHA256 Signature, key ID 9db62fb1: NOKEY

python3-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6
[swt2c@rawhide-test ~][PROD]$

It seems that probably the platform-python packages shouldn't have 
these tags?


I'm hearing a lot of crickets.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1484607 against rpm 
as I didn't see any obvious way for the platform-python packages to 
exclude themselves from the python3dist provides.


I'm just going to stop using the py3_dist stuff for now.

Scott


This has just been fixed. Thanks for noticing.


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

Re: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

On 08/24/2017 11:36 AM, Adam Williamson wrote:

Sorry, of course we have to actually build 6.9.9-9. It looks like
you're on this already, thanks.


Yes, I've issued builds. Once the buildroot override is available I'll send another 
email.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 09:27 -0700, Adam Williamson wrote:
> On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote:
> > On Thu, 24 Aug 2017 10:54:12 -0500
> > Michael Cronenworth  wrote:
> > 
> > > On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
> > > > Epoch bump? Why? The f25/f26 packages never even got to testing...
> > > > Just revert the commits, etc.
> > > 
> > > I thought Koji did an NVR check? Won't let a lower version or is it
> > > only when it's been pushed?
> > 
> > koji won't let you build one NVR twice for non-scratch builds
> > 
> > bodhi has some NVR checks, but they are not blocking
> 
> Yep, +1 others, for F25/F26 we don't need to do any new build for
> imagemagick itself, just revert the commits in the repo, set up a
> buildroot override for the 6.9.9-9 package, and then get to rebuilding
> dependencies.

Sorry, of course we have to actually build 6.9.9-9. It looks like
you're on this already, thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Kalev Lember]

On 08/24/2017 06:27 PM, Adam Williamson wrote:
> On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote:
>> On Thu, 24 Aug 2017 10:54:12 -0500
>> Michael Cronenworth  wrote:
>>
>>> On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
 Epoch bump? Why? The f25/f26 packages never even got to testing...
 Just revert the commits, etc.
>>>
>>> I thought Koji did an NVR check? Won't let a lower version or is it
>>> only when it's been pushed?
>>
>> koji won't let you build one NVR twice for non-scratch builds
>>
>> bodhi has some NVR checks, but they are not blocking
> 
> Yep, +1 others, for F25/F26 we don't need to do any new build for
> imagemagick itself, just revert the commits in the repo, set up a
> buildroot override for the 6.9.9-9 package, and then get to rebuilding
> dependencies.

Yes, agreed. This sounds like the best course of action; latest 6.9 for
F25/F26, and 7.0 for F27/F28.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

[Kalev Lember]

On 08/24/2017 05:48 PM, Kevin Fenzi wrote:
> I was going to look at f25/f26 for a 6.x update, but I haven't had any
> time to get to it. ;( Would need a bunch of rebuilds and waiting in
> testing a while so 3rd parties could see it and rebuild at the very least.

I think we're going to need an ABI compatibility package for the old
soname. This serves a two fold purpose: a) if something in F25/F26 fails
to rebuild against the new soname, it can keep using the compat package
and doesn't block the whole ImageMagick update from going to stable, and
b) we won't break 3rd parties code who might be shipping binaries linked
with the old soname.

I'm happy to help with this too, both with rebuilds and putting together
a compat package / reviewing it.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 18:15 +0200, Dan Horák wrote:
> On Thu, 24 Aug 2017 10:54:12 -0500
> Michael Cronenworth  wrote:
> 
> > On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
> > > Epoch bump? Why? The f25/f26 packages never even got to testing...
> > > Just revert the commits, etc.
> > 
> > I thought Koji did an NVR check? Won't let a lower version or is it
> > only when it's been pushed?
> 
> koji won't let you build one NVR twice for non-scratch builds
> 
> bodhi has some NVR checks, but they are not blocking

Yep, +1 others, for F25/F26 we don't need to do any new build for
imagemagick itself, just revert the commits in the repo, set up a
buildroot override for the 6.9.9-9 package, and then get to rebuilding
dependencies.
-- 
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

Re: Urgent attention required; ImageMagick update breakage

[Dan Horák]

On Thu, 24 Aug 2017 10:54:12 -0500
Michael Cronenworth  wrote:

> On 08/24/2017 10:49 AM, Kevin Fenzi wrote:
> > Epoch bump? Why? The f25/f26 packages never even got to testing...
> > Just revert the commits, etc.
> 
> I thought Koji did an NVR check? Won't let a lower version or is it
> only when it's been pushed?

koji won't let you build one NVR twice for non-scratch builds

bodhi has some NVR checks, but they are not blocking


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2017-08-25)

[Adam Miller]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2017-08-25 16:00 UTC'


Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1763 Fedora Modules Guidelines and Process
.fesco 1763
https://pagure.io/fesco/issue/1763

#topic #1765 Proposed Fedora 28 schedule
.fesco 1765
https://pagure.io/fesco/issue/1765

= New business =

#topic #1761 Update of "Fedora Release Live Cycle" and "Changes / Policy"
.fesco 1761
https://pagure.io/fesco/issue/1761

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

On 08/24/2017 10:49 AM, Kevin Fenzi wrote:

Epoch bump? Why? The f25/f26 packages never even got to testing... Just
revert the commits, etc.


I thought Koji did an NVR check? Won't let a lower version or is it only when it's 
been pushed?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Remi Collet]

Le 24/08/2017 à 17:43, Michael Cronenworth a écrit :

> I'll get an Epoch bump started... when it completes if you want to do
> rebuilds for F25/26 I'll work on F27+.

I don't think epoch bump is needed
(package never go in the repo)

Remi

> 
> Thanks,
> Michael
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Kevin Fenzi]

On 08/24/2017 08:43 AM, Michael Cronenworth wrote:
> On 08/24/2017 10:24 AM, Adam Williamson wrote:
>> As Remi said, the changes in 6.9.9 are far less significant than those
>> in 7.0.6. As several people pointed out, sending 7.x to stable releases
>> is clearly against the updates policy. I'd agree we definitely must
>> revert to 6.x for F25 and F26 updates; for those we should send out a
>> 6.9.9-9 update with rebuilds of all deps. I don't care if F27 and
>> Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon
>> at least for F27.
>>
>> I'm also willing to work on this, but everyone who's interested should
>> agree on a plan first, and then we could possibly split the work up
>> (e.g. into 6.x and 7.x work).
> 
> I'll compromise with F25/26 with 6.9 and F27+ getting 7.0.
> 
> I'll get an Epoch bump started... when it completes if you want to do
> rebuilds for F25/26 I'll work on F27+.

Epoch bump? Why? The f25/f26 packages never even got to testing... Just
revert the commits, etc.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

[Kevin Fenzi]

On 08/24/2017 08:19 AM, Adam Williamson wrote:
> On Thu, 2017-08-24 at 09:12 +0200, Remi Collet wrote:
>> Le 24/08/2017 à 08:58, Adam Williamson a écrit :
>>> On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote:
 Le 24/08/2017 à 02:32, Moez Roy a écrit :

> The soname bump requires packages that depend on it need to be rebuilt, so
> I updated ImageMagick to 7.0.6-9.


 Such a version bump in stable branch is not acceptable.

 ImageMagick 7 removed lot of functions (deprecated in v6)

 Especially as ImageMagick 6 is still maintained.

 BTW, latest version 6.9.9-9 also have some API changes

 - 6.9.6-8 => bump to .3
 - 6.9.7-6 => bump to .4
 - 6.9.9-0 => bump to .5

 Yes, this package is a nightmare.
>>>
>>> Note the versioning is a bit subtle. What was released upstream was
>>> 6.9.9-9 , which in our versioning would be 6.9.9.9 . Upstream *didn't*
>>> go from 6.9.8 to 6.9.9, but from 6.9.9-8 to 6.9.9-9. The package in
>>> Fedora before all this mess was versioned 6.9.9.3 , which I believe
>>> would be upstream's 6.9.9-3 , and I *think* there is no ABI/API
>>> incompatibility between 6.9.9-3 and 6.9.9-9. The soname in the 6.9.9.3
>>> packages was already
>>> "libMagickCore-6.Q16.so.5()(64bit)".
>>
>> Yes in F27+ (6.9.9.3)
>>
>> F25/F26 have 6.9.3.0 (upstream 6.9.3-0) with
>> libMagickCore-6.Q16.so.2
>> libMagickWand-6.Q16.so.2
> 
> Yep, I just looked back and saw that nirik built upstream 6.9.9-3 but
> hadn't actually sent it as an update, since it was an soname bump and
> all the necessary rebuilds weren't done yet :/

Sigh. Yeah, I didn't want to push 7.x to even rawhide without
investigation that all dependent packages were ready to move to it.

I was going to look at f25/f26 for a 6.x update, but I haven't had any
time to get to it. ;( Would need a bunch of rebuilds and waiting in
testing a while so 3rd parties could see it and rebuild at the very least.

kevin






signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

On 08/24/2017 10:24 AM, Adam Williamson wrote:

As Remi said, the changes in 6.9.9 are far less significant than those
in 7.0.6. As several people pointed out, sending 7.x to stable releases
is clearly against the updates policy. I'd agree we definitely must
revert to 6.x for F25 and F26 updates; for those we should send out a
6.9.9-9 update with rebuilds of all deps. I don't care if F27 and
Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon
at least for F27.

I'm also willing to work on this, but everyone who's interested should
agree on a plan first, and then we could possibly split the work up
(e.g. into 6.x and 7.x work).


I'll compromise with F25/26 with 6.9 and F27+ getting 7.0.

I'll get an Epoch bump started... when it completes if you want to do rebuilds for 
F25/26 I'll work on F27+.


Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: RHEL-7.4 is released (build roots updating)

[Stephen John Smoogen]

On 23 August 2017 at 10:59, Mátyás Selmeci  wrote:
> Is there a list of the packages that will be removed from EPEL because they
> are in RHEL 7.4? (And when that will happen?) Many of our users are on
> Scientific Linux and SL 7.4 is not out yet.
>

There were several lists and they were removed from EPEL a week or so ago.

https://pagure.io/releng/issue/6950
https://pagure.io/releng/issue/6948

covers the packages that should have been removed. I am now checking
with the CentOS CR to see if any others may need to be watched.

> Thanks,
> -Mat
>
> On 08/01/17 16:24, Stephen John Smoogen wrote:
>
>
> RHEL-7.4 was released today and so the build roots for EPEL packages will be
> updated as soon as the automatic reposync is done.
>
> This may cause problems for EPEL builds for CentOS people so please be
> careful in pushing items from epel-testing to epel until CentOS is caught
> up.
>
> --
> Stephen J Smoogen.
>
>
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 09:47 -0500, Michael Cronenworth wrote:
> On 08/24/2017 09:25 AM, Remi Collet wrote:
> > I really think we have to revert to 6 in stable branch
> > (and perhaps even in F27, which is very close to feature freeze)
> > 
> > - soname bump
> > - lot of removed API
> > - HDRI enabled by default
> 
> The SONAME is changing in 6.9 as well so I'm not sure reverting is great 
> either 
> otherwise I would have done it.
> 
> I'm prepared to perform rebuilds and push updates to get this resolved. 
> Assuming no 
> objections in the next day I'll get it rolling. Worst case if there's 
> negative karma 
> on the updates I'll push a revert to 6.9.

As Remi said, the changes in 6.9.9 are far less significant than those
in 7.0.6. As several people pointed out, sending 7.x to stable releases
is clearly against the updates policy. I'd agree we definitely must
revert to 6.x for F25 and F26 updates; for those we should send out a
6.9.9-9 update with rebuilds of all deps. I don't care if F27 and
Rawhide go to 6.9.9-9 or 7.0.6, but whichever, it should get done soon
at least for F27.

I'm also willing to work on this, but everyone who's interested should
agree on a plan first, and then we could possibly split the work up
(e.g. into 6.x and 7.x work).
-- 
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

Re: About "debugsource" package and repo layout

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2017-08-24 at 17:04 +0200, Remi Collet wrote:
> Hi,
> 
> Since F27, for each package, we have a "debugsource" package.
> 
> Question is about the repository layout
> 
> For now these packages are available in the standard repository
> 
> Ex:
> http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Ever
> ything/x86_64/os/Packages/y/
> 
>   yajl-2.1.0-8.fc27.x86_64.rpm
>   yajl-debugsource-2.1.0-8.fc27.x86_64.rpm
>   yajl-devel-2.1.0-8.fc27.x86_64.rpm
> 
> Shouldn't these packages be in the "debug" repository
> 
> ie:
> http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Ever
> ything/x86_64/debug/tree/Packages/y/
> 
>   yajl-debuginfo-2.1.0-8.fc27.x86_64.rpm
> 
> 
> 
Definitely you are right and those should be there, check:
- - https://pagure.io/pungi/issue/684
- - https://pagure.io/koji/pull-request/524

Unfortunately, I think those fixes are still not deployed..
> 
> Remi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlme7sAACgkQaVcUvRu8
X0zOzQ//dk9MEgqEkcyX1qfacjXLUmXyiBdUvpNaUMMAp4NyxYqNWWXuQPHpfboM
3ImqnLCBrac2hupA3PlPtRibFIcUKZIMzWf9IIhmyLEhgb9r8ltSY/zfRnALss6B
PgrMHl5y0/9nK/nz7Lb66hpcL6nDmRlna+kfdftbDjcMgwN3TyqFmmGFzykT7tjN
ZuIWI5F9QwXNOCvY7OvA8M1zCi+29Fvgo4hzNMDO+dAG+kwRyB+S3ImZ1EQcJXmB
PghnuSScDBND22Ys7R8VYm3ZJpspV5g9eH+DERgW13k4GAwHhSzumzVX4raPptco
DtPqLqkAp0hG7MnCmk3aR5WiW3DND2qPsCgwlF0ROqeUgFIc4NdNDMixypC58zoQ
MciWkgSK9DyEaLlk9V/XoHFfUMUZloLGM4WM9yYUF9gmZWy6x/g9NlqhLd7+A3Vt
Rso+KP5wcbzFj8S1UuOhU0lfpatX+wjmQzU6rxgmn91toOYiJ9deQ63DpVlul2cC
xFRwebTUBQVz+HNhX15E73rAwpO2aRxrQAlwlYFbXFqdrFbg6Tp7rhlv1Q6xBGcI
RH/9JkxqVFlnJWdlxTv+0ao/f1BJKPjtlBRju4lqjjQLpUNA2tV6AI1SFhUDD7Di
7VFeJ1JjVkWk7BrE5RrgdC/8uG81Kmy4z0w/UoNdVB/0QXLE4q0=
=r1I4
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

[Adam Williamson]

On Thu, 2017-08-24 at 09:12 +0200, Remi Collet wrote:
> Le 24/08/2017 à 08:58, Adam Williamson a écrit :
> > On Thu, 2017-08-24 at 06:44 +0200, Remi Collet wrote:
> > > Le 24/08/2017 à 02:32, Moez Roy a écrit :
> > > 
> > > > The soname bump requires packages that depend on it need to be rebuilt, 
> > > > so
> > > > I updated ImageMagick to 7.0.6-9.
> > > 
> > > 
> > > Such a version bump in stable branch is not acceptable.
> > > 
> > > ImageMagick 7 removed lot of functions (deprecated in v6)
> > > 
> > > Especially as ImageMagick 6 is still maintained.
> > > 
> > > BTW, latest version 6.9.9-9 also have some API changes
> > > 
> > > - 6.9.6-8 => bump to .3
> > > - 6.9.7-6 => bump to .4
> > > - 6.9.9-0 => bump to .5
> > > 
> > > Yes, this package is a nightmare.
> > 
> > Note the versioning is a bit subtle. What was released upstream was
> > 6.9.9-9 , which in our versioning would be 6.9.9.9 . Upstream *didn't*
> > go from 6.9.8 to 6.9.9, but from 6.9.9-8 to 6.9.9-9. The package in
> > Fedora before all this mess was versioned 6.9.9.3 , which I believe
> > would be upstream's 6.9.9-3 , and I *think* there is no ABI/API
> > incompatibility between 6.9.9-3 and 6.9.9-9. The soname in the 6.9.9.3
> > packages was already
> > "libMagickCore-6.Q16.so.5()(64bit)".
> 
> Yes in F27+ (6.9.9.3)
> 
> F25/F26 have 6.9.3.0 (upstream 6.9.3-0) with
> libMagickCore-6.Q16.so.2
> libMagickWand-6.Q16.so.2

Yep, I just looked back and saw that nirik built upstream 6.9.9-3 but
hadn't actually sent it as an update, since it was an soname bump and
all the necessary rebuilds weren't done yet :/
-- 
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

Re: Fedora's beaker instance

[Tim Flink]

On Thu, 17 Aug 2017 17:43:13 +1000
Dan Callaghan  wrote:

> Sorry for my very slow reply Petr...
> 
> Excerpts from pschindl's message of 2017-08-08 17:24 +02:00:
> > Hi Dan,
> > 
> > I have few questions regarding a beaker.qa.fp.org. What is the
> > state of the project right now? I now work with DesktopQA team on
> > upstreaming their tests. And because they run their tests on
> > internal beaker so I'd like to mimic their workflow. So I'd like to
> > try to run tests on our Fedora's beaker.
> > 
> > So my questions. Does the beaker.qa.fp.org works at all? Could you
> > give me access to at least one machine? Can I help you somehow with
> > make it work? What can I do to put F26 or Rawhide trees to Beaker?
> > 
> > Thank you for your answers. Have a nice day. With regards
> > Petr Schindler (Fedora QA)  
> 
> I've cc'ed the Fedora qa-devel list. Tim Flink did a lot of work
> getting the Fedora Beaker instance set up.
 
> If you wanted to get access to use it, I'm sure we could do that. We 
> would just need to add you to this group:
> 
> https://beaker.qa.fedoraproject.org/groups/qa-beaker-users#members
> 
> As far as I know, Beaker itself is fully up and running now (we had
> some issues with Fedora authentication but they were all sorted out a
> while back). However it looks like the Dell machines attached to
> Beaker are not successfully booting into the installer right now. Tim
> might know more about what is missing/broken with them. I'm not
> entirely sure what's wrong because I don't think I have access to
> their serial console.

The biggest problem I'm hitting right now is that I can't import repos.
There's something about the setup we have inside Fedora infra that
beaker's repo importing mechanism can't handle.

I keep meaning to get around to figuring out what's wrong and fix it
but as beaker is a pretty low priority right now, I never seem to get
around to it.

> That reminds me, one thing we never did set up properly is a
> Conserver instance so that Beaker can scrape the serial console logs.
> That would certainly make it easier to see why the Dell machines
> aren't netbooting successfully.

For now, you can find me and ask me to look at the machine itself. That
doesn't scale but for now, I'm not aware of other options.

> I should try and see about writing a playbook to deploy Conserver...

I'd love to see that happen :)

Tim


pgpUV439bfKjY.pgp
Description: OpenPGP digital signature
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

About "debugsource" package and repo layout

[Remi Collet]

Hi,

Since F27, for each package, we have a "debugsource" package.

Question is about the repository layout

For now these packages are available in the standard repository

Ex:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/y/

yajl-2.1.0-8.fc27.x86_64.rpm
yajl-debugsource-2.1.0-8.fc27.x86_64.rpm
yajl-devel-2.1.0-8.fc27.x86_64.rpm

Shouldn't these packages be in the "debug" repository

ie:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/debug/tree/Packages/y/

yajl-debuginfo-2.1.0-8.fc27.x86_64.rpm




Remi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Remi Collet]

Le 24/08/2017 à 16:47, Michael Cronenworth a écrit :
> On 08/24/2017 09:25 AM, Remi Collet wrote:
>> I really think we have to revert to 6 in stable branch
>> (and perhaps even in F27, which is very close to feature freeze)
>>
>> - soname bump
>> - lot of removed API
>> - HDRI enabled by default
> 
> The SONAME is changing in 6.9 as well so I'm not sure reverting is great
> either otherwise I would have done it.

Yes, but no removed API, and no hdri by default.

> 
> I'm prepared to perform rebuilds and push updates to get this resolved.
> Assuming no objections in the next day I'll get it rolling. Worst case
> if there's negative karma on the updates I'll push a revert to 6.9.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[nicolas . mailhot]

Hi,

I suspect the confusion between group and module names will lead to strange 
brittle special cases down the road and (worse) people being over-clever 
building solutions that rely on those special cases (exactly like the 
under-specified rpm update quirks which are being blamed nowadays).

Why not make the module shorthand specific?

package ⊂ @group ⊂ @@module

Or am I missing something?

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

On 08/24/2017 09:25 AM, Remi Collet wrote:

I really think we have to revert to 6 in stable branch
(and perhaps even in F27, which is very close to feature freeze)

- soname bump
- lot of removed API
- HDRI enabled by default


The SONAME is changing in 6.9 as well so I'm not sure reverting is great either 
otherwise I would have done it.


I'm prepared to perform rebuilds and push updates to get this resolved. Assuming no 
objections in the next day I'll get it rolling. Worst case if there's negative karma 
on the updates I'll push a revert to 6.9.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr) >= 4.16

[Dridi Boukelmoune]

Hello,

For some reason I fail to understand, a non-devel package is
conflicting with a devel package :-/

According to dnf it's the only explicit conflict for the package:

$ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64
pkgconfig(nspr) >= 4.16

Maybe someone confused Conflicts with BuildConflicts in the spec?

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[Miroslav Suchý]

Dne 24.8.2017 v 09:00 Marius Vollmer napsal(a):

My understanding from playing with Boltron is that "dnf install foo"
treats "foo" as a module name.  "dnf install" can not install packages


The final solution will be:
  dnf install foo - install rpm package
  dnf module install foo - install module
  dnf install @foo - install module (if comps of the same name exists it install comps, otherwise module, or vice 
versa, somebody from DNF team should clarify).



Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Miroslav Suchý]

Dne 24.8.2017 v 13:58 Cheng Ye napsal(a):

Hi,

Making the builddir accessible for failed build would be helpful. Some test 
suits will store log in a file in buildir without echoing anything else 
helpful. Without access to  builddir, it could be difficult to debug.  However, 
copying the builddir from mock directory to somewhere accessible could be a 
cumbersome task.



Mock actually support this.
https://github.com/rpm-software-management/mock/wiki/Plugin-ChrootScan

The question is how to define this in Copr per package? As every package will 
need different artifacts.

Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Remi Collet]

Le 24/08/2017 à 14:05, Dan Horák a écrit :

> so I've applied a workaround [1] to get ImageMagick built on all arches
> again until we have a proper fix, it's in Rawhide now, feel free to
> apply it to other branches as well

I really think we have to revert to 6 in stable branch
(and perhaps even in F27, which is very close to feature freeze)

- soname bump
- lot of removed API
- HDRI enabled by default



Remi.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-libintl-perl (master). "Upgrade to Fedora Rawhide"

[notifications]

From 0dcf3a1e5c0445401bc11cc1b911eee311a3e2fc Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 24 2017 14:22:27 +
Subject: Upgrade to Fedora Rawhide


---

diff --git a/perl-libintl-perl.yaml b/perl-libintl-perl.yaml
index dd94837..b21541e 100644
--- a/perl-libintl-perl.yaml
+++ b/perl-libintl-perl.yaml
@@ -10,28 +10,43 @@ data:
 module: [ MIT ]
 dependencies:
 buildrequires:
-base-runtime: master
 perl: master
+platform: master
+# Explicitly require transitive dependencies to work around
+# .
+host: master
 requires:
 perl: master
 references:
 community: https://docs.pagure.org/modularity/
 documentation: https://github.com/modularity-modules/perl-libintl-perl
 tracker: https://github.com/modularity-modules/perl-libintl-perl
+profiles:
+default:
+description: libintl-perl CPAN distribution.
+rpms:
+- perl-libintl-perl
+sharedir:
+description: >
+libintl-perl with support for searching locale data in 
File::ShareDir
+directories.
+rpms:
+- perl-File-ShareDir
+- perl-libintl-perl
 api:
 rpms:
 - perl-libintl-perl
 components:
 rpms:
 perl-Class-Inspector:
-rationale: Optional run-time and build-time dependency.
-ref: f26
+rationale: Optional run-time and build dependency.
+ref: master
 buildorder: 0
 perl-File-ShareDir:
-rationale: Optional run-time and build-time dependency.
-ref: f26
+rationale: Optional run-time and build dependency.
+ref: master
 buildorder: 1
 perl-libintl-perl:
-rationale: The API.
-ref: f26
+rationale: API.
+ref: master
 buildorder: 2



https://src.fedoraproject.org/modules/perl-libintl-perl/c/0dcf3a1e5c0445401bc11cc1b911eee311a3e2fc?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Unicode-EastAsianWidth (master). "Fix a typo in macros"

[notifications]

From 634b1a0a9cf31f0d483365bd5b7548c3727dcff3 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 24 2017 13:57:29 +
Subject: Fix a typo in macros


---

diff --git a/perl-Unicode-EastAsianWidth.yaml b/perl-Unicode-EastAsianWidth.yaml
index 9a89da7..108659f 100644
--- a/perl-Unicode-EastAsianWidth.yaml
+++ b/perl-Unicode-EastAsianWidth.yaml
@@ -54,7 +54,7 @@ data:
 rpms:
 macros: |
 %perl_bootstrap 1
-thout_perl_Module_Install_ReadmeFromPod_enables_pdf 1
+%_without_perl_Module_Install_ReadmeFromPod_enables_pdf 1
 components:
 rpms:
 perl-Capture-Tiny:



https://src.fedoraproject.org/modules/perl-Unicode-EastAsianWidth/c/634b1a0a9cf31f0d483365bd5b7548c3727dcff3?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Fedora Release Live Cycle

[Matthew Miller]

On Thu, Aug 24, 2017 at 01:52:16PM +0200, Jan Kurik wrote:
> In the group we had the discussion were no strong opinions whether
> these milestones need to be early in the release cycle or just before
> the "Beta Freeze". As such, I would like to open a discussion and
> collect some opinions on the timing of these key milestones. Any
> feedback or pros and cons are welcomed.

My proposed draft schedules move the branch later. My theory is that
this shorter branch time leads to less divergence and requires less
duplicated work during the run-up to the release (both for QA and
devel). But I'm definitely willing to try different things to see how
they work.
-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modularizing the world fast and iteratively

[Matthew Miller]

On Thu, Aug 24, 2017 at 03:20:12AM +0200, Kevin Kofler wrote:
> This is exactly why the separate Core and Extras were such a PITA and why 
> the Core-Extras Merge was done. Doing the opposite now is a BAD idea.

Core-Extras was a bad ideas because Core was developed inside Red Hat
in a non-open way and did not allow community involvement beyond that
of beta testing. Merging it all together was probably the only
realistic way to fix that (and fixing that was absolutely the best
thing to do), but if we'd kept separate repos, we'd have addressed the
technical problems sooner and had a lot more of the flexibility that we
_really_ need to keep growing.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is a package providing and requiring the same library in the package normal?

[Cheng Ye]

Thanks. It could be better if it can be documented somewhere in wiki.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Unicode-EastAsianWidth (master). "Upgrade to Fedora Rawhide"

[notifications]

From d1bb1b80fade6b0c62e9a378cd860c9ef87af189 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 24 2017 13:30:49 +
Subject: Upgrade to Fedora Rawhide


---

diff --git a/perl-Unicode-EastAsianWidth.yaml b/perl-Unicode-EastAsianWidth.yaml
index 4b2741e..bc091d3 100644
--- a/perl-Unicode-EastAsianWidth.yaml
+++ b/perl-Unicode-EastAsianWidth.yaml
@@ -10,19 +10,26 @@ data:
 module: [ MIT ]
 dependencies:
 buildrequires:
-base-runtime: f26
-perl: f26
-perl-Module-Install: f26
-perl-Module-Package: f26
-# Explicitely require perl-Moo to work around
+perl: master
+perl-Module-Install: master
+perl-Module-Package: master
+platform: master
+# Explicitly require transitive dependencies to work around
 # .
-perl-Moo: f26
+host: master
+perl-Moo: master
 requires:
-perl: f26
+perl: master
 references:
 community: https://docs.pagure.org/modularity/
 documentation: 
https://github.com/modularity-modules/perl-Unicode-EastAsianWidth
 tracker: 
https://github.com/modularity-modules/perl-Unicode-EastAsianWidth
+profiles:
+rpms:
+default:
+description: Unicode::EastAsianWidth Perl module
+rpms:
+- perl-Unicode-EastAsianWidth
 api:
 rpms:
 - perl-Unicode-EastAsianWidth
@@ -30,7 +37,6 @@ data:
 rpms:
 - perl-Capture-Tiny
 - perl-Devel-Symdump
-- perl-Module-Install-AuthorRequires
 - perl-Module-Install-AutoLicense
 - perl-Module-Install-GithubMeta
 - perl-Module-Install-ReadmeFromPod
@@ -40,82 +46,73 @@ data:
 - perl-Path-Class
 - perl-Pod-Coverage
 - perl-Pod-Markdown
-- perl-srpm-macros
 - perl-Test-Differences
 - perl-Test-InDistDir
 - perl-Test-Pod
 - perl-Test-Pod-Coverage
 components:
 rpms:
-perl-srpm-macros:
-rationale: Build-time dependency.
-ref: private-f27-modules-perl-Unicode-EastAsianWidth
-buildorder: 0
 perl-Capture-Tiny:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-Devel-Symdump:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
-perl-Module-Install-AuthorRequires:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
+perl-Module-Install-ReadmeMarkdownFromPod:
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-Path-Class:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-Test-InDistDir:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-Test-Pod:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-Module-Install-GithubMeta:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 2
+rationale: Build dependency.
+ref: master
+buildorder: 1
 perl-Module-Install-Repository:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 2
+rationale: Build dependency.
+ref: master
+buildorder: 1
 perl-Pod-Coverage:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 2
+rationale: Build dependency.
+ref: master
+buildorder: 1
 perl-Test-Pod-Coverage:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 3
+rationale: Build dependency.
+ref: master
+buildorder: 2
 

Re: Is a package providing and requiring the same library in the package normal?

[Rex Dieter]

Cheng Ye wrote:

> Hi,
> This is probably a simple packaging question.

Yes, per SUBJECT, this is normal and not out of the ordinary.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Is a package providing and requiring the same library in the package normal?

[Cheng Ye]

Hi,
This is probably a simple packaging question. Sorry for the noise if the answer 
already exists somewhere on the internet.

I am trying to package the IPC library. The built package installs (using dnf) 
and functions correctly, but the java-cmu-ipc package's automatic requires and 
provides include libjavaipc.so at the same time. 
Python sub packages which also contains a shared library (_IPC.so) doesn't have 
similar issue.
Do I need to filter this pair of require and provide? 
Does this indicate something went wrong during the build?

Build log: 
https://copr-be.cloud.fedoraproject.org/results/yecheng/cmu-ipc/fedora-rawhide-x86_64/00593636-cmu-ipc/build.log.gz

"Processing files: java-cmu-ipc-3.9.1a-1.fc28.x86_64
 Provides: java-cmu-ipc = 3.9.1a-1.fc28 java-cmu-ipc(x86-64) = 3.9.1a-1.fc28 
libipcjava.so.3.9()(64bit) "
"Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) 
libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) 
libipc.so.3.9()(64bit) libipcjava.so.3.9()(64bit) rtld(GNU_HASH) "

Review Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1481237

Thanks,
Ye Cheng.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[James Hogarth]

On 24 August 2017 at 10:33, Peter Robinson  wrote:

> > On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> >> Hello Fedora devels and users,
> >>
> >> more than three years ago, the same topic started discussion if we
> >> want
> >> this package in Fedora or not and how [1]. The discussion resulted
> >> mostly in flames and in the removal of the dependency on tcp_wrappers
> >> from systemd. But it was quite agreed that it is considered as a
> >> security layer for some users, if they use it correctly, or something
> >> that is or should be replaced by firewalls.
> >>
> >> So can we discuss it now once more without the affiliation to
> >> systemd?
> >> The fact is that we still do not have any other replacement except
> >> firewalls. But do we need one?
> >>
> >> The complete removal of the package is probably not a wise step, even
> >> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
> >> still available in Arch [3] without other tools depending on it. To
> >> be
> >> fair, Debian [4] is still building tools (for example openssh) with a
> >> build-time support for it.
> >>
> >> My primary concern is OpenSSH, which upstream dropped support for
> >> tcp_wrappers three years ago (late 2014) [5] and since then we are
> >> maintaining one more downstream patch. But this effort should be
> >> coordinated among other components to simplify the transition for
> >> users
> >> who insist on using it (using tcpd).
> >>
> >> Removing the dependency will also allow us to trim the default
> >> install for few more Kb.
> >>
> >> If there will be no significant drawbacks, I will progress with
> >> filling
> >> a system wide change for Fedora 28 and I will pull the maintainers of
> >> other tolls using libwrap into the round and discussion.
> >
> > Hello,
> > In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
> > time dependency:
> >
> >
> > Since I'm listed twice in there...
> >
> > With my packages and the situation with build time options I take the
> > position of enable as much as possible since our users don't get to pick
> > their compilation options.
> >
> > However tcp_wrappers is a legacy thing that no longer belongs in today's
> > world.
> >
> > I have no objection to a flag day in F28 development and dropping the
> build
> > option at some point, preferably before the thing that is no longer an
> alpha
> > ;) ... ie way before beta.
>
> With F-27 now branched off this can happen in F-28/rawhide now
> ___
>
>
Indeed ... it's a great time to do so ... but let's carry it out under the
auspices of a System Wide Change for F28 :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Jan Kratochvil]

On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote:
> On 24.08.2017 14:18, Jan Kratochvil wrote:
> > On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:
> > > I'm investigating why gdb returns so unreliable backtraces for mingw
> > > binaries without debuginfos,
> > They are perfectly reliable.  They just do not show the function names.
> > But those can be looked up later from *-debuginfo.rpm.
> I regularly have the issue that with larger programs, gdb aborts with
> "Backtrace stopped: previous frame inner to this frame (corrupt stack?) " if
> the crash happens somewhere deep down, say in some Qt library, and never
> gets to printing the frames of the caller of the application code I'm
> interested in. If debugsymbols are available, it prints the all the frames.
> Hence "unreliable". I supose this might be a bug, but I have no idea how to
> investigate.

In your OP example:

: #0  0x0040157d in ?? ()
: #1  0x004015b5 in ?? ()
: #2  0x004013f7 in ?? ()
: #3  0x0040152b in ?? ()
: #4  0x76af652d in KERNEL32!BaseThreadInitThunk ()
:from C:\Windows\system32\kernel32.dll
: #5  0x76d2c521 in ntdll!RtlUserThreadStart ()
:from C:\Windows\SYSTEM32\ntdll.dll
: #6  0x in ?? ()
: Backtrace stopped: previous frame inner to this frame (corrupt stack?)
: 
: With strip-debug, gdb reports:
: 
: #0  0x0040157d in foo() ()
: #1  0x004015b5 in main ()

You can see the backtrace is the same. I guess you will see that
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

even with installed *-debuginfo.rpm after you enter:
(gdb) set backtrace past-main on
(gdb) set backtrace past-entry on

The symbols (particularly the "main" symbol) just tell GDB to stop backtracing
earlier.  But the part that it already backtraced is the same.

In some cases *-debuginfo.rpm can really improve the backtrace (even the
numerical-only one, ignoring the address->functionname decoration).
This is due to .debug_frame sections there when the main binary is missing
corresponding .eh_frame.  But I have no idea how this works in PE32 and then
it is a packaging bug (missing -fasynchronous-unwind-tables) as the
numerical-only backtraces should be the same with and without debuginfo.

Last difference can be due to inlined functions being shown just with
*-debuginfo.rpm but that is not much important (and reconstructable from the
numerical-only backtrace).

But these *-debuginfo.rpm differences will not happen with your planned bare
functionname symbols (called ELF symbols or PE32 symbols in your case).


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Sandro Mani]

Hi Jan


On 24.08.2017 14:18, Jan Kratochvil wrote:

On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:

I'm investigating why gdb returns so unreliable backtraces for mingw
binaries without debuginfos,

They are perfectly reliable.  They just do not show the function names.
But those can be looked up later from *-debuginfo.rpm.
I regularly have the issue that with larger programs, gdb aborts with 
"Backtrace stopped: previous frame inner to this frame (corrupt stack?) 
" if the crash happens somewhere deep down, say in some Qt library, and 
never gets to printing the frames of the caller of the application code 
I'm interested in. If debugsymbols are available, it prints the all the 
frames. Hence "unreliable". I supose this might be a bug, but I have no 
idea how to investigate.


This has been implemented for Linux ELF binaries:
https://fedoraproject.org/wiki/Features/MiniDebugInfo
Yep, that was my inspiration for attempting to get something similar to 
work for PE binaries.


But the symbols take less space there as they are compressed.  You can check
how it looks like for Linux ELF binaries by:
rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section 
.gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz -dv 
/tmp/bash-debugdata.xz;readelf -Wa /tmp/bash-debugdata|less

GDB should be able to extract .gnu_debugdata even from PE32 binaries but
I guess nobody has ever tested that.
I tired injecting the xz compressed symbols into the PE binary 
analogously to how find-debuginfo.sh does it, but then windows told me 
that the binary was invalid.


You are right that after the MiniDebugInfo feature has been approved for
Fedora (*) it should be ported from find-debuginfo.sh even into
mingw-find-debuginfo.sh.  Therefore also in the compressed way, not just as
plain symbols you suggest.
If anyone with some knowledge in the area could help with that, I'd be 
greatful!


Thanks
Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1484858] New: perl-Net-IPv6Addr-0.5 is available

[bugzilla]

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

Bug ID: 1484858
   Summary: perl-Net-IPv6Addr-0.5 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-IPv6Addr
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.5
Current version/release in rawhide: 0.2-23.fc27
URL: http://search.cpan.org/dist/Net-IPv6Addr/

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

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

[Bug 1484857] New: perl-Net-GitHub-0.90 is available

[bugzilla]

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

Bug ID: 1484857
   Summary: perl-Net-GitHub-0.90 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-GitHub
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jpazdzi...@redhat.com, jples...@redhat.com,
lkund...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com



Latest upstream release: 0.90
Current version/release in rawhide: 0.89-2.fc27
URL: http://search.cpan.org/dist/Net-GitHub/

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

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

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Jan Kratochvil]

On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote:
> I'm investigating why gdb returns so unreliable backtraces for mingw
> binaries without debuginfos,

They are perfectly reliable.  They just do not show the function names.
But those can be looked up later from *-debuginfo.rpm.

...
> strip-debug: 46k
> strip-unneeded: 21k
...
> and it seems to work great, the binary size is 24k, and the stack trace

This has been implemented for Linux ELF binaries:
https://fedoraproject.org/wiki/Features/MiniDebugInfo

But the symbols take less space there as they are compressed.  You can check
how it looks like for Linux ELF binaries by:
rm -f /tmp/bash-debugdata{,.xz};objcopy --dump-section 
.gnu_debugdata=/tmp/bash-debugdata.xz /bin/bash /dev/null;xz -dv 
/tmp/bash-debugdata.xz;readelf -Wa /tmp/bash-debugdata|less

GDB should be able to extract .gnu_debugdata even from PE32 binaries but
I guess nobody has ever tested that.

You are right that after the MiniDebugInfo feature has been approved for
Fedora (*) it should be ported from find-debuginfo.sh even into
mingw-find-debuginfo.sh.  Therefore also in the compressed way, not just as
plain symbols you suggest.


Jan

(*) Personally I do not agree with that but that does not matter here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Dan Horák]

On Thu, 24 Aug 2017 09:04:51 +0200
Dan Horák  wrote:

> On Wed, 23 Aug 2017 22:16:40 -0500
> Michael Cronenworth  wrote:
> 
> > Hi all,
> > 
> > An ImageMagick update (6.9 => 7.0) with an SONAME bump and other
> > breakage has been pushed to F25 and higher.
> > 
> > First, the update introduces regressions on s390x and ppc64 arches.
> > - https://bugzilla.redhat.com/show_bug.cgi?id=1484578
> > - https://bugzilla.redhat.com/show_bug.cgi?id=1484579
> 
> these issues shouldn't have been solved with an ExcludeArch
> immediately as there is a risk of breaking buildroots for other
> packages and for other teams like modularity. If such problem
> happens, please contact us (the alternative-arches team) first, so we
> can plan the best action.

so I've applied a workaround [1] to get ImageMagick built on all arches
again until we have a proper fix, it's in Rawhide now, feel free to
apply it to other branches as well

It adds one more reason to run a CI on the upstream level that would
cover alternative arches, we have already something in progress.

[1]
http://pkgs.fedoraproject.org/rpms/ImageMagick/c/9d8a0e0d350a8d02ae40b76ea03f70d118798f23?branch=master


Dan

> 
> 
>   Thanks
> 
>   Dan
> 
> > Secondly, rebuilds are required for:
> > 
> >autotrace-0.31.1-44.fc26.src.rpm
> >converseen-0.9.6.2-1.fc27.src.rpm
> >dmtx-utils-0.7.4-2.fc27.src.rpm
> >drawtiming-0.7.1-20.fc26.src.rpm
> > F gtatool-2.2.0-4.fc27.src.rpm
> >imageinfo-0.05-25.fc26.src.rpm
> >inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm
> >kxstitch-1.2.0-7.fc26.src.rpm
> >perl-Image-SubImageFind-0.03-11.fc27.src.rpm
> >pfstools-2.0.6-1.fc27.src.rpm
> > F php-magickwand-1.0.9.2-9.fc24.src.rpm
> > F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm
> >psiconv-0.9.8-20.fc26.src.rpm
> >q-7.11-27.fc27.src.rpm
> >ripright-0.11-3.fc26.src.rpm
> >rss-glx-0.9.1.p-29.fc26.src.rpm
> > F rubygem-rmagick-2.16.0-3.fc26.src.rpm
> > F synfig-1.2.0-5.fc27.src.rpm
> >(boost issues)
> > F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm
> >(needs synfig)
> >vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm
> >vips-8.5.6-1.fc27.src.rpm
> >WindowMaker-0.95.8-1.fc27.src.rpm
> > F cuneiform
> >(some c++ blowup)
> >k3d
> > 
> > The ones with F have possible compile issues.
> > 
> > Thirdly, two updates have been created. I've disabled autopush on
> > them.
> > - https://bodhi.fedoraproject.org/updates/FEDORA-2017-0a1f3de4eb
> > - https://bodhi.fedoraproject.org/updates/FEDORA-2017-c276ee400a
> > 
> > It is really late here and I don't have the time to investigate the
> > arch issues right now. I'll investigate when I can.
> > ___ devel mailing list
> > -- devel@lists.fedoraproject.org To unsubscribe send an email to
> > devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Richard Kellner

[Máirín Duffy]

Hi Richard,

On 08/23/2017 05:53 PM, Richard Kellner wrote:

my name is Richard Kellner and I am a Python developer. In my free time,
I am also a PyCon SK volunteer. Recently I have got this crazy idea to
submit some of my packages to Fedora, so here I am. I have just
submitted my first package for review:
https://bugzilla.redhat.com/show_bug.cgi?id=1484561 hopefully several
more will come soon.

Looking forward to becoming part of the Fedora community.


You're most welcome! You are in good company with many Pythonistas in 
the project. See you around!


Cheers,
~m
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Cheng Ye]

Hi,

Making the builddir accessible for failed build would be helpful. Some test 
suits will store log in a file in buildir without echoing anything else 
helpful. Without access to  builddir, it could be difficult to debug.  However, 
copying the builddir from mock directory to somewhere accessible could be a 
cumbersome task. 

Thanks,
Ye Cheng
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Release Live Cycle

[Jan Kurik]

Hi everyone,

as you probably noted, one of the significant changes in F27 release
is the missing Alpha release. This is based on the "No More alphas"
[1] Change. The schedule for F27 release [2] has been put together
with the aim not to break any flow during the cycle and with intention
to make observations what issues and changes in the flow this Change
brings. There are also some minor changes in the schedule caused by
sliding milestones for Beta GA and Final GA dates (Target & Rain
dates).

There were several discussions on mailing lists as well as on private
level pointing to some issues related to these changes in scheduling
of key milestones. Finally we have two proposals. One put together by
my self [3] and the second one prepared by Adam [4]. These proposals
are the same starting from "Beta Freeze" milestone but different for
milestones preceding the "Beta Freeze". Basically the two proposals
differ for these milestones:

* Mass rebuild
* Branching
* Bodhi activation point

In the group we had the discussion were no strong opinions whether
these milestones need to be early in the release cycle or just before
the "Beta Freeze". As such, I would like to open a discussion and
collect some opinions on the timing of these key milestones. Any
feedback or pros and cons are welcomed.


[1] https://fedoraproject.org/wiki/Changes/NoMoreAlpha
[2] https://fedoraproject.org/wiki/Releases/27/Schedule
[3] https://pagure.io/fesco/issue/1761
[4] 
https://fedoraproject.org/wiki/User:Adamwill/NoMoreAlpha/Fedora_Release_Life_Cycle

Thanks & Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[Stephen Gallagher]

On Thu, Aug 24, 2017 at 3:02 AM Marius Vollmer 
wrote:

> My understanding from playing with Boltron is that "dnf install foo"
> treats "foo" as a module name.  "dnf install" can not install packages
> anymore.  So naively I assume that PackageKit will transparently start
> installing modules.  (I think PK uses libdnf, and I think I read
> somewhere that libdnf doesn't do anything with modules yet, so...)
>

This is not true. The modularity-aware DNF will first check to see if a
module matching the requested name exists and will install that. If it
doesn't, it will fall back to packages.

That being said, the implementation is still under debate. I'm personally
of the opinion that this is the correct behavior (since it requires no
adaptation for users), but there are some people who believe that it should
be explicit with `dnf module install` instead of `dnf install`.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

[Sandro Mani]

Hi

I'm investigating why gdb returns so unreliable backtraces for mingw 
binaries without debuginfos, and noticed a big improvement if I change 
strip-unneeded to strip-debug in mingw-find-debuginfo.sh. Currently, 
mingw-find-debuginfo.sh does the following:


mingw-objcopy --only-keep-debug "$binary" "$binary.debug"
mingw-objcopy --add-gnu-debuglink=$(basename "$binary.debug") 
--strip-unneeded "$binary"


For a trivial test application (see bottom of email), with 
strip-unneeded and no debug symbols, gdb reports:


#0  0x0040157d in ?? ()
#1  0x004015b5 in ?? ()
#2  0x004013f7 in ?? ()
#3  0x0040152b in ?? ()
#4  0x76af652d in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\system32\kernel32.dll
#5  0x76d2c521 in ntdll!RtlUserThreadStart ()
   from C:\Windows\SYSTEM32\ntdll.dll
#6  0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

With strip-debug, gdb reports:

#0  0x0040157d in foo() ()
#1  0x004015b5 in main ()

which is what I'd expect. Downside is the binary size:

strip-debug: 46k
strip-unneeded: 21k

Looking at the native find-debuginfo.sh, I see that some symbols are kept:

nm "$debuginfo" --format=sysv --defined-only | awk -F \| '{ if ($4 ~ 
"FUNC") print $1 }' | sort > "$funcsyms"


I tried replicating something similar for mingw, using strip-unneeded 
but keeping these FUNC symbols:


mingw-objcopy --only-keep-debug "$binary" "$binary.debug"
x86_64-w64-mingw32-nm "$binary.debug" --format=sysv --defined-only | awk 
-F \| '{ if ($4 ~ "Function") print $1 }' | sort > "$keep_symbols"
mingw-objcopy --add-gnu-debuglink=$(basename "$binary.debug") 
--strip-unneeded "$binary" --keep-symbols="$keep_symbols"


and it seems to work great, the binary size is 24k, and the stack trace

#0  0x0040157d in foo() ()
#1  0x004015b5 in main ()

is also good.

The thing is however that I'm not really too sure of what I'm doing. 
Does this make any sense? Should/could mingw-find-debuginfo.sh be 
enhanced this way?


Thanks
Sandro



#include 

void foo() {
  std::cout << (*((int*)0)) << std::endl;
}

int main() {
  foo();
  return 0;
}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[Marius Vollmer]

Richard Hughes  writes:

> On 24 August 2017 at 08:45, Marius Vollmer  wrote:
>
>> One approach is just to put them all into the collection data:
>
> You can't have two components with the same ID inside a 
> group with the same origin.

Okay, that was my understanding of the spec as well.

>> My proposed approach was to encode the exact same data via a spec
>> extension:
>>   
>> 
>>Recommended
>> 
>> 
>>Nightly builds
>>foo-nightly
>> 
>
> I'm sorry, but that makes almost no sense.  What is the software
> center supposed to do with variantsummary? Is the application name the
> same between the two variants?

The variantsummary is meant to be used in the UI element for selecting a
variant.

> Should reviews for the different variants be treated as the same thing
> or as different things?

I would say reviews for all variants should be associated with the
single component id.  I guess reviews carry information about the
version of the component that they were made for already, and the same
mechanism could be used to say which variant they apply to.

> I don't think it makes any sense at all making projects like GNOME
> Software, Apper, Discover, Muon and Cockpit (and others) understand
> much about the Fedora modularity stuff when everything seems to have
> standardized on AppStream -- including next-generation distributions
> methods like Flatpak.

This is all optional.  I am exploring what happens if a package with
AppStream metainfo data appears in a module, and I think I have sketched
out a path where we can do something correct/sensible with it that
doesn't require any changes to existing AppStream consumers.

A better path IMO is to decide that Software Centers don't want to see
naked modules when dealing with Applications, just flatpaks or other
containers.  I wasn't sure that this is an acceptable option, but it
looks like it is.

>> If a client understands "variants", it can trivially expand them back
>> into multiple entries for the same id.  Clients that don't understand
>> this will continue to just see one.
>
> They're two different things. Would gnome-software and cockpit show
> two search entries for the two variants or one?

One.

> Would you be able to switch between the variants?

Yes.

> Can both be installed at the same time, by two different users on the
> same system?

No.

>> Maybe I should emphasize that I am only trying to figure out what
>> happens if we subject a modularized repository to the usual AppStream
>> treatment.
>
> Can you provide some specifications on what a modularized repository
> should actually look like please? Is a repo going to contain .rpm
> packages like firefox-1.23.rpm and also firefox-2.34.rpm or something
> completely different?

This is a modularized repo, I think:


https://kojipkgs.fedoraproject.org/compose/26/Fedora-Modular-26-20170720.0/compose/Server/x86_64/os/

It does contain both

nodejs-6.10.3-2.module_9c237b2a.x86_64.rpm and
nodejs-8.0.0-1.module_42d8f2a0.x86_64.rpm

for example.

I hope the modularity people on this list can provide more details.

> Has anyone talked to the Fedora or GNOME designers about this?

I will talk to our Cockpit designers, of course, once everyone is back
from vacation.

> I'm trying hard not to get frustrated about questions about XML schema
> when I don't think anybody has considered the user experience of
> modularity.

Well, I have learned a lot already from this discussion, so thanks for
that!

> From a desktop point of view I'm currently of the opinion that it only
> makes sense to show modules that are flatpaks, and continue to use the
> appstream branch of the flatpak repository to get information about
> the modules.

This makes a lot of sense to me.

>> I am happy to just say that modularized repositories don't have
>> AppStream data, period.
>
> Why are you happy they don't have AppStream? I'm not sure trying to
> antagonize the people involved is a very good idea at all.

Sorry, again I should have been clearer: Instead of figuring out how to
make AppStream work with modularized repositories, we can also say that
we wont be installing applications as RPMs from modularized repositories
(only as flatpaks etc), and thus a modularized repository doesn't need
any AppStream data (period) and we don't need to figure out how the make
that work.


However, the general concept of variants of a single applications and
letting the user choose between them is a good one, no?  Firefox
Regular, Firefox Nightly, and Firefox Fatfree _are_ related to each
other and we can do better than just showing them next to each other in
a list, no?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Petr Stodulka]

On 24.8.2017 08:04, Pavel Raiskup wrote:
> On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote:
>> Do you use Copr for building packages for nightlies? For building packages
>> before pull request is merged?
> 
> Yes, not particulary me -- but I helped to guys in pgjdbc project to setup CI:
> 
> https://copr.fedorainfracloud.org/coprs/g/pgjdbc/pgjdbc-travis/
> https://github.com/pgjdbc/pgjdbc/blob/master/packaging/rpm/fedora-image/copr-ci-git
> 
>> Do you have your set up described somewhere?
> 
> No, since it is too complicated.  Tito is a burden for distro-agnostic 
> upstream.
> 
> Since upstream had travis-ci already enabled, my plan was to generate src.rpm 
> in
> travis-ci and submit build into copr (together with other CI tasks).
> 
> Two major problems:
> 1. Travis is (or was that time) debian/ubuntu only, so it is actually not very
>convenient to install all the necessary tooling there;  so the work-around
>was to use Fedora docker-image and that image is pulled in for each CI run.
> 
> 2. You need to store your copr credentials into git.  You can cipher that, but
>at least it is not convenient to store *your own* copr authentication token
>into git repo, because always at least other git committers can decipher 
> it.
>You also need to re-generate your API token twice a year (it means you need
>to bother the upstream with "useless" commits, but the worst thing is that
>you need to regularly go back and pay attention to fixing the CI).
> 
> Being able to specify (a) scm repo, (b) build deps and (c) any (turing 
> complete)
> script within the git repo (to generate the sources) would make setting up the
> CI a trivial task.

+1

That is something that could help us definitely too. Nowadays we have scripts 
for
packaging in Jenkins, that run tests and prepare SRPM for the COPR, that 
requires
in addition changes in upstream repository itself (e.g. public spec file as part
of the repository). More convenient would be (not only for our team, but for me 
too
as packager)

a) option to provide script in COPR, that will prepare sources, patches,
modified SPEC file, ... on the COPR side. The script would be processed for 
example
when I sent request to COPR for specific repository, with whatever data that 
will
be processed by the script (e.g. commit hash, branch, PR number).

b) store the specfile into the COPR repository, so it could be used by the 
script
   and it will not be required to be part of the upstream repository (usually 
the
   SPEC is not part of the upstream repo or we want different spec than upstream
   provides)

I found now that in COPR is something that b) describes, but I am not sure that
it is same. Still, own script that would prepare sources for COPR builds is the
most missing feature for me.


> 
> Pavel
> 
>> What is the name of your 
>> project?
>>
>> Please let me know. Either here or via private reply.
>> It will help me to understand your use of Copr and to make Copr better.
>>
>> Thanks in advance.
>>
>> Miroslav Suchy
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
Petr Stodulka
Core Services (In-place upgrades and migrations)
IRC nicks: pstodulk, skytak
Red Hat



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

[Petr Viktorin]

On 08/24/2017 12:22 PM, Nick Coghlan wrote:

On 24 August 2017 at 19:02, Petr Viktorin  wrote:

On 08/24/2017 10:13 AM, Nick Coghlan wrote:

My current thinking based on that discussion is that we're actually
going to need a module set that looks like this for F28+:

* Platform Python (already planned for F27)
- part of the Platform module
- stream names match Fedora releases (f26, f27, etc)


Stream names match the Platform module. We follow its policy here, even when
it changes.


Oh, interesting, I had that backwards (I thought the planned F27
Python modules were the ones named after upstream Python releases).

That means the current module definitions would be closer to what I'm
calling the "Integrated Python Modules".


My comment was for Platform Python :)


* Python Application Runtime Modules (already planned for F27)
- one module for Python 2 and one for Python 3
- stream names match upstream Python releases (2.7, 3.6, etc)
- Application Runtime Modules conflict with the corresponding >
Integrated Python Module
- provide "/usr/bin/python2" and "/usr/bin/python3" respectively
- also satisfy "python2-*" and "python3-*" RPM dependencies
- only the Python 2 module satisfies "python-*" RPM dependencies (for
now) > * Integrated Python Modules
- one module for Python 2 and one for Python 3


These need to be parallel installable, to support tox. So we need separate
modules for each Python release.


Aye, I agree that will be a good way to tackle the parallel
installable versions that *don't* define "/usr/bin/python3". However,
for containers designed to run Python applications (web or otherwise),
we *will* want mutually conflicting streams that define their symlinks
and RPM provides based only on the Python major version.

So lets make those extra modules their own distinct category:

* Python Interoperability Testing Modules
   - one module per Python X.Y release
   - only one stream per module
   - conflict with the corresponding Application Runtime stream
   - provide "/usr/bin/pythonXY" and "/usr/bin/pythonX.Y"
   - do NOT satisfy "python2-*" and "python3-*" RPM dependencies

And looking at their current implementation in Fedora, one notable
difference between them and the Application Runtime streams is that
these would just use their bundled pip and setuptools, rather than
splitting those out the way the regular packages do.


No, I don't want to support *full* parallel-installable stacks. Let's 
stick to what we currently support in Fedora, not more.


"Python Interoperability Testing Modules" get "x.y" streams and provide 
"x.y" binaries; "Python Application Runtime Modules" get one stream for 
python3 and one python2, and provide the python2/python3 binaries.


I don't think "Integrated Python Modules" are necessary in Fedora.

Also, the names are a mouthful; let's revise naming after we get the 
semantics down :)




- stream names match Fedora releases (f26, f27, etc)
- each depends on an *exact* version of the corresponding Python
  Application Runtime module



Huh? You just said Python Application Runtime Modules would conflict with
this.


Sorry about that - when I started writing the email, my plan was to
have them conflict with each other, but as I wrote that initial
version up I went "Hang on, couldn't I use a stream dependency here
and rely on *that* to trigger a conflict if you had an Integrated
Python module installed and then tried to switch to an unsupported
runtime stream, or vice-versa?"


* Default Python Module
- provides /usr/bin/python (and nothing else)
- stream names: no-default, python3-default, python2-default


+1
I guess this would contain a "python" RPM, containing just a /usr/bin/python
symlink, which would added to non-modular Fedora as well.


Pretty much, yeah. The "no-default" stream would be a bit different,
as in that case it would install a shell script that printed out a
custom error message.


A shell script that would satisfy file dependencies on "/usr/bin/python" 
might not be the best idea.



--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Module-Package (master). "Upgrade to Fedora Rawhide"

[notifications]

From 445832a57a1aaabe87cebef7f5cebeb7dcf78174 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 24 2017 11:26:02 +
Subject: Upgrade to Fedora Rawhide


---

diff --git a/perl-Module-Package.yaml b/perl-Module-Package.yaml
index 88bc369..481ac0b 100644
--- a/perl-Module-Package.yaml
+++ b/perl-Module-Package.yaml
@@ -9,10 +9,13 @@ data:
 module: [ MIT ]
 dependencies:
 buildrequires:
-base-runtime: master
 perl: master
 perl-Module-Install: master
 perl-Moo: master
+platform: master
+# Explicitly require transitive dependencies to work around
+# .
+host: master
 requires:
 perl: master
 perl-Module-Install: master
@@ -20,6 +23,11 @@ data:
 references:
 community: https://fedoraproject.org/wiki/Modularity
 documentation: 
https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
+profiles:
+default:
+description: Module::Package Perl module.
+rpms:
+- perl-Module-Package
 api:
 rpms:
 - perl-Module-Package
@@ -28,72 +36,73 @@ data:
 - perl-File-ShareDir-Install
 - perl-FreezeThaw
 - perl-MLDBM
-- perl-Module-Install-AuthorRequires
-- perl-srpm-macros
 - perl-Test-Pod
+buildopts:
+rpms:
+macros: |
+%_without_perl_File_BaseDir_enables_xdg_user_dirs 1
+%_without_perl_File_DesktopEntry_enables_optional_test 1
+%_without_perl_File_MimeInfo_enables_optional_test 1
+%_without_perl_File_MimeInfo_enables_shared_mime_info 1
 components:
 rpms:
-perl-srpm-macros:
-rationale: Build-time dependency.
-ref: private-f27-modules-perl-Module-Package
-buildorder: 0
 perl-Class-Inspector:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-File-BaseDir:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-File-ReadBackwards:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-File-ShareDir-Install:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-FreezeThaw:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-Module-Install-AuthorRequires:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Run-time dependency.
+ref: master
+buildorder: 0
 perl-Module-Install-ManifestSkip:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Run-time dependency.
+ref: master
+buildorder: 0
 perl-Test-Pod:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 1
+rationale: Build dependency.
+ref: master
+buildorder: 0
 perl-File-DesktopEntry:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 2
+ref: master
+buildorder: 1
 perl-File-ShareDir:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 2
+ref: master
+buildorder: 1
 perl-MLDBM:
-rationale: Build-time dependency.
-ref: f26
-buildorder: 2
+rationale: Build dependency.
+ref: master
+buildorder: 1
 perl-File-MimeInfo:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 3
+ref: master
+buildorder: 2
 perl-Module-Manifest-Skip:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 3
+ref: master
+buildorder: 2
 perl-IO-All:
 

Re: [modularity] Modularizing the world fast and iteratively

[Kevin Kofler]

Pavel Raiskup wrote:
> Ok, I agree that Fedora needs modules for life-cycle separation.

I don't. I consider what you call "life-cycle separation" (I'd rather call 
it "inconsistent EOLs") a bug rather than a feature.

This is yet another of those "features" that sound great on paper, but lead 
to a horrible user experience in practice. Right now, it is easy to know 
when you have to upgrade, as there is one EOL for the entire distro. With 
inconsistent per-module EOLs, as soon as you have a non-trivial amount of 
modules installed, it is impossible to track down when you need to upgrade 
what. So either you end up with an unsupported version of the module without 
even noticing, or you get forcefully upgraded at what will often be the 
worst possible time.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modularizing the world fast and iteratively

[Pavel Raiskup]

On Thursday, August 24, 2017 3:20:12 AM CEST Kevin Kofler wrote:
> Adam Samalik wrote:
> > all their dependencies, we need to build them. But, for example, a pretty
> > commonly needed thing like autotools [3] has pretty crazy build
> > dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2,
> > python3, etc.
> 
> This is exactly why the separate Core and Extras were such a PITA and why 
> the Core-Extras Merge was done. Doing the opposite now is a BAD idea.

I have similar feelings, unfortunately.

Dependencies go here and there, new software version means different dependancy
set; that's never-ending iteration in the distro ecosystem.  Trying to draw a
thick border line (called "circle") in Fedora Everything to separate the working
ecosystem into smaller ecosystem (where packages in one set don't see the other
sets) is IMO impossible without loosing some part of Fedora functionality (which
is not acceptable as we spent too much power on it so far).

Why I'm writing is the mentioned "autotools" keyword (for some reason it is
privileged soon-to-be module, dunno why).  We should first define "what belongs
to autotools".  But anyways...  Making it a self-standing module is not easily
possible.  All the (build)deps are there for reason.  We really don't want to
have "language foo" support in Automake without having that tested during
build-time (since that's the only testsuite the upstream can maintain).  It
means that build (and probably runtime) of Automake will depend on "lang foo"
forever (and that's noarch, with library deps it is even worse).  Why we are
making problems from non-problem [4]?

Ok, I agree that Fedora needs modules for life-cycle separation.  But I don't
understand why we start "bottom up" and not the other way around.  Why we we
start with the base build toolset like autotools, instead of with leaf
packages on which (almost) nobody depends on?  Good examples are
{ RHSCL } / { languages } ... Subtract language-collections as modularity
doesn't solve "parallel install-ability" so multiple versions of Python
versions won't be possible in module world (rhscl allows that).

Pavel

> Modularity may sound great on paper, but as soon as you actually try to 
> implement it, it falls apart like a house of cards.
> 
> Kevin Kofler

Adam wrote:
> >[4] 
> >https://github.com/fedora-modularity/dependency-report/blob/original-plan/modules/autotools/all/buildtime-binary-packages-short.txt
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: About retiring OmegaT from Fedora

[Ismael Olea]

On Tue, Aug 22, 2017 at 3:33 AM, Yaakov Selkowitz 
wrote:


>
> Then you should orphan it.  If nobody takes it up, then it will be
> automatically retired.
>

I thought about it, but it's so hard to update it seems to me to better
retire and reduce the noise :-m


-- 

Ismael Olea

http://olea.org/diario/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Miroslav Suchý]

Dne 24.8.2017 v 04:10 Rudolf Kastl napsal(a):

Hey,

I am currently maintaining llvm trunk and mesa git snapshot repos for f25 and f26 at: 
https://copr.fedorainfracloud.org/coprs/che.


One thing i would love to see is the ability to have a buildrepo and a release repo and beeing able to sync from build 
to release once a complete buildchain successfully built.


More thorough description of the problem and a possible solution:

* you have a dependency chain of 3 packages to build
* you need to regen repos after each package because the next package in the tree depends on the first one. (like clang 
on llvm)

* then after building the first 2 packages the 3rd package breaks ... you end 
up with a broken dep chain in the repo.



You can do that:

* go to Settings of project
* Check "Create repositories manually"

Build your 3 packages. During this stage your new builds will not be in available in project repository, but will be 
available via special /devel/ repository, which is available during build time in your Copr project.

So your users will not see those package, but your builds will see it.

You can even test it if it works if you change baseurl and append /devel/ to 
the end of url.

Once finished go to the main page of your project and in right column click on "Regenerate" in "Regenerate Repositories" 
form.


Finally you can go to Settings and uncheck "Create repositories manually".

Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

[Nick Coghlan]

On 24 August 2017 at 19:02, Petr Viktorin  wrote:
> On 08/24/2017 10:13 AM, Nick Coghlan wrote:
>> My current thinking based on that discussion is that we're actually
>> going to need a module set that looks like this for F28+:
>>
>> * Platform Python (already planned for F27)
>>- part of the Platform module
>>- stream names match Fedora releases (f26, f27, etc)
>
> Stream names match the Platform module. We follow its policy here, even when
> it changes.

Oh, interesting, I had that backwards (I thought the planned F27
Python modules were the ones named after upstream Python releases).

That means the current module definitions would be closer to what I'm
calling the "Integrated Python Modules".

>> * Python Application Runtime Modules (already planned for F27)
>>- one module for Python 2 and one for Python 3
>>- stream names match upstream Python releases (2.7, 3.6, etc)
>>- Application Runtime Modules conflict with the corresponding >
>> Integrated Python Module
>>- provide "/usr/bin/python2" and "/usr/bin/python3" respectively
>>- also satisfy "python2-*" and "python3-*" RPM dependencies
>>- only the Python 2 module satisfies "python-*" RPM dependencies (for
>> now) > * Integrated Python Modules
>>- one module for Python 2 and one for Python 3
>
> These need to be parallel installable, to support tox. So we need separate
> modules for each Python release.

Aye, I agree that will be a good way to tackle the parallel
installable versions that *don't* define "/usr/bin/python3". However,
for containers designed to run Python applications (web or otherwise),
we *will* want mutually conflicting streams that define their symlinks
and RPM provides based only on the Python major version.

So lets make those extra modules their own distinct category:

* Python Interoperability Testing Modules
  - one module per Python X.Y release
  - only one stream per module
  - conflict with the corresponding Application Runtime stream
  - provide "/usr/bin/pythonXY" and "/usr/bin/pythonX.Y"
  - do NOT satisfy "python2-*" and "python3-*" RPM dependencies

And looking at their current implementation in Fedora, one notable
difference between them and the Application Runtime streams is that
these would just use their bundled pip and setuptools, rather than
splitting those out the way the regular packages do.

>>- stream names match Fedora releases (f26, f27, etc)
>>- each depends on an *exact* version of the corresponding Python
>>  Application Runtime module
>
>
> Huh? You just said Python Application Runtime Modules would conflict with
> this.

Sorry about that - when I started writing the email, my plan was to
have them conflict with each other, but as I wrote that initial
version up I went "Hang on, couldn't I use a stream dependency here
and rely on *that* to trigger a conflict if you had an Integrated
Python module installed and then tried to switch to an unsupported
runtime stream, or vice-versa?"

>> * Default Python Module
>>- provides /usr/bin/python (and nothing else)
>>- stream names: no-default, python3-default, python2-default
>
> +1
> I guess this would contain a "python" RPM, containing just a /usr/bin/python
> symlink, which would added to non-modular Fedora as well.

Pretty much, yeah. The "no-default" stream would be a bit different,
as in that case it would install a shell script that printed out a
custom error message.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Peter Robinson]

> On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
>> Hello Fedora devels and users,
>>
>> more than three years ago, the same topic started discussion if we
>> want
>> this package in Fedora or not and how [1]. The discussion resulted
>> mostly in flames and in the removal of the dependency on tcp_wrappers
>> from systemd. But it was quite agreed that it is considered as a
>> security layer for some users, if they use it correctly, or something
>> that is or should be replaced by firewalls.
>>
>> So can we discuss it now once more without the affiliation to
>> systemd?
>> The fact is that we still do not have any other replacement except
>> firewalls. But do we need one?
>>
>> The complete removal of the package is probably not a wise step, even
>> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
>> still available in Arch [3] without other tools depending on it. To
>> be
>> fair, Debian [4] is still building tools (for example openssh) with a
>> build-time support for it.
>>
>> My primary concern is OpenSSH, which upstream dropped support for
>> tcp_wrappers three years ago (late 2014) [5] and since then we are
>> maintaining one more downstream patch. But this effort should be
>> coordinated among other components to simplify the transition for
>> users
>> who insist on using it (using tcpd).
>>
>> Removing the dependency will also allow us to trim the default
>> install for few more Kb.
>>
>> If there will be no significant drawbacks, I will progress with
>> filling
>> a system wide change for Fedora 28 and I will pull the maintainers of
>> other tolls using libwrap into the round and discussion.
>
> Hello,
> In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
> time dependency:
>
>
> Since I'm listed twice in there...
>
> With my packages and the situation with build time options I take the
> position of enable as much as possible since our users don't get to pick
> their compilation options.
>
> However tcp_wrappers is a legacy thing that no longer belongs in today's
> world.
>
> I have no objection to a flag day in F28 development and dropping the build
> option at some point, preferably before the thing that is no longer an alpha
> ;) ... ie way before beta.

With F-27 now branched off this can happen in F-28/rawhide now
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Moo (master). "Upgrade to Fedora Rawhide"

[notifications]

From b5dc3e5a3f28b282925d58263506e52a28ac6722 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Aug 24 2017 09:25:51 +
Subject: Upgrade to Fedora Rawhide


---

diff --git a/perl-Moo.yaml b/perl-Moo.yaml
index e9ca445..3bead0f 100644
--- a/perl-Moo.yaml
+++ b/perl-Moo.yaml
@@ -11,13 +11,21 @@ data:
 module: [ MIT ]
 dependencies:
 buildrequires:
-base-runtime: master
+platform: master
 perl: master
+# Explicitly require transitive dependencies to work around
+# .
+host: master
 requires:
 perl: master
 references:
 community: https://fedoraproject.org/wiki/Modularity
 documentation: 
https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
+profiles:
+default:
+description: Moo Perl module
+rpms:
+- perl-Moo
 api:
 rpms:
 - perl-Moo
@@ -25,80 +33,83 @@ data:
 rpms:
 - perl-Class-XSAccessor
 - perl-Devel-CheckBin
-- perl-srpm-macros
 - perl-strictures
 - perl-Sub-Name
 - perl-Test-Fatal
 - perl-Test-Pod
 - perl-Test-Requires
 - perl-Try-Tiny
+buildopts:
+rpms:
+macros: |
+%perl_bootstrap 1
+%_without_perl_Class_Method_Modifiers_enables_optional_test 1
+%_without_perl_Module_Runtime_enables_optional_test 1
+%_without_perl_strictures_enables_optional_test 1
+%_without_perl_Try_Tiny_enables_optional_test 1
 components:
 rpms:
-perl-srpm-macros:
-rationale: Build dependency.
-ref: private-f27-modules-perl-Moo
-buildorder: 0
 perl-Class-XSAccessor:
 rationale: Build dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-Devel-CheckBin:
 rationale: Build dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-Module-Runtime:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-strictures:
 rationale: Build dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-Sub-Exporter-Progressive:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-Test-Pod:
 rationale: Build dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-Test-Requires:
 rationale: Build dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-Try-Tiny:
 rationale: Build dependency.
-ref: f26
-buildorder: 1
+ref: master
+buildorder: 0
 perl-Devel-GlobalDestruction:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 2
+ref: master
+buildorder: 1
 perl-Import-Into:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 2
+ref: master
+buildorder: 1
 perl-Sub-Name:
 rationale: Build dependency.
-ref: f26
-buildorder: 2
+ref: master
+buildorder: 1
 perl-Test-Fatal:
 rationale: Build dependency.
-ref: f26
-buildorder: 2
+ref: master
+buildorder: 1
 perl-Class-Method-Modifiers:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 3
+ref: master
+buildorder: 2
 perl-Sub-Quote:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 3
+ref: master
+buildorder: 2
 perl-Role-Tiny:
 rationale: Run-time dependency.
-ref: f26
-buildorder: 4
+ref: master
+buildorder: 3
 perl-Moo:
 rationale: API.
-ref: f26
-buildorder: 

Re: CI projects in Copr

[Luya Tshimbalanga]

On 23/08/17 04:46 AM, Miroslav Suchý wrote:
> Hi,
> I am gathering informations about various use of CI with Copr. Do you
> use Copr for building packages for nightlies? For building packages
> before pull request is merged? Do you have your set up described
> somewhere? What is the name of your project?
>
> Please let me know. Either here or via private reply.
> It will help me to understand your use of Copr and to make Copr better.
>
> Thanks in advance.
>
> Miroslav Suchy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Running nightly Scribus. I had to manually set up as I found using scm-2
troublesome for svn repository given the lack of proper documentation.
It will be nice to have a mechanism to tarball a svn repository then use
the spec file.

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

[Petr Viktorin]

On 08/24/2017 10:13 AM, Nick Coghlan wrote:

On 21 August 2017 at 19:46, Petr Viktorin  wrote:

On 08/18/2017 01:38 PM, Nick Coghlan wrote:

Does that approach sound sufficiently plausible to folks that I can
use it to provide feedback to the folks working on the modularity
tooling as to the capabilities we think we'll need?


That sounds like it would work. But yes, please talk to the Modularity WG to
see if modules can be made to work that way.


Aye, this draft proposal was essentially me figuring out what I think
we're going to want/need for Python before I pitched the related
feature ideas to the Modularity WG :)

The proposal then became something I could point to to say "This is
the problem I'm trying to solve" while we discussed various possible
ways of solving it.

I finally had a discussion with Langdon about it today, and he really
isn't a fan of my idea of trying to enhance the modularity tooling to
natively support parallel installation of streams - he'd strongly
prefer that we stick to the idea of "one active stream per module per
system" (at least for now), and then rely on separate SRPMs and/or the
Software Collections parallel installation layout to handle use cases
like tox.

(Note: I'll get the properly formatted proposal updated by tomorrow,
so feel free to wait for that if the email version below is a bit hard
to read)

My current thinking based on that discussion is that we're actually
going to need a module set that looks like this for F28+:

* Platform Python (already planned for F27)
   - part of the Platform module
   - stream names match Fedora releases (f26, f27, etc)


Stream names match the Platform module. We follow its policy here, even 
when it changes.



* Python Application Runtime Modules (already planned for F27)
   - one module for Python 2 and one for Python 3
   - stream names match upstream Python releases (2.7, 3.6, etc)
   - Application Runtime Modules conflict with the corresponding >  
Integrated Python Module
   - provide "/usr/bin/python2" and "/usr/bin/python3" respectively
   - also satisfy "python2-*" and "python3-*" RPM dependencies
   - only the Python 2 module satisfies "python-*" RPM dependencies (for now) > 
* Integrated Python Modules
   - one module for Python 2 and one for Python 3


These need to be parallel installable, to support tox. So we need 
separate modules for each Python release.



   - stream names match Fedora releases (f26, f27, etc)
   - each depends on an *exact* version of the corresponding Python
 Application Runtime module


Huh? You just said Python Application Runtime Modules would conflict 
with this.



* Default Python Module
   - provides /usr/bin/python (and nothing else)
   - stream names: no-default, python3-default, python2-default


+1
I guess this would contain a "python" RPM, containing just a 
/usr/bin/python symlink, which would added to non-modular Fedora as well.




The scope for F27 would specifically be Platform Python and the Python
Application Runtime Modules, with the separate Integrated Python
Modules being defined for F28+

At least for now, the Python XY stacks for Fedora and EPEL, as well as
the Python SCLs, would be treated as something generated downstream
from the app runtime modules, rather than as something that the
modularity tooling would necessarily handle natively.

The general idea is that it would then be up to other modules to
decide whether they specifically needed the Integrated Python Module
with all the related system bindings (in which case they'd either
depend on that module, or depend on another RPM that depended on it),
or were prepared to cope with any installed version of Python 3 (in
which case they'd just use normal RPM level "python3*" dependencies).

Right now, the difference between the Integrated Python Modules and
the Python Application Runtime Modules isn't particularly obvious, but
it hopefully becomes clearer once we consider questions like "Who will
decide when to rebase to Python 3.7?" and "When will a particular
stream stop being updated?".

For the Integrated Python Modules, those are Fedora level design
decisions, as reflected in the stream names being based on Fedora
versions. This means that for a system container, or a traditional
mutable installation, you'd be able to continue to rely on a shared
Python installation with all the operating system level bindings for
things like the RPM database, without Fedora package maintainers
having to provide prebuilt bindings for arbitrary Python versions.
You'd only change streams when you changed base Fedora versions, and
the update cycle for these streams would match the Fedora release
cycle (i.e. each stream would receive updates for 13 months from the
date of the corresponding Fedora release).

By contrast, for the Python App Runtime Modules, when to rebase is an
application developer level decision, as reflected in the stream names
being based directly on Python versions. This means that 

Re: [modularity] Modules and AppStream

[Richard Hughes]

On 24 August 2017 at 08:45, Marius Vollmer  wrote:
> If appstream-builder finds two packages that both contain metainfo for
> the same component id, what does it do?

If I understand correctly, in appstream-builder it's an error, and the
"first encountered" component wins.

>  What should it do?  What should
> the Software Center do.  This isn't described in the AppStream spec
> beyond the "merge" and "pripority" attributes for the  tag.

You have to remember, the AppStream spec was initially designed as a
way to map application IDs to package names. AppStream metadata is
written by basically every distro and consumed by every software
center, and it's not Fedora specific, so you probably shouldn't be
super surprised it doesn't map into the Fedora modularity system very
well.

My personal feeling is that this whole modularity initiative is being
pushed hard into all layers of Fedora without actually working out how
this is going to work with the various upstream specifications and
projects. I'm sure it'll be great for Fedora in the short term, but
longer term it's going to hurt being a little island of
Fedora-specific schemas and tools.

> One approach is just to put them all into the collection data:

You can't have two components with the same ID inside a 
group with the same origin.

> This is what they do for Flatpaks if I understand Owen correctly.

No, flatpaks components have different  names for each different
branch. e.g. the org.mozilla.Firefox.Nightly.desktop thing I explained
in my last email.

> I had assumed that the spec doesn't allow this and I thought that
> changing it to allow it would be too drastic.  If this is established
> practice and we just need to update the spec to catch up with reality,
> great!

No, please can you re-read mine and Owens previous emails please.

> My proposed approach was to encode the exact same data via a spec
> extension:
>   
> 
>Recommended
> 
> 
>Nightly builds
>foo-nightly
> 

I'm sorry, but that makes almost no sense.  What is the software
center supposed to do with variantsummary? Is the application name the
same between the two variants? Should reviews for the different
variants be treated as the same thing or as different things?

To me a module is a superset of a set of packages, much like a
 -- so it would make sense to have something like
org.fedoraproject.modularity.http2-6 which contains the
translated name, the translated description, the SPDX license, and any
URL links too. Of course, this is mostly the same as the modulemd
metadata as specified
https://docs.pagure.org/modularity/development/building-modules/developing.html
so you can certainly create AppStream from that pretty easily. I don't
think it makes any sense at all making projects like GNOME Software,
Apper, Discover, Muon and Cockpit (and others) understand much about
the Fedora modularity stuff when everything seems to have standardized
on AppStream -- including next-generation distributions methods like
Flatpak.

> If a client understands "variants", it can trivially expand them back
> into multiple entries for the same id.  Clients that don't understand
> this will continue to just see one.

They're two different things. Would gnome-software and cockpit show
two search entries for the two variants or one? Would you be able to
switch between the variants? Can both be installed at the same time,
by two different users on the same system? If the modules are flatpaks
then they're two different components with two different AppIDs, that
can both be installed at the same time. I'm having a very hard time
working out how we'd communicate difficult to understand concepts to
the end user using packages, even wrapped up with modulemd metadata.

> Maybe I should emphasize that I am only trying to figure out what
> happens if we subject a modularized repository to the usual AppStream
> treatment.

Can you provide some specifications on what a modularized repository
should actually look like please? Is a repo going to contain .rpm
packages like firefox-1.23.rpm and also firefox-2.34.rpm or something
completely different? If both packages contain a metainfo/appdata file
with the same component  it's just not going to work very well
using appstream-builder.

> I think we would create broken AppStream collection data right now, or
> at least AppStream data that doesn't let us take advantage of the new
> features that modularity enables (streams and profiles).

Has anyone talked to the Fedora or GNOME designers about this? I'm
trying hard not to get frustrated about questions about XML schema
when I don't think anybody has considered the user experience of
modularity. From a desktop point of view I'm currently of the opinion
that it only makes sense to show modules that are flatpaks, and
continue to use the appstream branch of the flatpak repository to get
information about the modules.

> I am 

[Bug 1475081] CVE-2017-5944 rt: Remote code execution in the dashboard subscription interface

[bugzilla]

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

Andrej Nemec  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |ERRATA
Last Closed||2017-08-24 04:56:35



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

Python 3.5.4 in Fedora 25

[Petr Viktorin]

Hello,
Python 3.5.4 for Fedora 25 is now waiting in Bodhi; see more info here:
https://bodhi.fedoraproject.org/updates/python3-3.5.4-1.fc25

Please test and provide karma :)


--
Petr Viktorin
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Juan Orti Alcaine]

2017-08-22 5:17 GMT+02:00 Michal Novotny :
> Hello,
>
> we will have soon a planning meeting that should determine a more long-term
> strategy and bring us to a team agreement on what COPR currently is and what
> it should be in half a year or so.
>
> I would like to kindly ask for some input here on the devel list to find out
> what the actual expectations of COPR are and if there are any ideas about
> what could COPR bring to the game.
>

Hi,

I would like to be able to build for more arches, mainly arm.
I guess the limitation is because hardware for that architecture is
needed. Is not possible to cross-build the packages?
It would be great if the noarch packages were available to all architectures.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Modularity, container images, and the default Python stack(s)

[Nick Coghlan]

On 21 August 2017 at 19:46, Petr Viktorin  wrote:
> On 08/18/2017 01:38 PM, Nick Coghlan wrote:
>> Does that approach sound sufficiently plausible to folks that I can
>> use it to provide feedback to the folks working on the modularity
>> tooling as to the capabilities we think we'll need?
>
> That sounds like it would work. But yes, please talk to the Modularity WG to
> see if modules can be made to work that way.

Aye, this draft proposal was essentially me figuring out what I think
we're going to want/need for Python before I pitched the related
feature ideas to the Modularity WG :)

The proposal then became something I could point to to say "This is
the problem I'm trying to solve" while we discussed various possible
ways of solving it.

I finally had a discussion with Langdon about it today, and he really
isn't a fan of my idea of trying to enhance the modularity tooling to
natively support parallel installation of streams - he'd strongly
prefer that we stick to the idea of "one active stream per module per
system" (at least for now), and then rely on separate SRPMs and/or the
Software Collections parallel installation layout to handle use cases
like tox.

(Note: I'll get the properly formatted proposal updated by tomorrow,
so feel free to wait for that if the email version below is a bit hard
to read)

My current thinking based on that discussion is that we're actually
going to need a module set that looks like this for F28+:

* Platform Python (already planned for F27)
  - part of the Platform module
  - stream names match Fedora releases (f26, f27, etc)
* Python Application Runtime Modules (already planned for F27)
  - one module for Python 2 and one for Python 3
  - stream names match upstream Python releases (2.7, 3.6, etc)
  - Application Runtime Modules conflict with the corresponding
Integrated Python Module
  - provide "/usr/bin/python2" and "/usr/bin/python3" respectively
  - also satisfy "python2-*" and "python3-*" RPM dependencies
  - only the Python 2 module satisfies "python-*" RPM dependencies (for now)
* Integrated Python Modules
  - one module for Python 2 and one for Python 3
  - stream names match Fedora releases (f26, f27, etc)
  - each depends on an *exact* version of the corresponding Python
Application Runtime module
* Default Python Module
  - provides /usr/bin/python (and nothing else)
  - stream names: no-default, python3-default, python2-default

The scope for F27 would specifically be Platform Python and the Python
Application Runtime Modules, with the separate Integrated Python
Modules being defined for F28+

At least for now, the Python XY stacks for Fedora and EPEL, as well as
the Python SCLs, would be treated as something generated downstream
from the app runtime modules, rather than as something that the
modularity tooling would necessarily handle natively.

The general idea is that it would then be up to other modules to
decide whether they specifically needed the Integrated Python Module
with all the related system bindings (in which case they'd either
depend on that module, or depend on another RPM that depended on it),
or were prepared to cope with any installed version of Python 3 (in
which case they'd just use normal RPM level "python3*" dependencies).

Right now, the difference between the Integrated Python Modules and
the Python Application Runtime Modules isn't particularly obvious, but
it hopefully becomes clearer once we consider questions like "Who will
decide when to rebase to Python 3.7?" and "When will a particular
stream stop being updated?".

For the Integrated Python Modules, those are Fedora level design
decisions, as reflected in the stream names being based on Fedora
versions. This means that for a system container, or a traditional
mutable installation, you'd be able to continue to rely on a shared
Python installation with all the operating system level bindings for
things like the RPM database, without Fedora package maintainers
having to provide prebuilt bindings for arbitrary Python versions.
You'd only change streams when you changed base Fedora versions, and
the update cycle for these streams would match the Fedora release
cycle (i.e. each stream would receive updates for 13 months from the
date of the corresponding Fedora release).

By contrast, for the Python App Runtime Modules, when to rebase is an
application developer level decision, as reflected in the stream names
being based directly on Python versions. This means that for an
application container image, you'd be able to select an arbitrary
Python version of your choice, but in doing so, you'd potentially be
giving up ready access to pre-built bindings for various system APIs
(if your choice of stream didn't match the dependencies declared in
the Integrated Python Module). For these streams, the update cycle
would match that of the relevant upstream Python branch (i.e. full
maintenance updates until shortly after the next Python feature
release, then security 

[EPEL-devel] Re: nodejs broken

[Paul Howarth]

On 2017-08-23 18:27, Stephen Gallagher wrote:

I think the only sane approach here is going to be to just drop all of
the 7.3-specific stuff and just tell people that they're unfortunately
out of luck on CentOS until 7.4 is out for that platform.


Not entirely out of luck. CentOS 7 users could now enable the cr 
repository and pick up OpenSSL 1.0.2kk from there.


Paul.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Rudolf,

On Thu, Aug 24, 2017 at 4:10 AM, Rudolf Kastl  wrote:

> Hey,
>
> I am currently maintaining llvm trunk and mesa git snapshot repos for f25
> and f26 at: https://copr.fedorainfracloud.org/coprs/che.
>
> One thing i would love to see is the ability to have a buildrepo and a
> release repo and beeing able to sync from build to release once a complete
> buildchain successfully built.
>
> More thorough description of the problem and a possible solution:
>
> * you have a dependency chain of 3 packages to build
> * you need to regen repos after each package because the next package in
> the tree depends on the first one. (like clang on llvm)
> * then after building the first 2 packages the 3rd package breaks ... you
> end up with a broken dep chain in the repo.
>
> Now a workaround would be to do scratch builds first and then final repo
> builds. But e.g. for llvm (only the llvm library) that means... over 100
> minutes buildtime using 4 builders (32bit / 64bit for 2 distro versions).
>
> What i would love to see is to be able to build in one repository and then
> send (copy/rsync whatever) the built chain over to a release repository.
> This way also testing is possible before pushing the stuff to consumers.
>
>
So, this is interesting. This is something like auto-forking from one
project to another after a successful batch build (under development). It
actually could work just inside one project if the batch building would be
done separately from the main project repo and only be included if
successful. Ok, thanks for this input. I think we can do something about
this.


> kind regards,
> Rudolf Kastl
>
>
>
> 2017-08-22 17:15 GMT+02:00 Kamil Dudka :
>
>> On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
>> > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  wrote:
>> > > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
>> > > > Hey Kamil,
>> > > >
>> > > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka 
>> wrote:
>> > > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
>> > > > > > - the ability to directly upload srpms; that is, one can store
>> spec
>> > > > > >
>> > > > > >   files etc. on the local machine. I'm undecided, if
>> integrating a
>> > > > > >   distgit on copr would solve any issues or would introduce
>> more,
>> > >
>> > > like
>> > >
>> > > > > >   diverging specs.
>> > > > >
>> > > > > Building packages from dist-git is already possible via 'copr
>> > > > > buildfedpkg'.
>> > > > > The problem is that the last time I tried, it only worked for the
>> > >
>> > > official
>> > >
>> > > > > Fedora branches.  All attempts to build something from a
>> > >
>> > > private-kdudka-*
>> > >
>> > > > > branch failed with the well known "Could not find the dist from
>> branch
>> > > > > name"
>> > > > > failure of fedpkg.  Unless arbitrary dist-git branches are
>> suported,
>> > >
>> > > the
>> > >
>> > > > > 'copr buildfedpkg' command is pretty useless.
>> > > >
>> > > > Actually, we already support arbitrary dist-git branches in COPR
>> > >
>> > > Sounds good.  I wanted to check this:
>> > >
>> > > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
>> > > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
>> > >
>> > > Build was added to tmp:
>> > >   https://copr.fedorainfracloud.org/coprs/build/592748/
>> > >
>> > > Created builds: 592748
>> > > Watching build(s): (this may be safely interrupted)
>> > >
>> > >   16:20:56 Build 592748: importing
>> > >
>> > > But the task hangs indefinitely in the "importing" state.  You can see
>> > > that
>> > > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log
>> still
>> > > grows with obvious periodicity.
>> > >
>> > > Am I doing anything wrong?
>> >
>> > Uh, not really. fedpkg was not installed on the production machine thus
>> the
>> > import was failing.
>> > Note that this is still slightly under development but it should
>> definitely
>> > work as a feature in
>> > any case.
>>
>> OK.  Thank you for working on it!  I am looking forward to use it one
>> day...
>>
>> > > Kamil
>> > >
>> > > > and we also aim
>> > > > to be able to build from any dist-git (at least being based on
>> > > > https://src.fedoraproject.org/rpms/dist-git).
>> > > >
>> > > > Currently we also support building from copr-dist-git in addition to
>> > >
>> > > Fedora
>> > >
>> > > > DistGit but
>> > > > we need to reflect that in our API and in copr-cli interface by
>> renaming
>> > > > the subcommand.
>> > > > (or providing the new generic one while keeping the old one for some
>> > >
>> > > time)
>> > >
>> > > > Then there is actually also the new rpkg client (based on pyrpkg
>> lib):
>> > > > https://src.fedoraproject.org/rpms/rpkg-client
>> > > > that you can use for launching COPR builds from any dist-git repo
>> being
>> > > > locally checked out.
>> > > >
>> > > > > Kamil
>>