Re: Fedora Lifecycles: imagine longer-term possibilities

[David Tardon]

Hello,

On Sat, 2018-11-17 at 08:10 +, Leigh Scott wrote:
> > On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller 
> >  > 
> > "Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years"
> > 
> > https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lt...
> > 
> > I just don't see how we're going to be able to compete with that,
> > not 
> > unless our Fedora LTS is just CentOS with different branding.
> > 
> > Michael
> 
> I don't consider RHEL7 or CentOS7 are true LTS releases, they are
> more like tame fedora releases now.
> Each point release has major changes, 7.6 switched to mesa/libglvnd.
> 

Do you think that such major changes wouldn't happen in a Fedora LTS?

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Leigh Scott]

I'm hoping the Fedora LTS idea will die as quickly as it started.
___
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: Automating package maintainers responsivity check

[Mattia Verga]

Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:

>   You want to attract packagers, not irritate them.

In my opinion, "irritating" is when a maintainer doesn't reply to bugs that 
users fill in Bugzilla. If they can't found enough time to reply or change 
state of any bug in a six months period, than maybe it is better someone else 
take care of their package.

Being a volunteer doesn't mean to not have any responsibility.___
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: Automating package maintainers responsivity check

[Richard Shaw]

On Sat, Nov 17, 2018 at 11:47 AM Mattia Verga 
wrote:

>
>
> - after three emails without response, orphan their packages and inform
> devel list
>

I'm not sure I'm in favor of automatically orphaning packages. I think it
could "tell" of them to the devel list that way anyone who knows them can
try to get in touch with them before that happens.

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

How to get a list of C-only packages to review ?

[Alain Vigne]

As a new packager, I understand peer-reviewing packages is very important,
but it takes me (a lot of) time, and I do not have the necessary skills to
review any kind of packages (Go, Python, Rust, Java, Javascript, Ruby, ...
you name it)

That is why I can offer to review packages of C libs, apps, or GNOME apps,
Vala programs, or ..?, if I can be aware of such review to do.

How do I get such a list ?
Best regards
-- 
Alain V.
___
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: How to get a list of C-only packages to review ?

[Rex Dieter]

Alain Vigne wrote:

> As a new packager, I understand peer-reviewing packages is very important,
> but it takes me (a lot of) time, and I do not have the necessary skills to
> review any kind of packages (Go, Python, Rust, Java, Javascript, Ruby, ...
> you name it)
> 
> That is why I can offer to review packages of C libs, apps, or GNOME apps,
> Vala programs, or ..?, if I can be aware of such review to do.
> 
> How do I get such a list ?

Package reviews are not tracked by language, in general, so as far as I 
know, there is no such list currently.

That said, it's generally not a large task to determine if something is a C 
lib, gnome app, or something that depends on vala, by examining the 
package's .spec file for build depdnencies.

-- 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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> Jonathan Dieter wrote:
> > My proposal would be to make zchunk the rpm compression format for
> > Fedora.
> 
> Given that:
> 1. zchunk is based on zstd, which is typically less efficient in terms of
>compression ratio than xz, depending on settings
>(see, e.g., https://github.com/inikep/lzbench), and
> 2. zchunk can by design only compress chunks individually and not benefit
>from the space savings of a solid archive with a global dictionary,
> I fear that this is going to significantly increase the size of the RPMs, 
> which matters:
> * for the initial downloads,
> * for storage (e.g., keepcache=1, local mirrors, etc.), and
> * for the people not using deltas for whatever reason.
> 
> I think zchunk makes a lot of sense for the metadata, but I am not convinced 
> that it is the right choice for the RPMs themselves.

I suspect the first is true, but zchunk does actually allow for a
global (per-file) dictionary that can be used to compress each chunk. 
The difficulty is that the dictionary has to stay the same between file
versions, or the chunk checksums won't match.  There would have to be
some thought put into how to generate and store the dictionaries.

As for how much bigger a zchunked rpm will be compared to an xz rpm, at
the moment it's a bit hand-wavy.  Based on zchunked repodata work I've
done, I think we might be looking at a size that's slightly smaller
than a gzipped rpm.  I won't know for sure until I put together a
proof-of-concept, but I want to make sure that there aren't any gaping
holes in the proposal before I do that.

Jonathan
___
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: How to get a list of C-only packages to review ?

[Alain Vigne]

Agree, once the .spec file is opened, it is obvious.

But the list such as :
https://fedoraproject.org/PackageReviewStatus/NEW.html
doesn't give you easy access to the info: you have to open the BZ, then
look for the file (if you are lucky). Worst case is when .spec file needs
to be extracted (takes even more time !)

Also, how in BZ, do you state there is no need for reviewer, because review
already started ?
For example:
https://bugzilla.redhat.com/show_bug.cgi?id=1636668
?

I think I am looking for a kind of "TODO" task list I can contribute on.

BR,Alain

On Sun, Nov 18, 2018 at 5:03 PM Rex Dieter  wrote:

> Alain Vigne wrote:
>
> > As a new packager, I understand peer-reviewing packages is very
> important,
> > but it takes me (a lot of) time, and I do not have the necessary skills
> to
> > review any kind of packages (Go, Python, Rust, Java, Javascript, Ruby,
> ...
> > you name it)
> >
> > That is why I can offer to review packages of C libs, apps, or GNOME
> apps,
> > Vala programs, or ..?, if I can be aware of such review to do.
> >
> > How do I get such a list ?
>
> Package reviews are not tracked by language, in general, so as far as I
> know, there is no such list currently.
>
> That said, it's generally not a large task to determine if something is a
> C
> lib, gnome app, or something that depends on vala, by examining the
> package's .spec file for build depdnencies.
>
> -- 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
>


-- 
Alain V.
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Neal Gompa]

On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter  wrote:
>
> On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> > Jonathan Dieter wrote:
> > > My proposal would be to make zchunk the rpm compression format for
> > > Fedora.
> >
> > Given that:
> > 1. zchunk is based on zstd, which is typically less efficient in terms of
> >compression ratio than xz, depending on settings
> >(see, e.g., https://github.com/inikep/lzbench), and
> > 2. zchunk can by design only compress chunks individually and not benefit
> >from the space savings of a solid archive with a global dictionary,
> > I fear that this is going to significantly increase the size of the RPMs,
> > which matters:
> > * for the initial downloads,
> > * for storage (e.g., keepcache=1, local mirrors, etc.), and
> > * for the people not using deltas for whatever reason.
> >
> > I think zchunk makes a lot of sense for the metadata, but I am not convinced
> > that it is the right choice for the RPMs themselves.
>
> I suspect the first is true, but zchunk does actually allow for a
> global (per-file) dictionary that can be used to compress each chunk.
> The difficulty is that the dictionary has to stay the same between file
> versions, or the chunk checksums won't match.  There would have to be
> some thought put into how to generate and store the dictionaries.
>
> As for how much bigger a zchunked rpm will be compared to an xz rpm, at
> the moment it's a bit hand-wavy.  Based on zchunked repodata work I've
> done, I think we might be looking at a size that's slightly smaller
> than a gzipped rpm.  I won't know for sure until I put together a
> proof-of-concept, but I want to make sure that there aren't any gaping
> holes in the proposal before I do that.
>

I did some work several months ago to evaluate zstd compression for
RPMs for Fedora, because of the lower memory and CPU usage for
(de)compression. However, the average size increase from xz was pretty
large (~20% or more on average, and nothing ever was either the same
or smaller), even with heavier compression settings. That might have
changed a bit with newer zstd releases that offer some more tunables,
but I think it'll remain a tough sell on disk space.


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

Re: How to get a list of C-only packages to review ?

[Fabio Valentini]

On Sun, Nov 18, 2018, 18:15 Alain Vigne  Agree, once the .spec file is opened, it is obvious.
>
> But the list such as :
> https://fedoraproject.org/PackageReviewStatus/NEW.html
> doesn't give you easy access to the info: you have to open the BZ, then
> look for the file (if you are lucky). Worst case is when .spec file needs
> to be extracted (takes even more time !)
>
> Also, how in BZ, do you state there is no need for reviewer, because
> review already started ?
> For example:
> https://bugzilla.redhat.com/show_bug.cgi?id=1636668
> ?
>

If someone agrees to review a package, they usually assign the bug to
themselves - which also removes it from the "NEW" package reviews list you
linked above. So, assigning it to yourself after submitting the request
only hides the bug from this list, and possible reviewers.


> I think I am looking for a kind of "TODO" task list I can contribute on.
>

The link for Package Reviews in "NEW" status is exactly what you are
looking for - It's just that not all reviewers and submitters are strictly
following the procedure, making the list less useful than it might be.

Fabio


> BR,Alain
>
> On Sun, Nov 18, 2018 at 5:03 PM Rex Dieter  wrote:
>
>> Alain Vigne wrote:
>>
>> > As a new packager, I understand peer-reviewing packages is very
>> important,
>> > but it takes me (a lot of) time, and I do not have the necessary skills
>> to
>> > review any kind of packages (Go, Python, Rust, Java, Javascript, Ruby,
>> ...
>> > you name it)
>> >
>> > That is why I can offer to review packages of C libs, apps, or GNOME
>> apps,
>> > Vala programs, or ..?, if I can be aware of such review to do.
>> >
>> > How do I get such a list ?
>>
>> Package reviews are not tracked by language, in general, so as far as I
>> know, there is no such list currently.
>>
>> That said, it's generally not a large task to determine if something is a
>> C
>> lib, gnome app, or something that depends on vala, by examining the
>> package's .spec file for build depdnencies.
>>
>> -- 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
>>
>
>
> --
> Alain V.
> ___
> 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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Stephen John Smoogen]

On Sun, 18 Nov 2018 at 12:49, Neal Gompa  wrote:
>
> On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter  wrote:
> >
> > On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> > > Jonathan Dieter wrote:
> > > > My proposal would be to make zchunk the rpm compression format for
> > > > Fedora.
> > >
> > > Given that:
> > > 1. zchunk is based on zstd, which is typically less efficient in terms of
> > >compression ratio than xz, depending on settings
> > >(see, e.g., https://github.com/inikep/lzbench), and
> > > 2. zchunk can by design only compress chunks individually and not benefit
> > >from the space savings of a solid archive with a global dictionary,
> > > I fear that this is going to significantly increase the size of the RPMs,
> > > which matters:
> > > * for the initial downloads,
> > > * for storage (e.g., keepcache=1, local mirrors, etc.), and
> > > * for the people not using deltas for whatever reason.
> > >
> > > I think zchunk makes a lot of sense for the metadata, but I am not 
> > > convinced
> > > that it is the right choice for the RPMs themselves.
> >
> > I suspect the first is true, but zchunk does actually allow for a
> > global (per-file) dictionary that can be used to compress each chunk.
> > The difficulty is that the dictionary has to stay the same between file
> > versions, or the chunk checksums won't match.  There would have to be
> > some thought put into how to generate and store the dictionaries.
> >
> > As for how much bigger a zchunked rpm will be compared to an xz rpm, at
> > the moment it's a bit hand-wavy.  Based on zchunked repodata work I've
> > done, I think we might be looking at a size that's slightly smaller
> > than a gzipped rpm.  I won't know for sure until I put together a
> > proof-of-concept, but I want to make sure that there aren't any gaping
> > holes in the proposal before I do that.
> >
>
> I did some work several months ago to evaluate zstd compression for
> RPMs for Fedora, because of the lower memory and CPU usage for
> (de)compression. However, the average size increase from xz was pretty
> large (~20% or more on average, and nothing ever was either the same
> or smaller), even with heavier compression settings. That might have
> changed a bit with newer zstd releases that offer some more tunables,
> but I think it'll remain a tough sell on disk space.

So there are at least 4 legs here:
CPU usage (in both uncompression install and deltarpm)
Memory usage per transaction
Network amount
Disk amount

I expect that the best we are going to get in any 'improvement' is
going to be 3 out of the 4. The xz compression and delta-rpm has a
cpu/memory tradeoff for disk and network in comparison to gzip but it
is mostly acceptable if you have fairly modern desktops. However for
older hardware or lower power systems that tradeoff may not be good.



-- 
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: How do I "release" a spin/lab?

[Kevin Fenzi]

On 11/16/18 10:22 AM, Miro Hrončok wrote:
> When Fedora 29 was released, the Python Classroom Lab wasn't built.
> 
> The problem is now fixed:
> 
> https://koji.fedoraproject.org/koji/packageinfo?packageID=23847
> 
> However how do i build and release it, so it is listed on:
> 
> https://labs.fedoraproject.org/
> 
> And so that
> 
> https://labs.fedoraproject.org/python-classroom/download/index.html
> 
> Doesn't list 404 links?

Well, you will need 2 tickets:

First, against releng asking them to compose it and put it in place.
Then against websites asking them to update the website checksum, etc.

It should be possible to do this and place it in the same place as the
other spins that weren't produced in the rc.

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: Automating package maintainers responsivity check

[Kevin Fenzi]

On 11/18/18 1:44 AM, Mattia Verga wrote:
> Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:
> 
>>   You want to attract packagers, not irritate them.
> 
> In my opinion, "irritating" is when a maintainer doesn't reply to bugs that 
> users fill in Bugzilla. If they can't found enough time to reply or change 
> state of any bug in a six months period, than maybe it is better someone else 
> take care of their package.
> 
> Being a volunteer doesn't mean to not have any responsibility.

So, this has come up... at least 3 times.
I can't seem to find the first one, but at least one of the old discussions:

https://lwn.net/Articles/261833/

it was always decided that it would be too annoying to maintainers, but
that was before we had fedmsg and more information on activity, so
perhaps it's worth looking into again.

One of the problems is that we want bugs fixed, but all bugs are not
created equal. We don't want to force maintainers to say they are active
in every bug they get, but currently we allow non responsive process for
that, so a activity ping might well be an improvement over that.

We also want to know when people are inactive so we can get someone else
to maintain their packages, but any packages with co-maintainers should
already be taking that on, so perhaps we should worry more about
packages that only have one maintainer?

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: Automating package maintainers responsivity check

[Philip Kovacs]

 > Being a volunteer doesn't mean to not have any responsibility.
It's grossly unfair to insinuate that being a volunteer is associated with 
laziness or a lack of responsibility.
There are a myriad of things that we as packagers do that are completely silent 
to the surrounding automation and for which most people are never even aware.  
Working with upstream development teams, for example, filing bugs on their 
systems.  What Fedora sees as a patch or a version bump to a package may be the 
result of hours of thankless work on the part of the volunteer packager.   
If you want to find a way to automate notification that a maintainer is 
unresponsive after a reasonably period, fine.   Obsoleting their packages is 
just wrong however. On Sunday, November 18, 2018, 4:45:00 AM EST, Mattia 
Verga  wrote:  
 
  Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:
  
 
  You want to attract packagers, not irritate them. 

   
In my opinion, "irritating" is when a maintainer doesn't reply to bugs that 
users fill in Bugzilla. If they can't found enough time to reply or change 
state of any bug in a six months period, than maybe it is better someone else 
take care of their package.
 
Being a volunteer doesn't mean to not have any responsibility.

___
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: How do I "release" a spin/lab?

[Miro Hrončok]

On 18. 11. 18 19:37, Kevin Fenzi wrote:

On 11/16/18 10:22 AM, Miro Hrončok wrote:

When Fedora 29 was released, the Python Classroom Lab wasn't built.

The problem is now fixed:

https://koji.fedoraproject.org/koji/packageinfo?packageID=23847

However how do i build and release it, so it is listed on:

https://labs.fedoraproject.org/

And so that

https://labs.fedoraproject.org/python-classroom/download/index.html

Doesn't list 404 links?


Well, you will need 2 tickets:

First, against releng asking them to compose it and put it in place.
Then against websites asking them to update the website checksum, etc.

It should be possible to do this and place it in the same place as the
other spins that weren't produced in the rc.



Thanks Kevin, I'll do just 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

Fedora Upgrade - release criteria update proposal

[Frantisek Zatloukal]

We have encountered a bug[0] which seemingly “broke” offline updates after
systems were upgraded from an older Fedora to Fedora 29 and had some
multilib packages installed. After the discussion at last week's Release
Retrospective meeting, I am proposing some changes to our blocking
criterions in order to address similar issues in the future:

What we test now

We are currently blocking on upgrading from Fedora n-1 and n-2 releases
only with default package set installed.

What we can test

We can alter our upgrade test cases to also verify that updates after an
upgrade work. The test case might look like this:

   -

   Install Fedora n-1
   -

   Upgrade to Fedora n (updates-testing disabled)
   -

   Enable updates-testing
   -

   Update to latest packages
   -

   Verify that upgrade and update went fine and that the multilib packages
   installed before are still present


Apart from that, we can add (Final Blocking) test case
upgrade_dnf_current_workstation_multilib /
upgrade_dnf_current_minimal_multilib which will test upgrades (and then
updates as described above) with at least one i686 package installed on
x86_64 system. The other (less-generic, but closer to what users probably
do have on their systems) approach would be to test upgrade with steam (or
wine) installed.


What are our opinions about this?

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1642796
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Richard W.M. Jones]

I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.

From your email:

On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> But there are some good cases for a longer lifecycle. For one thing,
> this has been a really big blocker for getting Fedora shipped on
> hardware. Second, there are people who really could be happily running
> Fedora but since we don't check the tickbox, they don't even look at us
> seriously. I'd love to change these things. To do that, we need
> something that lasts for 36-48 months.

this sounds like a very valid problem.

But if this was fixed, what number of manufacturers would adopt Fedora
and how many installations do they ship (eg per year)?  Could it be
fixed in another way, like a special OEM Fedora release?

Is this the only problem that we're trying to solve or are there others?

Rich.

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Orion Poplawski]

On 11/18/18 2:29 PM, Richard W.M. Jones wrote:

I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.

 From your email:

On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:

But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.


this sounds like a very valid problem.

But if this was fixed, what number of manufacturers would adopt Fedora
and how many installations do they ship (eg per year)?  Could it be
fixed in another way, like a special OEM Fedora release?


And why haven't these manufacturers already adopted CentOS which is 
definitely around longer than 36-48 months?


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Tony Nelson]

On 18-11-18 16:29:45, Richard W.M. Jones wrote:

I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.

From your email:

On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> But there are some good cases for a longer lifecycle. For one thing,
> this has been a really big blocker for getting Fedora shipped on
> hardware. Second, there are people who really could be happily  
running
> Fedora but since we don't check the tickbox, they don't even look  
at us

> seriously. I'd love to change these things. To do that, we need
> something that lasts for 36-48 months.

this sounds like a very valid problem.

But if this was fixed, what number of manufacturers would adopt Fedora
and how many installations do they ship (eg per year)?  Could it be
fixed in another way, like a special OEM Fedora release?

Is this the only problem that we're trying to solve or are there  
others?


I would suggest fixing the "problem" in a completely different way.
There seems to be a class of customer that wants the very latest thing,
often, but for each such thing to hold still and be maintained for 3 to
7 years.  That isn't Fedora, or even RHEL.

Fedora can be updated and upgraded with good reliablility now.  So,
instead, continue to make updates and version upgrades more and more
reliable, and revertable when they don't work, as MSWindows has been
doing.  Get more users within those customers so they trust that
reliablility.  Then those customers can choose, in a business way, to
install Fedora for their customers, who will get and keep the latest
and greatest, and Fedora has captialized on its strengths.

--

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Neal Gompa]

On Sun, Nov 18, 2018 at 5:08 PM Orion Poplawski  wrote:
>
> On 11/18/18 2:29 PM, Richard W.M. Jones wrote:
> > I'm not for or against a longer Fedora lifecycle, but I think we need
> > a stronger statement of what the problem is we're trying to address.
> >
> >  From your email:
> >
> > On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> >> But there are some good cases for a longer lifecycle. For one thing,
> >> this has been a really big blocker for getting Fedora shipped on
> >> hardware. Second, there are people who really could be happily running
> >> Fedora but since we don't check the tickbox, they don't even look at us
> >> seriously. I'd love to change these things. To do that, we need
> >> something that lasts for 36-48 months.
> >
> > this sounds like a very valid problem.
> >
> > But if this was fixed, what number of manufacturers would adopt Fedora
> > and how many installations do they ship (eg per year)?  Could it be
> > fixed in another way, like a special OEM Fedora release?
>
> And why haven't these manufacturers already adopted CentOS which is
> definitely around longer than 36-48 months?
>

I think it's quite obvious why. No one can really influence what's in
CentOS. Red Hat Enterprise Linux itself is developed mostly behind
closed doors, after forking a Fedora release. If we had an equivalent
to Fedora Legacy/openSUSE Evergreen to support a specific release for
an extended period of time, we could also allow ODMs/OEMs to be part
of that process to help improve support of their equipment with Linux
and that effort would be able to be pushed upstream with guidance from
Fedora to benefit all Linux distributions. And while most people think
the relationship is Red Hat -> Fedora, it's actually the other way
around. Fedora can be an integration point for PC makers to help those
people to benefit the Linux ecosystem as a whole.

But I don't think we should extend the lifecycle on a general basis.
That's asking for trouble, since it cedes our leadership in the Linux
platform and destroys our ability to meet our own values.



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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Neal Gompa]

On Sun, Nov 18, 2018 at 5:30 PM Reindl Harald  wrote:
>
> Am 18.11.18 um 23:19 schrieb Neal Gompa:
> > I think it's quite obvious why. No one can really influence what's in
> > CentOS. Red Hat Enterprise Linux itself is developed mostly behind
> > closed doors, after forking a Fedora release.
>
> that must be why they ship a completly closed source windows

But for Windows, ODMs/OEMs benefit from the ecosystem of components
already building and targeting for that platform. And even Microsoft
does provide toolkits and assistance for major PC makers to better
support the Windows platform. And the Windows release lifecycle is
directly set up to support PC makers.

Fedora has a wonderful advantage in that our ethos and practice in
developing the distribution[1] often means we're directly plugged in
with the various upstreams and can help make things better. We can
provide that ecosystem value for PC makers, and by that token, we can
add major value over other Linux distributions and offer a positive
relationship to PC makers to encourage them to ship Linux on their
PCs, specifically Fedora.

[1]: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects

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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Gerald Henriksen]

On Sun, 18 Nov 2018 17:19:37 -0500, you wrote:

>But I don't think we should extend the lifecycle on a general basis.
>That's asking for trouble, since it cedes our leadership in the Linux
>platform and destroys our ability to meet our own values.

What leadership would Fedora be ceding by extending the lifecyle?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Server 29: when stop and start my qemu/kvm server, some service they do not start

[Dario Lesca]

Il giorno ven, 16/11/2018 alle 18.26 +0100, Dario Lesca ha scritto:
> I have fill this bug: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1650289 in which there
> are some useful logs files
> 
> If someone have some suggest to resolve this issue without modify the
> .service file of this service let me know

What's wrong in my bug report? Should I report it as a named bug? ...
or Samba bug?

... or I'm only one Samba AD on a KVM Virtual Machine with Fedora
Server user?

Someone have some suggest, or I must modify named.service and
gssproxy.service every time they are update?

Let me know
Thanks


-- 
Dario Lesca
(inviato dal mio Linux Fedora 28 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Upgrade - release criteria update proposal

[Adam Williamson]

On Sun, 2018-11-18 at 21:48 +0100, Frantisek Zatloukal wrote:
> We have encountered a bug[0] which seemingly “broke” offline updates after
> systems were upgraded from an older Fedora to Fedora 29 and had some
> multilib packages installed. After the discussion at last week's Release
> Retrospective meeting, I am proposing some changes to our blocking
> criterions in order to address similar issues in the future:

I don't think the bug had anything to do with upgrades, did it? AIUI it
would also affect a fresh F29 install to which multilib packages had
been added.
-- 
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: NSS package consolidation

[Robert-André Mauchin]

On lundi 12 novembre 2018 18:10:47 CET Daiki Ueno wrote:
> Tom Hughes  writes:
> 
> 
> > If it's going to one source rpm producing the same three binary
> > rpms then you are indeed correct.
> 
> 
> Thank you for the suggestions.  Then I will go ahead and retire nss-util
> and nss-softokn source packages once we are sure that the generated
> binary packages are sane enough.  I have created a copr repository for
> testing:
> https://copr.fedorainfracloud.org/coprs/ueno/nss-consolidate/
> 
> firefox and java-openjdk maintainers: could you check if these builds
> don't break anything?
> 
> Regards,
> -- 
> Daiki Ueno


Could we also remove the old cruft?

 - Group: is not needed.

 - %{__rm} -rf $RPM_BUILD_ROOT is not needed in %install

 - Using %{__rm}, %{__mkdir_p}, %{__install}, %{__cp}, %{__make} and so on is 
pointless, just use the binaries directly. 

 - %ldconfig_scriptlets: You can drop this now (since F28).

 - The man files should not be marked as %doc and %attr(0644,root,root) should 
not be needed as it is the default:

%attr(0644,root,root) %doc %{_mandir}*

 - The extension of the man pages .gz should be globbed instead as we may 
change the compression in the future.

 - Your Requires: in devel subpackages are missing %{?_isa}

Requires: nss%{?_isa} = %{version}-%{release}

Requires: nss-util%{?_isa} = %{version}-%{release}

 - Consider using a URL for Source0:

Source0:  https://hg.mozilla.org/projects/nss/archive/%
{nss_tag}.tar.gz

  with %global nss_tag NSS_3_40_RTM

instead of Source0:  %{name}-%{nss_archive_version}.tar.gz

   You may need to adjust %prep:

%setup -q -n nss-%{nss_tag}

   and -p1 the patches instead of -p0/-p1
   and remove the ./nss/ top directory from various commands in %build and 
%install to match the archive structure.

See my SPEC at https://copr-be.cloud.fedoraproject.org/results/eclipseo/
firefox-nightly/fedora-rawhide-x86_64/00826328-nss/nss.spec

Build: https://copr.fedorainfracloud.org/coprs/eclipseo/firefox-nightly/build/
826328/

Please consider these changes for your PR.

Best regards,

Robert-André

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: How to get a list of C-only packages to review ?

[Rex Dieter]

Alain Vigne wrote:

> Agree, once the .spec file is opened, it is obvious.
> 
> But the list such as :
> https://fedoraproject.org/PackageReviewStatus/NEW.html
> doesn't give you easy access to the info: you have to open the BZ, then
> look for the file (if you are lucky). Worst case is when .spec file needs
> to be extracted (takes even more time !)

Every (good) review should give a direct link to the .spec

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 162  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
 113  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
  96  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  68  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3492a96896   
myrepos-1.20180726-1.el7
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bdb21ebc3f   
drupal7-7.60-2.el7
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dea9ade8c1   
icecast-2.4.4-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cbfa290941   
mkvtoolnix-28.2.0-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-be918c58c6   
SDL2_image-2.0.4-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-df2d5af2fe   
mingw-SDL2-2.0.9-1.el7 mingw-SDL2_mixer-2.0.4-1.el7 mingw-SDL2_image-2.0.4-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-32e0cee0bb   
perl-Mojolicious-7.94-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9051b49e75   
suricata-4.0.6-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc29932f12   
pdns-4.0.6-2.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9270bbaec   
pdns-recursor-4.1.7-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a09ace87bb   
php-PHPMailer-5.2.27-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b4d4e0a3eb   
python-django-1.11.13-2.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0e73364530   
python-paramiko-2.1.1-0.9.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

incron-0.5.12-6.el7
zchunk-0.9.15-1.el7

Details about builds:



 incron-0.5.12-6.el7 (FEDORA-EPEL-2018-6d7a9a6147)
 Inotify cron system

Update Information:

0.5.12 for epel7 with various fixes.

ChangeLog:

* Wed Feb  7 2018 Fedora Release Engineering  - 
0.5.12-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Aug  2 2017 Fedora Release Engineering  - 
0.5.12-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Wed Jul 26 2017 Fedora Release Engineering  - 
0.5.12-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Thu Mar 30 2017 Orion Poplawski  - 0.5.12-4
- Do not install service file as executable
- Use %license
- Cleanup spec
* Fri Feb 10 2017 Fedora Release Engineering  - 
0.5.12-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Thu Feb  4 2016 Fedora Release Engineering  - 
0.5.12-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
* Sun Jan  3 2016 Kevin Fenzi  - 0.5.12-1
- Update to 0.5.12
* Wed Jun 17 2015 Fedora Release Engineering  
- 0.5.10-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
* Sat May  2 2015 Kalev Lember  - 0.5.10-9
- Rebuilt for GCC 5 C++11 ABI change

References:

  [ 1 ] Bug #1650654 - incorrect permissions on 
/usr/lib/systemd/system/incrond.service
https://bugzilla.redhat.com/show_bug.cgi?id=1650654




 zchunk-0.9.15-1.el7 (FEDORA-EPEL-2018-ecfada8595)
 Compressed file format that allows easy deltas

Update Information:

Switch from optional flags to more robust optional elements

ChangeLog:

* Tue Nov 13 2018 Jonathan Dieter  - 0.9.15-1
- Switch from optional flags to more robust optional elements

___
epel-devel mailing list -- epel-de...@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-de...@lists.fedoraproject.org

Re: Fedora Upgrade - release criteria update proposal

[Kevin Kofler]

Frantisek Zatloukal wrote:
>Install Fedora n-1
>Upgrade to Fedora n (updates-testing disabled)
>Enable updates-testing
>Update to latest packages
>Verify that upgrade and update went fine and that the multilib packages
>installed before are still present

If you follow exactly this procedure, the set of "the multilib packages 
installed before" will be empty and you will not reproduce the issue at 
hand. Multilib cruft has not been installed by default for years now! (And 
that is a good thing! Pure 64-bit just works.)

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

Re: Fedora Upgrade - release criteria update proposal

[Frantisek Zatloukal]

On Mon, Nov 19, 2018 at 6:43 AM Kevin Kofler  wrote:

> If you follow exactly this procedure, the set of "the multilib packages
> installed before" will be empty and you will not reproduce the issue at
> hand. Multilib cruft has not been installed by default for years now! (And
> that is a good thing! Pure 64-bit just works.)


Yeah, of course, the "Verify that upgrade and update went fine and that the
multilib packages installed before are still present" should have been in
the later paragraph.

>
On Mon, Nov 19, 2018 at 2:06 AM Adam Williamson 
wrote:

> I don't think the bug had anything to do with upgrades, did it? AIUI it
> would also affect a fresh F29 install to which multilib packages had
> been added.


I've got an impression from all the rant around that on the internet that
it happened just on upgraded systems. But it makes sense to also affect
clean installs.
___
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 rawhide compose report: 20181118.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181117.n.0
NEW: Fedora-Rawhide-20181118.n.0

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  5
Dropped packages:0
Upgraded packages:   66
Downgraded packages: 0

Size of added packages:  1.67 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.06 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -34.41 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20181118.n.0-sda.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20181118.n.0.iso
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20181118.n.0.iso
Image: AtomicHost dvd-ostree ppc64le
Path: 
AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-Rawhide-20181118.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: octave-optim-1.5.3-2.module_2483+967bde31
Summary: A non-linear optimization tool kit for Octave
RPMs:octave-optim
Size:1.44 MiB

Package: rust-arc-swap-0.3.5-1.fc30
Summary: Atomically swappable Arc
RPMs:rust-arc-swap+default-devel rust-arc-swap-devel
Size:52.68 KiB

Package: rust-heck-0.3.0-1.fc30
Summary: Case conversion library
RPMs:rust-heck+default-devel rust-heck-devel
Size:66.72 KiB

Package: rust-opener-0.3.2-1.fc30
Summary: Open a file or link using the system default program
RPMs:rust-opener+default-devel rust-opener-devel
Size:29.48 KiB

Package: rust-signal-hook-0.1.6-1.fc30
Summary: Unix signal handling
RPMs:rust-signal-hook+default-devel rust-signal-hook+futures-devel 
rust-signal-hook+mio-devel rust-signal-hook+mio-support-devel 
rust-signal-hook+mio-uds-devel rust-signal-hook+tokio-reactor-devel 
rust-signal-hook+tokio-support-devel rust-signal-hook-devel
Size:79.93 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  anyremote-6.7.2-1.fc30
Old package:  anyremote-6.7.1-3.fc29
Summary:  Remote control through Wi-Fi or bluetooth connection
RPMs: anyremote anyremote-data anyremote-doc
Size: 12.78 MiB
Size change:  -38.33 KiB
Changelog:
  * Sun Nov 18 2018 Mikhail Fedotov  - 6.7.2
  - Configuration file for Shotwell and Snappy were added. Weather script was 
fixed.


Package:  bijiben-3.30.3-1.fc30
Old package:  bijiben-3.30.2-1.fc30
Summary:  Simple Note Viewer
RPMs: bijiben
Size: 3.35 MiB
Size change:  16.79 KiB
Changelog:
  * Sat Nov 17 2018 Kalev Lember  - 3.30.3-1
  - Update to 3.30.3
  - Use upstream screenshots in appdata


Package:  dianara-1.4.2-1.fc30
Old package:  dianara-1.4.1-5.fc29
Summary:  Pump.io application for the desktop
RPMs: dianara
Size: 5.09 MiB
Size change:  -124.04 KiB
Changelog:
  * Sun Nov 18 2018 Antonio Trande  1.4.2-1
  - Release 1.4.2


Package:  dippi-2.7.1-1.fc30
Old package:  dippi-2.7.0-2.fc29
Summary:  Calculate display info like DPI and aspect ratio
RPMs: dippi
Size: 647.90 KiB
Size change:  1.21 KiB
Changelog:
  * Sat Nov 17 2018 Fabio Valentini  - 2.7.1-1
  - Update to version 2.7.1.


Package:  dnsdist-1.3.3-1.fc30
Old package:  dnsdist-1.3.0-3.fc29
Summary:  Highly DNS-, DoS- and abuse-aware loadbalancer
RPMs: dnsdist
Size: 7.16 MiB
Size change:  159.29 KiB
Changelog:
  * Sun Nov 18 2018 Sander Hoentjen  - 1.3.3-1
  - Update to 1.3.3
  - Fixes CVE-2018-14663


Package:  gmsh-4.0.5-1.fc30
Old package:  gmsh-4.0.4-1.fc30
Summary:  A three-dimensional finite element mesh generator
RPMs: gmsh gmsh-common gmsh-devel gmsh-devel-private gmsh-doc gmsh-libs 
gmsh-mpich gmsh-mpich-devel gmsh-mpich-devel-private gmsh-mpich-libs 
gmsh-openmpi gmsh-openmpi-devel gmsh-openmpi-devel-private gmsh-openmpi-libs 
python3-gmsh python3-gmsh-private
Size: 100.42 MiB
Size change:  361.42 KiB
Changelog:
  * Fri Nov 16 2018 Sandro Mani  - 4.0.5-1
  - Update to 4.0.5


Package:  gns3-gui-2.1.11-2.fc30
Old package:  gns3-gui-2.1.8-1.fc29
Summary:  GNS3 graphical user interface
RPMs: gns3-gui
Size: 4.73 MiB
Size change:  2.36 KiB
Changelog:
  * Sat Nov 17 2018 Athmane Madjoudj  - 
2.1.112.1.11-11
  - Update to 2.1.11 (rhbz #1581506)

  * Sat Nov 17 2018 Athmane Madjoudj  - 2.1.11-2
  - Add missing PyQt dep


Package:  gns3-server-2.1.11-1.fc30
Old package:  gns3-server-2.1.8-2.fc29
Summary:  Graphical Network Simulator 3
RPMs: gns3-server gns3-server-doc
Size: 12.22 MiB
Size change:  10.86 MiB
Changelog:
  * Sat Nov 17 2018 Athmane Madjoudj  - 2.1.11-1
  - Update to 2.1.11 (rhbz #1581507)
  - Drop unsued patch


Package:  gobject-introspection-1.58.1-1.fc30
Old package:  gobject-introspection-1.58.0-2.fc30
Summary:  Introspection system for GObject-based libraries
RPMs: gobject-introspection gobject-introspection-devel
Size: 8.96 MiB
Size change:  -1.52 KiB

[Bug 1612860] perl-Net-Pcap-0.18-9.fc29 FTBFS: stubs.inc:357:8: error: redefinition of 'struct pcap_rmtauth'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 127685
Version|29  |27



--- Comment #6 from Petr Pisar  ---
The new 1.9.0 libcap is now in all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org