Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Peter Robinson]

>> > On 28/04/18 14:55, Peter Robinson wrote:
>> >> On Sat, Apr 28, 2018 at 11:09 AM, Daniel Walsh <dwa...@redhat.com>
>> >> wrote:
>> >>> We are adding some features to container projects for User Namespace
>> >>> support
>> >>> that can take advantage of XFS Reflink.  I have talked to some of the
>> >>> XFS
>> >>> Reflink kernel engineers in Red Hat and they have informed me that
>> >>> they
>> >>> believe it is ready to be turned on by default.
>> >>>
>> >>> I am not sure who in Red Hat I should talk to about this? Whether we
>> >>> should
>> >>> turn it on in the installer or in the mkfs.xfs command?
>> >>>
>> >>> Who should I be talking to?  To make this happen.
>> >> I would speak to Eric Sandeen I believe he's the Red Hat maintainer
>> >> (or one of them) of XFS.
>> >>
>> >> Peter
>> > Indeed, and also we should look at this in the context of what is done
>> > for upstream. Ideally Fedora would just inherit the changes there, and 
>> > there
>> > should not be anything special required for Fedora,
>> >
>> > Steve.
>>
>> So, for context, I am the upstream maintainer of xfsprogs as well as for
>> Fedora xfsprogs.
>>
>> Historically, new features in XFS have gone from "Experimental" (i.e.
>> under
>> development), then dropped Experimental (development is ~done) but still
>> optional,
>> and eventually default.  We do this very conservatively, to give bugs a
>> chance
>> to shake out, which is one of the reasons XFS has a good reputation for
>> /not/
>> eating your data.
>>
>> Reflink on XFS only recently dropped "Experimental" and is not yet default
>> upstream;
>> it won't be default upstream for some time to come - think on the order of
>> months.
>>
>> However, we do want to give reflink more exposure, and so jumping the gun
>> a bit and
>> turning it on for rawhide / Fedora 29 is probably a good idea.
>>
>> I'm mostly ok with patching it on by default in mkfs.xfs; it does confuse
>> things a bit
>> when "our" version behaves fundamentally differently from upstream, but
>> it's probably
>> the right thing to do here.  I'll make sure that none of the other xfs
>> developers have
>> strong objections, and if not, I'll patch it in for fedora 29.
>>
>> Unless this should be a full blown Feature?  If so, I'm ok with following
>> that path
>> as well.
>
>
>
> XFS is the default filesystem on Fedora Server Edition, so yes: I think we
> should really have a System-Wide Change Proposal submitted for this,
> primarily to ensure that the information is spread widely (Change Proposals
> like this are picked up by Fedora Marketing and tech news, so it’ll be more
> widely dispersed than just on the fedora-devel list).

Assuming that the plan is to leave it enabled in F-29 on branching and
have it ship enabled in F-29 I agree, if the intention is to leave it
enabled in rawhide and disable it on branching then the Change
Proposal mechanism isn't the way to ensure wider knowledge.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: sysusage f27 and rawhide blocked in koji

[Peter Robinson]

On Sun, Jan 7, 2018 at 1:31 AM, Frank Crawford  wrote:
> Folks,
>
> Sorry to drop this in here, but I've can't find where else it could go. I'm
> the maintainer for sysusage, which was un-retired mid 2017, around the time
> of conversion to pagure.io for packages.
>
> The builds for F25 & F26 worked fine, and I assumed it would roll over to
> F27, etc, but I find that it isn't in F27 and when I try and build new
> versions for F27 and rawhide, I seem to be blocked in koji. What I get is:
>
> FAILED: BuildError: package sysusage is blocked for tag
> f27-updates-candidate or FAILED: BuildError: package sysusage is blocked for
> tag f28-pending
>
> So, how do I go about getting getting these tags unblocked for this package?

File a rel-eng ticket [1] as per the packaging guidelines

[1] https://pagure.io/releng
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:39 PM, Kevin Fenzi  wrote:
> On 01/07/2018 08:01 PM, Kevin Kofler wrote:
>> Kevin Fenzi wrote:
>>> The critera for bypassing batched is if the update is marked "urgent".
>>
>> The problem is, this appears to be insufficient.
> Well, if this firefox update was urgent, shouldn't it have been marked
> urgent?

I thought for some reason that all updates marked as security were
automatically urgent, maybe I'm misremembering, but if not it might be
good to do that as a RFE that way all security updates go out non
batched.

>> I really don't understand why we do this "batched" thing to begin with.
>
> To reduce the constant flow of updates that are very minor or affect
> very few mixed in with the major updates that affect lots of people and
> are urgent. To save users downloads of repodata.
>
>> Users who want to batch updates have always been able to do it, GNOME
>> Software will even do it for theNow, those users who want to batch their
>> updates are forced to follow Fedora rel-eng's schedule for the batches
>> rather than being able to pick their own weekday, so how does the server-
>> side batching help them? And those users (like me) who want to get their
>> updates, including security fixes (!) as we see here, as soon as they passed
>> testing are now screwed.
>
> rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch
> appears on wed's pushes).
>
> There was some discussion about changing the gnome batching based on the
> Fedora batching, but I don't know whats happened there.
>
> I haven't seen a bunch of urgent updates get blocked by this process.
> Do you have more data for updates that hit this?
>
>> If people insist on that "batched" misfeature, can we please at least get a
>> fast track repository that contains all the batched updates (but no updates
>> that are still in testing and have not been batched yet!)?
>
> I would be very much against additional repos like this.
>
>
> kevin
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:16 PM, Adam Williamson
 wrote:
> On Mon, 2018-01-08 at 14:40 +0100, Jan Kurik wrote:
>>
>> == Scope ==
>> * Proposal owners:
>> The general AArch64 support is already in place and is widely and
>> actively supported by the Fedora ARM SIG and numerous ARM vendors and
>> third parties in Fedora. There will be further and wider support,
>> hardware enablement, polish and general improvements.
>>
>> * Other developers:
>> N/A: There's no work required for other developers, the aarch64
>> architecture is already widely supported as an Alternate Architecture.
>>
>> * Release engineering:
>> Needs approval from release engineering as a primary architecture as
>> well as pungi configuration changes to output artifacts to new
>> location on the primary mirror.
>> rel-eng ticket #7243: https://pagure.io/releng/issue/7243
>>
>> * Policies and guidelines:
>> Updates to the primary architectures and release blocking details will
>> need to be updated to reflect that the AArch64 Server/Cloud/Docker
>> components are now considered primary.
>>
>> * Trademark approval:
>> N/A (not needed for this Change)
>
> A significant miss here is 'testing'. Making an arch primary means we
> need to ensure we have the necessary resources to run all the relevant
> validation testing.
>
> I note pwhalen is a co-owner of the proposal so he's likely signed up
> to ensure testing gets done, but still, it should be properly covered
> in the Change document itself.

Yes, we've got a bunch of stuff here but the change document template
doesn't really have a good spot to outline all of that.

> As a further note, almost all the Server validation for x86_64 is done
> by openQA; doing it manually can be a considerable pain, as you have to
> set up a mini FreeIPA deployment. It would probably be best if we add
> aarch64 workers to the Fedora openQA deployment to run these tests on
> aarch64; we've already extended openQA (staging) to ppc64, so all the
> bits should be in place for us to add another arch, pretty much. I'm
> going to follow up on this with pwhalen.

Yes, that is the plan, we have the HW to do it and Paul Whalen has it
running locally, the reason it's not in place already basically comes
down to two things:
1) we needed to wait for the DC migration before we could set some of it up
2) with all the various changes around CI/testing/modularity etc
awaiting to see what the final outcome would be

> Another consideration would be whether we ought to also have aarch64
> support in Taskotron, if it's going to become a primary arch. I'm not
> actually sure if Taskotron currently covers 32-bit ARM, though, even.

That's also on my list, basically we have some hardware, with the
option of more, I had on my list of options:
* openQA
* auto cloud
* task-o-tron
* other CI/CD pipelines
* any other options.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

[Peter Robinson]

>> within the whole Meltdown and Spectre story I realized that Koji pushes
>> even security updates to batched only, not directly to stable. In
>
> The critera for bypassing batched is if the update is marked "urgent".

Or once you push it stable and it's queued for batched the maintainer
then has an option to push stable in the same spot as usual, just
needs the maintainer to push the button again.

>> concrete case we have the firefox update [1], which already received 10
>> positive karma and many users complaining that it takes so long to get
>> it out as a stable update. Shouldn't we change that behaviour to get
>> such security updates out fast when maintainer relies on autopush when
>> karma threshold is reached?
>
> If they are urgent sure... perhaps this should have been so marked?
> Or the maintainer/submittor can request stable anytime after it has
> enough karma.
>
> Anyhow, I have pushed it to request stable and will do another f27 push
> after the current ones finish to get it out today.
>
> kevin
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 6:03 PM, Jonathan Dieter  wrote:
> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>> On 8 January 2018 at 12:28, Matthew Miller 
>> wrote:
>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>> > > A significant miss here is 'testing'. Making an arch primary
>> > > means we
>> > > need to ensure we have the necessary resources to run all the
>> > > relevant
>> > > validation testing.
>> >
>> > Are there hardware needs here? (Like, not in the server room but in
>> > QA
>> > team member's hands?)
>> >
>>
>> I would say in both. We would need to make sure we have enough
>> systems
>> which openqa can reliably run on and we need to have some sort of
>> system that testers can get a hand on. That would require a bit of a
>> 'we expect this hardware to work and this is how you buy/get it' from
>> the aarch64 team.. otherwise most everyone is going to come and ask
>> why the raspberry pi 3 isn't supported (just like they did with the
>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
>> more that is what most testers can get their hands on easily.. and it
>> is not a aarch64 platform we support).
>
> I may be going off in the weeds here, but is https://fedoraproject.org/
> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
> accurate when it says it *is* supported?

Nope, it's completely accurate and it's supported
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 6:06 PM, Andreas Tunek  wrote:
> 2018-01-08 19:03 GMT+01:00 Jonathan Dieter :
>> On Mon, 2018-01-08 at 12:53 -0500, Stephen John Smoogen wrote:
>>> On 8 January 2018 at 12:28, Matthew Miller 
>>> wrote:
>>> > On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>>> > > A significant miss here is 'testing'. Making an arch primary
>>> > > means we
>>> > > need to ensure we have the necessary resources to run all the
>>> > > relevant
>>> > > validation testing.
>>> >
>>> > Are there hardware needs here? (Like, not in the server room but in
>>> > QA
>>> > team member's hands?)
>>> >
>>>
>>> I would say in both. We would need to make sure we have enough
>>> systems
>>> which openqa can reliably run on and we need to have some sort of
>>> system that testers can get a hand on. That would require a bit of a
>>> 'we expect this hardware to work and this is how you buy/get it' from
>>> the aarch64 team.. otherwise most everyone is going to come and ask
>>> why the raspberry pi 3 isn't supported (just like they did with the
>>> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
>>> more that is what most testers can get their hands on easily.. and it
>>> is not a aarch64 platform we support).
>>
>> I may be going off in the weeds here, but is https://fedoraproject.org/
>> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support not
>> accurate when it says it *is* supported?
>>
>
> That link does not work for me and I get some strange redirect to the
> Fedora download page.

https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Anaconda modularization

[Peter Robinson]

On Mon, Jan 8, 2018 at 2:01 PM, Matthew Miller  wrote:
> On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote:
>> Yep - basically, there will be no "old" and "new, DBUS/modular"
>> Anaconda, the plan is to turn the current Anaconda to the new one one
>> step at a time.
>>
>> This should allow us to fix bugs as usual and handle any unforeseen
>> modularization issues early on one-by-one as they show up.
>
> It sounds like there actually isn't a contingency plan as such. Do you
> think that this could all be reverted on Final Freeze day if we would
> decide it's not working out? If not, let's not call that a contingency.

I would argue this isn't a "Self Contained Change" but a system wide
one. If anaconda is broken we can't even compose so this should all be
landed and complete by the time the system wide features need to be.

> I'm not saying we shouldn't do this, but let's be honest with
> ourselves. If the contingency plan is "None: we'll have to hold up the
> release for fixes if it's not ready", the Change plan should say that.

And we should be honest that the "Final Freeze day" is _WAY_ too late
to be working out whether we should revert this or not!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Mon, Jan 8, 2018 at 5:53 PM, Stephen John Smoogen  wrote:
> On 8 January 2018 at 12:28, Matthew Miller  wrote:
>> On Mon, Jan 08, 2018 at 09:16:05AM -0800, Adam Williamson wrote:
>>> A significant miss here is 'testing'. Making an arch primary means we
>>> need to ensure we have the necessary resources to run all the relevant
>>> validation testing.
>>
>> Are there hardware needs here? (Like, not in the server room but in QA
>> team member's hands?)
>>
>
> I would say in both. We would need to make sure we have enough systems
> which openqa can reliably run on and we need to have some sort of
> system that testers can get a hand on. That would require a bit of a

There will be more than enough HW for openQA, we have two large
systems we'll put into the cloud (awaiting commissioning now the DC
migration is done) which will enable us to use AutoCloud (or what ever
it's replacement is) for VM/Docker testing, and a number of physical
systems for OpenQA.

> 'we expect this hardware to work and this is how you buy/get it' from
> the aarch64 team.. otherwise most everyone is going to come and ask
> why the raspberry pi 3 isn't supported (just like they did with the

The Raspberry Pi 3 *IS* supported on aarch64 [1]! As is the Pine64,
currently headless needs a serial console but by F-28 it will be
supported with basic console out for HDMI too, We support around 20
aarch64 SBCs in F-27 [1] and I expect that to likely double, or even
more than that, with F-28. Along with all the SBSA compliant hardware
etc.

I have the ability to get HW provided to people that are actually
going to use it for testing the problem I have here is that I
regularly give people hardware for testing and I get zero testing back
and Paul, myself and others still end up doing all the testing.

> raspberry pi 1 and 2.) [I am not looking to rehash why it isn't ..
> more that is what most testers can get their hands on easily.. and it
> is not a aarch64 platform we support).

Err, RPi 0-2 are 32 bit only devices in the case of < 2 they're
ARMv6, and we support the RPi2 with 32 bit I don't see how any of
that is relevant to this conversation?

[1] https://nullr0ute.com/2017/11/overview-of-aarch64-sbc-support-in-fedora-27/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

On Tue, Jan 9, 2018 at 3:57 AM, Adam Williamson
<adamw...@fedoraproject.org> wrote:
> On Tue, 2018-01-09 at 03:43 +0000, Peter Robinson wrote:
>>
>> > A significant miss here is 'testing'. Making an arch primary means we
>> > need to ensure we have the necessary resources to run all the relevant
>> > validation testing.
>> >
>> > I note pwhalen is a co-owner of the proposal so he's likely signed up
>> > to ensure testing gets done, but still, it should be properly covered
>> > in the Change document itself.
>>
>> Yes, we've got a bunch of stuff here but the change document template
>> doesn't really have a good spot to outline all of that.
>
> It does have an entire section called "How To Test".

Fair enough, I was assuming more that was a end user individual as
opposed to CI/CD/infra details
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Peter Robinson]

>> > == Scope ==
>> > * Proposal owners:
>> > The general AArch64 support is already in place and is widely and
>> > actively supported by the Fedora ARM SIG and numerous ARM vendors
>> > and
>> > third parties in Fedora. There will be further and wider support,
>> > hardware enablement, polish and general improvements.
>> >
>> > * Other developers:
>> > N/A: There's no work required for other developers, the aarch64
>> > architecture is already widely supported as an Alternate
>> > Architecture.
>> >
>> > * Release engineering:
>> > Needs approval from release engineering as a primary architecture
>> > as
>> > well as pungi configuration changes to output artifacts to new
>> > location on the primary mirror.
>> > rel-eng ticket #7243: https://pagure.io/releng/issue/7243
>> >
>> > * Policies and guidelines:
>> > Updates to the primary architectures and release blocking details
>> > will
>> > need to be updated to reflect that the AArch64 Server/Cloud/Docker
>> > components are now considered primary.
>> >
>> > * Trademark approval:
>> > N/A (not needed for this Change)
>>
>> A significant miss here is 'testing'. Making an arch primary means we
>> need to ensure we have the necessary resources to run all the
>> relevant
>> validation testing.
>>
>> I note pwhalen is a co-owner of the proposal so he's likely signed up
>> to ensure testing gets done, but still, it should be properly covered
>> in the Change document itself.
>>
>> As a further note, almost all the Server validation for x86_64 is
>> done
>> by openQA; doing it manually can be a considerable pain, as you have
>> to
>> set up a mini FreeIPA deployment. It would probably be best if we add
>> aarch64 workers to the Fedora openQA deployment to run these tests on
>> aarch64; we've already extended openQA (staging) to ppc64, so all the
>> bits should be in place for us to add another arch, pretty much. I'm
>> going to follow up on this with pwhalen.
>>
>> Another consideration would be whether we ought to also have aarch64
>> support in Taskotron, if it's going to become a primary arch. I'm not
>> actually sure if Taskotron currently covers 32-bit ARM, though, even.
>
> currently taskotron is x86 only.  I am not sure what it would take to
> extend it beyond x86, it would be a worthwhile investigation. It would
> be useful to have all arches in openQA regardless of primary or
> secondary status. I would like to see openQA working for aarch64 in
> Fedora's instance a hard requirement of this change.

I'm fine with that, we already have OpenQA working fine on aarch64 and
the only reason it's not yet in the Fedora infra was that we were
awaiting on the DC move and the EOL of Fedora 25 to be able to move
hardware around.

In fact it basically was a hard requirement for myself (and I suspect
Paul as well) as basically I'm lazy and would prefer a machine do as
much as the testing as humanly possible so I don't have to :-D

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Peter Robinson]

On Thu, Jan 25, 2018 at 2:21 PM, Michael Cronenworth  wrote:
> On 01/25/2018 02:41 AM, Richard W.M. Jones wrote:
>>
>> I think the -z defs change should be reverted.  It breaks very long-
>> standing expected behaviour of linkers and there's been no proper
>> justification for doing it.
>
>
> +1
>
> This should go through a Fedora Change workflow. I am unaware of a Fedora
> Change for this.

It did [1], and I'm fairly certain it was referenced on this thread already too.

[1] https://fedoraproject.org/wiki/Changes/BINUTILS2291#Scope
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Peter Robinson]

On Sat, Jan 13, 2018 at 1:36 AM, Kevin Kofler  wrote:
> Jason L Tibbitts III wrote:
>> As a person not privy to Red Hat internals, I really have no idea what
>> state things are in there, but I have to assume that Red Hat is well
>> along with RHEL8 packaging and so I would be surprised if any changes
>> made to a rawhide branch in Fedora now would make any difference to how
>> RHEL8 builds.
>>
>> So think of it from my perspective, not having any knowledge of Red Hat
>> release dates and policy.  My interpretation of what Florian wrote was
>> that doing this (I assumed in rawhide) could potentially help the RHEL8
>> developers.  Which is great; everyone needs all the help they can get.
>> But if that's the case, then either RHEL8 hasn't even been branched yet
>> or it has been branched and someone has already had to make those
>> changes and they didn't flow back out to Fedora.  I certainly thought
>> RHEL8 was further along than that, so
>
> I really wish RHEL were developed more openly. Even without making the
> branches public, at least informing Fedora maintainers about when they
> branch from Rawhide would already help preventing unnecessary work. And for
> some packages, the contents end up leaking out to Rawhide (under %{?rhel}
> conditionals) anyway, so I'm not even all that sure hiding the branches is
> all that useful. The code will hopefully eventually end up in CentOS git
> anyway. But of course I don't expect anybody to listen to me…

Well given it's based on Fedora and most of the pre work happens in
Fedora (hence the request for ensuring the conditionals are correct) I
think that's relatively upstream. Also a lot of the packages actually
have the same specs in Fedora/RHEL/CentOS, a lot of the RHEL stuff is
rebased regularly and those maintainers keep things in sync, but like
everything different maintainers work in different ways/workflows so
some do diverge over the lifecycle of a RHEL release, but that's
generally seen quite easily via the centos dist-git instance.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /proc/sys/net/core/optmem_max on armv7l

[Peter Robinson]

> I just noticed, there is a difference in the default value of
> `/proc/sys/net/core/optmem_max` on armv7l:
>
> On all arches it is 20480, but on armv7l it is 10240.
>
> Is there any specific reason for limiting the maximum ancillary buffer
> size allowed per socket on this arch?

No specific reason, I think that would be an upstream kernel default,
I'm not aware we tweak that setting on any of the architectures so it
should be the arch default.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What's up with koji?

[Peter Robinson]

On Sat, Jan 27, 2018 at 8:32 AM, Florian Weimer  wrote:
> On 01/27/2018 12:10 AM, Josh Stone wrote:
>>
>> koji wait-repo f28-build --build=httpd-2.4.29-4.fc28
>>
>> It sometimes takes a while for the actual repo to be regenerated.
>
>
> The last rawhide repository was generated more than 12 hours ago.  I don't
> see a stuck newRepo tasks or something like that on the Koji website.  So it
> seems that repository generation has ceased completely.

The newRepos issue is known by the infra/rel-eng team and is being
investigated as I type this.

P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Peter Robinson]

 ATM all rawhide builds are failing for me, because autoconf's tests for
 CC are failing.
>>>
>>>
>>> Yes, we had an internal dependency issue involving annobin (not related
>>> to RPM dependencies), fixed by an annobin rebuild.  Later, a defective build
>>> of annobin was tagged into rawhide which had a file conflict, but this has
>>> since been resolved as well.
>>
>>
>> Is annobin-3.2-2.fc28 the fixed version?
>
>
> Ah!  We currently have:
>
>nevra|  name
> +-
>  annobin-2.0-3.fc27.x86_64  | Fedora/27/x86_64
>  annobin-3.1-1.fc28.src | Fedora/rawhide/source
>  annobin-3.1-1.fc28.x86_64  | Fedora/rawhide/x86_64
>  annobin-3.1-3.fc28.aarch64 | Fedora/28-build/aarch64
>  annobin-3.1-3.fc28.i686| Fedora/28-build/i386
>  annobin-3.1-3.fc28.ppc64le | Fedora/28-build/ppc64le
>  annobin-3.1-3.fc28.s390x   | Fedora/28-build/s390x
>  annobin-3.1-3.fc28.x86_64  | Fedora/28-build/x86_64
> (8 rows)
>
> rawhide repositories are composes, the *-build repositories come directly
> from Koji.  (I haven't mirrored everything, which is why the list is
> incomplete.)
>
> Koji isn't currently generating repositories, so annobin-3.2-2.fc28 hasn't
> showed up.  However, annobin-3.1-3.fc28 is also fine (annobin-3.2-1.fc28 has
> this particularly bug), as long as you use it with GCC 7.3.  So if you build
> using Koji use the mysteriously named “local” repository in mock, you should
> be able to build packages.

The newRepo issue is known by rel-eng/infra and is being investigated/worked on.

P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning some Spacewalk packages

[Peter Robinson]

On Tue, Jan 30, 2018 at 11:39 AM, Miroslav Suchý  wrote:
> I orphaned
>   rhnmd
> This is Spacewalk package which is not developed any more.

If it's dead upstream with no users within Fedora you're much better
off just retiring it directly with  "fedpkg retire" than letting it
hand around.

> And I orphaned
>   perl-Socket-MsgHdr
>   perl-Crypt-GeneratePassword
> as I these are not used in Spacewalk as well.
>
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide armv7hl buildroot busted?

[Peter Robinson]

On Fri, Feb 9, 2018 at 7:33 PM, Michael Cronenworth  wrote:
> I've tried two builds over the past couple hours that result in failures.
> Other architectures are building.

You need to reference the root task, it's hard to get back to that
from the .log files, and it allows people to see other things that
isn't just pure logs which are useful for debug.

> Is there something wrong in glibc/gcc/makefile for armv7hl?
>
> build.log
> https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/build.log
>
> root.log
> https://kojipkgs.fedoraproject.org//work/tasks/408/24900408/root.log
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass Rebuild for Fedora 28

[Peter Robinson]

>> We have now completed the automated part of the Fedora 28 mass rebuild,
>> The details for the scheduled mass rebuild for Fedora 28 can be found
>> here[1]. The failure page for the rebuilds can be found here[3] and the
>> full list of packages that are needing rebuilding can be found here[4].
>>   The needs rebuild list includes packages that failed to get submitted
>> to koji for various reasons, things like the spec bumping failing due
>> to incomplete or incorrect retirement
>>
>>
>> [1] https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
>> [2] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-failures.html
>> [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-need-rebuild.ht
>> ml
>> [4] https://fedoraproject.org/wiki/Releases/28/Schedule
>>
>
> f28-need-rebuild.html [4] shows that most of "need-rebuild" packages are
> assigned to rel-eng, and does not seem to show the "real" owner of packages
> correctly.

About 5K packages is very high for the average mass rebuild failures
(around 25% of the total source packages), there was a dist-git outage
during the mass rebuild and I wonder if a bunch of these were affected
by that issue, any chance rel-eng could check the logs to see if there
were timeouts/503 errors against a bunch of the failures?

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libevent-2.1.8 SONAME change.

[Peter Robinson]

On Thu, Feb 15, 2018 at 11:51 AM, Steve Dickson  wrote:
> Hello,
>
> Yesterday I updated libevent to the latest upstream release.
>
> I mistakenly did not realized there was a SONAME change
> in this update. So if your package is dependent on
> libevent, you are going to have to rebuild.
>
> My apologies for this oversight...

Specifying major version numbers in the library files (extract below)
will ensure a build failure when the soname bumps to ensure this
doesn't happen and that you're aware of it can do do appropriate
communication/side tag builds/etc so it doesn't break rawhide for
everyone else that's trying to get things done in the future.

%{_libdir}/libevent-*.so.*
%{_libdir}/libevent_core-*.so.*
%{_libdir}/libevent_extra-*.so.*
%{_libdir}/libevent_openssl-*.so.*
%{_libdir}/libevent_pthreads-*.so.*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] No more gnupg2 in buildroot

[Peter Robinson]

>> > > On Tue, 2018-02-20 at 19:11 +, Peter Robinson wrote:
>> > > > On Tue, Feb 20, 2018 at 1:11 PM, Igor Gnatenko
>> > > > <ignatenkobr...@fedoraproject.org> wrote:
>> > > > > -BEGIN PGP SIGNED MESSAGE-
>> > > > > Hash: SHA256
>> > > > >
>> > > > > Hey,
>> > > > >
>> > > > > today I've split⁰ librpmsign from rpm-build-libs into its own
>> > > > > subpackage
>> > > > > rpm-
>> > > > > sign-libs.
>> > > >
>> > > > Does this mean that the python bindings no longer depend on
>> > > > rpm-build-libs and hence won't be pulled for a standard minimal
>> > > > install and similar artifacts anymore?
>> > >
>> > > Nope, it means that python bindings will depend *also* on
>> > > rpm-sign-libs 
>> > >
>> > > Since bindings are monolitic, it's not possible to split them easily.
>> >
>> > Actually you could split out build- and sign-bindings (together or
>> > separately) from the main python bindings package. "import rpm"
>> > intentionally lets the build- and sign-module imports to fail to allow
>> > this so as long as the "submodules" depend on the main bindings it
>> > should be ok.
>>
>> Oh and BTW, the reason this hasn't been done is basically the same the
>> sign-libs hadn't been split up: in the past when I last looked at the
>> situation, there just was no benefit to doing so. Back then fedpkg was
>> present in buildroots, and yum + yum-utils used to be included in core
>> set (quite possibly "minimal" install as you know it today didn't even
>> exist), and yum itself dragged in a whole pile of gpg-related packages.
>
> This probably still doesn't make much sense, dnf pulls in python3-rpm and
> python3-gpg. In the end, both are pulling in gnupg2.

It might not to you, or from a pure programming/package sense, but it
would for people doing audit for large companies that come back with
questions like "why is this here? We need to audit all of this to
assess impact" it does make sense. Please fix it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] No more gnupg2 in buildroot

[Peter Robinson]

On Tue, Feb 20, 2018 at 1:11 PM, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hey,
>
> today I've split⁰ librpmsign from rpm-build-libs into its own subpackage rpm-
> sign-libs.

Does this mean that the python bindings no longer depend on
rpm-build-libs and hence won't be pulled for a standard minimal
install and similar artifacts anymore?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using devtoolset for EPEL builds

[Peter Robinson]

On Mon, Nov 13, 2017 at 9:59 AM, Peter Robinson <pbrobin...@gmail.com> wrote:
> On Fri, Oct 21, 2016 at 12:01 AM, Peter Robinson <pbrobin...@gmail.com> wrote:
>>>> I need/want/would like to build new node 6 for EL6, but gcc is too old.
>>>> For that reason, I'd like to use devtoolset-4-gcc, but the build fails
>>>> (obviously) because the package doesn't exist.
>>>>
>>>> So, is there a way to make that work somehow?
>>>> I am not sure about enabling external repos during build, maybe someone
>>>> will be wiser.
>>>
>>>
>>> This has already been discussed several times:
>>> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/KSEYFHCLVPK6DZBDOOPMK46AO65V2SM2/
>>> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/7HWJYGXFOMEROUYY2TQKZLKC2MSAAA7R/
>>> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/message/YQLNZYT5ATELGMHNGET7QCOG3S3UIYT5/
>>>
>>> There are some potential roadblocks, but it comes down to someone writing up
>>> an official proposal and going through the full approval process.
>>
>> So one of the major blockers for me for WRT to using DTS in builds it
>> that it is currently x86_64 only but with the next release, (DTS 6.0)
>> it will support all the RHEL architectures [1] which certainly make it
>> easier to support across platforms. We obviously don't want to deal
>> with it prior to GA and I have no idea when the intended GA is it's
>> certainly worth discussing further now as to what are the
>> requirements, advantages, potential issues etc.
>
> I think this is now worth revisiting, at least for EL7, now DTS is out
> and supports key architectures. Thoughts?
>
> https://developers.redhat.com/blog/2017/10/25/announcing-release-software-collections-developer-toolset-new-compilers/

Smooge: can this be added to the agenda for the next meeting?

I'm happy to do the work to enable it, just want to make sure it's
wanted before I start.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [fedora-arm] cmake segfault on 32-bit arches on Rawhide

[Peter Robinson]

On Thu, Jul 26, 2018 at 9:58 PM, Adam Williamson
 wrote:
> I just tried a rebuild of a package in Rawhide, it worked on most
> arches, but failed on armv7hl and i686 (our only 32-bit arches). On
> both arches, cmake seems to have segfaulted:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=28626511
> https://kojipkgs.fedoraproject.org//work/tasks/6529/28626529/build.log
> https://kojipkgs.fedoraproject.org//work/tasks/6531/28626531/build.log
>
> + /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
> -DCMAKE_BUILD_TYPE=Release .
> /var/tmp/rpm-tmp.0imLnb: line 47: 15870 Segmentation fault  (core
> dumped) /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG"
> -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG"
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG"
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
> -DCMAKE_BUILD_TYPE=Release .
>
> Just wanted to flag this up. I haven't yet tried doing the build in a
> mock to try and get the core out, or anything like that.

Finally got a few cycles to look at this, looks like it's fixed, not
sure what the issue/fix was but I suspect rdieter's new cmake major
version or possibly something as a result of the binutils breakage
fallout.

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

Re: %{valgrind_arches}

[Peter Robinson]

On Sun, Aug 5, 2018 at 5:52 PM, Jeff Johnson  wrote:> Try
>
> ...
> %check
> %ifarch ppc64 ppc64p7

You no longer need ppc64p7 as it's been killed off as of F-26

> exit 0
> %endif
> ...
>
> My comments apply to the rest of what you appear to be proposing everywhere.
> ___
> 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/message/BF5MQ4HNFZPYAJC7MAC7EMB2LNAH7PG4/
___
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/message/Q37JULZPNOV5UMJDL5BFE4P3UULPMULK/

Re: enabling KCM in the Fedora kernels

[Peter Robinson]

On Tue, 7 Aug 2018, 20:47 Kaleb S. KEITHLEY,  wrote:

> Hi,
>
> How would one go about requesting this be enabled by default?
>

Generally either email the ker...@lists.fp.o or open a kernel bugzilla

Upstream NFS-Ganesha devs have been playing with it a bit and got a
> modest performance boost.
>
> It's conceivable that GlusterFS could utilize it too.
>
> Thanks,
>
> --
>
> Kaleb
> ___
> 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/message/JSO5CKPO2GIDS77WLWHVVMRX7MJ5424S/
>
___
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/message/GZDH7MSZGMZLA3EQANC4AR4ZQBWE2B2R/

Re: Kernel lockdown patch & IPAddressAllow/IPAddressDeny systemd feature with Secure Boot

[Peter Robinson]

Probably a good idea to cc: this to the kernel list :-)

I suspect it's intentional but with the planned changes for iptables
etc to be backed by bpf in the upstream kernel sometime in the future
it's likely going to need to be reviewed.

Peter

On Tue, Aug 7, 2018 at 10:25 PM, Timothée Ravier  wrote:
> Booting Fedora with Secure Boot enabled will result in Lockdown being enabled 
> at boot time. This will completly disable the BPF system call for all users 
> [1][2].
>
> Unfortunately, this breaks the IPAddressAllow & IPAddressDeny systemd feature 
> [3][4][5].
>
> I don't have a solution for this, but as far as I understand, this will also 
> prevent other BPF use-cases (for example: Cilium on Fedora CoreOS).
>
> [1] 
> https://src.fedoraproject.org/rpms/kernel/blob/master/f/efi-lockdown.patch#_1525
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/jforbes/linux.git/commit/?h=lockdown=0eb0d0851747787f7182b3e9d0d38edb5925a678
> [3] https://github.com/systemd/systemd/blob/master/src/core/bpf-firewall.c
> [4] https://github.com/systemd/systemd/blob/master/NEWS#L1192
> [5] 
> https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#IPAddressAllow=ADDRESS%5B/PREFIXLENGTH%5D%E2%80%A6
> ___
> 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/message/ZMEWJMQH6DDMV3AZ4IG7LOYMMIETCH42/
___
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/message/RUWDEDQHS5I47YBPEZVEKXNU2BAX2SLU/

Re: F29 System Wide Change: uEFI for ARMv7

[Peter Robinson]

On Tue, Aug 7, 2018 at 11:05 PM, Dominik 'Rathann' Mierzejewski
 wrote:
> On Tuesday, 07 August 2018 at 11:05, Gerd Hoffmann wrote:
>>   Hi,
>>
>> > Gerd Hoffman has a nightly edk2 repo which builds arm32 images. If
>> > someone can figure out the magic qemu incantation to get those working
>> > with Fedora, similar to how aarch64 works, I can do the rest
>> >
>> > https://www.kraxel.org/repos/
>>
>> Yes, it is pretty much identical to aarch64.  My 32bit guest (on 64bit
>> host) config looks like this:
>
> Can you please document this on Fedora wiki somewhere or better yet,
> make mock -r fedora-rawhide-armv7hl automagically work on a non-ARM
> host?

That is quite hard but in the ARM section of the wiki we have how to
run a VM (ARMv7 or aarch64) using qemu/libvirt on other architectures.
___
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/message/R3P3AEWTFMTNW3RMALMGBFX5YZV36QFB/

Re: [HEADS UP] Update libgit2 to 0.27

[Peter Robinson]

On Thu, Aug 16, 2018 at 9:37 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Aug 16, 2018 at 02:14:41PM +1000, Amit Saha wrote:
>> Hi Igor,
>>
>> On Fri, Aug 10, 2018 at 4:33 PM Igor Gnatenko <
>> ignatenkobr...@fedoraproject.org> wrote:
>>
>> > Hello everyone,
>> >
>> > 0.27.x is released long time ago, but I never got time for updating it. It
>> > obviously involves SONAME change.
>> >
>> > The good thing about this release is that it breaks only things in runtime
>> > and only one function changed signature (for building) which nobody uses
>> > anyway.
>> >
>> > I'm going to update library as soon as I get time (possibly on this
>> > weekend if no all dependent packages build fine). I will handle all
>> > rebuilds myself, just sending a notice.
>> >
>> > List of affected packages is below.
>> > Maintainers by package:
>> > R-git2r  qulogic
>> > geany-pluginsdmaphy ohaessler pingou
>> > ghc-bdcs-api clumens
>> > ghc-gi-ggit  dshea
>> > git-evtagignatenkobrain walters
>> > gitg ankursinha ignatenkobrain nacho pwalter
>> > julianalimilan
>> > kf5-ktexteditor  dvratil jgrulich rdieter than
>> > libgit2-glib ignatenkobrain kalev nacho pwalter
>> > python-pygit2pwalter
>> > rubygem-rugged   ignatenkobrain ktdreyer tdawson
>> > rust-exa ignatenkobrain
>> > rust-pretty-git-prompt ignatenkobrain ttomecek
>> > subsurface   pingou
>> >
>> > Packages by maintainer:
>> > ankursinha gitg
>> > clumensghc-bdcs-api
>> > dmaphy geany-plugins
>> > dshea  ghc-gi-ggit
>> > dvratilkf5-ktexteditor
>> > ignatenkobrain git-evtag gitg libgit2-glib rubygem-rugged rust-exa
>> > rust-pretty-git-prompt
>> > jgrulich   kf5-ktexteditor
>> > kalev  libgit2-glib
>> > ktdreyer   rubygem-rugged
>> > nacho  gitg libgit2-glib
>> > nalimilan  julia
>> > ohaessler  geany-plugins
>> > pingou geany-plugins subsurface
>> > pwaltergitg libgit2-glib python-pygit2
>> > qulogicR-git2r
>> > rdieterkf5-ktexteditor
>> > tdawsonrubygem-rugged
>> > than   kf5-ktexteditor
>> > ttomecek   rust-pretty-git-prompt
>> > waltersgit-evtag
>> >
>>
>> Thanks for your work. Just noticed that julia  hasn't been built
>> succesfully (https://koji.fedoraproject.org/koji/packageinfo?packageID=19172)
>> .  Seems to have failed with: "cc1plus: error: unrecognized command line
>> option '-mcet'"
>>
>> This is currently an issue in Fedora Scientific building. What would be the
>> path forward here?
>
> Drop '-mcet'? It's a bit hard to find docs for it, but [1] says:
> """-mcet -fcf-protection enables support for the Control-Flow
> -Enforcement > Technology (CET) feature in future Intel CPUs. This
> -involves the
>  generation of additional NOPs, which are ignored by the current
>  CPUs. It is recommended that you enable this flag now, to detect any
>  issues caused by them (e.g., interactions with dynamic
>  instrumentation frameworks, or performance issues)."""
>
> It sounds like it's not something that is particularly needed at this
> time.
>
> The build log also has a lot of:
> /usr/include/features.h:381:4: warning: #warning _FORTIFY_SOURCE requires 
> compiling with optimization (-O) [-Wcpp]
>  #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
> ^~~
> This sounds like the package is not being built with the distro flags.

A lot of the scientific stacks appear to do as they please here (they
might have an exception, I'm not sure), but they have a tendency to
use very x86 specific ones, in most cases if they used the distro ones
the code would actually build/run across mult arch platforms. After
getting yelled at for trying to fix it I moved on with life.

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

Re: Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

[Peter Robinson]

On Fri, Aug 24, 2018 at 5:18 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Aug 24, 2018 at 02:39:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Aug 24, 2018 at 01:55:54PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Aug 24, 2018 at 12:38:48PM +, Petr Pisar wrote:
> > > > On 2018-08-22, Ben Cotton  wrote:
> > > > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
> > > > >
> > > > > glibc-minimal-langpack is added to @Buildsystem group and installed
> > > > > into the minimal buildroot instead of glibc-all-langpacks. Packages
> > > > > which need more locales than plain C/C.UTF-8/POSIX need to pull them
> > > > > in through BuildRequires.
> > > > >
> > > > I already wrote it in previous thread about this change but it seems
> > > > nobody takes me seriosly. Once again:
> >
> > When you wrote about mock configuration previously, I answered:
> > > Thanks, that's a good point. Do you know where this is configured?
> >
> > This was me taking the issue seriously. I haven't started working on
> > this yet because it got bumped to F30, but I keep a list of all the
> > points raised, including this one.
>
> I turns out Tomasz Torcz already fixed this:
> https://github.com/rpm-software-management/mock/commit/33db2351074753271700ee78c316bf1e36a00594
> > env['LANG'] = os.environ.setdefault('LANG', 'C.UTF-8')

That fixes the mock use case but koji configures and passes it's own
mock config and doesn't necessarily use the mock defaults so while it
may fix mock it's likely koji will need an associated patch as well.
___
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/message/EV6ZLPN4BDBLVKWCRXSTLRRE2U5A2ZF7/

Re: Will there be one more nightly compose for Fedora 29 Beta?

[Peter Robinson]

On Wed, Aug 29, 2018 at 1:40 PM Zamir SUN  wrote:
>
> Hi,
>
> I just wanna know if there will be one more compose for Fedora 29 for
> Beta? To be clear, I've retired some packages in Fedora 29 before the
> freeze which affect the LxQT appearance. But it did not take effect so I
> filed a ticket for Release Engineering but it was handled yesterday. And
> I did not see a new LxQT image till now.
>
> If there won't be a new compose, do I need to fill a FBR to resolve this?

There will be nigjhtly composes every night, there's a fix awaiting to
unblock, I would expect something of some sort today, one way or
another.
___
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: F29 Self-Contained Change: Basic FPGA Support

[Peter Robinson]

On Thu, Jul 19, 2018 at 6:40 PM, Justin Forbes  wrote:
>
>
> On Wed, Jul 18, 2018 at 4:26 PM, Ben Cotton  wrote:
>>
>> == Summary ==
>> A number of devices like Xilinx ZYNQ based devices such as the
>> 96boards Ultra96 and the Intel based UP² have onboard FPGAs. FPGA
>> manager is a vendor-neutral framework that has been upstream in the
>> kernel since 4.4. This is the initial support for FPGAs in Fedora
>> using open source vendor agnostic tools.
>>
>> == Owner ==
>> * Name: Peter Robinson
>> * Email: pbrobinson at fedora project dot org
>>
>> == Detailed Description ==
>>
>> The use of Artificial Intelligence and Machine Learning is growing.
>> There's a number types of compute power used to drive this, the
>> standard system CPU can handle basic work, but for more powerful needs
>> this workload gets moved to auxiliary processors such as GPGPU, FPGAs
>> or Neural Network processors. This will add initial support for FPGAs
>> in Fedora using the Linux Kernel support which currently supports
>> Altera,  Zynq, Lattice and other FPGAs. The use of FPGAs with Open
>> Source software is improving and this is the beginning of ensuring
>> that can be consumed in Fedora as easily as possible.
>>
>> == Benefit to Fedora ==
>>
>> The general purpose use of FPGAs is growing in the tech industry,
>> especially in AI and Machine Learning usecases for IoT and numerous
>> other places where special purpose workload acceleration is needed.
>> This will help developing these workloads on top of Fedora for use
>> across the distribution.
>>
>> == Scope ==
>> * Proposal owners: Kernel and userspace changes
>
>
> Is there a list of the proposed kernel changes anywhere?

Not yet, working on it, basically it will be enabling FPGA and the
associated options there.

>>
>>
>> * Other developers: N/A (not a System Wide Change)
>>
>> == Upgrade/compatibility impact ==
>> There is no impact to upgrades or platforms that don't contain FPGAs.
>>
>> == How To Test ==
>> Testing will require hardware with a supported FPGA. The initial
>> devices for this will be a 96boards Ultra96 or a UP² with a Altera
>> FPGA. Other devices will be supported and testing will be welcome.
>>
>> The process for testing will be linked to here.
>>
>> == User Experience ==
>> Currently the Fedora support for FPGAs is basically non existent.
>> There's currently a few open tools for specific FPGAs. This is the
>> beginning of improving this with the intention of having a uniform as
>> possible  user experience across FPGAs as is currently possible.
>>
>>
>> --
>> Ben Cotton
>> Fedora Program Manager
>> TZ=America/Indiana/Indianapolis
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PNQJ3E4GC4AITL3VMJ5OVZK2MGW2TTLL/
>
>
>
> ___
> 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/message/LJ27WRBNUSTT47SA3SGQV7OOPHOWEJCB/
>
___
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/message/47SJ3XSHC3I2GW2Y3WCB25F5WK4ZOZKQ/

Re: Fedora crda To wireless-regdb Upgrade

[Peter Robinson]

On Fri, Jul 20, 2018 at 7:47 PM, John W. Linville  wrote:
> A mostly "behind the scenes" aspect of the Linux wireless LAN
> (IEEE802.11) subsystem has changed upstream with some system-level
> effects. Replacing an existing package with a cleaner but functionally
> equivalent package is an attractive option, but there are questions
> regarding the update path, how signing the the regulatory database
> should be handled, and how to communicate these changes outward to the
> greater community.
>
> BACKGROUND
>
> Usage of Radio Frequency (RF) spectrum is generally regulated around
> the world. Even unlicensed use of RF spectrum (as with wireless LANs)
> is still subject to some level of local regulation. In order to support
> lawful use of wireless LAN technology with Linux around the world, the
> Linux kernel uses an externally maintained wireless regulatory database
> that encodes relevant information about known regulatory (i.e.
> legal/governmental) domains. The kernel makes use of this information
> in order to enforce wireless regulations for devices under its control,
> although some devices further apply their own limitations at the driver
> or firmware level as well.
>
> For a long time, the Linux kernel relied on a piece of software known
> as the Central Regulatory Domain Agent (CRDA) to feed the kernel with
> regulatory information in response to UDEV events that indicate what
> regulatory domain's rules are to be enforced. Also, within Fedora, the
> setregdomain script runs when a wireless netdev is instantiated. By
> default this script attempts to relate a system’s TZ (i.e. Time Zone)
> setting to a corresponding country code, which is then used to set the
> wireless regulatory domain. The setregdomain script can also use
> alternate means to determine which regulatory domain to request, as
> detailed in the setregdomain.1 man page.
>
> CRDA is maintained upstream in the crda git repository. The wireless
> regulatory database is maintained upstream in the wireless-regdb git
> repository. In Fedora, snapshots of both of the above repositories are
> built within the single crda RPM. This is done to enable build-time
> generation of a key used to sign the wireless-regdb database which is
> then embedded in the concurrently built crda binary in order to
> validate the integrity of the database at runtime.
>
> As of about the upstream 4.15 version of Linux, the kernel's wireless
> developers had determined that future updates to the wireless
> regulatory database may require format changes that would be
> incompatible with the existing CRDA implementation. Further, Linux
> kernel changes over the years now enabled the kernel to load firmware
> images without requiring a userland helper like CRDA. So, the Linux
> kernel wireless developers implemented an in-kernel replacement for
> CRDA. This includes code to validate the wireless regulatory database
> against a signature that is built into the kernel itself.
>
> SITUATION
>
> At present, Fedora kernels are configured to use the in-kernel wireless
> regulatory database loader. If the database is not found or is not
> signed with the key built into the kernel, then boot time messages
> appear, creating the appearance of a problem. For now, there is no
> actual problem. Fedora systems continue to ship with CRDA, which
> continues to perform its original duties with no effective problem as
> of yet. The harmless "error" messages during boot are the only symptom.
> (NOTE: the latest Fedora CRDA package works around this issue,
> eliminating the spurious "error" messages at boot time.)
>
> For now, there is no emergency. We could continue to ship CRDA as-is.
> My concern is that eventually, CRDA may no longer be a viable option
> for future regulatory database updates. In that case, it would seem to
> be better to change now than to do so in a rush later.
>
> Also, replacing the combined CRDA/wireless-regdb "crda" package with a
> new "wireless-regdb" package removes a wart from our package collection
> and replaces it with a package that is simpler and easier to understand
> how it is built. That will be one less "why did they do that?" item
> hanging around in Fedora.
>
> ACTION IN PROGRESS
>
> I have created a wireless-regdb package for Fedora. It simply installs
> the wireless regulatory database binary into /usr/lib/firmware,
> alongside it's pre-existing detached signature. This package includes a
> version of the setregdomain script that is virtually identical to what
> is in the existing crda package. This package has been approved for
> Fedora, but I recently imported the SRPM to the Fedora repository. (htt
> ps://bugzilla.redhat.com/show_bug.cgi?id=1598921)
>
> I have been testing with the above package for a couple of weeks, and
> the user experience is identical to using the crda solution. Given this
> success, I believe that the best option will be to push this package
> with Obsoletes and Provides for crda. This will facilitate a painless
> 

Re: F29 Mass rebuild - Help needed to fix failed build

[Peter Robinson]

On Wed, Jul 18, 2018 at 3:18 PM, Mattias Ellert
 wrote:
> ons 2018-07-18 klockan 15:23 +0200 skrev Zoltan Kota:
>> Hi All,
>>
>> The Mass rebuild of pybliographer failed. See below:
>> 
>> Fwd: releng's pybliographer-1.2.18-4.fc29 failed to build
>>
>> Notification time stamped 2018-07-15 03:04:40 UTC
>>
>> releng's pybliographer-1.2.18-4.fc29 failed to build
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=1121364
>> 
>> It seems the .configure script does not find 'python'. The script uses 
>> Python variable to store python path (configure.ac: AC_PATH_PROG(Python, 
>> python, no) ).
>>
>> Can I add/override this variable in the spec file?
>> eg. %configure Python=%{__python2}
>>
>> or what is the correct syntax/way to fix the issue?
>>
>> Thanks,
>> Zoltan
>
> diff --git a/pybliographer.spec b/pybliographer.spec
> index ac77e97..4649812 100644
> --- a/pybliographer.spec
> +++ b/pybliographer.spec
> @@ -47,6 +47,7 @@ file formats: BibTeX, ISI, Medline, Ovid, Refer.
>  %setup -q
>
>  %build
> +export Python=/usr/bin/python2

Or you can add:

BuildRequires: python-unversioned-command
___
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/message/D6E6N67IUJ3IJM7NMML7VUFJYEC2HSMN/

Re: [HEADS UP] Removal of GCC from the buildroot

[Peter Robinson]

On Sun, Jul 22, 2018 at 7:04 PM, Kevin Fenzi  wrote:
> On 07/21/2018 02:54 PM, Andrew Lutomirski wrote:
> On Jul 15, 2018, at 5:47 AM, Richard W.M. Jones  wrote:
>
> On Fri, Jul 13, 2018 at 04:05:42PM +0200, Mikolaj Izdebski wrote:
> On 07/12/2018 10:17 PM, Richard W.M. Jones wrote:
> Does each build start with its own fresh VM?  Do you care about the
> data in that build VM if either qemu or the host crashes?  If the
> answers are 'Yes' and 'No' respectively to these questions then IMHO
> this is the ideal situation for cache=unsafe.

 The answers are 'No' and 'Not much'.

 1. VMs are installed once and are running for week/months until they are
 reinstalled. In the meantime guests and hosts are rebooted during
 routine maintenance, to apply updates.
>>>
>>> In this case my preferred advice would be: DO NOT use cache=unsafe.
>>>
>>> We've only tested scenarios for very short-lived build or temporary
>>> VMs (for example when I was building RISC-V packages before we had
>>> Koji, I used a script which created a VM per build and there it made
>>> sense to use cache=unsafe).
>>>
>>> I do not think it's a good idea to be using this for VMs which are in
>>> any way long-lived as there could be unforeseen side effects which I'm
>>> not aware of and certainly have never tested.
>>>
 2. There would be no data loss in case of host or hypervisor crash.
 Worst case, if guest operating system was corrupted sysadmins would need
 to trigger VM install.
>>>
>>> Host crash => yes you'd definitely need to reinstall that VM.
>>>
>>> It's not a worst case, a host crash would near-definitely corrupt a VM
>>> that was ignoring flush requests.  It might even corrupt in an
>>> undetectable way (eg. throwing away data while leaving metadata
>>> intact).
>>
>> Would it make sense to boot the builders with -snapshot and
>> cache=unsafe?  After all, during normal operation, they don’t need to
>> persist anything.
>
> I don't think thats at all worth it for a slight bit of build speed.
>
>>
>> It might even be reasonable to reboot the VMs after every single build.
>
> Well, koji has no ability to do that currently, and note that some
> builders can in fact be doing multiple builds at once, so you would need
> to make sure all in progress builds were done and no new ones arrived, etc.
>
> There was a project a while back to make koji builders more dynamic (I
> think by making them cloud instances), but I am not sure whatever
> happened with it.

I seem to remember there was discussion of replacing mock with docker
containers as well, again I don't know what happened to that either.
___
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/message/JSIMJH2WWVQB7YAC7KPPBJ7YENRLJTFS/

Re: dnf history - change in how rpmdb checksum is computed

[Peter Robinson]

On Thu, Jul 19, 2018 at 3:26 PM, Neal Gompa  wrote:
> On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling  wrote:
>>
>> Regarding these two questions:
>>
 Are there any concerns about such change?
 I believe that >90% users wouldn't notice anything as it's related to the 
 history database only.
>>
>>
>>>
>>> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko 
>>>  wrote:
>>> Since we've changed the database entirely, what's the point of keeping same 
>>> algorithm for calculating checksum?
>>
>>
>>> On Wed, Jul 18, 2018 at 9:34 AM Daniel P. Berrangé  
>>> wrote:
>>> What's the benefit in changing to be compatible with YUM as opposed
>>> to stickin with current alogorithm ?
>>>
>>> Surely if we don't change it, even fewer users will notice that DNF's
>>> behaviour is different from YUM's, since DNF has been the default for
>>> many releases now.
>>>
>>> I could understand the motiviation to stay compatible with YUM if we
>>> were only just about to switch Fedora from YUM to DNF, but time is
>>> way in the past now. Shouldn't we optimize for the fact that DNF is
>>> the more widely deployed & used tool, and thus not worry about
>>> YUM compatibility in respect of the history DB ?
>>
>>
>> It is true that going forward in the Fedora world it matters less.  It is 
>> more of an impact for yum-3 compatibility as yum4/dnf is being considered in 
>> the RHEL7/CentOS7 userspace environments as described at 
>> https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/
>>
>> Currently yum version 3 and what the proof-of-concept project is calling 
>> yum4 work very well together side by side.  Users can safely switch back and 
>> forth.  The major problem is yum/dnf histories being different and the rpmdb 
>> checksum difference is a blocker for resolving the history compatibility.
>>
>> So think of this as an effort to bring package management parity between 
>> Fedora, RHEL 7, & CentOS7, as the latter two still have a long life ahead of 
>> them.
>>
>
> Is there a reason why we can't change YUM to match the DNF behavior?
> IMO, the YUM behavior is nonsense and isn't even a valid package
> identifier.

What about all the enterprise applications and other traditional
platforms that are deployed that expect the existing functionality or
outcomes, not saying it's necessarily correct but there's a lot of
technical debt out there. In a lot of cases there's legacy out there
that needs to be supported and that requires existing APIs to work as
they currently do so there can be migrations.

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

Re: GNOME 3.30.0 megaupdate

[Peter Robinson]

>> As many of you know, I've been gone half the summer. I'm back now since
>> Monday though and just in time for GNOME 3.30.0 :)
>>
>> We are quite a bit behind with the builds, like half of GNOME is still
>> at 3.28.x or at various stages of 3.29.x snapshots, so there's quite a
>> bit of catching up to do.
>>
>> I just requested a f29-gnome side tag and will be commencing 3.30.0
>> builds shortly. When the builds are done, I'll try to collect all the
>> builds in a single Bodhi megaupdate as usual. Please use 'fedpkg build
>> --target f29-gnome' if you are helping with builds, and I'll pick up
>> anything that is tagged with f29-gnome in koji.
>>
>> Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29
>> Beta, I guess it may be too late for that. Any opinions from QA here?
>>
>> There's also a few 3.30.0 builds already submitted separately into
>> Bodhi. I may try to collect those to the megaupdate as well, not sure
>> yet. Let's see how things go :)
>>
>
>
> I'd be *strongly* disinclined to give a Freeze Exception for a GNOME 
> mega-update. There's just far too much that could go wrong. Please plan to 
> land the mega-update in updates-testing once the Freeze lifts. U-T is enabled 
> by default on the Beta, so people will pick it up on their first post-install 
> update anyway.

Ultimately by declining it now all we're doing is pushing out the
pain, if any, to post beta which IMO is even worse given we're then
deferring it to GA freeze which is even worse!

Also there has been a precedent in the past for putting this in,
whether that is right or not I have no opinion.

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

Re: Fedora 29 Beta blocker status mail #1

[Peter Robinson]

On Sun, Sep 9, 2018 at 3:06 PM Robert Moskowitz  wrote:
>
> Adam,
>
> What is the position on openSSL 1.1.1?
>
> The openSSL team has targeted Sept 11 as the release date, and I have
> not seen any other word on the user list.  Of course there may be
> different discussion elsewhere.
>
> For all the features of TLS 1.3, you want openSSL 1.1.1.
>
> Speaking of TLS 1.3, I don't know what else needs to be done for support
> of it, but there is an intentional change in versions from the draft to
> the RFC...

All of the above is up to the openssl maintainer, it would still be
available in updates-testing for use anyway.

> Disclaimer:  I have a personal need of 1.1.1, as the PR that addressed
> my problems with creating EDDSA certs did not make the pre9 version, but
> it is in the master now.
>
> Bob
>
> On 9/7/18 8:20 PM, Adam Williamson wrote:
> > Hi folks! As we've only got a week to go for Beta, here's an update on
> > blocker bug status.
> >
> > tl;dr action summary
> > 
> >
> > Accepted blockers
> > -
> >
> > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1582524
> > ACTION: QA / reporter to verify whether fixed in 3.2.0-2.fc29
> >
> > 2. https://bugzilla.redhat.com/show_bug.cgi?id=1596540
> > ACTION: dnf team to fix bug and send out update
> >
> > 3. https://bugzilla.redhat.com/show_bug.cgi?id=1616167
> > ACTION: FESCo to decide on how much fixing is needed
> >
> > 4. https://bugzilla.redhat.com/show_bug.cgi?id=1615969
> > ACTION: nirik to build for for f29 and edit update
> >
> > 5. https://bugzilla.redhat.com/show_bug.cgi?id=1572916
> > ACTION: kernel team to report whether anything still needed
> >
> > Proposed blockers
> > -
> >
> > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1624972
> > ACTION: blocker reviewers to vote on status, QA to verify fix
> >
> > 2. https://bugzilla.redhat.com/show_bug.cgi?id=1626413
> > ACTION: bcl to ensure fix is ready in case of need
> >
> > 3. https://bugzilla.redhat.com/show_bug.cgi?id=1616269
> > ACTION: adamw to send out call-for-testing mail
> >
> > Bug-by-bug detail
> > =
> >
> > Accepted blockers
> > -
> >
> > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1582524 - dnf - POST
> > dnf doesn't follow default profile for an enabled non-default stream
> >
> > This is reported to be fixed in 3.3.0, but I'm not 100% sure if it's
> > fixed in 3.2.0-2.fc29, the build currently in F29. I've asked for
> > clarification in the bug.
> >
> > 2. https://bugzilla.redhat.com/show_bug.cgi?id=1596540 - dnf - ASSIGNED
> > RuntimeError: C++ std::exception: Exec failed: no such table: 
> > main.trans_cmdline
> >
> > This is one of several crasher bugs reported with DNF 3+ which seem to
> > relate to the history database. This one has a clear reproducer in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1596540#c30 , and dmach
> > committed to a fix there. We are waiting on that fix.
> >
> > 3. https://bugzilla.redhat.com/show_bug.cgi?id=1616167 - dnf - NEW
> > dnf doesn't record modular metadata in a local database
> >
> > This one was referred to FESCo: https://pagure.io/fesco/issue/1974 . It
> > will be discussed on Monday, and a decision made about to what extent
> > it needs to be addressed for Beta and/or Final.
> >
> > 4. https://bugzilla.redhat.com/show_bug.cgi?id=1615969 - grub2 - VERIFIED
> > AArch64 - Error when booting "error: out of memory."
> >
> > This was fixed by grub2-2.02-52.fc29, but that build is the one which
> > broke many x86_64 UEFI installs and thus was unpushed. We need a new
> > grub2 build which retains the fix for this bug and also fixes the
> > x86_64 UEFI bug. As pjones is apparently away ATM, I have asked nirik
> > if he can do this.
> >
> > 5. https://bugzilla.redhat.com/show_bug.cgi?id=1572916 - kernel - NEW
> > kernel after 4.17.0-0.rc2.git0.1.fc29 waits for random entropy on boot
> >
> > This one's been sitting on the blocker list a long time, I'm not
> > sure if anything more is needed here. I have asked the kernel folks for
> > an update.
> >
> > Proposed blockers
> > -
> >
> > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1624972 - lightdm - MODIFIED
> > No GUI desktop
> >
> > This looks like a clear blocker (Xfce ARM image failing to boot - Xfce
> > is the blocking desktop on 32-bit ARM), but it also seems like a
> > probable fix has been identified and we only need to push it.
> >
> > 2. https://bugzilla.redhat.com/show_bug.cgi?id=1626413 - lorax - NEW
> > Add dependency on librepo
> >
> > It seems that lorax has a librepo dep it does not express, but this was
> > hidden by dnf depending on librepo; apparently newer dnf builds no
> > longer do, so lorax needs to express the dependency. This is
> > technically not a blocker so long as the newer dnf builds aren't
> > actually in stable themselves, but as we're likely to need one to fix
> > the accepted DNF blockers, we'll want to have the lorax fix ready to
> > 

Re: GNOME 3.30.0 megaupdate

[Peter Robinson]

> On Thu, Sep 6, 2018 at 12:33 PM, Adam Williamson
>  wrote:
> > On Thu, 2018-09-06 at 10:41 -0600, Chris Murphy wrote:
> >> Fedora folks have been testing 3.29 for weeks now. Fedora people
> >> haven't been testing 3.30 because it's not really available to test.
> >> So I think it's reasonable for a GNOME specific change to explicitly
> >> state a request and expectation for a beta freeze exception for every
> >> Fedora release so that a .0 lands in the beta, and see if FESCo thinks
> >> that's sane and accepts the change.
> >
> > Uh, to be clear here: you do know that 3.29 is the development series
> > for 3.30, right? It's not a sudden major release jump. Effectively what
> > we have right now is more or less 3.30 rc0-and-a-bit; the proposal is
> > to go from that to 3.30 stable.
>
> I'm aware.
>
> But it's also striking me as a big deal that's no big deal, like we're
> playing a game of upping the vaguarity ante.

Nope, completely not, we do this most release cycles and not just
gnome... it also doesn't affect any of the artifacts that don't ship
gnome compents.

Having been involved in this process for so long I'm kind of surprised
the biggest deal of all of this is that this is a "big deal"... the
fact is post beta we open up the flood gates again so this is going to
be there so IMO I'd sooner it now where we can get people that do a
"quick fly by beta live CD boot" before they upgrade and catch the
issues now than at GA :)
___
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: [F29 only] Dropping requirements for initscripts package from specfiles

[Peter Robinson]

On Tue, Jun 19, 2018 at 3:56 PM, David Kaspar [Dee'Kej]
 wrote:
> Hello people,
>
> I'm working on making Fedora being able to function completely without the
> 'initscripts' package (hopefully) some day in the future. I have done some
> cleanup in initscripts recently, and I would like to ask maintainers of
> packages listed below to check if their package(s) still really need the
> initscripts package to function properly (for any reason).
>
> It seems that for many packages the requirement of initscripts is just a
> leftover from past. If the package does not need the initscripts any longer,
> please remove the requirement in Rawhide (F29) and forward. (Do not backport
> this change into F28 or F27, it would break things.)
>
> NOTE: In case you are depending on initscripts because of networking scripts
> (ifup/ifdown, etc.), then you will need to update your specfile to depend
> directly on new package 'network-scripts' (instead of 'initscripts').

It would be useful to do a similar change for chkconfig and split out
the alternatives binaries into a separate package as a bunch of the
chkconfig stuff is directly related to sys V and the initscripts
package.

Peter

> I've opened bug reports for each of the packages listed here, and created a
> tracking BZ for it:
> https://bugzilla.redhat.com/show_bug.cgi?id=1592330
>
> List of packages still depending on initscripts (some of them were already
> fixed):
>  3proxy
>  barry
>  boomaga-selinux
>  Canna
>  clamsmtp
>  conmux
>  crossfire-selinux
>  cyphesis
>  device-mapper-multipath
>  dpm-xrootd
>  ebnetd-common
>  exim
>  exim-clamav
>  foghorn
>  freeipa-client
>  glpi
>  groonga-munin-plugins
>  groonga-server-gqtp
>  iipsrv
>  isdn4k-utils
>  kbd
>  libstoragemgmt
>  mailman-3
>  nightview-server
>  node
>  ntop
>  numad
>  omniORB
>  openslp-server
>  os-net-config
>  pcp
>  pcsc-cyberjack
>  pgbouncer
>  plymouth
>  ppp
>  pure-ftpd-selinux
>  ratbox-services
>  sagator-core
>  spacewalk-config
>  spamassassin
>  spawn-fcgi
>  sslogger
>  systemtap-initscript
>  systemtap-server
>  tigervnc-server-minimal
>  torque-mom
>  torque-scheduler
>  torque-server
>  trafficserver
>  varnish
>  vdsm
>  vhostmd
>  vpnc
>  vte
>  vte291
>  vte3
>  wine-desktop
>  xboxdrv
>
> Thank you, and best regards! :)
>
> David Kaspar [Dee'Kej]
> Associate Software Engineer
> Brno, Czech Republic
>
> RED HAT | TRIED. TESTED. TRUSTED.
> Every airline in the Fortune 500 relies on Red Hat.
> Find out why at Trusted | Red Hat.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MRI2HG2WTDJ2BGZTZMZ3JLUMKGEFWM6P/
>
___
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/message/I4DLROLUEUAAOUZFBKS3XGXYI5UYGGOJ/

Re: F29 System Wide Change: uEFI for ARMv7

[Peter Robinson]

On Tue, Jul 10, 2018 at 9:22 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
>> On 07/03/2018 05:15 AM, Jan Kurik wrote:
>> > Move to uEFI as the default boot mechanism for ARMv7 devices.
>>
>> Will this work with virt-manager too? Currently, while aarch64 boots via
>> uEFI there, it seems that armv7 is only supported by manually specifying
>> a kernel and initrd.
>
> Ping.

Ping? Who or what? It's explicitly mentioned in the docs:
https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Dependencies
___
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/message/RDMGWFBQGBS72GF6DCNI3HAOFMM7LACH/

Re: Packages which use banned tags

[Peter Robinson]

On Tue, Jul 10, 2018 at 9:43 PM, Jason L Tibbitts III  wrote:
> The packaging guidelines indicate that the following tags must not be
> used:
>   Copyright:
>   Packager:
>   Vendor:
>   PreReq:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
>
> I wasn't aware that a package would even build if the first three were
> used, but it seems that a few instances of these tags persist.
>
> Nothing uses Copyright:.
>
> Five packages use Vendor:
>   dpkg etoys gold netbeans storhaug
>
> Packager: is used by mcollective
>
> apmud has Prereq: chkconfig which is obviously a sign that something is
> amiss.  But it's also marked ExclusiveArch: ppc which means that it
> hasn't existed anywhere since we dropped 32 bit ppc around, what, Fedora
> 12?  The only commits are from mass rebuilds and people doing general
> cleanup.
>
> ceph has "PreReq: %fillup_prereq" and I don't even know what that does.
> It seems to be inside of some suse-exclusive block, and so I'm not sure
> what is supposed to happen.  Which is why that kind of thing is not
> permitted in Fedora.  I guess that has to be another of those "nobody
> can touch this" packages.
>
> In any case, I will now proceed to dead.package apmud, remove the few
> Vendor: and Packager: uses and try to pretend ceph does not exist.  But
> for the record, here are the usual (but pleasantly short) lists:
>
> Maintainers by package:
> apmuddwmw2
> ceph branto dachary dmick ke4qqq kkeithle ktdreyer steve 
> stingray
> dpkg kanarip sergiomb topdog
> etoysdsd gavin tuxbrewr

I want intending on retiring eToys in F-29 anyway, it's part of the
Sugar stack, we've not shipped in SoaS for sometime and is for all
intents and purpose dead upstream. I'll do that this week.

> gold zaniyah
> mcollective  maxamillion
> netbeans moceap
> storhaug kkeithle
>
> Packages by maintainer:
> branto ceph
> dacharyceph
> dmick  ceph
> dsdetoys
> dwmw2  apmud
> gavin  etoys
> kanaripdpkg
> ke4qqq ceph
> kkeithle   ceph storhaug
> ktdreyer   ceph
> maxamillion mcollective
> moceap netbeans
> sergiomb   dpkg
> steve  ceph
> stingray   ceph
> topdog dpkg
> tuxbrewr   etoys
> zaniyahgold
> ___
> 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/message/RALCUFKEKK6MKFLDGL3K7WQJSOV5FK32/
___
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/message/QNUNQTGKOVC4C2LYLCZUSNHVBA6QD6BN/

Re: F29 System Wide Change: ZRAM support for ARM images

[Peter Robinson]

On Tue, Jul 10, 2018 at 10:50 PM, Kevin Fenzi  wrote:
> On 07/03/2018 05:39 AM, Jan Kurik wrote:
>> = Proposed System Wide Change: ZRAM support for ARM images =
>> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>>
>>
>> Owner(s):
>>   * Peter Robinson 
>>
>>
>> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
>> improve performance and reliability on ARM Single Board Computers such
>> a the Raspberry Pi.
>>
>>
>> == Detailed description ==
>> Current Fedora release artifacts for ARM platforms enable a small
>> amount of swap by default. While this has generally works OK in the
>> past it can cause a number of issues primarily wearing out SD cards
>> due to excess use of wear leveling. ZRAM can mitigate this and provide
>> more memory for ARM SBCs by compressing part of memory and using it as
>> a swap space. This provides better performance and improved
>> reliability across this class of device which overall provides a
>> better end user experience.
>
> So, it looks like anaconda has zram support and enables it if there's
> 2GB memory or less or you pass 'inst.zram=1' on the boot line.

It does.

> How does this interact with that? Could we perhaps get both of them to
> use the same setup so we don't have multiple places we enable this?

It doesn't, my understanding from a quick look is that anaconda
doesn't do anything persistent but rather loads the module and pokes
at the sys interface. I admit though I've not yet looked closely at
their implementation, although it is on my todo list.

Also on my todo list is possibly integrating with anaconda that it
installs/enables it when certain criteria are met similar to what it
does with other things like disk utilities if a particular FS is used
although this would likely be a future release once we better know how
well it works, side effects etc.

> Perhaps it's worth enabling on other arches as well?

Quite probably. There will be nothing arch specific about the
implementation. My intention here is to enable it on the pre-canned
images we produce for ARM. It's probably something worth looking at
for live images too but it's not something I have much interest in,
although I am very happy to assist those that might be once we've got
some data on how it's looking on the ARM images.

> Finally I wonder if the 2GB limit is still right?
> Should we increase that? I have heard of lot of people say recent
> releases need more memory, this might help that out?

I believe it would likely be useful on higher memory devices, enabling
it on the ARM pre canned images means we're looking at devices in the
512Mb to 8Gb range with most <=2Gb. In this range of devices it also
has the advantage that the swap won't pound the usually mSD/emmc
storage with the impact on wear leveling etc, this later is as much
the reason for doing it as the better performance.

I think there's a bunch of things we'll tweak as we go and I don't
expect to be placing a stick in the mud and calling this done.
___
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/message/DVVUGSE3ALUH4SLE5R2IPOR4I3Q2P3DK/

Re: F29 System Wide Change: ZRAM support for ARM images

[Peter Robinson]

>> = Proposed System Wide Change: ZRAM support for ARM images =
>> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>>
>>
>> Owner(s):
>>   * Peter Robinson 
>>
>>
>> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
>> improve performance and reliability on ARM Single Board Computers such
>> a the Raspberry Pi.
>>
>>
>> == Detailed description ==
>> Current Fedora release artifacts for ARM platforms enable a small
>> amount of swap by default. While this has generally works OK in the
>> past it can cause a number of issues primarily wearing out SD cards
>> due to excess use of wear leveling. ZRAM can mitigate this and provide
>> more memory for ARM SBCs by compressing part of memory and using it as
>> a swap space. This provides better performance and improved
>> reliability across this class of device which overall provides a
>> better end user experience.
>>
>>
>> == Scope ==
>>
>> * Proposal owners:
>> Package and include zram config and systemd units.
>
> Which "zram" config? There have been various attempts, e.g.
> https://bugzilla.redhat.com/show_bug.cgi?id=1469726. Do you plan
> to reuse one of the existing projects, or create something from
> scratch?

I plan on creating one from new but using various information from
these and other distros (I literally have dozens of tabs open of this
ATM) and information from the upstream kernel maintainer. The various
Fedora attempts all seem to be derived from one config [1]. The zram
upstream has evolved since then.

[1] https://github.com/mystilleef/FedoraZram
___
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/message/4ACHPP6Q6RL47QKWZ4NMTQISEJNKR473/

Re: F29 System Wide Change: ZRAM support for ARM images

[Peter Robinson]

On Wed, Jul 11, 2018 at 8:50 AM, Peter Robinson  wrote:
> On Tue, Jul 10, 2018 at 10:50 PM, Kevin Fenzi  wrote:
>> On 07/03/2018 05:39 AM, Jan Kurik wrote:
>>> = Proposed System Wide Change: ZRAM support for ARM images =
>>> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>>>
>>>
>>> Owner(s):
>>>   * Peter Robinson 
>>>
>>>
>>> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
>>> improve performance and reliability on ARM Single Board Computers such
>>> a the Raspberry Pi.
>>>
>>>
>>> == Detailed description ==
>>> Current Fedora release artifacts for ARM platforms enable a small
>>> amount of swap by default. While this has generally works OK in the
>>> past it can cause a number of issues primarily wearing out SD cards
>>> due to excess use of wear leveling. ZRAM can mitigate this and provide
>>> more memory for ARM SBCs by compressing part of memory and using it as
>>> a swap space. This provides better performance and improved
>>> reliability across this class of device which overall provides a
>>> better end user experience.
>>
>> So, it looks like anaconda has zram support and enables it if there's
>> 2GB memory or less or you pass 'inst.zram=1' on the boot line.
>
> It does.
>
>> How does this interact with that? Could we perhaps get both of them to
>> use the same setup so we don't have multiple places we enable this?
>
> It doesn't, my understanding from a quick look is that anaconda
> doesn't do anything persistent but rather loads the module and pokes
> at the sys interface. I admit though I've not yet looked closely at
> their implementation, although it is on my todo list.
>
> Also on my todo list is possibly integrating with anaconda that it
> installs/enables it when certain criteria are met similar to what it
> does with other things like disk utilities if a particular FS is used
> although this would likely be a future release once we better know how
> well it works, side effects etc.
>
>> Perhaps it's worth enabling on other arches as well?
>
> Quite probably. There will be nothing arch specific about the
> implementation. My intention here is to enable it on the pre-canned
> images we produce for ARM. It's probably something worth looking at
> for live images too but it's not something I have much interest in,
> although I am very happy to assist those that might be once we've got
> some data on how it's looking on the ARM images.

I forgot to mention here I'm intending on using it on x86 for IoT and
Hans has been investigating it on the Baytrail class of devices he's
been working on and I've been collaborating with him on some of the
detais.

>> Finally I wonder if the 2GB limit is still right?
>> Should we increase that? I have heard of lot of people say recent
>> releases need more memory, this might help that out?
>
> I believe it would likely be useful on higher memory devices, enabling
> it on the ARM pre canned images means we're looking at devices in the
> 512Mb to 8Gb range with most <=2Gb. In this range of devices it also
> has the advantage that the swap won't pound the usually mSD/emmc
> storage with the impact on wear leveling etc, this later is as much
> the reason for doing it as the better performance.
>
> I think there's a bunch of things we'll tweak as we go and I don't
> expect to be placing a stick in the mud and calling this done.
___
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/message/RGVVWKUGP4FLBF4P4XXLQM4SLZHZHKJY/

Re: F29 System Wide Change: ZRAM support for ARM images

[Peter Robinson]

On Wed, Jul 11, 2018 at 10:44 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Wed, Jul 11, 2018 at 08:33:36AM +0100, Peter Robinson wrote:
>> >> = Proposed System Wide Change: ZRAM support for ARM images =
>> >> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
>> >>
>> >>
>> >> Owner(s):
>> >>   * Peter Robinson 
>> >>
>> >>
>> >> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
>> >> improve performance and reliability on ARM Single Board Computers such
>> >> a the Raspberry Pi.
>> >>
>> >>
>> >> == Detailed description ==
>> >> Current Fedora release artifacts for ARM platforms enable a small
>> >> amount of swap by default. While this has generally works OK in the
>> >> past it can cause a number of issues primarily wearing out SD cards
>> >> due to excess use of wear leveling. ZRAM can mitigate this and provide
>> >> more memory for ARM SBCs by compressing part of memory and using it as
>> >> a swap space. This provides better performance and improved
>> >> reliability across this class of device which overall provides a
>> >> better end user experience.
>> >>
>> >>
>> >> == Scope ==
>> >>
>> >> * Proposal owners:
>> >> Package and include zram config and systemd units.
>> >
>> > Which "zram" config? There have been various attempts, e.g.
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1469726. Do you plan
>> > to reuse one of the existing projects, or create something from
>> > scratch?
>>
>> I plan on creating one from new but using various information from
>> these and other distros (I literally have dozens of tabs open of this
>> ATM) and information from the upstream kernel maintainer. The various
>> Fedora attempts all seem to be derived from one config [1]. The zram
>> upstream has evolved since then.
>
> Thanks.
>
> FWIW, I loaded the zram module on my laptop, and I see:
> - /dev/zram0 is created
> - /sys/block/zram0/max_comp_streams is 4, which matches the number of
>   CPU threads I have (1 socket × 2 cores × 2 threads each).
>
> So creating multiple devices like [1] seems pointless, and also adjusting
> max_comp_streams like anaconda does unnecessary. That simplifies things.

Correct, my intention is to create one device, this is the opinion of
the upstream maintainer as well. It will keep things more simple, we
have some ARM devices which have 10 cores and 1-2Gb of RAM, I don't
see it makes sense to make 10 devices as it would likely affect the
effectiveness of the swap if you have lots of small swap partitions.

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

Re: F29 System Wide Change: uEFI for ARMv7

[Peter Robinson]

>> >> > Move to uEFI as the default boot mechanism for ARMv7 devices.
>> >>
>> >> Will this work with virt-manager too? Currently, while aarch64 boots via
>> >> uEFI there, it seems that armv7 is only supported by manually specifying
>> >> a kernel and initrd.
>> >
>> > Ping.
>>
>> Ping? Who or what? It's explicitly mentioned in the docs:
>> https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Dependencies
>
> That part you link to wasn't in the abridged version sent to the
> mailing list. And even if it was, it should be OK to ask for

Well it was there from the original version that I submitted

> an explanation like that, and expect an answer.

Sure but "ping?" relays nothing at all.
___
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/message/DTSWH3VJQNCUZL2VVMX7PSDQMOV4BSEG/

Re: F29 System Wide Change: uEFI for ARMv7

[Peter Robinson]

On Wed, Jul 11, 2018 at 12:13 AM, Kyle Marek  wrote:
> On 07/10/2018 04:51 PM, Cole Robinson wrote:
>> On 07/10/2018 04:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
 On 07/03/2018 05:15 AM, Jan Kurik wrote:
> Move to uEFI as the default boot mechanism for ARMv7 devices.
 Will this work with virt-manager too? Currently, while aarch64 boots via
 uEFI there, it seems that armv7 is only supported by manually specifying
 a kernel and initrd.
>>> Ping.
>>>
>> Currently this won't work with virt-manager.
>>
>> If this arm32 stuff works similar to aarch64, then what we need is:
>> extend the edk2 package to build working arm32 images, some packaging
>> changes to libvirt, and some straightforward-but-not-trivial changes to
>> virt-manager to match.
>>
>> Gerd Hoffman has a nightly edk2 repo which builds arm32 images. If
>> someone can figure out the magic qemu incantation to get those working
>> with Fedora, similar to how aarch64 works, I can do the rest
>
> Is it not the usual "-drive
> file=OVMF_CODE.fd,format=raw,readonly=on,if=plfash" on a "-machine virt"
> type of VM?

Yes, it should be.
___
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/message/CJV2EIRR2ZMQYAFM6HPOEIHFYDLGVX4C/

Re: F29 System Wide Change: uEFI for ARMv7

[Peter Robinson]

On Tue, Jul 10, 2018 at 9:51 PM, Cole Robinson  wrote:
> On 07/10/2018 04:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
>>> On 07/03/2018 05:15 AM, Jan Kurik wrote:
 Move to uEFI as the default boot mechanism for ARMv7 devices.
>>>
>>> Will this work with virt-manager too? Currently, while aarch64 boots via
>>> uEFI there, it seems that armv7 is only supported by manually specifying
>>> a kernel and initrd.
>>
>> Ping.
>>
>
> Currently this won't work with virt-manager.

Yes, I'm aware.

> If this arm32 stuff works similar to aarch64, then what we need is:
> extend the edk2 package to build working arm32 images, some packaging
> changes to libvirt, and some straightforward-but-not-trivial changes to
> virt-manager to match.

My intention here was to look at the aarch64 support and copy that and
submit a patch. I would love help and I intended to reach out but have
been thumped with other escalations and problems so haven't had the
chance yet.

There is already an edk2-arm subpackage [1] in the Fedora builds and
it appears to work with my very basic testing.

> Gerd Hoffman has a nightly edk2 repo which builds arm32 images. If
> someone can figure out the magic qemu incantation to get those working
> with Fedora, similar to how aarch64 works, I can do the rest

Awesome, will reach out to work with you, thank you!

> https://www.kraxel.org/repos/

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1095923
___
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/message/MPA7ACORPAH2QVWELMREXH3BP3OGAXR2/

Re: [F29 only] Dropping requirements for initscripts package from specfiles

[Peter Robinson]

On Wed, Jul 4, 2018 at 1:18 PM, Neal Gompa  wrote:
> On Wed, Jul 4, 2018 at 8:16 AM Peter Robinson  wrote:
>>
>> On Tue, Jun 19, 2018 at 3:56 PM, David Kaspar [Dee'Kej]
>>  wrote:
>> > Hello people,
>> >
>> > I'm working on making Fedora being able to function completely without the
>> > 'initscripts' package (hopefully) some day in the future. I have done some
>> > cleanup in initscripts recently, and I would like to ask maintainers of
>> > packages listed below to check if their package(s) still really need the
>> > initscripts package to function properly (for any reason).
>> >
>> > It seems that for many packages the requirement of initscripts is just a
>> > leftover from past. If the package does not need the initscripts any 
>> > longer,
>> > please remove the requirement in Rawhide (F29) and forward. (Do not 
>> > backport
>> > this change into F28 or F27, it would break things.)
>> >
>> > NOTE: In case you are depending on initscripts because of networking 
>> > scripts
>> > (ifup/ifdown, etc.), then you will need to update your specfile to depend
>> > directly on new package 'network-scripts' (instead of 'initscripts').
>>
>> It would be useful to do a similar change for chkconfig and split out
>> the alternatives binaries into a separate package as a bunch of the
>> chkconfig stuff is directly related to sys V and the initscripts
>> package.
>>
>
> Since chkconfig can be used to manipulate systemd units indirectly, I
> don't think that's quite so necessary. However, it might make sense
> for the service(8) command implementation to be subpackaged in
> initscripts so that it can be installed without the legacy stuff.

Yes, it can be, it's not necessary though and the package as it stands
contains a lot of legacy stuff and is strictly optional.
___
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/message/LBSAOMQ2YROGKVFVIPFBUMC4LJ4TRAXJ/

Re: GCC 8.0.1 updates in F28

[Peter Robinson]

On Thu, Mar 15, 2018 at 6:25 AM, Vascom  wrote:
> Hi.
>
> GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> Or it will be updated soon so we can build some packages failed to build
> now?
> Or better use build override new gcc for this packages?

Is there a particular bug fix that you need in the GA release you need
for building against? The gcc release in stable is pretty close to GA
so unless there's a specific bug that was fixed between the last
stable build and the GA build it should make no difference to your
builds.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 8.0.1 updates in F28

[Peter Robinson]

On Thu, 15 Mar 2018, 10:26 Dan Horák, <d...@danny.cz> wrote:

> On Thu, 15 Mar 2018 17:11:49 +0000
> Peter Robinson <pbrobin...@gmail.com> wrote:
>
> > On Thu, Mar 15, 2018 at 6:25 AM, Vascom <vasc...@gmail.com> wrote:
> > > Hi.
> > >
> > > GCC 8.0.1-0.16 in F28 repo is freezed until F28 release?
> > > Or it will be updated soon so we can build some packages failed to
> > > build now?
> > > Or better use build override new gcc for this packages?
> >
> > Is there a particular bug fix that you need in the GA release you need
> > for building against? The gcc release in stable is pretty close to GA
> > so unless there's a specific bug that was fixed between the last
> > stable build and the GA build it should make no difference to your
> > builds.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1554279 (fixed with
> gcc-8.0.1-0.18.fc28) blocks builds packages using the gdal library, so
> an update (and override) would be useful
>

Makes sense, FE blocker would be useful for that then.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Critpath karma

[Peter Robinson]

On Tue, Mar 6, 2018 at 1:48 PM, Randy Barlow
 wrote:
> Greetings!
>
> Does anybody here know the history and/or purpose behind Bodhi's
> critical path karma? A brief grepping of Bodhi's codebase makes me think
> it isn't really used by Bodhi for any purpose other than recording and
> displaying people's entries. I.e., it doesn't seem to be used in Bodhi's
> state machine. It also seems to be confusing for testers.
>
> Does it serve a purpose? If not, should we remove it?

Critical path were (are) packages that were in blocking deliverables,
it pre-dates the Editions, basically if it was a core blocking package
 eg part of Workstaiton, it needed to get more testing/karma before it
could go stable, adamw probably has the most knowledge I suspect :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Server SIG Weekly Meeting Minutes (2018-04-03)

[Peter Robinson]

On Sun, Apr 8, 2018 at 12:01 PM, Tomasz Torcz ️ <to...@pipebreaker.pl> wrote:
> On Sun, Apr 08, 2018 at 10:05:12AM +0100, Peter Robinson wrote:
>>
>> >   * Feedback: Easy "home media server" would be nice  (sgallagh,
>> > 20:08:36)
>>
>> TBH I think that's quite a divergence from a typical "enterprise
>> server" that the Server SIG has targetted.
>
>   But this is probably much closer to what "real-world" Fedora server
>   deployments are.

What details have you got to back that up? I know of a lot of users of
Fedora Server that use it in an enterprise context, a lot more than in
a media server context.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Server SIG Weekly Meeting Minutes (2018-04-03)

[Peter Robinson]

 >   * Feedback: Easy "home media server" would be nice  (sgallagh,
 > 20:08:36)

 TBH I think that's quite a divergence from a typical "enterprise
 server" that the Server SIG has targetted.
>>>
>>>   But this is probably much closer to what "real-world" Fedora server
>>>   deployments are.
>>
>> What details have you got to back that up? I know of a lot of users of
>> Fedora Server that use it in an enterprise context, a lot more than in
>> a media server context.
>
> These are falling trees in the forest though. It isn't that they don't
> make a sound. It is just that no one really hears it and we have no
> way to know what they want/do if they don't. It is the same with every
> other 'enterprise' group in any other platform. Telling you that they
> are using it is no good if it means that you have to be in every
> meeting ever to represent them. You don't scale that far.

My point was that one person's personal experience doesn't make it
default and the norm as everyone has different experiences.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Ansible in EL7

[Peter Robinson]

On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger  wrote:
> James Hogarth wrote:
>> I was under the impression that as of 2.4.0 in EL7 we removed ansible
>> from EPEL7 since Red Hat included it in their extras repo, and EPEL
>> policy is not to conflict.
>>
>> I was surprised just now to see ansible 2.5.0 on a test centos system,
>> when it wasn't in extras, and on a little bit of a search found:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
>>
>> Of course this is a bit of an issue for CentOS/RHEL users that have
>> need for the Red Hat ansible as they have been upgraded, and RH will
>> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
>> to ensure they get it from the right repo.
>>
>> With a branch retirement shouldn't this have been blocked in koji?
>
> Red Hat announced today that Ansible was being deprecated
> from the extras channel.  Their advice is that those who
> have "previously installed Ansible and its dependencies from
> the Extras channel are advised to enable and update from the
> Ansible Engine channel, or uninstall the packages as future
> errata will not be provided from the Extras channel."
>
> https://access.redhat.com/errata/RHSA-2018:1075
>
> Given that, I believe it is reasonable to see ansible return
> to EPEL.  This was discussed in previous EPEL meetings a
> bit, so I'm sure it was known to at least some of the folks
> involved.

There probably should be an announcement sent to the epel announce
list then it gets to a wider audience so more people know this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora28 / autofs

[Peter Robinson]

On Sat, Apr 7, 2018 at 3:13 AM, Tomasz Kłoczko  wrote:
> On 6 April 2018 at 22:58, Pierre-Francois RENARD  wrote:
>> Hello guys,
>>
>> with F28 I tried to use autofs and nfs.
>
> BTW autofs: is it any particular reason why in Fedora kernels autofs
> support is compiled into the kernel and is not provided as loadable
> module?
>
> $ cat /proc/filesystems | grep auto; echo; lsmod | grep auto
> nodev autofs
>
> $
>
> PS. the same is with for example ext{2..4} support.
>
> $ cat /proc/filesystems | grep ext; echo; lsmod | grep ext
> ext3
> ext2
> ext4

It's also unrelated to this topic, it's (and I use it's, not they're,
as it's one driver) built in because it makes booting faster in the
general use case, it also makes debug and recovery easier when one of
the core filesystems is there and you don't need to find it in an
initrd, we also do it for other key widely used system components like
some ATA drivers, IP stack options etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Sliming down kernel and provide more as modules (Was: Re: Fedora28 / autofs)

[Peter Robinson]

Have you actually tested any of these proposed changes before you come
barging in, or even looked for history as to why they're like that?

In reality you should send this, with them all separate, with
reasons/justification why you believe they should be changed  to the
kernel list.

> Just checked what is in kernel configuration and seems ATA driver IS
> compiled statically into the kernel =:-o
> Why? Most of the used HW more likely will be using SATA.
> It would be really good to change this by:

SATA is ATA, there's Parallel and Serial ATA part of the same
stack within the kernel.

> -CONFIG_ATA=y
> +CONFIG_ATA=m
>
> Fedora on mounting initrd is using from mny years ramfs (not ext fs).
> If you want to debug what happens on mounting even rootfs fs driver
> you can use all tools which you may need packing them into initrd.
> With grubby now adding such additional tools is incredibly easy thing
> to do, and you don't need to have ext compiled into the kernel to
> prepare such debug tooling.
> You cannot use on recovery ext driver if your crashed hardware
> resources does not provide any block device formatted as ext fs vol.
>
> IPv4 support is not modularised in Linux kernel source code at all so
> for now it is not an option to have or not to have IP stack in main
> kernel binary like it is on for example Solaris. And yes, it would be
> good to have modularise IPv4 support (like it is with IPv6) to handle
> scenarios where someone is using only IPv6 but it is matter of some
> serious work which needs to be done with rearchitecting few things in
> Linux kernel .. not a choosing something in kernel source code
> configuration only.
>
> I've asked about reasons because I'm trying to use everywhere btrfs as
> rootfs and for the people using xfs only in similar situations this
> ext driver compiled into the kernel is like 1kg lead weight dangling
> between the legs .. (especially on some ARM systems with only 256MB
> RAM)
> IMO looks like only reasons why ext still is compiled into the kernel
> are related to the fact that for quite long time no one have been
> trying to update kernel source code configuration files and now mamy
> drivers are not even enabled as loadable modules.
>
> Many staging drivers and especially USB HID drivers are not enabled as
> well. IRDA, FPGA support is not at all enabled (even as module).
> There is many things which can be now provided as module instead be
> compiled in to the kernel.
>
> Few examples after quick review:
> 1) gzip support in initrd is enough as grubby is using only gzip.
>
>  CONFIG_RD_GZIP=y
> -CONFIG_RD_BZIP2=y
> -CONFIG_RD_LZMA=y
> -CONFIG_RD_XZ=y
> -CONFIG_RD_LZO=y
> -CONFIG_RD_LZ4=y
> +# CONFIG_RD_BZIP2 is not set
> +# CONFIG_RD_LZMA is not set
> +# CONFIG_RD_XZ is not set
> +# CONFIG_RD_LZO is not set
> +# CONFIG_RD_LZ4 is not set
>
> 2)
> -CONFIG_X86_MSR=y
> -CONFIG_=y
> +CONFIG_X86_MSR=m
> +CONFIG_X86_CPUID=m
>
> 3)
> -CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> -CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> +CONFIG_CPU_FREQ_GOV_USERSPACE=m
>  CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> -CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
>
> 4) I don't think that PCMCIA needs to be hardcoded in to the kernel

Historically there's actually reasons why it did actually, have you
tested this on older hardware?

> -CONFIG_PCCARD=y
> -CONFIG_PCMCIA=y
> +CONFIG_PCCARD=m
> +CONFIG_PCMCIA=m
>
> 5) especially on x86* or on guest systems working inside VM

There's supported HW that needs it built in, again have you looked at
list/git history as to why it's like that.

> -CONFIG_REGMAP_I2C=y
> -CONFIG_REGMAP_SPI=y
> +CONFIG_REGMAP_I2C=m
> +CONFIG_REGMAP_SPI=m
>
> 6) if someone is using only SCSI this will be useful
> -CONFIG_SATA_AHCI=y
> +CONFIG_SATA_AHCI=m
>
> -CONFIG_ATA_PIIX=y
> +CONFIG_ATA_PIIX=m
>
> 7)
> -CONFIG_INPUT_LEDS=y
> +CONFIG_INPUT_LEDS=m

There's hard dependencies why i2c needs to be built in.

> -CONFIG_I2C=y
> +CONFIG_I2C=m
>
> 8) If someone is using Linux working in VM or headless HW ..

Actually a lot of VMs have mice mapped by default.

> -CONFIG_INPUT_MOUSEDEV=y
> +CONFIG_INPUT_MOUSEDEV=m
>
> -CONFIG_MOUSE_PS2=y
> +CONFIG_MOUSE_PS2=m
>
> (this is useless in case guest system in VM)
> -CONFIG_HWMON=y
> +CONFIG_HWMON=m

The AGP is likely legitimate, it's been disabled on most non x86
arches for some time (I think some old ppc64 systems being the other
hold out), although those systems then won't get graphics until much
later in the boot process

> -CONFIG_AGP=y
> -CONFIG_AGP_AMD64=y
> -CONFIG_AGP_INTEL=y
> -CONFIG_AGP_SIS=y
> -CONFIG_AGP_VIA=y
> -CONFIG_INTEL_GTT=y
> +CONFIG_AGP=m
> +CONFIG_AGP_AMD64=m
> +CONFIG_AGP_INTEL=m
> +CONFIG_AGP_SIS=m
> +CONFIG_AGP_VIA=m
> +CONFIG_INTEL_GTT=m
>
> -CONFIG_HID_GENERIC=y
> +CONFIG_HID_GENERIC=m
>
> -CONFIG_USB=y
> +CONFIG_USB=m
>
> -CONFIG_USB_MON=y
> +CONFIG_USB_MON=m
>
> -CONFIG_USB_OHCI_HCD=y
> -CONFIG_USB_OHCI_HCD_PCI=y
> +CONFIG_USB_OHCI_HCD=m
> 

Re: RHEL 7.5 for aarch64

[Peter Robinson]

You should likely ask that on the epel-devel list, but I've added
smooge in as he's the EPEL lead.



On Fri, Apr 13, 2018 at 6:22 AM, Bojan Smojver  wrote:
> Anyone knows when RHEL 7.5 packages will be available for aarch64 in
> koji, so that new dependencies get picked up? I'm trying to build EPEL7
> xorgxrdp against the latest xorg-x11-server and all other arches have
> 1.19.5, but aarch64 is stuck on 1.19.3.
>
> PS. Buildroot overrides don't work here, AFAICT.
>
> Thanks,
> --
> Bojan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Stop building 389-ds-base on i686

[Peter Robinson]

On Thu, 29 Mar 2018, 16:24 Florian Weimer,  wrote:

> On 03/28/2018 08:48 PM, Tomasz Torcz ️ wrote:
>
> >> Note that while GCC produces broken code, this is actually an ABI bug,
> and
> >> we cannot change struct layout rules for long long retroactively. Maybe
> we
> >> could for _Atomic long long, but that would need a lengthy
> investigation,
> >> and I strongly believe that everyone is better off if the time is spent
> on
> >> improving 64-bit architectures.
> >
> >Does it mean that the bug was here for the last 23 years? And now this
> > became a problem?
>
> I'm not sure how you came up with the duration.  The bug is most
> certainly much younger than that, probably introduced along with the new
> atomic intrinsics in a late GCC 4.8.x release.  Arguably, it is a real
> bug only for _Atomic long long members.
>

Probably referring to the age of the 389-ds code base which dates all the
way back to Netscape Directory Server

Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Status of OwnCloud/NextCloud

[Peter Robinson]

On Tue, Apr 3, 2018 at 1:51 PM, Randy Barlow
 wrote:
> Greetings!
>
> It seems that OwnCloud and NextCloud might be unmaintained in Fedora. I
> found that upgrading my F27 box to F28 causes it to be unable to login:

I think the old maintainer did a blog post about this some time ago,
can't seem to find it with a quick search, but I think it was on the
planet.

> https://bugzilla.redhat.com/show_bug.cgi?id=1562949
>
> There are also CVEs open:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1472720
> https://bugzilla.redhat.com/show_bug.cgi?id=1451238
>
> Additionally, F27 has an issue that prevents the calendar from working
> unless you downgrade one package to the F26 version:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1525208
>
> I don't think I have the expertise or time to step in and help,
> unfortunately, but these issues do seem bad for Fedora's users. If the
> maintainers no longer have time to maintain them, should we retire them?
> Is anyone else interested in stepping up to help out?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Peter Robinson]

On Sat, 31 Mar 2018, 03:07 Chris Murphy,  wrote:

> On Fri, Mar 30, 2018 at 8:15 AM, Gerald Henriksen 
> wrote:
>
> > Consult the relevant experts, and based on their recommendations
> > mandate a base set of fonts that provide a quality first experience
> > with Fedora for everyone regardless of where they live and what
> > language they read/write.  Making compromises to save 400M on a
> > distribution that will need 20+G over  year doesn't seem very wise.
>
>
> Compression of small data like this might benefit from tuning. Zstd
> offers a training mode to produce a dictionary used for compression,
> offering upwards of 3x more compression. Speed of compression and
> decompression is also improved. Zstd even without a dictionary
> outperforms xz, in particular decompression speeds. But at the sheer
> volume of xz (or bzip2?) compression for RPMs and LiveOS images in
> koji, I'd bet the compression time savings would be significant,
> without dictionary. And if training is possible, the advantage in
> compression ratio and performance would be huge.
>

The compression used in rpms is mostly irrelevant in these cases because
when the rpm is installed on disk it's not compressed.

You also have the problem of availability of tools to handle the
compression, xz is a widely used format which has advantages too. In terms
of training I suspect given the wide range of data that gets jammed into
rpms you'd find the overall improvement is minimal.

The Zstd patches for squashfs-tools don't appear to be upstream still
> for whatever reason, but patches are available. The kernel code for
> squashfs and Btrfs has been there for a while. So implementing this
> for LiveOS images is probably a good deal easier than whatever RPM and
> koji would have to learn to make it happen for all rpms.
>

Live images are but one of the artifacts that we distribute, we also have
cloud, container, vagrant and the arm images all of which could be used on
top of other OSes which would need wide support for the format. Btrfs is
also not a default in any of the delivered artefacts.

Peter


>
> --
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): poppler (libpoppler.so.73 -> libpoppler.so.74)

[Peter Robinson]

On Sat, Mar 24, 2018 at 9:07 AM, Tomasz Kłoczko
 wrote:
> On 24 March 2018 at 03:14, Kevin Fenzi  wrote:
> [..]
>>> BTW In situations like this is possible to observe how really bad idea
>>> was building ALL Fedora +5.6k texlive* packages from single sec file.
>>
>> Except that is no longer the case. texlive-base only has ~120 or so
>> subpackages for each arch and also most of the packages that are deps
>> for other things. The larger 'texlive' package is now a noarch package
>> that doesn't need to be rebuilt very often.
>
> Looking on texlive-base.spec I see ~180 packages but it is really
> tiny/minor detail.
>
> $ grep ^%files texlive-base.spec -c; grep ^%package texlive-base.spec -c
> 182
> 181
>
> Good to know that (re)building all other ~5.5k texlive packages is
> perfectly OK now ..
> Rhetorical question: is it any and/or at least one good reason why
> those ~180 texlive-base packages using ~350 source tar balls must be
> (re)built always together?

Personally I think the better question is why popplar has to break
it's ABI so often? I mean it's not like the PDF spec is evolving that
quickly, why is it so terrible and unstable that is has to change so
much? I mean I'm sure I've seen java script implementations that have
less churn than it!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Stop building 389-ds-base on i686

[Peter Robinson]

>>> So, is this hardware limitation something that is likely to affect other
>>> packages? Is there something we could look for in how they consume
>>> atomic types to tell? I would hate for us to ship something else that is
>>> subject to this problem.
>>
>>
>> There is lots of fingerpointing, but no clear technical cause.
>>
>> We know that the (updated) i386 ABI is buggy in the sense that it does not
>> provide 8-byte alignment for 64-bit values (even if you use C11 _Atomic),
>> and the Intel manual says that the CMPXCHG8B instructions provides atomicity
>> for 8-byte-aligned memory locations only.  But it's not clear if this is the
>> cause of the observed problems.
>>
>> Note that while GCC produces broken code, this is actually an ABI bug, and
>> we cannot change struct layout rules for long long retroactively. Maybe we
>> could for _Atomic long long, but that would need a lengthy investigation,
>> and I strongly believe that everyone is better off if the time is spent on
>> improving 64-bit architectures.
>>
>> Applications should not use 64-bit atomics on i386.  They are non-portable
>> anyway because other 32-bit architectures (actually even the original i386)
>> do not support them, so upstream needs alternatives anyway.
>>
>
> Just to be clear, when other 32 bit architectures don't support it..
> if this code was attempted to be compiled on arm32 the compiler
> complains and errors? I am wanting to make sure we don't have some
> sort of silent snake in the other 32 bit architecture that i386 sort
> of showed first? [If they use a different method on arm32, can they
> use it on the i386? Or is there something about i386 not being really
> i386 (aka i686 etc) that makes this impossible. ]

The way I read some of the comments on the bugs in reviewing the code
it seems it could just as well happen on any architecture, it's just
easier to trigger (I explicitly steer clear of the term reproduce) on
i686.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 29 Final is GO

[Peter Robinson]

> On 25/10/2018 20:58, Ben Cotton wrote:
> > The Fedora 29 Final RC1.2 compose [1] is GO and will to be shipped
> > live on Tuesday, October 30, 2018.
> >
> > For more information please check the Go/No-Go meeting minutes [2] or logs 
> > [3].
> >
> > Thank you to everyone who has worked on this release.
> >
> > [1] http://dl.fedoraproject.org/pub/alt/stage/29_RC-1.2/
> > [2] 
> > https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-25/f29-final-go_no_go-meeting.2018-10-25-17.03.html
> > [3] 
> > https://meetbot.fedoraproject.org/fedora-meeting-1/2018-10-25/f29-final-go_no_go-meeting.2018-10-25-17.03.log.html
> >
>
> Is there any reason why
> https://koji.fedoraproject.org/koji/taskinfo?taskID=30445005 has been
> canceled? I don't see any obvious reason in the logs and I really want
> the Astronomy Spin to be shipped… Normally that spin builds fine, see
> latest daily build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=30453015
>
> In addition I want to note that we have many broken spins like the
> Python Classroom and Design. I'm not sure whether it is a good idea to
> ignore this, also for marketing reasons :(

Yes, I agree, I am at a loss as to why it was signed off as well,
there was blockers like "Be able to apply updates using the desktop
mechanism" that were seemingly ignored with broken gnome-software,
plus numerous other issues. I don't feel it was ready but clearly
someone had some agenda to ram it on through despite the issues.
___
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: IBM buying RedHat

[Peter Robinson]

On Mon, Oct 29, 2018 at 12:46 AM Simo Sorce  wrote:
>
> On Sun, 2018-10-28 at 19:44 -0400, Neal Gompa wrote:
> > It's always a wait and see approach. I'm a bit disappointed that no
> > one from Red Hat has said anything yet. The only comfort is that
> > apparently most RHers I know are equally surprised...
>
> We are all astonished honestly,
> I took to fedora-devel only because I finished reading *all* the
> internal emails about it that I downloaded so far (it took me a few
> hours) and ... still can't digest the news.
>
> > It'd be nice if someone from up top would deign to come and talk to us
> > directly...
>
> I am sure it will happen at some point, but this is news for *everyone*
> at Red Hat except a handful (at the CXX level) so give us some time ...

From the press release, which is all I know about, it's not due to
complete until "latter half of 2019." which is around a year from now
and it has to go through all the regulatory reviews. Until that point
there's nothing to discuss and I wouldn't expect any engagement with
the community until then because everything is subject to change.

So I suspect it's a wait and see and we'll know more a year from now.

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

Re: IBM buying RedHat

[Peter Robinson]

On Mon, Oct 29, 2018 at 9:45 AM Nicolas Mailhot
 wrote:
>
> Le 2018-10-29 10:18, Peter Robinson a écrit :
>
> > From the press release, which is all I know about, it's not due to
> > complete until "latter half of 2019." which is around a year from now
> > and it has to go through all the regulatory reviews.
>
> That’s not how those things work. As soon as two corps decide a buyout/a
> merge management is asked to anticipate it and start working and
> thinking as if the buyout/merge was effective.
>
> And then if regulators finally say no, it costs some back-pedalling, but
> you don’t announce that kind of change if you do not expect regulators
> to ok it.

Sure, but the fact is that there's going to be a long run way and I
would not expect anything to change in the community space for some
time, just look at the recent github process that happened with
Microsoft.
___
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: IBM buying RedHat

[Peter Robinson]

On Thu, Nov 1, 2018 at 2:26 PM Neal Gompa  wrote:
>
> On Thu, Nov 1, 2018 at 8:14 AM Nico Kadel-Garcia  wrote:
> >
> > On Tue, Oct 30, 2018 at 4:48 PM Matthew Miller  
> > wrote:
> > >
> > > On Sun, Oct 28, 2018 at 07:44:12PM -0400, Neal Gompa wrote:
> > > > It'd be nice if someone from up top would deign to come and talk to us
> > > > directly...
> > >
> > > Communications are pretty carefully controlled for regulatory reasons, and
> > > the fact is even those at the top don't know everything yet. And 
> > > speculation
> > > is basically right out. That said, I'm working on what I can do here. Are
> > > there specific things you'd like to ask?
> >
> > When did the engineering staff know?
>
> I'm pretty sure it's obvious by this thread that everyone found out at
> the same time...
>
> > Will IBM push Red Hat towards, or
> > away, from their current level of worldwide telecommuting? Whose
> > management will be in charge on a day to day basis? What will be the
> > relationship with Fedora? Will Red Hat engineers be as encouraged as
> > they are now to publish software and fixes to the Fedora releases?
> > Will the CentOS core development team stay employed by Red Hat?
>
> These are questions I'm interested in answers on. However, I'm also
> worried about how much the "cloud" was mentioned in the presser. It
> makes me nervous about Red Hat's investment into other areas, which a
> lot of the Linux ecosystem relies on, even outside of the Fedora
> community. Desktop Linux, traditional server platforms, IoT, etc. look
> like areas that might be disinvested in. :(

And none of those questions are anything to do with the Fedora project
what so ever, they are between Red Hat employees, Red Hat and IBM.
Whether a Red Hat employee works on Fedora from their house or an
office desk is irrelevant! While I know people are fascinated by
peaking over people's back fences or taking a sticky beak at someone
else's private life basically none of any of the above has any outcome
to do with Fedora, those questions that are have already been answered
on this thread as best as they currently can be.

> > What
> > is the expected release date for RHEL 8, so I can stop building the
> > *very* large dependency chains between current Fedora components I
> > need to backport to RHEL 7 and CentOS 7?
>
> Yeah, no. They're not going to answer this. I wouldn't even expect
> them to. But a little sleuthing will give you some idea of when we'll
> see the next RHEL release. :)

Completely irrelevant WRT anything to do with the IBM acquisition.

> > Will IBM and Red Hat rein in
> > the "let's replace another system function into systemd that has
> > nothing to do with logging or daemon management" ?

Completely irrelevant. Please keep the thread on topic. Nice try
trying to fuel sentiment but unrelated.
___
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: IBM buying RedHat

[Peter Robinson]

On Wed, Oct 31, 2018 at 6:13 AM John Coughlan  wrote:
>
> Yea - Does IBM have any plans on keeping, or discarding any of RH’s open 
> source efforts…like this one? Can we as a community still expect the same 
> sort of, and level of involvement post sale as we have enjoyed before hand 
> from RH/IBM employees?

See the thread on the council list, basically it's too early to tell,
no one is worried as IBM has a long record of embracing open source
and it's way too early to tell, it's not due to close until H2 next
year. See Matthew's response and others. For the time being it's
continue as normal.

> -L0ft
>
> > On Oct 30, 2018, at 12:12 PM, Matthew Miller  
> > wrote:
> >
> > On Sun, Oct 28, 2018 at 07:44:12PM -0400, Neal Gompa wrote:
> >> It'd be nice if someone from up top would deign to come and talk to us
> >> directly...
> >
> > Communications are pretty carefully controlled for regulatory reasons, and
> > the fact is even those at the top don't know everything yet. And speculation
> > is basically right out. That said, I'm working on what I can do here. Are
> > there specific things you'd like to ask?
> >
> > --
> > 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
> ___
> 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: Fedora's OpenH264 repo issue

[Peter Robinson]

https://pagure.io/releng/issue/7590

On Thu, Nov 8, 2018 at 10:51 AM Jan Pokorný  wrote:
>
> Not sure where to report this for the Fedora side, but there seems to
> be some synchronization issue regarding the built artifacts hosted at
> http://ciscobinary.openh264.org, since older packages can be obtained
> just fine:
> https://github.com/cisco/openh264/issues/3037#issuecomment-436932562
>
> --
> Jan (Poki)
> ___
> 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: Unexpected rebase of libsolv to 0.7.1 in F29, F28; please report any issues to bugzilla

[Peter Robinson]

On Mon, Nov 12, 2018 at 3:35 PM Jaroslav Mracek  wrote:
>
> Hello everyone,
>
> There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7) 
> into rawhide, but the rebase also ended up in stable branches of Fedora 28 
> and 29. This release could affect not only libsolv users, but also libdnf, 
> PackageKit, microdnf, or dnf related applications.
> I would like to ask everyone for intensive testing and reporting any issues 
> concerning the rebase.

How did this this happen? It's kind of strange that people weren't
aware this was happening, what is some auto "git merge master"
mistake. It's a fairly big problem to "accidentally" rebase to a major
new release and not realise it was happening, especially on something
so core as core updates infrastructure. What sort of things are you
going to put in place to ensure random rebases don't just happen
again?

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

Re: upgrade tinyproxy for f29?

[Peter Robinson]

On Mon, Sep 3, 2018 at 4:07 PM Michael Adam  wrote:
>
> Hi all,
>
> Tinyproxy just released a new version 1.10 which is has been overdue
> and containes 2 CVE fixes apart from several enhancements.
>
> I created builds for rawhide already.
>
> I was wondering if it is still possible to get tinyproxy to this important
> update in f29, since no other packages depend on it, afaict.
>
> If so, what do I do? Just update the scm branch and bring it in through Bodhi?

Sounds like a reasonable course of action. Is it backward compatible
in terms of any interface people might use? If so once it's baked in
f29 for a bit, we're in freeze atm any so it won't progress from
updates-testing -> stable until Beta gets signed off, you might want
to consider pushing to stable releases too due to CVEs
___
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: Semi-serious proposal: drop all optional entries from comps

[Peter Robinson]

> On Sat, Sep 22, 2018 at 11:39:51AM -0700, Adam Williamson wrote:
> > > Somewhere halfway between those, in that I've talked with the GNOME 
> > > Software
> > > dev about it in the past. Software presents "Categories" and "Featured
> > > Applications" -- the idea would be to extend that into also including
> > > curated bundles. One click to select everything recommended as "Fedora
> > > Design Suite".
> > That would be great *if* we could use the same mechanism for actually
> > doing the composes. If not it'd be pointless duplication of work and
> > just introduce more errors.
>
> Yeah, we probably want the same mechanism for composing release-blocking
> artifacts.
>
> Well, actually: anyone should be able define such a group, and anyone
> produce images (live media, vm/cloud images, container images) from those
> groups (possibly in Copr). Then we can promote certain sets of these as
> official, and others can be like Coprs are now.

Some of the group stuff is also used during the compose and if things
aren't in groups specified but needed by say a kickstart the packages
won't be in certain places and will break things. I did this by
accident when adding zram in F-29 and not adding it to comps.

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

Re: Blocking criteria proposal for F30+: Printing

[Peter Robinson]

> There was a bug[1] filed recently that indicated that printing was
> broken on certain printers. As a result of that discussion, it became
> apparent that there was no criteria for printing to work at all, which
> seems like an oversight.
>
> I discussed this briefly with Matthias Clasen this morning and he
> agreed that this should be treated as blocking for Workstation.
>
> I'd like to propose that we add the following criteria to Beta for Fedora 30+:
> * Printing must work on at least one printer available to Fedora QA.
> "Work" is defined as the output from the device matching a preview
> shown on the GNOME print preview display. (Note that differences in
> color reproduction are not considered "non-working".)
>
> and this to Final for Fedora 30+:
> * Printing must work on at least one printer using each of the
> following drivers:
> (I don't know which ones to specify here, but we ought to try to
> figure out a cross-section that covers a large swath of our expected
> user base).

I'm against this as a blocker for a number of reasons:
* When we've tried to do hardware specific blocking at the time like
dual boot with MacOS this has not worked well and the dual boot is
testable with one piece of hardware
* It's easy to do a zero day update or a standard update to fix it
post release as doesn't affect the install path
* We don't do it for other non critical hardware selections such as
digital cameras, video cameras, and other such things
* Hardware availability, I don't see blocking for one type of printer
over another type is a good use of our time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora for Web Development fail

[Peter Robinson]

> * Máirín Duffy:
>
> > - Found out it's cloud-info stalling the boot.
>
> I think it's actually cloud-init.
>
> > - Yay I have a login prompt! What's the login info? Ga...
> > - Realize have to run virt-customize --uninstall cloud-init --root-password 
> > password:whatever --selinux-relabel -a theimage
>
> I have requested downstream that we ship separate KVM and cloud images
> because cloud-init is a significant security risk when run outside a
> cloud environment which supports instance data injection (which libvirt
> does not provide).  cloud-init probes the network and executes scripts
> it finds there as root.  It cannot perform authentication because it
> performs customization of the image, and the owner of the VM is not
> known to it before it runs.
>
> A dedicated cloud image with a document procedure for injecting
> authentication information (could be an open root shell on the serial
> console) would help your use case as well and discourage people from
> abusing the insecure cloud images for KVM installs.

Might be better to move them all to ignition in F-30?
___
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 rawhide compose report: 20190114.n.0 changes

[Peter Robinson]

On Mon, Jan 14, 2019 at 2:52 PM Dan Horák  wrote:
>
> On Mon, 14 Jan 2019 13:54:02 +
> Fedora Rawhide Report  wrote:
>
> > OLD: Fedora-Rawhide-20190108.n.0
> > NEW: Fedora-Rawhide-20190114.n.0
> >
> > = SUMMARY =
> > Added images:3
> > Dropped images:  1
> > Added packages:  12
> > Dropped packages:3
> > Upgraded packages:   626
> > Downgraded packages: 1
> >
> > Size of added packages:  5.07 MiB
> > Size of dropped packages:1.47 MiB
> > Size of upgraded packages:   15.32 GiB
> > Size of downgraded packages: 9.98 MiB
> >
> > Size change of upgraded packages:   236.22 MiB
> > Size change of downgraded packages: 53.48 KiB
> >
> > = ADDED IMAGES =
> > Image: Server boot ppc64le
> > Path:
> > Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20190114.n.
> > 0.iso Image: Everything boot ppc64le Path:
> > Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20190114.n.
> > 0.iso Image: Server dvd ppc64le Path:
> > Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20190114.n.0.iso
>
> this means we have correctly fixed lorax templates after fbset removal,
> but we now seem to have a problem with the install.img size (or
> rather free space there), meaning the default 2GB is too small. Where we
> shall change the image size? Don't think reducing the content of
> the image would fix it for longer time.

It would be useful to see where it's bloated to see if we can reduce
bits in general, I think it would be useful overall not just for ppc.

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

Re: Driver for USB 3.0 Docking Station (displaylink?)

[Peter Robinson]

> Hi, I would like to try to use un my Asus notebook with Fedora 29 this ASUS 
> USB3.0 HZ-3 Docking Station
> https://www.asus.com/it/Laptops-Accessories/ASUS_USB30_HZ3_Docking_Station/
>
> For Linux I have found this driver:
> https://www.displaylink.com/downloads/
>
> But "Ubuntu" is not a S.O, it's a Distro! ... a S.O. like other mentioned in 
> this page is: "Linux"! ... not "Ubuntu"
>
> Ubuntu is Linux, Linux is not Ubuntu!
> This is very irritating ... Why not share simply a driver for Linux (then for 
> all distros) ?
>
> Why this drivers is not into kernel of default?

Basically displaylink isn't part of the open USB standards protocol
like say USB storage/input etc so it's a proprietary standard without
an open driver and without decent open spec or the details to write an
open driver its not great. I think the Arch Wiki describes it well
https://wiki.archlinux.org/index.php/DisplayLink
___
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: Backwards incompatible changes planned for Bodhi 4.0.0

[Peter Robinson]

> Greetings fellow Fedorans!
>
> I am about to start working on a set of backwards incompatible changes
> to Bodhi for its upcoming 4.0.0 release (Bodhi follows Semantic
> Versioning[0]):
>
> https://github.com/fedora-infra/bodhi/projects/6
>
> If the thought of backwards incompatible changes to Bodhi raises one or
> both of your eyebrows, please peruse the list of proposed changes there
> and comment on any issues that may concern you. I can't be sure who is
> using Bodhi for what, so please let me know if you think any of these
> changes are a Bad Idea™.

Is there an executive summary as to what's backwards incompatible and
what the impact on the average user is? A quick look at the kanban
doesn't give me any understanding :)
___
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: _performance_build and -O3 package builds

[Peter Robinson]

> Downstream, we had a separate set of builds flags for certain packages
> and used -O3 there, targeted at POWER (both ppc64 and ppc64le), for
> increased use of vectorization presumably.
>
> I don't think this was ever upstreamed to Fedora (the downstream changes
> were in the redhat-rpm-config package).  I don't recall seeing a
> corresponding Fedora change.  As a result, the recent downstream rebase
> lost support for this.

Not sure what you mean by upstreamed the downstream change, this was
in Fedora but around Fedora 26 the ppc64p7 sub architectured was
EOLed. Over all it was a yum hack and it wasn't supported in dnf and
we worked with IBM to move most of their optimisations to IFUNC or run
time detectable fast paths in the areas they felt needed specific
optimisations.

> Should Fedora package maintainers remove _performance_build support or
> custom flag overrides for -O3 from their packages?

The supported sub-set of packages for this particular project were:
binutils bzip2 cyrus-sasl glibc httpd kernel libxml2 mariadb openssl
pam pcre php postfix postgresql python python3 sendmail xz zlib

And yes, any perf build bits in those pacakages, and probably some
dependencies, is unused and can be removed.

> My understanding is that Fedora build flag policy is set by the
> redhat-rpm-config package, which currently specifies -O2 for all
> architectures.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Peter Robinson]

On Thu, Nov 29, 2018 at 11:10 PM Matthew Miller
 wrote:
>
> On Thu, Nov 29, 2018 at 12:15:52PM +, Peter Robinson wrote:
> > This is basically the problem I have with the work we're doing in IoT.
> > The basically will make me re-evaluate if IoT is now worth doing at
> > all in Fedora or whether I am now better off focusing my efforts
> > elsewhere.
>
> Is there something specific you're concerned about, or is it a general
> sense that there's likely to be something that you want updated? Since IoT
> is ostree-based, is it possible we could solve this by including packages
> from a newer module of whatever is problematic -- or even rawhide builds?
> (That is, you say that modularity isn't capable of soving this, but I'm not
> sure why not.)

As an example, and this is one thing, if I need to build the kernel
with some latest security feature in gcc to get some of the KSPP
functionality I can't do that with modularity.

Because so much of what IoT is doing is in a very small package set
and is focused on a combination of removing as much as possible while
tightening things down this not something that is achievable with
modularity.

The apps in containers are certainly able to make use of that, and I'm
in particular the various versions of nodejs I'm sure will be used in
IoT as there's a lot if IoT things that make use of nodejs.

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

Re: 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 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: [HEADS UP] Ceph-14.x.x, dropping 32-bit archs

[Peter Robinson]

Kaleb,

Firstly the title is misleading as there was no heads up, a heads up
is notice before you actually push the change, not when you do the
change.

> Ceph 14.x.x (Nautilus) will no longer be built on i686 and armv7hl archs
> starting in fedora-30/rawhide.
>
> The upstream project doesn't support it. The armv7hl builders don't have
> enough memory (or address space) to build some components.
>
> And the other active maintainer (branto) and I don't have cycles to
> devote to keeping it building on 32-bit archs.
>
> (FWIW, currently ceph-12.2.9 (luminous) is in rawhide, f29, and f28 and
> it has packages for i686 and armv7hl for people who want to run ceph on
> 32-bit archs.)

As others have asked in the thread can we possibly build client only?
___
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

[Peter Robinson]

> * Petr Pisar  [2018-12-03 11:24]:
> > On 2018-11-28, 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 ;)
> > >
> > That's nice, but Koji builders have not been reconfigured away from
> > LANG=en_US.UTF-8 and that means that all builds run in C (not C.UTF-8)
> > locale now and e.g. every Perl package build spits a warning like this:
> >
> > perl: warning: Setting locale failed.
> > perl: warning: Please check that your locale settings:
> >   LANGUAGE = (unset),
> >   LC_ALL = (unset),
> >   LANG = "en_US.UTF-8"
> > are supported and installed on your system.
> >
> > Example
> > .
>
> This is even causing some of my builds to fail because some cmake
> variables (CMAKE_SYSTEM_PROCESSOR below) end up containing a warning:
>
>   -- Found assembler: /usr/bin/clang
>   CMAKE_SYSTEM_PROCESSOR: _bin_sh: warning: setlocale: LC_ALL: cannot 
> change locale (en_US.UTF-8)
>   x86_64
>   CMake Error at functions.cmake:7 (message):
> Only AMD64, ARM64 and ARM are supported
>   Call Stack (most recent call first):
> CMakeLists.txt:175 (clr_unknown_arch)
>
> What's the correct way to disable this "setlocale: LC_ALL: cannot change
> locale (en_US.UTF-8)" warning? What environment variables should I be
> (un)setting when building in koji? Or should I install a langpack
> instead?

I suspect the proper fix will be in the cmake-rpm-macros package so
that it's fixed in a central location for all cmake consumers.

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

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

[Peter Robinson]

On Tue, Nov 27, 2018 at 3:39 PM 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.

This is basically the problem I have with the work we're doing in IoT.
The basically will make me re-evaluate if IoT is now worth doing at
all in Fedora or whether I am now better off focusing my efforts
elsewhere.

Going back to the F-20/F21 cycle we had major issues with the year gap
in releases for ARM64. We were waiting on toolchain enhancements that
landed about around a week (exact time-frames allude me) after Fedora
20 branched, which meant ultimately we had to wait 18 months from
branch to a stable release for end users to actually be able to
consume these enhancements, there was another one, I don't remember
exact component details, that due to upstream timing as well basically
meant it was longer than that more than that to consume. For reference
Fedora 20 branched on 2013-08-20 [1] and Fedora 21 was released on
2014-12-09.

From an IoT perspective where we're looking at some features around
security that could be cross component dependent
(toolchain/kernel/userspace) to be unable to consume for possibly an
18 month window, yes we rebase kernels but we need to rebase other
components and build against those, in a stable release is a complete
and utter disaster. Unfortunately this is not a problem that
modularity is capable of solving and IoT doesn't have the cycles to
even begin to consider dealing with that at the lower levels. Sure, it
would be fine for IoT app stacks, such as noodejs, in a container but
not below that.

Peter

[1] https://fedoraproject.org/wiki/Releases/20/Schedule
[2] https://en.wikipedia.org/wiki/Fedora_(operating_system)#Releases
___
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: Improving the compose: leave the current compose in place

[Peter Robinson]

On Tue, Nov 27, 2018 at 7:01 PM Paul Frields  wrote:
>
> On Tue, Nov 27, 2018 at 9:59 AM Owen Taylor  wrote:
> > A lot of discussion about improving the compose process seem to end up
> > with a "reality check" - that ideas have already been tried but don't
> > work because of requirements a) b) c) d). You can't have the pony, but
> > maybe if a lot of effort is put into it, you can have a faster rocking
> > horse.
> >
> > If want to fundamentally improve the Fedora workflow we need compose
> > ponies, we can't just have rocking horses!
> >
> > Perhaps it would make sense to leave the current 8-10 hour compose in
> > place for the forseeable future, and work on a new system in parallel
> > where the primary constraint is to be as fast as possible. Hopefully
> > most problems with the slow compose will get sorted out in the fast
> > composes, and the slow compose will become more reliable. Perhaps in a
> > distant future, we can make the new system do everything
>
> Indeed, this is basically the investigation I've proposed. I also think
>
> > I don't know what the system would look like exactly, but you could
> > imagine things like:
> >
> >  * Composed of several micro-composes (micro-compose-services?) to
> > avoid blocking on everything completing successfully.
> >
> >  * Able to do speculative composes for CI
> >
> >  * Either x86_64-only, or with decoupled architectures so that we can
> > throw x86_64 hardware (or cloud resources) at it, and make it super
> > fast.
> >
> >  * No IO /mnt/koji during the compose - having a big network share be
> > central to the process creates a performance bottleneck, makes it hard
> > to move to the cloud, and potentially adds a lot of "noise" to
> > figuring out what is going on where things are slow because of some
> > other entirely different thing is goin gon.
> >
> > Add your own bullet points :-)
>
> I would like to redefine a couple working assumptions:
>
> * Big tools are unwieldy and inevitably silo knowledge. The people
> behind them are often smart, hard-working, and care about great
> results. But bedrock FOSS principles say we get more value from
> rapidly iterating tools to which many people can/do contribute. We
> should see if we can avoid big tools that solve everything.
>
> * Reproducibility is something we can better enforce at development
> time than use time. It's pretty easy to pick one or more git heads at
> a certain time (for a tool, a containerized environment, etc.). Let's
> not get one hand tied behind our back at the outset via outmoded
> assumptions.

That is not entirely true. A level of reproducibility is also at build
time based on versions of other packages that the package has been
built against. The versions of components that another component is
built/composed against will greatly affect the reproducibility of a
component and that information is not in git.

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

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

[Peter Robinson]

On Thu, Nov 29, 2018 at 2:58 PM Gerald Henriksen  wrote:
>
> On Thu, 29 Nov 2018 12:15:52 +, you wrote:
>
> >From an IoT perspective where we're looking at some features around
> >security that could be cross component dependent
> >(toolchain/kernel/userspace) to be unable to consume for possibly an
> >18 month window, yes we rebase kernels but we need to rebase other
> >components and build against those, in a stable release is a complete
> >and utter disaster.
>
> Is it specific to the F30/31 timeframe, or is it something that could
> be alleviated by instead delaying to a F31/32 delay?
>
> In other words, if the delay is necessary is there a better choice of
> time to do it that would help to minimize the disruption to the
> various Fedora communities?

At the moment I don't see that changing at all from an IoT perspective.
___
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: Can we change the xz block size in our cloud images?

[Peter Robinson]

On Fri, Nov 23, 2018 at 12:43 PM Richard W.M. Jones  wrote:
>
> It looks like the raw format xz-compressed cloud images that we ship
> use a very large block size, possibly 192M.  This is not ideal and it
> would be better to use a smaller block size such as 16M so that they
> can be consumed without having to be uncompressed by nbdkit, or even
> be used remotely without even downloading them.
>
> (Long story here: https://rwmj.wordpress.com/2018/11/23/nbdkit-xz-curl/ )
>
> I recompressed the Fedora 29 cloud image using a 16M block size and
> there is about 4% overhead to doing this:
>
> before 194278292
> after  202874868
>
> At the moment I'm not clear what actual component does the xz
> compression step, so I don't even know where I could file a bug or who
> I could discuss this with, nor what the current code looks like.
> Apparently it's no longer done using appliance-tools.

The cloud images haven't used appliance-tools for years. It uses
imagefactory and some bits in koji.

Looking at the output of the logs it just runs:
$ /usr/bin/xz -z9T2
/var/tmp/koji/tasks/2418/31062418/Fedora-Cloud-Base-Rawhide-20181123.n.0.aarch64.raw

Example task: https://koji.fedoraproject.org/koji/taskinfo?taskID=31062418

So at a guess it should be a straight forward patch to koji.

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

Re: How much is dnf's minimum memory requirement?

[Peter Robinson]

On Sun, Nov 25, 2018 at 4:54 PM Benjamin Kircher
 wrote:
>
> What are dnf’s minimum memory requirements? It came as a surprise to me that 
> a simple `dnf check-update` is getting OOM’ed by the kernel on a (ok, fairly 
> small) 512MB VM.
>
>
> [root@node ~]# dnf check-update
> Killed
>
> [root@node ~]# free -h
>   totalusedfree  shared  buff/cache   
> available
> Mem:  480Mi   137Mi   292Mi   0.0Ki50Mi   
> 329Mi
> Swap:0B  0B  0B
>
> [root@node ~]# cat /etc/os-release |grep -i pretty_name
> PRETTY_NAME="Fedora 29 (Server Edition)”
>
> [root@node ~]# dnf --version
> 4.0.4
>   Installed: dnf-0:4.0.4-1.fc29.noarch at Tue 30 Oct 2018 03:38:30 PM GMT
>   Built: Fedora Project at Mon 15 Oct 2018 12:00:52 PM GMT
>
>   Installed: rpm-0:4.14.2-1.fc29.x86_64 at Tue 30 Oct 2018 03:37:40 PM GMT
>   Built: Fedora Project at Wed 22 Aug 2018 08:07:47 AM GMT
>
>
> According to [1], 1GB is required for a Fedora (desktop?) install but right 
> underneath is a note that says only if I want to install it with lots of 
> packages selected upfront.
>
>
> With F28 Server (ships with dnf 2.7.5) this worked perfectly fine on an 
> equally sized VM.
>
> Anyway, is memory consumption a thing with the new libdnf-in-C++ efforts? 
> Could a look into microdnf be a thing for me?
>
> Any advice appreciated.

I've not seen issues with it running on ARM devices with 512 Mb of
RAM, and there are some that run it on devices with 256Mb but that
tends to be a minimal image with no graphics
___
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: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Peter Robinson]

On Wed, Nov 21, 2018 at 12:09 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Nov 06, 2018 at 09:21:09AM -0600, Dennis Gilmore wrote:
> > the build group in koji is defined as
> > 
> > build
> > build
> > None
> > false
> > true
> > 
> >   bash
>
> Hmm, where is this defined?

In koji:
koji list-groups f30

> >  and in f30 comps the buildsys-build group is
> > 
> > buildsys-build
>
> https://pagure.io/fedora-comps/pull-request/346
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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

[Peter Robinson]

On Mon, Nov 26, 2018 at 5:57 AM David Herrmann  wrote:
>
> Hi
>
> On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko
>  wrote:
> >
> > On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko  
> > wrote:
> > [..]
> > > I’m talking about F30 recent change in which has been implemented switch 
> > > to dubs-broker.
> > > Ps. If this change has been propagated to F29 (hopefully not) more things 
> > > will be screwed.
> >
> > Seems I found what caused the issue.
> > I've been doing upgrade (only) dbus packages using rpm and for some
> > reason after all old dbus-daemon has been killed and deactivated and
> > at the same time dbus-broker has not been started.
> > Instant effect was very strange. For example I was unable to unpack
> > any archives with files owned by group/user not present in my system
> > because NSS seems now depends on dbus as well. After next few minutes
> > Gnome GUI crashed,
> >
> > if [ $1 -eq 1 ] ; then
> > systemctl --no-reload disable dbus-daemon.service
> > systemctl --no-reload --global disable dbus-daemon.service
> > systemctl --no-reload enable dbus-broker.service
> > systemctl --no-reload --global enable dbus-broker.service
> > fi
> >
> > This dbus-broker %post scriplet seems is only swapping started
> > services but does not stops dbus-daemon and starts dbus-broker if
> > dbus-daemon is already runimg.
>
> You cannot stop dbus-daemon on a running system. This would tear down
> everything. The package upgrade needs a reboot.
>
> > At the same time because in spec file is missing uninstall dbus-daemon
> > by missing "Obsoletes: dbus-daemon" below
>
> Uninstalling dbus-daemon would break a running system, because it
> would stop the system bus. Furthermore, other packages still depend on
> tools provided by the old dbus-package. Can you elaborate why it is
> harmful to keep dbus-daemon around? We made sure you can manually
> remove it, unless other packages explicitly depend on the dbus-daemon
> binary for private buses.
>
> > %triggerpostun -- dbus-daemon
> > systemctl --no-reload preset dbus-broker.service
> > systemctl --no-reload --global preset dbus-broker.service
> >
> > has not been activated as well. IMO implementing whole transition with
> > leaving both old and new packages installed seems is wrong.
> >
> > Solution: login after all in single mode and execute "systemctl enable
> > dbus-broker" than reboot.
>
> This surprises me. You are saying a simple reboot did not solve your
> issues? The `enable` line is executed during upgrade, but you are
> saying on your system dbus-broker was not enabled after the upgrade?
>
> > Other problem is that dnf and rpm are executing batch of packages
> > scriplets not the same order with other operations. Breaking rpm
> > semantics by dnf is kind of asking for troubles.
>
> Thanks a lot for the report. We tested this upgrade with several
> different setups (both dbus-daemon and broker installed/not installed
> before the upgrade, etc.), and we didn't see this behavior. We are
> aware that this update needs a reboot to fully work, but we made sure
> it somewhat works even if you don't reboot. For rawhide, there is
> sadly no way to mark updates as "needs reboot".

I have two arm systems running rawhide and they've both had problems
where I've ended up without dbus running so no network etc. I needed
to explicitly login locally and enable/disable services and reboot to
get things working again.
___
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

[Peter Robinson]

On Tue, Nov 27, 2018 at 6:26 PM Paul Frields  wrote:
>
> On Tue, Nov 27, 2018 at 9:50 AM Dennis Gilmore  wrote:
> [...snip...]
> > > The customers RH serves have specific expectations, and in part that
> > > dictates how delivery tooling is done. Binding the community to that
> > > may be counterproductive. This is especially true now that RHEL 8 Beta
> > > is out -- it's the perfect time for us to be rethinking at that level.
> >
> > Compose tooling is largely shared, delivery tooling is not, though
> > there is room for improvement and convergence on both sides.  We should
> > also consider CentOS and how we can share tooling, process and
> > resources, they still use something else entirely. Everything used in
> > Fedora is developed in the open and can be contributed to by anyone.
> > We have been talking about making the whole process flexible and
> > dynamic for years. I know internally they would like to have many of
> > the same things Fedora wants.
>
> Yeah, it sounds like we're aiming in the same direction here. This is
> part of what I mean by "decomposing the compose." We have one rather
> monolithic process right now, all or nothing. And it does so much that
> it's impossible to get any fast results from it. That doesn't mean it
> doesn't work well for what it does. But it's not very flexible, as you
> pointed out.

Actually amusingly if you look back through the history post F-21 and
the massive delays that happened due to various non monolithic
processes one of the outcomes of the "get a release done with
Fedora.next" was to be able to do full composes every day because
prior to that we only did newRepo, a network install and live/cloud
images and often we'd get to Alpha TC1 right after branching to
discover a whole bunch of stuff was completely broken. We finally got
this with the move to "pungi 4" in Fedora 24, and in the intervening
releases we had huge amounts of complaints because rel-eng couldn't
provide all release artifacts to be pushed through CI/CD so
regressions could be fixed instantaneously. Yes, I'm aware things
change, and I often push them, but it's worth knowing the history how
we got to where we are!

> With a more flexible compose we could choose to do smaller tasks (as
> well as capitalize on other time savings) for something like a
> speculative testing build. That kind of build could be used to perform
> integration testing as well as other tasks (automated, not manual!).

Yes, and in some regards there's already parts of the project doing
this, the TWA release runs like this, as does the IoT release and I
mentioned above ways to break some of the bits up more.

> We could even potentially test against much of the repetitive,
> time-consuming matrices manually (and heroically) run by QA. Then only
> choose to do more extensive tasks based on that being "green."

Completely agree, but there's quite a bit of work to be done to get to
that unicorn but none of the process to get there has been documented
or even proposed in this thread, it's not easy (believe me a lot of
people have looked over the years I've been involved in rel-eng) and
most of what I've seen of actual concrete means to get there won't get
us anywhere close to that, while yes it will still improve it.

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

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

[Peter Robinson]

On Mon, Nov 26, 2018 at 7:42 PM Adam Williamson
 wrote:
>
> On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote:
> > On 11/26/18 10:58 AM, Peter Robinson wrote:
> > > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> > >  wrote:
> > > > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller 
> > > > >  wrote:
> > > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > > > Here's the summary from the page, which proposes we pause the 
> > > > > > > release
> > > > > > > after F30 for these efforts:
> > > > > >
> > > > > > 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!)
> > > > >
> > > > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > > > done analysis.
> > > >
> > > > I just don't believe this is true. I'm pretty sure Dennis and Kevin
> > > > have both looked into it before.
> > >
> > > Yes, I mean recently, I was involved in the last time we attempted
> > > this, and there was a number of things identified but quite a bit has
> > > changed since that last happened.
> >
> > Yeah, I think our goal should be 1 minute... just as realistic as one
> > hour. ;)
> >
> > I have not looked into things recently. However:
> >
> > * The mock fsync change (https://pagure.io/releng/issue/7909) may help
> > some.
> >
> > * We have plans to redo the setup on the s390x builders, which should
> > result in them being much faster. That should help.
> >
> > * I know pungi maintaienrs have been doing some work to make things
> > faster (even in the last release out this morning).
> >
> > All that said, I am not sure there's going to be a way to get it down to
> > an hour. I think getting it down to 3-4hours may be very helpful tho and
> > might be possible.
>
> While we're on the topic of unicorns, if I were the person actually in
> charge of this and had the freedom to do it how I wanted, what I'd
> really want to do is create a much more *modular* compose process,
> where inputs and outputs were defined and associated with each other,
> and you could easily define subsets to be produced at different times
> for different reasons. Not a compose, but a Compose Construction Kit. A
> big chunk of the length of "the compose" is associated with the fact
> that we define "the compose" as a single thing which produces (last
> time I counted) 70+ deliverables. If we had an easy way to say 'ok,
> right now we need a compose which produces A, B, C and D from the
> minimum necessary sets of inputs', that would be a massive improvement.
>
> This hasn't been true for a while (we actually have something like half
> a dozen or more different "composes", right now), but the system is
> still less flexible and it's still more difficult to configure
> different composes than it really ought to be.

Yes, that was one of the ideas I had. Basically do the "newRepo" part
of the compose that generates the new set of tagged in and signed rpms
and base network isntallers 3-4 times a day and then run all the other
components separately (live/arm images, CoreOS, IoT, cloud images) on
their own schedule in separate components consuming the updates. This
is basically what some of the bits do now as you'd indicated. It then
allows focus to be put on each component to speed each piece up
independently rather than as a whole.

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

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

[Peter Robinson]

On Mon, Nov 26, 2018 at 7:47 PM Mohan Boddu  wrote:
>
>
>
> On Mon, Nov 26, 2018 at 2:30 PM Kevin Fenzi  wrote:
>>
>> On 11/26/18 10:58 AM, Peter Robinson wrote:
>> > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
>> >  wrote:
>> >>
>> >> On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
>> >>> On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller 
>> >>>  wrote:
>> >>>> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
>> >>>>> Here's the summary from the page, which proposes we pause the release
>> >>>>> after F30 for these efforts:
>> >>>>
>> >>>> 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!)
>> >>>
>> >>> Can I have a unicorn? Everyone wants this bug absolutely no one has
>> >>> done analysis.
>> >>
>> >> I just don't believe this is true. I'm pretty sure Dennis and Kevin
>> >> have both looked into it before.
>> >
>> > Yes, I mean recently, I was involved in the last time we attempted
>> > this, and there was a number of things identified but quite a bit has
>> > changed since that last happened.
>>
>> Yeah, I think our goal should be 1 minute... just as realistic as one
>> hour. ;)
>>
>> I have not looked into things recently. However:
>>
>> * The mock fsync change (https://pagure.io/releng/issue/7909) may help
>> some.
>>
>> * We have plans to redo the setup on the s390x builders, which should
>> result in them being much faster. That should help.
>>
>> * I know pungi maintaienrs have been doing some work to make things
>> faster (even in the last release out this morning).
>>
>> All that said, I am not sure there's going to be a way to get it down to
>> an hour. I think getting it down to 3-4hours may be very helpful tho and
>> might be possible.
>
> I totally agree, also as Peter mentioned, IOT composes are just taking 1 hour 
> as its
> just consuming the repo rather than generating newRepo as the normal
> nightly composes does. If we can generate the newRepo on the fly whenever
> a package gets build and just use the repo to generate the artifacts either
> individually (splitting the compose) or parallely (as we are doing right now 
> mostly)
> that would really help.

Unfortunately the newRepo/installer bit is likely the most I/O
intensive, but I think it we split it out into it's own process, see
mail I just sent, it would be a good start, and then also a good
separate standalone focus for optimizations.

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

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

[Peter Robinson]

On Mon, Nov 26, 2018 at 7:52 PM Paul Frields  wrote:
>
> On Mon, Nov 26, 2018 at 1:59 PM Peter Robinson  wrote:
> > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> >  wrote:
> > >
> > > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller 
> > > >  wrote:
> > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > > Here's the summary from the page, which proposes we pause the 
> > > > > > release
> > > > > > after F30 for these efforts:
> > > > >
> > > > > 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!)
> > > >
> > > > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > > > done analysis.
> > >
> > > I just don't believe this is true. I'm pretty sure Dennis and Kevin
> > > have both looked into it before.
> >
> > Yes, I mean recently, I was involved in the last time we attempted
> > this, and there was a number of things identified but quite a bit has
> > changed since that last happened.
>
> One of the large factors -- which I think was noted in the page -- was
> RPM scriptlets. Stephen Gallagher met with WIll Woods and James Antill
> just recently to talk about this. The time savings was substantial.
> Combining that with reducing the size of "speculative composes" that

There's no facts or details, to quote "The reported speed increase for
transactions is substantial. This may solve (or greatly reduce) the
compose speed problem, TBD." but it doesn't report the context of the
"speed increase for transactions"  like which transactions?
There's a lot of I/O heavy processes in the compose, like createrepo,
that don't run any rpm tracsactions what so ever.
___
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

[Peter Robinson]

On Mon, Nov 26, 2018 at 8:22 PM Stephen Gallagher  wrote:
>
> On Mon, Nov 26, 2018 at 3:03 PM Peter Robinson  wrote:
> > There's no facts or details, to quote "The reported speed increase for
> > transactions is substantial. This may solve (or greatly reduce) the
> > compose speed problem, TBD." but it doesn't report the context of the
> > "speed increase for transactions"  like which transactions?
> > There's a lot of I/O heavy processes in the compose, like createrepo,
> > that don't run any rpm tracsactions what so ever.
>
> Paul was referring to image creation here. We should be able to get a
> fairly significant (at least one order of magnitude) speed-up on
> creating any image that runs an RPM installation transaction. I'm not
> sure how much that will save in the *whole* compose process, but as
> it's an identified spot where we know how to optimize it, we should do
> so.

But ultimately removing rpm transactions is an optimisation to rpm
which, when it lands, the compose plus numerous other compoents that
use that code path will just consume and at that point get the
benefits of, it's not a reason to skip a release nor is it going to be
a revolution that gets the composes down to an hour. I don't believe
that that alone is and order of magnitude change, do you have any
actual hard figured to back the statement up?
___
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: Release Cadence WAS: Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 4:23 PM Brian (bex) Exelbierd
 wrote:
>
> On Mon, Nov 26, 2018 at 5:05 PM Matthew Miller  
> wrote:
> >
> > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > Here's the summary from the page, which proposes we pause the release
> > > after F30 for these efforts:
> >
> > 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
>
> I am +100 to these changes.
>
> The idea that we can essentially not release for a year to do this
> raises the interesting point that perhaps our release cadence is not
> as rigid as we think it may be.  I don't think we are going to skip
> Gnome and other major updates, are we?  If not, then this also runs
> into the conversation about longer lifecycles and whether we need
> releases, imho.

I like some of the ideas here but I feel we need to have an extremely
well defined set of problems to be solved else we'll delay the
release, achieve very little, and either never release again or not
have anything achieved except a waste of time.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Peter Robinson]

On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller  wrote:
>
> On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > Here's the summary from the page, which proposes we pause the release
> > after F30 for these efforts:
>
> 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!)

Can I have a unicorn? Everyone wants this bug absolutely no one has
done analysis. The fact of the matter is that the compose has a LOT of
I/O and I/O is slow and the cost to upgrade the infrastructure to get
high through put I/O is expensive and no one has ever offered the
budget to resolve that problem. The fact of the matter with this is
that we now produce a lot of release artifacts and that takes time,
some of it can probably be run more in parallel, and possibly some
things run at different times but without a combination of investment
in infrastructure, and maybe even hacking and slashing of components
this is not simply a check box.

For example the IoT compose takes around an hour but ATM we currently
produce 5 artifacts, mostly in parallel, and don't do things like
newRepo for the base rpms because we consume that from the main
compose.

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

They are very nice top level ideas, but each of those components need
to have in depth analysis and not just the hand wavy overview in the
link below.

> Please read 
> https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements
> and comment in this thread.
>
> --
> 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
___
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

[Peter Robinson]

On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
 wrote:
>
> On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote:
> > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller  
> > wrote:
> > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > Here's the summary from the page, which proposes we pause the release
> > > > after F30 for these efforts:
> > >
> > > 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!)
> >
> > Can I have a unicorn? Everyone wants this bug absolutely no one has
> > done analysis.
>
> I just don't believe this is true. I'm pretty sure Dennis and Kevin
> have both looked into it before.

Yes, I mean recently, I was involved in the last time we attempted
this, and there was a number of things identified but quite a bit has
changed since that last happened.

> >  The fact of the matter is that the compose has a LOT of
> > I/O and I/O is slow and the cost to upgrade the infrastructure to get
> > high through put I/O is expensive and no one has ever offered the
> > budget to resolve that problem. The fact of the matter with this is
> > that we now produce a lot of release artifacts and that takes time,
> > some of it can probably be run more in parallel, and possibly some
> > things run at different times but without a combination of investment
> > in infrastructure, and maybe even hacking and slashing of components
> > this is not simply a check box.
>
> That's why the proposal is to skip an entire release to give us time to
> work on it. If it was easy, that wouldn't be necessary.
>
> There are of course at least *two* possible solutions to "there's lots
> of I/O". One is "throw money at making the I/O faster", the other is
> "figure out how to do less I/O".
>
> One hour is a *target*, not a *requirement*. I don't think anyone's
> going to consider the time wasted if we wind up getting it down to two
> hours instead of one.
>
> (Though personally I'd like ten minutes. And two unicorns.)
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://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: delay F31 release to work out infrastructure and lifecycle challenges

[Peter Robinson]

On Mon, Nov 26, 2018 at 9:48 PM Matthew Miller  wrote:
>
> On Mon, Nov 26, 2018 at 08:02:26PM +, Peter Robinson wrote:
> > transactions is substantial. This may solve (or greatly reduce) the
> > compose speed problem, TBD." but it doesn't report the context of the
> > "speed increase for transactions"  like which transactions?
> > There's a lot of I/O heavy processes in the compose, like createrepo,
> > that don't run any rpm tracsactions what so ever.
>
> It seems like there's a lot of room to optimize those things too. For
> example, extract the needed metadata into a database and update that at
> build time rather than compose time, and run createrepo against that instead
> of rpms directly.

Completely agree there's a LOT of improvement that can be done, but I
don't see why that development work cannot be done in parallel and put
it into production when each of the various different components are
ready to go. Ultimately a lot of those sort of ways of optimising
things are things that have been known for some time but no one has
actually stepped up to do the dev work and it it into production
shape. Stopping the standard distro work won't miraculously make that
other work happen and appear.
___
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