date:20160629

Re: [heads-up] PHP 7.0 is now in rawhide

2016-06-29 Thread Remi Collet

Le 29/06/2016 à 08:22, Remi Collet a écrit :
> Get back old apc API:
> 1350148: php-pecl-apcu-bc - APCu Backwards Compatibility Module

Thanks to Nathanael, the package is now in rawhide.

Some explanation.

With PHP 5, apcu was providing both the old apc API (apc_* functions)
and the new apcu API (apcu_* functions).

With PHP 7 apcu only provides its own API,
while apcu-bc provide the old apc API (mostly function aliases).

So check your code/dependency to require the right API,
this works in all branches, including EPEL:
- php-pecl(APC)
- php-pecl(apcu)


Remi.

P.S. installing a user data cache should usually be an admin choice, so
a weak dependency.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Anyone know how to contact maintainer Salimma?

2016-06-29 Thread Avram Lubkin

I've been trying to contact Salimma, Michel Alexandre Salim, for the last
month. I've been trying to update python-sphinx which hasn't had an update
since last fall. Worked through all of the issues, but maintainer hasn't
responded to commit request, email, or bug reports.

Bug report for newest version of Sphinx with needinfo flag.
https://bugzilla.redhat.com/show_bug.cgi?id=1323202

Anyone have any info?


Thanks
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Problem with exact provides in pre-release version

2016-06-29 Thread Ahmad Samir

On 30 June 2016 at 01:21, Marcin Zajączkowski  wrote:
>
> Hi,
>
> I'm a maintainer of NetworkManager-sstp package and before 1.2.0 final
> will be released I experimenting in my CORP repo with pre-release Git
> version. I've encountered a situation which - I'm not sure - is a
> problem with my configuration or some issue with dependencies resolving.
>
> $ sudo dnf install NetworkManager-sstp-gnome
> Error: nothing provides NetworkManager-sstp(x86-64) =
> 1.2.0-0.20160514git86c2737d.fc24 needed by
> NetworkManager-sstp-gnome-1:1.2.0-0.20160514git86c2737d.fc24.x86_64
> (try to add '--allowerasing' to command line to replace conflicting
> packages)
>
> While already installed corresponding NetworkManager-sstp reports:
> $ rpm -q --provides NetworkManager-sstp
> NetworkManager-sstp = 1:1.2.0-0.20160514git86c2737d.fc24
> NetworkManager-sstp(x86-64) = 1:1.2.0-0.20160514git86c2737d.fc24
> config(NetworkManager-sstp) = 1:1.2.0-0.20160514git86c2737d.fc24
>
> I don't know why I have that error - NetworkManager-sstp seems to
> provide what is needed.
>
> In the SPEC file I have (for NetworkManager-sstp-gnome):
> > Requires: NetworkManager-sstp%{?_isa} = %{version}-%{release}
>

You should add the epoch to the requires:
Requires: NetworkManager-sstp%{?_isa} = %{epoch}:%{version}-%{release}

[...]

-- 
Ahmad Samir
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1351388] New: perl-HTML-FormFu-Model-DBIC-2.02 is available

2016-06-29 Thread bugzilla

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

Bug ID: 1351388
   Summary: perl-HTML-FormFu-Model-DBIC-2.02 is available
   Product: Fedora
   Version: rawhide
 Component: perl-HTML-FormFu-Model-DBIC
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 2.02
Current version/release in rawhide: 2.01-1.fc25
URL: http://search.cpan.org/dist/HTML-FormFu-Model-DBIC

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346784] perl-HTML-FormFu-2.03 is available

2016-06-29 Thread bugzilla

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-HTML-FormFu-2.02 is|perl-HTML-FormFu-2.03 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.03
Current version/release in rawhide: 2.01-8.fc25
URL: http://search.cpan.org/dist/HTML-FormFu/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Injecting perl-devel and perl-generators build-requires

2016-06-29 Thread Jeff Fearn

On 29/06/16 23:27, Petr Pisar wrote:
> On 2016-06-29, Jeff Fearn  wrote:
>> I would like the perl team to consider taking this opportunity to remove
>> non-standard behavior instead of adding more. The whole perl/perl-devel
>> split was to make the install smaller, mostly for build root reasons.
>> Since that is no longer a consideration can we make it so that requiring
>> perl gets you a proper perl core installed?
>>
>> That should stop most breakage as anyone using none core stuff should
>> have had it specifically required anyway.
>>
> What applies to any Fedora package, applies to Perl packages too.
> 
> For example we have about 2800 Perl packages, but only 493 are
> architecture specific that must depend on perl-devel and GCC. (I know
> the number because two months ago I accidentally removed perl-devel.)

But did you replace perl-devel with a proper perl core? Because unless
you did that you are just pointing out how broken the perl shipped in
Fedora is.

> So no, I do not consider making the core modules somewhat special.

You aren't *making* them special, you are accepting that this is how
perl works, this is how perl is designed to work, and that people should
have to care about the special packaging naming magic in spec files to
get their sources packaged.

> Perl
> would have fallen into the same mud where Python or TeX Live is now.

Fedora's & Red Hat's names are mud in the perl world, have been for
years, and it won't change until we stop breaking perl core.

Cheers, Jeff.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Problem with exact provides in pre-release version

2016-06-29 Thread Marcin Zajączkowski

Hi,

I'm a maintainer of NetworkManager-sstp package and before 1.2.0 final
will be released I experimenting in my CORP repo with pre-release Git
version. I've encountered a situation which - I'm not sure - is a
problem with my configuration or some issue with dependencies resolving.

$ sudo dnf install NetworkManager-sstp-gnome
Error: nothing provides NetworkManager-sstp(x86-64) =
1.2.0-0.20160514git86c2737d.fc24 needed by
NetworkManager-sstp-gnome-1:1.2.0-0.20160514git86c2737d.fc24.x86_64
(try to add '--allowerasing' to command line to replace conflicting
packages)

While already installed corresponding NetworkManager-sstp reports:
$ rpm -q --provides NetworkManager-sstp
NetworkManager-sstp = 1:1.2.0-0.20160514git86c2737d.fc24
NetworkManager-sstp(x86-64) = 1:1.2.0-0.20160514git86c2737d.fc24
config(NetworkManager-sstp) = 1:1.2.0-0.20160514git86c2737d.fc24

I don't know why I have that error - NetworkManager-sstp seems to
provide what is needed.

In the SPEC file I have (for NetworkManager-sstp-gnome):
> Requires: NetworkManager-sstp%{?_isa} = %{version}-%{release}

where:
> %global snapshot .20160514git86c2737d
> Version:   1.2.0
> Release:   0%{snapshot}%{?dist}

A branch with my pre-release changes:
http://pkgs.fedoraproject.org/cgit/rpms/NetworkManager-sstp.git/log/?h=user/szpak/NetworkManager-1.2-git
My CORP repo:
https://copr.fedorainfracloud.org/coprs/szpak/NetworkManager-sstp/

Do you know could be the reason?

Marcin
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Updated hdf5, netcdf, libdap coming to rawhide tomorrow

2016-06-29 Thread Orion Poplawski


On 06/28/2016 04:59 PM, Orion Poplawski wrote:

I'll be updating hdf5, netcdf, and libdap in rawhide tomorrow and doing
rebuilds of dependent packages.



Well, as typical, running into issues with openmpi on arm.  Investigating.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Maintainer preferred method of blocker bug notification?

2016-06-29 Thread Kevin Fenzi

On Wed, 29 Jun 2016 16:20:32 -0600
Chris Murphy  wrote:

...snip...

> The questions then, are:
> - Have we reached the pinnacle notification method of blocker bugs to
> maintainers? Or is there a better way to do this?

Well, I actually think the human touch here helps. (ie, when adamw does
do a roundup and tries to contact people with an update email), Which
makes it particularly hard to automate without being anoying. 

> - Would it help to have a nagbot (or enhance zodbot) to ping
> maintainers on IRC? Is the nagbot more or less likely to be ignored,
> or would it be about the same? Of course there are lower level
> questions about whether it's possible, what work it entails, would it
> be opt in or opt out, could notifications happen outside IRC, but for
> now I think the "in general" high level context is more useful.

No, I think it would not help. :) 

First, there's a number of folks who aren't on IRC (shocking I know),
then it gets back to the impersonalness of it... 

I'm not really sure that we have had slips (which as Matt tells us, are
completely expected and fine) due to some maintainer not realizing a
bug was a blocker and not looking at it. In general it's been because
the maintainer has lots of other things going on, or the bug is
difficult to fix and just takes time. 

kevin

pgpg9F0MGUPtq.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Maintainer preferred method of blocker bug notification?

2016-06-29 Thread Bruno Wolff III


On Wed, Jun 29, 2016 at 16:20:32 -0600,
 Chris Murphy  wrote:


- Would it help to have a nagbot (or enhance zodbot) to ping
maintainers on IRC? Is the nagbot more or less likely to be ignored,
or would it be about the same? Of course there are lower level
questions about whether it's possible, what work it entails, would it
be opt in or opt out, could notifications happen outside IRC, but for
now I think the "in general" high level context is more useful.


I think it is more likely to annoy people than to help.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1346539] perl-PDF-API2-2.028 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-PDF-API2-2.028-1.fc24 has been pushed to the Fedora 24 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-2016-9ed2826878

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Maintainer preferred method of blocker bug notification?

2016-06-29 Thread Chris Murphy

Hi,

At a recent QA meeting I raised the idea of a better way for
maintainers to find out when their package is a release blocking bug.
Better is vaguely defined by me as: not email based, and not adamw
based (Adam Williamson is in fact a person not a bot).

Currently, the ways a maintainer finds out a bug is release blocking:

1. Bugzilla email. When QA determines a bug is a blocker, it's noted
in the bug as a comment, and bugzilla emails (most) everyone on the
cc.

The problem with email is self-explanatory. If the bugzilla
notification email isn't being registered in a useful way, probably
more emails won't help either.

2. The very nifty Fedora Blocker Bug Tracking app
https://qa.fedoraproject.org/blockerbugs/

The problem with this is, it's passive. You need to check it. So it's
mainly used by QA folks to get a bird's eye view of the status of
blocker bugs, and freeze exceptions.

3. The illustrious, humorous, verbose, would have been cloned by now
were it affordable and timely enough, adamw, who sends out an email
summary of blocking bugs to devel@.

Problem, more email.

4. Adamw (or less often another human within QA) takes it upon
themselves to inquire via IRC. These are effective. Unknown is if
slips would have resulted if they didn't happen. But it seems at least
plausible that it would increase slips without this form of nagging
(reminding).

The problem is, I think it's inappropriate for any one person to have
to nag other people about their bugs. It's also tedious and manual.
The time and interest for any QA person to do this is low.


The questions then, are:
- Have we reached the pinnacle notification method of blocker bugs to
maintainers? Or is there a better way to do this?

- Would it help to have a nagbot (or enhance zodbot) to ping
maintainers on IRC? Is the nagbot more or less likely to be ignored,
or would it be about the same? Of course there are lower level
questions about whether it's possible, what work it entails, would it
be opt in or opt out, could notifications happen outside IRC, but for
now I think the "in general" high level context is more useful.



-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide-20160629.n.0 compose check report

2016-06-29 Thread Fedora compose checker

Missing expected images:

Workstation live i386
Cloud_base raw-xz i386
Atomic raw-xz x86_64
Kde raw-xz armhfp
Minimal raw-xz armhfp
Workstation live x86_64

Failed openQA tests: 8/78 (x86_64), 2/16 (i386)

ID: 24131   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/24131
ID: 24149   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/24149
ID: 24182   Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/24182
ID: 24183   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/24183
ID: 24184   Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/24184
ID: 24185   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/24185
ID: 24187   Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/24187
ID: 24217   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/24217
ID: 24219   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/24219
ID: 24224   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/24224

Passed openQA tests: 67/78 (x86_64), 14/16 (i386)

-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

2016-06-29 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 478  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 241  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 107  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-785fc9a2ea   
dropbear-2016.72-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c57f2c7e47   
drupal7-7.44-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d3e4c82ed7   
squidGuard-1.4-26.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-3126135a39   
wordpress-4.5.3-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cd7ade5b28   
phpMyAdmin-4.4.15.7-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e0c08a1414   
php-PHPMailer-5.2.16-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ce0d3be037   
gsi-openssh-6.6.1p1-4.el7


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

0ad-0.0.20-4.el7
0ad-data-0.0.20-1.el7
bash-completion-extras-2.1-11.el7
fedfind-2.4.10-1.el7
fedpkg-1.24-2.el7
kstars-16.04.2-1.el7
kubernetes-ansible-0.6.0-0.1.gitd65ebd5.el7
libabigail-1.0-0.8.rc5.2.el7
miniupnpc-2.0-1.el7
mozjs31-31.2.0-8.el7
nvidia-texture-tools-2.0.8-13.el7
perl-Config-Grammar-1.11-1.el7
python-stuf-0.9.16-7.el7
rpkg-1.45-2.el7
yamllint-1.3.2-1.el7

Details about builds:



 0ad-0.0.20-4.el7 (FEDORA-EPEL-2016-b92b91098f)
 Cross-Platform RTS Game of Ancient Warfare

Update Information:

Initial 0ad build for EPEL 7.




 0ad-data-0.0.20-1.el7 (FEDORA-EPEL-2016-b92b91098f)
 The Data Files for 0 AD

Update Information:

Initial 0ad build for EPEL 7.




 bash-completion-extras-2.1-11.el7 (FEDORA-EPEL-2016-57322c5a9c)
 Additional programmable completions for Bash

Update Information:

remove completion collision for rpm    remove files that conflict with base
bash-completion package

References:

  [ 1 ] Bug #1339420 - bash-completion-extras provides files provided by RHEL 
bash-completion package
https://bugzilla.redhat.com/show_bug.cgi?id=1339420




 fedfind-2.4.10-1.el7 (FEDORA-EPEL-2016-72986de743)
 Fedora Finder finds Fedora

Update Information:

This update mainly updates fedfind to handle the new Pungi 4 two-week Atomic
composes (release engineering is now building these, which are nightly composes
of Cloud and Atomic images for the current stable release, with Pungi 4, whereas
before they were built with the old compose process). The new `AtomicNightly`
subclass of `fedfind.release.Release` is added to handle these, and will be
returned when appropriate by `fedfind.release.get_release`.  This update also
stops fedfind using the `Pungi4Mirror` class which is intended to be used for
milestone releases that have been synced to the public mirror system; at
present, these composes are actually split in two and different outputs mirrored
to two different locations, and the productmd metadata is stripped from both
locations (as it no longer accurately reflects the contents to be found in
each), so fedfind cannot treat them as Pungi 4 composes as the metadata is
unavailable. Instead we simply use the old `MirrorRelease` subclasses, so the
contents are discovered by scraping and the metadata synthesized. Note that
fedfind does not and in fact never has supported finding the contents that are
split out and placed in the `alt/releases/` tree, as I was not aware of the fact
that composes were split in this way and never designed fedfind to take account
of it.




 fedpkg-1.24-2.el7 (FEDORA-EPEL-2016-e5e5513a38)
 Fedora utility for working with dist-git

Update Information:

This new release contains several

Re: Fixing /.autorelabel

2016-06-29 Thread Adam Williamson

On Wed, 2016-06-29 at 22:15 +0100, Richard W.M. Jones wrote:
> It should be possible to touch /.autorelabel and have the SELinux
> labels on the filesystem fixed at next boot.
> 
> Fedora 24 shipped with a couple of nasty bugs in /.autorelabel
> functionality:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1351352
>   https://bugzilla.redhat.com/show_bug.cgi?id=1349586
> 
> This is not particularly a new thing.  This bug against systemd was
> filed a couple of years ago, and still not fixed although the problem
> is understood and there is a fix:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1049656
> 
> The general issues are:
> 
> (1) Autorelabelling requires that the system is booted up "enough" to
> run the fedora-autorelabel.service.
> 
> (2) If SELinux is enabled during the boot, then services may fail to
> start up correctly because of mislabelled files.
> 
> (3) fedora-autorelabel.service requires local-fs.target.  This is a
> correct dependency, but it also happens quite late -- if you look at
> the attached chart you can see that dozens of services need to be
> started successfully before we even get to local-fs.target.
> 
> (4) If we don't reach the fedora-autorelabel.service then we can be
> dumped into a rescue shell, or worse still go into a boot loop.
> 
> (5) The fedora-autorelabel.service itself can fail to be run because
> SELinux stops systemd from working properly (the cause of
> RHBZ#1049656).
> 
> (6) A related problem is that the autorelabel doesn't stop other
> services from attempting to start while the relabel is happening.
> 
> I'm not sure what's a good way to fix it.  Some ways I can think of:
> 
> (e) Insert your idea here ...

Well, bug #1351352 (which you cited) isn't exactly a bug, but my
suggestion, which isn't quite the same as any of yours (though it's
similar to a couple). My suggestion is to have libselinux look whether
a relabel is planned - by checking for /.autorelabel or 'autorelabel'
on the cmdline, which is what the autorelabel service looks for - and
load in permissive mode if so.
-- 
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
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fixing /.autorelabel

2016-06-29 Thread Richard W.M. Jones

It should be possible to touch /.autorelabel and have the SELinux
labels on the filesystem fixed at next boot.

Fedora 24 shipped with a couple of nasty bugs in /.autorelabel
functionality:

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

This is not particularly a new thing.  This bug against systemd was
filed a couple of years ago, and still not fixed although the problem
is understood and there is a fix:

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

The general issues are:

(1) Autorelabelling requires that the system is booted up "enough" to
run the fedora-autorelabel.service.

(2) If SELinux is enabled during the boot, then services may fail to
start up correctly because of mislabelled files.

(3) fedora-autorelabel.service requires local-fs.target.  This is a
correct dependency, but it also happens quite late -- if you look at
the attached chart you can see that dozens of services need to be
started successfully before we even get to local-fs.target.

(4) If we don't reach the fedora-autorelabel.service then we can be
dumped into a rescue shell, or worse still go into a boot loop.

(5) The fedora-autorelabel.service itself can fail to be run because
SELinux stops systemd from working properly (the cause of
RHBZ#1049656).

(6) A related problem is that the autorelabel doesn't stop other
services from attempting to start while the relabel is happening.

I'm not sure what's a good way to fix it.  Some ways I can think of:

(a) Configure /etc/selinux/config to set SELinux permissive, and
modify the fedora-autorelabel.service so it edits /etc/selinux/config
to re-enable SELinux next time.  This editing would have to be
conditional, and the details are up in the air.  Maybe there could be
a "/.autorelabel-enforce-after-boot" file to do this?

[Note these are for VM images, so we cannot have "special" boot flags
that the user must set and modify, it must all happen automatically]

(b) Introduce some shortcut, low level, very minimal default target
which systemd uses when it sees the /.autorelabel file.  This was
basically what sysvinit used to do - the /.autorelabel file was
processed specially very early in the boot scripts.

(c) Instead of touching the file, set the default.target to some
special target.  The problem with this is we want to replace
default.target with the normal one after the autorelabel completes
successfully, and I've no idea how to do that.

(d) Combine setting SELinux to enforcing with checking for
/.autorelabel.  If whatever it is that reads /etc/selinux/config
notices that the /.autorelabel file exists, it should do the
autorelabel before setting SELinux to enforcing.

(e) Insert your idea here ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2016-06-30 16:00 UTC)

2016-06-29 Thread James Antill

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-06-30 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2016-06-30 09:00 Thu US/Pacific PDT
2016-06-30 12:00 Thu US/Eastern EDT
2016-06-30 16:00 Thu UTC <-
2016-06-30 17:00 Thu Europe/London  BST
2016-06-30 18:00 Thu Europe/Paris  CEST
2016-06-30 18:00 Thu Europe/Berlin CEST
2016-06-30 21:30 Thu Asia/Calcutta  IST
--new day--
2016-07-01 00:00 Fri Asia/Singapore SGT
2016-07-01 00:00 Fri Asia/Hong_Kong HKT
2016-07-01 01:00 Fri Asia/Tokyo JST
2016-07-01 02:00 Fri Australia/BrisbaneAEST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/13

= Followups =

#topic #558 Application/Library distinction and package
splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558

#topic #566 RPM file triggers
.fpc 566
https://fedorahosted.org/fpc/ticket/566

#topic #610 Packaging guidelines: Check upstream tarball
signatures
.fpc 610
https://fedorahosted.org/fpc/ticket/610

#topic #629 Handling directories under /var/lock and /var/run
in
%files and base image
.fpc 629
https://fedorahosted.org/fpc/ticket/629

#topic #633 Document unwritten rule about guideline exceptions
.fpc 633
https://fedorahosted.org/fpc/ticket/633

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/13

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
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
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1351354] New: amavisd-new: additional systemd hardening

2016-06-29 Thread bugzilla

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

Bug ID: 1351354
   Summary: amavisd-new: additional systemd hardening
   Product: Fedora
   Version: 24
 Component: amavisd-new
  Assignee: j.orti.alca...@gmail.com
  Reporter: candr...@integralblue.com
QA Contact: extras...@fedoraproject.org
CC: j.orti.alca...@gmail.com,
perl-devel@lists.fedoraproject.org, st...@silug.org,
vanmeeuwen+fed...@kolabsys.com



amavisd-new's systemd services should use more of systemd's hardening features.

http://pkgs.fedoraproject.org/cgit/rpms/amavisd-new.git/tree/amavis-mc.service
should probably have added to it:
CapabilityBoundingSet=
ProtectSystem=full
ProtectHome=true

http://pkgs.fedoraproject.org/cgit/rpms/amavisd-new.git/tree/amavisd-clean-quarantine.service
should probably have added to it:
CapabilityBoundingSet=
ProtectSystem=full
ProtectHome=true

http://pkgs.fedoraproject.org/cgit/rpms/amavisd-new.git/tree/amavisd-clean-tmp.service
should probably have added to it:
CapabilityBoundingSet=
ProtectSystem=full
ProtectHome=true

http://pkgs.fedoraproject.org/cgit/rpms/amavisd-new.git/tree/amavisd-snmp-zmq.service
should probably have added to it:
CapabilityBoundingSet=
ProtectHome=true
ProtectSystem=full

http://pkgs.fedoraproject.org/cgit/rpms/amavisd-new.git/tree/amavisd-snmp.service
should probably have added to it:
CapabilityBoundingSet=
ProtectHome=true
ProtectSystem=full

http://pkgs.fedoraproject.org/cgit/rpms/amavisd-new.git/tree/amavisd.service
should probably have added to it:
CapabilityBoundingSet=
ProtectHome=true
ProtectSystem=full

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Firefox on Wayland

2016-06-29 Thread Samuel Rakitničan

> On 06/28/2016 12:13 PM, Martin Stransky wrote:
> 
> New fixed package is available at Copr.
> ma.

Fixed the launcher crash for me. Window repainting [1] is still an issue for 
me, though, which makes it kind of unusable under wayland.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1349016
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Modularity] BPO - the great UI that shows you everything

2016-06-29 Thread Kevin Fenzi

On Wed, 29 Jun 2016 10:51:13 -0700
Adam Williamson  wrote:

> On Wed, 2016-06-29 at 18:18 +0200, Adam Samalik wrote:
> > Hi everyone,
> > 
> > I would like to hear your opinion/need your help!
> > 
> > I am working on a component of the Fedora Modularity[1] project,
> > called Build Pipeline Overview (BPO). It will be a single user
> > interface (probably both web and API) that would give you
> > information about "everything".  And I would like your help with
> > defining what that "everything" means.
> > 
> > To make the definition of "everything" easier, we are using a
> > concept of personas. These are basically groups of people that
> > would use the BPO UI that will help us to identify possible
> > use-cases.
> > 
> > @threebean have identified four personas:
> >  - Engineers/packagers
> >  - Release Engineering
> >  - QA
> >  - Project Management
> > 
> > I have put them into an Etherpad document [2].
> > 
> > 
> > What I'm asking from you: Could you please discuss here or in the
> > document what would you like to see in the BPO UI? Or what do you
> > think should be there. I would like to get as much input as
> > possible.  
> 
> For the record, as a QA person, I find this kind of squishy 'I'm
> building a thing, tell me what it should look like' question just
> impossible to answer. I cannot come up with anything until there's
> something more concrete to look at. Other QA folks may have better
> input, but it would be a good idea to send this mail to test@, since
> that is the official QA list.

Yeah, it's a bit hard when we don't know what "everything" means
here. :) 

That said a few comments: 

* Should there be a 'developer' or 'end user' type here? Ie, is it
  expected that they would want to look at this to see what the latest
  version of some module they care about is, or if there's new ones
  that might be coming along soon? Or is that another tool?

* Depending again on the kinds of things this can report on,
  infrastructure might be interested in it. Could we query it via
  nagios to let us know about problems in module building or testing ? 

* Modules can depend on other modules right? If so, a way to see that
  tree of dependencies in building would be nice (ie, moduleA depends
  on moduleB, and moduleB is currently rebuilding for foo, moduleA
  should show that it's pending rebuilding after that, etc)

I'm not sure I can provide much more until we have more information on
what information we can have there. ;) 

kevin

pgphB7AUdAo5i.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: introduction toogley | packaging intellij idea

2016-06-29 Thread toogley

> Hi Tobias,
> 
> Welcome to Fedora.

Hey and Thanks. :)

> I would recommend you joining Java SIG [1], where you can find help with
> packaging, reviews, bugfixes etc. We have IRC channel and mailing list
> where you can communicate with us.
> 
> [1] https://fedoraproject.org/wiki/SIGs/Java

Thanks also for this tip, I'll be there regularly.

> * I'm used to gpg-sign my git commits/tags by default. Should I continue this 
> practice while packaging? I've read somewhere that some people don't want 
> that, therefore my question.
> 
> We generally don't do that in Fedora.

Okay.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Gnome-shell crash with Nvidia drivers (fix available but not in Fedora 24 it seems)

2016-06-29 Thread Florian Müllner

On Tue, 28 Jun 2016, 16:50 Michael Catanzaro,  wrote:

>
> Hey Florian, it looks like a good time for another 3.20 release;
>

Yeah, I had planned another 3.20 release for a while. 3.20.3 is now pending
for testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-fb66c6e22c

>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] please review: Ticket48213 - setup-ds-admin.pl requires anonymous bind for registering with a remote config DS

2016-06-29 Thread Mark Reynolds

https://fedorahosted.org/389/ticket/48213

https://fedorahosted.org/389/attachment/ticket/48213/0001-Ticket-48213-Admin-server-registration-requires-anon.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-de...@lists.fedoraproject.org

Fedora rawhide compose report: 20160629.n.0 changes

2016-06-29 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20160628.n.0
NEW: Fedora-Rawhide-20160629.n.0

= SUMMARY =
Added images:0
Dropped images:  8
Added packages:  4
Dropped packages:0
Upgraded packages:   79
Downgraded packages: 0

Size of added packages:  5.99 MiB
Size of dropped packages:0.00 B
Size of upgraded packages:   1.15 GiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   -157.25 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Workstation live i386
Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-Rawhide-20160628.n.0.iso
Image: Robotics live i386
Path: Labs/i386/iso/Fedora-Robotics-Live-i386-Rawhide-20160628.n.0.iso
Image: Docker_Base docker armhfp
Path: Docker/armhfp/images/Fedora-Docker-Base-Rawhide-20160628.n.0.armhfp.tar.xz
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20160628.n.0.iso
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20160628.n.0.iso
Image: Workstation live x86_64
Path: 
Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20160628.n.0.iso
Image: Docker_Base docker x86_64
Path: Docker/x86_64/images/Fedora-Docker-Base-Rawhide-20160628.n.0.x86_64.tar.xz
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20160628.n.0.iso

= ADDED PACKAGES =
Package: kubernetes-ansible-0.6.0-0.1.gitd65ebd5.fc25
Summary: Playbook and set of roles for seting up a Kubernetes cluster onto 
machines
RPMs:kubernetes-ansible
Size:94674 bytes

Package: milkytracker-0.90.86-3.fc25
Summary: Module tracker software for creating music
RPMs:milkytracker
Size:2836662 bytes

Package: perl-MooX-Struct-0.013-1.fc25
Summary: Record structure-like Moo classes
RPMs:perl-MooX-Struct
Size:33754 bytes

Package: python-maxminddb-1.2.1-1.fc25
Summary: Reader for the MaxMind DB format
RPMs:python-maxminddb-doc python2-maxminddb python3-maxminddb
Size:3319290 bytes


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  arm-none-eabi-binutils-cs-1:2.26-1.fc25
Old package:  arm-none-eabi-binutils-cs-1:2.25-3.fc24
Summary:  GNU Binutils for cross-compilation for arm-none-eabi target
RPMs: arm-none-eabi-binutils-cs
Size: 6665294 bytes
Size change:  406108 bytes
Changelog:
  * Tue Jun 28 2016 Michal Hlavinka <mhlav...@redhat.com> - 1:2.26-1
  - update binutils to 2.26


Package:  arm-none-eabi-gcc-cs-1:6.1.0-1.fc25
Old package:  arm-none-eabi-gcc-cs-1:5.2.0-4.fc24
Summary:  GNU GCC for cross-compilation for arm-none-eabi target
RPMs: arm-none-eabi-gcc-cs arm-none-eabi-gcc-cs-c++
Size: 41225408 bytes
Size change:  -153112980 bytes
Changelog:
  * Tue Jun 28 2016 Michal Hlavinka <mhlav...@redhat.com> - 1:6.1.0-1
  - bootstrap build for gcc 6.1.0


Package:  audit-2.6.1-1.fc25
Old package:  audit-2.6-3.fc25
Summary:  User space tools for 2.6 kernel auditing
RPMs: audispd-plugins audispd-plugins-zos audit audit-libs 
audit-libs-devel audit-libs-python audit-libs-python3 audit-libs-static
Size: 2160872 bytes
Size change:  11728 bytes
Changelog:
  * Tue Jun 28 2016 Steve Grubb <sgr...@redhat.com> 2.6.1-1
  - New upstream bugfix release


Package:  automake-1.15-7.fc25
Old package:  automake-1.15-6.fc24
Summary:  A GNU tool for automatically creating Makefiles
RPMs: automake
Size: 710722 bytes
Size change:  -556 bytes
Changelog:
  * Tue Jun 28 2016 Pavel Raiskup <prais...@redhat.com> - 1.15-7
  - avoid using $GZIP variable during make dist, fix one dejagnu test case
(FTBFS fix, rhbz#1349381)


Package:  avr-binutils-1:2.26-1.fc25
Old package:  avr-binutils-1:2.25-3.fc24
Summary:  Cross Compiling GNU binutils targeted at avr
RPMs: avr-binutils
Size: 5538226 bytes
Size change:  300564 bytes
Changelog:
  * Tue Jun 28 2016 Michal Hlavinka <mhlav...@redhat.com> - 1:2.26-1
  - updated to 2.26


Package:  boost-1.60.0-8.fc25
Old package:  boost-1.60.0-7.fc25
Summary:  The free peer-reviewed portable C++ source libraries
RPMs: boost boost-atomic boost-build boost-chrono boost-container 
boost-context boost-coroutine boost-date-time boost-devel boost-doc 
boost-doctools boost-examples boost-filesystem boost-graph boost-graph-mpich 
boost-graph-openmpi boost-iostreams boost-jam boost-locale boost-log boost-math 
boost-mpich boost-mpich-devel boost-mpich-python boost-openmpi 
boost-openmpi-devel boost-openmpi-python boost-program-options boost-python 
boost-python3 boost-python3-devel boost-random boost-regex boost-serialization 
boost-signals boost-static boost-system boost-test boost-thread boost-timer 
boost-type_erasure boost-wave
Size: 164103844 bytes
Size change:  18256 bytes
Changelog:
  * Tue Jun 28 2016 Jonathan Wakely <jwak...@redhat.com> - 1.60.0-8
  - Add patch for Boost.Multiprecision (#1349638)


P

Broken dependencies: perl-Data-Alias

2016-06-29 Thread buildsys



perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

Broken dependencies: perl-Algorithm-Permute

2016-06-29 Thread buildsys



perl-Algorithm-Permute has broken dependencies in the rawhide tree:
On x86_64:
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
libperl.so.5.22()(64bit)
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Algorithm-Permute-0.12-21.fc24.i686 requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.i686 requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

Re: [Modularity] BPO - the great UI that shows you everything

2016-06-29 Thread Adam Williamson

On Wed, 2016-06-29 at 18:18 +0200, Adam Samalik wrote:
> Hi everyone,
> 
> I would like to hear your opinion/need your help!
> 
> I am working on a component of the Fedora Modularity[1] project, called
> Build Pipeline Overview (BPO). It will be a single user interface (probably
> both web and API) that would give you information about "everything".  And
> I would like your help with defining what that "everything" means.
> 
> To make the definition of "everything" easier, we are using a concept of
> personas. These are basically groups of people that would use the BPO UI
> that will help us to identify possible use-cases.
> 
> @threebean have identified four personas:
>  - Engineers/packagers
>  - Release Engineering
>  - QA
>  - Project Management
> 
> I have put them into an Etherpad document [2].
> 
> 
> What I'm asking from you: Could you please discuss here or in the document
> what would you like to see in the BPO UI? Or what do you think should be
> there. I would like to get as much input as possible.

For the record, as a QA person, I find this kind of squishy 'I'm
building a thing, tell me what it should look like' question just
impossible to answer. I cannot come up with anything until there's
something more concrete to look at. Other QA folks may have better
input, but it would be a good idea to send this mail to test@, since
that is the official QA list.
-- 
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
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1347880] perl-Devel-PPPort-3.35 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |25  |25
   |perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |24  |24
   |perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |22  |22
   ||perl-Devel-PPPort-3.35-1.fc
   ||23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346479] perl-Devel-PPPort-3.34 is available

2016-06-29 Thread bugzilla

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



--- Comment #16 from Fedora Update System  ---
perl-Devel-PPPort-3.35-1.fc23 has been pushed to the Fedora 23 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348010] perl-DBIx-RunSQL-0.15 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DBIx-RunSQL-0.15-1.fc2 |perl-DBIx-RunSQL-0.15-1.fc2
   |4   |4
   ||perl-DBIx-RunSQL-0.15-1.fc2
   ||3



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348010] perl-DBIx-RunSQL-0.15 is available

2016-06-29 Thread bugzilla

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



--- Comment #14 from Fedora Update System  ---
perl-DBIx-RunSQL-0.15-1.fc23 has been pushed to the Fedora 23 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1347880] perl-Devel-PPPort-3.35 is available

2016-06-29 Thread bugzilla

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



--- Comment #10 from Fedora Update System  ---
perl-Devel-PPPort-3.35-1.fc23 has been pushed to the Fedora 23 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346479] perl-Devel-PPPort-3.34 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Devel-PPPort-3.34-1.fc |perl-Devel-PPPort-3.34-1.fc
   |25  |25
   |perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |24  |24
   |perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |22  |22
   ||perl-Devel-PPPort-3.35-1.fc
   ||23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348367] perl-Module-CoreList-5.20160620 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |0620-1.fc25 |0620-1.fc25
   |perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |0620-1.fc24 |0620-1.fc24
   |perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |0620-1.fc22 |0620-1.fc22
   ||perl-Module-CoreList-5.2016
   ||0620-1.fc23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348367] perl-Module-CoreList-5.20160620 is available

2016-06-29 Thread bugzilla

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



--- Comment #14 from Fedora Update System  ---
perl-Module-CoreList-5.20160620-1.fc23 has been pushed to the Fedora 23 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1347887] perl-Getopt-Long-2.49.1 is available

2016-06-29 Thread bugzilla

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



--- Comment #10 from Fedora Update System  ---
perl-Getopt-Long-2.49.1-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346479] perl-Devel-PPPort-3.34 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Devel-PPPort-3.34-1.fc |perl-Devel-PPPort-3.34-1.fc
   |25  |25
   |perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |24  |24
   ||perl-Devel-PPPort-3.35-1.fc
   ||22



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346498] perl-Getopt-Long-2.49 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Getopt-Long-2.49-1.fc2 |perl-Getopt-Long-2.49-1.fc2
   |5   |5
   |perl-Getopt-Long-2.49-1.fc2 |perl-Getopt-Long-2.49-1.fc2
   |4   |4
   |perl-Getopt-Long-2.49-1.fc2 |perl-Getopt-Long-2.49-1.fc2
   |3   |3
   ||perl-Getopt-Long-2.49.1-1.f
   ||c22
 Resolution|--- |ERRATA
Last Closed|2016-06-18 14:29:03 |2016-06-29 13:20:17



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1347880] perl-Devel-PPPort-3.35 is available

2016-06-29 Thread bugzilla

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



--- Comment #9 from Fedora Update System  ---
perl-Devel-PPPort-3.35-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1345788] perl segmentation fault when using PerlIO Layer : locale and threads

2016-06-29 Thread bugzilla

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



--- Comment #9 from Fedora Update System  ---
perl-5.20.3-331.fc22 has been pushed to the Fedora 22 stable repository. If
problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1345788] perl segmentation fault when using PerlIO Layer : locale and threads

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-5.22.2-360.fc24|perl-5.22.2-360.fc24
   |perl-5.22.2-352.fc23|perl-5.22.2-352.fc23
   ||perl-5.20.3-331.fc22



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346498] perl-Getopt-Long-2.49 is available

2016-06-29 Thread bugzilla

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



--- Comment #15 from Fedora Update System  ---
perl-Getopt-Long-2.49.1-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1347880] perl-Devel-PPPort-3.35 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |25  |25
   |perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |24  |24
   ||perl-Devel-PPPort-3.35-1.fc
   ||22



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1347887] perl-Getopt-Long-2.49.1 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Getopt-Long-2.49.1-1.f |perl-Getopt-Long-2.49.1-1.f
   |c25 |c25
   |perl-Getopt-Long-2.49.1-1.f |perl-Getopt-Long-2.49.1-1.f
   |c24 |c24
   |perl-Getopt-Long-2.49.1-1.f |perl-Getopt-Long-2.49.1-1.f
   |c23 |c23
   ||perl-Getopt-Long-2.49.1-1.f
   ||c22



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346479] perl-Devel-PPPort-3.34 is available

2016-06-29 Thread bugzilla

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



--- Comment #15 from Fedora Update System  ---
perl-Devel-PPPort-3.35-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348367] perl-Module-CoreList-5.20160620 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |0620-1.fc25 |0620-1.fc25
   |perl-Module-CoreList-5.2016 |perl-Module-CoreList-5.2016
   |0620-1.fc24 |0620-1.fc24
   ||perl-Module-CoreList-5.2016
   ||0620-1.fc22



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348367] perl-Module-CoreList-5.20160620 is available

2016-06-29 Thread bugzilla

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



--- Comment #13 from Fedora Update System  ---
perl-Module-CoreList-5.20160620-1.fc22 has been pushed to the Fedora 22 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Modularity] BPO - the great UI that shows you everything

2016-06-29 Thread Adam Samalik

Hi everyone,

I would like to hear your opinion/need your help!

I am working on a component of the Fedora Modularity[1] project, called
Build Pipeline Overview (BPO). It will be a single user interface (probably
both web and API) that would give you information about "everything".  And
I would like your help with defining what that "everything" means.

To make the definition of "everything" easier, we are using a concept of
personas. These are basically groups of people that would use the BPO UI
that will help us to identify possible use-cases.

@threebean have identified four personas:
 - Engineers/packagers
 - Release Engineering
 - QA
 - Project Management

I have put them into an Etherpad document [2].


What I'm asking from you: Could you please discuss here or in the document
what would you like to see in the BPO UI? Or what do you think should be
there. I would like to get as much input as possible.

Thanks!
Adam


[1] https://fedoraproject.org/wiki/Modularization
[2] http://piratepad.nl/3h3lMUwld3

-- 

Adam Šamalík
---
Associate Software Engineer
Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Injecting perl-devel and perl-generators build-requires

2016-06-29 Thread Richard W.M. Jones

On Wed, Jun 29, 2016 at 01:14:00PM +, Petr Pisar wrote:
> On 2016-06-29, Kevin Kofler  wrote:
> > Petr Pisar wrote:
> >> per Build Root Without Perl Fedora 25 change
> >> , I'm
> >> ready to implement the most visible part of this change.
> >
> > That change completely fails to account for the unknown (probably very 
> > high) 
> > number of packages that run Perl scripts at any point of their build 
> > process.
> 
> Becuase it's impossible.

Actually 'auto-buildrequires' could detect this, although it would
require you to rebuild a package to find the implicit Perl dependency:

https://people.redhat.com/~rjones/auto-buildrequires/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Daniel P. Berrange

On Wed, Jun 29, 2016 at 04:54:42PM +0200, Florian Weimer wrote:
> On 06/29/2016 12:34 PM, Daniel P. Berrange wrote:
> > On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> > > On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > > > Debian handles this by having several packages [1]
> > > > 
> > > >  - qemu-user - the dynamic linked qemu user binaries
> > > >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> > > >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> > > >   rules to register them. The static binaries all
> > > >   have -static suffix on their name
> > > 
> > > Debian builds static libraries and puts them into their -dev packages.
> > > Fedora does not do this systematically.  Are all the static libraries you
> > > need actually available in Fedora?
> > 
> > Yes, everything we need exists - as mentioned its only glibc-static,
> > glib2-static, zlib-static and pcre-static that we need for this.
> 
> In this case, linking statically is indeed an option.
> 
> We currently have little tooling for static libraries.  Strictly speaking,
> all statically linked libraries have to be rebuilt even for minor glibc
> updates because we do not provide ABI compatibility for static linking
> (there are no compatibility symbols, static binaries always get the most
> recent implementation).

Yep, I understand those caveats - the flipside is that most other Linux
distros already provide statically linked qemu user emulators with glibc
without suffering unduly. So while I accept there are potential problems,
it doesn't seem like they're frequent / severe enough to make this approach
unviable.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Daniel P. Berrange

On Wed, Jun 29, 2016 at 06:45:36AM -0700, Neal Gompa wrote:
> On Wed, Jun 29, 2016 at 3:03 AM, Daniel P. Berrange  
> wrote:
> > For those who aren't familiar, QEMU actually provides two completely
> > different sets of emulators
> >
> >  - system emulators - they emulate a full virtual machine and thus run
> >a full guest OS.
> >  - user emulators - they emulate the Linux userspace ABI letting you
> >run non-native arch executables directly.
> >
> > The user emulators are what I'm concerned with in this mail, so ignore
> > the system emulators.
> >
> > Currently all the user emulators are provided in the "qemu-user" RPM
> > which also includes files in /usr/lib/binfmt.d to register each emulator
> > binary as a binary format handler for its respective architecture.
> >
> > This is ok if you have a non-native arch binary that's statically linked
> > and you just want to run it from context of your main OS root filesystem.
> > Running dynamic linked binaries won't fly because if say running an arm
> > binary on x86_64 host, it'll look for /lib/libc.so and find the i386 one,
> > instead of the arm one. You can't set LD_LIBRARY_PATH to override this
> > as the env var will apply to both qemu-arm (an x86_64 binary) and the
> > binary it is trying to run (an arm binary).
> >
> > More typical though is that you have a directory containing an fullish
> > install tree of a non-native architecture and you just want to chroot
> > into that. When doing such a chroot, the qemu-$ARCH emulator must be
> > present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
> > must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
> > So again you have the potential problem of clashing libc.so in /usr/lib
> > It is a shame Fedora doesn't have full multi-arch support, instead of
> > merely multi-lib to avoid these clashing lib dirs across architecture
> > RPMs.
> >
> > The recommended way to deal with this for the qemu user emulator binaries
> > to be statically linked, so when copied inside the non-native arch chroot,
> > they never need to resolve any native arch libraries. Fedora's qemu user
> > binaries are all dynamic linked right now.
> >
> > Debian handles this by having several packages [1]
> >
> >  - qemu-user - the dynamic linked qemu user binaries
> >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> >   rules to register them. The static binaries all
> >   have -static suffix on their name
> >
> > NB, this means qemu-binfmt and qemu-user-static are mutually exclusive
> > since they both provide the same binfmt files. You can however have both
> > qemu-user and qemu-user-static installed as their binary names won't
> > clash, and in this case the static ones will be registered as binfmts
> >
> > This nice thing about this multiple package approach is that when you
> > copied the x86_64 build of the "qemu-arm-static" binary into your arm
> > chroot, you still then have the possibility of installing the arm build
> > of the "qemu-arm" binary inside that chroot without filename clash.
> >
> > An alternative simpler approach would be to just have one package,
> > qemu-user, which contains the static binaries and never ship any
> > dynamic linked qemu user binaries. This is slightly more restrictive
> > though, as explained in the previous paragraph, so I'd like to avoid
> > doing that.
> >
> >
> > I'd like to make using non-native arch chroots simple with Fedora without
> > people needing to manually build their own static QEMU binaries, or download
> > static binaries provided by another distro[2]. So I'm suggesting to make a
> > change to Fedora qemu packages to essentially copy the way Debian has done
> > things. Specifically I will
> >
> >  - Pull the binfmt registration files out of qemu-user and into a
> >new qemu-binfmt package which depends on qemu-user.
> >
> >  - Add static builds of qemu user emulators to a new qemu-user-static
> >package, along with binfmt registration files
> >
> > The static build of QEMU user emulators is moderately light on
> > dependancies, only requiring glib2-static, pcre-static, zlib-static
> > and glibc-static packages.
> >
> > The change to introduce a qemu-binfmt package has small upgrade
> > implications since anyone with qemu-user installed today, will loose
> > the binary format rules unless they manually install qemu-binfmt. I
> > think the number of people affected is probably quite small, and some
> > of them may well wish to use qemu-user-static instead anyway.
> >
> > Obviously this would only be done in rawhide, not any existing stable
> > releases of Fedora.
> >
> > Nothing will change about the rest of QEMU packaging - ie all system
> > emulators will continue to use dynamic linking
> >
> > Regards,
> > Daniel
> >
> 
> 
> Amazingly, I've been pre-empted here. I was going to

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Florian Weimer


On 06/29/2016 12:34 PM, Daniel P. Berrange wrote:

On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:

On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:

Debian handles this by having several packages [1]

 - qemu-user - the dynamic linked qemu user binaries
 - qemu-binfmt - binfmt rules registering the dynamic linked binaries
 - qemu-user-static - the static linked qemu user binaries *and* binfmt
  rules to register them. The static binaries all
  have -static suffix on their name


Debian builds static libraries and puts them into their -dev packages.
Fedora does not do this systematically.  Are all the static libraries you
need actually available in Fedora?


Yes, everything we need exists - as mentioned its only glibc-static,
glib2-static, zlib-static and pcre-static that we need for this.


In this case, linking statically is indeed an option.

We currently have little tooling for static libraries.  Strictly 
speaking, all statically linked libraries have to be rebuilt even for 
minor glibc updates because we do not provide ABI compatibility for 
static linking (there are no compatibility symbols, static binaries 
always get the most recent implementation).



An alternative would be to bind-mount the real file system into the chroot
and run the native dynamic linker with a --library-path command line
argument that specifies the library directories in the bind mount. (It's
reasonable to specify --inhibit-cache as well.)  This would need some
adjustments in the binfmt wrapper.


The binfmt registrations are global to the OS, so the same binfmt command
needs to work whether inside or outside the chroot. So a scheme which
requires us to pass special args to make the linker looks elsewhere when
inside the chroot is not so easy. We'd have to create a wrapper program
around the real qemu user binary that decides which args to pass to the
linker, and that wrapper would then have to be statically linked


Yes, but it would be much simpler than the whole QEMU binary with its 
library dependencies.


Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Paolo Bonzini



On 29/06/2016 16:27, Simo Sorce wrote:
>> >  symlink: /usr/lib/qemu-user-root -> /
>> >  dir: /usr/lib/qemu-user-host-lib
>> >  symlink: /usr/lib/qemu-user-host-lib/libc.so -> 
>> > /usr/lib/qemu-user-root/lib/libc.so
>> > 
>> > And build qemu-$ARCH with rpath to /usr/lib/qemu-user-root/lib.
>> > 
>> > Then in the chroot you would need to bind mount the host root into
>> > /usr/lib/qemu-user-root, to override the symlink that would otherwise
>> > point back to /
> Why do you need 2 symlinks ?
> 
> I was thinking you'd have
> symlink: /usr/lib/qemu-user-lib-x86_64/ -> /usr/lib
> 
> In the chroot you just bind mount the host's /usr/lib
> as  /usr/lib/qemu-user-lib-x86_64
> 
> This assuming x86-64, you can bind mount in the appropriate arch-target
> dir on other arches.
> 

This only works if all symlinks in /usr/lib are relative.  Even then,
there are some cases where /usr/lib/foo.so symlinks to
../../lib/foo.so.1, so you'd need to:

1) bind-mount /usr/lib into /usr/lib/qemu-user-root/usr/lib

2) create a symlink /usr/lib/qemu-user-root/lib to
/usr/lib/qemu-user-root/usr/lib.

It seems a bit brittle.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Simo Sorce

On Wed, 2016-06-29 at 15:02 +0100, Daniel P. Berrange wrote:
> On Wed, Jun 29, 2016 at 09:39:11AM -0400, Simo Sorce wrote:
> > On Wed, 2016-06-29 at 11:34 +0100, Daniel P. Berrange wrote:
> > > On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> > > > On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > > > > Debian handles this by having several packages [1]
> > > > > 
> > > > >  - qemu-user - the dynamic linked qemu user binaries
> > > > >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> > > > >  - qemu-user-static - the static linked qemu user binaries *and* 
> > > > > binfmt
> > > > >   rules to register them. The static binaries all
> > > > > have -static suffix on their name
> > > > 
> > > > Debian builds static libraries and puts them into their -dev packages.
> > > > Fedora does not do this systematically.  Are all the static libraries 
> > > > you
> > > > need actually available in Fedora?
> > > 
> > > Yes, everything we need exists - as mentioned its only glibc-static,
> > > glib2-static, zlib-static and pcre-static that we need for this.
> > > 
> > > > An alternative would be to bind-mount the real file system into the 
> > > > chroot
> > > > and run the native dynamic linker with a --library-path command line
> > > > argument that specifies the library directories in the bind mount. (It's
> > > > reasonable to specify --inhibit-cache as well.)  This would need some
> > > > adjustments in the binfmt wrapper.
> > > 
> > > The binfmt registrations are global to the OS, so the same binfmt command
> > > needs to work whether inside or outside the chroot. So a scheme which
> > > requires us to pass special args to make the linker looks elsewhere when
> > > inside the chroot is not so easy. We'd have to create a wrapper program
> > > around the real qemu user binary that decides which args to pass to the
> > > linker, and that wrapper would then have to be statically linked
> > 
> > Just an idea:
> > 
> > Would it make sense to build the qemu-user binary so that it looks in a
> > different /lib directory (using rpath) like /lib/qemu-user-systemlib,
> > and then symlink into that directory the libraries it needs from the
> > host ?
> > 
> > That way if you use chroot and bind mount in that directory in the right
> > place the qemu-user binary uses different libraries from the emulated
> > binaries yet you do not have to resort to static linking.
> 
> I think you would need multiple levels of symlinking
> 
> On the host root
> 
>  symlink: /usr/lib/qemu-user-root -> /
>  dir: /usr/lib/qemu-user-host-lib
>  symlink: /usr/lib/qemu-user-host-lib/libc.so -> 
> /usr/lib/qemu-user-root/lib/libc.so
> 
> And build qemu-$ARCH with rpath to /usr/lib/qemu-user-root/lib.
> 
> Then in the chroot you would need to bind mount the host root into
> /usr/lib/qemu-user-root, to override the symlink that would otherwise
> point back to /

Why do you need 2 symlinks ?

I was thinking you'd have
symlink: /usr/lib/qemu-user-lib-x86_64/ -> /usr/lib

In the chroot you just bind mount the host's /usr/lib
as  /usr/lib/qemu-user-lib-x86_64

This assuming x86-64, you can bind mount in the appropriate arch-target
dir on other arches.

> Even if you do all that, you've now prevented installation of the
> foreign arch's qemu-user RPM inside the chroot,

See above, I think my solution would not prevent that.

>  as that will clash
> with the one you've setup from the host. Also the way you deal with
> cross-arch chroots is now different (and more complex) on Fedora, vs
> every other Linux distro which just provides a static qemu-$ARCH you
> can copy without needing to care about bind mounting extra dirs.

Yes, bind-mount is an additional step, but doesn't look like a huge
price to pay. Could even be done transparently by providing a
qemu-user.sh script that "does the right thing"

> So yes, it is probably possible, but it is not very appealing IMHO

Thought it may be neat, but if consistency with other distros is what
you are after then I would also lean to build a static binary.
It's just that linking in glibc statically is ... not great.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Daniel P. Berrange

On Wed, Jun 29, 2016 at 09:39:11AM -0400, Simo Sorce wrote:
> On Wed, 2016-06-29 at 11:34 +0100, Daniel P. Berrange wrote:
> > On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> > > On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > > > Debian handles this by having several packages [1]
> > > > 
> > > >  - qemu-user - the dynamic linked qemu user binaries
> > > >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> > > >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> > > >   rules to register them. The static binaries all
> > > >   have -static suffix on their name
> > > 
> > > Debian builds static libraries and puts them into their -dev packages.
> > > Fedora does not do this systematically.  Are all the static libraries you
> > > need actually available in Fedora?
> > 
> > Yes, everything we need exists - as mentioned its only glibc-static,
> > glib2-static, zlib-static and pcre-static that we need for this.
> > 
> > > An alternative would be to bind-mount the real file system into the chroot
> > > and run the native dynamic linker with a --library-path command line
> > > argument that specifies the library directories in the bind mount. (It's
> > > reasonable to specify --inhibit-cache as well.)  This would need some
> > > adjustments in the binfmt wrapper.
> > 
> > The binfmt registrations are global to the OS, so the same binfmt command
> > needs to work whether inside or outside the chroot. So a scheme which
> > requires us to pass special args to make the linker looks elsewhere when
> > inside the chroot is not so easy. We'd have to create a wrapper program
> > around the real qemu user binary that decides which args to pass to the
> > linker, and that wrapper would then have to be statically linked
> 
> Just an idea:
> 
> Would it make sense to build the qemu-user binary so that it looks in a
> different /lib directory (using rpath) like /lib/qemu-user-systemlib,
> and then symlink into that directory the libraries it needs from the
> host ?
> 
> That way if you use chroot and bind mount in that directory in the right
> place the qemu-user binary uses different libraries from the emulated
> binaries yet you do not have to resort to static linking.

I think you would need multiple levels of symlinking

On the host root

 symlink: /usr/lib/qemu-user-root -> /
 dir: /usr/lib/qemu-user-host-lib
 symlink: /usr/lib/qemu-user-host-lib/libc.so -> 
/usr/lib/qemu-user-root/lib/libc.so

And build qemu-$ARCH with rpath to /usr/lib/qemu-user-root/lib.

Then in the chroot you would need to bind mount the host root into
/usr/lib/qemu-user-root, to override the symlink that would otherwise
point back to /

Even if you do all that, you've now prevented installation of the
foreign arch's qemu-user RPM inside the chroot, as that will clash
with the one you've setup from the host. Also the way you deal with
cross-arch chroots is now different (and more complex) on Fedora, vs
every other Linux distro which just provides a static qemu-$ARCH you
can copy without needing to care about bind mounting extra dirs.

So yes, it is probably possible, but it is not very appealing IMHO

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ppisar changed jplesnik's 'approveacls' permission on perl-Module-Install-Copyright (master) to 'Approved'

2016-06-29 Thread notifications

ppisar changed jplesnik's 'approveacls' permission on 
perl-Module-Install-Copyright (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-Copyright/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed perl-sig's 'watchcommits' permission on perl-Module-Install-Copyright (master) to 'Approved'

2016-06-29 Thread notifications

ppisar changed perl-sig's 'watchcommits' permission on 
perl-Module-Install-Copyright (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-Copyright/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed jplesnik's 'commit' permission on perl-Module-Install-Copyright (master) to 'Approved'

2016-06-29 Thread notifications

ppisar changed jplesnik's 'commit' permission on perl-Module-Install-Copyright 
(master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-Copyright/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

ppisar changed perl-sig's 'watchbugzilla' permission on perl-Module-Install-Copyright (master) to 'Approved'

2016-06-29 Thread notifications

ppisar changed perl-sig's 'watchbugzilla' permission on 
perl-Module-Install-Copyright (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-Module-Install-Copyright/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Neal Gompa

On Wed, Jun 29, 2016 at 3:03 AM, Daniel P. Berrange  wrote:
> For those who aren't familiar, QEMU actually provides two completely
> different sets of emulators
>
>  - system emulators - they emulate a full virtual machine and thus run
>a full guest OS.
>  - user emulators - they emulate the Linux userspace ABI letting you
>run non-native arch executables directly.
>
> The user emulators are what I'm concerned with in this mail, so ignore
> the system emulators.
>
> Currently all the user emulators are provided in the "qemu-user" RPM
> which also includes files in /usr/lib/binfmt.d to register each emulator
> binary as a binary format handler for its respective architecture.
>
> This is ok if you have a non-native arch binary that's statically linked
> and you just want to run it from context of your main OS root filesystem.
> Running dynamic linked binaries won't fly because if say running an arm
> binary on x86_64 host, it'll look for /lib/libc.so and find the i386 one,
> instead of the arm one. You can't set LD_LIBRARY_PATH to override this
> as the env var will apply to both qemu-arm (an x86_64 binary) and the
> binary it is trying to run (an arm binary).
>
> More typical though is that you have a directory containing an fullish
> install tree of a non-native architecture and you just want to chroot
> into that. When doing such a chroot, the qemu-$ARCH emulator must be
> present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
> must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
> So again you have the potential problem of clashing libc.so in /usr/lib
> It is a shame Fedora doesn't have full multi-arch support, instead of
> merely multi-lib to avoid these clashing lib dirs across architecture
> RPMs.
>
> The recommended way to deal with this for the qemu user emulator binaries
> to be statically linked, so when copied inside the non-native arch chroot,
> they never need to resolve any native arch libraries. Fedora's qemu user
> binaries are all dynamic linked right now.
>
> Debian handles this by having several packages [1]
>
>  - qemu-user - the dynamic linked qemu user binaries
>  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
>  - qemu-user-static - the static linked qemu user binaries *and* binfmt
>   rules to register them. The static binaries all
>   have -static suffix on their name
>
> NB, this means qemu-binfmt and qemu-user-static are mutually exclusive
> since they both provide the same binfmt files. You can however have both
> qemu-user and qemu-user-static installed as their binary names won't
> clash, and in this case the static ones will be registered as binfmts
>
> This nice thing about this multiple package approach is that when you
> copied the x86_64 build of the "qemu-arm-static" binary into your arm
> chroot, you still then have the possibility of installing the arm build
> of the "qemu-arm" binary inside that chroot without filename clash.
>
> An alternative simpler approach would be to just have one package,
> qemu-user, which contains the static binaries and never ship any
> dynamic linked qemu user binaries. This is slightly more restrictive
> though, as explained in the previous paragraph, so I'd like to avoid
> doing that.
>
>
> I'd like to make using non-native arch chroots simple with Fedora without
> people needing to manually build their own static QEMU binaries, or download
> static binaries provided by another distro[2]. So I'm suggesting to make a
> change to Fedora qemu packages to essentially copy the way Debian has done
> things. Specifically I will
>
>  - Pull the binfmt registration files out of qemu-user and into a
>new qemu-binfmt package which depends on qemu-user.
>
>  - Add static builds of qemu user emulators to a new qemu-user-static
>package, along with binfmt registration files
>
> The static build of QEMU user emulators is moderately light on
> dependancies, only requiring glib2-static, pcre-static, zlib-static
> and glibc-static packages.
>
> The change to introduce a qemu-binfmt package has small upgrade
> implications since anyone with qemu-user installed today, will loose
> the binary format rules unless they manually install qemu-binfmt. I
> think the number of people affected is probably quite small, and some
> of them may well wish to use qemu-user-static instead anyway.
>
> Obviously this would only be done in rawhide, not any existing stable
> releases of Fedora.
>
> Nothing will change about the rest of QEMU packaging - ie all system
> emulators will continue to use dynamic linking
>
> Regards,
> Daniel
>


Amazingly, I've been pre-empted here. I was going to ask about this
for Fedora, since we've got interest in this for Mageia as part of
potentially enabling cross-arch building with mock in an easy fashion.

Mageia tries to keep its QEMU package in sync with Fedora, so I'd love
to see this happen so that it

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Simo Sorce

On Wed, 2016-06-29 at 11:34 +0100, Daniel P. Berrange wrote:
> On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> > On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > > Debian handles this by having several packages [1]
> > > 
> > >  - qemu-user - the dynamic linked qemu user binaries
> > >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> > >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> > >   rules to register them. The static binaries all
> > > have -static suffix on their name
> > 
> > Debian builds static libraries and puts them into their -dev packages.
> > Fedora does not do this systematically.  Are all the static libraries you
> > need actually available in Fedora?
> 
> Yes, everything we need exists - as mentioned its only glibc-static,
> glib2-static, zlib-static and pcre-static that we need for this.
> 
> > An alternative would be to bind-mount the real file system into the chroot
> > and run the native dynamic linker with a --library-path command line
> > argument that specifies the library directories in the bind mount. (It's
> > reasonable to specify --inhibit-cache as well.)  This would need some
> > adjustments in the binfmt wrapper.
> 
> The binfmt registrations are global to the OS, so the same binfmt command
> needs to work whether inside or outside the chroot. So a scheme which
> requires us to pass special args to make the linker looks elsewhere when
> inside the chroot is not so easy. We'd have to create a wrapper program
> around the real qemu user binary that decides which args to pass to the
> linker, and that wrapper would then have to be statically linked

Just an idea:

Would it make sense to build the qemu-user binary so that it looks in a
different /lib directory (using rpath) like /lib/qemu-user-systemlib,
and then symlink into that directory the libraries it needs from the
host ?

That way if you use chroot and bind mount in that directory in the right
place the qemu-user binary uses different libraries from the emulated
binaries yet you do not have to resort to static linking.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jplesnik pushed to perl-generators (f22). "Fixed regression in parsing of heredoc"

2016-06-29 Thread notifications

From 54bdcfb29fad033f2c3a7f7e79529d0fd1fb816e Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 29 Jun 2016 15:28:24 +0200
Subject: Fixed regression in parsing of heredoc

---
 ...1.06-Fix-regression-in-parsing-of-heredoc.patch | 96 ++
 perl-generators.spec   |  7 +-
 2 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 generators-1.06-Fix-regression-in-parsing-of-heredoc.patch

diff --git a/generators-1.06-Fix-regression-in-parsing-of-heredoc.patch 
b/generators-1.06-Fix-regression-in-parsing-of-heredoc.patch
new file mode 100644
index 000..369dd1b
--- /dev/null
+++ b/generators-1.06-Fix-regression-in-parsing-of-heredoc.patch
@@ -0,0 +1,96 @@
+diff -up generators-1.06/bin/perl.prov.orig generators-1.06/bin/perl.prov
+--- generators-1.06/bin/perl.prov.orig 2016-06-24 12:46:20.436213565 +0200
 generators-1.06/bin/perl.prov  2016-06-24 12:49:11.354484313 +0200
+@@ -74,13 +74,14 @@ sub process_file {
+ 
+ # skip the here-docs "<<" blocks
+ # assume that <<12 means bitwise operation
+-if (((m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?([^"'#<@])<<(\w+)\s*/ &&
+-  ($2 !~ m/^\d+$/)) ||
+- 
m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?[^"'#<@]<<\s*(["'`])(.+?|)\1\s*/
++if (((m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?[^"'#<@]<<[\\]?(\w+)\s*/ &&
++  ($1 !~ m/^\d+$/)) ||
++ 
m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?[^"'#<@]<<\s*('[^']*?'|"[^"]*?"|`[^`]*?`)\s*/
+ ) &&
+  ! m/q[qxwr]?\s*[{([#|!\/][^})\]#|!\/]*?<<[^<]/
+) {
+-  $tag = $2;
++  $tag = $1;
++  $tag =~ s/['"`]//g;
+   while () {
+ chomp;
+ ( $_ eq $tag ) && last;
+diff -up generators-1.06/bin/perl.req.orig generators-1.06/bin/perl.req
+--- generators-1.06/bin/perl.req.orig  2016-06-24 12:46:34.260154583 +0200
 generators-1.06/bin/perl.req   2016-06-24 12:51:45.703825754 +0200
+@@ -93,13 +93,14 @@ sub process_file {
+ 
+ # skip the here-docs "<<" blocks
+ # assume that <<12 means bitwise operation
+-if (((m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?([^"'#<@])<<(\w+)\s*/ &&
+-  ($2 !~ m/^\d+$/)) ||
+- 
m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?[^"'#<@]<<\s*(["'`])(.+?|)\1\s*/
++if (((m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?[^"'#<@]<<[\\]?(\w+)\s*/ &&
++  ($1 !~ m/^\d+$/)) ||
++ 
m/^\s*(?:'[^']*?'|"[^"]*?"|[^"'#]*?)*?[^"'#<@]<<\s*('[^']*?'|"[^"]*?"|`[^`]*?`)\s*/
+ ) &&
+  ! m/q[qxwr]?\s*[{([#|!\/][^})\]#|!\/]*?<<[^<]/
+) {
+-  $tag = $2;
++  $tag = $1;
++  $tag =~ s/['"`]//g;
+   if ($_ =~ m/^\s*use\s(constant)\s/) { add_require($1, undef) }
+   while () {
+ chomp;
+@@ -151,8 +152,8 @@ sub process_file {
+ }
+ 
+ my $modver_re = qr/[.0-9]+/;
+-my $begin_re = qr#qw\s*[(\/'"!|{]\s*|qq?\s*[(\/'"!|{]\s*|['"]#;
+-my $end_re   = qr#[)\/"'!|}]#;
++my $begin_re = qr#qw\s*[(\/'"!|{\[]\s*|qq?\s*[(\/'"!|{\[]\s*|['"]#;
++my $end_re   = qr#[)\/"'!|}\]]#;
+ 
+ # Skip multiline print and assign statements
+ if ( m/\$\S+\s*=\s*(")([^"\\]|(\\.))*$/ ||
+diff -up generators-1.06/t/08_heredoc.t.orig generators-1.06/t/08_heredoc.t
+--- generators-1.06/t/08_heredoc.t.orig2016-06-24 13:00:05.409693671 
+0200
 generators-1.06/t/08_heredoc.t 2016-06-24 13:01:11.742410289 +0200
+@@ -22,6 +22,7 @@ my @expectedrequires = (
+ "perl(Bitwise::Operator)\n",
+ "perl(constant)\n",
+ "perl(More::Then::Two::Mark)\n",
++"perl(Not::Hang)\n",
+ "perl(Not::In::Heredoc)\n",
+ "perl(THAT)\n",
+ );
+diff -up generators-1.06/t/data/heredoc.orig generators-1.06/t/data/heredoc
+--- generators-1.06/t/data/heredoc.orig2016-06-24 12:59:52.745747704 
+0200
 generators-1.06/t/data/heredoc 2016-06-24 13:00:49.219506749 +0200
+@@ -150,6 +150,26 @@ package Number::As::Tag;
+ use Number::As::Tag;
+ 1234
+ 
++$cost = <<\VISTA;   # Same thing!
++ That'll be $10 please, ma'am.
++package Vista
++use Vista
++VISTA
++
++s/this/ - 1.06-2
+- Fixed regression in parsing of heredoc
+
 * Tue Oct 06 2015 Jitka Plesnikova  - 1.06-1
 - 1.06 bump
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-generators.git/commit/?h=f22=54bdcfb29fad033f2c3a7f7e79529d0fd1fb816e
--
Fedora Extras Perl SIG

[Bug 1351172] perl.req gets exponentially slow in a certain scenario

2016-06-29 Thread bugzilla

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



--- Comment #1 from Fedora Update System  ---
perl-generators-1.06-2.fc22 has been submitted as an update to Fedora 22.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-c345d41682

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1351172] perl.req gets exponentially slow in a certain scenario

2016-06-29 Thread bugzilla

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-generators-1.09-1.fc25
   ||perl-generators-1.09-1.fc24
   ||perl-generators-1.06-2.fc23



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Injecting perl-devel and perl-generators build-requires

2016-06-29 Thread Petr Pisar

On 2016-06-29, Jeff Fearn  wrote:
> I would like the perl team to consider taking this opportunity to remove
> non-standard behavior instead of adding more. The whole perl/perl-devel
> split was to make the install smaller, mostly for build root reasons.
> Since that is no longer a consideration can we make it so that requiring
> perl gets you a proper perl core installed?
>
> That should stop most breakage as anyone using none core stuff should
> have had it specifically required anyway.
>
What applies to any Fedora package, applies to Perl packages too.

For example we have about 2800 Perl packages, but only 493 are
architecture specific that must depend on perl-devel and GCC. (I know
the number because two months ago I accidentally removed perl-devel.)

So no, I do not consider making the core modules somewhat special. Perl
would have fallen into the same mud where Python or TeX Live is now.

-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Injecting perl-devel and perl-generators build-requires

2016-06-29 Thread Sérgio Basto

On Qua, 2016-06-29 at 16:01 +1000, Jeff Fearn wrote:
> On 29/06/16 12:08, Kevin Kofler wrote:
> > 
> > Petr Pisar wrote:
> > > 
> > > per Build Root Without Perl Fedora 25 change
> > > ,
> > > I'm
> > > ready to implement the most visible part of this change.
> > That change completely fails to account for the unknown (probably
> > very high) 
> > number of packages that run Perl scripts at any point of their
> > build 
> > process. All the steps you documented to detect affected packages
> > catch only 
> > packages that actually have Perl-related output (because you scan
> > the 
> > RUNTIME dependencies for Perl module or libperl dependencies),
> > which are 
> > only the tip of the iceberg. I expect this change to break a huge
> > number of 
> > packages' build in very strange, hard to debug ways. It is likely
> > that some 
> > will even silently build with some important functionality removed,
> > because 
> > Perl was not available to build some generated file or test for
> > some system 
> > properties.
> > 
> > I also expect that a very high percentage of the packages will need
> > a BR 
> > perl (if not perl-generators or even perl-devel), making any
> > buildroot size 
> > savings moot, and actually SLOWING DOWN mock builds because perl
> > will no 
> > longer be included in the root cache.
> > 
> > IMHO, any approval you obtained for this feature needs to be
> > revisited, 
> > because you failed to accurately describe the impact.
> Good analysis.

I do not agree with you , because running a perl command without perl
installed, ends with and big error and stops the build , can remember
any example that silent fail . 

> I would like the perl team to consider taking this opportunity to
> remove
> non-standard behavior instead of adding more. The whole perl/perl-
> devel
> split was to make the install smaller, mostly for build root reasons.
> Since that is no longer a consideration can we make it so that
> requiring
> perl gets you a proper perl core installed?
> 
> That should stop most breakage as anyone using none core stuff should
> have had it specifically required anyway.
> 
> Cheers, Jeff.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Injecting perl-devel and perl-generators build-requires

2016-06-29 Thread Petr Pisar

On 2016-06-29, Kevin Kofler  wrote:
> Petr Pisar wrote:
>> per Build Root Without Perl Fedora 25 change
>> , I'm
>> ready to implement the most visible part of this change.
>
> That change completely fails to account for the unknown (probably very high) 
> number of packages that run Perl scripts at any point of their build 
> process.

Becuase it's impossible. At the and requiremnt to specify all build-time
dependencies has already existed before this removal attempt. So if it's
first time their maintainers responsibility. But I believe there will
not be more than few hunders of failures because of this.

> All the steps you documented to detect affected packages catch only 
> packages that actually have Perl-related output (because you scan the 
> RUNTIME dependencies for Perl module or libperl dependencies), which are 
> only the tip of the iceberg. I expect this change to break a huge number of 
> packages' build in very strange, hard to debug ways. It is likely that some 
> will even silently build with some important functionality removed, because 
> Perl was not available to build some generated file or test for some system 
> properties.
>
> I also expect that a very high percentage of the packages will need a BR 
> perl (if not perl-generators or even perl-devel), making any buildroot size 
> savings moot, and actually SLOWING DOWN mock builds because perl will no 
> longer be included in the root cache.
>
> IMHO, any approval you obtained for this feature needs to be revisited, 
> because you failed to accurately describe the impact.
>
Yes, it's one big IMHO. Would be great if you back "the unknown number",
"probably very high", "the tip of the iceberg", "huge number", "very
high percentage" with real numbers.  Otherwise it's only your
impression.

In my opinion, the amount of packages that build-require perl
transitively is less than half, so the net result will be a speed-up.

We could download root.logs from Koji and grep them for "Package
perl-4:\S* is already installed, skipping". That should provide some
data.

But I don't have direct access to Koji storage. Downloading them would
be too slow. I think I can ack Copr people to do it in Copr. It's not
Koji, but it could have representative data.

-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1347880] perl-Devel-PPPort-3.35 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Devel-PPPort-3.35-1.fc |perl-Devel-PPPort-3.35-1.fc
   |25  |25
   ||perl-Devel-PPPort-3.35-1.fc
   ||24
 Resolution|--- |ERRATA
Last Closed||2016-06-29 08:56:47



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346479] perl-Devel-PPPort-3.34 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Devel-PPPort-3.34-1.fc |perl-Devel-PPPort-3.34-1.fc
   |25  |25
   ||perl-Devel-PPPort-3.35-1.fc
   ||24
 Resolution|--- |ERRATA
Last Closed||2016-06-29 08:56:50



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1347880] perl-Devel-PPPort-3.35 is available

2016-06-29 Thread bugzilla

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



--- Comment #8 from Fedora Update System  ---
perl-Devel-PPPort-3.35-1.fc24 has been pushed to the Fedora 24 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346766] amavisd-new selinux policies prevent it running

2016-06-29 Thread bugzilla

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



--- Comment #7 from Fedora Update System  ---
amavisd-new-2.11.0-2.fc24 has been pushed to the Fedora 24 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346479] perl-Devel-PPPort-3.34 is available

2016-06-29 Thread bugzilla

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



--- Comment #14 from Fedora Update System  ---
perl-Devel-PPPort-3.35-1.fc24 has been pushed to the Fedora 24 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1330781] amavisd-new-2.11.0 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||amavisd-new-2.11.0-2.fc24
 Resolution|--- |ERRATA
Last Closed||2016-06-29 08:56:00



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348353] perl-CPAN-Perl-Releases-2.80 is available

2016-06-29 Thread bugzilla

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



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-2.80-1.fc24 has been pushed to the Fedora 24 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348010] perl-DBIx-RunSQL-0.15 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-DBIx-RunSQL-0.15-1.fc2
   ||4
 Resolution|--- |ERRATA
Last Closed||2016-06-29 08:56:05



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348010] perl-DBIx-RunSQL-0.15 is available

2016-06-29 Thread bugzilla

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



--- Comment #13 from Fedora Update System  ---
perl-DBIx-RunSQL-0.15-1.fc24 has been pushed to the Fedora 24 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1346766] amavisd-new selinux policies prevent it running

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2016-06-29 08:55:56



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1330781] amavisd-new-2.11.0 is available

2016-06-29 Thread bugzilla

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



--- Comment #9 from Fedora Update System  ---
amavisd-new-2.11.0-2.fc24 has been pushed to the Fedora 24 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1348353] perl-CPAN-Perl-Releases-2.80 is available

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-2.8 |perl-CPAN-Perl-Releases-2.8
   |0-1.fc25|0-1.fc25
   ||perl-CPAN-Perl-Releases-2.8
   ||0-1.fc24
 Resolution|--- |ERRATA
Last Closed||2016-06-29 08:55:40



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1337904] Upgrade perl-Net-CLI-Interact to 2.200005

2016-06-29 Thread bugzilla

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



--- Comment #3 from Fedora Update System  ---
perl-Net-CLI-Interact-2.25-1.fc24 has been pushed to the Fedora 24 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1337892] Upgrade perl-Net-Appliance-Session to 4.200002

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Net-Appliance-Session- |perl-Net-Appliance-Session-
   |4.22-1.fc25 |4.22-1.fc25
   ||perl-Net-Appliance-Session-
   ||4.22-1.fc24
 Resolution|--- |ERRATA
Last Closed||2016-06-29 08:54:45



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1337904] Upgrade perl-Net-CLI-Interact to 2.200005

2016-06-29 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Net-CLI-Interact-2.200 |perl-Net-CLI-Interact-2.200
   |005-1.fc25  |005-1.fc25
   ||perl-Net-CLI-Interact-2.200
   ||005-1.fc24
 Resolution|--- |ERRATA
Last Closed|2016-06-21 08:24:24 |2016-06-29 08:54:50



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1337892] Upgrade perl-Net-Appliance-Session to 4.200002

2016-06-29 Thread bugzilla

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



--- Comment #3 from Fedora Update System  ---
perl-Net-Appliance-Session-4.22-1.fc24 has been pushed to the Fedora 24
stable repository. If problems still persist, please make note of it in this
bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1351172] New: perl.req gets exponentially slow in a certain scenario

2016-06-29 Thread bugzilla

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

Bug ID: 1351172
   Summary: perl.req gets exponentially slow in a certain scenario
   Product: Fedora
   Version: 22
 Component: perl-generators
  Assignee: jples...@redhat.com
  Reporter: rel...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Description of problem:

The problem is perhaps best described by showing examples (see below) but given
certain input, perl.req gets really, really slow. This came up when I went to
upgrade the `cloc` package and `rpmbuild` seemingly got stuck and never
finished. I dug into it a tiny bit and got a smaller reproducer (again, see
below).

When I add letters to the variable name here perl.req gets *really* slow:

$ cat asdf
sub demo {
  ++$foo if  /\s*<<'/;
}


$ time /usr/lib/rpm/perl.req asdf
real0m0.361s
user0m0.358s
sys0m0.003s

--

$ cat asdf
sub demo {
  ++$foobar if  /\s*<<'/;
}


$ time /usr/lib/rpm/perl.req asdf
real0m2.891s
user0m2.884s
sys0m0.003s

--

$ cat asdf
sub demo {
  ++$foobarbaz if  /\s*<<'/;
}


$ time /usr/lib/rpm/perl.req asdf
real0m23.902s
user0m23.835s
sys0m0.019s


Version-Release number of selected component (if applicable):
perl-generators-1.06-1.fc22.noarch

How reproducible:
I haven't tested on newer Fedora. I'm planning on upgrading to F23 or F24 this
week, will be able to report then.


Steps to Reproduce:
1. Copypaste the above examples into a file
2. Run `/usr/lib/rpm/perl.req the_file`
3. ???
4. Profit

Actual results:
perl.req becomes very slow


Expected results:
perl.req doesn't become very slow. ;)

Additional info:
Happy to provide any other information, just let me know what you need.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Injecting perl-devel and perl-generators build-requires

2016-06-29 Thread Mikolaj Izdebski

On 06/23/2016 03:09 PM, Petr Pisar wrote:
> Hello,
> 
> per Build Root Without Perl Fedora 25 change
> , I'm ready to
> implement the most visible part of this change.

Good to to hear that. I've been using Perl-less buildroot in my personal
mock config on daily basis for two years, no problems found.

> I'm going to inject perl-devel and perl-generators build-requires into Fedora
> specification files tomorrow. That's necessary not to break building the
> packages when Perl will have been removed from the build root.

Note that once perl-generators are removed from minimal bulidroot, Perl
packages will start to fail in Koschei. This is because Koschei rebuilds
package from latest SRPM, not from SCM.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: fedora-packager installs yum

2016-06-29 Thread Raphael Groner

There's a controversial ongoing discussion. f-e-k needs a port to Python 3.

https://bugzilla.redhat.com/show_bug.cgi?id=1329629
https://bugzilla.redhat.com/show_bug.cgi?id=1024796
https://bugzilla.redhat.com/show_bug.cgi?id=1270600
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Daniel P. Berrange

On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > Debian handles this by having several packages [1]
> > 
> >  - qemu-user - the dynamic linked qemu user binaries
> >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> >   rules to register them. The static binaries all
> >   have -static suffix on their name
> 
> Debian builds static libraries and puts them into their -dev packages.
> Fedora does not do this systematically.  Are all the static libraries you
> need actually available in Fedora?

Yes, everything we need exists - as mentioned its only glibc-static,
glib2-static, zlib-static and pcre-static that we need for this.

> An alternative would be to bind-mount the real file system into the chroot
> and run the native dynamic linker with a --library-path command line
> argument that specifies the library directories in the bind mount. (It's
> reasonable to specify --inhibit-cache as well.)  This would need some
> adjustments in the binfmt wrapper.

The binfmt registrations are global to the OS, so the same binfmt command
needs to work whether inside or outside the chroot. So a scheme which
requires us to pass special args to make the linker looks elsewhere when
inside the chroot is not so easy. We'd have to create a wrapper program
around the real qemu user binary that decides which args to pass to the
linker, and that wrapper would then have to be statically linked

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Florian Weimer


On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:

Debian handles this by having several packages [1]

 - qemu-user - the dynamic linked qemu user binaries
 - qemu-binfmt - binfmt rules registering the dynamic linked binaries
 - qemu-user-static - the static linked qemu user binaries *and* binfmt
  rules to register them. The static binaries all
  have -static suffix on their name


Debian builds static libraries and puts them into their -dev packages. 
Fedora does not do this systematically.  Are all the static libraries 
you need actually available in Fedora?


An alternative would be to bind-mount the real file system into the 
chroot and run the native dynamic linker with a --library-path command 
line argument that specifies the library directories in the bind mount. 
(It's reasonable to specify --inhibit-cache as well.)  This would need 
some adjustments in the binfmt wrapper.


Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Automatic ABI checks for new package updates in bodhi using taskotron

2016-06-29 Thread Dodji Seketeli

Kamil Paral  a écrit:

> Thanks, I reported an RFE about this:
> https://phab.qadevel.cloud.fedoraproject.org/T811

Thanks Kamil,

Unfortunately, I still cannot log into
https://phab.qadevel.cloud.fedoraproject.org/T811 using my
do...@fedoraproject.org persona, so I cannot comment on the issue.  When
I try to log in there, I am getting this error:

[HTTP/500] Internal Server Error Internal Server Error

But I can log into the Fedora infrastracture just fine, in general.
It's just the https://phab.qadevel.cloud.fedoraproject.org/T811 thingy
that I am having issue with.  I am not sure what I am doing wrong. 

I wish all the tickets handling gets migrated to pagure.io one day :-)

Cheers,

-- 
Dodji
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-29 Thread Daniel P. Berrange

For those who aren't familiar, QEMU actually provides two completely
different sets of emulators

 - system emulators - they emulate a full virtual machine and thus run
   a full guest OS.
 - user emulators - they emulate the Linux userspace ABI letting you
   run non-native arch executables directly.

The user emulators are what I'm concerned with in this mail, so ignore
the system emulators.

Currently all the user emulators are provided in the "qemu-user" RPM
which also includes files in /usr/lib/binfmt.d to register each emulator
binary as a binary format handler for its respective architecture.

This is ok if you have a non-native arch binary that's statically linked
and you just want to run it from context of your main OS root filesystem.
Running dynamic linked binaries won't fly because if say running an arm
binary on x86_64 host, it'll look for /lib/libc.so and find the i386 one,
instead of the arm one. You can't set LD_LIBRARY_PATH to override this
as the env var will apply to both qemu-arm (an x86_64 binary) and the
binary it is trying to run (an arm binary).

More typical though is that you have a directory containing an fullish
install tree of a non-native architecture and you just want to chroot
into that. When doing such a chroot, the qemu-$ARCH emulator must be
present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
So again you have the potential problem of clashing libc.so in /usr/lib
It is a shame Fedora doesn't have full multi-arch support, instead of
merely multi-lib to avoid these clashing lib dirs across architecture
RPMs.

The recommended way to deal with this for the qemu user emulator binaries
to be statically linked, so when copied inside the non-native arch chroot,
they never need to resolve any native arch libraries. Fedora's qemu user
binaries are all dynamic linked right now.

Debian handles this by having several packages [1]

 - qemu-user - the dynamic linked qemu user binaries
 - qemu-binfmt - binfmt rules registering the dynamic linked binaries
 - qemu-user-static - the static linked qemu user binaries *and* binfmt
  rules to register them. The static binaries all
  have -static suffix on their name

NB, this means qemu-binfmt and qemu-user-static are mutually exclusive
since they both provide the same binfmt files. You can however have both
qemu-user and qemu-user-static installed as their binary names won't
clash, and in this case the static ones will be registered as binfmts

This nice thing about this multiple package approach is that when you
copied the x86_64 build of the "qemu-arm-static" binary into your arm
chroot, you still then have the possibility of installing the arm build
of the "qemu-arm" binary inside that chroot without filename clash.

An alternative simpler approach would be to just have one package,
qemu-user, which contains the static binaries and never ship any
dynamic linked qemu user binaries. This is slightly more restrictive
though, as explained in the previous paragraph, so I'd like to avoid
doing that.


I'd like to make using non-native arch chroots simple with Fedora without
people needing to manually build their own static QEMU binaries, or download
static binaries provided by another distro[2]. So I'm suggesting to make a
change to Fedora qemu packages to essentially copy the way Debian has done
things. Specifically I will

 - Pull the binfmt registration files out of qemu-user and into a
   new qemu-binfmt package which depends on qemu-user.

 - Add static builds of qemu user emulators to a new qemu-user-static
   package, along with binfmt registration files

The static build of QEMU user emulators is moderately light on
dependancies, only requiring glib2-static, pcre-static, zlib-static
and glibc-static packages.

The change to introduce a qemu-binfmt package has small upgrade
implications since anyone with qemu-user installed today, will loose
the binary format rules unless they manually install qemu-binfmt. I
think the number of people affected is probably quite small, and some
of them may well wish to use qemu-user-static instead anyway.

Obviously this would only be done in rawhide, not any existing stable
releases of Fedora.

Nothing will change about the rest of QEMU packaging - ie all system
emulators will continue to use dynamic linking

Regards,
Daniel

[1] https://wiki.debian.org/QemuUserEmulation
[2] 
https://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-binaries-on-an-x86-64-host-using-qemu-userspace-emulation/
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org

pghmcfc pushed to perl-Parse-CPAN-Meta (perl-Parse-CPAN-Meta-1.4421-1.fc25). "Update to 1.4421 (..more)"

2016-06-29 Thread notifications

From 26448209d04f513bb68a1d3bdfb3a6d0d9ef38ed Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Wed, 29 Jun 2016 10:36:46 +0100
Subject: Update to 1.4421

- New upstream release 1.4421
  - Add CPAN_META_JSON_BACKEND to allow requesting non-JSON.pm backends
  - Add CPAN_META_JSON_DECODER to allow Mojo::JSON/JSON::Tiny to be used just
for decoding
  - Re-encode strings before decode_json since that expects bytes
  - Add test cases for wide characters in META files
  - Bump JSON::PP prerequisite to 2.27300 to work around a bug before perl
5.8.7; includes a test to confirm correct behavior
- BR: perl-generators
- Simplify find command using -delete
---
 perl-Parse-CPAN-Meta.spec | 26 +-
 sources   |  2 +-
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/perl-Parse-CPAN-Meta.spec b/perl-Parse-CPAN-Meta.spec
index 1dbd377..afaab13 100644
--- a/perl-Parse-CPAN-Meta.spec
+++ b/perl-Parse-CPAN-Meta.spec
@@ -1,8 +1,8 @@
 Name:   perl-Parse-CPAN-Meta
 # dual-lifed module needs to match the epoch in perl.spec
 Epoch:  1
-Version:1.4417
-Release:366%{?dist}
+Version:1.4421
+Release:1%{?dist}
 Summary:Parse META.yml and META.json CPAN meta-data files
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,6 +10,9 @@ URL:http://search.cpan.org/dist/Parse-CPAN-Meta/
 Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Parse-CPAN-Meta-%{version}.tar.gz
 BuildArch:  noarch
 # Module Build
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -19,13 +22,14 @@ BuildRequires:  perl(Carp)
 BuildRequires:  perl(CPAN::Meta::YAML) >= 0.011
 BuildRequires:  perl(Encode)
 BuildRequires:  perl(Exporter)
-BuildRequires:  perl(JSON::PP) >= 2.27200
+BuildRequires:  perl(JSON::PP) >= 2.27300
 BuildRequires:  perl(strict)
 # Test Suite
 BuildRequires:  perl(File::Spec) >= 0.80
 BuildRequires:  perl(File::Spec::Functions)
 BuildRequires:  perl(lib)
 BuildRequires:  perl(Test::More) >= 0.82
+BuildRequires:  perl(utf8)
 BuildRequires:  perl(vars)
 BuildRequires:  perl(YAML)
 # Optional Tests
@@ -41,7 +45,7 @@ BuildRequires:  perl(JSON) >= 2.5
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   perl(CPAN::Meta::YAML) >= 0.011
 Requires:   perl(Encode)
-Requires:   perl(JSON::PP) >= 2.27200
+Requires:   perl(JSON::PP) >= 2.27300
 
 %description
 Parse::CPAN::Meta is a parser for META.json and META.yml files, using JSON::PP
@@ -64,7 +68,7 @@ make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot} UNINST=0
-find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name .packlist -delete
 %{_fixperms} %{buildroot}
 
 %check
@@ -77,6 +81,18 @@ make test
 %{_mandir}/man3/Parse::CPAN::Meta.3*
 
 %changelog
+* Wed Jun 29 2016 Paul Howarth  - 1:1.4421-1
+- Update to 1.4421
+  - Add CPAN_META_JSON_BACKEND to allow requesting non-JSON.pm backends
+  - Add CPAN_META_JSON_DECODER to allow Mojo::JSON/JSON::Tiny to be used just
+for decoding
+  - Re-encode strings before decode_json since that expects bytes
+  - Add test cases for wide characters in META files
+  - Bump JSON::PP prerequisite to 2.27300 to work around a bug before perl
+5.8.7; includes a test to confirm correct behavior
+- BR: perl-generators
+- Simplify find command using -delete
+
 * Wed May 18 2016 Jitka Plesnikova  - 1:1.4417-366
 - Perl 5.24 re-rebuild of bootstrapped packages
 
diff --git a/sources b/sources
index f479dc4..98eb4df 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b4f36533cba9ec56bef6f3797b7f4d84  Parse-CPAN-Meta-1.4417.tar.gz
+68af202068e42f42795e0750f0e97490  Parse-CPAN-Meta-1.4421.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Parse-CPAN-Meta.git/commit/?h=perl-Parse-CPAN-Meta-1.4421-1.fc25=26448209d04f513bb68a1d3bdfb3a6d0d9ef38ed
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc pushed to perl-Parse-CPAN-Meta (master). "Update to 1.4421 (..more)"

2016-06-29 Thread notifications

From 26448209d04f513bb68a1d3bdfb3a6d0d9ef38ed Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Wed, 29 Jun 2016 10:36:46 +0100
Subject: Update to 1.4421

- New upstream release 1.4421
  - Add CPAN_META_JSON_BACKEND to allow requesting non-JSON.pm backends
  - Add CPAN_META_JSON_DECODER to allow Mojo::JSON/JSON::Tiny to be used just
for decoding
  - Re-encode strings before decode_json since that expects bytes
  - Add test cases for wide characters in META files
  - Bump JSON::PP prerequisite to 2.27300 to work around a bug before perl
5.8.7; includes a test to confirm correct behavior
- BR: perl-generators
- Simplify find command using -delete
---
 perl-Parse-CPAN-Meta.spec | 26 +-
 sources   |  2 +-
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/perl-Parse-CPAN-Meta.spec b/perl-Parse-CPAN-Meta.spec
index 1dbd377..afaab13 100644
--- a/perl-Parse-CPAN-Meta.spec
+++ b/perl-Parse-CPAN-Meta.spec
@@ -1,8 +1,8 @@
 Name:   perl-Parse-CPAN-Meta
 # dual-lifed module needs to match the epoch in perl.spec
 Epoch:  1
-Version:1.4417
-Release:366%{?dist}
+Version:1.4421
+Release:1%{?dist}
 Summary:Parse META.yml and META.json CPAN meta-data files
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,6 +10,9 @@ URL:http://search.cpan.org/dist/Parse-CPAN-Meta/
 Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Parse-CPAN-Meta-%{version}.tar.gz
 BuildArch:  noarch
 # Module Build
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -19,13 +22,14 @@ BuildRequires:  perl(Carp)
 BuildRequires:  perl(CPAN::Meta::YAML) >= 0.011
 BuildRequires:  perl(Encode)
 BuildRequires:  perl(Exporter)
-BuildRequires:  perl(JSON::PP) >= 2.27200
+BuildRequires:  perl(JSON::PP) >= 2.27300
 BuildRequires:  perl(strict)
 # Test Suite
 BuildRequires:  perl(File::Spec) >= 0.80
 BuildRequires:  perl(File::Spec::Functions)
 BuildRequires:  perl(lib)
 BuildRequires:  perl(Test::More) >= 0.82
+BuildRequires:  perl(utf8)
 BuildRequires:  perl(vars)
 BuildRequires:  perl(YAML)
 # Optional Tests
@@ -41,7 +45,7 @@ BuildRequires:  perl(JSON) >= 2.5
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   perl(CPAN::Meta::YAML) >= 0.011
 Requires:   perl(Encode)
-Requires:   perl(JSON::PP) >= 2.27200
+Requires:   perl(JSON::PP) >= 2.27300
 
 %description
 Parse::CPAN::Meta is a parser for META.json and META.yml files, using JSON::PP
@@ -64,7 +68,7 @@ make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot} UNINST=0
-find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name .packlist -delete
 %{_fixperms} %{buildroot}
 
 %check
@@ -77,6 +81,18 @@ make test
 %{_mandir}/man3/Parse::CPAN::Meta.3*
 
 %changelog
+* Wed Jun 29 2016 Paul Howarth  - 1:1.4421-1
+- Update to 1.4421
+  - Add CPAN_META_JSON_BACKEND to allow requesting non-JSON.pm backends
+  - Add CPAN_META_JSON_DECODER to allow Mojo::JSON/JSON::Tiny to be used just
+for decoding
+  - Re-encode strings before decode_json since that expects bytes
+  - Add test cases for wide characters in META files
+  - Bump JSON::PP prerequisite to 2.27300 to work around a bug before perl
+5.8.7; includes a test to confirm correct behavior
+- BR: perl-generators
+- Simplify find command using -delete
+
 * Wed May 18 2016 Jitka Plesnikova  - 1:1.4417-366
 - Perl 5.24 re-rebuild of bootstrapped packages
 
diff --git a/sources b/sources
index f479dc4..98eb4df 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b4f36533cba9ec56bef6f3797b7f4d84  Parse-CPAN-Meta-1.4417.tar.gz
+68af202068e42f42795e0750f0e97490  Parse-CPAN-Meta-1.4421.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Parse-CPAN-Meta.git/commit/?h=master=26448209d04f513bb68a1d3bdfb3a6d0d9ef38ed
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

Re: Injecting perl-devel and perl-generators build-requires

2016-06-29 Thread Emmanuel Seyman

* Jeff Fearn [29/06/2016 16:01] :
>
> Since that is no longer a consideration can we make it so that requiring
> perl gets you a proper perl core installed?

We still get bug reports complaining about packages that depend on
perl-devel so I'm not sure the sentiment is universally shared.

Emmanuel
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (perl-DateTime-1.33-1.fc25). "Update to 1.33 (..more)"

2016-06-29 Thread notifications

From 63188e373158d4a57537e84fc1a96f2f50999f9c Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Wed, 29 Jun 2016 10:19:38 +0100
Subject: Update to 1.33

- New upstream release 1.33
  - When you pass a locale to $dt->set you will now get a warning suggesting
you should use $dt->set_locale instead (CPAN RT#115420)
  - Added support for $dt->truncate( to => 'quarter' ) (GH#17)
  - Fixed the $dt->set docs to say that you cannot pass a locale (even though
you can but you'll get a warning) and added more docs for $dt->set_locale
  - Require DateTime::Locale 1.05
  - Require DateTime::TimeZone 2.00
- Take advantage of NO_PACKLIST option in recent EU:MM
---
 perl-DateTime.spec | 25 +++--
 sources|  2 +-
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 361611a..80952d3 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.28
+Version:1.33
 Release:1%{?dist}
 Summary:Date and time object for Perl
 License:Artistic 2.0
@@ -14,13 +14,14 @@ BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 # Run-time:
 BuildRequires:  perl(base)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
-BuildRequires:  perl(DateTime::Locale) >= 0.41
-BuildRequires:  perl(DateTime::TimeZone) >= 1.74
+BuildRequires:  perl(DateTime::Locale) >= 1.05
+BuildRequires:  perl(DateTime::TimeZone) >= 2.00
+BuildRequires:  perl(Dist::CheckConflicts) >= 0.02
 BuildRequires:  perl(integer)
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Params::Validate) >= 1.03
@@ -34,6 +35,8 @@ BuildRequires:  perl(warnings::register)
 # Optional Run-time:
 BuildRequires:  perl(XSLoader)
 # Tests:
+BuildRequires:  perl(CPAN::Meta::Check) >= 0.011
+BuildRequires:  perl(CPAN::Meta::Requirements)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(Test::Fatal)
@@ -66,12 +69,11 @@ believed to be the birth of Jesus Christ.
 %setup -q -n DateTime-%{version}
 
 %build
-perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}" NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -delete
 find %{buildroot} -type f -name '*.bs' -empty -delete
 %{_fixperms} %{buildroot}
 
@@ -90,6 +92,17 @@ make test
 %{_mandir}/man3/DateTime::LeapSecond.3*
 
 %changelog
+* Wed Jun 29 2016 Paul Howarth  - 2:1.33-1
+- Update to 1.33
+  - When you pass a locale to $dt->set you will now get a warning suggesting
+you should use $dt->set_locale instead (CPAN RT#115420)
+  - Added support for $dt->truncate( to => 'quarter' ) (GH#17)
+  - Fixed the $dt->set docs to say that you cannot pass a locale (even though
+you can but you'll get a warning) and added more docs for $dt->set_locale
+  - Require DateTime::Locale 1.05
+  - Require DateTime::TimeZone 2.00
+- Take advantage of NO_PACKLIST option in recent EU:MM
+
 * Sun May 22 2016 Paul Howarth  - 2:1.28-1
 - Update to 1.28
   - Fixed handling of some floating point epochs; since DateTime treated the
diff --git a/sources b/sources
index 952e8c0..c01476d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-28d8a46cc8f6724bb039987339b42aaf  DateTime-1.28.tar.gz
+fcbb54d95f31d143be26e0253457e5eb  DateTime-1.33.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime.git/commit/?h=perl-DateTime-1.33-1.fc25=63188e373158d4a57537e84fc1a96f2f50999f9c
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc uploaded Parse-CPAN-Meta-1.4421.tar.gz for perl-Parse-CPAN-Meta

2016-06-29 Thread notifications

68af202068e42f42795e0750f0e97490  Parse-CPAN-Meta-1.4421.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Parse-CPAN-Meta/Parse-CPAN-Meta-1.4421.tar.gz/md5/68af202068e42f42795e0750f0e97490/Parse-CPAN-Meta-1.4421.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc pushed to perl-DateTime (master). "Update to 1.33 (..more)"

2016-06-29 Thread notifications

From 63188e373158d4a57537e84fc1a96f2f50999f9c Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Wed, 29 Jun 2016 10:19:38 +0100
Subject: Update to 1.33

- New upstream release 1.33
  - When you pass a locale to $dt->set you will now get a warning suggesting
you should use $dt->set_locale instead (CPAN RT#115420)
  - Added support for $dt->truncate( to => 'quarter' ) (GH#17)
  - Fixed the $dt->set docs to say that you cannot pass a locale (even though
you can but you'll get a warning) and added more docs for $dt->set_locale
  - Require DateTime::Locale 1.05
  - Require DateTime::TimeZone 2.00
- Take advantage of NO_PACKLIST option in recent EU:MM
---
 perl-DateTime.spec | 25 +++--
 sources|  2 +-
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 361611a..80952d3 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,6 +1,6 @@
 Name:   perl-DateTime
 Epoch:  2
-Version:1.28
+Version:1.33
 Release:1%{?dist}
 Summary:Date and time object for Perl
 License:Artistic 2.0
@@ -14,13 +14,14 @@ BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 # Run-time:
 BuildRequires:  perl(base)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(constant)
-BuildRequires:  perl(DateTime::Locale) >= 0.41
-BuildRequires:  perl(DateTime::TimeZone) >= 1.74
+BuildRequires:  perl(DateTime::Locale) >= 1.05
+BuildRequires:  perl(DateTime::TimeZone) >= 2.00
+BuildRequires:  perl(Dist::CheckConflicts) >= 0.02
 BuildRequires:  perl(integer)
 BuildRequires:  perl(overload)
 BuildRequires:  perl(Params::Validate) >= 1.03
@@ -34,6 +35,8 @@ BuildRequires:  perl(warnings::register)
 # Optional Run-time:
 BuildRequires:  perl(XSLoader)
 # Tests:
+BuildRequires:  perl(CPAN::Meta::Check) >= 0.011
+BuildRequires:  perl(CPAN::Meta::Requirements)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(Test::Fatal)
@@ -66,12 +69,11 @@ believed to be the birth of Jesus Christ.
 %setup -q -n DateTime-%{version}
 
 %build
-perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}" NO_PACKLIST=1
 make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -delete
 find %{buildroot} -type f -name '*.bs' -empty -delete
 %{_fixperms} %{buildroot}
 
@@ -90,6 +92,17 @@ make test
 %{_mandir}/man3/DateTime::LeapSecond.3*
 
 %changelog
+* Wed Jun 29 2016 Paul Howarth  - 2:1.33-1
+- Update to 1.33
+  - When you pass a locale to $dt->set you will now get a warning suggesting
+you should use $dt->set_locale instead (CPAN RT#115420)
+  - Added support for $dt->truncate( to => 'quarter' ) (GH#17)
+  - Fixed the $dt->set docs to say that you cannot pass a locale (even though
+you can but you'll get a warning) and added more docs for $dt->set_locale
+  - Require DateTime::Locale 1.05
+  - Require DateTime::TimeZone 2.00
+- Take advantage of NO_PACKLIST option in recent EU:MM
+
 * Sun May 22 2016 Paul Howarth  - 2:1.28-1
 - Update to 1.28
   - Fixed handling of some floating point epochs; since DateTime treated the
diff --git a/sources b/sources
index 952e8c0..c01476d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-28d8a46cc8f6724bb039987339b42aaf  DateTime-1.28.tar.gz
+fcbb54d95f31d143be26e0253457e5eb  DateTime-1.33.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime.git/commit/?h=master=63188e373158d4a57537e84fc1a96f2f50999f9c
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: introduction toogley | packaging intellij idea

2016-06-29 Thread Mikolaj Izdebski

Hi Tobias,

Welcome to Fedora.

On 06/22/2016 05:21 PM, toog...@mailbox.org wrote:

> * Are there some important documents I should additionally read?
> 
> * Do you have some tips for starting packaging, or dealing with the legacy 
> status of the package?

Java Packaging HOWTO mentioned by others is a good starting point.

I would recommend you joining Java SIG [1], where you can find help with
packaging, reviews, bugfixes etc. We have IRC channel and mailing list
where you can communicate with us.

[1] https://fedoraproject.org/wiki/SIGs/Java

> * I'm used to gpg-sign my git commits/tags by default. Should I continue this 
> practice while packaging? I've read somewhere that some people don't want 
> that, therefore my question.

We generally don't do that in Fedora.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Firefox on Wayland

2016-06-29 Thread Martin Stransky


On 06/28/2016 12:13 PM, Martin Stransky wrote:

On 06/28/2016 08:41 AM, Samuel Rakitničan wrote:

I've failed to launch the application properly under X.org and
Wayland using the launcher icon in GNOME shell.

But when I switched to Wayland, I executed the `firefox` command
from "Terminix" and it worked under XWayland with no regressions so
far (I didn't notice any other than links from other apps can't be
opened as it tries to open new instance of Firefox).


Having this issue as well. It crashes under wayland  when launched
from .desktop file for some reason, but not if started directly with
"firefox" from gnome-terminal.


It's https://bugzilla.redhat.com/show_bug.cgi?id=1349736


New fixed package is available at Copr.
ma.


-- devel mailing list devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

pghmcfc uploaded DateTime-1.33.tar.gz for perl-DateTime

2016-06-29 Thread notifications

fcbb54d95f31d143be26e0253457e5eb  DateTime-1.33.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-DateTime/DateTime-1.33.tar.gz/md5/fcbb54d95f31d143be26e0253457e5eb/DateTime-1.33.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

eseyman uploaded HTML-FormFu-2.03.tar.gz for perl-HTML-FormFu

2016-06-29 Thread notifications

43fe92f27ab11e7687382c936e9d0e7e  HTML-FormFu-2.03.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-HTML-FormFu/HTML-FormFu-2.03.tar.gz/md5/43fe92f27ab11e7687382c936e9d0e7e/HTML-FormFu-2.03.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

1 2 >

1 - 100 of 108 matches

Mail list logo