Re: [SPDX] Mass license change - batch #3 of all remaining packages
Miroslav Suchý wrote: > Dne 28. 08. 24 v 12:38 odp. Miro Hrončok napsal(a): > > Please exclude pythran: > > https://src.fedoraproject.org/rpms/pythran/pull-request/31 > > Ack. Excluded. (But still included in the files below) > > Also, could you please send a plain list of packages you plan to change, so > > I can run it trough > > find-package-maintainers and see the list of packages that I co-maintain? > > (Or just share the output of > > find-package-maintainers yourself.) > > List of maintainers > > https://miroslav.suchy.cz/fedora/rest-of-callaway-batch3-maintainers.txt > Just packages: https://miroslav.suchy.cz/fedora/rest-of-callaway-batch3.txt Please exclude zulucrypt. I am in the process of doing the conversion during my update to the newest upstream version, but it is waiting on two things: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/561, https://gitlab.com/fedora/legal/fedora-license-data/-/issues/512#note_2075509038. -Ian > And the same for the batch #2 > List of maintainers: > https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2-maintainers.txt > Just packages https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2.txt -- ___ 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: poppler soname bump in Rawhide
Gwyn Ciesla wrote: > libreoffice is done. > inkscape, sadly, uses the unstable API and fails: > In file included from /usr/include/poppler/Object.h:44, > from /usr/include/poppler/GfxState.h:41, > from /usr/include/poppler/Gfx.h:40, > from > /builddir/build/BUILD/inkscape-1.3.2-build/inkscape-1.3.2_2023-11-25_091e20ef0f/src/extension/internal/pdfinput/svg-builder.h:30, > from > /builddir/build/BUILD/inkscape-1.3.2-build/inkscape-1.3.2_2023-11-25_091e20ef0f/src/extension/internal/pdfinput/pdf-input.h:25, > from > /builddir/build/BUILD/inkscape-1.3.2-build/inkscape-1.3.2_2023-11-25_091e20ef0f/src/extension/init.cpp:41: > /usr/include/poppler/goo/GooString.h:241:24: error: ‘starts_with’ has not > been declared in ‘std::string’ > 241 | using std::string::starts_with; > |^~~ > /usr/include/poppler/goo/GooString.h:244:24: error: ‘ends_with’ has not been > declared in ‘std::string’ > 244 | using std::string::ends_with; > |^ > I'll dig further unless someone else has seen this before. Both std::string::starts_with() and std::string::ends_with() were added in C++20, so if this header is being included in a build using an older C++ standard, these two functions won't be defined by the string header. > -- > Gwyn Ciesla > she/her/hers > > in your fear, seek only peace > in your fear, seek only love > -d. bowie > Sent with Proton Mail secure email. > On Tuesday, August 6th, 2024 at 10:12 AM, Marek Kasik mka...@redhat.com wrote: > > Hi, > > > I've prepared rebase of poppler to 24.08.0, which was released last > > week, in the side tag "f41-build-side-93673". I'm asking you to build > > your dependent packages in it and I will merge it to the main buildroot > > at Monday (12th of August) just before the branching. > > > There are several API changes and soname bump of the base library > > libpoppler.so.* and also some changes in CPP frontend which needed bump > > of libpoppler-cpp.so.* too. > > > Packages which need to be rebuilt: > > boomaga > > calligra > > deepin-file-manager > > docparser > > efl > > extractpdfmark > > gambas3 > > gdal > > gdcm > > inkscape > > kf5-kitinerary > > kitinerary > > libcupsfilters > > libreoffice > > pdf2djvu > > pdfgrep > > R-pdftools > > scribus > > > If your package still uses the unstable API (headers from > > poppler-devel), could you consider to change it to use a stable API in > > the future (glib, qt5, C++)? It would mean less work for you and I would > > be able to disable the unstable API. > > > Regards > > Marek > > > -- > > ___ > > 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: heads up: julia has a bunch of incorrect Provides (bug 2291191)
> On Mon, Jun 10, 2024 at 11:57 PM Adam Williamson > > You are right - I meant to say it was suspicious that these commits > were only done in the f40 branch, but are not present in rawhide. > Usually packages are worked on in rawhide *first* and then changes are > merged or backported to stable branches. > > Reading up on the bug, the situation with Julia does indeed sound like > a major clusterf***. > If Julia only supports running on top of the same versions of > libraries that it was built against, maybe it needs to be rebuilt any > time any of those libraries change? It is more complex than that, because there is generally an FFI layer built into the Julia code, so if the API has changed at all for those libraries (which it did recently for SuiteSparse in a way that broke Julia), then parts inside Julia also need updating to match the new API. > It also sounds like Julia packages are distributed as pre-compiled > binaries? That seems like a major security issue if Julia is just > downloading pre-compiled binaries from somewhere and running them ... It is no more insecure than distributing RPM packages from mirrors in my view. They build all the binary packages using recipes from a GitHub repository here https://github.com/JuliaPackaging/Yggdrasil, and all the build logs are publicly viewable and build artifacts publicly downloadable for inspection. The binaries are then hosted as Julia packages in their own GitHub repo (in this org https://github.com/JuliaBinaryWrappers) with the binary artifacts attached as release artifacts. They also mirror them through packaging servers to distribute the load (so not everyone has to download from GitHub). So I don't see this as being any less secure than the RPM distribution chain. > > Fabio -- ___ 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: julia has a bunch of incorrect Provides (bug 2291191)
> Fabio Valentini venit, vidit, dixit 2024-06-14 16:25:56: > > Julia comes from a mindset or background where reproducibility is > important. Think of data science where you distribute both analysis and > code and want your code to always support your analysis ;-) > > Now, one thing is enabling that (via explicit requirements, bundling, > containerizing and such), another thing is basically inhibiting > unbundling. > > Julia users might be best served by not packaging Julia as rpm any more. > This implies not packaging it as Fedora flatpak either. > > I would not phrase this as "Fedora does not support Julia", though. > Rather, "Julia does not support distribution packaging" but also "Fedora > supports containerized workflows" such as those preferred by and > supported by Julia. In fact, Fedora/RHEL are *the* base for > containerized workflows, of course! The better way to use Julia is through juliaup (https://github.com/JuliaLang/juliaup), which will install it from versions compiled by the upstream project and hosted on their infrastructure - and also allow for installation of multiple versions side-by-side (since there are both long-term support versions like 1.6 and the current stable version). I had a look at packaging it before, but never followed up on that yet, just due to not having enough time yet. (I think it should just need to be a rust2rpm package, with one or two extra dependencies that need packaging). > > 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: Schedule for Monday's FESCo Meeting (2024-05-20)
Is there a full log somewhere? I don't see it on https://meetbot.fedoraproject.org/, and the usual links at the top of the summary email aren't there this time. -- ___ 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: Firefox 126.0 with DBus service
What if I don't use GNOME search? I don't use the GNOME desktop, so I don't want to have a random Firefox process running on my machine that is doing absolutely nothing and just hogging resources. Is this process only created when something tries to talk to it on the DBus socket, or is it always there listening? Also, don't new enabled-by-default services need approval from either FESCO or the Workstation WG according to the packaging docs (https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/)? I know the page seems to focus on systemd services, but it does mention DBus services in a few place on the page, so I thought it would apply to DBus services that are automatically enabled as well. -- ___ 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: CMake's check-compiles fails to parse WITH_GZFILEOP
> Dne 05. 01. 24 v 11:10 Milan Crha napsal(a): > > > There certainly were these changes: > > https://github.com/zlib-ng/zlib-ng/commit/0560a3a63dfdd6642724c8fad4db9dc... > > https://github.com/zlib-ng/zlib-ng/commit/6592accb2541aa637844cabef16b7ad... > > > Vít I don't think zlib-ng is the root cause of this, that looks to be setting the pkgconfig flags correctly, since there is no difference between compile definitions and other flags in pkgconfig (unlike CMake which does separate definitions, include paths, etc. into separate variables). What is happening is that CMake is assuming that -DWITH_GZFILEOP is actually a CMake internal variable for try_compile, when it is not. Building EDS with --trace --trace-expand shows it is trying to use the following call to try_compile: /usr/share/cmake/Modules/Internal/CheckSourceCompiles.cmake(101): try_compile(HAVE_GPOWERPROFILEMONITOR SOURCE_FROM_VAR src.c _source COMPILE_DEFINITIONS -DHAVE_GPOWERPROFILEMONITOR LINK_LIBRARIES;-L/usr/lib64;-lxml2;-lsoup-3.0;-lgobject-2.0;-lgio-2.0;-lgmodule-2.0;-pthread;-Wl,--export-dynamic;-lglib-2.0 CMAKE_FLAGS -DCOMPILE_DEFINITIONS:STRING=-I/usr/include/libxml2;-I/usr/include/libsoup-3.0;-I/usr/include/glib-2.0;-I/usr/lib64/glib-2.0/include;-I/usr/include/libmount;-I/usr/include/blkid;-I/usr/include/sysprof-6;-pthread;-DWITH_GZFILEOP -DINCLUDE_DIRECTORIES:STRING=/usr/include/libxml2;/usr/include/libsoup-3.0;/usr/include/glib-2.0;/usr/lib64/glib-2.0/include;/usr/include/libmount;/usr/include/blkid;/usr/include/sysprof-6 OUTPUT_VARIABLE OUTPUT ) Looking further up in the EDS CMake output, EDS itself is passing that inside its CMAKE_REQUIRED_FLAGS variable here: /builddir/build/BUILD/evolution-data-server-3.51.1/CMakeLists.txt(913): set(CMAKE_REQUIRED_FLAGS -I/usr/include/libxml2;-I/usr/include/libsoup-3.0;-I/usr/include/glib-2.0;-I/usr/lib64/glib-2.0/include;-I/usr/include/libmount;-I/usr/include/blkid;-I/usr/include/sysprof-6;-pthread;-DWITH_GZFILEOP ) /builddir/build/BUILD/evolution-data-server-3.51.1/CMakeLists.txt(914): set(CMAKE_REQUIRED_INCLUDES /usr/include/libxml2;/usr/include/libsoup-3.0;/usr/include/glib-2.0;/usr/lib64/glib-2.0/include;/usr/include/libmount;/usr/include/blkid;/usr/include/sysprof-6 ) /builddir/build/BUILD/evolution-data-server-3.51.1/CMakeLists.txt(915): set(CMAKE_REQUIRED_LIBRARIES -L/usr/lib64;-lxml2;-lsoup-3.0;-lgobject-2.0;-lgio-2.0;-lgmodule-2.0;-pthread;-Wl,--export-dynamic;-lglib-2.0 ) / An interesting thing to note about that is that it is using ;-list formatting in CMake for this call, but according to the docs for CheckCSourceCompiles, these CMAKE_REQUIRED_<> variables should have the values space-separated, not as a ;-list (https://cmake.org/cmake/help/latest/module/CheckCSourceCompiles.html), so that should probably be fixed in EDS to see if the problem stays or if it goes away. -Ian -- ___ 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: Linker Error on Security Issues (System-Wide)
On Mon, Nov 13, 2023 at 11:08 AM Aoife Moloney wrote: > Wiki -> > https://fedoraproject.org/wiki/Changes/Linker_Error_On_Security_Issues > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Change the system linker (ld.bfd) so that by default it will generate > an error message and fail if it is asked to create an executable > binary that contains one or more known security issues. These issues > are: > * an executable stack > * a loadable segment with read, write and execute permissions, > * a thread local storage segment with execute permission. > > == Owner == > * Name: [[User:nickc| Nick Clifton]] > * Email: ni...@redhat.com > > > == Detailed Description == > The BFD linker (ld.bfd) is able to detect several potential security > problems with the binaries that it is creating. Currently however the > linker's default behaviour is to generate warning messages about these > problems, but then it carries on and completes the link. > > Since only warning messages are generated, and these can be ignored or > lost in the output from a build, it is possible that packages are > being built without their owners being aware of the potential security > problems. Hence this change will alter the linker's default behaviour > to turn the warnings into errors, which in turn will prevent the > builds from completing successfully. > > The change would apply to three linker warnings: > > * The creation of a program containing a stack that is in a memory > region that has execute permission. > * The creation of a program with a loadable segment that has all three > of the read, write and execute permission bits set. > * The creation of a thread local storage segment that has the execute > permission bit set. > > == Feedback == > > == Benefit to Fedora == > The benefit of this change is that it will increase the overall > security of Fedora by helping to ensure that packages cannot be built > with one or more of these vulnerabilities without the owner being made > aware and having to take specific actions - either to remove the > vulnerability or disable the linker error message. > > == Scope == > * Proposal owners: > Enable the 'error_for_executable_stacks' and 'error_for_rwx_segments' > optional features in the binutils.spec file and then rebuild the > binutils. > > Following that a system wide rebuild will be needed in order for the > change to have a chance to take affect and cause vulnerable packages > to fail to build. Any packages that fail to build because of the > change will need to be updated to either remove the cause of the > problem or else add an extra command line option to be passed to the > linker to disable the new feature. > > * Other developers: > Other developers will only be affected if their package(s) fail to > build with the new linker. In this case the developer will need to > decide if the security vulnerability is actually needed by their > package, and if so add a linker command line option to turn off the > error, or if the vulnerability is not needed then fix their code so > that the problem is removed. > > It is known that this change will affect the edk2, glibc and grub2 > packages. Their owners will be contacted to assist them in deciding > how they wish to resolve the problems specific to their packages. > > Other developers can use the "--no-warn-execstack" and > "--no-warn-rwx-segments" linker command line options to disable the > errors. > Is there a way to test for problems due to this before the spec file changes are made? E.g. is there a set of linker flags that can be given during mock/scratch builds to enable this check in individual packages to see if they are affected? -Ian > > > * Release engineering: [https://pagure.io/releng/issue/11777] > > * Policies and guidelines: N/A (not needed for this Change) > The packaging guidelines should not need to be updated. The vast > majority of programs will not be affected by this change. Packages > that are affected will already be requiring special behaviour from the > linker, so it can be assumed that their maintainers are familiar with > how to report linker problems and how to receive help. > > > * Trademark approval: N/A (not needed for this Change) > > * Alignment with Community Initiatives: N/A > > > == Upgrade/compatibility impact == > Upgrading previous versions of Fedora to one containing this change > will have no immediate effect. In fact the only visible change would > be if the upgraded system is used to compile a program and that > program contains one or more of the potential security vulnerabilities > that will now trigger errors. Even then the previous functionality > (of being able to successfully compile the vulnerable program) can be > restored by adding a specific linker command l
Re: Does a change approved for f39 need reapproval for f40?
On Mon, Oct 30, 2023 at 2:06 PM Jonathan Wakely wrote: > Well it looks like I took too long to do the deferral to F40, and so > FESCO dropped the change: > https://pagure.io/fesco/issue/3059#comment-875144 > > So now do I need to re-submit as a fresh change for F40? > My reading of the email replies to the FESCO minutes when they announced this ( https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E3M624WQFJV4L5NCJBA3UC746Z7BWNO5/#TMIPXR25CJR72BUMXHKTVICUKVUU5REM) is that they want an entirely new change proposal for it... since they apparently didn't think anyone was working on it and that it was completely abandoned even though you had emailed that you were working on it. -Ian > > On Fri, 11 Aug 2023 at 20:49, Fabio Valentini > wrote: > > > > On Fri, Aug 11, 2023 at 9:43 PM Ben Cotton > wrote: > > > > > > On Fri, Aug 11, 2023 at 2:56 PM Jonathan Wakely > wrote: > > > > > > > > This change got approved for f39 but couldn't be done in time: > > > > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB > > > > > > > > Does it need to be re-proposed and approved for f40, or can we just > do it now? (in a side tag, as planned, of course). > > > > > > No, just do it: > > > > > > > Changes that cannot be completed will automatically be deferred to > the next release and do not require re-submission unless substantial > revisions are made. > > > > Speaking with my packager and FESCo hats on, I think it would also > > still be OK to push the change to both F40 *and* F39, so there > > wouldn't even be a need to defer at all. If you want to go this route, > > it might be good to ask FESCo for guidance (i.e. file a ticket), but I > > think the likelihood that we'll just tell you "go ahead with the > > changes in both F40 and F39" is pretty high. :) > > > > Fabio > > ___ > > 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 > ___ 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: Libcmis solib bump
On Thu, Oct 12, 2023 at 6:39 AM Gwyn Ciesla via devel < devel@lists.fedoraproject.org> wrote: > Libcmis 0.6.0 is coming to rawhide, and libreoffice-TexMaths, > openoffice.org-diafilter, python-paperwork-backend, and libreoffice are > being rebuild against it. > > Thanks for taking care of this, but just an FYI, the libreoffice-TexMaths and openoffice.org-diafilter packages need the updated libreoffice before they can be built, otherwise the rebuild isn't useful (and actually in this case, since the build for libreoffice-TexMaths ran before libreoffice is in the build root, it couldn't succeed since the current libreoffice package is uninstallable). -Ian > > -- > Gwyn Ciesla > she/her/hers > > in your fear, seek only peace > in your fear, seek only love > -d. bowie > > > > Sent from Proton Mail mobile > > > ___ > 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: Making -Wmissing-include-dirs an error?
On Tue, Oct 10, 2023 at 11:59 AM Neal Gompa wrote: > Hey all, > > Recently, one of the folks working on packaging stuff in Fedora KDE > nearly missed an issue caused by GCC emitting a warning about missing > include dirs: > > > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or > directory [-Wmissing-include-dirs] > > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or > directory [-Wmissing-include-dirs] > > I did manage to figure out this meant we needed an additional build > dependency (qt6-qtbase-private-devel, FYI), but it made me think if > there's a reason this shouldn't be an error. > > If it's an error, then at least we can evaluate these things and > ensure we have the right build inputs... > Missing an include directory isn't necessarily the problem though, it is the missing headers that aren't present when they are included that would be - and that should trigger a build error for the missing file. What advantage does failing on this warning provide that the failure on the include file missing doesn't? -Ian > > What do y'all think? > > -- > 真実はいつも一つ！/ 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 > ___ 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: Summary/Minutes from today's FESCo Meeting (2023-09-21)
On Thu, Sep 21, 2023 at 7:50 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Minutes: > https://meetbot.fedoraproject.org/fedora-meeting-2/2023-09-21/fesco.2023-09-21-17.03.html > Minutes (text): > https://meetbot.fedoraproject.org/fedora-meeting-2/2023-09-21/fesco.2023-09-21-17.03.txt > Log: > https://meetbot.fedoraproject.org/fedora-meeting-2/2023-09-21/fesco.2023-09-21-17.03.log.html > > Meeting summary > --- > * init process (zbyszek, 17:03:05) > * ModernizeTBB is dropped. (zbyszek, 17:11:37) > Why was this dropped instead of just being pushed to the next release? There is already the compat package imported ( https://src.fedoraproject.org/rpms/tbb2020.3, https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HHT5VR7V3DCDZYUICOX2J6ZSPXWKY2PX/), and it was stalled by fallout from Python 3.12 ( https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P44YQVEVWDDMYAUMQSA6NQQEVQRDAZ4G/, https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MPK673HOREP6GMBEFSNPWNH5FSAENNGF/). Dropping the change and making the owners go through the entire process again in F40 when it is already in progress is not a nice thing to do. -Ian > * LegacyXorgDriverRemoval is dropped. (zbyszek, 17:13:41) > * LINK: > https://src.fedoraproject.org/rpms/fedora-release/pull-request/279 > (Son_Goku, 17:15:38) > * ACTION: nirik to look into the last pull request for Enable > fwupd-refresh.timer by default on IoT, CoreOS & Server editions. > (zbyszek, 17:16:48) > * https://src.fedoraproject.org/rpms/fedora-release/pull-request/279 > (zbyszek, 17:16:57) > * Allow Removal of tzdata is (in its basic part) done. (zbyszek, > 17:21:02) > > * #3063 Should we remove Systemd-boot support from Anaconda (zbyszek, > 17:22:37) > * AGREED: REJECTED (0, 0, -6) (zbyszek, 17:28:11) > > * #3068 Ongoing problems with ELN contributions (zbyszek, 17:28:37) > * LINK: https://paste.centos.org/view/364d755f (mhroncok_web, > 17:48:54) > * LINK: > > https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2023-09-21/fesco.2023-09-21-17.03.log.txt > (nirik, 17:49:00) > * ACTION: sgallagh to preparate an update for the ELN documentation > (zbyszek, 18:06:13) > > * Next week's chair (zbyszek, 18:21:50) > * ACTION: sgallagh will chair next meeting (zbyszek, 18:24:11) > > * Open Floor (zbyszek, 18:24:12) > * LINK: https://koji.fedoraproject.org/koji/taskinfo?taskID=106473542 > for example (nirik, 18:38:37) > * ACTION: davdunc and/or mhayden to publish azure images (nirik, > 18:40:03) > * ACTION: adamw to make sure we have azure images linked from the > final candidate test pages, and an azure column in the table > (zbyszek, 18:40:09) > * AGREED: FedoraWorkstationImageBuilder is deferred to F40 (+6, 0, 0) > (zbyszek, 18:44:10) > * ACTION: zbyszek to adjust the Change page. (zbyszek, 18:44:31) > > Meeting ended at 18:45:54 UTC. > > > > > Action Items > > * nirik to look into the last pull request for Enable > fwupd-refresh.timer by default on IoT, CoreOS & Server editions. > * sgallagh to preparate an update for the ELN documentation > * sgallagh will chair next meeting > * davdunc and/or mhayden to publish azure images > * adamw to make sure we have azure images linked from the final > candidate test pages, and an azure column in the table > * zbyszek to adjust the Change page. > ___ > 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: F40 Change Proposal: KDE Plasma 6 (System Wide)
On Thu, 14 Sep 2023, 09:24 Michael J Gruber, wrote: > Am Mi., 13. Sept. 2023 um 23:29 Uhr schrieb Neal Gompa >: > > > > On Wed, Sep 13, 2023 at 5:24 PM Fabio Valentini > wrote: > > > > > > On Wed, Sep 13, 2023 at 11:19 PM Steven A. Falco < > stevenfa...@gmail.com> wrote: > > > > > > > > A question about this - the removal of X11 is listed on a change > proposal for KDE. Does the removal just apply to KDE or would it be > distribution wide; i.e. affecting all desktops? > > > > > > I assume the following is not meant literally: > > > > > > """ > > > 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. > > > """ > > > > > > I doubt that the intention is to drop X11 sessions entirely and make > > > "Plasma Wayland" the only session available on Fedora *in general*, > > > but rather that the "Plasma X11" session will be dropped, and that > > > "Plasma Wayland" will be the only *Plasma* session available. > > > > > > > Yes! Sorry if it's ambiguous, it's hard to write this to account for > > all the ways it can be interpreted. This is scoped to the KDE Plasma > > solution stack. > > The proposal is clearly about KDE plasma and *its* sessions. Or else > "leaving only Plasma Wayland as the sole offered desktop mode" would > have to mean the end of all other desktops on Fedora ;-) > > > Other desktops can and will make their own choices on the transition to > Wayland. > > Rightly so. Fewer and fewer will pull in X11, and that's a good change. > > Now, if you (as in "they" - not you Neal, obviously) see "change" and > something Wayland has not worked in the past and you go ballistic > about it then for you (as in "they") that formulation might be > ambiguous. But if you take a breath or a step back or both then the > proposal is crystal clear. At the same time, there is no way around it > given upstream's directions. > > Talking of upstream: I see some upstreams giving up on Wayland > support. Kicad was reported here, Scribus is another one. It's a > surprising time to do that, but probably indicates toolkit issues or > simply lack of people power. I hope we can help at least on the > toolkit side. That would be time well spent - invested in the future > of the platform. The decision to not support Wayland in KiCad was taken because the graphics stacks didn't have the features we relied on to provide the UI/UX wanted by our users (mainly pointer warping and window positioning, but there maybe others I can't recall now), and whenever we found discussions about having those kind of things in upstream toolkits like GTK4/Wayland, it always seemed to be greeted with responses that that seemed to convey "don't do that, it is terrible UI/UX and you are idiots for wanting it. We [the upstream devs] know exactly what every application should do and so you can either do it our way or go away and shut up." So, we decided not to invest anymore time or energy in this and just said "we don't support Wayland." I don't know if the attitude of the upstream projects has changed or not, but this previous response has soured our taste for doing work on it. -Ian Nobody will stop anyone from shipping a plasma-x11 > package (and it's ridiculous to try and read that into the proposal) > or even a full stack plasma 5, but that will just drag out the > transition that is happening nonetheless. > > Full disclosure: Writing this from F38/X11/i3 ;-) > F39 should be a good release to try the switch (Wayland/sway for me), > and in fact for some releases we have had dual session options now at > least for Gnome and KDE (X11/Wayland) so that one could try and switch > apps gradually. Reliance on WebRTC (and the switches i3/sway, st/foot > etc) made me chicken out so far, but now is the time! > > 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 > ___ 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 Thu, 14 Sep 2023, 00:17 Neal Gompa, wrote: > On Wed, Sep 13, 2023 at 7:02 PM Steven A. Falco > wrote: > > > > On 9/13/23 05:23 PM, Neal Gompa wrote: > > > Right. And I want to stress we are not dropping support for X11 > > > applications. Anything running as an X client in a desktop should work > > > as it has before. > > > > I'm not convinced KiCad will work in that scenario, so please let me > summarize what I've read here, and please correct me if I have any of this > wrong. > > > > The thing being removed is "Plasma(X11)", which is a native X11 stack; > i.e. no Wayland or Xwayland is involved when using Plasma(X11). This mode > is well supported by KiCad, and additionally it works well with my > multi-monitor setup. > > > > Should the change proposal be accepted, "Plasma(X11)" will be removed, > leaving "Plasma(Wayland)" as the only available KDE mode. Also, all X11 > applications will then be forced to use XWayland rather than X11, at least > under KDE. > > > > Assuming my summary is correct, here are my personal problems: > > > > Problem 1: The KiCad team says they don't support XWayland (nor do they > support pure Wayland) because of bugs. > > > > From what I've read through the issues, the ultimate problem is in > GTK, not wxWidgets, as there is in fact a supported Wayland protocol > for mouse warping[1]. Does this issue exist when using wxQt instead of > wxGTK? Admittedly, I'm not sure of the state of things with wxWidgets > and the backends... > > [1]: https://wayland.app/protocols/pointer-constraints-unstable-v1 > > Speaking as a member of the KiCad core development team, I am not convinced that extension will be easy to use. When I looked at it a few weeks ago, it still seemed to have portability problems between compositors/WM implementations. (See here for my conclusion https://github.com/wxWidgets/wxWidgets/issues/23778#issuecomment-1680398578). As a project, we already have to deal with enough problems from supporting MSW, macOS and Linux that having to now workaround quirks in different graphics stacks is not something we have the time or developer effort to do. We would rather be actually creating the features all our users need for their work instead of having to fight with the graphics stacks all the time. And aside from the mouse warping, we also want the ability to control where windows are placed on the screen. We are a multi-window application, and our users usually have a preferred setup for how the windows are arranged on their screen. Right now, we can save/restore that for them, but my understanding of the Wayland spec is that this is not allowed and so we are at the mercy of the desktop to put the windows where it wants. -Ian > Problem 2: Plasma(Wayland) doesn't work with my multi-monitor setup. > > > > Do you have a bug report filed at bugs.kde.org about your setup? The > KDE folks can take a look and we can try to have things fixed in > Plasma (in Plasma 5 today or Plasma 6 when it lands). > > > Conclusion: If there are remaining Fedora desktops using X11, I might be > able to continue using Fedora, and I might be able to continue supporting > KiCad, _assuming_ I'm willing to switch to another desktop. Of course, > after having used KDE for 20+ years, switching is not very appealing, nor > is it very likely, frankly. > > > > Part of the reason for filing this Change is to shake out these cases > and make sure we can get them covered. For what it's worth, I want you > to have a good experience on Plasma Wayland, and I'm happy to help try > to facilitate that however I can. > > > -- > 真実はいつも一つ！/ 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 > ___ 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: Rawhide build failures
I think it is actually because of a change proposal, there was a recent email about the webkit2gtk4.0 package changing: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IFRPWZNEFEGXGQFRNTH4LTFFLTJ5DOCL/, so it is actually a problem I think. -Ian On Mon, Aug 21, 2023 at 7:48 PM Steven A. Falco wrote: > Looks like it is a mirror issue. Adding --enablerepo=local corrects it. > > Please disregard my previous email. > > Steve > > On 8/21/23 02:41 PM, Steven A. Falco wrote: > > Not sure if this is a known problem, but I'm getting build failures from > mock on rawhide. F37, F38, and F39 are ok. > > > > Steve > > > > Error: > > Problem: package wxGTK-devel-3.2.2.1-5.fc39.x86_64 from fedora > requires libwx_gtk3u_webview-3.2.so.0()(64bit), but none of the providers > can be installed > >- cannot install the best candidate for the job > >- nothing provides libwebkit2gtk-4.0.so.37()(64bit) needed by > wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora > >- nothing provides libjavascriptcoregtk-4.0.so.18()(64bit) needed by > wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora > > (try to add '--skip-broken' to skip uninstallable packages or '--nobest' > to use not only best candidate packages) > > Finish: build setup for kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm > > Finish: build phase for kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm > > ERROR: Exception(kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm) > Config(fedora-rawhide-x86_64) 1 minutes 6 seconds > > INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result > > ERROR: Command failed: > > # /usr/bin/dnf-3 builddep --installroot > /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 40 > --setopt=deltarpm=False --setopt=allow_vendor_change=yes --allowerasing > --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock > /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/kicad-7.0.7-1000.20230821git45963a3.fc40.src.rpm > > No matches found for the following disable plugin patterns: local, > spacewalk, versionlock > > fedora 121 kB/s | 20 kB > 00:00 > > Error: > > Problem: package wxGTK-devel-3.2.2.1-5.fc39.x86_64 from fedora > requires libwx_gtk3u_webview-3.2.so.0()(64bit), but none of the providers > can be installed > >- cannot install the best candidate for the job > >- nothing provides libwebkit2gtk-4.0.so.37()(64bit) needed by > wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora > >- nothing provides libjavascriptcoregtk-4.0.so.18()(64bit) needed by > wxGTK-webview-3.2.2.1-5.fc39.x86_64 from fedora > > (try to add '--skip-broken' to skip uninstallable packages or '--nobest' > to use not only best candidate packages) > ___ > 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: Modernize Thread Building Blocks for Fedora 39
On Thu, Jul 6, 2023 at 11:12 AM Jonathan Wakely wrote: > This is a status update for > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB > > The tbb2020.3 compat package has now been added to rawhide: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb > > It doesn't include the docs or python modules (you can use the main > tbb package for those). > > The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given > package only needs to build against one or the other, not both. > > Later today I will start submitting pull requests for the packages > which need to switch from BuildRequires: tbb-devel (or similar) to > using tbb2020.3-devel instead. The affected packages are: > > blender > gazebo > opencascade > Wouldn't it be better to just update OpenCascade to its new upstream version in that sidetag as well instead of doing a compat package for it? The new OpenCascade actually requires the new TBB and can't be built with the older version. See https://bugzilla.redhat.com/show_bug.cgi?id=2217295. -Ian > opensubdiv > usd > > After those packages have been rebuilt against tbb2020.3 I'll create a > side tag and push a new spec file to the 'tbb' package to update it to > version 2021.9.0 (based on the > https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ package made > by Jerry James). Then the remaining packages that depend on tbb can be > rebuilt against the new tbb in the side tag. > ___ > 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: Orphaning despite having maintainers?
On Thu, Apr 27, 2023 at 3:25 AM Alexander Bokovoy wrote: > On ke, 26 huhti 2023, Gary Buhrmaster wrote: > >On Wed, Apr 26, 2023 at 9:04 AM Alexander Bokovoy > wrote: > >> > >> Hi, > >> > >> This morning I woke up to find that packages I maintain were orphaned > >> out of blue. Nobody contacted the maintainers, nobody raised any tickets > >> to releng, as far as I can see. Yet, releng ran the orphaning from what > >> I saw in a few bugs. > >> > >> What is happening? Who and how made those decisions? > > > >Removing inactive packagers (who have not > >made any package updates, nor responded to > >direct emails, for an extended period are removed > >from the packagers group as part of good > >security hygiene per: > > > https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ > > > >It is an artifact of that fact that in Fedora, packages > >have only one main admin, and when that packager > >is removed from the packagers group, their packages > >get orphaned (there is no automated promotion, > >and nor should there be, to select one of the other > >maintainers, as that would also imply other > >responsibilities that one might not want). You (or > >other interested packager) can go to: > > https://src.fedoraproject.org > >and "Take" that packager to become the new > >main admin/owner. > > My concern is that for packages that have more than one maintainer, no > notification that the packages will be orphaned has happened to them. > > Notifying the other maintainers is actually a part of the normal nonresponsive maintainer process ( https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#steps, Week 1 step 1). So I think this was probably just an oversight in the drafting of the mass removal process. > This is a pretty bad situation. Take, for example, cifs-utils. It had > six maintainers, including inactive admin at that point. None of the > maintainers except the inactive person received any notification that > the package was going to be orphaned. > > I understand the logic behind 'no automated promotion' but the current > logic in the process is effectively not treating existing maintainers as > worth anything. > > I see this as a problem with the policy and I am raising this issue as I > believe we should fix the policy. > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > ___ > 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: Change my new package name in src.fedoraporject.org ?
On Thu, Apr 13, 2023 at 11:21 AM Alexander Ploumistos < alex.ploumis...@gmail.com> wrote: > > > On Thu, Apr 13, 2023, 10:28 Miro Hrončok wrote: > >> On 13. 04. 23 10:18, Sébastien Le Roux wrote: >> > Dear all, >> > yesterday I created my first package repository: >> > >> > https://src.fedoraproject.org/rpms/Atomes >> > >> > I used the command (that you all must be familiar with): >> > >> > fedpkg request-repo Atomes 2130607 >> > >> > After a first try using "atomes" that did not work, indeed fedpkg >> requested >> > the keyword to be "Atomes" because of an information in the bug report. >> > >> > I could only certify afterwards that the repo was named "Atomes" and >> not >> > "atomes" as I hoped. >> > Can anyone help in renaming the project "atomes" instead of "Atomes" ? >> > >> > Thanks in advance for your help. >> >> RENAME the package review request bugzilla to "Review Request: atomes - >> An >> atomistic tool box" and try `fedpkg request-repo atomes 2130607` again. >> >> If it works, retire the Atomes package with `fedpkg retire "Renamed to >> atomes"`. >> >> In http://bugzilla.redhat.com/2130607 the reviewer should have noted >> this and >> not approve the package. >> > > > Sorry everyone for the formatting, I have to reply from my phone. > > I mistakenly thought that the name could be whatever upstream calls their > package and for the rest, the spec file is what matters. My bad. > > That being said, now that the requirement on lower case names has been > relaxed, I guess Sébastien can name the package with the same spelling he's > using upstream, i.e. "Atomes". If indeed he prefers that, can he use the > same branch that he's got now, rename his spec file to Atomes.spec and add > an "Obsolètes: atomes" in it to take care of users who might have already > installed it? > I think a Provides: atomes would be more appropriate than an Obsolete - there isn't an old package called atomes being replaced. > > I guess if he wants to strictly adhere to the rules, he'll have to jump > through the renaming hoop. > > My sincere apologies for the blunder. > ___ > 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: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 2:35 PM Stephen Smoogen wrote: > > > On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel < > devel@lists.fedoraproject.org> wrote: > >> >> >> On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen >> wrote: >> >>> >>> >>> On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < >>> devel@lists.fedoraproject.org> wrote: >>> >>>> >>>> >>>> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb wrote: >>>> >>>>> On 4/9/23 16:05, Ian McInerney via devel wrote: >>>>> > I decided to put F38 onto my new machine from the start (so a clean >>>>> > install), and now it seems to have some errors with DNF/RPM that I >>>>> > haven't seen before on F37 when I tried the same thing. >>>>> > >>>>> > Specifically, I am trying to install packages from a 3rd-party >>>>> > repository (the Intel oneAPI repo), and it is throwing errors like: >>>>> > >>>>> > package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA >>>>> > signature: BAD (package tag 1002: invalid OpenPGP signature) >>>>> >package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA >>>>> > signature: BAD (package tag 1002: invalid OpenPGP signature) >>>>> > >>>>> > There are two things I don't understand here. >>>>> > >>>>> > The first is, why does DNF/RPM in F38 fail to parse this GPG >>>>> signature, >>>>> > while DNF/RPM on F37 does parse it? >>>>> >>>>> https://fedoraproject.org/wiki/Changes/RpmSequoia >>>>> See the upgrade impact and user experience sections. >>>>> >>>>> You should contact Intel about fixing their packages. >>>>> >>>> >>>> So we have pushed a change in Fedora where there is no nice way for a >>>> user to workaround it except by complaining to a company that probably >>>> doesn't care what normal users (e.g. non-paying customers) care about? >>>> >>>> >>> Basically the problem is that several checksums and types of keys are >>> considered highly insecure and will cause problems for large numbers of >>> users who have systems which need to meet general security rules in various >>> industries. These include the SHA1 and DSA encryption keys and there are >>> requirements that operating systems no longer ship these as enabled for the >>> operating system to be used in universities, health care, etc. Where in the >>> past these sorts of things have been 'given' a long time for removal (aka >>> the 10+ years for MD5), my understanding is that these are being pushed >>> much faster and harder than before. [Mainly in that continued funding from >>> both public and private organizations is tied to audits etc.] The push is >>> going to come in several 'waves' with SHA1 and DSA marked as bad now and in >>> 1-2 years, SHA256 and RSA keys below 4096. Like most rapid changes, there >>> is always going to be a lot of grit in the gears for everyone trying to >>> continue working outside of the change :/ >>> >>> >> This error has nothing to do with the crypto change that was made - I had >> already reverted that change and pushed my crypto settings back to >> DEFAULT:FEDORA32, and it still gave these errors. They are completely >> caused by an RPM change. >> >> > You are correct and I was wrong. I should have downloaded the RPM to see > what the problem was first. The problem looks to be related to > https://github.com/rpm-software-management/rpm/issues/2351 where certain > code use to create 'PGP' signatures actually does not conform to the > OpenPGP standard. > > > # rpm -vvvK intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm > D: loading keyring from rpmdb > D: PRAGMA secure_delete = OFF: 0 > D: PRAGMA case_sensitive_like = ON: 0 > D: read h# 148 > Header SHA256 digest: OK > Header SHA1 digest: OK > D: added key gpg-pubkey-eb10b464-6202d9c6 to keyring > intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm: > Header V4 RSA/SHA256 Signature, key ID 7e6c5dbe: NOKEY > Header SHA256 digest: OK > Header SHA1 digest: OK > Payload SHA256 digest: OK > RSA signature: BAD (package tag 1002: invalid OpenPGP signature) > MD5 digest: OK > > I can't see if the code was using the gocrypt code or somet
Re: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen wrote: > > > On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < > devel@lists.fedoraproject.org> wrote: > >> >> >> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb wrote: >> >>> On 4/9/23 16:05, Ian McInerney via devel wrote: >>> > I decided to put F38 onto my new machine from the start (so a clean >>> > install), and now it seems to have some errors with DNF/RPM that I >>> > haven't seen before on F37 when I tried the same thing. >>> > >>> > Specifically, I am trying to install packages from a 3rd-party >>> > repository (the Intel oneAPI repo), and it is throwing errors like: >>> > >>> > package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA >>> > signature: BAD (package tag 1002: invalid OpenPGP signature) >>> >package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA >>> > signature: BAD (package tag 1002: invalid OpenPGP signature) >>> > >>> > There are two things I don't understand here. >>> > >>> > The first is, why does DNF/RPM in F38 fail to parse this GPG >>> signature, >>> > while DNF/RPM on F37 does parse it? >>> >>> https://fedoraproject.org/wiki/Changes/RpmSequoia >>> See the upgrade impact and user experience sections. >>> >>> You should contact Intel about fixing their packages. >>> >> >> So we have pushed a change in Fedora where there is no nice way for a >> user to workaround it except by complaining to a company that probably >> doesn't care what normal users (e.g. non-paying customers) care about? >> >> > Basically the problem is that several checksums and types of keys are > considered highly insecure and will cause problems for large numbers of > users who have systems which need to meet general security rules in various > industries. These include the SHA1 and DSA encryption keys and there are > requirements that operating systems no longer ship these as enabled for the > operating system to be used in universities, health care, etc. Where in the > past these sorts of things have been 'given' a long time for removal (aka > the 10+ years for MD5), my understanding is that these are being pushed > much faster and harder than before. [Mainly in that continued funding from > both public and private organizations is tied to audits etc.] The push is > going to come in several 'waves' with SHA1 and DSA marked as bad now and in > 1-2 years, SHA256 and RSA keys below 4096. Like most rapid changes, there > is always going to be a lot of grit in the gears for everyone trying to > continue working outside of the change :/ > > This error has nothing to do with the crypto change that was made - I had already reverted that change and pushed my crypto settings back to DEFAULT:FEDORA32, and it still gave these errors. They are completely caused by an RPM change. Further searching turned up this RPM issue: https://github.com/rpm-software-management/rpm/issues/2351, which does have a similar error to the one I saw, pointing to the change to the sequoia backend being the root cause. The part I disagree with is that this is "expected behavior". How is it good UX to break a user's system with no way of overriding it? If there is that drastic a difference in behavior between the two backends, then there should be a way to recover the legacy behavior when needed. -Ian > > > >> >> After further experimentation, I finally did find a way to do what I want >> (install these packages) - disable all package verification via the RPM >> macro. I initially found the option `tsflags=nocrypto` for DNF, but after >> putting that in the config file, it still didn't work (the man page for >> dnf.conf seems to suggest this should disable the checks that were failing >> here, but it didn't disable those). Falling back all the way to RPM with >> the --nosignature argument isn't an option here, because installing ~60 RPM >> packages manually is not going to fly. I eventually forced DNF to make RPM >> do it by setting `%_pkgverify_level none` inside `macros.verify`. I really >> don't want to use this large a hammer to fix this though, and would much >> rather the nocrypto option actually worked with DNF, so I could then >> disable it just for the one repo. >> >> -Ian >> >> >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >&g
Re: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb wrote: > On 4/9/23 16:05, Ian McInerney via devel wrote: > > I decided to put F38 onto my new machine from the start (so a clean > > install), and now it seems to have some errors with DNF/RPM that I > > haven't seen before on F37 when I tried the same thing. > > > > Specifically, I am trying to install packages from a 3rd-party > > repository (the Intel oneAPI repo), and it is throwing errors like: > > > > package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA > > signature: BAD (package tag 1002: invalid OpenPGP signature) > >package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA > > signature: BAD (package tag 1002: invalid OpenPGP signature) > > > > There are two things I don't understand here. > > > > The first is, why does DNF/RPM in F38 fail to parse this GPG signature, > > while DNF/RPM on F37 does parse it? > > https://fedoraproject.org/wiki/Changes/RpmSequoia > See the upgrade impact and user experience sections. > > You should contact Intel about fixing their packages. > So we have pushed a change in Fedora where there is no nice way for a user to workaround it except by complaining to a company that probably doesn't care what normal users (e.g. non-paying customers) care about? After further experimentation, I finally did find a way to do what I want (install these packages) - disable all package verification via the RPM macro. I initially found the option `tsflags=nocrypto` for DNF, but after putting that in the config file, it still didn't work (the man page for dnf.conf seems to suggest this should disable the checks that were failing here, but it didn't disable those). Falling back all the way to RPM with the --nosignature argument isn't an option here, because installing ~60 RPM packages manually is not going to fly. I eventually forced DNF to make RPM do it by setting `%_pkgverify_level none` inside `macros.verify`. I really don't want to use this large a hammer to fix this though, and would much rather the nocrypto option actually worked with DNF, so I could then disable it just for the one repo. -Ian > ___ > 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
F38 DNF/RPM install errors due to header signatures
I decided to put F38 onto my new machine from the start (so a clean install), and now it seems to have some errors with DNF/RPM that I haven't seen before on F37 when I tried the same thing. Specifically, I am trying to install packages from a 3rd-party repository (the Intel oneAPI repo), and it is throwing errors like: package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA signature: BAD (package tag 1002: invalid OpenPGP signature) package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA signature: BAD (package tag 1002: invalid OpenPGP signature) There are two things I don't understand here. The first is, why does DNF/RPM in F38 fail to parse this GPG signature, while DNF/RPM on F37 does parse it? Second, as a workaround I set both gpgcheck options in the repo file for this repository to be 0, but it still returns the same errors, so why is it still checking the GPG signature of the package if I disabled the GPG checks for the entire repo? For completeness, the versions are: F38: DNF 4.15.0-1.fc38 RPM 4.18.1-1.fc38 F37 DNF 4.14.0-1.fc37 RPM 4.18.0-1.fc37 Thanks, -Ian ___ 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: CentOS8/RHEL8/Fedora: dependency control: make gcc-c++ provide g++,required for pulseaudio.
On Sat, Mar 25, 2023 at 5:07 AM wrote:
The GCC spec file already contains
Provides: g++ = %{version}-%{release}
and doing a `dnf install g++` does try to install gcc-c++. So please be
specific about the error you are seeing and provide more information, and
especially why you say this is required for pulseaudio.
> Kind regards, Ilari Jääskeläinen.
> ___
> 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: Unretire IWYU - Include What You Use
On Thu, Mar 2, 2023 at 9:24 PM Benson Muite wrote: > Would like to unretire Include What You Use > https://bugzilla.redhat.com/show_bug.cgi?id=2175012 Taken, > > ___ > 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: c++ packaging of contour terminal and libunicode
On Mon, Feb 27, 2023 at 12:21 PM Felix Wang wrote: > Thanks for your advice. I tried and it can be built with no error, but > when installing built contour package, it shows the following error: > ``` > Error: > Problem: conflicting requests > - nothing provides libContourTerminalDisplay.so()(64bit) needed by > contour-20230226-1.fc39.x86_64 > - nothing provides libcrispy-core.so()(64bit) needed by > contour-20230226-1.fc39.x86_64 > ``` > This looks to be because upstream isn't installing those two shared libraries in their CMake steps, so the RPM isn't including them in its packaged files. The only files it is installing are: + /usr/bin/cmake --install redhat-linux-build -- Install configuration: "RelWithDebInfo" -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/bin/contour -- Set runtime path of "/home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/bin/contour" to "" -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/applications/org.contourterminal.Contour.desktop -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/kservices5/ServiceMenus/org.contourterminal.Contour.RunIn.desktop -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/kservices5/ServiceMenus/org.contourterminal.Contour.OpenHere.desktop -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/icons/hicolor/512x512/apps/org.contourterminal.Contour.png -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/icons/hicolor/256x256/apps/org.contourterminal.Contour.png -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/icons/hicolor/128x128/apps/org.contourterminal.Contour.png -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/icons/hicolor/64x64/apps/org.contourterminal.Contour.png -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/icons/hicolor/32x32/apps/org.contourterminal.Contour.png -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/metainfo/org.contourterminal.Contour.metainfo.xml -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/contour/shell-integration -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/contour/shell-integration/shell-integration.fish -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/contour/shell-integration/shell-integration.tcsh -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/contour/shell-integration/shell-integration.zsh -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/contour/LICENSE.txt -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/contour/README.md -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/terminfo -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/terminfo/c -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/terminfo/c/contour -- Installing: /home/ruby/rpmbuild/BUILDROOT/contour-20230226-1.fc39.x86_64/usr/share/terminfo/c/contour-latest So this is an upstream bug in their build scripts that should be fixed. Once that is fixed, you then need to add the libraries to the %files section of your spec file. -Ian > detailed steps information: > https://gist.github.com/topazus/adc72785c126c513093f5389c117cae7 > ___ > 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: c++ packaging of contour terminal and libunicode
Upstream appears to be disabling position independent code for some reason in the crispy-core library: https://github.com/contour-terminal/contour/blob/master/src/crispy/CMakeLists.txt#L100 (although they are using no-pie, which is odd since it is a library and I would have expected no-pic instead, since pie is for executables not libraries...). Try removing those options from the build and running it again. CMake should automatically pick up the PIC/PIE options from the hardened build flags provided by the RPM build system. -Ian On Mon, Feb 27, 2023 at 6:31 AM Felix Wang wrote: > The detailed information: > https://gist.github.com/topazus/b4bfd63b8cbce70acd4dac02a087d785 > ___ > 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: F39 proposal: Modernize Thread Building Blocks for Fedora 39 (System-Wide Change proposal)
On Wed, Feb 15, 2023 at 6:42 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Fedora is currently shipping version 2020.3 (released July 10, 2020) > of the Thread Building Blocks library. The current upstream version is > 2021.8 (released December 22, 2022). The Fedora community has > expressed [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 > interest] in moving the TBB package to track a more modern version of > the upstream. > > == Owner == > * Name: [[User:trodgers| Thomas Rodgers]] > * Email: trodg...@redhat.com > > > == Detailed Description == > Fedora has shipped with version 2020.3 of the Thread Building Blocks > library since Fedora 33. The > upstream project made a decision to break backward compatibility after > that version was released. > As packages move to match the upstream's changes it becomes more > difficult to defer updating the > Fedora packaging for TBB. The situation is further complicated as > there are currently a majority > of TBB dependent packages which have not been updated to track a new > upstream release, as detailed in this > [https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c1 analysis] on > the tracking issue. > > This proposal aims to provide a way to modernize the TBB packge > version for Fedora while providing stability for those packages which > continue to depend on the older TBB library version. > > It will be possible to install both devel and runtime versions of both > TBB packages, however the devel compat package for version 2020.3 will > require clients to point to a new include path where the legacy > headers will be found. > > == Feedback == > > > == Benefit to Fedora == > > Fedora 39 will include a current version of Thread Building Blocks > (version 2021.8) while continuing to support clients dependent on an > older version of TBB (version 2020.3). Fedora will stay relevant as > far as Thread Building Blocks clients are concerned. > > == Scope == > * Proposal owners: > ** A compat package based on the current 2020.3 version of the > existing TBB package will be created. > ** Evaluate TBB dependent packages to identify those which need to > move to the compat version of the TBB package. An initial analysis > suggests the majority of current TBB clients will need to move to the > compat package. > ** Post a request for rebuilds to fedora-devel > ** Create patches for those packages affected by this change to adjust > their includes to point the compat package's headers as necessary, > work with affected package owners to update package specs to account > for the change. > ** When most packages are done, re-tag all the packages in rawhide. > ** Watch fedora-devel and assist in rebuilding broken TBB clients. > > * Other developers: > ** Those who depend on Thread Building Blocks will have to rebuild > their packages. Feature owners will alleviate some of this work as > indicated above, and will assist those whose packages fail to build in > debugging them. > > * Release engineering: TODO > > * Policies and guidelines: N/A (not needed for this Change) > ** Apart from scope, this is business as usual, so no new policies, no > new guidelines. > > == Upgrade/compatibility impact == > * No manual configuration or data migration needed. > * Some impact on other packages needing code changes to rebuild. > > == How To Test == > * No special hardware is needed. > * Parallel install of the 2020.3 TBB compat packages and the updated > TBB packages and checking that it does not break other packages. > > == User Experience == > * Expected to remain largely the same. > * Developers building third-party software on Fedora may need to > rebuild against the new TBB packages, and may need to adjust their > code to either remain on the compat TBB version or move to the new > version supplied by the updated TBB package. > > == Dependencies == > Packages that must be rebuilt: > & dnf repoquery -s --releasever=rawhide --whatrequires libtbb\* > --enablerepo=fedora | sort -u > > The tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 > issue's] analysis suggests that only the following packages will be > able to move to a newer TBB - > * fawkes > * gazebo > * opencascade > * pmemkv > * root > This change will also allow for mold to unbundle its included TBB version and become dependent on the OS-provided library (that was my original impetus for wanting TBB to be updated in Fedora actually, because modl requires the newer TBB API and so can't build against the older 2020.3 package). -Ian > > While the remaining clients of TBB will need to have their spec's > include paths adjusted to use the 2020.3 compat package. > > == Contingency Plan == > > * Contingency me
Re: Tenacity
On Thu, Feb 9, 2023 at 2:30 PM Scott Talbert wrote: > On Wed, 8 Feb 2023, Brandon Nielsen via devel wrote: > > > On 2/8/23 9:30 PM, Reon Beon via devel wrote: > >> wxGTK should have that... > > > > It should, and they fixed it, but the fix never made it to the 3.1.X > series > > as far as I can tell. 3.2.1 in F37 at least builds, but for some reason > > liblibnyquist.so is missing. F38 / Rawhide has some lisp issue with the > > libnyquist stuff. > > Let me know if you want that bug fixed in F36 wxGTK. Looks like it should > be pretty easy to cherry-pick. > The entire file dialog customization system was added in 3.1.7 right before the 3.2.0 release, so the header file mentioned doesn't exist in 3.1.5, nor any of the core code it needs to actually work. That change is a change to the API of the file dialog methods, so it is IMO not cherry pickable to F36 because it would require cherry-picking this entire PR: https://github.com/wxWidgets/wxWidgets/pull/22476. If upstream tenacity wants to use the file dialog customizations, then they need to update their required versions to be 3.2.0+ only and not claim 3.1.5 compatibility. > > Scott > ___ > 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: Source download behind login?
On Wed, Dec 28, 2022 at 5:42 PM Richard Shaw wrote: > I'm working on updating the opencasecade package[1] but the main downloads > require a login. > > Is there a specific reason it needs to be their premade tarballs? If not, it looks like you should be able to pull the tarball from the tag in their git repo, which appears to be public. The git repo is here: https://git.dev.opencascade.org/gitweb/?p=occt.git The link to pull the tarballs should be something like: "https://git.dev. opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz" (where you can replace the tag as needed with the one for the version required) > I tried moving to a mirror (or what I thought was a mirror) on github but > discovered that the releases are not in sync. > > I guess I could download the source and then reupload to fedorapeople.org > but that seems less than ideal. > > Ideas? > > Thanks, > Richard > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2137719 > ___ > 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: Unannounced SONAME bump: wxGTK
On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw wrote: > I just had a chance to check out a bug[1] recently submitted against > trustedqsl and it appears that a new version of wxGTK with a SONAME bump > was built for f37+ but not all dependencies rebuilt. > > This was announced back in July while F37 was still Rawhide: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PD3EWAYG6HGKSWU5T337AXU4ONSK53VZ/#LYLHTVJQMLOWFFRB25MVM4S4726KPWMR And looking at the commit history for the F37 branch of trustedqsl, it has a commit referencing the wxGTK 3.2 version bump: https://src.fedoraproject.org/rpms/trustedqsl/commits/f37, and that was before the update you did to version 2.6.4. The build for 2.6.4 on F37 ( https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.6.4/1.fc37/data/logs/x86_64/build.log) also seems to have pulled the wxWidgets 3.2 dep correctly, with CMake reporting: Found wxWidgets: -pthread;;;-lwx_gtk3u_core-3.2;-lwx_baseu-3.2;-lwx_gtk3u_html-3.2 (found version "3.2.0") and the RPM dependency generator showing libwx_baseu-3.2.so.0()(64bit) libwx_baseu-3.2.so.0(WXU_3.2)(64bit) libwx_gtk3u_core-3.2.so.0()(64bit) libwx_gtk3u_core-3.2.so.0(WXU_3.2)(64bit) libwx_gtk3u_html-3.2.so.0()(64bit) libwx_gtk3u_html-3.2.so.0(WXU_3.2)(64bit) I am therefore very confused how the user could have 2.6.4 with a 3.1.5 dependency when the koji build for 2.6.4-1 shows wxGTK 3.2 in the buildroot and as a dependency. -Ian I'm not too worried about trustedqsl since I'm about to take care of the > build but it does have a long dependency list and I'm unsure whether the > other builds have been completed: > > 0ad > 4Pane > audacity > boinc-client > CubicSDR > diff-pdf > erlang > extrema > fityk > flamerobin > freedink-dfarc > freedv > fwknop-gui > gnuplot > guayadeque > hugin > iaxclient > kicad > mathgl > mediainfo > mrpt > openbabel > openmsx > OpenSceneGraph > p7zip > panoglview > pcem > phd2 > plplot > poedit > python-wxpython4 > rapidsvn > saga > scorched3d > scummvm-tools > sooperlooper > spatialite-gui > springlobby > trustedqsl > ucblogo > vavoom > visualboyadvance-m > wxmacmolplt > wxsqlite3 > xchm > xmlcopyeditor > xylib > > Thanks, > Richard > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2154622 > ___ > 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: HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates
On Tue, Nov 22, 2022 at 4:14 PM Fabio Valentini wrote: > Hi all, > > I've been collecting data about the dependency graph of Rust packages > in Fedora for over a year now, and I would like to start the process > of removing some accumulated cruft. In particular, I've been keeping > track of which packages for *library* packages (i.e. they ship only > source code but no binaries) have been leaf packages. > > List of Rust library-only packages, which no other package in Fedora > has depended on, for over a year (365 days+): > > - rust-compiletest_rs > - rust-constant_time_eq > - rust-conv > - rust-counted-array > - rust-dbus-tokio > - rust-defmac > - rust-dialoguer > I was just recently thinking of packaging juliaup ( https://github.com/JuliaLang/juliaup), and it has rust-dialoguer as a dependency, so if you can exclude it for now that would be great. -Ian > - rust-enumset > - rust-failure-tools > - rust-fake-simd > - rust-fbthrift_codegen_includer_proc_macro > - rust-fdlimit > - rust-hamcrest2 > - rust-html2pango > - rust-imgref > - rust-ioctl-rs > - rust-lipsum > - rust-listenfd > - rust-loggerv > - rust-lzw > - rust-macro-attr > - rust-mdl > - rust-mktemp > - rust-mnt > - rust-newtype_derive > - rust-odds > - rust-osstrtools > - rust-parse_cfg > - rust-permutate > - rust-piper > - rust-podio > - rust-proc-quote-impl > - rust-process_path > - rust-progress-streams > - rust-protoc-rust > - rust-quickersort > - rust-rand_jitter > - rust-rand_os > - rust-read_input > - rust-relay > - rust-rustc_tools_util > - rust-rustdoc-stripper > - rust-rustfilt > - rust-safe-transmute > - rust-scoped-tls-hkt > - rust-serde-pickle > - rust-serial-core > - rust-sluice > - rust-smallstr > - rust-spinning_top > - rust-spmc > - rust-ssh-key-dir > - rust-stb_truetype > - rust-string_cache_shared > - rust-strings > - rust-sudo_plugin > - rust-sxd-document > - rust-synom > - rust-sysctl > - rust-tabwriter > - rust-take > - rust-timerfd > - rust-tower-test > - rust-tower-util > - rust-ucd-util > - rust-unic-ucd-category > - rust-url_serde > - rust-urlocator > - rust-utf8-ranges > - rust-watchman_client > > Some of these packages are dependencies of things that will be worked > on at some point in the future (for example, packaging of GStreamer > plugins that are written in Rust), but others look very much like > accumulated cruft. > > If you see a package on this list that you would like to keep for some > reason, please speak up, and I will exclude it from future dependency > graph analysis. Otherwise I will soon start retiring packages that > have been unused for over a year. > > The packages that would be in the list above, but which I *know* will > get some use soon, are: > > - rust-curve25519-dalek > - rust-gstreamer-audio > - rust-gstreamer-editing-services > - rust-gstreamer-player > > I will probably start the cleanup process with packages for crates > that no longer have any dependent crates listed on the crates.io > registry (which is a good indicator that they are indeed obsolete), > and then continue with crates for which the longest amount of time has > passed since the last upstream release (which is "more than 5 years > ago" for some crates ...). > > Fabio > ___ > 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: CVE Tracking Bugs
On Wed, Sep 7, 2022 at 7:45 PM Ben Cotton wrote: > On Wed, Sep 7, 2022 at 2:05 PM Maxwell G via devel > wrote: > > > > Does anyone know how to reach prodsec about this? > > I'll reach out to the people I know and see what the best way to get > them in this conversation is. > > Has this conversation been started yet? Because the CVE reporting system doesn't seem to have been improved at all - in fact a recent CVE bug ( https://bugzilla.redhat.com/show_bug.cgi?id=2141029) was filed, had over 179 people added to the CC list, and there is no mention at all of which applications were identified as being affected or any other tracking bugs filed for those affected applications. So as a maintainer, I am then unsure why I was CC'd on the bug and which application prod sec wants me to examine for the vulnerability (especially since to my knowledge, none of the packages I maintain even use electron in any way or have its code contained inside of them). -Ian > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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: Silent changes in Packaging Guidelines
On Thu, Nov 3, 2022 at 12:02 PM Michael J Gruber wrote: > While it is annoying to spell out each file it does catch package changes > which might go unnoticed otherwise. In particular, we've had a few > unannounced soname changes and such lately. [Disclaimer: I have not checked > whether the maintainer ignored the build failure for an explicit soname or > got trapped by a wildcard in these cases.] > But the packaging guidelines already mentioned not globbing the soname part of the files, so this change makes no difference to that use case. Extending the no-globbing rule to other directories like datadir seems very excessive. Why should we have to list all files a package wants to ship as its data? -Ian > > We could probably live better with wildcards if proper rpmdiff-tools were > part of the workflow and of gating or such. Those would be the right tool > for the job. > ___ > 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: Bump f38 .so for libid3tag
On Wed, Aug 31, 2022 at 3:07 PM Leigh Scott wrote: > Switching upstream has increased the .so version from libid3tag.so.0 to > libid3tag.so.0.16.2 > I plan to do the rebuilds myself after checking everything builds ok in > copr. > > > Affected packages > > Fedora: > audacity-0:3.1.3-5.fc37.x86_64 Audacity will FTBFS right now because there was an update to the lv2 package that broke some old include directory paths (upstream did this in a patch release apparently) and I haven't had a chance to sit down and make a full patch for the new include paths. -Ian > easytag-0:2.4.3-16.fc37.x86_64 > gtkpod-0:2.1.5-21.fc37.x86_64 > imlib2-id3tag-loader-0:1.7.4-3.fc37.x86_64 > mp3fs-0:1.1.1-4.fc37.x86_64 > sonic-visualiser-0:4.5-2.fc37.x86_64 > sox-0:14.4.2.0-33.fc37.x86_64 > > Rpmfusion: > audacity-freeworld-0:3.1.3-4.fc37.x86_64 > libmp3splt-0:0.9.2-13.fc37.x86_64 > minidlna-0:1.3.0-8.fc37.x86_64 > mixxx-0:2.3.3-2.fc37.x86_64 > moc-0:2.6-0.46.svn3005.fc37.x86_64 > mpd-1:0.23.9-1.fc37.x86_64 > vdr-mp3-0:0.10.4-6.fc37.x86_64 > ___ > 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: Inactive packagers to be removed after the F37 release
On Fri, Aug 19, 2022 at 1:08 PM Ben Cotton wrote: > On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper > wrote: > > > > I like this policy, but it strikes me as odd that the packagers' email > > addresses are posted publicly on the Pagure tickets... Wouldn't that > > make it easier for spammers to get more email addresses? > > The script has a flag I can use in the future which (I believe) will > mask the addresses in the tickets. I didn't use it this time because > email addresses are already displayed all over the place. If a spammer > gets an email address from these tickets that they didn't have before, > then I'll be very surprised. > I really wish people would stop making the argument that just because other places/systems have terrible data hygiene, we can have terrible data hygiene too. Fedora should be trying to set the example of how to interact and behave, and the "follow the herd" mentality here is not acceptable in my opinion. Email address could be considered PII, and so there is a debate about when the GDPR-type regulations would apply to them (from what I read, it would apply for work email addresses giving full names or personal email addresses). While there is a legal basis for keeping the email address in the system and using it, I fail to see a legal basis that would allow publicly displaying an email address in this way. Many systems are also trying to reduce the exposure of personal email addresses, with major git hosting providers even creating anonymous commit emails that can be associated with user accounts on those systems and then used for your commits should you choose. So in short, I strongly argue for masking/removing the email address from all tickets like this, and the fact that they are displayed there was is so concerning to me that I opened a ticket about it last night: https://pagure.io/find-inactive-packagers/issue/619. -Ian > > That said, if there's a general consensus that addresses should be > masked in the ticket, then we can do that in the future. I considered > whether the tickets should default to private, but the downside is > that people wouldn't be able to log in and comment on the ticket via > the Pagure web interface, only by email. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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: Review request: sfsexp - Small Fast S-Expression Library
I'll take it and review it. I don't have any ones to swap currently. -Ian On Fri, Jun 10, 2022 at 12:09 PM Michael J Gruber wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=2095717 > > This is an optional dependency of notmuch, the mail indexer. sfsexp > enhances notmuch's capabilities considerably. > > Feel free to suggest a review swap within my capabilities (say C/Python). > > Cheers > 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 on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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
Update for fedora-obsolete-packages
There hasn't been an update to the fedora-obsolete-packages package after the upgrade testing that was done last month in preparation for the release of F36. There are currently 3 open bugs that are targetted against F36 [1, 2, 3]. Since we are entering the final freeze this week, can someone make an update to the package so these are properly obsoleted for F36 upgrades? [1] https://bugzilla.redhat.com/show_bug.cgi?id=2068936 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2050836 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2063412 ___ 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: Donate 1 minute of your time to test upgrades from F35 to F36
On Sat, Mar 12, 2022 at 3:20 PM Miroslav Suchý wrote: > Dne 12. 03. 22 v 15:15 José Abílio Matos napsal(a): > > On Saturday, 12 March 2022 11.23.11 WET José Abílio Matos wrote: > > > Error: > > > Problem: package julia-1.7.0.0-1.fc36.x86_64 requires > > > libmbedcrypto.so.3()(64bit), but none of the providers can be installed - > > > package julia-1.7.0.0-1.fc36.x86_64 requires libmbedtls.so.12()(64bit), > but > > > none of the providers can be installed - package > julia-1.7.0.0-1.fc36.x86_64 > > > requires libmbedx509.so.0()(64bit), but none of the providers can be > > > installed - problem with installed package julia-1.7.2-1.fc35.x86_64 > > > - mbedtls-2.16.12-1.fc35.x86_64 does not belong to a distupgrade > repository > > > - julia-1.7.2-1.fc35.x86_64 does not belong to a distupgrade repository > > Replying to myself julia 1.7.2 is not available in Fedora 36+ only in > Fedora 35. > > This is an excelent example of package and issue which should be reported > to > > https://src.fedoraproject.org/rpms/fedora-obsolete-packages/ > > Can you please report it there? > Why are you suggesting reporting it to fedora-obsolete-packages? The Julia package is not obsolete, and the maintainers are acutely aware of the install problem and are tracking it in the appropriate FTBFS/FTI bugzilla entries (https://bugzilla.redhat.com/show_bug.cgi?id=2045732, https://bugzilla.redhat.com/show_bug.cgi?id=2044284), but they need upstream input on the fixes in order to get it working. Considering this an obsolete package just because it has this install error right now is in my opinion very short-sighted. -Ian > Miroslav > ___ > 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 > ___ 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
Questions about new free-only FFMPEG in Fedora repos
I noticed in the electron thread that we now have FFMPEG 5.0 in the official Fedora repos, but this will of course mean that certain codecs are removed due to legal concerns. This prompts a few questions though: 1) How are these removed codecs handled in the library? Can we link an upstream application against FFMPEG in Fedora now and have it gracefully fail when it tries to access a non-free codec that was removed, or does the removal of these codecs create a different API that upstream applications would have to code around? e.g. does it mean they have to add conditional compilation for the specific codecs they need to use from FFMPEG instead of just around FFMPEG itself? 2) Is there an easily accessible list of the enabled codecs we can point upstreams to when talking about this? Thanks, -Ian ___ 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: Preventing account takeovers through expired domains
On Tue, Feb 22, 2022 at 2:15 AM Demi Marie Obenour wrote: > On 2/21/22 14:16, Vitaly Zaitsev via devel wrote: > > On 21/02/2022 19:25, Demi Marie Obenour wrote: > >> FIDO keys are significantly more secure than OTPs, and FAS should get > >> support for them. OTPs are still phishable, whereas FIDO2 generally > >> isn’t. > > > > OTP is absolutely free. FIDO2 requires the purchase of a special > > hardware token. > > One must remember that anyone in the packagers group can (with a > modicum of effort) get code execution on a huge number of machines, > and is thus an incredibly attractive target for phishing attacks. > Developing a roadmap to encourage, and eventually require, the use of > hardware authenticators to submit packages is a reasonable precaution > in this threat environment. A hardware authenticator could be a FIDO2 > token, smart card, etc. > While it may make sense from the security standpoint, we also need to factor in the community/economic factor for Fedora contributors. Requiring the use of a hardware key then means that contributors have to spend their money to buy such a key, adding an additional hurdle for them to go through. Having to get the hardware key may also be prohibitive for contributors coming from developing countries, or who are low-income/unemployed, where they may already have a computer to use, but the added cost of a new hardware key could be a large burden. The only viable option I see for requiring the use of hardware keys would be if RedHat (or another sponsor) provided them to packagers when needed. This is probably prohibitive to do for the entire packager group, so instead it would make more sense to focus on the group that would expose the largest amount of the distribution - the proven packager group. This set of packagers is a smaller group, and they would have shown a dedication to the community/Fedora in the past to be approved by FESCO. It would probably be easier to convince Redhat/the Fedora Council to sponsor hardware keys for that core group than the community at large should the decision to require them be made. -Ian > > -- > Sincerely, > Demi Marie Obenour > (she/her/hers)___ > 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 > ___ 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: Do we have any policy for disabling inactive users
On Fri, Feb 11, 2022 at 10:39 AM Björn Persson wrote: > Gary Buhrmaster wrote: > > A quick (and likely > > bad and incomplete) bugzilla search shows > > over 1000 tickets where there are upstream > > updates that are still in NEW status in > > bugzilla and had been (initially) opened > > over a year ago. I think that represents > > around 350 unique people. Those people > > may be otherwise active, of course, but > > those packages themselves look to be > > under maintained. > > Yes, that's a bad search. Till Maas told me eight years ago that the > release monitoring tickets are supposed to remain open when the > packages are upgraded. Thus an open Bugzilla ticket is no indication > that the package is unmaintained. You need to check what version is > actually in Rawhide. > > If the Bugzilla tickets should in fact not be left open, then they > should be automatically closed just like they're automatically opened. > I was under the impression these tickets should be handled like any other BZ tickets: you add them to the update in Bodhi when you create it, and then Bodhi will update them and autoclose them once the new version has been pushed to the stable repo. -Ian > > Björn Persson > ___ > 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 > ___ 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: emacs uninstallable in Rawhide at the moment
On Fri, Feb 4, 2022 at 12:21 PM Richard W.M. Jones wrote: > https://koji.fedoraproject.org/koji/taskinfo?taskID=82370784 > > DEBUG util.py:444: Problem: package emacs-1:27.2-9.fc35.x86_64 requires > libwebkit2gtk-4.0.so.37()(64bit), but none of the providers can be installed > DEBUG util.py:444:- conflicting requests > DEBUG util.py:444:- nothing provides gstreamer1-plugins-bad-freeworld > needed by webkit2gtk3-2.35.2-2.fc36.x86_64 > > There is already a BZ against webkit2gtk3 about this: https://bugzilla.redhat.com/show_bug.cgi?id=2050480. It also broke the Rawhide compose yesterday apparently, so hopefully it will get sorted today. -Ian > Having said that, why on earth is ocaml-dune (a command line build > tool) depending on emacs?! There's an emacs subpackage, but maybe > emacs-nox would be a better BR for that. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: Installing from updates-testing not working?
On Thu, Feb 3, 2022 at 7:41 PM Kevin Fenzi wrote: > On Thu, Feb 03, 2022 at 06:38:11PM +0000, Ian McInerney via devel wrote: > > > > I guess it was a mirror caching issue. I tried again just now and it > picked > > up the update just fine. I didn't think the updates-testing repo was > > mirrored though, but it is very annoying that the mirror sync and the > push > > to updates-testing apparently aren't synchronized, leading to a large lag > > there. > > yes, updates-testing is mirrored just like updates. > > Sadly there's not too much we can do about the sync time, since mirrors > are free to sync as ofter or inoften as they like. ;( > > It's possible that updates-testing doesn't get that much traffic these > days and we could look at un-mirroring it somehow. Everyone seems pretty > used to it by now however and you can get the updates from koji or from > bodhi directly too. > > kevin > >From a user experience perspective, the mirror lag time on it is very annoying. When the update is pushed to testing, Bodhi posts a comment in the associated Bugzilla saying that you should "soon" be able to install the update using the relevant DNF command. In my opinion, having to wait 18 hours before that command works (and continually having to try that command throughout the day to see when it will start working) is very annoying from the perspective of someone who wants to test the fix to a bug they are affected by/reported. Can we figure out how much traffic updates-testing is actually getting currently to see if it can be unmirrored? In my mind, it would seem that the fact updates live inside updates-testing for a very short time (on the timescale of days) before being moved to normal updates, and the fact it is not enabled by default, would make me think it is probably low traffic in comparison. Alternately, is there an option in DNF to automatically use the mirror that was updated most recently, even if it isn't the fastest/geographically closest? -Ian > ___ > 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 > ___ 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
Unannounced soname bump: liborcus
It appears that liborcus had an soname bump yesterday from 0.16 to 0.17, and the dependent packages were not rebuilt at the time. This seems to affect only LibreOffice, but makes it non-installable in Rawhide. Can someone rebuild it for the new library version? Thanks, -Ian ___ 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: Installing from updates-testing not working?
On Thu, Feb 3, 2022 at 1:15 PM Petr Pisar wrote: > V Thu, Feb 03, 2022 at 12:13:11PM +0000, Ian McInerney via devel napsal(a): > > I am trying to install a bodhi update that was pushed to testing last > night > > (https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e), and I > am > > using the DNF line it gives me but seeing this string instead: > > > > $ sudo dnf upgrade --enablerepo=updates-testing > > --advisory=FEDORA-2022-20f36a8b0e > > Last metadata expiration check: 0:01:49 ago on Thu 03 Feb 2022 12:07:31 > GMT. > > No security updates needed, but 642 updates available > > Dependencies resolved. > > Nothing to do. > > Complete! > > > > In previous times I installed from updates-testing it has worked and > never > > said there were no security updates available. Why is DNF refusing to > > install it this time? > > > It works for me. Isn't your mirror stalled? Check Repo-updated time stamp > in: > > # dnf repolist --repo=updates-testing -v > Loaded plugins: builddep, changelog, config-manager, copr, debug, > debuginfo-install, download, generate_completion_cache, groups-manager, > needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, > reposync > DNF version: 4.9.0 > cachedir: /var/cache/dnf > Last metadata expiration check: 0:02:06 ago on Thu 03 Feb 2022 02:11:08 PM > CET. > Repo-id: updates-testing > Repo-name : Fedora 35 - x86_64 - Test Updates > Repo-revision : 1643848757 > Repo-updated : Thu 03 Feb 2022 02:13:00 AM CET > Repo-pkgs : 12,484 > Repo-available-pkgs: 12,484 > Repo-size : 19 G > Repo-metalink : > https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f35&arch=x86_64 > Updated : Thu 03 Feb 2022 02:11:08 PM CET > Repo-baseurl : rsync:// > ftp.fi.muni.cz/pub/linux/fedora/linux/updates/testing/35/Everything/x86_64/ > (54 more) > Repo-expire: 21,600 second(s) (last: Thu 03 Feb 2022 02:11:08 PM > CET) > Repo-filename : /etc/yum.repos.d/fedora-updates-testing.repo > Total packages: 12,484 > > -- Petr > I guess it was a mirror caching issue. I tried again just now and it picked up the update just fine. I didn't think the updates-testing repo was mirrored though, but it is very annoying that the mirror sync and the push to updates-testing apparently aren't synchronized, leading to a large lag there. -Ian ___ 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
Installing from updates-testing not working?
I am trying to install a bodhi update that was pushed to testing last night (https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e), and I am using the DNF line it gives me but seeing this string instead: $ sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-20f36a8b0e Last metadata expiration check: 0:01:49 ago on Thu 03 Feb 2022 12:07:31 GMT. No security updates needed, but 642 updates available Dependencies resolved. Nothing to do. Complete! In previous times I installed from updates-testing it has worked and never said there were no security updates available. Why is DNF refusing to install it this time? Thanks, -Ian ___ 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: Heads-up: lxqt libraries soname bump
On Tue, Dec 28, 2021 at 11:37 AM Ian McInerney wrote: > On Mon, Dec 27, 2021 at 10:39 AM Zamir SUN wrote: > >> Hi, >> >> I'm updating the whole LXQt desktop to 1.0.0 in rawhide, and I've built >> the packages in the side tag f36-build-side-49104. > > > Did you run the build for lxqt-wallet? I see that there is a commit in > distgit that bumps the version to 1.0.0, but I can't find an associated > build in Koji for that version. I actually think that commit to lxqt-wallet > needs to be reverted though, and instead just a rebuild for lxqt-wallet is > needed. The upstream release still has version 3.2.2 as its most recent > version (which is the current version we package), and does not appear to > follow the standard lxqt release schedule/versioning system. > > I have reverted this commit in rawhide now, so lxqt-wallet is back to version 3.2.2. -Ian > -Ian > > >> The following package >> contains library with a soname bump >> >> liblxqt (liblxqt.so.1) >> liblxqt-globalkeys (liblxqt-globalkeys.so.1,liblxqt-globalkeys-ui.so.1) >> > >> I hope I did not miss anything. IIRC there are no packages outside of >> the LXQt SIG depends on those, but I'd like to still make people aware >> of the change and possible other packages I missed. >> > >> I'll merge the side tag by the last day of the year. >> >> HTH. >> >> -- >> Zamir SUN >> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E >> Want to know more about Fedora? >> Visit https://fedoraproject.org/wiki/ >> Ready to contribute? See https://whatcanidoforfedora.org/ >> 想了解更多中文资讯，访问 https://zh.fedoracommunity.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 >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > ___ 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: Heads-up: lxqt libraries soname bump
Apparently there were soname bumps in other lxqt packages that were updated other than just those two. The qtermwidget package appears to have had an soname bump from libqtermwidget5.so.0 to libqtermwidget5.so.1, breaking at least TexStudio in Rawhide. I did a build for it, and it has been pushed to rawhide now. I suggest that you modify every lxqt spec file to not glob the soname version for their exported libraries in the files section and instead have the version defined in the spec file as a global. That would fail then build when an soname bump occurs and the packager isn't aware of it, preventing these types of unannounced bump problems in the future when updating a lot of packages at once. -Ian On Mon, Dec 27, 2021 at 10:39 AM Zamir SUN wrote: > Hi, > > I'm updating the whole LXQt desktop to 1.0.0 in rawhide, and I've built > the packages in the side tag f36-build-side-49104. The following package > contains library with a soname bump > > liblxqt (liblxqt.so.1) > liblxqt-globalkeys (liblxqt-globalkeys.so.1,liblxqt-globalkeys-ui.so.1) > > I hope I did not miss anything. IIRC there are no packages outside of > the LXQt SIG depends on those, but I'd like to still make people aware > of the change and possible other packages I missed. > > I'll merge the side tag by the last day of the year. > > HTH. > > -- > Zamir SUN > GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E > Want to know more about Fedora? > Visit https://fedoraproject.org/wiki/ > Ready to contribute? See https://whatcanidoforfedora.org/ > 想了解更多中文资讯，访问 https://zh.fedoracommunity.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: Rawhide builds failing for a while now
On Tue, Dec 28, 2021 at 3:47 PM Justin Forbes wrote: > On Tue, Dec 28, 2021 at 9:29 AM Ian McInerney via devel > wrote: > > > > On Tue, Dec 28, 2021 at 3:19 PM Justin Forbes > wrote: > >> > >> On Mon, Dec 27, 2021 at 3:36 PM Kevin Fenzi wrote: > >> > > >> > On Mon, Dec 27, 2021 at 05:34:52AM -, Reon Beon via devel wrote: > >> > > What exactly is wrong? > >> > > > >> > > https://koji.fedoraproject.org/koji/builds?state=3&order=-build_id > >> > > >> > Well, thats the list of all failed builds in koji. There's various > >> > different reasons for each of them to have failed... > >> > > >> > >> kernel/kernel-tools/kernel-headers have been falling for about 5 days > >> now on x86 "unable to init mock buildroot" with: > >> > >> useradd warning: dbus's uid 81 outside of the SYS_UID_MIN 201 and > >> SYS_UID_MAX 999 range. > > > > > > This one shouldn't be fatal at least. I saw it in mock builds a while > ago and opened a bugzilla about it back then ( > https://bugzilla.redhat.com/show_bug.cgi?id=2028673). > > > > It seems to be, That is the only failure I see in the root.log, and > the builds fail with FAILED: BuildrootError: could not init mock > buildroot, mock exited with status 30; see root.log for more > information > > DEBUG util.py:446: Failed: > DEBUG util.py:444:authselect-libs-1.3.0-4.fc36.x86_64 > Error: Transaction failed > DEBUG util.py:598: Child return code was: 1 > > Justin > That is a different error during the transaction. The original warning I mentioned is in dbus-broker, and is only a warning (the RPM transaction continues with no error). The other two you have are in the authselect-libs package, and they appear to be caused by the change to using lua for the pre scriplets in https://src.fedoraproject.org/rpms/authselect/c/00f6a084f99e2a9ee9ceaaad3d4896e4bfc591dd?branch=rawhide. It is probably best to open a BZ against the authselect component with those errors. -Ian > > > -Ian > > > >> > >> > >> error: lua script failed: [string > >> "%prein(authselect-libs-1.3.0-4.fc36.x86_64)"]:8: field 'open' is not > >> callable (a nil value) > >> > >> Error in PREIN scriptlet in rpm package authselect-libs > >> error: authselect-libs-1.3.0-4.fc36.x86_64: install failed > >> > >> Justin > >> > >> > For example, the kf* ones at the top right now are due to a missing > >> > kaccounts-integration-devel of the needed version. > >> > > >> > You have to look at each build and drill down to whatever error it hit > >> > that caused it to fail. > >> > > >> > If you mean the rawhide composes that are failing thats due to two > bugs: > >> > https://bugzilla.redhat.com/show_bug.cgi?id=2034715 > >> > (anaconda dies with a traceback on 32bit arm) > >> > > >> > and > >> > > >> > https://bugzilla.redhat.com/show_bug.cgi?id=2035812 > >> > (systemd-journald fails to start on 32bit arm). > >> > > >> > I've untagged some packages and am running another compose right now > to > >> > see if that gets things going. > >> > > >> > kevin > >> > ___ > >> > 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 > >> ___ > >> 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: Rawhide builds failing for a while now
On Tue, Dec 28, 2021 at 3:19 PM Justin Forbes wrote: > On Mon, Dec 27, 2021 at 3:36 PM Kevin Fenzi wrote: > > > > On Mon, Dec 27, 2021 at 05:34:52AM -, Reon Beon via devel wrote: > > > What exactly is wrong? > > > > > > https://koji.fedoraproject.org/koji/builds?state=3&order=-build_id > > > > Well, thats the list of all failed builds in koji. There's various > > different reasons for each of them to have failed... > > > > kernel/kernel-tools/kernel-headers have been falling for about 5 days > now on x86 "unable to init mock buildroot" with: > > useradd warning: dbus's uid 81 outside of the SYS_UID_MIN 201 and > SYS_UID_MAX 999 range. > This one shouldn't be fatal at least. I saw it in mock builds a while ago and opened a bugzilla about it back then ( https://bugzilla.redhat.com/show_bug.cgi?id=2028673). -Ian > > error: lua script failed: [string > "%prein(authselect-libs-1.3.0-4.fc36.x86_64)"]:8: field 'open' is not > callable (a nil value) > > Error in PREIN scriptlet in rpm package authselect-libs > error: authselect-libs-1.3.0-4.fc36.x86_64: install failed > > Justin > > > For example, the kf* ones at the top right now are due to a missing > > kaccounts-integration-devel of the needed version. > > > > You have to look at each build and drill down to whatever error it hit > > that caused it to fail. > > > > If you mean the rawhide composes that are failing thats due to two bugs: > > https://bugzilla.redhat.com/show_bug.cgi?id=2034715 > > (anaconda dies with a traceback on 32bit arm) > > > > and > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2035812 > > (systemd-journald fails to start on 32bit arm). > > > > I've untagged some packages and am running another compose right now to > > see if that gets things going. > > > > kevin > > ___ > > 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 > ___ > 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 > ___ 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: Heads-up: lxqt libraries soname bump
On Mon, Dec 27, 2021 at 10:39 AM Zamir SUN wrote: > Hi, > > I'm updating the whole LXQt desktop to 1.0.0 in rawhide, and I've built > the packages in the side tag f36-build-side-49104. Did you run the build for lxqt-wallet? I see that there is a commit in distgit that bumps the version to 1.0.0, but I can't find an associated build in Koji for that version. I actually think that commit to lxqt-wallet needs to be reverted though, and instead just a rebuild for lxqt-wallet is needed. The upstream release still has version 3.2.2 as its most recent version (which is the current version we package), and does not appear to follow the standard lxqt release schedule/versioning system. -Ian > The following package > contains library with a soname bump > > liblxqt (liblxqt.so.1) > liblxqt-globalkeys (liblxqt-globalkeys.so.1,liblxqt-globalkeys-ui.so.1) > > I hope I did not miss anything. IIRC there are no packages outside of > the LXQt SIG depends on those, but I'd like to still make people aware > of the change and possible other packages I missed. > > I'll merge the side tag by the last day of the year. > > HTH. > > -- > Zamir SUN > GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E > Want to know more about Fedora? > Visit https://fedoraproject.org/wiki/ > Ready to contribute? See https://whatcanidoforfedora.org/ > 想了解更多中文资讯，访问 https://zh.fedoracommunity.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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: License correction: wlcs is “GPLv3”, not “GPLv2 or GPLv3”
On Tue, Nov 2, 2021 at 9:06 PM Tomasz Torcz wrote: > On Tue, Nov 02, 2021 at 03:26:52PM -0400, Ben Beasley wrote: > > The License field of wlcs has been corrected from “GPLv2 or GPLv3” to > > “GPLv3”. > > https://github.com/MirServer/wlcs (is this the right repo?) contains > both COPYING.GPL2 and COPYING.GPL3. How did you determine correct > license? > > I am guessing based on the actual license listed in the source files. Looking through some of them (such as https://github.com/MirServer/wlcs/blob/master/src/primary_selection.cpp), some only list GPLv3 while others list GPLv3 or GPLv2 - so the files that are only licensed under GPLv3 means it should be GPLv3 only. -Ian ___ 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: Considering ExcludeArch: %{ix86} for webkit2gtk3 (and now also ExcludeArch: %{arm}
Ideally, I think the %cmake macro should only add new cmake-specific flags that are needed and not add any other ones not defined by the base distribution to the build. None of these feel like cmake-specific flags to me, because -DNDEBUG is applicable to all build chains, and the others are in %optflags already: $ rpm --eval %optflags -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection So is there a reason for these to be added by the %cmake macro? -Ian On Tue, Oct 26, 2021 at 3:27 PM Michael Catanzaro wrote: > On Tue, Oct 26 2021 at 09:06:37 AM -0500, Michael Catanzaro > wrote: > > And that means we should not need ExcludeArch after all. Pretty sure > > I can make it build now that we understand what went wrong. Happy > > ending? Probably, let's see > > CC: Björn. I wonder if you expected cmake to propagate these flags > into packages that it builds? It's not clear whether you expected them > to be used only for the build of cmake itself, or whether you expected > them to be set for all package builds that use cmake. > > I'm a little surprised, because this change seems to be mostly > redundant with %optflags, yes? -O2 and -g are now being passed twice > during the build, since the existing CMake macros already respect > %optflags. Only -DNDEBUG is really new. I imagine this could cause > unexpected changes in other packages too. > > 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 on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: F36 Change: Retire the NIS(+) user-space utility programs (System-Wide Change proposal)
On Thu, Oct 21, 2021 at 9:38 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/retire_NIS_user_space_utils
>
>
> == Summary ==
>
> This change is about retiring the ypbind, yp-tools, and ypserv
> packages, and removal of the {nis,yp}domainname user-space utility
> programs from the hostname package.
>
>
> == Owner ==
>
> * Name: [[User:besser82 | Björn Esser]]
> * Email: besse...@fedoraproject.org
>
>
> == Detailed Description ==
> Those utility programs used to be present on virtually any UNIX system
> for decades, but are starting to become more and more deprecated.
> Also NIS(+) is known for not being secure at all. As we are going to
> [https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM
> remove the support for NIS(+) in PAM] during this development cycle,
> we also should get rid of those.
>
>
> == Feedback ==
> There was some discussion on
> [
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/T662DD2FD3YNPTVTOPCYFQRSOQCJWCSZ/
> the fedora-devel mailing-list]. Some people are reluctant about the
> removal of NIS(+) user-space support, while most are okay with it as
> there are more secure alternatives (LDAP, FreeIPA, etc.) available.
> The FPL is +1 on doing so.
>
>
> == Benefit to Fedora ==
> With this change we start directing our users and developers to move
> away from NIS(+) to secure alternatives like LDAP and/or FreeIPA.
>
>
> == Scope ==
> * Proposal owners:
> ** Retire the ypbind, yp-tools, and ypserv packages from Fedora.
>
Have you talked with the maintainers of these packages at all? I can't
recall if any of them replied in the RFC thread before, but it would be (in
my opinion) very bad form to retire a package without asking for the
maintainer's input and opinions.
(It might even be good to get one of/some of the maintainers as change
owners on this proposal as well to show they are involved in this).
-Ian
> ** Remove the {nis,yp}domainname user-space utility programs from the
> hostname package.
> * Other developers:
> ** Test this change.
> * Release engineering: [https://pagure.io/releng/issue/10352 #10352]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A
>
>
> == Upgrade/compatibility impact ==
> Users that were relying on support for NIS(+) will need to move to
> secure alternatives like LDAP and/or FreeIPA.
>
>
> == How To Test ==
> Check whether the named utility programs are still installed on your
> system after upgrading. If they are gone, everything is fine.
>
>
> == User Experience ==
> For some users this change may be a bit disruptive and it may require
> some learning curve for switching to alternative solutions.
>
>
> == Dependencies ==
> There are actually no external dependencies.
>
>
> == Contingency Plan ==
> * Contingency mechanism: Unretire the packages and build them for Fedora
> 36.
> * Contingency deadline: At beta freeze.
> * Blocks release? Yes.
>
>
> == Documentation ==
> The documentation about those utility programs should be dropped, if
> there even is any.
>
>
> == Release Notes ==
> The NIS(+) user-space utility programs have been removed from the
> distribution.
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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
>
___
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: leap from f22 to f34 fairytale
I think if you jump more than 2 versions at a time the packages obsoleted by fedora-obsolete-packages might not be picked up properly because it only holds packages for about 2 versions before they are removed from it. So jumping from F26 to F33 directly might miss the obsoletes from F27-F31ish. -Ian On Mon, Oct 11, 2021 at 1:49 PM JT wrote: > Nice. I did an update from F26-F33 last year doing one version at time > instead of jumping more than one version... and had no major issues. I > wonder how far back its possible to start from and walk through the version > updates. > > On Mon, Oct 11, 2021 at 3:55 AM Jiri Vanek wrote: > >> Hello good people! >> >> I would like to thanx to everybody for amazing work in fedora, for >> keeping it alive, and updatable. >> >> In friday I had found an old laptop running f22 and decided to try a leap >> update to f34. It was not just default inntall, there was vlc and much >> more "unknown" comonents. >> Well, transaction failed on python stack, but no surprise here (f31 ahd >> python2->python3?). >> So random bisetct, leap update to f27. Needed --nogpgcheck[1]. Wou. >> Transaction passed. Update passed, and system started and was alive. >> Although the system was behaving terribly (there were experiemtnal patches >> in graphic drivers and also >> gnomeshell was weird, not speaking about wayalnd), it was stable enough >> to make another huge leap. F27->f31 faile dagain on pythn stack, but only >> because of four packages. >> f27->f30 passed again. UNluckily --nogpg check was no longer transferable >> from download to reboot+update. But gpgcheck=1 in active repos fixed it.[1] >> in and in the morning a running shining smooth quick and super stbale >> system was there. >> f30-> f34 died again on python stack.. (yah, dnf and freinds should stop >> using that or keep embedded interpreter) >> f30->31 passed again to even more shining and more working system. >> f31->f33 (yup, that was typo, but found it to late in trasnaction) passed >> again withot issues. >> >> Thanx a lot! II was never expecting such leaps would work so smoothly! >> >>J. >> >> >> [1] https was a culprint herem causing the keys impossible to downlaod. >> in f31, gpgcheck could be enabled again. >> -- >> Jiri Vanek Mgr. >> Principal QA Software Engineer >> Red Hat Inc. >> +420 775 39 01 09 >> ___ >> 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 >> > ___ > 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 > ___ 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: f35-backgrounds ready for review
On Fri, Aug 27, 2021 at 9:12 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Thu, Aug 26, 2021 at 11:38:12AM -0400, Link Dupont wrote: > > On Thu, Aug 26 2021 at 03:12:24 PM +, Zbigniew > > Jędrzejewski-Szmek wrote: > > >True. But those subpackages could just be built from one source > > >package: > > > > > >fedora-backgrounds/f34 => builds all subpackages in the range 21..34 > > >fedora-backgrounds/f35 => builds all subpackages in the range 21..35 > > > > Assuming this range notation is a half-open interval > > Closed on both sides, I think. But we actually have backgrounds for > earlier releases too, see below. > > > , yes, I like > > this idea. Then each subsequent release could take the wallpapers > > from its predecessor and create a new subpackage named with the > > previous version. > > I think it'd look like this (e.g. f35 branch): > > ... > %package -n beefy-miracle-backgrounds > Summary: Backgrounds for f17 > ... > %package -n f21-backgrounds > Summary: Backgrounds for f21 > ... > %package -n f35-backgrounds > Summary: Backgrounds for f35 > Provides: fedora-backgrounds# only when f35 is the latest > > and then for f36 this would be extended with: > > %package -n f36-backgrounds > Summary: Backgrounds for f36 > Provides: fedora-backgrounds# moved here when f36 becomes the latest > > Currently, the spec file has subpackages for each desktop environment though (e.g. f35-backgrounds-gnome, f35-backgrounds-kde, etc.) since they have to be installed in different places for each background. How would we handle that in this type of spec file organization? -Ian > > Would that get unwieldy as the spec file grows? Is > > there an opportunity for macros to make this more sustainable? > > I don't think it'd be much of a problem even in long form, because > we'd essentially get a bunch of new lines once for each release… > But yeah, some macro magic would probably make this nicer. > > 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 on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: karma question
On Wed, Aug 25, 2021 at 11:00 AM Felix Schwarz wrote: > > Am 24.08.21 um 22:47 schrieb Steven A. Falco: > > Should I edit the criteria in f33 so I can mark it stable before the 7 > days > > elapse, or should I let it wait? It seems weird that one release would > have to > > wait longer than the other releases when the fix is identical for all of > them. > > Also I'd even prefer F33 getting the update a bit later: > I assume F33 users are valuing stability over "latest versions and fixes" > (otherwise they would have upgraded to F34 already). On the other hand the > bug > is probably not too bad (otherwise the bug would have been fixed earlier > or > users would have stopped using the package altogether). > > So as a F33 user I'd prefer only getting "rock solid" fixes over newer > stuff > which might introduce regressions. > > just a personal opinion though :-) > > Felix > That isn't what happened in this case though. One of the libraries it depended on was updated, which changed the patch version in the soname (there used to be no soname versioning for that library until now, when they introduced the versioning system). The library loader inside KiCad was searching for the exact soname because of the way the loader works (load the library explicitly and then find the function pointers), but because the soname it was built with didn't exist anymore, it couldn't find it. This led to an error on launching one part of the program, making that part stop working when it was working before the library update. All that was needed to fix this was a rebuild of the package to pick up the new soname - no patches required. -Ian ___ 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: OpenColorIO 2.0: armv7hf only linker error
On Mon, Aug 23, 2021 at 4:13 PM Ben Beasley wrote: > The same specialization of ProcessorCache: > >template class ProcessorCache; > > is explicitly instantiated in two different translation units: > > src/OpenColorIO/Processor.cpp > src/OpenColorIO/Config.cpp > > which violates the C++ standard (an explicit instantiation definition > shall appear at most once in a program). > > Since you are compiling with C++11 (vs. C++98), you can change the line > in Config.cpp to > >extern template class ProcessorCache; > > and it should be fine (in theory, I haven’t run a scratch build). > > - > > Side note: while CMake build systems tend to hard-code a C++ standard > version, it’s better in my opinion if we can override it to match the > default in GCC, currently C++17, since C++ code compiled with different > standard versions is not ABI-compatible. For CMake, this often looks > like -DCMAKE_CXX_STANDARD=17. (I don’t know a good way to obtain this > value automatically.) To me, this is in the spirit of respecting the > distribution’s build flags. > No, I don't think that this is a safe thing to do on a distribution level - overriding the chosen C++ standard of a project is not respecting upstream's decision, and could cause problems. For example, if upstream wants C++11 and uses std::auto_ptr, compiling with C++17 or C++20 would then break compilation because it was removed in those standard versions. > > When each C++ library is compiled with its own upstream-preferred C > standard version, it’s perfectly possible that an application might have > dependencies using mutually exclusive C++ ABIs, in which case it would > be impossible to package without bundled dependencies in Fedora. Or, > things might appear to work but there could be problems at runtime or > confusing linker errors down the road. > > Do you have a reference for that? I thought the C++ ABI we are talking about here is compiler-dependent and not standard-depdenent (e.g. https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options), so there is the possibility of having problems if we build half the distro with one GCC version and the other half with a different one (hence why we generally do a mass rebuild after the GCC toolchain is updated to its new stable ABI). While there has been one very large change to my knowledge (e.g. std::string in C++11), the C++ standard seems to have tried very hard (to the point of rejecting changes that would violate it) to allow the ABI to be forward compatible between standard versions > It’s not a theoretical problem: grpc builds as C++17, and links against > abseil-cpp which builds as C++17, but runs its unit tests using gtest > which is built in Fedora as C++11. This means grpc has to bundle its own > copy of gtest and build it as C++17. In this case, gtest is not exactly > a bundled library in the usual sense, since it can be proven that > nothing from gtest is linked into the installed libraries or executables. > > Of course, in some cases there are ecosystems of packages in Fedora that > are all currently hard-coding C++11, which happens to work well for > now—and adjusting one would mean adjusting them all. So the issue of C++ > ABI version is a potentially ugly one either way. > > On 8/23/21 10:19 AM, Richard Shaw wrote: > > I'm working on updating OpenColorIO to 2.0.1 and building in a side tag, > > however, the build failed but only on armv7hf with: > > > > usr/lib/libpystring.so /usr/lib/libyaml-cpp.so.0.6.3 > > ../testutils/libtestutils.a -lm ../../src/apputils/libapputils.a > > /usr/bin/ld: CMakeFiles/test_cpu_exec.dir/Processor_tests.cpp.o (symbol > > from plugin): in function > > `OpenColorIO_v2_0::ProcessorMetadata::ProcessorMetadata()': > > (.text+0x0): multiple definition of `typeinfo name for > > OpenColorIO_v2_0::ProcessorCache > std::shared_ptr >'; > > CMakeFiles/test_cpu_exec.dir/Config_tests.cpp.o (symbol from > > plugin):(.text+0x0): first defined here > > /usr/bin/ld: CMakeFiles/test_cpu_exec.dir/Processor_tests.cpp.o (symbol > > from plugin): in function > > `OpenColorIO_v2_0::ProcessorMetadata::ProcessorMetadata()': > > (.text+0x0): multiple definition of `typeinfo for > > OpenColorIO_v2_0::ProcessorCache > std::shared_ptr >'; > > CMakeFiles/test_cpu_exec.dir/Config_tests.cpp.o (symbol from > > plugin):(.text+0x0): first defined here > > collect2: error: ld returned 1 exit status > > > > Ideas? > > > > 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 > > Do not reply to spam on the list, report it: > https://pagure.i
