devel August 2019

devel@lists.fedoraproject.org

236 participants
363 discussions

Fedora 31 System-Wide Change proposal (late): No i686 Repositories
by Miro Hrončok 21 Sep '19

21 Sep '19

https://fedoraproject.org/wiki/Changes/Noi686Repositories (Ben is on vacation, so I announcing this on his behalf.) == Summary == Stop producing and distributing the Modular and Everything i686 repositories. == Owner == * Name: Kevin Fenzi * Email: kevin(a)scrye.com == Current status == * Targeted release: [[Releases/31| Fedora 31 ]] * Last updated:  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} * Tracker bug: <will be assigned by the Wrangler> * Release notes tracker: <will be assigned by the Wrangler> == Detailed Description == With the dropping of the i686 kernel package it's no longer possible to directly install Fedora 31 or later on i686 hardware, however, it is still possibly to upgrade older releases as long as we continue to provide a repository. This will leave those users with an old possibly vulnerable kernel installed. The only other use/need for the repostories is to allow maintainers to debug and test fixes for multilib shipped packages, but the koji buildroot repo can be used for this use case. == Benefit to Fedora == * users won't try and upgrade old i686 installs with insecure kernels. * compose times will be decreased (no more gathering i686 packages up and running createrepo on them). * Updates push times will be reduced. * disk size on mirrors will be reduced. == Scope == * Proposal owners: ** modify pungi-fedora to no longer produce i386 repo for Everything and Modular, modify bodhi config for f31+ to not make i386 repos for updates/updates-testing. ** modify mock to use the koji buildroot for i686 for f31+ for those few users that need to build i686 packages locally. * Other developers: n/a * Release engineering: [https://pagure.io/releng/issues 8529] == Upgrade/compatibility impact == i686 users will not be able to upgrade, and will have to move to another supported arch. == How To Test == * Confirm that there are no trees under https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Every… or https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Modul… * Confirm that there are no trees under https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|Mo… or https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Every… * Confirm that mock can init a chroot for fedora-i386-31 using the koji buildroot repository. == User Experience == * Users will get updates and rawhide and rc composes faster. * Users will not be able to upgrade to a insecure Fedora configuration. == Contingency Plan == i686 trees will just continue to be composed and published. Users can upgrade to them (with an old kernel from f30). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

48 165

swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations
by Chris Murphy 19 Sep '19

19 Sep '19

Hi, This is yet another follow-up for this thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Basics: "zswap" compresses swap and uses a defined memory pool as a cache, with spill over (still compressed) going into a conventional swap partition. The memory pool doesn't appear as a separate block device. A conventional swap partition on a drive is required. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docum… "swap on ZRAM" A ZRAM device appears as a block device, and is effectively a compressed RAM disk. It's common for this to be the exclusive swap device, of course it is volatile so in that configuration your system can't hibernate. But it's also possible to use swap priority in fstab to cause the ZRAM device to be used with higher priority, and a conventional swap partition on a drive with a lower priority. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docum… What they do: Either strategy can help avoid swap thrashing, by moderating the transition from exclusively RAM based work, to heavy swapping on disk. In my testing, the most aggressive memory starved workloads still result in an unresponsive system. Neither are a complete solution, they really seem to just be moderators that kick the can down the road. But I do think it's an improvement especially in the incidental swap use case, where transition from memory to swap isn't noticeable. Which is better? I don't know. Seriously, that's what all of my testing as come down to. A user won't likely notice the difference. Both dynamically allocate memory to their "memory pools" on demand. But otherwise, they really are two very different implementations. Regardless, Fedora Workstation and probably even Fedora Server, should use one of them by default out of the box. IoT folks are already using swap on ZRAM by default, in lieu of a disk based swap partition. And Anaconda folks are doing the same for low memory devices when the installer is launched. I've been using zswap on Fedora Workstation edition on my laptop, and Fedora Server on an Intel NUC, for maybe two years (earlier this summer I switched both of them swap on ZRAM to compare). How are they different? There are several "swap on ZRAM" implementations. The zram package in Fedora right now is what IoT folks are using which installs a systemd service unit to setup the ZRAM block device, mkswap on it, and then swapon, during system startup. Simple. The ideal scenario is to get everyone on the same page, and so far it looks like systemd's zram-generator, built in Rust, meets all the requirements. That needs to be confirmed, but also right now there's a small problem, it's not working. So we kinda need a someone familiar with Rust and systemd to take this on, if we want to use the same thing everywhere. https://github.com/systemd/zram-generator/issues/4 Whereas zswap is setup by using boot parameters, which we could have the installer set, contingent on a conventional swap partition being created. zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20 zswap.zpool=zbud Zswap upstream tells me they're close to dropping the experimental status, hopefully by the end of the summer. It might be a bit longer before they're as confident with zpool type z3fold. Hackfest anyone? -- Chris Murphy

4 6

plan to orphan cassandra
by Honza Horak 18 Sep '19

18 Sep '19

Cassandra has been originally packaged by folks in our team, in the time we had some stakes there. Since then, priorities changed and also people involved are not in our team any more. We tried to keep it packaged in Fedora with reasonable effort, but turned to be too big burden recently (depends on python2, missing java deps). From that reason, with sadness in my heart, I'd like to announce a plan to orphan the cassandra package in Fedora. So, this is obviously a call for everybody who would like to take it over -- let me know. There is also an idea to build it as a module, which could help us with missing deps, but that would be done later and does not change the plan for orphaning. Cheers, Honza

4 6

getting below error in fedpkg clone
by Muneendra Kumar M 16 Sep '19

16 Sep '19

Hi , Iam getting the below error when I run fedpkg clone fctxpd fedpkg clone fctxpd Cloning into 'fctxpd'... The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4' (RSA) to the list of known hosts. muneendra(a)pkgs.fedoraproject.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Could not execute clone: Failed to execute command. I have added the ssh-key at https://pagure.io/settings#nav-ssh-tab But still iam getting the below error. Can anyone help me where iam doing the mistake. Regards, Muneendra.

7 11

Donate 1 minute of your time to test upgrades from F29 to F30
by Miroslav Suchý 13 Sep '19

13 Sep '19

Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run: sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer N and nothing happens, no need to test the real upgrade. Upgrades will be fine for you. But very likely you get some dependency problem now. In that case please report it against appropriate package. Thank you Miroslav

37 71

Better interactivity in low-memory situations
by Chris Murphy 13 Sep '19

13 Sep '19

This subject matches a Fedora Workstation Working Group issue of the same name [1], and this post is intended to be an independent summary of the findings so far, and call for additional testing and discussion, in particular subject matter experts. Problem and thesis statement: Certain workloads, such as building webkitGTK from source, results in heavy swap usage eventually leading to the system becoming totally unresponsive. Look into switching from disk based swap, to swap on a ZRAM device. Summary of findings (restated, but basically the same as found at [2]): Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM, Samsung SSD 840 EVO, Fedora Rawhide Workstation. Test case, build WebKitGTK from source. $ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja $ ninja Case 1: 8GiB swap on SSD plain partition (not encrypted, not on LVM) Case 2: 8GiB swap on /dev/zram0 In each case, that swap is exclusive, there are no other swap devices. Within ~30 minutes in the first case, and ~10 minutes in the second case, the GUI is completely unresponsive, mouse pointer has frozen and doesn't recover after more than 30 minutes of waiting. By remote ssh, the first case is semi-responsive, updates should be every 5 seconds but are instead received every 2-5 minutes but it wasn't possible to compel recovery by cancelling the build process after another 30 minutes. By remote ssh, the second case is totally unresponsive, no updates for 30 minutes. The system was manually forced power off at that point, in both cases. oom killer never triggered. NOTE: ninja, by default on this system, sets N concurrent jobs to nrcpus + 2, which is 10 on this system. If I reboot with nr_cpus=4, ninja sets N jobs to 6. Case 3: 2GiB swap on /dev/zram0 In one test this resulted in system hang (no pointer movement) within 5 minutes of executing ninja, and within another 6 minutes oom killer is invoked on a cc1plus process, which is fatal to the build process, remaining build related processes quit on their own, and the system eventually recovers. But in two subsequent tests in this same configuration, oom killer wasn't invoked, and the system meandered between responsive for ~1 minute, totally frozen for 5-6 minutes, in a cycle lasting beyond 1 hour without ever triggering oom killer. Screenshot taken during one of the moments the remote ssh session updated https://drive.google.com/open?id=1IDboR1fzP4onu_tzyZxsx7M5cT_RJ7Iz The state had not changed after 45 minutes following the above screenshot so I forced power off on that system. But the point here is this slightly different configuration has some non-determinism to it, even though in the end it's a bad UX. The default, unprivileged build command is effectively taking down the system all the same. Case 4: 8GiB swap on SSD plain partition, `ninja -j 4` This is the same setup as Case 1, except I manually set N jobs to 4. Build succeeds, and except for a few mouse pointer stutters, the system remains responsive, even Firefox with multiple tabs open, and youtube video playing. Exactly the experience we'd like to see, albeit not all CPU resources are used for the build, but clearly the limiting factor is this particular package requires more than ~14GiB to build successfully, and the system + shell + Firefox, just doesn't have that. Starter questions: To what degree, and why, is this problem instigated by the build application (ninja in this example) or its supporting configuration files, including cmake? Or the kernel? Or the system configuration? Is it a straightforward problem, or is this actually somewhat nuanced with multiple components in suboptimal configuration coming together as the cause? Is it expected that an unprivileged user can run a command whose defaults eventually lead to a totally unrecoverable system? From a security risk standpoint, the blame can't be entirely on the user or the application configuration, but how should application containment be enforced? Other than containerizing the build programs, is there a practical way right now of enforcing CPU and memory limits on unprivileged applications? Other alternatives? At the very least it seems like getting to an oom killer sooner would result in a better experience, fail the process before the GUI becomes unresponsive and hangs out for 30+minutes (possibly many hours). [1] https://pagure.io/fedora-workstation/issue/98 [2] https://pagure.io/fedora-workstation/issue/98#comment-588713 Thanks, -- Chris Murphy

16 38

Intention to retire Release Notes RPM
by Brian (bex) Exelbierd 13 Sep '19

13 Sep '19

Hi All, Barring objection, I plan to retire the release notes package from Fedora on or after August 9, 2019. The package has not been updated since F28. Despite the fact that we have literally shipped a package containing the F28 release notes in F29 and F30, there have been no comments. This has been discussed with the docs team and is supported. I am not aware of any dependencies and I believe it was removed from release criteria in F29. I will run `fedpkg retire` and further request removal via https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&co… Please reply on list if you have any questions or concerns. regards, bex -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexelbie(a)redhat.com | bex(a)pobox.com

6 9

Re: Possibly unresponsive maintainer: vakwetu
by Fabio Valentini 13 Sep '19

13 Sep '19

On Tue, Jul 9, 2019 at 3:26 PM Rob Crittenden <rcritten(a)redhat.com> wrote: > > Fabio Valentini wrote: > > Hi everybody, > > > > While working on packages of the Stewardship SIG, I again came across > > another package that is in dire need of attention, while its main > > admin seems to be AWOL (even though the email address associated with > > his FAS account is a Red Hat one): > > > > - no bodhi updates in 4 years [0] > > - no bodhi comments in 2 years [0] > > - no koji builds in 4 years [1] > > > > There's also been no response to security issues on bugzilla, > > including CVE-2016-6346, CVE-2016-6347, CVE-2018-1051, CVE-2016-9606, > > CVE-2016-6345, CVE-2016-6348 - all of which are filed against the > > resteasy package, which is, entirely by coincidence (*sigh*), exactly > > the package that we need fixed for some Stewardship SIG packages. > > > > Since it looks like he's not been contributing to fedora in about 2-4 > > years, I will initiate the non-responsive maintainer process with > > FESCo if I don't get any negative feedback within a week. > > > > Fabio (decathorpe) > > > > [0]: https://bodhi.fedoraproject.org/users/vakwetu > > [1]: https://koji.fedoraproject.org/koji/userinfo?userID=2030 > > He's on PTO for a few weeks. > > rob Good to know, thanks! If it's necessary to fix the broken package (resteasy) before he's back, I'll use my provenpackager powers. Fabio

4 7

Packit-as-a-Service is now live!
by Tomas Tomecek 12 Sep '19

12 Sep '19

We are happy to announce the availability of Packit-as-a-Service [1], a GitHub App, which utilizes the Packit project [2]. Using the Packit service in your upstream projects helps you continuously ensure that your projects work in Fedora OS. Just add one config file [3] to your repository, along with the RPM spec file and you're almost there. We have started publishing docs for the service over here [4]. In the next couple of months, Packit Service will run in an invite-only mode, where we need to manually approve every user of the app. Our initial target is Fedora contributors. Packit service validates your pull requests by building your software in Fedora OS. Once the builds are done, Packit lets you know how to install the RPM with the change inside your environment. Packit service helps you test the changes before merging them to the main developer branch and shipping them to your users. Happy hacking! The packit team [1] https://github.com/apps/packit-as-a-service/ [2] https://packit.dev/ [3] https://github.com/packit-service/packit/blob/master/docs/configuration.md [4] https://packit.dev/packit-as-a-service/

2 1

Interest in doing Fedora CI with test subpackages
by Neil Horman 12 Sep '19

12 Sep '19

Hey all- I was starting to setup CI for one of my packages in Fedora (cscope), which requires that I have access to the sources to run my test (cscope uses its own source tree to search for various symbols to confirm that its working properly). Getting the sources in the CI environment is a bit of a pain, so I started working on trying to do this by creating a test subpackage (specifically named -citest) to package up the sources solely for the purpose of getting them installed and available during CI runs. It occured to me that this offers several advantages, among them: 1) the ability to codify dependencies within the ame spec file, rather than having to copy them to the test.yml file, and keep them in sync 2) The ability to use a file format (rpm spec files) that I'm more familiar with 3) Easy access to tests that are embedded in the source tree 4) minimizing the test harness setup in test.yml For anyone interested, I've got a pull request started here: https://src.fedoraproject.org/rpms/cscope/pull-request/2 If anyone wants to take a look at the changes I had to make to do this (fair warning, its still very rough). That all said, I was wondering if perhaps there was general interest in making this kind of test model somewhat more formal (i.e. creating an rpm macro library to make test package generation a bit easier, creating a standard entry point to run tests, etc). Thoughts welcome

3 3

← Newer
1
2
3
4
5
6
7
...
37
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 August 2019