Re: No minimal install anymore?

[Adam Williamson]

On Wed, 2016-06-15 at 20:18 -0500, den...@ausil.us wrote:
> Additionally everything is installable provides the minimal offering
> and has anaconda's defaults rather than servers.

In case you couldn't parse that, Dennis means the 'Everything' network
install image, which is basically the same as the old generic network
install image from pre-F22 - it offers all environment groups for
install, and uses the distribution generic default configuration (as
opposed to Server's default configuration).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Fedocal] Reminder meeting : Fedora 24 Final Go/No-Go Meeting - the 2nd round

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Fedora 24 Final Go/No-Go Meeting - the 2nd round on 2016-06-16 from 17:00:00 
to 19:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 24.

The meeting is scheduled at 17:00 UTC. Please follow the [FedoCal]
link to find the time of the meeting in your time-zone.

[FedoCal] https://apps.fedoraproject.org/calendar/meeting/4328/

"Before each public release Development, QA and Release Engineering
meet to determine if the release criteria are met for a particular
release. This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of
the QA Team."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 24 Final Blocker list:
https://qa.fedoraproject.org/blockerbugs/milestone/24/final/buglist

Thanks for attending,
Jan


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

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

Re: Fedora development of Snap packages

[Gerald Henriksen]

On Wed, 15 Jun 2016 22:18:00 -0400, you wrote:

>Snaps function very much like how Apple's ecosystem does for software
>delivery, and perhaps even Microsoft's UWP ecosystem too. It's very
>clear that the purpose of Snaps are to provide avenues to "encourage"
>people to lock into the Ubuntu platform.
>
>So far, I've seen people gloss over the real crux of the problem,
>which is that somehow we're trying to create walled gardens, and no
>one wants to fix that.

No, the problem is that the developers of open source projects and
languages have viewed the strict rules around packages in a
distribution as a problem, and have worked around it.

Swift (you know, the hot new language that still isn't in Fedora), Go,
Python, Node.js, etc. have all created their own "packaging" systems
to either bypass the traditional Linux distribution or to handle
running on macOS or Windows that don't have a packaging system.

Combine this with the fact that a lot of the development (most?) is no
longer happening on Linux for various reasons, and that the dependency
chain on a lot of software is a packaging nightmare, and you have
Ubuntu (with Snap), GNOME (with Flatpak), and the server people (with
Docker) all coming up with simpler ways to try and get stuff packaged
given the lack of volunteers to even try and get stuff packaged in the
traditional way.

The current method of packaging rpms in Fedora is not working - there
are simply too many things that aren't getting packaged - and a
simpler alternative needs to be found.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Bill Nottingham]

Neal Gompa (ngomp...@gmail.com) said: 
> And frankly, if you're trying to solve delivering software in a
> cross-distro fashion, you're doing it wrong. Take for example how RPMs
> "work": packages are generated with a set of generic dependencies
> based on the symbols of libraries and programs. There is literally no
> reason why I couldn't make a package on CentOS 7 and expect it to work
> on virtually every Linux distribution release from around that time.
> 
> To the best of my knowledge, the only significant breakage is with
> OpenSSL, where Fedora refused to set the same soversion that Debian,
> Mageia, Ubuntu, and other distros chose (1.0.0). This symbol break has
> led to it becoming impossible to ship something built on Fedora to
> work on a wide variety of distributions.
> 
> Much of the way RPM is designed is to *promote* cross-distro (and to
> some extent, cross-OS) packages. The fact that we don't is more of an
> artifact of the past than anything else. It continues to amaze me that
> we've given up on promoting our core technology in such a manner. In
> many, many, many ways, it is technically superior (in terms of
> flexibility and fitness for purpose) to the other alternatives out
> there, but everyone seems to have given up.

I would argue that the fact that very very very few upstreams even try to do
this puts the lie to the idea that RPM is a sufficient technology for this. 
Heck, Fedora doesn't even try to do this across Fedora versions in general
(MASS REBUILD THE WORLD!), and we control all of it.

Even those that do try for 'single' RPM builds accomplish this by
a) bundling the world outside of some really minimal LSB libs (for which
distros will yell at you... see this thread)
b) adding giant hacked shell scripts that includes a bunch of if statements
for distro-specific code (for which distros will yell at you... see this
thread)

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

Re: Fedora development of Snap packages

[Kevin Kofler]

Michael Catanzaro wrote:
> Background info: In the Workstation working group, we're currently
> planning to allow replacing RPM packages for graphical apps with
> Flatpaks. We're also planning to remove Fedora packages for selected
> apps that are offered as Flatpaks by upstream. For instance, if
> (hypothetical) Inkscape were to offer a Flatpak download on their web
> site, the Inkscape developers could request that we remove the Inkscape
> Fedora package and display their Flatpak in GNOME Software instead; the
> goal here is to reduce friction between upstream and downstream that
> people complain about so often, while ensuring it's still very easy to
> find and install software that runs reliably on Fedora. I guess we
> could do the same with snaps, if they become sufficiently popular, but
> it'd be quite unfortunate to support two competing desktop
> containerization solutions.

I find this completely unacceptable (no matter whether you end up using 
Flatpak, Snap or whatever other flavor of containerized application format). 
A container is NOT an appropriate replacement for a distribution package.

Containers necessarily bundle at least some libraries, thus coming with all 
the drawbacks of bundled libraries: problems keeping up with security 
updates, wasted space (bandwidth, disk and RAM), etc.

They will also never be supported outside of GNOME Software and MAYBE, if 
you're lucky, some day, Plasma Discover. There are many more ways to install 
applications: Apper, Yumex-DNF, the DNF command line, etc. I strongly doubt 
those will ever support containers in an integrated way. (In fact, I hope 
they won't. I don't want my package manager spammed with things that are 
clearly not packages.)

Even if you use GNOME Software, there are still going to be major 
differences in user experience depending on whether the package is actually 
a Flatpak or an RPM, even if the UI tries to hide it from you. E.g., the 
download time and the disk space requirements will necessarily be 
significantly higher for the Flatpak. There may also be differences in user 
experience due to the use of different libraries (different versions, 
different patches applied, different build-time configuration, etc.). And 
the sandboxing part of the containerization can also negatively affect the 
user experience.

And whether we want to package an application as an RPM should always be a 
function of whether somebody here in Fedora wants to package it, NOT of 
whether upstream wants it packaged. If the license allows us to package the 
software, and if we have people willing to do it, why would we let us get 
terms dictated from upstream that are not part of the license and in fact 
blatantly conflict with it?

I have also been pointed to this link: http://kmkeen.com/maintainers-matter/

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

Re: Fedora development of Snap packages

[Neal Gompa]

On Wed, Jun 15, 2016 at 9:39 PM, Colin Walters  wrote:
> Hi,
>
> On Tue, Jun 14, 2016, at 09:18 PM, Michael Catanzaro wrote:
>
>> Also, keep in mind that Flatpaks are not the only new type of software
>> we intend to support in Fedora. I know other folks are looking into
>> supporting Docker containers; I believe that's a Server WG initiative?
>
> One of the things that is still odd about Fedora is that people often
> say "Fedora" and most of the time they mean as a desktop OS.
>

Why do you think that is weird? Fedora is a perfectly fine desktop
Linux distribution. I'm wondering what your problem is if you think
that it can't be. Yeah, I get that many of you guys at Red Hat don't
care, but that doesn't mean that the rest of us don't. Besides, for a
lot of people, mentioning "Fedora" and "server" in the same sentence
in some positive manner would get you laughed right out! I personally
like server platforms with fresh software, as I'm a firm believer in
that keeping things fresh is the best way to be secure. Just because
it's an unpopular opinion doesn't make it any less of a valid
approach, though.

> Anyways, so yes we've invested quite a lot in Docker for server containers,
> and more specifically in Kubernetes and OpenShift v3.
>
> See:
>
> https://www.openshift.org/
>
> for lots more, and the effort we spend on Docker and Atomic Host
> is at http://www.projectatomic.io/ and that work lands in Fedora
> as well as CentOS.  Most of the production work honestly is in CentOS,
> but there have been discussions about improving the server/cloud/OpenShift
> state in Fedora as well.
>

Not that I don't like the underlying technologies that you're working
on (I do, and I think rpm-ostree is wicked cool!), but it's pretty
darn close-minded if you think of only one potential avenue for
usefulness. Michael Catanzaro suffers from the same problem, but only
from a different perspective.

If we start off with the assumption that the approaches being done by
Docker, Flatpak, and others is a reasonably sound approach (I could
easily make the argument otherwise, and I have earlier in the thread),
then it's important to pick apart what they are and what they do.

Docker is a platform for distributing container construction scripts
and base images. Much like how ebuilds and ports work, Dockerfiles are
simple instructions to create *something* to use. However, the
artifact it creates is a container filesystem tree, rather than a
package that can be integrated into a system. Nothing about Docker
provides any useful security in and of itself. Band-aids like using
sVirt and whatnot help, but that's not available to everyone, so you
can't assume everyone is using it.

Flatpak is a mechanism for provided self-contained applications
derived from already built artifacts, such as runtime images and
application build artifacts. It's supposed to provide sandboxing and
other things, but none of them are functional. It's also not very
flexible, as it's designed exclusively for graphical applications.

Snap is a mechanism like Flatpak, though it's also designed to support
more use-cases than Flatpak. To some degree, it combines Docker and
Flatpak into a single system. The big problem with Snaps is that
they're effectively dead in the water security-wise on any
distribution that isn't Ubuntu (and *maybe* openSUSE/SLES). Snaps,
unlike Flatpaks, are able to handle *all* kinds of things, from web
apps, to desktop graphical apps, to CLI and TUI apps, and even
services and servers.

Snaps have three big flaws:

1. For maximum usefulness an discovery, they have to be centrally
registered with Canonical, who is the sole publisher. This is further
compounded by the fact that none of the server components are planned
to be open sourced (I asked this morning in #snappy), so there's not
even a snowball's chance of democratizing the platform like there is
with Docker.

2. Snaps are designed for apps that "bundle all the things" and don't
provide an easy way to introspect and manage the state of the snaps
included. There's no information on what a snap is composed of, and
that's a huge security nightmare. The format is highly simplistic and
encourages very fat bundles, which is not good for bandwidth or
storage. Flatpaks are marginally better due to "runtimes" built into
the design.

3. Snaps are expressly designed to integrate tightly with Ubuntu, and
currently even relies on Ubuntu-specific code in various aspects of
the OS (AppArmor, Ubuntu Software, etc.). It even goes so far as
making it possible to compose and manage an operating system using
Ubuntu packages as inputs.

Snaps function very much like how Apple's ecosystem does for software
delivery, and perhaps even Microsoft's UWP ecosystem too. It's very
clear that the purpose of Snaps are to provide avenues to "encourage"
people to lock into the Ubuntu platform.

So far, I've seen people gloss over the real crux of the problem,
which is that somehow we're trying to create 

Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Kevin Kofler]

Michael Catanzaro wrote:
> I propose we retire the webkitgtk and webkitgtk3 packages when
> branching rawhide for F26 (expected to occur roughly February 2017),
> and forbid unretiring them. All their dependencies would then be
> removed from from Fedora according to the normal process shortly before
> the release of F27 (excepted to occur May 2017). If nobody objects,
> we'll carry out this plan shortly after the F26 branch point.

Looking at the terabazillion affected packages, this will be a trainwreck!

For QtWebKit, everyone was saying that it is impossible to keep supporting 
the old API. Then someone came and just did it. IMHO, this is the only 
practicable solution for WebKitGTK as well. Well, that or port all the 
applications in the list.

There are some extremely-high-profile applications in your list of affected 
packages: GIMP, SAGE (sagemath), Audacity, etc., and even GNOME Shell! (Now 
*I* wouldn't complain if GNOME Shell were removed from Fedora, but… ;-) ) So 
removing all those packages from Fedora, and even effectively forbidding 
them from being readded, is not practicable.

> Answer: If you're sure your application never processes untrusted
> input, it is a special flower. You should request a bundling exception
> from FESCo if you do not intend to upgrade.

So you want to replace one copy of vulnerable code by many copies of 
vulnerable code? How is that going to help any? It would also severely bloat 
the distribution, given the huge size of WebKit. This is just totally 
impractical.

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

Re: Fedora development of Snap packages

[Colin Walters]

Hi,

On Tue, Jun 14, 2016, at 09:18 PM, Michael Catanzaro wrote:

> Also, keep in mind that Flatpaks are not the only new type of software
> we intend to support in Fedora. I know other folks are looking into
> supporting Docker containers; I believe that's a Server WG initiative?

One of the things that is still odd about Fedora is that people often
say "Fedora" and most of the time they mean as a desktop OS.

Anyways, so yes we've invested quite a lot in Docker for server containers,
and more specifically in Kubernetes and OpenShift v3.  

See:

https://www.openshift.org/

for lots more, and the effort we spend on Docker and Atomic Host
is at http://www.projectatomic.io/ and that work lands in Fedora
as well as CentOS.  Most of the production work honestly is in CentOS,
but there have been discussions about improving the server/cloud/OpenShift
state in Fedora as well.


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

Re: No minimal install anymore?

[dennis]

Additionally everything is installable provides the minimal offering and has 
anaconda's defaults rather than servers.

Dennis

On June 15, 2016 4:31:03 PM CDT, Chris Murphy  wrote:
>Actually this is better:
>
>https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/message/4UGRPRK7J5NCSUW5KO7MDXGY56I446LY/
>--
>devel mailing list
>devel@lists.fedoraproject.org
>https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Ben Boeckel]

On Wed, Jun 15, 2016 at 19:24:35 -0500, Michael Catanzaro wrote:
> The reason we don't offer a sync API is that it could cause your
> application to hang during IPC between the browser process and the web
> process.

Understood. It's one of the reasons we're looking at getting the "uzbl"
bits separate from the "gui" bits. Unfortunately, there's lots of
crosstalk (accessing GTK objects from the other thread is fraught with
peril as one would expect) and C is not exactly the most…expressive
language for such things.

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

Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Michael Catanzaro]

On Wed, 2016-06-15 at 19:50 -0400, Ben Boeckel wrote:
> That works if you can deal with the result being asynchronous, but if
> your callback doesn't belong in the GUI thread…

Ah, I think this arose from the discussion about disabling/enabling
context menu items. [1] is related.

The reason we don't offer a sync API is that it could cause your
application to hang during IPC between the browser process and the web
process.

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

Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Ben Boeckel]

On Wed, Jun 15, 2016 at 18:23:00 -0500, Michael Catanzaro wrote:
> On Wed, 2016-06-15 at 22:26 +, Ben Boeckel wrote:
> > Note that running JavaScript code in the context of the webpage also
> > requires an extension (AFAICS).
> 
> Fortunately, you can actually do this from the UI process using
> webkit_web_view_run_javascript() and
> webkit_web_view_run_javascript_finish().
> 
> [1] 
> http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-run-javascript

That works if you can deal with the result being asynchronous, but if
your callback doesn't belong in the GUI thread…

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

Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Michael Catanzaro]

On Wed, 2016-06-15 at 22:26 +, Ben Boeckel wrote:
> Note that running JavaScript code in the context of the webpage also
> requires an extension (AFAICS).

Fortunately, you can actually do this from the UI process using
webkit_web_view_run_javascript() and
webkit_web_view_run_javascript_finish().

[1] 
http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-run-javascript
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 June 2016 at 22:07, Paul W. Frields  wrote:

> On Wed, Jun 15, 2016 at 09:08:35AM -0700, Adam Williamson wrote:
> > On Wed, 2016-06-15 at 17:08 +0200, Alexander Larsson wrote:
> > > On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > > > So I was rather surprised by this Softpaedia article today:
> > > >
> http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > > > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > > > It claims that Canonical state that they have been working with
> > > > Fedora developers to make this the universal packaging format.
> > > > The snapcraft.io site instructions say to use a COPR by a Canonical
> > > > employee who is not a Fedora packager.
> > > > Does anyone in marketing or development now what the article is
> > > > referring to and what's going on?
> > >
> > > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > > doesn't use filesystem namespaces like flatpak), how does this work on
> > > fedora? You can't use selinux and apparmour at the same time, so this
> > > shouldn't be able to work, unless they disable the containment feature.
> >
> > Right now, apparently, their install instructions tell you to disable
> > SELinux.
>
> Permissive mode is what they require:
> https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
>
>
>
In terms of security of the system that's effectively the same as disabling.

There's no need to differentiate in this context.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Chris Murphy]

On Tue, Jun 14, 2016 at 7:36 PM, Neal Gompa  wrote:

> The container/security thing is nothing specific or special to Flatpak
> and others, in fact it's more theater than anything else anyway, as it
> only works when conditions are "just right" (i.e., Wayland,
> supercharged containerization with SELinux, etc.).

If Flatpak applications silently run without sandboxing, I think it's
a problem. The user is being asked to trust that these applications
offer better security, so they need to do that or they need to be
informed in some user friendly manner.

I'd rather be bugged (spammed, whatever) every time I run a Flatpak
application that is not being sandboxed, than for this to be silently
not using sandboxing. I'd even rather have the application fail to
launch by default, if sandboxing won't occur, possibly with a user
override, even if that override were tedious, i.e. a flag used to
launch the application from command line, although maybe that's
creating too easy of an attack vector.


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

Re: Source, symbols and debuginfo for flatpaks/snaps

[Alexander Larsson]

On Wed, 2016-06-15 at 21:38 +0200, Mark Wielaard wrote:

> O! I see in builder/builder-utils.c "This code is based on
> debugedit.c
> from rpm". And I am just hacking on that for rpm (see some patches on
> rpm-ma...@rpm.org). 

Its just part of the debugedit stuff though, because we don't have to
rewrite the paths.

> Maybe it is an idea to extract that code and provide
> a "standalone" debugedit program that different packaging programs
> (rpmbuild, flatpak-builder, ...) could use to collect build-ids and
> debuginfo source path cleanups? 

Seems like a great idea.

> What would be a good list to discuss
> that? rpm-ecosystem, flatpak-devel?

I dunno. The flatpak list is at:
 https://lists.freedesktop.org/mailman/listinfo/xdg-app
and I'm on that, but it doesn't strike me as an ideal place.
I'm not on rpm-ecosystem though.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposal: remove insecure WebKitGTK+ packages for F27

[Ben Boeckel]

On Fri, 10 Jun, 2016 at 16:39:21 GMT, Michael Catanzaro wrote:
> If your app does use the DOM API, you have more work as you need to
> create a web process extension to access this API. You can use any form
> of IPC to communicate between the UI process and the web process; D-Bus 
> is a good option. Documentation here:

Note that running JavaScript code in the context of the webpage also
requires an extension (AFAICS).

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

F24 RC-1.2 validation test requests: FCoE, SAS

[Adam Williamson]

Hey folks! There are a couple of validation tests for F24 remaining
which are kind of exotic and setup-dependent. Particularly:

https://fedoraproject.org/wiki/QA:Testcase_install_to_FCoE_target

if there's anyone out there who has an FCoE setup and can run that
test, it'd be great. Just go to:

https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Installation

grab one of the install media linked to at the top, and run the test.
You can enter your result directly into the wiki page or use the
'relval report-results' CLI (dnf install relval), whichever you like,
or just reply to this mail and say if it works or not and I'll deal
with the wiki.

I did try doing an all-software, virtualized FCoE setup to test in
openQA (like we did with iSCSI), but couldn't manage to make it fly,
there seems to be pretty limited (and rather old) documentation with
lots of gaps in it, and I wasn't smart enough to put it all together :/

There is also the SAS (serial-attached-SCSI) test:

https://fedoraproject.org/wiki/QA:Testcase_install_to_SAS

but we've been waiving that one on the grounds that no-one has the
hardware for so long that it's more or less an in-joke at this point.
Still, if anyone *does* have the hardware and can test it, that'd be
great!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: No minimal install anymore?

[Chris Murphy]

Actually this is better:

https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/message/4UGRPRK7J5NCSUW5KO7MDXGY56I446LY/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: No minimal install anymore?

[Chris Murphy]

On Wed, Jun 15, 2016 at 3:25 PM, Ravindra Kumar
 wrote:
> Hi,
>
>
>
> Please forgive my ignorance. Does Fedora 24 server image no longer provide
> "Minimal Install" option?
>
>
>
> I see only "Fedora Server" and "Fedora Custom" options. Please see the
> attached screenshot for reference.


Custom is minimal.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FSJAZJ6HR65RWW2AL27OMBGB65H5KFE5/



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

Re: Fedora development of Snap packages

[Dave Love]

Przemek Klosowski  writes:

> It would be nice if there was a 'container snapshot' facility that
> would convert between a native application package from Fedora or
> Debian and a portable container---possibly both ways. Obviously,
> native->container is desirable for portability; the opposite
> conversion is less obviously useful but might be a basis for a
> cross-platform packaging process in the future.

It's obviously not what you're thinking of, but there's Singularity,
under review .

As an example, I haven't managed to port Scilab packaging to EPEL6, but
with singularity I can run the f23 version (or the Debian one) on RHEL6:

  $ scilab -version
  Scilab version "5.5.2.1427793548"
  scilab-5.5.2

The executable is basically a Fedora 23 system image (installed with
yum, and quite large) with a configured entry point, in which you can
run other commands:

  $ singularity exec `which scilab` rpm -q basesystem
  basesystem-11-1.fc23.noarch

I'm not sure about "both ways", but you can operate on the contents as
appropriate.

> In my mind, containers are primarily useful to run arbitrary untrusted
> third party applications, but of course they need  a good enough
> sandbox system for that. I hope such system will emerge from the
> current work.

The above is a different "primarily useful" for some of us in research
computing, where we don't actually want operating system containment.
That's the job of the HPC resource manager, if anything.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 2:17 PM, Stephen Gallagher  wrote:
> On 06/15/2016 03:46 PM, Chris Murphy wrote:
>> I don't understand the technical reason for the 1st reboot. The
>> substantial risk for updates is the user environment. If that's killed
>> off even multi-user.target is far less risk to do updates in. But I
>> don't see why system-update.target can't be isolated from
>> graphical.target rather than mandating a reboot to get there.
>
> I tried to cover this in an earlier post, but the first reboot is to protect
> against things like "user temporarily mounted over /usr/lib/foo so updating 
> the
> foo package isn't actually modifying the persistent system" and "there's a
> memory-leak bug in the kernel so 99% of system RAM is held by kernel space 
> while
> trying to update" or other unpredictable things that can happen according to
> chaos theory when system as complex as a modern Fedora has been running for
> days/weeks/months without a reboot. The first reboot puts the system into a
> (mostly) known state, which is basically a band-aid around a thousand other
> unpredictabilities.

To me this sounds like user sabotage. But lets say I accept this as
sufficiently common that it needs accounting for...

Systemd could unmount everything down to nearly going back to the
initramfs without a reboot, then remount everything per the usual
fstab generator rules just like at startup time, and then commence the
update.

Or probably faster and more reliable would be an nspawn container that
bind mounts the fs per the usual fstab generator rules like at startup
time, and does the offline update in the container environment, which
inside that container would be like a new boot (sorta).

The alternatives appear to have more problems and limitations. We
can't have delayed or scheduled unattended updates on encrypted rootfs
since the user needs to enter a passphrase; or we need a substantially
reworked initramfs that brings up networking much earlier in boot to
connect to a key server in order to unlock rootfs.


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

Re: Fedora development of Snap packages

[Paul W. Frields]

On Wed, Jun 15, 2016 at 09:08:35AM -0700, Adam Williamson wrote:
> On Wed, 2016-06-15 at 17:08 +0200, Alexander Larsson wrote:
> > On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > > So I was rather surprised by this Softpaedia article today:
> > > http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > > It claims that Canonical state that they have been working with
> > > Fedora developers to make this the universal packaging format.
> > > The snapcraft.io site instructions say to use a COPR by a Canonical
> > > employee who is not a Fedora packager.
> > > Does anyone in marketing or development now what the article is
> > > referring to and what's going on?
> > 
> > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > doesn't use filesystem namespaces like flatpak), how does this work on
> > fedora? You can't use selinux and apparmour at the same time, so this
> > shouldn't be able to work, unless they disable the containment feature.
> 
> Right now, apparently, their install instructions tell you to disable
> SELinux.

Permissive mode is what they require:
https://copr.fedorainfracloud.org/coprs/zyga/snapcore/

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Review Swap: Python Packages

[William Moreno]

2016-06-15 14:43 GMT-06:00 Avram Lubkin :

> I have a couple of simple Python packages that need to be reviewed. Will
> review yours in return.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1347006:
> python-sphinxcontrib-spelling
> https://bugzilla.redhat.com/show_bug.cgi?id=1340619: python-imagesize
>
>
I will take them

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

Review Swap: Python Packages

[Avram Lubkin]

I have a couple of simple Python packages that need to be reviewed. Will
review yours in return.

https://bugzilla.redhat.com/show_bug.cgi?id=1347006:
python-sphinxcontrib-spelling
https://bugzilla.redhat.com/show_bug.cgi?id=1340619: python-imagesize

Thanks,

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

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 03:46 PM, Chris Murphy wrote:
> I don't understand the technical reason for the 1st reboot. The
> substantial risk for updates is the user environment. If that's killed
> off even multi-user.target is far less risk to do updates in. But I
> don't see why system-update.target can't be isolated from
> graphical.target rather than mandating a reboot to get there.

I tried to cover this in an earlier post, but the first reboot is to protect
against things like "user temporarily mounted over /usr/lib/foo so updating the
foo package isn't actually modifying the persistent system" and "there's a
memory-leak bug in the kernel so 99% of system RAM is held by kernel space while
trying to update" or other unpredictable things that can happen according to
chaos theory when system as complex as a modern Fedora has been running for
days/weeks/months without a reboot. The first reboot puts the system into a
(mostly) known state, which is basically a band-aid around a thousand other
unpredictabilities.




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

Re: Why GUI software update tool is broken for me

[Przemek Klosowski]

On 06/15/2016 09:27 AM, Phil Cameron wrote:

On 06/15/2016 05:16 AM, Emmanuel Seyman wrote:
Id be interested in the original rationale behind this change, as I 
say, I

I believe the rationale is that there was no sane way to update running
applications (firefox, at least, would start not working in interesting
ways when you update it after having launched it).


So when you update an application that is running all you do is 
unlink the file name from the old file and link it to the new file. 
The old file does not go away because it is open by the running 
program. When the program exits, the file is deleted (only if the 
reference count is 0). The next time the program is run it will use 
the new file. 


There's also the issue of all the process-to-process communications: 
desktop bus, systemd and inter-app API, etc. The updated processes may 
speak a different language, and currently there's no unified way to 
express those relationships/dependencies. Some of the data may be even 
in-flight, so static version checking is not enough: consider the 
scenario of appA 1.0 checking and sending a desktop bus message to appB 
1.0; then appB gets updated to 2.0, and doesn't understand the message 
it receives.


I totally agree with you that requiring offline updates with reboot is 
heavy-handed, but it's the only reliable way given the current state of 
technology. You and I live dangerously by delaying those reboots, but 
there's a downside to that.


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

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 12:43 PM, Stephen Gallagher  wrote:
> On 06/15/2016 02:36 PM, Chris Murphy wrote:
>> On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher  
>> wrote:
>>> On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
 On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
> Of course, this comes with its own headaches, since of course if you
> are using
> an encrypted drive, you need to enter your password twice: once to
> start the
> update and once for the post-update reboot. A while ago I was working
> on a patch
> to PackageKit that would skip the second reboot and just `systemd
> isolate
> default.target` after the upgrade unless the kernel (or other early
> boot package
> like dracut) was updated. I never finished it, but I could try to dig
> it out and
> pass it on to someone who is interested in continuing it.

 If anyone wants to pick up this work, that would be hugely appreciated,
 as it would allow us to enable full disk encryption by default.

>>>
>>> Well, as I alluded to in another post, I think the disk encryption case is
>>> probably better solved by investing in the development and stabilization of
>>> Tang[1]. Then you would not need to enter the password manually at all.
>>>
>>> [1] https://github.com/npmccallum/tang/blob/master/README.md
>>
>> I see that it's solving a problem, but that problem isn't everyone's
>> problem, and the solution doesn't solve everyone's problem. It
>> requires a tang server, so how does this work for Workstation users?
>> Where is this server?
>>
>> I go to a random coffee shop, I'm on a totally different network, or I
>> travel a lot and I'm on many different networks, how does this scale?
>>
>
> One thing I've been thinkin about is building a tang server as an Android
> application, so that you can decrypt your system simply by having the computer
> make a temporary ad-hoc connection to your cellphone. If it's not within WiFI
> range, the computer doesn't unlock.

OK fine, but the context is doing pk offline updates. If the system
has an encrypted disk, it needs an initramfs that brings up networking
in order to find the tang server on my cell phone. My laptop
definitely does not have network access at all in the
system-update.target.



>> For a computer that needs to update an encrypted disk with the current
>> pk offline update mechanism means networking all has to be baked into
>> the initramfs and autoconfiguring in order for the disk to be
>> decrypted and updates applied.
>>
>
> That makes me nervous as storing the key in something that can survive a 
> reboot
> means that the key is potentially recoverable (such as if the machine gets
> powered off before the second reboot).

I'm not suggesting storing the key in the initramfs. I'm suggesting
networking needs to be brought up in the initramfs to find the tang
server in order to decrypt the drive. That's a substantially different
initramfs than we currently have as far as I'm aware.



>
>> I still think the update needs to happen on logout without first
>> rebooting, and only rebooting after the update is successfully
>> applied. If it were a scheduled/delayed update, then the default
>> behavior would be shutdown after the update is applied rather than
>> reboot.
>>
>> Something like that.
>>
>
> I think ostree is a better fit for you, then. It's atomic; you know before the
> reboot whether the packages will update cleanly or not (and you have a full
> rollback if something in runtime is broken). It requires no special mode to 
> prep
> the update, either.

What? Why does this suddenly need a completely different deployment
system to do something so basic? In particular one that's not yet
really ready for prime time.

Windows and macOS both do updates on logout and then reboot. They do
not reboot and then do updates, and neither of them have the benefit
of rpm-ostree. And they've both been doing this for an ungodly amount
of time, 20 some years give or take.

I don't understand the technical reason for the 1st reboot. The
substantial risk for updates is the user environment. If that's killed
off even multi-user.target is far less risk to do updates in. But I
don't see why system-update.target can't be isolated from
graphical.target rather than mandating a reboot to get there.


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

Re: Source, symbols and debuginfo for flatpaks/snaps

[Mark Wielaard]

On Wed, 2016-06-15 at 16:59 +0200, Alexander Larsson wrote:
> On Wed, 2016-06-15 at 12:19 +0200, Mark Wielaard wrote:
> > On Tue, 2016-06-14 at 22:02 +0200, Igor Gnatenko wrote:
> > > When DNF will be able to install flatpack pkgs then we can stop
> > > supporting
> > > distro packages for that.
> > 
> > One of the things I am working on is making access to sources,
> > symbols
> > and debuginfo easier for rpm packages as distributed by Fedora. That
> > helps users profiling, debugging and tracing the things they run on
> > their systems. For some background see:
> > https://gnu.wildebeest.org/blog/mjw/2016/02/02/where-are-your-symbols
> > -debuginfo-and-sources/
> > https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
> 
> Flatpak supports something called "extensions", where an app (or a
> runtime) can specify extension points which are then optionally there
> when running the app. One use of this in flatpak is debuginfo
> extensions for the case above (another is locale data). Also, if you
> use flatpak-builder to build your app then these are automatically
> built for you, similar to how rpm does it (which support for was also
> written by me).

O! I see in builder/builder-utils.c "This code is based on debugedit.c
from rpm". And I am just hacking on that for rpm (see some patches on
rpm-ma...@rpm.org). Maybe it is an idea to extract that code and provide
a "standalone" debugedit program that different packaging programs
(rpmbuild, flatpak-builder, ...) could use to collect build-ids and
debuginfo source path cleanups? What would be a good list to discuss
that? rpm-ecosystem, flatpak-devel?

Thanks,

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

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

[James Antill]

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

 Local time information (via. rktime):

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

 Links to all tickets below can be found at: 

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

= Followups =

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

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

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

#topic #628 Reserve UID/GID for cassandra
.fpc 628
https://fedorahosted.org/fpc/ticket/628

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

= Open Floor = 

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

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

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 12:46:43PM -0400, Matthew Miller wrote:
> > Thats is pretty crappy. That means things will keep accidentally being
> > packaged that depends on things not in the ubuntu core. It also means
> > that there is zero sandboxing.
> Can you elaborate on how this is different from Flatpak's
> currently-rather-open sandboxing (as seen elsewhere in this thread)?

Or, let me rephrase: I *think* the difference, communication approaches
aside, is: With Flatpak, we're telling developers that they need to
currently package their apps with large holes poked by default because
portals aren't available yet, let alone the corresponding application
changes. With Snappy, developers are encouraged to package as if a
sandboxing framework is in effect, but that on many distros, it won't
be. Correct?

-- 
Matthew Miller

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

[Bug 1344670] perl-MooseX-Types-Path-Class-0.09 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1344670
Bug 1344670 depends on bug 1346458, which changed state.

Bug 1346458 Summary: Review Request: perl-Test-Needs - Skip tests when modules 
not available
https://bugzilla.redhat.com/show_bug.cgi?id=1346458

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



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

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 02:36 PM, Chris Murphy wrote:
> On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher  
> wrote:
>> On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
>>> On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
 Of course, this comes with its own headaches, since of course if you
 are using
 an encrypted drive, you need to enter your password twice: once to
 start the
 update and once for the post-update reboot. A while ago I was working
 on a patch
 to PackageKit that would skip the second reboot and just `systemd
 isolate
 default.target` after the upgrade unless the kernel (or other early
 boot package
 like dracut) was updated. I never finished it, but I could try to dig
 it out and
 pass it on to someone who is interested in continuing it.
>>>
>>> If anyone wants to pick up this work, that would be hugely appreciated,
>>> as it would allow us to enable full disk encryption by default.
>>>
>>
>> Well, as I alluded to in another post, I think the disk encryption case is
>> probably better solved by investing in the development and stabilization of
>> Tang[1]. Then you would not need to enter the password manually at all.
>>
>> [1] https://github.com/npmccallum/tang/blob/master/README.md
> 
> I see that it's solving a problem, but that problem isn't everyone's
> problem, and the solution doesn't solve everyone's problem. It
> requires a tang server, so how does this work for Workstation users?
> Where is this server?
> 
> I go to a random coffee shop, I'm on a totally different network, or I
> travel a lot and I'm on many different networks, how does this scale?
> 

One thing I've been thinkin about is building a tang server as an Android
application, so that you can decrypt your system simply by having the computer
make a temporary ad-hoc connection to your cellphone. If it's not within WiFI
range, the computer doesn't unlock.

But yes, the main use-case for Tang is datacenters that don't want their drives
unencrypted at rest (in case they get thrown out or returned for service), but
don't want an interactive prompt when they need to do a rolling update requiring
a reboot.


> For a computer that needs to update an encrypted disk with the current
> pk offline update mechanism means networking all has to be baked into
> the initramfs and autoconfiguring in order for the disk to be
> decrypted and updates applied.
> 

That makes me nervous as storing the key in something that can survive a reboot
means that the key is potentially recoverable (such as if the machine gets
powered off before the second reboot).

> I still think the update needs to happen on logout without first
> rebooting, and only rebooting after the update is successfully
> applied. If it were a scheduled/delayed update, then the default
> behavior would be shutdown after the update is applied rather than
> reboot.
> 
> Something like that.
> 

I think ostree is a better fit for you, then. It's atomic; you know before the
reboot whether the packages will update cleanly or not (and you have a full
rollback if something in runtime is broken). It requires no special mode to prep
the update, either.



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

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 11:15 AM, Stephen Gallagher  wrote:
> On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
>> On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
>>> Of course, this comes with its own headaches, since of course if you
>>> are using
>>> an encrypted drive, you need to enter your password twice: once to
>>> start the
>>> update and once for the post-update reboot. A while ago I was working
>>> on a patch
>>> to PackageKit that would skip the second reboot and just `systemd
>>> isolate
>>> default.target` after the upgrade unless the kernel (or other early
>>> boot package
>>> like dracut) was updated. I never finished it, but I could try to dig
>>> it out and
>>> pass it on to someone who is interested in continuing it.
>>
>> If anyone wants to pick up this work, that would be hugely appreciated,
>> as it would allow us to enable full disk encryption by default.
>>
>
> Well, as I alluded to in another post, I think the disk encryption case is
> probably better solved by investing in the development and stabilization of
> Tang[1]. Then you would not need to enter the password manually at all.
>
> [1] https://github.com/npmccallum/tang/blob/master/README.md

I see that it's solving a problem, but that problem isn't everyone's
problem, and the solution doesn't solve everyone's problem. It
requires a tang server, so how does this work for Workstation users?
Where is this server?

I go to a random coffee shop, I'm on a totally different network, or I
travel a lot and I'm on many different networks, how does this scale?

For a computer that needs to update an encrypted disk with the current
pk offline update mechanism means networking all has to be baked into
the initramfs and autoconfiguring in order for the disk to be
decrypted and updates applied.

I still think the update needs to happen on logout without first
rebooting, and only rebooting after the update is successfully
applied. If it were a scheduled/delayed update, then the default
behavior would be shutdown after the update is applied rather than
reboot.

Something like that.

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

cbm pushed to perl-Text-BibTeX (master). "Version bump (#1346644)"

[notifications]

From 93356a9499f2c407fda97c30e0940983bce0f944 Mon Sep 17 00:00:00 2001
From: "Colin B. Macdonald" 
Date: Wed, 15 Jun 2016 11:13:08 -0700
Subject: Version bump (#1346644)

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

diff --git a/.gitignore b/.gitignore
index 4057aa0..3e7e4eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Text-BibTeX-0.70.tar.gz
 /Text-BibTeX-0.71.tar.gz
 /Text-BibTeX-0.72.tar.gz
+/Text-BibTeX-0.74.tar.gz
diff --git a/perl-Text-BibTeX.spec b/perl-Text-BibTeX.spec
index 73b755e..ef97049 100644
--- a/perl-Text-BibTeX.spec
+++ b/perl-Text-BibTeX.spec
@@ -1,6 +1,6 @@
 Name:   perl-Text-BibTeX
-Version:0.72
-Release:2%{?dist}
+Version:0.74
+Release:1%{?dist}
 Summary:Interface to read and parse BibTeX files
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -72,6 +72,9 @@ chrpath -d $RPM_BUILD_ROOT%{_bindir}/*
 %{_libdir}/*.so
 
 %changelog
+* Wed Jun 15 2016 Colin B. Macdonald  - 0.74-1
+- Version bump (#1346644)
+
 * Sun May 15 2016 Jitka Plesnikova  - 0.72-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index ea1d4ed..1778348 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-699d7c6439ba6fc4a3502a67827a2109  Text-BibTeX-0.72.tar.gz
+1bd024c079b71a30e3565fe103ddf333  Text-BibTeX-0.74.tar.gz
-- 
cgit v0.12



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

[Bug 1346644] perl-Text-BibTeX-0.74 is available

[bugzilla]

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



--- Comment #8 from Upstream Release Monitoring 
 ---
cbm's perl-Text-BibTeX-0.74-1.fc25 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=773276

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

cbm uploaded Text-BibTeX-0.74.tar.gz for perl-Text-BibTeX

[notifications]

1bd024c079b71a30e3565fe103ddf333  Text-BibTeX-0.74.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Text-BibTeX/Text-BibTeX-0.74.tar.gz/md5/1bd024c079b71a30e3565fe103ddf333/Text-BibTeX-0.74.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Rob Clark]

On Wed, Jun 15, 2016 at 12:07 AM, Florian Weimer  wrote:
> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
>
>> I *strongly* disagree here.  The xdg-app folks seem to be doing a
>> pretty good job with their sandbox.  The kernel attack surface is
>> reduced considerably, as is the attack surface against the user via
>> ptrace and filesystem access.  If Wayland is available (which is
>> should be!) then so is the attack surface against X.
>
>
> What about the direct access to DRI device nodes?  Why isn't this a problem
> that reduces the effectiveness of the sandbox considerably?

I think the theory is only allow access to render-nodes, which can
only access other processes buffers via dma-buf import (ie. other
process had to pass you the file-descriptor, which would be how buffer
sharing w/ wayland compositor works)

Not completely sure off the top of my head what the current state of
things are w/ g-s wayland and use of render nodes vs legacy
everyone-open /dev/dri/card0 and do dri2 auth dance..  but
render-nodes plus dma-buf is the way to isolate various users of gpu
as best as possible.

BR,
-R

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

Re: Fedora development of Snap packages

[Adam Williamson]

On Wed, 2016-06-15 at 12:46 -0400, Matthew Miller wrote:
> On Wed, Jun 15, 2016 at 06:25:17PM +0200, Alexander Larsson wrote:
> > > That's precisely what they are doing on non-Ubuntu distributions,
> > > disabling confinement.
> > Thats is pretty crappy. That means things will keep accidentally being
> > packaged that depends on things not in the ubuntu core. It also means
> > that there is zero sandboxing.
> 
> Can you elaborate on how this is different from Flatpak's
> currently-rather-open sandboxing (as seen elsewhere in this thread)?

It's different in that we're not issuing press releases loudly touting
how great it is. i.e. we're following responsible development
practices: while the product isn't actually done yet, we're talking
about it on blogs and at developer conferences and working to complete
it. While *their* product isn't actually done yet, Canonical is issuing
press releases which beg their readers to infer that a) Snappy is
completely done and b) all distributions have adopted it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1346478] perl-Business-CreditCard-0.36 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Business-CreditCard-0.36-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-0402eaadc3

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

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

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Devel-PPPort-3.34-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-3982e4e080

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

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

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Getopt-Long-2.49-1.fc23 has been pushed to the Fedora 23 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-cba245e24f

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

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 10:31 AM, Stephen Gallagher  wrote:


> Of course, this comes with its own headaches, since of course if you are using
> an encrypted drive, you need to enter your password twice: once to start the
> update and once for the post-update reboot.

Why not change from logout > reboot > update > reboot, to logout >
update > reboot/shutdown? I don't see how unattended/scheduled updates
can really work otherwise. It's probably not sane to stick the KEK
(hash) into NVRAM so it's there for unattended updates even if there's
a sure fire way to remove that entry after the reboot.

> A while ago I was working on a patch
> to PackageKit that would skip the second reboot and just `systemd isolate
> default.target` after the upgrade unless the kernel (or other early boot 
> package
> like dracut) was updated. I never finished it, but I could try to dig it out 
> and
> pass it on to someone who is interested in continuing it.

It's the first reboot that needs to go away in order to solve the
unattended update problem though.

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

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

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Getopt-Long-2.49-1.fc22 has been pushed to the Fedora 22 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-dd875d1442

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

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

[bugzilla]

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



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

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

[Bug 1346478] perl-Business-CreditCard-0.36 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-Business-CreditCard-0.36-1.fc22 has been pushed to the Fedora 22 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-b81a89d979

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

Re: Why GUI software update tool is broken for me

[Bruno Wolff III]

On Wed, Jun 15, 2016 at 10:50:06 -0600,
 Kevin Fenzi  wrote:


Sure and there's encryption as sgallagh mentioned.


There is probably a way to handle the encryption as (at least if there isn't 
a kernel update), as this is done already when switching from initramfs 
to your normal system after getting disk passwords, during normal boots 
already.

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

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 12:31 PM, Stephen Gallagher wrote:
> 
> 
> The justification for restarting both before and after installation exists and
> it does make some sense in certain circumstances.
> 
> Basically, the problem is that any number of things can change in the state of
> the system while it has been running that are impossible to predict. For
> example, the system's memory (and swap) could be almost all used up, leading 
> to
> unpredictable behavior while processing the update and %pre/%post scripts. 
> Also,
> a user may have manually played around with the mount table, resulting in some
> directory paths being unmounted or mounted over that the upgrade would write
> into. By forcing the system to reboot into a limited environment, it puts the
> system into something much closer to a known state which is less likely to
> experience an unrecoverable error. (Ever had a runaway log fill up a disk 
> during
> a dnf update? Not a good thing.)
> 
> 
> Of course, this comes with its own headaches, since of course if you are using
> an encrypted drive, you need to enter your password twice: once to start the
> update and once for the post-update reboot. A while ago I was working on a 
> patch
> to PackageKit that would skip the second reboot and just `systemd isolate
> default.target` after the upgrade unless the kernel (or other early boot 
> package
> like dracut) was updated. I never finished it, but I could try to dig it out 
> and
> pass it on to someone who is interested in continuing it.
> 

I meant to also include a section here about how this problem is also completely
solved by ostree[1] (the technology used by Project Atomic and upcoming Fedora
Workstation changes) which works by prepping all of the state of the system
while the current system is running. Then the system is rebooted once directly
into the new system, atomically. This leaves no room at all for upgrade failures
leaving the system unusable.

Historically, there was a tradeoff here, because it was difficult to use ostree
for upgrades with a custom set of packages on the system, but recently a lot of
work has gone into doing package layering as well, so it's well on its way to
becoming a complete replacement of the traditional package-by-package updater.


[1] https://github.com/projectatomic/rpm-ostree/blob/master/README.md



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

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 01:09 PM, Michael Catanzaro wrote:
> On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
>> Of course, this comes with its own headaches, since of course if you
>> are using
>> an encrypted drive, you need to enter your password twice: once to
>> start the
>> update and once for the post-update reboot. A while ago I was working
>> on a patch
>> to PackageKit that would skip the second reboot and just `systemd
>> isolate
>> default.target` after the upgrade unless the kernel (or other early
>> boot package
>> like dracut) was updated. I never finished it, but I could try to dig
>> it out and
>> pass it on to someone who is interested in continuing it.
> 
> If anyone wants to pick up this work, that would be hugely appreciated,
> as it would allow us to enable full disk encryption by default.
> 

Well, as I alluded to in another post, I think the disk encryption case is
probably better solved by investing in the development and stabilization of
Tang[1]. Then you would not need to enter the password manually at all.

[1] https://github.com/npmccallum/tang/blob/master/README.md



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

Re: Why GUI software update tool is broken for me

[Bruno Wolff III]

On Wed, Jun 15, 2016 at 10:49:18 -0600,
 Kevin Fenzi  wrote:


Well, it's different historical behavior/tradeoffs. dnf assumes you
will reboot as you need to / restart apps that need restarting.


And there is an extension that will tell you what needs to be restarted.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Michael Catanzaro]

On Wed, 2016-06-15 at 12:31 -0400, Stephen Gallagher wrote:
> Of course, this comes with its own headaches, since of course if you
> are using
> an encrypted drive, you need to enter your password twice: once to
> start the
> update and once for the post-update reboot. A while ago I was working
> on a patch
> to PackageKit that would skip the second reboot and just `systemd
> isolate
> default.target` after the upgrade unless the kernel (or other early
> boot package
> like dracut) was updated. I never finished it, but I could try to dig
> it out and
> pass it on to someone who is interested in continuing it.

If anyone wants to pick up this work, that would be hugely appreciated,
as it would allow us to enable full disk encryption by default.

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

enable ABRT reports for glusterfs

[Kaleb S. KEITHLEY]

Hi,

My search engine fu is failing atm.

I get ABRT reports from notificati...@fedoraproject.org for another
package (nfs-ganesha) that I'm the maintainer for.

I'd like to enable ABRT reports for glusterfs. But I can't seem to find
where to do that.  Or maybe glusterfs never crashes!

Thanks,

-- 

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

Re: Why GUI software update tool is broken for me

[Kevin Fenzi]

On Wed, 15 Jun 2016 12:41:42 -0400
Russell Doty  wrote:

> Note that the original poster says that he runs dnf -update from the
> command line because it allows him to do what he wants.
> 
> Based on the information discussed in this thread, shouldn't dnf also
> force a reboot before updates?

Well, it's different historical behavior/tradeoffs. dnf assumes you
will reboot as you need to / restart apps that need restarting. 

> We have an observed difference between what is permitted in the cli
> tool and what is permitted in the gui tool. Why this difference?

History and tradeoffs. dnf (and yum before it) have always applied
updates when you asked without a reboot, and they have decided that the
problems with doing so are acceptable. 

I'd personally be against changing this behavior now, but it might be
nice to add a way to opt in with dnf... ie, a 'dnf update --offline' or
something to apply the updates the way that gnome-software does for
those that want that. 

kevin


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

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 12:41 PM, Russell Doty wrote:
> Note that the original poster says that he runs dnf -update from the
> command line because it allows him to do what he wants.
> 
> Based on the information discussed in this thread, shouldn't dnf also
> force a reboot before updates?
> 
> We have an observed difference between what is permitted in the cli
> tool and what is permitted in the gui tool. Why this difference?


Traditionally, we've assumed a greater level of understanding for those who use
CLI tools as opposed to GUI tools. It's expected that if someone is using DNF
directly, it's because they know what they are doing (and what risks that
carries). I'm not going to comment on whether that assumption is correct or not,
just that it's what generally determines the mode of operation.

People *can* use the command-line to get the reboot behavior:
```
pkcon update --only-download
pkcon offline-trigger
reboot
```

That said, there *is* value to allowing people to update individual things
without forcing a system reboot if they know enough to do so. (For example, if I
am updating a leaf-node GUI application that is not currently running).

I think it makes sense however to leave the graphical tool to follow best and
safest practice. Advanced users can use the CLI tools. I think we'd see *far*
more angry pitchforks if we took away that decision from DNF.



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

Re: Why GUI software update tool is broken for me

[Kevin Fenzi]

On Wed, 15 Jun 2016 10:45:12 -0600
Chris Murphy  wrote:

> Laptop users need reminding. A scheduled update has a decent chance of
> not happening because the laptop is sleeping.

Sure and there's encryption as sgallagh mentioned. 

> The ability for applications to save their state would be great; and
> to autolaunch at next login. If the user were to explicitly quit the
> application, part of its cleanup would be to unset that autolaunch. So
> it'd need some granularity to distinguish between 'next login
> autolaunch' and 'user specified persistent autolaunch'.

Yeah, I don't know if thats planned or just not going to happen. 

kevin
 



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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1346506] perl-Git-PurePerl-0.52 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1346655] perl-SOAP-Lite-1.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1346478] perl-Business-CreditCard-0.36 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1346508] perl-Git-Repository-1.320 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Git-Repository-1.320-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-2016-b194964983

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

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 17:47, "Matthew Miller"  wrote:
>
> On Wed, Jun 15, 2016 at 06:25:17PM +0200, Alexander Larsson wrote:
> > > That's precisely what they are doing on non-Ubuntu distributions,
> > > disabling confinement.
> > Thats is pretty crappy. That means things will keep accidentally being
> > packaged that depends on things not in the ubuntu core. It also means
> > that there is zero sandboxing.
>
> Can you elaborate on how this is different from Flatpak's
> currently-rather-open sandboxing (as seen elsewhere in this thread)?
>
> --
>

Perhaps because flatpak doesn't tell the user to disable selinux and is not
being actively promoted as the new secure application deployment technology
being embraced by multiple major distributions?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 06:25:17PM +0200, Alexander Larsson wrote:
> > That's precisely what they are doing on non-Ubuntu distributions,
> > disabling confinement.
> Thats is pretty crappy. That means things will keep accidentally being
> packaged that depends on things not in the ubuntu core. It also means
> that there is zero sandboxing.

Can you elaborate on how this is different from Flatpak's
currently-rather-open sandboxing (as seen elsewhere in this thread)?

-- 
Matthew Miller

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

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 10:27 AM, Kevin Fenzi  wrote:
> On Wed, 15 Jun 2016 17:39:32 +0200
> Kamil Dudka  wrote:
>
>> On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
>> > Dne 15.6.2016 v 10:14 Ade napsal(a):
>> > > Why is this?  Well some time ago the behaviour of the tool
>> > > changed and now the only way to proceed is to click in "Restart
>> > > and Install" and this is NEVER what I want to do. I never want to
>> > > reboot my desktop just to apply updates, Id rather apply all the
>> > > updates and reboot to bring in the new kernel (if there is one)
>> > > when I have the time
>> > Imagine two regular updates.
>> >
>> > First you update mariadb-server package. %post is smart and it will
>> > condrestart the mariadb service. However...
>> >
>> > Next day you update "pam" package which
>> > provides /usr/lib64/libpam.so.0 which is used by mariadb service.
>> > Unless you restart your computer your mariadb server will continue
>> > to use old (and maybe insecure) libpam.so. Or unless you use
>> > dnf-plugins-extras-tracer:
>> > http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html
>>
>> It is a reason to restart the system (or just the services of
>> interest) _after_ installing the update, but not before installing
>> the update.
>
> I think it's a combination of all these:
>
> * If you simply apply updates and don't restart everything that uses
>   the things updated you will not be taking advantage of the security
>   or bugfixes. If those things are used by a lot of your apps,
>   restarting each one is tedious and/or as disruptive as just rebooting
>   anyhow.
>
> * Even though live updates work 'pretty well' there will always be a
>   number of corner cases where applications will not function correctly
>   after they are updated but before they are restarted. Directories or
>   resources they need may have changed, etc.
>
> Running tracer for a while can really open your eyes to how many things
> need restarting after normal updates flow.
>
> One thing that might make this less annoying to people would be ability
> to schedule the reboot for some off hours time (2am or something) and
> also ability (for gnome at least) to restore apps/windows/session
> again on login.

Laptop users need reminding. A scheduled update has a decent chance of
not happening because the laptop is sleeping.

The ability for applications to save their state would be great; and
to autolaunch at next login. If the user were to explicitly quit the
application, part of its cleanup would be to unset that autolaunch. So
it'd need some granularity to distinguish between 'next login
autolaunch' and 'user specified persistent autolaunch'.


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

Re: Fedora development of Snap packages

[Przemek Klosowski]

On 06/15/2016 01:24 AM, Tomasz Torcz wrote:

Well, if a packager wants to maintain it, why not?
>
>As someone who's a bit skeptical about containers as the future of software
>distribution, I'd like to continue getting "traditionally packaged"
>applications from Fedora where possible. I became a Fedora packager as a
>large part because I wanted to expand the pool of such software that was
>available in Fedora, by making it available to other users. It seems like
>that's not a thing we're going to care about as much going forward, which I
>guess is... fine, but I kind of have mixed feelings about the whole thing.
>
>I suspect I am in a minority here, though.

   I hope you aren't, I share your sentiments exactly.
Count me among the sceptics. As Florian pointed out, containers are 
convenient, but opaque: they bypass the technical process that is the 
basis for Fedora's excellence. As such, they are a form of technical 
debt: fine to a degree, but not a primary way to run your household.


It would be nice if there was a 'container snapshot' facility that would 
convert between a native application package from Fedora or Debian and a 
portable container---possibly both ways. Obviously, native->container is 
desirable for portability; the opposite conversion is less obviously 
useful but might be a basis for a cross-platform packaging process in 
the future.


In my mind, containers are primarily useful to run arbitrary untrusted 
third party applications, but of course they need  a good enough sandbox 
system for that. I hope such system will emerge from the current work.



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

Re: Why GUI software update tool is broken for me

[Russell Doty]

On Wed, 2016-06-15 at 10:27 -0600, Kevin Fenzi wrote:
> On Wed, 15 Jun 2016 17:39:32 +0200
> Kamil Dudka  wrote:
> 
> > 
> > On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
> > > 
> > > Dne 15.6.2016 v 10:14 Ade napsal(a):  
> > > > 
> > > > Why is this?  Well some time ago the behaviour of the tool
> > > > changed and now the only way to proceed is to click in "Restart
> > > > and Install" and this is NEVER what I want to do. I never want
> > > > to
> > > > reboot my desktop just to apply updates, Id rather apply all
> > > > the
> > > > updates and reboot to bring in the new kernel (if there is one)
> > > > when I have the time  
> > > Imagine two regular updates.
> > > 
> > > First you update mariadb-server package. %post is smart and it
> > > will
> > > condrestart the mariadb service. However...
> > > 
> > > Next day you update "pam" package which
> > > provides /usr/lib64/libpam.so.0 which is used by mariadb service.
> > > Unless you restart your computer your mariadb server will
> > > continue
> > > to use old (and maybe insecure) libpam.so. Or unless you use
> > > dnf-plugins-extras-tracer:
> > > http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html  
> > It is a reason to restart the system (or just the services of
> > interest) _after_ installing the update, but not before installing
> > the update.
> I think it's a combination of all these:
> 
> * If you simply apply updates and don't restart everything that uses
>   the things updated you will not be taking advantage of the security
>   or bugfixes. If those things are used by a lot of your apps,
>   restarting each one is tedious and/or as disruptive as just
> rebooting
>   anyhow. 
> 
> * Even though live updates work 'pretty well' there will always be a
>   number of corner cases where applications will not function
> correctly
>   after they are updated but before they are restarted. Directories
> or
>   resources they need may have changed, etc. 
> 
> Running tracer for a while can really open your eyes to how many
> things
> need restarting after normal updates flow. 
> 
> One thing that might make this less annoying to people would be
> ability
> to schedule the reboot for some off hours time (2am or something) and
> also ability (for gnome at least) to restore apps/windows/session
> again on login. 
> 
Note that the original poster says that he runs dnf -update from the
command line because it allows him to do what he wants.

Based on the information discussed in this thread, shouldn't dnf also
force a reboot before updates?

We have an observed difference between what is permitted in the cli
tool and what is permitted in the gui tool. Why this difference?
> kevin
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 17:25, "Matthew Miller"  wrote:
>
> On Wed, Jun 15, 2016 at 04:44:27PM +0100, James Hogarth wrote:
> > Considering how this actively negates the security of our distribution
and
> > how this is being promoted in the media, with them pointing to the
> > snapcraft site and the instructions there with COPR looking like it's on
> > approved Fedora infrastructure (for those who don't understand anyone
can
> > COPR and there is no review) I honestly wonder if this is a good case
for
> > pulling a COPR repo...
> > Would FESCO have authority here or is that going to be inadvisable a
road?
>
> There are plenty of things packaged in COPR which don't work with
> SELinux or are otherwise even more horrible. That's okay; it's one of
> the reasons we have COPR in the first place. Some things will
> "incubate" there and hopefully become less horrible (and maybe even
> migrate into the distro proper). Other things might stay terrible
> forever. In this particular case, though, given the note about SELinux
> support being planned, it looks like it's the better of the two
> situations, really.
>
> --

But are those projects issuing press releases and promoting their semi
broken software across the various tech sites?

But you do have a point.

It's going to have to be something that those of us supporting in IRC check
for when someone has issues with their browser or libreoffice I suppose.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 12:27 PM, Kevin Fenzi wrote:
> One thing that might make this less annoying to people would be ability
> to schedule the reboot for some off hours time (2am or something) and
> also ability (for gnome at least) to restore apps/windows/session
> again on login. 
> 

Scheduling the reboot for off-hours doesn't help much if you're following good
security practice and encrypting your drives, though. unless of course you are
set up to use something like Tang[1] to manage your drive encryption instead of
a password prompt.


[1] https://github.com/npmccallum/tang/blob/master/README.md



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

Re: Why GUI software update tool is broken for me

[Stephen Gallagher]

On 06/15/2016 11:39 AM, Kamil Dudka wrote:
> On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
>> Dne 15.6.2016 v 10:14 Ade napsal(a):
>>> Why is this?  Well some time ago the behaviour of the tool changed and now
>>> the only way to proceed is to click in "Restart and Install" and this is
>>> NEVER what I want to do. I never want to reboot my desktop just to apply
>>> updates, Id rather apply all the updates and reboot to bring in the new
>>> kernel (if there is one) when I have the time
>> Imagine two regular updates.
>>
>> First you update mariadb-server package. %post is smart and it will
>> condrestart the mariadb service. However...
>>
>> Next day you update "pam" package which provides /usr/lib64/libpam.so.0
>> which is used by mariadb service. Unless you restart your computer your
>> mariadb server will continue to use old (and maybe insecure) libpam.so. Or
>> unless you use dnf-plugins-extras-tracer:
>>   http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html
> 
> It is a reason to restart the system (or just the services of interest) 
> _after_ installing the update, but not before installing the update.


The justification for restarting both before and after installation exists and
it does make some sense in certain circumstances.

Basically, the problem is that any number of things can change in the state of
the system while it has been running that are impossible to predict. For
example, the system's memory (and swap) could be almost all used up, leading to
unpredictable behavior while processing the update and %pre/%post scripts. Also,
a user may have manually played around with the mount table, resulting in some
directory paths being unmounted or mounted over that the upgrade would write
into. By forcing the system to reboot into a limited environment, it puts the
system into something much closer to a known state which is less likely to
experience an unrecoverable error. (Ever had a runaway log fill up a disk during
a dnf update? Not a good thing.)


Of course, this comes with its own headaches, since of course if you are using
an encrypted drive, you need to enter your password twice: once to start the
update and once for the post-update reboot. A while ago I was working on a patch
to PackageKit that would skip the second reboot and just `systemd isolate
default.target` after the upgrade unless the kernel (or other early boot package
like dracut) was updated. I never finished it, but I could try to dig it out and
pass it on to someone who is interested in continuing it.



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

Re: Why GUI software update tool is broken for me

[Kevin Fenzi]

On Wed, 15 Jun 2016 17:39:32 +0200
Kamil Dudka  wrote:

> On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
> > Dne 15.6.2016 v 10:14 Ade napsal(a):  
> > > Why is this?  Well some time ago the behaviour of the tool
> > > changed and now the only way to proceed is to click in "Restart
> > > and Install" and this is NEVER what I want to do. I never want to
> > > reboot my desktop just to apply updates, Id rather apply all the
> > > updates and reboot to bring in the new kernel (if there is one)
> > > when I have the time  
> > Imagine two regular updates.
> > 
> > First you update mariadb-server package. %post is smart and it will
> > condrestart the mariadb service. However...
> > 
> > Next day you update "pam" package which
> > provides /usr/lib64/libpam.so.0 which is used by mariadb service.
> > Unless you restart your computer your mariadb server will continue
> > to use old (and maybe insecure) libpam.so. Or unless you use
> > dnf-plugins-extras-tracer:
> > http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html  
> 
> It is a reason to restart the system (or just the services of
> interest) _after_ installing the update, but not before installing
> the update.

I think it's a combination of all these:

* If you simply apply updates and don't restart everything that uses
  the things updated you will not be taking advantage of the security
  or bugfixes. If those things are used by a lot of your apps,
  restarting each one is tedious and/or as disruptive as just rebooting
  anyhow. 

* Even though live updates work 'pretty well' there will always be a
  number of corner cases where applications will not function correctly
  after they are updated but before they are restarted. Directories or
  resources they need may have changed, etc. 

Running tracer for a while can really open your eyes to how many things
need restarting after normal updates flow. 

One thing that might make this less annoying to people would be ability
to schedule the reboot for some off hours time (2am or something) and
also ability (for gnome at least) to restore apps/windows/session
again on login. 

kevin


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

Re: Fedora development of Snap packages

[Alexander Larsson]

On Wed, 2016-06-15 at 16:32 +0100, James Hogarth wrote:
> 
> 
> > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > doesn't use filesystem namespaces like flatpak), how does this work
> on
> > fedora? You can't use selinux and apparmour at the same time, so
> this
> > shouldn't be able to work, unless they disable the containment
> feature.
> >
> That's precisely what they are doing on non-Ubuntu distributions,
> disabling confinement.

Thats is pretty crappy. That means things will keep accidentally being
packaged that depends on things not in the ubuntu core. It also means
that there is zero sandboxing.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 04:44:27PM +0100, James Hogarth wrote:
> Considering how this actively negates the security of our distribution and
> how this is being promoted in the media, with them pointing to the
> snapcraft site and the instructions there with COPR looking like it's on
> approved Fedora infrastructure (for those who don't understand anyone can
> COPR and there is no review) I honestly wonder if this is a good case for
> pulling a COPR repo...
> Would FESCO have authority here or is that going to be inadvisable a road?

There are plenty of things packaged in COPR which don't work with
SELinux or are otherwise even more horrible. That's okay; it's one of
the reasons we have COPR in the first place. Some things will
"incubate" there and hopefully become less horrible (and maybe even
migrate into the distro proper). Other things might stay terrible
forever. In this particular case, though, given the note about SELinux
support being planned, it looks like it's the better of the two
situations, really.

-- 
Matthew Miller

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

Re: Why GUI software update tool is broken for me

[Chris Murphy]

On Wed, Jun 15, 2016 at 7:27 AM, Phil Cameron  wrote:

> On 06/15/2016 05:16 AM, Emmanuel Seyman wrote:
>
>> * Ade [15/06/2016 10:14] :
>>
>>> Id be interested in the original rationale behind this change, as I say,
>>> I
>>>
>> I believe the rationale is that there was no sane way to update running
>> applications (firefox, at least, would start not working in interesting
>> ways when you update it after having launched it).
>>
>> Emmanuel
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
> I think you misunderstand. A file remains in the system until it is no
> longer needed. The file and its name are two separate things. The name can
> be unlinked from a file and linked to another file ( as is done by update).
> The file remains around until all of it's names are unlinked and no process
> has it open. The reference count is incremented every time the file gets a
> name or is opened by some process. It is decremented every time a name is
> unlinked and every time it is closed. It is quietly deleted when the
> reference count finally goes to zero.
>
> So when you update an application that is running all you do is unlink the
> file name from the old file and link it to the new file. The old file does
> not go away because it is open by the running program. When the program
> exits, the file is deleted (only if the reference count is 0). The next
> time the program is run it will use the new file.


I think you're referring to VFS tracking open files, and assumes the update
process is entirely atomic, i.e. when updating a binary, an entirely new
binary is written to disk rather than overwriting the old one. If the old
one is overwritten then the VFS is going to point to the new one, the old
one is simply gone. I have no idea if dnf/rpm binary updates files
themselves atomically (the entire update process is definitely not atomic)
or if they're overwritten. I'm pretty sure they're overwritten.

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

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 17:12, "Rahul Sundaram"  wrote:
>
>
>
> On Wed, Jun 15, 2016 at 11:45 AM James Hogarth wrote:
>>
>> Considering how this actively negates the security of our distribution
and how this is being promoted in the media, with them pointing to the
snapcraft site and the instructions there with COPR looking like it's on
approved Fedora infrastructure (for those who don't understand anyone can
COPR and there is no review) I honestly wonder if this is a good case for
pulling a COPR repo...
>>
>> Would FESCO have authority here or is that going to be inadvisable a
road?
>
> Extremely inadvisable.   Copr exists in part for experimental packages.
When you enable a copr repo, you are warned that this is not part of the
official infrastructure and you are relying on the packager alone for any
support.   Pulling a COPR repo for anything other than violation of
published guidelines such as legal issues will look political even if you
have legitimate technical concerns about the quality of the software.   Do
you want Canonical to pull the Flatpak PPA because the quality of Flatpak
on Ubuntu isn't perfect?
>
>

If it was being widely advertised via the sponsoring entities PR department
the new secure thing whilst disabling the security in the system and trying
to look officialish then honestly yes I would.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Rahul Sundaram]

On Wed, Jun 15, 2016 at 11:45 AM James Hogarth wrote:

> Considering how this actively negates the security of our distribution and
> how this is being promoted in the media, with them pointing to the
> snapcraft site and the instructions there with COPR looking like it's on
> approved Fedora infrastructure (for those who don't understand anyone can
> COPR and there is no review) I honestly wonder if this is a good case for
> pulling a COPR repo...
>
> Would FESCO have authority here or is that going to be inadvisable a road?
>
Extremely inadvisable.   Copr exists in part for experimental packages.
When you enable a copr repo, you are warned that this is not part of the
official infrastructure and you are relying on the packager alone for any
support.   Pulling a COPR repo for anything other than violation of
published guidelines such as legal issues will look political even if you
have legitimate technical concerns about the quality of the software.   Do
you want Canonical to pull the Flatpak PPA because the quality of Flatpak
on Ubuntu isn't perfect?

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

Re: Fedora development of Snap packages

[Adam Williamson]

On Wed, 2016-06-15 at 17:08 +0200, Alexander Larsson wrote:
> On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > So I was rather surprised by this Softpaedia article today:
> > http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > It claims that Canonical state that they have been working with
> > Fedora developers to make this the universal packaging format.
> > The snapcraft.io site instructions say to use a COPR by a Canonical
> > employee who is not a Fedora packager.
> > Does anyone in marketing or development now what the article is
> > referring to and what's going on?
> 
> Snappy fundamentally relies on apparmour to do confinement (i.e. it
> doesn't use filesystem namespaces like flatpak), how does this work on
> fedora? You can't use selinux and apparmour at the same time, so this
> shouldn't be able to work, unless they disable the containment feature.

Right now, apparently, their install instructions tell you to disable
SELinux.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Kamil Dudka]

On Wednesday, June 15, 2016 17:29:02 Miroslav Suchý wrote:
> Dne 15.6.2016 v 10:14 Ade napsal(a):
> > Why is this?  Well some time ago the behaviour of the tool changed and now
> > the only way to proceed is to click in "Restart and Install" and this is
> > NEVER what I want to do. I never want to reboot my desktop just to apply
> > updates, Id rather apply all the updates and reboot to bring in the new
> > kernel (if there is one) when I have the time
> Imagine two regular updates.
> 
> First you update mariadb-server package. %post is smart and it will
> condrestart the mariadb service. However...
> 
> Next day you update "pam" package which provides /usr/lib64/libpam.so.0
> which is used by mariadb service. Unless you restart your computer your
> mariadb server will continue to use old (and maybe insecure) libpam.so. Or
> unless you use dnf-plugins-extras-tracer:
>   http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html

It is a reason to restart the system (or just the services of interest) 
_after_ installing the update, but not before installing the update.

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

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 16:34, "Matthew Miller"  wrote:
>
> On Wed, Jun 15, 2016 at 05:08:07PM +0200, Alexander Larsson wrote:
> > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > doesn't use filesystem namespaces like flatpak), how does this work on
> > fedora? You can't use selinux and apparmour at the same time, so this
> > shouldn't be able to work, unless they disable the containment feature.
>
> As I understand it, that's exactly what they do — there's a new
> "--disable-confinement" flag which is used¹. Additionally the COPR
> instructions² ask users to switch SELinux to permissive mode for F24
> (but note that "this restriction will be lifted later).
>
>
> 1.
http://copr-dist-git.fedorainfracloud.org/cgit/zyga/snapcore/snap-confine.git/tree/snap-confine.spec?id=09ccbb9f0537e2f519b18c8d8ef5613f1cabf5cc
> 2. https://copr.fedorainfracloud.org/coprs/zyga/snapcore/

Considering how this actively negates the security of our distribution and
how this is being promoted in the media, with them pointing to the
snapcraft site and the instructions there with COPR looking like it's on
approved Fedora infrastructure (for those who don't understand anyone can
COPR and there is no review) I honestly wonder if this is a good case for
pulling a COPR repo...

Would FESCO have authority here or is that going to be inadvisable a road?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 05:08:07PM +0200, Alexander Larsson wrote:
> Snappy fundamentally relies on apparmour to do confinement (i.e. it
> doesn't use filesystem namespaces like flatpak), how does this work on
> fedora? You can't use selinux and apparmour at the same time, so this
> shouldn't be able to work, unless they disable the containment feature.

As I understand it, that's exactly what they do — there's a new
"--disable-confinement" flag which is used¹. Additionally the COPR
instructions² ask users to switch SELinux to permissive mode for F24
(but note that "this restriction will be lifted later).


1. 
http://copr-dist-git.fedorainfracloud.org/cgit/zyga/snapcore/snap-confine.git/tree/snap-confine.spec?id=09ccbb9f0537e2f519b18c8d8ef5613f1cabf5cc
2. https://copr.fedorainfracloud.org/coprs/zyga/snapcore/

-- 
Matthew Miller

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

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 16:09, "Alexander Larsson"  wrote:
>
> On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > So I was rather surprised by this Softpaedia article today:
> > http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > It claims that Canonical state that they have been working with
> > Fedora developers to make this the universal packaging format.
> > The snapcraft.io site instructions say to use a COPR by a Canonical
> > employee who is not a Fedora packager.
> > Does anyone in marketing or development now what the article is
> > referring to and what's going on?
>
> Snappy fundamentally relies on apparmour to do confinement (i.e. it
> doesn't use filesystem namespaces like flatpak), how does this work on
> fedora? You can't use selinux and apparmour at the same time, so this
> shouldn't be able to work, unless they disable the containment feature.
>

That's precisely what they are doing on non-Ubuntu distributions, disabling
confinement.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Why GUI software update tool is broken for me

[Miroslav Suchý]

Dne 15.6.2016 v 10:14 Ade napsal(a):
> Why is this?  Well some time ago the behaviour of the tool changed and now 
> the only way to proceed is to click in
> "Restart and Install" and this is NEVER what I want to do. I never want to 
> reboot my desktop just to apply updates, Id
> rather apply all the updates and reboot to bring in the new kernel (if there 
> is one) when I have the time

Imagine two regular updates.

First you update mariadb-server package. %post is smart and it will condrestart 
the mariadb service. However...

Next day you update "pam" package which provides /usr/lib64/libpam.so.0 which 
is used by mariadb service.
Unless you restart your computer your mariadb server will continue to use old 
(and maybe insecure) libpam.so.
Or unless you use dnf-plugins-extras-tracer:
  http://dnf-plugins-extras.readthedocs.io/en/latest/tracer.html

-- 
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Chris Murphy]

On Wed, Jun 15, 2016 at 8:39 AM, Josh Boyer 
wrote:

> On Wed, Jun 15, 2016 at 10:13 AM, Chris Murphy 
> wrote:
> >
> >
> > On Tue, Jun 14, 2016 at 1:41 PM, Josh Boyer 
> > wrot:e
> >>
> >> How do you plan on addressing the problem reporting issue?  In your
> >> example, the Inkscape package will still exist in RPM form for other
> >> Editions.  That means there are potentially two versions of Inkscape,
> >> one from upstream and one packaged in Fedora.  How do you ensure
> >> problem reports are routed to the correct issue tracker?
> >
> >
> > Something Flatpak, or any other packaging method, could make easier for
> > developers and users is integrating an in-app bug reporting mechanism.
>
> That is a thing that could be done.
>
> > The packager chooses which (and possibly more than one) bug tracking
> system
> > to use and bakes that into the application in a way that abstracts the
> user
> > from this very long standing mess. So upstream packaged applications
> would
> > behind the scene submit the bug to the upstream preferred bug reporting
> > system; and Fedora packages applications to RHBZ or upstream or both.
>
> One of the issues with this idea is scale.  It requires app developers
> to do this.  Not every app developer will do this.  Which means the
> distributions are still going to have to solve this problem.


The idea is to provide the incentive to opt in. By virtue of creating a
Flatpak packaged application, filling in a few blanks, your app and your
users get bug reporting almost for free. It's like a bug reporting API. A
reference implementation that uses RHBZ or even GNOME's BZ would also
incentivize this quite a bit, not least of which is someone will want to
write a github backend for the thing pretty quickly.

There isn't much to be done about upstreams who don't care about user
feedback, or possess an impressive quantity of hubris necessary to not
recognize how much of a pain it is to track down where to file bugs and
sign up for that bug reporting system - per application. Ha, I mean, there
could be some comedy sketches I could think of to make fun of them. But
that's not a technical solution to the problem.


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

Re: Fedora development of Snap packages

[Alexander Larsson]

On Wed, 2016-06-15 at 08:24 +0200, Florian Weimer wrote:
> On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:
> > On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer  > > wrote:
> > > On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
> > > 
> > > > I *strongly* disagree here.  The xdg-app folks seem to be doing
> > > > a
> > > > pretty good job with their sandbox.  The kernel attack surface
> > > > is
> > > > reduced considerably, as is the attack surface against the user
> > > > via
> > > > ptrace and filesystem access.  If Wayland is available (which
> > > > is
> > > > should be!) then so is the attack surface against X.
> > > 
> > > 
> > > What about the direct access to DRI device nodes?  Why isn't this
> > > a problem
> > > that reduces the effectiveness of the sandbox considerably?
> > 
> > It's certainly a meaningful attack surface.  That being said, if it
> > works well, it should be about as dangerous as Chromium's render
> > sandbox, and the latter seems to work fairly well in practice.  I'm
> > assuming that xdg-app grants access to render nodes, not to the
> > legacy
> > node.
> 
> I'm not sure what kind of sandboxing there is.  I was just able to
> open 
> ~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile 
> (both outside the sandbox, obviously).

You can opt-out of parts of the sandbox for flatpak apps, and right now
most apps allow access to the home-directory, because we've not yet
finished the work on portals which will allow mediated access to user
files. That said, simple apps like a game will work fine without
granting them access to the users file.

This means current applications packaged with flatpak is mostly about
distribution, and not so much sandboxing. However, we're working on
fixing this.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[389-devel] please review: Ticket 48346 - Logging too verbose when re-acquiring expired kerberos ticket

[Mark Reynolds]

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

https://fedorahosted.org/389/attachment/ticket/48346/0001-Ticket-48346-log-too-verbose-when-re-acquiring-expir.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Alexander Larsson]

On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> So I was rather surprised by this Softpaedia article today:
> http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> ary-format-for-all-gnu-linux-distributions-505241.shtml
> It claims that Canonical state that they have been working with
> Fedora developers to make this the universal packaging format.
> The snapcraft.io site instructions say to use a COPR by a Canonical
> employee who is not a Fedora packager.
> Does anyone in marketing or development now what the article is
> referring to and what's going on?

Snappy fundamentally relies on apparmour to do confinement (i.e. it
doesn't use filesystem namespaces like flatpak), how does this work on
fedora? You can't use selinux and apparmour at the same time, so this
shouldn't be able to work, unless they disable the containment feature.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

jplesnik pushed to perl-Data-MessagePack (master). "0.50 bump"

[notifications]

From e9a7cb7044012e3506ca4005ca5143496914dfd4 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 15 Jun 2016 16:52:21 +0200
Subject: 0.50 bump

---
 .gitignore |  1 +
 perl-Data-MessagePack.spec | 12 ++--
 sources|  2 +-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 2b45528..3b17d04 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Data-MessagePack-0.47.tar.gz
 /Data-MessagePack-0.48.tar.gz
 /Data-MessagePack-0.49.tar.gz
+/Data-MessagePack-0.50.tar.gz
diff --git a/perl-Data-MessagePack.spec b/perl-Data-MessagePack.spec
index f3cd665..09cda2d 100644
--- a/perl-Data-MessagePack.spec
+++ b/perl-Data-MessagePack.spec
@@ -1,8 +1,8 @@
 %global pkgname Data-MessagePack
 
 Name:   perl-Data-MessagePack
-Version:0.49
-Release:2%{?dist}
+Version:0.50
+Release:1%{?dist}
 Summary:MessagePack serialising/deserialising
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Data-MessagePack/
@@ -12,6 +12,7 @@ BuildRequires:  gcc
 BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-devel
+BuildRequires:  perl-generators
 BuildRequires:  perl(Config)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(Cwd)
@@ -20,6 +21,7 @@ BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(Fcntl)
 BuildRequires:  perl(File::Basename)
 BuildRequires:  perl(File::Copy)
+BuildRequires:  perl(File::Copy::Recursive)
 BuildRequires:  perl(File::Find)
 BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::Spec)
@@ -29,6 +31,7 @@ BuildRequires:  perl(vars)
 # Run-time
 BuildRequires:  perl(B)
 BuildRequires:  perl(Carp)
+BuildRequires:  perl(Math::BigInt)
 BuildRequires:  perl(overload)
 BuildRequires:  perl(warnings)
 # Tests
@@ -43,6 +46,8 @@ BuildRequires:  perl(Tie::Array)
 BuildRequires:  perl(Tie::Hash)
 BuildRequires:  perl(utf8)
 BuildRequires:  perl(XSLoader)
+# Optional tests
+BuildRequires:  perl(threads)
 
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   perl(XSLoader)
@@ -73,6 +78,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jun 15 2016 Jitka Plesnikova  - 0.50-1
+- 0.50 bump
+
 * Sun May 15 2016 Jitka Plesnikova  - 0.49-2
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index 853c3e5..43185b8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8141b7b5d32ea1b2c80a17a08a81d714  Data-MessagePack-0.49.tar.gz
+3894fe36d26acf4a6b5d7fbe9dab5fb9  Data-MessagePack-0.50.tar.gz
-- 
cgit v0.12



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

jplesnik uploaded Data-MessagePack-0.50.tar.gz for perl-Data-MessagePack

[notifications]

3894fe36d26acf4a6b5d7fbe9dab5fb9  Data-MessagePack-0.50.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Data-MessagePack/Data-MessagePack-0.50.tar.gz/md5/3894fe36d26acf4a6b5d7fbe9dab5fb9/Data-MessagePack-0.50.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: Source, symbols and debuginfo for flatpaks/snaps

[Alexander Larsson]

On Wed, 2016-06-15 at 12:19 +0200, Mark Wielaard wrote:
> Hi,
> 
> On Tue, 2016-06-14 at 22:02 +0200, Igor Gnatenko wrote:
> > When DNF will be able to install flatpack pkgs then we can stop
> > supporting
> > distro packages for that.
> 
> One of the things I am working on is making access to sources,
> symbols
> and debuginfo easier for rpm packages as distributed by Fedora. That
> helps users profiling, debugging and tracing the things they run on
> their systems. For some background see:
> https://gnu.wildebeest.org/blog/mjw/2016/02/02/where-are-your-symbols
> -debuginfo-and-sources/
> https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo

Flatpak supports something called "extensions", where an app (or a
runtime) can specify extension points which are then optionally there
when running the app. One use of this in flatpak is debuginfo
extensions for the case above (another is locale data). Also, if you
use flatpak-builder to build your app then these are automatically
built for you, similar to how rpm does it (which support for was also
written by me).
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1346824] perl-Data-MessagePack-0.50 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Data-MessagePack-0.50-
   ||1.fc25
 Resolution|--- |RAWHIDE
Last Closed||2016-06-15 10:58:01



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

Re: Fedora development of Snap packages

[Chris Murphy]

On Wed, Jun 15, 2016 at 8:22 AM, Matthew Miller 
wrote:

>
>
> I'm also worried about lifecycle issues here. What if some popular
> upstream makes a popular Flatpak, we ditch the RPM packaging, and then
> upstream stops updating it, or does a horrible job - how do we get
> _back_?
>


At the moment the design goal is saying that doesn't matter so it'll keep
on running. There's no arbitrary method of disqualifying a Flatpak package,
e.g. with some kind of versioning method --> Flatpak 2 on Fedora could
support Flatpak 1 and 2 package applications, or it could refuse to run
Flatpak 1.


For that matter, are all Flatpak applications going to be third party?
> I've been assuming that we'll have a way to package software in this
> way *within Fedora*. Having a large application ecosystem is key, and
> honestly, I don't see that as likely without our _own_ effort.
>

Exactly.


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

Re: Fedora development of Snap packages

[Robert Marcano]

On 06/14/2016 09:08 PM, Michael Catanzaro wrote:


Certainly we're not going to come along and try to delete packages over
the maintainers' objections. In general, I expect package maintainers
would be deciding whether or not to make the switch, but yeah: if the
upstream developers request that we switch to their Flatpak, I would
hope that package maintainers would be willing to accommodate upstream.


I wish packagers don't abandon their efforts replacing that for a 
upstream flatpacks. Currently I trust packagers, the Fedora rules 
mandates that all source should be available and buildable, that 
everything is built on a clear trusted environment.


Will I trust flatpacks from everyone?, no. Some will be very careful on 
building things. I don't know if someone is linking with extra things we 
don't know or if they built things on a safe environment, or if their 
machines are already hacked to affect their build.


If someone have the need for a new updated version of an application 
with a flatpack and they trust their build, sure install it. But I will 
be happy to still use the RPM packaged version if I don't need new 
things. I wish flatpacks to be more of a way to distribute applications 
that make easy for developers build only one binary for Linux, but not 
as make them the only way, or for commercial applications what will 
never release source.


Hopefully no upstream developer become annoying requesting RPMs to be 
removed.

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

Fedora 24-20160615.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Cloud_base raw-xz i386
Workstation live x86_64

Failed openQA tests: 1/16 (i386), 1/2 (arm)

ID: 22815   Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
URL: https://openqa.fedoraproject.org/tests/22815
ID: 22892   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/22892

Passed openQA tests: 77/77 (x86_64), 15/16 (i386), 1/2 (arm)

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

Re: Fedora development of Snap packages

[Oliver Haessler]

 
> On 15/06/16 02:18, Michael Catanzaro wrote:
> 
> > On Tue, 2016-06-14 at 21:46 +0100, Tom Hughes wrote:
> >> I suspect this view originates in a very Gnomeish view of the
> >> world
> >> where upstream and the Fedora packagers are very close but I
> >> wonder
> >> how
> >> well it matches with situations where upstream and distros have a
> >> more
> >> antagonistic relationship...
> >
> > It's designed for third party application developers; packages work
> > great for big coherent projects like GNOME and KDE that all distros
> > package, but they're terrible for an upstream developer trying to
> > distribute one piece of software to users on 20 different distros.
> > By
> > making [specific, approved] upstream Flatpaks accessible in GNOME
> > Software, no longer does upstream have to deal with Fedora
> > packagers
> > saying "you can't bundle this and that" or "your package doesn't
> > build
> > with GCC 74" or "this violates or packaging guidelines," nor worry
> > about downstream patches causing different behavior in different
> > distros. Instead, Fedora just gets out of the way. The thinking is
> > that
> > this will make upstreams like us more... especially since it allows
> > them to control the pace of updates.
> 
> I understand why upstreams want to distribute in this way sure.
> 
> I also understand why we say those things that upstream don't like
> and
> why allowing upstreams to do whatever random nonsense crosses their
> mind
> is potentially a bad idea.
> 
> To be fair flatpaks are not my biggest concern given that, as I
> understand things, they are fairly well isolated/contained both in
> terms
> or how they install and how they are run.
> 
> I have far more worries about third party rpms which can put files
> anyway, run any scriptlets they like at install time, and generally
> interfere with the system as a whole.
> 
> I'm sure we've all encountered third party rpms that make us want to
> throw up because they lumped everything together in some bizarrely
> chosen directory and have 5000 lines of scriptlets that seem to
> represent about 10 years worth of accumulated bodges.
> 
> Just to take an example I just grabbed Google's latest chrome rpm and
> checked it. Among other things it has 1051 lines of scriptlets and,
> for
> some reason, installs a system cron job that will run as root every
> day.

This seems to happen for often with 3rd party rpm. I have seen the same
on the slack rpm as well as the vivaldi browser rpm (they use all the same cron 
job),
which basically checks if the repo file for the tool is under /etc/yum.repos.d
and if it is missing because you deleted it (aka moved it to disabled) it will
be daily recreated. Might be "great" for a non technical user, however if you
administrate several machines and want to have control over the updates to 
apply,
that is really annoying.

> 
> Now sure that is probably a case that would be better suited to a
> flatpak but my point is that it gives an idea of the relative quality
> of
> upstream packaging, and in many ways it's actually probably fairly
> well
> packaged compared to many.
> 
> Upstreams have different goals to us, and less understanding of the
> right ways to do things on a given distro, so they are inclined to
> cargo
> cult fixes based on what some not necessarily well informed person
> tells
> them on a bug report or on whatever blog post google turns up when
> they
> search for a solution to a problem.
> 
> The question here I think is how do we prioritise being fast vs being
> correct, and your argument is that we should sacrifice some
> quality/correctness in favour of speed and allowing upstreams to do
> whatever is most convenient to them.
> 
> Tom
> 
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Josh Boyer]

On Wed, Jun 15, 2016 at 10:13 AM, Chris Murphy  wrote:
>
>
> On Tue, Jun 14, 2016 at 1:41 PM, Josh Boyer 
> wrot:e
>>
>> How do you plan on addressing the problem reporting issue?  In your
>> example, the Inkscape package will still exist in RPM form for other
>> Editions.  That means there are potentially two versions of Inkscape,
>> one from upstream and one packaged in Fedora.  How do you ensure
>> problem reports are routed to the correct issue tracker?
>
>
> Something Flatpak, or any other packaging method, could make easier for
> developers and users is integrating an in-app bug reporting mechanism.

That is a thing that could be done.

> The packager chooses which (and possibly more than one) bug tracking system
> to use and bakes that into the application in a way that abstracts the user
> from this very long standing mess. So upstream packaged applications would
> behind the scene submit the bug to the upstream preferred bug reporting
> system; and Fedora packages applications to RHBZ or upstream or both.

One of the issues with this idea is scale.  It requires app developers
to do this.  Not every app developer will do this.  Which means the
distributions are still going to have to solve this problem.

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

[Bug 1331528] Please build perl-Unicode-CaseFold for EPEL

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Unicode-CaseFold-1.00-6.el6.1 has been submitted as an update to Fedora
EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e70a035a81

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

Fedora 24 compose report: 20160615.n.0 changes

[Fedora Branched Report]

OLD: Fedora-24-20160614.n.0
NEW: Fedora-24-20160615.n.0

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

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   226.59 MiB
Size of downgraded packages: 0.00 B

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

= ADDED IMAGES =
Image: Docker_Base docker armhfp
Path: Docker/armhfp/images/Fedora-Docker-Base-24-20160615.n.0.armhfp.tar.xz
Image: Docker_Base docker x86_64
Path: Docker/x86_64/images/Fedora-Docker-Base-24-20160615.n.0.x86_64.tar.xz
Image: Cinnamon live i386
Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-24-20160615.n.0.iso
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-24-20160615.n.0.iso

= DROPPED IMAGES =
Image: Workstation live i386
Path: Workstation/i386/iso/Fedora-Workstation-Live-i386-24-20160614.n.0.iso
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-24-20160614.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-24-20160614.n.0.iso
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-24-20160614.n.0.iso
Image: Games live i386
Path: Labs/i386/iso/Fedora-Games-Live-i386-24-20160614.n.0.iso
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-24-20160614.n.0.iso
Image: Workstation live x86_64
Path: Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-24-20160614.n.0.iso
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-24-20160614.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  IQmol-2.7.1-3.fc24
Old package:  IQmol-2.3.0-9.fc24
Summary:  A free open-source molecular editor and visualization package
RPMs: IQmol IQmol-samples
Size: 19076280 bytes
Size change:  2106796 bytes
Changelog:
  * Sun Sep 06 2015 Susi Lehtola <susi.leht...@iki.fi> - 2.3.0-9.1
  - Bump spec due to boost rebuild.

  * Mon Sep 14 2015 Susi Lehtola <jussileht...@fedoraproject.org> - 2.5.1-1
  - Update to 2.5.1.

  * Tue Sep 22 2015 Susi Lehtola <jussileht...@fedoraproject.org> - 2.5.1-1.1
  - Bump spec due to OpenMesh rebuild.

  * Sun Sep 27 2015 Susi Lehtola <jussileht...@fedoraproject.org> - 2.5.1-2
  - Don't mess with OpenBabel's data directories.

  * Thu Oct 29 2015 Susi Lehtola <jussileht...@fedoraproject.org> - 2.6.0-1
  - Update to 2.6.0.

  * Sun Dec 27 2015 Bj??rn Esser <fed...@besser82.io> - 2.6.0-2
  - Use %license

  * Sun Jan 31 2016 Susi Lehtola <jussileht...@fedoraproject.org> - 2.7.1-1
  - Update to 2.7.1.

  * Mon Feb 01 2016 Rex Dieter <rdie...@fedoraproject.org> - 2.7.1-2
  - use %qmake_qt5 to ensure proper build flags

  * Wed Feb 03 2016 Fedora Release Engineering <rel...@fedoraproject.org> - 
2.7.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild

  * Thu Mar 24 2016 Susi Lehtola <jussileht...@fedoraproject.org> - 2.7.1-4
  - Fix linking order.


Package:  PackageKit-1.1.1-3.fc24
Old package:  PackageKit-1.1.1-2.fc24
Summary:  Package management service
RPMs: PackageKit PackageKit-command-not-found PackageKit-cron 
PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin 
PackageKit-gtk3-module
Size: 3697642 bytes
Size change:  1704 bytes
Changelog:
  * Tue Jun 07 2016 Kalev Lember <klem...@redhat.com> - 1.1.1-3
  - Match unavailable packages for the what-provides query


Package:  golang-github-mistifyio-go-zfs-0-0.2.git1b4ae6f.fc24
Old package:  golang-github-mistifyio-go-zfs-0-0.1.git1b4ae6f.fc24
Summary:  Unit tests for golang-github-mistifyio-go-zfs package
RPMs: golang-github-mistifyio-go-zfs-devel 
golang-github-mistifyio-go-zfs-unit-test-devel
Size: 54474 bytes
Size change:  -16482 bytes
Changelog:
  * Tue Jun 07 2016 jchaloup <jchal...@redhat.com> - 0-0.2.git1b4ae6f
  - Don't build on arm architectures (missing zfs-fuse)
resolves: #1341333


Package:  grub2-1:2.02-0.34.fc24
Old package:  grub2-1:2.02-0.30.fc24
Summary:  Bootloader with support for Linux, Multiboot and more
RPMs: grub2 grub2-efi grub2-efi-modules grub2-starfield-theme 
grub2-tools
Size: 38611600 bytes
Size change:  -13504 bytes
Changelog:
  * Thu Jun 09 2016 pjones <pjo...@redhat.com> - 1:2.02-0.33
  - Revert TPM patches, they break some x86 platforms and ppc64
Resolves: rhbz#1334075
Resolves: rhbz#1334672
  - Chainloading on EFI doesn't work with some bootloaders
Resolves: rhbz#1320273

  * Fri Jun 10 2016 Peter Jones <pjo...@redhat.com> - 2.02-0.34
  - Update ppc64 configure invocation
Resolves: rhbz#1344700
  - Make chainloader code work right when shim is absent or disabled
Resolves: rhbz#1344512


Package:  pung

[Bug 1331528] Please build perl-Unicode-CaseFold for EPEL

[bugzilla]

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



--- Comment #7 from Xavier Bachelot  ---
Just patching the code to lower the Module::Build requirement seems enough for
EL6.

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

Re: Fedora development of Snap packages

[Matthew Miller]

On Tue, Jun 14, 2016 at 03:02:29PM -0500, Michael Catanzaro wrote:
> I was thinking remove the Fedora package. What's the point in
> maintaining a secret Fedora package for a graphical app, when we're
> going to be presenting a different version of that app to users? And as
> Josh says, this would also create confusion regarding where to report
> bugs, and also confusion when users have two different sets of bugs
> depending on whether you use a Fedora package or the upstream Flatpak.

Yeah, I'm really concerned about that particular confusion. I think the
new design for Software makes it reasonably clear at install time. But,
there's an inherent tension between making Flatpak software run
seamlessly and making sure users always know where blame (and credit!)
go for bugs and packaging problems.

I'm also worried about lifecycle issues here. What if some popular
upstream makes a popular Flatpak, we ditch the RPM packaging, and then
upstream stops updating it, or does a horrible job - how do we get
_back_?

Another concern is automated installation. Right now, one can do
kickstart installs for Workstation which pull in all desired apps. One
can even run a local mirror to make this faster and more reliable. But
how will this work if some (arbitrary?) apps need to be pulled from
third parties somewhere?

For that matter, are all Flatpak applications going to be third party?
I've been assuming that we'll have a way to package software in this
way *within Fedora*. Having a large application ecosystem is key, and
honestly, I don't see that as likely without our _own_ effort.

So much to figure out, here!

-- 
Matthew Miller

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

Re: Fedora development of Snap packages

[Avram Lubkin]

As many others have expressed, third-party RPMs tend to be done very
poorly, Oracle Java is a good bad example. That said, if it's something a
user wants to install on their system, that's their prerogative, but it's
not part of Fedora and shouldn't be. What we could do is make it easier to
install and enable third-party repos, then you actively have to enable them
and supposedly you know what you're doing (or are blindly following
something you found on Google). For me, I use repos from two providers,
Google and RPM Fusion. I think that's pretty common I add the repos in a
script I use for new desktop builds. For Google I cat out a repo file and
for RPM Fusion I pull down their repo RPM. Being able to dnf install a
third party repo would be a cleaner and I wouldn't mind this approach. I
would guess there's no legality concern because it's just adding a repo
file, but that's for the lawyers to decide.

As far as GUI tools for installing and managing software. I never use them
and I think that's common for "power users". That said, I could care less
what they do, but expect I can have the same capabilities on the command
line, and would expect those capibilities to be available through DNF.

On containerization/sandboxing, I see this as useful from a security
perspective, but not for software installation. What I see in the
commercial world with SCL is developers don't even try to make their
software run natively. Instead they pull a ton of libraries/modules into an
SCL environment, package it all in a huge RPM, and then never update the
included libraries. I think it would be more useful to work towards some
sort of automatic sandboxing and decouple that from software installation.

Avram

On Wed, Jun 15, 2016 at 8:55 AM, Michael Catanzaro 
wrote:

> On Wed, 2016-06-15 at 08:57 +0100, Tom Hughes wrote:
> > I have far more worries about third party rpms which can put files
> > anyway, run any scriptlets they like at install time, and generally
> > interfere with the system as a whole.
>
> Yeah, I'm not sure I like this part of the plan either. The goal is to
> make it as easy as possible to package software for Fedora, but I'm
> thinking that anyone who wants to distribute an RPM repo with metadata
> enabled in Fedora ought to be required to follow our packaging
> guidelines. That Chrome RPM seems like a weird case... but if Google's
> RPM sucks, just imagine what other vendors will do. You can horribly
> break the user's system with a bad RPM; there was a recent "dnf
> uninstalls sqlite" bug caused by some third-party RPM that bundles
> sqlite and also Provides it
>
> With Flatpak, it's indeed less of an issue. Your Flatpak might suck,
> but it can't hurt the system.
>
> Michael
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: libconfuse soname bump

[Jon Ciesla]

On Wed, Jun 15, 2016 at 8:17 AM, Sérgio Basto  wrote:

> On Qua, 2016-06-15 at 08:43 +, Petr Pisar wrote:
> > On 2016-06-14, Jon Ciesla  wrote:
> > >
> > > I'm updating libconfuse to 3.0, which is a soname change.  The only
> > > dependency I can find is libftdi, which I'm doing as well.
> > >
> > # dnf repoquery --whatrequires 'libconfuse.so.0()(64bit)' --source --
> > quiet
> > bmon-3.7-2.fc24.src.rpm
> > ganglia-3.7.2-8.fc25.src.rpm
> > i3status-2.10-2.fc24.src.rpm
> > libconfuse-2.7-10.fc24.src.rpm
> > libftdi-1.2-8.fc24.src.rpm
> > opensips-1.11.6-3.fc25.src.rpm
> > shigofumi-0.6-3.fc24.src.rpm
> > tilda-1.3.3-1.fc25.src.rpm
>
> with alldeps option, dnf repoquery also works well :
> dnf repoquery  --disablerepo='*' --enablerepo=rawhide --whatrequires
> libconfuse --source --alldeps --available
>
> bmon-3.7-2.fc24.src.rpm
> ganglia-3.7.2-8.fc25.src.rpm
> i3status-2.10-2.fc24.src.rpm
> libconfuse-2.7-10.fc24.src.rpm
> libftdi-1.2-8.fc24.src.rpm
> opensips-1.11.6-3.fc25.src.rpm
> shigofumi-0.6-3.fc24.src.rpm
> tilda-1.3.3-1.fc25.src.rpm
>
> Thanks, I'm fixing everything but shigofumi, which is already done.

-j


>
> > -- Petr
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> > .org
> --
> Sérgio M. B.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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