Re: Golang bundled() Provides generator

[Dan Čermák]

Hi Maxwell & Go SIG,

we have recently started working on introducing a bundled() provides
generator for golang in openSUSE and found a very simple solution using
the output of `go version -m /path/to/binary` [1]

The solution is of course only that simple, because we build more or
less all go binaries with vendored dependencies and hence we do not need
to distinguish between those build with vendored and those build
without.

As I would like to align the Fedora and openSUSE go packaging closer
together and hence, if possible, find a solution to use this generator
for both Fedora and openSUSE. I think it is a bit simpler and does not
require to ship the modules.txt in the final rpm. However, I see that
both are rather weak reasons.

Do you see a way how we can find a common solution? E.g. by having a
macro %go_enable_bundled_provides that would set an environment variable
and enable the bundled generator?


Cheers,

Dan

Footnotes:
[1]  https://github.com/dcermak/golang-packaging/blob/master/golang.prov
--
___
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: An update on RHEL moving to issues.redhat.com

[Dan Čermák]

Ondřej Budai  writes:

> What about hosted Gitea from gitea.com?
>
> Gitea is fully open source, very popular in the self-hosting community and
> their hosted offering would free up some of our precious infra team
> resources.

Gitea is ok from a UX perspective but it is still quite lacking from an
integration point of view. Also, I have found it's API to have a few odd
quirks after working with it for quite some time at $dayjob. Maybe it'll
get there in another year or two, if it gets at least *some* corporate
backing.


Cheers,

Dan
___
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: Macros in side-tag

[Dan Čermák]

Hi Vít,

Vít Ondruch  writes:

> Hi,
>
> Koji has grown new functionality to enable setting macros in side-tag:
>
> https://pagure.io/releng/issue/11254
>
> I have asked FeSCo to approve to use them:
>
> https://pagure.io/fesco/issue/3046
>
> My immediate use case is to improve the package bootstrapping
> experience.

This is great news, thank you for working on this!

Although I personally have no immediate use for this, I believe this
could be of great help for release-engineering and packagers performing
large scale experiments. Setting macros in side-tags gives is one of the
key features that the open build service provides via the so-called
project-config. This would allow simpler experimentation to globally
toggle build flags, build options or develop new macros entirely
(although COPR might be a better fit in a few instances).


Cheers,

Dan
___
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: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

[Dan Čermák]

Hi,

Aoife Moloney  writes:

> https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault
>
*snip*
>
> == Detailed Description ==
>
> Firmware for hardware devices can have bugs and firmware updates
> generally help address those. Firmware updates might however need
> manual interaction, a reboot or device unplug/re-plug so we can not
> enable firmware update by default.
>
> This change thus only enable notifying about new firmware updates, not
> installing them.
>
> With this change, Fedora installations will contact the Linux Vendor
> Firmware Service CDN (LVFS, https://cdn.fwupd.org/) to get the updated
> metadata but will not send any information about the hardware without
> user interaction.
>
> See the LVFS privacy policy at
> https://lvfs.readthedocs.io/en/latest/privacy.html.
>

I like this, it's a very unobtrusive change and will point some admins
to apply firmware updates. Thanks for this idea!


Cheers,

Dan
___
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: F39 Change Proposal: Color Bash Prompt (System Wide)

[Dan Čermák]

Hi,

Aoife Moloney  writes:

> https://fedoraproject.org/wiki/Changes/Color_Bash_Prompt
>
> == Summary ==
> Introduce a default colored prompt for Fedora's default shell bash.
>
> == Owner ==
>
> * Name: [[User:Petersen| Jens Petersen]]
>
> * Email: 
>
>
> == Detailed Description ==
> For a long time the Fedora default shell prompt has been monochrome,
> which makes it difficult to find shell prompt commands between long
> command outputs when scrolling through terminal shell output.
> This Change introduces a simple default colored shell prompt, which
> users can also easily theme themselves.
>
> [https://petersen.fedorapeople.org/color-bash-prompt.png screenshot of
> color bash prompt in gnome-terminal]

I am overall in favor of this change, thanks for working on this Jens
and for keeping it simple!

I like the simple look, but I would suggest to add a either spaces
in front and after the exit code or braces around it or something else
visually distinctive from the rest of the prompt. At the moment the exit
code looks like something that got crammed into the prompt by accident.


Cheers,

Dan
___
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: Fedora ELN Plans for Summer 2023

[Dan Čermák]

Florian Weimer  writes:

> * Stephen Gallagher:
>
>> First, as the cleanup of unnecessary dependencies in the Fedora ELN
>> has not yet completed, we are revising our plan of performing a
>> mass-import of *all* Fedora ELN content to CentOS Stream 10 in July.
>> Instead, we plan to move to a phased approach wherein we will first
>> import, build and test only the portions of CentOS Stream 10 that we
>> currently have slated for inclusion in the delivered "runtime". As a
>> necessary side-effect of this, it means that we will NOT be
>> transitioning directly to CentOS Stream 10 as a self-hosted
>> environment.
>
> A bit related to the CentOS 10 bringup, the CentOS ISA SIG is currently
> porting CentOS 9 Stream to the x86-64-v3 ISA level.  I believe there are
> some failures that are not yet fixed in ELN/upstream, and we'll be
> sharing our workarounds with rawhide/ELN as appropriate.

Just out of curiosity, have you looked at the glibc-hwcaps effort that
has been going on the openSUSE side of the world for this? In theory it
should allow to have the optimized subpackages for the respective
architecture levels in the same repositories and it would not require a
full rebuild of the who distribution.


Cheers,

Dan
___
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: Modules without modularity

[Dan Čermák]

Hi Petře,

Petr Pisar  writes:

> Hello,
>
> as it seems that module build infrastructure isn't getting any better, as
> modular YUM repositories are going to be deconfigured
> ,
> there is a time to look at different ways how to package alternative content.
>
> There are few aproaches, like compat packages, or full namespacing (Python).
> Yet modularity had some unique features, especially retaining nonmangled
> package names and other RPM dependencies.
>
> I spent some time thinking how to approximate the nice features with current
> state of RPM, Koji, and DNF and come up with this approach
> . The linked approach achieves
> it at the expense of dedicated build targets and an inability to introduce
> completely new modules (as opposite to new streams of existing modules) after
> releasing an installation media.

I like the proposal, it gives us nearly all the benefits of modularity
without the complexity introduced by modular repos and MBS.

I have one question about this part:

> The only drawback is one have to decide before GA which software will
> have an alternative content and create meta-packages for the default
> streams. Otherwise, users installing from GA media and upgrading later
> could get installed a nondefault stream.

Why is that?

Wouldn't the process work as follows:
- you create your packages, the metapackage and add them to
  fedora-release
- users upgrading from GA will get the new fedora-release with the
  proper Suggests:
- users installing from a respin will have the proper Suggests: from the
  beginning

The only way that I see how this could go sideways is the scenario where
you switch what the default stream is after GA. But I thought that was
forbidden by policy anyway?


Thanks for this proposal!

Dan
___
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: more distinct default bash prompt?

[Dan Čermák]

Hi Jens,

Jens-Ulrik Petersen  writes:

> In Fedora the bash prompt is not colored or highlighted by default.
>
> I personally find this a usability issue: it makes it hard to find previous
> commands between long outputs when scrolling back in a terminal.  Of course
> in my own host I have a custom prompt, but it means whenever I am using a
> different Fedora/Centos/RHEL system or vm, the prompt is not highlighted by
> default, which I miss.
>
> Since I spent a little time thinking about and investigating this I thought
> I would write to start a discussion here.
>
> I noticed that Ubuntu has a bold green and blue prompt and NixOS has a
> green one by default, though not Archlinux or OpenSuSE I think.
>
> I think it would be nice to have a distinctive prompt by default, or at
> least a very easy way to get one permanently (ie in a single command: even
> if that were `dnf install bash-color-prompt` or running say `colorprompt`
> once).
>
> For example I could suggest we change the default fedora bash prompt from:
> PS1="[\u@\h \W]\\$ "
> to something like:
> PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
>
> Then the PROMPT_COLOR envvar would make it easy for users to change or
> customize their prompt coloring anyway.
> For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
> seems readable in both dark or light terminals.
>
> What do people think overall? Are there other pros and cons of a color
> prompt?
> Any better ideas or direction?

I think your suggestion is very unobtrusive and a great quality of life
improvement! So please go for it!

My only suggestion would be to double check with someone who's familiar
with accessibility with respect to color blindness to find the best
possible default, so that color blind users will not have an even harder
time spotting the prompt.


Cheers,

Dan
___
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: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Dan Čermák]

Hi,

Aoife Moloney  writes:

> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
>
snip
>
> There is considerable implementation complexity within OSBS to implement this,
> because the N/V/R need to be written into generated Dockerfile as
> labels ''before'' building it,
> but it should be manageable. If not, we'll need to switch to a different 
> scheme.
> (Running dnf with --best when building the container will
> help make this reliable
> and would be a general improvement.)

Just out of interest, has this complicated part been already implemented
or is it still on the todo list? Would using a different container build
system reduce the complexity here?


Cheers,

Dan
___
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: F39 proposal: mkosi-initrd (Self-Contained Change proposal)

[Dan Čermák]

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/mkosi-initrd
>
> 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 ==
>
> `mkosi-initrd` is an alternative builder for initrds.
> It will be packaged in Fedora, so that users can use it to build
> initrds locally.
> A `kernel-install` plugin will be provided to build the initrd when a
> kernel package is installed.
> As a stretch goal, initrds will be build in koji and delivered via rpm 
> packages.
> As a further stretch goal, pre-built initrds will be used in Unified
> Kernel Images that can be delivered via rpm packages.
>
> Only a subset of installation types will be supported.
>
> == Owner ==
> * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
> * Name: [[User:lnykryn| Lukáš Nykrýn ]]
> * Name:  [[User:Daandemeyer| Daan De Meyer]]
> * Email: zbyszek - at - in.waw.pl, lnykryn - at - redhat.com,
> daandemeyer - at - fb.com
>
>
>
> == Detailed Description ==
> The process by which we create initrds is complicated and inefficient.
> Initrds contain duplicate functionality and require a lot of maintainer 
> effort.
> The aim of this proposal is to introduce a vastly simplified mechanism
> of initrd creation and simplified initrd contents.
>
> The `mkosi-initrd` project is a set of config files for `mkosi`.
> `mkosi` is a program to build operating system images from system packages.
> An initrd is built by invoking `mkosi` with the config provided by
> `mkosi-initrd`.
>
> Instead of building initrds by scraping the file system and figuring
> out dependencies again,
> existing packages and normal package installation via `dnf`/`rpm` is
> used to populate the initrd.
> This also means that the package manager is responsible for satisfying
> dependencies.
> At runtime, `systemd` is responsible for setting up the execution
> environment and invoking programs.
>
> Currently, initrds built in this way are bigger than initrds built by dracut.
> They also have limited functionality:
> many common types of systems work just fine, but more exotic
> configurations are not supported.
> See [[#Scope|Scope]] below for a list of known good/bad features.
>
> The goal of this change is to provide an ''alternative'' mechanism.
> If the feedback is positive, we may consider using initrds built with
> `mkosi-initrd` as default in certain scenarios.
> There are no plans to remove `dracut` in the foreseeable future.
> This means that for any case not supported or not working well,
> `dracut` remains a natural fallback.
> In this way this change is similar to
> [[Changes/Unified_Kernel_Support_Phase_1]],
> as it provides a preview of a new technology as an alternative to the
> current established approach.
>
> == Feedback ==
>
>
> == Benefit to Fedora ==
> Current initrd generation with `dracut` is showing its age.
> As upstream packages evolve,
> repeating the dependency resolution in `dracut` is a constant drain of
> maintainer time.
> Our `dracut` initrds are already using `systemd`.
> But `systemd` is constantly evolving and adding new functionality
> related to early boot:
> decryption of disks, access to secrets, new configuration mechanisms,
> state checks and boot counting.
> More and more, `dracut` runtime scripting is a thin wrapper around `systemd`.
> We have two job queues: the `dracut` initqueue, and the `systemd` job queue.
> This duplication makes everything harder, both during preparation and
> at runtime, for little benefit.
>
> The design principle of the new approach is to remove duplicate functionality:
> * package `Requires` replace dracut module dependency logic and
> automatic installation of libraries based on `ldd` output
> * `systemd` job management replaces the remainder of `dracut` runtime
> * the environment in the initrd is just a normal linux system (albeit
> on a temporary root fs)
> * normal package contents replace special scripts crafted for the initrd
>
> Generally, the new scheme requires very little new stuff.
> We reuse things that are already available (and used):
> `dnf` and `rpm`,
> packages for all stuff that is used in the initrd,
> `systemd`,
> special systemd units for the initrd.
>
> The new component is a mechanism that builds the initrd out of packages.
> But it is a relatively simple step that requires very little maintenance.
> The biggest part of the initial work is the creation of package lists
> to install in the initrd,
> and adjusting packages to to function correctly in the initrd and not
> pull in unnecessary dependencies.
> Afterwards, there might be occasional maintenance related to bugs or
> package splits.
>
> Initrds built with `mkosi-initrd` should be fully reproducible (in the
> sense of reproducible builds).
>
> The work done in packages has external benefits:
> package minimization 

Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Dan Čermák]

Chris Adams  writes:

> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
>> On Tue, Apr 04, 2023 at 11:17:50AM +0200, Jakub Jelinek wrote:
>> > Why a subrpm?  Should be possible to just arrange for one src.rpm to
>> > build the library twice and install the x86-64-v3 into
>> > /usr/lib64/glibc-hwcaps/x86-64-v3/
>> > Perhaps come with some macro to simplify that for packagers.
>> 
>> If we start compiling libaries twice, it'd double the package sizes
>> (or actually more than double, since in the benchmarks the code size
>> with -v3 is also increased slightly). I assume people would want to
>> get the optimized form split out to a subpackage so people who don't
>> use this, don't pay the price. If we use the new "dynamic subpackages"
>> feature of RPM, and some smart macros, this could even not be a big
>> packaging burden.
>
> Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
> PITA sometimes.  But cramming multiple architectures of core libraries
> into a single RPM would be bad for disk space, image size, downloads,
> etc.
>
> But something that didn't exist in the i386/i686 days is containers -
> whether base images like for podman or full things like Flatpaks.
> Before going too deep into multi-level architectures, that should be
> taken into account.

Afaik at least container runtimes do not support really support x86_64
subarchitectures: https://github.com/containers/podman/discussions/15256


Cheers,

Dan
___
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: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Dan Čermák]

Hi,

Mattia Verga via devel  writes:

> Il 31/03/23 17:27, Florian Festi ha scritto:
>> On 3/31/23 15:40, Stephen Gallagher wrote:
>>> On Thu, Mar 30, 2023 at 3:42 PM Ben Cotton  wrote:
 https://fedoraproject.org/wiki/Changes/RPM-4.19
 == Detailed Description ==
 RPM 4.19 contains various improvements over previous versions. Many of
 them are internal in nature such as moving from automake to cmake,
 improvements to the test suite, stripping copies of system functions,
 splitting translations into a separate project and more. There are
 still several user facing changes:

 * New rpmsort(8) utility for sorting RPM versions
>>> Handy!
>>>
 * x86-64 architecture levels (v2-v4) as architectures
>>> Could you explain more what this means, exactly?
>> No! But here is the commit:
>>
>>   
>> https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847
>>
>> It looks like it adds x86_64_v2, x86_64_v3 and x86_64_v4. Something
>> about some x86_64 processors having additional capabilities.
>>
> Is there anyone who could provide some benchmarks to see if there are
> significant performance improvements about using v2/v3/v3 versus plain
> x86_64? If so, do you think we could drop building i686 by default (to
> save some resources) and provide v2 (or v3, or v4) alongside x86_64?

The only benchmark that *I* am aware of is this one done by Martin
Jambor: https://jamborm.github.io/spec-2022-07-29-levels/

tl;dr; v2 does not really bring notable improvements, only v3 but also
only in some selected synthetic benchmarks.


openSUSE Tumbleweed went a different route and chose to utilize
glibc-hwcaps instead:
https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels
https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/ZOHLT4CQ7TDOJJ2VV7HKMN5G2MR2CTMD/


Cheers,

Dan
___
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: Specfile - Upgrade - Check if the old and the new package versions are the same

[Dan Čermák]

Hi Simon,

On March 30, 2023 12:54:49 AM UTC, Simon Pichugin  wrote:
>Hi folks,
>I've spent some time experimenting and trying to implement something like
>this ($subject):
>
>During `%preun servers`:
>
>export OLD_VERSION="$(rpm -qa openldap | awk -F- '/^openldap/ &&
>split($2,ver,/\./) >= 1 {print ver[1] "." ver[2] "." ver[3]}')"
>
>Then, during `%post servers`
>
>if [ $1 -lt 2 ] || [ "%{major_version}.%{minor_version}" =
>"${OLD_VERSION}" ] ; then
># do something
>fi
>
>I understand that it's not the correct way... Could you please suggest how
>something like this can be achieved? (during the upgrade - check if the old
>and the new package versions are the same)

You could try to use rpmdev-vercmp. I am not sure if its exit code indicates 
whether two versions are equal, but it provides easy to parse output.

Hope that helps,
Dan
___
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

[Dan Čermák]

Hi Fabio,

On March 9, 2023 1:37:14 PM UTC, 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).
>
>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).

As someone who accidentally build a package in the wrong time period, I'm very 
much in favor of preventing this from happening in the future.

Thanks for this proposal!


Dan
___
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: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases

[Dan Čermák]

Hi Lokesh,

Lokesh Mandvekar  writes:

> Hi,
>
> We (podman upstream and fedora maintainers) are hoping to disable i686
> and 32-bit arm builds for Podman and some related tools under
> https://github.com/containers org. We would like to do this also for
> released Fedora versions, and not just the upcoming ones.
>
> What Fedora paperwork do we need in place to get this going?

I would suggest to file a self-contained change proposal to get some
visibility for this change in the official release notes. But afaik all
you have to do is to define `ExclusiveArch:` or `ExcludeArch:` in your
spec file.


Hope this helps,

Dan
___
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: IoT Simplified Installer (Self-Contained Change proposal)

[Dan Čermák]

Hi Peter,

Peter Robinson  writes:

> On Wed, Jan 18, 2023 at 11:20 AM Dan Čermák
>  wrote:
>>
>> Ben Cotton  writes:
>>
>> > https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller
>> >
>> > 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 ==
>> > Offer Fedora IoT users a new method to create and deploy customized
>> > Fedora IoT disk images using a new installer called Simplified
>> > Installer.
>> >
>> > == Owner ==
>> > * Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
>> > * Email: amurd...@redhat.com, pwha...@fedoraproject.org
>> >
>> >
>> > == Detailed Description ==
>> > The Fedora IoT Simplified Installer will use coreos-installer to write
>> > an OStree raw image straight to a disk specified in a kernel argument,
>> > without the need for a kickstart or user interaction. This type of
>> > installation is ideal for devices connected at the edge where
>> > connectivity can be slow or intermittent. It offers the ability to
>> > configure the system via osbuild itself, FDO and Ignition.
>> >
>> > == Feedback ==
>> >
>> >
>> > == Benefit to Fedora ==
>> > The addition of the Fedora IoT Simplified Installer will benefit IoT
>> > users by allowing them to create customized disk images for use on
>> > their edge devices. This feature is already available downstream,
>> > adding it to Fedora will once again bring Fedora back to the true
>> > upstream of RHEL for edge and allows testing and adoption of new
>> > functionality like FIDO Device Onboarding.
>> >
>> > == Scope ==
>> > * Proposal owners:
>> > ** Test building Fedora IoT Simplified Installer with `osbuild-composer`
>> > ** Update Fedora IoT documentation with usage instructions.
>> >
>> > * Other developers:
>> >
>> > * Release engineering:
>> > * Policies and guidelines: N/A (not needed for this Change)
>> >
>> > * Trademark approval: N/A (not needed for this Change)
>> > * Alignment with Objectives:
>> >
>> >
>> > == Upgrade/compatibility impact ==
>> > * Not applicable to this change.
>> >
>> > == How To Test ==
>> > Testable by installing `osbuild-composer` in Fedora 38 and using the
>> > command line tool or the Cockpit web interface to create a Fedora IoT
>> > Simplified Installer iso to deploy a UEFI enabled edge device.
>> >
>> >
>> > == User Experience ==
>> > This change will greatly enhance the Fedora IoT user experience by
>> > allowing users to utilize `osbuild-composer` and blueprints to create
>> > customized Fedora IoT deployments and leverage new features like FIDO
>> > Device Onboarding for secure zero touch device onboarding of edge
>> > devices as well as Ignition to configure the device once it starts.
>>
>> Will it still be possible to use something simple like zezere /
>> provision.fedoraproject.org to deploy your ssh keys? I find that to be
>> one of the major advantage of Fedora IoT over all the other images for
>> the Raspberry Pi out there, as I can easily get the IP of my newly
>> setup device and push my ssh keys from FAS there without ever having to
>> bother with ignition.
>
> Yes, we're looking to revitalize zezere too but I think that will more
> likely be a F-39 feature at this stage.

Thanks for keeping this on the table!

I don't want to be demanding here, but I would personally prefer if
zezere stayed also for the interim period, but I completely understand
if that has a low priority.


Cheers,

Dan
___
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: IoT Simplified Installer (Self-Contained Change proposal)

[Dan Čermák]

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller
>
> 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 ==
> Offer Fedora IoT users a new method to create and deploy customized
> Fedora IoT disk images using a new installer called Simplified
> Installer.
>
> == Owner ==
> * Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
> * Email: amurd...@redhat.com, pwha...@fedoraproject.org
>
>
> == Detailed Description ==
> The Fedora IoT Simplified Installer will use coreos-installer to write
> an OStree raw image straight to a disk specified in a kernel argument,
> without the need for a kickstart or user interaction. This type of
> installation is ideal for devices connected at the edge where
> connectivity can be slow or intermittent. It offers the ability to
> configure the system via osbuild itself, FDO and Ignition.
>
> == Feedback ==
>
>
> == Benefit to Fedora ==
> The addition of the Fedora IoT Simplified Installer will benefit IoT
> users by allowing them to create customized disk images for use on
> their edge devices. This feature is already available downstream,
> adding it to Fedora will once again bring Fedora back to the true
> upstream of RHEL for edge and allows testing and adoption of new
> functionality like FIDO Device Onboarding.
>
> == Scope ==
> * Proposal owners:
> ** Test building Fedora IoT Simplified Installer with `osbuild-composer`
> ** Update Fedora IoT documentation with usage instructions.
>
> * Other developers:
>
> * Release engineering:
> * Policies and guidelines: N/A (not needed for this Change)
>
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
> * Not applicable to this change.
>
> == How To Test ==
> Testable by installing `osbuild-composer` in Fedora 38 and using the
> command line tool or the Cockpit web interface to create a Fedora IoT
> Simplified Installer iso to deploy a UEFI enabled edge device.
>
>
> == User Experience ==
> This change will greatly enhance the Fedora IoT user experience by
> allowing users to utilize `osbuild-composer` and blueprints to create
> customized Fedora IoT deployments and leverage new features like FIDO
> Device Onboarding for secure zero touch device onboarding of edge
> devices as well as Ignition to configure the device once it starts.

Will it still be possible to use something simple like zezere /
provision.fedoraproject.org to deploy your ssh keys? I find that to be
one of the major advantage of Fedora IoT over all the other images for
the Raspberry Pi out there, as I can easily get the IP of my newly
setup device and push my ssh keys from FAS there without ever having to
bother with ignition.


Cheers,

Dan
___
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: Use cases for 'fedpkg scratch-build'

[Dan Čermák]

Otto Liljalaakso  writes:

> Hello everybody,
>
> I would like to gather different use cases for the 'fedpkg 
> scratch-build' command.
>
> Currently, this is exactly the same as 'fedpkg build --scratch', meaning 
> that is performs a scratch build of the pushed head of the current 
> branch. At least in my workflow, I only do scratch builds before 
> pushing, to ensure that what I am about to push builds correctly in 
> Koji. Because if this, I never use the default form. Instead, I always 
> specify 'fedpkg scratch-build --srpm', so that the srpm to build from is 
> locally generated from the local working directory.
>
> What I would like to do is to submit a pull request to either fedpkg or 
> rpkg, making that the default. It is a single line code change, not 
> counting changes to documentation and code comments.
>
> Doing a scratch build from the pushed contents would still be possible 
> by either a) using 'fedpkg build --scratch' or b) checking out the 
> remote head and then issuing 'fedpkg scratch-build'.
>
> Above change seems like a clear improvement to me, making the most used 
> option the default. But I have noticed that workflows differ wildly 
> between packagers, so before submitting any code for review, I would 
> like to hear if somebody regularly uses the default form 'fedpkg 
> scratch-build' and thinks it currently does the right thing.

I pretty much use fedpkg scratch-build only with the --srpm option in
the same way that you do. Thus I very welcome this change and thank you
for submitting this pull request!


Cheers,

Dan
___
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: Macro expanded on comment?

[Dan Čermák]

Ron Olson  writes:

> Hey all-
>
> I commented out a SOURCES line in a spec file to test something and got an 
> interesting warning: “Macro expanded in comment on line …”. I assume it’s 
> just that, a warning, but was kinda surprised to see a commented-out line 
> being evaluated at all. I did some searching and came across this BZ from 
> 2015: https://bugzilla.redhat.com/show_bug.cgi?id=1224660 that seems to 
> suggest there’s a better way (%dnl), so if I want to comment something out 
> instead of putting a # in front of the line, I should use %dnl?

Yes, # does not prevent macro expansion, all it does is that # is
prepended to the expanded macro before it is being fed to the shell. For
single line macros, that is equivalent to commenting it out, but for
macros that expand to multiple lines, you'll get *very* interesting
errors. And macros which have side effects will still have that side
effect.

%dnl on the other hand will (iirc) instruct RPM to not expand anything
after it on this line.


Cheers,

Dan
___
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: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

[Dan Čermák]

Hi,

On November 23, 2022 8:08:59 PM UTC, Ben Cotton  wrote:
>https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
>
>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 {{package|fedora-autofirstboot}} to desktop variants to run a
>predetermined set of tasks on first boot after post installation,
>notably installing codecs and cleaning up installer packages from the
>installed system.
>
>== Owner ==
>* Name: [[User:Ngompa| Neal Gompa]]
>* Email: ngomp...@gmail.com
>
>
>== Detailed Description ==
>{{package|fedora-autofirstboot}} is a collection of scripts that
>invoke on firstboot of a freshly installed system to run a set of
>predetermined tasks. It also provides a framework for third-parties to
>introduce their own firstboot tasks to run through this framework. The
>initial services included are to install OpenH264 and remove Anaconda.
>
>
>== Benefit to Fedora ==
>The main benefit is to smooth out the new user experience for new
>Fedora Linux installations. In particular, we can deal with a
>long-standing sticking point that Anaconda remains installed on the
>user's machine when it is not useful to do so.
>
>== Scope ==
>* Proposal owners:
>** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
>** Add a preset to {{package|fedora-release}} for
>fedora-autofirstboot.service
>
>* Other developers: N/A (not needed for this Change)
>
>* Release engineering: [https://pagure.io/releng/issue/11148 #11148]
>* Policies and guidelines: N/A (not needed for this Change)
>* Trademark approval: N/A (not needed for this Change)
>* Alignment with Objectives: N/A
>
>
>== Upgrade/compatibility impact ==
>This will have no impact on upgraded systems, since the firstboot
>condition is not true in that case.
>
>
>== How To Test ==
>
># Install Fedora Workstation, KDE, etc.
># Reboot into installed environment
># Check to see openh264 is installed and
>anaconda-core is not.
>
>== User Experience ==
>The first boot will be slightly slower because of these tasks running,
>though they should happily run in the background as other services
>start up, so it should not be noticeable.
>
>== Dependencies ==
>The main dependency is {{package|fedora-release}}, though we will need
>to ensure all {{package|udisks2}} plugins get pulled in as
>dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
>they don't get uninstalled when Anaconda is.
>
>
>== Contingency Plan ==
>* Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
>the kickstarts
>* Contingency deadline: Final freeze
>* Blocks release? No
>
>
>== Documentation ==
>There is not currently much documentation in
>[https://pagure.io/fedora-autofirstboot the upstream project], though
>contributions are welcome.

This sounds great, but it would be nice if the documentation could be expanded, 
before we flick the switch that makes this the default in Fedora. Especially as 
this sounds like something that could simplify our (=the i3 SIG) kickstart and 
custom scripts.

>
>== Release Notes ==
>Fedora Linux now ships with a framework for setting up first-boot
>services and uses this to install multimedia software and remove the
>installer software from the system after installation.
>
___
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: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Dan Čermák]

Hi Daniel,

On November 23, 2022 5:44:01 PM UTC, "Daniel P. Berrangé"  
wrote:
>On Wed, Nov 23, 2022 at 01:20:24PM +0100, Ralf Corsépius wrote:
>> 
>> 
>> Am 23.11.22 um 12:20 schrieb Miro Hrončok:
>> > Hello.
>> > 
>> > Based on my conversation with Fridolín Pokorný @fpokorny, I've removed
>> > them from their Fedora packages.
>> > 
>> > They left Red Hat and are no longer interested in maintaining Fedora
>> > packages.
>> 
>> I am wondering, why Red Hat/FESCO/... still hasn't found some "formal"
>> successor regulations/proceedures to migitate such cases, provided they have
>> happened many times before, in all the years, Fedora is around?
>
>The mitigation/successor strategy is to have comaintainers for every
>package.
>
>Unfortunately our tools enforce the notion of a "main admin" and
>if that person leaves that role has to be given to another
>comaintainer explicitly.

In my personal packaging experience that wouldn't really help, as all packages 
that I have been involved in, have been or are maintained by a single person, 
irrespective of the number of admins. And once it gets orphaned, none of the 
"ordinary" admins pick it up.

But that's just my experience, yours might (and probably does) differ.

>IMHO we would be better off eliminating the notion of 'main admin'
>entirely and have all co-maintainers be at the equal level, so there
>is no need for a dance to give packages to comaintainers. There
>should only be manual action needed if the last comaintainer quits.
>
>A workaround for the 'main admin' problem is to have a robot account
>as the 'main admin' and all the real people as merely 'admin', so
>the main admin never leaves, but that's a bit tedious to setup.
>
>With regards,
>Daniel
___
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: moby-engine (also known as Docker) maintenance in Fedora

[Dan Čermák]

Hi Timothée,

On November 14, 2022 7:18:45 PM UTC, "Timothée Ravier" 
 wrote:
>Hi everyone,
>
>The moby-engine package [1] (also known as Docker) has been orphaned in Fedora 
>and is looking for a new maintainer. The waiting period will soon be over and 
>the package will be retired if nobody steps in.
>
>This means that the package will be unavailable starting with the next release 
>of Fedora (Fedora 38) that should happen in approximately 5 to 6 months.
>
>If you are using this package and are interested in helping maintaining it, 
>now is the time to come forward!

I'm using docker for $dayjob and would be willing to help out a bit, but I will 
not be the main maintainer, as I don't feel comfortable taking such a huge 
package and lack the cycles for that.

>
>This notably impacts Fedora CoreOS as we are including the moby-engine package 
>by default to let users pick their container engine of choice whithout 
>deciding for them in advance. We offer both major container engines by default 
>in the image (podman and moby-engine).

No offense, but this sounds like that this is something the Fedora coreos team 
should tackle. Given that Fedora coreos appears to be driven to a large extend 
by redhat (at least that's my impression, please correct me if I'm wrong), I 
find it a bit odd that the business is asking volunteers to step up to help the 
business out...

>
>If the moby-engine package ends up being retired for Fedora 38, then we will 
>have to recommend to its users on Fedora CoreOS that they either switch to the 
>official Docker packages [2] or move to containerd or podman when the rebase 
>to Fedora 38 happens alongside the Fedora 38 release [3].
>
>Note that we will likely not remove the containerd package from Fedora CoreOS 
>as it is still maintained in Fedora and is currently used by Kubernetes 
>distributions based on Fedora CoreOS (such as Typhoon for example).
>
>See also the Fedora CoreOS tracker issue [4] for more details.
>
>[1] https://src.fedoraproject.org/rpms/moby-engine
>[2] https://docs.docker.com/engine/install/fedora/
>[3] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
>[4] https://github.com/coreos/fedora-coreos-tracker/issues/1291
>
>Thanks,
>
>Timothée Ravier for the Fedora CoreOS 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: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Dan Čermák]

Hi,

On October 10, 2022 8:17:15 AM UTC, Zdenek Dohnal  wrote:
>Hi all,
>
>I maintain qpdf in Fedora, which recently got a new major release version, 
>which breaks compatibility with other packages, so I created a side tag for 
>other maintainers to use for building, and then releasing it altogether in 
>rawhide.
>
>However the side tag:
>
>f38-build-side-58658
>
>got automatically deleted, even when it had builds connected to it already. 
>Documentation [1] does not mention any automatic side-tags cleanup and its 
>deadlines.
>
>Although packagers can create a new side tag easily, I found it inconvenient 
>for maintainers, because the synchronization among the maintainers can take 
>weeks to finish the rebuild and release the update and automatic removal 
>without notice (do excuse me if I missed a notification email about this - I 
>have many filters and it could end up somewhere where I wasn't able to find 
>it) prolongs this process.
>
>What I would like to propose are the following options:
>
>A) don't do side-tag cleanups after a specific time frame, but only when the 
>specific event happens - branching, GA, EOL - it can be consuming to our 
>resources, but maintainer are still able to remove the side tags manually in 
>case it contains a big set of packages and AFAIK the process itself is not 
>such spread in usage...
>
>or
>
>B) do a side-tags cleanup and mention it in the documentation together with 
>specification what the removal's time frame is, so maintainers can act 
>accordingly
>
>or
>
>C) (my preferred) Koji or releng (depends on whether the cleanup happened 
>automatically or manually) will send an email to a side tag creator with 'Hi, 
>your side tag is going to expire - do you need it?' Or with automaton - 'use 
>this command to prolong it.' And if there is no response or if the creator 
>approves, remove the side tag.

This sound like the preferred solution to me as well.


Cheers,

Dan
___
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: [INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Dan Čermák]

Hi Stephen,

Stephen Gallagher  writes:

> On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton  wrote:

> *snip*

> When a Node.js release goes out of support, we have a question to
> answer: do we Obsolete it with a newer version? If so, which one? The
> most recent version or the oldest one? It will not be 100% compatible
> in either case. Do we Obsolete it with fedora-retired-packages? Do we
> just leave the packages in Fedora forever (possibly patching the
> `/usr/bin/node` binary to warn that it's out of support)?

I would definitely obsolete it. I personally would obsolete it with the
default nodejs version, if there is one.

> There's another potential upgrade issue: We have multiple choices of
> how to upgrade from the nodejs package to the nodejsXX packages:
> 1) Upgrading from either F36 or F37 will result in you getting Node.js
> 18. (This method is closest to how things worked prior to this Change,
> where the nodejs package would just get updated to the latest stable
> release)
> 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading
> from F37 will move you onto Node.js 18 in F38. (This method maintains
> compatibility with applications running on the current system)
> 3) Upgrading from F36 or F37 will *remove* the nodejs package and the
> user will need to manually select one to install. (This method has
> increased friction, but more user choice)
> 4) Upgrading from F36 or F37 will leave the existing nodejs package on
> the system, receiving no updates. Users of F38 will need to manually
> remove and install a newer version. (This method is high-friction,
> offers nothing over any of the others and potentially leaves people
> vulnerable)
>
> With options 1), 3) and 4), we can make the change in F38 exclusively.
> However if we want to do 2), we *also* need to either backport this
> Change to Fedora 37 and Fedora 36 because otherwise we would have to
> continuously update the Obsoletes: values in F38. With 1) I can update
> the Obsoletes: to just treat any Node.js with an epoch < 3 as the
> trigger to move to nodejs18.
>
> My questions to those brave souls who have read this far:
> 1) Which do you think is the best of the above options for upgrades to F38?

My personal preference would be Option 1. Imho it's a bit expected that
you might have to do some cleanup after a system upgrade. So moving to
the latest stable version sounds like a good overall compromise for most
users: you'll get the latest stable version and if you need an older
version, you'll (hopefully) figure it out during the post-upgrade
cleanup. (And we could implement it without backporting)

> 2) What do we do about future upgrades in the following scenarios:
> a. The user has nodejsXX installed as the default interpreter. The
> nodejsXX package is no longer available upon upgrade (EOL).

I would upgrade to the new default version.

> b. The user has nodejsXX installed as the default interpreter. The
> nodejsXX package is available but non-default upon upgrade.

Unless it is very simple to upgrade to that non-default version on
upgrade, I'd just upgrade to the new default/latest stable as well in
this case.


Cheers,

Dan
___
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: limiting the (systemd) journal size

[Dan Čermák]

Hi,

On September 27, 2022 6:13:48 PM UTC, Chris Murphy  
wrote:
>
>
>On Tue, Sep 27, 2022, at 10:59 AM, Gregory Bartholomew wrote:
>>> 
>>> What about modifying /etc/systemd/journald.conf:
>>> 
>>> MaxFileSec=1week
>>> MaxRetentionSec=5week
>>> 
>>> This should result in at least 4 weeks of journal entries, i.e. it would 
>>> delete a journal
>>> file once entries reach 5 weeks old, but since the journal files are 
>>> rotated weekly, it
>>> should mean a given journal file won't have more than a week's worth of 
>>> entries.
>>> So you'd have between 4-5 weeks worth of entries at any given time.
>>
>> Thanks for the tip. That does look like a better solution and I'll do 
>> that for my containers. Although, since I don't want it to hinder 
>> future updates of /etc/systemd/journald.conf, I'll put those lines in 
>> /etc/systemd/journald.conf.d/override.conf.
>
>I hadn't considered the container case at all, that containers running 
>systemd-journald would have their own journals and retention policy. I wonder 
>if the container default should have volatile journals? Or forward the 
>journals to the host by default? But yes I can see how many containers each 
>thinking they have a 4G cap could quickly become a problem.

Note that the majority of containers are not running journald. Only init-type 
containers under podman or nspawn containers have their own journal. All others 
will simply log to the container runtime's log (which can be journald, but 
needn't be).
___
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: Request for help: Package downgrades on upgrade from F36 to F37

[Dan Čermák]

Fabio Valentini  writes:


> - obs-build-0:20220812-393.9.1.fc36 > obs-build-0:20211125-376.1.3.fc37

Whoops, my bad… Build is running right now.
___
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: Inactive packagers to be removed after the F37 release

[Dan Čermák]

Hi,

On September 16, 2022 5:03:03 PM UTC, Kevin Fenzi  wrote:
>On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
>> Isn't peer review much better and easier solution over all? We could also
>> require signed commits I guess.
>
>I think it would slow things down quite a lot to require peer review of
>every commit. 

It would a bit, but it is doable. openSUSE tumbleweed works like that: every 
commit that is sent into the rolling distro is reviewed by the release 
managers. It adds some overhead and it would most certainly require dedicated 
reviewers and additional tooling.

>I'd personally like to avoid anything where we need to support gpg.
>It's a mess and I think it would waste a lot of cycles explaining how to
>use it or help people get setup. ;( If there's some easier/more clear
>way to sign things that could be a option tho.
>
>kevin
___
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: rpm with sequoia pgp

[Dan Čermák]

Hi Neal,

"Neal H. Walfield"  writes:

> Hi all,
>
> rpm 4.18 is on the horizon and includes a new OpenPGP backend based on
> Sequoia PGP.
>
>   https://rpm.org/wiki/Releases/4.18.0
>   https://sequoia-pgp.org/
>
> Thanks to Fabio Valentini (decathorpe) for packaging not only
> rpm-sequoia, but all of the Sequoia packages for Fedora.
>
>   
> https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/

As Sequoia is written in Rust, what is your RISCV story? Fedora is (at
least that's my impression) a quite popular choice for RISCV boards, so
rpm working on RISCV would be crucial for us staying relevant.


Cheers,

Dan
___
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: Heads-up / for discussion: dnf not working with 1G of RAM or less

[Dan Čermák]

Casey Jao via devel  writes:

> Old rpm-ostree thread about this: 
> https://github.com/coreos/rpm-ostree/issues/1127
>
> 1. Debian provides a comparably sized package catalog using one-tenth the 
> size of Fedora's metadata. Are there any lessons that Fedora can learn from 
> Debian?
> 2. Does SUSE have the same problem?

No, I don't think so. openSUSE and SUSE use zypper + libzypp instead of
dnf and iirc zypper is lighter on memory usage (but lacks the more "fancy"
features like `dnf repoquery`).

Also, the openSUSE Tumbleweed repository is smaller than the Fedora
repository (and only contains the latest rebuilds, i.e. even less
metadata). I am not 100% sure about Leap though, as I have heard horror
stories about the size of the Leap Update repository size (the
repository contains every package build for the whole release)…
___
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: [fedora-arm] Heads-up / for discussion: dnf not working with 1G of RAM or less

[Dan Čermák]

Hi,

Adam Williamson  writes:

> Hey folks! I apologize for the wide distribution, but this seemed like
> a bug it'd be appropriate to get a wide range of input on.
>
> There's a bug that was proposed as an F37 Beta blocker:
> https://bugzilla.redhat.com/show_bug.cgi?id=1907030
>
> it's quite an old bug, but up until recently, the summary was
> apparently accurate - dnf would run out of memory with 512M of RAM, but
> was OK with 1G. However, as of quite recently, on F36 at least (not
> sure if anyone's explicitly tested F37), dnf operations are commonly
> failing on VMs/containers with 1G of RAM due to running out of RAM and
> getting OOM-killed.
>
> There's some discussion in the bug about what might be causing this and
> potential ways to resolve it, and please do dig into/contribute to that
> if you can, but the other question here I guess is: how much do we care
> about this? How bad is it that you can't reliably run dnf operations on
> top of a minimal Fedora environment with 1G of RAM?
>
> This obviously has some overlap with our stated hardware requirements,
> so here they are for the record:
>
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/
>
> that specifies 2GB as the minimum memory for "the default
> installation", by which I think it's referring to a default Workstation
> install, though this should be clarified. But then there's a "Low
> memory installations" boxout, which suggests that "users with less than
> 768MB of system memory may have better results performing a minimal
> install and adding to it afterward", which kinda is recommending that
> people do exactly the thing that doesn't work (do a minimal install
> then use dnf on it), and implying it'll work.
>
> After some consideration I don't think it makes sense to take this bug
> as an F37 blocker, since it already affects F36, and that's what I'll
> be suggesting at the next blocker review meeting. However, it does seem
> a perfect candidate for prioritized bug status, and I've nominated it
> for that.

I agree, this needn't block F37, but I still think that this should be
fixed. Unless I use microdnf, I cannot upgrade my VPS with 1GB RAM that
happily hosts my home page, which is quite a bummer and a bit of a shame
to be honest.


Cheers,

Dan
___
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: How text files / documentation affect package licensing

[Dan Čermák]

On August 10, 2022 7:18:35 PM UTC, Jerry James  wrote:
>On Wed, Aug 10, 2022 at 12:52 PM Dan Čermák
> wrote:
>> I think that there's another pitfall here: if you e.g. build a HTML 
>> documentation, then you should (?) include the license of all the bundled 
>> fonts, CSS and JavaScript as well. I'm afraid we mostly don't do this at all.
>
>Right.  Documentation builders such as doxygen and python-sphinx drop
>CSS, JavaScript, and image files into the built documentation.  Those
>may carry the license of the documentation builder, or an entirely
>different license.  If those documentation builders each provided a
>subpackage that contains the stuff that might be copied into
>documentation, then we could swizzle our documentation packages to use
>symlinks into those subpackages.  I'm not clear on how that would
>affect the licensing, though.  Also, that means that if you update
>your documentation builder so that the static stuff is not backwards
>compatible, you have to rebuild everything that uses it.  That might
>be more pain than we want to deal with.
>
>> PDF would be probably a lot safer.
>
>Then we have to worry about the licenses of embedded fonts, right?

Yes, but AFAIK HTML documentation also pulls in fonts.
___
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: dnf makecache memory usage increase

[Dan Čermák]

Stephen Smoogen  writes:

> On Mon, 1 Aug 2022 at 07:45, Dusty Mabe  wrote:
>
>>
>>
>> On 7/29/22 12:05, Peter Robinson wrote:
>> >> Looks like dnf makecache is uses a lot more memory, causing issues on
>> >> smaller systems/containers.
>> >>
>> >> F34:
>> >>
>> >> Metadata cache created.
>> >> 1.51user 0.15system 0:12.01elapsed 13%CPU (0avgtext+0avgdata
>> 162440maxresident)k
>> >> 144inputs+56outputs (0major+46906minor)pagefaults 0swaps
>> >>
>> >>
>> >> F35:
>> >>
>> >> Metadata cache created.
>> >> 29.28user 2.15system 0:49.94elapsed 62%CPU (0avgtext+0avgdata
>> 841704maxresident)k
>> >> 184160inputs+497320outputs (181major+425900minor)pagefaults 0swaps
>> >>
>> >> Is this a known issue?
>> >
>> > I've seen it on arm systems with 512Mb RAM which previously ran dnf
>> > (not just makecache) fine and now don't. There was a bug opened but
>> > the dnf team closed it.
>>
>>
>> Seems like this bug is related
>> https://bugzilla.redhat.com/show_bug.cgi?id=1907030
>>
>> We are hitting this issue in Fedora CoreOS CI on VMs with 1G of RAM.
>>
>
> I wonder if this is one of those problems where microdnf needs to be used
> until the full dnf rewrite in C++ is done.  I remember something about
> memory usage and dnf vs microdnf a while ago for smaller memory systems..
> and with the general 'we need to double memory usage' every couple of
> releases that applications have ... maybe 1Gb is no longer valid?

It definitely is no longer valid. I am running Fedora Server on a 1 GB
RAM VPS and unless I kill everything on that box (including the
firewall), I can't run dnf upgrade...


Cheers,

Dan
___
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: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Dan Čermák]

David Malcolm  writes:

> On Mon, 2022-07-18 at 13:29 -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/Emacs_28
>> 
>> 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 ==
>> 
>> Update GNU Emacs to 28.1 release. This release includes a wide
>> variety
>> of new features, including native compilation of Lisp files.
>> 
>> == Owner ==
>> 
>> * Name: [[User:Bhavin192| Bhavin Gandhi]]
>> * Email: bhavin...@fedoraproject.org
>> 
>> 
>> == Detailed Description ==
>> 
>> The Emacs package will be updated to 28.1 release of GNU Emacs. This
>> will have native compilation feature enabled, and will package
>> additional natively compiled Lisp files.
>
> Does this add a Requires: on libgccjit, or just a BuildRequires: on
> libgccjit?

It adds a requires as well:
❯ ldd (which emacs)|grep gcc
libgccjit.so.0 => /lib64/libgccjit.so.0 (0x7fd0d463d000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fd0d4622000)

❯ rpm -qR emacs|grep gcc
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libgcc_s.so.1(GCC_3.3.1)(64bit)
libgccjit
libgccjit.so.0()(64bit)
libgccjit.so.0(LIBGCCJIT_ABI_0)(64bit)
libgccjit.so.0(LIBGCCJIT_ABI_1)(64bit)
libgccjit.so.0(LIBGCCJIT_ABI_11)(64bit)
libgccjit.so.0(LIBGCCJIT_ABI_13)(64bit)
libgccjit.so.0(LIBGCCJIT_ABI_14)(64bit)


Cheers,

Dan
___
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: Retiring the pcre package from Fedora

[Dan Čermák]

Hi,

Lukas Javorsky  writes:

> i3
> i3-gaps

there is a patch to make i3 (and thus i3-gaps) compatible with pcre2 [1],
which has been merged upstream. I can cherry pick it and rebuild i3 in
Rawhide without requiring pcre, if this is urgent. Otherwise I'd rather
wait for the next upstream release.


Cheers,

Dan

Footnotes:
[1]  https://github.com/i3/i3/pull/4684
___
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: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Dan Čermák]

Hi Kevin and all,

"Kevin P. Fleming"  writes:

> On 7/20/22 14:57, Marcus Müller wrote:
>> Oh! That comes as a surprise. Let me try a rebuild!
>>
>> :( I was really looking forward to emacs-pgtk.
>>
> Forgive my relative newbie-ness here, but this proposal is to upgrade 
> Emacs to version 28 in F37. That seems fine.
>
> This week my F36 system got upgraded to Emacs version 28, so it's 
> already in F36. How is that possible?

Apologies, this is my fault. After the Emacs 28 PR got merged, I went
ahead, built Emacs in Fedora 36 as well and submitted it as an
update [1] (after one borked attempt before), which got quickly pushed
to stable.

Sorry for breaking your packages Jerry. Maybe we should add some gating
tests to prevent this kind of breakage in the future. Would you have
some details what happened?


Sorry for this mess,

Dan

Footnotes:
[1]  https://bodhi.fedoraproject.org/updates/FEDORA-2022-d75f0c2a4a
___
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: F37 proposal: SELinux Parallel Autorelabel (Self-Contained Change proposal)

[Dan Čermák]

On July 15, 2022 9:42:35 PM UTC, Ben Cotton  wrote:
>https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel
>
>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 ==
>After a system's SELinux mode is switched from disabled to enabled, or
>after an administrator runs `fixfiles onboot`, SELinux autorelabel
>will be run in parallel by default.
>
>== Owner ==
>* Name: [[User:plautrba| Petr Lautrbach]]
>* Email: plaut...@redhat.com
>
>
>== Detailed Description ==
>SELinux tools `restorecon` and `fixfiles` recently gained the ability
>to relabel files in parallel using the `-T nthreads` option. This
>option is currently not used in the automatic relabel after reboot.
>When users want/need the parallel relabeling they have to specify the
>option explicitly (e.g. `fixfiles -T 0 onboot`). With this change `-T
>0` (0 == use all available CPU cores) will be the default for
>`fixfiles onboot` and users will have to use `fixfiles -T 1 onboot` to
>force it to use only one thread.
>
>The rationale is that when autorelabel runs, there are no other
>resource-intensive processes running on the system, so it's fine (and
>actually better) to use all available parallelism to speed up the task
>and get to a fully booted system faster.
>
>
>== Benefit to Fedora ==
>Faster reboot after switching back to an SELinux enabled system or
>when triggering autorelabel explicitly.

Just out of curiosity, how large is the speedup typically?

>
>== Scope ==
>* Proposal owners:
>** Update `/usr/libexec/selinux/selinux-autorelabel` to use `-T 0` by default.
>
>* Other developers:
>* Release engineering:
>* Policies and guidelines: N/A (not needed for this Change)
>* Trademark approval: N/A (not needed for this Change)
>* Alignment with Objectives:
>
>
>== Upgrade/compatibility impact ==
>
>
>== How To Test ==
># boot with SELinux disabled - add `selinux=0` to the kernel command line
># reboot
># store the time it took
># run `fixfiles -T 1 onboot`
># reboot
># the latter reboot should take longer time
>
>
>== User Experience ==
>Systems should be up and running faster after SELinux autorelabel.
>
>== Dependencies ==
>
>
>== Contingency Plan ==
>* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
>System Wide Change)
>* Contingency deadline: N/A (not a System Wide Change)
>* Blocks release? N/A (not a System Wide Change), Yes/No
>
>== Documentation ==
>
>N/A (not a System Wide Change)
>
>
___
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: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)

[Dan Čermák]

Hi,

On July 15, 2022 9:30:48 PM UTC, Ben Cotton  wrote:
>https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image
>
>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 ==
>The work on Web UI for the Anaconda installer has advanced enough so
>that it is possible to create and publish self contained preview
>images.
>
>== Owner ==
>* Name: [[User:m4rtink| Martin Kolman]]
>* Email: mkol...@redhat.com
>
>
>== Detailed Description ==
>Even though still very simple the new Anaconda Web UI is now far
>enough to support a simple installation workflow from a self-contained
>image while demonstrating all the main aspects of the new UI, such as:
>
>* flexible Wizard layout
>* responsive PatternFly components
>* new style built-in help
>* local and remote access to the Web UI
>
>For this we will create a self-contained boot.iso style image with a
>built-in tar-payload (so that the image can work even without network
>access) based on the latest Anaconda upstream code.
>
>We aim to have the image available for download just after the F37
>release (so that the tar-payload can contain final F37 release
>content) and then updated automatically in regular intervals.
>
>That way the rather active Web UI development of the Web UI will be
>reflected in the up-to-date installation image, as well as any
>feedback and community PRs.
>
>
>== Benefit to Fedora ==
>The Anaconda Web UI will provide modern responsive user interface
>based on a well known
>and widely used toolkit (PatternFly) and backed by proven Cockpit tooling.
>
>The screen layout is based on latest UX design guidelines as well as
>usability testing of the new interface and extensive mockup work.
>
>There are improvements in developer experience as well due to the more
>modern & more mainstream UI technology chosen and powerful Cockpit
>test tooling (rich unit-test as well as pixel-test framework). The
>stateless property of the Web UI allows almost live-coding style of UI
>development. This should make it easier to work on the Anaconda Web UI
>for not only the Anaconda team, addon developer but also for any
>interested contributors.
>
>Remote Web UI access should also provide a much better experience than
>the slow and inefficient VNC based remote GUI installation support
>Anaconda has today. Due to no need for local rendering remotely driven
>GUI installations on a constrained hardware with minimal installation
>images should become possible.
>
>
>== Scope ==
>* Proposal owners:
>The Anaconda team will setup and maintain an automated Web UI preview
>image creation pipeline, with the image being available via a web
>server on the Fedora infrastructure.
>
>It will be a '''preview image only''', not an official Fedora
>deliverable and it will not influence Fedora release criteria in any
>way.
>
>* Other developers:
>Other developers and Fedora users are welcome to try the image once it
>is released and to provide feedback.
>
>* Release engineering:
>* Policies and guidelines: N/A (not needed for this Change)
>* Trademark approval: N/A (not needed for this Change)
>* Alignment with Objectives:
>
>
>== Upgrade/compatibility impact ==
>(not supplied)
>
>
>== How To Test ==
>Download the Anaconda Web UI preview image and boot it on VM or
>hardware that contains no important data.
>
>Install using the Web UI locally, alternatively try using the Web UI remotely.
>
>The installed OS should be functional but its testing or any issues
>with it are currently out of scope for the Anaconda Web UI preview
>image.

Do you have any plans to integrate this with the Fedora openQA tests? That 
would automatically give you some basic coverage for the functionality of the 
installed system.

>To provide feedback use one of the Anaconda team communication channels:
>
>* IRC: [https://web.libera.chat/#anaconda #anaconda] on libera.chat
>* mailing list: anaconda-de...@lists.fedoraproject.org -
>https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org/
>* Github Discussion: https://github.com/rhinstaller/anaconda/discussions
>
>
>== User Experience ==
>Should be improved compared to the current GTK interface.
>
>== Dependencies ==
>(not supplied)
>
>
>== Contingency Plan ==
>* Contingency mechanism: If we hit some blocking technical issues, the
>image will be published later.
>* Contingency deadline: N/A (not a System Wide Change)
>* Blocks release? N/A (not a System Wide Change), Yes/No
>
>
>== Documentation ==
>N/A (not a System Wide Change)
>
>
___
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: 

Re: proposal idea: EOL notifications

[Dan Čermák]

Hi,

On July 6, 2022 3:44:49 PM UTC, "Zbigniew Jędrzejewski-Szmek" 
 wrote:
>Hi,
>
>In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
>notification when a Fedora stops being supported. Various proposals
>for online checks were discussed in the bug, but I think we might make
>do with something much simpler.
>
>https://github.com/systemd/systemd/pull/23924 proposes adding
>SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
>e.g. pop up a desktop notification when that date is close, and a
>bigger redder notification once it has been passed. The date could be
>set to some initial value even on the initial release, and then
>adjusted through updates to fedora-release.rpm if our schedule slips.
>I guess we could add a notification during boot in systemd itself, but
>most users wouldn't see that, so a graphical notification would also
>be needed.
>
>The advantage of this proposal that it is very simple and will work
>even on machines that don't have network connectivity, and can be easily
>integrated into various DEs and tools.
>
>WDYT?

I like this idea! As long as we never move an eol earlier, I see very little 
potential issues.


Cheers,

Dan
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Dan Čermák]

Kevin Kofler via devel  writes:

> Fabio Valentini wrote:
>> And if we say this argument is valid, then should we also build all our
>> packages with ASAN / TSAN / etc. instrumentation, as well?
>
> And ASAN would actually have tangible benefits for end users, namely 
> preventing some memory bug exploits, whereas frame pointers only slow things 
> down and are of no use whatsoever for non-developer users (and even most 
> developers).

Please never run ASAN in production workloads:
https://www.openwall.com/lists/oss-security/2016/02/17/9

tl;dr; you'll create a local root exploit.



Cheers,

Dan
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Dan Čermák]

On July 4, 2022 2:54:11 PM UTC, Kevin Kofler via devel 
 wrote:
>Daan De Meyer via devel wrote:
>> As mentioned in the change proposal, when using sampling profilers that
>> rely on fast access to the stacktrace, there is currently no viable
>> alternative to frame pointers. DWARF unwinding in absence of frame
>> pointers is too slow because of the complexity of the DWARF format and the
>> necessity to copy the stack to userspace and do unwinding there due to the
>> lack of an in kernel DWARF unwinder.
>
>And as already pointed out several times in this thread, that is a very 
>niche use case for which you cannot hold the entire Fedora community 
>hostage. This is not Facebook Linux.
>
>I do not know anybody personally who runs 24/7 profiling in production as 
>you apparently do.

I think Kevin has a point here. This change will degrade the performance of 
everyone at all times so that a minority can run their very niche use case. I 
would thus suggest that if you really need this in production, that you rebuild 
just the packages that you need with the additional flags in koji, copr or obs 
and use these instead of making everyone pay the price.

If it turns out that the performance hit is really negligible (especially on 
register starved architectures), then I'd be more than happy to revisit the 
topic. There's really no need for duplicate work if it has no negative impact 
on the majority of our users.


Cheers,

Dan
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Dan Čermák]

Hi,

On June 16, 2022 8:53:59 PM UTC, Ben Cotton  wrote:
>https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
>
>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 ==
>
>Fedora will add -fno-omit-frame-pointer to the default C/C++
>compilation flags, which will improve the effectiveness of profiling
>and debugging tools.
>
>== Owner ==
>* Name: [[User:daandemeyer| Daan De Meyer]], [[User:Dcavalca| Davide
>Cavalca]], [[ Andrii Nakryiko]]
>* Email: daandeme...@fb.com, dcava...@fb.com, andr...@fb.com
>
>
>== Detailed Description ==
>
>Credits to Mirek Klimos, whose internal note on stacktrace unwinding
>formed the basis for this change proposal (myre...@gmail.com).
>
>Any performance or efficiency work relies on accurate profiling data.
>Sampling profilers probe the target program's call stack at regular
>intervals and store the stack traces. If we collect enough of them, we
>can closely approximate the real cost of a library or function with
>minimal runtime overhead.
>
>Stack trace capture what’s running on a thread. It should start with
>clone - if the thread was created via clone syscall - or with _start -
>if it’s the main thread of the process. The last function in the stack
>trace is code that CPU is currently executing. If a stack starts with
>[unknown] or any other symbol, it means it's not complete.
>
>=== Unwinding ===
>
>How does the profiler get the list of function names? There are two parts of 
>it:
>
># Unwinding the stack - getting a list of virtual addresses pointing
>to the executable code
># Symbolization - translating virtual addresses into human-readable
>information, like function name, inlined functions at the address, or
>file name and line number.
>
>Unwinding is what we're interested in for the purpose of this
>proposal. The important things are:
>
>* Data on stack is split into frames, each frame belonging to one function.
>* Right before each function call, the return address is put on the
>stack. This is the instruction address in the caller to which we will
>eventually return — and that's what we care about.
>* One register, called the "frame pointer" or "base pointer" register
>(RBP), is traditionally used to point to the beginning of the current
>frame. Every function should back up RBP onto the stack and set it
>properly at the very beginning.
>
>The “frame pointer” part is achieved by adding push %rbp, mov
>%rsp,%rbp to the beginning of every function and by adding pop %rbp
>before returning. Using this knowledge, stack unwinding boils down to
>traversing a linked list:
>
>https://i.imgur.com/P6pFdPD.png

As you specifically use x86_64 assembly as an example here: have you looked on 
the impact this will have on other architectures like arm or riscv?


Cheers,

Dan

>
>=== Where’s the catch? ===
>
>The frame pointer register is not necessary to run a compiled binary.
>It makes it easy to unwind the stack, and some debugging tools rely on
>frame pointers, but the compiler knows how much data it put on the
>stack, so it can generate code that doesn't need the RBP. Not using
>the frame pointer register can make a program more efficient:
>
>* We don’t need to back up the value of the register onto the stack,
>which saves 3 instructions per function.
>* We can treat the RBP as a general-purpose register and use it for
>something else.
>
>Whether the compiler sets frame pointer or not is controlled by the
>-fomit-frame-pointer flag and the default is "omit", meaning we can’t
>use this method of stack unwinding by default.
>
>To make it possible to rely on the frame pointer being available,
>we'll add -fno-omit-frame-pointer to the default C/C++ compilation
>flags. This will instruct the compiler to make sure the frame pointer
>is always available. This will in turn allow profiling tools to
>provide accurate performance data which can drive performance
>improvements in core libraries and executables.
>
>== Feedback ==
>
>=== Potential performance impact ===
>
>* Meta builds all its libraries and executables with
>-fno-omit-frame-pointer by default. Internal benchmarks did not show
>significant impact on performance when omitting the frame pointer for
>two of our most performance intensive applications.
>* Firefox recently landed a change to preserve the frame pointer in
>all jitted code
>(https://bugzilla.mozilla.org/show_bug.cgi?id=1426134). No significant
>decrease in performance was observed.
>* Kernel 4.8 frame pointer benchmarks by Suse showed 5%-10%
>regressions in some benchmarks
>(https://lore.kernel.org/all/20170602104048.jkkzssljsompj...@suse.de/T/#u)
>
>Should individual libraries or executables notice a significant
>performance degradation caused by including the frame pointer
>everywhere, these packages can opt-out on an individual basis as

Re: Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates

[Dan Čermák]

Sounds like a great addition Adam!

Just to double check: if you have not enabled gating, then openQA will not be 
run at all?


Cheers,

Dan

On June 9, 2022 7:48:29 PM UTC, Adam Williamson  
wrote:
>Hi folks!
>
>We've had openQA testing of updates for stable and branched releases,
>and gating based on those tests, enabled for a while now. I believe
>this is going quite well, and I think we addressed the issues reported
>when we first enabled gating - Bodhi's gating status updates work more
>smoothly now, and openQA respects Bodhi's "re-run tests" button so
>failed tests can be re-triggered.
>
>A few weeks ago, I enabled testing of Rawhide updates in the openQA
>lab/stg instance. This was to see how smoothly the tests run, how often
>we run into unexpected failures or problems, and whether the hardware
>resources we have are sufficient for the extra load.
>
>So far this has been going more smoothly than I anticipated, if
>anything. The workers seem to keep up with the test load, even though
>one out of three worker systems for the stg instance is currently out
>of commission (we're using it to investigate a bug). We do get
>occasional failures which seem to be related to Rawhide kernel slowness
>(e.g. operations timing out that usually don't otherwise time out), but
>on the whole, the level of false failures is (I would say) acceptably
>low, enough that my current regime of checking the test results daily
>and restarting failed ones that don't seem to indicate a real bug
>should be sufficient.
>
>So, I'd like to propose that we enable Rawhide update testing on the
>production openQA instance also. This would cause results to appear on
>the Automated Tests tab in Bodhi, but they would be only informational
>(and unless the update was gated by a CI test, or somehow otherwise
>configured not to be pushed automatically, updates would continue to be
>pushed 'stable' almost immediately on creation, regardless of the
>openQA results).
>
>More significantly, I'd also propose that we turn on gating on openQA
>results for Rawhide updates. This would mean Rawhide updates would be
>held from going 'stable' (and included in the next compose) until the
>gating openQA tests had run and passed. We may want to do this a bit
>after turning on the tests; perhaps Fedora 37 branch point would be a
>natural time to do it.
>
>Currently this would usually mean a wait from update submission to
>'stable push' (which really means that the build goes into the
>buildroot, and will go into the next Rawhide compose when it happens)
>of somewhere between 45 minutes and a couple of hours. It would also
>mean that if Rawhide updates for inter-dependent packages are not
>correctly grouped, the dependent update(s) will fail testing and be
>gated until the update they depend on has passed testing and been
>pushed. The tests for the dependent update(s) would then need to be re-
>run, either by someone hitting the button in Bodhi or an openQA admin
>noticing and restarting them, before the dependent update(s) could be
>pushed.
>
>In the worst case, if updated packages A and B both need the other to
>work correctly but the updates are submitted separately, both updates
>may fail tests and be blocked. This could only be resolved by waiving
>the failures, or replacing the separate updates with an update
>containing both packages.
>
>All of those considerations are already true for stable and branched
>releases, but people are probably more used to grouping updates for
>stable and branched than doing it for Rawhide, and the typical flow of
>going from a build to an update provides more opportunity to create
>grouped updates for branched/stable. For Rawhide the easiest way to do
>it if you need to do it is to do the builds in a side tag and use
>Bodhi's ability to create updates from a side tag.
>
>As with branched/stable, only critical path updates would have the
>tests run and be gated on the results. Non-critpath updates would be
>unaffected. (There's a small allowlist of non-critpath packages for
>which the tests are also run, but they are not currently gated on the
>results).
>
>I think doing this could really help us keep Rawhide solid and avoid
>introducing major compose-breaking bugs, at minimal cost. But it's a
>significant change and I wanted to see what folks think. In particular,
>if you find the existing gating of updates for stable/branched releases
>to cause problems in any way, I'd love to hear about it.
>
>Thanks folks!
___
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: News from printing world aka PWG May 2022 meetup

[Dan Čermák]

Hi Petře,

Petr Menšík  writes:

> Thank you for that COPR repository.
>
> I think using SNAPs on Fedora is wrong. I don't like what snaps do with 
> mounted filesystems and consider flatpak more appropriate replacement. 
> But flatpak wants to isolate application from the system. Those apps 
> require to integrate into the system on the other hand.
>
> I assume from provided explanation that printer apps needs direct access 
> to USB ports and therefore are not good candidate for placing into some 
> kind of container. It needs a direct access to the host hardware, 
> therefore it belongs to the system. Or is it possible to forward just 
> limited sets of of USB devices into a container?
>
> Could perhaps alternative package with unreleased snapshots be provided? 
> That would allow packaging required printer apps, which cannot use 
> stable versions. Should be module considered for applications and new 
> version of cups filters?

Have you considered putting CUPS into a module and provide a stable &
unreleased stream?


Cheers,

Dan
___
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: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

[Dan Čermák]

Maxwell G via devel  writes:

> On Tuesday, May 17, 2022 10:06:44 AM CDT Miroslav Suchý wrote:
>> > Do we need to %if-%else it in the spec file? I recall some discussion 
>> > about this on the legal list, but I see no 
>> > guidelines proposed here. 
>> 
>> If you maintain one spec for all branches then you will need %if-%else. And 
>> yes, it works.
>> 
> If that ends up being the policy, it would be nice if there was a convenience 
> macro that was set to 1 on branches that allow SPDX identifiers.

I would welcome this as well, as I try to keep my dist-git history
linear.


Cheers,

Dan
___
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: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)

[Dan Čermák]

Hi David,

David Woodhouse  writes:

> On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote:
>> 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.
>> 
>> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1
>> 
>> 
>> == Summary ==
>> 
>> Cryptographic policies will be tightened in Fedora 38-39,
>> SHA-1 signatures will no longer be trusted by default.
>> Fedora 37 specifically doesn't come with any change of defaults,
>> and this Fedora Change is an advance warning filed for extra visibility.
>> Test your setup with FUTURE today and file bugs so you won't get bit
>> by Fedora 38-39.
>> 
>
> Changes like this have been very disruptive in the past because they
> haven't been completely thought through.
>
> Can we please make 100% sure these policies are not going to break
> things like VPN clients in the way that we have before.

They are going to break things, but Ubuntu 22.04 deprecated SHA1
signatures already, so it's very likely that a good chunk of the fallout
will be cleared by the time Fedora 38 and 39 ship.


Cheers,

Dan
___
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: FESCo wants to know what you use i686 packages for

[Dan Čermák]

Felix Schwarz  writes:

> I use wine and lutris (+ 32bit mingw packages).

Yes, same here
___
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

[EPEL-devel] Re: RHEL moving to issues.redhat.com only long term

[Dan Čermák]

Hi Adam,

Adam Williamson  writes:

> snip

> That could obviously have pretty significant consequences for Fedora.
> Bugzilla isn't only an issue tracker for Fedora; we run some
> significant processes through it, notably the Change process, the
> blocker/FE bug process, and the prioritized bug process. In A World
> Without Bugzilla all of those would need adapting (and their
> documentation updating). There's fairly tight integration between Bodhi
> and Bugzilla, which would need to be redesigned. Those are just things
> I can think of off the top of my head. There are also a couple of
> decades worth of internet links to Fedora issues on RH Bugzilla, of
> course.
>
> I guess the two big choices for Fedora if RH said "we're not
> maintaining Bugzilla any more" would be 1) take over maintaining
> Bugzilla or 2) switch to something else. 1) would probably be the path
> of least resistance, I guess.

Short term it is the path of the least resistance, but at least what
I've heard from $dayjob, maintaining a Bugzilla instance is no easy
task, as they are often customized (via non-upstream patches) and this
all needs to be maintained. I cannot speak for our infra team, but I
really don't know if they'd like yet another huge service, because this
effectively means they'd have to take over maintenance of
bugzilla.redhat.com...

>
> This does also kinda lead to a larger question for me, trying to wear
> both Red Hat and Fedora hats at the same time[0]. I wonder if we're
> kind of lacking a...mechanism, for want of a better word, to handle the
> *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora
> project" first started. At that point Fedora and Red Hat shared a lot
> of tooling and infrastructure, and this was useful to both sides in
> many ways; it saves on development costs and it makes it easy for
> people to work in both worlds. With my Red Hat on, I think I'm allowed
> to say that internally we often talk about this being desirable -
> having consistency between how X is done in Fedora and how it's done
> for RHEL - and it obviously has benefits to Fedora too (it means we
> don't have to find the resources to do that same work at Fedora level).
>
> However, situations like this make me wonder if we might have an issue
> with keeping shared infra/tooling where it's desirable. It seems like
> this is a decision/conversation that's been happening within RH, about
> what makes sense for RH in terms of RHEL development. AFAIK this is the
> first time it's been formally talked about in a Fedora context, and the
> messaging is "RH has already decided to stop using Bugzilla for RHEL
> after 9". In other words, RH has decided on its own to move away from
> something that is part of the shared RH/Fedora "heritage way of doing
> things".
>
> I'm not saying that's wrong, but as I said it does make me wonder
> whether, if both sides do find shared tooling/approaches beneficial, we
> might want to approach this kind of potential change differently in
> future. Otherwise it does seem like we could sort of gradually drift
> apart, with no explicit intention to do so, and lose the benefits of
> shared tooling and process. Unless the ultimate outcome of this is
> "Fedora adopts issues.redhat.com for bug tracking" - which would be a
> possibility, but doesn't seem like a certainty - the result will be
> that we go from having a shared bug tracker, with the benefits of
> shared maintenance and being able to easily clone or reference bugs
> between Fedora and RHEL, to each maintaining our own bug tracker and
> not having those benefits.
>
> Of course, there would be sensitivities in developing such a process -
> it could look a lot like Red Hat telling Fedora how to do stuff, which
> I think isn't exactly the relationship we want to have. But at the same
> time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop
> using this thing they'd previously both used" is always the best choice
> either.

No, certainly not. I think it would have been nice if the tooling
discussion happened before RH decided to drop Bugzilla so that we can
all use a common tooling. However, I also know that in a business
sometimes reaching such a consensus is everything but easy. It would
have been nice if someone at least tried though.


Cheers,

Dan
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RHEL moving to issues.redhat.com only long term

[Dan Čermák]

Hi Adam,

Adam Williamson  writes:

> snip

> That could obviously have pretty significant consequences for Fedora.
> Bugzilla isn't only an issue tracker for Fedora; we run some
> significant processes through it, notably the Change process, the
> blocker/FE bug process, and the prioritized bug process. In A World
> Without Bugzilla all of those would need adapting (and their
> documentation updating). There's fairly tight integration between Bodhi
> and Bugzilla, which would need to be redesigned. Those are just things
> I can think of off the top of my head. There are also a couple of
> decades worth of internet links to Fedora issues on RH Bugzilla, of
> course.
>
> I guess the two big choices for Fedora if RH said "we're not
> maintaining Bugzilla any more" would be 1) take over maintaining
> Bugzilla or 2) switch to something else. 1) would probably be the path
> of least resistance, I guess.

Short term it is the path of the least resistance, but at least what
I've heard from $dayjob, maintaining a Bugzilla instance is no easy
task, as they are often customized (via non-upstream patches) and this
all needs to be maintained. I cannot speak for our infra team, but I
really don't know if they'd like yet another huge service, because this
effectively means they'd have to take over maintenance of
bugzilla.redhat.com...

>
> This does also kinda lead to a larger question for me, trying to wear
> both Red Hat and Fedora hats at the same time[0]. I wonder if we're
> kind of lacking a...mechanism, for want of a better word, to handle the
> *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora
> project" first started. At that point Fedora and Red Hat shared a lot
> of tooling and infrastructure, and this was useful to both sides in
> many ways; it saves on development costs and it makes it easy for
> people to work in both worlds. With my Red Hat on, I think I'm allowed
> to say that internally we often talk about this being desirable -
> having consistency between how X is done in Fedora and how it's done
> for RHEL - and it obviously has benefits to Fedora too (it means we
> don't have to find the resources to do that same work at Fedora level).
>
> However, situations like this make me wonder if we might have an issue
> with keeping shared infra/tooling where it's desirable. It seems like
> this is a decision/conversation that's been happening within RH, about
> what makes sense for RH in terms of RHEL development. AFAIK this is the
> first time it's been formally talked about in a Fedora context, and the
> messaging is "RH has already decided to stop using Bugzilla for RHEL
> after 9". In other words, RH has decided on its own to move away from
> something that is part of the shared RH/Fedora "heritage way of doing
> things".
>
> I'm not saying that's wrong, but as I said it does make me wonder
> whether, if both sides do find shared tooling/approaches beneficial, we
> might want to approach this kind of potential change differently in
> future. Otherwise it does seem like we could sort of gradually drift
> apart, with no explicit intention to do so, and lose the benefits of
> shared tooling and process. Unless the ultimate outcome of this is
> "Fedora adopts issues.redhat.com for bug tracking" - which would be a
> possibility, but doesn't seem like a certainty - the result will be
> that we go from having a shared bug tracker, with the benefits of
> shared maintenance and being able to easily clone or reference bugs
> between Fedora and RHEL, to each maintaining our own bug tracker and
> not having those benefits.
>
> Of course, there would be sensitivities in developing such a process -
> it could look a lot like Red Hat telling Fedora how to do stuff, which
> I think isn't exactly the relationship we want to have. But at the same
> time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop
> using this thing they'd previously both used" is always the best choice
> either.

No, certainly not. I think it would have been nice if the tooling
discussion happened before RH decided to drop Bugzilla so that we can
all use a common tooling. However, I also know that in a business
sometimes reaching such a consensus is everything but easy. It would
have been nice if someone at least tried though.


Cheers,

Dan
___
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: VERY late notification emails

[Dan Čermák]

On March 5, 2022 9:03:54 AM UTC, Gary Buhrmaster  
wrote:
>On Mon, Feb 28, 2022 at 5:25 PM Kevin Fenzi  wrote:
>
>> No, there's things we can do and are trying to do. ;)
>
>I seem to remember that one of the issues
>identified was (for those of us using gmail
>for the notifications) was that google could
>end up throttling emails.
>
>I have a vague recollection that google has
>numerous recommendations to mitigate
>against throttling (including DKIM and SPF),
>in addition to a method in which one can
>reduce certain delays for "buik" email
>and also monitor for issues ((I think via
>postmaster.google.com?)
>
>I am going to presume that these resources
>have been investigated and you have looked
>at the google monitoring information.  Can
>you share why the emails are getting delayed
>according to Google?

It's definitely not just Google, I keep getting delayed emails as well and my 
emails are not hosted by a big provider.


Cheers,

Dan
___
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: Need advice on NET_ADMIN capability on a binary (iotop-c)

[Dan Čermák]

Hi Boian,

On February 20, 2022 12:49:53 AM UTC, Boian Bonev  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Hello,
>
>I have got a pull request [1] that implements installing iotop-c with the
>NET_ADMIN capability by default and I am trying to evaluate if that is OK or
>not.
>
>Currently iotop-c will only allow to be run as root. In case it is run as some
>other user, it will advise to use sudo, or alternatively add the NET_ADMIN
>capability to the binary:
>
>sudo setcap 'cap_net_admin+eip' /iotop
>
>Obviously that will have to be redone after each update, adding some
>inconvenience for admins who decide to allow that for non-root users. 

This is not really an answer to the security question, but if that remains 
unresolved, you could also introduce a sub package to iotop-c, that would 
contain a transaction file trigger on the binary and add the capability. Thus 
user would be able to opt into having iotop-c with the added capability even 
after upgrades, as long as the sub package is installed.

> I have
>never considered installing it suid - that would be an overkill and may
>introduce security problems. I always use it as root and have never given that
>too much thought, also never before did deep analyses of the consequences of
>the above setcap.
>
>Here is a brief list of the consequences of allowing non-root users to run it
>by the setcap:
>
>- - Process IO usage will be exposed [maybe OK]
>- - Process list and command lines will be exposed (same as other tops) [safe]
>- - Re-nicing own processes to rt/* will not work [safe]
>- - Re-nicing non-own processes will not work [safe]
>- - task_delayacct sysctl toggle (Ctrl-T) will not work [safe]
>- - There are no other networking operations besides TASKSTATS from
>NETLINK_GENERIC that would allow the unprivileged user do privileged tasks via
>the higher capped binary [safe]
>
>As a summary it seems that accepting the PR is 99% OK, but I'd prefer to get
>more opinions before doing so.
>
>With best regards,
>b.
>
>[1] https://src.fedoraproject.org/rpms/iotop-c/pull-request/1
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmIRkDEACgkQE2VyCRPS
>8i32ww//dRzxVtff8+8qQ2ujLwf49ZigGdawkgdnJRuE+0oBDV30yycENblSLNWB
>8FlidJcA+ZkoWf9WyoRvXydPcnuEhsr7y9UxyS/XA6l4iHHpUn7SJ/i79KAmVb8J
>uuyWDBa23fZ4P22fy8/EklCzACWDeiYwS/jv+fwr8oLjEZ6nG+kjmMDIx5I2oA8J
>vAfhCRLSTBXTQnWRs9MMxMIjQ9dcTvzOdv8ZPq+lVJuG6xrinLrH00XWLmDC7Dgh
>/Ie2hvuHFCmId8BBAN5I47bh57ly4aZH0QKVpQL7x5bOYJDF1R27NHW660MxFZay
>4xCZwYkLBcUtcm9R9SG8cZCd0nDptMRwmpvxu26QgFFl5hJgngdq4xmp3xsS/W2Y
>JmQ7eTB+ypCVzd0QiQNHIfP1I+6NQbbakA+YIfiT9Uk1Z610IsO3cGW3tr2mSiBW
>5/2fb2kU/vK4f2QPFwXJU8PYdJO/c9/zTFoRHomWG/MQx0zhNM8h0sK1tdxLp4V2
>wuU/8wihpJx+rAofbmf2FrLowRYshiKqKeGYEWiWHLUAqWWKlBXkBiV5PY8l/YNx
>Ta8Kd9aK00aezFmYa3TOHQyJYBuChdp/zqYfhRfRveXKj3TJMRW9MlgDtvuXXfUu
>ukpSZWgR8twIhh+1QlS5rWZILIyVcdd0lNOSUYb2/i41bSREXkA=
>=EJ2s
>-END PGP SIGNATURE-
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://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: IMA signing notes and code

[Dan Čermák]

Hi Ken,

On February 14, 2022 5:10:41 PM UTC, Ken Dreyer  wrote:
>Hi folks,
>
>I've been researching IMA signing with RPM. This is a new feature in
>CentOS 9 that has not been enabled in Fedora
>
>I'm not an IMA expert, and I don't work on this for Red Hat, I'm just
>an interested user. (In particular, I'm interested in how our build
>systems track signatures, and how those get passed along the rest of
>the pipeline.)
>
>I'm finding there's no simple "guide to RPM and IMA" where I might
>contribute further documentation, so for now I've posted my notes and
>code to https://github.com/ktdreyer/ima
>
>It would be great to build some sort of documentation site that
>explains this stuff, but it's unclear to me what is the RPM team's
>responsibility vs other teams, etc. See
>https://github.com/rpm-software-management/rpm-web/issues/28 for
>example - RPM has a new "FILESIGNATURES" header, but no docs for that.
>
>What's a better place for this documentation to live?

I suppose that the RPM specifics should go into RPM's documentation. And 
everything else that covers the Fedora bits and pieces, like copr, koji, pungi, 
etc should go to docs.fedoraproject.org.


Cheers,

Dan
___
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: Do we have any policy for disabling inactive users

[Dan Čermák]

Mattia Verga via devel  writes:

> Il 11/02/22 07:54, Zbigniew Jędrzejewski-Szmek ha scritto:
>> On Thu, Feb 10, 2022 at 11:05:03PM +, Gary Buhrmaster wrote:
>>> On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton  wrote:
>>>
 I have concerns with this approach. I would guess there's a long tail
 of packagers that maintain relatively few packages. These packages
 might not have frequent upstream releases or require new manual
 builds.
>>> There are a lot of packages in Fedora that are, for all
>>> practical purposes, "functionally stabilized" upstream.
>>> They get recompiled at the mass rebuild, but otherwise
>>> are in "if it ain't broke, don't fix it" mode (upstream and
>>> packaging).  And that seems fine to me.
>>>
 If we were to automate it, we absolutely should have a
 trivial way for people to regain packager status (i.e. not
 have to get re-sponsored, etc).
>>> The question is then what are you protecting against?
>>> If you can reset your password (via email link), and
>>> then click a button that says "I'm BACK!", you return
>>> to the original concern that was raised about whether
>>> this is really the same person you think it is.
>> You are right, it seems hard to do this in a way that has an actual
>> effect without offending real people. But I think we should try
>> to find some way. With 1500+ unused accounts it is just *too easy*
>> for someone to find a way to access one of the accounts in an unauthorized
>> way. Essentially, if you get access to one the email accounts, you can
>> reset the FAS password. I'd guess that a large fraction of those mail
>> addresses are on univerisities all around the world, and somebody might
>> do it just for kicks.
>>
>> In particular, if we removed the 'packager' bit, people would still
>> have the account and all history associated with it. If they ever
>> want to starting doing packaging work directly (because note that they
>> don't actually need it if they're active but somebody else is submitting
>> the builds), I think a manual procedure where you have to e.g. open
>> a ticket on sponsors tracker to ask to be reinstantated would be OK.
>>
> This is exactly my point of view. My proposal wasn't meant for kicking
> off anyone, I was just proposing a periodic check of who's still
> overseeing their account.
>
> I'll try to write down a quick script which should expand the one from
> Ben by looking for any activity in the last year in
> src.fedoraproject.org instead of Koji, then check those users for any
> activity in Fedora (datagrepper?).
>
> For the identified users with no activity, I suppose that sending one
> email per year asking "hey, is this still your email account and are you
> still engaged in Fedora packaging" would be no harm. And, if no reply is
> received after an adequate period (2 weeks?), removing the "packager"
> bit from the account would be no harm as well. I'm not proposing to
> delete their account.

I'd suggest to make it a month at least, just in case someone takes a
longer vacation.

> The only issue would be how to handle packages that are maintained from
> such users, I think they'd need to be orphaned.

That's really the only sensible option imho.


Cheers,

Dan
___
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: Do we have any policy for disabling inactive users

[Dan Čermák]

Mattia Verga via devel  writes:

> Just being paranoid here: do we have any policy / automatism for
> disabling "power" users (in packager group or like) which have been
> inactive for long time?
>
> I'm no security expert, but an inactive user account may be hacked
> without noticing and if such account have powers like being in the
> packager group may inject bad things in the distribution.
> I also imagine the case where a user no more use their email address and
> that become available to someone else. The new user may easily reset the
> password and gain access to the old Fedora account (provided that the
> old user didn't use 2fa).
>
> Does it make sense to start thinking to prune inactive packagers without
> waiting someone to start the "unresponsive maintainer policy"? Maybe a
> script could check user activities in src.fedoraproject.org and send a
> warning email if no activity is made in one year?

Sounds like a good idea to me and waiting for a year of inactivity is
imho a reasonable amount of time, if we give them enough time to respond
*and* also provide a way to reactivate a deactivated account.


Cheers,

Dan
___
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: Non-responsive maintainer for nim/jetbrains-mono-fonts package

[Dan Čermák]

On February 3, 2022 6:28:33 PM UTC, Michael Kuhn  
wrote:
>Hi,
>
>jetbrains-mono-fonts is scheduled for retirement due to not building
>since Fedora 33. I have opened a PR some time ago, fixing this problem:
>https://src.fedoraproject.org/rpms/jetbrains-mono-fonts/pull-request/2
>However, the maintainer seems to be inactive at the moment. I would be
>happy to help or take over maintaining this package since I do not want
>to see it removed from Fedora.
>
>If anyone knows how to reach nim, please let me know.

AFAIK nim went MIA over a year ago and sadly I've not heard anything about 
their whereabouts. But treat this as hearsay, as I have no written evidence.


Cheers,

Dan
___
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: RFE: CMake AutoRequires?

[Dan Čermák]

Hi Kevin,

On January 27, 2022 3:59:04 AM UTC, Kevin Kofler via devel 
 wrote:
>Hi,
>
>when working on finally fixing Trojitá to build (it had been FTBFS since 
>F34, so removal was impending), I have noticed that the Akonadi contacts 
>plugin was not getting built because of missing transitive build 
>dependencies:
>https://bugzilla.redhat.com/show_bug.cgi?id=2046299
>https://bugzilla.redhat.com/show_bug.cgi?id=2046310
>https://bugzilla.redhat.com/show_bug.cgi?id=2046574
>
>They all have in common that FooConfig.cmake wants the CMake package Bar, 
>but foo-devel does not Require bar-devel. So building against Foo does not 
>work out of the box, only when manually BRing also bar-devel.
>
>The thing is, we have had for a while AutoProvides scripts for CMake that 
>automatically let bar-devel Provide cmake(Bar). This is already used in many 
>places. What is missing, though, is corresponding AutoRequires, so that foo-
>devel automatically Requires: cmake(Bar) if FooConfig.cmake requires Bar.

There is something like that already in place:
https://src.fedoraproject.org/rpms/cmake/blob/rawhide/f/cmake.req

But I guess it does not produce the requires that you expect it should?

Maybe an automatic buildrequires generator would solve your use case better?


Cheers,

Dan
___
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: Self Introduction: Matthew Davis

[Dan Čermák]

Welcome to the community Matthew!

Great to see so many new people join and especially willing to contribute to 
epel! Hope you're going to have a great time :-)


Cheers,

Dan

On January 27, 2022 1:31:37 AM UTC, Matthew Davis 
 wrote:
>Greetings,
>
>I am Matthew. I am a DevOps lead engineer for a small company. I have 
>used Red Hat / rpm-based distributions for a long time now.I have built 
>rpms for almost as long.I have come through my career from operations 
>track rather than a software development track.In addition to building 
>packages, I have also operated a private Koji and Open Build Service 
>instances.
>
>I have wanted to contribute back to the Fedora community for some time 
>now.I finally can do so.I enjoy taking upstream software and packaging 
>them.I am also passionate about infrastructure as well.Initially I hope 
>to assist the community with the “branch and build” request related to 
>EPEL 9.
>
>I am looking forward to helping where I can.
>
___
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: What to do with packages that fail to install since Fedora 34 but BZs are ASSIGNED?

[Dan Čermák]

Hi Miro,

Miro Hrončok  writes:

> On 25. 01. 22 15:48, Stephen Gallagher wrote:
>> On Tue, Jan 25, 2022 at 6:43 AM Miro Hrončok  wrote:
>>>
>>> Hello,
>>>
>>> during the Fedora 34 development cycle a year ago, I've reported the 
>>> following
>>> buzgillas about packages that don't install:
>>>
>>> https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED=blocked=blocked=blocked_id=12391194=substring=substring=substring=Fedora_format=advanced=F34FailsToInstall=F35FailsToInstall=F36FailsToInstall
>>>
>>> They were set to ASSIGNED by their maintainers but since then, they still 
>>> don't
>>> install on Fedora 34, Fedora 35 or Fedora 36.
>>>
>>> I see no point in keeping such packages in the repositories, yet the policy
>>> does not currently allow to do anything other than keep them.
>>>
>>> Should I take some steps, or do we keep building and shipping the broken
>>> packages forever?
>> 
>> Wouldn't this fit under the non-responsive maintainer policy?
>
> Well, the obvious problem with that approach is that the packagers are 
> otherwise active (at least the majority of them):
>
> Fabian Affolter (5 bugzillas)
> Dan Horák (4 bugzillas)
> Peter Robinson, Rust SIG, Mukundan Ragavan...
>
> And the non-responsive maintainer policy kinda assumes the maintainers are 
> generally not interested / responsive.

In that case I would suggest that we draft a policy comparable to how we
handle FTBFS packages, as non-installable packages are about as useful
as those that cannot be build (at least for the end user they might be
actually more harmful).


Cheers,

Dan
___
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: [Discussion] Future of the CLI APP packaging

[Dan Čermák]

Hi,

Jiri Konecny  writes:

> Dne 07. 01. 22 v 21:54 Major Hayden napsal(a):
>> On 1/7/22 14:46, Jiri Konecny wrote:
>>> I would like to do here a bit of brainstorming and ask if there is an 
>>> existing solution to this problem. To explain my problem,
>>> recently I found more and more apps likes terminals, prompt and 
>>> command line tooling, which are great to use but not
>>> packaged or are outdated in our repositories. The reason for this is 
>>> simple. These apps are written in languages like Rust or
>>> Go which works the way that there are plenty of smaller libraries and 
>>> these are really a hell to package or maintain in
>>> Fedora. On the other hand it's pretty simple to build it from the 
>>> source (most of the time) but hard to split it into packages.
>>
>> Oh gosh, yes, this has been a problem for me for a while. I maintain 
>> azure-cli, which has a few subpackages. It depends on about 95 other 
>> Azure Python SDK components which depend on various Python libraries. 
>> Each of these must be carefully updated when the main azure-cli 
>> package is updated. 掠
>>
>>> I would say, that for GUI apps we already done that. We have Flatpak 
>>> which is doing great job to get these apps there
>>> and motivate people to do that because it's then consumable on plenty 
>>> of places. However, this is not really usable if you
>>> need app which is core part of the system (like prompt) or emacs/vim 
>>> which needs a lot of dependencies from the system
>>> based on user configuration.
>>
>> I do like Flatpaks for GUI applications.
>>
>> For CLIs, I've seen people use container images since it's a single 
>> item that is easily updated. However, it's not always easy to 
>> determine how a container was built and the home of its sources. 
>>
>> The cloud vendors seem to be moving towards bundling everything up 
>> into a zip file that you download and run. AWS now has their own 
>> crypto/hashing components and bundled Python in a zip. Google has a 
>> large zip with plenty of third party vendored content.
> Bundling to ZIP is again the same issue. You have to download it from 
> somewhere and from my PoV that is a bigger problem than not being able 
> to validate the content.

I am afraid that we will not get around bundling dependencies in the
long haul if we want packaging to still be a doable effort.

There however kind off a middle ground between "package everything" and
"bundle everything", that is currently pursued by the openSUSE project
for node.js: allow the build system to "inject" system packages into a
npm install via a local registry. That would allow packagers to still
bundle most of the non-critical™ packages, while the security relevant
ones could be maintained as rpms and get more attention. Iirc the plan
was to provide this functionality via
https://github.com/openSUSE/npm-localhost-proxy, but I am not sure if
it's already implemented or whether that's the correct project.


Cheers,

Dan
___
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: Clean EVR upgrade between releases no more required?

[Dan Čermák]

Hi Mattia,

Mattia Verga via devel  writes:

> In this [1] rpmautospec bug it is claimed that a clean EVR upgrade
> between Fedora releases is no more required.

Afaik this should be correct, as dnf system-upgrade uses distro-sync
nowadays and will perform the upgrade correctly even if that implies a
EVR downgrade.


Cheers,

Dan
___
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: Does anybody still use `starship'?

[Dan Čermák]

Otto Urpelainen  writes:

> Igor Raits kirjoitti 9.1.2022 klo 13.24:
>> Hello,
>> 
>> I'm interested to hear if there are any users of the `starship'
>> application here in Fedora that consume it from the repositories.
>> Please speak up if you do!
>
> I use it, too.

Same here and very thankful for being able to do that!
___
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: How do we announce new packages?

[Dan Čermák]

Kevin Fenzi  writes:

> On Sat, Jan 01, 2022 at 12:23:49PM +0100, Dan Čermák wrote:
>> Fabio Valentini  writes:
>> 
>> > On Sun, Dec 26, 2021 at 9:09 PM Matthew Miller  
>> > wrote:
>> >>
>> >> On Sat, Dec 25, 2021 at 09:15:38PM +0100, Fabio Valentini wrote:
>> >> > So ... maybe we could have a mailing list for this?
>> >> >
>> >> > Maybe "awesome-announce" or "the-new-shinyness" (I'm kidding! I'm bad
>> >> > with names!) at lists.fedoraproject.org, where all Fedora contributors
>> >> > could post the fancy new thing that they just made? Because we
>> >> > definitely don't have a good place for announcements like that right
>> >> > now (the community blog might be the right place for some of those,
>> >> > but it is a higher barrier to actually write a blog post that gets
>> >> > edited etc. instead of writing an e-mail to a mailing list).
>> >>
>> >> Hmmm.
>> >>
>> >> The Community Blog should have a pretty low barrier to entry. Are
>> >> people feeling blocked by that? We should try to adjust if so.
>> >>
>> >> As it is, the bar is basically "is this appropriate for this site" and "is
>> >> the categorization right", with the editorial pass mostly being for
>> >> egregious problems. In other words, I don't think it's actually much more
>> >> heavyweight than a moderated announce mailing list would be.
>> >>
>> >> But I also am not sure Community Blog is the right audience — that's
>> >> intended to be contributor-facing, and this seems like something aimed to 
>> >> e
>> >> more user-facing.
>> >
>> > Those are exactly my thoughts. I don't think there's a way for Fedora
>> > contributors to "market" the cool new thing they've been working on to
>> > *users* (or tech publications)?
>> >
>> > I mean, submitting a Change Proposal results in things getting
>> > announced pretty publicly, but that does not fit for smaller changes,
>> > or changes that are not specific to the next Fedora release.
>> >
>> > I know that some tech news websites follow discussions on the devel
>> > list (and probably the announcement lists), but those are mostly not
>> > really of interest to *users*, and there's no mailing list for "here's
>> > a cool new feature!" that they can subscribe to. That might skew
>> > newsworthy items more towards the "negative news" side of things, like
>> > "this package is orphaned / retired" / "Is this maintainer still
>> > responsive" etc., having more *positive* news to report on would be
>> > nice for Fedora.
>> 
>> So how about we just create such a list, make it moderated, ensure that
>> every post gets at least *some* proofreading and see how it works out?
>
> I'm game... but that brings us to the hardest problem in computers: 
> what do we name it? :) 
>
> new-tech? noteable-changes? new-features?

fedora-contributor-announce?

> And... who will moderate? Perhaps we could/should file a infra ticket on
> the list and have interested parties add their names there?

Sounds good to me.


Cheers,

Dan
___
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: How do we announce new packages?

[Dan Čermák]

Fabio Valentini  writes:

> On Sun, Dec 26, 2021 at 9:09 PM Matthew Miller  
> wrote:
>>
>> On Sat, Dec 25, 2021 at 09:15:38PM +0100, Fabio Valentini wrote:
>> > So ... maybe we could have a mailing list for this?
>> >
>> > Maybe "awesome-announce" or "the-new-shinyness" (I'm kidding! I'm bad
>> > with names!) at lists.fedoraproject.org, where all Fedora contributors
>> > could post the fancy new thing that they just made? Because we
>> > definitely don't have a good place for announcements like that right
>> > now (the community blog might be the right place for some of those,
>> > but it is a higher barrier to actually write a blog post that gets
>> > edited etc. instead of writing an e-mail to a mailing list).
>>
>> Hmmm.
>>
>> The Community Blog should have a pretty low barrier to entry. Are
>> people feeling blocked by that? We should try to adjust if so.
>>
>> As it is, the bar is basically "is this appropriate for this site" and "is
>> the categorization right", with the editorial pass mostly being for
>> egregious problems. In other words, I don't think it's actually much more
>> heavyweight than a moderated announce mailing list would be.
>>
>> But I also am not sure Community Blog is the right audience — that's
>> intended to be contributor-facing, and this seems like something aimed to e
>> more user-facing.
>
> Those are exactly my thoughts. I don't think there's a way for Fedora
> contributors to "market" the cool new thing they've been working on to
> *users* (or tech publications)?
>
> I mean, submitting a Change Proposal results in things getting
> announced pretty publicly, but that does not fit for smaller changes,
> or changes that are not specific to the next Fedora release.
>
> I know that some tech news websites follow discussions on the devel
> list (and probably the announcement lists), but those are mostly not
> really of interest to *users*, and there's no mailing list for "here's
> a cool new feature!" that they can subscribe to. That might skew
> newsworthy items more towards the "negative news" side of things, like
> "this package is orphaned / retired" / "Is this maintainer still
> responsive" etc., having more *positive* news to report on would be
> nice for Fedora.

So how about we just create such a list, make it moderated, ensure that
every post gets at least *some* proofreading and see how it works out?


Cheers,

Dan
___
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: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)

[Dan Čermák]

Elliott Sales de Andrade  writes:

> On Wed, 29 Dec 2021 at 10:02, Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change
>>
>> == Summary ==
>> Update Hunspell Dictionary system directory from /usr/share/myspell/
>> to /usr/share/hunspell/
>>
>> == Owner ==
>> * Name: [[User:vishalvvr| Vishal Vijayraghavan]]
>> * Email: 
>>
>>
>> == Detailed Description ==
>> In most of Linux distributions the standard Hunspell dictionary path
>> is `/usr/share/hunspell/` but in Fedora still has
>> `/usr/share/myspell/`. This effort is to follow default standard to
>> install all Hunspell dictionary into `/usr/share/hunspell/` instead of
>> `/usr/share/myspell/`.
>>
>>
>> == Benefit to Fedora ==
>> This will future proof Fedora to use the correct current location for
>> hunspell spelling dictionaries.
>>
>> == Scope ==
>> * Proposal owners:
>> In total there are `135` packages which is to be updated. libreoffice
>> & Firefox are the two main applications and rest are mostly language
>> dictionary packages.
>>
>> * Other developers:
>>
>> * Policies and guidelines: N/A (not needed for this Change)
>> * Trademark approval: N/A (not needed for this Change)
>> * Alignment with Objectives:
>>
>>
>> == Upgrade/compatibility impact ==
>>
>>
>> == How To Test ==
>> 1. Check if default installed dictionary path is
>> `/usr/share/hunspell/` instead of `/usr/share/myspell/`
>>
>> `$ hunspell -D` or `$ ls /usr/share/hunspell/`
>>
>> 2. Install any language dictionary and check if it getting installed
>> into '/usr/share/hunspell/'
>>
>> `$ dnf install hunspell-hi`
>>
>> `$ hunspell -D`
>>
>
> If, as mentioned above, this will possibly affect applications such as
> Firefox and LibreOffice, then those should also be tested as well.

Emacs and other text editors could be affected by this as well.


Cheers,

Dan
___
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: Package wishlist site?

[Dan Čermák]

Hi Jakube,

Jakub Kadlčík  writes:

> Hello,
>
> TL;DR What about a place where people could ask for something to be
> packaged in Fedora?

As others already commented: I don't think that this is a good
idea.

Packaging a program for others where you have no real personal
interest/benefit/buy-in is in my experience not sustainable in the long
haul, besides nearly no one doing it (probably for that reason). I would
actually even say that having such a list is harmful to the project as
it would suggest that someone will eventually package the app, thereby
more or less guaranteeing disappointment.


Cheers,

Dan
___
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: F36 Change: DIGLIM (System-Wide Change proposal)

[Dan Čermák]

Ben Cotton  writes:

*snip*

>
> It will also make Fedora able to detect tampering of its components at
> a more privileged level, the kernel, without the interference of user
> space programs. Once tampering has been detected, the actions of the
> altered component are prevented before that component gets the chance
> to perform any action. Fedora could be configured to also allow the
> usage of components provided by the user, if he wishes to do so
> (DIGLIM has a tool to build custom digest lists).

How would that look in practice? Will a user just get a message in the
journal?

> == Upgrade/compatibility impact ==
> The user should ensure that software (not updated) from the old
> distribution is packaged and the package header is signed, or he
> should create and sign a custom digest list for the software he wishes
> to use after the upgrade.

Uhm, so locally/manually installed software (i.e. not signed by Fedora's
signkeys) will silently break when switching to F36? How about 3rd party
repositories?


Cheers,

Dan
___
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: openQA tests in Pull Requests?

[Dan Čermák]

Hi,

Adam Williamson  writes:

> On Tue, 2021-12-07 at 13:21 +0100, Miro Hrončok wrote:
>> Hello QA,
>> 
>> is there a way (even a hacky one) to run openQA tests (the ones that run on 
>> Bodhi updates of critpath packages) on an open Pull Request?
>
> Hey Miro! Right now there really isn't, I'm afraid. The least official
> thing we can run the tests for right now is a scratch build, so you
> need to at least turn the PR into a scratch build somehow.
>
> There's no public/self-serve way to schedule for a scratch build at the
> moment; someone with admin/moderator access (so, usually, me) needs to
> do it for you.
>
> If there is substantial interest I could look at implementing something
> here...I would expect that some system or other (CI? Koschei?) must
> surely have a way of turning pull requests into package builds already,
> so I'd want to find that and build on it rather than reinventing it if
> possible.
>
> The other stumbling block is that we still don't run these tests on
> Rawhide, so if you want to test the PR in the context of the
> rawhide/main branch, it would be more difficult (even just doing a one-
> off, because the tests use pre-rolled disk images as a base, and we
> don't build several of the needed images for Rawhide currently).
>
> That's something that could change, but it would be a fairly major
> thing and might possibly require me to beg infra for more hardware or
> finally find the time to see if we can run openQA tests In The Cloud. I
> can provide more details on that whole area if you're interested...

So, opensuse and suse do the following for the released distributions
(e.g. opensuse Leap):
each update gets put into a staging area in the build service, which
rebuilds a subset of the distribution, creates the installation images
and publishes repositories from the staging area. Then openqa is
triggered for the staging area and a bot reports back.

This is not exactly a test on a pull request though, because the actual
pull request equivalent happens in a different place. It is more
equivalent to testing a bodhi update or a side tag.

What I could imagine would be the following: some CI (e.g. Zuul) builds
an image from the pull request and publishes that image somewhere
publicly accessible. Then Zuul would trigger an openqa job and set
ISO_1_URL or HDD_1_URL to the published image, openqa then pulls these
and runs all tests. It would however require that no repositories are
accessed during the tests. And we'd also need some bot to report back an
pagure, but that shouldn't be impossible either, as openqa publishes all
test results via mqtt.

And yes, that will require more hardware to run so many tests.


Hope this helps,

Dan

> -- 
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
> ___
> qa-devel mailing list -- qa-devel@lists.fedoraproject.org
> To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Review request for oclock package (orphaned since F35)

[Dan Čermák]

Hi,

Globe Trotter via devel  writes:

> Thank you to Dan Čermák for reviewing this package. However, I had two 
> questions from his comments. The first was that the spec file should use 
> gpgverify. 
> So, I went to the suggested webpage: 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification
> and did the following to get my signature 
>
> Source0:    https://www.x.org/pub/individual/app/%{name}-%{version}.tar.gz
> Source1:    %{source0}.sig
>
> but can not tell how to get the gpg keyring from the site. 
>
> Second, it is also suggested that I start using rpmautospec, as that will 
> make package maintenance simpler in the long run. I like that of course, but 
> I am trying to understand where this is used? 

rpmautospec reduces the necessary churn when updating packages, in the
simplest case it boils down to this:
- use `Release: %autorelease` instead of bumping it yourself
- don't write the %changelog yourself, just put:
--8<---cut here---start->8---
%changelog
%autochangelog
--8<---cut here---end--->8---
at the bottom of the spec

The rpmautospec automation will then bump the release via %autorelease
on each git commit and put every commit message into the changelog.
This has the huge advantage, that it makes updating across all branches
rather easy as you do not have to resolve merge conflicts due to
diverging changelogs or different release numbers any more.


Hope this explains it a bit, feel free to reach out directly if you've
got further questions,

Dan
___
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: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Dan Čermák]

Hi,

just a minor suggestion:

On November 15, 2021 7:15:49 PM UTC, Ben Cotton  wrote:
>
>Overall arm32 is generally waning with generally few new ARMv7 devices
>added to Fedora in recent releases. 

Remove one of the two generally/general.

>== Contingency Plan ==
>
>Continue on as before with the added advantage of the people that
>protested the removal of the architecture will be actively
>contributing to the maintenance of the architecture
>
>* Contingency mechanism: Leave enabled. We basically won't get to this
>if FESCo doesn't approve the change.
>* Contingency deadline: Mass rebuild.
>* Blocks release? Yes
>* Blocks product? Yes

I am a bit confused, assuming this gets approved and implemented: is there a 
way back?


Cheers,

Dan
___
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 CoreOS streams rebasing to Fedora Linux 35

[Dan Čermák]

Hi Dusty,

Dusty Mabe  writes:

> - cgroups v2 is now the default [5]
> - 64-bit ARM (aarch64) artifacts are now available [8]
> - Raspberry Pi 4 install documentation is now available [9]
> - Switching to iptables-nft by default [14]

What a list! Thanks for all your work on these features that I've been
waiting for.

/me goes to reflash a few RPi4s now...


Cheers,

Dan
___
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 minimum hardware requirements

[Dan Čermák]

Nico Kadel-Garcia  writes:

> On Sun, Oct 17, 2021 at 3:36 PM Chris Murphy  wrote:
>>
>>
>>
>> On Sat, Oct 16, 2021, 10:01 PM Kevin Kofler via devel 
>>  wrote:
>>>
>>>
>>>
>>> I still remember how Red Hat Linux and (IIRC) Fedora Core 1 could be booted
>>> from a floppy (older Red Hat Linux releases even had a fully functioning
>>> rescue mode on the floppy, later ones could at least still boot a HDD
>>> install from the boot floppy, which is how I installed them, and in that way
>>> also boot the rescue mode). These days, the minimum boot image (know known
>>> as the netinst ISO) barely fits on a CD, and in Fedora 33 even exceeded CD
>>> size (https://pagure.io/minimization/issue/23). The Fedora 34 netinst image
>>> is still 450 times the size of a floppy!
>>
>>
>>
>> The top two reasons for this: a significant portion of anaconda used to be 
>> downloaded, and now is included on the media; linux-firmware bloat, which is 
>> the fastest growing package for the past few years. Front this point there's 
>> a bunch of pressure points and trade-offs. This cycle we were over CD-ROM 
>> size of 700MiB, and ended up trimming out about 30M from linux-firmware.
>>
>> --
>> Chris Murphy
>
> It's also X based with GUI's, rather than an ncurses based graphical
> interface. Reviewing a fresh install, there is little to nothing that
> couldn't be done in a much, much smaller text interface going through
> a linear checklist with ncurses, and follow Eric Raymond's old
> guidelines for open source interfaces titled "The Luxury of
> Ignorance". But some folks like pretty GUIs, even though sophisticated
> GUI's cost resources to run.

They are also much more intuitive to use for your average user/ newcomer
to Linux in contrast to a text interface (which will put them off when
compared to the Windows or Ubuntu installer). Yes, a text interface is
much more resource friendly, but imho that will cause more harm than
actual benefit.


Cheers,

Dan
___
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: bodhi updates skipping updates-testing entirely

[Dan Čermák]

Hi Fabio,

Fabio Valentini  writes:

> So, I wonder, should updates always be allowed to skip being in the
> "updates-testing" repository entirely? There's probably good reasons
> for it sometimes (for example, time-critical security updates, i.e.
> firefox, kernel, etc.), but in the general case, not giving regular
> "non-koji" update testers any time to test updates before they're
> pushed to stable seems suboptimal.

No I don't think that this should be generally allowed, it should be
imho prohibited for critical path updates where we schedule a full
openQA run.

> Maybe updates should only be able to be pushed to stable by karma if
> they are in the "testing" state, and need a manual "submit to stable"
> button push if they're still "pending"? That should be both fairly
> straightforward to implement in bodhi, and should allow for both the
> "pending → stable fast-track, this is urgent" and the "lets wait and
> let it sit in updates-testing for at least one day" scenarios.
>
> What do you think?

Having packages at least a day in testing (unless absolute urgency is
required) sounds like a good idea to me. This could very well happen
automatically like Miro suggested.


Cheers,

Dan
___
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: final link failed: memory exhausted on armv7l

[Dan Čermák]

Hi Iñaki,

Iñaki Ucar  writes:

> Hi,
>
> RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
> [3, 4] with this message (memory exhausted). The same build on the
> same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
> on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
> fix this?

You could try to build without LTO, iirc that requires a lot of memory
during linking.

And if that doesn't help: ExcludeArch…


Hope this helps,

Dan
___
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: Onboarding package

[Dan Čermák]

Vitaly Zaitsev via devel  writes:

> On 05/10/2021 18:04, Stephen John Smoogen wrote:
>> So we need a real proposal with an end to end idea of what
>> is being done, what is to be learned, and how it is to be 'watched' by
>> real developers to make sure people are learning things.
>
> Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small 
> set of Fedora infra, including Koji+Bodhi.

How about a vagrant box or a docker-compose file :)

However, I'm a little worried that this might be too fat or not too
simple to set up automatically (koji itself uses Kerberos for auth,
which by itself is a huge beast…)


Cheers,

Dan
___
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: Onboarding package

[Dan Čermák]

Kevin Fenzi  writes:

> Another possible way we could do this is have this setup in our staging
> env. ie, they do the same things, but it's in staging (which we never
> compose anyhow). That has the danger of something being broken in stg
> without us realizing it, or them diverging.

+1 on having this just in staging. While it will make it a little less
like "the real deal", it will definitely lower the barrier for
experimentation. And we could also periodically reset the package, so
that newcomers can go wild ;-)


Cheers,

Dan
___
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: F36 Change: Retired Packages (Self-Contained Change proposal)

[Dan Čermák]

Vitaly Zaitsev via devel  writes:

> On 07/10/2021 17:45, Ben Cotton wrote:
>> Subpackage `remove-retired-packages` has been created (subpackage of
>> `fedora-upgrade`).
>
> I suggest integrating this functionality into dnf as a plugin.
>
> Example:
> sudo dnf clean-retired --releasever=32

This sounds like a great idea!

Would it be possible to have this distro agnostic, so that dnf users who
are not running Fedora could leverage this plugin?


Cheers,

Dan
___
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  Java: The Death of Two SIGs

[Dan Čermák]

Neal Gompa  writes:

>>
>> On that topic, I've just read an interview of Nicolas Lécureuil, the
>> president of the Mageia board, in which he says that Mageia's Java stack
>> is based on Fedora's and that he interacts with Fedora's Java team
>> (leading me to wonder who exactly he is interacting with given Fabio's
>> description of the SIG's activity in the opening mail of this thread).
>>
>
> I also wonder about openSUSE's Java team, since their packages are
> *also* based on ours.

The openSUSE Java team is one overworked guy who managed to bootstrap
gradle 4 (iirc) a few years ago and now tries to put fires out whenever
there is little time.

We could try to coordinate & collaborate with him, but afaik neither
openSUSE has a ton of manpower when it comes to Java.


Cheers,

Dan
___
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 F34 to F35

[Dan Čermák]

Miroslav Suchý  writes:

> Do you want to make Fedora 35 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=35 --setopt=module_platform_id=platform:f35 \
>
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
>
> distro-sync

All good over here :)


Thanks everyone who worked on F35!

Dan
___
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: Running ldconfig after the RPM transaction

[Dan Čermák]

Hi Florian,

Florian Weimer  writes:

> * Dan Čermák:
>
>> it has been recently proposed to switch openSUSE to run ldconfig via a
>> %transfiletriggerin/-un scriptlet instead of manually in %post & %postun
>> the same way as Fedora does it at the moment.
>>
>> However, an interesting issue has been raised: what happens if package A
>> gets upgraded in the same transaction as package B, but B needs A during
>> the upgrade. A will install a new shared library, but ldconfig will run
>> after B has already tried to upgrade.
>
> Fedora ships the soname links in the package, addressing this issue.
> For example, openssl-libs contains:
>
> /usr/lib64/libcrypto.so.1.1
> /usr/lib64/libcrypto.so.1.1.1k
> /usr/lib64/libssl.so.1.1
> /usr/lib64/libssl.so.1.1.1k
>
> As a result, running ldconfig is purely an optimization.

Would that still be the case when the SONAME is bumped? I would assume
that the old symlink is no longer valid. Or is that also not an issue
because we rebuild the dependency on a SONAME bump?


Thanks,

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

Running ldconfig after the RPM transaction

[Dan Čermák]

Hi list,

it has been recently proposed to switch openSUSE to run ldconfig via a
%transfiletriggerin/-un scriptlet instead of manually in %post & %postun
the same way as Fedora does it at the moment.

However, an interesting issue has been raised: what happens if package A
gets upgraded in the same transaction as package B, but B needs A during
the upgrade. A will install a new shared library, but ldconfig will run
after B has already tried to upgrade.

Do we have some mechanism to prevent this? Or does this essentially
never happen in practice?

The only "workaround" that came up was to use ordinary file triggers,
but that is not a great idea either these would fire way too frequently
(as mentioned by Florian Weimer on this list in 2018: [1]).


Cheers,

Dan

Footnotes:
[1]  
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DVBZI2UJRHI5GVMJXIQNLHK4TUFS5ZM2/
___
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

Summary/Minutes from today's FESCo Meeting (2021-08-23)

[Dan Čermák]

Unfortunately we had technical difficulties with zodbot, so these are my
manually taken minutes:

#2659 Arbitration request: Crypto policy prevents VPN connections
https://pagure.io/fesco/issue/2659

is considered resolved


#2661 Add fedora-third-party-refresh.service to 90-default.preset for rpm-ostree
https://pagure.io/fesco/issue/2661

accepted


#2662 F36 Change: MinGW debug symbols location change
https://pagure.io/fesco/issue/2662

accepted


#2663 Start signing repodata
https://pagure.io/fesco/issue/2663

should be coordinated with the interested parties and then resubmitted
as a change proposal


#2660 F35 incomplete changes: Code complete (testable) deadline
https://pagure.io/fesco/issue/2660

The golang 1.17 change[1] and Introduce Module obsoletes and EOL[2] are
being deferred to F36, the rest is either implemented or has already
been deferred or rejected.



Action items:
- mhroncok to ask about the state of the Module obsoletes and EOL in the
  modularity meeting
- ngompa to chair next weeks meeting


Footnotes:
[1]  https://fedoraproject.org/wiki/Changes/golang1.17

[2]  https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL
___
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

Schedule for Monday's FESCo Meeting (2021-08-23)

[Dan Čermák]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:00UTC in #fedora-meeting on
irc.libera.chat.

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

or run:
  date -d '2021-08-23 19:00 UTC'


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

= Discussed and Voted in the Ticket =


= Followups =

#2659 Arbitration request: Crypto policy prevents VPN connections
https://pagure.io/fesco/issue/2659

#2660 F35 incomplete changes: Code complete (testable) deadline
https://pagure.io/fesco/issue/2660

= New business =

#2661 Add fedora-third-party-refresh.service to 90-default.preset for rpm-ostree
https://pagure.io/fesco/issue/2661

#2662 F36 Change: MinGW debug symbols location change
https://pagure.io/fesco/issue/2662

#2663 Start signing repodata
https://pagure.io/fesco/issue/2663


= 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.
___
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: The Death of Java (packages)

[Dan Čermák]

I'd also like to plug Jakub's new sponsor page: 
https://docs.pagure.org/fedora-sponsors/all

There you can find all currently active sponsors by language, interest, etc.


Cheers,

Dan

On August 12, 2021 7:29:10 AM UTC, Felix Schwarz  
wrote:
>Hi Stephen,
>
>thank you for your interest in contributing to Fedora. I can totally understand
>that the current policies may seem overwhelming so that becoming a packager
>might be seen as some kind of "elite" status.
>I think I would feel the same way if I didn't become a packager ~10 years ago.
>
>However I would like to emphasize Ben's point:
>> I think becoming a packager is not as complicated as you’ve written. To
>> become a packager, you must convince a packager sponsor to sponsor you.
>> That’s all; there is no rule about how to do the convincing.
>
>Maybe you do 1-2 package updates or fixes (pull request via 
>src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. 
>Try contacting some of them directly after you verified they are still active 
>(mailing list/src.fedoraproject.org). Also it helps usually if these sponsors 
>are interested in the languages/tech stack which you tried to improve.
>
>That being said: Java in Fedora is one of the hardest areas to tackle. Several 
>"high profile" packagers had to give up on that task (despite heroic efforts) 
>because it is just too much for one person (or a small team).
>
>Part of the problem is that the Java upstream "culture" does not matches the 
>processes of a traditional Linux distribution like Fedora. Lots of bundled 
>dependencies, "secret" build processes and on top a huge number of small 
>packages.
>
>I can understand that "keeping Eclipse in Fedora" is a worthy goal for sure 
>but 
>really a lot of work. Other areas like Python packaging are much easier as 
>applications tend to be smaller and bundling is less common in the Python 
>world. 
>(Also great efforts by our Python team!)
>
>
>One of the things I'd be interested in is "reprocible builds" which I think 
>might be easier to contribute. While there is a lot of infrastructure to build 
>(= a lot of work) you can also just fix one package at a time (probably with a 
>few upstream commits). Even if you stop contributing to Fedora after some 
>months 
>or years you advanced the state of Fedora/Linux anyway.
>
>Felix
>___
>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: Help with gdal sphinx doc build failure

[Dan Čermák]

Orion Poplawski  writes:

> On 8/11/21 2:24 PM, Dan Čermák wrote:
>> Hi Orion,
>> 
>> Orion Poplawski  writes:
>> 
>>> I've reported: https://bugzilla.redhat.com/show_bug.cgi?id=1992426
>>>
>
>>> This appears to be due to breathe not handling parsing errors.  There is
>>> a PR upstream at https://github.com/michaeljones/breathe/pull/711 but it
>>> doesn't apply cleanly to the current release so I haven't been able to
>>> test it.
>> 
>> I've applied the patch from the PR to breathe and made a scratch build:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=73684859
>> 
>> Could you give that one a try?
>
> That appears to do the trick.  Can we get that built for rawhide and f35?

Builds are already running and should finish in a few minutes.


Cheers,

Dan
___
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: Help with gdal sphinx doc build failure

[Dan Čermák]

Hi Orion,

Orion Poplawski  writes:

> I've reported: https://bugzilla.redhat.com/show_bug.cgi?id=1992426
>
> gdal docs are failing to build with:
>
>
>
> Exception occurred:
>
>File "/usr/lib/python3.10/site-packages/sphinx/util/cfamily.py", line 
> 275, in fail
>
>  raise self._make_multi_error(errors, '')
>
> sphinx.util.cfamily.DefinitionError: Invalid C++ declaration: Expected 
> identifier in nested name. [error at 8]
>
>typename...
>
>^
>
>
>
> This appears to be due to breathe not handling parsing errors.  There is 
> a PR upstream at https://github.com/michaeljones/breathe/pull/711 but it 
> doesn't apply cleanly to the current release so I haven't been able to 
> test it.

I've applied the patch from the PR to breathe and made a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=73684859

Could you give that one a try?


Cheers,

Dan
___
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: Use of sed in spec files

[Dan Čermák]

Hi Richard,

Richard Shaw  writes:

> It's quite common to need to do some minor manipulation in a spec file and
> you decide to use sed instead of patching so you don't have to update it
> every release.
>
> The problem is that sed returns 0 whether it actually did anything or not.
>
> Thinking about this I did some searching and you can use custom exit
> codes[1].

Nice find!

> The question is, does anyone think this is important? Important enough to
> have guidelines around? Sure it doesn't hurt anything (unless the search
> term is added in another context) but it does lead to spec file cruft.

I think we should mention this in the guidelines and let packagers
decide whether they want to use this or not, as should be able to judge
this best by themselves.


Cheers,

Dan
___
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: guile22 -> gnutls -> lots of virt packages

[Dan Čermák]

On July 7, 2021 9:14:34 PM UTC, "Zbigniew Jędrzejewski-Szmek" 
 wrote:
>On Wed, Jul 07, 2021 at 06:21:08PM +0200, Petr Menšík wrote:
>> What would be considered sufficient research about usage of guile? If
>> package provides it as optional feature among many other features,
>how
>> should package owner test one feature is still demanded? Do we have
>any
>> best practice? Is asking on users@ and devel@ list enough?
>
>I strongly suspect that those users would have made themselves known
>by now. Neal mentioned that he uses guile in some projects, and that's
>pretty much it so far.

I wouldn't be so sure about that. I don't expect most Fedora users to read 
devel, especially these rather long "orphaned packages threads". So my guess is 
that most devs, who are not Fedora contributors, but use make in their personal 
projects are not even aware of this discussion taking place.


Cheers,

Dan
___
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: rpmautospec deployment into production

[Dan Čermák]

Otto Urpelainen  writes:

> Dan Čermák kirjoitti 18.7.2021 klo 23.38:
>> Otto Urpelainen  writes:
>> 
>>> Dan Čermák kirjoitti 17.7.2021 klo 23.10:
>>>> Robert-André Mauchin  writes:
>>>>
>>>>> What is the situation wrt new packages? Should we enforce the use of
>>>>> rpmautospec during reviews or is it completely optional?
>>>>
>>>> I think we should encourage the usage of rpmautospec for new packages,
>>>> provided that the packager feels comfortable enough to use it. E.g. I
>>>> wouldn't suggest it for someone's first package. But this shouldn't
>>>> become a *MUST*, at least not yet.
>>>
>>> I am curious regarding the reasons for not recommending rpmautospec for
>>> new maintainers? It is an automation feature that removes manual steps
>>> from the process. Using it is simpler than doing the same manually. I
>>> think we should offer the simplest possible process for newcomers and
>>> only recommend manual overrides for use cases that automation cannot
>>> handle (yet).
>> 
>> Well, I think that a total newcomer is already struggling enough to
>> produce a good spec file for their first package, but now they also need
>> to keep in mind that their changelog is tied to the git history (and can
>> thus not be changed easily anymore). Back when I started packaging, I
>> found a lot of the details quite confusing and was building packages on
>> copr and locally for a few years before I dared to go near koji. At
>> least for me using rpmautospec would've been another one of these
>> confusing details. That's why I would only recommend its usage, until
>> most other build system out there use something comparable and beginners
>> can be expected to know this concept already.
>
> Understood. That makes sense. This is a case of different backgrounds. 
> The only rpm packages I have ever built are Fedora official packages. 
>  From that angle, using rpmautospec is just simpler. In your case, it is 
> the other way round.

Yeah, so for a package review I'd suggest the usage of rpmautospec if
the packager is comfortable with that, but wouldn't enforce it for now.


Cheers,

Dan
___
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: rpmautospec deployment into production

[Dan Čermák]

Otto Urpelainen  writes:

> Dan Čermák kirjoitti 17.7.2021 klo 23.10:
>> Robert-André Mauchin  writes:
>> 
>>> What is the situation wrt new packages? Should we enforce the use of
>>> rpmautospec during reviews or is it completely optional?
>> 
>> I think we should encourage the usage of rpmautospec for new packages,
>> provided that the packager feels comfortable enough to use it. E.g. I
>> wouldn't suggest it for someone's first package. But this shouldn't
>> become a *MUST*, at least not yet.
>
> I am curious regarding the reasons for not recommending rpmautospec for 
> new maintainers? It is an automation feature that removes manual steps 
> from the process. Using it is simpler than doing the same manually. I 
> think we should offer the simplest possible process for newcomers and 
> only recommend manual overrides for use cases that automation cannot 
> handle (yet).

Well, I think that a total newcomer is already struggling enough to
produce a good spec file for their first package, but now they also need
to keep in mind that their changelog is tied to the git history (and can
thus not be changed easily anymore). Back when I started packaging, I
found a lot of the details quite confusing and was building packages on
copr and locally for a few years before I dared to go near koji. At
least for me using rpmautospec would've been another one of these
confusing details. That's why I would only recommend its usage, until
most other build system out there use something comparable and beginners
can be expected to know this concept already.


Cheers,

Dan
___
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: rpmautospec deployment into production

[Dan Čermák]

Robert-André Mauchin  writes:

*snip*

> What is the situation wrt new packages? Should we enforce the use of 
> rpmautospec during reviews or is it completely optional?

I think we should encourage the usage of rpmautospec for new packages,
provided that the packager feels comfortable enough to use it. E.g. I
wouldn't suggest it for someone's first package. But this shouldn't
become a *MUST*, at least not yet.


Cheers,

Dan
___
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: Permanent Updates Policy exception for PrusaSlicer, Cura, Black, tox, HTTPie and ownCloud Desktop Client

[Dan Čermák]

Otto Urpelainen  writes:

*snip*

>
> I wonder if Updates Policy should have general wording that would allow 
> you to update this package without asking for exceptions, or at least 
> "make it more likely to grant a request"? It does not make much sense to 
> disallow client program updates because they contain "new features" when 
> the remote backends it is connecting to require those features.
>
> Web browsers are another example of this, and maybe also your 3d printer 
> control apps.

Agreed, I think we should not prevent upgrades to new major versions for
end user applications where it is highly desirable to be able to use the
new version. This is especially important for programs that connect to a
backend that might be using a newer version outside of the user's
control.

I am however unsure what the exact rules are, because I also pushed an
upgrade of Emacs from 26 to 27 to Fedora 33 and received a few
complaints there (to my surprise).


Cheers,

Dan
___
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: Schedule for Monday's FESCo Meeting (2021-07-12)

[Dan Čermák]

Hi folks, I'll probably not make it to today's meeting.

Sorry for the late notice,

Dan

On July 12, 2021 11:20:13 AM UTC, "Zbigniew Jędrzejewski-Szmek" 
 wrote:
>Following is the list of topics that will be discussed in the
>FESCo meeting Monday at 19:00UTC in #fedora-meeting on
>irc.libera.chat.
>
>To convert UTC to your local time, take a look at
>  http://fedoraproject.org/wiki/UTCHowto
>
>or run:
>  date -d '2021-07-12 19:00 UTC'
>
>
>Links to all issues to be discussed can be found at: 
>https://pagure.io/fesco/report/meeting_agenda
>
>= Discussed and Voted in the Ticket =
>
>#2629 F35 Change: MinGW environment and toolchain update
>https://pagure.io/fesco/issue/2629
>APPROVED (+5, 0, 0)
>
>#2627 F35 Change: Libvirt Modular Daemons
>https://pagure.io/fesco/issue/2627
>APPROVED (+5, 0, 0)
>
>#2626 F35 Change: Remove authselect-compat package
>https://pagure.io/fesco/issue/2626
>APPROVED (+4,0,-0)
>
>#2630 F35 Change: libmemcached-awesome
>https://pagure.io/fesco/issue/2630
>
>
>= Followups =
>
>= New business =
>
>
>#2624 Proposal: Ban bots from submitting non-scratch koji builds 
>https://pagure.io/fesco/issue/2624
>
>
>= 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. 
>___
>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: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

[Dan Čermák]

Thanks a lot for this Michel!

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros
>
> == Summary ==
> Introduce macros, similar to openSUSE's
> [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
> memory-constraints]), for optionally limiting build parallelism for
> build-time memory-bound packages
>
> == Owner ==
> * Name: [[User:salimma|Michel Alexandre Salim]]
> * Email: michel AT michel-slm DOT name
>
>
> == Detailed Description ==
> Some source packages have a memory usage per build thread higher than
> the RAM:CPU ratio available in some of our builders. Further, this
> ratio can be different for different build server on different
> architectures.
>
> At the moment, such packages
> ([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390
> ceph], 
> [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14
> chromium], 
> [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82
> mcrouter]) have to implement their own logic for determining the safe
> amount of parallelism, and redefine `_smp_build_ncpus`.
>
> When this proposal is implemented, they can instead declaratively
> specify the amount of RAM needed per build thread, e.g.
>
>   %limit_build -m 8192
>
> for declaring a build thread should be allocated 8GB of RAM.
>
> Since Koji supports
> [https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-changes
> setting default values for macros], there will be a macro for the
> default memory limit (name TBD) that, if set, will be used to cap
> `_smp_build_ncpus` unless overridden by `%limit_build -m`.
> 0
> I'm proposing to tentatively call the macro package
> `build-constraints-rpm-macros` to allow the possibility of adding
> macros for related needs e.g. [https://pagure.io/copr/copr/issue/1678
> build timeouts] to the same package.
>
>
> == Benefit to Fedora ==
> This change simplifies maintaining specs for software that are
> memory-bounded rather than CPU-bounded on our build servers
>
> It could potentially improve build reliability for these packages, by
> reducing the number of jobs failing because of OOM errors, and reduce
> the need for package maintainers to debug these failures.
>
> By keeping the user-facing API aligned with what openSUSE is using, we
> open up the possibility to collaborate with them and with the upstream
> RPM project to get such macros upstreamed into RPM itself (see
> [https://github.com/rpm-software-management/rpm/pull/821 previous
> attempt]). **note** that is not in scope for this Change.
>
> == Scope ==
> * Proposal owners:
> ** Introduce new macros
> ** Update known packages to use the new macros, replacing their custom
> `_smp_build_ncpus` overrides
>
> * Other developers:
> ** The proposal owners might not catch all references of such logic.
> Individual package maintainers can try refactoring their packages
> using these new macros
>
> * Release engineering: [https://pagure.io/releng/issue/10188 #10188]
> No mass rebuild needed. Affected packages should be rebuilt using the new 
> macro
>
> * Policies and guidelines: Packaging guideline can be updated to
> recommend using these macros for build-time memory-bound packages
>
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A
>
>
> == Upgrade/compatibility impact ==
> No impact, affects package building only. Also, the use of the new
> macros are optional.
>
>
>
> == How To Test ==
> 1. Install `build-constraints-rpm-macros`
> 2. Modify spec to set `%limit_build -n AMOUNT_IN_MB` in `%build`
> 3. Rebuild in koji and make sure it passes on all supported architectures
>
>
>
> == User Experience ==
>
>
> == Dependencies ==
> This can optionally be added as dependencies of `redhat-rpm-config`
> and `epel-rpm-macros`, depending on how many packages need this
>
>
>
> == Contingency Plan ==
>
> * Contingency mechanism: (What to do?  Who will do it?)
> Revert changed packages to their previous way of capping the number of
> build jobs
>
> * Contingency deadline: beta
> * Blocks release? No
>
>
> == Documentation ==
> Previous discussion:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU/#GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU
>
> openSUSE implementation:
> https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
>
>
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List 

Re: [Fedora-packaging] Macro to smoke-test-import a Python module in %check

[Dan Čermák]

Miro Hrončok  writes:

> On 28. 06. 21 22:25, Dan Čermák wrote:
>> Hi Miro,
>> 
>> Miro Hrončok  writes:
>> 
>>> Hello Python RPM packagers,
>>>
>>> based on some discussion in the "F35 Change: Python Packaging Guidelines
>>> overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro 
>>> that
>>> can help to test-import a Python module in %check when no other tests exist 
>>> or
>>> are when they cannot be executed during build [1].
>>>
>>> The semantics is quite simple:
>>>
>>>
>>>   %check
>>>   %py3_check_import mymodule mymodule.submodule
>>>
>>> ...
>> 
>> This looks pretty good imho. Would it somehow be possible for the macro
>> to automatically try to import the module name from the generated
>> python3.Ydist() provides? That would make the macro even more convenient
>> to use and reduce any potential user error further.
>
> Honestly, I'd rather not do that. People already confuse "module names" 
> (that's 
> what you import) with "Python package names" (that's what you install from 
> PyPI 
> or what's provided as python3.Ydist()). And while this would make the macro 
> slightly easier to use for the optimal case when those names are identical, 
> it 
> would only create more confusion when they are not.
>
> In the future, we could extend it to automatically import modules found in 
> the 
> %buidlroot, but now I'd rather provide a simple tool where the packager needs 
> to be explicit, than a very complex tool that does heuristics.

That makes sense & is probably the better approach initially. I have
honestly no idea what could be improved here, so this looks more than
fine by me :)


Cheers,

Dan
___
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-packaging] Macro to smoke-test-import a Python module in %check

[Dan Čermák]

Hi Miro,

Miro Hrončok  writes:

> Hello Python RPM packagers,
>
> based on some discussion in the "F35 Change: Python Packaging Guidelines 
> overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that 
> can help to test-import a Python module in %check when no other tests exist 
> or 
> are when they cannot be executed during build [1].
>
> The semantics is quite simple:
>
>
>  %check
>  %py3_check_import mymodule mymodule.submodule
>
> When all listed modules are successfully imported, "nothing happens", when at 
> lest one fails to import, the entire build fails. The above line is 
> translated 
> very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the 
> implementation [0] for more accurate representation). Given the Python 
> semantics, it is possible to use commas as module separators as well (but no 
> parentheses).
>
> The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
>
> The runtime dependencies are obviously needed for this to work, so they need 
> to 
> be manually BuildRequired or even better, generated in 
> %generate_buildrequires 
> via `%pyproject_buildrequires -r` to use this macro.
>
> The macro can be used repeatedly when importing multiple modules at once is 
> undesired (e.g. when only one module can be imported from the same Python 
> interpreter):
>
>  %check
>  %py3_check_import mymodule.either
>  %py3_check_import mymodule.or
>
> Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
>
>   - Do you have better ideas for the macro name?
>   - Do you have better ideas for the macro semantics?

This looks pretty good imho. Would it somehow be possible for the macro
to automatically try to import the module name from the generated
python3.Ydist() provides? That would make the macro even more convenient
to use and reduce any potential user error further.


Cheers,

Dan
___
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: Banning bots from submitting automated koji builds

[Dan Čermák]

On June 22, 2021 1:26:30 PM UTC, "Miroslav Suchý"  wrote:
>Dne 20. 06. 21 v 10:42 Miro Hrončok napsal(a):
>> Rather than "no bots allowed" policy, we might need a "bots that
>violate our policies and guidelines or have a 
>> tendency to break things will be disabled until fixed" policy. 
>
>Every bot has been written by somebody. 1) it should be always clear
>who is responsible for the bot 2) The owner should 
>take conseq^H^H^H responsibility for it.

I'd prefer this policy over an outright ban.
___
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 Source-git SIG report #1 (June 2021)

[Dan Čermák]

On June 24, 2021 6:08:17 PM UTC, "Zbigniew Jędrzejewski-Szmek" 
 wrote:
>On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote:
>> On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok 
>wrote:
>> >
>> > On 24. 06. 21 11:16, Tomas Tomecek wrote:
>> > > ## Choosing git forge to host source-git repositories
>> > > We need to find a home for all the source-git repositories. This
>is
>> > > actually a really hard task because we have many options
>(github.com,
>> > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or
>> > > on-premise) and different expectations: some projects already
>have
>> > > repos set up on different platforms while Pagure is the primary
>forge
>> > > now. Since the CPE team is investigating GitLab as a forge, it's
>even
>> > > harder for us to figure out the primary forge. We may end up
>> > > supporting both actually: pagure.io and gitlab.com. What are your
>> > > thoughts on this topic? Would you prefer pagure.io or gitlab.com
>> > > More info:
>> > > * https://pagure.io/fedora-source-git/sig/issue/1
>> > > * https://pagure.io/fedora-source-git/sig/issue/7
>> >
>> > I would expect that since the soruce git is just an intermediate
>thing,
>> > supporting "any forge" is nice to have, but hard. I'd start with
>some common
>> > options (Pagure + 1 other) and see where you'll get.
>> 
>> Yep, that's exactly what I'd like us to do. As soon as we have the
>> service which accepts processes events up and running, it shouldn't
>be
>> that hard to teach it new fedora-messaging messages or webhook
>> payloads.
>> 
>> > > ## High-level workflow proposal up for review
>> > > Hunor proposed a high-level workflow linked below and I strongly
>> > > recommend reading it. We have also started discussing many
>details in
>> > > the process, such as getting archives: should we generate one
>from the
>> > > source-git repo or use the official release archive from
>upstream?
>> >
>> > One thing to consider is that the upstream tarballs might be
>cryptographically
>> > signed and packages should verify the signature in %prep.
>> 
>> This is a very good point - in such a case, we should always pull the
>> official upstream tarball instead of generating a new one downstream.
>
>Hmm, but how would that work? I thought that the whole point of
>source-git is to build from a commit that contains some upstream 
>version + downstream patches + downstream distro config like the spec
>file,
>and that the build step of applying downstream patches just doesn't
>exist.
>If you reuse the upstream tarball, then by necessity those downstream
>patches need to be serialized and applied on top like in dist-git. So
>you lose the property that the checkout from version control is *the*
>source you build, but you also lose the property that the source you
>build is what was signed (since patches are applied).

But if the tooling automatically creates the "correct" srpm for you (e.g. 
either upstream tarball + patches or a git tarball), then I'd consider that a 
valuable improvement already. Sure, it might not be perfect, but it would help.
___
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 Source-git SIG report #1 (June 2021)

[Dan Čermák]

On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok"  wrote:
>On 24. 06. 21 23:07, Miroslav Suchý wrote:
>> Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a):
 One thing to consider is that the upstream tarballs might be
>cryptographically
 signed and packages should verify the signature in %prep.
>>> This is a very good point - in such a case, we should always pull
>the
>>> official upstream tarball instead of generating a new one downstream
>> 
>> Does it matter? If you are able to generate byte2byte identical
>tarball then 
>> you can choose any of them.
>
>AFAIK git does not grantee to produce byte2byte identical archives
>across 
>different versions of git, zlib, gzip etc. So even if upstream signs
>the git 
>generated archive, generating a byte2byte identical one might be
>tricky.

Especially with xz, which iirc has reproducibility issues in parallel mode.
___
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: x86_64-v2 in Fedora

[Dan Čermák]

On June 17, 2021 12:08:44 AM UTC, Neal Gompa  wrote:
>On Wed, Jun 16, 2021 at 6:08 PM Kevin Kofler via devel
> wrote:
>>
>> Neal Gompa wrote:
>> > Yeah, I think that proposal was not workable because of AVX2. The
>> > x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
>> > current x86_64 baseline. All of these instructions were present in
>the
>> > first Intel Macs launched in 2007, as I recall.
>>
>> Still means my Core 2 Duo notebook would no longer be able to run
>Fedora.
>>
>> >> Different question: How is the runtime CPU feature detection /
>> >> dispatch support in glibc coming along? Shouldn't this "work" by
>now?
>> >
>> > No idea, good question, though!
>>
>> Indeed, runtime detection is clearly the way to go.
>>
>> Why does this proposal to desupport hardware for no good reason
>(because the
>> performance gain can be obtained in a compatible way, where it is
>even
>> noticeable at all) keep coming up again and again?
>>
>
>It keeps coming up because we don't have support for subarches in RPM
>for anything but ARM architectures. That deficiency forces us to keep
>considering raising the baseline instead of being able to have select
>packages with subarch content. This is important because not
>everything *can* use glibc-hwcap hardware detection at runtime, and
>sometimes you need optimized binaries.

Honestly, this sounds to me like we rather should find a solution how to "fix" 
this in RPM (I know of the previous unsuccessful attempts). Otherwise I don't 
really see compelling reasons why we should raise the baseline to x86_64v2 when 
it provides very small gain. Because in contrast to runtime detection or 
cutting edge software, this has the disadvantage that once you raise it, you 
throw people out. So it better be worth it and ATM I don't see why it is.


>
>
>--
>真実はいつも一つ！/ 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 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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Dan Čermák]

Petr Viktorin  writes:

> On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote:
>> On 14.06.2021 15:32, Ben Cotton wrote:
>>> Running upstream tests is mandatory.
>> 
>> What about tests that require network access?
>
>
> Thanks for this and all the other concerns about mandatory tests!
> I updated the proposal to mane them not mandatory, but require a smoke 
> test if they're not there.
> I also removed the mention of Fedora CI: it was meant as an escape hatch 
> for tests that need network, but that's now unnecessary.
>
> Diff: 
> https://pagure.io/fork/pviktori/packaging-committee/c/ec9643873c989e0ff264128891665f6ad78f3e4a?branch=new-py-guidelines
> History including other minor changes: 
> https://pagure.io/fork/pviktori/packaging-committee/commits/new-py-guidelines
>
> New wording:
>
> If a test suite exists upstream,
> it *SHOULD* be run in the `+%check+` section.
> If that is not possible with reasonable effort,
> at least a basic smoke test (such as importing the packaged module)
> *MUST* be run in `+%check+`.
>
> You *MAY* exclude specific failing tests.
> You *MUST NOT* disable the entire testsuite
> or ignore its result to solve a build failure.
>
> As an exception,
> you *MAY* disable tests with an appropriate `+%if+` conditional
> (e.g. http://rpm.org/user_doc/conditional_builds.html[bcond])
> when xref:index.adoc#bootstrapping[bootstrapping].
>
> Most errors in Python happen at run-time,
> so tests are extremely important to root out issues,
> especially when mass rebuilds are required.
>
> Common reasons for skipping tests in `+%check+` include requiring
> network access,
> dependencies not packaged in Fedora,
> and/or specialized hardware or resources.

This is much better, thank you! And thanks Miro for the new macro!


Cheers,

Dan
___
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: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Dan Čermák]

Miro Hrončok  writes:

> On 14. 06. 21 19:35, Benjamin Beasley wrote:
>> I’m still in favor of running every test that is even vaguely practical in 
>> %check, but upstream Python packaging practices are wildly diverse 
>> (arguably, a mess) and it seems like a strongly worded SHOULD with a 
>> fallback of “trust the packager” would be a better approach than forcing 
>> packagers to build complicated CI configurations and go to great lengths to 
>> implement and debug network-connected tests they cannot reproduce locally.
>
> I don't disagree with you.
>
> However I think we should at least strictly require a smoke test (such as 
> %python3 -c "import foo, foo.bar") in such cases, for reasons described 
> below...

I would then suggest to change the wording from "Running upstream tests
is mandatory." to "Upstream tests SHOULD be run unless there are
compelling reasons. In that case basic smoke tests MUST be added to
%check".

We could consider suggesting Fedora CI for tests that require network
access, but given the voiced concerns its unlikely to be a viable
alternative for both package maintainers and the Python SIG conducting
Python version bump rebuilds.


Cheers,

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