[Bug 1669888] perl-Inline-Struct-0.27 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Inline-Struct-0.27-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-b152a53f5b

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1669888] perl-Inline-Struct-0.27 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Inline-Struct-0.27-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-368b440898

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Nicolas Mailhot]

Le jeudi 31 janvier 2019 à 19:52 -0500, Neal Gompa a écrit :
> On Thu, Jan 31, 2019 at 6:58 PM Stephen John Smoogen  > wrote:
> > On Thu, 31 Jan 2019 at 07:28, Igor Gnatenko <
> > ignatenkobr...@fedoraproject.org> wrote:
> > > Problem №1: Build-only packages
> > > 
> > > Rawhide gating makes this much more complicated because builds
> > > appear in buildroot slower, updating group of packages would need
> > > side tags and it’s just painful to work with.
> > > 
> > > https://pagure.io/fesco/issue/2068
> > > 
> > > And, after all, those packages shouldn’t be shipped to users.
> > 
> > My main problem with this is the above. Yes Joe Desktop User isn't
> > going to see/need that package.. but we have a LOT of packagers who
> > take our stuff and rebuild it for themselves for various reasons. I
> > find it hard to put together the proposal which is supposed to make
> > developing/packaging easier with making developing/packaging harder.
> > Whether you want it to or not, this comes across as "If you want to
> > use Go or Rust, you will need our special set of tools which we keep
> > hidden."
> > 
> 
> This is actually something I really don't like either. But the Fedora
> leadership has pushed very hard on the concept of having packages that
> aren't available to "normies", and require special tooling to be able
> to leverage (that for various reasons, I can't even use as a third
> party packager!). 

If MBI is about hiding build packages I don't see the point and I'm not
interested.

What I *am* interested in is being able to import in one go the
hundred(s) of srpms involved in building the complex highly modularized
stuff package projects output nowadays, without the two months of review
getting each spec audited separately would entail.

Our main infra and main administrative processes just don't scale.

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

Re: F30: Self-Contained Change proposal: Firefox Wayland By Default On Gnome

[Tom Hughes]

On 01/02/2019 06:49, Chris Murphy wrote:


For what it's worth, starting with firefox 65 there are two packages:
firefox-wayland-65.0-1.fc29.x86_64
firefox-65.0-1.fc29.x86_64


That has existed for some time, it's not new with 65.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30: Self-Contained Change proposal: Firefox Wayland By Default On Gnome

[Chris Murphy]

For what it's worth, starting with firefox 65 there are two packages:
firefox-wayland-65.0-1.fc29.x86_64
firefox-65.0-1.fc29.x86_64

And after installing them there are two application icons in gnome:
Firefox and Firefox on Wayland. Both work fine when I've logged into a
gnome wayland session; and if it's a gnome on Xorg session, only
Firefox launches, whereas Firefox on Wayland sorta just fails silently
(spinner hangs out for a bit then goes away), there is a journal
message 'firefox[13165]: cannot open display: :0' but that's it.

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

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

[389-devel] 389 DS nightly 2019-02-01 - % PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/02/01/report-389-ds-base-1.4.1.1-20190201gitaf9bb72.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Can't figure out how to build flatpaks

[Owen Taylor]

On Thu, Jan 31, 2019 at 12:23 PM Pete Walter  wrote:
> I've noticed that someone created a flatpak build for one of my packages 
> (feedreader), but it's horribly out of date: flatpak has 2.5.1 vs rpm has 
> 2.7.0. I've been trying to update the flatpak build, but not much luck here. 
> The documentation is pretty verbose, but seems to miss some crucial steps and 
> nothing really works.

Thanks for trying it out, and sorry that you are having problems!

[...]
> Up until here everything seems to check out and download correctly, but then 
> when I do:
>
> $ flatpak-module local-build --install
[...]
> module_build_service.errors.UnprocessableEntity: None of the base module 
> (platform) streams in the buildrequires section could be found

This is a poor error message. What it means is that your buildrequires
is missing:

 platform: [f29]

(for other modules, you may want platform: [] to build against all
streams, but that doesn't make so much sense for Flatpaks, where a
single build will work on multiple Fedora versions.)

Requiring all modules to depend directly on platform instead of just
indirectly through (in this case, flatpak-runtime) is a change in MBS
as aof a few months ago, 'fedmod rpm2flatpak' will now add this
dependency automatically but the feedreader.yaml modulemd file is old.
You can  run
'fedmod rpm2flatpak --force --flatpak-common --flathub=feedreader
feedreader' to update the files in modules/feedreader, and commit the
changes if they look good. (I've turned over modules/feedreader to you
in src.fedoraproject.org.)

>   - buildrequires:
>   flatpak-runtime: [f29]
> requires:
>   flatpak-runtime: [f29]
>
> so I've tried to do 'dnf install flatpak-runtime' but the package doesn't 
> seem to be available.

These are module buildrequires, not package buildrequires. But as
above, it's just a really confusing error message.

> Next, I thought I'd try building it in koji. Not sure how to do that, the 
> docs are fairly vague, mentioning 'git push origin master' but I don't have 
> anything really to push, the existing git doesn't seem to refer to package 
> versions or anything. I figured that maybe it somehow magically connects it 
> to dist-git rpms/feedreader and gets the sources there

If you look at feedreader.yaml, the different components have 'ref:
f29' - this means "use the f29 branch of dist-git/rpms/". The way
that the module-build-service works however, the *first time* a
particular git commit of modules/ is done, the
module-build-service code freezes the versions of all components
remembers them if you try to build the same commit again. So building
again without a change would have built 2.5.1 again. A useful thing to
know is:

 git commit --allow-empty -m "Rebuild for newer feedreader" ; git push origin

Note that you do need to fix up the platform dependency of
feedreader.yaml, so it's not important here.

> so I've tried just 'fedpkg module-build' without pushing anything to 
> modules/flatpak, but that fails again with the familiar missing buildrequires 
> error:
>
> $ fedpkg module-build
> Submitting the module build...
> Could not execute module_build: The build failed with:
> None of the base module (platform or bootstrap) streams in the buildrequires 
> section could be found

Yes, that's the same error.

> Is the flatpak building actually working for anyone? What am I doing wrong? 
> How do I specify what version to actually build?

It is currently working, yes. And rebuilding it (with fixes) will
automatically use the latest versions of the branch. I'm trying to
work now on a small application to show a status page for the Flatpaks
in Fedora that will highlight cases where the RPMs are newer than
what's in the Flatpaks.

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

[Bug 1670644] perl-Ouch-0.0501 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Ouch-0.0501-1.fc29 has been pushed to the Fedora 29 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-2019-e08b178ad9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1670644] perl-Ouch-0.0501 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Ouch-0.0501-1.fc28 has been pushed to the Fedora 28 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-2019-d6085904b0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1668421] perl-Inline-Struct-0.26 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Inline-Struct-0.26-1.f |perl-Inline-Struct-0.26-1.f
   |c30 |c30
   |perl-Inline-Struct-0.26-1.f |perl-Inline-Struct-0.26-1.f
   |c28 |c28
   ||perl-Inline-Struct-0.26-1.f
   ||c29



--- Comment #7 from Fedora Update System  ---
perl-Inline-Struct-0.26-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1667692] perl-Inline-Struct-0.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Inline-Struct-0.25-1.f |perl-Inline-Struct-0.25-1.f
   |c30 |c30
   |perl-Inline-Struct-0.26-1.f |perl-Inline-Struct-0.26-1.f
   |c28 |c28
   ||perl-Inline-Struct-0.26-1.f
   ||c29



--- Comment #11 from Fedora Update System  ---
perl-Inline-Struct-0.26-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1668421] perl-Inline-Struct-0.26 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Inline-Struct-0.26-1.f |perl-Inline-Struct-0.26-1.f
   |c30 |c30
   ||perl-Inline-Struct-0.26-1.f
   ||c28
 Resolution|--- |ERRATA
Last Closed||2019-02-01 01:41:40



--- Comment #6 from Fedora Update System  ---
perl-Inline-Struct-0.26-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1667692] perl-Inline-Struct-0.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Inline-Struct-0.25-1.f |perl-Inline-Struct-0.25-1.f
   |c30 |c30
   ||perl-Inline-Struct-0.26-1.f
   ||c28
 Resolution|--- |ERRATA
Last Closed||2019-02-01 01:41:41



--- Comment #10 from Fedora Update System  ---
perl-Inline-Struct-0.26-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Kevin Fenzi]

On 1/31/19 4:52 PM, Neal Gompa wrote:

...snip...

> COPR was supposed to be that outlet, but no one gives a damn about it.
> Everyone complains that the service is "bad" and that the design is
> "bad" but no one wants to actually constructively improve it. The
> quality of service on COPR has fallen due to lack of care and
> unwillingness to invest, so what are we supposed to do? The horrible

I've heard you and some others say this, but can you perhaps expand on
it? How has quality of service of copr fallen?

There are times when a bunch of builds are dumped on it that it takes a
bit to catch up, but it's usually like an hour not days or anything.
Is it the build time you refer to? Or something(s) else?

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Neal Gompa]

On Thu, Jan 31, 2019 at 6:58 PM Stephen John Smoogen  wrote:
>
> On Thu, 31 Jan 2019 at 07:28, Igor Gnatenko 
>  wrote:
>>
>> Problem №1: Build-only packages
>>
>> Rawhide gating makes this much more complicated because builds appear in 
>> buildroot slower, updating group of packages would need side tags and it’s 
>> just painful to work with.
>>
>> https://pagure.io/fesco/issue/2068
>>
>> And, after all, those packages shouldn’t be shipped to users.
>
>
> My main problem with this is the above. Yes Joe Desktop User isn't going to 
> see/need that package.. but we have a LOT of packagers who take our stuff and 
> rebuild it for themselves for various reasons. I find it hard to put together 
> the proposal which is supposed to make developing/packaging easier with 
> making developing/packaging harder. Whether you want it to or not, this comes 
> across as "If you want to use Go or Rust, you will need our special set of 
> tools which we keep hidden."
>

This is actually something I really don't like either. But the Fedora
leadership has pushed very hard on the concept of having packages that
aren't available to "normies", and require special tooling to be able
to leverage (that for various reasons, I can't even use as a third
party packager!). That's a big part of the core to how Modularity is
being used. The CRB in RHEL 8 is another example of this. But fixing
this is very hard when few others see it as a problem. There was even
talk of not publishing SRPMs of packages that make up modules a while
ago. That idea died very quickly thankfully, but I don't know how
people think of these things anymore.

I'm tired of fighting... Our tools haven't improved enough to handle
our new challenges in the Fedora way, because it's hard for people in
the community to experiment and explore in this manner. My hope is
that with something like MBI, we can finally put the power to
experiment and develop tooling that actually makes sense for Fedora
(rather than clearly being designed for RHEL and shoehorned into
Fedora) without all the pain and agony of people imposing RHELish
requirements. There's no way we can evolve and meet the needs of our
communities without some way for people to "play".

COPR was supposed to be that outlet, but no one gives a damn about it.
Everyone complains that the service is "bad" and that the design is
"bad" but no one wants to actually constructively improve it. The
quality of service on COPR has fallen due to lack of care and
unwillingness to invest, so what are we supposed to do? The horrible
thing is that COPR is successful *despite* that. COPR is an
interesting and cool service, and I would have loved to see an
eventual merger of the Koji and COPR systems (because there are
awesome attributes to both and we should have a large and strong team
actually supporting the literal core of the distribution), but it
won't happen because everyone thinks the COPR system is terrible even
though it's not really.

I've been arguing for literally years about our shortcomings. I've
built tools for working around pitfalls in the Fedora workflow for my
personal use. I've personally explored how other people and other
distributions do things. I got my hands dirty to learn about other
ways of doing things. I've used that knowledge and expertise to avoid
those mistakes when deploying package and image construction
infrastructure for $DAYJOB. But it deeply saddens me that I have not
been able to make any meaningful progress in convincing anyone that it
was something that we should invest in.

I still believe that Modularity, as designed, is a mistake. But if I
don't have a way to prove a better way to do things, there's no way
anything will improve. The folks running the show like what they have
now, so it'll take a lot to trigger change.



-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Stephen John Smoogen]

On Thu, 31 Jan 2019 at 07:28, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> Problem №1: Build-only packages
>
>
> Rawhide gating makes this much more complicated because builds appear in
> buildroot slower, updating group of packages would need side tags and it’s
> just painful to work with.
>
> https://pagure.io/fesco/issue/2068
>
> And, after all, those packages shouldn’t be shipped to users.
>

My main problem with this is the above. Yes Joe Desktop User isn't going to
see/need that package.. but we have a LOT of packagers who take our stuff
and rebuild it for themselves for various reasons. I find it hard to put
together the proposal which is supposed to make developing/packaging easier
with making developing/packaging harder. Whether you want it to or not,
this comes across as "If you want to use Go or Rust, you will need our
special set of tools which we keep hidden."


>
>


-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: OpenVPN 3 Linux client - v3 beta release

[David Sommerseth]

On 01/02/2019 00:01, Tom Hughes wrote:
> On 31/01/2019 22:44, David Sommerseth wrote:
> 
>> This new client shares the same code base the OpenVPN Connect (proprietary)
>> clients uses as well as the OpenVPN for Android when switching to use the
>> OpenVPN 3 backend.  The OpenVPN 3 code base is a rewrite in C++ and makes use
>> of the more modern features of C++11.
> 
> So what does this mean for the server? Currently client and server
> are the same program but it sounds like this is a pure client so does
> that mean client support will be removed from the current program to
> make it server only? or that there will be a new server?

Yes, this is a pure client.  But it is mostly backwards compatible with
OpenVPN 2.x servers.  The most noticeable missing features are support for TAP
devices and the lack of --fragment.  TAP support is not planned, as all VPN
APIs on mobile devices and even the Unified Windows Platform (UWP) API does
only support TUN mode.

Users depending on TAP may continue to use OpenVPN 2.x for a long time
forward, but should start considering to switch to routed TUN in the future.

The --fragment features is troublesome.  It is unfortunately needed in some
networks, but it is a quite heavy feature to implement - especially when this
is not too often needed.  This feature basically needs to do a lot of a
similar task you'll find in the TCP stack, and in particular packet reassembly
and keep track of packets received - and then the chunking of packets into new
sizes.  We are investigating better solutions to --fragment, both in the
company and within the community.  Our ideal goal would be that --fragment
would no longer needed and the OpenVPN protocol itself would figure out how to
solve this issue when it occurs.

There are more options which are unsupported (if you test your configuration
with the openvpn2 front-end provided in the openvpn3 package, you'll notice
soon enough).  We will backport those options which makes sense and has a real
use case (like --verify-x509-name).  But the overall idea is to try to reduce
the quite enormous amount of options available in OpenVPN 2.x.


-- 
kind regards,

David Sommerseth
OpenVPN Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: OpenVPN 3 Linux client - v3 beta release

[Tom Hughes]

On 31/01/2019 22:44, David Sommerseth wrote:


This new client shares the same code base the OpenVPN Connect (proprietary)
clients uses as well as the OpenVPN for Android when switching to use the
OpenVPN 3 backend.  The OpenVPN 3 code base is a rewrite in C++ and makes use
of the more modern features of C++11.


So what does this mean for the server? Currently client and server
are the same program but it sounds like this is a pure client so does
that mean client support will be removed from the current program to
make it server only? or that there will be a new server?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

OpenVPN 3 Linux client - v3 beta release

[David Sommerseth]

Hi,

As some of you know, I've been involved with the OpenVPN packages for some
time as well as being an upstream OpenVPN developer and maintainer.  Now we
have released the third beta release of OpenVPN 3 Linux.

This new client shares the same code base the OpenVPN Connect (proprietary)
clients uses as well as the OpenVPN for Android when switching to use the
OpenVPN 3 backend.  The OpenVPN 3 code base is a rewrite in C++ and makes use
of the more modern features of C++11.

The Linux version is also very different from the OpenVPN 2.x generation, as
it is now D-Bus based.  We have done this to allow easier integration with
other users and front-ends on Linux as well as having a better privilege
separation.  Once all the backend pieces of OpenVPN 3 Linux has settled non of
them runs with more privileges than absolutely needed and there are several
services running which is responsible for only a subset of the features.  This
is probably the least privileged OpenVPN implementation available today.  On
top of that, we have also tried to make DNS configuration work out-of-the-box
as well (but here we need much more work to be really complete).

Part of this project we're also trying to get some kind of equivalent of the
Android VPN API in place on Linux.  We have our own D-Bus service which
provides the needed functionality and can hopefully work as a stepping stone
towards something which can also be used outside OpenVPN alone too.  The
current implementation should already provide all the needed features to
create and configure TUN devices (including IP addresses, routing and DNS) for
unprivileged users.

I'm announcing this here now as we also have Fedora Copr builds available for
EPEL-7, Fedora 28, Fedora 29 and Rawhide.  In not too far future I would like
to get the process running to get the openvpn3 package into the mainline
Fedora repositories as well.



Our main source repositories can be found here:




We would be very much interested to get more users to try this out and to move
this project forward.  The current codebase is in a reasonably good shape.  It
is a bit rough around the edges when it comes to the DNS configuration and
/etc/resolv.conf handling, but otherwise it is fairly production ready.

This project aims to have good and reasonable documentation.  I'm not saying
we're perfect in this regards, and we're open to improve here too.  All D-Bus
services should be fairly well documented and we should have man pages for
most of the binaries we provide.

* D-Bus details
  

* man pages:
  


Feel free to reach out if you have some questions or good ideas.


--
kind regards,

David Sommerseth
OpenVPN Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Mass rebuild - emacs broken

[Richard W.M. Jones]

emacs isn't installable at the moment, so any package that needs emacs
fails to build, eg:

https://koji.fedoraproject.org/koji/taskinfo?taskID=32380321

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Kevin Fenzi]

On 1/31/19 4:24 AM, Igor Gnatenko wrote:

> ProblemsProblem №1: Build-only packages
> 
> Some ecosystems have many build-only packages (packages which are used to
> build other packages, without having them installed on end-user systems).
> Those ecosystems include Java, Rust and Go.
> 
> It is extremely hard to keep up maintaining them due to lack of
> time/people. Upstreams are usually changing quickly (sometimes when you
> update just one such package, you’d need to update tens of the
> dependencies). Few facts about such packages:
> 
>-
> 
>They are almost always outdated in released versions of distribution;
>-
> 
>They are often FTBFS (e.g. because there was compiler update but not
>package update, broken deps, broken APIs due to deps rebases, …).
> 
> 
> In Rust ecosystem, we abuse Rawhide to build and store such packages there
> and then generate end-user application (e.g. ripgrep) which uses some of
> those packages and produces binary for all supported releases. Those
> applications have high quality and are supported.
> 
> Rawhide gating makes this much more complicated because builds appear in
> buildroot slower, updating group of packages would need side tags and it’s
> just painful to work with.

Note that the rawhide gating plans include self service side tags, so
you can make one anytime you want to update a collection of packages.

This of course doesn't solve the above problem, but it's worth
mentioning I think.

> https://pagure.io/fesco/issue/2068
> 
> And, after all, those packages shouldn’t be shipped to users.

This of course means however that users who want to build their own
verions of the applications or whatever can't start from our repos, they
have to use whatever setup we use for developing them. I don't know any
answers here but it seems to me we keep making it harder for people to
use Fedora to develop applications.

...snip...

> Solution
> 
>-
> 
>Separate Koji + Koschei deployed in Fedora infrastructure cloud;

Turns out we are going to be retiring our cloud, so no, this is not a
place to put it. :)

>-
> 
>Builders are optimized for the best performance (see below
>
> 
>);
>-
> 
>People can have their own targets where they can break things as they
>wish without affecting others;

Would that be entirely self service? Or ?

>-
> 
>Package changes are eventually contributed to Fedora proper by merging
>changes to Fedora dist-git and rebuilding packages in official Fedora Koji;

Where is the source for the changes from? Would this need it's own
pagure/src/dist-git? Or would it pull from PR's in prod dist git? Or ?

>-
> 
>All improvements can eventually be contributed back to official Fedora
>infra.

Sounds great!

> 
> Ideas
> 
> All ideas which you’ll find below are just an ideas and do not have to be
> implemented.
> Idea №1: Automated legal review
> 
> openSUSE released their review app called Cavil
>  which we could try running in automated
> way.

I guess this would be up to legal to look at and tell us if it's worth
doing.

> Idea №2: Automated package review
> 
> Currently review process is burden and we could run automated legal review,
> create a repo, run set of checks and notify person. Somewhat similar to
> fresque . In future might be
> integrated with approval process and auto-imported into Fedora.

Sounds great if someone has time to build the app(s)

> Idea №3: Building packages for multiple distributions
> 
> In Rust ecosystem, we managed to get have same packaging guidelines in
> openSUSE, Mageia and Fedora. We could automatically build some packages on
> multiple distributions and be kinda upstream.

So, this setup will need to distribute things... would it need mirrors
as well? or ?

> Idea №4: Building custom images with user content
> 
> Deploy (or build) a tool(s) to enable user-built install, appliance and
> container images with their content (modulo restrictions similar to COPR)
> on top of Fedora.

Yeah, this has been attempted about 3 times, but if someone has cycles
to work on a app/tool again, great!

> Implementation details
> 
>-
> 
>Koji and Koschei deployed in fedorainfracloud.org

Nope. There are options of course, but the cloud won't be one. ;)
We could do a remote cloud provider possibly, or we are considering
another openshift cluster with kubevirt or perhaps just some simple
virthost/ansible controlled thing. In any case I think if it's important
we can get resources.
>-
> 
>A few builders constantly running, with a possibility to add more
>builders as needed and as available cloud resources allow

koji doesn't have much way to dynamically deal with builders...

>-
> 
>Deployed and maintained by proposal owners - not supported by Fedora
>

Re: F30 Self-Contained Change proposal: MongoDB Removal

[John Harris]

On Thursday, January 31, 2019 4:32:38 PM EST Stephen John Smoogen wrote:
> On Thu, 31 Jan 2019 at 16:21, John Harris  wrote:
> > On Thursday, January 31, 2019 2:09:08 PM EST Chris Murphy wrote:
> > > And that is the most central problem with the license, and why it
> > > isn't free for everyone all of the time. The idea free licenses can
> > > have gray areas where they aren't free, pollutes the free license
> > > ecosystem with confusion. And it burdens users who aren't sure of
> > > their usage with having to hire a lawyer to find out. So the answer
> > > is, it's not a free license. We can't have people downloading Fedora
> > > who use it for building a service and then they end up snared in a
> > > lawsuit because 'oh fuck we're using MongoDB! and we didn't know about
> > > this! we thought Fedora was only free software!'
> > 
> > Even taken to an extreme, it would likely be sufficient to link to
> > Fedora's
> > sources on any software used to provide MongoDB as a service, assuming
> > their
> > service itself is free software.
> 
> For the last time, please move this to the legal list, a blog, or your own
> tweet stream. This isn't the list for non-lawyers to discuss how they think
> law, licenses and contracts 'work' just because it looks just like COBOL.

Please do not suggest non-free platforms such as Twitter. Most users do not 
know how to use such a platform without running non-free JavaScript, which may 
restrict their Four Freedoms.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: MongoDB Removal

[Stephen John Smoogen]

On Thu, 31 Jan 2019 at 16:21, John Harris  wrote:

> On Thursday, January 31, 2019 2:09:08 PM EST Chris Murphy wrote:
> > And that is the most central problem with the license, and why it
> > isn't free for everyone all of the time. The idea free licenses can
> > have gray areas where they aren't free, pollutes the free license
> > ecosystem with confusion. And it burdens users who aren't sure of
> > their usage with having to hire a lawyer to find out. So the answer
> > is, it's not a free license. We can't have people downloading Fedora
> > who use it for building a service and then they end up snared in a
> > lawsuit because 'oh fuck we're using MongoDB! and we didn't know about
> > this! we thought Fedora was only free software!'
>
> Even taken to an extreme, it would likely be sufficient to link to
> Fedora's
> sources on any software used to provide MongoDB as a service, assuming
> their
> service itself is free software.
>
>
>
For the last time, please move this to the legal list, a blog, or your own
tweet stream. This isn't the list for non-lawyers to discuss how they think
law, licenses and contracts 'work' just because it looks just like COBOL.


-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: MongoDB Removal

[John Harris]

On Thursday, January 31, 2019 2:09:08 PM EST Chris Murphy wrote:
> And that is the most central problem with the license, and why it
> isn't free for everyone all of the time. The idea free licenses can
> have gray areas where they aren't free, pollutes the free license
> ecosystem with confusion. And it burdens users who aren't sure of
> their usage with having to hire a lawyer to find out. So the answer
> is, it's not a free license. We can't have people downloading Fedora
> who use it for building a service and then they end up snared in a
> lawsuit because 'oh fuck we're using MongoDB! and we didn't know about
> this! we thought Fedora was only free software!'

Even taken to an extreme, it would likely be sufficient to link to Fedora's 
sources on any software used to provide MongoDB as a service, assuming their 
service itself is free software.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: MongoDB Removal

[Chris Murphy]

On Wed, Jan 30, 2019 at 4:42 PM John Harris  wrote:
>
> On Wednesday, January 30, 2019 4:19:13 PM EST Simon Farnsworth wrote:
> > But the SSPL also prevents you from using Free Software with it, unless you
> > have sufficient rights to offer said Free Software under the SSPL, as per
> > section 13 of the SSPL.
>
> You don't have to relicense software in order to be able to use it.
>
> > I do not have sufficient rights to relicence the Linux kernel under the SSPL
> > - it's not GPLv2 compatible - and the Linux kernel is one part of a service
> > I might choose to offer using only Free Software from Fedora's repos, plus
> > an SSPL licensed component.
>
> Yeah, none of that matters. See section 1.
>
> > Thus, I'm stuck - I can't use non-SSPL software from Fedora (or, indeed,
> > from the FSF) in combination with SSPL licensed software to provide a
> > service, even if I *also* make the full source of the entire service
> > available, since I'm not making the source available under the SSPL.
>
> Unless you're providing MongoDB as a service, it doesn't matter, even
> according to their own FAQ.

And that is the most central problem with the license, and why it
isn't free for everyone all of the time. The idea free licenses can
have gray areas where they aren't free, pollutes the free license
ecosystem with confusion. And it burdens users who aren't sure of
their usage with having to hire a lawyer to find out. So the answer
is, it's not a free license. We can't have people downloading Fedora
who use it for building a service and then they end up snared in a
lawsuit because 'oh fuck we're using MongoDB! and we didn't know about
this! we thought Fedora was only free software!'


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

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Kevin Fenzi]

On 1/30/19 1:39 PM, Adam Williamson wrote:

> Question: how plausibly can we sort of "test retire" yum? i.e. just
> somehow run a single compose process without it included, and see what
> breaks?

Well, we could block yum in koji and remove it from all builders and see
what happens, but I think it will break all epel builds (unless we
switch epel to use dnf for buildroot population too) at least.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Boost 1.69 update with soname bumps in rawhide/F30

[Patrick Diehl]

Hi,

I maintain the hpx package, which links against boost. I would prefer to
build my package by myself, since we will need to update it to compile/link
with boost 1.69. I tested it yesterday and we need to patch our last stable
release to work with boost 1.69. The patch should be available next week.

Best,

Patrick

On Fri, 25 Jan 2019 at 09:58, Jonathan Wakely 
wrote:

> With enormous thanks to Denis Arnaud for doing the actual boost.spec
> rebase, we're ready to update Boost in rawhide, for this change:
> https://fedoraproject.org/wiki/Changes/F30Boost169
>
> As always, this changes the soname of every libboost_*.so library, so
> we'll be rebuilding all the packages that link to Boost libs. These
> rebuilds will happen on the f30-boost side tag, and once they're all
> done everything will move to the main f30 target all at once.
>
> IF YOU MAINTAIN A PACKAGE THAT DEPENDS ON BOOST and need to rebuild it
> in the next few days, please get in touch so we can coordinate. It's
> better to avoid me doing a rebuild in the f30-boost side tag, then
> somebody else doing another rebuild in the main f30 target, and then
> me having to do another build in the side tag! If you'd rather I don't
> rebuild your package (e.g. so you can finish an update and then build
> it yourself) please get in touch.
>
> I've done local builds of most of them, and 130+ build OK. Any that
> fail I'll create bugzilla FTBFS reports for.
>
> I expect the following to fail, because they link to
> libboost_python.so and that has changed to libboost_python27.so, so
> unless they have build-system logic to already detect that change
> (which might exist in some build systems already, I guess), they'll
> need a fix:
>
> avogadro
> condor
> dmlite
> freecad
> gfal2-python
> ledger
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Stephen John Smoogen]

On Thu, 31 Jan 2019 at 07:28, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> Solution
>
>-
>
>Separate Koji + Koschei deployed in Fedora infrastructure cloud;
>
>

>
>-
>
>FAQ
>
> Why not COPR?
>
>-
>
>COPR has been starved of resources for years, which has impaired its
>ability to provide reliable service at scale. Fedora Infrastructure refuses
>to consider supporting it officially and Fedora Release Engineering seems
>to have some undefined issues with COPR.
>-
>
>
>
>
OK I would say that putting this into the very place where the other build
system is starved of resources does not sound like it is going to work any
better. You will need to price out what AWS is and find a budget payer for
it. There are several groups who should be able to do so if they can find a
real budget for it.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Miro Hrončok]

On 31. 01. 19 16:32, Michal Domonkos wrote:

On Wed, Jan 30, 2019 at 6:46 PM Miro Hrončok  wrote:

Based on the entire discussion so far, here's my proposal:

   - we change this to a system wide change
   - we move it to Fedora 31
   - we retire the packages from rawhide as soon as f30 is branched regardless 
of
the dependent packages
   - packages with broken deps / FTBFS due to this will be retired if not fixed
by beta freeze

Contingency mechanism:

   - if some process (releng or similar) needs the packages in order to ship
Fedora 31, the packages are added into a designated copr repo maintained by the
person/team responsible for the tool that needs yum (or other packages retired)

   - if the above is not possible and the packages are indeed needed in the
actual f31 repos, packages are unretired but the person/team responsible for the
tool that needs yum maintains them as long as they need them and retires them
once that is no longer true


+1

As an alternative solution, based on a discussion with Neal Gompa
today on IRC, I propose the following:

   - we remove python-urlgrabber from the original change proposal
(i.e. keeping it in F30)
   - we proceed with the retirement of the rest of the YUM stack in F30
   - we make sure the kojid PR[1] is merged in time for F30

This is based on the following two facts:

   - python-urlgrabber seems to be the last component of the YUM stack
that turns this proposal into a "system-wide" change, due to a number
of infra bits that require it (sigul, koji-containerbuild, osc or
imagefactory).   Therefore, if we just postpone the removal of
python-urlgrabber to F31 and merge that kojid PR, we could perhaps
agree on re-qualifying the change as "self-contained" (plus, there's
also the possibility of porting[2] python-urlgrabber to Python 3, but
that's for a separate discussion)
   - the kojid PR[1] is also in-line with another F30 change[3], so
there should be enough incentive to have it merged

Before I go ahead and edit the proposal: Does this variant make sense to you?


It does to me. But well, I've been called a Python 2 deletionist before, so not 
sure if I'm not biased :)



[1] https://pagure.io/koji/pull-request/1117
[2] https://github.com/rpm-software-management/urlgrabber/pull/8
[3] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal



--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Ben Cotton]

Igor,

This is great. It seems like it would fit in really well with the Packager
Experience objective proposal[1] that Ben Rosser was working on. I know you
weighed in on that thread at one point. Is this a part of that proposed
objective or is it separate?

[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6HUAWQA35ZBUGPVNLCGGP5H5HFOUHNUZ/#V2GNNKC4CN6GRZOMEW3I3COXQSB57CPD

-- 
Ben Cotton
Fedora Program Manager
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Can't figure out how to build flatpaks

[Pete Walter]

Hi,

I've noticed that someone created a flatpak build for one of my packages 
(feedreader), but it's horribly out of date: flatpak has 2.5.1 vs rpm has 
2.7.0. I've been trying to update the flatpak build, but not much luck here. 
The documentation is pretty verbose, but seems to miss some crucial steps and 
nothing really works.

I've been following 
https://fishsoup.net/misc/fedora-docs-flatpak/flatpak/tutorial/

Specifically, I've typed the following commands:

# dnf install flatpak-module-tools fedmod

$ fedpkg clone modules/feedreader
$ cd feedreader
$ fedmod fetch-metadata

Up until here everything seems to check out and download correctly, but then 
when I do:

$ flatpak-module local-build --install
2019-01-31 17:11:52,388 - MainThread - moksha.hub - WARNING - Cannot find qpid 
python module. Make sure you have python-qpid installed.
BUILDING MODULE
===
Traceback (most recent call last):
  File "/usr/bin/mbs-manager", line 11, in 
load_entry_point('module-build-service==2.12.2', 'console_scripts', 
'mbs-manager')()
  File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line 
189, in manager_wrapper
manager.run()
  File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 417, 
in run
result = self.handle(argv[0], argv[1:])
  File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 386, 
in handle
res = handle(*args, **config)
  File "/usr/lib/python3.7/site-packages/flask_script/commands.py", line 216, 
in __call__
return self.run(*args, **kwargs)
  File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line 
154, in build_module_locally
username, handle, str(stream), skiptests, optional_params)
  File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", 
line 386, in submit_module_build_from_yaml
return submit_module_build(username, None, mmd, optional_params)
  File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", 
line 486, in submit_module_build
mmds = generate_expanded_mmds(db.session, mmd, raise_if_stream_ambigous, 
default_streams)
  File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py", 
line 345, in generate_expanded_mmds
current_mmd, default_streams, raise_if_stream_ambigous)
  File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py", 
line 276, in get_mmds_required_by_module_recursively
.format(base_module_choices))
module_build_service.errors.UnprocessableEntity: None of the base module 
(platform) streams in the buildrequires section could be found

error: mbs-manager build_module_locally failed
error: log: None


From this error message, it's unclear to me what I need to install. 
feedreader.yaml has:

  - buildrequires:
  flatpak-runtime: [f29]
requires:
  flatpak-runtime: [f29]

so I've tried to do 'dnf install flatpak-runtime' but the package doesn't seem 
to be available.

Next, I thought I'd try building it in koji. Not sure how to do that, the docs 
are fairly vague, mentioning 'git push origin master' but I don't have anything 
really to push, the existing git doesn't seem to refer to package versions or 
anything. I figured that maybe it somehow magically connects it to dist-git 
rpms/feedreader and gets the sources there so I've tried just 'fedpkg 
module-build' without pushing anything to modules/flatpak, but that fails again 
with the familiar missing buildrequires error:

$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
None of the base module (platform or bootstrap) streams in the buildrequires 
section could be found

Is the flatpak building actually working for anyone? What am I doing wrong? How 
do I specify what version to actually build?

Thanks,
Pete

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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Neal Gompa]

On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller 
wrote:
>
> On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote:
> > Please don't do that. You'll basically break the distribution for all
> > third-party packagers. Modules are not supported by anyone at all, and
> > it's too difficult to integrate as it currently stands (and I'm
> > actually trying because of the impending doom that is RHEL 8).
>
> Can you elaborate? How would this break third-party packagers?
>

I've mentioned this before in other places, but the Fedora Modularity
initiative, as currently designed and implemented, is functionally
impossible for me as a third-party packager to use. As stuff moves from the
regular repository to the modular repo, I lose access to that content for
dependencies. This affects my ability to ship software for Fedora as part
of the work I do for my day job. And once the distribution starts requiring
modules to function or to access entire ecosystems (like Java), I'm SOL.

I was horrified when I found out that RHEL 8 was "modularized" in this
manner, because I can't construct a build environment for it right now.
There was no thought into the broader ecosystem, or even solving the
problem in a reasonably compatible manner.

A lot of my tools just flat out break because the assumption that rpm-md is
always XML was broken by modulemd for repodata being YAML instead of XML.
My ability to hack together even a jerry-rigged solution has been hampered
by the fact that I can't even access all the different options easily
either. The repository looks like nonsense and everything is basically
broken to conventional tools because of the massive collection of
conflicting sets of packages with odd NVRs that make version comparisons
behave oddly.


-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Michal Domonkos]

On Wed, Jan 30, 2019 at 6:46 PM Miro Hrončok  wrote:
> Based on the entire discussion so far, here's my proposal:
>
>   - we change this to a system wide change
>   - we move it to Fedora 31
>   - we retire the packages from rawhide as soon as f30 is branched regardless 
> of
> the dependent packages
>   - packages with broken deps / FTBFS due to this will be retired if not fixed
> by beta freeze
>
> Contingency mechanism:
>
>   - if some process (releng or similar) needs the packages in order to ship
> Fedora 31, the packages are added into a designated copr repo maintained by 
> the
> person/team responsible for the tool that needs yum (or other packages 
> retired)
>
>   - if the above is not possible and the packages are indeed needed in the
> actual f31 repos, packages are unretired but the person/team responsible for 
> the
> tool that needs yum maintains them as long as they need them and retires them
> once that is no longer true

+1

As an alternative solution, based on a discussion with Neal Gompa
today on IRC, I propose the following:

  - we remove python-urlgrabber from the original change proposal
(i.e. keeping it in F30)
  - we proceed with the retirement of the rest of the YUM stack in F30
  - we make sure the kojid PR[1] is merged in time for F30

This is based on the following two facts:

  - python-urlgrabber seems to be the last component of the YUM stack
that turns this proposal into a "system-wide" change, due to a number
of infra bits that require it (sigul, koji-containerbuild, osc or
imagefactory).   Therefore, if we just postpone the removal of
python-urlgrabber to F31 and merge that kojid PR, we could perhaps
agree on re-qualifying the change as "self-contained" (plus, there's
also the possibility of porting[2] python-urlgrabber to Python 3, but
that's for a separate discussion)
  - the kojid PR[1] is also in-line with another F30 change[3], so
there should be enough incentive to have it merged

Before I go ahead and edit the proposal: Does this variant make sense to you?

[1] https://pagure.io/koji/pull-request/1117
[2] https://github.com/rpm-software-management/urlgrabber/pull/8
[3] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

-- 
Michal Domonkos
Software Engineer, Software Mgmt Subsystem
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [modularity] Policy change: module defaults changes & Fedora Changes

[John Harris]

On Thursday, January 31, 2019 9:29:57 AM EST Adam Samalik wrote:
> The Modularity Team has published an updated policy regarding changing
> module defaults and submitting Fedora Changes [1].
> 
> Simplified summary:
> instead of: "Packagers must submit a Fedora Change when changing module
> defaults."
> it now says: "Packagers should submit a Fedora Change when changing module
> defaults based on their best judgement."
> 
> That brings it much closer to how we handle major changes in traditional
> packages.
> 
> Cheers!
> Adam
> 
> [1]
> https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defa
> ults/

This is great. I'm glad that Modularity is becoming more in line with 
traditional packages, where this would not have been an issue.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Boost 1.69 update with soname bumps in rawhide/F30

[José Abílio Matos]

On Tuesday, 29 January 2019 20.11.13 WET Jonathan Wakely wrote:
> Thanks! Do you want me to apply that patch for rawhide and rebuild it?

I have added the patch and changed accordingly the spec file and I am 
expecting for it to be picked by the rebuild in course. :-)

Thank you. :-)
-- 
José Abílio

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

[modularity] Policy change: module defaults changes & Fedora Changes

[Adam Samalik]

The Modularity Team has published an updated policy regarding changing
module defaults and submitting Fedora Changes [1].

Simplified summary:
instead of: "Packagers must submit a Fedora Change when changing module
defaults."
it now says: "Packagers should submit a Fedora Change when changing module
defaults based on their best judgement."

That brings it much closer to how we handle major changes in traditional
packages.

Cheers!
Adam

[1]
https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/

-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Brian (bex) Exelbierd]

On Thu, Jan 31, 2019 at 1:40 PM Mikolaj Izdebski  wrote:
>
> On Thu, Jan 31, 2019 at 1:36 PM Josh Boyer  wrote:
> > Why does this need to be deployed in the fedora infrastructure cloud?
> > Seems like you could stand it up in AWS or somewhere else.
>
> Because we (Fedora contributors) don't have budget to pay AWS bills.
> If someone is willing to sponsor this then AWS would work well.

I encourage you to specify what you need and then the Project can
figure out if and how it wants to provide it.  So if you need a
specific kind of access, note that.  If you just need machines, note
that.  If you need sysadmin work, note that, etc.

regards,

bex

>
> --
> Mikolaj
> ___
> infrastructure mailing list -- infrastruct...@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org



-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MBI (Playground 2.0)

[Mikolaj Izdebski]

On Thu, Jan 31, 2019 at 1:36 PM Josh Boyer  wrote:
> Why does this need to be deployed in the fedora infrastructure cloud?
> Seems like you could stand it up in AWS or somewhere else.

Because we (Fedora contributors) don't have budget to pay AWS bills.
If someone is willing to sponsor this then AWS would work well.

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

Re: MBI (Playground 2.0)

[Josh Boyer]

On Thu, Jan 31, 2019 at 7:28 AM Igor Gnatenko
 wrote:
>
> MayBe I …(can do something useful)?
>
> Hello,
>
> We've been discussing some (hopefully) nice idea with Mikolaj, Neal and Jakub 
> how we could improve packager (and user) experience and we have some proposal 
> which will be described below.
>
> We would like to ask you to read it, understand it and ask us any questions 
> you have. From the Fedora Infrastructure we would like to ask for some 
> machines to implement this idea (you can find some more information in 
> "Implementation details" part).
>
> I would like to apologize for HTML email, but it is much easier to have it 
> that way to have better visibility and reading easiness.
>
> Feel free to reply to this email or comment in google doc (there is a link on 
> the bottom).
>
> Proposal Owners
>
> Mikolaj Izdebski (mizdebsk) - Java SIG, Fedora infrastructure
>
> Igor Gnatenko (ignatenkobrain) - Rust SIG, Golang SIG, Neuro SIG, RPM and 
> libsolv contributor
>
> Neal Gompa (ngompa) - Rust SIG, Golang SIG, RPM contributor
>
> Jakub Čajka (jcajka) - Golang SIG, Container SIG
>
>
> This proposal aligns with the objective of improving the packager experience 
> by developing a platform whereby the proposal owners and others can 
> experiment with improvements that can be funneled back into the official 
> production infrastructure.
>
> Problems
>
> Problem №1: Build-only packages
>
> Some ecosystems have many build-only packages (packages which are used to 
> build other packages, without having them installed on end-user systems). 
> Those ecosystems include Java, Rust and Go.
>
>
> It is extremely hard to keep up maintaining them due to lack of time/people. 
> Upstreams are usually changing quickly (sometimes when you update just one 
> such package, you’d need to update tens of the dependencies). Few facts about 
> such packages:
>
> They are almost always outdated in released versions of distribution;
>
> They are often FTBFS (e.g. because there was compiler update but not package 
> update, broken deps, broken APIs due to deps rebases, …).
>
>
> In Rust ecosystem, we abuse Rawhide to build and store such packages there 
> and then generate end-user application (e.g. ripgrep) which uses some of 
> those packages and produces binary for all supported releases. Those 
> applications have high quality and are supported.
>
> Rawhide gating makes this much more complicated because builds appear in 
> buildroot slower, updating group of packages would need side tags and it’s 
> just painful to work with.
>
> https://pagure.io/fesco/issue/2068
>
>
> And, after all, those packages shouldn’t be shipped to users.
>
> Problem №2: Testing of new rpm/koji/mock features/configuration
>
> When developing new features in RPM (e.g. rich dependencies) or testing 
> different Koji configuration (e.g. removing gcc/gcc-c++ from the buildroot), 
> it is required to make custom configuration and try building things.
>
> Problem №3: Developing modules
>
> Modules are built in MBS as a single unit. It is hard to develop big modules 
> by progressively improving individual packages or small package groups. 
> Scratch builds for modules are not implemented. Local builds work differently 
> from official module builds, they don’t scale and don’t allow groups of 
> people to work collaboratively. All these problems can be solved by first 
> developing a flat repository of packages in a shared environment and then 
> generating modulemd from such package set.
>
> Problem №4: Testing things before push
>
> Primary Fedora Koji and dist-git are not suited for packaging 
> experimentation. Packagers are expected to experiment on their own systems 
> and push changes of successful experiments only. But this approach doesn’t 
> scale with number of maintained packages. Often you can find commits like 
> “d’oh, forgot to upload sources” or “let’s try with this settings”. People 
> need to build things somewhere quickly, do development and testing. And only 
> after that, they should push commit(s) to Fedora.
>
> Solution
>
> Separate Koji + Koschei deployed in Fedora infrastructure cloud;

Why does this need to be deployed in the fedora infrastructure cloud?
Seems like you could stand it up in AWS or somewhere else.

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

MBI (Playground 2.0)

[Igor Gnatenko]

MayBe I …(can do something useful)?

Hello,

We've been discussing some (hopefully) nice idea with Mikolaj, Neal and
Jakub how we could improve packager (and user) experience and we have some
proposal which will be described below.

We would like to ask you to read it, understand it and ask us any questions
you have. From the Fedora Infrastructure we would like to ask for some
machines to implement this idea (you can find some more information in
"Implementation details" part).

I would like to apologize for HTML email, but it is much easier to have it
that way to have better visibility and reading easiness.

Feel free to reply to this email or comment in google doc (there is a link
on the bottom).
Proposal Owners

   -

   Mikolaj Izdebski (mizdebsk)  - Java SIG, Fedora
   infrastructure
   -

   Igor Gnatenko (ignatenkobrain)  - Rust
   SIG, Golang SIG, Neuro SIG, RPM and libsolv contributor
   -

   Neal Gompa (ngompa)  - Rust SIG, Golang SIG, RPM
   contributor
   -

   Jakub Čajka (jcajka)  - Golang SIG, Container
   SIG


This proposal aligns with the objective of improving the packager experience
 by
developing a platform whereby the proposal owners and others can experiment
with improvements that can be funneled back into the official production
infrastructure.
ProblemsProblem №1: Build-only packages

Some ecosystems have many build-only packages (packages which are used to
build other packages, without having them installed on end-user systems).
Those ecosystems include Java, Rust and Go.

It is extremely hard to keep up maintaining them due to lack of
time/people. Upstreams are usually changing quickly (sometimes when you
update just one such package, you’d need to update tens of the
dependencies). Few facts about such packages:

   -

   They are almost always outdated in released versions of distribution;
   -

   They are often FTBFS (e.g. because there was compiler update but not
   package update, broken deps, broken APIs due to deps rebases, …).


In Rust ecosystem, we abuse Rawhide to build and store such packages there
and then generate end-user application (e.g. ripgrep) which uses some of
those packages and produces binary for all supported releases. Those
applications have high quality and are supported.

Rawhide gating makes this much more complicated because builds appear in
buildroot slower, updating group of packages would need side tags and it’s
just painful to work with.

https://pagure.io/fesco/issue/2068

And, after all, those packages shouldn’t be shipped to users.
Problem №2: Testing of new rpm/koji/mock features/configuration

When developing new features in RPM (e.g. rich dependencies) or testing
different Koji configuration (e.g. removing gcc/gcc-c++ from the
buildroot), it is required to make custom configuration and try building
things.
Problem №3: Developing modules

Modules are built in MBS as a single unit. It is hard to develop big
modules by progressively improving individual packages or small package
groups. Scratch builds for modules are not implemented. Local builds work
differently from official module builds, they don’t scale and don’t allow
groups of people to work collaboratively. All these problems can be solved
by first developing a flat repository of packages in a shared environment
and then generating modulemd from such package set.
Problem №4: Testing things before push

Primary Fedora Koji and dist-git are not suited for packaging
experimentation. Packagers are expected to experiment on their own systems
and push changes of successful experiments only. But this approach doesn’t
scale with number of maintained packages. Often you can find commits like
“d’oh, forgot to upload sources” or “let’s try with this settings”. People
need to build things somewhere quickly, do development and testing. And
only after that, they should push commit(s) to Fedora.
Solution

   -

   Separate Koji + Koschei deployed in Fedora infrastructure cloud;
   -

   Builders are optimized for the best performance (see below
   

   );
   -

   People can have their own targets where they can break things as they
   wish without affecting others;
   -

   Package changes are eventually contributed to Fedora proper by merging
   changes to Fedora dist-git and rebuilding packages in official Fedora Koji;
   -

   All improvements can eventually be contributed back to official Fedora
   infra.

Ideas

All ideas which you’ll find below are just an ideas and do not have to be
implemented.
Idea №1: Automated legal review

openSUSE released their review app called Cavil
 which we could try running in automated
way.
Idea №2: Automated package review

Currently review process is burden and we could run automated legal review,
create a repo, run set of checks and notify person. Somewhat 

Re: Fedora 30 Mass Rebuild

[Mohan Boddu]

Hi all,

Fedora 30 Mass Rebuild will start in few minutes. We are preparing for the
final steps and will run mass rebuild once everything is in place.

On Wed, Jan 30, 2019 at 4:02 AM Mohan Boddu  wrote:

> Hi all,
>
> Per the Fedora 30 schedule[1] we are supposed to start the mass rebuild
> on Jan 30th 2019, but due to known bug with gcc it got pushed by a day and
> will start on Jan 31st 2019[2]. We are doing a mass rebuild for Fedora 30 for
> all the changes listed in
>
> https://pagure.io/releng/issue/8086
>
> This is a heads up that it will be done in a side tag and moved over
> when completed. We will be running scripts to output failure stats.
> please be sure to let releng know if you see any bugs in the reporting.
>
> You can contact releng in #fedora-releng on freenode.
>
> Failures can be seen
>
> https://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html
>
> Things still needing rebuilt
>
> https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html
>
> [1] https://fedoraproject.org/wiki/Releases/30/Schedule
> [2] https://pagure.io/fesco/issue/2066
>
> Regards
>
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Mass Rebuild

[Mohan Boddu]

Hi all,

Fedora 30 Mass Rebuild will start in few minutes. We are preparing for the
final steps and will run mass rebuild once everything is in place.

On Wed, Jan 30, 2019 at 4:02 AM Mohan Boddu  wrote:

> Hi all,
>
> Per the Fedora 30 schedule[1] we are supposed to start the mass rebuild
> on Jan 30th 2019, but due to known bug with gcc it got pushed by a day and
> will start on Jan 31st 2019[2]. We are doing a mass rebuild for Fedora 30 for
> all the changes listed in
>
> https://pagure.io/releng/issue/8086
>
> This is a heads up that it will be done in a side tag and moved over
> when completed. We will be running scripts to output failure stats.
> please be sure to let releng know if you see any bugs in the reporting.
>
> You can contact releng in #fedora-releng on freenode.
>
> Failures can be seen
>
> https://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html
>
> Things still needing rebuilt
>
> https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html
>
> [1] https://fedoraproject.org/wiki/Releases/30/Schedule
> [2] https://pagure.io/fesco/issue/2066
>
> Regards
>
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Fixing Wireguard spec file

[Germano Massullo]

Joe, I found a machine on which I can reproduce the problem. I installed
wireguard-dkms-0.0.20190123-2.fc29.noarch
on top of
wireguard-dkms-0.0.20190123-1.fc29.noarch
but the machine while running
# dkms autoinstall
still returns
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist.

Actually I am leaving this place, so I will have no longer access to
this machine for a certain amount of time
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Stephen John Smoogen]

On Thu, 31 Jan 2019 at 05:46, Panu Matilainen  wrote:

> On 1/30/19 2:52 PM, Stephen John Smoogen wrote:
> >
> >
>
> So basically: treat all changes as system-wide by default with a single
> proposal deadline, but if the review process discovers that a change
> truly is a self-contained one then it can be "downgraded" to
> self-contained and allow later submission into the distro. Defaulting to
> system-wide should also take away feeling of gaming the system.
>
>
Would 'allow for earlier entrance into the distro' work better. AKA if it
is self-contained they can push it into rawhide on X date and if it is
system-wide they get a date so people are aware when it happens and can
help fix/report bugs to it?

[And yes I just added 3 layers to this cake.]


> - Panu -
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange rawhide behaviour

[Miro Hrončok]

On 31. 01. 19 11:51, Stephen John Smoogen wrote:



On Thu, 31 Jan 2019 at 05:21, Miro Hrončok > wrote:


On 31. 01. 19 10:56, Adam Williamson wrote:
 > Just as a note, what's in the 'rawhide' repo right now differs quite a
 > lot from what's in the buildroot as we haven't had a successful compose
 > since 2019-01-21. This is for various reasons - most recently
 > libreoffice needed rebuilding for the poppler soname bump and did not
 > build successfully for nearly a week, and now lorax has a dependency
 > issue.

Oh I was so happy that I managed to build libreoffice this night after it
timeouted on arm yesterday, and now it's lorax :(

I'm hypnotizing

https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID

for days. When I blink I see "Fedora-Rawhide-20190121.n.1" written on a 
wall :D

Remind me why is this designed in a way that one single thing can block the
entire repo from even being created? I never really understood that part. I
mean
of course we can't build images, but why not repos?


Because everything was designed when we had a much smaller set of packages and 
several things have come up over and over again.
1. Anything that breaks apart the distro from being 1 thing brings up the Extras 
vs Core boogeymen and massive flame wars that some packages have become 'core 
(can block a compose)' and others 'extras (can't block a compose)'. Nobody in 
release engineering/IT has any emotional energy to get involved in that anymore.
2. Some method could be done but it takes a lot of concentrated effort by the 
people keeping the current system working. We are not allowed to slow down 
releases and are being asked to speed them up. Slowing anything down causes 
people to complain mightily (even if they earlier complained things were 
broken).. so we have been going along as best we can.
3. There have been several quick 'oh that would fix everything!' fixes that 
people have tried and each one has fallen down to either a) the size of the repo 
b) sure that works but anyone can inject or alter a build with their own rootkit 
type problems (or similar security problems). That then takes time to figure out 
how not to do that.. and we fall into 1 & 2.


We can try to get out of this but people are going to have to deal with some 
breakage, slowing, etc.. or come up with an alternative solution and implement it.


Thanks for this!


 > (it occurs to me to wonder whether it should be a matter of policy that
 > soname rebuilds that involve libreoffice must be done in a side tag,
 > but Rawhide package gating may render that concern obsolete soon).

Please, make that a policy! Soon can easily become months.


Do you want it to be a written policy or a coded policy? A written policy no one 
actually follows can happen shortly. A policy which actually looks to see if you 
are doing something and doesn't would be another thing.


I suppose start with a written policy. Make sure that we inform all the 
maintainers of whatever libs libreoffice requires directly. It BRs ~100 devel 
packages, so we can watch them closely and constantly remind the maintainers if 
they break this policy.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange rawhide behaviour

[Stephen John Smoogen]

On Thu, 31 Jan 2019 at 05:21, Miro Hrončok  wrote:

> On 31. 01. 19 10:56, Adam Williamson wrote:
> > Just as a note, what's in the 'rawhide' repo right now differs quite a
> > lot from what's in the buildroot as we haven't had a successful compose
> > since 2019-01-21. This is for various reasons - most recently
> > libreoffice needed rebuilding for the poppler soname bump and did not
> > build successfully for nearly a week, and now lorax has a dependency
> > issue.
>
> Oh I was so happy that I managed to build libreoffice this night after it
> timeouted on arm yesterday, and now it's lorax :(
>
> I'm hypnotizing
>
> https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID
> for days. When I blink I see "Fedora-Rawhide-20190121.n.1" written on a
> wall :D
>
> Remind me why is this designed in a way that one single thing can block
> the
> entire repo from even being created? I never really understood that part.
> I mean
> of course we can't build images, but why not repos?
>
>
Because everything was designed when we had a much smaller set of packages
and several things have come up over and over again.
1. Anything that breaks apart the distro from being 1 thing brings up the
Extras vs Core boogeymen and massive flame wars that some packages have
become 'core (can block a compose)' and others 'extras (can't block a
compose)'. Nobody in release engineering/IT has any emotional energy to get
involved in that anymore.
2. Some method could be done but it takes a lot of concentrated effort by
the people keeping the current system working. We are not allowed to slow
down releases and are being asked to speed them up. Slowing anything down
causes people to complain mightily (even if they earlier complained things
were broken).. so we have been going along as best we can.
3. There have been several quick 'oh that would fix everything!' fixes that
people have tried and each one has fallen down to either a) the size of the
repo b) sure that works but anyone can inject or alter a build with their
own rootkit type problems (or similar security problems). That then takes
time to figure out how not to do that.. and we fall into 1 & 2.

We can try to get out of this but people are going to have to deal with
some breakage, slowing, etc.. or come up with an alternative solution and
implement it.


> > (it occurs to me to wonder whether it should be a matter of policy that
> > soname rebuilds that involve libreoffice must be done in a side tag,
> > but Rawhide package gating may render that concern obsolete soon).
>
> Please, make that a policy! Soon can easily become months.
>
>
Do you want it to be a written policy or a coded policy? A written policy
no one actually follows can happen shortly. A policy which actually looks
to see if you are doing something and doesn't would be another thing.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Retire YUM 3

[Panu Matilainen]

On 1/30/19 2:52 PM, Stephen John Smoogen wrote:



On Wed, 30 Jan 2019 at 07:11, Matthew Miller > wrote:


On Wed, Jan 30, 2019 at 11:49:55AM +0100, Vít Ondruch wrote:
 > > 1) Move System-Wide and Self-Contained proposal deadlines to be the
 > > same date and allow FESCO/etc determine if the proposal needs to be
 > > moved to SW or SC then?
 > This split between SW and SC was artificial since the beginning
and I'd
 > be happy if we dropped it.

Well, sure, it's a process we made up. In that sense, _everything_ is
artificial when you get right down to it.

The difference really is supposed to be that self-contained changes are
"FYI" advertisements to the rest of the community and valuable for
release
notes, talking points, and other docs -- they don't really need approval
(except when they actually exceed that scope). System-wide changes need
coordination and greater communication, which is why they are
supposed to be
earlier.

We could make self-contained changes due earlier and go through the same
greater review process, but then we're gonna get a lot more "ugh
Fedora is
so process-heavy and bureaucratic" and people just not doing it at all.


The problem is that people are not really seeing what a 'self-contained' 
change is and to entirely detail out what it means.. we are also a 
process-heavy and bureaucratic system. I can see why changing bash or 
removing yum both look like they are self-contained to the maintainers. 
I also can see why a lot of people can feel like this was a game to 
sneak in a change because to them it is clearly not self-contained. I 
can finally see that we are going to deal with this every release with 
more and more  band-aids.


Since this clearly isn't working as it is, how about just taking the 
decision between self-contained and system-wide away from the 
maintainer? The thing is, the maintainer doesn't always see or even know 
the bigger picture. And because us humans are lazy, we're occasionally 
tempted to try sneak something in via an easier route because "such a 
small thing really can't break anything". Everybody's been there at one 
point or the other.


So basically: treat all changes as system-wide by default with a single 
proposal deadline, but if the review process discovers that a change 
truly is a self-contained one then it can be "downgraded" to 
self-contained and allow later submission into the distro. Defaulting to 
system-wide should also take away feeling of gaming the system.


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

Re: Strange rawhide behaviour

[Miro Hrončok]

On 31. 01. 19 11:18, Miro Hrončok wrote:

On 31. 01. 19 10:56, Adam Williamson wrote:

Just as a note, what's in the 'rawhide' repo right now differs quite a
lot from what's in the buildroot as we haven't had a successful compose
since 2019-01-21. This is for various reasons - most recently
libreoffice needed rebuilding for the poppler soname bump and did not
build successfully for nearly a week, and now lorax has a dependency
issue.


Oh I was so happy that I managed to build libreoffice this night after it 
timeouted on arm yesterday, and now it's lorax :(


Anyway:

Successfully waited 8:31 for lorax-30.13-2.fc30 to appear in the f30-build repo

If somebody has the powers to initiate a compose, please use them.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange rawhide behaviour

[Miro Hrončok]

On 31. 01. 19 10:56, Adam Williamson wrote:

Just as a note, what's in the 'rawhide' repo right now differs quite a
lot from what's in the buildroot as we haven't had a successful compose
since 2019-01-21. This is for various reasons - most recently
libreoffice needed rebuilding for the poppler soname bump and did not
build successfully for nearly a week, and now lorax has a dependency
issue.


Oh I was so happy that I managed to build libreoffice this night after it 
timeouted on arm yesterday, and now it's lorax :(


I'm hypnotizing 
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID 
for days. When I blink I see "Fedora-Rawhide-20190121.n.1" written on a wall :D


Remind me why is this designed in a way that one single thing can block the 
entire repo from even being created? I never really understood that part. I mean 
of course we can't build images, but why not repos?



(it occurs to me to wonder whether it should be a matter of policy that
soname rebuilds that involve libreoffice must be done in a side tag,
but Rawhide package gating may render that concern obsolete soon).


Please, make that a policy! Soon can easily become months.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fixing Wireguard spec file

[Germano Massullo]

Il giorno gio 31 gen 2019, 00:15 Joe Doss  ha scritto:

> Hey Germano,
>
> I have a working RPM that does not error out with Error! Could not locate
> dkms.conf file if you want to test it out before I push it to copr.
>


Hi Joe, I can test it on next Wireguard snapshot release, actually I cannot
reproduce an update action

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

[Bug 1671231] perl-Encode-3.00 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Encode-3.00-8.fc30
 Resolution|--- |RAWHIDE
Last Closed||2019-01-31 10:04:17



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 30.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Bash 5.0

[Neal Gompa]

On Thu, Jan 31, 2019 at 4:23 AM Matthew Miller  wrote:
>
> On Tue, Jan 29, 2019 at 03:01:55PM +0100, Igor Gnatenko wrote:
> > > But wait also: can't the module just refer to the release-branch (base)
> > > dist-git? Why maintain two copies?
> > Well, they can. But someone needs to build it twice: once using fedpkg
> > build and once using fedpkg module-build from the different repo
> > (which always requires at least empty commit).
>
> That's kind of annoying. Can we use Freshmaker or similar to auto-build the
> module?
>

We have stuff like that? I don't think we do. Automation for making
release package builds seems to scare people here. :/

> > > [2] hey, what happened to sgallagh's "hybrid" proposal where output from
> > > modules could just be *tagged into* base? That seemed perfect for 
> > > cases
> > > like this.
> > Well, it is called UM which is stuck in the FESCo loop.
>
> That seems significantly more complicated to me. Ursa Major is about adding
> modules to the buildroot; the "hybrid" idea was that the modular package
> builds could also be tagged as "regular" builds and land in the non-modular
> repo.
>

This proposal is completely new to me. I've never heard *anyone*
talking about that. If we did that, I'd be considerably happier, since
it won't break the world, and packages that we build with module
tooling don't need to require modularity enablement at runtime.



-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Strange rawhide behaviour

[Adam Williamson]

On Wed, 2019-01-30 at 15:37 +0100, Michal Schorm wrote:
> Right.
> 
> Yes, I'm trying to test the installation from the mirrors. There will
> be a delay.
> 
> Buildroot repo != compose repo.
> That's where I was mistaken.
> 
> Case closed, I'll wait :)

Just as a note, what's in the 'rawhide' repo right now differs quite a
lot from what's in the buildroot as we haven't had a successful compose
since 2019-01-21. This is for various reasons - most recently
libreoffice needed rebuilding for the poppler soname bump and did not
build successfully for nearly a week, and now lorax has a dependency
issue.

(it occurs to me to wonder whether it should be a matter of policy that
soname rebuilds that involve libreoffice must be done in a side tag,
but Rawhide package gating may render that concern obsolete soon).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: MongoDB Removal

[Florian Weimer]

* Emmanuel Seyman:

> I'm also going to note that the SSPLv1 has been superseded by the SSPLv2

That's not correct.  Version 1 is still current.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1670644] perl-Ouch-0.0501 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Ouch-0.0501-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-e08b178ad9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1670644] perl-Ouch-0.0501 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Ouch-0.0501-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-d6085904b0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fixing Wireguard spec file

[Fabio Valentini]

On Thu, Jan 31, 2019, 00:15 Joe Doss  Hey Germano,
>
> I have a working RPM that does not error out with Error! Could not locate
> dkms.conf file if you want to test it out before I push it to copr.
>
>
> https://copr-be.cloud.fedoraproject.org/results/jdoss/wireguard-testing/fedora-29-x86_64/00852015-wireguard-dkms/wireguard-dkms-0.0.20190123-2.fc29.noarch.rpm
>
> It is an issue with DKMS as I suspected. `%post` runs before the new
> package's `%preun` and the --rpm_safe_upgrade isn't working as it should.
> https://github.com/dell/dkms/issues/25#issuecomment-360275619. I followed
> this post's suggestion and moved from %post to %posttrans and this issue no
> longer happens. It feels hacky and I might spend some more time this
> weekend trying to find a better solution. ZFS worked around it with a bunch
> of bash
> https://github.com/zfsonlinux/zfs/blob/master/rpm/generic/zfs-dkms.spec.in#L74-L102
> so that might be what we try down the road.
>

On a related note, have you looked into using akmods instead of dkms? In m
experience, it works much better, especially because it actually integrates
with the packaging system (kernel modules are built as rpm packages and
installed with dnf, whenever the kernel or the module itself is updated).

Fabio


> If anyone on the list has a better idea on how to work around this issue
> please let me know.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1670644] perl-Ouch-0.0501 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC|ppi...@redhat.com   |
   Fixed In Version||perl-Ouch-0.0501-1.fc30



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: MongoDB Removal

[Emmanuel Seyman]

* John Harris [30/01/2019 21:09] :
>
> I'm offline for the night, but figured I'd head this off at the pass. I am 
> not 
> an attorney, and this does not constitute legal advice.

On that note, I'm going to recommend that legal discussions take place on the
legal list, not the devel one.

I'm also going to note that the SSPLv1 has been superseded by the SSPLv2 so
discussing the merits of the latter doesn't seem like the most productive use
of one time's but YMMV.

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