date:20170717

Adam Williamson wrote:
> So, during the blocker review process in the last few cycles, we have
> several times come up against the unfortunate situation that a bug that
> in the usual course of events would block a release is discovered
> extremely late - say the day before the go/no-go meeting - and at least
> some folks have argued that it's sometimes appropriate to not block the
> release in this case.
> 
> This position has gained quite a bit of acceptance, and we agreed at
> the F26 Final go/no-go meeting to draft up some formal policy for this
> so we can make such decisions consistently and not in an ad hoc way
> that might lead to it becoming a loophole that gets abused.

IMHO, this is a slippery slope eroding the quality of Fedora just because 
some people are not willing to wait a week longer for their "fix". The 
argument that this steals time from the next cycle is also invalid, because 
the obvious answer there is: "Don't Do That Then" – the schedule for the 
next release needs to start from the ACTUAL release date of the current 
release, NOT the planned release.

There is at least one user a day asking on #fedora-kde about the Discover 
issue that you decided to ignore in violation of the process, and no doubt 
there are many more who don't bother asking and just wipe Fedora and install 
Kubuntu or Neon instead. The bug would have been trivial to fix.

A blocker ought to be a blocker, no matter when it is discovered and how 
long it takes to fix.

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: Graphical Applications as Flatpaks

Daniel P. Berrange wrote:
> Use of RPM is merely a particular historical choice of delivery mechanism,
> and certainly not the defining characteristic of what it means to be the
> Fedora distribution. For users consuming the Fedora desktop, the fact that
> they're using RPM is hidden away as an implementation detail behind the
> apps like GNOME software.

The choice of RPM as opposed to, say, dpkg/deb can be called "historical", 
but the concept of delivering packages with dependencies and automatic 
dependency resolution is very much a user-visible defining characteristic. 

Many Fedora users do not use GNOME Software. Several spins ship Dnfdragora 
as their package manager, which is based on DNF and RPM and actually shows 
dependencies. There are also many users using the dnf command line directly. 
And even the KDE equivalent of GNOME Software, Plasma Discover, now 
reportedly shows what dependencies it is going to install when you install a 
new package. (I don't know whether GNOME Software itself does that.)

And even if the UI tries to hide the difference, the inherent technical 
differences between RPMs and Flatpaks WILL be noticed by the user. Download 
sizes, behavior when a library is upgraded, etc.

> Upstream still has to choose what base layer(s) they build their
> application flatpak on top of, and thus Fedora is a clearly choice there.
> Fedora also still provides the infrastructure for building flatpaks,
> hosting to distribute and mirror them, review of flatpak image manifests,
> quality testing before release, and more. Essentially the things that
> Fedora already does for software provided via RPMs, are still beneficial
> to at least some extent when using flatpaks.

I think Fedora deserves to be much more than just a runtime that a container 
can choose to use within the container.

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: Graphical Applications as Flatpaks

2017-07-17 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Jul 18, 2017 at 02:58:52AM +0200, Kevin Kofler wrote:
> Daniel P. Berrange wrote:
> > Yeah, that last point is the real difficult issue, it forces you to keep
> > the RPM in parallel with the flatpak, unless we were to either change
> > RPM (yuk), or find a way to auto-generate a RPM wrapper around the flatpak
> > to pull in it contents.
> 
> You need to keep the RPM anyway because there are users out there (e.g., me) 
> who are NOT going to install a Flatpak, but demand native packages.

Kevin,

*please*, *please* tone down the negativity. You can "demand", but the
project is not bound by demands. You have to *convince* people. There
are good arguments to keep RPMs around, at least for the foreseeable future,
so don't burn them by non-technical posts.

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

Bastien Nocera wrote:
> However we end up doing it, I think it'd be better if we could do it
> without you, whatever it is you do for Fedora. We, and certainly I, don't
> want this level of toxicity and utter malfeasance on a mailing-list that
> I'm supposed to be subscribed to.
> 
> Please, do leave, so you don't have to endure our apparent incompetence.

Nicolas Mailhot has done a lot of work on font packaging and organizing the 
Fonts SIG. Asking an experienced contributor like him to leave is extremely 
rude. All the more because you are just shooting the messenger. And you 
yourself admitted that you did not even bother looking him up before ruling 
him dispensable.

This kind of toxic attitude is absolutely unacceptable. How about YOU leave 
instead?

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: Graphical Applications as Flatpaks

Jiří Eischmann wrote:
> I agree with Matt here, Fedora Project's mission (neither the old one,
> nor the new draft) doesn't say anything about RPM. RPM is just means to
> an end, not the goal. And I don't know why Fedora should be tied to RPM
> forever. Really successful brands don't die when their current solution
> stops being relevant, really successful brands are able to transition
> themselves and stay relevant as the market shifts.

You are implying there that RPM is (or will soon be) no longer relevant, 
which is just not true. Flatpak does NOT deliver equivalent functionality.

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: Graphical Applications as Flatpaks

Daniel P. Berrange wrote:
> Yeah, that last point is the real difficult issue, it forces you to keep
> the RPM in parallel with the flatpak, unless we were to either change
> RPM (yuk), or find a way to auto-generate a RPM wrapper around the flatpak
> to pull in it contents.

You need to keep the RPM anyway because there are users out there (e.g., me) 
who are NOT going to install a Flatpak, but demand native packages.

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: Graphical Applications as Flatpaks

Daniel P. Berrange wrote:
> I had to write a script to read the dnf planned transaction log and finish
> installing and erasing remaining packages, and manually run any %posttrans
> scripts.

Such a dnf-complete-transaction script would be a nice addition to DNF.

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: Graphical Applications as Flatpaks

Michael Stahl wrote:
> no, the worst case is this:
> 
> https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-when-system-has-hybrid-graphics-and-systemd-udev-is-in-update/

That was a one-time bug that is already fixed. It also affected only systems 
with hybrid graphics, lots of systems were not affected at all. And as I 
explained in my reply to Bastien Nocera, X crashing will still allow the 
update to complete if you use PackageKit or dnfdaemon.

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: Graphical Applications as Flatpaks

Bastien Nocera wrote:
> It's like you didn't listen to the arguments when this feature was
> implemented in Fedora years ago, and continue not to. You're wrong, and
> the fact that you keep insisting you're not is frankly intellectual
> dishonesty.

I am using online updates of RPMs all the time. How is it dishonest to say 
that it just works for me, when this is the fact?

> If you really believe you're correct, try to kill your X server in the
> middle of an upgrade...

That will actually not hurt at all if you upgrade through PackageKit (with a 
frontend like plasma-pk-updates that does online updates) or dnfdaemon (with 
Dnfdragora or Yumex-DNF), because those run outside of the X session, they 
are activated off the D-Bus system bus (not the session bus).

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

Blocker bug process proposal: waiving late-discovered blockers to next release

2017-07-17 Thread Adam Williamson

Hi, folks!

So, during the blocker review process in the last few cycles, we have
several times come up against the unfortunate situation that a bug that
in the usual course of events would block a release is discovered
extremely late - say the day before the go/no-go meeting - and at least
some folks have argued that it's sometimes appropriate to not block the
release in this case.

This position has gained quite a bit of acceptance, and we agreed at
the F26 Final go/no-go meeting to draft up some formal policy for this
so we can make such decisions consistently and not in an ad hoc way
that might lead to it becoming a loophole that gets abused.

So, here's my proposal for that. The actual guts of the 'review
blockers' process are kind of split between
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and 
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting , so we could
kinda document this in either, but my preference is for the former. I
propose we add a new section to
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process , called
'Exceptional cases' or similar, as a sub-section of the 'Reviewing
blocker bugs' section. This is my proposed text. Note that it also
covers another type of case we have occasionally come across in the
past, but similarly never specifically formulated.

##

=== Exceptional cases ===

Generally speaking, any bug that is agreed to be a violation of the
[[Fedora Release Criteria|release criteria]] should be accepted as a
blocker bug for the next relevant milestone release.

However, as explained in the [[Fedora_Release_Life_Cycle|Fedora life
cycle page]] and the
[[Fedora_Release_Criteria#Release_Constraints|release criteria]], we
consider Fedora's release process not to be strictly based on time
''or'' strictly based on quality, but to take both into consideration.
This can mean that, in some exceptional circumstances, we may agree
that a bug constitutes a sufficient violation of the release criteria
that it would ordinarily be accepted as a blocker bug for the next
milestone release, but in fact accept it as a blocker bug for a later
milestone release.

There are currently two established circumstances in which this may
occur.

Firstly, it may occur if it is agreed to be very unlikely that the bug
can possibly be fixed within a reasonable time frame for the release to
be made. For instance, fixing the bug may be a task of such technical
complexity that it cannot possibly be achieved for several weeks or
months, and it may be held that such a delay would be too disruptive to
Fedora's development to be justified.

Secondly, it may occur if the bug is discovered very late in the
release validation process. Sometimes, a relatively less important
blocker bug (such as a non-vital default installed application on a
release-blocking medium failing to run, for instance) may only be found
very near the end of the release validation process, too late for it to
be reasonably possible to fix it without delaying the release. Again,
we may make the determination that in such a case it is preferable to
go ahead with the release rather than delay it to fix such a late-
discovered bug.

All such cases must be evaluated and discussed by the usual parties
(usually at a blocker bug review meeting) and all relevant factors must
be taken into account, much like the discussion of a bug that is a
'conditional' violation of the release criteria. At least the following
will almost always be relevant:

* The severity and likely prevalence of the bug
* Whether the bug could, or should, have been discovered earlier
* How long the release in question has already been delayed
* Whether delaying the release may give us an opportunity to carry out
other desirable work
* The possible effects of the expected delay (to Fedora itself, and
also to other things influenced by Fedora's schedules, including
downstream projects)

It is expected that in almost 'exceptional' cases, the bug will be
accepted as a blocker either for the very next milestone release, or
for the equivalent milestone for the next release (e.g. if this
'exceptional' provision is agreed to apply to a bug that otherwise
would have blocked {{FedoraVersion|long|next}} Final, it should be
accepted as a blocker either for {{FedoraVersion|long|next2}} Alpha or
{{FedoraVersion|long|next2}} Final).

#

That's a bit wordy (suggestions for cutting it down are appreciated!),
but I think it covers all the salient points. Thoughts? Concerns?
Suggestions? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: pass 1 gcc 7 shadow warns

2017-07-17 Thread William Brown

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

https://pagure.io/389-ds-base/issue/raw/ca882e9e8cb106549f4eaad1cc62e4bf96647ba53888ef1879b81a40f3a17146-0001-Ticket-49275-shadow-warnings-for-gcc7-pass-1.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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

Dusty Mabe wrote:
> I'm sure some people are aware but for those who aren't it is worth noting
> that we have an entire edition (atomic host) that is built around atomic
> updates for rpm content.

Atomic updates for "rpm content", but not for actual RPMs, unfortunately, 
only for blobs composed on the server side from an unchangeable set of RPMs. 
So it does not solve the problem at all.

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: Graphical Applications as Flatpaks

Daniel Walsh wrote:
> I read this like containers are something new and interesting.

Nope, we are saying they are something new and uninteresting. ;-)

> Upstream docker project started this effort a few years ago and the world
> has latched onto it.  Fedora needs to adjust and become great at
> containers.

Why? Just because "the world has latched onto it", for some definition of 
"the world", even if it does not bring us any benefit (because we already 
have distribution technologies that are far superior)?

> Some of the interesting work we have been doing with atomic host, and
> atomic workstation is great.

You and I clearly do not have the same definition of "great".

> We don't have to continue to do things the way we have for 20 years.

But we also don't have to stop doing things the way we have been doing with 
no issues for 20 years. Especially when the overhyped replacement is 
actually worse and does away with the most important feature of our existing 
software delivery mechanism (shared dependencies with automatic dependency 
resolution).

> I believe Fedora needs to be at the forefront of figuring out these
> container issues.

Then it should be at the forefront of figuring out how to build virtual 
containers from packaged content in /usr (as has been discussed elsewhere in 
this thread) rather than shipping container blobs duplicating the world.

> Flatpacks integration into the desktop gives us the potential of a great
> leap forwards in security.  Imagine if Fedora finally fixes the biggest
> security issue of the desktop by running browsers in containers, in a
> truly secure manner with it fully integrated, not hacked up like it is
> in the SELinux Sandbox or by running docker images like Jess Frazelle was.

My browser (QupZilla) is already sandboxed, without SELinux, without Docker, 
and without Flatpak. (It uses the Chromium seccomp sandbox.)

> The stuff that flatpack is doing has been very good.

You and I clearly do not have the same definition of "very good".

> Colin Walters work on ostree and rpm-ostree is looking into how we can
> do offline updates already and yet this discussion is ignoring it.  This
> stuff is great and it is currently controlled by Fedora we should be
> taking advantage of it. I run the atomic workstation now and am running
> flatpack, as well as development environments in containers.  I feel
> some pain, but we are learning how to deal with it.

If you are a masochist, that is your problem. You don't have to force this 
on all Fedora users.

The ostree technology removes the possibility to make any changes to the 
base packages from the user, which makes it an extremely inflexible delivery 
method. I do not want to use ostree, not now, not ever.

> We need to learn to live with combinations of rpm packages, ostree
> distributions and containers running on Fedora.

We don't need to at all. RPM will continue working, if it does not get 
deliberately sabotaged by the proponents of containers.

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

[Bug 1470205] CVE-2017-10672 perl-XML-LibXML: Use-after-free by controlling the arguments to a replaceChild call [ fedora-all]

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



--- Comment #7 from Fedora Update System  ---
perl-XML-LibXML-2.0129-2.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-3d5354d30f

-- 
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 1471443] perl-Module-CoreList-5.20170715 is available

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



--- Comment #7 from Fedora Update System  ---
perl-Module-CoreList-5.20170715-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-b8e76e4e05

-- 
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 1471500] perl-Module-Runtime-0.015 is available

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



--- Comment #9 from Fedora Update System  ---
perl-Module-Runtime-0.015-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-6c1aa99ce7

-- 
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 1471440] perl-CPAN-Perl-Releases-3.28 is available

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



--- Comment #6 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.28-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-a1fd7d484b

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

On Mon, Jul 17, 2017 at 05:02:42PM -0500, Michael Catanzaro wrote:
> I think that's probably worthwhile. The way I see it, we have a
> large number of users who prefer an entirely RPM-based system,
> although most users would be better off with an Atomic system and
> just layering a few RPMs on top. I suspect we can satisfy both
> groups of users while doing only a minimal amount of work. Making
> patches conditional is not so hard.

I definitely would like to see as much "magic" and infrastructure
support as we can muster for this, so we avoid the complication of SCL
macros -- the original idea there was that the same spec files could be
used for non-SCL packages, and it got so complex that that didn't
really pan out.

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

2017-07-17 Thread Owen Taylor

On Fri, 2017-07-14 at 21:29 +0200, Lars Seipel wrote:
> 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

I think you've found a note in the docs pointing out one spot where
things aren't completely solved yet, and taken that as an example of a
huge class of problem, while that huge class of problems actually does
not exist.

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

You are over-estimating the amount of separate files that need to be
visible to an application. Other than their own files, most
applications just read standard files out of /etc, and those can be
propagated or stubbed out as necessary.

One big advantage of the namespace approach over the SELinux or seccomp
approach to create a sandbox is that if an application looks for some
file that is not exposed to the sandbox, it's just not there - it's not
a permission error or a crash.

But, yes, complex applications will not just sandbox as is - and to fix
that poking holes is not sufficient - you need to find safe ways of
doing the same things. The Flatpak model is to expect code changes in
applications, and expect that those code changes will happen upstream.

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

2017-07-17 Thread Michael Catanzaro

On Mon, Jul 17, 2017 at 3:38 AM, Kevin Kofler  
wrote:

The problem is that the RPMs that go into the Flatpaks are not FHS-
compliant, so the RPMs will have to carry some conditionals and be 
built

twice.


Yes, that is true. Some apps will have to be patched for Flatpak, and 
building them as both RPMs and Flatpaks is going to require 
conditionals. So there will be some overhead if we support both.


I think that's probably worthwhile. The way I see it, we have a large 
number of users who prefer an entirely RPM-based system, although most 
users would be better off with an Atomic system and just layering a few 
RPMs on top. I suspect we can satisfy both groups of users while doing 
only a minimal amount of work. Making patches conditional is not so 
hard.


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

[Fedocal] Reminder meeting : Modularity Office Hours

2017-07-17 Thread nils

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2017-07-18 from 10:00:00 to 11:00:00 US/Eastern
   At https://meet.jit.si/fedora-modularity

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

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

[Bug 1470205] CVE-2017-10672 perl-XML-LibXML: Use-after-free by controlling the arguments to a replaceChild call [ fedora-all]

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



--- Comment #6 from Fedora Update System  ---
perl-XML-LibXML-2.0129-2.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-534f300508

-- 
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 1471500] perl-Module-Runtime-0.015 is available

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



--- Comment #8 from Fedora Update System  ---
perl-Module-Runtime-0.015-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-f95c5d9fae

-- 
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 1471440] perl-CPAN-Perl-Releases-3.28 is available

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



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.28-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-798f1cd92e

-- 
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 1471443] perl-Module-CoreList-5.20170715 is available

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



--- Comment #6 from Fedora Update System  ---
perl-Module-CoreList-5.20170715-1.fc25 has been pushed to the Fedora 25 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-c13221b431

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

2017-07-17 Thread Owen Taylor

On Mon, 2017-07-17 at 17:51 +0200, nicolas.mail...@laposte.net wrote:
> >  There's a
> > burning the ships sort of appeal in that approach,
> 
> Actually, the correct analogy would be "burning platform" (and we all
> know how well that ended).


I almost certainly should avoid responding to such an intentionally
inflammatory mail, but...

[...]

> Even if it eventually succeeds crash-landing it in Fedora while half
> the security and management tools are lacking is a great way for the
> distribution to get an awful reputation, while others will rip the
> fruits of this work some years later.

I'm entirely puzzled about how you think we could possibly land Flatpak
support in Fedora well integrated with our infrastructure, and our
security and management tools without starting to work on it, which is
essentially what this change proposal is about

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

[Bug 1471443] perl-Module-CoreList-5.20170715 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Module-CoreList-5.20170715-1.fc24 has been pushed to the Fedora 24 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9d333e0dc1

-- 
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 1470205] CVE-2017-10672 perl-XML-LibXML: Use-after-free by controlling the arguments to a replaceChild call [ fedora-all]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-XML-LibXML-2.0128-2.fc24 has been pushed to the Fedora 24 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-790ff602a6

-- 
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 1471440] perl-CPAN-Perl-Releases-3.28 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.28-1.fc24 has been pushed to the Fedora 24 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-212c5aec20

-- 
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 1471500] perl-Module-Runtime-0.015 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
perl-Module-Runtime-0.015-1.fc24 has been pushed to the Fedora 24 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f89173832

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

2017-07-17 Thread Owen Taylor

On Sat, 2017-07-15 at 13:43 -0400, Matthew Miller wrote:
> On Fri, Jul 14, 2017 at 02:56:34PM -0700, Andrew Lutomirski wrote:
> > 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 don't agree. With this model, every time you try to do something,
> you're bombarded with questions asking if you want to do the thing
> you tried to do. It gets very easy to fall into a default of clicking
> a bunch of yesses all the time. That serves no *real* security
> benefit and yet adds to user annoyance. There's gotta be a better way
> than that.

Flatpak doesn't really use either the old or new Android model - it
*does* try to have a better way of doing things.

There are a static set of upfront permissions that are associated with
the application - this is likely what Andy is thinking of. While they
are reasonably fine-grained, they are low-level we are unlikely to
present them in the user's default view as more than "sandboxed" vs.
"unsandboxed" - some permissions can be considered to be pretty safe
(talk to Wayland, talk to the external network), and others entirely
not safe (talk to X11, read/write the user's home directory.)

These are not going to be used for things like "can read and write my
contacts", "can access my computer's camera", and whatever else Android
bugs you about - those use cases are handled by portals.

The primary user interaction of a portal is to show a user interface
for the task (opening a file, sending an email, printing, etc.) - and
let the user decide if they want to proceed or not. In the minority of
case where this doesn't make much sense - say access to GPS - then the
portal asks the user similar to the new Android style and implements
smart memory behavior.

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

[Bug 1467123] perl-PDF-API2-2.032 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-PDF-API2-2.032-1.fc27  |perl-PDF-API2-2.032-1.fc27
   |perl-PDF-API2-2.033-1.fc26  |perl-PDF-API2-2.033-1.fc26
   ||perl-PDF-API2-2.033-1.fc25



--- Comment #10 from Fedora Update System  ---
perl-PDF-API2-2.033-1.fc25 has been pushed to the Fedora 25 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1468565] perl-PDF-API2-2.033 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-PDF-API2-2.033-1.fc27  |perl-PDF-API2-2.033-1.fc27
   |perl-PDF-API2-2.033-1.fc26  |perl-PDF-API2-2.033-1.fc26
   ||perl-PDF-API2-2.033-1.fc25



--- Comment #7 from Fedora Update System  ---
perl-PDF-API2-2.033-1.fc25 has been pushed to the Fedora 25 stable repository.
If problems still persist, please make note of it in this bug report.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

2017-07-17 Thread Daniel Walsh


On 07/17/2017 03:14 PM, Neal Gompa wrote:

On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl  wrote:

On 17.07.2017 19:26, Richard W.M. Jones wrote:

On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:

On 16.07.2017 12:54, Richard W.M. Jones wrote:

On Fri, Jul 14, 2017 at 04:59:37PM +, Debarshi Ray wrote:

On Fri, Jul 14, 2017 at 09:44:18AM +0100, 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.

Huh? How would you get sandboxing without Flatpaks? Unless you are
proposing a different sandboxing technology.

Things like libvirt-sandbox have been around for a really long time
and don't require special packaging (in fact they work with any
arbitrary command).

reading between the lines of the fine documentation, there is no mention
of X11 or GUI applications, so i guess "arbitrary" is a bit of an
exaggeration?

It seems like it's not mentioned in the docs, but it does work as in
this example of running evince to view a suspect PDF file:

   https://honk.sigxcpu.org/con/More_sandboxing.html

says:

 Note that the above example shares /tmp with the sandbox in order to
give it access to the X11 socket. A better isolation can probably be
achieved using xpra or xvnc but I haven't looked into this yet.

so it doesn't actually sandbox very much, with access to the X11 socket
the app can keylog and inject shell commands into terminal windows as
much as it likes.


BTW libvirt sandbox allows either full-virt or container sandboxing.

i'd hope if you don't use containers but full-virt it's going to use
something more secure, like SPICE or something to display the GUI?

but i'd call virtualization a bit of a heavy-weight approach.

... there's more prior art, the SELinux "sandbox -X", which at least
starts a nested Xephyr for your convenience.

http://danwalsh.livejournal.com/31146.html
http://danwalsh.livejournal.com/31247.html

these have in common that they're generally not very user friendly: you
have to set up which files the program will have access to when you
start it; also copy/paste probably doesn't work between the nested X
server, which may or may not be a feature.

FlatPak portals have the potential to be more user friendly since you
can use the application's normal file picker to open files and the
application only gets access to the file the user chooses.

Portals themselves are orthogonal to the Flatpak distribution
mechanism. They can be used with regular applications too.



I read this like containers are something new and interesting. Upstream 
docker project started this effort a few years ago and the world has 
latched onto it.  Fedora needs to adjust and become great at 
containers.  Some of the interesting work we have been doing with atomic 
host, and atomic workstation is great.  We don't have to continue to do 
things the way we have for 20 years.  I believe Fedora needs to be at 
the forefront of figuring out these container issues.  Flatpacks 
integration into the desktop gives us the potential of a great leap 
forwards in security.  Imagine if Fedora finally fixes the biggest 
security issue of the desktop by running browsers in containers, in a 
truly secure manner with it fully integrated, not hacked up like it is 
in the SELinux Sandbox or by running docker images like Jess Frazelle was.


The stuff that flatpack is doing has been very good.

Colin Walters work on ostree and rpm-ostree is looking into how we can 
do offline updates already and yet this discussion is ignoring it.  This 
stuff is great and it is currently controlled by Fedora we should be 
taking advantage of it. I run the atomic workstation now and am running 
flatpack, as well as development environments in containers.  I feel 
some pain, but we are learning how to deal with it.


We need to learn to live with combinations of rpm packages, ostree 
distributions and containers running on Fedora.


___
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

2017-07-17 Thread Neal Gompa

On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl  wrote:
> On 17.07.2017 19:26, Richard W.M. Jones wrote:
>> On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
>>> On 16.07.2017 12:54, Richard W.M. Jones wrote:
 On Fri, Jul 14, 2017 at 04:59:37PM +, Debarshi Ray wrote:
> On Fri, Jul 14, 2017 at 09:44:18AM +0100, 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.
>
> Huh? How would you get sandboxing without Flatpaks? Unless you are
> proposing a different sandboxing technology.

 Things like libvirt-sandbox have been around for a really long time
 and don't require special packaging (in fact they work with any
 arbitrary command).
>>>
>>> reading between the lines of the fine documentation, there is no mention
>>> of X11 or GUI applications, so i guess "arbitrary" is a bit of an
>>> exaggeration?
>>
>> It seems like it's not mentioned in the docs, but it does work as in
>> this example of running evince to view a suspect PDF file:
>>
>>   https://honk.sigxcpu.org/con/More_sandboxing.html
>
> says:
>
> Note that the above example shares /tmp with the sandbox in order to
> give it access to the X11 socket. A better isolation can probably be
> achieved using xpra or xvnc but I haven't looked into this yet.
>
> so it doesn't actually sandbox very much, with access to the X11 socket
> the app can keylog and inject shell commands into terminal windows as
> much as it likes.
>
>> BTW libvirt sandbox allows either full-virt or container sandboxing.
>
> i'd hope if you don't use containers but full-virt it's going to use
> something more secure, like SPICE or something to display the GUI?
>
> but i'd call virtualization a bit of a heavy-weight approach.
>
> ... there's more prior art, the SELinux "sandbox -X", which at least
> starts a nested Xephyr for your convenience.
>
> http://danwalsh.livejournal.com/31146.html
> http://danwalsh.livejournal.com/31247.html
>
> these have in common that they're generally not very user friendly: you
> have to set up which files the program will have access to when you
> start it; also copy/paste probably doesn't work between the nested X
> server, which may or may not be a feature.
>
> FlatPak portals have the potential to be more user friendly since you
> can use the application's normal file picker to open files and the
> application only gets access to the file the user chooses.

Portals themselves are orthogonal to the Flatpak distribution
mechanism. They can be used with regular applications too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: git - wrong paths in documentation files

2017-07-17 Thread Todd Zullinger

Hi Petr,

Petr Stodulka wrote:

Hi folks,
I am looking at the #1357438 BZ about broken links to "How to*" doc files and I am thinking,
about the best solution of this. Problem is with using of %doc macro, which moves/copies
doc files to specific directories of each subpackage. However the Makefile expects that will
be used just one directory, where all documentation will be included.

It can be fixed basically in two ways:

1) Do not use %doc macro and keep all Doc files under common directory,
e.g. /usr/share/doc/git/
ignoring the sub-package that install specific doc files.

2) Use sed for affected doc files to modify path correctly.

The 1st method seems much better for me, because doc files will be together and in case of changes
of doc files or another split/rename/merge of packages, it will be still OK. The 2nd method would
provide incompatible solution in future when another changes in doc files will be provided or
split of packages will be different.

I haven't seen any requirement in packaging guidelines, that we have to put all files to specific
directories bounded with specific subpackage, so why do not use '/usr/share/doc/git'?. The third option
would be create symlink, but that solution seems ugly to me.

What do you think? In case we will want to change filelist, I would prefer make this change in F26
yet too.

I also think that all the docs belong in /usr/share/doc/git.

There was a thread on either devel or packaging a year or so ago
regarding interations between using %doc in %files and manually
placing files in %docdir. I don't know if that will come up here or
not. It's easy enough to check the rpm contents after any changes to
the file list though.

--
Todd
~~
I don't mind arguing with myself. It's when I lose that it bothers me.
-- Richard Powers

signature.asc
Description: PGP signature
___
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

2017-07-17 Thread Michael Stahl

On 17.07.2017 19:26, Richard W.M. Jones wrote:
> On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
>> On 16.07.2017 12:54, Richard W.M. Jones wrote:
>>> On Fri, Jul 14, 2017 at 04:59:37PM +, Debarshi Ray wrote:
 On Fri, Jul 14, 2017 at 09:44:18AM +0100, 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.

 Huh? How would you get sandboxing without Flatpaks? Unless you are
 proposing a different sandboxing technology.
>>>
>>> Things like libvirt-sandbox have been around for a really long time
>>> and don't require special packaging (in fact they work with any
>>> arbitrary command).
>>
>> reading between the lines of the fine documentation, there is no mention
>> of X11 or GUI applications, so i guess "arbitrary" is a bit of an
>> exaggeration?
> 
> It seems like it's not mentioned in the docs, but it does work as in
> this example of running evince to view a suspect PDF file:
> 
>   https://honk.sigxcpu.org/con/More_sandboxing.html

says:

Note that the above example shares /tmp with the sandbox in order to
give it access to the X11 socket. A better isolation can probably be
achieved using xpra or xvnc but I haven't looked into this yet.

so it doesn't actually sandbox very much, with access to the X11 socket
the app can keylog and inject shell commands into terminal windows as
much as it likes.

> BTW libvirt sandbox allows either full-virt or container sandboxing.

i'd hope if you don't use containers but full-virt it's going to use
something more secure, like SPICE or something to display the GUI?

but i'd call virtualization a bit of a heavy-weight approach.

... there's more prior art, the SELinux "sandbox -X", which at least
starts a nested Xephyr for your convenience.

http://danwalsh.livejournal.com/31146.html
http://danwalsh.livejournal.com/31247.html

these have in common that they're generally not very user friendly: you
have to set up which files the program will have access to when you
start it; also copy/paste probably doesn't work between the nested X
server, which may or may not be a feature.

FlatPak portals have the potential to be more user friendly since you
can use the application's normal file picker to open files and the
application only gets access to the file the user chooses.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

git - wrong paths in documentation files

2017-07-17 Thread Petr Stodulka


Hi folks,
I am looking at the #1357438 BZ about broken links to "How to*" doc files and I 
am thinking,
about the best solution of this. Problem is with using of %doc macro, which 
moves/copies
doc files to specific directories of each subpackage. However the Makefile 
expects that will
be used just one directory, where all documentation will be included.

It can be fixed basically in two ways:

  1) Do not use %doc macro and keep all Doc files under common directory,
   e.g. /usr/share/doc/git/
 ignoring the sub-package that install specific doc files.

  2) Use sed for affected doc files to modify path correctly.

The 1st method seems much better for me, because doc files will be together and 
in case of changes
of doc files or another split/rename/merge of packages, it will be still OK. 
The 2nd method would
provide incompatible solution in future when another changes in doc files will 
be provided or
split of packages will be different.

I haven't seen any requirement in packaging guidelines, that we have to put all 
files to specific
directories bounded with specific subpackage, so why do not use 
'/usr/share/doc/git'?. The third option
would be create symlink, but that solution seems ugly to me.

What do you think? In case we will want to change filelist, I would prefer make 
this change in F26
yet too.

Thanks for feedback/advice,
 Petr





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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

2017-07-17 Thread Dusty Mabe



On 07/14/2017 05:04 PM, Richard Hughes wrote:
> 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.

I'm sure some people are aware but for those who aren't it is worth noting 
that we have an entire edition (atomic host) that is built around atomic 
updates for rpm content. We are starting to make progress with a workstation
variant that is built on the same technology.

[1] https://getfedora.org/atomic/download/
[2] 
https://download.fedoraproject.org/pub/fedora/linux/releases/26/Workstation/x86_64/iso/Fedora-Workstation-ostree-x86_64-26-1.5.iso
___
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

2017-07-17 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Jul 17, 2017 at 09:48:46AM +0100, Daniel P. Berrange wrote:
> On Sat, Jul 15, 2017 at 05:17:44PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Jul 14, 2017 at 03:42:15PM +0100, Daniel P. Berrange wrote:
> > > 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.
> > 
> > This depends on how exactly flatpacks are built:
> > - if first an rpm is built, and then flatpack is built out of rpms,
> >   it's strictly more work (although there are benefits to users of 
> > installing
> >   using flatpacks over plain rpms, so it's an actual benefit for users
> >   and hence not pointless).
> > 
> > - if one is building a _leaf_ application, and all deps are available as
> >   rpms, then the packager doesn't need to follow the strict rpm rules,
> >   and if they only build a flatpack without the intermediate rpm,
> >   some work is saved.
> > 
> > - if one is building an application that anything else depends on, things
> >   get more complicated.
> >   (Let's take inkscape as an example: it's a end-user graphical application,
> >   but it has command-line mode where it converts svgs to pngs and such,
> >   so it might be used e.g. when generating documentation or in %check
> >   for another package.)
> > 
> >   If inkscape is still available as rpm, it can be used as a dep in building
> >   other rpms. If however inkscape suddenly becomes available only as a 
> > flatpack,
> >   how does that work? Do we allow rpms to specify BuildRequires: 
> > inkscape.flatpack,
> >   and koji will install it

Re: Spam

2017-07-17 Thread Naheem Zaffar

I have received a few on the development mailing list.

On 17 Jul 2017 6:48 pm,  wrote:

> On Mon, Jul 17, 2017 at 12:41 PM, Samuel Sieb  wrote:
>
>> I haven't seen any spam on the devel list.  I even checked my spam
>> folder.  Maybe the messages are being sent directly to you, not the list?
>>
>
> They're being sent to 389-de...@lists.fedoraproject.org (whatever that
> is). I can see in the mail headers that they're passing through Fedora's
> SMPT servers and failing spam checks. I assume the spam checks lose out to
> Kevin being subscribed to the list.
>
> Michael
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Spam

2017-07-17 Thread mcatanzaro


On Mon, Jul 17, 2017 at 12:41 PM, Samuel Sieb  wrote:
I haven't seen any spam on the devel list.  I even checked my spam 
folder.  Maybe the messages are being sent directly to you, not the 
list?


They're being sent to 389-de...@lists.fedoraproject.org (whatever that 
is). I can see in the mail headers that they're passing through 
Fedora's SMPT servers and failing spam checks. I assume the spam checks 
lose out to Kevin being subscribed to the list.


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

2017-07-17 Thread Bastien Nocera

"We" in this case is me, my Red Hat colleagues working on GNOME, Fedora 
Workstation, upstream developers involved in Fedora Workstation and upstream 
developers who are not involved in Fedora, usually because of answers like this.

I'm also fine with you leaving. In fact, that's probably a request I made to a 
number of Fedora decision makers.

This has nothing to do with the apparent technical discussion and everything to 
do with the tone and vocabulary used. If you think we're that incompetent, or 
full of ourselves, then please, do leave, and show us how great you and your 
ideas are because I'm not, and we are not, going anywhere.

- Original Message -
> 
> 
> Am 17.07.2017 um 18:58 schrieb Bastien Nocera:
> >> 1. make flatpacked sofware behave like rpms in all the rpm-centric
> >> management
> >> tools, and remove the rpm layer only when everyone *in* *the* *Fedora*
> >> *universe* agrees it is not needed anymore and the replacements are
> >> better.
> >> 2. make a wayland, not a gnome 3.0
> > 
> > However we end up doing it, I think it'd be better if we could do it
> > without
> > you, whatever it is you do for Fedora. We, and certainly I, don't want this
> > level of toxicity and utter malfeasance on a mailing-list that I'm supposed
> > to be subscribed to.
> > 
> > Please, do leave, so you don't have to endure our apparent incompetence
> 
> who you you think you are?
> 
> that "we" includes the userbase GNOME centric people tend to forget and
> if you are not careful enough the "we" could remain some people making a
> distribution for their own usecase without a userbase
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Spam

2017-07-17 Thread Stephen John Smoogen

On 17 July 2017 at 13:34,   wrote:
> Hi,
>
> Do the list admins have any plans to combat the spammers that are spoofing
> Kevin Fenzi to bypass the moderation queue?
>

We are aware of this and have been dealing with whack-a-mole in trying
to fix it.

> Could we please at least hold his messages for moderation? Maybe he could
> manually approve his own messages, as annoying as that would be. Though I
> don't know what we would do if they start spoofing anyone else.
>

At this point they are hitting the lists with various names and kevin
has worked so far. I expect they will just move to anyone else
afterwords.

> They're hitting desktop@ too, so we need to take care of both lists.

They are hitting all the lists.

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



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

Re: Spam

2017-07-17 Thread Athos Ribeiro

On Mon, Jul 17, 2017 at 10:41:13AM -0700, Samuel Sieb wrote:
> I haven't seen any spam on the devel list.  I even checked my spam folder.
> Maybe the messages are being sent directly to you, not the list?

I am getting those messages as well :)

-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Spam

2017-07-17 Thread Samuel Sieb


On 07/17/2017 10:34 AM, mcatanz...@gnome.org wrote:
Do the list admins have any plans to combat the spammers that are 
spoofing Kevin Fenzi to bypass the moderation queue?


Could we please at least hold his messages for moderation? Maybe he 
could manually approve his own messages, as annoying as that would be. 
Though I don't know what we would do if they start spoofing anyone else.


They're hitting desktop@ too, so we need to take care of both lists.


I haven't seen any spam on the devel list.  I even checked my spam 
folder.  Maybe the messages are being sent directly to you, not the list?

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

Spam

2017-07-17 Thread mcatanzaro


Hi,

Do the list admins have any plans to combat the spammers that are 
spoofing Kevin Fenzi to bypass the moderation queue?


Could we please at least hold his messages for moderation? Maybe he 
could manually approve his own messages, as annoying as that would be. 
Though I don't know what we would do if they start spoofing anyone else.


They're hitting desktop@ too, so we need to take care of both lists.

Michael


___
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

2017-07-17 Thread Bastien Nocera



- Original Message -
> On Sun, Jul 16, 2017 at 11:13:28PM +0200, Kevin Kofler wrote:
> > Matthew Miller wrote:
> > > I strongly dispute the idea that Fedora must be tied to a particular
> > > packaging technology.
> > 
> > The particular packaging technology is what ensures that we have a
> > coherent,
> > integrated system. Flatpaks by design cannot offer the kind of integration
> > that native packages can offer, neither in terms of using shared system
> > libraries (saving space), nor in terms of user experience (even with
> > "portals", there will always be kinds of interoperation that the sandbox
> > just cannot allow).
> > 
> > And if the users will get their packages in a generic format rather than a
> > native Fedora format, what advantage do they get from getting it from
> > Fedora
> > to begin with? The point of delivering Fedora packages is to integrate them
> > into the distribution. Only native packages can provide that.
> 
> Exactly, upstreams might as well just deliver .zip files which unpack
> into a single directory and provide a ./application.sh script to set
> up the LD_LIBRARY_PATH and cgroups right.  That's basically what we're
> talking about here when you strip it back to the essentials.

That's about as accurate as me saying that virtualisation is essentially
using the CPU's builtin virtualisation functionality when you strip it back
to the essentials.
___
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

2017-07-17 Thread Richard W.M. Jones

On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
> On 16.07.2017 12:54, Richard W.M. Jones wrote:
> > On Fri, Jul 14, 2017 at 04:59:37PM +, Debarshi Ray wrote:
> >> On Fri, Jul 14, 2017 at 09:44:18AM +0100, 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.
> >>
> >> Huh? How would you get sandboxing without Flatpaks? Unless you are
> >> proposing a different sandboxing technology.
> > 
> > Things like libvirt-sandbox have been around for a really long time
> > and don't require special packaging (in fact they work with any
> > arbitrary command).
> 
> reading between the lines of the fine documentation, there is no mention
> of X11 or GUI applications, so i guess "arbitrary" is a bit of an
> exaggeration?

It seems like it's not mentioned in the docs, but it does work as in
this example of running evince to view a suspect PDF file:

  https://honk.sigxcpu.org/con/More_sandboxing.html

BTW libvirt sandbox allows either full-virt or container sandboxing.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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

2017-07-17 Thread Richard W.M. Jones

On Sun, Jul 16, 2017 at 11:13:28PM +0200, Kevin Kofler wrote:
> Matthew Miller wrote:
> > I strongly dispute the idea that Fedora must be tied to a particular
> > packaging technology.
> 
> The particular packaging technology is what ensures that we have a coherent, 
> integrated system. Flatpaks by design cannot offer the kind of integration 
> that native packages can offer, neither in terms of using shared system 
> libraries (saving space), nor in terms of user experience (even with 
> "portals", there will always be kinds of interoperation that the sandbox 
> just cannot allow).
> 
> And if the users will get their packages in a generic format rather than a 
> native Fedora format, what advantage do they get from getting it from Fedora 
> to begin with? The point of delivering Fedora packages is to integrate them 
> into the distribution. Only native packages can provide that.

Exactly, upstreams might as well just deliver .zip files which unpack
into a single directory and provide a ./application.sh script to set
up the LD_LIBRARY_PATH and cgroups right.  That's basically what we're
talking about here when you strip it back to the essentials.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

2017-07-17 Thread Bastien Nocera



- Original Message -
> >  There's a
> > burning the ships sort of appeal in that approach,
> 
> Actually, the correct analogy would be "burning platform" (and we all know
> how well that ended).
> 
> Flatpacks are an unproven tech that can still crash and burn in the market.
> 
> Even if it eventually succeeds crash-landing it in Fedora while half the
> security and management tools are lacking is a great way for the
> distribution to get an awful reputation, while others will rip the fruits of
> this work some years later.
> 
> It would be nice, for once, if the desktop team could integrate its latest
> idea in the distribution, and remove deprecated parts once the replacements
> are mature, instead of forcing on everyone half-assed software, with half
> the bits missing, no alternatives, and years of bad blood while they insist
> it is good enough and users are wrong to expect working workflows (yay for
> echo chamber effects and devs agreeing with themselves they are right but
> persecuted).
> 
> ie:
> 1. make flatpacked sofware behave like rpms in all the rpm-centric management
> tools, and remove the rpm layer only when everyone *in* *the* *Fedora*
> *universe* agrees it is not needed anymore and the replacements are better.
> 2. make a wayland, not a gnome 3.0

However we end up doing it, I think it'd be better if we could do it without
you, whatever it is you do for Fedora. We, and certainly I, don't want this
level of toxicity and utter malfeasance on a mailing-list that I'm supposed
to be subscribed to.

Please, do leave, so you don't have to endure our apparent incompetence.
___
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

2017-07-17 Thread stan

On Mon, 17 Jul 2017 11:31:54 -0400
Matthew Miller  wrote:

> No one is talking about "ripping RPM out of Fedora".

I'm glad to hear it.  I have a tendency to hyperbole in this noisy
world.

On 07/10/2017 09:31 PM, Owen Taylor wrote:
>
>  F29: packagers (of graphical applications) must create Flatpaks of
>   their applications if possible. They *may* keep standard RPM
>   packaging.  

I interpreted this as such a death knell.  I think if it's not required,
it's on its way out.  It is a short step from there to

F31:  packagers of graphical applications must create Flatpacks of their
  applications, and standard RPM packaging will not be allowed for
  such applications.

That said, flatpaks might turn out to be the greatest thing since
sliced bread, and they certainly have their use cases, as described by
contributors to this thread.  In ten years, maybe everyone will be
using flatpak equivalent technology, and I'll be just another luddite
has been.
___
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

2017-07-17 Thread Richard Hughes

On 17 July 2017 at 15:11, Matthew Miller  wrote:
>> the whole operating system and no longer can compare the installed
>> packages of two machines with a single command
> Yeah, I agree that it's important to have a unified management
> interface like this.

I also agree, but I don't think the answer is "teach dnf about
flatpak". I'd need a whole heap of requirements, but certainly making
a tool that uses libgnomesoftware (there are no GTK deps before the
krazy crowd get all upset) would just be a few days of developer time.
It's not going to be as powerful as the flatpak CLI, nor the DNF CLI
but I don't think it needs to be.

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

2017-07-17 Thread nicolas . mailhot

>  There's a
> burning the ships sort of appeal in that approach,

Actually, the correct analogy would be "burning platform" (and we all know how 
well that ended).

Flatpacks are an unproven tech that can still crash and burn in the market.

Even if it eventually succeeds crash-landing it in Fedora while half the 
security and management tools are lacking is a great way for the distribution 
to get an awful reputation, while others will rip the fruits of this work some 
years later.

It would be nice, for once, if the desktop team could integrate its latest idea 
in the distribution, and remove deprecated parts once the replacements are 
mature, instead of forcing on everyone half-assed software, with half the bits 
missing, no alternatives, and years of bad blood while they insist it is good 
enough and users are wrong to expect working workflows (yay for echo chamber 
effects and devs agreeing with themselves they are right but persecuted).

ie:
1. make flatpacked sofware behave like rpms in all the rpm-centric management 
tools, and remove the rpm layer only when everyone *in* *the* *Fedora* 
*universe* agrees it is not needed anymore and the replacements are better.
2. make a wayland, not a gnome 3.0

Regards,

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

[Bug 1468565] perl-PDF-API2-2.033 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-PDF-API2-2.033-1.fc27  |perl-PDF-API2-2.033-1.fc27
   ||perl-PDF-API2-2.033-1.fc26
 Resolution|--- |ERRATA
Last Closed||2017-07-17 11:51:34



--- Comment #6 from Fedora Update System  ---
perl-PDF-API2-2.033-1.fc26 has been pushed to the Fedora 26 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1467123] perl-PDF-API2-2.032 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-PDF-API2-2.032-1.fc27  |perl-PDF-API2-2.032-1.fc27
   ||perl-PDF-API2-2.033-1.fc26
 Resolution|--- |ERRATA
Last Closed||2017-07-17 11:51:37



--- Comment #9 from Fedora Update System  ---
perl-PDF-API2-2.033-1.fc26 has been pushed to the Fedora 26 stable repository.
If problems still persist, please make note of it in this bug report.

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

Re: F27 System Wide Change: Graphical Applications as Flatpaks

2017-07-17 Thread Stephen John Smoogen

On 17 July 2017 at 10:10, Matthew Miller  wrote:
> On Sun, Jul 16, 2017 at 01:17:25PM -0400, Stephen John Smoogen wrote:
>> These sorts of deep brand issues are why most companies start new
>> brands which might look like they are competing with their primary
>> one. It can showcase some new identity and get people to see it as
>> useful or better than what they have already. It can also show where
>> things aren't going to work at all because people just aren't
>> interested in something. The Soap industry is a classic study in
>> brands where most people buy things because of something they tie to
>> the brand be it a logo, a smell, a look or even just the container it
>> comes in. Whenever the company changes those things, it causes
>> significant drop in sales and they are usually going back to what they
>> had. So instead a soap company will just start a new line with
>> whatever is different they want to see. No tie in with the original
>> soap. Sometimes that soap takes over and other times it just sits
>> there and goes away after 8 months.
>
> We could look at starting a new brand. But, I don't think your
> Harley-Davidson analogy applies, because we're not using this to break
> into a new market. We're using this to make sure that we remain

If you change something associated with your brand, you are making a
new market. It doesn't matter if we were going from RPM to
Flatpack+RPM or going from Blue to Purple. The people who associate
with the older brand are going to be shocked/bewildered/confused and
the new people are going to need to be convinced that RPM+Flatpack is
better than .deb+Snap.

Yes this isn't rational but humans are anything but rational. It is a
gut feeling and you need to use psychology to deal with it.

> relevant as the market we are in changes. Let's take the current shift
> to electric cars as a branding analogy — GM *could* have gone with a
> whole new name, but instead we have the Chevrolet Volt. (And Nissan
> Leaf. And Ford is even reusing the "Focus" name.)

Those are sub-brands where you can experiment on things.
GM -> Chevrolet -> Camaro
GM -> Chevrolet -> Corvette
GM -> Chevrolet -> Tahoe
GM -> Chevrolet -> Volt.

That is a branded name chain and it has a brand strategy of "You trust
Chevrolet and you trust GM. So you can trust the Volt because it came
from that chain". [Or the opposite if you don't like GM or
Chevrolet..] And if I go into a Chevrolet dealership I am going to
expect certain things because I know other Chevrolet cars. [4 wheels,
doors in regular spots, engine in the front, power, dealership help]
Fedora -> Workstation
Fedora -> Server
Fedora -> Atomic

sort of works in this context. However we are not taking the "we are
making the Volt" as a sub-brand. Instead we are saying "So all our
vehicles are going to be hybrids in 18 months." which is more of the
Volvo approach but they are going with a 4 year approach to get their
brand story in place about why and how they are doing it.

Look at all the pain and suffering that the dnf people have had to go
through for the last 3 years because dnf is not yum but it kept having
to be so because people expected it to be. Now multiply this by 10
because we are talking about something lower down in the guts where
everything from every spec file writing doc needs an update and every
'rpm -V' only covers some part of the OS.

Look I am not against moving this to a new format. I guess I am just
tired of the merry-go-round of "completely new feature that people say
will cause problems", "those are just complainers", "oh look we have
to rethink all these things and make it like what we had because those
complainers did have some legitimate concerns", "we had to miss our
market window because we were too aggressive", "well maybe if we come
up with this completely new feature..."

And with that I am going to bow out here as what I was hoping was
going to be "could we plan this out a bit longer" is coming across as
"stop". This wasn't helpful to the dnf people and burnt a good many
developers out completely from floss and I am not going to be part of
the burn out the flatpack group.

>
> I think this matches our current and upcoming challenge more closely.
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Stephen J Smoogen.
___
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

2017-07-17 Thread Jiří Eischmann

stan píše v Po 17. 07. 2017 v 08:02 -0700:
> On Mon, 17 Jul 2017 10:10:16 -0400
> Matthew Miller  wrote:
> 
> > We could look at starting a new brand. But, I don't think your
> > Harley-Davidson analogy applies, because we're not using this to
> > break
> > into a new market. We're using this to make sure that we remain
> > relevant as the market we are in changes. 
> 
> Except the whole market isn't changing.  It is just a new niche
> opening
> up.  It's like Gnome3 deciding to convert the desktop interface for
> mobile, creating a hybrid that tries to satisfy both, but hits the
> sweet spot for neither.  They would have been better off with a new
> product targeted at mobiles exclusively, called maybe goblin or
> pixie,
> while retaining their old brand, gnome2, to satisfy existing desktop
> users who were happy with the paradigm embodied in that brand.
> 
> > Let's take the current shift
> > to electric cars as a branding analogy — GM *could* have gone with
> > a
> > whole new name, but instead we have the Chevrolet Volt. (And Nissan
> > Leaf. And Ford is even reusing the "Focus" name.)
> > 
> > I think this matches our current and upcoming challenge more
> > closely. 
> 
> I think you are agreeing with him.  GM didn't convert the chevy
> malibu
> to electric.  They created a new brand.  People who want an IC malibu
> still can buy one, and know it isn't going to be electric tomorrow,
> leaving them high and dry.  And those who want to dip a toe into the
> Ecar market, can try it out from a brand they trust.  Just like the
> soap analogy.

Except they didn't really create a new car brand, just a model brand.
No one is saying Fedora for desktop will be all flatpaks from now on.
There will be another flavour that will be called Fedora Atomic
Workstation alongside  RPM-based Fedora Workstation. Just like
Chevrolet has electric Volt and traditional Malibu at the same time.
But no one in GM/Chevrolet is saying: No, the Chevrolet brand is
associated with combustion engines and it will stay that way forever.
GM is not spinning a new car company/brand for electric cars.
You say that they keep Malibu for people who want traditional cars, but
for how long? No one in GM is not gonna give you any promises because
if the market eventually shifts to electric cars they will just stop
doing the traditional cars. But the Chevrolet brand will stay.

I agree with Matt here, Fedora Project's mission (neither the old one,
nor the new draft) doesn't say anything about RPM. RPM is just means to
an end, not the goal. And I don't know why Fedora should be tied to RPM
forever. Really successful brands don't die when their current solution
stops being relevant, really successful brands are able to transition
themselves and stay relevant as the market shifts.

BTW we already have an official edition which doesn't use RPM as a
delivery system - Fedora Atomic and it's been part of the Fedora
Project for several years.

Jiri

> In my opinion, the equivalent for fedora would be to create a new
> spin
> called gatsby or homburg that uses flatpaks.  Maybe one waxes and one
> wanes. Or maybe there is a fork.  But what is being discussed now is
> making an all or nothing bet on a new technology.  Once rpm is ripped
> out of fedora, it won't be coming back, in practical terms.  There's
> a
> burning the ships sort of appeal in that approach, but it isn't the
> most prudent path from an expected value perspective.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
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

On Mon, Jul 17, 2017 at 08:02:10AM -0700, stan wrote:
> making an all or nothing bet on a new technology.  Once rpm is ripped
> out of fedora, it won't be coming back, in practical terms.  There's a
> burning the ships sort of appeal in that approach, but it isn't the
> most prudent path from an expected value perspective.

No one is talking about "ripping RPM out of Fedora".

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

2017-07-17 Thread stan

On Mon, 17 Jul 2017 12:45:27 +0200
Michael Stahl  wrote:

> On 16.07.2017 14:10, Kevin Kofler wrote:
> > Debarshi Ray wrote:  
> >> How about reliable online updates of running applications as a
> >> benefit?  
> > 
> > Upgrading RPM applications online just works. I do it all the time.
> > The KDE tools do not even implement offline updates (and IMHO
> > that's a good thing). The worst that can happen is that some
> > recalcitrant applications (by far the minority) need to be
> > restarted after updating (or if you upgraded the whole desktop,
> > then your session may need to be restarted after updating). Until
> > you do that, the current session may be "hosed" to some extent, but
> > restarting will fix it.  
> 
> no, the worst case is this:
> 
> https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-when-system-has-hybrid-graphics-and-systemd-udev-is-in-update/

Anecdotal confirmation of the assertion in that link that running dnf
(or formerly yum) from a virtual console is a good way to go.  I've
only done updates that way in stable versions since Fedora 3 and have
never had an update issue because of the update process. In rawhide, I
always run dnf updates that way, but without X running because of the
less stable environment. Again, no update issues.

I guess it's about balancing the level of risk with the cost of
mitigating risk.  How much is it worth in various dimensions to go
another sigma lower in risk?  For me, the above cost in process yields a
risk I can live with.
___
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

2017-07-17 Thread Przemek Klosowski


On 07/15/2017 01:43 PM, Matthew Miller wrote:

On Fri, Jul 14, 2017 at 02:56:34PM -0700, Andrew Lutomirski wrote:

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 don't agree. With this model, every time you try to do something,
you're bombarded with questions asking if you want to do the thing you
tried to do. It gets very easy to fall into a default of clicking a
bunch of yesses all the time. That serves no *real* security benefit
and yet adds to user annoyance. There's gotta be a better way than
that.
That depends whether the process Andrew described happens every time you 
run the app, or only when the packager prepares a flatpack, in which  
case the annoying questions are asked of the knowledgeable packager, and 
only once. Of course this assumes that it's practical to do a complete 
run-through of all the different code paths, which may be questionable 
for large apps.
___
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

2017-07-17 Thread stan

On Mon, 17 Jul 2017 10:10:16 -0400
Matthew Miller  wrote:

> We could look at starting a new brand. But, I don't think your
> Harley-Davidson analogy applies, because we're not using this to break
> into a new market. We're using this to make sure that we remain
> relevant as the market we are in changes. 

Except the whole market isn't changing.  It is just a new niche opening
up.  It's like Gnome3 deciding to convert the desktop interface for
mobile, creating a hybrid that tries to satisfy both, but hits the
sweet spot for neither.  They would have been better off with a new
product targeted at mobiles exclusively, called maybe goblin or pixie,
while retaining their old brand, gnome2, to satisfy existing desktop
users who were happy with the paradigm embodied in that brand.

> Let's take the current shift
> to electric cars as a branding analogy — GM *could* have gone with a
> whole new name, but instead we have the Chevrolet Volt. (And Nissan
> Leaf. And Ford is even reusing the "Focus" name.)
> 
> I think this matches our current and upcoming challenge more closely. 

I think you are agreeing with him.  GM didn't convert the chevy malibu
to electric.  They created a new brand.  People who want an IC malibu
still can buy one, and know it isn't going to be electric tomorrow,
leaving them high and dry.  And those who want to dip a toe into the
Ecar market, can try it out from a brand they trust.  Just like the
soap analogy.

In my opinion, the equivalent for fedora would be to create a new spin
called gatsby or homburg that uses flatpaks.  Maybe one waxes and one
wanes. Or maybe there is a fork.  But what is being discussed now is
making an all or nothing bet on a new technology.  Once rpm is ripped
out of fedora, it won't be coming back, in practical terms.  There's a
burning the ships sort of appeal in that approach, but it isn't the
most prudent path from an expected value perspective.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning: clamav, sphinx, mldonkey

2017-07-17 Thread Christopher Meng

I hope someone can take mldonkey, as I still remember the days patching it
to pass the compiler.
-- 

Yours sincerely,
Christopher Meng

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

spot pushed to perl-Image-Info (master). "1.41"

From 0b79af0b76021757757220afb8e9f3d40cef1b8d Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Mon, 17 Jul 2017 10:53:39 -0400
Subject: 1.41

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

diff --git a/.gitignore b/.gitignore
index b1a9280..dc618d3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ Image-Info-1.28.tar.gz
 /Image-Info-1.38.tar.gz
 /Image-Info-1.39.tar.gz
 /Image-Info-1.40.tar.gz
+/Image-Info-1.41.tar.gz
diff --git a/perl-Image-Info.spec b/perl-Image-Info.spec
index 637cbd8..e8c87a7 100644
--- a/perl-Image-Info.spec
+++ b/perl-Image-Info.spec
@@ -1,6 +1,6 @@
 Name:   perl-Image-Info
-Version:1.40
-Release:2%{?dist}
+Version:1.41
+Release:1%{?dist}
 Summary:Image meta information extraction module for Perl
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -67,6 +67,9 @@ make test
 %{_mandir}/man3/*.3pm*
 
 %changelog
+* Mon Jul 17 2017 Tom Callaway  - 1.41-1
+- update to 1.41
+
 * Mon Jun 05 2017 Jitka Plesnikova  - 1.40-2
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index bae1d43..043aa28 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Image-Info-1.40.tar.gz) = 
9a5caddea3b54a9433621144284eb52ee9683db0420a35b0774101cc50f28a98f03a988748fc280b4d34e4c0312b7585f063c844b0bbce3efd9621bf6c76b35b
+SHA512 (Image-Info-1.41.tar.gz) = 
7e3cb103efa004ce728b6e594f5b7518fa5be14a814e6f06d4a3e85563d7896fd283855cfe9e091c22b3728f6126501463f7326d704c0188ad696206f9318824
-- 
cgit v1.1



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

spot uploaded Image-Info-1.41.tar.gz for perl-Image-Info

7e3cb103efa004ce728b6e594f5b7518fa5be14a814e6f06d4a3e85563d7896fd283855cfe9e091c22b3728f6126501463f7326d704c0188ad696206f9318824
  Image-Info-1.41.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Image-Info/Image-Info-1.41.tar.gz/sha512/7e3cb103efa004ce728b6e594f5b7518fa5be14a814e6f06d4a3e85563d7896fd283855cfe9e091c22b3728f6126501463f7326d704c0188ad696206f9318824/Image-Info-1.41.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

2017-07-17 Fedora QA Devel Meeting Minutes

2017-07-17 Thread Tim Flink

=
#fedora-meeting-1: fedora-qadevel
=

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2017-07-17/fedora-qadevel.2017-07-17-14.01.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2017-07-17/fedora-qadevel.2017-07-17-14.01.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2017-07-17/fedora-qadevel.2017-07-17-14.01.log.html

Meeting summary
---
* roll call  (tflink, 14:01:16)

* Announcements and Information  (tflink, 14:03:41)
  * depcheck has been removed from production -- kparal and mkrizek
(tflink, 14:03:55)
  * libtaskotron 0.4.24 built and submitted as updated (still in
testing) -- kparal  (tflink, 14:03:55)
  * task-mtf now has a pretty html overview page -- kparal and jscotka
(tflink, 14:03:55)
  * taskotron stack now works with Jenkins in place of Buildbot --
jskladan (+jsedlak)  (tflink, 14:03:55)
  * mkrizek has left Fedora QA  (kparal, 14:04:14)

* taskotron + Jenkins  (tflink, 14:08:06)

* Fedora Atomic Host CI and ResultsDB  (tflink, 14:27:51)

* Tasking  (tflink, 14:32:12)

* Open Floor  (tflink, 14:39:50)

Meeting ended at 14:42:13 UTC.




Action Items






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




People Present (lines said)
---
* tflink (88)
* jskladan (51)
* kparal (30)
* puiterwijk (9)
* roshi (4)
* zodbot (4)
* tenk (2)
* garretraziel (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


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

spot uploaded Test-MockModule-0.12.tar.gz for perl-Test-MockModule

be257682d2515b835442e604a69d16b394c67d4bf25f2547cd7408bde5ca1981d3ca1e40e2a458307f3385c937ac946fe46968cdef170ce27b30b3668323
  Test-MockModule-0.12.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Test-MockModule/Test-MockModule-0.12.tar.gz/sha512/be257682d2515b835442e604a69d16b394c67d4bf25f2547cd7408bde5ca1981d3ca1e40e2a458307f3385c937ac946fe46968cdef170ce27b30b3668323/Test-MockModule-0.12.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

spot pushed to perl-Test-MockModule (master). "0.12"

From 51258f077a3638674d0c93287d5c94a4af9027ec Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Mon, 17 Jul 2017 10:31:16 -0400
Subject: 0.12

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

diff --git a/.gitignore b/.gitignore
index 407e0ce..f8eb212 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Test-MockModule-0.05.tar.gz
 /Test-MockModule-0.09.tar.gz
 /Test-MockModule-0.10.tar.gz
 /Test-MockModule-0.11.tar.gz
+/Test-MockModule-0.12.tar.gz
diff --git a/perl-Test-MockModule.spec b/perl-Test-MockModule.spec
index e3e7f23..e7c589e 100644
--- a/perl-Test-MockModule.spec
+++ b/perl-Test-MockModule.spec
@@ -1,6 +1,6 @@
 Name:   perl-Test-MockModule
-Version:0.11
-Release:5%{?dist}
+Version:0.12
+Release:1%{?dist}
 Summary:Override subroutines in a module for unit testing
 Group:  Development/Libraries
 License:GPL+ or Artistic
@@ -37,6 +37,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Jul 17 2017 Tom Callaway  - 0.12-1
+- update to 0.12
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 0.11-5
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index 6955348..b68654b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-736fa14f2cdda27cf9df034a5b2816f1  Test-MockModule-0.11.tar.gz
+SHA512 (Test-MockModule-0.12.tar.gz) = 
be257682d2515b835442e604a69d16b394c67d4bf25f2547cd7408bde5ca1981d3ca1e40e2a458307f3385c937ac946fe46968cdef170ce27b30b3668323
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Test-MockModule.git/commit/?h=master=51258f077a3638674d0c93287d5c94a4af9027ec
___
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

On Sun, Jul 16, 2017 at 04:31:33PM +0200, Reindl Harald wrote:
> users which had chosen Fedora because of a single package manager
> working without any GUI will dispute with their feet if it goes in a
> direction where you no longer can upgrade *everything* with "dnf
> distro-sync", no longer can build meta-rpm-packages making sure you
> can remove everything listed with "dnf leaves" safely while cover
> the whole operating system and no longer can compare the installed
> packages of two machines with a single command

Yeah, I agree that it's important to have a unified management
interface like this.



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

On Sun, Jul 16, 2017 at 01:17:25PM -0400, Stephen John Smoogen wrote:
> These sorts of deep brand issues are why most companies start new
> brands which might look like they are competing with their primary
> one. It can showcase some new identity and get people to see it as
> useful or better than what they have already. It can also show where
> things aren't going to work at all because people just aren't
> interested in something. The Soap industry is a classic study in
> brands where most people buy things because of something they tie to
> the brand be it a logo, a smell, a look or even just the container it
> comes in. Whenever the company changes those things, it causes
> significant drop in sales and they are usually going back to what they
> had. So instead a soap company will just start a new line with
> whatever is different they want to see. No tie in with the original
> soap. Sometimes that soap takes over and other times it just sits
> there and goes away after 8 months.

We could look at starting a new brand. But, I don't think your
Harley-Davidson analogy applies, because we're not using this to break
into a new market. We're using this to make sure that we remain
relevant as the market we are in changes. Let's take the current shift
to electric cars as a branding analogy — GM *could* have gone with a
whole new name, but instead we have the Chevrolet Volt. (And Nissan
Leaf. And Ford is even reusing the "Focus" name.)

I think this matches our current and upcoming challenge more closely.

-- 
Matthew Miller

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

[Bug 1471500] perl-Module-Runtime-0.015 is available

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



--- Comment #6 from Fedora Update System  ---
perl-Module-Runtime-0.015-1.fc24 has been submitted as an update to Fedora 24.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-8f89173832

-- 
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 1471500] perl-Module-Runtime-0.015 is available

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



--- Comment #5 from Fedora Update System  ---
perl-Module-Runtime-0.015-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-f95c5d9fae

-- 
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 1471500] perl-Module-Runtime-0.015 is available

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



--- Comment #4 from Fedora Update System  ---
perl-Module-Runtime-0.015-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-6c1aa99ce7

-- 
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-Module-Runtime (f24). "perl dependency renamed to perl-interpreter "

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

---
 perl-Module-Runtime.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index ec25889..a3db583 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -12,7 +12,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(strict)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f24=d0b0f3aabfd61e011dc3d6965f63d638ec257c4a
___
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-Module-Runtime (f24). "Mandatory Perl build-requires added "

From 49139228caf2875d7eed3ac6055b94664a3ccb81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 10:11:46 +0200
Subject: Mandatory Perl build-requires added
 

---
 perl-Module-Runtime.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index a21ad09..6c136bb 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -9,6 +9,7 @@ URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl
+BuildRequires:  perl-generators
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f24=49139228caf2875d7eed3ac6055b94664a3ccb81
___
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-Module-Runtime (f24). "0.015 bump"

From ba99222b8b45d0ada156839677cfac8f29543701 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 17 Jul 2017 15:22:31 +0200
Subject: 0.015 bump

---
 .gitignore   |  1 +
 perl-Module-Runtime.spec | 28 
 sources  |  2 +-
 3 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0f6dd88..28fd9c1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Module-Runtime-0.012.tar.gz
 /Module-Runtime-0.013.tar.gz
 /Module-Runtime-0.014.tar.gz
+/Module-Runtime-0.015.tar.gz
diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index a3db583..b325348 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -4,22 +4,23 @@
 %{bcond_without perl_Module_Runtime_enables_optional_test}
 
 Name:   perl-Module-Runtime
-Version:0.014
-Release:7%{?dist}
+Version:0.015
+Release:1%{?dist}
 Summary:Runtime module handling
 License:GPL+ or Artistic
-Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl-interpreter
+BuildRequires:  make
 BuildRequires:  perl-generators
-BuildRequires:  perl(Module::Build)
-BuildRequires:  perl(strict)
-BuildRequires:  perl(warnings)
+BuildRequires:  perl-interpreter
+BuildRequires:  perl(:VERSION) >= 5.6
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 # Tests:
 BuildRequires:  perl(Math::BigInt)
-BuildRequires:  perl(Test::More)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::More) >= 0.41
+BuildRequires:  perl(warnings)
 %if %{with perl_Module_Runtime_enables_optional_test}
 # Optional tests:
 BuildRequires:  perl(Test::Pod) >= 1.00
@@ -35,15 +36,15 @@ modules, which are normally handled at compile time.
 %setup -q -n Module-Runtime-%{version}
 
 %build
-perl Build.PL installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make %{?_smp_mflags}
 
 %install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install DESTDIR=%{buildroot}
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+make test
 
 %files
 %doc Changes README
@@ -51,6 +52,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 17 2017 Petr Pisar  - 0.015-1
+- 0.015 bump
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
0.014-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
diff --git a/sources b/sources
index 462252a..c222068 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6597bc25536a30476f0d75b64d35734  Module-Runtime-0.014.tar.gz
+SHA512 (Module-Runtime-0.015.tar.gz) = 
13f85128130f1543d6be86c002b5d093ed530ab069a7fdf2c109317a234a800611c43e8ff7349f43eb35e0169f80f677a117277a70aa138f0f147d9cf8fb16d0
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f24=ba99222b8b45d0ada156839677cfac8f29543701
___
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-Module-Runtime (f24). "Introduce build-condition for optional tests"

From 5591d1029cf6320617347d36325dfb6e79fbd454 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 27 Apr 2017 16:40:05 +0200
Subject: Introduce build-condition for optional tests

---
 perl-Module-Runtime.spec | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index 6c136bb..ec25889 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -1,4 +1,8 @@
 # This file is licensed under the terms of GNU GPLv2+.
+
+# Run optional tests
+%{bcond_without perl_Module_Runtime_enables_optional_test}
+
 Name:   perl-Module-Runtime
 Version:0.014
 Release:7%{?dist}
@@ -16,9 +20,11 @@ BuildRequires:  perl(warnings)
 # Tests:
 BuildRequires:  perl(Math::BigInt)
 BuildRequires:  perl(Test::More)
+%if %{with perl_Module_Runtime_enables_optional_test}
 # Optional tests:
 BuildRequires:  perl(Test::Pod) >= 1.00
 BuildRequires:  perl(Test::Pod::Coverage)
+%endif
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f24=5591d1029cf6320617347d36325dfb6e79fbd454
___
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-Module-Runtime (f25). "0.015 bump"

From f0a71a75e2095ea4c68f8f061db1f656b8e9cb50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 17 Jul 2017 15:22:31 +0200
Subject: 0.015 bump

---
 .gitignore   |  1 +
 perl-Module-Runtime.spec | 28 
 sources  |  2 +-
 3 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0f6dd88..28fd9c1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Module-Runtime-0.012.tar.gz
 /Module-Runtime-0.013.tar.gz
 /Module-Runtime-0.014.tar.gz
+/Module-Runtime-0.015.tar.gz
diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index 069a741..efe2585 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -4,22 +4,23 @@
 %{bcond_without perl_Module_Runtime_enables_optional_test}
 
 Name:   perl-Module-Runtime
-Version:0.014
-Release:8%{?dist}
+Version:0.015
+Release:1%{?dist}
 Summary:Runtime module handling
 License:GPL+ or Artistic
-Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl-interpreter
+BuildRequires:  make
 BuildRequires:  perl-generators
-BuildRequires:  perl(Module::Build)
-BuildRequires:  perl(strict)
-BuildRequires:  perl(warnings)
+BuildRequires:  perl-interpreter
+BuildRequires:  perl(:VERSION) >= 5.6
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 # Tests:
 BuildRequires:  perl(Math::BigInt)
-BuildRequires:  perl(Test::More)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::More) >= 0.41
+BuildRequires:  perl(warnings)
 %if %{with perl_Module_Runtime_enables_optional_test}
 # Optional tests:
 BuildRequires:  perl(Test::Pod) >= 1.00
@@ -35,15 +36,15 @@ modules, which are normally handled at compile time.
 %setup -q -n Module-Runtime-%{version}
 
 %build
-perl Build.PL installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make %{?_smp_mflags}
 
 %install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install DESTDIR=%{buildroot}
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+make test
 
 %files
 %doc Changes README
@@ -51,6 +52,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 17 2017 Petr Pisar  - 0.015-1
+- 0.015 bump
+
 * Sun May 15 2016 Jitka Plesnikova  - 0.014-8
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 462252a..c222068 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6597bc25536a30476f0d75b64d35734  Module-Runtime-0.014.tar.gz
+SHA512 (Module-Runtime-0.015.tar.gz) = 
13f85128130f1543d6be86c002b5d093ed530ab069a7fdf2c109317a234a800611c43e8ff7349f43eb35e0169f80f677a117277a70aa138f0f147d9cf8fb16d0
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f25=f0a71a75e2095ea4c68f8f061db1f656b8e9cb50
___
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-Module-Runtime (f25). "perl dependency renamed to perl-interpreter "

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

---
 perl-Module-Runtime.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index db23955..069a741 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -12,7 +12,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(strict)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f25=c772f9993199f2610a9200b92a538d98cb1327ea
___
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-Module-Runtime (f25). "Introduce build-condition for optional tests"

From 88b121e9eae24e197b740eae22f1739eac8c54ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 27 Apr 2017 16:40:05 +0200
Subject: Introduce build-condition for optional tests

---
 perl-Module-Runtime.spec | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index ed29a92..db23955 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -1,4 +1,8 @@
 # This file is licensed under the terms of GNU GPLv2+.
+
+# Run optional tests
+%{bcond_without perl_Module_Runtime_enables_optional_test}
+
 Name:   perl-Module-Runtime
 Version:0.014
 Release:8%{?dist}
@@ -16,9 +20,11 @@ BuildRequires:  perl(warnings)
 # Tests:
 BuildRequires:  perl(Math::BigInt)
 BuildRequires:  perl(Test::More)
+%if %{with perl_Module_Runtime_enables_optional_test}
 # Optional tests:
 BuildRequires:  perl(Test::Pod) >= 1.00
 BuildRequires:  perl(Test::Pod::Coverage)
+%endif
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f25=88b121e9eae24e197b740eae22f1739eac8c54ba
___
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-Module-Runtime (f26). "perl dependency renamed to perl-interpreter "

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

---
 perl-Module-Runtime.spec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index 26f2896..a60e112 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -12,7 +12,7 @@ Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl
+BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(strict)
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=f26=38c677b23263a4decf36f1a395a44da581fa5db5
___
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-Module-Runtime (f26). "0.015 bump"

From b61338418e9c84469b3d76a17b70f38497d30dd7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 17 Jul 2017 15:22:31 +0200
Subject: 0.015 bump

---
 .gitignore   |  1 +
 perl-Module-Runtime.spec | 28 
 sources  |  2 +-
 3 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0f6dd88..28fd9c1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Module-Runtime-0.012.tar.gz
 /Module-Runtime-0.013.tar.gz
 /Module-Runtime-0.014.tar.gz
+/Module-Runtime-0.015.tar.gz
diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index a60e112..8b88469 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -4,22 +4,23 @@
 %{bcond_without perl_Module_Runtime_enables_optional_test}
 
 Name:   perl-Module-Runtime
-Version:0.014
-Release:9%{?dist}
+Version:0.015
+Release:1%{?dist}
 Summary:Runtime module handling
 License:GPL+ or Artistic
-Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl-interpreter
+BuildRequires:  make
 BuildRequires:  perl-generators
-BuildRequires:  perl(Module::Build)
-BuildRequires:  perl(strict)
-BuildRequires:  perl(warnings)
+BuildRequires:  perl-interpreter
+BuildRequires:  perl(:VERSION) >= 5.6
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 # Tests:
 BuildRequires:  perl(Math::BigInt)
-BuildRequires:  perl(Test::More)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::More) >= 0.41
+BuildRequires:  perl(warnings)
 %if %{with perl_Module_Runtime_enables_optional_test}
 # Optional tests:
 BuildRequires:  perl(Test::Pod) >= 1.00
@@ -35,15 +36,15 @@ modules, which are normally handled at compile time.
 %setup -q -n Module-Runtime-%{version}
 
 %build
-perl Build.PL installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make %{?_smp_mflags}
 
 %install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install DESTDIR=%{buildroot}
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+make test
 
 %files
 %doc Changes README
@@ -51,6 +52,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 17 2017 Petr Pisar  - 0.015-1
+- 0.015 bump
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
0.014-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
diff --git a/sources b/sources
index 462252a..c222068 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6597bc25536a30476f0d75b64d35734  Module-Runtime-0.014.tar.gz
+SHA512 (Module-Runtime-0.015.tar.gz) = 
13f85128130f1543d6be86c002b5d093ed530ab069a7fdf2c109317a234a800611c43e8ff7349f43eb35e0169f80f677a117277a70aa138f0f147d9cf8fb16d0
-- 
cgit v1.1



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

[Bug 1471500] perl-Module-Runtime-0.015 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Module-Runtime-0.015-1
   ||.fc27



--- Comment #3 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
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-Module-Runtime (master). "0.015 bump"

From 1edf626f3849cf50f700450851d920f18c730b53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Mon, 17 Jul 2017 15:22:31 +0200
Subject: 0.015 bump

---
 .gitignore   |  1 +
 perl-Module-Runtime.spec | 28 
 sources  |  2 +-
 3 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0f6dd88..28fd9c1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
 /Module-Runtime-0.012.tar.gz
 /Module-Runtime-0.013.tar.gz
 /Module-Runtime-0.014.tar.gz
+/Module-Runtime-0.015.tar.gz
diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index f7ec154..5488206 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -4,22 +4,23 @@
 %{bcond_without perl_Module_Runtime_enables_optional_test}
 
 Name:   perl-Module-Runtime
-Version:0.014
-Release:10%{?dist}
+Version:0.015
+Release:1%{?dist}
 Summary:Runtime module handling
 License:GPL+ or Artistic
-Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Module-Runtime/
 Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
 BuildArch:  noarch
-BuildRequires:  perl-interpreter
+BuildRequires:  make
 BuildRequires:  perl-generators
-BuildRequires:  perl(Module::Build)
-BuildRequires:  perl(strict)
-BuildRequires:  perl(warnings)
+BuildRequires:  perl-interpreter
+BuildRequires:  perl(:VERSION) >= 5.6
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 # Tests:
 BuildRequires:  perl(Math::BigInt)
-BuildRequires:  perl(Test::More)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::More) >= 0.41
+BuildRequires:  perl(warnings)
 %if %{with perl_Module_Runtime_enables_optional_test}
 # Optional tests:
 BuildRequires:  perl(Test::Pod) >= 1.00
@@ -35,15 +36,15 @@ modules, which are normally handled at compile time.
 %setup -q -n Module-Runtime-%{version}
 
 %build
-perl Build.PL installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+make %{?_smp_mflags}
 
 %install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install DESTDIR=%{buildroot}
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-./Build test
+make test
 
 %files
 %doc Changes README
@@ -51,6 +52,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Mon Jul 17 2017 Petr Pisar  - 0.015-1
+- 0.015 bump
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 0.014-10
 - Perl 5.26 rebuild
 
diff --git a/sources b/sources
index 462252a..c222068 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a6597bc25536a30476f0d75b64d35734  Module-Runtime-0.014.tar.gz
+SHA512 (Module-Runtime-0.015.tar.gz) = 
13f85128130f1543d6be86c002b5d093ed530ab069a7fdf2c109317a234a800611c43e8ff7349f43eb35e0169f80f677a117277a70aa138f0f147d9cf8fb16d0
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Module-Runtime.git/commit/?h=master=1edf626f3849cf50f700450851d920f18c730b53
___
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

2017-07-17 Thread Debarshi Ray

On Sun, Jul 16, 2017 at 11:56:26AM +0100, Richard W.M. Jones wrote:
> On Fri, Jul 14, 2017 at 10:04:37PM +0100, Richard Hughes wrote:
> > 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,
> 
> Which could be fixed and the fix would benefit everyone ...
> 
> > and this is the main reason we force upgrade to be offline
> > in the workstation product.
> 
> No, that's a workaround for not fixing it properly.

No, that's not true.

(I love one-liners.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar uploaded Module-Runtime-0.015.tar.gz for perl-Module-Runtime

13f85128130f1543d6be86c002b5d093ed530ab069a7fdf2c109317a234a800611c43e8ff7349f43eb35e0169f80f677a117277a70aa138f0f147d9cf8fb16d0
  Module-Runtime-0.015.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Module-Runtime/Module-Runtime-0.015.tar.gz/sha512/13f85128130f1543d6be86c002b5d093ed530ab069a7fdf2c109317a234a800611c43e8ff7349f43eb35e0169f80f677a117277a70aa138f0f147d9cf8fb16d0/Module-Runtime-0.015.tar.gz
___
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 (f24). "5.22.4 bump"

From e5b865603532a910b784c8c549965fb391467bef Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 17 Jul 2017 15:08:09 +0200
Subject: 5.22.4 bump

---
 .gitignore |   1 +
 3-Fix-checks-for-tainted-dir-in-ENV-PATH.patch | 191 -
 perl.spec  |  17 +-
 sources|   2 +-
 4 files changed, 10 insertions(+), 201 deletions(-)
 delete mode 100644 perl-5.22.3-Fix-checks-for-tainted-dir-in-ENV-PATH.patch

diff --git a/.gitignore b/.gitignore
index 28fae75..9749d7a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,3 +22,4 @@ perl-5.12.1.tar.gz
 /perl-5.22.1.tar.bz2
 /perl-5.22.2.tar.bz2
 /perl-5.22.3.tar.bz2
+/perl-5.22.4.tar.bz2
diff --git a/perl-5.22.3-Fix-checks-for-tainted-dir-in-ENV-PATH.patch 
b/perl-5.22.3-Fix-checks-for-tainted-dir-in-ENV-PATH.patch
deleted file mode 100644
index 4ea66de..000
--- a/perl-5.22.3-Fix-checks-for-tainted-dir-in-ENV-PATH.patch
+++ /dev/null
@@ -1,191 +0,0 @@
-From 326dd098113de7c1d79c00ef1eb1860d0e502586 Mon Sep 17 00:00:00 2001
-From: Father Chrysostomos 
-Date: Sat, 3 Sep 2016 13:30:22 -0700
-Subject: [PATCH] Fix checks for tainted dir in $ENV{PATH}
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Ported to 5.22.3:
-
-commit ba0a4150f6f1604df236035adf6df18bd43de88e
-Author: Father Chrysostomos 
-Date:   Sat Sep 3 13:30:22 2016 -0700
-
-Fix checks for tainted dir in $ENV{PATH}
-
-$ cat > foo
-#!/usr/bin/perl
-print "What?!\n"
-^D
-$ chmod +x foo
-$ ./perl -Ilib -Te '$ENV{PATH}="."; exec "foo"'
-Insecure directory in $ENV{PATH} while running with -T switch at -e line 1.
-
-That is what I expect to see.  But:
-
-$ ./perl -Ilib -Te '$ENV{PATH}="/\\:."; exec "foo"'
-What?!
-
-Perl is allowing the \ to escape the :, but the \ is not treated as an
-escape by the system, allowing a relative path in PATH to be consid-
-ered safe.
-
-Signed-off-by: Petr Písař 

- embed.fnc|  4 
- embed.h  |  1 +
- mg.c |  2 +-
- proto.h  |  9 +
- t/op/taint.t | 18 +-
- util.c   | 25 ++---
- 6 files changed, 54 insertions(+), 5 deletions(-)
-
-diff --git a/embed.fnc b/embed.fnc
-index 3dbf9e8..7eed88e 100644
 a/embed.fnc
-+++ b/embed.fnc
-@@ -343,6 +343,10 @@ Ap|I32|debstackptrs
- pR|SV *   |defelem_target |NN SV *sv|NULLOK MAGIC *mg
- Anp   |char*  |delimcpy   |NN char* to|NN const char* toend|NN const 
char* from \
-   |NN const char* fromend|int delim|NN I32* retlen
-+np|char*  |delimcpy_no_escape|NN char* to|NN const char* toend \
-+ |NN const char* from \
-+ |NN const char* fromend|int delim \
-+ |NN I32* retlen
- : Used in op.c, perl.c
- pM|void   |delete_eval_scope
- Aprd|OP*|die_sv |NN SV *baseex
-diff --git a/embed.h b/embed.h
-index e09ffee..fe310b6 100644
 a/embed.h
-+++ b/embed.h
-@@ -1161,6 +1161,7 @@
- #define deb_stack_all()   Perl_deb_stack_all(aTHX)
- #define defelem_target(a,b)   Perl_defelem_target(aTHX_ a,b)
- #define delete_eval_scope()   Perl_delete_eval_scope(aTHX)
-+#define delimcpy_no_escapePerl_delimcpy_no_escape
- #define die_unwind(a) Perl_die_unwind(aTHX_ a)
- #define do_aexec5(a,b,c,d,e)  Perl_do_aexec5(aTHX_ a,b,c,d,e)
- #define do_dump_pad(a,b,c,d)  Perl_do_dump_pad(aTHX_ a,b,c,d)
-diff --git a/mg.c b/mg.c
-index 064a1ae..b67f8e2 100644
 a/mg.c
-+++ b/mg.c
-@@ -1254,7 +1254,7 @@ Perl_magic_setenv(pTHX_ SV *sv, MAGIC *mg)
- #else
-   const char path_sep = ':';
- #endif
--  s = delimcpy(tmpbuf, tmpbuf + sizeof tmpbuf,
-+  s = delimcpy_no_escape(tmpbuf, tmpbuf + sizeof tmpbuf,
-s, strend, path_sep, );
-   s++;
-   if (i >= (I32)sizeof tmpbuf   /* too long -- assume the worst */
-diff --git a/proto.h b/proto.h
-index f82c62e..3b57ca4 100644
 a/proto.h
-+++ b/proto.h
-@@ -891,6 +891,15 @@ PERL_CALLCONV char*   Perl_delimcpy(char* to, const 
char* toend, const char* from,
- #define PERL_ARGS_ASSERT_DELIMCPY \
-   assert(to); assert(toend); assert(from); assert(fromend); assert(retlen)
- 
-+PERL_CALLCONV char*   Perl_delimcpy_no_escape(char* to, const char* toend, 
const char* from, const char* fromend, int delim, I32* retlen)
-+  __attribute__nonnull__(1)
-+  __attribute__nonnull__(2)
-+  __attribute__nonnull__(3)
-+  __attribute__nonnull__(4)
-+  __attribute__nonnull__(6);
-+#define PERL_ARGS_ASSERT_DELIMCPY_NO_ESCAPE   \
-+  assert(to); assert(toend); assert(from);

jplesnik uploaded perl-5.22.4.tar.bz2 for perl

d91e86449e86e42657e62f7592675cee73eeef1766fdde6df923702f3b5f30ae82c0e4c847615f3de61acf6ff4e294f763fc0381a9cc044f25debb369415d96b
  perl-5.22.4.tar.bz2

https://src.fedoraproject.org/lookaside/pkgs/perl/perl-5.22.4.tar.bz2/sha512/d91e86449e86e42657e62f7592675cee73eeef1766fdde6df923702f3b5f30ae82c0e4c847615f3de61acf6ff4e294f763fc0381a9cc044f25debb369415d96b/perl-5.22.4.tar.bz2
___
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 (f26). "Remove unused patch; Fixed version in changelog"

From a4c750bfc34aefe2be6423af2bc325b5442695e6 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 17 Jul 2017 15:00:30 +0200
Subject: Remove unused patch; Fixed version in changelog

---
 1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch | 185 -
 perl.spec  |   2 +-
 2 files changed, 1 insertion(+), 186 deletions(-)
 delete mode 100644 perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch

diff --git a/perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch 
b/perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch
deleted file mode 100644
index 0092b24..000
--- a/perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch
+++ /dev/null
@@ -1,185 +0,0 @@
-From ab412ef46f7ded04234bfd31ce9e73ce5c8b23cb Mon Sep 17 00:00:00 2001
-From: Father Chrysostomos 
-Date: Sat, 3 Sep 2016 13:30:22 -0700
-Subject: [PATCH] Fix checks for tainted dir in $ENV{PATH}
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Ported to 5.24.1:
-
-commit ba0a4150f6f1604df236035adf6df18bd43de88e
-Author: Father Chrysostomos 
-Date:   Sat Sep 3 13:30:22 2016 -0700
-
-Fix checks for tainted dir in $ENV{PATH}
-
-$ cat > foo
-#!/usr/bin/perl
-print "What?!\n"
-^D
-$ chmod +x foo
-$ ./perl -Ilib -Te '$ENV{PATH}="."; exec "foo"'
-Insecure directory in $ENV{PATH} while running with -T switch at -e line 1.
-
-That is what I expect to see.  But:
-
-$ ./perl -Ilib -Te '$ENV{PATH}="/\\:."; exec "foo"'
-What?!
-
-Perl is allowing the \ to escape the :, but the \ is not treated as an
-escape by the system, allowing a relative path in PATH to be consid-
-ered safe.
-
-Signed-off-by: Petr Písař 

- embed.fnc|  4 
- embed.h  |  1 +
- mg.c |  2 +-
- proto.h  |  3 +++
- t/op/taint.t | 18 +-
- util.c   | 25 ++---
- 6 files changed, 48 insertions(+), 5 deletions(-)
-
-diff --git a/embed.fnc b/embed.fnc
-index 2395efb..4aeb767 100644
 a/embed.fnc
-+++ b/embed.fnc
-@@ -344,6 +344,10 @@ Ap|I32|debstackptrs
- pR|SV *   |defelem_target |NN SV *sv|NULLOK MAGIC *mg
- Anp   |char*  |delimcpy   |NN char* to|NN const char* toend|NN const 
char* from \
-   |NN const char* fromend|int delim|NN I32* retlen
-+np|char*  |delimcpy_no_escape|NN char* to|NN const char* toend \
-+ |NN const char* from \
-+ |NN const char* fromend|int delim \
-+ |NN I32* retlen
- : Used in op.c, perl.c
- pM|void   |delete_eval_scope
- Aprd|OP*|die_sv |NN SV *baseex
-diff --git a/embed.h b/embed.h
-index 42c65b2..5b2998d 100644
 a/embed.h
-+++ b/embed.h
-@@ -1206,6 +1206,7 @@
- #define deb_stack_all()   Perl_deb_stack_all(aTHX)
- #define defelem_target(a,b)   Perl_defelem_target(aTHX_ a,b)
- #define delete_eval_scope()   Perl_delete_eval_scope(aTHX)
-+#define delimcpy_no_escapePerl_delimcpy_no_escape
- #define die_unwind(a) Perl_die_unwind(aTHX_ a)
- #define do_aexec5(a,b,c,d,e)  Perl_do_aexec5(aTHX_ a,b,c,d,e)
- #define do_dump_pad(a,b,c,d)  Perl_do_dump_pad(aTHX_ a,b,c,d)
-diff --git a/mg.c b/mg.c
-index 4321a40..1c43c9d 100644
 a/mg.c
-+++ b/mg.c
-@@ -1259,7 +1259,7 @@ Perl_magic_setenv(pTHX_ SV *sv, MAGIC *mg)
- #else
-   const char path_sep = ':';
- #endif
--  s = delimcpy(tmpbuf, tmpbuf + sizeof tmpbuf,
-+  s = delimcpy_no_escape(tmpbuf, tmpbuf + sizeof tmpbuf,
-s, strend, path_sep, );
-   s++;
-   if (i >= (I32)sizeof tmpbuf   /* too long -- assume the worst */
-diff --git a/proto.h b/proto.h
-index 2b2004a..6c1f840 100644
 a/proto.h
-+++ b/proto.h
-@@ -659,6 +659,9 @@ PERL_CALLCONV void Perl_delete_eval_scope(pTHX);
- PERL_CALLCONV char*   Perl_delimcpy(char* to, const char* toend, const char* 
from, const char* fromend, int delim, I32* retlen);
- #define PERL_ARGS_ASSERT_DELIMCPY \
-   assert(to); assert(toend); assert(from); assert(fromend); assert(retlen)
-+PERL_CALLCONV char*   Perl_delimcpy_no_escape(char* to, const char* toend, 
const char* from, const char* fromend, int delim, I32* retlen);
-+#define PERL_ARGS_ASSERT_DELIMCPY_NO_ESCAPE   \
-+  assert(to); assert(toend); assert(from); assert(fromend); assert(retlen)
- PERL_CALLCONV voidPerl_despatch_signals(pTHX);
- PERL_CALLCONV_NO_RET OP*  Perl_die(pTHX_ const char* pat, ...)
-   __attribute__noreturn__
-diff --git a/t/op/taint.t b/t/op/taint.t
-index 101c6da..846ac23 100644
 a/t/op/taint.t
-+++ b/t/op/taint.t
-@@ -17,7 +17,7 @@ BEGIN {
- use strict;
- use Config;
- 
--plan tests => 808;
-+plan tests => 812;
- 
- $| = 1;
- 
-@@ -187,6 +187,22 @@ my $TEST = 'TEST';
-   like($@,

jplesnik pushed to perl (f25). "Remove unused patch; Fixed version in changelog"

From 5a37dd9fa6bc125ba80d3abf4624e2d04b3ad630 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Mon, 17 Jul 2017 14:56:54 +0200
Subject: Remove unused patch; Fixed version in changelog

---
 1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch | 185 -
 perl.spec  |   2 +-
 2 files changed, 1 insertion(+), 186 deletions(-)
 delete mode 100644 perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch

diff --git a/perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch 
b/perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch
deleted file mode 100644
index 0092b24..000
--- a/perl-5.24.1-Fix-checks-for-tainted-dir-in-ENV-PATH.patch
+++ /dev/null
@@ -1,185 +0,0 @@
-From ab412ef46f7ded04234bfd31ce9e73ce5c8b23cb Mon Sep 17 00:00:00 2001
-From: Father Chrysostomos 
-Date: Sat, 3 Sep 2016 13:30:22 -0700
-Subject: [PATCH] Fix checks for tainted dir in $ENV{PATH}
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Ported to 5.24.1:
-
-commit ba0a4150f6f1604df236035adf6df18bd43de88e
-Author: Father Chrysostomos 
-Date:   Sat Sep 3 13:30:22 2016 -0700
-
-Fix checks for tainted dir in $ENV{PATH}
-
-$ cat > foo
-#!/usr/bin/perl
-print "What?!\n"
-^D
-$ chmod +x foo
-$ ./perl -Ilib -Te '$ENV{PATH}="."; exec "foo"'
-Insecure directory in $ENV{PATH} while running with -T switch at -e line 1.
-
-That is what I expect to see.  But:
-
-$ ./perl -Ilib -Te '$ENV{PATH}="/\\:."; exec "foo"'
-What?!
-
-Perl is allowing the \ to escape the :, but the \ is not treated as an
-escape by the system, allowing a relative path in PATH to be consid-
-ered safe.
-
-Signed-off-by: Petr Písař 

- embed.fnc|  4 
- embed.h  |  1 +
- mg.c |  2 +-
- proto.h  |  3 +++
- t/op/taint.t | 18 +-
- util.c   | 25 ++---
- 6 files changed, 48 insertions(+), 5 deletions(-)
-
-diff --git a/embed.fnc b/embed.fnc
-index 2395efb..4aeb767 100644
 a/embed.fnc
-+++ b/embed.fnc
-@@ -344,6 +344,10 @@ Ap|I32|debstackptrs
- pR|SV *   |defelem_target |NN SV *sv|NULLOK MAGIC *mg
- Anp   |char*  |delimcpy   |NN char* to|NN const char* toend|NN const 
char* from \
-   |NN const char* fromend|int delim|NN I32* retlen
-+np|char*  |delimcpy_no_escape|NN char* to|NN const char* toend \
-+ |NN const char* from \
-+ |NN const char* fromend|int delim \
-+ |NN I32* retlen
- : Used in op.c, perl.c
- pM|void   |delete_eval_scope
- Aprd|OP*|die_sv |NN SV *baseex
-diff --git a/embed.h b/embed.h
-index 42c65b2..5b2998d 100644
 a/embed.h
-+++ b/embed.h
-@@ -1206,6 +1206,7 @@
- #define deb_stack_all()   Perl_deb_stack_all(aTHX)
- #define defelem_target(a,b)   Perl_defelem_target(aTHX_ a,b)
- #define delete_eval_scope()   Perl_delete_eval_scope(aTHX)
-+#define delimcpy_no_escapePerl_delimcpy_no_escape
- #define die_unwind(a) Perl_die_unwind(aTHX_ a)
- #define do_aexec5(a,b,c,d,e)  Perl_do_aexec5(aTHX_ a,b,c,d,e)
- #define do_dump_pad(a,b,c,d)  Perl_do_dump_pad(aTHX_ a,b,c,d)
-diff --git a/mg.c b/mg.c
-index 4321a40..1c43c9d 100644
 a/mg.c
-+++ b/mg.c
-@@ -1259,7 +1259,7 @@ Perl_magic_setenv(pTHX_ SV *sv, MAGIC *mg)
- #else
-   const char path_sep = ':';
- #endif
--  s = delimcpy(tmpbuf, tmpbuf + sizeof tmpbuf,
-+  s = delimcpy_no_escape(tmpbuf, tmpbuf + sizeof tmpbuf,
-s, strend, path_sep, );
-   s++;
-   if (i >= (I32)sizeof tmpbuf   /* too long -- assume the worst */
-diff --git a/proto.h b/proto.h
-index 2b2004a..6c1f840 100644
 a/proto.h
-+++ b/proto.h
-@@ -659,6 +659,9 @@ PERL_CALLCONV void Perl_delete_eval_scope(pTHX);
- PERL_CALLCONV char*   Perl_delimcpy(char* to, const char* toend, const char* 
from, const char* fromend, int delim, I32* retlen);
- #define PERL_ARGS_ASSERT_DELIMCPY \
-   assert(to); assert(toend); assert(from); assert(fromend); assert(retlen)
-+PERL_CALLCONV char*   Perl_delimcpy_no_escape(char* to, const char* toend, 
const char* from, const char* fromend, int delim, I32* retlen);
-+#define PERL_ARGS_ASSERT_DELIMCPY_NO_ESCAPE   \
-+  assert(to); assert(toend); assert(from); assert(fromend); assert(retlen)
- PERL_CALLCONV voidPerl_despatch_signals(pTHX);
- PERL_CALLCONV_NO_RET OP*  Perl_die(pTHX_ const char* pat, ...)
-   __attribute__noreturn__
-diff --git a/t/op/taint.t b/t/op/taint.t
-index 101c6da..846ac23 100644
 a/t/op/taint.t
-+++ b/t/op/taint.t
-@@ -17,7 +17,7 @@ BEGIN {
- use strict;
- use Config;
- 
--plan tests => 808;
-+plan tests => 812;
- 
- $| = 1;
- 
-@@ -187,6 +187,22 @@ my $TEST = 'TEST';
-   like($@,

ppisar set the monitor flag of rpms/perl-Module-Runtime to nobuild

ppisar set the monitor flag of rpms/perl-Module-Runtime to nobuild

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

[Bug 1471443] perl-Module-CoreList-5.20170715 is available