Re: convert everything to rpmautospec?
On Wed, 10 Apr 2024 at 16:30, Pierre-Yves Chibon wrote: [...] > Let's look at it in another way: would you say that the people who leaved in > the > 14th century were liars for saying that the earth is flat? > No, they just didn't know. Off-topic and not really affecting the validity of your point, but the idea that people in the 14th century / Middle Ages generally believed that the earth was flat is a myth. I recently read about it in the book "Fake History: 101 Things that Never Happened" by Jo Teeuwisse (great book, BTW!), but also Wikipedia happens to have a decent article about it: https://en.wikipedia.org/wiki/Myth_of_the_flat_Earth -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help with creating first PR for a package
On Sun, 18 Feb 2024 at 09:23, Kan-Ru Chen wrote: > > Hi, > > On Sun, Feb 18, 2024, at 10:52 AM, Loren M. Lang wrote: > > I've cloned it down and worked on bringing it more up-to-date. Now that > > I have something passing the test suite, I thought I'd file a PR and > > start a discussion. I forked the project on Pagure.io, but found that > > even with my own personal fork, I don't seem to have commit access to it > > without being in the Packagers group. Is that standard? I thought the > > point of the fork was to allow non-packagers to use the PR mechanism as > > an easy mechanism for sponsors to view proposals. > > > > In any case, I decided to through it up on GitHub temporarily so I could > > at least create a Remote PR. > > > > https://src.fedoraproject.org/rpms/python-cachelib/pull-request/6 > > I have recently done this. You need to use fedpkg to clone the repository then > it will setup the hook for authentication with FAS. > > For example if you have fork at `fork/penguin359/rpms/python-cachelib` then > use > this command to clone > > fedpkg clone -a forks/penguin359/rpms/python-cachelib > > then in the cloned repo you can push normally. FWIW. it is documented here: https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: zuul-config-generator - add your packages to Zuul CI seamlessly
On Tue, 6 Feb 2024 at 14:18, Sandro wrote: > > On 06-02-2024 10:32, Karolina Surma wrote: > > Please note, if you want to add hundreds of packages at once, coordinate > > with the Zuul folks -- they know best how much it can handle. > > Do you happen to have contact details or a pointer to them? > > I have an issue with Zuul (not related to adding packages) that I'd like > them to look into, but so far I have been unable to figure out where to > report that or whom to contact. I usually report them to https://pagure.io/fedora-ci/general/issues - you can see a bunch of existing Zuul issues there and there is even an issue label for "Zuul CI", so one can assume this is the right place. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Figure out what killed an app (rhbz#2253099)
On Fri, 2 Feb 2024 at 17:52, Yanko Kaneti wrote: > > On Thu, 2024-02-01 at 09:44 +0100, Ondrej Mosnáček wrote: > > On Thu, 1 Feb 2024 at 09:13, Milan Crha wrote: > > > The kernel tracing log for sig==9 shows: > > > > > > gnome-terminal--2924[002] dN.2. 2520.462889: signal_generate: > > > sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0 > > > > > > There is no such thing (apart of the tracing log) when Evolution is > > > suddenly killed, the logs are muted. That makes me believe it's not the > > > OOM killer whom kills the application. I'm back at square 1; or maybe > > > square 2, as I know possibly kernel sends it, but not why. > > > > Try running `echo stacktrace >/sys/kernel/tracing/trace_options` (as > > root) and then collect the kernel trace again. That should give you a > > backtrace of kernel functions from the signal generation, which could > > help you/us to figure out the reason the process was killed. > > So, figured the easiest way to help trigger the kill here is to put load > on the machine. > > $ stress-ng --cpu -1 --cpu-method all -t 5m --cpu-load 95 > > then starting evolution seems to do it almost every time shortly after > start (I have around 200k messages in the folder its trying to display) > > I've enabled the stacktrace tracing option and like Milan set a sig==9 > filter. And here is what I got in the trace buffer after it was killed > > # tracer: nop > # > # entries-in-buffer/entries-written: 34/34 #P:16 > # > #_-=> irqs-off/BH-disabled > # / _=> need-resched > # | / _---=> hardirq/softirq > # || / _--=> preempt-depth > # ||| / _-=> migrate-disable > # / delay > # TASK-PID CPU# | TIMESTAMP FUNCTION > # | | | | | | >evolution-9096[002] d..1. 1207.016489: signal_generate: sig=9 > errno=0 code=128 comm=evolution pid=9096 grp=1 res=0 >evolution-9096[002] d..1. 1207.016495: > => trace_event_raw_event_signal_generate > => __send_signal_locked > => posix_cpu_timers_work > => task_work_run > => irqentry_exit_to_user_mode > => asm_sysvec_apic_timer_interrupt So, browsing through the relevant kernel code, it seems the only cases which could have led to this backtrace are: 1. When a task's RT timeout goes over the RLIMIT_RTTIME hard limit (see function check_thread_timers() in kernel/time/posix-cpu-timers.c). 2. When a task's CPU time goes over the RLIMIT_CPU hard limit (see function check_process_timers() in kernel/time/posix-cpu-timers.c). I may have missed some code path, but these resource limits should be the next thing to check. >evolution-9096[002] d..2. 1207.016564: signal_generate: sig=9 > errno=0 code=0 comm=bwrap pid=9145 grp=1 res=0 >evolution-9096[002] d..2. 1207.016568: > => trace_event_raw_event_signal_generate > => __send_signal_locked > => do_send_sig_info > => do_exit > => do_group_exit > => get_signal > => arch_do_signal_or_restart > => irqentry_exit_to_user_mode > => asm_sysvec_apic_timer_interrupt > ... > and 32 other events of bwrap cleaning up. > > Does that shed any light? Other that is seems to be sending the signal > to itself. > > -Yanko > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Figure out what killed an app (rhbz#2253099)
On Thu, 1 Feb 2024 at 09:13, Milan Crha wrote: > The kernel tracing log for sig==9 shows: > > gnome-terminal--2924[002] dN.2. 2520.462889: signal_generate: > sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0 > > There is no such thing (apart of the tracing log) when Evolution is > suddenly killed, the logs are muted. That makes me believe it's not the > OOM killer whom kills the application. I'm back at square 1; or maybe > square 2, as I know possibly kernel sends it, but not why. Try running `echo stacktrace >/sys/kernel/tracing/trace_options` (as root) and then collect the kernel trace again. That should give you a backtrace of kernel functions from the signal generation, which could help you/us to figure out the reason the process was killed. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Mon, 18 Dec 2023 at 19:39, Priscila Gutierres wrote: > > virtme-ng makes testing a new kernel and developing new modules A LOT easier. > > On Mon, Dec 18, 2023 at 10:27 AM Richard W.M. Jones wrote: >> >> On Mon, Dec 18, 2023 at 11:20:22AM +0100, Miro Hrončok wrote: >> > virtmeorphan 4 weeks >> > ago >> >> I have no special knowledge of this package, but I did read the >> article below a few weeks ago about virtme-ng. In particular >> virtme-ng uses virtiofs (instead of 9p) which is a more modern way to >> export filesystems into VMs. We (the virt team) have for a very very >> long time recommended people steer clear of 9p, for security, >> performance and maintainability reasons. >> >> https://lwn.net/Articles/951313/ FWIW, I wanted to try out virtme-ng, so I packaged it and submitted for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2255805 If anyone is interested in having it in Fedora, please consider taking the review. Co-maintainer offers are also welcome :) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: KDE Plasma 6 (System Wide)
On Wed, Sep 13, 2023 at 5:54 PM Aoife Moloney wrote: > == Summary == > KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE > Community. It is based on Qt 6 and KDE Frameworks 6 and brings many > changes and improvements over previous versions. For Fedora Linux, the > transition to KDE Plasma 6 will also include dropping support for the > X11 session entirely, leaving only Plasma Wayland as the sole offered > desktop mode. For me, the biggest blocker for switching to Wayland is the lack of session restore support (https://bugs.kde.org/show_bug.cgi?id=436318). I have a bunch of text editor and file browser windows permanently open across several activities and losing the layout after every reboot would be a big productivity killer for me. This is even listed right at the top of the showstoppers list on the KDE wiki: https://community.kde.org/Plasma/Wayland_Showstoppers Please don't remove X11 support until this is fixed (implemented) :( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Anyone interested in packaging + maintaining the nimble language?
On Tue, Sep 12, 2023 at 9:22 AM Sandro wrote: > > On 12-09-2023 03:36, Maxwell G wrote: > >> It isn't packaged for Fedora yet, though. Is anyone using it, and would > >> like to package + maintain it for Fedora? > > IIRC, we used to have nim in Fedora and then it was retired. > > Indeed. That may be a good starting point. > > There's also nim-srpm-macros [1], which has a bit of a misleading name. > It's for converting nimble packages to RPM. > > [1] https://src.fedoraproject.org/rpms/nim-srpm-macros Just FYI, there is an open review ticket for nim: https://bugzilla.redhat.com/show_bug.cgi?id=2183700 (I'm not involved in any way, just happened to notice it a while ago while looking for a review swap candidate.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Non-responsive maintainer check for juergh
Hello, Does anyone know how to contact juergh (Juerg Haefliger)? They are the sole maintainer of a single package in Fedora (cloud-utils), which hasn't seen any activity for almost 4 years. I've filed a non-responsive check bug here: https://bugzilla.redhat.com/show_bug.cgi?id=2234606 Here are open bugs and PRs waiting for a response from them: https://src.fedoraproject.org/rpms/cloud-utils/pull-request/3 https://bugzilla.redhat.com/show_bug.cgi?id=2051099 https://bugzilla.redhat.com/show_bug.cgi?id=2184158 Thanks, Ondrej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
License correction for strawberry
Hello, The license for strawberry has been corrected and converted to SPDX from "GPLv2 and GPLv3+ and LGPLv2 and ASL 2.0 and MIT and Boost" to "MIT AND Apache-2.0 AND GPL-2.0-or-later AND GPL-3.0-or-later". Refer to the spec file for the license breakdown by source files, which should now correspond to the latest tarball contents. Cheers, Ondrej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 7:30 PM Michael Catanzaro wrote: > And anybody who isn't > willing to buy a security key wouldn't be able to contribute to Fedora > at all. This is just not true. Anyone with an Android or iOS device can set up a software token via FreeOTP [1]. Sure, security-wise it's not as good as a HW token, but it's already way better than nothing. I've been using it for 2FA on Fedora for several months now without any problem. I'm really surprised that this thread got so far without mentioning FreeOTP... [1] https://freeotp.github.io/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
