Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 10, 2019 at 03:19:43AM -0400, James Antill wrote:
> On Tue, 2019-07-02 at 10:22 +, Zbigniew Jędrzejewski-Szmek wrote:
> > 
> > I love the goal, but this document says very little about the means
> > to achieve that goal. I would like to see specific solutions
> > described for each class of scriptlets that is present, including
> > approximate numbers of packages that are affected. As often, the
> > devil is in the details, and there indeed are classes of scriptlets
> > which have been successfully made obsolete and we now only need to
> > get rid of the usage usage in spec files, but then there are other
> > classes of scriptlets which might be very hard to replace.
> 
>  Yes, we've had a spreadsheet for a bit with that data (raw data
> generated by[1]), I'll try to get that into html/wiki this week.
>  For a significant portion of the work the plan is:
> 
> 1. ldconfig => delete them as not needed
Right. It's insane how many of those we still have. On my F30 box,
"rpm -q -a --scripts |rg -c ldconfig" says 107! Getting rid of those
would certainly be nice.

> 2. adduser/group/etc. => sysusers files
> 3. touch/mv/cp/etc. => systemd-tmpfiles
tmpfiles doesn't support moving stuff. It might be possible to make
do with a copy and remove operation, but that doesn't seem nice.

Otherwise, tmpfiles and sysusers are there, and should work. But
sysusers hasn't such thaaat much exposure yet. But if there are any
shortcomings, we should be able to fix them.

> ...there have been ideas for some of the exceptional cases, but if we
> don't it all of them for F31 we'll still be in a better place for F32.

Agreed. I'm not yet convinced we can get rid of all scriptlets in a way
that would require workarounds that are more painful than the original
scriptlets, but I'm sure we can should down 90% of scriptlets.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RPM building on s390x sometimes is very slow on F-30+

[Peter Lemenkov]

Hello All,
Not sure if it's only me but every time I'm trying to build Erlang on
F-30 or Rawhide it takes forever to complete. It's all started
relatively recently (maybe a month or two). See the following logs for
the example.

* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065 (s390x
task, two days and still work-in-progress)

Does anyone experience the same issue?
-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM building on s390x sometimes is very slow on F-30+

[Philip Kovacs via devel]

 It's likely the big endian emulation running on little endian machines which 
is killing performance.  I also have some time sensitive package tests failing 
on s390x.   On Thursday, July 11, 2019, 05:30:28 AM EDT, Peter Lemenkov 
 wrote:  
 
 Hello All,
Not sure if it's only me but every time I'm trying to build Erlang on
F-30 or Rawhide it takes forever to complete. It's all started
relatively recently (maybe a month or two). See the following logs for
the example.

* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065 (s390x
task, two days and still work-in-progress)

Does anyone experience the same issue?
-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM building on s390x sometimes is very slow on F-30+

[Dan Horák]

On Thu, 11 Jul 2019 10:11:40 + (UTC)
Philip Kovacs via devel  wrote:

>  It's likely the big endian emulation running on little endian
> machines which is killing performance.  I also have some time
> sensitive package tests failing on s390x.   On Thursday, July 11,

there is no emulation in place, all builds are native, so it could be a
weirdness in the VM or the host for the builders being overloaded.

I'm running a local rebuild in rawhide now, so will see how fast this
goes.


Dan

> 2019, 05:30:28 AM EDT, Peter Lemenkov  wrote:
> Hello All, Not sure if it's only me but every time I'm trying to
> build Erlang on F-30 or Rawhide it takes forever to complete. It's
> all started relatively recently (maybe a month or two). See the
> following logs for the example.
> 
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065 (s390x
> task, two days and still work-in-progress)
> 
> Does anyone experience the same issue?
> -- 
> With best regards, Peter Lemenkov.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Bundler 2.0

[Pavel Valena]

- Original Message -
> From: "Vít Ondruch" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, July 11, 2019 8:45:12 AM
> Subject: Re: Fedora 31 Self-Contained Change proposal: Bundler 2.0
> 
> 
> 
> I think that we will end-up with this slightly edited version of the proposal
> :)
> 
> > Keep Bundler 1.16 as rubygem-bundler1 subpackage of ruby package.
> 
> The problem is that Ruby ships with bundled Bundler 1.x and RubyGems depends
> Bundler 1.x. Although I'm not sure how tight the coupling is :/ Upstream
> acts as the RubyGems and Bundler are inseparable, but I believe that the
> coupling is useful just for some niche use case.
> 
> 
> So the proposal is to move the independent rubygem-bundler into Bundler 2.x
> and replace the rubygem-bundler subpackage of ruby package by
> rubygem-bundler1 subpackage and keep it around as long as RubyGems does not
> migrate to the new version.
> 
> Also, if I am not mistaken, the Gemfile.lock created by Bundler can enforce
> the version of Bundler required.
> 
> 
> Please note that it should be safe to install rubygem-bundler1 alongside the
> rubygem-bundler.

The applications created (=Bundled) with Bundler 1 will still need to use 
Bundler 1 or they need to upgrade manually to Bundler 2[0].

Bundler 2 can dynamically select required runtime (v1 or v2) depending on the 
lock (=dependency) file.

Regards,
Pavel

[0] 
https://bundler.io/v2.0/guides/bundler_2_upgrade.html#upgrading-applications-from-bundler-1-to-bundler-2

> 
> 
> 
> 
> 
> Vít
> 
> 
> 
> Dne 10. 07. 19 v 20:49 Igor Gnatenko napsal(a):
> 
> 
> 
> Why do we want to keep old version around?
> 
> On Wed, Jul 10, 2019, 20:12 Ben Cotton < bcot...@redhat.com > wrote:
> 
> 
> https://fedoraproject.org/wiki/Changes/Bundler_2.0
> 
> == Summary ==
> Upgrade to Bundler 2.0, the latest stable gem version.
> 
> == Owner ==
> * Name: [[User:pvalena | Pavel Valena]], [[User:vondruch | Vit Ondruch]]
> * Email: pval...@redhat.com , vondr...@redhat.com
> 
> == Detailed Description ==
> Bundler 2 is new major upstream release, that includes many
> improvements and bug fixes.
> 
> == Benefit to Fedora ==
> Keeping with a latest release, Bundler is enabling simple Ruby
> application dependency managemenent.
> 
> == Scope ==
> * Proposal owners:
> ** Move Bundler 1.16 to rubygem-bundler1 (sub)package.
> ** Build Bundler 2.0. Current changes:
> https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/5
> ** Work has been done in a Copr repository:
> https://copr.fedorainfracloud.org/coprs/pvalena/rubygem-bundler/
> * Other developers: N/A
> * Release engineering: N/A
> * Policies and guidelines: N/A
> * Trademark approval: N/A
> 
> == Upgrade/compatibility impact ==
> All applications and Gemfiles that currently work with Bundler 1 will
> continue to work with Bundler 2.
> 
> Notable changes:
> * Dropped support for end of lifed Ruby versions 1.8.7 through 2.2
> * Dropped support for end of lifed RubyGems versions 1.3.6 through 2.5
> * Moved error messages from STDOUT to STDERR
> 
> == How To Test ==
> * No special hardware is needed.
> * Install Bundler 2
> * Run `bundle --version`
> * Create new applications as before
> * If something doesn't work as it should, let us know.
> 
> == User Experience ==
> New features that come with Bundler 2.0 will be available. Current
> version will be available as rubygem-bundler1.
> 
> == Documentation ==
> https://bundler.io/docs.html
> 
> == Release Notes ==
> * https://bundler.io/blog/2019/01/03/announcing-bundler-2.html
> * https://bundler.io/blog/2018/11/04/an-update-on-bundler-2.html
> 
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM building on s390x sometimes is very slow on F-30+

[Stephen John Smoogen]

On Thu, 11 Jul 2019 at 06:47, Philip Kovacs via devel <
devel@lists.fedoraproject.org> wrote:

> It's likely the big endian emulation running on little endian machines
> which is killing performance.
> I also have some time sensitive package tests failing on s390x.
>

I am a bit confused by what you are saying. Could you restate?  Compilation
on s390x happens on native hardware. But are you meaning that the erlang VM
is little endian and the big-endian s390x is having to emulate it?

We have been having problems with the s390x systems lately due to multiple
reasons outside of infrastructure's control. Kevin Fenzi has been working
on trying to get a replacement set of builders in place over the last week
to try and deal with this. I do not know if your build got stuck on a
builder which was transitioning or something similar.


> On Thursday, July 11, 2019, 05:30:28 AM EDT, Peter Lemenkov <
> lemen...@gmail.com> wrote:
>
>
> Hello All,
> Not sure if it's only me but every time I'm trying to build Erlang on
> F-30 or Rawhide it takes forever to complete. It's all started
> relatively recently (maybe a month or two). See the following logs for
> the example.
>
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065 (s390x
> task, two days and still work-in-progress)
>
> Does anyone experience the same issue?
> --
> With best regards, Peter Lemenkov.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM building on s390x sometimes is very slow on F-30+

[Dan Horák]

On Thu, 11 Jul 2019 12:33:58 +0200
Dan Horák  wrote:

> On Thu, 11 Jul 2019 10:11:40 + (UTC)
> Philip Kovacs via devel  wrote:
> 
> >  It's likely the big endian emulation running on little endian
> > machines which is killing performance.  I also have some time
> > sensitive package tests failing on s390x.   On Thursday, July
> > 11,
> 
> there is no emulation in place, all builds are native, so it could be
> a weirdness in the VM or the host for the builders being overloaded.
> 
> I'm running a local rebuild in rawhide now, so will see how fast this
> goes.

and it took ~1 hour, so likely the builder VM deserves a reboot


Dan

> 
> 
>   Dan
> 
> > 2019, 05:30:28 AM EDT, Peter Lemenkov  wrote:
> > Hello All, Not sure if it's only me but every time I'm trying to
> > build Erlang on F-30 or Rawhide it takes forever to complete. It's
> > all started relatively recently (maybe a month or two). See the
> > following logs for the example.
> > 
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065
> > (s390x task, two days and still work-in-progress)
> > 
> > Does anyone experience the same issue?
> > -- 
> > With best regards, Peter Lemenkov.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Heads up: No more snap plugin in gnome-software

[Richard Hughes]

Hi all,

In Fedora 31 I'll be disabling the snap plugin from GNOME Software.
It's never been enabled in RHEL and so this change only affects
Fedora. It's also not installed by default and so this change should
only affect a few people. It's also not really a FutureFeature, it's a
RemovalOfFeature but I'm happy to write something for the process and
release notes if required.

Recently Canonical decided that they are not going to be installing
gnome-software in the next LTS, preferring instead to ship a "Snap
Store by Canonical" rather than GNOME Software. The new Snap store
will obviously not support Flatpaks (or packages, or even firmware
updates for that matter). The developers currently assigned to work on
gnome-software have been reassigned to work on Snap Store, and I'm not
confident they'll be able to keep both the old and new codebases in
the air at the same time.

As you might know, enabling the snap plugin also enables the "Snap
Store" which seemingly violates the same rules which prevent us
installing Flathub by default (enabling access to nonfree software,
and software with patent restrictions). Without the Snap Store the
snap support is pretty useless, as snapd is so tied to the snapcraft
ecosystem, and because you can't actually run your own instance of the
snap store, unlike Flatpak.

The existing snap plugin is not very well tested and I don't want to
be the one responsible when it breaks. At the moment enabling the snap
plugin causes the general UX of gnome-software to degrade, as all
search queries are also routed through snapd rather than being handled
in the same process. The design of snapd also means that packages just
get updated behind gnome-software's back, and so it's very hard to do
anything useful in the UI, or to make things like metered data work
correctly. There's also still no sandboxing support years after it was
promised, which means on Fedora running a snap is no more secure than
"wget -O - URL | bash", again much unlike Flatpak.

I appreciate this is going to be controversial, and that some people
want snap support turned back on in GNOME Software. My answer there
would be that I'm perfectly happy with someone creating a new
gnome-software-snap top-level package (plugins in gnome-software are
just runtime loaded .so objects, rather than all compiled together)
and then they're responsible for keeping it up to date with any plugin
ABI breaks in gnome-software upstream (usually once per GNOME cycle)
and for any API or behaviour changes in snapd-glib. Basically, as long
as it's not my email that gets pinged by bugzilla when it breaks it's
fine. There was some suggestion that upstream we'd remove the snap
plugin completely, but I think it will remain until we see if snap
support improves or deteriorates further.

Comments welcome, but anyone who insults me or insists I do more work
than I'm doing now will be ignored.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Neal Gompa]

On Thu, Jul 11, 2019 at 4:26 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Jul 10, 2019 at 03:19:43AM -0400, James Antill wrote:
> > On Tue, 2019-07-02 at 10:22 +, Zbigniew Jędrzejewski-Szmek wrote:
> > >
> > > I love the goal, but this document says very little about the means
> > > to achieve that goal. I would like to see specific solutions
> > > described for each class of scriptlets that is present, including
> > > approximate numbers of packages that are affected. As often, the
> > > devil is in the details, and there indeed are classes of scriptlets
> > > which have been successfully made obsolete and we now only need to
> > > get rid of the usage usage in spec files, but then there are other
> > > classes of scriptlets which might be very hard to replace.
> >
> >  Yes, we've had a spreadsheet for a bit with that data (raw data
> > generated by[1]), I'll try to get that into html/wiki this week.
> >  For a significant portion of the work the plan is:
> >
> > 1. ldconfig => delete them as not needed
> Right. It's insane how many of those we still have. On my F30 box,
> "rpm -q -a --scripts |rg -c ldconfig" says 107! Getting rid of those
> would certainly be nice.
>
> > 2. adduser/group/etc. => sysusers files
> > 3. touch/mv/cp/etc. => systemd-tmpfiles
> tmpfiles doesn't support moving stuff. It might be possible to make
> do with a copy and remove operation, but that doesn't seem nice.
>
> Otherwise, tmpfiles and sysusers are there, and should work. But
> sysusers hasn't such thaaat much exposure yet. But if there are any
> shortcomings, we should be able to fix them.
>
> > ...there have been ideas for some of the exceptional cases, but if we
> > don't it all of them for F31 we'll still be in a better place for F32.
>
> Agreed. I'm not yet convinced we can get rid of all scriptlets in a way
> that would require workarounds that are more painful than the original
> scriptlets, but I'm sure we can should down 90% of scriptlets.
>

I disagree about the user/group creation, at least the way it's being
planned in here.

The way openSUSE solved this problem probably makes sense for dealing
with issues like needing the users+groups to exist before package is
being installed:

1. sysusers are in their own (sub)packages, dep generators generate user()
and group() Provides
2. main package can require those user() and group() names, forcing
the sysusers to be installed first
3. Transaction ordering deals with the rest of the problem :)




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Dridi Boukelmoune]

> I disagree about the user/group creation, at least the way it's being
> planned in here.
>
> The way openSUSE solved this problem probably makes sense for dealing
> with issues like needing the users+groups to exist before package is
> being installed:
>
> 1. sysusers are in their own (sub)packages, dep generators generate user()
> and group() Provides
> 2. main package can require those user() and group() names, forcing
> the sysusers to be installed first
> 3. Transaction ordering deals with the rest of the problem :)

Sounds like something similar debuginfo packages where we don't have
to do anything besides compiling with debug symbols, except that here
we'd need to either install the sysusers file if it comes from upstream or
create one, and I assume everything else would be handled automatically?

I would be on board for such a change, as I would like to do that for
the varnish package (ideally on el7 too if that can be ported over
there). I have strongly considered doing that manually since this
needs to be done beforehand, and in my specific case (wearing my
upstream hat) we would be fine with the user short-circuiting the
sysusers file prior to installation as the users/group we recommend
are optional and /usr/*bin/varnish* tools can also work with other
arbitrary credentials of the sysadmin's discretion to drop privileges.

(Please keep the latter in mind for other packages, they may break if
someone drops a different sysusers file in /etc, but ten they probably
asked for it.)




Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Neal Gompa]

On Thu, Jul 11, 2019 at 8:22 AM Richard Hughes  wrote:
>
> Hi all,
>
> In Fedora 31 I'll be disabling the snap plugin from GNOME Software.
> It's never been enabled in RHEL and so this change only affects
> Fedora. It's also not installed by default and so this change should
> only affect a few people. It's also not really a FutureFeature, it's a
> RemovalOfFeature but I'm happy to write something for the process and
> release notes if required.
>
> Recently Canonical decided that they are not going to be installing
> gnome-software in the next LTS, preferring instead to ship a "Snap
> Store by Canonical" rather than GNOME Software. The new Snap store
> will obviously not support Flatpaks (or packages, or even firmware
> updates for that matter). The developers currently assigned to work on
> gnome-software have been reassigned to work on Snap Store, and I'm not
> confident they'll be able to keep both the old and new codebases in
> the air at the same time.
>

This is completely news to me. As far as I knew, Canonical was still
actively committed to maintaining the snap plugin upstream and
advancing it as a solution for distro integration for snaps in
non-Ubuntu distributions.

My understanding of the situation was that Canonical is working on a
separate experience tailored for Ubuntu because they have extra needs,
but all of it was built on GNOME Software in the first place.

> As you might know, enabling the snap plugin also enables the "Snap
> Store" which seemingly violates the same rules which prevent us
> installing Flathub by default (enabling access to nonfree software,
> and software with patent restrictions). Without the Snap Store the
> snap support is pretty useless, as snapd is so tied to the snapcraft
> ecosystem, and because you can't actually run your own instance of the
> snap store, unlike Flatpak.
>

My opinion on this is that because we don't ship the plugin or snapd
by default on any variant of Fedora, we don't really run counter to
the rules. If there's something more specific you'd like for the snap
integration in Fedora to do, that can be discussed separately and
please talk to me off-list about it.

> The existing snap plugin is not very well tested and I don't want to
> be the one responsible when it breaks. At the moment enabling the snap
> plugin causes the general UX of gnome-software to degrade, as all
> search queries are also routed through snapd rather than being handled
> in the same process. The design of snapd also means that packages just
> get updated behind gnome-software's back, and so it's very hard to do
> anything useful in the UI, or to make things like metered data work
> correctly. There's also still no sandboxing support years after it was
> promised, which means on Fedora running a snap is no more secure than
> "wget -O - URL | bash", again much unlike Flatpak.
>

This actually hasn't been true for almost a year (snapd has seccomp
and other filters in place), and in the last few months, we've rolled
out *very basic* SELinux support into snapd. Today, snaps are
sandboxed through the snapd-selinux policy, which generally confines
snaps to only interacting with each other, and select holes for system
integration.

We've been working very hard upstream on improving this story for
Fedora, and we've made tremendous progress.

> I appreciate this is going to be controversial, and that some people
> want snap support turned back on in GNOME Software. My answer there
> would be that I'm perfectly happy with someone creating a new
> gnome-software-snap top-level package (plugins in gnome-software are
> just runtime loaded .so objects, rather than all compiled together)
> and then they're responsible for keeping it up to date with any plugin
> ABI breaks in gnome-software upstream (usually once per GNOME cycle)
> and for any API or behaviour changes in snapd-glib. Basically, as long
> as it's not my email that gets pinged by bugzilla when it breaks it's
> fine. There was some suggestion that upstream we'd remove the snap
> plugin completely, but I think it will remain until we see if snap
> support improves or deteriorates further.
>

Would it make sense for Zygmunt and Maciek (CC'd to this email) to be
added as CC contacts on Bugzilla, so they can address snap plugin
issues when they arise?

> Comments welcome, but anyone who insults me or insists I do more work
> than I'm doing now will be ignored.
>

I'm just generally confused about this, and somewhat blindsided...
I wish someone had looped *me* into these conversations, as one of the
snap support maintainers in Fedora, I'm relying on these things to
provide a good experience for Fedora users of snaps...




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidel

Re: Fedora 31 Self-Contained Change proposal: Bundler 2.0

[Igor Gnatenko]

Thanks for clarifying!

On Thu, Jul 11, 2019 at 1:34 PM Pavel Valena  wrote:
>
> - Original Message -
> > From: "Vít Ondruch" 
> > To: devel@lists.fedoraproject.org
> > Sent: Thursday, July 11, 2019 8:45:12 AM
> > Subject: Re: Fedora 31 Self-Contained Change proposal: Bundler 2.0
> >
> >
> >
> > I think that we will end-up with this slightly edited version of the 
> > proposal
> > :)
> >
> > > Keep Bundler 1.16 as rubygem-bundler1 subpackage of ruby package.
> >
> > The problem is that Ruby ships with bundled Bundler 1.x and RubyGems depends
> > Bundler 1.x. Although I'm not sure how tight the coupling is :/ Upstream
> > acts as the RubyGems and Bundler are inseparable, but I believe that the
> > coupling is useful just for some niche use case.
> >
> >
> > So the proposal is to move the independent rubygem-bundler into Bundler 2.x
> > and replace the rubygem-bundler subpackage of ruby package by
> > rubygem-bundler1 subpackage and keep it around as long as RubyGems does not
> > migrate to the new version.
> >
> > Also, if I am not mistaken, the Gemfile.lock created by Bundler can enforce
> > the version of Bundler required.
> >
> >
> > Please note that it should be safe to install rubygem-bundler1 alongside the
> > rubygem-bundler.
>
> The applications created (=Bundled) with Bundler 1 will still need to use 
> Bundler 1 or they need to upgrade manually to Bundler 2[0].
>
> Bundler 2 can dynamically select required runtime (v1 or v2) depending on the 
> lock (=dependency) file.
>
> Regards,
> Pavel
>
> [0] 
> https://bundler.io/v2.0/guides/bundler_2_upgrade.html#upgrading-applications-from-bundler-1-to-bundler-2
>
> >
> >
> >
> >
> >
> > Vít
> >
> >
> >
> > Dne 10. 07. 19 v 20:49 Igor Gnatenko napsal(a):
> >
> >
> >
> > Why do we want to keep old version around?
> >
> > On Wed, Jul 10, 2019, 20:12 Ben Cotton < bcot...@redhat.com > wrote:
> >
> >
> > https://fedoraproject.org/wiki/Changes/Bundler_2.0
> >
> > == Summary ==
> > Upgrade to Bundler 2.0, the latest stable gem version.
> >
> > == Owner ==
> > * Name: [[User:pvalena | Pavel Valena]], [[User:vondruch | Vit Ondruch]]
> > * Email: pval...@redhat.com , vondr...@redhat.com
> >
> > == Detailed Description ==
> > Bundler 2 is new major upstream release, that includes many
> > improvements and bug fixes.
> >
> > == Benefit to Fedora ==
> > Keeping with a latest release, Bundler is enabling simple Ruby
> > application dependency managemenent.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Move Bundler 1.16 to rubygem-bundler1 (sub)package.
> > ** Build Bundler 2.0. Current changes:
> > https://src.fedoraproject.org/rpms/rubygem-bundler/pull-request/5
> > ** Work has been done in a Copr repository:
> > https://copr.fedorainfracloud.org/coprs/pvalena/rubygem-bundler/
> > * Other developers: N/A
> > * Release engineering: N/A
> > * Policies and guidelines: N/A
> > * Trademark approval: N/A
> >
> > == Upgrade/compatibility impact ==
> > All applications and Gemfiles that currently work with Bundler 1 will
> > continue to work with Bundler 2.
> >
> > Notable changes:
> > * Dropped support for end of lifed Ruby versions 1.8.7 through 2.2
> > * Dropped support for end of lifed RubyGems versions 1.3.6 through 2.5
> > * Moved error messages from STDOUT to STDERR
> >
> > == How To Test ==
> > * No special hardware is needed.
> > * Install Bundler 2
> > * Run `bundle --version`
> > * Create new applications as before
> > * If something doesn't work as it should, let us know.
> >
> > == User Experience ==
> > New features that come with Bundler 2.0 will be available. Current
> > version will be available as rubygem-bundler1.
> >
> > == Documentation ==
> > https://bundler.io/docs.html
> >
> > == Release Notes ==
> > * https://bundler.io/blog/2019/01/03/announcing-bundler-2.html
> > * https://bundler.io/blog/2018/11/04/an-update-on-bundler-2.html
> >
> > --
> > Ben Cotton
> > He / Him / His
> > Fedora Program Manager
> > Red Hat
> > TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Bundler 2.0

[Jun Aruga]

There are 2 Ruby modules 2.5 and 2.6.
Ruby 2.5 module has rubygem-bundler in it.
How about keeping the rubygem-bundler as 1.X?

-- 
Jun Aruga | He - His - Him
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Richard Hughes]

On Thu, 11 Jul 2019 at 14:52, Neal Gompa  wrote:
> My understanding of the situation was that Canonical is working on a
> separate experience tailored for Ubuntu because they have extra needs,
> but all of it was built on GNOME Software in the first place.

No, it's also a new codebase: https://github.com/ubuntu/snap-store --
it's confusing as the name "Snap Store" is also the name of the
debadged-gnome-software version too.

> My opinion on this is that because we don't ship the plugin or snapd
> by default on any variant of Fedora, we don't really run counter to
> the rules.

So in the same way, we could have a checkbox for "Flathub support" in
the gnome-software addons page? I don't think that would wash with
legal as we would be "facilitating" access to patent encumbered
software. I don't think the "by default" arguments protects us like
that.

> Would it make sense for Zygmunt and Maciek (CC'd to this email) to be
> added as CC contacts on Bugzilla, so they can address snap plugin
> issues when they arise?

No, as they're not the ones committing fixes to gnome-software.
Watching a bugzilla ticket doesn't equate to being responsible for
bugs. The snap plugin self tests are failing in CI, and we can't even
update to a newer gnome-software in rawhide as the version of
snapd-glib is too old. Usually when that happens either me or Kalev
have to hunt down the new tarballs, add any new BRs, scratch build,
build, submit as an update etc and that's just not fair.

> I'm just generally confused about this, and somewhat blindsided...

I was informed of the Canonical decision a few weeks ago, and it too
took me by surprise. I guess winning the war comes at a cost, and this
camel has a broken back.

> I wish someone had looped *me* into these conversations, as one of the
> snap support maintainers in Fedora, I'm relying on these things to
> provide a good experience for Fedora users of snaps...

I was asked not to distribute details about the conversations until
they had made a public statement, which still hasn't been done. I'm
not comfortable with the situation at all either but we have to do
something.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MPFR 4

[Jerry James]

On Mon, Jul 8, 2019 at 4:14 AM James Paul Turner
 wrote:
> That seems appropriate. We need to discuss this with pcahyna. I have
> CCd him. Pavel, please see above.
>
> To avoid this issue in the future, is it possible to have the two
> separate packages maintained by separate teams, or is that just a
> headache waiting to happen?

I'm not sure.  In this case, though, i don't think we need it.  I've
been building packages in a local mock for the last few days.  I've
still got 6 to go, and so far I've only hit 2 issues, neither of them
related to MPFR.  Unless something comes up with these last few, I
think we need the MPFR 3 and MPC-linked-with-MPFR-3 compatibility
packages only to get gcc switched over, then we can discard them and
have an entirely MPFR 4 distribution.

In fact, I know that one of the remaining 6, sagemath, won't be a
problem.  Upstream advertises support for MPFR 4.  All I have to do is
drop sagemath-mpfr.patch, which keeps it building with MPFR 3.

Pavel, are you around?  Some of these packages take a long time to
build, but I think if we had, say, a 4 or 5 day window in which the
gcc and texlive maintainers agreed not to do any new builds, we could
get Fedora switched entirely over to MPFR 4.  We need to start
figuring out when that should happen.  We are already past the
deadline for system-wide change proposals for Fedora 31, but if we get
our ducks in a row, we can perhaps get this into Fedora 32 as soon as
that window opens.  (I'm assuming this will be a system-wide change
since it affects gcc.)
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM building on s390x sometimes is very slow on F-30+

[Brian Clark]

On Thu, Jul 11, 2019, 6:06 AM Peter Lemenkov  wrote:

> Hello All,
> Not sure if it's only me but every time I'm trying to build Erlang on
> F-30 or Rawhide it takes forever to complete. It's all started
> relatively recently (maybe a month or two). See the following logs for
> the example.
>
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065 (s390x
> task, two days and still work-in-progress)
>
> Does anyone experience the same issue?
> --
> With best regards, Peter Lemenkov.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lines disordered in mock's build.log

[Miro Hrončok]

On 01. 07. 19 15:53, Fabio Valentini wrote:
On Mon, Jul 1, 2019, 15:42 Miro Hrončok > wrote:


Hello,

I've noticed that last couple of weeks, I see disordered lines in mock's
build.log. This happens constantly in local mock, copr and Koji. Example:


25/41 Test #25: List_test    Passed    0.01 sec
        Start 26: Particle_test
26/41 Test #26: Particle_test    Passed    Errors while
running CTest
make[3]: ***
[src/core/unit_tests/CMakeFiles/check_unit_tests.dir/build.make:60:
src/core/unit_tests/CMakeFiles/check_unit_tests] Error 8
make[2]: *** [CMakeFiles/Makefile2:2265:
src/core/unit_tests/CMakeFiles/check_unit_tests.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:116: CMakeFiles/check.dir/rule] Error 2
make: *** [Makefile:191: check] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.yUtVju (%check)
0.01 sec
        Start 27: for_each_pair_test
...
41/41 Test #41: Span_test    Passed    0.01 sec

98% tests passed, 1 tests failed out of 41

Total Test time (real) =  16.69 sec

The following tests FAILED:
          23 - ParticleCache_test (Failed)
make[3]: Leaving directory '/builddir/build/BUILD/espresso/openmpi_build'
make[2]: Leaving directory '/builddir/build/BUILD/espresso/openmpi_build'
make[1]: Leaving directory '/builddir/build/BUILD/espresso/openmpi_build'


RPM build errors:
      Bad exit status from /var/tmp/rpm-tmp.yUtVju (%check)



See the "error: Bad exit status from /var/tmp/rpm-tmp.yUtVju (%check)" part 
in
the middle of %check output.

Has something changed? Or is it an rpm 4.15 thing?


I think this is caused by multithreading in RPM 4.15. A similar issue breaks 
specially-formatted output from Java packaging tools - because it's no longer 
necessarily on contiguous, uninterrupted lines in the build.log.


I think stdout / stderr from different sources are no longer printed in strictly 
chronological order (file / stdfoo writes are not flushed).


I wonder whether this would be considered a bug in rpm?

Florian, Panu?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Bundler 2.0

[Igor Gnatenko]

On Thu, Jul 11, 2019 at 5:09 PM Jun Aruga  wrote:
>
> There are 2 Ruby modules 2.5 and 2.6.
> Ruby 2.5 module has rubygem-bundler in it.
> How about keeping the rubygem-bundler as 1.X?

Guidelines say that if you want multiple versions, unversioned version
should be the latest. So rubygem-bundler should be 2.x. You'll need to
fix your modules.

> --
> Jun Aruga | He - His - Him
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Fedora-spins] roundup of failing images for 2019-07-07

[Kevin Fenzi]

On 7/7/19 9:31 PM, Peter Robinson wrote:
> On Mon, Jul 8, 2019 at 1:44 AM Kevin Fenzi  wrote:
>>
>> So, what better way to relax on a sunday than to look at image compose
>> failures? :)
>>
>> 1. The armv7 workstation compose:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=36106518
>>
>> This is failing because it cannot find 'epiphany'.
>> This is because it's using the Workstation repo instead of the
>> "Everything" repo to compose from. So, we either need to fix that or
>> remove epiphany from it's kickstart. Who "owns" this image? The arm SIG?
>> Workstation sig?
> 
> Arm SIG, what does the Live and other Workstation images use in terms
> of repos, does it make sense just to use Everything repo for all of
> them and just not generate the Workstation repo, or do we pull
> epiphany into the Workstation repo?

epiphany is explicitly added in the arm kickstart here, the x86_64
workstation live does not have it. It is also thus not in the
Workstation repo.

So, either remove it from kickstart (in favor of firefox now?)
or
make the arm workstation use Everything repo.
I thought we made the x86 Workstation already use Everything repo, but I
could be wrong.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM building on s390x sometimes is very slow on F-30+

[Kevin Fenzi]

On 7/11/19 4:13 AM, Stephen John Smoogen wrote:
> On Thu, 11 Jul 2019 at 06:47, Philip Kovacs via devel <
> devel@lists.fedoraproject.org> wrote:
> 
>> It's likely the big endian emulation running on little endian machines
>> which is killing performance.
>> I also have some time sensitive package tests failing on s390x.
>>
> 
> I am a bit confused by what you are saying. Could you restate?  Compilation
> on s390x happens on native hardware. But are you meaning that the erlang VM
> is little endian and the big-endian s390x is having to emulate it?
> 
> We have been having problems with the s390x systems lately due to multiple
> reasons outside of infrastructure's control. Kevin Fenzi has been working
> on trying to get a replacement set of builders in place over the last week
> to try and deal with this. I do not know if your build got stuck on a
> builder which was transitioning or something similar.

So, yeah, part of this is my fault. :(

If you look at
https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065
you will note that there are 4 buildroots listed. That means the build
was restarted 4 times. Likely this happened when I was
installing/updating/shuffling builders around there. Sorry about that.

That said, it still should have finished long ago.

The current state of s390x builders:

buildvm-s390x-01 to 14 are all the existing Z/VM instances we have had
for a long while. Likely we are going to keep them for a while until we
are sure the kvm instances are reliable and happy.

buildvm-s390x-15 to 24 are new kvm instances. They have a higher
'weight' than the others and from my testing are much faster.

Your build seems perhaps stuck in tests?

I've freed it (again) and it's now running on buildvm-s390x-22 (a kvm
instance). Lets see how it does there. I will in the meantime
update/reboot the Z/VM instances.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Review swap

[Robert-André Mauchin]

Hello,

I'd like a review for go2rpm:

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

I can do any review in exchange.

Best regards,

Robert-André

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Neal Gompa]

On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes  wrote:
>
> On Thu, 11 Jul 2019 at 14:52, Neal Gompa  wrote:
> > My understanding of the situation was that Canonical is working on a
> > separate experience tailored for Ubuntu because they have extra needs,
> > but all of it was built on GNOME Software in the first place.
>
> No, it's also a new codebase: https://github.com/ubuntu/snap-store --
> it's confusing as the name "Snap Store" is also the name of the
> debadged-gnome-software version too.
>
> > My opinion on this is that because we don't ship the plugin or snapd
> > by default on any variant of Fedora, we don't really run counter to
> > the rules.
>
> So in the same way, we could have a checkbox for "Flathub support" in
> the gnome-software addons page? I don't think that would wash with
> legal as we would be "facilitating" access to patent encumbered
> software. I don't think the "by default" arguments protects us like
> that.
>
> > Would it make sense for Zygmunt and Maciek (CC'd to this email) to be
> > added as CC contacts on Bugzilla, so they can address snap plugin
> > issues when they arise?
>
> No, as they're not the ones committing fixes to gnome-software.
> Watching a bugzilla ticket doesn't equate to being responsible for
> bugs. The snap plugin self tests are failing in CI, and we can't even
> update to a newer gnome-software in rawhide as the version of
> snapd-glib is too old. Usually when that happens either me or Kalev
> have to hunt down the new tarballs, add any new BRs, scratch build,
> build, submit as an update etc and that's just not fair.
>

For what it's worth, Robert Ancell also has an RHBZ account and can be
added as a CC if needed. That said, Maciek and Zygmunt are the folks
at Canonical generally responsible for ensuring the non-Ubuntu
experience is as good as it can be. They are the people I work with
for Fedora considerations upstream most of the time. They are both
knowledgeable and capable of working on that side if needed.

I was unaware you've been needing new releases of snapd-glib more
frequently. I've mainly been updating them whenever I get a bug report
or when I notice a new version is available. If you need me to be more
aggressive on updating snapd-glib, I could have done that.

> > I'm just generally confused about this, and somewhat blindsided...
>
> I was informed of the Canonical decision a few weeks ago, and it too
> took me by surprise. I guess winning the war comes at a cost, and this
> camel has a broken back.
>
> > I wish someone had looped *me* into these conversations, as one of the
> > snap support maintainers in Fedora, I'm relying on these things to
> > provide a good experience for Fedora users of snaps...
>
> I was asked not to distribute details about the conversations until
> they had made a public statement, which still hasn't been done. I'm
> not comfortable with the situation at all either but we have to do
> something.
>

:(


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Ben Cotton]

Ideally, this would be submitted as a Change proposal, but I don't
think it really matters. I would ask you to file an issue for the
Release Notes[1] so it can be communicated to the public (unless
someone else steps forward and maintains it so you don't have to).

[1] https://pagure.io/fedora-docs/release-notes/new_issue

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Adam Williamson]

On Thu, 2019-07-11 at 13:14 -0400, Neal Gompa wrote:
> On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes  wrote:
> > On Thu, 11 Jul 2019 at 14:52, Neal Gompa  wrote:
> > > My understanding of the situation was that Canonical is working on a
> > > separate experience tailored for Ubuntu because they have extra needs,
> > > but all of it was built on GNOME Software in the first place.
> > 
> > No, it's also a new codebase: https://github.com/ubuntu/snap-store --
> > it's confusing as the name "Snap Store" is also the name of the
> > debadged-gnome-software version too.
> > 
> > > My opinion on this is that because we don't ship the plugin or snapd
> > > by default on any variant of Fedora, we don't really run counter to
> > > the rules.
> > 
> > So in the same way, we could have a checkbox for "Flathub support" in
> > the gnome-software addons page? I don't think that would wash with
> > legal as we would be "facilitating" access to patent encumbered
> > software. I don't think the "by default" arguments protects us like
> > that.
> > 
> > > Would it make sense for Zygmunt and Maciek (CC'd to this email) to be
> > > added as CC contacts on Bugzilla, so they can address snap plugin
> > > issues when they arise?
> > 
> > No, as they're not the ones committing fixes to gnome-software.
> > Watching a bugzilla ticket doesn't equate to being responsible for
> > bugs. The snap plugin self tests are failing in CI, and we can't even
> > update to a newer gnome-software in rawhide as the version of
> > snapd-glib is too old. Usually when that happens either me or Kalev
> > have to hunt down the new tarballs, add any new BRs, scratch build,
> > build, submit as an update etc and that's just not fair.
> > 
> 
> For what it's worth, Robert Ancell also has an RHBZ account and can be
> added as a CC if needed. That said, Maciek and Zygmunt are the folks
> at Canonical generally responsible for ensuring the non-Ubuntu
> experience is as good as it can be. They are the people I work with
> for Fedora considerations upstream most of the time. They are both
> knowledgeable and capable of working on that side if needed.
> 
> I was unaware you've been needing new releases of snapd-glib more
> frequently. I've mainly been updating them whenever I get a bug report
> or when I notice a new version is available. If you need me to be more
> aggressive on updating snapd-glib, I could have done that.
> 
> > > I'm just generally confused about this, and somewhat blindsided...
> > 
> > I was informed of the Canonical decision a few weeks ago, and it too
> > took me by surprise. I guess winning the war comes at a cost, and this
> > camel has a broken back.
> > 
> > > I wish someone had looped *me* into these conversations, as one of the
> > > snap support maintainers in Fedora, I'm relying on these things to
> > > provide a good experience for Fedora users of snaps...
> > 
> > I was asked not to distribute details about the conversations until
> > they had made a public statement, which still hasn't been done. I'm
> > not comfortable with the situation at all either but we have to do
> > something.
> > 

Practically speaking, Neal, can you not just create the 'gnome-
software-snap' package Richard suggested, and maintain that? Is there
any problem with doing so?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Neal Gompa]

On Thu, Jul 11, 2019 at 2:37 PM Adam Williamson
 wrote:
>
> On Thu, 2019-07-11 at 13:14 -0400, Neal Gompa wrote:
> > On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes  wrote:
> > > On Thu, 11 Jul 2019 at 14:52, Neal Gompa  wrote:
> > > > My understanding of the situation was that Canonical is working on a
> > > > separate experience tailored for Ubuntu because they have extra needs,
> > > > but all of it was built on GNOME Software in the first place.
> > >
> > > No, it's also a new codebase: https://github.com/ubuntu/snap-store --
> > > it's confusing as the name "Snap Store" is also the name of the
> > > debadged-gnome-software version too.
> > >
> > > > My opinion on this is that because we don't ship the plugin or snapd
> > > > by default on any variant of Fedora, we don't really run counter to
> > > > the rules.
> > >
> > > So in the same way, we could have a checkbox for "Flathub support" in
> > > the gnome-software addons page? I don't think that would wash with
> > > legal as we would be "facilitating" access to patent encumbered
> > > software. I don't think the "by default" arguments protects us like
> > > that.
> > >
> > > > Would it make sense for Zygmunt and Maciek (CC'd to this email) to be
> > > > added as CC contacts on Bugzilla, so they can address snap plugin
> > > > issues when they arise?
> > >
> > > No, as they're not the ones committing fixes to gnome-software.
> > > Watching a bugzilla ticket doesn't equate to being responsible for
> > > bugs. The snap plugin self tests are failing in CI, and we can't even
> > > update to a newer gnome-software in rawhide as the version of
> > > snapd-glib is too old. Usually when that happens either me or Kalev
> > > have to hunt down the new tarballs, add any new BRs, scratch build,
> > > build, submit as an update etc and that's just not fair.
> > >
> >
> > For what it's worth, Robert Ancell also has an RHBZ account and can be
> > added as a CC if needed. That said, Maciek and Zygmunt are the folks
> > at Canonical generally responsible for ensuring the non-Ubuntu
> > experience is as good as it can be. They are the people I work with
> > for Fedora considerations upstream most of the time. They are both
> > knowledgeable and capable of working on that side if needed.
> >
> > I was unaware you've been needing new releases of snapd-glib more
> > frequently. I've mainly been updating them whenever I get a bug report
> > or when I notice a new version is available. If you need me to be more
> > aggressive on updating snapd-glib, I could have done that.
> >
> > > > I'm just generally confused about this, and somewhat blindsided...
> > >
> > > I was informed of the Canonical decision a few weeks ago, and it too
> > > took me by surprise. I guess winning the war comes at a cost, and this
> > > camel has a broken back.
> > >
> > > > I wish someone had looped *me* into these conversations, as one of the
> > > > snap support maintainers in Fedora, I'm relying on these things to
> > > > provide a good experience for Fedora users of snaps...
> > >
> > > I was asked not to distribute details about the conversations until
> > > they had made a public statement, which still hasn't been done. I'm
> > > not comfortable with the situation at all either but we have to do
> > > something.
> > >
>
> Practically speaking, Neal, can you not just create the 'gnome-
> software-snap' package Richard suggested, and maintain that? Is there
> any problem with doing so?

Technically speaking, I can.

However, GNOME Software provides no ABI guarantees for plugins, which
is why all of them are in-tree. If an update occurs even within stable
releases, I would expect it to have a chance to break. I considered
this approach when I introduced snapd to EPEL7, but discarded it for
this reason.

If forced to, I'll do that, but I'd really rather avoid having to go
down that path. And if GNOME Software removes the plugin, that makes
it even harder on me. But again, if forced, I guess I'll do something
to try to provide a good experience for Fedora Workstation users. I
don't know what I'll do, but I'll try to figure something out.





--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2019-07-12)

[Igor Gnatenko]

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

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

or run:
  date -d '2019-07-12 15:00 UTC'


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

= Discussed and Voted in the Ticket =

F31 Self-Contained Change: Xfce 4.14
https://pagure.io/fesco/issue/2157
APPROVED (+6, 0, -0)

F31 Self-Contained Change: Custom Crypto Policies
https://pagure.io/fesco/issue/2158
APPROVED (+6, 0, -0)

Unresponsive Maintainer: gil
https://pagure.io/fesco/issue/2159
APPROVED (+3, 0, -0)

Unresponsive Maintainer: lef
https://pagure.io/fesco/issue/2160
APPROVED (+3, 0, -0)

F31 System-Wide Change: No more i686 kernels or bootable images
https://pagure.io/fesco/issue/2162
APPROVED (+6, 0, -0)

F31 System-Wide Change: The GNU C Library version 2.30
https://pagure.io/fesco/issue/2163
APPROVED (+7, 0, -0)

F31 Self-Contained Change: Move test.support module to python3-test subpackage
https://pagure.io/fesco/issue/2164
APPROVED (+5, 0, -0)

= Followups =

#topic #2162 F31 System-Wide Change: No more i686 kernels or bootable images
.fesco 2162
https://pagure.io/fesco/issue/2162

#topic #2149 Proposal to change non-responsive maintainer policy
.fesco 2149
https://pagure.io/fesco/issue/2149

#topic #2146 Temporarily revert breaking module changes
.fesco 2146
https://pagure.io/fesco/issue/2146

= New business =

#topic #2166 F31 System-Wide Change: Python means Python 3
.fesco 2166
https://pagure.io/fesco/issue/2166

#topic #2165 F31 System-Wide Change: Golang 1.13
.fesco 2165
https://pagure.io/fesco/issue/2165

#topic #2155 Non-responsive maintainer "bdpepple" for package "farstream02"
.fesco 2155
https://pagure.io/fesco/issue/2155

= Open Floor =

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

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

Re: Orphaning moby-engine (Docker)

[Olivier Lemasle]

On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
>
> I have orphaned moby-engine, the community Docker package in Fedora,
> due to no longer working in a role where I can maintain it as part of
> the job.  If anyone wants to take it, it is up to date in F30 and
> rawhide branches (F29 was not updated for compatibility since it
> doesn't enable SELinux), but there is an open issue that should be
> addressed before pushing new updates:  Docker 18.09 and later
> conflicts with runc and containerd since it dropped "docker-" prefixes
> from its binaries.  I can describe some options and backstory if
> needed, but I suppose you could address it however you want as the new
> maintainer.
>

I'm open to maintaining this package. However, what was the reason
"moby-engine" packaged its own version of runc and containerd, both
packaged on their own in Fedora?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lines disordered in mock's build.log

[Rex Dieter]

Miro Hrončok wrote:

> Hello,
> 
> I've noticed that last couple of weeks, I see disordered lines in mock's
> build.log. This happens constantly in local mock, copr and Koji. Example:

Are you using %make_build or at least 'make -O' ?

just 'make %{?_smp_mflags}' does have chances of getting ordering wrong 
without -O flag

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[Daniel Walsh]

On 7/11/19 4:32 PM, Olivier Lemasle wrote:
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
>> I have orphaned moby-engine, the community Docker package in Fedora,
>> due to no longer working in a role where I can maintain it as part of
>> the job.  If anyone wants to take it, it is up to date in F30 and
>> rawhide branches (F29 was not updated for compatibility since it
>> doesn't enable SELinux), but there is an open issue that should be
>> addressed before pushing new updates:  Docker 18.09 and later
>> conflicts with runc and containerd since it dropped "docker-" prefixes
>> from its binaries.  I can describe some options and backstory if
>> needed, but I suppose you could address it however you want as the new
>> maintainer.
>>
> I'm open to maintaining this package. However, what was the reason
> "moby-engine" packaged its own version of runc and containerd, both
> packaged on their own in Fedora?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

They shouldn't, we have an open Bugzilla on that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Richard Hughes]

On Thu, 11 Jul 2019 at 21:02, Neal Gompa  wrote:
> If an update occurs even within stable
> releases, I would expect it to have a chance to break.

We don't break plugin ABI in stable GNOME releases. e.g. 3.32.1 will
be the same internal ABI as 3.32.x. In development releases (e.g.
3.33.x) all plugin ABI is fair game.

Also note: at the moment the plan is to keep the snap plugin in the
upstream tree unless something drastic changes.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Lines disordered in mock's build.log

[Miro Hrončok]

On 11. 07. 19 22:40, Rex Dieter wrote:

Miro Hrončok wrote:


Hello,

I've noticed that last couple of weeks, I see disordered lines in mock's
build.log. This happens constantly in local mock, copr and Koji. Example:


Are you using %make_build or at least 'make -O' ?

just 'make %{?_smp_mflags}' does have chances of getting ordering wrong
without -O flag


This happens everywhere, not just with make.

Sometimes I even see "Bad exist status from %check" in the middle of pytest 
output.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[David Michael]

On Thu, Jul 11, 2019 at 5:22 PM Olivier Lemasle  wrote:
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
> > I have orphaned moby-engine, the community Docker package in Fedora,
> > due to no longer working in a role where I can maintain it as part of
> > the job.  If anyone wants to take it, it is up to date in F30 and
> > rawhide branches (F29 was not updated for compatibility since it
> > doesn't enable SELinux), but there is an open issue that should be
> > addressed before pushing new updates:  Docker 18.09 and later
> > conflicts with runc and containerd since it dropped "docker-" prefixes
> > from its binaries.  I can describe some options and backstory if
> > needed, but I suppose you could address it however you want as the new
> > maintainer.
> >
>
> I'm open to maintaining this package. However, what was the reason
> "moby-engine" packaged its own version of runc and containerd, both
> packaged on their own in Fedora?

Each upstream Docker release targets a specific commit of each
component (containerd, proxy, runc, and tini) specified at:

https://github.com/docker/docker-ce/tree/v18.09.7/components/engine/hack/dockerfile/install

These specific commits are basically considered part of the release;
e.g. they are included in the Docker versions' release notes.  I'm not
aware of the initial decision to bundle the components in the Fedora
package since it was done that way from the beginning before I was a
maintainer (I'd assume it was due to previous Docker versions using
forks of the containerd and runc repos), but from experience
maintaining it for another distro, upstream would send user bug
reports back to you as the distro maintainer if there is any deviation
from what they're shipping.  It might end up being less maintenance
work by not unbundling the specified versions.

Also, when I started maintaining it for Fedora, it was explained to me
that moby-engine should follow upstream to provide an expected Docker
experience on Fedora CoreOS (since any specialized container needs
would be implemented in podman), but I don't think it is a priority
for that team anymore.  You can probably do whatever you think is best
at this point.

Thanks.

David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Robert Ancell]

Thanks Neal.

Let me reassure you that we are committed to maintaining the G-S Snap
plugin and snapd-glib. We do want to ensure it’s available for any user of
GNOME Software that wishes to use Snaps, regardless of which distro they
are using. The Snap plugin is enabled in all Ubuntu releases so it should
work well, but if there are unit test failures please let us know.

We’re happy for the Snap plugin to be built in a separate source package
for Fedora if that’s necessary and we’re obviously keen to see snapd-glib
up to date in Fedora. The dependencies are fairly light so it should be
quick to update but let us know if there is anything we can do to make this
easier. Note that snapd-glib updates frequently to enable new features in
snapd but retains backwards compatibility.

It’s still very early days for our ideas for
https://github.com/ubuntu/snap-store and we’ll post more detailed
information in the next few weeks.

On Fri, Jul 12, 2019 at 5:15 AM Neal Gompa  wrote:

> On Thu, Jul 11, 2019 at 11:34 AM Richard Hughes 
> wrote:
> >
> > On Thu, 11 Jul 2019 at 14:52, Neal Gompa  wrote:
> > > My understanding of the situation was that Canonical is working on a
> > > separate experience tailored for Ubuntu because they have extra needs,
> > > but all of it was built on GNOME Software in the first place.
> >
> > No, it's also a new codebase: https://github.com/ubuntu/snap-store --
> > it's confusing as the name "Snap Store" is also the name of the
> > debadged-gnome-software version too.
> >
> > > My opinion on this is that because we don't ship the plugin or snapd
> > > by default on any variant of Fedora, we don't really run counter to
> > > the rules.
> >
> > So in the same way, we could have a checkbox for "Flathub support" in
> > the gnome-software addons page? I don't think that would wash with
> > legal as we would be "facilitating" access to patent encumbered
> > software. I don't think the "by default" arguments protects us like
> > that.
> >
> > > Would it make sense for Zygmunt and Maciek (CC'd to this email) to be
> > > added as CC contacts on Bugzilla, so they can address snap plugin
> > > issues when they arise?
> >
> > No, as they're not the ones committing fixes to gnome-software.
> > Watching a bugzilla ticket doesn't equate to being responsible for
> > bugs. The snap plugin self tests are failing in CI, and we can't even
> > update to a newer gnome-software in rawhide as the version of
> > snapd-glib is too old. Usually when that happens either me or Kalev
> > have to hunt down the new tarballs, add any new BRs, scratch build,
> > build, submit as an update etc and that's just not fair.
> >
>
> For what it's worth, Robert Ancell also has an RHBZ account and can be
> added as a CC if needed. That said, Maciek and Zygmunt are the folks
> at Canonical generally responsible for ensuring the non-Ubuntu
> experience is as good as it can be. They are the people I work with
> for Fedora considerations upstream most of the time. They are both
> knowledgeable and capable of working on that side if needed.
>
> I was unaware you've been needing new releases of snapd-glib more
> frequently. I've mainly been updating them whenever I get a bug report
> or when I notice a new version is available. If you need me to be more
> aggressive on updating snapd-glib, I could have done that.
>
> > > I'm just generally confused about this, and somewhat blindsided...
> >
> > I was informed of the Canonical decision a few weeks ago, and it too
> > took me by surprise. I guess winning the war comes at a cost, and this
> > camel has a broken back.
> >
> > > I wish someone had looped *me* into these conversations, as one of the
> > > snap support maintainers in Fedora, I'm relying on these things to
> > > provide a good experience for Fedora users of snaps...
> >
> > I was asked not to distribute details about the conversations until
> > they had made a public statement, which still hasn't been done. I'm
> > not comfortable with the situation at all either but we have to do
> > something.
> >
>
> :(
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: No more snap plugin in gnome-software

[Neal Gompa]

On Thu, Jul 11, 2019 at 9:13 PM Robert Ancell
 wrote:
>
> Thanks Neal.
>
> Let me reassure you that we are committed to maintaining the G-S Snap plugin 
> and snapd-glib. We do want to ensure it’s available for any user of GNOME 
> Software that wishes to use Snaps, regardless of which distro they are using. 
> The Snap plugin is enabled in all Ubuntu releases so it should work well, but 
> if there are unit test failures please let us know.

What I'm confused about is how the situation got to this point.
Richard seems to indicate that this has been broken in GNOME Software
upstream for some time, and that's concerning. I thought you worked
upstream in GNOME on this?

>
> We’re happy for the Snap plugin to be built in a separate source package for 
> Fedora if that’s necessary and we’re obviously keen to see snapd-glib up to 
> date in Fedora. The dependencies are fairly light so it should be quick to 
> update but let us know if there is anything we can do to make this easier. 
> Note that snapd-glib updates frequently to enable new features in snapd but 
> retains backwards compatibility.
>

Honestly, the only reason I hadn't updated it to 1.48 is due to being
busy and lack of noticing it's there. It's been generally easy for me
to update it across all Fedora releases and even EPEL7.

I've pushed updates to Bodhi now for snapd-glib 1.48, in addition to
pushing it into Rawhide:
* F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b6612c5fe5
* F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-bc3dfb389f
* EPEL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-238f49e9a5

On Thu, Jul 11, 2019 at 5:34 PM Richard Hughes  wrote:
>
> On Thu, 11 Jul 2019 at 21:02, Neal Gompa  wrote:
> > If an update occurs even within stable
> > releases, I would expect it to have a chance to break.
>
> We don't break plugin ABI in stable GNOME releases. e.g. 3.32.1 will
> be the same internal ABI as 3.32.x. In development releases (e.g.
> 3.33.x) all plugin ABI is fair game.
>
> Also note: at the moment the plan is to keep the snap plugin in the
> upstream tree unless something drastic changes.
>

I'd *really* prefer to find a solution which lets us keep building the
plugin as part of the gnome-software source package. If there have
been snap plugin specific issues, I haven't heard of them, and I
*know* that Robert and the rest of the folks working on non-Ubuntu
snap work would like to know about them, so they can do something
about it. Sadly, omniscience and mind reading technology don't exist,
so we need to be told these things. :)



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

orphaning: comps-extras, goffice08

[Bill Nottingham]

comps-extras: required by PackageKit
goffice08: required by nip2, cutter

Neither has required any significant maintenance if someone wants to pick them 
up.

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org