Two review swaps
Hello and happy holidays ! I have two review requests I'd like to swap with anyone willing to ! 1. python-pyfiglet : https://bugzilla.redhat.com/show_bug.cgi?id=1876108 This one has been in a legal hell for a 3 years ! But, it is finally freed from legal and updated to the new guidelines ! I'm swapping this because it would otherwise never get reviewed ^^'. Everything concerning legalese should be sorted and it had initially been approved, but it might cause you some trouble if you are allergic to anything legal :P. 2. python-willow : https://bugzilla.redhat.com/show_bug.cgi?id=2255935 Just a simple dependency needed to upgrade Setzer ! This package though needs another one to be updated before being shipped to Fedora, I'm just hoping to get it approved so that I can push it as soon as the dependency in question is updated. A successful COPR build with the updated dependency is provided, so that shouldn't be a problem. Happy holidays, Lyes Saadi-- ___ 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: Will noarch packages "inherit" ExcludeArch from another noarch package
Oh, wow ! Thank you so much ! Didn't expect for it to be solved this quickly when giving up :P ! Le 13/09/2023 à 16:51, Jerry James a écrit : On Tue, Sep 12, 2023 at 10:02 PM Jerry James wrote: I looked at blueprint-compiler tonight, and found 2 bugs with the handling of bitfields. Sadly, fixing those still doesn't make the test suite pass, so there is at least one more bug lurking somewhere. Still, I think the package is probably fixable. If you can wait just a little longer, I will try to find the next bug tomorrow. Bug 3 was on the line right next to bug 2. :-) I have opened https://gitlab.gnome.org/jwestman/blueprint-compiler/-/merge_requests/143. That patch does not apply cleanly to version 0.6.0, but the attached version does. ___ 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: Will noarch packages "inherit" ExcludeArch from another noarch package
Oh woops, answered to Jerry James privately instead to the whole devel mailing list. It's indeed about blueprint-compiler. Le 12/09/2023 à 19:03, Dan Horák a écrit : On Tue, 12 Sep 2023 10:08:57 -0600 Jerry James wrote: On Tue, Sep 12, 2023 at 10:03 AM Lyes Saadi wrote: I have a noarch package which faces an issue with one of its arches (s390x), and which happens to have multiple noarch packages depending on it, and they won't build either if they were built on that same arch (but, they will still work normally when installed on that arch). And so, I plan on adding an ExcludeArch, as per https://docs.fedoraproject.org/en-US/packaging-guidelines/#_arch_specific_runtime_and_build_time_dependencies. But, I don't know if I need to also ask maintainers of every dependency to add ExcludeArch themselves. Indeed, the guideline says : > You can limit both the architectures used to build a noarch package, *and the repositories to which the built noarch package will be added* So, am I correct in assuming that if my noarch package uses ExcludeArch, every other dependent package, when building, will not build on that Arch as well ? You will indeed have to ask the maintainers of consuming packages to add that ExcludeArch too. What package is it and what is the nature of the problem on s390x? Maybe it can be fixed. I believe it's about blueprint-compiler, which has some big endian issues, please see https://bugzilla.redhat.com/show_bug.cgi?id=2169892 Dan ___ 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
Will noarch packages "inherit" ExcludeArch from another noarch package
Hello ! I have a noarch package which faces an issue with one of its arches (s390x), and which happens to have multiple noarch packages depending on it, and they won't build either if they were built on that same arch (but, they will still work normally when installed on that arch). And so, I plan on adding an ExcludeArch, as per https://docs.fedoraproject.org/en-US/packaging-guidelines/#_arch_specific_runtime_and_build_time_dependencies. But, I don't know if I need to also ask maintainers of every dependency to add ExcludeArch themselves. Indeed, the guideline says : > You can limit both the architectures used to build a noarch package, *and the repositories to which the built noarch package will be added* So, am I correct in assuming that if my noarch package uses ExcludeArch, every other dependent package, when building, will not build on that Arch as well ? Greetings, Lyes Saadi ___ 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
Thanks ! Guess I'll take it then. Le 10/10/2022 à 22:04, Miro Hrončok a écrit : On 10. 10. 22 21:05, Lyes Saadi wrote: Does anyone know what happened to python-yapsy? https://pagure.io/fesco/issue/2866 ___ 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
Does anyone know what happened to python-yapsy? I'm considering taking it if no one else wants to, since I have a package in COPR depending on it. Regards, Lyes Saadi Le 10/10/2022 à 10:31, Miro Hrončok a écrit : The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2022-10-10.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change Falcon orphan 1 weeks ago amora orphan 4 weeks ago blueberry nonamedotc, orphan, rathann 4 weeks ago brewtarget orphan 0 weeks ago capstone orphan, rebus, ret2libc 1 weeks ago containerd go-sig, gotmax23, orphan 0 weeks ago csound orphan 1 weeks ago espresso-ab avigne, orphan 5 weeks ago geompp orphan 3 weeks ago geteltorito orphan 4 weeks ago giada orphan 3 weeks ago gimp-focusblur-plugin orphan 5 weeks ago gmqcc orphan 5 weeks ago golang-github-beevik-etree go-sig, mgoodwin, nathans, 2 weeks ago orphan golang-github-crewjam-httperr go-sig, mgoodwin, nathans, 2 weeks ago orphan golang-github-crewjam-saml go-sig, mgoodwin, nathans, 2 weeks ago orphan golang-github-dchest-uniuri go-sig, mgoodwin, nathans, 2 weeks ago orphan golang-github-logr-stdr eclipseo, go-sig, orphan 2 weeks ago golang-github-magefile-mage go-sig, mgoodwin, nathans, 2 weeks ago orphan golang-github-russellhaering- go-sig, mgoodwin, nathans, 2 weeks ago goxmldsig orphan golang-github-timberio-datemath go-sig, mgoodwin, nathans, 2 weeks ago orphan golang-github-ua-parser-uap go-sig, mgoodwin, nathans, 2 weeks ago orphan hct avigne, orphan 5 weeks ago kelbt orphan 5 weeks ago llvm11.0 orphan, tstellar 0 weeks ago moby-engine go-sig, gotmax23, orphan 0 weeks ago monobristol orphan 5 weeks ago nautilus-search-tool orphan 3 weeks ago origin go-sig, orphan, tdawson 5 weeks ago owl-lisp huzaifas, orphan 4 weeks ago perl-Parse-Debian-Packages orphan 5 weeks ago php-psr-http-client orphan 5 weeks ago pinpoint orphan 3 weeks ago pt-astra-sans-font orphan 4 weeks ago pt-astra-serif-font orphan 4 weeks ago python-APScheduler orphan, zuul 1 weeks ago python-PyRSS2Gen orphan 0 weeks ago python-cached_property adamwill, orphan 0 weeks ago python-charon orphan 2 weeks ago python-coreapi orphan 5 weeks ago python-cores
Re: how to update rpms/vile?
Hello, mmckinst seems to have been marked as an Inactive Packager looking at the recently introduced Inactive Packager Policy: https://pagure.io/find-inactive-packagers/issue/230 As such, he will loose packager status in two months in case he doesn't answer. If you don't want to wait for two months, you can follow the Non-responsive Maintainer Policy: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ If the request is granted, his packages will be orphaned, and any packager will be able to pick it up, including you. He last logged into the Fedora Account System on the 18th of August 2020. Greetings, Lyes Saadi Le 26/08/2022 à 00:46, Thomas Dickey a écrit : I'm the upstream developer/maintainer for vile (vi like emacs) and a few other programs packaged in Fedora. The vile rpm is a couple of years out of date, now, and I don't see recent activity by the package maintainer. What can I do to get it moving again? (Earlier this year, I restored a couple that had been orphaned, but that isn't the current state for vile). ___ 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: GNOME's Icon Development Kit icons potentially causing implicit conflicts
I have tried to create a package for that, including rpm-macros to easily remove conflicting installed icons. Here it is: https://lyessaadi.fedorapeople.org/icon-development-kit-2022.08.18-1.fc38.src.rpm Should I submit that for review and change conflicting packages? Or should we instead instruct packagers to fix their apps? Regards, Lyes Saadi Le 24/08/2022 à 10:40, Lyes Saadi a écrit : Le 24/08/2022 à 09:47, Vít Ondruch a écrit :> Shouldn't we have shared "Icon Library" package, which would solve the conflicts? Yes, this is what I'm also proposing, and what I think is probably the most painless solution. Additionally, since packages like gnome-control-center install icons this way, it would make it harder to miss the potential conflicts. Although, I think that the Icon Library app doesn't put apps in categories nor does it install them system-wide. I think it would be easier to package Icon Development Kit itself. Regards, Lyes Saadi ___ 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: GNOME's Icon Development Kit icons potentially causing implicit conflicts
Le 24/08/2022 à 09:47, Vít Ondruch a écrit :> Shouldn't we have shared "Icon Library" package, which would solve the conflicts? Yes, this is what I'm also proposing, and what I think is probably the most painless solution. Additionally, since packages like gnome-control-center install icons this way, it would make it harder to miss the potential conflicts. Although, I think that the Icon Library app doesn't put apps in categories nor does it install them system-wide. I think it would be easier to package Icon Development Kit itself. Regards, Lyes Saadi ___ 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
GNOME's Icon Development Kit icons potentially causing implicit conflicts
Hello devel,
I recently packaged blackbox-terminal, but, someone packaging another
app, extension-manager noticed that his package conflicted with mine,
and a `dnf whatprovides` later noticed that it also conflicted with
cozy*. I soon discovered that all those apps shared icons from the Icon
Development Kit[1] app, mostly known thanks to Icon Library[2].
Icon Library instruct developers to include these icons in a gresource
file, basically hard coding them into the app. But, it seems that this
is not followed by all app developers, and that some install them
directly in `/usr/share/icons/hicolor/`.
There are multiple other apps packaged in Fedora out there using these
icons. And it is likely that some of them are causing implicit conflicts
we haven't caught (Note: fortunately, that does not seem to be the case,
look at the end note). And, this problem will only worsen with time.
So, if you are a maintainer of a GNOME app, please check if your app is
concerned. Especially since most packagers "glob" icons in the %files
section.
Fortunately, Icon Development Kit is under CC0, so we're kinda saved
from a Licensing apocalypse (although, I have to admit that this is not
ideal).
From there, packagers who have noticed the conflict have three options
at their disposal:
1- Using gresource files, or
2- Renaming the icons by appending the app's name or uuid, or
3- Install them somewhere else, like in /usr/share/%{name}/icons
Both require patching the source code of the app, and quite a bit of effort.
Another option would be to package those icons, and delete all icons
concerned from what the app installs (maybe using a macro to simplify
things), and make the app depend on the package containing these icons.
Another question we should ask ourselves is how to prevent those
conflicts from slipping by in the distribution in the Future.
Regards,
Lyes Saadi
---
Note:
I've decided before sending this e-mail to check which packages have
installed in /usr/share/icons/hicolor an icon for which an icon with a
similar name exists in Icon Development Kit. My script seems to have
some errors, I thus might have missed some, but it already took me 1h30
to execute it, so I'll try to fix it another day. Anyway, here is the list:
cozy
gnome-system-monitor
geary
notejot
gnome-control-center
Fortunately, the number of affected packages is limited, but the fact
that some core apps are there show that no package is immune from this
problem.
---
* not all of them are from the Icon Development Kit.
[1]: https://gitlab.gnome.org/Teams/Design/icon-development-kit
[2]: https://apps.gnome.org/fr/app/org.gnome.design.IconLibrary/
___
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: Review swap : blueprint-compiler
Thanks! Happy to do it :)! Le 21/08/2022 à 19:56, Jonathan Wright via devel a écrit : I'm happy to trade for https://bugzilla.redhat.com/show_bug.cgi?id=2118887 <https://bugzilla.redhat.com/show_bug.cgi?id=2118887> On Sun, Aug 21, 2022 at 1:03 PM Lyes Saadi <mailto:lyessa...@fedoraproject.org>> wrote: Hello devel! I have new dependency I need to update dialect to 2.0. It's been waiting since july, so I'm proposing a review swap. It's the python/meson guidelines. blueprint-compiler : https://bugzilla.redhat.com/show_bug.cgi?id=2106919 <https://bugzilla.redhat.com/show_bug.cgi?id=2106919> Regards, Lyes Saadi ___ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-le...@lists.fedoraproject.org <mailto:devel-le...@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue <https://pagure.io/fedora-infrastructure/new_issue> -- Jonathan Wright AlmaLinux Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan> ___ 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
Review swap : blueprint-compiler
Hello devel! I have new dependency I need to update dialect to 2.0. It's been waiting since july, so I'm proposing a review swap. It's the python/meson guidelines. blueprint-compiler : https://bugzilla.redhat.com/show_bug.cgi?id=2106919 Regards, Lyes Saadi ___ 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: wlroots 0.15 update is coming to rawhide
Thank you for your hard work :)! Thanks to the wlroots0.14 compat package, nothing broke :D! cage's master branch is already on 0.15, so, hopefully, there will be a release using it soon :)! Le 16/01/2022 à 23:20, Aleksei Bavshin a écrit : On 1/11/22 21:29, Aleksei Bavshin wrote: Greetings, By the end of this week I'm planning to update wlroots in rawhide to 0.15 (libwlroots.so.10) and sway to the latest release candidate. No breakages are expected as wlroots0.14 compatibility package will be introduced in the same side-tag. Additionally, I intend to retire wlroots0.12 and wlroots0.13 before f36 is branched. Currently only `phoc` and `gamescope` depend on these compatibility packages. Both have releases or patches with support for new wlroots versions, so I'll retire the compat libs once we get the updates in rawhide. Wlroots 0.15.0 is available in rawhide buildroot and all dependent updates are unblocked. % koji wait-repo f36-build --build wlroots-0.15.0-1.fc36 Successfully waited 0:01 for wlroots-0.15.0-1.fc36 to appear in the f36-build repo In 1-2 weeks (after the upstream release), I'll bump sway to the 1.7 final in rawhide and update sway:rolling module for f35 and f34. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Does anybody still use `starship'?
I use it as well straight from the repos :) ! ❯ starship --version starship 0.56.0 branch: commit_hash: build_time:2021-09-30 12:45:52 build_env:rustc 1.55.0 (Fedora 1.55.0-1.fc35), I'm not very familiar with rust packaging (though I do know and use rust itself), but I could try to do some rust packaging and maybe give some help if no one else is available to help. TBH, having an out of date starship is not that much of a problem for me (and I guess for most users), since updates do not usually have much changes, especially if the root of that issue is dependencies. Le 09/01/2022 à 12:24, Igor Raits a écrit : Hello, I saw some recent discussions (yet another time) how packaging Rust / Go / Node.js is horrible, we should simply bundle everything and such. Let's not discuss this here, though. I'm interested to hear if there are any users of the `starship' application here in Fedora that consume it from the repositories. Please speak up if you do! As pointed out in the other places, I don't think we are able to update things like that as fast as releases popping out with just as few people working on the packaging Rust stack these days (I'm pretty much not contributing for last couple years due to the other work). And the question, if we want to keep packaging it (with some slower update cycle, as the time permits) or we want to retire it completely. Personally, I'd love to have more people working on packaging (and most importantly keeping up-to-date) Rust crates / apps but I think this is not so realistic :) ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
I wonder what is Slack's TOS? Maybe with their approval, a COPR could be maintained without any issue? COPR can't be used for building non-free software: https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr Indeed, forgot about that when writing my e-mail ^^'! I guess someone volunteering to properly package it in RPM Fusion could do it (if they got Slack's approval), since Slack seems to be no longer willing to ship it themselves. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
Le 10/11/2021 à 17:47, Vitaly Zaitsev via devel a écrit : On 10/11/2021 16:33, Lyes Saadi wrote: I could even imagine someone creating a repo (not in COPR hopefully, due to legal issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant to other discussions here) the bundled electron with Fedora's making things like Desktop sharing (not sure if it requires more changes) and Wayland working natively, packaged in a convenient RPM, a bit like what is currently available in the AUR. Proprietary apps don't allow patching of their code. Recently discussed in #flatpak:matrix.org. That's why I said « not in COPR hopefully » ^_^. Client modification is prohibited by Discord, but it is not really acting on that unless it harms them (the AUR repo is an example of that). I wonder what is Slack's TOS? Maybe with their approval, a COPR could be maintained without any issue? (Also, I just want to insist I am not pushing nor advising anyone to do something breaking Discord's TOS without their approval, I'm just thinking of examples of external demand for a Discord package in Fedora.) Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the electron apps would not necessarily happen in the official repos (due to the enormous work needed). We will have another problem - different Electron apps require different major versions of Electron engine. That is true. Though, compat-packages could be an option for the main repository anyway. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
Le 10/11/2021 à 11:27, Vitaly Zaitsev via devel a écrit : On 10/11/2021 09:44, Andreas Schneider wrote: Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)? By the way, which Electron app do you want to package? Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the electron apps would not necessarily happen in the official repos (due to the enormous work needed). I could very well imagine a properly maintained Electron in the repos, including the patches for Wayland & Pipewire, and then some packagers/users building everything in COPR disregarding some of the Guidelines in instances where it is too hard to apply them. I could even imagine someone creating a repo (not in COPR hopefully, due to legal issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant to other discussions here) the bundled electron with Fedora's making things like Desktop sharing (not sure if it requires more changes) and Wayland working natively, packaged in a convenient RPM, a bit like what is currently available in the AUR. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
/usr/share/appdata vs /usr/share/metainfo
Hello,
I was packaging a new application when I noticed that it installed its
AppData file in `/usr/share/appdata`, instead of `%{metainfodir}`:
`/usr/share/metainfo`. Never noticing the distinction before, I use dnf
and find several other packages installing files there. Interestingly,
the `%{__metainfo_path}` macro do also refer to `/usr/share/appdata`. I
even find out that an app I'm developing in GTK is installing its
AppData file there :P!
The Guidelines itself is ambiguous, it is not a MUST that AppData files
should be installed in `%{metainfodir}`, but it is clearly intended to
be required (the SHOULD referring to the existence of the AppData file,
and not its location):
> If a package contains a GUI application, then it SHOULD install a
|.metainfo.xml| file into |%{_metainfodir}|. Installed |.metainfo.xml|
files MUST follow the AppStream specification page
.
And I found an old discussion on the mailing list about it [1]. Neal
Gompa is recommending there that the AppData should be installed in
`%{_metainfodir}`. So, shouldn't we clarify the Guidelines to precise
that the AppData file MUST be installed in `%{_metainfodir}` as well as
fixing the packages using the wrong path or should we allow both paths
to coexist?
I don't think that this is an important issue though, since
`appstream-glib` take both paths in account [2].
Ironically, I found some `.metainfo.xml` in `/usr/share/appdata` and
some `.appdata.xml` in `/usr/share/metainfo`.
[1]:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DTWEF524FXOR5MY7VQUDY3K6JLIKNUQM/
[2]:
https://github.com/hughsie/appstream-glib/blob/master/libappstream-builder/plugins/asb-plugin-appdata.c#L31-L35
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Is there a command to expand Source0 from spec file to the final URL?
Hello,
It is possible, using spectool:
spectool -s 0 path/to/specfile.spec
Le 06/07/2021 à 17:15, Richard W.M. Jones a écrit :
Is this possible? I've got one with lots of %{macros} in it.
It seems like this should be possible using rpmspec, but I can't work
out how.
Rich.
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: wlroots 0.13.0 update for rawhide and f34
Rebuilt :)! Thank you for the update! Le 19/04/2021 à 19:01, Aleksei Bavshin a écrit : wlroots-0.13 is now available in rawhide. The compatibility issues are resolved via `wlroots0.12` package which will be installed on update if there is anything that depends on `libwlroots.so.7`. No rebuilds are necessary. If your package depends on the old wlroots API or hardware support, you may need to adjust build requirements to one of following: BuildRequires: pkgconfig(wlroots) = 0.12.0 BuildRequires: (pkgconfig(wlroots) >= 0.12 with pkgconfig(wlroots) < 0.13) for future builds. --- @atim, @fnux, @lyessaadi, if you want to have new versions of cage/hikari/labwc to be available in f34 as a day 0 update, you are welcome to use the side-tag `f34-build-side-40158` (`fedpkg build --target=f34-build-side-40158`). Merge ETA is in 1 day. Although in the case of hikari that might not work, as the side-tag does not contain libucl from `f34-updates-testing` :( On 4/7/21 1:54 PM, Aleksei Bavshin wrote: Greetings, wlroots 0.13.0 and sway 1.6 have been released today. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. For all the dependents I identified either upstream patches or ETA for the new release and have successful copr builds. I'm planning to create rawhide side-tag later today, rebuild all @sway-sig packages and send PRs with instructions to the packages I don't have access to. The side-tag will be merged in a week or when all the rebuilds are done. I also plan to prepare a day 0 update for f34 once rawhide rebuilds are completed. Let me know if you have any concerns about that. BCC: maintainer aliases for cage, labwc, phoc and wayfire ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Can the BTRFS transparent compression mess with RPM's free space checks?
I think I realized what went wrong: I compressed my filesystem _after_
already having done some snapshots. I think it then duplicated all my
files and basically filled my filesystem... And I did
Sorry for that! I'm happy to be wrong at least. And thank you for this
great answer!
Le 19/04/2021 à 23:29, Dominique Martinet a écrit :
Lyes Saadi wrote on Mon, Apr 19, 2021 at 10:56:51PM +0100:
It's a bit late to ask this question, but it emerged when I noticed that
after upgrading my PC to Silverblue 34 and after compressing manually my
files, and doing some snapshots, rpm-ostree began complaining about the
absence of free space... While compsize reported that I used only 84G(o/io?)
of my 249Go filesystem... I then realized that because of the compression
and the snapshots, ostree thought that my disk was full. The same problem
happened with gnome-disk. I reported both issues[1][2].
Err, no.
btrfs has been reporting proper things in statfs that programs can rely
on, compsize is only there for you if you're curious and for debugging.
In this case your filesystem is really almost full (around 8GB free
according to your output)
That was a problem very early on and basically everyone complained df
being unuseable would break too many programs.
You probably compressed your / but have snapshots laying around that
still take up space and weren't considered in your compsize command?
If you don't trust df (statfs), you have two btrfs commands to look at
for more details; here's what it gives on my system:
# btrfs fi df /
Data, single: total=278.36GiB, used=274.63GiB
System, DUP: total=32.00MiB, used=48.00KiB
Metadata, DUP: total=9.29GiB, used=6.88GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
# btrfs fi usage /
Overall:
Device size:330.00GiB
Device allocated: 297.00GiB
Device unallocated: 33.00GiB
Device missing: 0.00B
Used: 288.39GiB
Free (estimated):36.73GiB (min: 20.23GiB)
Free (statfs, df): 36.73GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:278.36GiB, Used:274.63GiB (98.66%)
/dev/mapper/slash278.36GiB
Metadata,DUP: Size:9.29GiB, Used:6.88GiB (74.09%)
/dev/mapper/slash 18.57GiB
System,DUP: Size:32.00MiB, Used:48.00KiB (0.15%)
/dev/mapper/slash 64.00MiB
Unallocated:
/dev/mapper/slash 33.00GiB
And for comparison:
# df -h /
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/slash 330G 289G 37G 89% /
In all cases, the Used column actually corresponds to compressed size --
real blocks on disk and not uncompressed data size.
I have way too many subvolumes but here's an output that lists more than
289G "used"; I'm lazy so without snapshots:
# compsize -x / /home /var /var/lib/machines/ /nix
Processed 2722869 files, 1820146 regular extents (2063805 refs), 1625123 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 76% 232G 302G 317G
none 100% 196G 196G 194G
zstd33% 34G 104G 122G
prealloc 100% 1.0G 1.0G 553M
Hm, not very convincing, adding a few (there's more, I guess adding all
of them should bring the Disk Usage column up to 289G but this just
takes too long for this mail -- the "proper" way to track snapshot usage
would be quota but I don't have these enabled here):
# compsize -x / /home /var /var/lib/machines/ /nix /.snapshots/{19,20}*/snapshot
Processed 10803451 files, 2110568 regular extents (7656942 refs), 5960388
inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 75% 249G 331G 732G
none 100% 206G 206G 281G
zstd33% 41G 123G 451G
prealloc 100% 1.0G 1.0G 551M
I would suggest finding what subvolumes you may have (btrfs subvolume
list /) and cleanup old ones, I'm not sure what is used by default
nowadays (snapper?) there might be higher level commands
They might not be visible from your mountpoint if your setup mounts a
subvolume by default, in which case you can mount your btrfs volume
somewhere else with -o subvol=/ for example to show everything and play
with compsize if you want.
___
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.fedora
Can the BTRFS transparent compression mess with RPM's free space checks?
Hello! It's a bit late to ask this question, but it emerged when I noticed that after upgrading my PC to Silverblue 34 and after compressing manually my files, and doing some snapshots, rpm-ostree began complaining about the absence of free space... While compsize reported that I used only 84G(o/io?) of my 249Go filesystem... I then realized that because of the compression and the snapshots, ostree thought that my disk was full. The same problem happened with gnome-disk. I reported both issues[1][2]. But, in the rpm-ostree issue, jlebon raised an important question: does this also happen with RPM? Because if it does, this may mess up quite a bit the next Fedora Release... Note: I am not an expert in BTRFS or RPM, so, I'm sorry if this question is irrelevant. [1]: https://github.com/coreos/rpm-ostree/issues/2761 [2]: https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/211 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
Wouldn't using a "Conflicts=" option in the systemd user unit file work while preventing both from running simultaneously? (I mean, except when it is started from cli directly.) Le 05/12/2020 à 21:43, Erich Eickmeyer a écrit : On 12/5/20 12:39 PM, Naheem Zaffar wrote: I understand the need for replacing pulseaudio package when upgrading, but it should be possible to have both installed and have the service from only one activated? Atleast for current fedora that will make it easier to test and switch between implementations. The point is you don't want/shouldn't have both pipewire and pulseaudio installed simultaneously since pipewire-pulseaudio is a drop-in replacement. So no, that would be a bad idea. -- Erich Eickmeyer Maintainer Fedora Jam ___ 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 ___ 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
Unretiring python-googletrans
Hello, In order to package dialect[1], I'm unretiring python-googletrans[2]. Since this package was released for more than a year now, I am going through a re-review[3]. Sincerely, Lyes Saadi [1]: https://github.com/gi-lom/dialect [2]: https://src.fedoraproject.org/rpms/python-googletrans [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1889104 ___ 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
Re: Proposal: Install gparted to Live installers
YES! PLEASE! I recently had an issue where gparted would have saved me *hours* of head banging! No one should have to use `fdisk`... *No one...* *NO ONE...* Sincerely, Lyes Saadi. Le 04/06/2020 à 16:00, Richard Shaw a écrit : I'm trying to install Fedora 32 to a MS Surface GO which has some sort of non-standard UEFI install. It refuses to boot anything but Windows from the ESP partition even though I can see it using efibootmgr. In troubleshooting this and working around it I'm using the F32 live installer, but I keep having to install gparted. The installer would be much more useful with it preinstalled. I nearly have resorted to system rescue cd since it does come pre-installed... It only adds a little more than 8MB installed... Thanks, Richard ___ 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 ___ 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
Re: FTBFS bug not reassigned
Hi! This might be related to this issue: https://pagure.io/fedora-infrastructure/issue/8628 I had the same problem a month ago... Maybe you can ask for someone there to fix your account's permissions manually? Le 17/05/2020 à 00:25, Benjamin Lowry a écrit : I recently adopted flatbuffers, which was orphaned due to an open FTBFS in F32 [1]. I've fixed the spec, rebuilt, and made an update in bodhi, but I'm unable to close the FTBFS bug because it hasn't been reassigned to me. What should I do? Am I supposed to be able to edit this bug? I'm in the editbugs group... -ben [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1799345 ___ 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 ___ 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
Re: The Chromium Dilemma
Le 13/04/2020 à 16:27, Peter Robinson a écrit : People that want the Fedora version of the build, even without the extra bits, would get rpmfusion if they happen to have rpmfusion enabled for another reason. Maybe a special repository only for chromium? I mean, chromium is important enough for an exception like that. Or, distributing two different .repo files, one of them with: exclude=chromium That could do the trick while keeping user's freedom. ___ 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
Re: Copr Build System - review of 2019 and vote for features in 2020
Le 08/01/2020 à 10:00, Miroslav Suchý a écrit : * build Flatpak application from your project - we have a viable idea how to build Flatpak app from your project with just a few clicks, and we can upload the result to some registry. E.g., to https://quay.io/ If it works as I understand it, that could be extremely useful for SilverBlue Users. ___ 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
Self Introduction: Lyes Saadi
Hi ! So, it's now 1 week that I have proposed to join the package maintainer community ( https://bugzilla.redhat.com/show_bug.cgi?id=1770147 , it would be really kind of you to review it ;), or give me a thought, not especially sponsorship, just advice) and that I subscribed to the devel mailing list (You seem really passionate about modularity :p). I didn't post my Self Introduction the same day as I wanted to know a little bit about this amazing community that I joined for many years now and how it works behind. Fedora is my first Linux, and, even if I tested other distributions, Fedora was the only one that I kept through my journey, for it's bleeding edge software, it's incredible community, it's innovating solutions (Silverblue, that I'm using), and it's openness. And today (or a week ago :p), it's my turn, finally, to contribute. I would really be honored to do it. For my packaging experience, I haven't done anything big, yet. I contributed here and there to some COPR specs, I built some myself (like NoteKit, that appeared in the last "4 cool new projects to try in COPR", I was so proud, and I was so happy for the developer of that awesome program). But the package that made me here, is mbpfan, an incredible daemon for MacBooks, that I thought was a shame that it isn't on Fedora's repos while on Debian's, Ubuntu's and other repos... It's a wonderful program to control fan speed of MacBook, very poorly managed by default. IMHO, it is crucial to the experience of Linux on Macs. Now, about my self. So I'm a French-Tunisian guy, love programming, math and Linux. Nothing really interesting about me. I have Fedora Silverblue on an old MacBook as a main PC. I've grown to like Fedora and Linux in general. When I joined this community, I was mind blown by everything: By the fact that we can change the DE, the fact that it was free and open, the fact that It doesn't crash constantly, and the fact that everyone is invited to contribute to it, which is now my turn :D. So, as a last statement (or paragraph), thank you all, thank you for reading me, thank you for your hard work, thank you for dedicating your life to Linux, to help millions around the globe, for freeing the poor and the enthusiast of Windows. Thank you all for being part of this community and allowing me to be part of it (hopefully :D). If you have some time :) : https://bugzilla.redhat.com/show_bug.cgi?id=1770147 ___ 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
