Hi,
About this documentation [0], finally talks about rescue a bootloader
with live images ... (but I will wrote about that in another time)
I run in trouble on cloning a disk from an old computer and starting
booting on a new computer , security get the thing more complicated, I
had to disable secure boot and selinux not sure , but I advice boot
with kernel parameter selinux=0
my old computer was bios legacy and the new have UEFI and here starts
the challenge .
I think just after do the lvm steps (my disks have lvm partitons) [1] I
start to boot correctly and the problem (I think) was that I need to
run one time
'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg' . I think is wrong
use grub2-mkconfig -o /boot/grub2/grub.cfg , like it is wrote on grub2
on a uefi system [2], should we fix it ? and the advice of boot with
selinux=0 ?
Best regards,
[0]
https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/
[1]
https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/#_lvm_steps
[2]https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/#_instal…
--
Sérgio M. B.
Kenneth Goldman kirjoitti 3.5.2024 klo 23.07:
> A review from a complete newbie ...
>
> 1. The link points to a pull request. Where is the actual tutorial?
At the time you and I originally wrote, nowhere. The docs development
workflow is to update the documentation source Git using the usual
workflow with pull requests and so, then automation periodically (once a
day I think?) generating the actual docs.fedoraproject.org site.
It would be great to have automation that generates a temporary site for
each pull request, and it would be even more great if it would also
highlight changed/added/removed parts in the resulting site. But at the
moment, we do not have anything like that. So if reading Pagure's texual
diff does not work (which, for large changes, it often does not), then
you need to fetch the pull request's branch and generate the site
locally. Repo's README tells you how to that.
But in this case, by coincidence, I just merged the pull request, so now
you can read the actual tutorial live [2]. Feedback is still welcome, if
you have any!
[2]:
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial…
> 2. The page refers to Pagure, Antora, ... I wonder if they're necessary for
> packaging.
I am not sure what you are referring to with "the page". The pull
request page?
Antora is the site generator used for Fedora Docs, and Package
Maintainer Docs sources are hosted on pagure.io, so both of those are
very much necessary for docs writing. If Pagure or Antora arenecessary
for packaging? The answers are "yes" and "no". But the tutorial itself
does not even mention either.
> As a newbie, I would like an example that looks like:
>
> 1. Push the main branch to github.
> 2. Do these steps.
> n. Push the result to Fedora.
I agree. For now, the tutorial only covers specfile writing and test
builds, but does not have anything about interaction with upstream,
pushing to dist-git or official Fedora builds. Extending the tutorial to
also cover those topics (in part 3 and beyond) would not be very
difficult. The main issue is that we would need a dummy upstream project
solely for this purpose, and some people to play the part of upstream
developers, to merge pull requests from people following the tutorial.
There was a thread about this kind of tutorial in devel some years ago
also, but unfortunately I cannot seem to find it now.
salt-master has been broken on Fedora since Fedora 39, when we moved to Python 3.12.
https://bugzilla.redhat.com/show_bug.cgi?id=2250197
Upstream doesn't seem particularly interested in supporting anything outside of their 'onedir' packaging, which bundles it's own Python stack. Most of the work required to work on 3.12, I THINK, involves unbundling twisted, which is non-trival.
The good news is that they do that with the 3007.x series. The bad news is that that requires a recent version of python-cryptography that breaks several other packages:
https://bugzilla.redhat.com/show_bug.cgi?id=2257380
Since I needed something that works for config management, I've migrated my own stuff from salt to something that works with distro packaging and doesn't have odd version constraints¹.
As a consequence, I can no longer sufficiently test new releases. As a result, I've just sent 3006.8 to updates-testing for rawhide-f38, and will orphan salt on May 21 2024, when f38 is EOL.
If someone wants to take ownership before then, please let me know.
-Gwyn
1. Ansible.
--
Gwyn Ciesla
she/her/hers
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with Proton Mail secure email.
Hello everybody,
I wrote a pull request for Package Maintainer Docs about adding a
simpler tutorial package than GNU Hello [1]. Since it is a larger change
and I have not received any reviews yet, I would like to announce this
work here, in hope of getting some feedback, before just merging the
change. Since I have already described the work in the pull request
description, I will just copy it here below. Feel free to respond on the
list or in pull request comments.
[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/153
> Add simpler Banner package to packaging tutorial
>
> Packaging tutorial's approach of packaging GNU Hello has suffered from
> certain complexities in GNU Hello package. The package is quite old and
> uses some tooling from the GNU project that are not very widely used
> any more, such as Texinfo. Also, the package is old and thus suffers
> from e.g. having a file that is not UTF-8 encoded. To avoid immediately
> exposing tutorial readers to these quirks, make GNU Hello part 2 of the
> tutorial and add a simpler package, Banner, as part 1. This way the
> reader can reach a complete specfile, compliant with Fedora guidelines,
> quicker, and still get a feeling for resolving packaging quirks in the
> second part.
>
> In the future, basing the first tutorial on real packages should
> probably be switched to hosting dedicated "test project", which avoid
> any quirks and can be packaged to Fedora requirements using only
> Fedora's set of RPM macros. Such package should also avoid GNU
> Autotools and be based on CMake or Meson, which are simpler to
> understand and more widespread today.
Dear all,
You are kindly invited to the meeting:
ELN SIG on 2024-05-03 from 12:00:00 to 13:00:00 US/Eastern
At fedora-meeting(a)irc.libera.chat
The meeting will be about:
Source: https://calendar.fedoraproject.org//meeting/10568/