Installation image layout
by Marek Marczykowski-Górecki
Hi all!
I'm new on this list. I work on Qubes OS, where Fedora is used as a base
distribution.
While trying to build the installation image in reproducible manner[1],
I found the current installation image have unusual layout. Quoting
dracut.cmdline manual page:
squashfs.img | Squashfs from LiveCD .iso downloaded via network
!(mount)
/LiveOS
|- rootfs.img | Filesystem image to mount read-only
!(mount)
/bin | Live filesystem
/boot |
/dev |
... |
This rootfs.img layer makes the image build very much unreproducible.
Why is it even there? Bare squashfs.img layer should be enough. Then,
mount overlayfs over it (I see there is even some partial support for it
in dmsquash-live). Most other Live systems I've seen use just squashfs +
overlayfs (or aufs if kernel is older), so it's commonly tested
configuration. I *guess* it's there for historical reason, from before
aufs/overlayfs being available. Is there any other reason for that?
If there is no other reason, I propose to drop this and have
installer/live filesystem directly in squashfs.img. This have multiple
benefits:
- it's much easier to make the image build process reproducible (see
below)
- less complexity, both in the build and in the boot (the whole
dmsquash-live dracut module can be replaced with <20 line
function[2]
- smaller initramfs (which is extremely important if needed to be
included in efiboot.img, which can't be larger than 32MB)
- slightly faster boot time (device-mapper is slow)
What do you think?
As for the reproducibility, I've made changes to lorax (including
dropping rootfs.img layer), anaconda, pungi and createrepo and this all
allows to build bit-by-bit identical image, given the same input (rpm
packages, pungi configuration, $SOURCE_DATE_EPOCH variable[3]). Well,
almost - there is an issue with efiboot.img, but I already have a
solution, just not pushed it yet.
You can find all the pull requests collected here:
https://github.com/QubesOS/qubes-installer-qubes-os/pull/26
I'll work further to make the changes merged upstream.
[1] https://reproducible-builds.org/
[2] https://github.com/QubesOS/qubes-installer-qubes-os/pull/26/commits/332be...
[3] https://reproducible-builds.org/specs/source-date-epoch/
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
1 day, 14 hours
Bodhi update pushes are now automated
by Mohan Boddu
Hello all,
For a long time now updates are pushed manually everyday. It was
troublesome and someone has to own it for a week and look after it.
Now, the pushes are automated and are pushed everyday at 00:00 UTC. If
anything fails there will be an oncall person (same person who used to do
the pushes) who will take care of the failure.
During release freezes these automated pushes are disabled and are manually
pushed by RelEng/Infra. Since freezes should be handled differently this
will give RelEng more control over the pushes.
Please let us know if you have any questions or contact us on
#fedora-releng on Freenode.
Thanks,
Mohan Boddu.
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
1 week, 2 days
Lifecycle objective - problems, solutions, and proposal
by Paul Frields
I worked with FPL Matthew Miller and our engineering manager Jim
Perrin, among others, to define the various problems we want to solve
in diversifying the Fedora lifecycle. We're seeking review and
feedback from community members. The most salient feedback will be
from those involved in the efforts we describe, but we welcome all
constructive feedback.
Here's the summary from the page, which proposes we pause the release
after F30 for these efforts:
* * *
Fedora’s singular lifecycle has been in place for almost a decade and
a half. During that time, technology users have changed how they
consume platform and applications. Fedora needs to be more toward the
forefront of these changes. But more importantly, Fedora needs to be
more hospitable to community management of lifecycle.
Currently Fedora can’t scale for more community ownership of the
things we release: (1) Only a few people can build and push out
releases; and (2) we manage releases largely based on that staffing.
The Fedora community should be able to run releases of content
themselves, using tools that work well, with only minimal oversight,
and determine their own schedule for doing so.
This implies a great deal of both redesign and reworking of tools and
processes. To unblock the community, several things need to happen. We
need a faster, more scalable compose to enable CI/CD operations; we
need to automate more testing and quality measures; and we need to
update our delivery tools and processes. We also need to track and
coordinate this work across teams, since it involves collaboration
among Fedora infrastructure, QA, applications, release engineering,
CentOS CI, maintainers, and more.
We should skip the F31 release cycle and leave F30 in place longer in
order to focus on improving the tooling and testing changes. These
tooling changes will improve the overall reliability of Fedora, and
will decrease the manual effort and complexities involved in producing
the distribution artifacts. Although we’ve done this before to make
“editions” happen, the intent is to track this multi-team effort more
actively so we can (1) use the time as well as possible, and (2) give
the work maximum transparency.
* * *
The full page is here, with a set of problems, solutions, and actions
proposed. I invite you to take time to read it in detail:
https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements
I also attached that page to the main Lifecycle objective page here,
which was previously approved by the Council:
https://fedoraproject.org/wiki/Objectives/Lifecycle
Rather than try to spin this one email into a thread of doom that
people will give up on reading, I encourage those with feedback to
open a thread for any particular topic. That way the community
discussion should be more useful for all.
I'll collect input and use it both for responses and to help tweak
plans for (hopefully) optimal results. I'm on vacation next week, for
which timing I apologize. But I'll try to look at mail here from time
to time and when I return.
--
Paul
1 week, 4 days
What does delaying F31 mean for packagers/users?
by Owen Taylor
One of the key parts of making a decision to delay/skip F31 is
figuring out, ahead of the decision, what the expected experience is
for users and packagers. Does F30 have normal stability, or do we try
to keep users happy by moving things forward with ad-hoc updates and
cross-our-fingers and hope nothing breaks?
I tend to think about this in terms of GNOME - would we rebase to
GNOME 3.34 in the middle of F30 or not? But there's a lot of other
pieces of software where similar considerations apply: container
tools, cockpit, NetworkManager, etc.
And if we did do updates like that, would we consider respinning media
and making a "F30.1"?
Owen
1 week, 6 days
Upgraded from F28 x96_64 XFCE Spin to F29 => rough audio
by Philip Rhoades
People,
I haven't seen any posts about this but is anyone else having problem
with audio after an upgrade? - it happens with both PulseAudio and with
just basic ALSA. I have a relatively simple setup:
*-multimedia
description: Audio device
product: 200 Series PCH HD Audio
vendor: Intel Corporation
physical id: 1f.3
bus info: pci@0000:00:1f.3
version: 00
width: 64 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list
configuration: driver=snd_hda_intel latency=32
resources: irq:133 memory:df140000-df143fff
memory:df120000-df12ffff
The audio is bearable for spoken stuff but for music it is not . . very
staticky - like a recording done with a very old, cheap microphone . .
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
2 weeks, 3 days
Automating Package Review (Was: fedora-review -- do we have a maintainer?)
by Stephen Gallagher
On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny <clime(a)redhat.com> wrote:
> On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl> wrote:
>
>> f-r currently fails to build (#1603956), it has a bunch of bugs open [1]
>> and many issues and unhandled pull requests in the upstream repo [2, 3].
>> The last upstream commit was 2 years ago.
>>
>> f-r has is annoyingly outdated and gives often outright bad advice
>> (for example about BR:gcc or BR:g++). The situation would be
>> significantly
>> improved if the outstanding PRs were merged.
>>
>> f-r is also python2-only now, which will be a problem soon since
>> support for python2 is waning [4].
>>
>> Is there any hope of upstream and downstream activity on f-r?
>>
>
> I was thinking about getting the fedora-review checks rewritten into the
> standard Test interface
> (
> https://qa.fedoraproject.org/docs/libtaskotron/latest/standard-test-inter...)
> so that they
> can be run in Taskotron. We can also just probably run one big
> fedora-review check from
> a taskotron test, well, this just came to my mind recently, getting the
> actual solution ready
> might take a little bit of time.
> '
>
I'd *really* like to see us get to a point where package review is
fully-automated. Basically we could just have a web-service that you pass a
URL to an SRPM plus authenticate with your FAS account and it will perform
all of the validity checks and if they all pass would go ahead and request
the branches for you and import the SRPM.
Once this is fully automated, we can then *also* add the same checks to CI
(taskotron, OSCI or whatever) so that on each build it gets rerun, which
will allow us to help reduce the rate of packages falling out of compliance
(as well as being updated whenever the checks get made more comprehensive).
Historically, we've had human review mainly to protect against two things,
bundling and unacceptable licenses. In both of these cases, I'd like for us
to move towards a culture of assuming goodwill on behalf of our packagers.
Most of the packagers in Fedora have been doing it for a long time and know
what is and is not acceptable. Optimizing for the minority case is
wasteful, especially when it adds hurdles and delays to getting software
delivered.
I think what we should instead do is allow things through immediately
following automated review and just assume that those few cases that slip
through that should not will get handled after the fact as soon as they are
noticed (either by someone noticing or an improvement in the automated tool
discovering the problem).
I feel strongly that automated, continuous review would be of far greater
value to Fedora than front-loading the review process the way we have been
doing (which serves mostly to discourage people from even starting).
1 month
Fedora Hardware portal
by Andrey Ponomarenko
Hi,
The Linux-Hardware.org database has been divided recently into a set of databases, one per each Linux distro. The one for Fedora is available at:
https://linux-hardware.org/?d=Fedora
Everyone can contribute to the database with the help of https://github.com/linuxhw/hw-probe (various packages are available: AppImage, Snap, Flatpak, Docker, RPM, etc.). The tool is intended to simplify collecting of hardware info and logs necessary for investigating hardware related problems. You need to execute only one simple command to collect all system logs at once:
sudo hw-probe -all -upload
Hardware failures are highlighted in the collected logs (important SMART attributes, errors in dmesg and xorg.log, etc.). Also it's handy to search for particular hardware configurations in the community and review errors in logs to check operability of devices on board (for some devices this is done automatically by hw-probe — see statuses of devices in your probe).
Hardware stats and raw data are dumped to Github repositories: https://github.com/linuxhw
Enjoy!
1 month
Commit notifications for Fedora dist-git
by Florian Weimer
On src.fedoraproject.org, I selected “Watch Issues, PRs, and Commits”
for various packages and assumed that I would receive notifications for
new commits. But nothing arrives anymore, as far as I can tell.
Obviously, this is problematic if proven packages do uncoordinated
package changes.
What can we do here? I can filter down scm-commits, but I don't know
how complete those notifications are.
Thanks,
Florian
1 month
