devel November 2018

devel@lists.fedoraproject.org

227 participants
247 discussions

What does delaying F31 mean for packagers/users?
by Owen Taylor 04 Jan '19

04 Jan '19

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

17 23

Upgraded from F28 x96_64 XFCE Spin to F29 => rough audio
by Philip Rhoades 01 Jan '19

01 Jan '19

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

5 9

fedora-rawhide-kernel-nodebug is not getting updates
by Igor Gnatenko 19 Dec '18

19 Dec '18

Does anybody know why? Last kernel available there is 2 weeks old. https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/

7 7

Automating Package Review (Was: fedora-review -- do we have a maintainer?)
by Stephen Gallagher 18 Dec '18

18 Dec '18

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-interfa…) > 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).

10 15

Fedora Hardware portal
by Andrey Ponomarenko 18 Dec '18

18 Dec '18

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!

3 4

PSA: Please check that your Python 2 package doesn't have dependent packages before dropping it
by Randy Barlow 14 Dec '18

14 Dec '18

Greetings! 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[0]. 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 package: $ 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. [0] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

3 3

Commit notifications for Fedora dist-git
by Florian Weimer 14 Dec '18

14 Dec '18

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

2 3

Spam/scam links in bugzilla
by Alexander Ploumistos 09 Dec '18

09 Dec '18

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=d… 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

8 8

Fedora Lifecycles: imagine longer-term possibilities
by Matthew Miller 07 Dec '18

07 Dec '18

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

59 168

Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
by Jonathan Dieter 05 Dec '18

05 Dec '18

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#Chal… [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

31 57

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2018