[Bug 1471307] perl-ExtUtils-CBuilder-0.280226 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
One or more of the new sources for this package are identical to the old
sources. It's likely this package does not use the version macro in its Source
URLs. If possible, please update the specfile to include the version macro in
the Source URLs

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1471307] New: perl-ExtUtils-CBuilder-0.280226 is available

[bugzilla]

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

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



Latest upstream release: 0.280226
Current version/release in rawhide: 0.280225-393.fc27
URL: http://search.cpan.org/dist/ExtUtils-CBuilder/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

> On Jul 14, 2017, at 12:54 PM, Florian Weimer  wrote:
> The app store model also assumes that the app store operator acts as
> some sort of gate keeper, so there has to be some policy enforcement at
> this level, too.  It is not sufficient to pass through just what the
> application developer asked for.

This is only a problem because Flatpak is currently following the IMO
rather busted old Android model. With very few, if any, exceptions, I
think a much better model would be for an application to start with
basically no permissions and to have to ask for fine-grained
permissions as needed.  Think iOS but tighter.  By default, an app
shouldn't be able to use the network, see what other applications are
installed, or get your unique advertising ID without explicit consent,
let alone access your dotfiles.

I would like to see a situation in which running random Flatpaks is as
safe or safer than visitng random webpages, at least insofar as the
*intentional* surface by which it can damage you should be as small or
smaller than that of a webpage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

 On Jul 14, 2017, at 11:30 AM, Richard Hughes  wrote:
>
>> On 14 July 2017 at 19:12, Andrew Lutomirski  wrote:
>> As above, it could be the exact same sandbox technology with the same
>> portals and everything.  The sandboxed program would just be files in
>> /usr instead of a Flatpak.
>
> How could that work? The runtime gets mounted in /usr and the app gets
> mounted in /app in a different place.
> https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf is a good
> read.

I don't see the problem.  The runtime could be all of /use and the app
could be a symlink living in /app that points at /usr.  The latter
could be created on the fly in a tmpfs.

Or the flatpak runtime could learn to accept a special type of
manifest that just says to run /usr/bin/whatever and not worry about
/app.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[stan]

On Fri, 14 Jul 2017 19:30:18 +0100
Richard Hughes  wrote:

> How could that work? The runtime gets mounted in /usr and the app gets
> mounted in /app in a different place.
> https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf is a good
> read.

I just read that.  I'm ignorant of flatpak except for seeing it
mentioned here and reading that.  I have a ton of questions about
how this is going to work, and a lot of misgivings, but I'll just
lurk for most of them, as they are questions that are going to have
to be answered in the course of development.  One I would like
answered, though, is what would be the difference in size for a binary
rpm of, say, gedit and a flatpak of gedit?  It sounds like a flatpak is
many times larger than a binary rpm.  Is that true?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Richard Hughes]

On 14 July 2017 at 20:28, Andreas Tunek  wrote:
> Is this really more reliable than using dnf (for graphical packages
> like Recepies and Builder)?

It's hugely more reliable. You can't actually trust rpm to do anything
atomically, and this is the main reason we force upgrade to be offline
in the workstation product. Just doing this one step reduced the
number of people experiencing the dead-system-after-upgrading bugs by
two order of magnitude, but it SUCKS to have to reboot to apply
application updates. Doing live updates with rpm is a bit like doing
maintenance on your car engine while driving down the freeway. Most of
the time it's fine, and you feel awesome. 0.001% of the time you die
in a huge fireball.

> What exactly is it that makes flatpaks
> more reliable?

They are *designed* to be updated atomically. You can safely update
application from a->b->c all running any permutation of running
processes and flatpak makes sure that the running app is only cleaned
up when the last instance is closed. RPM is an awesome system for
building the OS, just not managing *apps*. Flatpak is that awesome
thing for apps.

Richard, the man that gets to triage the "live updates hosed my system" bugs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Matthew Miller]

On Fri, Jul 14, 2017 at 07:25:11PM +0100, Richard Hughes wrote:
> Maybe tangential to the proposal/discussion/ranting, but you can
> actually use gnome-software on the command line.
> /usr/libexec/gnome-software-cmd (no GTK parts get loaded) has got a
> bit cleverer in F26 and is set to get even cleverer in F27. With this
> tool you can install/remove/update flatpaks, packages, gnome shell
> extensions, and even update firmware. It's not quite ready for human
> consumption (it's designed as a debug tool), but it could quite easily
> be moved into /usr/bin/ and a man page be written. I don't think
> "teach dnf about everything" is a super practical plan.

I dunno about "practical", but "one unified commandline tool to manage
all the software on my system" sure is *nice* from a user and admin
perspective. Maybe the dnf tool could be a plugin wrapper around
/usr/libexec/gnome-software-cmd?

-- 
Matthew Miller

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Florian Weimer]

On 07/12/2017 06:26 AM, mcatanz...@gnome.org wrote:
> I kinda agree here (though I am a bit surprised, as I did not think you
> were a very big SELinux fan). We absolutely could be investing more in
> SELinux. But we have not been. Very few applications actually have
> SELinux profiles, and they are all maintained downstream rather than
> upstream. The volume of erroneous SELinux denials in Bugzilla is too
> high, and the response time for fixing them too slow. SELinux profiles
> work best when they are maintained upstream by application developers
> who are familiar with SELinux, not by SELinux developers who are
> unfamiliar with the application. But application developers who are
> familiar with SELinux basically do not exist, and never will. So it
> would be useful to have a general sandbox that works for the vast
> majority of desktop apps.

On the other hand, most upstreams, even if they know about SELinux, will
rarely adopt restrictive policies.  They are also not modular in the
sense that you can write a policies for an application without taking
their library dependencies into account, or policies for libraries
without examining how applications use the library.  And when it comes
to rarely used features, I don't think many upstreams would implement
them and then prevent their use with a security policy.

The app store model also assumes that the app store operator acts as
some sort of gate keeper, so there has to be some policy enforcement at
this level, too.  It is not sufficient to pass through just what the
application developer asked for.

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

Re: Orphaning: clamav, sphinx, mldonkey

[Ben Cotton]

I'll take sphinx.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Lars Seipel]

On Tue, Jul 11, 2017 at 11:26:04PM -0500, mcatanz...@gnome.org wrote:
> But we have not been. Very few applications actually have SELinux profiles,
> and they are all maintained downstream rather than upstream. The volume of
> erroneous SELinux denials in Bugzilla is too high, and the response time for
> fixing them too slow. SELinux profiles work best when they are maintained
> upstream by application developers who are familiar with SELinux, not by
> SELinux developers who are unfamiliar with the application.

We do have the same issue with sandbox policies for Flatpak, no?  This
is the hard part of any sandboxing system and (judging from the current
docs) Flatpak hasn't tackled it yet.

A Flatpak app currently requires the following incantation to access the
host's dconf, so that it can behave like its users would expect:

> --filesystem=xdg-run/dconf
> --filesystem=~/.config/dconf:ro
> --talk-name=ca.desrt.dconf
> --env=DCONF_USER_CONFIG_DIR=.config/dconf

Now, while this specific dconf issue might get solved at some point,
dconf won't be enough for the vast majority of useful apps. All the crap
that lives in the various dot files in your home directory and elsewhere
on the system and that affects the behaviour of a program needs to be
made available to the app. Other things must not be, such as everything
containing secrets.

Some apps (e.g. virt-manager) need access to your ssh-agent socket but
you certainly don't want to make it available to every single app. This
is just a single instance of the general case of a program talking to
one of the numerous services that may run on the host.
programs depending on user configuration.

You want some environment variables passed through to the sandboxed app
(EDITOR or whatever) but not others (e.g. AWS_SECRET). How is the
Flatpak app even going to execute your favorite editor?

Someone is going to have to write all the policy for that. Otherwise,
the only apps that Flatpak will be able to handle properly are going to
be trivial mobile-style apps that don't interact with anything but their
developer's cloud services.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andreas Tunek]

2017-07-14 19:05 GMT+02:00 Debarshi Ray :
> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
>> >  F29: packagers (of graphical applications) must create Flatpaks of
>> >   their applications if possible. They *may* keep standard RPM
>> >   packaging.
>>
>> At least we see where this is going.
>>
>> If RPMs of the graphical application work fine now, what on earth is
>> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
>> of them - as already explained, sandboxing is orthogonal to packaging.
>
> How about reliable online updates of running applications as a
> benefit?

Is this really more reliable than using dnf (for graphical packages
like Recepies and Builder)? What exactly is it that makes flatpaks
more reliable?

/Andreas

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Christian Schaller]

One major reason is that it enables us to move towards having the Atomic 
Workstation
version be the primary one and maybe in the (very) long run be the only one.

A bit more detail about that can be found here:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation

Or this talk from FLOCK by Patrick Uiterwijk:
https://www.youtube.com/watch?v=zduGfpfwHz4

Christian


- Original Message -
> From: "Richard W.M. Jones" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, July 14, 2017 4:44:18 AM
> Subject: Re: F27 System Wide Change: Graphical Applications as Flatpaks
> 
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> >  F29: packagers (of graphical applications) must create Flatpaks of
> >   their applications if possible. They *may* keep standard RPM
> >   packaging.
> 
> At least we see where this is going.
> 
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Richard Hughes]

On 14 July 2017 at 19:12, Andrew Lutomirski  wrote:
> As above, it could be the exact same sandbox technology with the same
> portals and everything.  The sandboxed program would just be files in
> /usr instead of a Flatpak.

How could that work? The runtime gets mounted in /usr and the app gets
mounted in /app in a different place.
https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf is a good
read.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Richard Hughes]

On 14 July 2017 at 12:32, Dominik 'Rathann' Mierzejewski
 wrote:
> From what I read, only GNOME Software app supports Flatpaks and not
> everyone uses GNOME Software to install software.

Maybe tangential to the proposal/discussion/ranting, but you can
actually use gnome-software on the command line.
/usr/libexec/gnome-software-cmd (no GTK parts get loaded) has got a
bit cleverer in F26 and is set to get even cleverer in F27. With this
tool you can install/remove/update flatpaks, packages, gnome shell
extensions, and even update firmware. It's not quite ready for human
consumption (it's designed as a debug tool), but it could quite easily
be moved into /usr/bin/ and a man page be written. I don't think
"teach dnf about everything" is a super practical plan.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

On Fri, Jul 14, 2017 at 9:59 AM, Debarshi Ray  wrote:
> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
>> >  F29: packagers (of graphical applications) must create Flatpaks of
>> >   their applications if possible. They *may* keep standard RPM
>> >   packaging.
>>
>> At least we see where this is going.
>>
>> If RPMs of the graphical application work fine now, what on earth is
>> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
>> of them - as already explained, sandboxing is orthogonal to packaging.
>
> Huh? How would you get sandboxing without Flatpaks? Unless you are
> proposing a different sandboxing technology.

As above, it could be the exact same sandbox technology with the same
portals and everything.  The sandboxed program would just be files in
/usr instead of a Flatpak.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Rahul Sundaram]

On Fri, Jul 14, 2017 at 1:27 PM Matthew Miller 
> > How about reliable online updates of running applications as a
> > benefit?
>
> AND the ability to roll back, to choose beta or stable streams, etc.
>

These are reasonably good advantages but if there isn't a seamless
transition between them, it induces a lot of pain.   For instance,  dnf
cannot install flatpak apps currently and I can't use kickstart to automate
installation in the same way etc.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Matthew Miller]

On Fri, Jul 14, 2017 at 05:05:23PM +, Debarshi Ray wrote:
> > At least we see where this is going.
> > 
> > If RPMs of the graphical application work fine now, what on earth is
> > the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> > of them - as already explained, sandboxing is orthogonal to packaging.
> 
> How about reliable online updates of running applications as a
> benefit?

AND the ability to roll back, to choose beta or stable streams, etc.
For example, the Google Play app store, you can check a box to opt in
to beta versions of an app you're interested in following the bleeding
edge of. It'd be awesome to do that in Fedora. We *could* do that with
traditional packaging, but in practice doing it well seems like at
least as much work as the flatpak bundle approach — and we still
wouldn't get the update advantage.

-- 
Matthew Miller

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

Summary/Minnutes from today's FESCo Meeting (2017-07-14)

[Justin Forbes]

===
#fedora-meeting: FESCO (2017-07-14)
===


Meeting started by jforbes at 16:00:06 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2017-07-14/fesco.2017-07-14-16.00.log.html
.



Meeting summary
---
* init process  (jforbes, 16:00:06)

* #1738 - F27 System Wide Change: 32 bit UEFI Support  (jforbes,
  16:07:03)
  * LINK: https://pagure.io/fesco/issue/1738   (jforbes, 16:07:04)
  * AGREED: F27 System Wide Change: 32 bit UEFI Support is approved
(+5,0,-0)  (jforbes, 16:08:16)

* #1739 - F27 System Wide Change: Drop 256term.sh  (jforbes, 16:08:42)
  * LINK: https://pagure.io/fesco/issue/1739   (jforbes, 16:08:43)
  * AGREED: F27 System Wide Change: Drop 256term.sh is approved
(+5,0,-0)  (jforbes, 16:10:45)

* #1740 - F27 System Wide Change: The GNU C Library version 2.26
  (jforbes, 16:11:12)
  * LINK: https://pagure.io/fesco/issue/1740   (jforbes, 16:11:12)
  * AGREED: F27 System Wide Change: The GNU C Library version 2.26 is
approved (+5,0,-0)  (jforbes, 16:13:37)

* #1741 - F27 System Wide Change: Graphical Applications as Flatpaks
  (jforbes, 16:13:40)
  * LINK: https://pagure.io/fesco/issue/1741   (jforbes, 16:13:41)
  * AGREED: F27 System Wide Change: Graphical Applications as Flatpak
deferred a week for further discussion  (jforbes, 16:17:00)

* #1742 - F27 Self Contained Change: Improved Bay- and Cherry-Trail
  device support  (jforbes, 16:17:18)
  * LINK: https://pagure.io/fesco/issue/1742   (jforbes, 16:17:18)
  * AGREED: F27 Self Contained Change: Improved Bay- and Cherry-Trail
device support is approved (+5,0,-0)  (jforbes, 16:18:22)

* Next week's chair  (jforbes, 16:19:15)
  * sgallagh to chair next week  (jforbes, 16:19:34)
  * jsmith volunteered for the week after as he is out next week
(jforbes, 16:19:55)

* Open Floor  (jforbes, 16:20:17)

* #1729 - F27 System Wide Change: Host and Platform  (jforbes, 16:23:13)
  * LINK: https://pagure.io/fesco/issue/1729   (jforbes, 16:23:14)
  * AGREED: F27 System Wide Change: Host and Platform is approved
(+5,0,-0)  (jforbes, 16:39:46)

* #1730 - F27 System Wide Change: Modular Release  (jforbes, 16:40:01)
  * LINK: https://pagure.io/fesco/issue/1730   (jforbes, 16:40:02)
  * AGREED: F27 System Wide Change: Modular Release is approved
(+5,0,-0)  (jforbes, 16:44:27)

* #1731 - F27 System Wide Change: Modular Server  (jforbes, 16:44:45)
  * LINK: https://pagure.io/fesco/issue/1731   (jforbes, 16:44:45)
  * AGREED: F27 System Wide Change: Modular Server is approved (+5,0,-0)
(jforbes, 16:48:10)

* #1732 - F27 Self Contained Change: Remove SSH-1 from OpenSSH clients
  (jforbes, 16:48:22)
  * LINK: https://pagure.io/fesco/issue/1732   (jforbes, 16:48:23)
  * AGREED: F27 Self Contained Change: Remove SSH-1 from OpenSSH clients
is approved (+5,0,-0)  (jforbes, 16:50:34)

* #1733 - F27 Self Contained Change: Samba AD  (jforbes, 16:50:51)
  * LINK: https://pagure.io/fesco/issue/1733   (jforbes, 16:50:51)
  * AGREED: F27 Self Contained Change: Samba AD is approved (+5,0,-0)
(jforbes, 16:54:22)

* open floor  (jforbes, 16:54:39)

Meeting ended at 16:57:39 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* jforbes (81)
* jsmith (24)
* sgallagh (22)
* contyk (21)
* zodbot (20)
* maxamillion (19)
* Rathann (14)
* jreznik (4)
* ignatenkobrain (1)
* nirik (0)
* kalev (0)
* jwb (0)
* dgilmore (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Debarshi Ray]

On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> >  F29: packagers (of graphical applications) must create Flatpaks of
> >   their applications if possible. They *may* keep standard RPM
> >   packaging.
> 
> At least we see where this is going.
> 
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.

How about reliable online updates of running applications as a
benefit?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Debarshi Ray]

On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> >  F29: packagers (of graphical applications) must create Flatpaks of
> >   their applications if possible. They *may* keep standard RPM
> >   packaging.
> 
> At least we see where this is going.
> 
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.

Huh? How would you get sandboxing without Flatpaks? Unless you are
proposing a different sandboxing technology.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170714.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Workstation live i386
Server boot i386
Atomic raw-xz x86_64
Kde live i386

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

New failures (same test did not fail in Rawhide-20170712.n.1):

ID: 120732  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/120732
ID: 120764  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/120764
ID: 120775  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/120775
ID: 120779  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/120779
ID: 120784  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/120784

Old failures (same test failed in Rawhide-20170712.n.1):

ID: 120651  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/120651
ID: 120654  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/120654
ID: 120676  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/120676
ID: 120677  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/120677
ID: 120684  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/120684
ID: 120690  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/120690
ID: 120694  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/120694
ID: 120695  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/120695
ID: 120708  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/120708
ID: 120763  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/120763
ID: 120767  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/120767
ID: 120768  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/120768
ID: 120769  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/120769
ID: 120770  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/120770
ID: 120771  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/120771
ID: 120785  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/120785

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

New soft failures (same test did not soft fail in Rawhide-20170712.n.1):

ID: 120664  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/120664
ID: 120665  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/120665
ID: 120683  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/120683
ID: 120711  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/120711
ID: 120754  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/120754
ID: 120780  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/120780

Old soft failures (same test soft failed in Rawhide-20170712.n.1):

ID: 120640  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/120640
ID: 120641  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/120641
ID: 120642  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/120642
ID: 120643  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/120643
ID: 120662  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/120662
ID: 120663  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/120663
ID: 120697  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/120697
ID: 120698  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/120698
ID: 120709  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/120709
ID: 120710  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/120710
ID: 120712  Test: x86_64 universal install_delete_pata
URL: 

Re: Schedule for today's FESCo Meeting (2017-07-14)

[Justin Forbes]

On Fri, Jul 14, 2017 at 10:05 AM, Jaroslav Reznik  wrote:
> On Fri, Jul 14, 2017 at 3:36 PM, Justin Forbes  wrote:
>> Following is the list of topics that will be discussed in the
>> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
>> irc.freenode.net.
>>
>> To convert UTC to your local time, take a look at
>>   http://fedoraproject.org/wiki/UTCHowto
>>
>> or run:
>>   date -d '2017-07-14 16:00 UTC'
>>
>>
>> Links to all issues below can be found at:
>> https://pagure.io/fesco/report/meeting_agenda
>>
>> There is no new business scheduled at this time.
>
> Hi,
> I created quite a few F27 change proposals tickets, could you please
> add it to the agenda? Unfortunately I'm not able to tag it with
> "meeting" tag (I don't have sufficient permission).
>
> See https://fedoraproject.org/wiki/Category:ChangeReadyForFesco
>
> Thanks,
> Jaroslav
>
>>
>>
>> = Open Floor =
>>
>> For more complete details, please visit each individual
>> issue.  The report of the agenda items can be found at
>> https://pagure.io/fesco/report/meeting_agenda
>>
>> If you would like to add something to this agenda, you can
>> reply to this e-mail, file a new issue at
>> https://pagure.io/fesco, e-mail me directly, or bring it
>> up at the end of the meeting, during the open floor topic. Note
>> that added topics may be deferred until the following meeting.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
= New Business =

#topic #1729 - F27 System Wide Change: Host and Platform
.fesco 1729
https://pagure.io/fesco/issue/1729

#topic #1730 - F27 System Wide Change: Modular Release
.fesco 1730
https://pagure.io/fesco/issue/1730

#topic #1731 - F27 System Wide Change: Modular Server
.fesco 1731
https://pagure.io/fesco/issue/1731

#topic #1732 - F27 Self Contained Change: Remove SSH-1 from OpenSSH clients
.fesco 1732
https://pagure.io/fesco/issue/1732

#topic #1733 - F27 Self Contained Change: Samba AD
.fesco 1733
https://pagure.io/fesco/issue/1733

#topic #1738 - F27 System Wide Change: 32 bit UEFI Support
.fesco 1738
https://pagure.io/fesco/issue/1738

#topic #1739 - F27 System Wide Change: Drop 256term.sh
.fesco 1739
https://pagure.io/fesco/issue/1739

#topic #1740 - F27 System Wide Change: The GNU C Library version 2.26
.fesco 1740
https://pagure.io/fesco/issue/1740

#topic #1741 - F27 System Wide Change: Graphical Applications as Flatpaks
.fesco 1741
https://pagure.io/fesco/issue/1741

#topic #1742 - F27 Self Contained Change: Improved Bay- and
Cherry-Trail device support
.fesco 1742
https://pagure.io/fesco/issue/1742
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedpkg new-sources broken?

[Fabio Valentini]

On Fri, Jul 14, 2017 at 2:56 PM, Petr Pisar  wrote:
> On 2017-07-14, Mamoru TASAKA  wrote:
>> Fabio Valentini wrote on 07/14/2017 06:04 PM:
>>> Right now, I can't build updates or new packages, because "fedpkg
>>> new-sources" is getting stuck (for more than 15 minutes) without error
>>> message (other than the bodhi deprecation warning) and it doesn't do
>>> anything until I kill it ...
>>>
>>> I can't pin down the exact date it stopped working (since I don't use it
>>> every day), but I first noticed it yesterday after installing updates from
>>> f26-updates-testing (although those updates probably didn't cause the bug,
>>> because downgrading to f26 stable packages didn't help).
>>>
>>> Am I the only one affected by this bug or has nobody else been building
>>> packages? ;)
>>
>> Yes, I am seeing the same issue on F-26.
>> Looks like some of nss-* 3.31.0-1.0.fc26 packages are the culprits.
>> I downgraded to nss-* 3.30.2-1.1.fc26 and it seems to be working.
>>
> I have experienced this issue now with nss-3.31.0-1.0.fc25.x86_64 on
> F25. The fedpkg client gets stucked after reading expired
> ~/.fedora.cert. After removing the old certificate-key file, it works
> again with the new nss.

Good catch! After removing ~/.fedora.cert, it works for me again, too :)

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

Re: Wayland (?) unstability F25/F26 on Lenovo X201

[Pavel Lisý]

Hello

After another testing it looks more like Intel HD Graphics (i915)
problem (xorg-x11-drv-intel or kernel). 

I've tried add "video=DP-1:d" to grub boot line but it didn't help. 
Screen went to black after cca 2.5 hour and after that laptop shutdown. 
It is really hard to test it because crash comes suddenly in different
periods.

I couldn't find any solution on Google.

Pavel Lisy

František Zatloukal píše v Út 04. 07. 2017 v 12:59 +0200:
> Hi,
> First of all, make sure to try Gnome on Xorg or KDE session (you should
> see this option after clicking on "gear" icon on login screen). Is it
> stable?
> 
> Can you check abrt for anything suspicious?
> 
> 2017-07-04 12:18 GMT+02:00 Pavel Lisý :
> > Hello
> > 
> > I have laptop Lenovo X201 with fedora for a long time. I haven't had
> > any
> > problem with HW support up to release 25. Started with F25 beta -
> > system started to be unstable and I'm not sure why. I can log in and
> > work
> > for while - from a few tens of minutes to 1-3 hours. Than display turns
> > to
> > black with tiny line on left and after few seconds laptop is switched
> > off
> > (shutdown).
> > 
> > I've though it is problem of release 25 but the same is in F26 beta.
> > Can it
> > be because of Gnome on wayland?
> > 
> > I have more distribution on this laptop (Linux Mint 18 Cinnamon and
> > Xfce,
> > CentOS 7, Fedora 24, Fedora 25 KDE.
> > 
> > I've never had this behaviour in F24 or CentOS 7 (which I've used
> > regularly
> > 
> > until now)
> > 
> > Have you seen something similar? Where should I report it in bugzilla?
> > 
> > Pavel Lisy
> > 
> > --
> > Pavel Lisý 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Pavel Lisý 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for today's FESCo Meeting (2017-07-14)

[Jaroslav Reznik]

On Fri, Jul 14, 2017 at 3:36 PM, Justin Forbes  wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
> irc.freenode.net.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '2017-07-14 16:00 UTC'
>
>
> Links to all issues below can be found at:
> https://pagure.io/fesco/report/meeting_agenda
>
> There is no new business scheduled at this time.

Hi,
I created quite a few F27 change proposals tickets, could you please
add it to the agenda? Unfortunately I'm not able to tag it with
"meeting" tag (I don't have sufficient permission).

See https://fedoraproject.org/wiki/Category:ChangeReadyForFesco

Thanks,
Jaroslav

>
>
> = Open Floor =
>
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
>
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Disable cairo-gl backend in F27

[Adam Jackson]

On Mon, 2017-07-10 at 23:43 +0900, Mamoru TASAKA wrote:

> While I may be missing something, I don't think current Fedora package
> needs ruby cairo-gl bindings.
> Also, ruby-cairo gem does not have examples for cairo-gl surface nor have
> test suite for that, so I guess the ruby-cairo upstream does not care.

I've rebuilt cairo and rubygem-cairo with the gl backend disabled. If
there's any further fallout I'm sure the mass rebuild will let us know.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Colin Walters]

On Wed, Jul 12, 2017, at 07:53 AM, Kevin Kofler wrote:
>
> When I see the plans that are floated around, the other stuff might also end 
> up being containerized in a similar way, just using other technologies 
> (e.g., Docker).

There are definitely apps today that are designed to run in standalone 
Docker/OCI
containers, and even more that *solely* target Kubernetes/OpenShift.

So on the server side, we are definitely going to be crossing the same bridge
here for desktop apps - some software in Fedora will be container only, and
any RPMs that we might generate for it are only intermediate forms, not 
user-facing.

It is a bit silly to put them in Fedora Everything, hence aligning container 
builds
with Modularity help in the same way it will for flatpak.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Daniel P. Berrange]

On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote:
> > Jaroslav Reznik wrote:
> > > = System Wide Change: Graphical Applications as Flatpaks =
> > > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Fl
> > > atpaks
> > > 
> > > Change owner(s):
> > > * Owen Taylor 
> > 
> > This change is leaving several questions unanswered:
> > 
> > * As I understand it, those Flatpaks are going to be built from RPMs.
> > Is the intent to ship both the original RPMs and the Flatpak or only
> > the Flatpak (or is this going to depend on the individual package)?
> > And if the former, are the shipped RPMs going to be the FHS-compliant 
> > version or the one relocated into Flatpak's proprietary prefix?
> 
> The rebuilt RPMs are really only interesting within Flatpaks - they
> will be available for download from Koji, but there would be no reason
> for a user to do so.
> 
> As for standard application RPMs, it's really going to be something
> we figure out over time. My vision is something like:
> 
>  F27: packagers are *able* to create Flatpaks of their application.
>   They must also maintain standard RPMs.
> 
>  F28: packagers (of graphical applications) are *encouraged* to create
>   Flatpaks of their applications along side standard RPM packaging.
>   They *may* drop the standard RPM packaging if there is good
>   reason to.
> 
>  F29: packagers (of graphical applications) must create Flatpaks of
>   their applications if possible. They *may* keep standard RPM
>   packaging.
> 
> But this is really highly dependent on how modularity work happens more
> widely in Fedora. "standard RPM packaging" assumes we still have
> a F tag in Koji where everything is built together with common
> coordinated dependencies.

If I look at this from my POV as the upstream maintainer of a graphical
application wishing to make it widely available to users of many distros.
The question is whether it is beneficial for me to join Fedora packaging
world to package my app, or whether to package it standalone as a flatpak
and never get involved in Fedora at all.

With the proposed F27 rule here, I would have less work todo if I just
built my app as a flatpak, as I can avoid creating RPMs and just build
a single flatpak that should work on all distros. IOW by mandating
continued creation of RPMs, alongside flatpaks, we would be discouraging
people from becoming Fedora maintainers. 

Thus could suggest more flexibility - require continued maint of RPMs
for *existing* applications in Fedora only, to give some grace period
where we figure out how to provide a seemless upgrade path for people
who have an existing RPM installed to magically replace it with flatpak.
Anyone wishing to package a *new* application in F27, however, should be
able to straight to flatpaks only as there's no upgrade path issue to
worry about.

This would encourage upstream app maintainers to join Fedora to make
use of the review, build & distribution mechanisms for flatpaks, without
forcing them todo extra work to create RPMs too.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Broken dependencies: perl-HTML-FormFu-MultiForm

[buildsys]

perl-HTML-FormFu-MultiForm has broken dependencies in the rawhide tree:
On x86_64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-HTML-FormFu-MultiForm-1.00-9.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-OpenOffice-UNO

[buildsys]

perl-OpenOffice-UNO has broken dependencies in the rawhide tree:
On x86_64:
perl-OpenOffice-UNO-0.07-21.fc26.x86_64 requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-OpenOffice-UNO-0.07-21.fc26.armv7hl requires libperl.so.5.24
perl-OpenOffice-UNO-0.07-21.fc26.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-OpenOffice-UNO-0.07-21.fc26.ppc64le requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.ppc64le requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-OpenOffice-UNO-0.07-21.fc26.aarch64 requires 
libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-OpenOffice-UNO-0.07-21.fc26.ppc64 requires libperl.so.5.24()(64bit)
perl-OpenOffice-UNO-0.07-21.fc26.ppc64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-OpenOffice-UNO-0.07-21.fc26.i686 requires libperl.so.5.24
perl-OpenOffice-UNO-0.07-21.fc26.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-PDL-Graphics-PLplot

[buildsys]

perl-PDL-Graphics-PLplot has broken dependencies in the rawhide tree:
On aarch64:
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
libperl.so.5.24()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
libplplot.so.13()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On x86_64:
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
libperl.so.5.24()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
libplplot.so.13()(64bit)
perl-PDL-Graphics-PLplot-0.71-6.fc27.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires libperl.so.5.24
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires libplplot.so.13
perl-PDL-Graphics-PLplot-0.71-6.fc27.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires libperl.so.5.24
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires libplplot.so.13
perl-PDL-Graphics-PLplot-0.71-6.fc27.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-SDL

[buildsys]

perl-SDL has broken dependencies in the rawhide tree:
On x86_64:
perl-SDL-2.546-7.fc26.x86_64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.x86_64 requires perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-SDL-2.546-7.fc26.armv7hl requires libperl.so.5.24
perl-SDL-2.546-7.fc26.armv7hl requires perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-SDL-2.546-7.fc26.ppc64le requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.ppc64le requires perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-SDL-2.546-7.fc26.aarch64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.aarch64 requires perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-SDL-2.546-7.fc26.ppc64 requires libperl.so.5.24()(64bit)
perl-SDL-2.546-7.fc26.ppc64 requires perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-SDL-2.546-7.fc26.i686 requires libperl.so.5.24
perl-SDL-2.546-7.fc26.i686 requires perl(:MODULE_COMPAT_5.24.1)
On x86_64:
perl-Module-Build-SDL-2.546-7.fc26.x86_64 requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Module-Build-SDL-2.546-7.fc26.armv7hl requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Module-Build-SDL-2.546-7.fc26.ppc64le requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Module-Build-SDL-2.546-7.fc26.aarch64 requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Module-Build-SDL-2.546-7.fc26.ppc64 requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Module-Build-SDL-2.546-7.fc26.i686 requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Catalyst-Controller-HTML-FormFu

[buildsys]

perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide 
tree:
On x86_64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Catalyst-Controller-HTML-FormFu-2.01-2.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Gtk3-WebKit

[buildsys]

perl-Gtk3-WebKit has broken dependencies in the rawhide tree:
On x86_64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Gtk3-WebKit-0.06-7.fc26.noarch requires perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Algorithm-CurveFit

[buildsys]

perl-Algorithm-CurveFit has broken dependencies in the rawhide tree:
On x86_64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On armhfp:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64le:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On aarch64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On ppc64:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
On i386:
perl-Algorithm-CurveFit-1.05-18.fc26.noarch requires 
perl(:MODULE_COMPAT_5.24.1)
Please resolve this as soon as possible.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Pierre-Yves Chibon]

On Fri, Jul 14, 2017 at 03:32:03PM +0200, Kevin Kofler wrote:
> Owen Taylor wrote:
> > As for standard application RPMs, it's really going to be something
> > we figure out over time. My vision is something like:
> > 
> >  F27: packagers are *able* to create Flatpaks of their application.
> >   They must also maintain standard RPMs.
> > 
> >  F28: packagers (of graphical applications) are *encouraged* to create
> >   Flatpaks of their applications along side standard RPM packaging.
> >   They *may* drop the standard RPM packaging if there is good
> >   reason to.
> > 
> >  F29: packagers (of graphical applications) must create Flatpaks of
> >   their applications if possible. They *may* keep standard RPM
> >   packaging.
> 
> This sounds a lot like:
> https://en.wikipedia.org/wiki/Salami_tactics
> to me, a common strategy used by construction companies to subvert 
> environmental rules, obviously frowned upon. You are trying to submit small 
> innocous-sounding changes in an attempt to sneak in your plan to completely 
> subvert Fedora while minimizing opposition.
> 
> I really hope that FESCo will evaluate the above complete plan when 
> considering your change proposal, not just the thin salami slice that you 
> submitted.

Well, let's be fair here, if it was indeed what you are describing, would it be
announced on this list 1.5 years in advance ?


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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[William Moreno]

> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.

+1, completely!


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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Emmanuel Seyman]

* Dominik 'Rathann' Mierzejewski [14/07/2017 13:32] :
>
> Is `dnf install foo' still going to work when foo is converted to a
> Flatpak and no longer built as a plain RPM?

I was unable to find Recipes (an application in the latest GNOME) either
by dnf or Gnome Software. Using Google, I found out this app is only
available via flatpak and that installing and upgrading it requires using
the flatpak commands instead of the dnf/Gnome Software ones.

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

Re: Installing all core Perl modules by perl package

[Petr Pisar]

On Wed, Jun 14, 2017 at 01:52:40PM +0200, Petr Pisar wrote:
> Therefore I offered them that Fedora can make "dnf install perl" working as
> thay want and it will be implemented by renaming perl-core to perl and
> giving a new name to present perl package.
> 
> Thus I created this Fedora Change
> 
> naively aiming to Fedora 27.
> 
For you information, this change si completed. perl-5.26.0-395.fc27 swaped the
two subpackages.

Also please note that new packaging guidelines are in effect. Build-require
perl-interpreter package for having perl programm. Not perl package.

-- Petr


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

Schedule for today's FESCo Meeting (2017-07-14)

[Justin Forbes]

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

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

or run:
  date -d '2017-07-14 16:00 UTC'


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

There is no new business scheduled at this time.


= Open Floor =

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

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Kevin Kofler]

Owen Taylor wrote:
> As for standard application RPMs, it's really going to be something
> we figure out over time. My vision is something like:
> 
>  F27: packagers are *able* to create Flatpaks of their application.
>   They must also maintain standard RPMs.
> 
>  F28: packagers (of graphical applications) are *encouraged* to create
>   Flatpaks of their applications along side standard RPM packaging.
>   They *may* drop the standard RPM packaging if there is good
>   reason to.
> 
>  F29: packagers (of graphical applications) must create Flatpaks of
>   their applications if possible. They *may* keep standard RPM
>   packaging.

This sounds a lot like:
https://en.wikipedia.org/wiki/Salami_tactics
to me, a common strategy used by construction companies to subvert 
environmental rules, obviously frowned upon. You are trying to submit small 
innocous-sounding changes in an attempt to sneak in your plan to completely 
subvert Fedora while minimizing opposition.

I really hope that FESCo will evaluate the above complete plan when 
considering your change proposal, not just the thin salami slice that you 
submitted.

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

Re: F27 System Wide Change: perl Package to Install Core Modules

[Petr Pisar]

On 2017-06-15, Jan Kurik  wrote:
>= Proposed System Wide Change: perl Package to Install Core Modules =
> https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
>
> Change owner(s):
> * Petr Písař 
>
> dnf install perl will install all core Perl modules that come with
> Perl upstream sources.
>
This change has been implemented in perl-5.26.0-395.fc27.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Kevin Kofler]

Richard W.M. Jones wrote:
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.

+1, completely!

I think it is completely unacceptable to REPLACE RPMs with Flatpaks, and 
this is exactly why I am so much opposed to this innocuous-sounding change 
proposal that is just the beginning of the slippery slope.

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

[Bug 1469517] perl-Term-ProgressBar-2.20 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Term-ProgressBar-2.20-
   ||1.fc27
 Resolution|--- |RAWHIDE
Last Closed||2017-07-14 09:23:17



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Term-ProgressBar (master). "Merge branch 'master' of ssh://pkgs.fedoraproject.org/rpms/perl-Term-ProgressBar"

[notifications]

From 5ebefb91769c3d9336b71dd77109dc3c978b23e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 12 Jul 2017 14:26:36 +0200
Subject: perl dependency renamed to perl-interpreter
 

---
 perl-Term-ProgressBar.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Term-ProgressBar.spec b/perl-Term-ProgressBar.spec
index fed7ac9..1342039 100644
--- a/perl-Term-ProgressBar.spec
+++ b/perl-Term-ProgressBar.spec
@@ -11,7 +11,7 @@ BuildArch:  noarch
 BuildRequires:  coreutils
 BuildRequires:  findutils
 BuildRequires:  make
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(strict)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Term-ProgressBar.git/commit/?h=master=cf040fef2298fa601efa4016de916d2544368117
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Term-ProgressBar (master). "2.20 bump"

[notifications]

From 574df36c280e1f4cd1ebf54bad3dac381bcdf359 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 14 Jul 2017 15:17:23 +0200
Subject: 2.20 bump

---
 .gitignore | 1 +
 perl-Term-ProgressBar.spec | 5 -
 sources| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6ba49da..fb78e04 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ Term-ProgressBar-2.09.tar.gz
 /Term-ProgressBar-2.17.tar.gz
 /Term-ProgressBar-2.18.tar.gz
 /Term-ProgressBar-2.19.tar.gz
+/Term-ProgressBar-2.20.tar.gz
diff --git a/perl-Term-ProgressBar.spec b/perl-Term-ProgressBar.spec
index fed7ac9..43cea02 100644
--- a/perl-Term-ProgressBar.spec
+++ b/perl-Term-ProgressBar.spec
@@ -1,5 +1,5 @@
 Name:   perl-Term-ProgressBar
-Version:2.19
+Version:2.20
 Release:1%{?dist}
 Summary:Provide a progress meter on a standard terminal
 License:GPL+ or Artistic
@@ -65,6 +65,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 14 2017 Jitka Plesnikova  - 2.20-1
+- 2.20 bump
+
 * Tue Jul 11 2017 Jitka Plesnikova  - 2.19-1
 - 2.19 bump
 
diff --git a/sources b/sources
index 73f0dc4..f599f11 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Term-ProgressBar-2.19.tar.gz) = 
bd7598b6de29d5615f81a6e406e60c95ce005e2339d30e1f8b462b40ad3232db48e7f15ca8a4d5682b4bd7b51d8fd7cc70a8ec50eb9709afd05f3d37252c6d19
+SHA512 (Term-ProgressBar-2.20.tar.gz) = 
47662ce685edb0f5e036f3e68af069eef9713eef94d662e7ecfc88e53a22e9e34ad6e3b461a5d1aecd33791653f538bc675055673ab30ec08f08f9f6192262fd
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Term-ProgressBar.git/commit/?h=master=574df36c280e1f4cd1ebf54bad3dac381bcdf359
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] Please review: [lib389] Issue 48 - Add support for USN plugin

[Ilias Stamatis]

https://pagure.io/lib389/issue/48

https://pagure.io/lib389/issue/raw/44349b844e78b688e9633a325cadf268328f2ad22737094a45244c0dcd168641-0001-Issue-48-Add-support-for-USN-plugin.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1471089] perl-Coro-6.512 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Coro-6.512-1.fc27
 Resolution|--- |CURRENTRELEASE
Last Closed||2017-07-14 09:20:22



--- Comment #1 from Petr Pisar  ---
While this release accepted patches, it disabled hardening (we enable again)
and played a little bit with JIT (that we do not use), I'd rather see it in
rawhide only.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Coro (master). "6.512 bump"

[notifications]

From 3dcd10a1605125e41b180fc8440eacdbfbac2a65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 14 Jul 2017 15:09:37 +0200
Subject: 6.512 bump

---
 .gitignore |  1 +
 ...mppad_name_-variable-sizes-to-Perl-5.26.0.patch | 60 --
 Coro-6.511-Do-not-use-argarray.patch   | 38 --
 Coro-6.512-Disable-disabling-FORTIFY_SOURCE.patch  | 49 ++
 perl-Coro.spec | 19 +++
 sources|  2 +-
 6 files changed, 58 insertions(+), 111 deletions(-)
 delete mode 100644 
Coro-6.511-Adjust-comppad_name_-variable-sizes-to-Perl-5.26.0.patch
 delete mode 100644 Coro-6.511-Do-not-use-argarray.patch
 create mode 100644 Coro-6.512-Disable-disabling-FORTIFY_SOURCE.patch

diff --git a/.gitignore b/.gitignore
index 200b969..2adbefc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,3 +27,4 @@
 /Coro-6.48.tar.gz
 /Coro-6.49.tar.gz
 /Coro-6.511.tar.gz
+/Coro-6.512.tar.gz
diff --git 
a/Coro-6.511-Adjust-comppad_name_-variable-sizes-to-Perl-5.26.0.patch 
b/Coro-6.511-Adjust-comppad_name_-variable-sizes-to-Perl-5.26.0.patch
deleted file mode 100644
index 2fb34c0..000
--- a/Coro-6.511-Adjust-comppad_name_-variable-sizes-to-Perl-5.26.0.patch
+++ /dev/null
@@ -1,60 +0,0 @@
-From b48bc3a8141e5f27ce48b6f3ebbe2ba6ee7bda94 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
-Date: Tue, 23 May 2017 15:12:06 +0200
-Subject: [PATCH] Adjust comppad_name_ variable sizes to Perl 5.26.0
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Perl 5.26.0 changed some variable types in this commit:
-
-commit d12be05dd0210a08e077f0cc9586a5a963122547
-Author: David Mitchell 
-Date:   Mon Sep 26 15:56:08 2016 +0100
-
-make PL_ pad vars be of type PADOFFSET
-
-Now that that PADOFFSET is signed, make
-
-PL_comppad_name_fill
-PL_comppad_name_floor
-PL_padix
-PL_constpadix
-PL_padix_floor
-PL_min_intro_pending
-PL_max_intro_pending
-
-be of type PADOFFSET rather than I32, to match the rest of the pad
-interface.
-
-At the same time, change various I32 local vars in pad.c functions to be
-PADOFFSET.
-
-This patch adjusts Coro to the changes.
-
-Signed-off-by: Petr Písař 

- Coro/state.h | 5 +
- 1 file changed, 5 insertions(+)
-
-diff --git a/Coro/state.h b/Coro/state.h
-index 9a3e84f..8d6d067 100644
 a/Coro/state.h
-+++ b/Coro/state.h
-@@ -83,8 +83,13 @@ VAR(compcv,CV *)   /* currently compiling 
subroutine */
- 
- VAR(comppad,   AV *)   /* storage for lexically scoped 
temporaries */
- VAR(comppad_name,  AV *)   /* variable names for "my" variables */
-+#if PERL_VERSION_ATLEAST (5,25,6)
-+VAR(comppad_name_fill, PADOFFSET)/* last "introduced" variable offset 
*/
-+VAR(comppad_name_floor,PADOFFSET)/* start of vars in innermost block 
*/
-+#else
- VAR(comppad_name_fill, I32)/* last "introduced" variable offset */
- VAR(comppad_name_floor,I32)/* start of vars in innermost block */
-+#endif
- 
- VAR(runops,runops_proc_t)  /* for tracing support */
- 
--- 
-2.9.4
-
diff --git a/Coro-6.511-Do-not-use-argarray.patch 
b/Coro-6.511-Do-not-use-argarray.patch
deleted file mode 100644
index a14a205..000
--- a/Coro-6.511-Do-not-use-argarray.patch
+++ /dev/null
@@ -1,38 +0,0 @@
-From e5bbd3e590aed6e7bad9a9a5b55e2c2631d10a37 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
-Date: Mon, 27 Jun 2016 10:52:57 +0200
-Subject: [PATCH] Do not use argarray
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The argarray was removed before perl 5.24,
-code equivalence displayed in e2657e180a66b618ece78ca6b9c1f9e9b361a948
-Perl5 commit,
-,
-bug #1338707
-
-Signed-off-by: Petr Písař 

- Coro/State.xs | 4 
- 1 file changed, 4 insertions(+)
-
-diff --git a/Coro/State.xs b/Coro/State.xs
-index 687fc25..e60690d 100644
 a/Coro/State.xs
-+++ b/Coro/State.xs
-@@ -1412,7 +1412,11 @@ runops_trace (pTHX)
-   PUSHMARK (SP);
-   PUSHs (_sv_yes);
-   PUSHs (fullname);
-+# if PERL_VERSION_ATLEAST(5,24,0)
-+  PUSHs (CxHASARGS (cx) ? sv_2mortal (newRV_inc 
(PL_curpad[0])) : _sv_undef);
-+#else
-   PUSHs (CxHASARGS (cx) ? sv_2mortal (newRV_inc ((SV 
*)cx->blk_sub.argarray)) : _sv_undef);
-+#endif
-   PUTBACK;
-   cb = hv_fetch ((HV *)SvRV (coro_current), 
"_trace_sub_cb", sizeof ("_trace_sub_cb") - 1, 0);
-   if (cb) call_sv (*cb, 

jplesnik uploaded Term-ProgressBar-2.20.tar.gz for perl-Term-ProgressBar

[notifications]

47662ce685edb0f5e036f3e68af069eef9713eef94d662e7ecfc88e53a22e9e34ad6e3b461a5d1aecd33791653f538bc675055673ab30ec08f08f9f6192262fd
  Term-ProgressBar-2.20.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Term-ProgressBar/Term-ProgressBar-2.20.tar.gz/sha512/47662ce685edb0f5e036f3e68af069eef9713eef94d662e7ecfc88e53a22e9e34ad6e3b461a5d1aecd33791653f538bc675055673ab30ec08f08f9f6192262fd/Term-ProgressBar-2.20.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: VirtualBox Guest Integration

[Josh Boyer]

On Sat, Jul 8, 2017 at 9:36 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 07-07-17 16:43, Sérgio Basto wrote:
>>
>> On Fri, 2017-07-07 at 08:14 -0400, Nico Kadel-Garcia wrote:
>>>
>>> On Thu, Jul 6, 2017 at 2:57 PM, Zbigniew Jędrzejewski-Szmek
>>>  wrote:
>>>
 We want to make the default installation do the right thing, as far
 as
 possible, on any system, without any explicit configuration or
 admin steps.
 In this case it's possible: if a virtualization "channel" is
 configured,
 we should assume that the user wants the service. This means that
 the
 "guest additions" rpms should be a) installed by default, b)
 enabled
 when installed, c) work ootb when running in the right
 virtualization
 and silently do nothing otherwise.
 Essentially, I want to take the same image and boot it in
 virtualbox,
 kvm, on bare metal, and in a container, and have things just work.
>>>
>>>
>>> Good luck with that. Since the Virtualbox guest additions are *not*
>>> RPM enabled from their installation CD images, RPM is likely to
>>> interfere with working, more recent installations of VBox drivers
>>> from
>>> the "Guiest Additions" iso image, unless great caution is employed
>>> and
>>> unless someone can convince them to be completely consistent in
>>> installation tools, or to gracefully allow older and newer verson on
>>> the same host.
>>
>>
>> yes, we need install VirtualBox-guest-additions , which means
>> VirtualBox will be one Fedora Package and BTW I hope that Fedora use
>> RPMFusion package or based on that, I have many work there.
>> And there [1] we got vboxservice.service which have
>> ConditionVirtualization=|oracle
>
> No worries I do plan to use your package as a starting point and
> I will coordinate with you. For now I'm focussed on cleaning up the
> kernel module stuff though.

Do you expect this to be complete and upstream in time for F27?

While the upstream work is on-going, are you proposing to add the
drivers to the kernel package via a patch?  The Change could read
either way on that.

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

Re: fedpkg new-sources broken?

[Petr Pisar]

On 2017-07-14, Mamoru TASAKA  wrote:
> Fabio Valentini wrote on 07/14/2017 06:04 PM:
>> Right now, I can't build updates or new packages, because "fedpkg
>> new-sources" is getting stuck (for more than 15 minutes) without error
>> message (other than the bodhi deprecation warning) and it doesn't do
>> anything until I kill it ...
>> 
>> I can't pin down the exact date it stopped working (since I don't use it
>> every day), but I first noticed it yesterday after installing updates from
>> f26-updates-testing (although those updates probably didn't cause the bug,
>> because downgrading to f26 stable packages didn't help).
>> 
>> Am I the only one affected by this bug or has nobody else been building
>> packages? ;)
>
> Yes, I am seeing the same issue on F-26.
> Looks like some of nss-* 3.31.0-1.0.fc26 packages are the culprits.
> I downgraded to nss-* 3.30.2-1.1.fc26 and it seems to be working.
>
I have experienced this issue now with nss-3.31.0-1.0.fc25.x86_64 on
F25. The fedpkg client gets stucked after reading expired
~/.fedora.cert. After removing the old certificate-key file, it works
again with the new nss.

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

[389-devel] Re: Please review: ticket 49287 - csn pending lists don't work across multiple backends

[Ludwig Krispenz]

here is a revised patch, integrating Williams comments and a 
contribution by Thierry


https://pagure.io/389-ds-base/issue/raw/6d855f63e2e6968692eb06332c322aedbdc3e528232e63881344077864be75ec-0001-Ticket-49287-v3-extend-csnpl-handling-to-multiple-ba.patch

On 07/05/2017 01:02 PM, Ludwig Krispenz wrote:


ticket:
https://pagure.io/389-ds-base/issue/49287

design:
http://www.port389.org/docs/389ds/design/csn-pending-lists-and-ruv-update.html 



fix:
https://pagure.io/389-ds-base/issue/raw/7accb768b1e06a3623c2674daf8b0108daf594b72887014bf4c4831c06b59eeb-0001-Ticket-49287-extend-csnpl-handling-to-multiple-backe.patch 



ci-test:
https://pagure.io/389-ds-base/issue/raw/7077a3becff06e5936b34ea4a6bf0b83127d25134fd3a2a8ba06ba1b4c7cfe45-0001-test-for-pending-list-handling-across-multiple-backe.patch 





--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

ppisar uploaded Coro-6.512.tar.gz for perl-Coro

[notifications]

39cb946fd87961811d73b089d144bb25fcac046874a4a918ca2f58fde5feb19a16adf7c977641f8b5ca39fbbb92f92ba464ebc3b99ef4a8cd24f210b302d65f1
  Coro-6.512.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Coro/Coro-6.512.tar.gz/sha512/39cb946fd87961811d73b089d144bb25fcac046874a4a918ca2f58fde5feb19a16adf7c977641f8b5ca39fbbb92f92ba464ebc3b99ef4a8cd24f210b302d65f1/Coro-6.512.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1470196] mariadb library upgrade to 10.2 causes perl-DBD-MySQL FTBFS

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

External Bug ID||CPAN 122431



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1470196] mariadb library upgrade to 10.2 causes perl-DBD-MySQL FTBFS

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
External Bug ID||CPAN 122429
   Fixed In Version||perl-DBD-MySQL-4.043-2.fc27
 Resolution|--- |RAWHIDE
Last Closed||2017-07-14 08:46:38



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1471090] perl-Cache-FastMmap-1.46 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Cache-FastMmap-1.46-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-20f5e516cd

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-DBD-MySQL (master). "Fix for new version of MariaDB 10.2 (bug #1470196)"

[notifications]

From 2fd4382d13034fd653de96ed0614cd0100e2be74 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Fri, 14 Jul 2017 14:40:04 +0200
Subject: Fix for new version of MariaDB 10.2 (bug #1470196)

---
 ...4.043-Fix-build-failures-for-MariaDB-10.2.patch | 74 ++
 perl-DBD-MySQL.spec|  8 ++-
 2 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 DBD-mysql-4.043-Fix-build-failures-for-MariaDB-10.2.patch

diff --git a/DBD-mysql-4.043-Fix-build-failures-for-MariaDB-10.2.patch 
b/DBD-mysql-4.043-Fix-build-failures-for-MariaDB-10.2.patch
new file mode 100644
index 000..cc864d4
--- /dev/null
+++ b/DBD-mysql-4.043-Fix-build-failures-for-MariaDB-10.2.patch
@@ -0,0 +1,74 @@
+From 60d57caa60ee925b3596c45c461ae260a2550502 Mon Sep 17 00:00:00 2001
+From: Jitka Plesnikova 
+Date: Fri, 14 Jul 2017 14:13:50 +0200
+Subject: [PATCH] Fix build failures for MariaDB 10.2
+
+---
+ dbdimp.c | 7 +++
+ dbdimp.h | 1 +
+ mysql.xs | 4 ++--
+ 3 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/dbdimp.c b/dbdimp.c
+index 9b8b313..fa628b0 100644
+--- a/dbdimp.c
 b/dbdimp.c
+@@ -1979,6 +1979,9 @@ MYSQL *mysql_dr_connect(
+ 
+ if (result)
+ {
++#if MYSQL_VERSION_ID >= 50013
++   my_bool reconnect= 1;
++#endif
+ #if MYSQL_VERSION_ID >=SERVER_PREPARE_VERSION
+   /* connection succeeded. */
+   /* imp_dbh == NULL when mysql_dr_connect() is called from mysql.xs
+@@ -1997,7 +2000,11 @@ MYSQL *mysql_dr_connect(
+ we turn off Mysql's auto reconnect and handle re-connecting ourselves
+ so that we can keep track of when this happens.
+   */
++#if MYSQL_VERSION_ID >= 50013
++  mysql_options(result, MYSQL_OPT_RECONNECT, );
++#else
+   result->reconnect=0;
++#endif
+ }
+ else {
+   /* 
+diff --git a/dbdimp.h b/dbdimp.h
+index 935256e..3a5fcaa 100644
+--- a/dbdimp.h
 b/dbdimp.h
+@@ -20,6 +20,7 @@
+ #include   /* installed by the DBI module*/
+ #include   /* Comes with MySQL-devel */
+ #include   /* Comes MySQL */
++#include   /* Comes with MySQL-devel */
+ 
+ #include  /* Comes with MySQL-devel */
+ 
+diff --git a/mysql.xs b/mysql.xs
+index 13c6a57..bb3622b 100644
+--- a/mysql.xs
 b/mysql.xs
+@@ -790,7 +790,7 @@ dbd_mysql_get_info(dbh, sql_info_type)
+ D_imp_dbh(dbh);
+ IV type = 0;
+ SV* retsv=NULL;
+-#if !defined(MARIADB_BASE_VERSION) && MYSQL_VERSION_ID >= 50709
++#if MYSQL_VERSION_ID >= 50709
+ /* MariaDB 10 is not MySQL source level compatible so this only applies to 
MySQL*/
+ IV buffer_len;
+ #endif 
+@@ -822,7 +822,7 @@ dbd_mysql_get_info(dbh, sql_info_type)
+   retsv = newSVpvn("`", 1);
+   break;
+   case SQL_MAXIMUM_STATEMENT_LENGTH:
+-#if !defined(MARIADB_BASE_VERSION) && MYSQL_VERSION_ID >= 50709
++#if MYSQL_VERSION_ID >= 50709
+ /* MariaDB 10 is not MySQL source level compatible so this
+only applies to MySQL*/
+   /* mysql_get_option() was added in mysql 5.7.3 */
+-- 
+2.9.4
+
diff --git a/perl-DBD-MySQL.spec b/perl-DBD-MySQL.spec
index 95ba568..662ccf0 100644
--- a/perl-DBD-MySQL.spec
+++ b/perl-DBD-MySQL.spec
@@ -1,6 +1,6 @@
 Name:   perl-DBD-MySQL
 Version:4.043
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:A MySQL interface for Perl
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -8,6 +8,8 @@ URL:http://search.cpan.org/dist/DBD-mysql/
 Source0:
http://www.cpan.org/authors/id/M/MI/MICHIELB/DBD-mysql-%{version}.tar.gz
 # Fix for CVE-2017-10788
 Patch0: 
DBD-mysql-4.043-Fix-use-after-free-after-calling-mysql_stmt_close.patch.txt
+# Fix for new version of MariaDB 10.2
+Patch1: DBD-mysql-4.043-Fix-build-failures-for-MariaDB-10.2.patch
 BuildRequires:  mariadb, mariadb-devel, zlib-devel
 BuildRequires:  coreutils
 BuildRequires:  findutils
@@ -43,6 +45,7 @@ management system.
 %prep
 %setup -q -n DBD-mysql-%{version}
 %patch0 -p1
+%patch1 -p1
 
 # Correct file permissions
 find . -type f | xargs chmod -x
@@ -70,6 +73,9 @@ find %{buildroot} -type f -name '*.bs' -empty -delete
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Jul 13 2017 Jitka Plesnikova  - 4.043-2
+- Fix for new version of MariaDB 10.2 (bug #1470196)
+
 * Fri Jun 30 2017 Jitka Plesnikova  - 4.043-1
 - 4.043 bump
 - Fixed CVE-2017-10788 (bug #1467600)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-DBD-MySQL.git/commit/?h=master=2fd4382d13034fd653de96ed0614cd0100e2be74
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adelton pushed to perl-Cache-FastMmap (f25). "1471090 - Rebase to upstream version 1.46. (..more)"

[notifications]

From 8c8feba582034ee02500a40e2f5ac21eef1edc14 Mon Sep 17 00:00:00 2001
From: Jan Pazdziora 
Date: Fri, 14 Jul 2017 14:29:33 +0200
Subject: 1471090 - Rebase to upstream version 1.46.

(cherry picked from commit b7218e03acbd15476b0a3254cc9d768c5910816b)
---
 .gitignore   | 1 +
 perl-Cache-FastMmap.spec | 5 -
 sources  | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0ed1545..b8ac0b0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Cache-FastMmap-1.35.tar.gz
 /Cache-FastMmap-1.43.tar.gz
 /Cache-FastMmap-1.44.tar.gz
 /Cache-FastMmap-1.45.tar.gz
+/Cache-FastMmap-1.46.tar.gz
diff --git a/perl-Cache-FastMmap.spec b/perl-Cache-FastMmap.spec
index 0251056..f3e4550 100644
--- a/perl-Cache-FastMmap.spec
+++ b/perl-Cache-FastMmap.spec
@@ -1,5 +1,5 @@
 Name:   perl-Cache-FastMmap
-Version:1.45
+Version:1.46
 Release:1%{?dist}
 Summary:Uses an mmap'ed file to act as a shared memory interprocess 
cache
 License:GPL+ or Artistic
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 14 2017 Jan Pazdziora  - 1.46-1
+- 1471090 - Rebase to upstream version 1.46.
+
 * Wed Mar 22 2017 Jan Pazdziora  - 1.45-1
 - 1432914 - Rebase to upstream version 1.45.
 
diff --git a/sources b/sources
index 0ef009f..2db5c30 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Cache-FastMmap-1.45.tar.gz) = 
7c35ec3dd991295f56f03eb2839d88bcf1cb741c6d9c873e0cabdd8f4ba17ed7c790f82a3843cd40fd200450e4080208893734ff49120ef633309a8686058f3f
+SHA512 (Cache-FastMmap-1.46.tar.gz) = 
155c55dcbb05b83a7bf35ef70d4436b54ad0dc8684871c03048ac7dc364c5ce408152409fdc88d7c53f38ff7d767ec2c181da8c1e6118826ba0120ef20b77f59
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Cache-FastMmap.git/commit/?h=f25=8c8feba582034ee02500a40e2f5ac21eef1edc14
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adelton pushed to perl-Cache-FastMmap (f26). "1471090 - Rebase to upstream version 1.46. (..more)"

[notifications]

From 8c8feba582034ee02500a40e2f5ac21eef1edc14 Mon Sep 17 00:00:00 2001
From: Jan Pazdziora 
Date: Fri, 14 Jul 2017 14:29:33 +0200
Subject: 1471090 - Rebase to upstream version 1.46.

(cherry picked from commit b7218e03acbd15476b0a3254cc9d768c5910816b)
---
 .gitignore   | 1 +
 perl-Cache-FastMmap.spec | 5 -
 sources  | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0ed1545..b8ac0b0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Cache-FastMmap-1.35.tar.gz
 /Cache-FastMmap-1.43.tar.gz
 /Cache-FastMmap-1.44.tar.gz
 /Cache-FastMmap-1.45.tar.gz
+/Cache-FastMmap-1.46.tar.gz
diff --git a/perl-Cache-FastMmap.spec b/perl-Cache-FastMmap.spec
index 0251056..f3e4550 100644
--- a/perl-Cache-FastMmap.spec
+++ b/perl-Cache-FastMmap.spec
@@ -1,5 +1,5 @@
 Name:   perl-Cache-FastMmap
-Version:1.45
+Version:1.46
 Release:1%{?dist}
 Summary:Uses an mmap'ed file to act as a shared memory interprocess 
cache
 License:GPL+ or Artistic
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 14 2017 Jan Pazdziora  - 1.46-1
+- 1471090 - Rebase to upstream version 1.46.
+
 * Wed Mar 22 2017 Jan Pazdziora  - 1.45-1
 - 1432914 - Rebase to upstream version 1.45.
 
diff --git a/sources b/sources
index 0ef009f..2db5c30 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Cache-FastMmap-1.45.tar.gz) = 
7c35ec3dd991295f56f03eb2839d88bcf1cb741c6d9c873e0cabdd8f4ba17ed7c790f82a3843cd40fd200450e4080208893734ff49120ef633309a8686058f3f
+SHA512 (Cache-FastMmap-1.46.tar.gz) = 
155c55dcbb05b83a7bf35ef70d4436b54ad0dc8684871c03048ac7dc364c5ce408152409fdc88d7c53f38ff7d767ec2c181da8c1e6118826ba0120ef20b77f59
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Cache-FastMmap.git/commit/?h=f26=8c8feba582034ee02500a40e2f5ac21eef1edc14
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adelton uploaded Cache-FastMmap-1.46.tar.gz for perl-Cache-FastMmap

[notifications]

155c55dcbb05b83a7bf35ef70d4436b54ad0dc8684871c03048ac7dc364c5ce408152409fdc88d7c53f38ff7d767ec2c181da8c1e6118826ba0120ef20b77f59
  Cache-FastMmap-1.46.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Cache-FastMmap/Cache-FastMmap-1.46.tar.gz/sha512/155c55dcbb05b83a7bf35ef70d4436b54ad0dc8684871c03048ac7dc364c5ce408152409fdc88d7c53f38ff7d767ec2c181da8c1e6118826ba0120ef20b77f59/Cache-FastMmap-1.46.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

adelton pushed to perl-Cache-FastMmap (master). "1471090 - Rebase to upstream version 1.46."

[notifications]

From b7218e03acbd15476b0a3254cc9d768c5910816b Mon Sep 17 00:00:00 2001
From: Jan Pazdziora 
Date: Fri, 14 Jul 2017 14:29:33 +0200
Subject: 1471090 - Rebase to upstream version 1.46.

---
 .gitignore   | 1 +
 perl-Cache-FastMmap.spec | 7 +--
 sources  | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0ed1545..b8ac0b0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Cache-FastMmap-1.35.tar.gz
 /Cache-FastMmap-1.43.tar.gz
 /Cache-FastMmap-1.44.tar.gz
 /Cache-FastMmap-1.45.tar.gz
+/Cache-FastMmap-1.46.tar.gz
diff --git a/perl-Cache-FastMmap.spec b/perl-Cache-FastMmap.spec
index 6a9fbb4..9082a28 100644
--- a/perl-Cache-FastMmap.spec
+++ b/perl-Cache-FastMmap.spec
@@ -1,6 +1,6 @@
 Name:   perl-Cache-FastMmap
-Version:1.45
-Release:2%{?dist}
+Version:1.46
+Release:1%{?dist}
 Summary:Uses an mmap'ed file to act as a shared memory interprocess 
cache
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 14 2017 Jan Pazdziora  - 1.46-1
+- 1471090 - Rebase to upstream version 1.46.
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 1.45-2
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index 0ef009f..2db5c30 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Cache-FastMmap-1.45.tar.gz) = 
7c35ec3dd991295f56f03eb2839d88bcf1cb741c6d9c873e0cabdd8f4ba17ed7c790f82a3843cd40fd200450e4080208893734ff49120ef633309a8686058f3f
+SHA512 (Cache-FastMmap-1.46.tar.gz) = 
155c55dcbb05b83a7bf35ef70d4436b54ad0dc8684871c03048ac7dc364c5ce408152409fdc88d7c53f38ff7d767ec2c181da8c1e6118826ba0120ef20b77f59
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Cache-FastMmap.git/commit/?h=master=b7218e03acbd15476b0a3254cc9d768c5910816b
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] Please review: Ticket 49031 - Improve memberof with a cache of group parents

[Sankar Ramalingam]

https://pagure.io/389-ds-base/issue/49031

https://pagure.io/389-ds-base/issue/raw/7d3d1450ab9aa9c43422fbc6c7327b5ed9d236492c2de91866cc1e4df187dd41-0001-Add-performance-tests-for-memberof-plugin.patch

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

[Bug 1471090] New: perl-Cache-FastMmap-1.46 is available

[bugzilla]

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

Bug ID: 1471090
   Summary: perl-Cache-FastMmap-1.46 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Cache-FastMmap
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jpazdzi...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.46
Current version/release in rawhide: 1.45-2.fc27
URL: http://search.cpan.org/dist/Cache-FastMmap/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1471089] New: perl-Coro-6.512 is available

[bugzilla]

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

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



Latest upstream release: 6.512
Current version/release in rawhide: 6.511-4.fc27
URL: http://search.cpan.org/dist/Coro/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: fedpkg new-sources broken?

[Mamoru TASAKA]

Hello:

Fabio Valentini wrote on 07/14/2017 06:04 PM:

Right now, I can't build updates or new packages, because "fedpkg
new-sources" is getting stuck (for more than 15 minutes) without error
message (other than the bodhi deprecation warning) and it doesn't do
anything until I kill it ...

I can't pin down the exact date it stopped working (since I don't use it
every day), but I first noticed it yesterday after installing updates from
f26-updates-testing (although those updates probably didn't cause the bug,
because downgrading to f26 stable packages didn't help).

Am I the only one affected by this bug or has nobody else been building
packages? ;)

Fabio



Yes, I am seeing the same issue on F-26.
Looks like some of nss-* 3.31.0-1.0.fc26 packages are the culprits. I 
downgraded to
nss-* 3.30.2-1.1.fc26 and it seems to be working.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Dominik 'Rathann' Mierzejewski]

On Friday, 14 July 2017 at 10:44, Richard W.M. Jones wrote:
> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> >  F29: packagers (of graphical applications) must create Flatpaks of
> >   their applications if possible. They *may* keep standard RPM
> >   packaging.
> 
> At least we see where this is going.
> 
> If RPMs of the graphical application work fine now, what on earth is
> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
> of them - as already explained, sandboxing is orthogonal to packaging.

Is `dnf install foo' still going to work when foo is converted to a
Flatpak and no longer built as a plain RPM? In my opinion, that's
a prerequisite to dropping any RPMs in favour of Flatpaks. I'm fine
with introducing Flatpaks alongside RPMs as an option, but I'm against
forcing packagers to switch to Flatpaks as the primary distribution
format if the existing package management tools do not support it.
From what I read, only GNOME Software app supports Flatpaks and not
everyone uses GNOME Software to install software.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Concerning Beignet OpenCL driver stability

[Germano Massullo]

Looks like the problem has been fixed ->
https://bugzilla.redhat.com/show_bug.cgi?id=1470876#c6
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SONAME change] MySQL, MariaDB

[Michal Schorm]

Rex, the 10.2.7-2 version is finally out (after 20h of building :/ )

I did a scratch build of the 'os-autoinst' package and it looks like it
does not complain about the missing symbols anymore:
https://koji.fedoraproject.org/koji/taskinfo?taskID=20519110

Did that solved the issue, or am I just looking to the wrong place?



--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

On Fri, Jul 14, 2017 at 2:40 AM, Rex Dieter  wrote:

> Adam Williamson wrote:
>
> > On Thu, 2017-07-13 at 10:37 +0200, Michal Schorm wrote:
> >> A new version of MariaDB 10.2-4 is out, it now has fixed symlinks and
> >> Provides.
> >
> > I'm afraid even this build doesn't entirely work right, for some
> > reason: see this build failure I just got notified about by koschei:
> >
> > https://apps.fedoraproject.org/koschei/build/3070598
> > https://kojipkgs.fedoraproject.org/work/tasks/3960/20493960/build.log
> >
> > Note the errors at the end all relate to libmysqlclient and one claims
> > it cannot be found,
>
> non-verbose build.log aside, I'm pretty sure that:
> usr/lib64/libgdal.so.20: undefined reference to
> `mysql_error@libmysqlclient_18'
> type errors, means libgdal likely needs rebuilding first, before any of
> it's
> dependencies.
>
> -- Rex
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedpkg new-sources broken?

[Richard W.M. Jones]

On Fri, Jul 14, 2017 at 09:04:23AM +, Fabio Valentini wrote:
> Right now, I can't build updates or new packages, because "fedpkg
> new-sources" is getting stuck (for more than 15 minutes) without error
> message (other than the bodhi deprecation warning) and it doesn't do
> anything until I kill it ...
> 
> I can't pin down the exact date it stopped working (since I don't use it
> every day), but I first noticed it yesterday after installing updates from
> f26-updates-testing (although those updates probably didn't cause the bug,
> because downgrading to f26 stable packages didn't help).
> 
> Am I the only one affected by this bug or has nobody else been building
> packages? ;)

It worked for me about 2 hours ago when I was uploading a new
version of american-fuzzy-lop.

Might it be a network problem, either at your side or on the server
side?  Proxy settings might also affect curl.

fedpkg has ‘--verbose’ and ‘--debug’ options which might help.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of rpms/perl-Locale-TextDomain-OO-Util

[notifications]

pkgdb_updater updated: description of rpms/perl-Locale-TextDomain-OO-Util

https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Locale-TextDomain-OO-Util/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of rpms/perl-MooX-Singleton

[notifications]

pkgdb_updater updated: description of rpms/perl-MooX-Singleton
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-MooX-Singleton/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of rpms/perl-Image-Sane

[notifications]

pkgdb_updater updated: description of rpms/perl-Image-Sane
https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Image-Sane/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of rpms/perl-MooX-StrictConstructor

[notifications]

pkgdb_updater updated: description of rpms/perl-MooX-StrictConstructor

https://admin.fedoraproject.org/pkgdb/package/rpms/perl-MooX-StrictConstructor/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pkgdb_updater updated: description of rpms/perl-Locale-Utils-PlaceholderMaketext

[notifications]

pkgdb_updater updated: description of rpms/perl-Locale-Utils-PlaceholderMaketext

https://admin.fedoraproject.org/pkgdb/package/rpms/perl-Locale-Utils-PlaceholderMaketext/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: fedpkg new-sources broken?

[Michal Novotny]

Hello,

I was able to successfully use 'fedpkg new-sources' (still from f25) right
now.

clime

On Fri, Jul 14, 2017 at 11:04 AM, Fabio Valentini 
wrote:

> Right now, I can't build updates or new packages, because "fedpkg
> new-sources" is getting stuck (for more than 15 minutes) without error
> message (other than the bodhi deprecation warning) and it doesn't do
> anything until I kill it ...
>
> I can't pin down the exact date it stopped working (since I don't use it
> every day), but I first noticed it yesterday after installing updates from
> f26-updates-testing (although those updates probably didn't cause the bug,
> because downgrading to f26 stable packages didn't help).
>
> Am I the only one affected by this bug or has nobody else been building
> packages? ;)
>
> Fabio
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

dist.abicheck FAILED for perl-5.26.0-395.fc27

[notifications]

dist.abicheck FAILED for perl-5.26.0-395.fc27

https://taskotron.fedoraproject.org/artifacts/all/59e89c8a-6877-11e7-a988-5254008e42f6/task_output/perl-5.26.0-395.fc27.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

fedpkg new-sources broken?

[Fabio Valentini]

Right now, I can't build updates or new packages, because "fedpkg
new-sources" is getting stuck (for more than 15 minutes) without error
message (other than the bodhi deprecation warning) and it doesn't do
anything until I kill it ...

I can't pin down the exact date it stopped working (since I don't use it
every day), but I first noticed it yesterday after installing updates from
f26-updates-testing (although those updates probably didn't cause the bug,
because downgrading to f26 stable packages didn't help).

Am I the only one affected by this bug or has nobody else been building
packages? ;)

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

ppisar pushed to perl (master). "Remove spurious non-perl Provides from pregenerated dependency list"

[notifications]

From aa787938a49e2a1559a3aa50c75535d76fc8d354 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 14 Jul 2017 08:35:58 +0200
Subject: Remove spurious non-perl Provides from pregenerated dependency list

---
 gendep.macros | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gendep.macros b/gendep.macros
index a521a6b..cffe3a6 100644
--- a/gendep.macros
+++ b/gendep.macros
@@ -841,7 +841,6 @@ Provides: perl(subs) = 1.02 \
 Provides: perl(vars) = 1.03 \
 Provides: perl(vmsish) = 1.04 \
 Provides: perl(warnings::register) = 1.04 \
-Provides: perl(x86-64) = 4:5.26.0-392.fc27 \
 %{nil}
 %global gendep_perl_Archive_Tar \
 Requires: perl(:VERSION) >= 5.5.0 \
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl.git/commit/?h=master=aa787938a49e2a1559a3aa50c75535d76fc8d354
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl (master). "perl package installs all core modules (..more)"

[notifications]

From 5d2d98f2b22b6bba7ee06168dc4e45f6495b319b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 28 Jun 2017 10:22:16 +0200
Subject: perl package installs all core modules

This commit renames perl to perl-interprer and perl-core to perl.
---
 gendep.macros | 492 +-
 perl.spec | 240 +++-
 2 files changed, 381 insertions(+), 351 deletions(-)

diff --git a/gendep.macros b/gendep.macros
index 13cbf58..a521a6b 100644
--- a/gendep.macros
+++ b/gendep.macros
@@ -1,248 +1,4 @@
 %global gendep_perl \
-Requires: perl(:VERSION) >= 5.0.0 \
-Requires: perl(:VERSION) >= 5.10.1 \
-Requires: perl(:VERSION) >= 5.24.0 \
-Requires: perl(:VERSION) >= 5.3.0 \
-Requires: perl(:VERSION) >= 5.5.0 \
-Requires: perl(:VERSION) >= 5.6.0 \
-Requires: perl(:VERSION) >= 5.7.0 \
-Requires: perl(:VERSION) >= 5.7.3 \
-Requires: perl(:VERSION) >= 5.8.0 \
-Requires: perl(:VERSION) >= 5.9.1 \
-Requires: perl(:VERSION) >= 5.9.4 \
-Requires: perl(B) \
-Requires: perl(B::Concise) \
-Requires: perl(B::Op_private) \
-Requires: perl(B::Terse) \
-Requires: perl(Carp) \
-Requires: perl(Class::Struct) \
-Requires: perl(Config) \
-Requires: perl(Cwd) \
-Requires: perl(Exporter) \
-Requires: perl(ExtUtils::Constant::Base) \
-Requires: perl(ExtUtils::Constant::Utils) \
-Requires: perl(ExtUtils::Constant::XS) \
-Requires: perl(Fcntl) \
-Requires: perl(File::Basename) \
-Requires: perl(File::Path) \
-Requires: perl(File::Spec) \
-Requires: perl(File::Spec::Functions) \
-Requires: perl(I18N::LangTags) \
-Requires: perl(IO::File) \
-Requires: perl(IPC::Open3) \
-Requires: perl(Opcode) >= 1.01 \
-Requires: perl(POSIX) \
-Requires: perl(Scalar::Util) >= 1.10 \
-Requires: perl(Symbol) \
-Requires: perl(Text::Tabs) \
-Requires: perl(Text::Wrap) \
-Requires: perl(Tie::Handle) \
-Requires: perl(Tie::Hash) \
-Requires: perl(Tie::StdHandle) \
-Requires: perl(Time::tm) \
-Requires: perl(Unicode::Normalize) \
-Requires: perl(XSLoader) \
-Requires: perl(_charnames) \
-Requires: perl(bytes) \
-Requires: perl(charnames) \
-Requires: perl(constant) \
-Requires: perl(feature) \
-Requires: perl(if) \
-Requires: perl(integer) \
-Requires: perl(overload) \
-Requires: perl(parent) \
-Requires: perl(re) \
-Requires: perl(strict) \
-Requires: perl(subs) \
-Requires: perl(threads) \
-Requires: perl(threads::shared) \
-Requires: perl(unicore::Name) \
-Requires: perl(utf8) \
-Requires: perl(vars) \
-Requires: perl(warnings) \
-Requires: perl(warnings::register) \
-Provides: perl(AnyDBM_File) = 1.01 \
-Provides: perl(AutoLoader) = 5.74 \
-Provides: perl(AutoSplit) = 1.06 \
-Provides: perl(B) = 1.68 \
-Provides: perl(B::Concise) = 0.999 \
-Provides: perl(B::Deparse) = 1.40 \
-Provides: perl(B::OBJECT) \
-Provides: perl(B::Op_private) = 5.026000 \
-Provides: perl(B::Showlex) = 1.05 \
-Provides: perl(B::Terse) = 1.07 \
-Provides: perl(B::Xref) = 1.06 \
-Provides: perl(Benchmark) = 1.22 \
-Provides: perl(Class::Struct) = 0.65 \
-Provides: perl(Class::Struct::Tie_ISA) \
-Provides: perl(Config) = 5.026000 \
-Provides: perl(Config::Extensions) = 0.01 \
-Provides: perl(DB) = 1.08 \
-Provides: perl(DBM_Filter) = 0.06 \
-Provides: perl(DBM_Filter::compress) = 0.03 \
-Provides: perl(DBM_Filter::encode) = 0.03 \
-Provides: perl(DBM_Filter::int32) = 0.03 \
-Provides: perl(DBM_Filter::null) = 0.03 \
-Provides: perl(DBM_Filter::utf8) = 0.03 \
-Provides: perl(DirHandle) = 1.04 \
-Provides: perl(Dumpvalue) = 1.18 \
-Provides: perl(DynaLoader) = 1.42 \
-Provides: perl(EVERY::LAST) \
-Provides: perl(English) = 1.10 \
-Provides: perl(ExtUtils::Constant) = 0.23 \
-Provides: perl(ExtUtils::Constant::Base) = 0.05 \
-Provides: perl(ExtUtils::Constant::ProxySubs) = 0.08 \
-Provides: perl(ExtUtils::Constant::Utils) = 0.03 \
-Provides: perl(ExtUtils::Constant::XS) = 0.03 \
-Provides: perl(Fcntl) = 1.13 \
-Provides: perl(File::Basename) = 2.85 \
-Provides: perl(File::Compare) = 1.1006 \
-Provides: perl(File::Copy) = 2.32 \
-Provides: perl(File::DosGlob) = 1.12 \
-Provides: perl(File::Find) = 1.34 \
-Provides: perl(File::Glob) = 1.28 \
-Provides: perl(File::stat) = 1.07 \
-Provides: perl(FileCache) = 1.09 \
-Provides: perl(FileHandle) = 2.03 \
-Provides: perl(FindBin) = 1.51 \
-Provides: perl(GDBM_File) = 1.15 \
-Provides: perl(Getopt::Std) = 1.12 \
-Provides: perl(Hash::Util) = 0.22 \
-Provides: perl(Hash::Util::FieldHash) = 1.19 \
-Provides: perl(I18N::Collate) = 1.02 \
-Provides: perl(I18N::LangTags) = 0.42 \
-Provides: perl(I18N::LangTags::Detect) = 1.06 \
-Provides: perl(I18N::LangTags::List) = 0.39 \
-Provides: perl(I18N::Langinfo) = 0.13 \
-Provides: perl(IPC::Open2) = 1.04 \
-Provides: perl(IPC::Open3) = 1.20 \
-Provides: perl(NDBM_File) = 1.14 \
-Provides: perl(NEXT) = 0.67 \
-Provides: perl(NEXT::ACTUAL) \
-Provides: perl(NEXT::ACTUAL::DISTINCT) \
-Provides: perl(NEXT::ACTUAL::UNSEEN) \
-Provides: perl(NEXT::DISTINCT) \
-Provides: perl(NEXT::DISTINCT::ACTUAL) \
-Provides: 

ppisar pushed to perl (master). "Remove obsolete Group tags"

[notifications]

From 3f7d1e5123b8cced6e5c7b00918c76bb38b79f27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Wed, 28 Jun 2017 11:00:48 +0200
Subject: Remove obsolete Group tags

---
 perl.spec | 114 --
 1 file changed, 114 deletions(-)

diff --git a/perl.spec b/perl.spec
index 4fdb4f5..042b938 100644
--- a/perl.spec
+++ b/perl.spec
@@ -35,7 +35,6 @@
 %bcond_without test
 
 Name:   perl
-Group:  Development/Languages
 # These are all found licenses. They are distributed among various
 # subpackages.
 # dist/Tie-File/lib/Tie/File.pm:GPLv2+ or Artistic
@@ -315,7 +314,6 @@ details on the Perl decomposition into packages.
 
 %package interpreter
 Summary:Standalone executable Perl interpreter
-Group:  Development/Languages
 License:(GPL+ or Artistic) and (GPLv2+ or Artistic) and BSD and Public 
Domain and UCD
 # perl-interpreter denotes a package with the perl executable.
 # Full EVR is for compatibility with systems that swapped perl and perl-core
@@ -376,7 +374,6 @@ Perl utils like "splain" or "perlbug" can be found in 
perl-utils package.
 
 %package libs
 Summary:The libraries for the perl run-time
-Group:  Development/Languages
 License:(GPL+ or Artistic) and HSLR and MIT and UCD
 # Compat provides
 Provides:   %perl_compat
@@ -415,7 +412,6 @@ directories).
 
 %package devel
 Summary:Header #files for use in perl development
-Group:  Development/Languages
 # l1_char_class_tab.h is generated from lib/unicore sources:UCD
 License:(GPL+ or Artistic) and UCD
 # Require $Config{libs} providers, bug #905482
@@ -442,7 +438,6 @@ Most perl packages will need to install perl-devel to build.
 
 %package macros
 Summary:Macros for rpmbuild
-Group:  Development/Languages
 License:GPL+ or Artistic
 Requires:   %perl_compat
 %if %{defined perl_bootstrap}
@@ -457,7 +452,6 @@ by perl. Perl is needed because of git.
 
 %package tests
 Summary:The Perl test suite
-Group:  Development/Languages
 License:GPL+ or Artistic
 # right?
 AutoReqProv:0
@@ -477,7 +471,6 @@ modules).
 
 %package utils
 Summary:Utilities packaged with the Perl distribution
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
 Version:%{perl_version}
@@ -499,7 +492,6 @@ packages like perldoc by perl-Pod-Perldoc.
 %if %{dual_life} || %{rebuild_from_scratch}
 %package Archive-Tar
 Summary:A module for Perl manipulation of .tar files
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
 Version:2.24
@@ -528,7 +520,6 @@ gzipped tar files.
 
 %package Attribute-Handlers
 Summary:Simpler definition of attribute handlers
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
 Version:0.99
@@ -550,7 +541,6 @@ phases (i.e. in a "BEGIN", "CHECK", "INIT", or "END" block).
 %if %{dual_life} || %{rebuild_from_scratch}
 %package autodie
 Summary:Replace functions with ones that succeed or die
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
 Version:2.29
@@ -577,7 +567,6 @@ autodie in preference to "Fatal".
 %if %{dual_life} || %{rebuild_from_scratch}
 %package B-Debug
 Summary:Walk Perl syntax tree, print debug information about op-codes
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
 Version:1.24
@@ -594,7 +583,6 @@ B::Concise and B::Terse for other details.
 
 %package bignum
 Summary:Transparent big number support for Perl
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
 Version:0.47
@@ -619,7 +607,6 @@ Epoch:  0
 # Real version 1.42
 Version:1.42
 License:GPL+ or Artistic
-Group:  Development/Libraries
 Requires:   %perl_compat
 Provides:   perl(Carp::Heavy) = %{version}
 %if %{defined perl_bootstrap}
@@ -643,7 +630,6 @@ but it is a good educated guess.
 %if %{dual_life} || %{rebuild_from_scratch}
 %package Compress-Raw-Bzip2
 Summary:Low-Level Interface to bzip2 compression library
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  0
 Version:2.074
@@ -658,7 +644,6 @@ It is used by IO::Compress::Bzip2.
 
 %package Compress-Raw-Zlib
 Summary:Low-Level Interface to the zlib compression library
-Group:  Development/Libraries
 License:(GPL+ or Artistic) and zlib
 Epoch:  0
 Version:2.074
@@ -675,7 +660,6 @@ It is used by IO::Compress::Zlib.
 %if %{dual_life} || %{rebuild_from_scratch}
 %package Config-Perl-V
 Summary:Structured data retrieval of perl -V output
-Group:  Development/Libraries
 License:GPL+ or Artistic
 Epoch:  

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Richard W.M. Jones]

On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
>  F29: packagers (of graphical applications) must create Flatpaks of
>   their applications if possible. They *may* keep standard RPM
>   packaging.

At least we see where this is going.

If RPMs of the graphical application work fine now, what on earth is
the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
of them - as already explained, sandboxing is orthogonal to packaging.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-XML-LibXML (master). "Rename perl dependency in scriptlets"

[notifications]

From 57c60f31f60494a43dc978dc874bad2b3b789e35 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 14 Jul 2017 09:15:30 +0200
Subject: Rename perl dependency in scriptlets

---
 perl-XML-LibXML.spec | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/perl-XML-LibXML.spec b/perl-XML-LibXML.spec
index 6b5dab9..94522cb 100644
--- a/perl-XML-LibXML.spec
+++ b/perl-XML-LibXML.spec
@@ -8,7 +8,7 @@ Name:   perl-XML-LibXML
 # it might not be needed anymore
 # this module is maintained, the other is not
 Version:2.0129
-Release:3%{?dist}
+Release:4%{?dist}
 Epoch:  1
 Summary:Perl interface to the libxml2 library
 Group:  Development/Libraries
@@ -76,9 +76,9 @@ BuildRequires:  perl(utf8)
 # Author test - Test::Kwalitee::Extra
 # Author test - Test::TrailingSpace
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-# Run-require "perl" because a triggerin script needs it.
+# Run-require "perl-interpreter" because a triggerin script needs it.
 Requires:   perl-interpreter
-Requires(preun):perl
+Requires(preun):perl-interpreter
 # threads and threads::shared are optional
 Provides:   perl-XML-LibXML-Common = %{version}
 Obsoletes:  perl-XML-LibXML-Common <= 0.13
@@ -136,6 +136,9 @@ fi
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Jul 14 2017 Petr Pisar  - 1:2.0129-4
+- Rename perl dependency in scriptlets
+
 * Thu Jul 13 2017 Petr Pisar  - 1:2.0129-3
 - perl dependency renamed to perl-interpreter
   
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-XML-LibXML.git/commit/?h=master=57c60f31f60494a43dc978dc874bad2b3b789e35
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[389-devel] Please review: poc - optional rust queue for ns events

[William Brown]

https://pagure.io/389-ds-base/issue/49325

https://pagure.io/389-ds-base/issue/raw/8ef878a1004308b10982350df76c0378063147024706bdc774bd8b755e07cd67-0001-Ticket-49325-Proof-of-concept-rust-tqueue-in-sds.patch

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1470196] mariadb library upgrade to 10.2 causes perl-DBD-MySQL FTBFS

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||Github
   ||perl5-dbi/DBD-mysql/issues/
   ||139



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1470196] mariadb library upgrade to 10.2 causes perl-DBD-MySQL FTBFS

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
External Bug ID||Github
   ||perl5-dbi/DBD-mysql/pull/13
   ||3



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org