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
4 years, 8 months
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
4 years, 8 months
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).
4 years, 9 months
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!
4 years, 9 months
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
4 years, 9 months
Spam/scam links in bugzilla
by Alexander Ploumistos
Hello,
A few minutes ago I was notified about a post in a closed bug. It
turns out that the account that made the post has been sporadically
spamming various bugs:
https://bugzilla.redhat.com/page.cgi?id=user_activity.html&action=run&who...
The websites that are being linked to from these posts seem to be of
the support scam garden variety.
I did not know where to report this, hence this message.
Can someone nuke the posts or at least the hyperlinks?
Btw, bugzilla reports that there are multiple accounts with the same
name, so that might be worth looking into.
Regards,
Alex
4 years, 9 months
Fedora Lifecycles: imagine longer-term possibilities
by Matthew Miller
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.
When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_. So, digging in, it often really
means "I don't want the pain and fear of big OS upgrades".
We've addressed that in several ways: first, making upgrades better.
(Thanks everyone who has worked on that.) A Fedora release-to-release
update is normally not much more trouble than you might get some random
Tuesday with a rolling release. Second, we have some things like Fedora
Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
rolling stream on top of the Fedora release base. And finally, there's
the coming-someday plans for gating Rawhide, making that a better
proposition for people who really want to live on the edge.
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.
So, what would this look like? I have some ideas, but, really, there
are many possibilities. That's what this thread is for. Let's figure it
out. How would we structure repositories? How would we make sure we're
not overworked? How would we balance this with getting people new stuff
fast as well?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4 years, 9 months
Proposal: Faster composes by eliminating deltarpms and using
zchunked rpms instead
by Jonathan Dieter
For reference, this is in reply to Paul's email about lifecycle
objectives, specifically focusing on problem statement #1[1].
<tl;dr>
Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time. This will require changes
to both the rpm format and new features in the zchunk format.
</tl;dr>
*deltarpm background*
As part of the compose process, deltarpms are generated between each
new rpm and both the GA version of the rpm and the previous version.
This process is very CPU and memory intensive, especially for large
rpms.
This also means that deltarpms are only useful for an end user if they
are either updating from GA or have been diligent about keeping their
system up-to-date. If a user is updating a package from N-2 to N,
there will be no deltarpm and the full rpm will be downloaded.
*zchunk background*
As some are aware, I've been working on zchunk[2], a compression format
that's designed for highly efficient deltas, and using it minimize
metadata downloads[3].
The core idea behind zchunk is that a file is split into independently
compressed chunks and the checksum of each compressed chunk is stored
in the zchunk header. When downloading a new version of the file, you
download the zchunk header first, check which chunks you already have,
and then download the rest.
*Proposal*
My proposal would be to make zchunk the rpm compression format for
Fedora. This would involve a few additions to the zchunk format[4]
(something the format has been designed to accommodate), and would
require some changes to the rpm file format.
*Benefit*
The benefit of zchunked rpms is that, when downloading an updated rpm,
you would only need to download the chunks that have changed from
what's on your system.
The uncompressed local chunks would be combined with the downloaded
compressed chunks to create a local rpm that will pass signature
verification without needing to recompress the uncompressed local
chunks, making this computationally much faster than rebuilding a
deltarpm, a win for users.
The savings wouldn't be as good as what deltarpm can achieve, but
deltarpms would be redundant and could be removed, completely
eliminating a large step from the compose process.
*Drawbacks*
1. Downloading a new release of a zchunked rpm would be larger than
downloading the equivalent deltarpm. This is offset by the fact
that the client is able to work out which chunks it needs no matter
what the original rpm is, rather than needing a specific original
rpm as deltarpm does.
2. The rebuilt rpm may not be byte-for-byte identical to the original,
but will be able to be validated without decompression, as explained
in the next section
*Changes*
The zchunk format would need to be extended to allow for a zchunked rpm
to contain both the uncompressed chunks that were already on the local
system and the newly downloaded compressed chunks while still passing
signature verification. This would also require moving signature
verification to zchunk.
The rpm file format has to be changed because the zchunk header needs
to be at the beginning of the file in order for the zchunk library
figure out which chunks it needs to download. My suggestions for
changes to the rpm file format are as follows:
1. Signing should be moved to the zchunk format as described at the
beginning of this section
2. The rpm header should be stored in one stream inside the zchunk
file. This allows it to be easily extracted separately from the
data
3. The rpm cpio should be stored in a second stream inside the zchunk
file.
4. At minimum, an optional zchunk element should be set to identify
zchunk rpms as rpms rather than regular zchunk files. If desired,
optional elements could also be set containing %{name}, %[version},
%{release}, %{arch} and %{epoch}. This would allow this information
to be read easily without needing to extract the rpm header stream.
*Final notes*
I realize this is a massive proposal, zchunk is still very young, and
we're still working on getting the dnf zchunk pull requests reviewed.
I do think it's feasible and provides an opportunity to eliminate a
pain point from our compose process while still reducing the download
size for our users.
[1]:
https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements#Ch...
[2]: https://github.com/zchunk/zchunk
[3]: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
[4]: https://github.com/zchunk/zchunk/blob/master/zchunk_format.txt
4 years, 9 months
