Re: Build error with GCC 14, not even a warning in GCC 13
On 1/16/24 15:54, Tom Hughes via devel wrote: On 16/01/2024 23:49, Richard Shaw wrote: On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin mailto:aleba...@fedoraproject.org>> wrote: Ah, I misread the include path. It's our package that is too old :( https://src.fedoraproject.org/rpms/rapidjson/pull-request/4 <https://src.fedoraproject.org/rpms/rapidjson/pull-request/4> should help. It doesn't look like the pull request has gotten any attention. Perhaps it's time to initiate the non-responsive maintainer process? Right because the other two PRs I've merged in the last couple of weeks, including one today, are not evidence of responsiveness? That PR is on my to look at list but rather obviously it needs more work than the other ones. I'm not really keen on packaging a random git snapshot because there's no way to know how good or bad it is but I realise that due to upstream being a pain it may be necessary here. For a conservative approach, cherry-picking 3b2441b, 862c39b, 24ebd51, 64faab2, a98e999 seems to be enough. The first 2 commits take care of the issue from this thread, and the remaining 3 are needed to support using rapidjson from projects with -std=c++20. Tom OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Build error with GCC 14, not even a warning in GCC 13
Ah, I misread the include path. It's our package that is too old :(
https://src.fedoraproject.org/rpms/rapidjson/pull-request/4 should help.
On Tue, Jan 16, 2024 at 3:32 PM Aleksei Bavshin
wrote:
>
> On Tue, Jan 16, 2024 at 3:07 PM Richard Shaw wrote:
> >
> > I'm working on getting a new dependency of one of my packages into Fedora:
> >
> > https://github.com/socketio/socket.io-client-cpp/releases
> >
> > After doing successful test builds locally in mock (no error output at all)
> > I used fedora-create-review but all the builds failed with:
> >
> > In file included from
> > /builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
> > /usr/include/rapidjson/document.h: In member function
> > ‘rapidjson::GenericStringRef&
> > rapidjson::GenericStringRef::operator=(const
> > rapidjson::GenericStringRef&)’:
> > /usr/include/rapidjson/document.h:319:82: error: assignment of read-only
> > member ‘rapidjson::GenericStringRef::length’
> > 319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s =
> > rhs.s; length = rhs.length; }
> > |
> > ~~~^~~~
> > gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121:
> > CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1
> >
> > Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023
> >
> > Is this a real error?
>
> Yes, see https://github.com/Tencent/rapidjson/issues/718. The operator
> implementation is most certainly not legal, but previous versions of
> the compiler may have been ignoring that due to not being asked to
> instantiate the specific method.
> This was fixed 8 years ago, apparently bundled deps in
> socket.io-client-cpp are even older.
>
> >
> > 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, 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: Build error with GCC 14, not even a warning in GCC 13
On Tue, Jan 16, 2024 at 3:07 PM Richard Shaw wrote:
>
> I'm working on getting a new dependency of one of my packages into Fedora:
>
> https://github.com/socketio/socket.io-client-cpp/releases
>
> After doing successful test builds locally in mock (no error output at all) I
> used fedora-create-review but all the builds failed with:
>
> In file included from
> /builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
> /usr/include/rapidjson/document.h: In member function
> ‘rapidjson::GenericStringRef&
> rapidjson::GenericStringRef::operator=(const
> rapidjson::GenericStringRef&)’:
> /usr/include/rapidjson/document.h:319:82: error: assignment of read-only
> member ‘rapidjson::GenericStringRef::length’
> 319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s =
> rhs.s; length = rhs.length; }
> |
> ~~~^~~~
> gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121:
> CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1
>
> Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023
>
> Is this a real error?
Yes, see https://github.com/Tencent/rapidjson/issues/718. The operator
implementation is most certainly not legal, but previous versions of
the compiler may have been ignoring that due to not being asked to
instantiate the specific method.
This was fixed 8 years ago, apparently bundled deps in
socket.io-client-cpp are even older.
>
> 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, 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
wlroots 0.17 update announcement
Greetings, I'm planning to update wlroots in rawhide and f39 to 0.17.0[1] by the end of the week. As usual, the update contains API/ABI breaking changes and soname will be bumped to libwlroots.so.12. wlroots0.16 compatibility package will be introduced in the same update. No breakages are expected and no action is required from the maintainers of dependent packages. Some packages (only gamescope so far) may benefit from rebasing to a release that requires 0.17.0, for this purpose I'll post the side-tag ids once available. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.17.0 -- Best regards, Aleksei Bavshin OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
Ouch. I swear, I wanted to check if you're still interested in maintaining RBTools. Just slipped my mind when I saw that the packages are in process of being dropped from f39 :( I can add you as an admin when the unretirement is processed. On Wed, Oct 4, 2023 at 4:48 PM Jonathan Wright via devel wrote: > > Shoot those were mine. I didn't mean to let them orphan :( > > On Wed, Oct 4, 2023 at 6:39 PM Aleksei Bavshin > wrote: >> >> On Mon, Sep 25, 2023 at 5:00 AM Miro Hrončok wrote: >> > RBTools orphan 2 weeks >> > ago >> > python-pydiffxorphan 2 weeks >> > ago >> >> Somehow I missed the retirement of these two packages (can we have >> nice 'will be retired in a week' emails for the FTI process as well, >> please?). >> I need to keep these alive, and it took two small patches to fix >> compatibility with python 3.12. Unretirement tickets are already >> filed. >> ___ >> 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 > > > > -- > Jonathan Wright > AlmaLinux Foundation > Mattermost: chat > ___ > 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: Orphaned packages looking for new maintainers
On Mon, Sep 25, 2023 at 5:00 AM Miro Hrončok wrote: > RBTools orphan 2 weeks ago > python-pydiffxorphan 2 weeks ago Somehow I missed the retirement of these two packages (can we have nice 'will be retired in a week' emails for the FTI process as well, please?). I need to keep these alive, and it took two small patches to fix compatibility with python 3.12. Unretirement tickets are already filed. ___ 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: Announcing fmt library soversion bump
On 6/28/23 04:10, Vitaly Zaitsev via devel wrote: Results: 37 builds succeeded, 19 failed. FTBFS: waybar Known regression in fmt. Please, apply https://github.com/fmtlib/fmt/pull/3430. OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: wlroots 0.16 update announcement
On 11/27/22 14:51, Aleksei Bavshin wrote: Greetings, Sometime within the next week, I'll be updating wlroots in rawhide to 0.16.0[1] and sway to the latest release candidate. As usual, the update contains API/ABI breaking changes and soname will be bumped to libwlroots.so.11. wlroots0.15 compatibility package will be introduced in the same side-tag. No breakages are expected and no action is required from the maintainers of dependent packages. I'll send another notice with a side-tag id to unblock the updates that already require 0.16 (currently only labwc) when it's ready. *** I'm also planning to update wlroots in f37 once 0.16.1 is available. There are a plenty of bug fixes and some important security features (ext-session-lock-v1) that, I believe, should not require waiting another 6 months for f38. Sway will likely not be included in the initial f37 update, but may follow later when it gets sufficient testing. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0 Sorry for delay, the side-tag for f37 is ready. Use 'fedpkg build --target=f37-build-side-61499' to use it. Please, ping me when you build something into the tag so I could refresh the bodhi update. OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for advice - ffmpeg-free and wf-recorder
On 12/16/22 21:29, Bob Hepple wrote: I am the packager for wf-recorder (a wl-roots/wayland screen recorder) which presently resides in rpmfusion - it uses proprietary ffmpeg codecs by default (libx246). Now that we have ffmpeg-free we have an opportunity to move wf-recorder to the mainstream and change the default codec to the non-proprietary libopenh264. This woud be in rawhide/f38 and on. Thanks for considering that! f37 would be nice too. ffmpeg-free is available in this release, so nothing prevents moving wf-recorder to Fedora 37 repos. This all works fine in testing on f37. The fly in the ointment is that if ffmpeg/rpmfusion is installed in place of ffmpeg-free, then wf-recorder can no longer access libopenh264 and fails with an error. There is a workaround in the use of the option -c libx264. Several solutions occur to me and I'm looking for guidance on which path to take: 0. leave wf-recorder where it is, in rpmfusion as in f37 and earlier. A. compile wf-recorder as shipped by upstream with the default libx264 - the '-c libopenh264' workaround would be needed if ffmpeg-free is installed. This annoys users who install stock fedora. B. compile wf-recorder with libopenh264 as the default - the '-c libx264' workaround would be needed if ffmpeg/rpmfusion is installed and would annoy those users. > C. leave wf-recorder in rpmfusion and create a wf-recorder-free package by analogy to ffmpeg (this might be obscure as it's not likely to get much publicity - and annoy everyone sooner or later) Option C sounds like too much maintenance burden for a default option value. D. the best option might be to choose a codec common to both ffmpeg and ffmpeg-free. I'm not terribly au fait with the various codecs so which would I choose? These codecs appear to be in both packages: h263_v4l2m2m V4L2 mem2mem H.263 encoder wrapper (codec h263) h264_amf AMD AMF H.264 Encoder (codec h264) h264_nvenc NVIDIA NVENC H.264 encoder (codec h264) h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264) h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec h264) h264_vaapi H.264/AVC (VAAPI) (codec h264) hevc_amf AMD AMF HEVC encoder (codec hevc) hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc) hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc) hevc_v4l2m2m V4L2 mem2mem HEVC encoder wrapper (codec hevc) hevc_vaapi H.265/HEVC (VAAPI) (codec hevc) libaom-av1 libaom AV1 (codec av1) libopenjpeg OpenJPEG JPEG 2000 (codec jpeg2000) librav1e librav1e AV1 (codec av1) libsvtav1 SVT-AV1(Scalable Video Technology for AV1) encoder (codec av1) libtheora libtheora Theora (codec theora) libvpx libvpx VP8 (codec vp8) libvpx-vp9 libvpx VP9 (codec vp9) libwebp_anim libwebp WebP image (codec webp) libwebp libwebp WebP image (codec webp) mjpeg_qsv MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg) mjpeg_vaapi MJPEG (VAAPI) (codec mjpeg) mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video) mpeg2_vaapi MPEG-2 (VAAPI) (codec mpeg2video) mpeg4_v4l2m2m V4L2 mem2mem MPEG4 encoder wrapper (codec mpeg4) vp8_v4l2m2m V4L2 mem2mem VP8 encoder wrapper (codec vp8) vp8_vaapi VP8 (VAAPI) (codec vp8) vp9_qsv VP9 video (Intel Quick Sync Video acceleration) (codec vp9) vp9_vaapi VP9 (VAAPI) (codec vp9) I'm not an expert enough to tell what to choose, but at least I can tell what should be avoided: - anything h264 or HEVC - these are patented and Fedora won't ship a software implementation of the encoder for these. (except libopenh264, but OSTree-based systems won't have even that). - anything with words vaapi, qsv, v4l2m2m or amf - these only work with a specific hardware - image formats - jpeg or webp might be a bad choice for a screen recorder Next I'm going to suggest to exclude Theora (a bit outdated) and AV1 (which is _slow_ and less widespread, especially in hw decoders). Huh, that leaves us with VP8 and VP9. I don't know how these compare in real-time encoding speed but I hope that VP9 encoder is fast enough for hardware released after 2013 :) Please, also consult with the upstream - wf-recorder includes default parameters for libx264/libx265[1], so they could add a good preset for a royalty-free encoder. [1]: https://github.com/ammen99/wf-recorder/blob/master/src/frame-writer.cpp#L47 ___ 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
Re: wlroots 0.16 update announcement
On 11/27/22 14:51, Aleksei Bavshin wrote: Greetings, Sometime within the next week, I'll be updating wlroots in rawhide to 0.16.0[1] and sway to the latest release candidate. As usual, the update contains API/ABI breaking changes and soname will be bumped to libwlroots.so.11. wlroots0.15 compatibility package will be introduced in the same side-tag. No breakages are expected and no action is required from the maintainers of dependent packages. I'll send another notice with a side-tag id to unblock the updates that already require 0.16 (currently only labwc) when it's ready. (BCC: labwc and wayfire maintainer) New wlroots is now built and tagged into 'f38-build-side-60585'. Use 'fedpkg build --target=f38-build-side-60585' if you want to update your packages that require 0.16. Or wait until I merge the side tag into rawhide in ~1 day -- no practical difference. *** I'm also planning to update wlroots in f37 once 0.16.1 is available. There are a plenty of bug fixes and some important security features (ext-session-lock-v1) that, I believe, should not require waiting another 6 months for f38. Sway will likely not be included in the initial f37 update, but may follow later when it gets sufficient testing. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0 OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mystery fedpkg srpm failure
On 12/1/22 23:18, Aleksei Bavshin wrote: On 12/1/22 22:28, Florian Weimer wrote: I don't see what spec file aspect is causing this failure: $ fedpkg clone -a cups-bjnp Cloning into 'cups-bjnp'... remote: Enumerating objects: 278, done. remote: Counting objects: 100% (278/278), done. remote: Compressing objects: 100% (222/222), done. remote: Total 278 (delta 112), reused 96 (delta 47), pack-reused 0 Receiving objects: 100% (278/278), 158.64 KiB | 752.00 KiB/s, done. Resolving deltas: 100% (112/112), done. $ cd cups-bjnp $ fedpkg srpm Not downloading unused cups-bjnp-2.0.3.tar.gz setting SOURCE_DATE_EPOCH=1669852800 error: Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No such file or directory RPM build errors: Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No such file or directory Could not execute srpm: Failed to execute command. fedpkg-simple doesn't have this problem (presumably because it downloads whatever is in the sources file, whether used or not), so the package builds fine in Koji. Any ideas? Difference in opinions on specfile syntax :) This is the regex rpkg uses to find the source/patch tags: r'^((source[0-9]*|patch[0-9]*)\s*:\s*(?P.*))\s*$'[1] Actually, r'^((source[0-9]*|patch[0-9]*):\s*(?P.*))\s*$', The line in my message was something I modified to test the hypothesis. As you can see, it does not expect spaces between Source[0-9]* and ':'. rpm, however, allows the spaces and there's 6 packages in Fedora that use this syntax quirk. [1]: https://pagure.io/rpkg/blob/master/f/pyrpkg/spec.py#_18 Thanks, Florian ___ 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 OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mystery fedpkg srpm failure
On 12/1/22 22:28, Florian Weimer wrote: I don't see what spec file aspect is causing this failure: $ fedpkg clone -a cups-bjnp Cloning into 'cups-bjnp'... remote: Enumerating objects: 278, done. remote: Counting objects: 100% (278/278), done. remote: Compressing objects: 100% (222/222), done. remote: Total 278 (delta 112), reused 96 (delta 47), pack-reused 0 Receiving objects: 100% (278/278), 158.64 KiB | 752.00 KiB/s, done. Resolving deltas: 100% (112/112), done. $ cd cups-bjnp $ fedpkg srpm Not downloading unused cups-bjnp-2.0.3.tar.gz setting SOURCE_DATE_EPOCH=1669852800 error: Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No such file or directory RPM build errors: Bad file: /home/fweimer/cups-bjnp/cups-bjnp-2.0.3.tar.gz: No such file or directory Could not execute srpm: Failed to execute command. fedpkg-simple doesn't have this problem (presumably because it downloads whatever is in the sources file, whether used or not), so the package builds fine in Koji. Any ideas? Difference in opinions on specfile syntax :) This is the regex rpkg uses to find the source/patch tags: r'^((source[0-9]*|patch[0-9]*)\s*:\s*(?P.*))\s*$'[1] As you can see, it does not expect spaces between Source[0-9]* and ':'. rpm, however, allows the spaces and there's 6 packages in Fedora that use this syntax quirk. [1]: https://pagure.io/rpkg/blob/master/f/pyrpkg/spec.py#_18 Thanks, Florian ___ 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 OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
wlroots 0.16 update announcement
Greetings, Sometime within the next week, I'll be updating wlroots in rawhide to 0.16.0[1] and sway to the latest release candidate. As usual, the update contains API/ABI breaking changes and soname will be bumped to libwlroots.so.11. wlroots0.15 compatibility package will be introduced in the same side-tag. No breakages are expected and no action is required from the maintainers of dependent packages. I'll send another notice with a side-tag id to unblock the updates that already require 0.16 (currently only labwc) when it's ready. *** I'm also planning to update wlroots in f37 once 0.16.1 is available. There are a plenty of bug fixes and some important security features (ext-session-lock-v1) that, I believe, should not require waiting another 6 months for f38. Sway will likely not be included in the initial f37 update, but may follow later when it gets sufficient testing. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.16.0 -- Best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On Mon, Sep 26, 2022 at 2:28 AM Miro Hrončok wrote: > > rust-just orphan, rust-sig 3 weeks ago I'll take rust-just. I already have a package spec that builds/installs in rawhide chroot and just filed an unretirement ticket. ___ 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: Announcing fmt library soversion bump
On 7/11/22 09:50, Ben Beasley wrote:
Two of the three packages I tried to rebuild (bear and fmidi) failed
with errors like:
/usr/include/fmt/core.h:1733:7: error: static assertion failed: Cannot format an
argument. To make type T formattable provide a formatter
specialization:https://fmt.dev/latest/api.html#udt
1733 | formattable,
| ^~~
Links to failing scratch builds in the side tag:
https://koji.fedoraproject.org/koji/taskinfo?taskID=89380682
https://koji.fedoraproject.org/koji/taskinfo?taskID=89380736
I found that there was already a bug report open upstream for Bear:
https://github.com/rizsotto/Bear/issues/471
Thanks for bringing attention to that. I suspect the following fmt
changelog entry:
"Disabled automatic std::ostream insertion operator (operator<<)
discovery when fmt/ostream.h is included to prevent ODR violations. You
can get the old behavior by defining FMT_DEPRECATED_OSTREAM but this
will be removed in the next major release. Use fmt::streamed or
fmt::ostream_formatter to enable formatting via std::ostream instead."
That is a VERY breaking change and there will be more packages affected.
It's likely also affecting dependents of spdlog which use external fmt
and .
The fix is simple, but not backward-compatible:
template <> struct fmt::formatter : ostream_formatter {};
(a custom fmt::formatter for the type would work as well).
I already confirmed that `waybar` is broken and will submit a fix
upstream when I have time. Setting up a copr repo to find all other
breakages sounds like a good idea.
If that FTBFS rate is typical of the full set of affected packages, then
merging the side tag without resolving the API incompatibilities in
dependent packages will be pretty disruptive to Rawhide as a whole.
Would you consider setting up a COPR to figure out how many packages are
affected by the API changes, and filing Bugzillas on the affected
dependent packages? It might take a while for affected package
maintainers to become aware of the problem, investigate, and perhaps
work with upstreams to prepare the necessary patches.
Link to fmt 9.0.0 release notes:
https://github.com/fmtlib/fmt/releases/tag/9.0.0
– Ben
On 7/11/22 12:21, Ben Beasley wrote:
I don’t believe this list is nearly complete. Two packages I maintain
that would be affected (fmidi and giada) are absent from the list.
Using the following command:
mock -r fedora-rawhide-x86_64 --dnf-cmd -- repoquery
--whatrequires 'libfmt.so.8*'
I found these additional dependent packages that were missing from the
original list:
* bear
* cachelib
* easyeffects
* easyrpg-player
* fb303
* fbthrift
* fizz
* fmidi
* freeopcua
* gerbera
* giada
* gnuradio
* gr-funcube
* libsemigroups
* luxcorerender
* mcrouter
* nheko
* proxygen
* rstudio
* wangle
* watchman
* waybar
I will go ahead and rebuild bear, fmidi, and giada into the side tag.
On 7/10/22 13:43, Vitaly Zaitsev via devel wrote:
Hello.
fmt 9.0.x update will include a soversion bump from .8 to .9. It has
both API and ABI changes.
Changelog: https://github.com/fmtlib/fmt/releases/tag/9.0.0
The list of affected packages in Rawhide:
0ad
OpenImageIO
cantera
ceph
dolphin-emu
domoticz
folly
libsonata
mkvtoolnix
sdrpp
spdlog
vcpkg
zswap-cli
I can rebuild only spdlog, vcpkg and zswap-cli. For others, I will
need proven-packagers assistance.
Please use the f37-build-side-54844 side tag. I will merge it into
Rawhide later.
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
Re: wlroots 0.15 update is coming to rawhide
On 1/11/22 21:29, Aleksei Bavshin wrote: Greetings, By the end of this week I'm planning to update wlroots in rawhide to 0.15 (libwlroots.so.10) and sway to the latest release candidate. No breakages are expected as wlroots0.14 compatibility package will be introduced in the same side-tag. Additionally, I intend to retire wlroots0.12 and wlroots0.13 before f36 is branched. Currently only `phoc` and `gamescope` depend on these compatibility packages. Both have releases or patches with support for new wlroots versions, so I'll retire the compat libs once we get the updates in rawhide. Wlroots 0.15.0 is available in rawhide buildroot and all dependent updates are unblocked. % koji wait-repo f36-build --build wlroots-0.15.0-1.fc36 Successfully waited 0:01 for wlroots-0.15.0-1.fc36 to appear in the f36-build repo In 1-2 weeks (after the upstream release), I'll bump sway to the 1.7 final in rawhide and update sway:rolling module for f35 and f34. -- With best regards, Aleksei Bavshin ___ 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: [Sway] wlroots 0.15 update is coming to rawhide
On 1/12/22 10:52, Onyeibo Oku wrote: On Wed Jan 12, 2022 at 6:29 AM WAT, Aleksei Bavshin wrote: Greetings, By the end of this week I'm planning to update wlroots in rawhide to 0.15 (libwlroots.so.10) and sway to the latest release candidate. No breakages are expected as wlroots0.14 compatibility package will be introduced in the same side-tag. -- Best regards, Aleksei Bavshin I am excited about improvements on Sway. Where can I read more about wlroots 0.15? What nice new feature(s) should we expect? Sorry, forgot to reply yesterday. Here's the upstream release notes with all the changes since sway 1.6.1/wlroots 0.14.1: https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.15.0 https://github.com/swaywm/sway/releases/tag/1.7-rc1 Sway is mostly feature-complete (as it has a goal of not doing more than i3 does) so there's not a lot of shiny new features. The main focus of this release cycle was on wlroots internal improvements and new wayland protocols (xdg-activation, drm-lease, linux-dmabuf feedback support). Thanks Aleksei, Regards Onyeibo (@twohot) OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
wlroots 0.15 update is coming to rawhide
Greetings, By the end of this week I'm planning to update wlroots in rawhide to 0.15 (libwlroots.so.10) and sway to the latest release candidate. No breakages are expected as wlroots0.14 compatibility package will be introduced in the same side-tag. Additionally, I intend to retire wlroots0.12 and wlroots0.13 before f36 is branched. Currently only `phoc` and `gamescope` depend on these compatibility packages. Both have releases or patches with support for new wlroots versions, so I'll retire the compat libs once we get the updates in rawhide. -- Best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: rust: Request for packaging rust-html-escape and rust-smallbitvec
On 12/3/21 03:15, Andreas Schneider wrote: On Thursday, December 2, 2021 9:07:06 PM CET Aleksei Bavshin wrote: `smallbitvec` deps are only needed for benchmark, so the test suite is actually passing without these. Should be safe to drop with metadata patch. rust-tiny_http 0.8.2 also has a benchmark-only dependency `fdlimit` which we can drop. The situation with tree-sitter-cli testsuite is complicated: it requires a few other github repos with a grammar definitions and who knows what else. I haven't succeeded in running it so far, so we can keep it turned off. And that would make `rust-spin` update unnecessary. The draft packages are available from https://copr.fedorainfracloud.org/coprs/alebastr/rust-tree-sitter-cli/; seems working with available grammar files (with exception of `build-wasm` and `playground` subcommands which require emscripten). This is great work, thank you very much. I didn't know that the tree-sitter- cli needs it own package and can't be built in the current tree-sitter package. So I will just continue to take care of tree-sitter and just build the lib. So having tree-sitter-cli in the next fedora version would be awesome. Reviews (and PR for rust-tiny_http update) are sent. Upstream issue for missing license file: https://github.com/tree-sitter/tree-sitter/issues/1520 Andreas, do you want to have comaintainer access to the tree-sitter-cli packages? Best regards Andreas ___ 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: rust: Request for packaging rust-html-escape and rust-smallbitvec
On 12/2/21 09:56, Fabio Valentini wrote: On Wed, Dec 1, 2021 at 5:07 PM Andreas Schneider wrote: Hello, I would like to compile the tree-sitter parser generating tool. For this rust- html-escape and rust-smallbitvec is missing in the distro. It would allow that you can add additional languages for highlighting in neovim. If someone who is familiar with rust could packages those two small extensions, that would be really great! Hello! It turns out, it is not as simple as "just two small extensions". Packaging the html-escape crate is not a problem, it has no dependencies that are not already present in Fedora. smallbitvec has very outdated dependencies for running its test suite, so that has to be turned off. You also seem to have missed tiny_http 0.8.x, which is present in Fedora repos, but with a version that is too old (0.6.2). But the bigger problem will be tree-sitter-cli itself, which is split into multiple, separately-shipped Rust crates - so there's these additional dependencies to the two you assumed going into this endeavour: - tree-sitter-cli - tree-sitter - tree-sitter-config - tree-sitter-highlight - tree-sitter-loader - tree-sitter-tags Those will also have to be packaged. They don't have any dependencies that are not packaged for Fedora yet, but tree-sitter requires spin version 0.7.x, whereas we have spin 0.5.2 right now. This means, in total: - new package: rust-html-escape - new package: rust-smallbitvec - update package: rust-tiny_http to version 0.8.2 - new package: rust-tiny_http0.6 compat package - new package: rust-tree-sitter-cli - new package: rust-tree-sitter - new package: rust-tree-sitter-config - new package: rust-tree-sitter-highlight - new package: rust-tree-sitter-loader - new package: rust-tree-sitter-tags - update package: rust-spin to version 0.7.1 - new package: rust-spin0.5 compat package So, ten new packages, plus two updates, plus two new compat packages (unless I missed something - there might be more TODO items than those). Welcome to the Rust world! ;) `smallbitvec` deps are only needed for benchmark, so the test suite is actually passing without these. Should be safe to drop with metadata patch. rust-tiny_http 0.8.2 also has a benchmark-only dependency `fdlimit` which we can drop. The situation with tree-sitter-cli testsuite is complicated: it requires a few other github repos with a grammar definitions and who knows what else. I haven't succeeded in running it so far, so we can keep it turned off. And that would make `rust-spin` update unnecessary. The draft packages are available from https://copr.fedorainfracloud.org/coprs/alebastr/rust-tree-sitter-cli/; seems working with available grammar files (with exception of `build-wasm` and `playground` subcommands which require emscripten). The Rust SIG *can* help with this work, but I don't like committing the SIG (which has been mostly myself, for the past months) to more work maintaining ever more packages without a good reason. 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 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: Firefox Hardware acceleration & VA-API how-to
On 11/15/21 08:45, Martin Stransky wrote: On 11/15/21 17:38, Aleksei Bavshin wrote: On 11/12/21 00:37, Martin Stransky wrote: Hi folks, I was told that people were having trouble with Firefox/HW acceleration/VA-API setup on Fedora so I put some info at wiki at: https://fedoraproject.org/wiki/Firefox_Hardware_acceleration Hope it helps. Martin Intel section fails to mention that accelerated video decoding on the Iris XE (Gen12) GPUs requires intel-media-driver and won't work with older libva-intel-driver. So we're out of luck until the sandboxing issue is resolved and the fix is backported to Fedora Firefox builds. As usually, please update the page. Thanks. Hm. I just reread the whole section again. Martin, did you mean to use intel-media-driver (iHD_drv_video.so) instead of the libva-intel-hybrid-driver (hybrid_drv_video.so)? Because everything makes sense with that substitution and the sandbox bug only mentions iHD_drv_video.so. To be honest, I have no idea what GPUs even use libva-intel-hybrid-driver alone. libva-intel-driver claims to support everything up to Gen 10 GPUs and Gen11+ (Ice Lake, Tiger Lake, etc..) is handled by the intel-media-driver. And hybrid-driver's only purpose seems to be a VP9 decoding backend for the libva-intel-driver (--enable-hybrid-codec). Can someone confirm that? -- Best regards, Aleksei Bavshin ___ 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: Firefox Hardware acceleration & VA-API how-to
On 11/12/21 00:37, Martin Stransky wrote: Hi folks, I was told that people were having trouble with Firefox/HW acceleration/VA-API setup on Fedora so I put some info at wiki at: https://fedoraproject.org/wiki/Firefox_Hardware_acceleration Hope it helps. Martin Intel section fails to mention that accelerated video decoding on the Iris XE (Gen12) GPUs requires intel-media-driver and won't work with older libva-intel-driver. So we're out of luck until the sandboxing issue is resolved and the fix is backported to Fedora Firefox builds. -- Best regards, Aleksei Bavshin ___ 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: Firefox Hardware acceleration & VA-API how-to
On 11/15/21 04:34, Fabio Valentini wrote: On Fri, Nov 12, 2021 at 9:37 AM Martin Stransky wrote: Hi folks, I was told that people were having trouble with Firefox/HW acceleration/VA-API setup on Fedora so I put some info at wiki at: https://fedoraproject.org/wiki/Firefox_Hardware_acceleration Hope it helps. Martin I appreciate the effort to document ways to improve things. However: Video decoding on NVIDIA Please buy some real Linux hardware. This doesn't really help at all. Is it supposed to be funny, or is it just cynical resignation? After trying to configure HW acceleration on 9xx series GPU, I'll just take that as a serious response. Consider following points: * VDPAU is not compatible with Wayland, our main desktop scenario. * Video decoding in Firefox on X11 is limited to X11/EGL, which does not work with the Nvidia proprietary driver (but at least there's a hope for that scenario). * There's no NVDEC vaapi backend, and I see opinions that it would be hard to fit NVDEC into vaapi model. * Nouveau support ends at VP5 (7xx series). The wording might be different, but _at the moment_ any recent Nvidia hardware cannot be used for HW video acceleration in Firefox. -- Best regards, Aleksei Bavshin ___ 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: Firmware packages
On 11/8/21 22:36, Miroslav Suchý wrote: In the recent discussion about saving space (in the ELF thread) there poped up linux-firmware topic several time. Let's kick it off as separate thread. I have several question and I am unable to find the answer for them. 1. How do I find which firmware package I need? On my workstation I have: $ rpm-qa|grepfirmware |wc-l 27 I seriously doubt I need all of them. I definitely do not need them on server, where I never add any new HW. But how do I know which one is in use and which not? From my (fairly limited) knowledge, you'll have to look at `modinfo` for loaded modules or `MODULE_FIRMWARE` and `request_firmware.*` API usage within the kernel sources. I'm not aware if that documents all the firmware files in use, but hopefully someone from kernel or linux-firmware maintenance teams can chime in. AFAIK, there is no information about the mapping of device ids -> fw files available. I.e., let's say, `iwlwifi` in 5.15.0 declares 47 unique firmware files and 77 supported PCI ids. But each of those PCI ids would require only a small subset of these 47 firmware binaries. Thus, the `iwl.*-firmware` packages can be split in a way it is done right now and installed/removed as necessary. It should possible to collect the data from the kernel source manually, but imagine the effort to do that and to keep it up-to-date... --- I considered proposing to use rpm metadata for the very same purpose, something like Supplements: device(pci:8086:a0f0) >= rev20 Supplements: device(usb:8087:0026) or Provides: firmware(pci:8086:a0f0) Provides: firmware(usb:8087:0026) but we'd really want to have that autogenerated, and there's no input data readily available for that. Also, you'd want to expose the hardware information from the rpm side as well, which is a whole another problem. I believe we still can't get CPU hwcaps exposed, and this would add lspci/lsusb information to the mix. 2. How the firmware packages actually work? Do I need them to be present every time? Or when module is loaded? Or something else? (sorry if this too naive question). A module can load a firmware binary with the `request_firmware` API at any moment of it's lifetime. Usually, this happens when the module is initialized or discovers a new supported device, but I don't believe that is a strictly enforced rule. The process itself is complicated enough (I recall it used to involve udev as an intermediary to access the filesystem), and may have a place for on-demand firmware package installation. But that's prone to breaks and won't function offline. Also, see above for required device id -> firmware files mapping. 3. The linux-firmare has 100MB. And cca 280 MB extracted. Is it about the time to split the package? Here are the biggest space eater of the space: 18M /usr/lib/firmware/amdgpu 18M /usr/lib/firmware/qcom 28M /usr/lib/firmware/intel 31M /usr/lib/firmware/mrvl 47M /usr/lib/firmware/mellanox You can slightly reduce the installation footprint if you have minimum/maximum supported kernel version. Some of the firmware binaries have an API version, and the kernel will use only currently supported API (I'll point to `iwlwifi` as an example again. It's what lead me to a rabbit hole of firmware loaders, after all). The rest are kept there only to support older kernels. But that doesn't apply to all the firmware files and drivers, and again, the compat database has to be collected and updated manually. 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 -- Best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unexpected /patches VERIFY result from rpminspect
On 11/4/21 09:17, Florian Weimer wrote: Why is this VERIFY? The patch was generated as if by “git show”, and I do not see anything wrong with it. rpminspect thinks that the patch is suspiciously large and asks you to confirm that it is intentional. There's a test description in the beginning of the log: Inspects all patches defined in the spec file and reports changes between builds. At the INFO level, rpminspect reports diffstat(1) and patch size changes. If thresholds are reached regarding a change in the patch size or the number of files the patch touches, rpminspect reports the change at the VERIFY level unless the comparison is for a rebase. The configuration file can also list patch names that rpminspect should ignore during the inspection. -- Best regards, Aleksei Bavshin ___ 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: Font Awesome version 5
Hello Jerry, On 8/4/21 3:57 PM, Jerry James wrote: Am I stepping on your toes with this? That is, had you already started working on a v5 package? I don't want to get in your way if so. On the other hand, if you haven't, would you like to comaintain the one I'm working on? No, I haven't, so feel free to continue. Previous attempt to upgrade fontawesome wasn't successful (rhbz#1854348 if you haven't seen that already), so I was just trying to estimate the magnitude of disaster :) Fabio (@fale) did the aforementioned upgrade and could be more inclined to comaintain fa5. One potentially confusing thing is that FA5 consists of two fonts: Font Awesome 5 Free and Font Awesome 5 Brands. fa-free-fonts could be interpreted as containing only the former one. Another is the whole parallel-installable thing and a need to guess which package is 4 or 5 (and 6 in a not-so-distant future). I'd suggest fontawesome5-fonts, or at least something with explicit version in the package name. Okay, that makes sense. I guess that means that I didn't handle the subpackages correctly, then. I'll give this some thought. Thanks for the input! -- With best regards, Aleksei Bavshin ___ 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: Font Awesome version 5
On 8/2/21 2:35 PM, Jerry James wrote: In the review of python-pydata-sphinx-theme (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1981997), the fact that our FontAwesome font packages are on version 4.x came up. That new package needs version 5.x. I tried to make it work with 4.x ... no luck. I do not want to take over the existing fontawesome-fonts package, nor do I want to be involved in porting anything from version 4.x to version 5.x. I am willing, however, to maintain a parallel-installable version 5.x of the fonts, so that applications can migrate on their own schedules (with an eye to eventually deprecating and/or removing the existing package). Thanks for doing this! 4 and 5 (and 6) are not backward compatible. Glyphs are missing, replaced, changed codepoints, etc... Not all things could be ported and I don't believe we'll ever get rid of 4. Good thing is that _some_ of the packages with `Requires: fontawesome-fonts` already require v5 and work with v4 only partially. Not so good thing is that someone need to go through about 30 packages and update dependencies to `font(fontawesome)` and `font(fontawesome5free)`. I started looking at the packages last month, but got distracted with work and never finished. Can return to that in a couple of weeks. I have filed a review request: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1989300 It uses the name fontawesome-free-fonts for two reasons: - To be different from the existing package name for parallel installability; and - To distinguish the Fedora package from the Pro version of the fonts. One potentially confusing thing is that FA5 consists of two fonts: Font Awesome 5 Free and Font Awesome 5 Brands. fa-free-fonts could be interpreted as containing only the former one. Another is the whole parallel-installable thing and a need to guess which package is 4 or 5 (and 6 in a not-so-distant future). I'd suggest fontawesome5-fonts, or at least something with explicit version in the package name. I have two misgivings about this package and would appreciate some input from the community on these points. 1. Does the name rationale make sense? 2. Do we actually need the web subpackage? The font guidelines say NOT to package svg, woff, etc. versions of a font because modern browsers can read the otf versions. On the other hand, the web subpackage also contains JavaScript versions of the fonts (which cannot be built from source using only Fedora packages, alas!). On the gripping hand, the existing package has a web subpackage, and it seems to be used (by 8 packages). Thanks! -- With best regards, Aleksei Bavshin ___ 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: systemd-oomd blows away the gnome-shell desktop session
On 7/27/21 6:23 PM, David Airlie wrote: Hi, I've been using f34 with gnome/wayland session on a 16MB machine which has 8GB zram swap configured. If I build anything large inside my desktop environment (llvm/clang) from a gnome-terminal, systemd-oomd blows away my whole desktop slice. This seems overly hostile. Now in theory I can use systemd-run to run a shell but my understanding is the DE is meant to be smarter here. Is it at least launching firefox etc in new cgroups or are all processes on my desktop in one big cgroup? IIRC, gnome-terminal supposed to put each tab into a new cgroup. And Gnome would create cgroup for each desktop application started via Gnome shell or glib functions. While it's still a bit fragile and there's a lot of ways to escape (i.e. xdg-open, third-party application launchers, starting apps from the terminal, etc.), normal use in Gnome should work just fine. --- From your description, something obviously went wrong: either assignment of cgroups has failed and everything is in the same big group, or sd-oomd made a bad shot. systemd-cgls should show which it is. For the former, I happen to see at least one case where this outright fails - some SELinux user roles don't have access to the required systemd dbus interface and method call with cgroup assignment couldn't be sent. For the latter, I noticed that on my old hw (8GB ram) sd-oomd always preferred to kill firefox instead of gcc. Something made cgroup with firefox less likeable ¯\_(ツ)_/¯ Even if it launched gnome-terminal in another group I assume this would result in it blowing away all my open terminals just to kill the compiler/linker that is consuming all the RAM/swap. Again this seems overly hostile. Any ideas other than campaigning for systemd-oomd to be turned off again? Dave. ___ 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 -- With best regards, Aleksei Bavshin ___ 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: guile22 -> gnutls -> lots of virt packages
On 7/7/21 2:14 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jul 07, 2021 at 06:21:08PM +0200, Petr Menšík wrote: What would be considered sufficient research about usage of guile? If package provides it as optional feature among many other features, how should package owner test one feature is still demanded? Do we have any best practice? Is asking on users@ and devel@ list enough? I strongly suspect that those users would have made themselves known by now. Neal mentioned that he uses guile in some projects, and that's pretty much it so far. Well, I'm using guile scripting support in gdb as it seems to be noticeably faster than python for my scenarios with parsing huge heap areas. But I do that on CentOS 7/8s with my own backports of the gdb package and won't be losing a lot if Fedora spec hides guile under %bcond. Maybe there are others who are abstaining from this discussion simply because they don't expect to be affected by the change. (I'd have a stronger opinion on that if we had better ECMAScript support in guile though) -- Best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wlroots 0.14.0 is coming to rawhide
On 6/26/21 2:52 PM, Aleksei Bavshin wrote: Rawhide update ETA is in a week from this message or when all the required builds are complete. Wlroots 0.14 and new versions of dependent packages are now available in rawhide. Thanks to everyone for your help with this update! sway:rolling module build for f34 is completed and will be in updates-testing-modular soon. -- Best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing fmt library soversion bump
On 7/5/21 6:27 AM, Richard Shaw wrote: waybar failed with: > ... This looks to be fmt related... Fixed and rebuilt in the side-tag -- Best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wlroots 0.14.0 is coming to rawhide
On 7/3/21 12:43 PM, Artem Tim wrote: Done for labwc and wayfire: * https://koji.fedoraproject.org/koji/taskinfo?taskID=71258443 * https://koji.fedoraproject.org/koji/taskinfo?taskID=71258789 Thanks you! Thanks for updating it. What's a plan for f34? No plans at the moment, we normally don't push breaking wlroots changes into stable branches. Even if we wanted to, I'd prefer to wait for 0.14.1 with following regressions resolved: - https://github.com/swaywm/wlroots/issues/2987 - https://github.com/swaywm/wlroots/issues/2991 Both are compelling reasons to keep f34 at the current version. -- Best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wlroots 0.14.0 is coming to rawhide
On 6/26/21 2:52 PM, Aleksei Bavshin wrote: Greetings, wlroots 0.14.0 was released this week with a lot of bugfixes, new pixman software renderer for not-so-recent hardware and continuation of renderer refactoring. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. Artem, Lyes, Timothée, The side-tag for this update is 'f35-build-side-43323'. Use 'fedpkg build --target=f35-build-side-43323' to use it. and send a PR with compatibility patches for `labwc` That's no longer necessary since labwc 0.3.0 compatible with the new wlroots. Just bump the version and build into the side-tag as usual. Merging the side-tag into rawhide will be slightly delayed as I'm still working on `gamescope` update. -- Best regards, Aleksei Bavshin ___ 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
wlroots 0.14.0 is coming to rawhide
Greetings, wlroots 0.14.0 was released this week with a lot of bugfixes, new pixman software renderer for not-so-recent hardware and continuation of renderer refactoring. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. I'll be taking care of all rebuilds except `cage`, `labwc` and `wayfire`. I'll notify maintainers of those packages additionally (and send a PR with compatibility patches for `labwc`) once the side-tag is ready. `phoc` will continue using wlroots0.12 compat package; no actions required here. Rawhide update ETA is in a week from this message or when all the required builds are complete. -- Best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wlroots 0.13.0 update for rawhide and f34
wlroots-0.13 is now available in rawhide. The compatibility issues are resolved via `wlroots0.12` package which will be installed on update if there is anything that depends on `libwlroots.so.7`. No rebuilds are necessary. If your package depends on the old wlroots API or hardware support, you may need to adjust build requirements to one of following: BuildRequires: pkgconfig(wlroots) = 0.12.0 BuildRequires: (pkgconfig(wlroots) >= 0.12 with pkgconfig(wlroots) < 0.13) for future builds. --- @atim, @fnux, @lyessaadi, if you want to have new versions of cage/hikari/labwc to be available in f34 as a day 0 update, you are welcome to use the side-tag `f34-build-side-40158` (`fedpkg build --target=f34-build-side-40158`). Merge ETA is in 1 day. Although in the case of hikari that might not work, as the side-tag does not contain libucl from `f34-updates-testing` :( On 4/7/21 1:54 PM, Aleksei Bavshin wrote: Greetings, wlroots 0.13.0 and sway 1.6 have been released today. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. For all the dependents I identified either upstream patches or ETA for the new release and have successful copr builds. I'm planning to create rawhide side-tag later today, rebuild all @sway-sig packages and send PRs with instructions to the packages I don't have access to. The side-tag will be merged in a week or when all the rebuilds are done. I also plan to prepare a day 0 update for f34 once rawhide rebuilds are completed. Let me know if you have any concerns about that. BCC: maintainer aliases for cage, labwc, phoc and wayfire -- With best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: wlroots 0.13.0 update for rawhide and f34
The update is on hold until we figure out how to deal with wlroots 0.13.0 regression on PinePhone[1]. New wlroots drm backend code doesn't seem to like lima + sun4i-drm display controller combination :( The backup plan if we don't have a fix in a next few weeks is to create wlroots0.12 compat package and modify `phoc` spec to require it. [1]: https://github.com/swaywm/wlroots/issues/2795 On 4/7/21 1:54 PM, Aleksei Bavshin wrote: Greetings, wlroots 0.13.0 and sway 1.6 have been released today. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. For all the dependents I identified either upstream patches or ETA for the new release and have successful copr builds. I'm planning to create rawhide side-tag later today, rebuild all @sway-sig packages and send PRs with instructions to the packages I don't have access to. The side-tag will be merged in a week or when all the rebuilds are done. I also plan to prepare a day 0 update for f34 once rawhide rebuilds are completed. Let me know if you have any concerns about that. BCC: maintainer aliases for cage, labwc, phoc and wayfire -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
wlroots 0.13.0 update for rawhide and f34
Greetings, wlroots 0.13.0 and sway 1.6 have been released today. As usual, the update is API and ABI breaking and all dependent packages must be rebuilt. For all the dependents I identified either upstream patches or ETA for the new release and have successful copr builds. I'm planning to create rawhide side-tag later today, rebuild all @sway-sig packages and send PRs with instructions to the packages I don't have access to. The side-tag will be merged in a week or when all the rebuilds are done. I also plan to prepare a day 0 update for f34 once rawhide rebuilds are completed. Let me know if you have any concerns about that. BCC: maintainer aliases for cage, labwc, phoc and wayfire -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaning pasystray, clipit, python-i3ipc, rnv
I took python-i3ipc; I have a package with dependency on it. Thanks for maintaining it all these years! On 3/18/21 12:44 PM, Michael Šimáček wrote: Hi, Due to lack of time and motivation I've just orphaned the following packages which are now free to take: pasystray clipit python-i3ipc rnv Regards, Michael Simacek ___ 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 -- With best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On 12/21/20 1:53 PM, Neal Gompa wrote: On Mon, Dec 21, 2020 at 4:52 PM Aleksei Bavshin wrote: On 12/21/20 8:28 AM, Ben Cotton wrote: == Documentation == https://www.freedesktop.org/software/systemd/man/systemd-oomd.html https://www.freedesktop.org/software/systemd/man/oomctl.html https://www.freedesktop.org/software/systemd/man/oomd.conf.html Be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). If you're using a desktop environment like GNOME, it already spawns many session components with the systemd user manager. This makes me slightly very concerned. According to cgls, I have most of the apps running directly under user-$UID.slice -> session-X.scope. That includes a compositor (sway) and a few applications that consume uncomfortably close to 100% of available memory (firefox, thunderbird, clangd, gcc, etc...). My understanding is that unless I configure all of the above to run under dedicated scopes, an attempt to run a memory-intensive task would make systemd-oomd terminate the whole user slice with all my apps. Is there anything that could be improved for that scenario? I don't expect that all our desktop users would start using `systemd-run --scope --user` to launch their applications. My understanding is that we intend to do exactly that for you automatically when you open an application through a desktop file. So it should be fine from that perspective. Should I mention that this is happening not in GNOME and neither make nor vim are using desktop files to start subprocesses? And there are dozens of application launchers in Fedora repositories that aren't aware of systemd or cgroups. I'm raising that point because I'd like to have at least a set of recommendations for any alternative environments. So far it seems like the impact outside of major DEs and standard desktop workflows wasn't considered. Don't take this as an antagonism to the proposal, I see the benefits of systemd-oomd and will likely use it myself with a few shell aliases, patches and config changes. It's just that as a maintainer of one of those alternative desktop environments I have no idea how to make that work in default configuration. -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
On 12/21/20 8:28 AM, Ben Cotton wrote: == Documentation == https://www.freedesktop.org/software/systemd/man/systemd-oomd.html https://www.freedesktop.org/software/systemd/man/oomctl.html https://www.freedesktop.org/software/systemd/man/oomd.conf.html Be aware that if you intend to enable monitoring and actions on user.slice, user-$UID.slice, or their ancestor cgroups, it is highly recommended that your programs be managed by the systemd user manager to prevent running too many processes under the same session scope (and thus avoid a situation where memory intensive tasks trigger systemd-oomd to kill everything under the cgroup). If you're using a desktop environment like GNOME, it already spawns many session components with the systemd user manager. This makes me slightly very concerned. According to cgls, I have most of the apps running directly under user-$UID.slice -> session-X.scope. That includes a compositor (sway) and a few applications that consume uncomfortably close to 100% of available memory (firefox, thunderbird, clangd, gcc, etc...). My understanding is that unless I configure all of the above to run under dedicated scopes, an attempt to run a memory-intensive task would make systemd-oomd terminate the whole user slice with all my apps. Is there anything that could be improved for that scenario? I don't expect that all our desktop users would start using `systemd-run --scope --user` to launch their applications. -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: wlroots 0.12 update with soname change
On 11/10/20 9:57 PM, Aleksei Bavshin wrote: Greetings, I'm planning to push wlroots 0.12.0 update into rawhide next week. As usual, the update is ABI breaking and will change soname (6 -> 7). This time no source changes required for any of the packages; simple rebuild with release bump would be sufficient. I will send an additional message once I figure out how to set up a side-tag and get new wlroots build published into it. The side-tag is ready. You can build your packages with new wlroots using following command: fedpkg build --target=f34-build-side-33997 Use 'koji wait-repo f34-build-side-33997' to wait for the build repo to be updated if you are building multiple dependent packages (which is likely relevant only for wayfire). I'll request the side-tag merge in a week from the initial announcement or when all rebuilds are completed. Affected packages (maintainer aliases in Bcc): - cage - gamescope - phoc - sway - wayfire -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
wlroots 0.12 update with soname change
Greetings, I'm planning to push wlroots 0.12.0 update into rawhide next week. As usual, the update is ABI breaking and will change soname (6 -> 7). This time no source changes required for any of the packages; simple rebuild with release bump would be sufficient. I will send an additional message once I figure out how to set up a side-tag and get new wlroots build published into it. Affected packages (maintainer aliases in Bcc): - cage - gamescope - phoc - sway - wayfire -- With best regards, Aleksei Bavshin OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Removing packages from module
Petr and Daniel, thanks a lot for your replies.
I hope some of mentioned limitations could be reflected in the
modularity documentation. I read through most of it (including the
drafts for f33 change) and I don't feel that the consequences of adding
package to the module are clearly communicated.
And maybe something could be added to the modulemd spec to reflect that
the specific package is no longer required starting from release x. I
don't expect that to work from updates-modular for branched releases,
but having the ability to drop packages from module on a development
release would be awesome.
On 7/20/20 4:46 AM, Petr Pisar wrote:
> On Fri, Jul 17, 2020 at 02:14:49PM -0700, Aleksei Bavshin wrote:
>> The real question is how to do the change in f33 considering that f32
>> and f33 modules must be built from the same modulemd file.
>
> You wrap a %files section of the package you want to remove with a condition
> based on the Fedora version:
>
> %if %{fedora} < 33
> %files
> ...
> %end
>
> This will cause the when building the module component, rpmbuild won't produce
> the unwanted binary package on F33, but it will produce it on F32.
>
> The only problem is if that is the only binary package produced by the spec
> file. Then rpmbuild would report an error, because it would consider it
> a packaging mistake. But it can be worked around by produced a dummy package
> instead:
>
> %if %{fedora} < 33
> %files
> ...
> %else
> %files -n dummy
> %end
>
> and filtering out the dummy package from the module on modulemd level with
> /data/filetr/rpms/dummy entry.>
>> And now I'm curious what would happen if I specify `platform: [-f33]`
>> and publish new module build. Would that remove previously published
>> metadata from rawhide?
>
> No. Rawhide repository is composed from the latest builds tagged into
> a rawhide tag. That means Rawhide would still contain the last module built
> from f33 platform.
>
>> I guess the right answer is somewhere around servicelevels and `eol`
>> specification.
>>
> Theoretically yes. You can file a releng request
> <https://pagure.io/releng/new_issue> of moduel_eol type to shorten the EOL.
> But I worry that a compose process does not respect the EOL dates and instead
> the EOLed modules are removed from a compose configuration by relengs
> manually once before branching a new Fedora release (33 is the next one).
>
> -- Petr
--
With best regards,
Aleksei Bavshin
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Removing packages from module
On 7/17/20 1:50 PM, Daniel Mach wrote: > > > Dne 17. 07. 20 v 14:15 Aleksei Bavshin napsal(a): >> On 7/17/20 3:27 AM, Daniel Mach wrote: >>> Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a): >>>> If the package was part of the module during the release of Fedora 32, >>>> dnf will see 2 versions/builds of the module-stream: >>>> >>>> - the one that existed during the release (containing the package) >>>> - the one from updates (no longer containing the package) >>>> >>>> The "original" version will still filter out the non-modular version >>>> of the package from any transaction. >>>> >>>> And given the way modular filtering works, a package cannot >>>> technically be "demodularized" this was during one release, unless you >>>> force a module reset from another package's scriptlet. >> >> Thanks for clarifying this, Miro. So the filter is built based on the >> module metadata instead of the installed packages. I guess I >> misunderstood that part. >> >> That's just sad. I woke up with the bright idea about removing the >> packages from modulemd and then adding `sway-module-obsoletes` which >> Obsoletes everything in the module that's behind f32-updates. We have >> several packages like this since the last module rebuild. >> >> If there's a cached non-updateable module metadata from fedora-modular >> which is always considered by dnf together with the updated version from >> fedora-updates-modular, that had no chance of working. > That's exactly how it works. > Unlike RPMs where usually the latest version is the result of a > transaction, module metadata are additive. > Sum of all versions make a stream and it's content (incl. the old RPM > versions) so you can eventually downgrade your package if you need to. > We know about the issue and we want to introduce some de-modularization > feature, but we need to fix more serious issues first. > >> >>>> During the update to Fedora 33 a modular reset should happen anyway. >>>> But even if it doesn't I believe that the packages would be upgraded >>>> to non-modular, assuming their EVR is higher. I might be wrong thou, >>>> because the concept of removing packages from modules and making them >>>> non-modular is full of booby traps. >>> >>> The module reset is essential, because otherwise DNF will keep using >>> fail-safe module data on disk and that would still keep the package >>> filtered. >>> >>> I suggest making the change in F33 / Rawhide. >>> Rawhide shouldn't break, because there's only one (the latest) version >>> of each module in the repodata and if you release a new modulemd without >>> the package, everything should work as expected. >> Your suggestion implies that there's a way to build different set of >> packages for different releases within the same module stream, right? >> >> Because with what Miro said, we are stuck with the requirement to update >> every package we have in the module until f32 is EOL. I can't just drop >> package x from modulemd and say "x won't be ever updated in f32 because >> modularity" :( >> > The F33 change I suggested doesn't retrospectively apply on F32. > You're really stuck maintaining the package until F32 EOL. Yes, that's something I already accepted. The real question is how to do the change in f33 considering that f32 and f33 modules must be built from the same modulemd file. I only see the ability to disable module stream build for f33. And now I'm curious what would happen if I specify `platform: [-f33]` and publish new module build. Would that remove previously published metadata from rawhide? I guess the right answer is somewhere around servicelevels and `eol` specification. -- With best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Removing packages from module
On 7/17/20 3:27 AM, Daniel Mach wrote: > Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a): >> If the package was part of the module during the release of Fedora 32, >> dnf will see 2 versions/builds of the module-stream: >> >> - the one that existed during the release (containing the package) >> - the one from updates (no longer containing the package) >> >> The "original" version will still filter out the non-modular version >> of the package from any transaction. >> >> And given the way modular filtering works, a package cannot >> technically be "demodularized" this was during one release, unless you >> force a module reset from another package's scriptlet. Thanks for clarifying this, Miro. So the filter is built based on the module metadata instead of the installed packages. I guess I misunderstood that part. That's just sad. I woke up with the bright idea about removing the packages from modulemd and then adding `sway-module-obsoletes` which Obsoletes everything in the module that's behind f32-updates. We have several packages like this since the last module rebuild. If there's a cached non-updateable module metadata from fedora-modular which is always considered by dnf together with the updated version from fedora-updates-modular, that had no chance of working. >> During the update to Fedora 33 a modular reset should happen anyway. >> But even if it doesn't I believe that the packages would be upgraded >> to non-modular, assuming their EVR is higher. I might be wrong thou, >> because the concept of removing packages from modules and making them >> non-modular is full of booby traps. > > The module reset is essential, because otherwise DNF will keep using > fail-safe module data on disk and that would still keep the package > filtered. > > I suggest making the change in F33 / Rawhide. > Rawhide shouldn't break, because there's only one (the latest) version > of each module in the repodata and if you release a new modulemd without > the package, everything should work as expected. Your suggestion implies that there's a way to build different set of packages for different releases within the same module stream, right? Because with what Miro said, we are stuck with the requirement to update every package we have in the module until f32 is EOL. I can't just drop package x from modulemd and say "x won't be ever updated in f32 because modularity" :( -- With best regards, Aleksei Bavshin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Removing packages from module
Hi, I'm considering dropping some packages from sway:rolling modulemd definition, however I don't clearly understand what would be the resulting upgrade behavior. Let's assume that the module is already enabled and all the packages are installed in the user's system. Also, the module was containing the same set of packages during f32 release (i.e. in fedora-modular). In an optimistic case I'd like to believe that once the package is removed from the modulemd file and a new module update is published, the override magic hacked into dnf would stop masking package from non-modular repository. NEVRA would be the only factor deciding the update priority and when we push new build of the package into f32-updates it would update the remaining modular build of the package with lower EVR. In a pessimistic case I expect that the package removed from the module will never be updated by dnf in the same release cycle since the already installed version originates from the modular repository. Upgrade to f33 would require module reset. I have zero knowledge on the modularity implementation so I would appreciate if anyone could clarify which behavior is more likely to happen before we start experimenting on real users :) -- With best regards, Aleksei Bavshin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
wlroots soname bump
Hi list, wlroots will be updated to 0.11.0 in rawhide next week. The update breaks API/ABI and will change soversion from 5 to 6. Dependent packages: - phoc - sway - wayfire For all affected packages I identified either upstream release or interim patches restoring their functionality. I already sent details to a narrower list of recipients and I'll contact maintainers of the affected packages once more when we publish the wlroots build. -- With best regards, Aleksei Bavshin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: pagure ssh key
Hi Samuel, SSH access to src.fp.o is limited to packagers. However you can push to your fork via http as described here: https://docs.fedoraproject.org/en-US/ci/pull-requests/ On Tue, Apr 14, 2020 at 2:15 PM Samuel Sieb wrote: > > I'm wanting to make a pull request on src.fedoraproject.org, so I need > to setup an ssh key. According to the docs at > https://docs.pagure.org/pagure/usage/first_steps.html, there should be > an authentication section in my settings, but there isn't. Then I > remembered that I added an ssh public key to my FAS profile on > admin.fedoraproject.org. I checked that and it's valid and matches my > key. I've given it some time (hours) in case there's some delay needed > after forking. However, I'm still getting an authentication error when > trying to clone using git over ssh. > ss...@pkgs.fedoraproject.org: Permission denied (publickey) > > Is there something I'm missing? I'm not a packager, but I have a FAS > account and it let me fork the repo. > ___ > 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 -- With best regards, Aleksei Bavshin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: f32-backgrounds available for testing
> > For the Design team, new change is the drop of standard, normalish, tv, > tv-wider folders in favour of a single wallpapers (aside the time of day > theme) using system settings thus tremendously saving space. > Does desktop-backgrounds-compat have a fix for that change? I remember that it had symlinks to all these folders and files. With best regards, Aleksei ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Guile exception caught in /usr/lib/rpm/find-debuginfo.sh
Hi Dan, Sounds like you need to add explicit '--without-guile' to GDB_MINIMAL_CONFIGURE_FLAGS. Otherwise it autodetects to enabled. -- With best regards, Aleksei ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: Aleksei Bavshin
Hi all, My name is Aleksei and I'm Russian living in the San Franciso Bay Area. I've been using Linux at home since 2003 and developing closed-source Linux software for my daytime jobs over the last decade. I started with Mandrake 9, tried ALT, spent a few years with Slackware and finally ended my pursuit of a perfect distro on Fedora 9 (Sulphur). Been using and promoting Fedora ever since; Linux users from Tomsk, Russia may still remember my efforts on keeping a mirror of Fedora repository in a city intranet and packaging small things missing in official repos. I'm also a fan of tiling window managers; have been using xmonad and awesome wm for a while until certain hardware issue made me switch to wayland. Nowadays my main wm is sway, and I'm joining Fedora to make contribution to sway ecosystem. My first package will be waybar, which I'm finally moving from copr to the main Fedora repository. Afterwards I'll be looking for other missing bits that would help sway users. Looking forward to doing something for my favorite Linux distribution. -- With best regards, Aleksei Bavshin ___ 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
