I'm new on this list. I work on Qubes OS, where Fedora is used as a base
While trying to build the installation image in reproducible manner,
I found the current installation image have unusual layout. Quoting
dracut.cmdline manual page:
squashfs.img | Squashfs from LiveCD .iso downloaded via network
|- rootfs.img | Filesystem image to mount read-only
/bin | Live filesystem
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
- it's much easier to make the image build process reproducible (see
- less complexity, both in the build and in the boot (the whole
dmsquash-live dracut module can be replaced with <20 line
- 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). 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:
I'll work further to make the changes merged upstream.
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?
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 
>> 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
>> 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 .
>> 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
> 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
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).
I've been bitten twice in the past week by dependencies of my packages
dropping the Python 2 RPMs, presumably due to the Fedora 30 change.
Note that the change does state that the package should not be dropped
if other packages depend on them.
On that note, I do know how to check if other packages Require my
$ dnf repoquery --whatrequires <something_my_package_provides>
How do I check if other packages BuildRequire my package? There doesn't
seem to be a --whatbuildrequires option on dnf's repoquery.
I try build new version of perdition package.
It build fine
(https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416) on all
architectures except armv7hl and s390x. On that I got
error: Installed (but unpackaged) file(s) found:
Could someone please help me solve that problem?
With best wishes, Pavel Alexeev.
Yes, I'm a fool - I believe in people, honesty, justice as open source.
And also in the fact that I can make this world just a little better
unless stop fighting.
new meson release is out (release notes
<https://mesonbuild.com/Release-notes-for-0-48-0.html>) which removes tools
which are deprecated for quite long time:
I will push it now for Rawhide and F29. F28 and EPEL7 won't get update
because of this incompatibility, but if you need it for building updates --
let me know and I will consider pushing it even there.
Thanks for attention!
There was a bug filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
At yesterday's F29 Go/No-Go meeting, we discussed the blocker status
of BZ #1628192 - Fedora 29 installation cannot see a firmware RAID
device. While the blocker criteria clearly states that this should be
a blocker for Beta, many of the people present at the meeting
disagreed, for a variety of reasons.
* Hardware supporting fwraid is considerably less pervasive than it
was when the criterion was written
* Testing this criterion can only be done with install media, which
limits our testing pool to the very dedicated members of Fedora QA.
Yes, anyone *can* download a nightly compose and try it, but in
practice this tends to be limited to the core testers. The majority of
testing that this feature will get will tend to happen as people try
out the Beta release.
To that end, I'd like to propose that we make the following change to
the criteria going forward:
"The blocking criterion for successful installation atop a firmware
RAID array is moved to the GA release criteria."