[Bug 1671231] New: perl-Encode-3.00 is available

[bugzilla]

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

Bug ID: 1671231
   Summary: perl-Encode-3.00 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Encode
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.00
Current version/release in rawhide: 2.99-7.fc30
URL: http://search.cpan.org/dist/Encode/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2849/

-- 
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: [Late] F30 System-Wide Change proposal: GCC9

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 29, 2019 at 01:22:19PM +, Daniel P. Berrangé wrote:
> On Tue, Jan 29, 2019 at 02:12:03PM +0100, Jakub Jelinek wrote:
> > On Tue, Jan 29, 2019 at 01:04:25PM +, Daniel P. Berrangé wrote:
> > > The variable was already initialized right at the start. The compound
> > > literal is just a short-hand for later changing the values in several
> > > fields of the struct at once. This is no different to manually assigning
> > > new values to each individual field one at a time. eg
> > > 
> > >   struct demo demo = {0};
> > > 
> > >   ...some code with a goto...
> > > 
> > >   demo = (struct demo) { .cmd = "foo" };
> > 
> > No, I wasn't talking about the demo variable, the warning is not about demo
> > variable.  The warning is about the compound literal variable.
> > That is an anonymous (when used at block scope automatic) variable, kind
> > like:
> >   struct demo __complit = { .cmd = "foo" };
> >   demo = __complit;
> > and with the goto you are crossing initialization of that variable.
> 
> Urgh. I would never have understood that from the warning message :-( It
> is complaining about something that doesn't even exist as far as I was
> concerned
> 
> > When you aren't taking address of this, the optimizers will likely optimize
> > the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" }
> > that address could be used later on in the function, dereferenced etc.
> 
> Is it practical to get the warning supressed when code is not taking the
> address of the anonymous var ?
> 
> If not then we pretty much have to abandon use of these anonymous
> compound initializers for re-assigning existing variables :-(

Let me second that. In systemd upstream we have been slowly changing
code to use compound initializers instead in places where "all" fields
of a structure would be assigned. With explicit list it's easy to miss
some fields when the code is changed, and compound initialization
avoids this risk. It's much more elegant. 

Zbyszek
___
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] Re: lib389 devel notes

[William Brown]

> On 31 Jan 2019, at 13:34, Mark Reynolds  wrote:
> 
> 
> On 1/30/19 9:16 PM, William Brown wrote:
>> Hi,
>> 
>> I noticed a few things that seem out of place in lib389’s cli tools. I just 
>> want to point out that using raw print isn’t really correct. Using log 
>> allows us to capture the written output for test verification, so always use 
>> log, not print.
> We have to use print() because the logging causes all kinds of issues with 
> CLI interaction.  Mainly you can not redirect it as you would expect, there 
> were other issues too but I don't recall them at the moment.  I think there 
> was a double logging issue as well?  The only viable option at the time was 
> to use to print() for the CLI tool's output.

No problem. I think this is a stdout/stderr issue as you say, but we can tell 
the logger to use stdout. I’ll put that into the PR as well. 


>> 
>> If you are then writing a function on a lib389 dsldapobject, you shouldn’t 
>> directly log the output either. You should return it (probably as a dict!) 
>> to the caller. This way the caller can either display/format the object 
>> correctly *or* they can consume the data in further functions. Even more 
>> important, by simply returning a dict, you can consume the _json magic. I 
>> saw an example where get_attr_vals was used, and then ensure_str called, 
>> then json transformed. The better way would have been to use 
>> get_attr_vals_utf8_json() which would have done all the correct wrapping and 
>> transformation for you :)
>> 
>> I know it seems nitpicky, but little details like this matter for testing 
>> and api cleanliness and reuse in future applications :)
>> 
>> Thanks,
>> 
>> —
>> Sincerely,
>> 
>> William Brown
>> Software Engineer, 389 Directory Server
>> SUSE Labs
>> ___
>> 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

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
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

[389-devel] Re: lib389 devel notes

[Mark Reynolds]

On 1/30/19 9:16 PM, William Brown wrote:

Hi,

I noticed a few things that seem out of place in lib389’s cli tools. I just 
want to point out that using raw print isn’t really correct. Using log allows 
us to capture the written output for test verification, so always use log, not 
print.
We have to use print() because the logging causes all kinds of issues 
with CLI interaction.  Mainly you can not redirect it as you would 
expect, there were other issues too but I don't recall them at the 
moment.  I think there was a double logging issue as well?  The only 
viable option at the time was to use to print() for the CLI tool's output.


If you are then writing a function on a lib389 dsldapobject, you shouldn’t 
directly log the output either. You should return it (probably as a dict!) to 
the caller. This way the caller can either display/format the object correctly 
*or* they can consume the data in further functions. Even more important, by 
simply returning a dict, you can consume the _json magic. I saw an example 
where get_attr_vals was used, and then ensure_str called, then json 
transformed. The better way would have been to use get_attr_vals_utf8_json() 
which would have done all the correct wrapping and transformation for you :)

I know it seems nitpicky, but little details like this matter for testing and 
api cleanliness and reuse in future applications :)

Thanks,

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
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

___
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

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

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/01/31/report-389-ds-base-1.4.1.1-20190131gitaf9bb72.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

[389-devel] Please review 50184 - cli tool parity for lib389

[William Brown]

https://pagure.io/389-ds-base/pull-request/50190

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

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
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

[389-devel] lib389 devel notes

[William Brown]

Hi,

I noticed a few things that seem out of place in lib389’s cli tools. I just 
want to point out that using raw print isn’t really correct. Using log allows 
us to capture the written output for test verification, so always use log, not 
print.

If you are then writing a function on a lib389 dsldapobject, you shouldn’t 
directly log the output either. You should return it (probably as a dict!) to 
the caller. This way the caller can either display/format the object correctly 
*or* they can consume the data in further functions. Even more important, by 
simply returning a dict, you can consume the _json magic. I saw an example 
where get_attr_vals was used, and then ensure_str called, then json 
transformed. The better way would have been to use get_attr_vals_utf8_json() 
which would have done all the correct wrapping and transformation for you :) 

I know it seems nitpicky, but little details like this matter for testing and 
api cleanliness and reuse in future applications :)

Thanks, 

—
Sincerely,

William Brown
Software Engineer, 389 Directory Server
SUSE Labs
___
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: F30 Self-Contained Change proposal: MongoDB Removal

[John Harris]

On Wednesday, January 30, 2019 9:05:42 PM EST Simon Farnsworth wrote:
> Where are you licensed to practice law? And is this legal advice that I can
> rely on your professional liability insurance for? Note that this statement
> is the exact opposite of one I've had from a real lawyer whose liability
> insurance kicks in if they're wrong - using MongoDB as a backing store
> could well be enough to require you to supply the whole service, including
> Major Components like the Linux kernel, under SSPL. AGPL is unacceptable -
> the terms say SSPL, and AGPL and SSPL are not identical.

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.

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

[Simon Farnsworth]

> On 31 Jan 2019, at 01:21, John Harris  wrote:
> 
> On Wednesday, January 30, 2019 8:10:13 PM EST Simon Farnsworth wrote:
>> I do if I'm using it to provide a service that could be construed as "making
>> the functionality of the Program … available to third parties as a
>> service", under section 13 of the SSPL. As MongoDB's functionality includes
>> retrieval of documents and document fragments, it's possible to construe
>> the licence as covering anything that involves retrieval of a document or
>> document fragment from a server (so all web applications, for example).
> 
> Yeah, that's not what section 13 actually says.
> 
> If you make the functionality of the Program or a modified version available 
> to third parties as a service, you must make the Service Source Code 
> available 
> via network download to everyone at no charge, under the terms of this 
> License.
> 

What exactly is "the functionality of the Program" in the case of MongoDB? 
Document storage and retrieval are two components of that functionality, and as 
written, it can be construed as meaning that if you provide document retrieval 
or document storage from MongoDB in your service, then you "make the 
functionality of the Program …available to third parties as a service".

I suspect this isn't what they mean, but it's what they've written in their 
licence.

> While the license certainly doesn't require anything that uses MongoDB as a 
> backing store to be free software, you should definitely make that free 
> software under the terms of a license such as the AGPL.
> 

Where are you licensed to practice law? And is this legal advice that I can 
rely on your professional liability insurance for? Note that this statement is 
the exact opposite of one I've had from a real lawyer whose liability insurance 
kicks in if they're wrong - using MongoDB as a backing store could well be 
enough to require you to supply the whole service, including Major Components 
like the Linux kernel, under SSPL. AGPL is unacceptable - the terms say SSPL, 
and AGPL and SSPL are not identical.

>> This may not be what's intended, but it's a reasonable reading of the
>> licence as written, and it could get expensive to argue in court that
>> covering all document retrieval was not intended.
> 
> Perhaps. The easiest option is to just use only free software.
> 
Worse than that - the only option if section 13 kicks in is to use only SSPL 
licensed software, as you have to supply the majority of your source code 
*under the SSPL*. Not just supply source code, but licence it under SSPL terms. 
AGPL may be Free Software, but it's not acceptable here.
>> 
>>> 
>>> 
 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.
>> 
>> 
>> I've read section 1 - Linux implements more than just a "Standard Interface"
>> as per that section (it goes beyond POSIX or any interface specified by an
>> Official Standards Body, and is not specified for a particular programming
>> language). Because of the way section 1 is drafted, "System Libraries" are
>> excluded from section 13, but *not* "Major Components"; the kernel in this
>> case is a major component, and is thus only definitively excluded if it
>> implements a "Standard Interface".
> 
> While I disagree, if you're worried about that just don't use grsecurity and 
> you're fine. Oh, and don't use proprietary kernel modules.
> 
Or xfs, or ext4, or mmap, as they all supply things beyond just Standard 
Interfaces as per the licence. And it's not enough to just release source - you 
are required to supply the source to everything you supply under SSPL terms, 
which means that you must have the rights to relicense all source you're 
supplying under the SSPL.

>> This may be an oversight - they may intend to exclude "Major Components" as
>> well as "System Libraries", but it's not what they've written in the
>> licence text. Only an item "which is not part of that Major Component" or
>> which "serves only to enable use of the work with that Major Component, or
>> to implement a Standard Interface" are excluded from the SSPL's reach.
> 
>> But not according to the text of the SSPL; for MongoDB specifically, the FAQ
>> may act as "estoppel", but it's not part of the licence as written; merely
>> providing document storage or retrieval provides "the functionality of the
>> Program … to third parties". If I do that as a service - e.g. pulling out
>> billing records from MongoDB - I'm "mak[ing] the functionality of the
>> Program or a modified version available to third parties as a service", and
>> I'm covered by section 13 and have to distribute all but "System Libraries"
>> as source under the SSPL. This *includes* "Major Components", as section 1
>> 

Re: F30 Self-Contained Change proposal: MongoDB Removal

[John Harris]

On Wednesday, January 30, 2019 8:10:13 PM EST Simon Farnsworth wrote:
> I do if I'm using it to provide a service that could be construed as "making
> the functionality of the Program … available to third parties as a
> service", under section 13 of the SSPL. As MongoDB's functionality includes
> retrieval of documents and document fragments, it's possible to construe
> the licence as covering anything that involves retrieval of a document or
> document fragment from a server (so all web applications, for example).
 
Yeah, that's not what section 13 actually says.

If you make the functionality of the Program or a modified version available 
to third parties as a service, you must make the Service Source Code available 
via network download to everyone at no charge, under the terms of this 
License.

While the license certainly doesn't require anything that uses MongoDB as a 
backing store to be free software, you should definitely make that free 
software under the terms of a license such as the AGPL.

> This may not be what's intended, but it's a reasonable reading of the
> licence as written, and it could get expensive to argue in court that
> covering all document retrieval was not intended.

Perhaps. The easiest option is to just use only free software.
 
> 
> > 
> > 
> >> 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.
> 
> 
> I've read section 1 - Linux implements more than just a "Standard Interface"
> as per that section (it goes beyond POSIX or any interface specified by an
> Official Standards Body, and is not specified for a particular programming
> language). Because of the way section 1 is drafted, "System Libraries" are
> excluded from section 13, but *not* "Major Components"; the kernel in this
> case is a major component, and is thus only definitively excluded if it
> implements a "Standard Interface".

While I disagree, if you're worried about that just don't use grsecurity and 
you're fine. Oh, and don't use proprietary kernel modules.
 
> This may be an oversight - they may intend to exclude "Major Components" as
> well as "System Libraries", but it's not what they've written in the
> licence text. Only an item "which is not part of that Major Component" or
> which "serves only to enable use of the work with that Major Component, or
> to implement a Standard Interface" are excluded from the SSPL's reach.

> But not according to the text of the SSPL; for MongoDB specifically, the FAQ
> may act as "estoppel", but it's not part of the licence as written; merely
> providing document storage or retrieval provides "the functionality of the
> Program … to third parties". If I do that as a service - e.g. pulling out
> billing records from MongoDB - I'm "mak[ing] the functionality of the
> Program or a modified version available to third parties as a service", and
> I'm covered by section 13 and have to distribute all but "System Libraries"
> as source under the SSPL. This *includes* "Major Components", as section 1
> doesn't actually exclude them.

Yes, I think SSPLv2 is going to be coming around soon to address that.
 
> Again, this may not be what they intended, but it's what the text of the
> licence says, and I would rather not rely on having to claim that what they
> wrote is not what they meant in order to succeed in court.
 
Fair enough.

> Given these issues with the drafting of the licence, and the need to rely on
> MongoDB's FAQ to argue that, in the MongoDB case, the FAQ acts as estoppel,
> I can see why Fedora legal would consider the licence non-free. You've made
> claims for it that aren't backed by the actual text of the licence, for
> example.

Sure, but my interpretation of the License is based both on my comprehension 
and on the intent set by the FAQ.

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

[Simon Farnsworth]

Note that I'm not a lawyer of any type - this is a distillation of 
conversations I've had with real lawyers, but you should not take it as legal 
advice. Talk to your own legal people if you need something you can rely on.

> On 30 Jan 2019, at 23:41, 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 if I'm using it to provide a service that could be construed as "making 
the functionality of the Program … available to third parties as a service", 
under section 13 of the SSPL. As MongoDB's functionality includes retrieval of 
documents and document fragments, it's possible to construe the licence as 
covering anything that involves retrieval of a document or document fragment 
from a server (so all web applications, for example).

This may not be what's intended, but it's a reasonable reading of the licence 
as written, and it could get expensive to argue in court that covering all 
document retrieval was not intended.

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

I've read section 1 - Linux implements more than just a "Standard Interface" as 
per that section (it goes beyond POSIX or any interface specified by an 
Official Standards Body, and is not specified for a particular programming 
language). Because of the way section 1 is drafted, "System Libraries" are 
excluded from section 13, but *not* "Major Components"; the kernel in this case 
is a major component, and is thus only definitively excluded if it implements a 
"Standard Interface".

This may be an oversight - they may intend to exclude "Major Components" as 
well as "System Libraries", but it's not what they've written in the licence 
text. Only an item "which is not part of that Major Component" or which "serves 
only to enable use of the work with that Major Component, or to implement a 
Standard Interface" are excluded from the SSPL's reach.

> 
>> 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.
> 
But not according to the text of the SSPL; for MongoDB specifically, the FAQ 
may act as "estoppel", but it's not part of the licence as written; merely 
providing document storage or retrieval provides "the functionality of the 
Program … to third parties". If I do that as a service - e.g. pulling out 
billing records from MongoDB - I'm "mak[ing] the functionality of the Program 
or a modified version available to third parties as a service", and I'm covered 
by section 13 and have to distribute all but "System Libraries" as source under 
the SSPL. This *includes* "Major Components", as section 1 doesn't actually 
exclude them.

Again, this may not be what they intended, but it's what the text of the 
licence says, and I would rather not rely on having to claim that what they 
wrote is not what they meant in order to succeed in court.

Given these issues with the drafting of the licence, and the need to rely on 
MongoDB's FAQ to argue that, in the MongoDB case, the FAQ acts as estoppel, I 
can see why Fedora legal would consider the licence non-free. You've made 
claims for it that aren't backed by the actual text of the licence, for example.
-- 
Simon
___
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

[EPEL-devel] Incoming rebase to Pagure 5.x for EPEL 7 (+ python-celery in EPEL 7 now)

[Neal Gompa]

Hey all,

After the discovery of the lack of python-celery in EPEL 7 when I
first proposed the rebase update for the "pagure" package a few months
ago, I went back to working out how to bring celery into EPEL 7.

I'm pleased to say that a new update has been proposed[1] that updates
"pagure" and includes "python-celery". It awaits testing now.

If you're running an instance of Pagure using the EPEL 7 package,
please backup everything before attempting to follow through the
documentation on upgrading[2]. For clean installations, please consult
the setup documentation[3].

Personally, I would recommend exporting everything out, rebuilding
with the new version, and importing your repositories back in. That is
likely to be less risky, given the substantial delta between 2.x and
5.x.

Going forward, we expect that the "pagure" package will be more
actively maintained, so we will hopefully avoid these problems in the
future.

We're sorry for the inconvenience, but we hope this will be a one-time pain.

[1]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dd9e038712
[2]: https://pagure.io/pagure/blob/master/f/UPGRADING.rst
[3]: https://docs.pagure.org/pagure/install.html

--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: NeuroFedora review swaps

[Ankur Sinha]

Hello,

Here's the next NeuroFedora package that needs review:

- auryn: https://bugzilla.redhat.com/show_bug.cgi?id=1671171

Always happy to swap reviews :)

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
https://fedoraproject.org/wiki/User:Ankursinha

Time zone: Europe/London


signature.asc
Description: PGP 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: F30 Self-Contained Change proposal: MongoDB Removal

[John Harris]

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.

-- 
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: Fixing Wireguard spec file

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

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

Re: exiv2-0.27.0 coming to rawhide

[Rex Dieter]

All builds that I'm aware of have been submitted for rawhide.  I've filed bugs 
to track all known failures, tracked here,
https://bugzilla.redhat.com/show_bug.cgi?id=1665246

Any help to resolve these would be much appreciated.

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

[Jonathan Wakely]

On 30/01/19 21:16 +0100, Dominik 'Rathann' Mierzejewski wrote:

Hi, Jon.

On Wednesday, 30 January 2019 at 13:31, Jonathan Wakely wrote:
[...]

The following packages fail to build because boost::tribool is no
longer impicitly convertible to bool (and so the conversion must be
done explicitly with a cast). I'll try to fix these if I have time:

Maintainers by package:

[...]

mkvtoolnix   itamarjp kwizart mso rathann


Thanks for the build attempt and explanation. There's a new version
available from upstream. I'll check if it fixes things. Until when do
I still need to build into the f30-boost tag?


Hi,

I'll be requesting the side tag be merged and removed in an hour or
two, and then the mass rebuild will happen tomorrow.

So unless you're *very* quick, you'll probably not need to use the
side tag :-)

___
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: Outage 2019-02-02 13:00 UTC -> 15:00 UTC

[Stephen John Smoogen]

On Wed, 30 Jan 2019 at 16:31, Fabio Valentini  wrote:

> On Wed, Jan 30, 2019 at 6:16 PM Stephen John Smoogen 
> wrote:
> >
> >
> > This outage is a replacement of an earlier one in December which had to
> be cancelled.
> >
> >
> > There will be an outage starting at 2019-02-02 13:00 UTC,
> > which will last approximately 2 hours.
>
> The f30 mass rebuild got delayed at least a day and so it might still
> be ongoing at that point in time.
> What would that mean for this outage (or the mass rebuild)?
>
> Fabio
>
>
The outage is only network level so the builds should queue up until the
network returns.

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

Self Introduction

[Samuel P]

Hi Folks. My name is Samuel and I have been a user of Fedora for about 7 years 
now. I am a systems engineer co-maintaining my company's patching 
infrastructure, working closely with carlwgeorge. I use Fedora as my main 
workstation with special interest in both exotic display and audio 
configurations. I've had a lot of enjoyment tinkering with Fedora over the past 
few years using it as my workstation at the office along with the trials that 
come along with maintaining it as new releases become available. I currently 
run Fedora 28 on a few devices and plan on upgrading them to 29 over the next 
few months.

Recently I've been working to get a piece of software known as "fpart" 
integrated into Fedora and eventually EPEL that I'd be looking to use to solve 
some automation tasks I deal with on a semi-regular basis. I can pull down the 
source and build it on my own but I'd prefer to take a cleaner approach of 
creating proper rpms and go through the process of getting them approved and 
released within the distribution itself along with maintaining the package as 
newer releases become available.

At this point I'm looking for sponsorship to move to the next step of getting 
the package integrated; working with carlwgeorge I was able to clean up the 
package to approval status in the following bugzilla:

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

I would be appreciative of any sponsors willing to assist with these endeavors. 
Thanks.

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

[Adam Williamson]

On Wed, 2019-01-30 at 12:36 -0800, Kevin Fenzi wrote:
> On 1/30/19 9:45 AM, Miro Hrončok wrote:
> > On 28. 01. 19 18:27, Ben Cotton wrote:
> > > (Note this change was previously submitted for Fedora 29:
> > > https://pagure.io/fesco/issue/2064)
> > > 
> > > https://fedoraproject.org/wiki/Changes/Retire_YUM_3
> > 
> > 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
> 
> +1, but I would like to see some comment from koji developers that this
> is realistic with their plans or why not.
> 
> > 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
> 
> I don't think we want to use a copr for this, but we could build the
> needed packages in our infra-f30 tag, so they would exist and be usable
> by infra but not in the main repos. Of course we would really like to
> avoid this...

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?
-- 
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: Outage 2019-02-02 13:00 UTC -> 15:00 UTC

[Fabio Valentini]

On Wed, Jan 30, 2019 at 6:16 PM Stephen John Smoogen  wrote:
>
>
> This outage is a replacement of an earlier one in December which had to be 
> cancelled.
>
>
> There will be an outage starting at 2019-02-02 13:00 UTC,
> which will last approximately 2 hours.

The f30 mass rebuild got delayed at least a day and so it might still
be ongoing at that point in time.
What would that mean for this outage (or the mass rebuild)?

Fabio

> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
>
> date -d '2019-02-02 13:00UTC'
>
> Reason for outage:
>
> Various switches at the colocation are needing updates and reboots to get 
> latest firmware working. While the outage should not take the entire 2 hours, 
> it is being blocked out in case there are problems which are not realized and 
> need backing out or other changes.
>
> Affected Services:
>
> dl.fedoraproject.org
> all build services
> most web services
> copr and all other cloud services.
>
> Ticket Link:
>
> https://pagure.io/fedora-infrastructure/issue/7535
>
> Please join #fedora-admin or #fedora-noc on irc.freenode.net
> or add comments to the ticket for this outage above.
>
> --
> 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
___
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

[Simon Farnsworth]

> On 30 Jan 2019, at 17:06, John Harris  wrote:
> 
> On Tuesday, January 29, 2019 10:28:46 PM EST Neal Gompa wrote:
>> On Tue, Jan 29, 2019 at 5:33 PM John Harris  wrote:
>> 
>>> 
>>> 
>>> On Tuesday, January 29, 2019 5:29:58 AM EST Ben Cotton wrote:
>>> 
 Fedora has determined that the Server Side Public Licensev1 (SSPL) is
 not a Free Software License.
>>> 
>>> 
>>> 
>>> For what reason is SSPL considered non-free? As I see, it's essentially a
>>> GPL incompatible AGPL license.
>>> 
>>> 
>> 
>> 
>> It restricts fields of endeavor and how you can use it. That conflicts
>> with freedom 0 of the Free Software Definition. In addition, no one is
>> sure it's actually possible to comply with the SSPL as worded, since
>> it attempts to convert the licensing of everything that's part of the
>> running system, including things not directly linked to it.
> 
> The ability to use proprietary software in combination with free software is 
> not part of Freedom 0.
> 
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.

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.

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.

-- 
Simon
___
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 9:45 AM, Miro Hrončok wrote:
> On 28. 01. 19 18:27, Ben Cotton wrote:
>> (Note this change was previously submitted for Fedora 29:
>> https://pagure.io/fesco/issue/2064)
>>
>> https://fedoraproject.org/wiki/Changes/Retire_YUM_3
> 
> 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

+1, but I would like to see some comment from koji developers that this
is realistic with their plans or why not.

> 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

I don't think we want to use a copr for this, but we could build the
needed packages in our infra-f30 tag, so they would exist and be usable
by infra but not in the main repos. Of course we would really like to
avoid this...

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

[Dominik 'Rathann' Mierzejewski]

Hi, Jon.

On Wednesday, 30 January 2019 at 13:31, Jonathan Wakely wrote:
[...]
> The following packages fail to build because boost::tribool is no
> longer impicitly convertible to bool (and so the conversion must be
> done explicitly with a cast). I'll try to fix these if I have time:
> 
> Maintainers by package:
[...]
> mkvtoolnix   itamarjp kwizart mso rathann

Thanks for the build attempt and explanation. There's a new version
available from upstream. I'll check if it fixes things. Until when do
I still need to build into the f30-boost tag?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: Self Introduction: Gergely Gombos

[Dominik 'Rathann' Mierzejewski]

Welcome to Fedora!

On Wednesday, 30 January 2019 at 17:54, Gergely Gombos wrote:
> Hi Fedora devs,
> 
> My name is Gergely Gombos. I've been using Fedora for about 1.5 years and
> I'm a software developer. I like the FOSS philosophy and using a lot of
> open-source software in the Javascript world, I'd like to make my
> contribution, too.
> 
> I'm looking for a sponsor, and my first RPM package is
> "pulseaudio-module-bluetooth-aptx" and its dependency "libldac".
> 
> The original project  - yet
> to be merged into upstream Pulseaudio - provides awesome audio quality for
> Bluetooth headsets via aptX, AAC and LDAC codecs. This is something that is
> hard to set up even on Windows! And this package works seamlessly on Linux.

That would be awesome. I happen to own a BT headset, so I should be able
to test this. I hope it passes legal review and we can add it to Fedora.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: Organizing a "packager experience" objective and working group

[Kevin Fenzi]

On 1/14/19 12:04 PM, Ben Rosser wrote:
> On Fri, Jan 11, 2019 at 8:11 AM Igor Gnatenko
>  wrote:
>>
>> I'm definitely interested to help (I have 6+ years experience as a packager)!
>>
>> Can we have a topic on discussion.fp.o? I think it is much easier to discuss 
>> such things there.
> 
> Thanks! Also thanks to everyone who's expressed interest in this
> thread so far. :) If no one objects, I'll go through this thread and
> add people's names to the wiki page.
> 
> I wanted to start the discussion here, since most/all packagers are
> subscribed to this mailing list and I wanted to make sure the entire
> group saw it. But I agree it makes sense to move discussions
> elsewhere, either to a separate mailing list, or discussion.fp.o, or
> both. Feel free to start a topic there! I guess this would go under
> the "project conversation" section?
> 
> I was also thinking about creating an IRC channel... does that sound
> like a good idea? (Maybe #fedora-packaging, if it is not in use? Or
> maybe #fedora-packaging-qol or something instead.)

I'd really think this would fall under the #fedora-devel channel.
It's not all that busy and this definitely affects developers.

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: F30 Self-Contained Change proposal: Retire YUM 3

[Miro Hrončok]

On 28. 01. 19 18:27, Ben Cotton wrote:

(Note this change was previously submitted for Fedora 29:
https://pagure.io/fesco/issue/2064)

https://fedoraproject.org/wiki/Changes/Retire_YUM_3


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


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

Outage 2019-02-02 13:00 UTC -> 15:00 UTC

[Stephen John Smoogen]

This outage is a replacement of an earlier one in December which had to be
cancelled.


There will be an outage starting at 2019-02-02 13:00 UTC,
which will last approximately 2 hours.

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

date -d '2019-02-02 13:00UTC'

Reason for outage:

Various switches at the colocation are needing updates and reboots to get
latest firmware working. While the outage should not take the entire 2
hours, it is being blocked out in case there are problems which are not
realized and need backing out or other changes.

Affected Services:

dl.fedoraproject.org
all build services
most web services
copr and all other cloud services.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/7535

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

-- 
Stephen J Smoogen.
___
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: F30 Self-Contained Change proposal: MongoDB Removal

[Stephen John Smoogen]

Fedora does not run RPM Fusion nor have any say of what is in it so any
discussion of doing so would need to be over in their mailing lists etc
versus Fedora.

On Wed, 30 Jan 2019 at 12:16, Richard Shaw  wrote:

> I'm not sure if my previous email made it through and it's not an ideal
> solution but...
>
> What about moving MongoDB and it's dependencies to RPM Fusion?
>
> Thanks,
> Richard
> ___
> 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

[Björn 'besser82' Esser]

Am Mittwoch, den 30.01.2019, 15:50 +0100 schrieb Tomasz Torcz:
>   I saw exactly this on Monday. I submitted a build of owfs package,
> which immediately failed with
>   DEBUG util.py:490:  BUILDSTDERR:   - nothing provides gcc = 8.69
> needed by annobin-8.69-2.fc30.x86_64
> 
>  Strange thing was, annobin-8.69-2.fc30.x86_64 has been built only _2
> hours_
> before my build.  How it got to be in buildroot – it's a mystery…


The buildroot repository for Rawhide is automaticaly generated when a
new / updated package has been successfully built.

The "regular" installation repository for Rawhide is generated on a
daily base with the compose.  If the compose fails for any arbitrary
reason, there will be no regenerated regular repository for Rawhide.

Björn


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

[Richard Shaw]

I'm not sure if my previous email made it through and it's not an ideal
solution but...

What about moving MongoDB and it's dependencies to RPM Fusion?

Thanks,
Richard
___
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

Outage 2019-02-02 13:00 UTC -> 15:00 UTC

[Stephen John Smoogen]

This outage is a replacement of an earlier one in December which had to be
cancelled.


There will be an outage starting at 2019-02-02 13:00 UTC,
which will last approximately 2 hours.

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

date -d '2019-02-02 13:00UTC'

Reason for outage:

Various switches at the colocation are needing updates and reboots to get
latest firmware working. While the outage should not take the entire 2
hours, it is being blocked out in case there are problems which are not
realized and need backing out or other changes.

Affected Services:

dl.fedoraproject.org
all build services
most web services
copr and all other cloud services.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/7535

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

-- 
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 Tuesday, January 29, 2019 10:28:46 PM EST Neal Gompa wrote:
> On Tue, Jan 29, 2019 at 5:33 PM John Harris  wrote:
> 
> >
> >
> > On Tuesday, January 29, 2019 5:29:58 AM EST Ben Cotton wrote:
> > 
> > > Fedora has determined that the Server Side Public Licensev1 (SSPL) is
> > > not a Free Software License.
> >
> >
> >
> > For what reason is SSPL considered non-free? As I see, it's essentially a
> > GPL incompatible AGPL license.
> >
> >
> 
> 
> It restricts fields of endeavor and how you can use it. That conflicts
> with freedom 0 of the Free Software Definition. In addition, no one is
> sure it's actually possible to comply with the SSPL as worded, since
> it attempts to convert the licensing of everything that's part of the
> running system, including things not directly linked to it.

The ability to use proprietary software in combination with free software is 
not part of Freedom 0.

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

Self Introduction: Gergely Gombos

[Gergely Gombos]

Hi Fedora devs,

My name is Gergely Gombos. I've been using Fedora for about 1.5 years 
and I'm a software developer. I like the FOSS philosophy and using a lot 
of open-source software in the Javascript world, I'd like to make my 
contribution, too.


I'm looking for a sponsor, and my first RPM package is 
"pulseaudio-module-bluetooth-aptx" and its dependency "libldac".


The original project  - 
yet to be merged into upstream Pulseaudio - provides awesome audio 
quality for Bluetooth headsets via aptX, AAC and LDAC codecs. This is 
something that is hard to set up even on Windows! And this package works 
seamlessly on Linux.


Originally this was in a COPR repo, with >100 downloads, but it got 
deleted due to legal reasons (ffmpeg build dependency). So I hope it 
will find a new home in RPMFusion since Fedora users are waiting for it.


One of its dependencies is the LDAC library *libldac* which may be 
eligible for the Fedora repos. The library has an Apache v2 license but 
Sony may have patented the algorithm - it requires licensing for 
hardware developers.


I've spent quite a lot of time figuring out how RPM packaging works and 
get this working and (hopefully) conforming to the guidelines - I 
appreciate your review and help.


And of course if this project succeeds, I'm more than happy to take part 
in further packaging projects. :)


The package:

libldac - #1671064 

Thanks!

Best regards,

Greg

___
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: exiv2-0.27.0 coming to rawhide

[Germano Massullo]

Thank you Rex
___
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: exiv2-0.27.0 coming to rawhide

[Rex Dieter]

Sorry for the delay, but took a while to have some time to work on it, so as 
threatened/promised, starting today asap in earnest.

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

[Tom Hughes]

On 30/01/2019 14:50, Tomasz Torcz wrote:


   I saw exactly this on Monday. I submitted a build of owfs package,
which immediately failed with
   DEBUG util.py:490:  BUILDSTDERR:   - nothing provides gcc = 8.69 needed by 
annobin-8.69-2.fc30.x86_64

  Strange thing was, annobin-8.69-2.fc30.x86_64 has been built only _2 hours_
before my build.  How it got to be in buildroot – it's a mystery…


It was a buggy build of annobin made while trying to fix the
dependencies (RHBZ#1607430) and it was fixed a few hours later.

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: Strange rawhide behaviour

[Tomasz Torcz]

On Wed, Jan 30, 2019 at 03:20:31PM +0100, Michal Schorm wrote:
> On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:
> > Not necessarily. Builds are only pushed to repositories after a successful 
> > compose, but are available in koji only a few minutes after they were built.
> > That means that packages built locally or on COPR (which use the rawhide 
> > repository) get "older" versions than the koji builds that have access to 
> > new packages pre-compose.
> 
> All of those packages were built in Koji.
> I wasn't talking about any custom builds. (since custom builds can't
> be added anyhow to Koji, right?)
> 
> That means - it (the icu 63) was in the repository at the build time
> of the community-mysql, but wasn't later at install time.
> Wizardy? Untagged buiid?

  I saw exactly this on Monday. I submitted a build of owfs package,
which immediately failed with
  DEBUG util.py:490:  BUILDSTDERR:   - nothing provides gcc = 8.69 needed by 
annobin-8.69-2.fc30.x86_64

 Strange thing was, annobin-8.69-2.fc30.x86_64 has been built only _2 hours_
before my build.  How it got to be in buildroot – it's a mystery…

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
___
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

[Tom Hughes]

Yes I think it's been about a week since the last rawhide compose
so the mirrors are well out of date.

With the mass rebuild about to start it's probably not going to
get better any time soon either...

Tom

On 30/01/2019 14:37, 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 :)
Thanks
--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Jan 30, 2019 at 3:30 PM Tom Hughes  wrote:


What do you mean by "install time" exactly?

Do you mean you have a system using rawhide from the mirrors
and you are trying to install there?

If so are you installing community-mysql itself from the
mirrors? or have you fetched than from koji to install
manually?

Tom

On 30/01/2019 14:20, Michal Schorm wrote:

On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:

Not necessarily. Builds are only pushed to repositories after a successful 
compose, but are available in koji only a few minutes after they were built.
That means that packages built locally or on COPR (which use the rawhide repository) get 
"older" versions than the koji builds that have access to new packages 
pre-compose.


All of those packages were built in Koji.
I wasn't talking about any custom builds. (since custom builds can't
be added anyhow to Koji, right?)

That means - it (the icu 63) was in the repository at the build time
of the community-mysql, but wasn't later at install time.
Wizardy? Untagged buiid?

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:


On Wed, Jan 30, 2019, 14:56 Michal Schorm 

Hello,

I built "community-mysql" package in version 8.0.14 in rawhide.
It was built on top of "libicu-devel" 63.1-1.fc30

--

1)
But when I tried to install the community-mysql package into Rawhide, I got:
nothing provides libicuio.so.63()(64bit) needed by
community-mysql-server-8.0.14-2.fc30.x86_64

That means, it was available in the buildroot, but not in the repository.
How is that possible? The buildroot also need the exact same
repository to install packages from, right?



Not necessarily. Builds are only pushed to repositories after a successful 
compose, but are available in koji only a few minutes after they were built.

That means that packages built locally or on COPR (which use the rawhide repository) get 
"older" versions than the koji builds that have access to new packages 
pre-compose.



--

2)
When installed the latest icu build, I got:
ackage xfsprogs-4.18.0-1.fc30.x86_64 requires
libicui18n.so.62()(64bit), but none of the providers can be installed

Which means, "community-mysql" was built on top of the newer library
version that its dependencies.
Unfortunate, however that should sooner or later fix itself, thanks to
koschei rebuilding the packages.



Koschei does only koji scratch "test" builds, which aren't submitted to 
repositories at all.


Or at some point, rawhide will
undergo a system wide rebuild. Right?



Yes. Check the fedora 30 schedule - it was planned for today but delayed to 
tomorrow because of a known GCC bug.

Fabio




--

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
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

___
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




--
Tom Hughes (t...@compton.nu)
http://compton.nu/



--
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: Strange rawhide behaviour

[Michal Schorm]

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 :)
Thanks
--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Jan 30, 2019 at 3:30 PM Tom Hughes  wrote:
>
> What do you mean by "install time" exactly?
>
> Do you mean you have a system using rawhide from the mirrors
> and you are trying to install there?
>
> If so are you installing community-mysql itself from the
> mirrors? or have you fetched than from koji to install
> manually?
>
> Tom
>
> On 30/01/2019 14:20, Michal Schorm wrote:
> > On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  
> > wrote:
> >> Not necessarily. Builds are only pushed to repositories after a successful 
> >> compose, but are available in koji only a few minutes after they were 
> >> built.
> >> That means that packages built locally or on COPR (which use the rawhide 
> >> repository) get "older" versions than the koji builds that have access to 
> >> new packages pre-compose.
> >
> > All of those packages were built in Koji.
> > I wasn't talking about any custom builds. (since custom builds can't
> > be added anyhow to Koji, right?)
> >
> > That means - it (the icu 63) was in the repository at the build time
> > of the community-mysql, but wasn't later at install time.
> > Wizardy? Untagged buiid?
> >
> > --
> >
> > Michal Schorm
> > Software Engineer
> > Core Services - Databases Team
> > Red Hat
> >
> > --
> >
> > On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  
> > wrote:
> >>
> >> On Wed, Jan 30, 2019, 14:56 Michal Schorm  >>>
> >>> Hello,
> >>>
> >>> I built "community-mysql" package in version 8.0.14 in rawhide.
> >>> It was built on top of "libicu-devel" 63.1-1.fc30
> >>>
> >>> --
> >>>
> >>> 1)
> >>> But when I tried to install the community-mysql package into Rawhide, I 
> >>> got:
> >>> nothing provides libicuio.so.63()(64bit) needed by
> >>> community-mysql-server-8.0.14-2.fc30.x86_64
> >>>
> >>> That means, it was available in the buildroot, but not in the repository.
> >>> How is that possible? The buildroot also need the exact same
> >>> repository to install packages from, right?
> >>
> >>
> >> Not necessarily. Builds are only pushed to repositories after a successful 
> >> compose, but are available in koji only a few minutes after they were 
> >> built.
> >>
> >> That means that packages built locally or on COPR (which use the rawhide 
> >> repository) get "older" versions than the koji builds that have access to 
> >> new packages pre-compose.
> >>
> >>>
> >>> --
> >>>
> >>> 2)
> >>> When installed the latest icu build, I got:
> >>> ackage xfsprogs-4.18.0-1.fc30.x86_64 requires
> >>> libicui18n.so.62()(64bit), but none of the providers can be installed
> >>>
> >>> Which means, "community-mysql" was built on top of the newer library
> >>> version that its dependencies.
> >>> Unfortunate, however that should sooner or later fix itself, thanks to
> >>> koschei rebuilding the packages.
> >>
> >>
> >> Koschei does only koji scratch "test" builds, which aren't submitted to 
> >> repositories at all.
> >>
> >>> Or at some point, rawhide will
> >>> undergo a system wide rebuild. Right?
> >>
> >>
> >> Yes. Check the fedora 30 schedule - it was planned for today but delayed 
> >> to tomorrow because of a known GCC bug.
> >>
> >> Fabio
> >>
> >>
> >>>
> >>> --
> >>>
> >>> Michal
> >>>
> >>> --
> >>>
> >>> Michal Schorm
> >>> Software Engineer
> >>> Core Services - Databases Team
> >>> 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
> > ___
> > 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
> >
>
>
> --
> 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: Strange rawhide behaviour

[Tom Hughes]

What do you mean by "install time" exactly?

Do you mean you have a system using rawhide from the mirrors
and you are trying to install there?

If so are you installing community-mysql itself from the
mirrors? or have you fetched than from koji to install
manually?

Tom

On 30/01/2019 14:20, Michal Schorm wrote:

On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:

Not necessarily. Builds are only pushed to repositories after a successful 
compose, but are available in koji only a few minutes after they were built.
That means that packages built locally or on COPR (which use the rawhide repository) get 
"older" versions than the koji builds that have access to new packages 
pre-compose.


All of those packages were built in Koji.
I wasn't talking about any custom builds. (since custom builds can't
be added anyhow to Koji, right?)

That means - it (the icu 63) was in the repository at the build time
of the community-mysql, but wasn't later at install time.
Wizardy? Untagged buiid?

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:


On Wed, Jan 30, 2019, 14:56 Michal Schorm 

Hello,

I built "community-mysql" package in version 8.0.14 in rawhide.
It was built on top of "libicu-devel" 63.1-1.fc30

--

1)
But when I tried to install the community-mysql package into Rawhide, I got:
nothing provides libicuio.so.63()(64bit) needed by
community-mysql-server-8.0.14-2.fc30.x86_64

That means, it was available in the buildroot, but not in the repository.
How is that possible? The buildroot also need the exact same
repository to install packages from, right?



Not necessarily. Builds are only pushed to repositories after a successful 
compose, but are available in koji only a few minutes after they were built.

That means that packages built locally or on COPR (which use the rawhide repository) get 
"older" versions than the koji builds that have access to new packages 
pre-compose.



--

2)
When installed the latest icu build, I got:
ackage xfsprogs-4.18.0-1.fc30.x86_64 requires
libicui18n.so.62()(64bit), but none of the providers can be installed

Which means, "community-mysql" was built on top of the newer library
version that its dependencies.
Unfortunate, however that should sooner or later fix itself, thanks to
koschei rebuilding the packages.



Koschei does only koji scratch "test" builds, which aren't submitted to 
repositories at all.


Or at some point, rawhide will
undergo a system wide rebuild. Right?



Yes. Check the fedora 30 schedule - it was planned for today but delayed to 
tomorrow because of a known GCC bug.

Fabio




--

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
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

___
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




--
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: Strange rawhide behaviour

[Florian Weimer]

* Michal Schorm:

> That means, it was available in the buildroot, but not in the repository.
> How is that possible? The buildroot also need the exact same
> repository to install packages from, right?

The default repository for mock and installations is a compose.  It is
regularly recreated from the buildroot, but it can lag behind the
buildroot by basically an arbitrary amount of time.

You can use mock with --enablerepo=local to build in a chroot that has
the actual buildroot active.

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

Re: Strange rawhide behaviour

[Michal Schorm]

On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:
> Not necessarily. Builds are only pushed to repositories after a successful 
> compose, but are available in koji only a few minutes after they were built.
> That means that packages built locally or on COPR (which use the rawhide 
> repository) get "older" versions than the koji builds that have access to new 
> packages pre-compose.

All of those packages were built in Koji.
I wasn't talking about any custom builds. (since custom builds can't
be added anyhow to Koji, right?)

That means - it (the icu 63) was in the repository at the build time
of the community-mysql, but wasn't later at install time.
Wizardy? Untagged buiid?

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:
>
> On Wed, Jan 30, 2019, 14:56 Michal Schorm >
>> Hello,
>>
>> I built "community-mysql" package in version 8.0.14 in rawhide.
>> It was built on top of "libicu-devel" 63.1-1.fc30
>>
>> --
>>
>> 1)
>> But when I tried to install the community-mysql package into Rawhide, I got:
>> nothing provides libicuio.so.63()(64bit) needed by
>> community-mysql-server-8.0.14-2.fc30.x86_64
>>
>> That means, it was available in the buildroot, but not in the repository.
>> How is that possible? The buildroot also need the exact same
>> repository to install packages from, right?
>
>
> Not necessarily. Builds are only pushed to repositories after a successful 
> compose, but are available in koji only a few minutes after they were built.
>
> That means that packages built locally or on COPR (which use the rawhide 
> repository) get "older" versions than the koji builds that have access to new 
> packages pre-compose.
>
>>
>> --
>>
>> 2)
>> When installed the latest icu build, I got:
>> ackage xfsprogs-4.18.0-1.fc30.x86_64 requires
>> libicui18n.so.62()(64bit), but none of the providers can be installed
>>
>> Which means, "community-mysql" was built on top of the newer library
>> version that its dependencies.
>> Unfortunate, however that should sooner or later fix itself, thanks to
>> koschei rebuilding the packages.
>
>
> Koschei does only koji scratch "test" builds, which aren't submitted to 
> repositories at all.
>
>> Or at some point, rawhide will
>> undergo a system wide rebuild. Right?
>
>
> Yes. Check the fedora 30 schedule - it was planned for today but delayed to 
> tomorrow because of a known GCC bug.
>
> Fabio
>
>
>>
>> --
>>
>> Michal
>>
>> --
>>
>> Michal Schorm
>> Software Engineer
>> Core Services - Databases Team
>> 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
___
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

[Joe Doss]

I am actively trying to track down why DKMS is not removing the old WireGuard 
version correctly. I suspect it is something to do with DKMS as other WireGuard 
users that use DKMS for things like ZFS 
(https://utcc.utoronto.ca/~cks/space/blog/linux/MyKernelUpdateSteps) are 
setting the same kinds of issues.

If anyone on this list has any insight on what might be the cause, please let 
me know.

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

[Fabio Valentini]

On Wed, Jan 30, 2019, 14:56 Michal Schorm  Hello,
>
> I built "community-mysql" package in version 8.0.14 in rawhide.
> It was built on top of "libicu-devel" 63.1-1.fc30
>
> --
>
> 1)
> But when I tried to install the community-mysql package into Rawhide, I
> got:
> nothing provides libicuio.so.63()(64bit) needed by
> community-mysql-server-8.0.14-2.fc30.x86_64
>
> That means, it was available in the buildroot, but not in the repository.
> How is that possible? The buildroot also need the exact same
> repository to install packages from, right?
>

Not necessarily. Builds are only pushed to repositories after a successful
compose, but are available in koji only a few minutes after they were built.

That means that packages built locally or on COPR (which use the rawhide
repository) get "older" versions than the koji builds that have access to
new packages pre-compose.


> --
>
> 2)
> When installed the latest icu build, I got:
> ackage xfsprogs-4.18.0-1.fc30.x86_64 requires
> libicui18n.so.62()(64bit), but none of the providers can be installed
>
> Which means, "community-mysql" was built on top of the newer library
> version that its dependencies.
> Unfortunate, however that should sooner or later fix itself, thanks to
> koschei rebuilding the packages.


Koschei does only koji scratch "test" builds, which aren't submitted to
repositories at all.

Or at some point, rawhide will
> undergo a system wide rebuild. Right?


Yes. Check the fedora 30 schedule - it was planned for today but delayed to
tomorrow because of a known GCC bug.

Fabio



> --
>
> Michal
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> 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
>
___
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: [HEADS UP] Removal of ldconfig scriptlets

[Igor Gnatenko]

Tomasz, feel free to send pull requests for rest of packages. ~150
packages is definitely smaller amount than ~1800.

On Wed, Jan 30, 2019 at 2:51 PM Tomasz Kłoczko  wrote:
>
> On Tue, 22 Jan 2019 at 19:07, Igor Gnatenko 
>  wrote:
>>
>> And ldconfig part is done. I'll remove other scriptlets this/next week.
>
>
> [tkloczko@domek SPECS.fedora]$ egrep 
> "^%p.*/sbin/ldconfig|Requres:.*/sbin/ldconfig|^/sbin/ldconfig" * -l | wc -l
> 168
> [tkloczko@domek SPECS.fedora]$ egrep 
> "^%p.*/sbin/ldconfig|Requres:.*/sbin/ldconfig|^/sbin/ldconfig" * -l
> 8sync.spec
> abrt.spec
> alliance.spec
> alsa-plugins.spec
> am-utils.spec
> apt.spec
> armadillo.spec
> ast.spec
> atlas.spec
> bes.spec
> bind.spec
> binutils.spec
> bookkeeper.spec
> bro.spec
> ceph.spec
> condor.spec
> createrepo_c.spec
> dmapd.spec
> dmlite.spec
> dmraid.spec
> dpm-dsi.spec
> dpm-xrootd.spec
> dynafed.spec
> dyninst.spec
> ecryptfs-utils.spec
> edac-utils.spec
> efl.spec
> elfutils.spec
> fann.spec
> flatpak-runtime-config.spec
> flow-tools.spec
> fmt-ptrn.spec
> fstrm.spec
> fts.spec
> fwupdate.spec
> fwupd.spec
> galera.spec
> garmintools.spec
> getdns.spec
> glibc.spec
> glib.spec
> glusterfs.spec
> gmp.spec
> gnome-libs.spec
> grass.spec
> gtkglext.spec
> gtk+.spec
> guile22.spec
> hackrf.spec
> haveged.spec
> heimdal.spec
> hylafax+.spec
> ibus-anthy.spec
> icecream.spec
> iguanaIR.spec
> imlib.spec
> ipmiutil.spec
> iscsi-initiator-utils.spec
> isdn4k-utils.spec
> Judy.spec
> kdepimlibs.spec
> kdesvn.spec
> knot-resolver.spec
> knot.spec
> libcloudproviders.spec
> libcxl.spec
> libdigidocpp.spec
> libdnf.spec
> liberasurecode.spec
> libgcrypt.spec
> libglade.spec
> libhbalinux.spec
> libica.spec
> libiscsi.spec
> libmirage.spec
> libnfc.spec
> libpng10.spec
> librepo.spec
> librtas.spec
> libservicelog.spec
> libstoragemgmt.spec
> libvirt-cim.spec
> libvirt.spec
> libvpd.spec
> libxml.spec
> lldpad.spec
> lldpd.spec
> llvm3.9.spec
> llvm5.0.spec
> llvm6.0.spec
> lockdev.spec
> LogService.spec
> lttng-tools.spec
> lvm2.spec
> mach.spec
> maloc.spec
> mate-desktop.spec
> mate-panel.spec
> mosquitto.spec
> nacl-arm-binutils.spec
> nacl-binutils.spec
> nco.spec
> netcdf-cxx.spec
> netcf.spec
> nfft.spec
> nss-pam-ldapd.spec
> nut.spec
> ogre.spec
> openchange.spec
> openni-primesense.spec
> opensc.spec
> ORBit.spec
> paflib.spec
> palapeli.spec
> pam.spec
> pciutils.spec
> plasma-mediacenter.spec
> portmidi.spec
> postgresql-pgpool-II.spec
> qpid-cpp.spec
> qpid-dispatch.spec
> qt3.spec
> recoll.spec
> remctl.spec
> resource-agents.spec
> root.spec
> rrdtool.spec
> R.spec
> samba.spec
> satyr.spec
> sblim-cmpi-base.spec
> sblim-cmpi-fsvol.spec
> sblim-cmpi-network.spec
> sblim-cmpi-nfsv3.spec
> sblim-cmpi-nfsv4.spec
> sblim-cmpi-rpm.spec
> sblim-cmpi-sysfs.spec
> sblim-cmpi-syslog.spec
> sblim-sfcb.spec
> slim.spec
> snoopy.spec
> speech-dispatcher.spec
> sqliteodbc.spec
> sssd.spec
> stunnel.spec
> swift-lang.spec
> tclx.spec
> tix.spec
> tlog.spec
> tntnet.spec
> tog-pegasus.spec
> tpm2-abrmd.spec
> trafficserver.spec
> trustedqsl.spec
> uim.spec
> unuran.spec
> util-linux.spec
> vala-compat.spec
> varnish.spec
> vrpn.spec
> vzctl.spec
> xerces-c27.spec
> xfce4-statusnotifier-plugin.spec
> xorg-x11-drv-openchrome.spec
> yaz.spec
> zita-resampler.spec
> zookeeper.spec
> zvbi.spec
>
> If you are doing now mass cleanups you can clean as well below:
>
> [tkloczko@domek SPECS.fedora]$ grep ^%clean *
> davix.spec:%clean
> docbook-simple.spec:%clean
> dtach.spec:%clean
> dynafed.spec:%clean
> gcl.spec:%clean
> gfal2-python.spec:%clean
> gfal2.spec:%clean
> gfal2-util.spec:%clean
> gfalFS.spec:%clean
> imvirt.spec:%clean
> initial-setup.spec:%clean
> libdirq.spec:%clean
> perl-Test-Signature.spec:%clean
> pvs-sbcl.spec:%clean
> python-nss.spec:%clean
> sparse.spec:%clean
>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> ___
> 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: [HEADS UP] Removal of ldconfig scriptlets

[Igor Gnatenko]

I'm definitely not touching glibc ;)

The rest is minority and probably shouldn't be touched (esp. LLVM). I
can take a look after mass rebuild.

On Wed, Jan 30, 2019 at 2:56 PM Florian Weimer  wrote:
>
> * Tomasz Kłoczko:
>
> > glibc.spec
>
> Please do not change glibc.
>
> 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
___
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

Strange rawhide behaviour

[Michal Schorm]

Hello,

I built "community-mysql" package in version 8.0.14 in rawhide.
It was built on top of "libicu-devel" 63.1-1.fc30

--

1)
But when I tried to install the community-mysql package into Rawhide, I got:
nothing provides libicuio.so.63()(64bit) needed by
community-mysql-server-8.0.14-2.fc30.x86_64

That means, it was available in the buildroot, but not in the repository.
How is that possible? The buildroot also need the exact same
repository to install packages from, right?

--

2)
When installed the latest icu build, I got:
ackage xfsprogs-4.18.0-1.fc30.x86_64 requires
libicui18n.so.62()(64bit), but none of the providers can be installed

Which means, "community-mysql" was built on top of the newer library
version that its dependencies.
Unfortunate, however that should sooner or later fix itself, thanks to
koschei rebuilding the packages. Or at some point, rawhide will
undergo a system wide rebuild. Right?

--

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
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: [HEADS UP] Removal of ldconfig scriptlets

[Florian Weimer]

* Tomasz Kłoczko:

> glibc.spec

Please do not change glibc.

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

Re: [HEADS UP] Removal of ldconfig scriptlets

[Tomasz Kłoczko]

On Tue, 22 Jan 2019 at 19:07, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> And ldconfig part is done. I'll remove other scriptlets this/next week.
>

[tkloczko@domek SPECS.fedora]$ egrep
"^%p.*/sbin/ldconfig|Requres:.*/sbin/ldconfig|^/sbin/ldconfig" * -l | wc -l
168
[tkloczko@domek SPECS.fedora]$ egrep
"^%p.*/sbin/ldconfig|Requres:.*/sbin/ldconfig|^/sbin/ldconfig" * -l
8sync.spec
abrt.spec
alliance.spec
alsa-plugins.spec
am-utils.spec
apt.spec
armadillo.spec
ast.spec
atlas.spec
bes.spec
bind.spec
binutils.spec
bookkeeper.spec
bro.spec
ceph.spec
condor.spec
createrepo_c.spec
dmapd.spec
dmlite.spec
dmraid.spec
dpm-dsi.spec
dpm-xrootd.spec
dynafed.spec
dyninst.spec
ecryptfs-utils.spec
edac-utils.spec
efl.spec
elfutils.spec
fann.spec
flatpak-runtime-config.spec
flow-tools.spec
fmt-ptrn.spec
fstrm.spec
fts.spec
fwupdate.spec
fwupd.spec
galera.spec
garmintools.spec
getdns.spec
glibc.spec
glib.spec
glusterfs.spec
gmp.spec
gnome-libs.spec
grass.spec
gtkglext.spec
gtk+.spec
guile22.spec
hackrf.spec
haveged.spec
heimdal.spec
hylafax+.spec
ibus-anthy.spec
icecream.spec
iguanaIR.spec
imlib.spec
ipmiutil.spec
iscsi-initiator-utils.spec
isdn4k-utils.spec
Judy.spec
kdepimlibs.spec
kdesvn.spec
knot-resolver.spec
knot.spec
libcloudproviders.spec
libcxl.spec
libdigidocpp.spec
libdnf.spec
liberasurecode.spec
libgcrypt.spec
libglade.spec
libhbalinux.spec
libica.spec
libiscsi.spec
libmirage.spec
libnfc.spec
libpng10.spec
librepo.spec
librtas.spec
libservicelog.spec
libstoragemgmt.spec
libvirt-cim.spec
libvirt.spec
libvpd.spec
libxml.spec
lldpad.spec
lldpd.spec
llvm3.9.spec
llvm5.0.spec
llvm6.0.spec
lockdev.spec
LogService.spec
lttng-tools.spec
lvm2.spec
mach.spec
maloc.spec
mate-desktop.spec
mate-panel.spec
mosquitto.spec
nacl-arm-binutils.spec
nacl-binutils.spec
nco.spec
netcdf-cxx.spec
netcf.spec
nfft.spec
nss-pam-ldapd.spec
nut.spec
ogre.spec
openchange.spec
openni-primesense.spec
opensc.spec
ORBit.spec
paflib.spec
palapeli.spec
pam.spec
pciutils.spec
plasma-mediacenter.spec
portmidi.spec
postgresql-pgpool-II.spec
qpid-cpp.spec
qpid-dispatch.spec
qt3.spec
recoll.spec
remctl.spec
resource-agents.spec
root.spec
rrdtool.spec
R.spec
samba.spec
satyr.spec
sblim-cmpi-base.spec
sblim-cmpi-fsvol.spec
sblim-cmpi-network.spec
sblim-cmpi-nfsv3.spec
sblim-cmpi-nfsv4.spec
sblim-cmpi-rpm.spec
sblim-cmpi-sysfs.spec
sblim-cmpi-syslog.spec
sblim-sfcb.spec
slim.spec
snoopy.spec
speech-dispatcher.spec
sqliteodbc.spec
sssd.spec
stunnel.spec
swift-lang.spec
tclx.spec
tix.spec
tlog.spec
tntnet.spec
tog-pegasus.spec
tpm2-abrmd.spec
trafficserver.spec
trustedqsl.spec
uim.spec
unuran.spec
util-linux.spec
vala-compat.spec
varnish.spec
vrpn.spec
vzctl.spec
xerces-c27.spec
xfce4-statusnotifier-plugin.spec
xorg-x11-drv-openchrome.spec
yaz.spec
zita-resampler.spec
zookeeper.spec
zvbi.spec

If you are doing now mass cleanups you can clean as well below:

[tkloczko@domek SPECS.fedora]$ grep ^%clean *
davix.spec:%clean
docbook-simple.spec:%clean
dtach.spec:%clean
dynafed.spec:%clean
gcl.spec:%clean
gfal2-python.spec:%clean
gfal2.spec:%clean
gfal2-util.spec:%clean
gfalFS.spec:%clean
imvirt.spec:%clean
initial-setup.spec:%clean
libdirq.spec:%clean
perl-Test-Signature.spec:%clean
pvs-sbcl.spec:%clean
python-nss.spec:%clean
sparse.spec:%clean

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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

[Nico Kadel-Garcia]

On Tue, Jan 29, 2019 at 10:31 PM Neal Gompa  wrote:
>
> On Tue, Jan 29, 2019 at 5:33 PM John Harris  wrote:
> >
> > On Tuesday, January 29, 2019 5:29:58 AM EST Ben Cotton wrote:
> > > Fedora has determined that the Server Side Public Licensev1 (SSPL) is
> > > not a Free Software License.
> >
> > For what reason is SSPL considered non-free? As I see, it's essentially a 
> > GPL
> > incompatible AGPL license.
> >
>
> It restricts fields of endeavor and how you can use it. That conflicts
> with freedom 0 of the Free Software Definition. In addition, no one is
> sure it's actually possible to comply with the SSPL as worded, since
> it attempts to convert the licensing of everything that's part of the
> running system, including things not directly linked to it.

Ahh. Thank you for the clarification. Licenses are much like power
adapters, modular software installation tools. Everyone wants to
invent their own, many have similar fundamental flaws, none are
completely compatible, and we wind up with something like this from
XKCD.

https://xkcd.com/1406/
___
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

[Fabio Valentini]

On Wed, Jan 30, 2019, 13:56 Peter Robinson  On Wed, Jan 30, 2019 at 9:41 AM Florian Weimer  wrote:
> >
> > * Miro Hrončok:
> >
> > > On 29. 01. 19 19:04, John Harris wrote:
> > >> On Monday, January 28, 2019 12:27:19 PM EST Ben Cotton wrote:
> > >>> Remove packages from the distribution:
> > >>> * createrepo
> > >>> * yum
> > >>> * yum-langpacks
> > >>> * yum-utils
> > >>> * yum-metadata-parser
> > >>> * yum-updatesd
> > >>> * python-urlgrabber
> > >>
> > >> Are there already `dnf` equivalents to `createrepo` and `yum-utils`?
> > >
> > > AFAIK createrepo_c for createrepo and dnf itself for yum-utils.
> >
> > Part of the yum-utils functionality landed in dnf-plugins-core,
> > e.g. “debuginfo-install” turned into “dnf debuginfo-install”, and the
> > latter needs dnf-plugins-core.
>
> There's still some missing pieces there, like package-cleanup, which
> in theory the dnf devs once said in reality you should never need but
> in practice I find I still regularly need to install it.
>

dnf-utils provides package-cleanup.

Fabio


> Peter
> ___
> 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: F30 Self-Contained Change proposal: Retire YUM 3

[Vít Ondruch]

Dne 30. 01. 19 v 13:10 Matthew Miller napsal(a):
> 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.
>

I don't dispute anything of this.

But I have always said, and it is exhibited by these cases, that we
should judge the importance of the changes and their impact by the
feedback on ML and not by anything else. If you want to make the change
proposal process less bureaucratic, removing the SC vs SW distinction
would be nice start.

It should work like this:


1) I propose some change I am working on. I should provide some basic
information.

2) The proposal is published on devel{,-announce} and feedback is solicited.

3a) If there is positive feedback, just some clarifications or no
feedback at all, change is automatically accepted.

3b) When the feedback is that this might involve other parties, then
additional information, which ensures all involved parties are informed
and collaborating, should be provided (unless the information is
provided already). FESCo approval might be needed if there is no consensus.


Honestly, if I were in Michal's position, I would be thinking next time
if I should propose the change at all, because if he did it without any
approval, we would live with it anyway. But I hope we don't want to go
in this direction.


Vít

___
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

[Peter Robinson]

On Wed, Jan 30, 2019 at 9:41 AM Florian Weimer  wrote:
>
> * Miro Hrončok:
>
> > On 29. 01. 19 19:04, John Harris wrote:
> >> On Monday, January 28, 2019 12:27:19 PM EST Ben Cotton wrote:
> >>> Remove packages from the distribution:
> >>> * createrepo
> >>> * yum
> >>> * yum-langpacks
> >>> * yum-utils
> >>> * yum-metadata-parser
> >>> * yum-updatesd
> >>> * python-urlgrabber
> >>
> >> Are there already `dnf` equivalents to `createrepo` and `yum-utils`?
> >
> > AFAIK createrepo_c for createrepo and dnf itself for yum-utils.
>
> Part of the yum-utils functionality landed in dnf-plugins-core,
> e.g. “debuginfo-install” turned into “dnf debuginfo-install”, and the
> latter needs dnf-plugins-core.

There's still some missing pieces there, like package-cleanup, which
in theory the dnf devs once said in reality you should never need but
in practice I find I still regularly need to install it.

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

[Miro Hrončok]

On 30. 01. 19 13:31, Jonathan Wakely wrote:

On 25/01/19 15:57 +, 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.


I'm nearly done with the Boost rebuilds.

Several packages have been patched so they link to the new names for
the Boost.Python libs. -lboost_python becomes -lboost_python27 and
-lboost_python3 becomes -lboost_python37. I'm still fixing some
occurrences of that.

Several packages build OK on all targets except armv7hl, where they
get unit test failures. Those should get fixed by the new gcc landing
in the buildroot soon (and I probably won't rebuild them, but will let
the mass rebuild handle them).

> ...

The following packages fail to build because boost::tribool is no
longer impicitly convertible to bool (and so the conversion must be
done explicitly with a cast). I'll try to fix these if I have time:

Maintainers by package:
openscad churchyard


This has been fixed upstream. If you are going to work on it, see:

https://github.com/openscad/openscad/issues/2529

I will eventually get to it, so you don't have to do that.

--
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: F30 Self-Contained Change proposal: Retire YUM 3

[Stephen John Smoogen]

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.

People have been complaining about how process-heavy and bureaucratic
Fedora is since we called it fedora.us. I just don't have any patience  for
it any more because many of the people who complain regularly and loudly...
also complain about every other time someone skips the processes and breaks
their stuff. We just need to face that an open distribution with multiple
developers that releases continually requires some sort of detailed
process and bureaucracy to keep things flowing. The more developers and the
more  packages, the larger the combinatorics that the processes are needed
to keep things oiled.


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

[Adam Williamson]

On Tue, 2019-01-29 at 14:31 -0500, Stephen John Smoogen wrote:
> On Tue, 29 Jan 2019 at 05:42, Matthew Miller 
> wrote:
> 
> > On Mon, Jan 28, 2019 at 06:41:26PM +0100, Miro Hrončok wrote:
> > > > This feels more like system-wide change…
> > > > Especially since you say that some extra packages will be retired.
> > > 
> > > A very limited set. The distro as a whole should not be impacted by this.
> > > 
> > > The retired packages are legacy cruft. And the important stuff that
> > > needs to be updated needs some motivation like this.
> > 
> > "This change needs to motivate other important stuff that we don't have
> > direct control over to change" seems like *exactly* the reason we ask for
> > system-wide changes to be filed earlier.
> > 
> > 
> > 
> This is like the 4th system wide change this release which is coming in as
> a Self-Contained. Each time the developer thinks it is self-contained
> because it is just one  little thing, but on regards it turns into being a
> system-wide change. However because the two deadlines are one after the
> other, it means that this change is pushed out another 6 months where the
> 3-4 weeks between System-Wide and Self-Contained doesn't seem very long.
> Can we either:

I feel like this is a bit of a side track, when the fundamental point
here should be: "the week of the mass rebuild" seems rather late to
propose "hey let's try retiring yum again and see what breaks this time
and if we can get it fixed". I would've been all in favour of doing
that, say, a month ago. I'm less in favour of doing it now when we're
down to less than three weeks to branching. I do take the argument
relating to Python 2 deprecation...but that was known about long ago.
-- 
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: Boost 1.69 update with soname bumps in rawhide/F30

[Jonathan Wakely]

On 25/01/19 15:57 +, 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.


I'm nearly done with the Boost rebuilds.

Several packages have been patched so they link to the new names for
the Boost.Python libs. -lboost_python becomes -lboost_python27 and
-lboost_python3 becomes -lboost_python37. I'm still fixing some
occurrences of that.

Several packages build OK on all targets except armv7hl, where they
get unit test failures. Those should get fixed by the new gcc landing
in the buildroot soon (and I probably won't rebuild them, but will let
the mass rebuild handle them).

The following packages use Boost.Signals which is been REMOVED from
Boost. The packages must be updated to use Boost.Signals2 (or bundle
an old Boost).

Maintainers by package:
ekigamcrha pbrobinson
freecad  hobbes1069 jkastner zultron
gazebo   rmattes
pingus   limb
spring   gilboa rmattes
swiftjkaluza

Packages by maintainer:
gilboa spring
hobbes1069 freecad
jkaluzaswift
jkastner   freecad
limb   pingus
mcrha  ekiga
pbrobinson ekiga
rmattesgazebo spring
zultronfreecad


The following packages fail to build because of -Werror. Your package
is bad and you should feel bad:

Maintainers by package:
colobot  suve
gnucash  notting
mstflint dledford honli jirka jstanley michich
qpid-cpp irina nsantos

Packages by maintainer:
dledford   mstflint
honli  mstflint
irina  qpid-cpp
jirka  mstflint
jstanley   mstflint
michichmstflint
nottinggnucash
nsantosqpid-cpp
suve   colobot


The following packages fail to build because boost::tribool is no
longer impicitly convertible to bool (and so the conversion must be
done explicitly with a cast). I'll try to fix these if I have time:

Maintainers by package:
dyninst  fche jistone lberk orion scox wcohen
fts  andreamanzi simonm
mkvtoolnix   itamarjp kwizart mso rathann
openscad churchyard
wesnoth  bruno limb pwalter

Packages by maintainer:
andreamanzi fts
bruno  wesnoth
churchyard openscad
fche   dyninst
itamarjp   mkvtoolnix
jistonedyninst
kwizartmkvtoolnix
lberk  dyninst
limb   wesnoth
msomkvtoolnix
orion  dyninst
pwalterwesnoth
rathannmkvtoolnix
scox   dyninst
simonm fts
wcohen dyninst


___
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

[Matthew Miller]

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.

-- 
Matthew Miller

Fedora Project Leader
___
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]

* John Harris:

> On Tuesday, January 29, 2019 5:29:58 AM EST Ben Cotton wrote:
>> Fedora has determined that the Server Side Public Licensev1 (SSPL) is
>> not a Free Software License.
>
> For what reason is SSPL considered non-free? As I see, it's
> essentially a GPL incompatible AGPL license.

For a start, it's unclear what “service” means.  Fedora provides
precompiled binaries and community support.  Does this “make the
functionality of the Program […] available to third parties as a
service”?  Who knows.  The FAQ only says that “users” (and not
distributions) are allowed to redistribute the software, and it does not
really talk about pre-built binaries.

(Fedora relies on a volunteer mirror network, so we can't publish all
the source code for the package download service even if we wanted to.)

It's true that one person employed by the company said that they do not
mean “service” as in “goods in services” in section 13, but we don't
know if that reflects a company position, and what the exact distinction
between pre-built software and software-as-a-service is.  Things like
OpenShift Operators blurry the line considerably.

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

Re: Sync deadlines for self contained and system wide changes

[Ben Cotton]

On Wed, Jan 30, 2019 at 5:50 AM Miro Hrončok  wrote:
>
> On 29. 01. 19 20:31, Stephen John Smoogen 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?
> > 2) Move Self-Contained deadline BEFORE System-Wide so that  if it is really
> > System-Wide move it to the correct category?
> > 3) Add a re-evaluate deadline after the first two? This allows us to get an 
> > idea
> > that "oh wait this is going to really mess things up and we need to push 
> > this
> > out one release?" or other items
>
> I'm starting a new thread about this so it is not buried in the YUM3 removal 
> thread.
>
> I don't think 2 brings us any benefit over 1.
>
> I understand the need of soon deadline for changes needing the mass rebuild.
> However I guess changes not needing it might share a deadline, so we are able 
> to
> "upgrade" a Self Contained change proposal to System Wide without postponing 
> to
> the next Fedora release.
>
> Before we do any changes, what is the actual reasoning for two deadlines?
> Is it the assumption that System Wide changes need more time? That is not 
> always
> correct.
>
I think it's more that Self-Contained Changes should have no
downstream impact, so we can give them a little more time to come in.
System-Wide Changes could potentially impact the mass rebuild, etc, so
they need to come in a little earlier. Arguably, it should be a week
or two sooner than it is now since a Change that requires a mass
rebuild that is submitted the day of the deadline doesn't have a lot
of time to get approved and implemented.

On Wed, Jan 30, 2019 at 5:51 AM Vít Ondruch  wrote:
>
> This split between SW and SC was artificial since the beginning and I'd be 
> happy if we dropped it.
>
It's a meaningful distinction because it changes the level of rigor
that we require. Adding a leaf package and changing the compiler
version should not be treated the same. That was one of the problems
with the old Features process.

I have no objections to unifying the proposal deadlines to the current
System-Wide proposal deadline. It means there's a shorter window for
Self-Contained Change proposals to be submitted, but I don't know if
that's particularly meaningful, especially since some proposals being
labeled as Self-Contained should really be System-Wide. That benefit
may outweigh the downside of the shorter window.

It's clear, though, that the guidance for how to distinguish the
Change types needs improving. I will work on that as I start migrating
content out of the wiki and into docs.fp.o.

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

Vagrant 2.2 with QEMU Session

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Vagrant_2.2_with_QEMU_Session

== Summary ==
Upgrade to Vagrant 2.2, the latest stable version of Vagrant. Enable
QEMU Session by default.

== Owner ==
* Name: [[User:pvalena | Pavel Valena]], [[User:vondruch | Vit Ondruch]]
* Email: pval...@redhat.com, vondr...@redhat.com
* Release notes owner:

== Detailed Description ==
Vagrant 2.2 is new upstream's major release, that includes many
features, improvements, and and bug fixes.
Using '''qemu:///session''' instead of '''qemu:///system''' Vagrant
will run unprivileged.

== Benefit to Fedora ==

* Enable QEMU Session by default. With this, there's no need for user
to input any password, or be present in some group. Everyone is able
to use Vagrant, regardless of group or other ACLs.
* Add host support for void linux
* Add support for VirtualBox 6.0
* Add command for uploading files to guest

== Scope ==
* Proposal owners:
** Finish packaging Vagrant 2.2. Current changes:
https://src.fedoraproject.org/rpms/vagrant/pull-request/17
** Finish packaging Vagrant-Libvirt plugin. Current changes:
https://src.fedoraproject.org/rpms/vagrant-libvirt/pull-request/3
** Work has been done in a Copr repository:
https://copr.fedorainfracloud.org/coprs/pvalena/vagrant/
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #8085]
** 
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Because of QEMU Session enabled by defailt, a failure occurs with if
Vagrantfile contains:
```
test_vm.vm.network :private_network, :ip => "172.16.0.2"
```
or similar.
Can be solved by setting `libvirt.qemu_use_session = false` in Vagrantfile.

== How To Test ==
* No special hardware is needed.
* Install Vagrant
* Run ```vagrant version```
* Use your Vagrantfiles or create new as before
* If something doesn't work as it should, let us know.

== User Experience ==
New features that come with Vagrant 2.2 will be available.
Users will not need to add themseles to any group, or have root ACLs
and input a password every time they use Vagrant.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)

== Documentation ==
https://www.vagrantup.com/docs/

== Release Notes ==
https://github.com/hashicorp/vagrant/blob/master/CHANGELOG.md

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
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: Vagrant 2.2 with QEMU Session

[Miro Hrončok]

On 30. 01. 19 11:45, Vít Ondruch wrote:


Dne 30. 01. 19 v 11:40 Miro Hrončok napsal(a):

On 30. 01. 19 11:21, Matthew Miller wrote:

On Wed, Jan 30, 2019 at 04:36:59AM -0500, Ben Cotton wrote:

* Add support for VirtualBox 6.0


Does this affect us? How?


Affects users with VirtualBox 6 installed from 3rd party repos.



Vagrant in Fedora defaults to Libvirt. But VirtualBox support is quite
often on the table. Presumably there is more boxes available for
VirtualBox, because its support of Windows host? Just guessing.


IMHO there are more boxes available for VirtualBox because AFAIK upstream 
defaults to it.


As for OS support, I use it for macOS.

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

Sync deadlines for self contained and system wide changes

[Miro Hrončok]

On 29. 01. 19 20:31, Stephen John Smoogen wrote:
This is like the 4th system wide change this release which is coming in as a 
Self-Contained. Each time the developer thinks it is self-contained because it 
is just one  little thing, but on regards it turns into being a system-wide 
change. However because the two deadlines are one after the other, it means that 
this change is pushed out another 6 months where the 3-4 weeks between 
System-Wide and Self-Contained doesn't seem very long. Can we either:


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?
2) Move Self-Contained deadline BEFORE System-Wide so that  if it is really  
System-Wide move it to the correct category?
3) Add a re-evaluate deadline after the first two? This allows us to get an idea 
that "oh wait this is going to really mess things up and we need to push this 
out one release?" or other items


I'm starting a new thread about this so it is not buried in the YUM3 removal 
thread.

I don't think 2 brings us any benefit over 1.

I understand the need of soon deadline for changes needing the mass rebuild.
However I guess changes not needing it might share a deadline, so we are able to 
"upgrade" a Self Contained change proposal to System Wide without postponing to 
the next Fedora release.


Before we do any changes, what is the actual reasoning for two deadlines?
Is it the assumption that System Wide changes need more time? That is not always 
correct.


--
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: F30 Self-Contained Change proposal: Retire YUM 3

[Vít Ondruch]

Dne 29. 01. 19 v 20:31 Stephen John Smoogen napsal(a):
>
>
> On Tue, 29 Jan 2019 at 05:42, Matthew Miller  > wrote:
>
> On Mon, Jan 28, 2019 at 06:41:26PM +0100, Miro Hrončok wrote:
> > >This feels more like system-wide change…
> > >Especially since you say that some extra packages will be retired.
> >
> > A very limited set. The distro as a whole should not be impacted
> by this.
> >
> > The retired packages are legacy cruft. And the important stuff that
> > needs to be updated needs some motivation like this.
>
> "This change needs to motivate other important stuff that we don't
> have
> direct control over to change" seems like *exactly* the reason we
> ask for
> system-wide changes to be filed earlier.
>
>
>
> This is like the 4th system wide change this release which is coming
> in as a Self-Contained. Each time the developer thinks it is
> self-contained because it is just one  little thing, but on regards it
> turns into being a system-wide change. However because the two
> deadlines are one after the other, it means that this change is pushed
> out another 6 months where the 3-4 weeks between System-Wide and
> Self-Contained doesn't seem very long. Can we either:
>
> 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.

If we keep this division, I am for one deadline for both.


Vít


> 2) Move Self-Contained deadline BEFORE System-Wide so that  if it is
> really  System-Wide move it to the correct category?
> 3) Add a re-evaluate deadline after the first two? This allows us to
> get an idea that "oh wait this is going to really mess things up and
> we need to push this out one release?" or other items
>
> At the moment, I think pushing out removal of yum3 for Fedora31
> doesn't make sense if there isn't enough python2 for it to be useful
> in Fedora30. However I also think this is a system-wide change because
> a lot of tools need time to test that they REALLY do support not
> having yum3 in them. 
>
>
> -- 
> 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
___
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: Vagrant 2.2 with QEMU Session

[Vít Ondruch]

Dne 30. 01. 19 v 11:40 Miro Hrončok napsal(a):
> On 30. 01. 19 11:21, Matthew Miller wrote:
>> On Wed, Jan 30, 2019 at 04:36:59AM -0500, Ben Cotton wrote:
>>> * Enable QEMU Session by default. With this, there's no need for user
>>> to input any password, or be present in some group. Everyone is able
>>> to use Vagrant, regardless of group or other ACLs.
>>
>> This seems amazing.
>>
>>> * Add support for VirtualBox 6.0
>>
>> Does this affect us? How?
>
> Affects users with VirtualBox 6 installed from 3rd party repos.
>

Vagrant in Fedora defaults to Libvirt. But VirtualBox support is quite
often on the table. Presumably there is more boxes available for
VirtualBox, because its support of Windows host? Just guessing.


Vít
___
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: Vagrant 2.2 with QEMU Session

[Miro Hrončok]

On 30. 01. 19 11:21, Matthew Miller wrote:

On Wed, Jan 30, 2019 at 04:36:59AM -0500, Ben Cotton wrote:

* Enable QEMU Session by default. With this, there's no need for user
to input any password, or be present in some group. Everyone is able
to use Vagrant, regardless of group or other ACLs.


This seems amazing.


* Add support for VirtualBox 6.0


Does this affect us? How?


Affects users with VirtualBox 6 installed from 3rd party repos.

--
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: F30 Self-Contained Change proposal: Bash 5.0

[Matthew Miller]

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?

-- 
Matthew Miller

Fedora Project Leader
___
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

[Matthew Miller]

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?

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

-- 
Matthew Miller

Fedora Project Leader
___
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

[Code complete, needs testing] Re: F30 Self-Contained Change proposal: libcrypt.so.1 (compatibility library for POSIX): Let encrypt, encrypt_r, setkey, setkey_r, and fcrypt return ENOSYS instead of pe

[Björn 'besser82' Esser]

The change [1] has been successfully implemented and is code complete,
pending QA / testing.


You will need to have libxcrypt-compat >= 4.4.3-3.fc30 and some prebuilt
binary linking at least one of these functions installed for testing
this:

  * encrypt{,_r}
  * setkey{,_r}
  * fcrypt


Please test this change and report problems / bugs related to this
change on Bugzilla against the libxcrypt package of the Fedora
component.  Your bug should also block rhbz# 1670735, so I can track
everything much easier in one place.

Björn aka besser82


[1]  
https://fedoraproject.org/wiki/Changes/libcrypt_so_1_Let_encrypt_encrypt_r_setkey_setkey_r_and_fcrypt_return_ENOSYS_instead_of_performing_any_real_operation


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: Vagrant 2.2 with QEMU Session

[Matthew Miller]

On Wed, Jan 30, 2019 at 04:36:59AM -0500, Ben Cotton wrote:
> * Enable QEMU Session by default. With this, there's no need for user
> to input any password, or be present in some group. Everyone is able
> to use Vagrant, regardless of group or other ACLs.

This seems amazing.

> * Add support for VirtualBox 6.0

Does this affect us? How?

-- 
Matthew Miller

Fedora Project Leader
___
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

[Vít Ondruch]

Dne 29. 01. 19 v 16:22 Florian Weimer napsal(a):
> * Honza Horak:
>
>>> Yes, right. There is rubygem-mongo and rubygem-mongoid and they will
>>> become FTBFS without MongoDB. The test suite could be disabled, but this
>>> will be unfortunate, because historically it helped to uncover issues on
>>> some of our arches.
>> While I see the value of tests, I personally don't consider just the
>> testing purposes to be a good enough reason to keep unmaintained
>> mongodb-server in Fedora, and don't see any other option here.


My main point was that this should be coordinated and the test suite
should be at least disable to prevent FTBFS.


> Maybe we could keep it as a buildroot-only package (similar to glibc32)
> and filter it from the composes?


But this would be much better option.


Vít


>
> On the other hand, it would set a bad precedent.
>
> 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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Adam Williamson]

On Wed, 2019-01-30 at 10:32 +0100, Adam Williamson wrote:
> 
> and the results show up in Bodhi (albeit under the heading
> 'undefined', which is a bug we should fix):

> https://bodhi.fedoraproject.org/updates/FEDORA-2019-9d006f6254 (see
> Automated Tests tab)

https://github.com/fedora-infra/bodhi/pull/2969
-- 
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: Bash 5.0

[Siteshwar Vashisht]

- Original Message -
> From: "Adam Williamson" 
> To: "Development discussions related to Fedora" 
> , "Neal Gompa" 
> Cc: "Stef Walter" , svashi...@redhat.com
> Sent: Wednesday, January 30, 2019 10:32:32 AM
> Subject: Re: F30 Self-Contained Change proposal: Bash 5.0
> 
> So for the record, I looked into this a bit further, and in fact it has
> already been done. There are tests in bash dist-git:
> 
> https://src.fedoraproject.org/rpms/bash/blob/master/f/tests
> 
> and they are actually being run by the pipeline:
> 
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f29-build-pipeline/detail/fedora-f29-build-pipeline/282/pipeline
> 
> and the results show up in Bodhi (albeit under the heading
> 'undefined', which is a bug we should fix):
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-9d006f6254 (see
> Automated Tests tab)
> 
> which means Greenwave knows about them, because Bodhi now uses
> Greenwave as its source of result data (so anything that shows up in
> Bodhi is definitely in Greenwave).
> 
> I don't know if the tests that have been imported into dist-git are
> *all* of RH's internal tests - Sitesh might know. But certainly some or
> all of them have been upstreamed, and are properly set up such that
> they will run on any builds done in Fedora and will be available for
> the Rawhide gating stuff once that's fully implemented.

Currently there are just 3 tests that have been upstreamed from our internal 
repos[1].

I wanted to get all of them upstreamed in fedora, but it can't be done due to 
other priorities.


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

[1] https://src.fedoraproject.org/tests/shell/tree/master

-- 
--
Siteshwar Vashisht
___
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: Vagrant 2.2 with QEMU Session

[Ben Cotton]

To be clear, this is a F30 Self-Contained Change proposal. /me drinks
more coffee

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

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

[Florian Weimer]

* Miro Hrončok:

> On 29. 01. 19 19:04, John Harris wrote:
>> On Monday, January 28, 2019 12:27:19 PM EST Ben Cotton wrote:
>>> Remove packages from the distribution:
>>> * createrepo
>>> * yum
>>> * yum-langpacks
>>> * yum-utils
>>> * yum-metadata-parser
>>> * yum-updatesd
>>> * python-urlgrabber
>>
>> Are there already `dnf` equivalents to `createrepo` and `yum-utils`?
>
> AFAIK createrepo_c for createrepo and dnf itself for yum-utils.

Part of the yum-utils functionality landed in dnf-plugins-core,
e.g. “debuginfo-install” turned into “dnf debuginfo-install”, and the
latter needs dnf-plugins-core.

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

Vagrant 2.2 with QEMU Session

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Vagrant_2.2_with_QEMU_Session

== Summary ==
Upgrade to Vagrant 2.2, the latest stable version of Vagrant. Enable
QEMU Session by default.

== Owner ==
* Name: [[User:pvalena | Pavel Valena]], [[User:vondruch | Vit Ondruch]]
* Email: pval...@redhat.com, vondr...@redhat.com
* Release notes owner:

== Detailed Description ==
Vagrant 2.2 is new upstream's major release, that includes many
features, improvements, and and bug fixes.
Using '''qemu:///session''' instead of '''qemu:///system''' Vagrant
will run unprivileged.

== Benefit to Fedora ==

* Enable QEMU Session by default. With this, there's no need for user
to input any password, or be present in some group. Everyone is able
to use Vagrant, regardless of group or other ACLs.
* Add host support for void linux
* Add support for VirtualBox 6.0
* Add command for uploading files to guest

== Scope ==
* Proposal owners:
** Finish packaging Vagrant 2.2. Current changes:
https://src.fedoraproject.org/rpms/vagrant/pull-request/17
** Finish packaging Vagrant-Libvirt plugin. Current changes:
https://src.fedoraproject.org/rpms/vagrant-libvirt/pull-request/3
** Work has been done in a Copr repository:
https://copr.fedorainfracloud.org/coprs/pvalena/vagrant/
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #8085]
** 
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Because of QEMU Session enabled by defailt, a failure occurs with if
Vagrantfile contains:
```
test_vm.vm.network :private_network, :ip => "172.16.0.2"
```
or similar.
Can be solved by setting `libvirt.qemu_use_session = false` in Vagrantfile.

== How To Test ==
* No special hardware is needed.
* Install Vagrant
* Run ```vagrant version```
* Use your Vagrantfiles or create new as before
* If something doesn't work as it should, let us know.

== User Experience ==
New features that come with Vagrant 2.2 will be available.
Users will not need to add themseles to any group, or have root ACLs
and input a password every time they use Vagrant.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)

== Documentation ==
https://www.vagrantup.com/docs/

== Release Notes ==
https://github.com/hashicorp/vagrant/blob/master/CHANGELOG.md

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

Re: F30 Self-Contained Change proposal: Bash 5.0

[Adam Williamson]

On Mon, 2019-01-28 at 08:56 +0100, Adam Williamson wrote:
> 
> > Have you run these tests on bash 5.0 rebase yet? Also, would it be
> > possible to get this into Fedora Dist-Git so that the checks could be
> > run as part of any build/update/PR to the package?
> 
> Great point, Neal - that would indeed be super helpful, if it's
> possible. Siteshwar, in case you haven't seen it,
> https://fedoraproject.org/wiki/CI/Quick_Start_Guide is the quick start
> version of how to do this, and the longer write-ups are in:
> 
> https://fedoraproject.org/wiki/CI/Tests
> https://fedoraproject.org/wiki/CI/Share_Test_Code
> https://fedoraproject.org/wiki/CI/Pull_Requests
> https://fedoraproject.org/wiki/CI/Examples
> 
> the higher-level https://fedoraproject.org/wiki/CI page has an overview
> of the whole system, and other useful links.

So for the record, I looked into this a bit further, and in fact it has
already been done. There are tests in bash dist-git:

https://src.fedoraproject.org/rpms/bash/blob/master/f/tests

and they are actually being run by the pipeline:

https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f29-build-pipeline/detail/fedora-f29-build-pipeline/282/pipeline

and the results show up in Bodhi (albeit under the heading
'undefined', which is a bug we should fix):

https://bodhi.fedoraproject.org/updates/FEDORA-2019-9d006f6254 (see
Automated Tests tab)

which means Greenwave knows about them, because Bodhi now uses
Greenwave as its source of result data (so anything that shows up in
Bodhi is definitely in Greenwave).

I don't know if the tests that have been imported into dist-git are
*all* of RH's internal tests - Sitesh might know. But certainly some or
all of them have been upstreamed, and are properly set up such that
they will run on any builds done in Fedora and will be available for
the Rawhide gating stuff once that's fully implemented.
-- 
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: Server Side Public License (SSPL) v1

[Ben Cotton]

John,

You can see the discussion on the legal mailing list's archives:

https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/US4PKGDMBQRDYGIYVM2ETARJ5ZPU7TNX/#US4PKGDMBQRDYGIYVM2ETARJ5ZPU7TNX

If you have further questions, le...@lists.fedoraproject.org is the right forum.

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

Fedora 30 Mass Rebuild

[Mohan Boddu]

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

Fedora 30 Mass Rebuild

[Mohan Boddu]

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