Re: Fedora Workstation 40 aarch64 download -- How to run Live CD installer?

[Dennis Gilmore via devel]

https://ausil.fedorapeople.org/Fedora-Workstation-Live-aarch64-40-20240417.n.0.iso
is the last ISO built for a nightly compose for F40. It gives you the
prerelease warning but is very close to GA.

Dennis

On Wed, May 22, 2024 at 7:40 AM Adam Williamson
 wrote:
>
> On Tue, 2024-05-21 at 20:15 -0400, Neal Gompa wrote:
> > On Tue, May 21, 2024 at 8:11 PM Samuel Sieb  wrote:
> > >
> > > On 5/21/24 5:08 PM, Brian Masney wrote:
> > > > I want to put Fedora 40 on my Lenovo Thinkpad x13s laptop, which is an
> > > > aarch64-based laptop with a Qualcomm SoC. I downloaded the Fedora raw
> > > > image from [1], and I can boot from USB using the directions at [2].
> > > > All of the other supported architectures have an ISO available,
> > > > however aarch64 only has a raw image available.
> > > >
> > > > In the past, I would dd the Fedora image directly to my nvme drive,
> > > > however this time I'd like to go through the installer so that I can
> > > > easily setup LUKS encryption on my nvme drive through the installer.
> > > > The raw image doesn't have the installer, and I didn't have luck
> > > > installing the anaconda-livecd package.
> > > >
> > > > Is there a Live ISO available for aarch64 anywhere with an installer?
> > >
> > > https://dl.fedoraproject.org/pub/fedora/linux/releases/40/Workstation/aarch64/iso/
> >
> > That is the experimental osbuild one. There is no official ISO, as it
> > failed to build. It affected Fedora KDE and other variants too. :(
>
> Yes, that.
>
> Beyond that, Dennis Gilmore has been poking at Fedora on the x13s for a
> bit, and has run into some issues you might want to be aware of. See
> https://bugzilla.redhat.com/show_bug.cgi?id=2254940 and
> https://bugzilla.redhat.com/show_bug.cgi?id=2264794 .
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Possible deprecation/removal of Initial Setup from Fedora

[Dennis Gilmore via devel]

On Thu, Nov 23, 2023 at 6:51 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Nov 22, 2023 at 01:53:14PM +0100, Gerd Hoffmann wrote:
> > On Tue, Nov 21, 2023 at 08:07:06AM -0800, Davide Cavalca wrote:
> > > On 2023-11-21 04:34, Jiri Konecny wrote:
> > > > Is Anaconda Initial Setup important for your project or workflow? What
> > > > functionality is absolutely necessary for you? Do you use the text
> > > > mode or the graphical mode? Are you aware of any alternatives? Is
> > > > there anything that would prevent you from migrating to one of the
> > > > proposed alternatives? Also please feel free to share this mail to any
> > > > relevant groups.
> > >
> > > The Fedora Asahi Remix uses initial-setup (in text mode) for our Server 
> > > and
> > > Minimal variants.
> >
> > I think this is used by *all* server images.  It offers to set the root
> > password and add users, so without that you simply can't login ...
>
> systemd-firstboot can set the root user password, but it cannot create
> other users. But maybe we should extend it allow that. We recently had
> a discussion about adding support for creating "normal" users from
> systemd-sysusers, and the conclusion was that we can add a basic mode
> where /etc/skel is copied and the user is written to file databases.
> If people think this would be useful, I could that this idea upstream.

Does it allow for setting the network, language, hostname, and timezone?

Dennis
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Anaconda-devel] Re: Possible deprecation/removal of Initial Setup from Fedora

[Dennis Gilmore via devel]

On Mon, Nov 27, 2023 at 7:53 AM Neal Gompa  wrote:
>
> On Mon, Nov 27, 2023 at 8:13 AM  wrote:
> >
> > On Fri, 2023-11-24 at 15:15 -0800, Adam Williamson wrote:
> > > On Tue, 2023-11-21 at 13:34 +0100, Jiri Konecny wrote:
> > > > Hello everyone,
> > > >
> > > > Is Anaconda Initial Setup important for your project or workflow?
> > > > What
> > > > functionality is absolutely necessary for you? Do you use the text
> > > > mode
> > > > or the graphical mode? Are you aware of any alternatives? Is there
> > > > anything that would prevent you from migrating to one of the
> > > > proposed
> > > > alternatives? Also please feel free to share this mail to any
> > > > relevant
> > > > groups.
> > >
> > > In addition to the other uses identified: if you do a KDE install and
> > > set the root password but do not create a user account, i-s will run
> > > on
> > > first boot and allow (not sure if it requires) user creation. This is
> > > probably the case for other non-GNOME desktops too (GNOME uses its
> > > own
> > > gnome-initial-setup).
> > Sure, but is this really necessary on those images ? If it only
> > triggers if no user account is present only only provides user
> > creation, what about enforcing user creation at installation time
> > instead ?
> >
>
> That is not possible in all cases. Two cases offhand that it is not possible 
> on:
>
> * ARM images
> * OEM preload images
>
> These two cases require us to not pre-configure a user but also allow
> the user to be created on first boot.


These use cases do more than just creating a user account, the user
can also choose to set a root password, set the system timezone, set
the system language, configure the network and hostname. I have pasted
below the first screen you get on initial setup on the Minimal Arm
image

1) [ ] Language settings 2) [x] Time settings
   (Language is not set.)   (America/New_York timezone)
3) [x] Network configuration 4) [!] Root password
   (Connected: enp1s0)  (Root account is disabled)
5) [!] User creation
   (No user will be created)

Dennis

>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Possible deprecation/removal of Initial Setup from Fedora

[Dennis Gilmore via devel]

All of the Arm disk images use initial-setup to configure the image.
There would need to a concrete plan on how to manage the transition to
something else.

Dennis

On Tue, Nov 21, 2023 at 6:35 AM Jiri Konecny  wrote:
>
> Hello everyone,
>
> We (anaconda team) are considering discontinuation of the Anaconda's
> Initial Setup[0] tool, which is not related to Gnome Initial Setup. Here
> is a list of the reasons:
>
> * The relationship between the installer and the Initial Setup is very
> fragile. It is easy to break the Initial Setup by changes in the
> installer or break the installer while we are trying to fix the support
> for the Initial Setup. The shared code is complex as a result and it
> complicates development and maintenance of both projects.
>
> * As we had higher priority items to work on, the codebase is not in an
> ideal state and the upstream repository doesn't even have a proper
> automated CI. Fixing all these issues would take a lot of our resources
> that we would like to spent on improving the installer instead.
>
> * The Initial Setup tool is unnecessarily complicated. Since it shares
> code with the installer, it has to adapt to many limitations and
> requirements of the installation environment. It doesn't use the full
> potential of the installed system, because the installer can't. It
> postpones all actions until the end of the configuration, because the
> installer has to. It doesn't offer the best user experience for the
> first boot configuration, because it is designed to reuse parts of an
> installer. It drags Anaconda into the installed systems.
>
> * There are already alternatives: Gnome Initial Setup,
> systemd-firstboot, and preparation for KDE solution of initial setup. So
> the ecosystem changed from the time when Initial Setup was introduced.
> We think that these alternatives are able to give you a better solution.
>
>
> Before taking any action, we would like to understand your use-cases to
> find out how we can help you to make the transition smoother and also to
> find out how much time you would need for migration.
>
> Is Anaconda Initial Setup important for your project or workflow? What
> functionality is absolutely necessary for you? Do you use the text mode
> or the graphical mode? Are you aware of any alternatives? Is there
> anything that would prevent you from migrating to one of the proposed
> alternatives? Also please feel free to share this mail to any relevant
> groups.
>
> [0]: https://github.com/rhinstaller/initial-setup
>
> Best Regards,
> Anaconda team
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: PR #47: binutils: drop gold

[Dennis Gilmore via devel]

I think it is fair to say it is a system wide change

Dennis

On Wed, Aug 2, 2023 at 1:40 PM Amit Shah  wrote:

>
>
> On Wed, 2023-08-02 at 10:50 -0500, Dennis Gilmore via devel wrote:
> > Given https://fedoraproject.org/wiki/Changes/BINUTILS_GOLD and
> > https://fedoraproject.org/wiki/Features/GoldLinkerDefault it seems
> > reasonable that to remove the feature we have a change to ensure wide
> > notice and documentation of the change
>
> I didn't know there were plans to switch it to default. Good thing we
> didn't do it!
>
> Does wide notice mean a Fedora Change Proposal?  I don't think this
> will qualify for a system-wide change.
>
>
> Thanks,
> Amit
>
> > On Wed, Jun 21, 2023 at 10:08 AM Amit Shah 
> > wrote:
> > > (I realized I hadn't subscribed to f-devel with this email ID, and
> > > this
> > > message didn't make it to devel.  Resending.)
> > >
> > > On Thu, 2023-06-15 at 13:59 +0200, Amit Shah wrote:
> > > > Hey Nick,
> > > >
> > > > I submitted
> > > >
> > > > https://src.fedoraproject.org/rpms/binutils/pull-request/47
> > > >
> > > > yesterday to not build gold by default.
> > > >
> > > > Creating this thread here to ensure you see this, and also a
> > > > chance to
> > > > discuss the change via email rather than on the PR.
> > > >
> > > > Cheers,
> > > >
> > > >Amit
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-
> > > US/project/code-of-conduct/
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedorapro
> > > ject.org
> > > Do not reply to spam, report it: https://pagure.io/fedora-
> > > infrastructure/new_issue
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-
> > US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> > ct.org
> > Do not reply to spam, report it: https://pagure.io/fedora-
> > infrastructure/new_issue
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: PR #47: binutils: drop gold

[Dennis Gilmore via devel]

Given https://fedoraproject.org/wiki/Changes/BINUTILS_GOLD and
https://fedoraproject.org/wiki/Features/GoldLinkerDefault it seems
reasonable that to remove the feature we have a change to ensure wide
notice and documentation of the change

Dennis

On Wed, Jun 21, 2023 at 10:08 AM Amit Shah  wrote:

> (I realized I hadn't subscribed to f-devel with this email ID, and this
> message didn't make it to devel.  Resending.)
>
> On Thu, 2023-06-15 at 13:59 +0200, Amit Shah wrote:
> > Hey Nick,
> >
> > I submitted
> >
> > https://src.fedoraproject.org/rpms/binutils/pull-request/47
> >
> > yesterday to not build gold by default.
> >
> > Creating this thread here to ensure you see this, and also a chance to
> > discuss the change via email rather than on the PR.
> >
> > Cheers,
> >
> >   Amit
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: No koji builds during mass branching and updates-testing enablement

[Dennis Gilmore via devel]

On Thu, Mar 9, 2023 at 7:37 AM Fabio Valentini  wrote:

> Hi all,
>
> As a follow-up from a recent discussion on Matrix/IRC, I'm proposing
> the following change to the development cycle / release schedule:
>
> "Koji builds are blocked while mass branching and updates-testing
> enablement are in progress."
>
> That's it, that's the entire RFC.
>
> Roughly every six months, I run a check for updates that are present
> in the current "stable" release, but missing from "branched", and
> every six months, there's a non-negligible number of builds and / or
> bodhi updates that get stuck in a void because they just happened to
> have been run at the exact worst moment.
>
> In my opinion, the benefits of implementing this change (less releng
> time spent on fixing builds that are stuck in an inconsistent state)
> would outweigh the downsides (two windows of a few hours each during
> the early development cycle where no builds can be launched).
>
> Issues that I see with builds that just "happened to be in the wrong
> place at the wrong time" fall broadly into two categories (though I
> have seen other types of problems that are more rare):
>
> 1. Builds launched while the mass branching is in progress have the
> fcXX (where XX = old-rawhide / branched) dist-tag, but only gets
> tagged with fXY (XY = new-rawhide) by koji. This results in them only
> being available in the rawhide repos, and not from "branched" at all.
> Just resubmitting the build for "branched" doesn't work, because the
> wrong dist-tag causes NVR conflicts. Fixing this requires either
> releng intervention (useless busywork) or bumping the release and
> submitting new builds for *both rawhide and branched* (waste of
> resources).
>

I think this can be resolved by changing the branching process, though
there would still be a small race condition window. We used to lock
everything when branching when we used CVS and went to a lot of effort not
to lock everything. Doing the koji side completely before doing anything in
git should help significantly here.  you can also disable all the builders
and wait for the active builds to complete then do everything, that way new
builds will queue up and wait for the builders to be renabled.



> 2. Builds launched just before updates-testing enablement can get
> stuck in "testing" state before there is an actual updates-testing
> repo, and are hence not available from *any* repository (for testing?)
> during the beta freeze, but will get pushed to stable afterwards. This
> results in users who want to test the beta release (or "pre-beta" with
> updates-testing enabled) to not see these updates at all, but they
> will be pushed to "stable" immediately after the beta freeze is lifted
> (i.e. without *any* amount of testing).
>

I do not understand how this is at all possible. If a build has the tag to
be stable it will show up freeze or not. it may not be in the beta compose,
but will be in the nightly composes and being tested and available there.

Dennis

Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: drop delta rpms (for real this time)

[Dennis Gilmore via devel]

On Tue, Feb 21, 2023 at 2:48 PM Matthew Miller 
wrote:

> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> priority. Last time we talked about this we didn't really get anywhere...
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
>
> ... and that ticket hasn't moved, because fixing it isn't trivial.
>
>
> What we're doing now — as has been the case for several years, already
> noted
> in the previous discussion — has very little end-user value. Also as noted
> in that thread (as in the ticket)... that's unfortunate, because it did
> bring some real benefits (and could possibly do even more.)
>
> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.
>

The last updates just now on three different machines gave me
Delta RPMs reduced 284.9 MB of updates to 281.0 MB (1.4% saved)
Delta RPMs reduced 14.3 MB of updates to 3.3 MB (76.9% saved)
 and the third had no Delta RPMs

Outside of specific instances, the first or last results are typical.  I
think it is time to say goodbye. Times are very different from what they
were when we added support.

Dennis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Dennis Gilmore via devel]

On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote:
> > In my case, I have Network Manager config files included in my initrd
> > and bootargs to bring up the network so that I get automatic disk
> > decryption while on my home network, and prompted for a password when
> > I am not at home. I think this a reasonable enough use case it should
> > be considered in the long term plan. There was an effort many years
> > ago that built the initramfs with the kernel, it was abandoned due to
> > not being able to guarantee sources for the binaries in the initramfs,
>
> If a UKI is built in koji, the initrd it embeds must also be built in koji. 
> And
> when the initrd is built in koji, it is just taking some binaries from rpms 
> and
> repacking them. We ensure that we have an srpm for any official srpm. Thus, 
> going
> back from the UKI, you look up the initrd, and the logs for the initrd build,
> and get a list of rpms, and then look the appropriate srpms from that, and 
> from
> the srpms you get the sources. There's a few more steps, but the availability 
> of
> sources is guaranteed using the mechanism existing for normal rpms.

In the past that was deemed to not be good enough. by legal as it is
too hard for the average user to do.

> > trying to dig up the details I am having trouble finding it, but legal
> > blocked it there is a reference to it in an old FESCo meeting
> > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
> > Additionally, we should also consider
> > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
> > implications and why we moved to have kernel-core, kernel-modules, and
> > kernel-modules-extra for cloud and different use cases.
>
> Yes. That's why this proposal explicitly targets a narrow use case which 
> doesn't
> need many drivers and will support many different machines with the same
> (relatively small) initrd.

I think the proposal needs to be explicit in how other use cases and
all architectures will be handled. I think if we do not have a path
for all architectures to be supported we should spend more time
working out how to cover them all.

> Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Dennis Gilmore via devel]

In my case, I have Network Manager config files included in my initrd
and bootargs to bring up the network so that I get automatic disk
decryption while on my home network, and prompted for a password when
I am not at home. I think this a reasonable enough use case it should
be considered in the long term plan. There was an effort many years
ago that built the initramfs with the kernel, it was abandoned due to
not being able to guarantee sources for the binaries in the initramfs,
trying to dig up the details I am having trouble finding it, but legal
blocked it there is a reference to it in an old FESCo meeting
https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html.
Additionally, we should also consider
https://fedoraproject.org/wiki/Features/DracutHostOnly and the size
implications and why we moved to have kernel-core, kernel-modules, and
kernel-modules-extra for cloud and different use cases.

Dennis

On Tue, Dec 20, 2022 at 9:22 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
>
> == Summary ==
> Add support for unified kernels images to Fedora.
>
> == Owner ==
> * Name: [[User:kraxel| Gerd Hoffmann]]
> * Email: kra...@redhat.com
>
>
> == Detailed Description ==
> The goal is to move away from initrd images being generated on the
> installed machine.  They are generated while building the kernel
> package instead, then shipped as part of a unified kernel image.
>
> A unified kernel image is an all-in-one efi binary containing kernel,
> initrd, cmdline and signature.  The secure boot signature covers
> everything, specifically the initrd is included which is not the case
> when the initrd gets loaded as separate file from /boot.
>
> Main motivation for this move is to make the distro more robust and more 
> secure.
>
> Switching the whole distro over to unified kernels quickly is not
> realistic though.  Too many features are depending on the current
> workflow with a host-specific initrd (and host-specific kernel command
> line), which is fundamentally incompatible with unified kernels where
> everybody will have the same initrd and command line. Thats why there
> is 'Phase 1' in title, so we can have more Phases in future releases
> 
>
> A host-specific initrd / command line is needed today for:
>
> * features needing optional dracut modules (initrd rebuild needed to
> enable them).
> * configuration / secrets baked into the initrd (booting from iscsi
> for example).
> * configuration being specified on the kernel command line.
> ** root filesystem being the most important one.
> [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions]
> allow to remove this.
>
> Phase 1 goals (high priority):
>
> * Ship a unified kernel image as (optional) kernel sub-rpm.  Users can
> opt-in to use that kernel by installing the sub-rpm.  Initial focus is
> on booting virtual machines where we have a relatively small and well
> defined set of drivers / features needed.  Supporting modern physical
> machines with standard setup (i.e. boot from local sata/nvme storage)
> too should be easy.
> * Update kernel install scripts so unified kernels are installed and
> updated properly.
> * Add bootloader support for unified kernel images.  Add
> [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
> unified kernel bls support] to grub2, or support using systemd-boot,
> or both.
>
> Phase 1 goals (lower priority, might move to Phase 2):
>
> * Add proper discoverable partitions support to installers (anaconda,
> image builder, ...).
> ** Temporary workaround possible: set types using sfdisk in %post script.
> ** When using btrfs: configure 'root' subvolume as default volume.
> * Add proper systemd-boot support to installers.
> ** Temporary workaround possible: run 'bootctl install' in %post script.
> * Better measurement and remote attestation support.
> ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to
> allow pre-calculate TPM PCR values.
> ** avoid using grub2 (measures every config file line executed which
> is next to impossible to pre-calculate).
> * Switch cloud images to use unified kernels.
>
> Phase 2/3 goals (longer-term stuff which is not realistic to complete for 
> F38).
>
> * Move away from using the kernel command line for configuration.
> * Move away from storing secrets in the initrd.
> * Handle dracut optional modules in a different way.
>
> systemd has some building blocks which can be used, although none of
> them are used by fedora today.
> [https://www.freedesktop.org/software/systemd/man/systemd-creds.html
> systemd credentials] can be used for secrets (also for configuration).
> The 

Re: Donate 1 minute of your time to test upgrades from F36 to F37

[Dennis Gilmore via devel]

# dnf --releasever=37 --setopt=module_platform_id=platform:f37
--enablerepo=updates-testing $(rpm -q fedora-repos-modular >/dev/null
&& echo --enablerepo=updates-testing-modular) --assumeno distro-sync
Fedora 37 - x86_64

  22 MB/s |
81 MB 00:03
Fedora 37 openh264 (From Cisco) - x86_64

 3.0 kB/s |
2.5 kB 00:00
Fedora Modular 37 - x86_64

 4.5 MB/s |
3.8 MB 00:00
Fedora 37 - x86_64 - Updates

 237  B/s |
257  B 00:01
Fedora Modular 37 - x86_64 - Updates

 722  B/s |
257  B 00:00
Fedora 37 - x86_64 - Test Updates

 4.1 MB/s |
5.0 MB 00:01
Fedora Modular 37 - x86_64 - Test Updates

 266 kB/s |
267 kB 00:01
RCM Tools for Fedora 37 (RPMs)

 7.5 kB/s |
4.5 kB 00:00
RPM Fusion for Fedora 37 - Free

 528 kB/s |
680 kB 00:01
RPM Fusion for Fedora 37 - Free - Updates

 192  B/s |
257  B 00:01
Error:
 Problem: problem with installed package 0ad-0.0.25b-2.fc36.x86_64
  - package 0ad-0.0.25b-2.fc36.x86_64 requires
libboost_filesystem.so.1.76.0()(64bit), but none of the providers can
be installed
  - boost-filesystem-1.76.0-12.fc36.x86_64 does not belong to a
distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

On Mon, Sep 12, 2022 at 8:00 AM Miroslav Suchý  wrote:
>
> Do you want to make Fedora 37 better? Please spend 1 minute of your time and 
> try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo 
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveal 
> potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
>
> The `--assumeno` will just test the transaction, but does not make the actual 
> upgrade.
>
>
> In case you hit dependency issues, please report it against the appropriate 
> package.
>
> Or against fedora-obsolete-packages if that package should be removed in 
> Fedora 37. Please check existing reports against
>
> fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F37FailsToInstall) 
> reports:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109_id_type=anddependson=tvp_id=12486533
>
> Thank you
>
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Dennis Gilmore]

On Sun, Feb 6, 2022 at 7:55 AM David Bold  wrote:
>
> On 11/15/21 20:15, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/RetireARMv7
> >
> ...
> > == Scope ==
> >
> > * Proposal owners: Work with rel-eng to disable the architecture in
> > koji, remove all the various pungi pieces and clean up any other
> > release detritus.
> >
> > * Other developers: No action required.
> >
> > * Release engineering: [https://pagure.io/releng/issue/10387 Releng
> > issue #10387] Disable a bunch of stuff, it's really just one koji
> > admin command and a PR for pungi config changes
> >
> > * Policies and guidelines: No initial updates to policies and
> > guidelines as ARMv7 won't completely disappear until F-36 EOL.
> >
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> >
> > Any current users of Fedora on ARMv7 devices won't be able to upgrade
> > to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
> >
> ...
> > == User Experience ==
> > Any current users of Fedora on ARMv7 devices won't be able to upgrade
> > to Fedora 37, they will have to stay on Fedora 36 until it's EOL.
> ...
>
> I just tried to install Fedora on RPi, and I ended up on [1] where I
> downloaded an image. That was unfortunately armv7 - and I needed to go
> to [2] - which was not linked in the descriptions [3,4]. Also the wiki
> lists first the armv7 [5]
>
> As such I think there will be very many people being stuck on F36,
> without a way to update to F37. I was not happy that my old RPi will not
> work any more, but that we still push people towards a to be retired
> version is very bad.
>
> I think at least this needs to be taken into account, and the websites
> should be fixed as soon as possible. Further, if this is possible, there
> should be instructions to update from armv7 to aarch64, to make a direct
> upgrade, rather than reinstall, possible.
>
> tl;dr
> 1) mention that also aarch64 users are affect, if they run armv7
> software, which seems quite likely
> 2) Change the websites, add deprecation info, and point to aarch64 pages
> 3) discuss impact on armv7 on aarch64 users

We do not support running 32-bit arm software on an AArch64 system. We
should look at places that suggest a 32 bit version of Fedora for a
raspberry pi and update that to use AArch64 versions. Possibly adding
a dnf plugin to all 32 bit arm systems giving users a warning that the
EOL of 32 bit arm is coming and depending on the hardware they will
need to replace it or in the case of the raspberry pi if it is new
enough they could do a clean AArch64 install

Dennis

> Cheers,
> David
>
>
> [1] https://arm.fedoraproject.org/
> [2] https://alt.fedoraproject.org/alt/
> [3] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/
> [4]
> https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#installing-fedora-on-a-raspberry-pi-using-the-fedora-arm-installer_rpi
> [5] https://www.fedoraproject.org/wiki/Architectures/ARM/Fedora_Linux_35
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Any recent changes to the arm builders?

[Dennis Gilmore]

On Wed, Aug 18, 2021 at 3:11 PM Florian Weimer  wrote:
>
> * Dennis Gilmore:
>
> > We intentionally never looked at enabling that and always had no plans
> > to support multi-lib on Arm
>
> It's not multilib.  Buildroots aren't multilib.
>
> I'm pretty sure no one but Fedora is building 32-bit Arm binaries on
> 32-bit Arm kernels.  It's very much a dead end.
>
> Debian uses 64-bit kernels:
>
> | Package: glibc
> | Version: 2.31-16
> | Source Version: 2.31-16
> | Distribution: sid
> | Machine Architecture: arm64
> | Host Architecture: armhf
> | Build Architecture: armhf
> | Build Type: any

There is some magic that's needed for multi-lib that will be needed
for the AArch64 host's rpm to install the rpms into a 32bit chroot.

Dennis

> <https://buildd.debian.org/status/fetch.php?pkg=glibc=armhf=2.31-16=1629282244=0>
>
> Others use cross-compilers.
>
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Any recent changes to the arm builders?

[Dennis Gilmore]

On Mon, Aug 16, 2021 at 12:55 AM Florian Weimer  wrote:
>
> * Kevin Fenzi:
>
> > On Sun, Aug 15, 2021 at 01:51:16PM +0200, Florian Weimer wrote:
> >> * Kevin Fenzi:
> >>
> >> > Yes. They were mistakenly running the normal kernel (so they had ~3GB
> >> > memory available). I moved them back to the lpae kernel (so they see
> >> > 40GB memory), but this causes
> >> >
> >> > https://bugzilla.redhat.com/show_bug.cgi?id=1920183
> >> >
> >> > basically OOM kills kojid, which restarts kojid, which restarts the
> >> > build, which kills kojid, etc...
> >>
> >> Why aren't the builders running 64-bit kernels, like we do for x86-64?
> >
> > This is not a configuration that I think we support in any way.
>
> Who is “we”?
>
> I expect that 64-bit kernel bugs will get more attention upstream.
>
> > At least rpm rejects trying to install a aarch64 kernel on a 32bit
> > userspace.
>
> The host (including kojid) should probably be 64-bit, and only the
> chroot 32-bit.  If that doesn't work, it's an RPM bug/missing feature.

We intentionally never looked at enabling that and always had no plans
to support multi-lib on Arm

Dennis

> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Mass Rebuild

[Dennis Gilmore]

On Wed, Jul 21, 2021 at 3:53 PM Richard W.M. Jones  wrote:
>
> On Wed, Jul 21, 2021 at 01:52:26PM +0200, Tomas Hrcka wrote:
> >
> >
> > Can the packagers fix the failures in the f35-rebuild side tag by
> > themselves
> > while the rebuild is in progress, or do they have to wait on merging the
> > tag?
> >
> >
> >
> > So I am unable to find any policy on this. But assuming that the
> > mass rebuilds bump spec, the packager should be fine with creating a
> > new release.
>
> I'm confused -  if we fix something should we do a build
> in regular rawhide, or in f35-rebuild (or both?)
>

It should be the same as all other mass rebuilds and be done in
rawhide only. the only exception being if you resubmit something that
failed due a fixed build, the buildroot for mass rebuilds is the
rawhide rebuild and until the side tagged is tagged over things are
not built against the new builds in the side tag.

Dennis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New RPM submission

[Dennis Gilmore]

some of the changes have just been committed already, or an equivalent.

The value you have for the license is incorrect
https://fedoraproject.org/wiki/Licensing:Main lists the correct values
-License:LGPL-2.1
+License:LGPLv2


There is no need to explicitly Require xapian-core-libs as rpm
requires the correct shared library provided automatically.
-Requires:   xapian-core, xapian-core-libs, dovecot
+Requires:   xapian-core, dovecot


the description needs to be broken down into shorter lines.  I would
probably expand somewhere in the description that FTS stands for Full
Text Search
 %description
-This project intends to provide a straightforward, simple and
maintenance free, way to configure FTS plugin for Dovecot, leveraging
the efforts by the Xapian.org team.
-
-This effort came after Dovecot team decided to deprecate "fts_squat"
included in the dovecot core, and due to the complexity of the Solr
plugin capabilitles, un-needed for most users.
+This project intends to provide a straightforward, simple and maintenance
+free, way to configure FTS plugin for Dovecot, leveraging the efforts by
+the Xapian.org team.
+
+This effort came after Dovecot team decided to deprecate "fts_squat"
+included in the dovecot core, and due to the complexity of the Solr plugin
+capabilitles, un-needed for most users.


Dennis

On Sun, Apr 25, 2021 at 10:04 AM Joan Moreau  wrote:
>
> > you probably sent the same srpm
>
> No, it is a new one , re-generated
>
>
> > just fine, I did make a few changes to the spec file. with a correct 
> > changelag entry it should pass review
>
> What changes are you suggesting ?
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New RPM submission

[Dennis Gilmore]

you probably sent the same srpm,
https://koji.fedoraproject.org/koji/taskinfo?taskID=2020 builds
just fine, I did make a few changes to the spec file. with a correct
changelag entry it should pass review

Dennis

On Sun, Apr 25, 2021 at 8:58 AM Joan Moreau via devel
 wrote:
>
> Same status :(
>
> https://kojipkgs.fedoraproject.org//work/tasks/9973/66659973/build.log
>
>
>
> On 2021-04-25 14:46, Richard Shaw wrote:
>
> On Sun, Apr 25, 2021 at 8:36 AM Joan Moreau via devel 
>  wrote:
>
> When I launch the "koji" comand, build fails because it does not find g++
>
> (see : https://kojipkgs.fedoraproject.org//work/tasks/9140/66659140/build.log 
> )
>
> However, I put gcc-c++ in the BuildRequires line
>
> (see : 
> https://github.com/grosjo/fts-xapian/blob/master/PACKAGES/RPM/fts-xapian.spec 
> )
>
>
> Just a drive by look at it but try changing:
>
> ./configure --with-dovecot=/usr/lib64/dovecot
>
> to:
>
> %configure --with-dovecot=/usr/lib64/dovecot
>
> Thanks,
> Richard
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New RPM submission

[Dennis Gilmore]

On Sun, Apr 25, 2021 at 8:48 AM Richard Shaw  wrote:
>
> On Sun, Apr 25, 2021 at 8:36 AM Joan Moreau via devel 
>  wrote:
>>
>> When I launch the "koji" comand, build fails because it does not find g++
>>
>> (see : 
>> https://kojipkgs.fedoraproject.org//work/tasks/9140/66659140/build.log )
>>
>> However, I put gcc-c++ in the BuildRequires line
>>
>> (see : 
>> https://github.com/grosjo/fts-xapian/blob/master/PACKAGES/RPM/fts-xapian.spec
>>  )
>
>
> Just a drive by look at it but try changing:
>
> ./configure --with-dovecot=/usr/lib64/dovecot
>
> to:
>
> %configure --with-dovecot=/usr/lib64/dovecot


probably should actually be

%configure --with-dovecot=%{_libdir}/dovecot

Dennis

> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: declaring estimated per-builder RAM usage in spec file

[Dennis Gilmore]

perhaps you should look at how ceph has dealt with a similar issue,
they set the max number of cpus based on the system ram.
https://src.fedoraproject.org/rpms/ceph/blob/rawhide/f/ceph.spec#_1246

Dennis

On Fri, Mar 26, 2021 at 7:49 PM Michel Alexandre Salim
 wrote:
>
> Hi all,
>
> This idea came about when I'm debugging build issues with mcrouter,
> which turns out to be due to build jobs failing to allocate memory and
> getting terminated without aborting the entire compilation, causing
> link issues when empty or corrupted objects are encountered:
>
> https://src.fedoraproject.org/rpms/mcrouter/blob/rawhide/f/mcrouter.spec#_4-8
>
> As a rough estimate it seems like each of the CPU core passed with
> %{_smp_build_ncpus} ended up consuming close to 8 GB of RAM. And that's
> with LTO disabled (yeah, it's not a good situation to be in).
>
> Right now I'm just overriding _smp_build_ncpus to 1, but there is a
> more elegant solution I'd like to propose:
>
> What if one can declaratively set the required RAM per build job --
> either with a single macro, or maybe two if the LTO usecase requires
> even more RAM. e.g. to declare each core might take up to 8 GB:
>
> %global _smp_build_ram_per_cpu 8192
>
> then in case this is run on our aarch64 builder with 40GB RAM,
> dynamically take the minimum of the existing _smp_build_ncpus (which
> AIUI is determined by the number of cores on the machine) and (amount
> of RAM / _smp_build_ram_per_cpu), in this case capping the actual
> number passed to -j to 5.
>
> Is there interest in having this be available? I could imagine it might
> be useful for other resource-intensive package builds e.g. for
> Chromium.
>
> Best regards,
>
> --
> Michel Alexandre Salim
> profile: https://keyoxide.org/mic...@michel-slm.name
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: python noarch packaging vs pip install

[Dennis Gilmore]

On Mon, 2021-03-08 at 19:07 +0100, Miro Hrončok wrote:
> On 08. 03. 21 18:33, Mattia Verga via devel wrote:
> > I'm just wondering: what's the benefit of packaging Python noarch
> > projects in Fedora?
> 
> You can use them as requirements for packaged applications.
> 
> > I can see the reason about packaging architecture specific packages,
> > since they will benefit of optimizations and security flags that
> > Fedora
> > uses, but noarch packages are simply the source code that gets
> > compiled
> > at runtime by the Python interpreter, aren't they?
> > 
> > In what way is different from installing them by pip? Does packaging
> > them worth spending resources (disk space, Koji cycles) and packagers
> > time?
> 
> See above. If they are required by something, it is necessary.
> Packaging leaf libraries as RPMs however indeed brings very little
> benefit.

by packaging you can avoid some of the mess that is seen
https://github.com/pavoni/pywemo/issues/253 pip does not handle some
use cases, rpm/dnf would throw an error and not let you shoot yourself
in the foot

Denis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F33 to F34

[Dennis Gilmore]

 yum distro-sync --releasever 34
Last metadata expiration check: 0:10:11 ago on Wed 24 Feb 2021 11:55:46 AM CST.
Error:
 Problem: package gnome-tour-40~beta-3.fc34.x86_64 obsoletes
gnome-getting-started-docs < 3.38.1-2 provided by
gnome-getting-started-docs-3.38.0-2.fc34.noarch
  - package gnome-getting-started-docs-es-3.38.0-2.fc34.noarch
requires gnome-getting-started-docs = 3.38.0-2.fc34, but none of the
providers can be installed
  - problem with installed package gnome-tour-3.38.0-2.fc33.x86_64
  - problem with installed package
gnome-getting-started-docs-es-3.38.0-1.fc33.noarch
  - gnome-tour-3.38.0-2.fc33.x86_64 does not belong to a distupgrade repository
  - gnome-getting-started-docs-es-3.38.0-1.fc33.noarch does not belong
to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)


is what I get here

On Tue, Feb 23, 2021 at 8:02 AM Geraldo Simião Kutz
 wrote:
>
> I tried here on a F33 kde spin (on bare metal Acer/intel notebook) and it 
> worked fine, just as expected:
> Instalar48 Pacotes
> Atualizar 2019 Pacotes
> Remover  5 Pacotes
> Desatualizar 2 Pacotes
> Tamanho total do download: 1.8 G
>
> regards
> Geraldo
>
> FAS: geraldosimiao
>
>
> Em sáb., 20 de fev. de 2021 às 06:49, Miroslav Suchý  
> escreveu:
>>
>> Do you want to make Fedora 34 better? Please spend 1 minute of your time and 
>> try to run:
>>
>># Run this only if you use default Fedora modules
>># next time you run any DNF command default modules will be enabled again
>>sudo dnf module reset '*'
>>
>>sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
>>  --enablerepo=updates-testing --enablerepo=updates-testing-modular \
>>  distro-sync
>>
>> This command does not replace `dnf system-upgrade`, but it will reveal 
>> potential problems. You may also run `dnf
>> upgrade` before running this command.
>>
>> If you have have rdma-core.i686 installed you have to pass `--allowerasing`.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1919864
>>
>>
>> If you get this prompt:
>>
>>...
>>Total download size: XXX M
>>Is this ok [y/N]:
>>
>> you can answer N and nothing happens, no need to test the actual upgrade.
>>
>> But very likely you get some dependency problem now. In that case, please 
>> report it against the appropriate package. Or
>> against fedora-obsolete-packages if that package should be removed in Fedora 
>> 34. Please check existing reports against
>> fedora-obsolete-packages first:
>>https://red.ht/2kuBDPu
>> and also there is already bunch of "Fails to install" reports:
>>https://bugzilla.redhat.com/show_bug.cgi?id=F34FailsToInstall
>>
>> Thank you
>>
>> P.S. sent from workstation successfully upgraded to F34 :)
>>
>> --
>> Miroslav Suchy, RHCA
>> Red Hat, Associate Manager, Community Packaging Tools, #brno, 
>> #fedora-buildsys
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it: 
>> https://pagure.io/fedora-infrastructure
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reducing noise on devel list

[Dennis Gilmore]

Hi all,

I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all
automated emails to a separate list where people who want to follow
can, while I was part of the proliferation of compose reports coming
here, there is now a great deal of them, and they no longer seem to
trigger any conversation. I think that devel list would benefit from
having all automated reports sent to a reports-list and letting people
bring reports over when there is something to discuss. I was asked to
bring the request to the list for people to weigh in.

Thanks

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

Re: Repository metadata signing?

[Dennis Gilmore]

It would require https://bugzilla.redhat.com/show_bug.cgi?id=1768206
to be fixed. Right now the design in dnf for supporting gpg keys is
quite user hostile, especially in automated unattended use cases.

Dennis

On Mon, Nov 2, 2020 at 6:25 PM Marek Marczykowski-Górecki
 wrote:
>
> Hello all,
>
> Are there any plans to have Fedora repository metadata signed? I think
> dnf supports it for a long time already. I know the packages themselves
> are already signed, but metadata do carry some extra information that
> potentially could be manipulated - for example to _selectively_ hide
> some updates, or to exploit metadata-parsing code (like in [1]).
>
> By default Fedora authenticates metadata using metalink downloaded over
> HTTPS from a Fedora-controlled infrastructure. But still an attack is
> possible with some rather extreme preconditions - namely to obtain a
> mis-issued certificate for mirrors.fedoraproject.org and MitM the
> connection. But also, if anyone set a specific mirror (examples to
> uncomment are over plain http, BTW) or use a 3rd-party repository that
> doesn't use metalinks, it is far easier to mount an attack on repository
> metadata.
>
> Additionally, signed metadata could reduce damage in case of
> metalink-hosting server compromise.
>
> I don't know much about Fedora infrastructure, but perhaps there is
> still something I could help with?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1868639
>
> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Test-Announce] RIP: Thomas Gilliard (satellit)

[Dennis Gilmore]

This is very sad news, he was a very enthusiastic tester.

Dennis

On Sun, Aug 2, 2020 at 5:49 PM Adam Williamson
 wrote:
>
> Hi, folks. I'm sad to report that Thomas Gilliard (satellit), who was a
> valued member of the QA team for many years, passed away last week. His
> wife contacted me with the news. Thomas was a regular and reassuring
> presence at QA and blocker review meetings and ran many thousands of
> tests since he first joined the team in 2009. He was particularly
> dedicated to testing our Sugar builds. We'll miss him.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> test-announce mailing list -- test-annou...@lists.fedoraproject.org
> To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Remove all non UK/USA English spell checker variants from default Fedora installation

[Dennis Gilmore]

Just like there is many different dialects of Spanish, and other
languages the same is true of English, many parts of the language are
shared, and the most critical part for most people is making sure that
things like Paper settings, date, and number formats are correct for
their location. It is also critical that the local nuances though
looking at what is in place on disk all the other languages are
symlinks to en_GB except for en_CA and en_US

Dennis

On Sat, Jul 18, 2020 at 7:45 AM Germano Massullo
 wrote:
>
> All desktop oriented Fedora installers install on the system packages:
> hunspell
> hunspell-en
> hunspell-en-GB
> hunspell-en-US
>
> When a user opens the language list of the spell checker, is has ~24 
> different English options, like English (Antigua and Barbuda), English 
> (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1])
> People who are not native English speakers have this list even bigger because 
> they will have their own language entry, plus others.
>
> Since the huge list is brought by hunspell-en, can we just ship Fedora with 
> hunspell-en-GB and hunspell-en-US ?
> Another option could be to move all non GB/USA English variants to other 
> hunspell-en-* packages as I said in ticket [2]
>
>
> [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

system time in Fedora 32

[Dennis Gilmore]

Hi all,

before going off an filing a bug, I wanted to gather some input.  I
added a battery  for the RTC to one of my ARM boards, in testing that
it was working as expected I booted the system I noticed the following

[root@localhost ~]# date
Wed 01 Apr 2020 05:24:35 PM UTC
[root@localhost ~]# hwclock
2020-04-08 15:15:29.146007+00:00

trying to sync the clock I get

[root@localhost ~]# hwclock --hctosys --verbose
hwclock from util-linux 2.35.1
System Time: 1585762054.571276
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1585761886 seconds after 1969
Last calibration done at 1585761886 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/04/08 15:18:25
Hw clock time : 2020/04/08 15:18:25 = 1586359105 seconds since 1969
Time since last adjustment is 597219 seconds
Calculated Hardware Clock drift is 0.00 seconds
Calling settimeofday(NULL, 0) to set persistent_clock_is_local.
Calling settimeofday(1586359105.00, 0)
hwclock: settimeofday() failed: Invalid argument
[root@localhost ~]# rpm -q glibc
glibc-2.31-2.fc32.aarch64

I came across https://www.mail-archive.com/info-gnu@gnu.org/msg02694.html
which to me indicates that the API used by hwclock is being removed
and it needs updating. I wanted to get a better understanding of what
is going on, and if it should be considered as a blocker for f32. I
tested and the bug exists on x86 and arm and would exist on other
arches also if the network is connected at boot it should not matter
as ntp/chrony would do the right thing. However, without network, the
date and time would be broken, potentially off so much that when
network is connected dnf will not work.

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

Re: Koji shows root.log to blame when in fact the error is in build.log

[Dennis Gilmore]

On Fri, Oct 4, 2019 at 6:30 AM Richard W.M. Jones  wrote:
>
>
> This has happened to me twice this morning, the second time here:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=38048038
>
> Rich.
koji uses very simple logic in parsing mock return codes
https://pagure.io/koji/blob/master/f/builder/kojid#_544 it looks like
mock has started using different return codes and koji will need to
learn them all

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

Re: Tagging commit hashes of Koji builds in dist-git

[Dennis Gilmore]

On Thu, Jun 6, 2019 at 7:11 AM Neal Gompa  wrote:
>
> On Thu, Jun 6, 2019 at 7:53 AM Florian Weimer  wrote:
> >
> > Is there a reason why we do not tag dist-git commits, using a name which
> > is derived from the NEVR from a Koji build?
> >
> > How well does Git scale with thousands of tags?
> >
>
> We used to back in the CVS days, because we needed it for plague. Koji
> blocks duplicate submissions anyway, so it stopped being needed when
> we transitioned to Git.

it was not plague that needed it, using tags was the only way to
cjeckout the intended output, they had the problem that they were not
immutable, if you made a typo you forced in a new tag so you did not
need to bump the nvr

> We're going to probably introduce it for some automation in the near
> future, though.
>
> Git is not great with thousands of any kind of refs, be it branches or
> tags. It still works, it's just things like 'git log' get kind of
> expensive.

koji stores the git hash for all builds, writing a script to get the
hash for a given nvr would be trivial. it just means you have to be
online to retrieve the data than being able to get the date while
disconnected, if it was stored in git.

Dennis

>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-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 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Dennis Gilmore]

On Fri, May 17, 2019 at 7:24 AM Stephen Gallagher  wrote:
>
> On Thu, May 16, 2019 at 2:54 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
> >
> > == Summary ==
> > The upstream OpenSSH disabled password logins for root back in 2015.
> > The Fedora should follow to keep security expectation and avoid users
> > surprises with this configuration.
> >
> > == Owner ==
> > * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
> > * Email: jje...@redhat.com
> >
> > == Detailed Description ==
> >
> > The OpenSSH server configuration contains a configuration option
> > `PermitRootLogin`, which controls whether the root user is allowed to
> > login using passwords or using public key authentication. The root
> > login is target of most of the random or targeted attack on Linux
> > systems and password is usually the weakest part. For that reason, the
> > upstream OpenSSH changed this option in 2015 to `prohibit-password`,
> > which still allows public-key authentication, but prevents the
> > password logins. Fedora was for many practical reasons keeping the old
> > configuration since then, but the difference is no longer bearable and
> > might confuse users expecting the root logins will not be enabled out
> > of the box.
> >
> > On the other hand, there is still a lot of infrastructure, installers
> > and test instances that simply might depend on this configuration and
> > therefore this change needs to go through the system-wide change so
> > everyone is onboard.
> >
> > == Benefit to Fedora ==
> >
> > This will provide more secure Fedora installations out of the box and
> > prevent inadvertently accessible root logins in the wild.
> >
>
> I'm not particularly *opposed* to this change in behavior, but in the
> Fedora Server case, SSH is the primary mechanism for gaining access to
> the system. If we disallow password logins for root, then many
> installs will be inaccessible and users will get... grumpy.

I usually ssh in and enroll my machines to my ipa server, I am not
sure how we can do that in the arm cases where we use pre-generated
images. I know I can use cockpit,  however, the socket is generally
disabled, and them seems to randomly get disabled post install.

Dennis

> There aren't really any major problems for interactive installs where
> the user has direct console access, so I'll disregard that case for
> the moment. For kickstart-based installs, I suppose users would
> normally know to put their SSH public keys in place, so that's also
> less of a concern.
>
> The problematic case I see is the remote VNC headless install. The
> installation is interactive, but there may not be a way to gain direct
> access to the installed system after that. We need to ensure that the
> resulting system is always accessible. Right now, the interactive
> installer would allow us (even encourage us) to set up that machine
> with only a root user and password, which after this Change would mean
> that the system is not reachable.
>
> I see some possible options here, all requiring Anaconda changes:
> 1) Provide a checkbox in the root user creation spoke (defaulting to
> "off") to enable root password logins over SSH. Ideally with notes
> about why it's recommended not to do this.
> 2) Allow users to provide a public SSH key for the root user. Since
> this is generally not performed in an environment where the keys can
> be copy-pasted, we'd probably need to allow specifying a [tiny]URL for
> an authorized_keys file.
> 3) Force Anaconda to require the creation of a non-root user that is a
> member of the `wheel` group, so that this user can be used to SSH in
> and administer the system. Essentially, remove the root user creation
> spoke as an option from the interactive install.
> 4) Force Cockpit to be installed and available on any system that
> doesn't select a non-root user at installation time. This will allow a
> password-based login and allows the root user to set up their SSH keys
> via the "Accounts" tab.
>
> I'm all for hearing what other options we may have here, but those are
> the simplest ones I can think of.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-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: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Dennis Gilmore]

On Thu, May 9, 2019 at 10:22 AM Jun Aruga  wrote:
>
> Kevin and Clement, thanks for the explanation.
>
> I am looking forward to seeing the final compose.
>
> > So, likely we haven't had a armv7 fedora 30 compose recently, and so no
> one has updated it. The container sig would be the ones to ask here.
>
> Sure, I will subscribe the mailing list.
>
> > Yes I do the Dockerhub updates, and since we did not have a full
> compose working in a while I did my best to at least get something out
> for fedora 30.
>
> Thank you for your work! I appreciate it.
>
> > The problem we have with the compose is tracked in this ticket -->
> https://pagure.io/releng/issue/8173
>
> Sure, I will subscribe it.
>
>
> By the way, let me tell you why I want the mult arch Container.
> I am working for multiarch project now [1].
>
> As you may know, when we build or run different arch container (ex.
> aarch64) on the host arch (ex. x86_64), we can not do it.
>
> ```
> $ docker run --rm -t arm64v8/fedora:30 uname -m
> standard_init_linux.go:207: exec user process caused "no such file or 
> directory"
> ```

you should just run
$ docker run --rm -t fedora:30 uname -m
on all arches, we push manifest listed containers to dockerhub so that
command will work everywhere.

Dennis

> But below commands should work on your x86_64 host OS.
> As it is not officially released on the multiarch project, it is still
> my private container repository.
>
> $ docker run --rm --privileged multiarch/qemu-user-static:register --reset
> $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m
> aarch64
> $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-s390x uname -m
> s390x
>
> This technology enables you to debug your app on the multi arch
> environment on local easily or add the environment to your x86_64 base
> CI.
> If you are interested in how it works, see [2] and [3].
>
> [1] multiarch project: https://github.com/multiarch
> [2] https://github.com/multiarch/qemu-user-static
> [3] https://github.com/multiarch/fedora
>
> --
> Jun Aruga / He - His - Him
> jar...@redhat.com / IRC: jaruga
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-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: Maintainer test instances

[Dennis Gilmore]

https://www.openmainframeproject.org/ has some information on getting
access to mainframe resources. there is also some information at
https://osuosl.org/services/ibm-z/ I believe both of them end up
running on hardware at Marist brothers college. there is also some
info on how to use Jenkins for ci on mainframe.

Dennis

On Thu, Apr 4, 2019 at 4:41 PM Neal Gompa  wrote:
>
> On Thu, Apr 4, 2019 at 3:27 PM Kevin Fenzi  wrote:
> >
> > On 4/4/19 1:16 PM, Neal Gompa wrote:
> > > On Thu, Apr 4, 2019 at 10:02 AM Kevin Fenzi  wrote:
> > >>
> > >> Greetings.
> > >>
> > >> This is a periodic reminder that we have some test instances setup for
> > >> package maintainers. Please see:
> > >>
> > >> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> > >>
> > >> for more information.
> > >>
> > >> Additionally, I have just added 2 aarch64 instances (running Fedora 29).
> > >>
> > >> I hope folks will find them useful.
> > >>
> > >
> > > These are definitely awesome, thanks Kevin!
> > >
> > > Would it also be possible to get some s390x in here? It seems like
> > > it's the only arch we support that we don't have here...
> >
> > I'd love to, but sadly the ones we have now are: limited in number,
> > accessible only via a slowish link, and in a lab where we definitely do
> > not want to allow unrestricted access.
> >
> > I think there may be some ibm resources that have instances available,
> > but not sure of the details. I can try and look into getting us an
> > instance somewhere that we could setup as a maintainer test one...
> >
>
> That'd be super useful, as there are times when I have failures only
> in s390x, and not having a way to debug them makes it very painful. :(
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-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: FC30 Mass Rebuild still not finished

[Dennis Gilmore]

On Thu, 2019-02-14 at 02:45 +0100, Tomasz Kłoczko wrote:
> Hi,
> 
> Looks like MR which started two weeks ago still is not fully
> finished. Below command has been executed in mirrored rawhide source
> packages tree.
> 
> [tkloczko@domek fedora]$ for i in fc{21..30}; do echo "$i $(ls -1
> */*$i.src.rpm | wc -l)"; done; echo; ls -1 ?/*|wc -l
> fc21 16
> fc22 15
> fc23 21
> fc24 80
> fc25 12
> fc26 61
> fc27 79
> fc28 223
> fc29 14133
> fc30 25760
> [tkloczko@domek fedora]$ find . -mtime +14 | wc -l; ls -1 ?/* | wc -l
> 20746
> 40616
> 
> Looks like only about half packages actually have been rebuild.
> Possible cause: failing Fedora build infra like in rebuild of the mc
> package:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=32784400
> 
> Is it any plan to resend all those pending build requests?
Package owners are responsible for rebuiling packages that failed to
build, there is only 21638 source rpms in all of fedora as of todays
compose.

$ ls /mnt/koji/compose/rawhide/latest-Fedora-
Rawhide/compose/Everything/source/tree/Packages/*/|wc -l
21638

something is not quite right in your numbers

it looks like there is a total of 1225 srpms that have a .fc2? disttag
in them

$ ls /mnt/koji/compose/rawhide/latest-Fedora-
Rawhide/compose/Everything/source/tree/Packages/*/*fc2?.src.rpm|wc -l
1225

but people should fix the FTBFS for those 1225 packages

Dennis

> kloczek
> -- 
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Multilib inconsistencies between fedora/updates/updates-testing composes

[Dennis Gilmore]

https://pagure.io/releng/issue/4084 its an issue that has existed for
nearly a decade and not been solved. Time was not taken to fixing it
after we disabled installing multilib by default as there was no
reports of it for years.

Dennis

El mié, 12-12-2018 a las 11:32 +0100, Florian Weimer escribió:
> We have seen reports that glibc-headers.i686 comes and goes from the
> x86_64 updates compose.  Previously, we have seen this only for the
> updates-testing compose: 
> 
> This leads to a very bad update experience.  Users file bugs against
> the
> glibc package, but I don't think we can do anything on our side, at
> least not until we know what the actual compose bug is and what
> triggers
> it.
> 
> 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


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

Re: RFC: make fedora-release archful and add some provides

[Dennis Gilmore]

El vie, 14-12-2018 a las 20:33 +0100, Igor Gnatenko escribió:
> Hello folks,
> 
> for long time we have problem if you have some arch-specific
> BuildRequires, you still get one src.rpm from one of arches (not sure
> how koji chooses that one) which might not work for your
> architecture.
> 
> For example if you have following in spec:
> %ifarch %{ldc_arches}
> BuildRequires: ldc
> %endif
> 
> And the src.rpm is taken by koji from x86_64 (included in
> %{ldc_arches}), then you won't be able to run `dnf builddep foo`,
> because it will complain that ldc package is missing.

Can you please be clearer in the problem you are seeing? When
rebuilding srpms, the correct thing to do always is rebuild the srpm
first for the target arch. If I am reading your proposal correctly you
could no longer use macros to define arches. Instead you would have to
have the list of arches embedded in every spec file. The reason that
macros were used in this case was to ensure that all packages were
updated when supported arches changed. So while you could still use the
macro for Exclude/ExclusiveArch lines. You could not when it came
enabling some functionality on a subset of arches.  How many packages
are we talking about?

Dennis


> PROPOSAL:
> 1. make fedora-release archful
> 2. add Provides: system-architecture($arch) to fedora-release, where
> $arch is architecture name
> 3. use Requires: (foo if (system-architecture(x86_64) or
> system-architecture(i686))) in packages
> 
> What do you think? Any suggestions are welcome!
> 
> --
> -Igor Gnatenko
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

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

[Dennis Gilmore]

El lun, 26-11-2018 a las 19:44 -0500, Paul Frields escribió:
> On Mon, Nov 26, 2018 at 5:47 PM Dennis Gilmore 
> wrote:
> > El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió:
> > > Because the people that would be tasked with doing the
> > > development are
> > > also tasked with cranking out the release.  It's a "need more
> > > people problem".
> > 
> > This is no longer entirely true, development of the compose tools
> > is
> > done entirely by PNT DevOps today. Bodhi and other tools in parts
> > of
> > the delivery pipeline are developed by people in Fedora Engineering
> > who
> > also have other tasks to do.
> > 
> > > > 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.
> > > 
> > > Well, I kind of disagree.  Barring magical people that appear out
> > > of
> > > the woodwork that know how the tools work and how they need to be
> > > improved, I don't see an alternative.  Not doing a release to
> > > focus on
> > > our tech debt seems like a good tradeoff.  If there are others
> > > that
> > > really WANT to continue cranking the release with the tools as
> > > they
> > > are today... that might be something that could be pursued.  It
> > > would
> > > still require net new contributors to a critical area.
> > 
> > We would need to engage with the team working on the compose tools
> > and
> > see what time they can dedicate to meeting Fedora's needs.  Likely
> > a
> > end state needs to be defined. then the work can be scoped.
> 
> There are a lot of assumptions wrapped up in these statements. I'm
> not
> sure we should be assuming that delivery mechanisms ought to all be
> tied to internal Red Hat teams. This might be a good opportunity for
> us (meaning people variously assigned in both places) to think about
> whether we should try to decouple more of our delivery side (compose,
> push, etc.), while keeping a tight bond at the build/test side.

There is a lot of assumptions in your assumptions, language is hard :),
I was trying to outline where things are at  not at all how things
should be, sorry I was not clear enough there. My main goal was
pointing out changes from where things were 5 years ago.

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

Dennis


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

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

[Dennis Gilmore]

El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió:
> On Mon, Nov 26, 2018 at 5:01 PM Peter Robinson 
> wrote:
> > On Mon, Nov 26, 2018 at 9:48 PM Matthew Miller <
> > mat...@fedoraproject.org> 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
> 
> Because the people that would be tasked with doing the development
> are
> also tasked with cranking out the release.  It's a "need more people
> problem".

This is no longer entirely true, development of the compose tools is
done entirely by PNT DevOps today. Bodhi and other tools in parts of
the delivery pipeline are developed by people in Fedora Engineering who
also have other tasks to do.

> > 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.
> 
> Well, I kind of disagree.  Barring magical people that appear out of
> the woodwork that know how the tools work and how they need to be
> improved, I don't see an alternative.  Not doing a release to focus
> on
> our tech debt seems like a good tradeoff.  If there are others that
> really WANT to continue cranking the release with the tools as they
> are today... that might be something that could be pursued.  It would
> still require net new contributors to a critical area.

We would need to engage with the team working on the compose tools and
see what time they can dedicate to meeting Fedora's needs.  Likely a
end state needs to be defined. then the work can be scoped. 

Dennis


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

Re: Can we change the xz block size in our cloud images?

[Dennis Gilmore]

On Fri, 2018-11-23 at 13:43 +, Richard W.M. Jones wrote:
> On Fri, Nov 23, 2018 at 12:48:30PM +, Peter Robinson wrote:
> > On Fri, Nov 23, 2018 at 12:43 PM Richard W.M. Jones <
> > rjo...@redhat.com> 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.
> 
> Thanks Peter, I found the source now:
> 
>   https://pagure.io/koji/blob/master/f/builder/kojid#_3887
> 
> More generally, what are the goals for these cloud images?  Example
> questions for the mailing list:
> 
> Must they be absolutely as small as possible?  (I assume small size
> is
> a goal to some extent because of the cost of bandwidth and mirroring
> space).
> 
> Is it important to let people download them and run them without
> uncompressing them?  For me, unxz is pretty slow as well as the
> obvious problem with consuming disk space, so I can get started on a
> cloud image faster if it can be uncompressed on the fly (faster still
> if I didn't have to download it up front, but that has other issues
> like causing load on the mirror sites).
> 
>   $ time unxz Fedora-Cloud-Base-29-1.2.x86_64.raw.xz 
>   real   0m23.760s
>   user   0m21.564s
>   sys0m0.729s
> 
> What do people do with the cloud images?  Do you download them and
> put
> them in local a Glance store?  Do you ignore the published cloud
> images and instead get Fedora on clouds through some other method
> like
> AMIs published by 3rd parties?
Primarily they are there for use in uploading to cloud providers. When
we set things up our goal was solely to make them as small as possible,
our only use case was uploading to EC2 and we delivered them as part of
the release solely to make sure they were available and people could
compare what was in EC2 to what is available for verification
processes. The only other use case we considered was people downloading
and putting them in their own cloud environment.  It sounds like you
have some other use cases and should work with release engineering to
look at accomodating them.  We probably should have some documentation
on each deliverable and the use cases they are supposed to support.

Dennis


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

Re: mass-removal of LANG=anything-not-C.UTF-8 in packages

[Dennis Gilmore]

El lun, 05-11-2018 a las 23:24 +, Zbigniew Jędrzejewski-Szmek
escribió:
> Dear maintainers,
> 
> I'm working again on implementing
> https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot.
> The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8
> (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This
> will be backwards and forwards compatible, in the sense that packages
> that use C.UTF-8 should build OK on older and newer Fedoras.
> 
> Once that's done, I'll file the PRs to actually replace glibc-
> langpacks-all
> with glibc-minimal-langpacks in mock and koji.

What is the change you are planning to put into mock and koji?

the build group in koji is defined as 


build
build
None
false
true

  bash
  bzip2
  coreutils
  cpio
  diffutils
  fedora-release
  findutils
  gawk
  grep
  gzip
  info
  make
  patch
  redhat-rpm-config
  rpm-build
  sed
  shadow-utils
  tar
  unzip
  util-linux
  which
  xz

  
 and in f30 comps the buildsys-build group is 

buildsys-build
<_name>Buildsystem building group
<_description/>
false
false

  bash
  bzip2
  coreutils
  cpio
  diffutils
  fedora-release
  findutils
  gawk
  grep
  gzip
  info
  make
  patch
  redhat-rpm-config
  rpm-build
  sed
  shadow-utils
  tar
  unzip
  util-linux
  which
  xz

  

These are what mock uses to create the minimal buildroot in both cases,
neither includes anything with glibc, greping through the mock code for
glibc turns up nothing.  I mention all of this because glibc-all-
langpacks is pulled into the buildroot entirely by dependencies, the
only change needed is to whatever package is pulling in glibc-all-
langpacks to no longer pull it in. 

Dennis



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

Re: Moving on from Council Engineering role

[Dennis Gilmore]

El jue, 11-10-2018 a las 12:53 -0400, Josh Boyer escribió:
> Hello Fedora Friends,
> 
> I believe it's time for me to move on from my current role as the
> Council Engineering representative.  When I resigned from FESCo a bit
> ago, I thought I could still fulfill this role.  Unfortunately, that
> turns out to not be the case.  I cannot in good conscience hold a
> seat
> on the Council and be an absentee member.
> 
> As we look to the future for Fedora, we need someone with more active
> participation to be present.  Fortunately, we have a large set of
> very
> competent people that I believe can step into this role without
> issue.
> While it is only a suggestion, I would like to nominate Petr Šabata
> as
> the new Council Engineering rep.  He is more than capable of
> discussing the technical implications of Modularity and the newly
> proposed Objective from Paul.  The decision will ultimately be up to
> FESCo and the Council of course.
> 
> These are important times for Fedora and I'm excited for the future!
> I will continue to participate as I can and I'm looking forward to
> seeing the directions we take as a project and as a distribution.  It
> has been an honor to be part of the Fedora Council for the past few
> years.  Thank you to the community for trusting me with that role for
> so long.

Thank you Josh for all your work over the years, and for the self
awareness that you are not doing the job you want to be doing. I think
that Petr would be able to the job technically very well, however I
object to your reasoning for nominating him. It seems to me that the
nominations is done with a strong bias to a small subset of the
technical directions we are going in. As the Engineering representive I
think there needs to also be a strong focus on the other things like
Fedora CoreOS, emerging technologies (some are coverd with objectives
like IoT), as well as the other technical challenges fedora is facing.
I also know Petr has a lot on his plate already.  Are we perhaps asking
too much of him?

Dennis


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

Re: fedpkg clone doesn*t work

[Dennis Gilmore]

El lun, 10-09-2018 a las 14:58 +, Martin Gansser escribió:
> every time I edit my account, the public ssh key is missing.
> 
> the FSA public SSH-key and the key in .ssh/id_rsa.pub are the same.

Can you ssh to fedorapeople.org?

Dennis


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

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Dennis Gilmore]

El jue, 14-06-2018 a las 12:06 +0200, Jan Kurik escribió:
> = Proposed System Wide Change: Make BootLoaderSpec the default =
> https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault
> 
> 
> Owner(s):
>   * Javier Martinez Canillas 
>   * Peter Jones 
> 
> 
> Use BootLoaderSpec fragment files by default to populate the
> bootloaders boot menu entries.
> 
> 
> 
> == Detailed description ==
> The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> Boot Loader Specification (BLS)] defines a scheme and file format to
> manage boot loader configuration for each boot option in a drop-in
> directory, without the need to manipulate bootloader configuration
> files. These drop-in directories are the standard on Linux nowadays,
> so the goal is to also extend this concept for boot menu entries.
> This is especially important in Fedora because the same bootloader is
> not used in all architectures. GRUB 2 is used in most of them, but
> there are others such as zipl for s390x and Petitboot for ppc64le.
> Not
> all bootloaders have the same configuration file format, so there is
> a
> need for an indirection level and per bootloader specific logic to
> edit these configuration files, when adding or removing a boot entry.
> The current component that does this work is grubby, that has support
> for all the different bootloader configuration file formats and
> manipulates them on kernel installation or uninstallation. Besides
> manipulating the bootloader configuration files, grubby also does
> other things like running dracut to create an initial ramdisk image.
> Fedora already has a lot of infrastructure in place to not require
> modifying bootloader configuration files for boot menu entries. The
> BootLoaderSpec and drop-in BLS fragments can be used instead, and the
> kernel-install script can do any additional task that is currently
> done by grubby. The kernel-install script has a pluggable design that
> uses a drop-in directory for scripts to extend its functionality. So
> if needed, any bootloader specific logic can be implemented as
> kernel-install scripts.
> With this setup the bootloader configuration could be static and not
> modified after installation.
> The missing piece was the lack of BLS support on all the supported
> bootloaders, but all of them have support to parse BLS fragments now.
> So we can default to install BLS files on kernel installation and
> drop
> grubby.

There is no BLS support in u-boot, how is it planned to support ARM
systems? it is not an issue for aarch64 systems using u-boot as they
use the efi implementation and load grub2, that is not true on 32 bit
arm at all.

Dennis

> == Scope ==
> * Proposal owners:
> ** Generate BLS snippets at kernel build time and ship in the kernel
> packages.
> ** Make kernel-install scripts to copy the BLS, kernel and initramfs
> images and do any architecture specific task.
> ** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot
> menu entries from the information in BLS files.
> ** Have a grubby wrapper for backward compatbility that manipulates
> BLS files.
> ** Modify packages that use grubby to instead install BLS fragments
> (memtest86+, tuned).
> ** Make sure this is all properly documented in release-notes, etc.
> 
> * Other developers:
> ** The anaconda developers will need to review and merge the patches
> to change the default to BLS.
> ** Test and watch for regressions.
> 
> * Release engineering:
> RelEng review ticket: https://pagure.io/releng/issue/7572
> 
> ** List of deliverables:
> N/A
> 
> * Policies and guidelines:
> The policies and guidelines do not need to be updated.
> 
> * Trademark approval:
> No changes needed.
> -- 
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/CTKJBECHWEVF5IN6FO5TV7SIYWIMKYRT/

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

Re: streamlining fedora-release (again)

[Dennis Gilmore]

El mié, 27-06-2018 a las 11:58 +, Zbigniew Jędrzejewski-Szmek
escribió:
> Hi,
> 
> I'd like to pick up the process of converting fedora-release from a
> split "upstream"/"downstream" model into a single repo in src.fp.o.
> 
> For previous discussions see
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/thread/CIKK4WEF5ACVWZ6EWBKNHSKKKCDTV27C/#CIKK4WEF5ACVWZ6EWBKNH
> SKKKCDTV27C
> https://pagure.io/fedora-release/pull-request/119
> https://pagure.io/releng/issue/7293
> 
> I made the changes requested by Dennis Gilmore
> (an exploded repo, no tarball) and they are available in
> https://src.fedoraproject.org/fork/zbyszek/rpms/fedora-release/branch
> /drop-upstream-split .
> 
> "Tests" were requested — I tested using rpmdiff and diffoscope that
> the changes only introduce timestamp differences, and then the
> subsequent cleanup commits only introduce expected differences
> (Group tag becomes "Unspecified", the description is updated,
> whitespace changes in scriptlets). If additional testing is required
> let me know what.
> 
> As stated previously, I'm requesting co-maintainership of
> fedora-release to merge presets requests in reasonable time
> and to implement the changes described above.
> 
> Let me know if you need anything else from me now.
> (I'll revisit the outstanding PRs against fedora-release once
> the new repo is established, I hope that happens quickly.)
> 
> Zbyszek
fedora-release is no longer in my scope of influence, however the
testing requested was to make sure that any updates do not break the
package, the reluctance to simplify the process is due to the number of
times simple patches were submitted that broke things in unintended
ways.

Dennis

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

Re: FESCo Elections - May 2018 : Results announcement

[Dennis Gilmore]

On Thu, 2018-06-14 at 23:50 +0200, Till Maas wrote:
> On Thu, Jun 14, 2018 at 03:57:36PM -0400, Josh Boyer wrote:
> > On Thu, Jun 14, 2018 at 3:53 PM Randy Barlow
> > > Downside is that it would be possible (though I'd guess unlikely)
> > > for
> > > all of FESCo to suddenly change to 9 different people and there'd
> > > be no
> > > members who know the current state of things. We would also need
> > > to do
> > > something a little awkward to get into this state since we
> > > currently
> > > have staggered terms.
> > 
> > The election structure was setup specifically to avoid this
> > problem.
> > The alternative solutions were all pretty poor.
> 
> This seems to be a very theoretical problem because it would mean
> that
> we have nine times the number of new candidates that we have now and
> everyone is so unsatisfied with FESCo that only new candidates will
> be
> elected. And if there is so deep dissatisfaction, a fresh start might
> even be a good idea. Also there would still be other people around to
> provide guidance or there is another problem.

Theory will always become reality at some point. I think there is very
good reasons to keep the staggered approach to electing FESCo members. 

Dennis

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

Re: F29 System Wide Change: i686 Is For x86-64

[Dennis Gilmore]

El mar, 05-06-2018 a las 15:59 -0400, Adam Jackson escribió:
> On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
> 
> > as part of this change I suspect we would need to make kernel
> > changes
> > to stop building a i686 kernel, and all i686 deliverables would
> > stop
> > being made.
> 
> We would?

the change has a few things that indicate to me that it is true

The Release Notes section explicitly claims it is true
Fedora 29 requires an x86-64 system for installation. This includes the
32-bit x86 (i686) packages built primarily for use x86-64 systems.

as well as the CFLAGS changes
The default compiler flags will be switched to -march=x86-64
-mtune=generic -mfpmath=sse -mstackrealign. This enables SSE2 support
with optimal backwards compatibility due to automatic stack
realignment. (16-byte stack alignment was introduced with SSE2 support
in the i386 ABI, but old binaries only provide 4-byte stack alignment.)

if we use -march=x86-64 on 32 bit builds why would it be expected that
code will run okay on any 32 bit x86 machine? So if it is not true that
the code will only run on x86-64 then the change needs to be updated to
reflect what 32 bit systems the code will run on, or we work with the
kernel team, drop support entirely for 32 bit x86 kernels, and work
with releng to drop all 32 bit x86 deliverables.

Florian please update the change so that it reflects the actual
situation.

Dennis





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

Re: F29 System Wide Change: i686 Is For x86-64

[Dennis Gilmore]

El mar, 05-06-2018 a las 15:59 -0400, Adam Jackson escribió:
> On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote:
> 
> > as part of this change I suspect we would need to make kernel
> > changes
> > to stop building a i686 kernel, and all i686 deliverables would
> > stop
> > being made.
> 
> We would?
It may be a bad assumption on my part, I am assuming that optimising to
run on x86_64 means that we will not be able to run on any actual
x86_32 hardware.

Dennis

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

Re: F29 System Wide Change: i686 Is For x86-64

[Dennis Gilmore]

as part of this change I suspect we would need to make kernel changes
to stop building a i686 kernel, and all i686 deliverables would stop
being made. With the current tooling we would never be able to build 32
bit x86 containers, which is not something that is done today.  I would
also be curious what the plan is to test the 32 bit bits. they are
likely to get significantly less testing than the little they get
today.

Dennis

El lun, 04-06-2018 a las 10:35 +0200, Jan Kurik escribió:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
> 
> 
> Owner(s):
>   * Florian Weimer 
> 
> 
> Fedora builds its i686 packages for use on x86-64 systems as multi-
> lib RPMs.
> 
> 
> 
> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they
> are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject
> .org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).
> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.
> 
> 
> == Scope ==
> * Proposal owners:
> Adjust the redhat-rpm-config, gcc, and glibc packages to switch to
> the
> new compiler flags. Except for mstackrealign, there is substantial
> experience with this configuration downstream.
> 
> * Other developers:
> Other developers can enable SSE2 optimization in their packages if
> they want, where this has been a compile-time option only.
> 
> * Release engineering:
> https://pagure.io/releng/issues/7543 #7543
> 
> ** List of deliverables: TBD
> 
> * Policies and guidelines:
> i686 is no longer a primary architecture. The Packaging Guidelines do
> not currently require support for non-SSE2 x86 systems, so no change
> is required there.
> 
> * Trademark approval:
> N/A (not needed for this Change)
> -- 
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/CC22ZTFDB5L3BFSQG7M3TUZUVYKFUSKP/

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

Summary/Minutes from today's FESCo Meeting (2018-06-01)

[Dennis Gilmore]

===
#fedora-meeting: FESCO (2018-06-01)
===


Meeting started by dgilmore at 15:00:53 UTC. The full logs are
available
at
https://meetbot.fedoraproject.org/fedora-meeting/2018-06-01/fesco.2018-
06-01-15.00.log.html
.



Meeting summary
---
* init process  (dgilmore, 15:01:00)

* #1901 F29 System Wide Change: Perl Move to MetaCPAN  (tyll, 15:06:28)
  * LINK: https://pagure.io/fesco/issue/19011   (tyll, 15:06:34)
  * AGREED: accept F29 System Wide Change: Perl Move to MetaCPAN (+6,
0,
-0)  (tyll, 15:10:00)

* #1899 F29 System Wide Change: Move /usr/bin/python into a separate
  package  (tyll, 15:10:54)
  * LINK: https://pagure.io/fesco/issue/18999   (tyll, 15:10:59)
  * AGREED: accept F29 System Wide Change: Move /usr/bin/python into a
separate package (+7, 0, -0)  (tyll, 15:29:55)

* #1898 F29 System Wide Change: The tzdata transition to  (dgilmore,
  15:30:50)
  * LINK: https://pagure.io/fesco/issue/18988   (dgilmore, 15:30:57)
  * AGREED: accept F29 System Wide Change: The tzdata transition to
'vanguard' format (+7, 0, -0)  (dgilmore, 15:32:45)

* #1897 F29 System Wide Change: Perl 5.28  (dgilmore, 15:32:53)
  * LINK: https://pagure.io/fesco/issue/18977   (dgilmore, 15:32:58)
  * AGREED: accept F29 System Wide Change: Perl 5.28 (+7, 0, -0)
(dgilmore, 15:35:56)

* #1893 Non-responsive maintainer for libinvm-i18n,libinvm-cli,
  (dgilmore, 15:36:16)
  * LINK: https://pagure.io/fesco/issue/18933   (dgilmore, 15:36:22)
  * ACTION: bowlofeggs to follow up on devel@  (dgilmore, 15:37:12)
  * AGREED: bowlofeggs to buy everyone , followup on devel@ and then
look at again next week  (dgilmore, 15:38:26)
  * AGREED: bowlofeggs to buy everyone , followup on devel@ and then
look at again next week (+7, 0, -0)  (dgilmore, 15:38:54)
  * AGREED: bowlofeggs to buy everyone , followup on devel@ and then
look at again next week (+7, 0, -0)  (dgilmore, 15:39:10)

* Elections  (dgilmore, 15:39:30)
  * LINK:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nomina
tions
(dgilmore, 15:40:10)
  * do not forget the interviews  (tyll, 15:41:41)
  * there is now the required minimum number of candidates, elections
can move forward  (dgilmore, 15:41:41)
  * interview stage can now proceed  (dgilmore, 15:42:20)

* Next week's chair  (dgilmore, 15:42:39)
  * ACTION: bowlofeggs will chair next meeting  (dgilmore, 15:44:19)

* Open Floor  (dgilmore, 15:44:21)
  * Flock CfP is open  (dgilmore, 15:45:05)
  * LINK: https://flocktofedora.org/#cfpp   (tyll, 15:45:38)
  * Flock 2018 will be in Dresden, Germany this August 8-11  (zbyszek,
15:45:51)
  * LINK:
https://bugzilla.redhat.com/showdependencytree.cgi?id=1555378_
resolved=1
(tyll, 15:49:28)
  * about 891 open FTBFS bugs  (tyll, 15:49:43)

Meeting ended at 15:52:59 UTC.




Action Items

* bowlofeggs to follow up on devel@
* bowlofeggs will chair next meeting




Action Items, by person
---
* bowlofeggs
  * bowlofeggs to follow up on devel@
  * bowlofeggs will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dgilmore (61)
* tyll (43)
* bowlofeggs (40)
* zbyszek (31)
* maxamillion (22)
* zodbot (20)
* nirik (19)
* jsmith (14)
* sgallagh (0)
* jwb (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

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

Schedule for Friday's FESCo Meeting (2018-06-01)

[Dennis Gilmore]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

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

or run:
  date -d '2018-06-01 15:00 UTC'


Links to all issues below can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1893 Non-responsive maintainer for libinvm-i18n,libinvm-cli,
libinvm-cim
.fesco 1893
https://pagure.io/fesco/issue/1893

= New business =

#topic #1901 F29 System Wide Change: Perl Move to MetaCPAN
.fesco 1901
https://pagure.io/fesco/issue/1901

#topic #1899 F29 System Wide Change: Move /usr/bin/python into a
separate package
.fesco 1899
https://pagure.io/fesco/issue/1899

#topic #1898 F29 System Wide Change: The tzdata transition to
'vanguard' format
.fesco 1898
https://pagure.io/fesco/issue/1898

#topic #1897 F29 System Wide Change: Perl 5.28
.fesco 1897
https://pagure.io/fesco/issue/1897


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

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

Re: How to make DNS resolving fail early in mock?

[Dennis Gilmore]

El mié, 30-05-2018 a las 14:33 +0200, Miro Hrončok escribió:
> On 30.5.2018 14:09, Miro Hrončok wrote:
> > So I decided to test this. I've added the following to the spec:
> > 
> >  time curl http://example.com/
> > 
> > Here are the times:
> > 
> >   * my mock: real  0m56.595s Could not resolve host
> >   * Koji:real  0m0.030s  Could not resolve host
> 
> And copr: real  0m40.578s Could not resolve host
> 
You could try using --old-chroot the koji builders also have the
internet firewalled off. they ips that they can connect to is extremely
 limited.

Dennis 

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

[Fwd: Renaming "docker" references to generic ones like "container" or "OCI']

[Dennis Gilmore]

I am forwarding to devel list as Sushma was not subscribed and it was
rejected.

Dennis

- Mensaje reenviado 
De: Sushma Gajanur Shivakumar 
Para: devel-annou...@lists.fedoraproject.org
Cc: Ben Breard , den...@ausil.us, Mohan Boddu , Greg Sterling 
Asunto: Renaming "docker" references to generic ones like "container"
or "OCI'
Fecha: Fri, 13 Apr 2018 16:15:32 +0200

Hi All,

As the container landscape has changed over the last few years, Docker
Inc. has changed what the term "docker" means. Along with changes in
the container namespace with tools like buildah, cri-o, rkt and other
ways to run containers, it makes sense to refer to containers in a more
generic sense, using terms like "container" or "OCI(Open Container
Initiative)" instead of "docker".

We have already renamed the Docker namespace to "containers" in dist-
git. The Bugzilla project for containers is under container as well.
Wherever possible to be consistent with using more generic terms,
"docker" should be renamed to an appropriate generic term. This will
allow us to more seamlessly adapt and change with the continuing
evolution of the container based world. A side effect is that the
changes will more closely align us with ongoing work within Red Hat.

There are several areas that can be evaluated for changes from "docker"
to "container" (or OCI).  These include:
Changing a package description to be more generic
Working with upstream to rename the project and bringing that back to
Fedora
Changing labels and descriptions used within Dockerfiles
The non-exhaustive* full list of current containers[1] and packages[2]
to be considered is not a very large list and your consideration and
efforts to help are greatly appreciated.

* The bellow URLs will not show a package that is using docker only in
the package description which shows up in bugzilla along with other
locations
[1] https://src.fedoraproject.org/projects/container/%2A
[2] https://src.fedoraproject.org/projects/*docker*


Best Regards,
Sushma Shivakumar
RCM Project Manager
Red Hat, Brno

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Status of OwnCloud/NextCloud

[Dennis Gilmore]

El mar, 03-04-2018 a las 17:07 +, Stephen Gallagher escribió:
> On Tue, Apr 3, 2018 at 12:39 PM Christian Glombek  .de> wrote:
> > Hello!
> > 
> > I'd be happy to maintain NextCloud!I have already done the
> > packaging work for NC v13 and v13.0.1, and various dependencies.
> > Unfortunately there is no upgrade path from the EOL'd v10 rpm that
> > is in Fedora right now, which seems to be somewhat of a blocker.
> > I'd happily support upgrades from v13 but I have no interest in
> > packaging old versions (I might reconsider if dependency bundling
> > were allowed for these "upgrade path" rpms).
> 
> Could you explain more about what you would need to do to clean the
> upgrade path from v10? I'm not sure what you meant above.

nextcloud requires that in order to get to nextcloud 13 from 10, you
upgrade to 11 then to 12 then finally to 13. you have to run the
upgrade process in order to keep things working. they do not support
skipping versions
Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: SSE2 support on PPC/s390/ARM

[Dennis Gilmore]

El sáb, 17-03-2018 a las 17:25 +0100, Antonio Trande escribió:
> Hello everyone.
> 

> 
> Please, can you confirm that SSE2 support is not on those
> architectures?
> If it's so, i will obliged to exclude new release of Openclonk on
> PPC/s390/ARM.

sse2 is a intel cpu extention it is only available on x86 https://en.wi
kipedia.org/wiki/SSE2 it is also not available on all x86 cpu's the
code is question seems to have a bug in its design if it is relying on
the behavior, some supported 32 bit hardware will not run the code.
Taking advantage of such instructions should be a runtime decison and
on other arches the code should have a path that will work. https://fed
oraproject.org/wiki/Packaging:Guidelines#Architecture_Support lays out
the policy for excluding arches, please be sure to file the appropriate
bugs. It would be good to work with upstream to look into supporting
all architectures. The architecture teams can help you in getting
things working.


Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Dennis Gilmore]

El vie, 16-03-2018 a las 15:19 -0700, Adam Williamson escribió:
> On Fri, 2018-03-16 at 16:04 -0400, Dennis Gregorovic wrote:
> > modules are not RPMs.  I would not expect them to necessarily use
> > the same
> > format as RPMs.  If we take koji out of the equation,
> 
> That's an extremely big and invalid 'if', though.
koji is mirroring rpm's behaviour, the if would have to be if you took
rpm out of the equation.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Changes in Fedora Release Engineering

[Dennis Gilmore]

Hi all,

Today I am writing to announce some changes in Fedora Release
Engineering. Effective Friday the 23rd of March 2018 Mohan Boddu will
be taking over as the primary person responsible for Release
Engineering in Fedora.  Mohan has effectively been the primary person
since Fedora 26 as he has been doing most of the work.  I will be
taking on a new role within Red Hat, and will no longer be in the
internal Release Engineering team. 

Going forward Mohan will be supported by Suzanne Yeghiayan as project
manager for release engineering. All requests for work should go though
pagure[1] or taiga[2] to be groomed, prioritised and scoped.


I have posted a blog post[3] with some of my thoughts in reflection
looking back at the last 8 or so years.

Thank you all for you support over the years and your continued support
of Mohan and the rest of the Release Engineers in Fedora.


Dennis

[1] https://pagure.io/releng
[2] https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-at
omic-tooling/
[3] https://ausil.us/wordpress/?p=143

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Changes in Fedora Release Engineering

[Dennis Gilmore]

Hi all,

Today I am writing to announce some changes in Fedora Release
Engineering. Effective Friday the 23rd of March 2018 Mohan Boddu will
be taking over as the primary person responsible for Release
Engineering in Fedora.  Mohan has effectively been the primary person
since Fedora 26 as he has been doing most of the work.  I will be
taking on a new role within Red Hat, and will no longer be in the
internal Release Engineering team. 

Going forward Mohan will be supported by Suzanne Yeghiayan as project
manager for release engineering. All requests for work should go though
pagure[1] or taiga[2] to be groomed, prioritised and scoped.


I have posted a blog post[3] with some of my thoughts in reflection
looking back at the last 8 or so years.

Thank you all for you support over the years and your continued support
of Mohan and the rest of the Release Engineers in Fedora.


Dennis

[1] https://pagure.io/releng
[2] https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-at
omic-tooling/
[3] https://ausil.us/wordpress/?p=143

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Re: F28 FTBFS bugs?

[Dennis Gilmore]

El jue, 15-03-2018 a las 11:01 +0100, Daiki Ueno escribió:
> Hello,
> 
> Yesterday I received a couple of new FTBFS bugs, apparently triggered
> by
> the F28 mass rebuild:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1556047
> https://bugzilla.redhat.com/show_bug.cgi?id=1556162
> 
> As the mentioned koji builds are back in February, I am wondering if
> those are something I should still worry about.
> 
> I suspect the former was failing due to a Vala regression recently
> fixed[1], and the latter could be a false-positive as it points to
> the
> build against f27-candidate.
> 
> Footnotes: 
> [1]  https://bugzilla.gnome.org/show_bug.cgi?id=793299
> 
have you rebuilt your packages?  if not yes you need to rebuild them

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Improving the glibc32 situation

[Dennis Gilmore]

El vie, 09-03-2018 a las 14:55 +0100, Florian Weimer escribió:
> On 03/09/2018 02:52 PM, Josh Boyer wrote:
> 
> > Stepping back a bit, I'm curious why glibc32 would land in the
> > composes.  It shouldn't...  it should only be tagged in the fNN-
> > build
> > tags, which the composes should not pull from.  Where do we have
> > recent issues of it getting pulled into a compose?
> 
> It happens after every single mass rebuild.  The package is rebuilt
> and 
> tagged, and then *boom*.
> 
> Thanks,
> Florian

I think we can resolve this by adding glibc32 to the mass rebuild
blacklist. then it will not be rebuilt.  the sources for it is
precompiled binaries so rebuilding does nothing

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Broken system upgrade due to rich dependencies

[Dennis Gilmore]

El jue, 08-03-2018 a las 12:55 +0200, Panu Matilainen escribió:
> On 03/08/2018 12:42 PM, Panu Matilainen wrote:
> > On 03/08/2018 12:21 PM, Reindl Harald wrote:
> > > 
> > > 
> > > Am 08.03.2018 um 08:53 schrieb Panu Matilainen:
> > > > P.P.S. So why didn't yum have anything like that? Because back
> > > > then, 
> > > > there were other upgrade methods that did run on the "target
> > > > stack": 
> > > > anaconda, preupgrade, fedup to name a few
> > > 
> > > and i never used one of them - i did hundrets of dist-upgrades
> > > for 
> > > more than a decade on dozens of machines (workstations and
> > > production 
> > > servers) with yum/dnf - full stop
> > 
> > Sure. You just either didn't upgrade between versions that
> > introduced a 
> > new rpmlib() dependency or updated rpm first, one way or the
> > other. 
> 
> ...or the couple of features were introduced in that period were
> done 
> using the one generic solution at hand I did mention in my earlier 
> email: wait until the previous Fedora supports the new feature too 
> before enabling in the new. Come to think of it, I think this was
> mostly 
> the case. It'd be in the ml archives if somebody wants to dig (we're 
> talking about rpm 4.6 - 4.7 era, SHA256 file digests and XZ payload 
> compression being the big ones I can remember offhand)
> 
> Oh, and of course back then it was nearly impossible to introduce
> such 
> features in the first place because the builders were running RHEL. 
> Those couple of features that were introduced required a custom rpm
> to 
> be used on builders. Those were the days... no I dont miss.
> 
I do not miss those days either, but we knew and communicated the
changes. and managed them so upgrades would work. We were careful to
make sure that the change was managed. Maybe too careful. Managing
hybrid systems for building was a pain and I never want to go do that
again.  We do need to make sure that as new rpm/dnf features are
supported that we have everything in place to fully support them,  that
means waiting for a short period of time from being in RPM to being
something we can tell packagers to go and use.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Dennis Gilmore]

El mar, 06-03-2018 a las 17:20 +0100, Germano Massullo escribió:
> Il 06/03/2018 16:35, Dennis Gilmore ha scritto:
> > El mar, 06-03-2018 a las 15:29 +0100, Germano Massullo escribió:
> > > During package firefox-pkcs11-loader build, the following two
> > > spec
> > > file
> > > lines
> > > 
> > > %dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
> > > %_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> > > 
> > > and also this variant
> > > 
> > > %dir %{_libdir}/mozilla/pkcs11-modules/
> > > %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> > > 
> > > lead to errors
> > > 
> > > Directory not found: /builddir/build/BUILDROOT/firefox-pkcs11-
> > > loader-
> > > 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
> > > File not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
> > > 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-
> > > modules/onepinopenscpkcs11.json
> > 
> > noarch only builds do not have %{_lib} or %{_libdir} defined 
> > 
> 
> Thank you very much, I solved with
> %{cmake} . -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}
> 
> Could you please leave a feedback about the comment I am going to
> attach
> in the spec file?
> 
> # in noarch builds, %%{_libdir} is not defined in cmake, so the
> default
> # installation would try installing for example
> # file onepinopenscpkcs11.json
> # into /usr/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # even if the system architecture is 64bit. This will lead to errors
> because
> # the %%files entry
> # %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # would be defined as
> # /usr/lib64/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # that is different from the previous one

so the content should always be in /usr/lib for a noarch build as it
has to work for cases where _lib is both lib64 and lib  if the content
needs to be in /usr/lib64/mozilla/pkcs11-modules on systems with lib64
as the value for _lib then your content and package needs to be
archful. I am concerned that you are not going to get the outcome you
expect here.


Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Dennis Gilmore]

El mar, 06-03-2018 a las 15:29 +0100, Germano Massullo escribió:
> During package firefox-pkcs11-loader build, the following two spec
> file
> lines
> 
> %dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
> %_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> and also this variant
> 
> %dir %{_libdir}/mozilla/pkcs11-modules/
> %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> lead to errors
> 
> Directory not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
> 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
> File not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
> 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-
> modules/onepinopenscpkcs11.json

noarch only builds do not have %{_lib} or %{_libdir} defined 

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Critpath karma

[Dennis Gilmore]

El mar, 06-03-2018 a las 08:48 -0500, Randy Barlow escribió:
> 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?

In the past we required a proven tester to sign off on testing a
critpath package to provide extra assurance that the update worked and
did not break critical functionality. I do not believe that we are
using proven testers any longer. Having some requirements on automated
testing for critpath I think could be useful. I would suggest that we
look at how we could reuse it to a different purpose rather than
throwing it out.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How do you bump fedora-repos-rawhide to f29?

[Dennis Gilmore]

dnf update --relasever=29 distro-sync --disablerepo=* --
enablerepo=rawhide

Dennis
El sáb, 03-03-2018 a las 21:15 +, Philip Kovacs escribió:
> I would settle for knowledge of where the f29/rawhide gpg keys are
> hidden so I import them.
> 
> The "To Rawhide" instructions below are outdated as they direct you
> to a page where the f29/rawhide
> are not presented.
> 
> Upgrading Fedora using package manager - Fedora Project Wiki
> 
>Upgrading Fedora using package manager - Fedora Project
> Wiki   
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Appstream metadata compose failures

[Dennis Gilmore]

El vie, 02-03-2018 a las 11:28 +0100, Kalev Lember escribió:
> Hi,
> 
> hughsie just did a new appstream-data compose for F29 and I noticed
> there's quite a large number of packages failing in the logs:
> 
> https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html
> 
> Would be awesome if maintainers could have a look and see if they can
> make their packages pass!
> 
We were supposed to make builds fail if the appstream metadata failed,
why has that not been done?

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 -> libqpdf.so.21)

[Dennis Gilmore]

El mié, 28-02-2018 a las 12:32 +0100, Ralf Corsepius escribió:
> On 02/28/2018 12:21 PM, Vít Ondruch wrote:
> > 
> > 
> > Dne 28.2.2018 v 12:14 Ralf Corsepius napsal(a):
> > > On 02/27/2018 07:27 PM, Richard Shaw wrote:
> > > > On Tue, Feb 27, 2018 at 12:16 PM, Adam Williamson
> > > > 
> > > > > wrote:
> > > > 
> > > > 
> > > >  Once again, folks, *please* announce your soname bumps,
> > > > and
> > > > co-ordinate
> > > >  rebuilds. (In fact it looks like Zdenek is the maintainer
> > > > of both
> > > >  packages and could have rebuilt cups-filters, but just
> > > > forgot to).
> > > > 
> > > > 
> > > > Is it time to update the packaging guidelines to enforce
> > > > setting a
> > > > "%global sover " and using it in %files?
> > > > 
> > > > If nothing else it should at least be documented as a best
> > > > practice.
> > > 
> > > I would be very opposed to this.
> > > 
> > > Even though some folks want rawhide to appear a release, rawhide
> > > is
> > > not a release. So SONAME breakages are expected to happen in
> > > rawhide
> > > and maintainers supposed to be reacted upon.
> > 
> > Yes, if they notice!
> 
> They - rsp. the maintainers of dependent packages - (usually) will 
> notice very soon, because they'll receive an email notifying them
> about 
> the breakage.

Actually they will not receive any such email currently, the tool that
sends the emails has had sending email turned off because it does not
understand rich and boolean dependencies and was creating a lot of
noise. Announcing is the polite thing to do. It can also help a
maintainer get help, or allow someone to raise concerns. some soname
bumps are handled in side tags because we know that the ABI will break
or a very large amount of packages will be affected. I would like us to
figure out how to deal with soname breakages in a more automated way.
It however needs people to write new tooling to be able to cope with
it, I currently do not have enough cycles to take on doing the work. 
So if someone wants a project to do please come and talk to me about
it.

Dennis



signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Dennis Gilmore]

El mié, 28-02-2018 a las 10:35 +0100, Vít Ondruch escribió:
> Can the logs actually contain timestamps with timezone?
> 
> And was the compose successful today or not. Looking at
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-201
> 80228.n.0/logs/global/pungi.global.log
> 
> it probably was, but it is not obvious from the log.
> 
the status of the compose can always be found in the STATUS file of the
root of the compose https://kojipkgs.fedoraproject.org/compose/rawhide/
Fedora-Rawhide-20180228.n.0/STATUS is todays for instance

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F29 System Wide Change: Remove GCC from BuildRoot

[Dennis Gilmore]

El lun, 19-02-2018 a las 10:56 +0100, Vít Ondruch escribió:
> 
> 
> Dne 19.2.2018 v 00:52 Dennis Gilmore napsal(a):
> > El vie, 16-02-2018 a las 12:56 +0100, Jan Kurik escribió:
> > > Proposed System Wide Change: Remove GCC from BuildRoot
> > > https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> > > 
> > > 
> > > Owner(s):
> > >   * Igor Gnatenko 
> > > 
> > > 
> > > Removing gcc and gcc-c++ from default buildroot in Koji and mock.
> > > 
> > > 
> > > 
> > > == Detailed description ==
> > > Since beginning of Fedora, gcc (and gcc-c++) are installed in
> > > every
> > > buildroot. Times have changed and nowadays many of packages are
> > > not
> > > written in C/C++, they are written in Python, Ruby, Node.js, Go,
> > > Rust,
> > > OCaml, Perl and so on so they don't need to have C/C++ compiler.
> > > Installing gcc and gcc-c++ takes time so if we remove it, we can
> > > improve build times for many of the packages.
> > 
> > What is the expected savinsg in time for builds?
>  
> It depends who is your target audience. These were the numbers for me
> last time we discussed this specific question:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/message/LWC5L53CD2BLJKSF2XXZ4D57MS2WXEJL/
> 
> 
> BTW it is interesting, that although Perl was removed since the last
> time, the minimal buildroot is bigger than it used to be and it takes
> longer to install then it used to:
> 
> Install  171 Packages
> 
> Total download size: 128 M
> Installed size: 494 M
> 
> real1m17,327s
> user0m55,004s
> sys0m6,176s

redhat-rpm-config taht is needed has grown dependencies, as language
specifc macros have moved into their own space

> 
> 
> 
> V.
> 
> >  I realise it is hard
> > to measure, however it should only be a second or two per build at
> > most. Buildroot creation time is really not the slowest piece of
> > the
> > pipeline. There is a lot of other areas that I feel would net a
> > bigger
> > win. For instance machine learning bots to do package reviews and
> > package maintainenece, where changes like this could be
> > automatically
> > built in to the package maintainece lifecycle.

None of that addresses the questions, is this really a worthwhile use
of time,  are we not better off investing in automated management of
package maintainence and lifecycle rather than minor tweaks to existing
   process and fixing subjective time consuming things. If we automated
80% of the basic lifecycle tasks will we not all be better off and have
time to work on things we find much more interesting?

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F29 System Wide Change: Remove GCC from BuildRoot

[Dennis Gilmore]

El vie, 16-02-2018 a las 12:56 +0100, Jan Kurik escribió:
> Proposed System Wide Change: Remove GCC from BuildRoot
> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> 
> 
> Owner(s):
>   * Igor Gnatenko 
> 
> 
> Removing gcc and gcc-c++ from default buildroot in Koji and mock.
> 
> 
> 
> == Detailed description ==
> Since beginning of Fedora, gcc (and gcc-c++) are installed in every
> buildroot. Times have changed and nowadays many of packages are not
> written in C/C++, they are written in Python, Ruby, Node.js, Go,
> Rust,
> OCaml, Perl and so on so they don't need to have C/C++ compiler.
> Installing gcc and gcc-c++ takes time so if we remove it, we can
> improve build times for many of the packages.

What is the expected savinsg in time for builds? I realise it is hard
to measure, however it should only be a second or two per build at
most. Buildroot creation time is really not the slowest piece of the
pipeline. There is a lot of other areas that I feel would net a bigger
win. For instance machine learning bots to do package reviews and
package maintainenece, where changes like this could be automatically
built in to the package maintainece lifecycle.

Dennsi

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Dennis Gilmore]

El jue, 15-02-2018 a las 17:34 -0500, Matthew Miller escribió:
> As shown at https://www.happyassassin.net/nightlies.html, we haven't
> had a successful compose for almost two weeks. AIUI this is mostly
> worked out now, but it raises the question: who should be keeping
> track
> of this and coordinating fixes? For the releases, the blocker bug
> process basically handles this, so functionally the ownership ends up
> with QA (and the various heroes of QA who then track down all the
> problems). For rawhide, we don't have any such thing. Is it rel-eng?
> Is
> it FESCo? Is it the FPgM? Is it QA after all?
> 
> I suspect that right now, the answer is kind of "It's all of us
> together", which unfortunately practically speaking often comes down
> to
> 0.02% per person and rounds down to 0.
> 
> Or if the answer is: "Matthew, you are the FPL. It's you!" … then
> fine,
> but I'm going to then have to find some way to turn around and
> delegate. :)
> 
> I was chatting with Kevin Fenzi and he suggested naming a release
> manager for each release — someone who would keep track of stuff
> starting at branch, and help coordinate things like this.
> 
> This would help with more than just Rawhide — I'm sure everyone
> involved in the blocker bug process would be grateful for more help.
> At
> least, if it was someone who isn't already deeply involved in that.
> I'm
> thinking probably someone selected from FESCo — but it also could be
> a
> way for people with the particular set of skills required here to get
> involved in a way that's different from FESCo membership.
> 
> What do you think?

I think you are putting the cart before the horse slightly here. We
have a few issues that we need to address and that we have to
fundamentally step back and rethink how we put Fedora together. I feel
that your statement makes an assumption that how we do things today is
okay.

A fundamental issue we have today is that we have no way to test the
changes as they come in. As a result we hit apoint right before
branching where people put in a lot of change all at once, with the
result being it breaks things, we then get into fire fighting mode.
Having a project manager to stay on top of changes and change
management and trying to balance the change and get people to submit it
ealier may help some, but it would not fully address the issue of
making sure that the change is good.

I strongly believe that in order to really address the problem we need
to take a step back and look at the factory we have for making Fedora. 
 Today in order to make and ship Fedora we have a process that starts
by gathering by gathering together all of the rpms we have built,
putting them into a place so that we can feed them into making the
anaconda run time. Once we have the anaconda runtime we make the
distribution repos for the rpms and start the ostree creation. we then
create the Cloud images, containers, install dvd's, arm disk images,
livecd's etc. 

The entire process today is configured as a big blob. It requires that
the release engineer configuring the compose understand the end to end
process on how we build and ship everything. What the inputs for each
piece is, the expected outputs, and what pieces are required to make
other pieces. The way we have set things up means that the amount of
knowledge needed to be effecive is massive.  If you compare it to a
more traditional process, say a restaurant, you would have to go and
pick the fruits and vegetables that have been planted by someone else,
plan a extensive menu, answer the phone and take reservations, start
cooking the meals, greet the guest and seat them, take drink orders, go
make and deliver the drinks, take the meal orders, then go cook and
plate the meals, serve them to the guests and refresh drinks, make sure
that everyone is happy, once they are done eating clean the tables, and
take desert orders, go make plate and deliver desert, make any coffee
or tea thats required, deliver to the table, once the table is done,
you generate the bill, take it to the table, collect payment, then
clean up and do all the dishes after, wash the table linens and get
tings ready for the next meal.  If anything goes wrong during this
process that is run by a single person  you get to clean up and start
over from the start. That is a little long winded but shows how we have
not done the best by ourselves in how we have built and designed the
delivery of things today. Restaurants do not work in the way described
by a single person, neither does a car get built by having someone
design then build the car and get it out the door.  It can work for
special boutique offerings, it does not scale well for wide spread
distribution.

I would like to have us look at not only the processes for how we build
and ship the distribution. I have some ideas for how we can keep the
important pieces of how we build and ship things today, but give us the
flexibility to have the peices be more independent and controlled. 
Some 

Re: Mass Rebuild for Fedora 28

[Dennis Gilmore]

El mar, 13-02-2018 a las 20:14 +, Samuel Rakitničan escribió:
> Strange error with camotics:
> 
> Error: 
>  Problem: package cairo-devel-1.15.10-2.fc28.x86_64 requires
> pkgconfig(gobject-2.0), but none of the providers can be installed
>   - conflicting requests
>   - nothing provides /usr/bin//usr/bin/python3 needed by glib2-devel-
> 2.55.2-1.fc28.x86_64

that looks like a packaging bug in glib2

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Mass Rebuild for Fedora 28

[Dennis Gilmore]

Hi All,

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 

Please quickly clean up all build failures as the schedule[5] has us
branching next Tuesday, on the 20th of February and enabling Bodhi on 
the 6th of March, So expect to see a 28 branched compose in about a
week from now.

Many Thanks

Dennis

[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

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Infrastructure manager change

[Dennis Gilmore]

El mié, 17-01-2018 a las 07:00 -0800, Jim Perrin escribió:
> Hello  Fedora developers,
> I know some of you may not be familiar with me[1] unless you’re also
> working with CentOS or EPEL, but I’d like to take this opportunity to
> introduce myself a bit more formally on the list.
> 
> As of 1 February, I’ll be the reporting manager for the Fedora
> Infrastructure Administration team, and the Fedora Infrastructure
> Applications team[2], as well as the CentOS engineering team internal
> to
> Red Hat.  For the most part, this is a Red Hat internal
> organizational
> change that doesn’t really impact anything in the community. Paul
> Frields set a good example of being transparent with the community,
> and
> I want to continue that with this transition. Paul won’t be going too
> far as part of this transition, as he’s taking a promotion of his
> own,
> and I’ll be reporting to him as part of the new structure.
> 
> 
> This is a fantastic group of people, and I’m excited to be working
> with
> them. There will be a bit of transition time as Paul and I work
> through
> the team organization and update the wiki to reflect the changes, but
> you’ll probably be seeing a bit more of me around here.
> You may now return to your regularly scheduled mailing list.
> 
> 1. https://fedoraproject.org/wiki/User:Jperrin
> 2. https://fedoraproject.org/wiki/Fedora_Engineering

Hi Jim,

Nice yto see you on the blue side of the Fence :D I am looking forward
to  seeing how Fedora and CentOS can work better together 

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Building Fedora modules on EL [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Dennis Gilmore]

El jue, 18-01-2018 a las 14:33 -0500, Matthew Miller escribió:
> On Thu, Jan 18, 2018 at 02:09:26PM -0500, Josh Boyer wrote:
> > > Given that Python 2 is going EOL in about two years, I don't
> > > think we
> > > want it in EPEL proper. If we do provide it, it should be in a
> > > module.
> > 
> > You're referring to EPEL > 7, right? 
> 
> For Python, yes.
> 
> >   Also, that last part is kind of
> > a leap in assumption.  Perhaps it's because I'm not up to speed on
> > EPEL plans, but do we have timelines for when/if modules will be
> > created for and available for EPEL?

> It's the plan of record that by default, all modules will be built
> across all available buildroots. I'm not sure if that means EPEL7
> will
> be an available option for technical reasons, but I hope so. This
> will
> possibly require a modular-capable DNF in EPEL proper or in a side-
> repo
> of some sort -- TBD. But if that works, we'll start having modular
> content for EL right along with the F28 release.

If this is something we want to do in that timeline things need to be
getting put in place now. We should have a discssion about what we
would like, what timelines we would do it on, and how it would all look
and work. The DNF and RPM teams probably need to chime in to let us
know what is practical. in order to have it in the F28 timeline we need
to get it enabled in the next 6-8 weeks.

> If not, it'll have to wait for the "higher than 7" RHEL release, but
> should be able to enable module building for that pretty quickly once
> the target OS is available.

What EPEL greater than 7 looks like will be a discussion to be had when
 there is something to build against relased publicly, until we see
what the base looks like we can not determine what EPEL will look like.

> I know that many of us Fedora packagers stay away from EPEL, but at
> least for me, that's largely because I'm not confident about
> committing
> to the long lifecycle, because to keep packages stable I'd have to
> diverge from Fedora, and because rpm abilities lag so much.

This is a big issue, it is a commitment, people have thier own ideas on
what stable and supported in EPEL means. 

> With modules, the first two concerns are handled (because I can
> maintain my modules with whatever commitments I feel comfortable
> with,
> even with an EL target). And at least initially the RPM/DNF
> functionality
> should be on par with modern Fedora.
agreed.

Dennis


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Dennis Gilmore]

The only way to really do this would be to make rpmfusion-release
require it. However that will mean users have to download and install
two packages to make it all work. That may break things for people who
intentionally remove gnome-software and PackageKit 

Dennis

El mar, 16-01-2018 a las 18:08 +, Ankur Sinha escribió:
> Hello,
> 
> We're generating appstream data for rpmfusion packages nowadays to
> enable users to install packages from there using gnome-software and
> friends too.
> 
> Is there a way to automatically pull in the rpmfusion appstream data
> packages? We looked at weak dependencies, specifically backward
> dependencies. So, we added:
> 
> Supplements:appstream-data
> 
> to the rpmfusion appstream data spec files. However, based on my
> understanding of how these things work, this implies that the
> rpmfusion
> appstream data packages are pulled into a transaction only if the
> fedora
> appstream data package is being installed or updated too. Is that
> right?
> 
> If it is, is there a way to pull in rpmfusion appstream data if
> fedora
> appstream data is already installed on the system, and not part of
> the
> current transaction? Any suggestions on how this should be done?
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: AArch64 Server Promotion

[Dennis Gilmore]

El lun, 08-01-2018 a las 09:16 -0800, Adam Williamson escribió:
> 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.
> 
> 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.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2017-12-15)

[Dennis Gilmore]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

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

or run:
  date -d '2017-12-15 16:00 UTC'


Links to all issues below can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1767 F28 Self Contained Changes
.fesco 1767
https://pagure.io/fesco/issue/1767

#topic #1799 The ProvenPackager rubric needs more formality
.fesco 1799
https://pagure.io/fesco/issue/1799

= New business =

#topic #1805 Election Interview Questions
.fesco 1805
https://pagure.io/fesco/issue/1805

#topic #1804 Election Process Clarifications
.fesco 1804
https://pagure.io/fesco/issue/1804

#topic #1803 F28 System Wide Change: Reduce Initial Setup Redundancy
.fesco 1803
https://pagure.io/fesco/issue/1803

#topic #1802 F28 System Wide Change: Switch libcurl to use libssh
instead of libssh2
.fesco 1802
https://pagure.io/fesco/issue/1802

#topic #1800 Election Planning discussion 
.fesco 1800
https://pagure.io/fesco/issue/1800

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: streamlining fedora-release

[Dennis Gilmore]

El mar, 05-12-2017 a las 07:31 +, Zbigniew Jędrzejewski-Szmek
escribió:
> On Mon, Dec 04, 2017 at 12:49:48PM -0600, Dennis Gilmore wrote:
> > El vie, 10-11-2017 a las 09:12 -0500, Neal Gompa escribió:
> > > On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek
> > > <zbys...@in.waw.pl> wrote:
> > > > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote:
> > > > > Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > The fedora-release package contains stuff that is tied to
> > > > > > each
> > > > > > Fedora
> > > > > > version and changes slowly, and it also contains the preset
> > > > > > files for
> > > > > > systemd units, which change fairly often (a few requests
> > > > > > per
> > > > > > month).
> > > > > 
> > > > > Why not have a separate fedora-presets then? Just like
> > > > > fedora-
> > > > > repos was
> > > > > split out from fedora-release several releases ago.
> > > > 
> > > > Well, pfff, no particular reason, at least from my side. Just
> > > > opening
> > > > a new package and going through the (trivial) review, etc., is
> > > > a
> > > > bit
> > > > of up-front effort, and then releasing updates for two packages
> > > > is
> > > > always a bit more effort then for one. So instead, I'd want a
> > > > good
> > > > reason
> > > > to make another package and how that is going to solve
> > > > something.
> > > > So far I
> > > > haven't seen anything except some hypothetical issues.
> > > 
> > > This would allow us to deduplicate the presets shipped in
> > > generic-release and fedora-release, wouldn't it?
> > 
> > We do not keep them in sync between fedora-release and generic-
> > release
> > this is because generic-release is there just to provide an example
> > of
> > how you would setup a -release package for a custom forked OS. it
> > is
> > not intended to be a complete drop in for fedora-release.
> 
> It might be still worth doing, just to avoid the duplication.
> 
> Anyway, any thoughts on the major parts of my proposal?

I am not opposed to it. I would however like to see a test suite built
up. we have had too many changes that are well intentioned that have
caused major breakages and bugs. So if it came along with the start of
a test suite then sure. The spec itself will need changes to not use a
tarball anymore, I would like to just use the exploded tree all managed
in dist-git than have an awkward set of steps to upload the tarball
that is made from the same location.

Dennis

> Zbyszek
> 
> > > And as long has it has a "system-presets" Provides, downstream
> > > folks
> > > can swap them easily enough.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: streamlining fedora-release

[Dennis Gilmore]

El vie, 10-11-2017 a las 09:12 -0500, Neal Gompa escribió:
> On Fri, Nov 10, 2017 at 9:04 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Fri, Nov 10, 2017 at 02:45:26PM +0100, Kevin Kofler wrote:
> > > Zbigniew Jędrzejewski-Szmek wrote:
> > > > The fedora-release package contains stuff that is tied to each
> > > > Fedora
> > > > version and changes slowly, and it also contains the preset
> > > > files for
> > > > systemd units, which change fairly often (a few requests per
> > > > month).
> > > 
> > > Why not have a separate fedora-presets then? Just like fedora-
> > > repos was
> > > split out from fedora-release several releases ago.
> > 
> > Well, pfff, no particular reason, at least from my side. Just
> > opening
> > a new package and going through the (trivial) review, etc., is a
> > bit
> > of up-front effort, and then releasing updates for two packages is
> > always a bit more effort then for one. So instead, I'd want a good
> > reason
> > to make another package and how that is going to solve something.
> > So far I
> > haven't seen anything except some hypothetical issues.
> 
> This would allow us to deduplicate the presets shipped in
> generic-release and fedora-release, wouldn't it?

We do not keep them in sync between fedora-release and generic-release
this is because generic-release is there just to provide an example of
how you would setup a -release package for a custom forked OS. it is
not intended to be a complete drop in for fedora-release.

Dennis


> And as long has it has a "system-presets" Provides, downstream folks
> can swap them easily enough.
> 
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26/F27 updates-testing and multilib problems

[Dennis Gilmore]

El dom, 22-10-2017 a las 11:39 -0400, Randy Barlow escribió:
> On 10/22/2017 09:04 AM, Dennis Gilmore wrote:
> > updates does not have composes it has mashes, the behaviour is
> > expected
> > to be different, the problem boils down to the fact that if a
> > package
> > is made multilib indirectly, i.e. it is only pulled in because some
> > external package that is multilib requires it, it will only be
> > multilib
> > in updates or updates-testing if the package requiring it is also
> > in
> > the same repo.
> 
> Hi Dennis!
> 
> Since Bodhi is planning to switch to using Pungi instead of mash to
> generate its repositories "very soon" (potentially as early as
> Tuesday
> this week if testing and FBRs go well), do you think that will help
> resolve this discrepancy?
completely unkown at this point of time

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26/F27 updates-testing and multilib problems

[Dennis Gilmore]

El jue, 19-10-2017 a las 19:29 +0200, Florian Weimer escribió:
> On 10/19/2017 06:42 PM, Dennis Gilmore wrote:
> 
> > There is long standing 8+ year old bugs we have never gotten around
> > to
> > to ensure multilib is correct in all cases. It is unfortuantly
> > expected
> > sometimes, it probably has happened a lot over the yearsm, but
> > since
> > defaulting to turning off installing multilib by default we have
> > not
> > had and issues filed in years, until you asked earlier this year.
> > we
> > may be able to resolve the issues with the move to use pungi for
> > updates pushes rather than mashing the repos.
> 
> I'm not sure if it's the same bug.  Based on the reports, it feels
> like 
> as if every other compose is broken.  Either we have been
> exceedingly 
> unlucky the past week or so, or we're hitting some new issue.
> 
> Thanks,
> Florian
Florian,

updates does not have composes it has mashes, the behaviour is expected
to be different, the problem boils down to the fact that if a package
is made multilib indirectly, i.e. it is only pulled in because some
external package that is multilib requires it, it will only be multilib
in updates or updates-testing if the package requiring it is also in
the same repo. the way we make the updates and updates-testing repos
make the repo and does multilib in isolation, without any consideration
 for what was multilib in the base repo, as it has no knowledge it even
exits,  we have had a bug open for ~8 years to fix and until this year
when you raised an issue about it had not had any reports of issues
since we defaulted to not installing multilib by default.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26/F27 updates-testing and multilib problems

[Dennis Gilmore]

El lun, 16-10-2017 a las 18:06 +0200, Florian Weimer escribió:
> Are there currently bugs in composes for x86-64 for F26/F27?  We had
> one 
> case for F27 where the compose was demonstrably broken because it
> lacked 
> a required multilib:
> 
>https://pagure.io/releng/issue/7071
> 
> We received a report on an issue which looks similar, this time on
> F26:
> 
>https://bodhi.fedoraproject.org/updates/glibc-2.25-12.fc26#comment
> -676598
> 
> This time, glibc-headers-2.25-12.fc26.i686.rpm seems to be missing.
> 
> Any ideas what is going on here?
> 
> I'm not aware of doing anything wrong in the glibc package.
> 
> Thanks,
> Florian

There is long standing 8+ year old bugs we have never gotten around to
to ensure multilib is correct in all cases. It is unfortuantly expected
sometimes, it probably has happened a lot over the yearsm, but since
defaulting to turning off installing multilib by default we have not
had and issues filed in years, until you asked earlier this year. we
may be able to resolve the issues with the move to use pungi for
updates pushes rather than mashing the repos.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide packages not getting pushed?

[Dennis Gilmore]

El jue, 21-09-2017 a las 07:29 +0200, Florian Weimer escribió:
> On 09/20/2017 10:16 PM, Peter Robinson wrote:
> > There was a signing issue. This is seen by the fact it was tagged
> > into
> > f28-pending. There's a few reasons this might happen, and depending
> > on
> > what it is the quickest way for anyone to fix this themselves is to
> > try and untag/retag it to  -pending and it should move to f28 in a
> > few
> > minutes, if not open a rel-eng ticket.
> 
> Is tagging and untagging builds really available to Fedora developers
> in 
> general?  The last time I tried it, I got a permission error.
> 
> Thanks,
> Florian

It is in the -pending tags, you need to be in Release Engineering to
untag from f28. 

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

Re: Kernel 4.13 rebase plans

[Dennis Gilmore]

El vie, 22-09-2017 a las 15:25 -0500, Michael Catanzaro escribió:
> On Fri, Sep 22, 2017 at 2:21 PM, Chris Adams 
> wrote:
> > On what grounds?  There is nothing in the Fedora guidelines that
> > makes
> > package maintainers beholden to third-party (by definition, not
> > part 
> > of
> > Fedora) repos.  There's nothing for FESCo to vote on, unless you
> > are
> > going to propose that change.
> 
> OK, I'll bite. The grounds are that FESCo has granted the WG full 
> control over the Workstation product, and the kernel package is part
> of 
> that product. Although I can't speak for the entire WG today, I
> would 
> be fairly astounded if the WG were to choose to allow kernel updates
> to 
> break Negativo users after having identified Negativo as a strategic 
> priority and advertised it as supported. So if a kernel update goes
> out 
> that breaks Negativo users, I would expect a policy to delay future 
> kernel upgrades until Negativo has been tested and confirmed to be 
> working. Since that would be controversial, someone would surely
> appeal 
> to FESCo. Probably easier for everyone to take it straight to FESCo, 
> right?
> 
> But again, if there is already a technical solution (a fallback to 
> noveau) in place and working, as I suspect (would be really nice if 
> somebody could confirm that!) then it doesn't matter.
> 
> Michael

Just catching up on email, There is no such thing as a WG post GA, we
ship and support a single stream of updates for all products, editions
and spins. The only way that the WG could stop or control any update
for a package not owned by the WG is to provide enough negative karma
to an update in Bodhi to force it to not be ppushable. I would really
hope that people would not do that to keep updates out, and would
instead have a open honest discussion to try figure out a acceptable
path forward.  Any change to how we do updates would require
significant changes in many parts of how we manage the ditro and update
process. It would need discussions with Release Engineering and
Infrastructre, that came with resources to support the work.


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

Re: Is it possible to upload new sources of a package from a URL?

[Dennis Gilmore]

El mar, 26-09-2017 a las 01:49 +0330, Hedayat Vatankhah escribió:
> /*Pierre-yves Chibon*/ wrote on Mon, 25 Sep 2017 09:38:39 +0200:
> > On Sun, Sep 24, 2017 at 10:56:45AM +0330, Hedayat Vatankhah wrote:
> > > Dear all,
> > > Currently, AFAIK, the suggested method to upload new sources for
> > > a package
> > > is using 'fedpkg new-sources' which uploads new sources from your
> > > local
> > > system. I wonder if there is a method to upload new sources from
> > > a URL
> > > rather than your local filesystem? It is specially useful for
> > > large
> > > packages.
> > 
> > It's an interesting idea but then it would become quite hard to
> > check if there
> > is a mitm attack of some sort. With the current process, at least
> > the packager
> > has the possibility to check the sources locally before uploading
> > them into
> > Fedora.
> > The solution would be to provide the sha + the url and let the down
> > be server
> > side but that won't save you from downloading the sources locally
> > first.
> 
> Yes, but even if I'm forced to download locally, it is much better
> than 
> being forced to upload it again. (Also, note that the current
> process 
> doesn't prevent MITM if it happens when I download the source).
> Also, it is easier to schedule the download for a time when it is 
> cheaper (or free), but it'd be harder to do it for an upload since
> it 
> requires authentication.
It does if you go to the effort to fully verify the sources. Which is a
task that you are supposed to do. We have always rulled out pulling
down the sources from random machines on the internet due to not being
able to validate that the sources are correct or as intended. 

> I wonder where I can fill an RFE for this feature. The current
> situation 
> is a blocker for people like me to maintain any package with large 
> source/data archives. I saw COPR supports a similar thing, and I
> hope 
> Fedora will support it too.
It would take a lot of effort to ensure that what we get is what is
intended and can be trusted. Today We rely on you as a packager
verifying the sources, and by uploading them directly you are saying
this is really what I intended to send you and I have ensured that it
is good.  You would need to work with release engineering and
infrastucture to come up with some way to sign off on the code being
used.

Given that many times the big tarballs actually only have a small
amount of change. using exploded sources or making the copy in dist-git 
being a mirror of the upstream SCM could work better. maybe we could
make a new namespace for the upstream code mirror. then we could make
tarballs from a given commit.

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

Re: Splitting AppStream data into Workstation/Server

[Dennis Gilmore]

El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió:
> On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes <hughsi...@gmail.com>
> wrote:
> > On 4 September 2017 at 17:15, Dennis Gilmore <den...@ausil.us>
> > wrote:
> > > The correct way to deal with appstream is to add the appstream
> > > data to
> > > rpm headers and then teach createrepo to make the appropriate
> > > metadata
> > > files.
> > 
> > I'm sure we've had this discussion before, but:
> > 
> > * What happens if a single package contains two desktop files?
> > * Would we embed a 32bit color 128x128 icon in the rpm header (10kb
> > per app)?
> > * Would we embed all the translations in the appdata file, or just
> > the
> > entire appdata file (92kb per app)?
> > * Would we include the entire .desktop file and all the
> > translations there too?
> > 
> > > you would then have appropriate appdata in the server,
> > > workstation etc repos
> > 
> > We'd have larger rpms for no end-user gain. The metadata just has
> > to
> > exist long enough to be collected into one large AppStream file
> > (and
> > included in the metadata repomd. I see no gain whatsoever for
> > distributing the single-package appstream metadata as part of the
> > package download or included in the rpmdb. It's just a workaround,
> > just the same as running appstream-builder+modifyrepo on a tree of
> > built rpms is.
> > 
> 
> It sounds like it would make more sense for createrepo_c to link to
> the AppStream builder library to handle AppStream metadata processing
> as part of the createrepo_c repodata generation, wouldn't it? Then it
> accomplishes the same goal without bloating the rpm headers with more
> things that don't make sense in there.
It would not be a good way to do things, the expensive bit is extacting
and manageing the appdata info. that is super expensive and comes with
other costs.  we currently use createrepo_c for GA releases and the old
createrepo for updates. There has to be a way to easily extract the
data without having to reach into the belly of the rpm payload. The
soultion we use needs to work for anyone making repos and not be tied
in anyway to a specific implementation of how we build ship and manage
the software lifecycle.

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

Re: Splitting AppStream data into Workstation/Server

[Dennis Gilmore]

El lun, 04-09-2017 a las 17:33 +0100, Richard Hughes escribió:
> On 4 September 2017 at 17:15, Dennis Gilmore <den...@ausil.us> wrote:
> > The correct way to deal with appstream is to add the appstream data
> > to
> > rpm headers and then teach createrepo to make the appropriate
> > metadata
> > files.
> 
> I'm sure we've had this discussion before, but:
We have had this discussion about 3 or 4 times.

> * What happens if a single package contains two desktop files?
both end up in the headers,
> * Would we embed a 32bit color 128x128 icon in the rpm header (10kb
> per app)?
we would have to, there is simply no sane way to extract and manage
things from inside the rpms. the appdata being agnostic is great, but
there has to be a technology specific way to manage the data without
expensive overhead

> * Would we embed all the translations in the appdata file, or just
> the
> entire appdata file (92kb per app)?
> * Would we include the entire .desktop file and all the translations
> there too?
> 
> > you would then have appropriate appdata in the server,
> > workstation etc repos
> 
> We'd have larger rpms for no end-user gain. The metadata just has to
> exist long enough to be collected into one large AppStream file (and
> included in the metadata repomd. I see no gain whatsoever for
> distributing the single-package appstream metadata as part of the
> package download or included in the rpmdb. It's just a workaround,
> just the same as running appstream-builder+modifyrepo on a tree of
> built rpms is.

we would have a end user gain, they would get consistent updated
correct data all the time.

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

Re: Splitting AppStream data into Workstation/Server

[Dennis Gilmore]

El vie, 01-09-2017 a las 13:37 +0300, Marius Vollmer escribió:
> Hi,
> 
> I hope that soon the first Cockpit add-on appears in the Fedora
> repositories.  Cockpit can find such add-ons via their AppStream
> metainfo data, similar to how GNOME Software finds applications to
> install for a desktop environment.
> 
> Thus, we would need to install the appstream-data package also on a
> Server.
> 
> This is a good enough first step, I guess, but appstream-data is
> quite
> big and mostly useless on a Server.  We don't need to know about all
> the
> desktop applications and their icons.
> 
> 
> So, what about creating a dedicated appstream-data-server package
> that
> carries only those components that we want to see on a Server?
> 
> Initially, it would contain only components of type "addon" that
> extend
> "cockpit.desktop", and components of type "service".
> 
The correct way to deal with appstream is to add the appstream data to
rpm headers and then teach createrepo to make the appropriate metadata
files. you would then have appropriate appdata in the server,
workstation etc repos, with per module repos you could have
apppropriately limited repos or we cwould need to make changes to
mirrormanager, how we build and ship updates, and limit users to
appropriate Server etc repos. the hack of how we build and ship it
today works but has a lot of issues with Race conditions etc.

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

Re: RFC: retiring yum

[Dennis Gilmore]

El vie, 01-09-2017 a las 21:19 +0200, Igor Gnatenko escribió:
> On Fri, 2017-09-01 at 13:56 -0400, Neal Gompa wrote:
> > On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
> >  wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > > 
> > > So I think F28/F29 would be best time for retiring YUM. Right now
> > > DNF
> > > should be already stable and provide same capabilities (or
> > > documented
> > > that something will not be supported).
> > > 
> > > Hopefully infrastructure / rel-eng folks will finally add support
> > > for
> > > rich dependencies[0] which would mean that yum will not work in
> > > Fedora
> > > anyway, so..
> > > 
> > > Do you still have some critical missing functionality in DNF? And
> > > let
> > > us know reasons why would you like to keep YUM available
> > > (hopefully
> > > there are no)!
> > > 
> > 
> > There is still one thing I've noticed we're missing: API and CLI
> > for
> > getting package changelogs[1]. This exists in yum but doesn't in
> > dnf.
> 
> While I agree that this is missing functionality, being honest I
> think
> we should educate users to use updateinfo which is meant for users
> while changelogs might be interested only for developers. Updateinfo
> is
> coming from what is written in bodhi.
> > 
> > In addition, don't we still need yum in the repositories for mock
> > to
> > target EL6 and EL7 for EPEL?
> 
> I don't think so, but better to ask developers of mock.

yes we do need yum to be around until RHEL 7 goes EOL

Dennis

> > [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1066867 (CLI RFEs
> > are
> > blocked by this bug)
> > 
> > 
> > 
> > -- 
> > 真実はいつも一つ！/ Always, there's only one truth!
> > ___
> > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Dennis Gilmore]

El mar, 15-08-2017 a las 22:37 +0200, Jan Kurik escribió:
> On Tue, Aug 15, 2017 at 10:22 PM, Dennis Gilmore <den...@ausil.us>
> wrote:
> > El mar, 15-08-2017 a las 12:36 +0200, Kevin Kofler escribió:
> > > Jan Kurik wrote:
> > > >   # votes |  name
> > > > - +--
> > > >  505  | Justin W. Flory (jwf / jflory7)
> > > > - +--
> > > 
> > > No wonder, he is the only candidate who bothered filling out the
> > > questionnaire. It shows that answering voters' questions helps.
> > > (Though I
> > > personally did not vote for him because the answers were not even
> > > close to
> > > what I wanted to hear.) May this be a lesson for future
> > > candidates!
> > > 
> > > Kevin Kofler
> > 
> > What questionnaire? I was not asked to fill one out, I would have
> > done
> > so if asked.
> 
> It was the one sent to you by Justin with subject "[Fedora elections]
> ausil: Your Council interview template".
okay, must have been when I had mail server issues the other week as I
do not have it that I can find. No biggie, Justin is doing good work in
Fedora and I am possitive that he will do an excellent job

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Dennis Gilmore]

El mar, 15-08-2017 a las 12:36 +0200, Kevin Kofler escribió:
> Jan Kurik wrote:
> >   # votes |  name
> > - +--
> >  505  | Justin W. Flory (jwf / jflory7)
> > - +--
> 
> No wonder, he is the only candidate who bothered filling out the 
> questionnaire. It shows that answering voters' questions helps.
> (Though I 
> personally did not vote for him because the answers were not even
> close to 
> what I wanted to hear.) May this be a lesson for future candidates!
> 
> Kevin Kofler
What questionnaire? I was not asked to fill one out, I would have done
so if asked.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass rebuilds update

[Dennis Gilmore]

El lun, 07-08-2017 a las 16:35 +, Zbigniew Jędrzejewski-Szmek
escribió:
> On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote:
> > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.ht
> > ml
> > [4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-fa
> > ilur
> > es.html
> 
> Will the up-to-date status be tracked somehow?
> 
The script that updates them is being run in screen in a while true
loop sleeping for 600 seconds between runs. so yes, they will be
updated.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass rebuilds update

[Dennis Gilmore]

El lun, 07-08-2017 a las 10:50 -0400, Matthew Miller escribió:
> On Mon, Aug 07, 2017 at 09:35:46AM -0500, Dennis Gilmore wrote:
> > We have now completed two mass rebuilds, The first one was the
> > scheduled mass rebuild for Fedora 27 details are here[1] the second
> > one
> > was all archful packages due to the binutils bug[2] on ppc64le. The
> > failures pages for the two rebuilds can be found here[3] and
> > here[4]
> 
> How should we read these two lists? Do we need to check both, or does
> one supercede the other?

If your package is a noarch only package, you should read the first
list, if your package is archful you should look for it in the second
list. It is all a tad messy.

Dennis


> > Please quickly clean up all build failures as the schedule[5] has
> > us
> > branching next Tuesday, August the 15th and enabling Bodhi  on
> > August
> > the 29th, So expect to see a 27 branched compose in about a week
> > from
> > now.
> 
> Cool!
> 
> -- 
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: debuginfo repository matching f27-build

[Dennis Gilmore]

El lun, 07-08-2017 a las 10:00 +0100, Peter Robinson escribió:
> On Mon, Aug 7, 2017 at 9:53 AM, Florian Weimer 
> wrote:
> > On 08/01/2017 08:42 AM, den...@ausil.us wrote:
> > > There is no debug repos for the buildroot repos.
> > 
> > Can we fix this, please?  Or offer a tool like “dnf debuginfo-
> > install”
> > that gets the debuginfo directly from Koji, without a need for a
> > repository?
> 
> Probably best to file a rel-eng ticket requesting it, reuquests/RFEs
> tend to get lost on lists

It will need an upstream koji change to do. Best to file it there.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Mass rebuilds update

[Dennis Gilmore]

Hi All,

We have now completed two mass rebuilds, The first one was the
scheduled mass rebuild for Fedora 27 details are here[1] the second one
was all archful packages due to the binutils bug[2] on ppc64le. The
failures pages for the two rebuilds can be found here[3] and here[4]

Please quickly clean up all build failures as the schedule[5] has us
branching next Tuesday, August the 15th and enabling Bodhi  on August
the 29th, So expect to see a 27 branched compose in about a week from
now.

Many Thanks

Dennis

[1] https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
[2] https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
[3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html
[4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-failur
es.html
[5] https://fedoraproject.org/wiki/Releases/27/Schedule

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Mass rebuilds update

[Dennis Gilmore]

Hi All,

We have now completed two mass rebuilds, The first one was the
scheduled mass rebuild for Fedora 27 details are here[1] the second one
was all archful packages due to the binutils bug[2] on ppc64le. The
failures pages for the two rebuilds can be found here[3] and here[4]

Please quickly clean up all build failures as the schedule[5] has us
branching next Tuesday, August the 15th and enabling Bodhi  on August
the 29th, So expect to see a 27 branched compose in about a week from
now.

Many Thanks

Dennis

[1] https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
[2] https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
[3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html
[4] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-binutils-failur
es.html
[5] https://fedoraproject.org/wiki/Releases/27/Schedule

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Dennis Gilmore]

El mar, 01-08-2017 a las 08:26 +0100, Michael Catanzaro escribió:
> Keep in mind that GNOME Software already only checks for non-security 
> updates weekly. So it will actually take as much as two weeks for the
> update to reach users once it enters batched, which I suspect may not
> have been intended. We are really looking at weekly updates with an
> additional one-week delay. Probably you were intending to implement
> weekly updates without that delay, which seems more desirable? If so,
> coordination with the Software developers will be needed.
> 
> Also, if I mark a security update as low priority, that means it
> really is low priority. There's no need for many security updates to
> skip batched. Many are e.g. minor DoS vulnerabilities that are
> unlikely to be exploited ever, let alone in the next two weeks. Of
> course remote code execution problems should probably skip batched,
> but those are unlikely to be marked as low priority. ;)
> 
> Michael

gnome-software really should follow what we ship, in what you describe
we have the potential of making some parts worse for users. because
there is a non null probability that users will lose the ability to
install deltarpms.  I would really like to see us have a single unified
view on update management at a distro level and not having different
tools implementing their own behaviours.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Dennis Gilmore]

El mar, 11-07-2017 a las 16:03 -0500, Justin Forbes escribió:
> 
> The kernel team quit "supporting" i686 several releases ago, it is
> down to community support, which is pretty much nonexistent.  Sure,
> people file bugs, but rarely do people point to or supply patches for
> those bugs.   The biggest issue is how much it is ignored by upstream
> as well. We have issues where things were never tested on i686, and
> then have to be fixed before we can release necessary and relevant
> updates which impact everyone else.   And discontinuing the i686
> build
> for F27 would still mean over a year left of supported Fedora on i686
> hardware.
> When looking at those check ins, it would also be interesting to note
> which of those are running on virt or containers. Containers would
> still be possible, and 32bit userspace in virt guests with a 64bit
> kernel would still be possible. The kernel header package would still
> be built, so all other 32bit i686 packages would continue to build
> and
> work just fine.
> 
> Justin

For the record, the tooling to make base container images requires a
running kernelof the given arch, and we currently have never attempted
to make offical 32 bit x86 containers. so any container usage for i686
is done out in the ethers by people who care about it. we also stopped
making 32 bit cloud images a few years back. slowly the 32 bit x86
deliverables have been going away.  If the kernel was removed, the only
deliverable we could do given current tooling, workflows and
requirements would be an everything repo.


Last time I tried to run a 32 bit userland with a 64 bit kernel yum at
the time did not support the setup at all. I am not sure how much work
would be needed to make things work correctly using a 32 bit userland
and 64 bit kernel. Most of the support for that was removed when SPARC
support was yanked from the tooling. So it is possible, it would
require a significant investment in tooling, dnf, release tool chain
updates. Given what is currently on release engineering plates its not
work that could be accepted for us to do. Someone would have to
volunteer to work with us to do the work and get the changes
implemented. 

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: No More i686 Kernels

[Dennis Gilmore]

El jue, 13-07-2017 a las 11:53 +0200, Florian Weimer escribió:
> On 07/13/2017 11:40 AM, Dennis Gilmore wrote:
> > This is 100% a system wide change, the releng issue linked does not
> > exist, however not having a kernel will mean that we have to stop
> > making everything for 32 bit x86. The only thing we could do is
> > make 32 bot x86 containers, which is something we do not do at all
> > today.
> 
> I don't understand.  We already build i686 packages in chroots on
> x86-64
> hosts running a 64-bit kernel.
> 
> Here's an example:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=20482941
> 
> uname in the build log is:
> 
> Linux buildhw-09.phx2.fedoraproject.org 4.11.5-200.fc25.x86_64 #1 SMP
> Wed Jun 14 17:17:29 UTC 2017 i686 i686 i386 GNU/Linux
> 
> I think this means it's a 64-bit kernel package, and someone just ran
> setarch to change the uname output.
> 

We have not ran 32 bit harware or installations on the builders in over
10 years. we build in chroot's made and managed by mock. and we are
looking at moving to using systemd-nspawn. Waht I was talking about is
end user deliverables. we currently are not making 32 bit x86 container
base images, the tooling that makes them(imagefactory) requires a
anaconda install tree so that a vm can be booted to install the
contents for the image. There is a difference in what and how we build
and what and how we ship things. 

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

Re: F27 Self Contained Change: No More i686 Kernels

[Dennis Gilmore]

This is 100% a system wide change, the releng issue linked does not exist, 
however not having a kernel will mean that we have to stop making everything 
for 32 bit x86. The only thing we could do is make 32 bot x86 containers, which 
is something we do not do at all today.  It makes me want to look at changing 
up some of the build processes as most 32 bit x86_64 builds will never ship. 
The only content readily available would be what is multilib. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: Decouple system java setting from java command setting

[Dennis Gilmore]

I would like to see some details on how this is going to be
implemented.

It all seem very vague and handwavy

El jue, 08-06-2017 a las 15:55 +0200, Jan Kurik escribió:
> = Proposed Self Contained Change: Decouple system java setting from
> java command setting =
> https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_f
> rom_java_command_setting
> 
> Change owner(s):
> * Michael Simacek 
> * Mikolaj Izdebski 
> 
> Alternatives can be used to specify which Java installation should be
> the default for the system. Currently, changing the default java
> command causes not only a change to the /usr/bin/java symlink, but
> also affects the which runtime is used for system installed Java
> applications. We propose introduction of separate setting for
> system-wide java applications.
> 
> 
> == Detailed Description ==
> Fedora allows parallel installation of multiple Java runtime
> environments and it uses alternatives mechanism to allow the user to
> switch between them. JDK packages provide a set of alternatives
> symlinks for it's executables. The java symlink is used to determine
> the java command (/usr/bin/java), but also determines which runtime
> environment is used to run system-wide Java applications installed
> from RPMs, such as maven or eclipse. While in theory different Java
> runtime environments are drop-in replacements for each other, in
> practice some of the applications may stop working properly. Users
> usually install alternative JDKs in order to run their own
> applications and don't expect that changing the java command will
> have
> effect on the system applications. By introducing a separate setting
> for system-wide java, we would avoid this problem. We propose
> specifying default Java runtime for RPM-managed applications in
> /etc/java/java.conf (this is already possible, but not currently
> used). Administrators would still be able to override the system
> default if they need to.
> 
> 
> == Scope ==
> * Proposal owners:
> Adjust javapackages-tools to provide default Java setting in
> /etc/java/java.conf
> 
> * Other developers:
> N/A (not a System Wide Change)
> 
> * Release engineering:
> https://pagure.io/releng/issue/6831
> 
> * List of deliverables:
> N/A (not a System Wide Change)
> 
> * Policies and guidelines:
> N/A (not a System Wide Change)
> 
> * Trademark approval:
> N/A (not needed for this Change)
> -- 
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The future of the packager group for dist-git

[Dennis Gilmore]

El dom, 04-06-2017 a las 08:52 +0200, Pierre-Yves Chibon escribió:
> On Sat, Jun 03, 2017 at 01:31:50PM +0100, James Hogarth wrote:
> >On 3 Jun 2017 8:33 am, "Pierre-Yves Chibon"  > > wrote:
> > 
> >I think to abandon the packager group for non-scratch builds
> > would be a
> >mistake.
> >The sponsorship to packager status is an important part of
> > ensuring that
> >those joining the community are aware of the guidelines so they
> > are more
> >able to follow the guidelines when updating a spec.
> >I think this would be less of an issue if koji required the
> > packager group
> >(and not just an acl check of the package) to build the non-
> > scratch
> >packages.
> 
> So iirc, there is a cron script that sync from pkgdb to koji the list
> of users
> allowed to do non-scratch builds. This script has already been ported
> from pkgdb
> to pagure, if we could tweak it so that it syncs not only the person
> with commit
> access to the project and member of the packager group, I think we
> would obtain
> the desired behaviour.
> 
What you describe is simply not possible in koji

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org