devel August 2019

devel@lists.fedoraproject.org

236 participants
361 discussions

plan to orphan cassandra
by Honza Horak 17 Sep '19

17 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 11 Sep '19

11 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

Please help with youtube-dl and possibly other packages of mine.
by Till Maas 11 Sep '19

11 Sep '19

Hi, Please help with updating youtube-dl and possibly other packages of mine because I cannot do it and my comaintainers do not seem to be able to do it as well. Thank you and kind regards Till

4 4

[HEADS UP] Retiring python2 and introducing python27 later this week
by Miro Hrončok 11 Sep '19

11 Sep '19

We are retiring python2 and introducing python27 later this week. Rawhide only. As for now, nothing should break, except python2-debug will exist no more. Packages (build)requiring python2 or python2-devel should continue to work for now. If not, let us know. If you plan to keep a Python 2 package in Fedora 32+, talk to me, I can help you draft an exception request. Will post a reply here once it is done. The following packages build subpackages for python2-debug (and should stop doing it in Fedora 32+): - gcc-python-plugin (FTBFS) - python-mysql (PR exists) - python-psycopg2 (notified in an existing bugzilla) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 9

← 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