Re: What does delaying F31 mean for packagers/users?

[Debarshi Ray]

On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
> One of the key parts of making a decision to delay/skip F31 is
> figuring out, ahead of the decision, what the expected experience is
> for users and packagers. Does F30 have normal stability, or do we try
> to keep users happy by moving things forward with ad-hoc updates and
> cross-our-fingers and hope nothing breaks?
> 
> I tend to think about this in terms of GNOME - would we rebase to
> GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> pieces of software where similar considerations apply: container
> tools, cockpit, NetworkManager, etc.
> 
> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?

Umm... can't we treat it the same as the Fedora 20/21 situation?
Skipping a GNOME release can be a bit painful for the upstream GNOME
community, which is overwhelmingly tilted towards Fedora, but it's not
the end of the world either. After all, I don't think the longer
Fedora 21 cycle had any negative long-term effect on that group at
all. :)

The Desktop Team could more aggressively backport bug-fixes to GNOME
3.34 upstream, and if needed backport selected features to Fedora 30
downstream. We have done this during the usual six month Fedora
releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
have done this for RHEL too, so there's some precedence in this area.
___
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: What does delaying F31 mean for packagers/users?

[Lukas Ruzicka]

Sorry about the two lines of the letter that do not fit much into the
concept:

So, I like the idea of one major and one minor release, if we want to stay
conservative and do not want to go the rolling updates way. And, in case we
want to stay super conservative and we do not want change anything, I think
Debarshi's approach would work just fine.

Thanks for understanding,
Lukas

On Wed, Nov 28, 2018 at 10:20 AM Lukas Ruzicka  wrote:

> Hello,
> I do not think that we should be taking the path towards Gnome being in
> one module. This is not, what "modular" means. In my understanding, modules
> should be smaller, rather independent units, that will help solve some user
> cases, but definitely not upgrading half of the system.
> Also, if we should provide updated ISOs, as one of the ideas was, why not
> do a normal release instead? It does not have to be packed with all new
> stuff, fixes and minor updates could be just fine ... and the new Gnome.
> I think there are several strategies, where we could go next, for example:
>
>
>- Release regularly to get the new Gnome, but do not push for so many
>new features in Fedora 31, if we need more time to fix things.
>- Adopt the Major / Minor approach and make the autumn release a minor
>one, so that Fedora 31 becomes a minor release.
>- Adopt the "rolling updates" strategy for Fedora and introduce a
>Fedora LTS that would be here for people who do not want rolling updates.
>- Just skip the release with all the consequences it will have ... no
>updates to new versions
>
> Let us not make Fedora messy by creating huge modules with dependencies in
> the whole system. It is too risky to go that way, because modularity is
> just at its beginning and has issues we must solve first. For example, what
> happens if you have a module stream installed and all the dependencies in a
> working system and you want to change from one stream to another? As far as
> I know, nobody guarantees at the moment, that the dependencies will not
> break. Can you image how putting Gnome into a module will affect the system
> when this is not solved?
>
> I'd rather see Fedora stay a bit older for a period of time than to see it
> breaking and leaving people angry.
>
> Take care,
> Lukas
>
>
>
>
> I quite like the idea of one major and one minor release in a year.
>
> I think that Debarshi's approach would work nicely
>
> On Wed, Nov 28, 2018 at 9:34 AM Debarshi Ray  wrote:
>
>> On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
>> > One of the key parts of making a decision to delay/skip F31 is
>> > figuring out, ahead of the decision, what the expected experience is
>> > for users and packagers. Does F30 have normal stability, or do we try
>> > to keep users happy by moving things forward with ad-hoc updates and
>> > cross-our-fingers and hope nothing breaks?
>> >
>> > I tend to think about this in terms of GNOME - would we rebase to
>> > GNOME 3.34 in the middle of F30 or not? But there's a lot of other
>> > pieces of software where similar considerations apply: container
>> > tools, cockpit, NetworkManager, etc.
>> >
>> > And if we did do updates like that, would we consider respinning media
>> > and making a "F30.1"?
>>
>> Umm... can't we treat it the same as the Fedora 20/21 situation?
>> Skipping a GNOME release can be a bit painful for the upstream GNOME
>> community, which is overwhelmingly tilted towards Fedora, but it's not
>> the end of the world either. After all, I don't think the longer
>> Fedora 21 cycle had any negative long-term effect on that group at
>> all. :)
>>
>> The Desktop Team could more aggressively backport bug-fixes to GNOME
>> 3.34 upstream, and if needed backport selected features to Fedora 30
>> downstream. We have done this during the usual six month Fedora
>> releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
>> have done this for RHEL too, so there's some precedence in this area.
>> ___
>> 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
>>
>
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> 
>
> Purkyňova 115
>
> 612 45 Brno - Královo Pole
>
> lruzi...@redhat.com
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What does delaying F31 mean for packagers/users?

[Kamil Paral]

On Tue, Nov 27, 2018 at 4:39 PM Owen Taylor  wrote:

> And if we did do updates like that, would we consider respinning media
> and making a "F30.1"?
>

What's the difference between re-spinning install media and doing a proper
F31 release? At least from QA point of view, I see very little difference.
We would need RCs, we would need a freeze, blocker bug meetings, the whole
process. And of course some of our tooling might not account for a special
F30.1 release-but-not-really, so it might end up more work than a standard
release. I can't speak for releng, but I'd expect a similar story.
___
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: Move to an annual platform release starting at F30

[Peter Robinson]

On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
 wrote:
>
> On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy  wrote:
> > Paul's proposal was definitely a one-time pause for the reasons you
> > state.  He requested we follow-up with additional questions and
> > suggestions so I'm questioning and suggesting taking it a step
> > further.  We talk about rolling releases, but people are skeptical due
> > to rawhide instability.  What does it look like if the "rolling"
> > happens on top of an otherwise stable platform where fundamentals like
> > compilers, libraries and core system tools are held steady, but things
> > on top move fast?  Maybe you don't need an F30.1, maybe it means F30
> > just keeps getting nice incremental updates for as long as the
> > editions want to stick with it.  Variable lifecycle or cadence can
> > open up these kinds of options.  Some things are better fast. Some
> > things are better slow.
>
> This.  Yes This. +100
>
> I think that Fedora's role as an innovater in the OS space means we
> should be aggressively exploring this.  Rolling Releases, Tech-Driven
> Releases and Time-Based Releases all have well known positives and
> negatives.  All of the work that has been done on Modularity,
> containers, flatpaks, OSTree, and more, gives us the opportunity to
> really re-think this.  While it is true there are dozens (or more)
> additional solutions to the too-fast/too-slow and the
> incompatible-libraries problems, these technologies seem to be gaining
> the most adoption across a variety of use cases.  They are all also
> generally well supported in Fedora and we need to aggressively push
> them to achieve this goal or determine where the dead-end is so we can
> move to the next innovation.
>
> I personal am hugely in favor of us adopting a bootable-base model
> that allows us to iterate the kernel and the various user-space pieces
> at the speed of the upstream, the user's desires and the builder's
> desires[^0] all at the same time.  While this will require us to do
> some level of NxM matrix building and testing, a base that didn't have
> to change often for most use cases reduces the matrix considerably.

The above doesn't make sense, you're saying "move as fast as upstream"
and "a base that doesn't change" in the same context, which is it?

> I'd push Brendans' concept further and suggest that we try to
> eliminate as many of the compilers, libraries and core system tools as
> possible from this bootable-base so that those can iterate at their
> own speed, perhaps 4 year for a laptop vendor and 30 day for a
> experimental ARM device.  Fedora as a project might not build output
> for the whole range, but a build system that allowed us to help others
> be successful would be a huge help here.

Again what do you even mean by eliminate the compilers? Also how do we
not change something core, such as a compiler, for 4 years while also
change it every 30 days?

> I recognize that I, like most people, see the world through the lens
> of my specific use case, but remember, "Fedora creates an innovative
> platform for hardware, clouds, and containers that enables software
> developers and community members to build tailored solutions for their
> users."  As long as we don't block a use cases arbitrarily and we
> leave room for that innovation and service we are doing the right
> thing.  The debate about what use cases should be done fully by
> Fedora, enabled for a SIG/WG via our build system or done externally
> by those using only the parts that make sense for them is a separate
> debate.

I agree on some of your points above, but TBH most of it reads like
some form of marketing coolaid!

Also it does account at all for any and/or all of the resources that
we'd need to even enact some of this, even if it's possible?


> 0: Builder's desires are the desires of the person who put the entire
> system together to fulfill the needs of their community per our
> mission statement.  If my mythical llama herders need the oldest Libre
> Office possible but the newest Rust packaging and whatever random
> version of httpd that Fedora deems "stable", then that is what I
> desire, even if the upstream or other non-llama herding users desire
> something different.  However, I'd also push that we should try to
> reach a point where if a llama herder for non-llama reasons needs a
> different httpd, they can just enable and use it (using the language
> of modularity).  In case it isn't clear, the "builder's desires"
> includes the goals of every current lab, spin, and edition, separately
> and where appropriate together.
> ___
> 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: 
> 

Re: What does delaying F31 mean for packagers/users?

[Brian (bex) Exelbierd]

On Tue, Nov 27, 2018 at 10:56 PM drago01  wrote:
>
>
>
> On Tuesday, November 27, 2018, Owen Taylor  wrote:
>>
>> On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher  
>> wrote:
>> > As came up in another part of the earlier thread, I think this is an
>> > opportunity for Modularity. For those things like GNOME that want to
>> > rev mid-release, if they shipped the 3.34 release as new stream, those
>> > that want to move to it will have that option, and those who fear
>> > change can remain on the 3.32 release, even if it's not getting
>> > support. This would have to be something communicated at release-time
>> > of course.
>>
>> If we want to offer optional GNOME-3.34, a module is probably a better
>> alternative to using a copr - which is what we did last time.
>> (https://copr.fedorainfracloud.org/coprs/rhughes/f20-gnome-3-12/) But
>> we have to recognize that if we create such a module we are
>> effectively creating a Fedora 30.1 - because libraries in that module
>> will replace system libraries. From the point where we release such a
>> module, any RPM-packaged applications that use GNOME libraries will
>> have to be tested against *both* F30 and F30+gnome-3-34.
>>
>> It's also a minimally scalable approach - we wouldn't want to have a
>> GNOME 3.34 module and a NetworkManager-1.16 module and support
>> arbitrary combinations.
>>
>> And we'd have to figure out some strategy for not breaking F31 updates
>> when you have the desktop:3.34 module enabled.
>>
>>
>
> I don't think modules are useful for non self contained package sets (like a 
> desktop environment). As you said we might end up having half the distro in 
> that module.

I'm not sure this is a bad thing.  My understanding is that modules
are designed to allow for this in a transparent way to to the "half"
of the system that isn't in the module.  I realize this can create a
huge build/test matrix, but putting down some boundaries can allow us
to reduce the matrix to a manageable size (with automation we need
anyway) and not block someone who has a reason to need somethign
different from either building their own bits to fill in parts of the
matrix or possibly federating with our build system to fill in gaps
for themselves and their community.

regards,

bex

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



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

Re: What does extended F30 cycle mean for F29?

[Peter Robinson]

On Wed, Nov 28, 2018 at 7:14 AM Kalev Lember  wrote:
>
> If F31 is delayed by 6 months and F30 is supported for 6 months longer,
> does it mean F29 *also* automatically gets a longer cycle since it by
> policy becomes EOL when F31 is out + 1 month?
>
> Can we EOL F29 6 months before F31 is out to not have *two* long term
> branches to maintain?

So going back to memory of what we did in the F-21 cycle, we EOLed
F-19 at the 13 months line and then F-20 continued until a month after
F-22 was out.
___
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: Move to an annual platform release starting at F30

[Brian (bex) Exelbierd]

On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy  wrote:
> Paul's proposal was definitely a one-time pause for the reasons you
> state.  He requested we follow-up with additional questions and
> suggestions so I'm questioning and suggesting taking it a step
> further.  We talk about rolling releases, but people are skeptical due
> to rawhide instability.  What does it look like if the "rolling"
> happens on top of an otherwise stable platform where fundamentals like
> compilers, libraries and core system tools are held steady, but things
> on top move fast?  Maybe you don't need an F30.1, maybe it means F30
> just keeps getting nice incremental updates for as long as the
> editions want to stick with it.  Variable lifecycle or cadence can
> open up these kinds of options.  Some things are better fast. Some
> things are better slow.

This.  Yes This. +100

I think that Fedora's role as an innovater in the OS space means we
should be aggressively exploring this.  Rolling Releases, Tech-Driven
Releases and Time-Based Releases all have well known positives and
negatives.  All of the work that has been done on Modularity,
containers, flatpaks, OSTree, and more, gives us the opportunity to
really re-think this.  While it is true there are dozens (or more)
additional solutions to the too-fast/too-slow and the
incompatible-libraries problems, these technologies seem to be gaining
the most adoption across a variety of use cases.  They are all also
generally well supported in Fedora and we need to aggressively push
them to achieve this goal or determine where the dead-end is so we can
move to the next innovation.

I personal am hugely in favor of us adopting a bootable-base model
that allows us to iterate the kernel and the various user-space pieces
at the speed of the upstream, the user's desires and the builder's
desires[^0] all at the same time.  While this will require us to do
some level of NxM matrix building and testing, a base that didn't have
to change often for most use cases reduces the matrix considerably.

I'd push Brendans' concept further and suggest that we try to
eliminate as many of the compilers, libraries and core system tools as
possible from this bootable-base so that those can iterate at their
own speed, perhaps 4 year for a laptop vendor and 30 day for a
experimental ARM device.  Fedora as a project might not build output
for the whole range, but a build system that allowed us to help others
be successful would be a huge help here.

I recognize that I, like most people, see the world through the lens
of my specific use case, but remember, "Fedora creates an innovative
platform for hardware, clouds, and containers that enables software
developers and community members to build tailored solutions for their
users."  As long as we don't block a use cases arbitrarily and we
leave room for that innovation and service we are doing the right
thing.  The debate about what use cases should be done fully by
Fedora, enabled for a SIG/WG via our build system or done externally
by those using only the parts that make sense for them is a separate
debate.

regards,

bex

0: Builder's desires are the desires of the person who put the entire
system together to fulfill the needs of their community per our
mission statement.  If my mythical llama herders need the oldest Libre
Office possible but the newest Rust packaging and whatever random
version of httpd that Fedora deems "stable", then that is what I
desire, even if the upstream or other non-llama herding users desire
something different.  However, I'd also push that we should try to
reach a point where if a llama herder for non-llama reasons needs a
different httpd, they can just enable and use it (using the language
of modularity).  In case it isn't clear, the "builder's desires"
includes the goals of every current lab, spin, and edition, separately
and where appropriate together.
___
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: What does extended F30 cycle mean for F29?

[Tom Hughes]

On 28/11/2018 08:45, Peter Robinson wrote:

On Wed, Nov 28, 2018 at 7:14 AM Kalev Lember  wrote:


If F31 is delayed by 6 months and F30 is supported for 6 months longer,
does it mean F29 *also* automatically gets a longer cycle since it by
policy becomes EOL when F31 is out + 1 month?

Can we EOL F29 6 months before F31 is out to not have *two* long term
branches to maintain?


So going back to memory of what we did in the F-21 cycle, we EOLed
F-19 at the 13 months line and then F-20 continued until a month after
F-22 was out.


End of life is not technically defined as a given number of months but
rather it is defined as one month after the release of the next but one
release so unless that definition was changed that is what would happen:

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#End_of_Life_.28EOL.29

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: What does delaying F31 mean for packagers/users?

[Lukas Ruzicka]

Hello,
I do not think that we should be taking the path towards Gnome being in one
module. This is not, what "modular" means. In my understanding, modules
should be smaller, rather independent units, that will help solve some user
cases, but definitely not upgrading half of the system.
Also, if we should provide updated ISOs, as one of the ideas was, why not
do a normal release instead? It does not have to be packed with all new
stuff, fixes and minor updates could be just fine ... and the new Gnome.
I think there are several strategies, where we could go next, for example:


   - Release regularly to get the new Gnome, but do not push for so many
   new features in Fedora 31, if we need more time to fix things.
   - Adopt the Major / Minor approach and make the autumn release a minor
   one, so that Fedora 31 becomes a minor release.
   - Adopt the "rolling updates" strategy for Fedora and introduce a Fedora
   LTS that would be here for people who do not want rolling updates.
   - Just skip the release with all the consequences it will have ... no
   updates to new versions

Let us not make Fedora messy by creating huge modules with dependencies in
the whole system. It is too risky to go that way, because modularity is
just at its beginning and has issues we must solve first. For example, what
happens if you have a module stream installed and all the dependencies in a
working system and you want to change from one stream to another? As far as
I know, nobody guarantees at the moment, that the dependencies will not
break. Can you image how putting Gnome into a module will affect the system
when this is not solved?

I'd rather see Fedora stay a bit older for a period of time than to see it
breaking and leaving people angry.

Take care,
Lukas




I quite like the idea of one major and one minor release in a year.

I think that Debarshi's approach would work nicely

On Wed, Nov 28, 2018 at 9:34 AM Debarshi Ray  wrote:

> On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
> > One of the key parts of making a decision to delay/skip F31 is
> > figuring out, ahead of the decision, what the expected experience is
> > for users and packagers. Does F30 have normal stability, or do we try
> > to keep users happy by moving things forward with ad-hoc updates and
> > cross-our-fingers and hope nothing breaks?
> >
> > I tend to think about this in terms of GNOME - would we rebase to
> > GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> > pieces of software where similar considerations apply: container
> > tools, cockpit, NetworkManager, etc.
> >
> > And if we did do updates like that, would we consider respinning media
> > and making a "F30.1"?
>
> Umm... can't we treat it the same as the Fedora 20/21 situation?
> Skipping a GNOME release can be a bit painful for the upstream GNOME
> community, which is overwhelmingly tilted towards Fedora, but it's not
> the end of the world either. After all, I don't think the longer
> Fedora 21 cycle had any negative long-term effect on that group at
> all. :)
>
> The Desktop Team could more aggressively backport bug-fixes to GNOME
> 3.34 upstream, and if needed backport selected features to Fedora 30
> downstream. We have done this during the usual six month Fedora
> releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
> have done this for RHEL too, so there's some precedence in this area.
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Last dbus upgrade issues

[Igor Gnatenko]

So I've tried to do following update:
Install  dbus-broker-16-7.fc30.x86_64@rawhide
Upgrade  dbus-1:1.12.10-9.fc30.x86_64@rawhide
Upgraded dbus-1:1.12.10-8.fc30.x86_64@@System
Upgrade  dbus-common-1:1.12.10-9.fc30.noarch @rawhide
Upgraded dbus-common-1:1.12.10-8.fc30.noarch @@System
Upgrade  dbus-daemon-1:1.12.10-9.fc30.x86_64 @rawhide
Upgraded dbus-daemon-1:1.12.10-8.fc30.x86_64 @@System
Upgrade  dbus-libs-1:1.12.10-9.fc30.x86_64   @rawhide
Upgraded dbus-libs-1:1.12.10-8.fc30.x86_64   @@System
Upgrade  dbus-tools-1:1.12.10-9.fc30.x86_64  @rawhide
Upgraded dbus-tools-1:1.12.10-8.fc30.x86_64  @@System
Upgrade  dbus-x11-1:1.12.10-9.fc30.x86_64@rawhide
Upgraded dbus-x11-1:1.12.10-8.fc30.x86_64@@System

I ended up with disabled both dbus-daemon and dbus-broker.
On Mon, Nov 26, 2018 at 3:19 PM Tom Gundersen  wrote:
>
> Hi Tomasz,
>
> On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko  
> wrote:
>>
>> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek 
>>  wrote:
>>>
>>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>>> > After last dbus upgrade gdm found that is not able to start.
>>>
>>> What Fedora version? Ideally provide specific rpm versions.
>>> dbus-in-F29 != dbus-in-F30 now.
>>
>>
>> I’m talking about F30 recent change in which has been implemented switch to 
>> dubs-broker.
>
>
> Thanks for the report, and sorry for the inconvenience. There was indeed a 
> bug in the dbus-broker spec file, which we now fixed with version 16-7 
> (should land in rawhide any minute).
>
>>
>> Ps. If this change has been propagated to F29 (hopefully not) more things 
>> will be screwed.
>
>
> It has not (and will not be).
>
> Cheers,
>
> Tom
> ___
> 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

Schedule for Thursday's FPC Meeting (2018-11-29 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-11-29 17:00 UTC in #fedora-meeting-1 on 
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2018-11-29 09:00 PST  US/Pacific
2018-11-29 12:00 EST  --> US/Eastern <--
2018-11-29 17:00 GMT  Europe/London 
2018-11-29 17:00 UTC  UTC   
2018-11-29 18:00 CET  Europe/Berlin 
2018-11-29 18:00 CET  Europe/Paris  
2018-11-29 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2018-11-30 01:00 HKT  Asia/Hong_Kong
2018-11-30 01:00 +08  Asia/Singapore
2018-11-30 02:00 JST  Asia/Tokyo
2018-11-30 03:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #719 Simplify packaging of forge-hosted projects 
.fpc 719
https://pagure.io/packaging-committee/issue/719

= New business =

#topic #806 Guideline change procedure should be updated for PRs 
.fpc 806
https://pagure.io/packaging-committee/issue/806

#topic #830 Update Python manual byte compilation rules 
.fpc 830
https://pagure.io/packaging-committee/issue/830

#topic #832 Proposal for version guideline overhaul (including tilde) 
.fpc 832
https://pagure.io/packaging-committee/issue/832

#topic #834 Multilib file conflict
.fpc 834
https://pagure.io/packaging-committee/issue/834

= Open Floor = 

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

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Move to an annual platform release starting at F30

[Igor Gnatenko]

On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd
 wrote:
>
> On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson  wrote:
> >
> > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
> >  wrote:
> > >
> > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy  wrote:
> > > > Paul's proposal was definitely a one-time pause for the reasons you
> > > > state.  He requested we follow-up with additional questions and
> > > > suggestions so I'm questioning and suggesting taking it a step
> > > > further.  We talk about rolling releases, but people are skeptical due
> > > > to rawhide instability.  What does it look like if the "rolling"
> > > > happens on top of an otherwise stable platform where fundamentals like
> > > > compilers, libraries and core system tools are held steady, but things
> > > > on top move fast?  Maybe you don't need an F30.1, maybe it means F30
> > > > just keeps getting nice incremental updates for as long as the
> > > > editions want to stick with it.  Variable lifecycle or cadence can
> > > > open up these kinds of options.  Some things are better fast. Some
> > > > things are better slow.
> > >
> > > This.  Yes This. +100
> > >
> > > I think that Fedora's role as an innovater in the OS space means we
> > > should be aggressively exploring this.  Rolling Releases, Tech-Driven
> > > Releases and Time-Based Releases all have well known positives and
> > > negatives.  All of the work that has been done on Modularity,
> > > containers, flatpaks, OSTree, and more, gives us the opportunity to
> > > really re-think this.  While it is true there are dozens (or more)
> > > additional solutions to the too-fast/too-slow and the
> > > incompatible-libraries problems, these technologies seem to be gaining
> > > the most adoption across a variety of use cases.  They are all also
> > > generally well supported in Fedora and we need to aggressively push
> > > them to achieve this goal or determine where the dead-end is so we can
> > > move to the next innovation.
> > >
> > > I personal am hugely in favor of us adopting a bootable-base model
> > > that allows us to iterate the kernel and the various user-space pieces
> > > at the speed of the upstream, the user's desires and the builder's
> > > desires[^0] all at the same time.  While this will require us to do
> > > some level of NxM matrix building and testing, a base that didn't have
> > > to change often for most use cases reduces the matrix considerably.
> >
> > The above doesn't make sense, you're saying "move as fast as upstream"
> > and "a base that doesn't change" in the same context, which is it?
>
> I've failed to be clear - sorry about that.  Let me try again.
>
> Please remember that I tend think from the lens of user space, not
> kernel space.  So there may be detail errors in this, I am hoping the
> concepts are valid though.
>
> In general, I can run various versions of my applications against
> multiple different kernels, for example.  Therefore, if I have a
> kernel that changed once a year, it isn't going to, for many
> applications, stop me from changing versions multiple times during the
> year.  Therefore if Fedora had a stabilized bootable base, I could
> move my applications at the cadence of upstream, or a stabilized
> release (not at all) or at the speed in the middle I want.  Fedora
> might not build the entire range of that, but I am not prevented from
> choosing amongst multiple Fedora provided options (stable vs devel or
> all supported upstream releases, for example).

So you mean that you want CentOS stable base and latest software you want?

> The bootable base would change based on Fedora's needs.  Perhaps we
> decide want to new kernels (again sorry for my failings in this field)
> every 6 months to introduce new drivers and hardware support.  Someone
> who wants faster can self-build for their community/needs more
> frequently or a hardware vendor might want a kernel that doesn't
> change as often and is backported.  Fedora may not build the whole
> range here either.
>
> > > I'd push Brendans' concept further and suggest that we try to
> > > eliminate as many of the compilers, libraries and core system tools as
> > > possible from this bootable-base so that those can iterate at their
> > > own speed, perhaps 4 year for a laptop vendor and 30 day for a
> > > experimental ARM device.  Fedora as a project might not build output
> > > for the whole range, but a build system that allowed us to help others
> > > be successful would be a huge help here.
> >
> > Again what do you even mean by eliminate the compilers? Also how do we
> > not change something core, such as a compiler, for 4 years while also
> > change it every 30 days?
>
> "Eliminate the compilers" was meant to mean, make them modules or
> non-bootable base components as much as possible.  I realize that for
> something like glibc that can be hard to impossible and for things
> like Fortran a non-issue.
>
> Communities have different needs, and every time we 

Re: Last dbus upgrade issues

[Nicolas Mailhot]

Le 2018-11-26 16:08, Bruno Wolff III a écrit :

On Mon, Nov 26, 2018 at 15:57:25 +0100,
 Tomasz Kłoczko  wrote:


4) not able to start gdm (because dbus was not running) blocks any
local login. Simple after such crash it is not possible to open or
switch to any local consoles!!!


I was able to login to a shell, so this one might be configuration 
specific.


I had it too, forcing boot in rescue mode is not the same thing as 
switching to a console (it requires access to the bootloader menu)


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

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Henrique Martins]

My configuration is different, just take as FYI.

> ... it seems that in Fedora 29 /etc/nssswitch.conf ought
> to be a symlink.  This machine has been upgraded from F28
> and this is not the case.  AFAIK I have never edited the
> file.

It is still a file and not a link on my f29, which has been
dnf-upgraded for I can't remember how many revisions. I did
edit nsswitch.conf and remove all mdns references, as I run
a local DNS server.

> # authselect check

It replies with
  Current configuration is valid.
on my system.

> authselect-1.0.2-1.fc29.x86_64
> glibc-2.28-20.fc29.x86_64
> nss-mdns-0.14.1-2.fc29.x86_64
> systemd-libs-239-6.git9f3aed1.fc29.x86_64

I have the same rpms.

> Trying to track down a bug in IPP printing
> (https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

I have avahi/bonjour disabled, thus can't check for this.  I
do have a network printer, on socket://.

-- Henrique
___
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-20181128.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 99/142 (x86_64), 24/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20181127.n.0):

ID: 313100  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/313100
ID: 313101  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/313101
ID: 313104  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/313104
ID: 313105  Test: x86_64 Workstation-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/313105
ID: 313107  Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/313107
ID: 313108  Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/313108
ID: 313109  Test: x86_64 Workstation-live-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/313109
ID: 313110  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/313110
ID: 313111  Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/313111
ID: 313115  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/313115
ID: 313118  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/313118
ID: 313119  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/313119
ID: 313120  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/313120
ID: 313124  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/313124
ID: 313125  Test: x86_64 KDE-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/313125
ID: 313126  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/313126
ID: 313130  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/313130
ID: 313131  Test: x86_64 KDE-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/313131
ID: 313133  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/313133
ID: 313135  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/313135
ID: 313140  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/313140
ID: 313141  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/313141
ID: 313142  Test: x86_64 Silverblue-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/313142
ID: 313154  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/313154
ID: 313198  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/313198
ID: 313202  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/313202
ID: 313205  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/313205
ID: 313206  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/313206
ID: 313207  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/313207
ID: 313209  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/313209
ID: 313210  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/313210

Old failures (same test failed in Rawhide-20181127.n.0):

ID: 313071  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/313071
ID: 313072  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/313072
ID: 313073  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/313073
ID: 313074  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/313074
ID: 313081  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/313081
ID: 313098  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/313098
ID: 313099  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/313099
ID: 313102  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/313102
ID: 313106  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/313106
ID: 313112  Test: x86_64 Workstation-live-iso desktop_browser
URL: 

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Ralf Corsepius]

On 11/28/18 3:45 PM, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link,


It's authselect.

# rpm -qV glibc
L  c /etc/nsswitch.conf


# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


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

Can't set initial passwd

[Ralf Corsepius]

Hi,

I am facing a weird problem with creating a new user account:

Create a new user:
# adduser -m tester

Trying to change his passwd:
# passwd tester
Changing password for user tester.

At this point, passwd hangs and doesn't do anything.
I am not getting the "usual" passwd-prompt.

What's going on here?

Ralf
___
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: Move to an annual platform release starting at F30

[Mohan Boddu]

I totally agree with Paul and Kevin.

I want to see a faster release cycle (probably rolling release) and shorter
processes to get a release out.

On Tue, Nov 27, 2018 at 3:02 PM Kevin Fenzi  wrote:

> I agree with the folks in this subthread, but I think we are going to
> have to look at 'redesigning' things more than just 'optimizing'.
>
> ie, collect all our inputs and outputs and things we need to do in the
> process and figure out how to make it modular (no relation) so we can
> look at just a single changed input and quickly test and generate all
> the outputs that are affected by that input (and not any of the others).
>
> For example, a new xfce4-settings package comes out, we want to test it,
> test the Xfce live media and if it all passes, perhaps release that media.
>
If we can do this, we can release different artifacts at different times
which
gives more comfort and flexibility to different WG's.

>
> It may well be that we can figure out a 'base platform' just by looking
> at these imput/outputs: what things are in most or all outputs?
>
> kevin
>
>
> ___
> 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: /etc/nssswitch.conf is supposed to be a symlink now?

[Tom Hughes]

On 28/11/2018 14:45, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.


That's true but...


If find out which packages replaces our configuration with a symbolic
link, please file a bug against that package.  If they want to take over
/etc/nsswitch.conf, this is negotiable, but it needs coordination with
the glibc package.


...as I understood it under the old authconfig regime the glibc
installed version was overwritten by the authconfig generated version
as part of the install? and I thought authselect was supposed to
have taken over that role.

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: Fedora Lifecycles: imagine longer-term possibilities

[Brian (bex) Exelbierd]

On Wed, Nov 28, 2018 at 2:53 PM Nicolas Mailhot
 wrote:
>
> Le 2018-11-26 12:31, Brian (bex) Exelbierd a écrit :
>
> >
> > I agree that we need a beta vs stable pathway, but I am not sure
> > having a release helps us.
>
> If we want hardware manufacturers to ship Fedora-compatible hardware we
> need to ship them official Fedora starting points. "Just pick any",
> spend months QAing, and then get told you didn't choose the right
> starting point won't fly with them.

I don't think that formal releases and "pick any random thing you
like" represents the full range of options here.  We have a "stable
stream and we have a beta stream" is neither of those but does provide
clarity.

regards,

bex

>
> --
> Nicolas Mailhot



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

Fedora rawhide compose report: 20181128.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181127.n.0
NEW: Fedora-Rawhide-20181128.n.0

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

Size of added packages:  32.88 MiB
Size of dropped packages:301.12 KiB
Size of upgraded packages:   3.87 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -806.23 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: blaze-3.4-1.fc30
Summary: An high-performance C++ math library for dense and sparse arithmetic
RPMs:blaze-devel
Size:7.58 MiB

Package: gnome-shell-extension-gsconnect-16-1.fc30
Summary: KDE Connect implementation for GNOME Shell
RPMs:gnome-shell-extension-gsconnect nautilus-gsconnect 
webextension-gsconnect
Size:1.21 MiB

Package: ocaml-lwt-log-1.1.0-2.fc30
Summary: Lwt logging library
RPMs:ocaml-lwt-log ocaml-lwt-log-devel
Size:1.64 MiB

Package: php-maxminddb-1.4.0-1.fc30
Summary: MaxMind DB Reader extension
RPMs:php-maxmind-db-reader php-maxminddb
Size:159.84 KiB

Package: python-chaospy-2.3.5-1.fc30
Summary: Numerical tool for performing uncertainty quantification using 
polynomial
RPMs:python-chaospy-doc python3-chaospy
Size:21.90 MiB

Package: python-mne-bids-0.1-2.fc30
Summary: Experimental code for BIDS using MNE
RPMs:python3-mne-bids
Size:45.25 KiB

Package: python-pynwb-0.6.1-3.fc30
Summary: PyNWB is a Python package for working with NWB files
RPMs:python3-pynwb
Size:272.05 KiB

Package: python-spake2-0.8-1.fc30
Summary: SPAKE2 password-authenticated key exchange
RPMs:python3-spake2
Size:84.17 KiB


= DROPPED PACKAGES =
Package: dd-plist-1.21-1.fc30
Summary: A java library providing support for ASCII, XML and binary property 
lists
RPMs:dd-plist dd-plist-javadoc
Size:150.38 KiB

Package: directory-maven-plugin-0.3.1-1.fc30
Summary: Establish locations for files in multi-module builds
RPMs:directory-maven-plugin directory-maven-plugin-javadoc
Size:54.11 KiB

Package: ee4j-parent-1.0.1-1.fc30
Summary: Parent POM file for Eclipse Enterprise for Java projects
RPMs:ee4j-parent
Size:10.35 KiB

Package: owasp-java-encoder-1.2.2-1.fc30
Summary: Collection of high-performance low-overhead contextual encoders
RPMs:owasp-java-encoder owasp-java-encoder-javadoc
Size:86.30 KiB


= UPGRADED PACKAGES =
Package:  appstream-0.12.3-1.fc30
Old package:  appstream-0.12.2-2.fc30
Summary:  Utilities to generate, maintain and access the AppStream database
RPMs: appstream appstream-devel appstream-qt appstream-qt-devel 
appstream-vala
Size: 12.11 MiB
Size change:  2.33 KiB
Changelog:
  * Tue Nov 27 2018 Rex Dieter  - 0.12.3-1
  - 0.12.3


Package:  bluedevil-5.14.4-1.fc30
Old package:  bluedevil-5.14.3-1.fc30
Summary:  Bluetooth stack for KDE
RPMs: bluedevil
Size: 2.16 MiB
Size change:  -96 B
Changelog:
  * Tue Nov 27 2018 Rex Dieter  - 5.14.4-1
  - 5.14.4


Package:  bodhi-3.11.1-100.fc30
Old package:  bodhi-3.11.0-1.fc30
Summary:  A modular framework that facilitates publishing software updates
RPMs: bodhi-client bodhi-composer bodhi-docs bodhi-server python2-bodhi 
python2-bodhi-client python3-bodhi python3-bodhi-client
Size: 5.99 MiB
Size change:  2.19 KiB
Changelog:
  * Fri Nov 16 2018 Randy Barlow  - 3.11.0-3
  - Bump the release to 3 so that f29-infra has a newer version than f29.

  * Tue Nov 27 2018 Randy Barlow  - 3.11.1-100
  - Update to 3.11.1.


Package:  breeze-gtk-5.14.4-1.fc30
Old package:  breeze-gtk-5.14.3-1.fc30
Summary:  Breeze widget theme for Gtk2 and Gtk3
RPMs: breeze-gtk
Size: 1.77 MiB
Size change:  52 B
Changelog:
  * Tue Nov 27 2018 Rex Dieter  - 5.14.4-1
  - 5.14.4


Package:  btrbk-0.27.0-1.fc30
Old package:  btrbk-0.26.1-4.fc29
Summary:  Tool for creating snapshots and remote backups of btrfs 
sub-volumes
RPMs: btrbk
Size: 111.71 KiB
Size change:  3.18 KiB
Changelog:
  * Tue Nov 27 2018 Michael Goodwin  - 0.27.0-1
  - Update to 0.27.0


Package:  buildah-1.6-3.dev.git4126176.fc30
Old package:  buildah-1.6-2.dev.gitd5a3c52.fc30
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 23.53 MiB
Size change:  504 B
Changelog:
  * Wed Nov 28 2018 Lokesh Mandvekar (Bot)  - 
1.6-3.dev.git4126176
  - autobuilt 4126176


Package:  chromium-70.0.3538.110-1.fc30
Old package:  chromium-70.0.3538.77-4.fc30
Summary:  A WebKit (Blink) powered web browser
RPMs: chrome-remote-desktop chromedriver chromium chromium-common 
chromium-headless chromium-libs chromium-libs-media
Size: 815.40 MiB
Size change:  -14.11 KiB
Changelog:
  * Mon Nov 26 2018 Tom Callaway  - 70.0.3538.110-1
  - update to .110


Package:  clang-7.0.0-5.fc30
Old package:  clang-7.0.0-4.fc30

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Ralf Corsepius]

On 11/28/18 4:37 PM, Robert Marcano wrote:

On 11/28/18 11:20 AM, Ralf Corsepius wrote:



# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


My clean F29 installation had no such symbolic link, has to "authselect 
select --force ..." to force the creation of the link.


You are probably right.

I missed to mention, I currently am using authselect's "nis"-profile, 
because upgrading from f28 to f29 has screwed up my handcrafted 
nsswitch.conf, leaving me with semi-dysfunctional systems, which had 
caused me to experiment with authselect's "nis"-profile.


Ralf
___
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: Move to an annual platform release starting at F30

[Owen Taylor]

On Wed, Nov 28, 2018 at 3:07 AM Brian (bex) Exelbierd
 wrote:

> I think that Fedora's role as an innovater in the OS space means we
> should be aggressively exploring this.  Rolling Releases, Tech-Driven
> Releases and Time-Based Releases all have well known positives and
> negatives.  All of the work that has been done on Modularity,
> containers, flatpaks, OSTree, and more, gives us the opportunity to
> really re-think this.  While it is true there are dozens (or more)
> additional solutions to the too-fast/too-slow and the
> incompatible-libraries problems, these technologies seem to be gaining
> the most adoption across a variety of use cases.  They are all also
> generally well supported in Fedora and we need to aggressively push
> them to achieve this goal or determine where the dead-end is so we can
> move to the next innovation.

We have a lot of flexibility with all these technologies. What we need
to achieve through our processes - CI, the release process, etc, is to
enable users to take advantage of the technologies to achieve their
goals - to get their work done - without having new problems thrown at
them - excessive complexity, instability, etc.

> I personal am hugely in favor of us adopting a bootable-base model
> that allows us to iterate the kernel and the various user-space pieces
> at the speed of the upstream, the user's desires and the builder's
> desires[^0] all at the same time.  While this will require us to do
> some level of NxM matrix building and testing, a base that didn't have
> to change often for most use cases reduces the matrix considerably.

The term "bootable-base" concerns me - because it could be interpreted
to mean a minimal bootable set - just enough to get systemd and dnf
running, perhaps. In another mail, you explained what you meant as
"light up the machine level [...] and get containers/flatpaks/etc
running". What does it take to get containers running usefully? It
probably looks quite a bit like Fedora CoreOS. What does it take to
get Flatpaks running in a useful way to users? - you need a full
desktop environment - something like Fedora Silverblue (or the default
install set of Fedora Workstation if you prefer loose packages).

While the Fedora release today contains a lot more software than this
"core operating system" - generally our release processes today are
targeted at trying to release a stable core operating system - and
this is something we can't lose if we start changing around how things
work. It's not that I don't think the maintenance of glibc and gcc is
really important, but if we refocus our release processes only on
that, and one day a broken wpa-supplicant rebase lands and half our
users lose networking - that would be a really poor outcome for
Fedora.

> I'd push Brendans' concept further and suggest that we try to
> eliminate as many of the compilers, libraries and core system tools as
> possible from this bootable-base so that those can iterate at their
> own speed, perhaps 4 year for a laptop vendor and 30 day for a
> experimental ARM device.  Fedora as a project might not build output
> for the whole range, but a build system that allowed us to help others
> be successful would be a huge help here.

Fedora needs to be an operating system provider, not just an operating
system toolbox provider. There are a lot of use cases for the
"operating system toolbox"

 - To build the operating systems that Fedora releases - CoreOS,
Workstation, etc.
 - To create the containers, Flatpak runtimes, and Flatpaks that Fedora releases
 - For users to create application containers
 - To create development environments (pet containers)
 - For adventurous users to create new, customized operating systems

but you can't do integration testing on operating system toolbox,
because the whole point is that you can integrated it any way you want
and only the end user defines what is broken and what is working.
Producing a *quality* operating system requires us to focus our
processes on the integrated operating systems that we produce, on the
applications we produce - and that's what our processes should be
around.

Could we replace the current 6 month release processes with an
alternate set of processes around multiple rolling branches? It's
certainly a possibility, but it's going to be very difficult to get a
high level of stability - a level of stability that is acceptable to
all end users - without a process where the *entire operating system*
gets beta tested before being pushed out.

If we want to move in the direction of rolling releases, the first
step is to get the continuous integration testing and gating in place
to make rawhide consumable by a broader set of people. That would be
incredibly useful even if we keep the current 6 month tempo, but
essential if we want to move to a rolling stable model. Until we can
demonstrate that, it seems really premature to talk about rolling
stable models.

Owen
___
devel 

replace unclutter with unclutter-xfixes?

[Henrique Martins]

Unclutter seems to be an orphaned package that keeps being
rebuilt, there even is an fc30 rpm.  The URL given in the
fc29 package points to a dead link on MIT.  I filed a
bugzilla report on this and no one replied.

Rdesktop seems to haven been obsoleted. It has its problems,
mostly excessive refreshes that can freeze the display for
long periods of time. The rdesktop package on my system is
for fc24.

One of its replacements is xfreerdp.  No combination of
unclutter's options seem to work without interfering with
xfreerdp, short of making unclutter not hide the cursor in
those windows which I'd like to do.  (When unclutter wakes
up to check for mouse moves, it temporarily steals the mouse
from xfreerdp which causes it to reset the keyboard, loosing
the state of modifiers keys, e.g. control being held down.)

There is an utility called unclutter-xfixes on github
  http://github.com/Airblader/unclutter-xfixes
which is a rewrite based on the X11-xfixes library and works
much better than the old unclutter.

There is a COPR build of unclutter-xfixes
  https://copr.fedorainfracloud.org/coprs/nbeernink/unclutter-xfixes/
Most other distros seem to have it as an optional package.

I've recently submitted a pull request to unclutter-xfixes
that will make it accept all unclutter flags and behave like
unclutter did.  It ignores a couple of flags that don't make
sense with xfixes, without any loss of functionality.

Once accepted, it will be an almost drop-in replacement for
unclutter, maybe needing a couple of minor tweaks: it uses
the same binary name, it calls itself unclutter-xfixes under
usage, the man page is unclutter-xfixes, not unclutter.

Could Fedora replace unclutter with unclutter-xfixes?

-- Henrique
___
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: /etc/nssswitch.conf is supposed to be a symlink now?

[Robert Marcano]

On 11/28/18 11:20 AM, Ralf Corsepius wrote:

On 11/28/18 3:45 PM, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link,


It's authselect.

# rpm -qV glibc
L  c /etc/nsswitch.conf


# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


My clean F29 installation had no such symbolic link, has to "authselect 
select --force ..." to force the creation of the link.


The non symlinked /etc/nsswitch.conf even had the header:

  # Do not modify this file manually.

  # If you want to make changes to nsswitch.conf please modify
  # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.

So, was it generated at some point by authselect and not as symbolic link?

Note: Today I got new update for authselect (1.0.2-1.fc29)



Ralf
___
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: /etc/nssswitch.conf is supposed to be a symlink now?

[Robert Marcano]

On 11/28/18 11:37 AM, Robert Marcano wrote:

On 11/28/18 11:20 AM, Ralf Corsepius wrote:

On 11/28/18 3:45 PM, Florian Weimer wrote:

* Richard W. M. Jones:


Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link,


It's authselect.

# rpm -qV glibc
L  c /etc/nsswitch.conf


# ls -l /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> 
/etc/authselect/nsswitch.conf


My clean F29 installation had no such symbolic link, has to "authselect 
select --force ..." to force the creation of the link.


The non symlinked /etc/nsswitch.conf even had the header:

   # Do not modify this file manually.

   # If you want to make changes to nsswitch.conf please modify
   # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.

So, was it generated at some point by authselect and not as symbolic link?

Note: Today I got new update for authselect (1.0.2-1.fc29)


There is another thing I found wrong. The backed up nsswitch.conf has 
these lines appended (ckey and incomplete aliases line) after the real 
end of the original file (aliases: files):


  aliases:files
  ckey:  files

  aliases:fil

I can repeat this bad backup indefinitely:

1) check current nsswitch has no such lines
2) run authselect select --force ...
3) backup at /usr/lib/authselect/backup//nsswitch has the 
appended lines






Ralf
___
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: Last dbus upgrade issues

[Igor Gnatenko]

I don't have time to revert back and try updating again, but the fix looks good!

Thanks!
On Wed, Nov 28, 2018 at 1:19 PM Tom Gundersen  wrote:
>
> Hi Igor,
>
> The upgrade path should hopefully be fixed with dbus-broker-16-8.
>
> Cheers,
>
> Tom
>
> On Wed, Nov 28, 2018 at 10:33 AM Igor Gnatenko 
>  wrote:
>>
>> So I've tried to do following update:
>> Install  dbus-broker-16-7.fc30.x86_64@rawhide
>> Upgrade  dbus-1:1.12.10-9.fc30.x86_64@rawhide
>> Upgraded dbus-1:1.12.10-8.fc30.x86_64@@System
>> Upgrade  dbus-common-1:1.12.10-9.fc30.noarch @rawhide
>> Upgraded dbus-common-1:1.12.10-8.fc30.noarch @@System
>> Upgrade  dbus-daemon-1:1.12.10-9.fc30.x86_64 @rawhide
>> Upgraded dbus-daemon-1:1.12.10-8.fc30.x86_64 @@System
>> Upgrade  dbus-libs-1:1.12.10-9.fc30.x86_64   @rawhide
>> Upgraded dbus-libs-1:1.12.10-8.fc30.x86_64   @@System
>> Upgrade  dbus-tools-1:1.12.10-9.fc30.x86_64  @rawhide
>> Upgraded dbus-tools-1:1.12.10-8.fc30.x86_64  @@System
>> Upgrade  dbus-x11-1:1.12.10-9.fc30.x86_64@rawhide
>> Upgraded dbus-x11-1:1.12.10-8.fc30.x86_64@@System
>>
>> I ended up with disabled both dbus-daemon and dbus-broker.
>> On Mon, Nov 26, 2018 at 3:19 PM Tom Gundersen  wrote:
>> >
>> > Hi Tomasz,
>> >
>> > On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko  
>> > wrote:
>> >>
>> >> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek 
>> >>  wrote:
>> >>>
>> >>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>> >>> > After last dbus upgrade gdm found that is not able to start.
>> >>>
>> >>> What Fedora version? Ideally provide specific rpm versions.
>> >>> dbus-in-F29 != dbus-in-F30 now.
>> >>
>> >>
>> >> I’m talking about F30 recent change in which has been implemented switch 
>> >> to dubs-broker.
>> >
>> >
>> > Thanks for the report, and sorry for the inconvenience. There was indeed a 
>> > bug in the dbus-broker spec file, which we now fixed with version 16-7 
>> > (should land in rawhide any minute).
>> >
>> >>
>> >> Ps. If this change has been propagated to F29 (hopefully not) more things 
>> >> will be screwed.
>> >
>> >
>> > It has not (and will not be).
>> >
>> > Cheers,
>> >
>> > Tom
>> > ___
>> > 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
>
> ___
> 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: Move to an annual platform release starting at F30

[Igor Gnatenko]

On Wed, Nov 28, 2018 at 1:49 PM Brian (bex) Exelbierd
 wrote:
>
> On Wed, Nov 28, 2018 at 1:31 PM Igor Gnatenko
>  wrote:
> >
> > On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd
> >  wrote:
> > >
> > > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson  
> > > wrote:
> > > >
> > > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
> > > >  wrote:
> > > > >
> > > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy  
> > > > > wrote:
> > > > > > Paul's proposal was definitely a one-time pause for the reasons you
> > > > > > state.  He requested we follow-up with additional questions and
> > > > > > suggestions so I'm questioning and suggesting taking it a step
> > > > > > further.  We talk about rolling releases, but people are skeptical 
> > > > > > due
> > > > > > to rawhide instability.  What does it look like if the "rolling"
> > > > > > happens on top of an otherwise stable platform where fundamentals 
> > > > > > like
> > > > > > compilers, libraries and core system tools are held steady, but 
> > > > > > things
> > > > > > on top move fast?  Maybe you don't need an F30.1, maybe it means F30
> > > > > > just keeps getting nice incremental updates for as long as the
> > > > > > editions want to stick with it.  Variable lifecycle or cadence can
> > > > > > open up these kinds of options.  Some things are better fast. Some
> > > > > > things are better slow.
> > > > >
> > > > > This.  Yes This. +100
> > > > >
> > > > > I think that Fedora's role as an innovater in the OS space means we
> > > > > should be aggressively exploring this.  Rolling Releases, Tech-Driven
> > > > > Releases and Time-Based Releases all have well known positives and
> > > > > negatives.  All of the work that has been done on Modularity,
> > > > > containers, flatpaks, OSTree, and more, gives us the opportunity to
> > > > > really re-think this.  While it is true there are dozens (or more)
> > > > > additional solutions to the too-fast/too-slow and the
> > > > > incompatible-libraries problems, these technologies seem to be gaining
> > > > > the most adoption across a variety of use cases.  They are all also
> > > > > generally well supported in Fedora and we need to aggressively push
> > > > > them to achieve this goal or determine where the dead-end is so we can
> > > > > move to the next innovation.
> > > > >
> > > > > I personal am hugely in favor of us adopting a bootable-base model
> > > > > that allows us to iterate the kernel and the various user-space pieces
> > > > > at the speed of the upstream, the user's desires and the builder's
> > > > > desires[^0] all at the same time.  While this will require us to do
> > > > > some level of NxM matrix building and testing, a base that didn't have
> > > > > to change often for most use cases reduces the matrix considerably.
> > > >
> > > > The above doesn't make sense, you're saying "move as fast as upstream"
> > > > and "a base that doesn't change" in the same context, which is it?
> > >
> > > I've failed to be clear - sorry about that.  Let me try again.
> > >
> > > Please remember that I tend think from the lens of user space, not
> > > kernel space.  So there may be detail errors in this, I am hoping the
> > > concepts are valid though.
> > >
> > > In general, I can run various versions of my applications against
> > > multiple different kernels, for example.  Therefore, if I have a
> > > kernel that changed once a year, it isn't going to, for many
> > > applications, stop me from changing versions multiple times during the
> > > year.  Therefore if Fedora had a stabilized bootable base, I could
> > > move my applications at the cadence of upstream, or a stabilized
> > > release (not at all) or at the speed in the middle I want.  Fedora
> > > might not build the entire range of that, but I am not prevented from
> > > choosing amongst multiple Fedora provided options (stable vs devel or
> > > all supported upstream releases, for example).
> >
> > So you mean that you want CentOS stable base and latest software you want?
>
> Nope.  I want CentOS to serve their user base.  If the CentOS project
> chooses to formally become part of Fedora and to release a
> longer-maintained base to their users under the banner of our mission,
> I welcome them with open arms.  But, that is their decision.
>
> I don't think Fedora wants to get into 10 year life cycles and that
> level of backporting.  But, accepting a new kernel/bootable base
> shouldn't force me to take a new version of LibreOffice, for example.

So what you are saying here is what "first" version of Modularity was
about. And it didn't work out because of many reasons. One of them is
no useful CI infrastructure (still not solved) which didn't allow
packagers to remove useless BuildRequires for tests (because rpmbuild
is still tte way to run test suite).

If we can get commitment from people who maintain "minimal viable
base" to move their tests to CI and get FTBFS fixes in time -- it
might work.

> > > The bootable base 

Re: Fedora Lifecycles: imagine longer-term possibilities

[Nicolas Mailhot]

Le 2018-11-26 12:31, Brian (bex) Exelbierd a écrit :



I agree that we need a beta vs stable pathway, but I am not sure
having a release helps us.


If we want hardware manufacturers to ship Fedora-compatible hardware we 
need to ship them official Fedora starting points. "Just pick any", 
spend months QAing, and then get told you didn't choose the right 
starting point won't fly with them.


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

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Tom Hughes]

On 28/11/2018 13:40, Richard W.M. Jones wrote:


We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.


Well I though authselect was supposed to be the default
now in which case yes it would be but I just checked a
clean install of F29 that I did and authselect doesn't
seem to be active there either.

I was actually interested because I was trying to find
out what the current Fedora defaults for the nss databases
that authselect doesn't handle should be on a machine
where I had enabled authselect and I was wondering how
the installer handled that, but apparently it doesn't ;-)

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: Proposal: Move to an annual platform release starting at F30

[Brian (bex) Exelbierd]

On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson  wrote:
>
> On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
>  wrote:
> >
> > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy  wrote:
> > > Paul's proposal was definitely a one-time pause for the reasons you
> > > state.  He requested we follow-up with additional questions and
> > > suggestions so I'm questioning and suggesting taking it a step
> > > further.  We talk about rolling releases, but people are skeptical due
> > > to rawhide instability.  What does it look like if the "rolling"
> > > happens on top of an otherwise stable platform where fundamentals like
> > > compilers, libraries and core system tools are held steady, but things
> > > on top move fast?  Maybe you don't need an F30.1, maybe it means F30
> > > just keeps getting nice incremental updates for as long as the
> > > editions want to stick with it.  Variable lifecycle or cadence can
> > > open up these kinds of options.  Some things are better fast. Some
> > > things are better slow.
> >
> > This.  Yes This. +100
> >
> > I think that Fedora's role as an innovater in the OS space means we
> > should be aggressively exploring this.  Rolling Releases, Tech-Driven
> > Releases and Time-Based Releases all have well known positives and
> > negatives.  All of the work that has been done on Modularity,
> > containers, flatpaks, OSTree, and more, gives us the opportunity to
> > really re-think this.  While it is true there are dozens (or more)
> > additional solutions to the too-fast/too-slow and the
> > incompatible-libraries problems, these technologies seem to be gaining
> > the most adoption across a variety of use cases.  They are all also
> > generally well supported in Fedora and we need to aggressively push
> > them to achieve this goal or determine where the dead-end is so we can
> > move to the next innovation.
> >
> > I personal am hugely in favor of us adopting a bootable-base model
> > that allows us to iterate the kernel and the various user-space pieces
> > at the speed of the upstream, the user's desires and the builder's
> > desires[^0] all at the same time.  While this will require us to do
> > some level of NxM matrix building and testing, a base that didn't have
> > to change often for most use cases reduces the matrix considerably.
>
> The above doesn't make sense, you're saying "move as fast as upstream"
> and "a base that doesn't change" in the same context, which is it?

I've failed to be clear - sorry about that.  Let me try again.

Please remember that I tend think from the lens of user space, not
kernel space.  So there may be detail errors in this, I am hoping the
concepts are valid though.

In general, I can run various versions of my applications against
multiple different kernels, for example.  Therefore, if I have a
kernel that changed once a year, it isn't going to, for many
applications, stop me from changing versions multiple times during the
year.  Therefore if Fedora had a stabilized bootable base, I could
move my applications at the cadence of upstream, or a stabilized
release (not at all) or at the speed in the middle I want.  Fedora
might not build the entire range of that, but I am not prevented from
choosing amongst multiple Fedora provided options (stable vs devel or
all supported upstream releases, for example).

The bootable base would change based on Fedora's needs.  Perhaps we
decide want to new kernels (again sorry for my failings in this field)
every 6 months to introduce new drivers and hardware support.  Someone
who wants faster can self-build for their community/needs more
frequently or a hardware vendor might want a kernel that doesn't
change as often and is backported.  Fedora may not build the whole
range here either.

> > I'd push Brendans' concept further and suggest that we try to
> > eliminate as many of the compilers, libraries and core system tools as
> > possible from this bootable-base so that those can iterate at their
> > own speed, perhaps 4 year for a laptop vendor and 30 day for a
> > experimental ARM device.  Fedora as a project might not build output
> > for the whole range, but a build system that allowed us to help others
> > be successful would be a huge help here.
>
> Again what do you even mean by eliminate the compilers? Also how do we
> not change something core, such as a compiler, for 4 years while also
> change it every 30 days?

"Eliminate the compilers" was meant to mean, make them modules or
non-bootable base components as much as possible.  I realize that for
something like glibc that can be hard to impossible and for things
like Fortran a non-issue.

Communities have different needs, and every time we freeze or force
change we create challenges for those needs to be met.  My point is
that by keeping our base to the "light up the machine level (another
hated idiom) and get containers/flatpaks/etc running" we can allow the
builder to focus on their community's needs or the user to get their
own 

/etc/nssswitch.conf is supposed to be a symlink now?

[Richard W.M. Jones]

Trying to track down a bug in IPP printing
(https://bugzilla.redhat.com/show_bug.cgi?id=1653276).

We're down a rabbit hole where it seems that in Fedora 29
/etc/nssswitch.conf ought to be a symlink.  This machine has been
upgraded from F28 and this is not the case.  AFAIK I have never edited
the file.

Also:

# authselect check
[error] [/etc/authselect/system-auth] has unexpected content!
[error] [/etc/authselect/password-auth] has unexpected content!
[error] [/etc/authselect/fingerprint-auth] has unexpected content!
[error] [/etc/authselect/nsswitch.conf] has unexpected content!
[error] [/etc/authselect/dconf-db] has unexpected content!
[error] [/etc/nsswitch.conf] is not a symbolic link!
[error] [/etc/nsswitch.conf] was not created by authselect!
Current configuration is not valid. It was probably modified outside authselect.

which sounds bad, but the error message is not actionable: no
indication how this happened nor how to fix it.

authselect-1.0.2-1.fc29.x86_64
glibc-2.28-20.fc29.x86_64
nss-mdns-0.14.1-2.fc29.x86_64
systemd-libs-239-6.git9f3aed1.fc29.x86_64

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: Last dbus upgrade issues

[Tom Gundersen]

Hi Igor,

The upgrade path should hopefully be fixed with dbus-broker-16-8.

Cheers,

Tom

On Wed, Nov 28, 2018 at 10:33 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> So I've tried to do following update:
> Install  dbus-broker-16-7.fc30.x86_64@rawhide
> Upgrade  dbus-1:1.12.10-9.fc30.x86_64@rawhide
> Upgraded dbus-1:1.12.10-8.fc30.x86_64@@System
> Upgrade  dbus-common-1:1.12.10-9.fc30.noarch @rawhide
> Upgraded dbus-common-1:1.12.10-8.fc30.noarch @@System
> Upgrade  dbus-daemon-1:1.12.10-9.fc30.x86_64 @rawhide
> Upgraded dbus-daemon-1:1.12.10-8.fc30.x86_64 @@System
> Upgrade  dbus-libs-1:1.12.10-9.fc30.x86_64   @rawhide
> Upgraded dbus-libs-1:1.12.10-8.fc30.x86_64   @@System
> Upgrade  dbus-tools-1:1.12.10-9.fc30.x86_64  @rawhide
> Upgraded dbus-tools-1:1.12.10-8.fc30.x86_64  @@System
> Upgrade  dbus-x11-1:1.12.10-9.fc30.x86_64@rawhide
> Upgraded dbus-x11-1:1.12.10-8.fc30.x86_64@@System
>
> I ended up with disabled both dbus-daemon and dbus-broker.
> On Mon, Nov 26, 2018 at 3:19 PM Tom Gundersen  wrote:
> >
> > Hi Tomasz,
> >
> > On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko <
> kloczko.tom...@gmail.com> wrote:
> >>
> >> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> >>>
> >>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
> >>> > After last dbus upgrade gdm found that is not able to start.
> >>>
> >>> What Fedora version? Ideally provide specific rpm versions.
> >>> dbus-in-F29 != dbus-in-F30 now.
> >>
> >>
> >> I’m talking about F30 recent change in which has been implemented
> switch to dubs-broker.
> >
> >
> > Thanks for the report, and sorry for the inconvenience. There was indeed
> a bug in the dbus-broker spec file, which we now fixed with version 16-7
> (should land in rawhide any minute).
> >
> >>
> >> Ps. If this change has been propagated to F29 (hopefully not) more
> things will be screwed.
> >
> >
> > It has not (and will not be).
> >
> > Cheers,
> >
> > Tom
> > ___
> > 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
>
___
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: Move to an annual platform release starting at F30

[Fabio Valentini]

On Wed, Nov 28, 2018 at 1:07 PM Brian (bex) Exelbierd
 wrote:
>
> On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson  wrote:
> >
> > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
> >  wrote:
> > >
> > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy  wrote:
> > > > Paul's proposal was definitely a one-time pause for the reasons you
> > > > state.  He requested we follow-up with additional questions and
> > > > suggestions so I'm questioning and suggesting taking it a step
> > > > further.  We talk about rolling releases, but people are skeptical due
> > > > to rawhide instability.  What does it look like if the "rolling"
> > > > happens on top of an otherwise stable platform where fundamentals like
> > > > compilers, libraries and core system tools are held steady, but things
> > > > on top move fast?  Maybe you don't need an F30.1, maybe it means F30
> > > > just keeps getting nice incremental updates for as long as the
> > > > editions want to stick with it.  Variable lifecycle or cadence can
> > > > open up these kinds of options.  Some things are better fast. Some
> > > > things are better slow.
> > >
> > > This.  Yes This. +100
> > >
> > > I think that Fedora's role as an innovater in the OS space means we
> > > should be aggressively exploring this.  Rolling Releases, Tech-Driven
> > > Releases and Time-Based Releases all have well known positives and
> > > negatives.  All of the work that has been done on Modularity,
> > > containers, flatpaks, OSTree, and more, gives us the opportunity to
> > > really re-think this.  While it is true there are dozens (or more)
> > > additional solutions to the too-fast/too-slow and the
> > > incompatible-libraries problems, these technologies seem to be gaining
> > > the most adoption across a variety of use cases.  They are all also
> > > generally well supported in Fedora and we need to aggressively push
> > > them to achieve this goal or determine where the dead-end is so we can
> > > move to the next innovation.
> > >
> > > I personal am hugely in favor of us adopting a bootable-base model
> > > that allows us to iterate the kernel and the various user-space pieces
> > > at the speed of the upstream, the user's desires and the builder's
> > > desires[^0] all at the same time.  While this will require us to do
> > > some level of NxM matrix building and testing, a base that didn't have
> > > to change often for most use cases reduces the matrix considerably.
> >
> > The above doesn't make sense, you're saying "move as fast as upstream"
> > and "a base that doesn't change" in the same context, which is it?
>
> I've failed to be clear - sorry about that.  Let me try again.
>
> Please remember that I tend think from the lens of user space, not
> kernel space.  So there may be detail errors in this, I am hoping the
> concepts are valid though.
>
> In general, I can run various versions of my applications against
> multiple different kernels, for example.  Therefore, if I have a
> kernel that changed once a year, it isn't going to, for many
> applications, stop me from changing versions multiple times during the
> year.  Therefore if Fedora had a stabilized bootable base, I could
> move my applications at the cadence of upstream, or a stabilized
> release (not at all) or at the speed in the middle I want.  Fedora
> might not build the entire range of that, but I am not prevented from
> choosing amongst multiple Fedora provided options (stable vs devel or
> all supported upstream releases, for example).

I think the kernel is a bad example here. It's exceedly stable across
releases, so it's probably the one component that's least problematic
to upgrade during a fedora release. The fedora kernel team is already
doing that, and they are doing an excellent job, which they definitely
deserve more praise for than they get. For me, the frequent,
well-executed stable kernel updates are one thing that positively
distinguishes fedora from other non-rolling distros.

On the other hand, specific releases of GCC, glibc, (golang, ruby,
python, ocaml, perl, node, insert other compilers / interpreters here)
would be better examples of a "stable base". They really warrant "new
releases", since major updates of those components usually require
mass rebuilds of their dependent packages.

So, I'd rather draw the line between "base" and "rolling application
releases" *atop* the development environment that the versions of GCC,
glibc, python, golang, etc. make up, not below them. This is what many
packagers already do, from my experience. GNOME really is an exception
here, even KDE/KF5/Plasma is updated regularly during stable releases.

Whether the "base" system (that's used for development and building
all other packages atop it) is released every 6 months (aligning with
semi-annual releases of i.e. golang) or yearly (more in line with
~annual releases of GCC, python, etc.) isn't as important then, since
what's important to users (hardware support - kernel, and
applications) is 

Re: Proposal: Move to an annual platform release starting at F30

[Brian (bex) Exelbierd]

On Wed, Nov 28, 2018 at 1:31 PM Igor Gnatenko
 wrote:
>
> On Wed, Nov 28, 2018 at 1:14 PM Brian (bex) Exelbierd
>  wrote:
> >
> > On Wed, Nov 28, 2018 at 12:12 PM Peter Robinson  
> > wrote:
> > >
> > > On Wed, Nov 28, 2018 at 8:07 AM Brian (bex) Exelbierd
> > >  wrote:
> > > >
> > > > On Wed, Nov 28, 2018 at 4:15 AM Brendan Conoboy  wrote:
> > > > > Paul's proposal was definitely a one-time pause for the reasons you
> > > > > state.  He requested we follow-up with additional questions and
> > > > > suggestions so I'm questioning and suggesting taking it a step
> > > > > further.  We talk about rolling releases, but people are skeptical due
> > > > > to rawhide instability.  What does it look like if the "rolling"
> > > > > happens on top of an otherwise stable platform where fundamentals like
> > > > > compilers, libraries and core system tools are held steady, but things
> > > > > on top move fast?  Maybe you don't need an F30.1, maybe it means F30
> > > > > just keeps getting nice incremental updates for as long as the
> > > > > editions want to stick with it.  Variable lifecycle or cadence can
> > > > > open up these kinds of options.  Some things are better fast. Some
> > > > > things are better slow.
> > > >
> > > > This.  Yes This. +100
> > > >
> > > > I think that Fedora's role as an innovater in the OS space means we
> > > > should be aggressively exploring this.  Rolling Releases, Tech-Driven
> > > > Releases and Time-Based Releases all have well known positives and
> > > > negatives.  All of the work that has been done on Modularity,
> > > > containers, flatpaks, OSTree, and more, gives us the opportunity to
> > > > really re-think this.  While it is true there are dozens (or more)
> > > > additional solutions to the too-fast/too-slow and the
> > > > incompatible-libraries problems, these technologies seem to be gaining
> > > > the most adoption across a variety of use cases.  They are all also
> > > > generally well supported in Fedora and we need to aggressively push
> > > > them to achieve this goal or determine where the dead-end is so we can
> > > > move to the next innovation.
> > > >
> > > > I personal am hugely in favor of us adopting a bootable-base model
> > > > that allows us to iterate the kernel and the various user-space pieces
> > > > at the speed of the upstream, the user's desires and the builder's
> > > > desires[^0] all at the same time.  While this will require us to do
> > > > some level of NxM matrix building and testing, a base that didn't have
> > > > to change often for most use cases reduces the matrix considerably.
> > >
> > > The above doesn't make sense, you're saying "move as fast as upstream"
> > > and "a base that doesn't change" in the same context, which is it?
> >
> > I've failed to be clear - sorry about that.  Let me try again.
> >
> > Please remember that I tend think from the lens of user space, not
> > kernel space.  So there may be detail errors in this, I am hoping the
> > concepts are valid though.
> >
> > In general, I can run various versions of my applications against
> > multiple different kernels, for example.  Therefore, if I have a
> > kernel that changed once a year, it isn't going to, for many
> > applications, stop me from changing versions multiple times during the
> > year.  Therefore if Fedora had a stabilized bootable base, I could
> > move my applications at the cadence of upstream, or a stabilized
> > release (not at all) or at the speed in the middle I want.  Fedora
> > might not build the entire range of that, but I am not prevented from
> > choosing amongst multiple Fedora provided options (stable vs devel or
> > all supported upstream releases, for example).
>
> So you mean that you want CentOS stable base and latest software you want?

Nope.  I want CentOS to serve their user base.  If the CentOS project
chooses to formally become part of Fedora and to release a
longer-maintained base to their users under the banner of our mission,
I welcome them with open arms.  But, that is their decision.

I don't think Fedora wants to get into 10 year life cycles and that
level of backporting.  But, accepting a new kernel/bootable base
shouldn't force me to take a new version of LibreOffice, for example.

> > The bootable base would change based on Fedora's needs.  Perhaps we
> > decide want to new kernels (again sorry for my failings in this field)
> > every 6 months to introduce new drivers and hardware support.  Someone
> > who wants faster can self-build for their community/needs more
> > frequently or a hardware vendor might want a kernel that doesn't
> > change as often and is backported.  Fedora may not build the whole
> > range here either.
> >
> > > > I'd push Brendans' concept further and suggest that we try to
> > > > eliminate as many of the compilers, libraries and core system tools as
> > > > possible from this bootable-base so that those can iterate at their
> > > > own speed, perhaps 4 year for a laptop vendor and 30 day for a
> 

Heads up: OpenImageIO 2.0 for Rawhide

[Richard Shaw]

Upstream has just released 2.0 RC1 and I'm working on test builds. I don't
expect much to change at this point as they run master in production so
it's pretty stable.

It is a SONAME bump so once the 2.0 GA release happens I plan to update
Rawhide only at this time and rebuild dependencies unless there's a need
for it to land in F29.

There are several packages that will need to be rebuilt but I believe
Blender is the biggest consumer of OIIO for the Cycles rendering engine.

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

Re: Last dbus upgrade issues

[Nicolas Mailhot]

Hi,

Since I hit it too…

I agree it's a problem when subsystem maintainers assume reboot is cheap 
and controlled and they do not need to make in-place update work (those 
people need a few months baby-sitting headless systems where any mistake 
means unracking and rewiring in uncomfortable physical positions just to 
access hdmi or usb ports).


But… it’s even more a problem, that the people who assumed they could 
design a system around reboots, didn’t provide a reliable way for 
packages to declare the actions required to make the next boot work, 
somewhere where they are sure to be executed before the next boot 
attempt. Because the systems that rebooted on a state without network, 
with broken gdm, and no console login, did provide the OS with the 
required reboot window in the first place.


We had the same thing with grub fast boot recently. I don't care if boot 
is pretty or fast, if problem remediation, is not built in the boot 
process in the first place.


Regards,

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

Re: Last dbus upgrade issues

[Tomasz Kłoczko]

On Wed, 28 Nov 2018 at 13:44, Igor Gnatenko
 wrote:
>
> I don't have time to revert back and try updating again, but the fix looks 
> good!

Whoever will be doing dbus upgrade just please do this using commands like below

# dnf upgrade -y --downloadonly dbus\*

than:

# rpm -Uvvvh /var/cache/dnf/rawhide-*/packages/dbus* 2>&1 | tee
~/dbus-upgrade.out

If anything will go wrong just please share ~/dbus-upgrade.out file.
I think that instead download and upgrade using rpm necessary
diagnostics could be done by add more -v to dnf like "dnf  upgrade
-yvvv dbus\*"

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: /etc/nssswitch.conf is supposed to be a symlink now?

[Florian Weimer]

* Richard W. M. Jones:

> Trying to track down a bug in IPP printing
> (https://bugzilla.redhat.com/show_bug.cgi?id=1653276).
>
> We're down a rabbit hole where it seems that in Fedora 29
> /etc/nssswitch.conf ought to be a symlink.  This machine has been
> upgraded from F28 and this is not the case.  AFAIK I have never edited
> the file.

/etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
ship it.

If find out which packages replaces our configuration with a symbolic
link, please file a bug against that package.  If they want to take over
/etc/nsswitch.conf, this is negotiable, but it needs coordination with
the glibc package.

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: Proposal: Move to an annual platform release starting at F30

[Josh Boyer]

On Wed, Nov 28, 2018 at 12:47 PM Owen Taylor  wrote:
>
> On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen  
> wrote:
> > On Wed, 28 Nov 2018 at 11:37, Owen Taylor  wrote:
>
> > > Fedora needs to be an operating system provider, not just an operating
> > > system toolbox provider. 
> >
> > I feel like we have been saying this for 15+ years even before Fedora
> > was Fedora. Even back in the RHL days, we would argue over whether
> > what we were providing was an 'OS' or not versus a toolkit for someone
> > else to work with.
>
> I don't think we've just been saying this, I think we've been steadily
> improving in this area - both in our focus and in our processes. The
> move to editions was particularly helpful.

I think this is a key observation.  Some people thought Editions were
just rearranging stuff arbitrarily or for little value.  I continue to
see them as a great way to focus on specific user bases.  What we're
discussing now is just continuation of that at a more fundamental
level.

For some reason I can't understand, people want a revolution every
time.  Fedora often has a tendency to look at evolution as failure.
That isn't sustainable and leads to repeating mistakes, creating
totally new problems, etc.  There is nothing wrong with iteration as
long as you know where you're going and why you're making the changes
you're making.

In this particular round, I think focusing on some of the fundamentals
on how we construct our OS (compose tooling, real actual CI, etc) is
another evolution.  Does it materially change what Fedora is to end
users?  No.  Does it have benefits for them and for maintainers in the
long run?  Yes.

We seem to also keep trying to force fit a single OS release
methodology into all use cases.  That leads to a poor fit many times.
With looking at multiple lifecycles and how to pull that off using the
fundamentals above, we can actually still look at being an OS provider
but it doesn't have to be a singular OS.  We can create the platform
necessary to have commonality at certain layers across different use
cases.

Do I think all of this will happen in a single Fedora "release"?  No.
It's good to be somewhat timeboxed, and I think we can make really
great strides on some of it.  For other bits we'll have to see how
things fall out going forward.  But if we don't take the time now to
work on the enablers, the big picture or theoretical goals won't
matter.

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

Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Randy Barlow]

On Wed, 2018-11-28 at 18:19 +0100, Kevin Kofler wrote:
> And why do we need to stop the presses to do that? This is entirely 
> orthogonal to distribution development and can be done in parallel.

The problem is that the people who do the work to get the release done
are the same people who would need to do the retooling work, so there
is a resource conflict.


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: Proposal: Move to an annual platform release starting at F30

[Josh Boyer]

On Wed, Nov 28, 2018 at 12:57 PM Stephen John Smoogen  wrote:
>
> On Wed, 28 Nov 2018 at 12:47, Owen Taylor  wrote:
> >
> > On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen  
> > wrote:
> > > On Wed, 28 Nov 2018 at 11:37, Owen Taylor  wrote:
> >
> > > > Fedora needs to be an operating system provider, not just an operating
> > > > system toolbox provider. 
> > >
> > > I feel like we have been saying this for 15+ years even before Fedora
> > > was Fedora. Even back in the RHL days, we would argue over whether
> > > what we were providing was an 'OS' or not versus a toolkit for someone
> > > else to work with.
> >
> > I don't think we've just been saying this, I think we've been steadily
> > improving in this area - both in our focus and in our processes. The
> > move to editions was particularly helpful.
> >
>
> I didn't mean to assume we haven't improved on it, but I do believe it
> is the central 'conflict' we have had. My main worry is that can we
> actually achieve being an "operating system provider" or are we always
> going to be a toolbox who isn't happy with itself? (or thirdly, are we
> already an operating system provider with delusions of being a
> toolbox?)

Why do either of those possibilities matter?  Or asked more directly,
why wouldn't we continue to look at ourselves and iterate and try to
improve?  There is no "done" state in an operating system.

> How can we know if we actually are still making progress if we each
> have a different definition of what that operating system is.

Great question.  I know there are different ideas around it in terms
of platform vs. core/extras vs. lifecycles of different bits.  I think
coming to a general consensus on that is a huge part of the discussion
we're having here.

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

Re: What does extended F30 cycle mean for F29?

[Matthew Miller]

On Wed, Nov 28, 2018 at 08:45:55AM +, Peter Robinson wrote:
> > If F31 is delayed by 6 months and F30 is supported for 6 months longer,
> > does it mean F29 *also* automatically gets a longer cycle since it by
> > policy becomes EOL when F31 is out + 1 month?
> > Can we EOL F29 6 months before F31 is out to not have *two* long term
> > branches to maintain?
> So going back to memory of what we did in the F-21 cycle, we EOLed
> F-19 at the 13 months line and then F-20 continued until a month after
> F-22 was out.

I'd support doing this again.

-- 
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Kevin Kofler]

Matthew Miller wrote:
> I know it was a big time-off holiday week in the US, but I expected a
> little more interest in this post. Perhaps it seemed like too much text to
> digest along with turkey and stuffing. :) I'm highlighting it with a
> subject reflecting the big, direct impact, and here's some other top-level
> proposals:
> 
> * embrace Taiga (an open source kanban tool) for project planning
> * fix the compose speed (target: one hour!)
> * really actually for real gated Rawhide
> * better CI pipeline tests for everything
> * define a base platform -- Red Hat wants to focus resources here
> * better tooling for non-base deliverables
> * better metrics for everything

And why do we need to stop the presses to do that? This is entirely 
orthogonal to distribution development and can be done in parallel.

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: Proposal: Move to an annual platform release starting at F30

[Owen Taylor]

On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen  wrote:
> On Wed, 28 Nov 2018 at 11:37, Owen Taylor  wrote:

> > Fedora needs to be an operating system provider, not just an operating
> > system toolbox provider. 
>
> I feel like we have been saying this for 15+ years even before Fedora
> was Fedora. Even back in the RHL days, we would argue over whether
> what we were providing was an 'OS' or not versus a toolkit for someone
> else to work with.

I don't think we've just been saying this, I think we've been steadily
improving in this area - both in our focus and in our processes. The
move to editions was particularly helpful.

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

Re: Proposal: Move to an annual platform release starting at F30

[Stephen John Smoogen]

On Wed, 28 Nov 2018 at 12:47, Owen Taylor  wrote:
>
> On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen  
> wrote:
> > On Wed, 28 Nov 2018 at 11:37, Owen Taylor  wrote:
>
> > > Fedora needs to be an operating system provider, not just an operating
> > > system toolbox provider. 
> >
> > I feel like we have been saying this for 15+ years even before Fedora
> > was Fedora. Even back in the RHL days, we would argue over whether
> > what we were providing was an 'OS' or not versus a toolkit for someone
> > else to work with.
>
> I don't think we've just been saying this, I think we've been steadily
> improving in this area - both in our focus and in our processes. The
> move to editions was particularly helpful.
>

I didn't mean to assume we haven't improved on it, but I do believe it
is the central 'conflict' we have had. My main worry is that can we
actually achieve being an "operating system provider" or are we always
going to be a toolbox who isn't happy with itself? (or thirdly, are we
already an operating system provider with delusions of being a
toolbox?)

How can we know if we actually are still making progress if we each
have a different definition of what that operating system is.

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



-- 
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: What does extended F30 cycle mean for F29?

[Kevin Kofler]

Peter Robinson wrote:
> So going back to memory of what we did in the F-21 cycle, we EOLed
> F-19 at the 13 months line and then F-20 continued until a month after
> F-22 was out.

No, we did not! F19 was supported until a month after F21 was released:
https://fedoraproject.org/wiki/Releases/21/Schedule ← F21 release 2014-12-09
https://fedoramagazine.org/fedora-19-eol-01-06-2015/ ← F19 EOL 2015-01-06
and that it what needs to happen to meet the promises we made to users. The 
whole point of the support cycle is to allow upgrading to Fn+2 directly. 
EOLing the release early because Fn+2 was delayed totally defeats the point.

If we are not prepared to do that, we simply must not prolong the F30 cycle 
arbitrarily. I don't see why we need to do that to begin with. 
Infrastructure work can be done in parallel with distribution development. 
Extending the release cycle is only useful if it actually leads to extended 
support times for the releases!

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: /etc/nssswitch.conf is supposed to be a symlink now?

[Richard W.M. Jones]

On Wed, Nov 28, 2018 at 05:02:17PM +0100, Reindl Harald wrote:
> 
> 
> Am 28.11.18 um 15:45 schrieb Florian Weimer:
> > * Richard W. M. Jones:
> > 
> >> Trying to track down a bug in IPP printing
> >> (https://bugzilla.redhat.com/show_bug.cgi?id=1653276).
> >>
> >> We're down a rabbit hole where it seems that in Fedora 29
> >> /etc/nssswitch.conf ought to be a symlink.  This machine has been
> >> upgraded from F28 and this is not the case.  AFAIK I have never edited
> >> the file.
> > 
> > /etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
> > ship it.
> > 
> > If find out which packages replaces our configuration with a symbolic
> > link, please file a bug against that package.  If they want to take over
> > /etc/nsswitch.conf, this is negotiable, but it needs coordination with
> > the glibc package.
> 
> and that's why i do "chattr +i /etc/nsswitch.conf" and "chattr +i
> /etc/resolv.conf" for year - guys stop mangle around in /etc - this is
> admin area and way too often the mdns crap was added unasked or "mysql"
> for nss-mysql touched in the past years finding you perfectly working
> config in a damned .bak file
> 
> everything which touchs /etc at updates is broken by design

Yes I've been doing chattr +i /etc/resolv.conf for a very long time.

However in the case of /etc/nsswitch.conf, changing it (with the
cooperation of glibc of course) to be a symlink seems reasonable.

What I'm (still) missing is what's the actual plan?  What should
things look like?

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: Proposal: Move to an annual platform release starting at F30

[Stephen John Smoogen]

On Wed, 28 Nov 2018 at 13:05, Josh Boyer  wrote:
>
> On Wed, Nov 28, 2018 at 12:57 PM Stephen John Smoogen  
> wrote:
> >
> > On Wed, 28 Nov 2018 at 12:47, Owen Taylor  wrote:
> > >
> > > On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen  
> > > wrote:
> > > > On Wed, 28 Nov 2018 at 11:37, Owen Taylor  wrote:
> > >
> > > > > Fedora needs to be an operating system provider, not just an operating
> > > > > system toolbox provider. 
> > > >
> > > > I feel like we have been saying this for 15+ years even before Fedora
> > > > was Fedora. Even back in the RHL days, we would argue over whether
> > > > what we were providing was an 'OS' or not versus a toolkit for someone
> > > > else to work with.
> > >
> > > I don't think we've just been saying this, I think we've been steadily
> > > improving in this area - both in our focus and in our processes. The
> > > move to editions was particularly helpful.
> > >
> >
> > I didn't mean to assume we haven't improved on it, but I do believe it
> > is the central 'conflict' we have had. My main worry is that can we
> > actually achieve being an "operating system provider" or are we always
> > going to be a toolbox who isn't happy with itself? (or thirdly, are we
> > already an operating system provider with delusions of being a
> > toolbox?)
>
> Why do either of those possibilities matter?  Or asked more directly,
> why wouldn't we continue to look at ourselves and iterate and try to
> improve?  There is no "done" state in an operating system.
>

You communicated clearer in your previous email what I wanted to say
better than I have in mine. Evolution versus revolution. We spend a
lot of time and energy talking for and against revolutions every
release because we don't seem to know what we are at and when in fact
most of them are evolutions which later on weren't as big as expected.

I just want us to come to some consensus on what we have accomplished,
where we are at, and then see if we can work out what we need to
iterate and improve. [I am probably still not communicating this any
better than I did in my previous emails, as I think you covered it
very well previously. ]

> > How can we know if we actually are still making progress if we each
> > have a different definition of what that operating system is.
>
> Great question.  I know there are different ideas around it in terms
> of platform vs. core/extras vs. lifecycles of different bits.  I think
> coming to a general consensus on that is a huge part of the discussion
> we're having here.

Thanks. I am interested in working out what we have accomplished so
far, and what we are hurting on in concrete terms.


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



-- 
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: Last dbus upgrade issues

[Jan Pokorný]

On 26/11/18 20:58 +0100, Jan Pokorný wrote:
> On 26/11/18 15:12 +0100, Tom Gundersen wrote:
>> On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko 
>> wrote:
>> 
>>> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
>>> zbys...@in.waw.pl> wrote:
>>> 
 On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
> After last dbus upgrade gdm found that is not able to start.
> 
> [...] 
> 
>> Thanks for the report, and sorry for the inconvenience. There was indeed a
>> bug in the dbus-broker spec file, which we now fixed with version 16-7
>> (should land in rawhide any minute).
> 
> Thanks for sparing others if not early adopters (nicely demonstrated
> like even mere-text-mode-friendly available tooling is dependent on
> this single central point these days, NetworkManager/nmtui, even
> dhclient complained about DBus, luckily it worked regardless).
> 
> Anyway, I've hit another new incompatibility, preventing me to, e.g.,
> run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
> Workaround is to switch back to dbus-daemon.service.

This must have been something intermittent, perhaps a fallout from me
trying to deal with a "difficulties to do anything once rebooted after
installing -6 build" as detailed by others in this thread, bug closed.

-- 
Nazdar,
Jan (Poki)


pgpCXBNEbf9Pg.pgp
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: Self Introduction: Dillen Meijboom

[Matthew Miller]

On Wed, Nov 28, 2018 at 10:16:32PM +0100, Dillen Meijboom wrote:
> My name is Dillen and I'm a developer from the Netherlands. I recently
> switched from ArchLinux to Fedora and currently figuring out how packaging
> for Fedora works. I mostly worked on commercial projects the past couple
> of years but I'd like to contribute more to open-source projects like
> Fedora.

That's great -- welcome to Fedora!

-- 
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: Proposal: Move to an annual platform release starting at F30

[Stephen John Smoogen]

On Wed, 28 Nov 2018 at 11:37, Owen Taylor  wrote:
>
> On Wed, Nov 28, 2018 at 3:07 AM Brian (bex) Exelbierd
>  wrote:
>

> > I'd push Brendans' concept further and suggest that we try to
> > eliminate as many of the compilers, libraries and core system tools as
> > possible from this bootable-base so that those can iterate at their
> > own speed, perhaps 4 year for a laptop vendor and 30 day for a
> > experimental ARM device.  Fedora as a project might not build output
> > for the whole range, but a build system that allowed us to help others
> > be successful would be a huge help here.
>
> Fedora needs to be an operating system provider, not just an operating
> system toolbox provider. 

I feel like we have been saying this for 15+ years even before Fedora
was Fedora. Even back in the RHL days, we would argue over whether
what we were providing was an 'OS' or not versus a toolkit for someone
else to work with. [Especially during the days when Mandrake and a
couple others were just rebuilds of Red Hat Linux with specific kernel
flags and some light patching to sed Red Hat Linux to Mandrake.]

Do we even know what an operating system provider is? Because it seems
like we do this every release where each groups look at what was
produced versus what they wanted and all they can see is all the
compromises they had to make to get it out the door. And unless we
actually come up with some specific things of what is really wanted,
we will be doing this every release in the future too.


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

[HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead

[Igor Gnatenko]

Hello,

the removal of glibc-all-langpacks from the buildroot[0] is done.
Standard buildroot has decreased from 445 to 237 megabytes in
installed size ;)

Before:
DEBUG util.py:439:  Install  146 Packages
DEBUG util.py:439:  Total download size: 86 M
DEBUG util.py:439:  Installed size: 445 M

After:
DEBUG util.py:439:  Install  146 Packages
DEBUG util.py:439:  Total download size: 61 M
DEBUG util.py:439:  Installed size: 237 M

All thanks go to zbyszek and mboddu :champagne:!

[0]https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead

[Randy Barlow]

On Wed, 2018-11-28 at 20:33 +0100, Igor Gnatenko wrote:
> the removal of glibc-all-langpacks from the buildroot[0] is done.
> Standard buildroot has decreased from 445 to 237 megabytes in
> installed size ;

Nice!


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

Fedora 30 System-Wide Change proposal: Ruby 2.6

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_2.6

== Summary ==
Ruby 2.6 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.5 in Fedora 29 to
Ruby 2.6 in Fedora 30, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondr...@redhat.com, pval...@redhat.com

== Detailed Description ==
Ruby 2.6 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== JIT ===

Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler.

JIT compiler aims to improve performance of any Ruby program
execution. Unlike ordinary JIT compilers for other languages, Ruby’s
JIT compiler does JIT compilation in a unique way, which prints C code
to a disk and spawns common C compiler process to generate native
code.

The main purpose of this JIT release is to provide a chance to check
if it works for your platform and to find out security risks before
the 2.6 release. JIT compiler is supported when Ruby is built by GCC,
Clang, or Microsoft VC++, which needs to be available on runtime.
Otherwise you can’t use it for now.

As of Ruby 2.6.0 preview3, we achieved 1.7x faster performance than
Ruby 2.5 on CPU-intensive non-trivial benchmark workload called
Optcarrot. The performance on memory-intensive workload like Rails
application are going to be improved as well.

=== RubyVM::AST [Experimental] ===

Ruby 2.6 introduces `RubyVM::AST` module.

This module has `parse` method which parses a given ruby code of
string and returns AST (Abstract Syntax Tree) nodes, and `parse_file`
method which parses a given ruby code file and returns AST nodes.
`RubyVM::AST::Node` class is also introduced. You can get location
information and children nodes from `Node` objects. This feature is
experimental. Compatibility of the structure of AST nodes are not
guaranteed.

=== New Features ===

* Add a new alias `then` to `Kernel#yield_self`.
* Add `Random.bytes`.
* Add `Binding#source_location`.  This method returns the source
location of binding, a 2-element array of __FILE__ and __LINE__.
* Add `:exception` option to let `Kernel.#system` raise error instead
of returning `false`.
* Add a new alias then to `Kernel#yield_self`.
* `else` without `rescue` now causes a syntax error. [EXPERIMENTAL]
* Constant names may start with a non-ASCII capital letter.
* An endless range, (1..), is introduced. It works as it has no end.

=== Performance improvements ===

* Speedup `Proc#call` because we don’t need to care about $SAFE any
more. With `lc_fizzbuzz` benchmark it makes x1.4 speed improvement.
* Speedup `block.call` where block is passed block parameter. Ruby 2.6
improves the performance of passed block calling. There can observed
2.6x improvement with micro-benchmarks.
* Transient Heap (theap) is introduced. theap is managed heap for
short-living memory objects which are pointed by specific classes. For
example, making small and short-living Hash object is x2 faster. With
rdoc benchmark, 6-7% performance improvement is observed.

=== Other notable changes since 2.5 ===

* `$SAFE` is a process global state and we can set `0` again.
* Passing `safe_level` to `ERB.new` is deprecated. `trim_mode` and
`eoutvar` arguments are changed to keyword arguments.
* Merged RubyGems 3.0.0.beta2.
* Merge Bundler as default gem.

== Benefit to Fedora ==

With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.

== Scope ==
* Proposal owners:
** Finish packaging of Ruby 2.6. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/32
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
.

* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 2.6 properly.

* Release engineering: [https://pagure.io/releng/issue/7936 #7936]
** Separate Koji tag for package rebuild will be needed.
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.

== How To Test ==
* No special hardware is needed.
* To test, install Ruby 2.6. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 2.6.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.

== User Experience ==
The Ruby programs/scripts should behave as they were used to.

== Dependencies ==

$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq 

Self Introduction: Dillen Meijboom

[Dillen Meijboom]

Hi there!

My name is Dillen and I'm a developer from the Netherlands. I recently
switched from ArchLinux to Fedora and currently figuring out how
packaging for Fedora works. I mostly worked on commercial projects the past 
couple of years but I'd like to contribute more to open-source projects like 
Fedora.

The first thing I'm "working" on is updating a package that is
outdated. It also has a new dependency so that's my first contribution
review request (see: 
https://bugzilla.redhat.com/show_bug.cgi?id=1654426).

Greetings,
Dillen
___
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: /etc/nssswitch.conf is supposed to be a symlink now?

[Jan Pokorný]

On 28/11/18 11:48 -0400, Robert Marcano wrote:
> There is another thing I found wrong. The backed up nsswitch.conf has these
> lines appended (ckey and incomplete aliases line) after the real end of the
> original file (aliases: files):
> 
>   aliases:files
>   ckey:  files
> 
>   aliases:fil
> 
> I can repeat this bad backup indefinitely:
> 
> 1) check current nsswitch has no such lines
> 2) run authselect select --force ...
> 3) backup at /usr/lib/authselect/backup//nsswitch has the
> appended lines

Have observed a similar corruption (with explicitly named backup, but
it's likely of no significance) yesterday with Rawhide, but at that time
it was least of my problems (see dbus-broker [vs. systemd-nspawn] in
a slightly older thread, nsswitch.conf/pam was actually a false start
based on some messages in journal I thought might be related).

Buffer handling bug?

-- 
Nazdar,
Jan (Poki)


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

Changing nsswitch.conf on a running system (was Re: /etc/nssswitch.conf is supposed to be a symlink now?)

[Ray Strode]

Hi,

On Wed, Nov 28, 2018, 9:45 AM Florian Weimer  /etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
> ship it.
>
> If find out which packages replaces our configuration with a symbolic
> link, please file a bug against that package.  If they want to take over
> /etc/nsswitch.conf, this is negotiable, but it needs coordination with
> the glibc package.
>

This is a bit of a tangent, but we probably avoid changing
/etc/nsswitch.conf on a running system at all (defer until next offline
update?) until

https://sourceware.org/bugzilla/show_bug.cgi?id=12459

gets fixed.  as it stands, no long running daemon will see changes to the
file, I think, leading to potentially weird bugs sometime after authselect
is run right? (and maybe not in an obviously connected way)

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

[Bug 1654194] New: Upgrade perl-Catalyst-Runtime to 5.90123

[bugzilla]

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

Bug ID: 1654194
   Summary: Upgrade perl-Catalyst-Runtime to 5.90123
   Product: Fedora
   Version: rawhide
 Component: perl-Catalyst-Runtime
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest Fedora delivers 5.90122 version. Upstream released 5.90123. When you
have free time, please upgrade it.

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

[Bug 1654195] Upgrade perl-Software-License to 0.103014

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Software-License-0.103
   ||014-1.fc30
 Resolution|--- |RAWHIDE
   Assignee|emman...@seyman.fr  |p...@city-fan.org
Last Closed||2018-11-28 05:42:07



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=31157161

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

[Bug 1377997] perl-XML-LibXML: Expanding external entities by default [ fedora-all]

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 118032
Version|27  |28



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

[Bug 1475784] Useless dependency on perl(Email::Address)

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Assignee|tcall...@redhat.com |ppi...@redhat.com



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

[Bug 1475784] Useless dependency on perl(Email::Address)

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Email-MessageID-1.406-10.fc29 has been submitted as an update to Fedora
29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f2773a48c9

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

[Bug 1450364] read_file(, binmode => ':utf8') produces warnings

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Version|27  |28
   Fixed In Version||perl-File-Slurp-.25-1.f
   ||c29



--- Comment #4 from Petr Pisar  ---
File-Slurp-.25 fixed this warning. But a similar issue in other places of
the code still exist.

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

[Bug 1231244] perl-HTTP-Proxy-0.303-2.fc23 FTBFS: tests fail randomly

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||Github
   ||book/HTTP-Proxy/issues/7
Version|27  |28



--- Comment #8 from Petr Pisar  ---
The issue has not yet been fixed in upstream and I still can reproduce it.

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

[Bug 1475784] Useless dependency on perl(Email::Address)

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-Email-MessageID-1.406-
   ||10.fc30



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

[Bug 1379554] perl-XML-Twig: expand_external_ents option fails to work as documented [fedora-all]

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 118097
Version|27  |28



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

[Bug 1653175] Upgrade perl-Git-Repository to 1.323

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
perl-Git-Repository-1.323-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-c02d63449d

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

[Bug 1654195] New: Upgrade perl-Software-License to 0.103014

[bugzilla]

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

Bug ID: 1654195
   Summary: Upgrade perl-Software-License to 0.103014
   Product: Fedora
   Version: rawhide
 Component: perl-Software-License
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, emman...@seyman.fr,
iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest Fedora delivers 0.103013 version. Upstream released 0.103014. When you
have free time, please upgrade it.

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

[Bug 1487209] perl-Graphics-TIFF-6-1.fc27 FTBFS: MagickCore/exception.c: 1034: ThrowMagickExceptionList: Assertion `exception->signature == MagickCoreSignature' failed

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |NOTABUG
Last Closed||2018-11-28 04:38:15



--- Comment #4 from Petr Pisar  ---
Fedora still has ImageMagick 6.9. No issue there.

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

[Bug 1450364] read_file(, binmode => ':utf8') produces warnings

[bugzilla]

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



--- Comment #5 from Ralf Corsepius  ---
(In reply to Petr Pisar from comment #4)
> File-Slurp-.25 fixed this warning. But a similar issue in other places
> of the code still exist.

Yes, this bug is still unfixed:
From a mock-build.log targeting fc30:
...
syswrite() is deprecated on :utf8 handles. This will be a fatal error in Perl
5.30 at /builddir/build/BUILD/File-Slurp-.25/blib/lib/File/Slurp.pm line
368.
...

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

[Bug 1653175] Upgrade perl-Git-Repository to 1.323

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Git-Repository-1.323-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-c02d63449d

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

[Bug 1475784] Useless dependency on perl(Email::Address)

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Email-MessageID-1.406-10.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f2773a48c9

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

[Bug 1651151] Upgrade perl-FFI-CheckLib to 0.23

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-FFI-CheckLib-0.23-1.fc |perl-FFI-CheckLib-0.23-1.fc
   |30  |30
   |perl-FFI-CheckLib-0.23-1.fc |perl-FFI-CheckLib-0.23-1.fc
   |28  |28
   ||perl-FFI-CheckLib-0.23-1.fc
   ||29



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

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

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Net-Pcap-0.18-10.fc30  |perl-Net-Pcap-0.18-10.fc30
   |perl-Net-Pcap-0.18-10.fc29  |perl-Net-Pcap-0.18-10.fc29
   ||perl-Net-Pcap-0.18-8.fc28



--- Comment #13 from Fedora Update System  ---
perl-Net-Pcap-0.18-8.fc28 has been pushed to the Fedora 28 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1651151] Upgrade perl-FFI-CheckLib to 0.23

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-FFI-CheckLib-0.23-1.fc |perl-FFI-CheckLib-0.23-1.fc
   |30  |30
   ||perl-FFI-CheckLib-0.23-1.fc
   ||28
 Resolution|--- |ERRATA
Last Closed||2018-11-28 21:26:52



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

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

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Net-Pcap-0.18-10.fc30  |perl-Net-Pcap-0.18-10.fc30
   |perl-Net-Pcap-0.18-10.fc29  |perl-Net-Pcap-0.18-10.fc29
   |perl-Net-Pcap-0.18-8.fc28   |perl-Net-Pcap-0.18-8.fc28
   ||perl-Net-Pcap-0.18-7.fc27



--- Comment #14 from Fedora Update System  ---
perl-Net-Pcap-0.18-7.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

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

[EPEL-devel] Re: EPEL 8 Beta/Alpha?

[Paul Howarth]

On Wed, 28 Nov 2018 07:01:04 -0600
Richard Shaw  wrote:

> On Wed, Nov 28, 2018 at 5:29 AM Paul Howarth 
> wrote:
> 
> > On Wed, 28 Nov 2018 10:53:58 +0530
> >
> > I seem to remember that for EL-7 we generally just branched the f19
> > packages for epel7, rebuilt and that was pretty much it.
> >  
> 
> I thought it was more of an "opt-in" situation, that packages that
> had a EL -1 branch didn't automatically get an EL new branch?
> 
> I would definitely like the opportunity to do some major version
> upgrades of some of the packages I maintain.

It was mostly opt-in as I recall it, but some packages got EPEL
branches for the first time as they were needed as dependencies. Anyone
packaging for EPEL-8 should of course be free to choose whichever
version of their package is best suited to it; I think f19 was the
latest at the time of the EL7 beta release when a lot of stuff got
built.

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

[EPEL-devel] Re: EPEL 8 Beta/Alpha?

[Richard Shaw]

On Wed, Nov 28, 2018 at 5:29 AM Paul Howarth  wrote:

> On Wed, 28 Nov 2018 10:53:58 +0530
>
> I seem to remember that for EL-7 we generally just branched the f19
> packages for epel7, rebuilt and that was pretty much it.
>

I thought it was more of an "opt-in" situation, that packages that had a EL
-1 branch didn't automatically get an EL new branch?

I would definitely like the opportunity to do some major version upgrades
of some of the packages I maintain.

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

[rpms/perl-Email-MessageID] PR #1: Remove unneeded requirement

[Tom Callaway]

spot commented on the pull-request: `Remove unneeded requirement` that you are 
following:
``
Looks like this happened in rawhide before I could merge this. Closing out.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Email-MessageID/pull-request/1
___
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

[rpms/perl-Email-MessageID] PR #1: Remove unneeded requirement

[Tom Callaway]

spot canceled a pull-request against the project: `perl-Email-MessageID` that 
you are following.

Cancelled pull-request:

``
Remove unneeded requirement
``

https://src.fedoraproject.org/rpms/perl-Email-MessageID/pull-request/1
___
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

Fedora 30 System-Wide Change proposal: Ruby 2.6

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_2.6

== Summary ==
Ruby 2.6 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.5 in Fedora 29 to
Ruby 2.6 in Fedora 30, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondr...@redhat.com, pval...@redhat.com

== Detailed Description ==
Ruby 2.6 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== JIT ===

Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler.

JIT compiler aims to improve performance of any Ruby program
execution. Unlike ordinary JIT compilers for other languages, Ruby’s
JIT compiler does JIT compilation in a unique way, which prints C code
to a disk and spawns common C compiler process to generate native
code.

The main purpose of this JIT release is to provide a chance to check
if it works for your platform and to find out security risks before
the 2.6 release. JIT compiler is supported when Ruby is built by GCC,
Clang, or Microsoft VC++, which needs to be available on runtime.
Otherwise you can’t use it for now.

As of Ruby 2.6.0 preview3, we achieved 1.7x faster performance than
Ruby 2.5 on CPU-intensive non-trivial benchmark workload called
Optcarrot. The performance on memory-intensive workload like Rails
application are going to be improved as well.

=== RubyVM::AST [Experimental] ===

Ruby 2.6 introduces `RubyVM::AST` module.

This module has `parse` method which parses a given ruby code of
string and returns AST (Abstract Syntax Tree) nodes, and `parse_file`
method which parses a given ruby code file and returns AST nodes.
`RubyVM::AST::Node` class is also introduced. You can get location
information and children nodes from `Node` objects. This feature is
experimental. Compatibility of the structure of AST nodes are not
guaranteed.

=== New Features ===

* Add a new alias `then` to `Kernel#yield_self`.
* Add `Random.bytes`.
* Add `Binding#source_location`.  This method returns the source
location of binding, a 2-element array of __FILE__ and __LINE__.
* Add `:exception` option to let `Kernel.#system` raise error instead
of returning `false`.
* Add a new alias then to `Kernel#yield_self`.
* `else` without `rescue` now causes a syntax error. [EXPERIMENTAL]
* Constant names may start with a non-ASCII capital letter.
* An endless range, (1..), is introduced. It works as it has no end.

=== Performance improvements ===

* Speedup `Proc#call` because we don’t need to care about $SAFE any
more. With `lc_fizzbuzz` benchmark it makes x1.4 speed improvement.
* Speedup `block.call` where block is passed block parameter. Ruby 2.6
improves the performance of passed block calling. There can observed
2.6x improvement with micro-benchmarks.
* Transient Heap (theap) is introduced. theap is managed heap for
short-living memory objects which are pointed by specific classes. For
example, making small and short-living Hash object is x2 faster. With
rdoc benchmark, 6-7% performance improvement is observed.

=== Other notable changes since 2.5 ===

* `$SAFE` is a process global state and we can set `0` again.
* Passing `safe_level` to `ERB.new` is deprecated. `trim_mode` and
`eoutvar` arguments are changed to keyword arguments.
* Merged RubyGems 3.0.0.beta2.
* Merge Bundler as default gem.

== Benefit to Fedora ==

With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.

== Scope ==
* Proposal owners:
** Finish packaging of Ruby 2.6. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/32
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
.

* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 2.6 properly.

* Release engineering: [https://pagure.io/releng/issue/7936 #7936]
** Separate Koji tag for package rebuild will be needed.
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.

== How To Test ==
* No special hardware is needed.
* To test, install Ruby 2.6. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 2.6.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.

== User Experience ==
The Ruby programs/scripts should behave as they were used to.

== Dependencies ==

$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq