Re: Moving away from the term "karma" in Bodhi
On Sunday, November 10, 2024, Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > I have started to move away Bodhi from using the term "karma" to rate > updates. I know this word has become familiar to all Fedora users, but > there were several requests in the past to stop the misuse. As I may not > be the most "politically correct" person you know, this task has been > low priority for me; nevertheless, I've now found some spare time to > start working on it. > > So, I plan to replace the term "karma" with "feedback" where users > submit their (+1|0|-1) vote: a Comment will no more have the "karma" > property, but it will be "feedback". At the same time, TestCaseKarma and > BugKarma will become TestCaseFeedback and BugFeedback. > > > This to me looks like: solving a non existing problem by creating a new one (unnecessary confusion). I couldn't care much about what it is called, but it has been ok place for years and people got used to it. -- ___ 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: Moving away from the term "karma" in Bodhi
Am Di., 12. Nov. 2024 um 09:23 Uhr schrieb drago01 : > > > > On Sunday, November 10, 2024, Mattia Verga via devel > wrote: >> >> I have started to move away Bodhi from using the term "karma" to rate >> updates. I know this word has become familiar to all Fedora users, but >> there were several requests in the past to stop the misuse. As I may not >> be the most "politically correct" person you know, this task has been >> low priority for me; nevertheless, I've now found some spare time to >> start working on it. >> >> So, I plan to replace the term "karma" with "feedback" where users >> submit their (+1|0|-1) vote: a Comment will no more have the "karma" >> property, but it will be "feedback". At the same time, TestCaseKarma and >> BugKarma will become TestCaseFeedback and BugFeedback. >> >> > > This to me looks like: solving a non existing problem by creating a new one > (unnecessary confusion). I couldn't care much about what it is called, but it > has been ok place for years and people got used to it. I do appreciate us being considerate. But have y'all noticed that no one spoke up who felt offended by the term, or who could even give input from the perspective of a "believer" or someone in the know about the meaning of the term karma in a religious context (beyond the quite common non-religious usage in English and other languages)? As such, it appears to be a made-up problem indeed. Made-up out of good intentions (I don't doubt that), but made up over the heads of those whose beliefs "we" intend to protect. Now, we have a tendency to hide concepts and meanings behind terms which no outsider could possibly infer from the terms - karma, koji, bodhi, pagure, noggin, ... If we use this initiative to *clear up* things I'm all for it. From the suggestions, "feedback" is too close to comment, but "score" seems to convey what it is. It does lose the quite fitting meaning that karma has colloquially/secularly. Michael -- ___ 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: [Fedora-packaging] Packaging Guidelines for Applications using Git Submodules
Hello, I found out this old thread while searching for Fedora packaging guidelines for Git submodules. Are there any news about guidelines on how to deal with them? I could not find any information on docs.fedoraproject.org I am currently dealing with this submodule https://github.com/web-eid/web-eid-app/tree/main/lib I think I should just treat it as a bundled library and trying to unbundle it by creating a separate package -- ___ 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: ABI change in ImageMagick
On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote:
> Le 11/11/2024 à 11:02, Dan Horák a écrit :
> > Hi,
> >
> > seems ImageMagick 7.1.1.40 comes with an ABI change
> >
> > it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit)
> > and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead.
> > This sounds wrong ...
>
> See https://github.com/ImageMagick/ImageMagick/pull/7768
I don't know if should ignore this ABI changes honestly
fedabipkgdiff -a ImageMagick-7.1.1.39-1.fc41 ImageMagick-7.1.1.40-1.fc41 >
fedabipkgdiff.txt
Comparing the ABI of binaries between
ImageMagick-libs-7.1.1.39-1.fc41.x86_64.rpm and
ImageMagick-libs-7.1.1.40-1.fc41.x86_64.rpm:
changes of 'libMagickCore-7.Q16HDRI.so.10.0.1'===
Functions changes summary: 0 Removed, 1 Changed (575 filtered out), 0 Added
functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some indirect sub-type change:
[C] 'function CacheView* AcquireAuthenticCacheView(const Image*,
ExceptionInfo*)' at cache-view.c:112:1 has some indirect sub-type changes:
parameter 1 of type 'const Image*' has sub-type changes:
in pointed to type 'const Image':
in unqualified underlying type 'typedef Image' at magick-type.h:194:1:
underlying type 'struct _Image' at image.h:131:1 changed:
type size hasn't changed
1 data member changes (5 filtered):
type of 'FilterType filter' changed:
underlying type 'enum FilterType' at resample.h:33:1 changed:
type size hasn't changed
2 enumerator insertions:
'FilterType::MagicKernelSharp2013Filter' value '32'
'FilterType::MagicKernelSharp2021Filter' value '33'
1 enumerator change:
'FilterType::SentinelFilter' from value '32' to '34' at
resample.h:33:1
end of changes of
'libMagickCore-7.Q16HDRI.so.10.0.1'===
changes of 'libMagickWand-7.Q16HDRI.so.10.0.1'===
Functions changes summary: 648 Removed, 0 Changed, 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 0 Added function symbol not
referenced by debug info
Variable symbols changes summary: 1 Removed, 0 Added variable symbol not
referenced by debug info
648 Removed functions:
[D] 'function DrawingWand* AcquireDrawingWand(const DrawInfo*, Image*)'
{AcquireDrawingWand@@VERS_10.0}
[D] 'function MagickCLI* AcquireMagickCLI(ImageInfo*, ExceptionInfo*)'
{AcquireMagickCLI@@VERS_10.0}
[D] 'function ScriptTokenInfo* AcquireScriptTokenInfo(const char*)'
{AcquireScriptTokenInfo@@VERS_10.0}
[D] 'function size_t AcquireWandId(void)'{AcquireWandId@@VERS_10.0}
[D] 'function MagickBooleanType AnimateImageCommand(ImageInfo*, int,
char**, char**, ExceptionInfo*)'{AnimateImageCommand@@VERS_10.0}
[D] 'function void CLIOption(MagickCLI*, const char*, ...)'
{CLIOption@@VERS_10.0}
[D] 'function MagickBooleanType CLIThrowException(MagickCLI*, const char*,
const char*, const size_t, const ExceptionType, const char*, const char*, ...)'
{CLIThrowException@@VERS_10.0}
[D] 'function void ClearDrawingWand(DrawingWand*)'
{ClearDrawingWand@@VERS_10.0}
[D] 'function void ClearMagickWand(MagickWand*)'
{ClearMagickWand@@VERS_10.0}
[D] 'function void ClearPixelIterator(PixelIterator*)'
{ClearPixelIterator@@VERS_10.0}
[D] 'function void ClearPixelWand(PixelWand*)'
{ClearPixelWand@@VERS_10.0}
[D] 'function DrawingWand* CloneDrawingWand(const DrawingWand*)'
{CloneDrawingWand@@VERS_10.0}
[D] 'function MagickWand* CloneMagickWand(const MagickWand*)'
{CloneMagickWand@@VERS_10.0}
[D] 'function PixelIterator* ClonePixelIterator(const PixelIterator*)'
{ClonePixelIterator@@VERS_10.0}
[D] 'function PixelWand* ClonePixelWand(const PixelWand*)'
{ClonePixelWand@@VERS_10.0}
[D] 'function PixelWand** ClonePixelWands(const PixelWand**, const size_t)'
{ClonePixelWands@@VERS_10.0}
[D] 'function WandView* CloneWandView(const WandView*)'
{CloneWandView@@VERS_10.0}
(...)
1 Removed variable symbol not referenced by debug info:
[D] .gomp_critical_user_MagickCore_MagickCommandGenesis@@VERS_10.0
end of changes of
'libMagickWand-7.Q16HDRI.so.10.0.1'===
Comparing the ABI of binaries between
ImageMagick-c++-7.1.1.39-1.fc41.x86_64.rpm and
ImageMagick-c++-7.1.1.40-1.fc41.x86_64.rpm:
changes of 'libMagick++-7.Q16HDRI.so.5.0.0'===
Functions changes summary: 0 Removed, 1 Changed (813 filtered out), 0 Added
functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
1 function with some indirect sub-type change:
[C] 'method Magick::Image::Image(MagickCore
Summary/Minutes from today's FESCo Meeting (2024-11-12)
Text Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-11-12/fesco.2024-11-12-17.01.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-11-12/fesco.2024-11-12-17.01.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-11-12/fesco.2024-11-12-17.01.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-11-12/fesco.2024-11-12-17.01.html Meeting summary --- * TOPIC: Init Process (@zbyszek:fedora.im, 17:01:33) * TOPIC: #3268 Nonresponsive maintainer: Fabian Affolter fab (@zbyszek:fedora.im, 17:04:45) * LINK: https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests (@salimma:fedora.im, 17:15:36) * ACTION: Michel Lind 🍥 UTC-5 to put up a PR for a stalled request process (@salimma:fedora.im, 17:19:42) * TOPIC: Next week's chair (@zbyszek:fedora.im, 17:20:56) * ACTION: Stephen Gallagher will chair the next meeting. (@zbyszek:fedora.im, 17:22:07) * TOPIC: Open Floor (@zbyszek:fedora.im, 17:22:14) * LINK: https://fedorapeople.org/groups/schedule/f-41/f-41-elections-tasks.html (@zbyszek:fedora.im, 17:25:51) (The nomination process starts tomorrow.) Action items * Michel Lind to put up a PR for a stalled request process * Stephen Gallagher will chair the next meeting -- ___ 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: What is "FAILED: ActionNotAllowed: policy violation (tag)"
On Mon, Nov 11, 2024 at 04:23:16AM -0600, Andrea Bolognani wrote: > On Fri, Sep 27, 2024 at 09:35:20AM -0400, Stephen Gallagher wrote: > > On Fri, Sep 27, 2024 at 8:30 AM Richard W.M. Jones > > wrote: > > > We wanted to build pesign so we can automatically trigger RISC-V > > > builds, since for some reason (I guess related to this) it hasn't been > > > built for f42 & f41. But ... > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=124051163 > > > > There is an extremely short list of people who are allowed to build > > and tag pesign because they need to have privilege to sign it with the > > special secure-boot keys. I don't know the complete list of people > > with this privilege, but I know nfrayer has it (CCed). > > Ping. > > Can we please look into getting pesign rebuilt? Ideally in f41, but > at the very least in f42. I bumped the release and did a rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=125797324 If that all looks ok and it's needed, can do f41 too. kevin signature.asc Description: PGP signature -- ___ 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: ABI change in ImageMagick
Le 13/11/2024 à 04:42, Sérgio Basto a écrit : On Tue, 2024-11-12 at 07:35 +0100, Remi Collet wrote: Le 11/11/2024 à 11:02, Dan Horák a écrit : Hi, seems ImageMagick 7.1.1.40 comes with an ABI change it drops libMagickWand-7.Q16HDRI.so.10(VERS_10.0)(64bit) and has libMagickWand-7.Q16HDRI.so.10(VERS_10.2)(64bit) instead. This sounds wrong ... See https://github.com/ImageMagick/ImageMagick/pull/7768 I don't know if should ignore this ABI changes honestly fedabipkgdiff -a ImageMagick-7.1.1.39-1.fc41 ImageMagick-7.1.1.40-1.fc41 > fedabipkgdiff.txt I only see change in a enum (2 new values) IMHO The map change is an error breaking everything map should be used to document in which version a symbol was introduced changing default from 10_0 to 10_2 doesn't make sense Remi -- ___ 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
Fedora rawhide compose report: 20241112.n.0 changes
OLD: Fedora-Rawhide-2024.n.0 NEW: Fedora-Rawhide-20241112.n.0 = SUMMARY = Added images:9 Dropped images: 0 Added packages: 5 Dropped packages:1 Upgraded packages: 88 Downgraded packages: 0 Size of added packages: 1.68 MiB Size of dropped packages:882.49 KiB Size of upgraded packages: 3.71 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -101.89 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20241112.n.0.iso Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20241112.n.0.x86_64.vagrant-virtualbox.box Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20241112.n.0.x86_64.vagrant-libvirt.box Image: Budgie live x86_64 Path: Spins/x86_64/iso/Fedora-Budgie-Live-x86_64-Rawhide-20241112.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20241112.n.0.iso Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20241112.n.0.iso Image: Python_Classroom raw-xz aarch64 Path: Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20241112.n.0.aarch64.raw.xz Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20241112.n.0.iso Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20241112.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: erlang-riak_pipe-3.0.16-1.fc42 Summary: Riak Pipelines RPMs:erlang-riak_pipe Size:180.08 KiB Package: maui-mauikit-pix-4.0.0-1.fc42 Summary: Image gallery manager built on the maui framework RPMs:maui-mauikit-pix Size:1.39 MiB Package: python-extruct-0.17.0-1.fc42 Summary: Extract embedded metadata from HTML markup RPMs:python3-extruct Size:66.57 KiB Package: python-pytest-freezer-0.4.8-1.fc42 Summary: Pytest plugin providing a fixture interface for freezegun RPMs:python3-pytest-freezer Size:12.16 KiB Package: python-snakemake-executor-plugin-azure-batch-0.3.0-1.fc42 Summary: A Snakemake executor plugin for submitting jobs to Microsoft Azure Batch RPMs:python3-snakemake-executor-plugin-azure-batch Size:35.61 KiB = DROPPED PACKAGES = Package: libva-intel-hybrid-driver-1.0.2-29.fc41 Summary: VA driver for Intel G45 & HD Graphics family RPMs:libva-intel-hybrid-driver Size:882.49 KiB = UPGRADED PACKAGES = Package: adoptium-temurin-java-repository-1-13.fc42 Old package: adoptium-temurin-java-repository-1-12.fc42 Summary: Fedora package repository files for yum and dnf along with gpg public keys RPMs: adoptium-temurin-java-repository Size: 33.54 KiB Size change: 1.31 KiB Changelog: * Mon Nov 11 2024 Jiri Vanek - 1-13 - Obsoleten also openjfx-devel Package: alsa-sof-firmware-2024.09.1-1.fc42 Old package: alsa-sof-firmware-2024.09-1.fc42 Summary: Firmware and topology files for Sound Open Firmware project RPMs: alsa-sof-firmware alsa-sof-firmware-debug Size: 7.74 MiB Size change: 10.04 KiB Changelog: * Mon Nov 11 2024 Jaroslav Kysela - 2024.09.1-1 - Update to v2024.09.1 Package: asahi-audio-2.4-1.fc42 Old package: asahi-audio-2.3-1.fc42 Summary: PipeWire DSP profiles for Apple Silicon machines RPMs: asahi-audio Size: 1.77 MiB Size change: -106 B Changelog: * Mon Nov 11 2024 Hector Martin - 2.4-1 - Update to 2.4; fixes RHBZ#2324850 Package: bids-schema-0.11.3^post2-1.fc42 Old package: bids-schema-0.11.3^post1-2.fc42 Summary: BIDS schema description RPMs: bids-schema python3-bidsschematools python3-bidsschematools+expressions python3-bidsschematools+render Size: 434.59 KiB Size change: 339 B Changelog: * Mon Nov 11 2024 Benjamin A. Beasley - 0.11.3^post2-1 - Update to 0.11.3^post2 (close RHBZ#2325251) Package: budgie-desktop-10.9.2-4.fc42 Old package: budgie-desktop-10.9.2-3.fc41 Summary: A feature-rich, modern desktop designed to keep out the way of the user RPMs: budgie-desktop budgie-desktop-devel budgie-desktop-docs Size: 7.78 MiB Size change: -8.42 KiB Changelog: * Mon Nov 11 2024 Joshua Strobl - 10.9.2-4 - Add patch to support latest libxfce4windowing Package: build2-0.17.0-3.fc42 Old package: build2-0.17.0-2.fc42 Summary: Cross-platform build toolchain for developing and packaging C++ code RPMs: bdep bdep-doc bpkg bpkg-doc build2 build2-doc build2-rpm-macros libbpkg libbpkg-devel libbuild2 libbuild2-devel libbutl libbutl-devel Size: 32.25 MiB Size change: -16.38 KiB Changelog: * Mon Nov 11 2024 Matthew Krupcale - 0.17.0-3 - Add bpkg patches for dnf5 Package: buttermanager-2.5.2-1.fc42 Old package: buttermanager-2.4.2-12.fc41 Summary: Tool for mana
Re: Moving away from the term "karma" in Bodhi
On Tue, Nov 12, 2024 at 09:43:37AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Nov 12, 2024 at 09:07:33AM +, Daniel P. Berrangé wrote: > >"Karma: Is the update generally functional?" > > > > The word "karma" is adding no value here, it is mere word clutter > > and could be trivially removed. > > You describe the use of the word from the perspective of newcomers. > But I think this misses an important function of the term: it has a > very precise meaning for people who are permanent contributors. > If I say "the update had negative karma", everybody knows _exactly_ what > this means. Once we replace "karma" by an immediately-understood but > generic term, we'll need to clarify _those_ uses. I doubt our Fedora contributors are going to find it difficult to understand this change, it'll be a short term blip at worst, quickly forgotten about. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ 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: HEADS UP: tesseract-5.5.0 coming to rawhide
On 12.11.24 11:07, Michael J Gruber wrote: Am Di., 12. Nov. 2024 um 08:32 Uhr schrieb Sandro Mani : Hi I'll be building tesseract-5.5 in the f42-build-side-100090 side tag, and also rebuilding the following dependencies: ffmpeg gimagereader mupdf opencv python-PyMuPDF R-tesseract skanpage zathura-pdf-mupdf crow-translate maui-mauikit-imagetools I have updates to mupdf and PyMuPDF in the pipeline. Should I "fold them in"? This would affect qpdfview also which I cannot commit to (and that is why I accumulate ABI breaking changes to mupdf). Yes, feel free to build them in the f42-build-side-100090 side tag. If you need a rebuild of qpdfview I can take care of that. Thanks Sandro -- ___ 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: Moving away from the term "karma" in Bodhi
On Tue, Nov 12, 2024 at 09:07:33AM +, Daniel P. Berrangé wrote: >"Karma: Is the update generally functional?" > > The word "karma" is adding no value here, it is mere word clutter > and could be trivially removed. You describe the use of the word from the perspective of newcomers. But I think this misses an important function of the term: it has a very precise meaning for people who are permanent contributors. If I say "the update had negative karma", everybody knows _exactly_ what this means. Once we replace "karma" by an immediately-understood but generic term, we'll need to clarify _those_ uses. Zbyszek -- ___ 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: [Fedora-packaging] Packaging Guidelines for Applications using Git Submodules
On Tue, Nov 12, 2024 at 09:29:02AM -, Germano Massullo wrote: > Hello, I found out this old thread while searching for Fedora packaging > guidelines for Git submodules. > Are there any news about guidelines on how to deal with them? I could not > find any information on docs.fedoraproject.org > I am currently dealing with this submodule > https://github.com/web-eid/web-eid-app/tree/main/lib > I think I should just treat it as a bundled library and trying to unbundle it > by creating a separate package Whether upstream has used a git submodule, vs deep copying the 3rd party code into their repo, is largely irrelevant to Fedora, as we're not working directly with upstream git repositories, we're using tarballs in the RPM build. IOW, if the 3rd party code ends up in the source tarball that Fedora is building from, then the "bundled library" packaging guidelines apply. Even if the git submodule code ends up in separate source tarballs, to be used alongside the main source tarball, the "bundled library" guidelines should still apply. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ 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: HEADS UP: tesseract-5.5.0 coming to rawhide
Am Di., 12. Nov. 2024 um 08:32 Uhr schrieb Sandro Mani : > > Hi > > I'll be building tesseract-5.5 in the f42-build-side-100090 side tag, and > also rebuilding the following dependencies: > > ffmpeg > gimagereader > mupdf > opencv > python-PyMuPDF > R-tesseract > skanpage > zathura-pdf-mupdf > crow-translate > maui-mauikit-imagetools > I have updates to mupdf and PyMuPDF in the pipeline. Should I "fold them in"? This would affect qpdfview also which I cannot commit to (and that is why I accumulate ABI breaking changes to mupdf). Michael -- ___ 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
Schedule for Tuesday's FESCo Meeting (2024-11-12)
Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-11-12 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3285 Request for exception: lxqt-wallet 4.0.0 update https://pagure.io/fesco/issue/3285 APPROVED (+4, 0, 0) #3286 Change: Python 3.14 https://pagure.io/fesco/issue/3286 APPROVED (+6, 0, 0) #3287 Change: Retire zbus v1 https://pagure.io/fesco/issue/3287 APPROVED (+6, 0, 0) = Followups = = New business = #3268 Nonresponsive maintainer: Fabian Affolter fab https://pagure.io/fesco/issue/3268 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- ___ 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: Moving away from the term "karma" in Bodhi
On Tue, Nov 12, 2024 at 4:44 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Nov 12, 2024 at 09:07:33AM +, Daniel P. Berrangé wrote: > >"Karma: Is the update generally functional?" > > > > The word "karma" is adding no value here, it is mere word clutter > > and could be trivially removed. > > You describe the use of the word from the perspective of newcomers. > But I think this misses an important function of the term: it has a > very precise meaning for people who are permanent contributors. > If I say "the update had negative karma", everybody knows _exactly_ what > this means. Once we replace "karma" by an immediately-understood but > generic term, we'll need to clarify _those_ uses. > Exactly. We're also talking about offense that I don't think is actually there. I certainly wasn't offended at the usage of the term, I thought it was quite apt. The karma is the sum of the positive and negative from the testers, and if it's more positive than negative, it can land. It's pretty easy to understand, and being a unique word means it only needs to be explained once. Moreover, there's no overload since the term is only used in *one* context. Every other suggestion is used in multiple contexts in Fedora, which makes it difficult to succinctly state in a way that everyone will grasp. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ 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: Thunderbird FTBFS on ppc64le
Hi, On Monday, 2024-11-11 21:58:25 +0100, Kalev Lember wrote: > On Mon, Nov 11, 2024 at 5:35 PM Dan Horák wrote: > > > > I suppose it's similar to the issues Firefox is having and that's OOM > > during compiling the Rust code ... > > It might be possible to work this around by sticking > > %ifarch ppc64le > %global rustflags_debuginfo 1 > %endif > > at the top of the spec file. Can you try if it helps, Eike? That worked at least in a scratch build for rawhide. I'll try that again with the next update. Thanks! Eike -- GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A signature.asc Description: PGP signature -- ___ 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: Moving away from the term "karma" in Bodhi
On Mon, Nov 11, 2024 at 11:25:40AM -0500, Matthew Miller wrote: > On Mon, Nov 11, 2024 at 11:58:39AM +0100, Lukas Ruzicka wrote: > > Well, I am very sad about this step and I feel very sorry that you are > > trying to remove the word karma from the process. I believe that Karma > > denotes one of the most powerful, the most noble, and the most fair > > principles of this world, because traditionally it is above this world. > > I think this is _why_ we should change it. We don't mean _any_ of that. We > mean "does this package update look good, or does it have bugs that should > block its release". Our use trivializes the term. > > I think "update feedback" is perfectly clear and more descriptive. Agreed, my guiding principal is apps should "tell it like it is". IOW, use descriptive terms, avoid cute analogies. We can already see that our use of the word "karma" as an analogy for update feedback is flawed. For example, right next to the word "karma" at the bottom of the comment form, we have to put descriptive text telling users what we actually want from them: "Karma: Is the update generally functional?" The word "karma" is adding no value here, it is mere word clutter and could be trivially removed. Then against each comment we have a summary line saying "joeuser provided feedback 20 hours ago 👍 karma" the thumbs up / thumbs down symbol in this line is telling users what actually matters. The word "karma" here is adding no value, it is again useless word clutter. There are many other instances across Bohdi, but there are viable alternatives throughout which would end up being more descriptive. IOW, whether or not "karma" is an acceptable term to use is ultimately a distraction. More fundamentally it is a poor choice of term from a descriptive POV, and we'll end up improving bodhi for users overall by replacing it. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ 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
Taking over the `rust-serial-core` package in fedora
The rust-serial-core was retired 2 years ago due to no dependent packages and was unused for 2 release cycles (https://src.fedoraproject.org/rpms/rust-serial-core/blob/rawhide/f/dead.package#). I will need this packag as it will be a dependency for a package i am packaging, linuntil, https://bugzilla.redhat.com/show_bug.cgi?id=2310209 link to the ticket:https://bugzilla.redhat.com/show_bug.cgi?id=2318054 -- ___ 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: Moving away from the term "karma" in Bodhi
On Tue, Nov 12, 2024 at 10:11 AM Michael J Gruber wrote: > Now, we have a tendency to hide concepts and meanings behind terms > which no outsider could possibly infer from the terms - karma, koji, > bodhi, pagure, noggin, ... If we use this initiative to *clear up* > things I'm all for it. Here I believe you are mixing 'terms' and 'names'. 'Koji' is the *name* of the software [1], while the descriptive term would be something like "RPM building and tracking system". But there is a number of similar software (COPR, Pulp, SBS, ...), and even bigger numbers of their instances. (Fedora Koji instance, RPMFusion Koji instance, CentOS Stream Koji instance, ...) Same way you naturally use names like: "FB messenger, telegram, snapchat, whatsapp", instead of calling each just "that instant messaging app". That's hardly the same category as the 'karma' term used in a software named Bodhi. [1] https://pagure.io/koji/ -- Michal Schorm Software Engineer Databases Team Red Hat -- -- ___ 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: Thunderbird FTBFS on ppc64le
Unfortunately, building large projects that use Rust with full debuginfo tends to push the memory limits of our builders. The peak memory usage is usually at link time, so reducing the number of parallel jobs isn’t helpful. For now, reducing the debuginfo level as suggested seems to be the best way to kick the can down the road until (hopefully, someday) builders can be allocated more memory. The ppc64le architecture is often the first affected since its builders tend to have a little less available memory, but high memory usage from debugging symbols happens on all architectures. For uv, I have to set rustflags_debuginfo to 1 across the board. Even that barely works on some of the more memory-constrained builders. I spent some time looking for clever ideas that could make time-memory tradeoffs and came up empty-handed. On 11/12/24 9:23 AM, Eike Rathke wrote: Hi, On Monday, 2024-11-11 21:58:25 +0100, Kalev Lember wrote: On Mon, Nov 11, 2024 at 5:35 PM Dan Horák wrote: I suppose it's similar to the issues Firefox is having and that's OOM during compiling the Rust code ... It might be possible to work this around by sticking %ifarch ppc64le %global rustflags_debuginfo 1 %endif at the top of the spec file. Can you try if it helps, Eike? That worked at least in a scratch build for rawhide. I'll try that again with the next update. Thanks! Eike -- ___ 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: Moving away from the term "karma" in Bodhi
On Tue, Nov 12, 2024 at 10:08 AM Daniel P. Berrangé wrote: > For example, right next to the word "karma" at the bottom of the > comment form, we have to put descriptive text telling users what > we actually want from them: >"Karma: Is the update generally functional?" > The word "karma" is adding no value here, it is mere word clutter > and could be trivially removed. > > Then against each comment we have a summary line saying > "joeuser provided feedback 20 hours ago 👍 karma" > the thumbs up / thumbs down symbol in this line is telling users > what actually matters. The word "karma" here is adding no value, > it is again useless word clutter. I agree with this observation and in this particular case (term "karma" used in Bodhi) I'd be up for clarification / term cleanup, since we already have redundant, well understood, mechanics in place. -- Michal Schorm Software Engineer Databases Team Red Hat -- -- ___ 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
